<< 前へ | Home

これまで体験してきたメール送信の難しさ #SendGrid_jp

SendGrid Advent Calendar 2016の12月22日分です。

メールを送る際、プロトコルとしてSMTPが使われていてメールサーバにはPostfixやGoogleのメールサーバなどを使えば簡単というのは割と有名です。
が、送るのは簡単だけど何かと問題が発生するものです。

私のこれまでの経験をちょっとメモしておこうと思います。

メール配信周りの運用経験


1. 自宅サーバ運用の掲示板(James、2000年〜)
2000年くらいから自宅サーバで掲示板を運用していました。Tomcatで動くServlet + JSPのアプリケーションで、メールアドレスを登録しておくと新規書き込みがメールで通知されるというものです。
メールの配信にはPure JavaのメールサーバであるJamesを使っていました。
自宅サーバで運用してた(今も動いてるけど)のは勉強、練習みたいなもので特にサーバの運用が好きなわけではありません。なんかガラケーで届かないと訴える人が多いなーと思いながらなんとなく運用していました。

2. 自宅サーバ運用の掲示板(Google Apps、2007年〜)
たしか自宅サーバのマシンを更改するタイミングでJamesの運用が面倒になり、Google Apps for Domainからメールを送るようにしました。
なんとなくガラケーにも届きやすくなったような??

3. いくつかのドメインでのメール運用(Google Apps)
友人知人のWebサイトやドメインを運用する中、もちろんたいしてお金はもらっておらず責任はとれないということで自宅サーバでの運用ではなくGoogleでメールの送信をしていました。

4. 会社のメール運用(Google Apps、2013年〜)
会社のメールもやはりGoogle Apps(現G Suite?)を使ってます。

勉強不足で、ボンヤリと「メール配信はなんとなく自前でサーバを建ててもよいし、GoogleのSMTPサーバを使うも良いし、なんでも良い」と長年思っていました。時々配信に失敗しているなーと思いつつ。

起きたトラブル


1. ガラケーに配信されないことがある
ガラケーの、いわゆる「キャリアメール」については「届かないことがある」「全く届かない」という話がボチボチありました。自宅掲示板サーバは商用環境の運用ではないので大して調べもせず、ドメインのホワイトリストに入っていないからとか、リンク入りのメールは全部拒否する設定になっているとか、PCメールは受け付けない設定になっているから、といった理由だと思っていました。(それらの理由による不達も多いにあると思いますが
実感的にJamesからGoogle Appsにしてから到達率は少し増えたように感じます。

2. ガラケーじゃなくても配信されないことがある
Google Apps for Domainを使っていればガラケー以外は大丈夫だろうとたかをくくっていましたが、会社のメールもたまにとどいてないらしいことが分かりました。長い間、相手側のサーバの不具合だと決めつけていました。

3. 文字化けが起きる
メールのエンコーディングは日本語を送るのに一番無難(と思っている)ISO-2022-JPで送っていました。UTF-8に固定しているような人でないかぎり正常に読んでいただけます。
が、お客様のお名前で「山﨑」といった異体字が使われているとJavaのプログラム内では正常に扱えても、ISO-2022-JPに変換するタイミングで"?"に化けてしまいます。

4. 24時間メールが配信できなくなる
オフィスを移転した際、移転のお知らせをお客様にメールで一斉に送付しました。自作のプログラムで、顧客リストをグルグル回しながら順に送っていったのですが、途中から送信できなくなりました。エラーメッセージを調べると、どうやらGoogle Apps for Domainではメール配信数に上限があることがわかりました。(無料だと24時間で500、有料では2000件)
移転のお知らせを送れないのは全く困りませんが、受注の確認や、ライセンスが送付出来ないのは大問題です。

とった対策


1. / 2. SPFレコードを設定しました。知っている人からすればビックリでしょうが、なんと会社を立ち上げて2年もの間SPFレコードを設定していませんでした。

SPFレコードはDNSに設定するもので、「このドメインからはこのIPアドレスからメールを配信するよ」という宣言です。得体の知れない人(送信元IPアドレス)が「これが株式会社サムライズムからのメールです」と主張して手渡してきても確証が得られないので、「これは送信元ドメインを偽装しているのでは?」と疑われてしまうわけです。
SPFレコードを設定しておけば「弊社からのメールはGoogleのSMTPサーバから配信されますよ」と宣言できるので、疑われにくくなるという仕組みです。
「メール配信はPostfixでもなんでも、メールサーバがあれば送れるさ!」と思っているエンジニアは結構多いので気をつけましょう。

3. 「必要に応じて」UTF-8にする
異体字に対応すべく、ある時期からメールを全部UTF-8で配信するようにしました。イマドキさすがにUTF-8が読めないクライアントはないだろう、と踏んでのことです。
が、それなりの数のお客様から「化けていて読めない」という声を頂くようになりました。異体字が含まれるメール以上の数なので問題です。
そこで今では「基本的にISO-2022-JP、ISO-2022-JPで表せない異体字が含まれる場合はUTF-8」で送信するようにしています。以降文字化けは起きていません(聞く限りは)。

4. 大量配信しない
問題解決ではなく、消極的な回避ですがまとめて配信することは移転のお知らせで一回やっただけでやめにしました。

以上、SendGridとは間接的にしか関係ないけれども「メール配信をナメてかかると痛い目に遭うよ」という話でした。
文字だらけで申し訳ないですが、経験に学ぶのは愚か者なので、これからメール配信をする可能性のある方は歴史に学んでいるSendGridを初めとするメール配信サービスを利用することをお勧めします。
株式会社サムライズムでは少しずつ検証を重ねながら、今週から全面的にSendGridでメール配信をするように切り替えました

現状どのように使っているか、どういう点につまずいたのか、などはまた別途まとめたいと思います。

このエントリーをはてなブックマークに追加   

BPMエンジンとしてのJIRA #augj

TL;DR


JIRAでBPMとか考えるのはやめましょう。でもちょっとしたシステムと人間系ワークフローとの連携に使うのは良いアイディアです。

今更だけどJIRAって?


JIRAは一般的にバグトラッキング、または課題トラッキングシステムと分類される製品です。

良くあるのがソフトウエア製品の今後追加する機能やバグを課題として登録しておき、担当者を決めて、終わったら完了済課題としてマークしていく使い方ですね。

JIRAが導入されている企業、プロジェクトは非常に多く、そして様々な場面で利用できるようカスタマイズの幅も広いです。

ワークフロー


中でも便利なのが「ワークフロー」です。つまり、課題が登録されてオープン状態なのか、完了してクローズしている状態なのかだけでなく、課題が登録されてから完了するまでワークフローがたどる可能性のある状態をグラフで表せる機能です。例えば注文を頂いたら

・受注内容を確認する
・確認完了したら上長の決裁を待つ
・決裁が完了したら手配して終わり

というワークフローがあれば以下のように定義します


ちなみにこのグラフィカルに定義できる仕組みは元々サードパーティーのプラグインだったのが、出来が良いので買収の上取り込まれたという経緯があります。ステキ。

ワークフロー上で状態を遷移するタイミングで決まった人に担当を変えるとか、特定の条件が揃っていないと状態を遷移できないとか、遷移のタイミングでWebhookを呼び出すといったこともできます。

ビジネスプロセスマネジメントとワークフロー


エンタープライズ系のベンダに勤めていた私はワークフローと聞けばBPM(ビジネスプロセスマネジメント)を思い浮かべます。BPMはビジネスプロセスを分析/解析して、可視化・システム化して、監視、改善していくことです。

なんとなく口頭伝承されてきたプロセスは人によってブレがあったり、間違いがあったりします。必ずしも人間の作業をシステムで全部置き換えるところまでいかなくても、まずは作業の流れを統一してブレをなくすことが大事です。

その後は運用状態を監視して、どこにボトルネックがあるのか、手戻りが発生しやすいのはどこなのか、ここは自動化すべきなのでは、といったことを分析して改善していきます。

BPM用の製品として(自分的に)有名なのがAlfrescoや、jBPMです。

BPM製品では人間系がからむ承認といった手順とシステムで自動化させたフローを管理できます。

JIRAでBPM・・・に向かない


結論から言うと、JIRAでBPMを行うには制約が大きすぎます。理由はさくっと2つ思い付きます。(細かいこと考えるといくらでもあります)

1. フローの平行パスを定義出来ない
ビジネスプロセスを分析すれば、例えば
「課長と部長の承認がいるけれども順番は問わない」
「システムが集計しているのと平行して人間は請求書を投函する」
みたいな平行パスが現れてきます。JIRAのワークフローは2つ以上の状態を持つことができないので、フラグ用のフィールドを持たせるとか、サブタスクを定義するといった設計上の工夫が必要になります。「工夫」で回避できますが、ビジネスプロセスを俯瞰して監視、管理したいという点からするとちょっと辛いですね。

2. トランザクション管理ができない
エンタープライズシステムでは1にも2にもトランザクションです。特定の処理が失敗したら関連する処理はまとめてロールバックしたいところ。JIRAで、状態遷移するタイミングでWebhookで何らかの一連の処理を呼び出すことはできますが、処理が失敗したからといってまとめてロールバックしてくれるわけではありません。まぁHTTPを超えてトランザクションを管理しようとする試みは間違いだということは歴史が証明しているのでJIRAのワークフローとトランザクショナルな処理を絡めようという発想はやめましょう。

というわけでBPMをしたいならBPM製品を使うべきです。

JIRAでBPMができるパターン


本格的なBPMには向きませんが、ちょっとした人間系フローと、システムの連携にJIRAは便利です。ざっと2パターン紹介します。

・おい人間やっとけパターン
弊社=株式会社サムライズムで活用しているパターンです。ソフトウェアの販売をしているサムライズムですが、ご注文頂いたライセンスを手配する作業は*だいたい*システム化しています。*だいたい*というのが肝で、システムで自動化できていない部分があるのです。
具体的には一定の割合で請求書の書面を郵送して欲しいというお客様に対して
・請求書を印刷
・3つ折りにして封筒に入れる
・投函する
という作業が発生します。こちらはMisoca APIとかを使えば自動化できるのですが頻度、分量としては多くないので人間が運用でカバーしています。
人間がやるべき作業は忘れてしまいがちなので、システムから自動的に課題を登録して作業の完遂を促しています。システムから課題の作成するには公式のJavaライブラリを使っていますが、Atlassian独自醸造Apache HttpClientライブラリに依存しており数多くの他製品と競合しますので皆さんがんばってください。REST APIを直接叩くのがいいかも・・・。

郵送が必要な場合、機械が人間に依頼するコード(㍿サムライズムの本物のコード)

・人間も機械も仲良くパターン
ワークフローに平行パスがなく、一部システムで処理をしたい部分があればちょっとしたBPM的にJIRAのワークフローを使えます。そしてシステムが処理するのは遷移中にWebhookを呼び出すのではなく、状態として定義するのが良いです。(たぶん。でも場合による)。
システム用にユーザーを一人割り当て、状態遷移のタイミングで担当者をシステムに割り振るように設定しましょう。するとシステム処理中、人間には「担当している課題」として見えないので安心ですね。システム側で処理がうまくいかない場合、リトライを重ねることもできますし、リトライ試行回数を超えたら「失敗しました」、みたいな状態に遷移させてもokです。
(BPM製品だとビジネスプロセスとしてリトライ回数や例外系へのジャンプの定義が出来たりします。JIRAでやる場合は自前で)

いかがでしたでしょうか。長々と文字だけで書き連ねてしまいました。JIRAは主に人間系の課題の管理に使うのに向いていますが、工夫次第ではシステムと人間の連携にも使えます。
あまりにも工夫が必要な場合はJIRAを適用すべき場面ではないかもしれません。うまいことやってください。

このエントリーをはてなブックマークに追加   

JJUG CCC 2016 Fallに参加しました #jjug_ccc #ccc_l6 #ccc_cd7

日本Javaユーザーグループ(@JJUG)が年二回開催しているカンファレンス、JJUG CCCの秋版、JJUG CCC Fall 2016に参加しました。

CCCはTポイントとは関係なくて「クロスコミュニティカンファレンス」=「様々なコミュニティが交われれば、Javaだけにこだわらずにね」、みたいな意。

今回はスポンサーとして、そしてスピーカーとしての参加です。スポンサーとしては沢山の人に自慢の、お気に入りツールのご紹介が出来て大変有意義でした。

ご立派に出来上がった弊社ブース

・受験勉強経験も留学経験もない日本人がJavaOneで英語で講演できるようになるまで
セッション1つ目。外資系の勤務経験が長かったり、JavaOneで講演したり、海外のベンダと取引していて「割と英語出来る」立ち位置を獲得している自分。
でもハーフでもないし、留学経験もない。しかも多くの人がガッツリ英語を勉強するであろう大学受験もしていない自分がどうやってここまで頑張ってきたのかを説明して参考にして頂ければ、というセッションで話をしました。

小部屋で20分のセッションは立ち見(というか座り見)が沢山の満席。

英語の上達に王道はたぶんなく、あくまで自分の場合何をしてきたかということを参考情報としてお伝えしました。日頃より伝えたい話だったので、沢山の方々に前のめりで聞いていただけて良かった!
また機会があればこの話はもっとして伝えたいです。

感想を含んだブログ:
JJUG CCC 2016 Fallに参加してきました! #jjug_ccc - Challenge Java EE !
JJUG_CCC 2016 Fallに参加しました! #jjug_ccc - 僕はここだ!


JJUG CCC 2016 fall 参加報告 - エンターテイメント!!



ステッカーはいつもながら好評!

・Javaエンジニアのキャリアを考えるパネルディスカッション
大谷さん(@johtani)の(と?)応募したセッション。モデレータとして主に話を聞く側として参加させて頂きました。
Java界隈のエンジニアを経て現在はクックパッドで人事部長をしている(@yoshiori)さん、Java関連で調べ物をすると必ずヒットするHishidama's Java Memoの(@hishidama)さんを交えての4人で臨みました。
それぞれに違うキャリアを築いており、三者三様(私の話も交えたので四者四様?)の話が出て大変有意義でした。違うキャリアながらも共通項も大いに見いだせて私自身も参考になった点が多くあります。

感想を含んだブログ:
JJUG CCC 2016 fall 参加報告 - エンターテイメント!!

タグ :
このエントリーをはてなブックマークに追加   

4/2(土) Kotlin 1.0リリース記念勉強会 in 京都に行ってきました #kotlin_kansai #jkug

JetBrains黙認Kotlinエバンジェリストである@ngsw_taroに誘われ、4/2(土) Kotlin 1.0リリース記念勉強会 in 京都に行ってきました。

ふと気がついたら通常参加枠が満席でLT枠のみ!ちょうど良いので背水の陣ドリブンで自社システムへのKotlin導入をして勉強会に臨みました。
スライドはこちら↓

データクラスから始めるKotlin / JetBrainsに行ってきました from Yusuke Yamamoto


セッションで話したのは"左側"のみですが、会場では予想以上に"右側"を楽しんで頂けたようでなによりです!

KotlinはJavaに慣れている人にとって導入障壁が低く、かつモダンな言語の恩恵にあずかることが出来て良さそうだなーと思っていました。実際に試してみたところ予想以上にスムースに導入でき、作業を始めた当日にすんなりとプロダクションシステムに組み込むことができました。
既存のJavaのエコシステムに乗っかりやすく開発ワークフローを変える必要がなく、大変好みです。

最後にみんなでKotlinポーズ!


その他の方々のセッションの資料は以下のイベントのページに掲載されています。
4/2(土) Kotlin 1.0リリース記念勉強会 in 京都

まだまだ自分が試していない機能について紹介があり勉強になりました。自社システムで着々とKotlin化を進めていきたいと思います。
主催の関ジャバの皆様、ありがとうございました!

このエントリーをはてなブックマークに追加   

PHPカンファレンス福岡2015に行きました! #phpconfuk


PHPカンファレンス福岡2015に行きました。
生まれて初めての福岡。また近いうちに来ようと胸に誓いました。










































このエントリーをはてなブックマークに追加   

逆引きNashorn - やりたいことからNashornのサンプルコードを引く

機械校正ツールであるRedPen(ライブデモ)は、デフォルトで内蔵している沢山の校正ロジックに加え、ユーザーがカスタムロジックを実装することができます。
自分で実装するにはJavaでValidatorというクラスを拡張すれば良いのですが、間口を広げるためにJavaScriptでもロジックを実装できるようにしました。
RedPen自体はJavaで実装しており、JavaからV8などを呼び出すのは大変なのでJava8に内蔵されているJavaScriptエンジンであるNashornを使いました。

あちこちの情報をかき集めて工夫をしたので、ここにまとめておきます。
やりたいことと、実現するためのコードを逆引き的に並べています。実現方法は全部違うけれども、どのコードもHello Nashornと出力するだけです。

JavaScriptを呼び出す
JavaScriptの関数をJavaから呼び出す
JavaのstaticメソッドをJavaScriptから呼び出す
JavaScriptからJavaのオブジェクトを参照する(バインドする)
JavaScriptをコンパイルしてから呼び出す
JavaオブジェクトのメソッドをJavaScriptの標準関数のように呼び出す

簡単にビルド、実行できるようまとめたものはGitHubに置いてあります。(ASLと書いてあるけど、創造性を微塵も感じさせないコードなので好き勝手コピペしていただいても大丈夫かと)

JavaScriptを呼び出す
print関数を呼び出すだけのJavaScriptを実行します。getEngineByName()の引数はjsでもJavaScriptでもNashornでもok。
SimpleNashorn.java

public class SimpleNashorn {
public static void main(String... args) throws ScriptException {
ScriptEngineManager manager = new ScriptEngineManager();
// works also with "js" / "javascript"
ScriptEngine engine = manager.getEngineByName("nashorn");
// prints "Hello Nashorn"
engine.eval("print('Hello Nashorn');");
}
}

JavaScriptの関数をJavaから呼び出す
JavaScript内で定義してある関数をJavaコードから呼び出す。invokeFunctionの第一引数が関数名、第二引数は可変長引数で、第一引数で指定した関数に渡すパラメータを任意の個数渡せる。
InvokeJavaScriptFunctions.java
public class InvokeJavaScriptFunction {
public static void main(String... args) throws ScriptException, NoSuchMethodException {
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("nashorn");
engine.eval("function hello(message){print(message);}");
Invocable invocable = (Invocable) engine;
// prints "Hello Nashorn"
invocable.invokeFunction("hello", "Hello Nashorn");
}
}

JavaのstaticメソッドをJavaScriptから呼び出す
Java.typeっていうNashorn固有の機能を使います。
InvokeJavaStaticMethod.java
public class InvokeJavaStaticMethod {
public static void main(String... args) throws ScriptException {
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("nashorn");
// prints "Hello Nashorn"
engine.eval("Java.type('nashornsampler.InvokeJavaStaticMethod').hello('Hello Nashorn');");
}

public static void hello(String message) {
System.out.println(message);
}
}

JavaScriptからJavaのオブジェクトを参照する(バインドする)
JavaScriptとJavaで相互に作用のあるコードを書くときはこんな風に。
BindJavaObject.java
public class BindJavaObject {
public static void main(String... args) throws ScriptException {
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("nashorn");
engine.put("myObj", new BindJavaObject());
// prints "Hello Nashorn"
engine.eval("myObj.hello();");
}

public void hello(){
System.out.println("Hello Nashorn");
}
}

JavaScriptをコンパイルしてから呼び出す
JavaScriptコードを一旦Javaのバイトコードにコンパイルしてから実行します。繰り返し呼び出す場合は高速。Java8u40以降であればコンパイル結果はキャッシュされるのでJVMを再起動しても速攻でコンパイル結果が得られるらしい。
InvokeCompiledJavaScriptFunction.java
public class InvokeCompiledJavaScriptFunction {
public static void main(String... args) throws ScriptException, NoSuchMethodException {
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("nashorn");
CompiledScript compiledScript = ((Compilable) engine).compile("function hello(message){print(message);}");
compiledScript.eval();
Invocable invocable = (Invocable) engine;
// prints "Hello Nashorn"
invocable.invokeFunction("hello", "Hello Nashorn");
}
}

JavaオブジェクトのメソッドをJavaScriptの標準関数のように呼び出す
JavaオブジェクトメソッドをJavaScriptよりobj.method()ではなく、単にmethod()と呼び出したい場合はこんな風に。
(恐らく要Java8u40以降)
BindJavaMethod.java
public class BindJavaMethod {
public static void main(String... args) throws ScriptException {
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("nashorn");
engine.put("toBeBound", new BindJavaMethod());
engine.eval("var hello = Function.prototype.bind.call(toBeBound.hello, toBeBound);");
// prints "Hello Nashorn"
engine.eval("hello('Hello Nashorn')");
}

public void hello(String message) {
System.out.println(message);
}
}


関連記事:
Heroku Buttonで簡単にHerokuにデプロイ #herokujp - #侍ズム
WebアプリケーションをIntelliJ IDEAからHerokuへデプロイする #herokujp #jbugj - #侍ズム
Java WebアプリケーションをHerokuへデプロイする #herokujp - #侍ズム
Getting Started with Java on Heroku | Heroku Dev Center
RedPen を公開しました (ベータバージョン) | Advanced Technology Lab
社内共有会で使用した RedPen 資料と進捗 | Advanced Technology Lab

このエントリーをはてなブックマークに追加   

Twitter4Jが8周年を迎えました!お祝い募集中 #twitter8j

Twitter4Jを公開したのが2007年6月9日。
Twitter4J 1.0 リリース - #侍ズム

今年でなんと8周年を迎えました。自分が開発してきた中では一番手間暇、時間を掛けているコードになります。

レートリミット、画像アップロード、ハッシュタグ、リツイート、幻のアノテーション、リスト、ストリーミングAPI・・・・そしてAPI1.1。とてつもない速度のアップデートに逐一対応してきました。

最近は新機能の追加はTwitterと連携するアプリケーションを開発している開発者達によって行われています。自分がやっているのはpull requestのレビュー/マージやLambda対応、可変長引数の導入(最近まだJava1.4互換にしていた関係で使っていなかった)など。

「クローズドベータのAPIアクセス権も一部もらっているのでそこらへんの開発はやっていかないと!」と1年前にも書いているのですが、やっていかないと!

ここ毎年活用させて頂いていますが、応援の声を物(Amazonギフト)で届けてくれるサービス、Kampa!でお祝い、応援の声を集められればと思います。

Twitter4Jでなにか楽を出来た方、勉強になったよ!応援してるよ!という方、実際にアプリ・サービスで使っているよ!という方、以下のリンクよりカンパをいただけるとうれしいです(15円からカンパできます)。




もちろんカンパをいただかなくても日頃の「ありがとう」の声、ツイートでもたくさんたくさん元気がでるので今後ともご声援をいただければ幸いです。

なお、カンパしていただく際はどなたから送られてきたか分かるよう、メッセージにお名前やハンドル、そしてもしよろしければ以下に掲載するための情報をご記入いただければと思います。(どうしてもという場合はもちろん匿名でも結構ですが)

また昨年と同じく、カンパしてくださった方・プロジェクト・企業のロゴ/リンクを随時このエントリに貼り付けていきます。
必ずしも掲載している企業やプロジェクトがTwitter4Jを活用しているわけではありません。(順不同、大小不同):

セガの岩﨑さん(@twtrfk)はバーチャファイターを始めとするアーケードゲームのTwitter連携にTwitter4Jを活用してくださっています。

Virtua Fighter5 Final ShowdownのTwitter連動機能について #twtr_hack from Takeshi Iwasaki

・Virtua Fighter5 Final Showdown:バーチャファイター5 ファイナルショーダウン


・初音ミク Project DIVA Arcade Future Tone


岡山で、東京で、サンフランシスコで、お世話になってます!:


@sue445作:
Azusaar!!(いつもAPIを利用させて頂いてます!)


ツイ廃あらーとの(@MulticolorWorld)、昨年に引き続き応援、ありがとうございます!
毎日0時にツイート数等の統計をツイートしてくれるサービス:

ツイ廃あらーと開発日誌 | 開発中のこととかいろいろ

Java EEについて、堀北真希さんについてたくさん情報発信してくださっているキクタローさんから。ありがとうございます!:



Groovyを初めとする最新情報を発信してくださっている@grimrose。ありがとうございます!:


ざきやまさん(@z_a_ki3)ありがとうございます!
おれろぐ #z_a_ki3


画像収集ボットなどを開発していらっしゃる@gecko655、ありがとうございます!:
・\アッカリーン/ (@akalin_kotlin)


・藤宮香織(@Fujimiya_Monday)


以前Twitter API勉強会で学習して対話できるボット、わけちを紹介してくださった@kaiba、ありがとうございます!
わけち(waketi)の紹介
あれ、なんかアイコン変わった?

ブログ:
Pokosho!

@bina1204より。いつもマラソンと英語の勉強応援してます!:
I Wanna Be β | 何事も人並みに

@jjugでいつもお世話になっている@megascus、ありがとうございます。
熊本でのご活躍をお祈りしてます!:
水まんじゅう
熊本で働いてくださるITエンジニア募集 - 水まんじゅう

@kt81より。いつもIntelliJ IDEAのご利用ありがとうございます!


@ijufumi_0810より。IntelliJ IDEAのご利用ありがとうございます!


Twitter4Jのプルリクエストもお送り頂いたことがある小宮さん(@komiya_atsushi)より、出張前のお忙しい中お祝いを。ありがとうございます。

blog.k11i.biz

http://www.slideshare.net/komiyaatsushi

自動校正ツールRedPenなどを開発してる(私もコントリビュートしてます)、@takahi_iより。ありがとうございます!

Github - RedPen

そして、RedPenをお試しいただいたこともある@kubosho_より。ありがとうございます!
I'm kubosho_


Twitter4Jにコントリビュートしてくださっている@fat_daruuuumaより。ありがとうございます!
でぶだるまは赤だるま


@zinbeより。ありがとうございます!

我らねぶた馬鹿

@morizo_999より。ありがとうございます!

I Wanna Be A Clean Corder

岩切さん(@kohsei)より。ありがとうございます!


よすけっちょさん(@aeolia)より。ありがとうございます!


@objectxplosiveより。ありがとうございます!


Twitter4JのHTTP2対応や、様々なプロパティの追加など多大なコントリビュートをしてくださっている竹内さん(@takkeより。ありがとうございます!

ついっとぺーん


大きな電話帳


黒田さん(@i2key)より。ありがとうございます!Twitter API勉強会のときからのつながり?長い!
そして最近はスプラトゥーンで一緒に遊んでいただいてます!


最近リッター3Kで打たれまくっている@eiryuより。ブログもいつも参考にさせていただいています。ありがとうございます!

コードつれづれ

いろいろな勉強会で、そしてSpring Bootの本でお世話になっている@makingより。ありがとうございます!

BLOG.IK.AM


やまもとゆうすけさん(@doenis05)より。研究室時代より5年ほど、Twitterのデータを使うときにTwitter4Jを使って頂いていたそうです。ありがとうございます!


@MegaBlackLabel)より。いつもTwitterでお世話になっております!



関連記事:
Twitter4Jが7周年を迎えました!お祝い募集中 #twitter7j
Twitter4Jが6周年を迎えました!お祝い募集中 #twitter4j6thanniversary - #侍ズム

このエントリーをはてなブックマークに追加