System.nanoTime() をJMockitで乗っ取る
Javaでミドルウェアなど書いていると必然的に内部でタイマーを作ったりすることになってその制御に System.nanoTime() とかを使うことになると思うんだけど、じゃあテストどうしよっかと思うと、テストでは、まあ好きなタイミングで時間を進めたり好きなところで時間を止めたりってことが普通したいじゃないですか。どうすんのという話。
JMockitを使う
とりあえずJMockitを使っとけという話っぽい。static methodをモックできるのはこれしかない*1。
JMockitは理想的なモックフレームワーク - じゅんいち☆かとうの技術日誌
ちょいちょい調べると例が見付かるので真似る。
import org.junit.Test; import static org.hamcrest.Matchers.is; import static org.junit.Assert.*; import mockit.Expectations; import mockit.Mocked; public class FooTest { @Test public void testTimer(@Mocked System unused) { long current = System.nanoTime(); new Expectations() {{ System.nanoTime(); result = current; }}; assertThat(System.nanoTime(), is(current)); } }
JUnit4に怒られる
コンパイル通ったぜー、と思うとなんかテストでコケる。
java.lang.Exception: Method testTimer should have no parameters
調べてみたらこんなのが見付かった。要はJUnitよりも前にJMockitを書いておけと。えー、と思いながらとりあえず build.gradle を変更してみた。
dependencies {
// jmockit should be written before junit
// http://robertmarkbramprogrammer.blogspot.jp/2013/03/eclipse-and-jmockit-method-should-have.html
testCompile group: 'org.jmockit', name: 'jmockit', version: '1.33'
testCompile group: 'junit', name: 'junit', version: '4.11'
testCompile group: 'org.hamcrest', name: 'hamcrest-all', version: '1.3'
// ...
}そしたら期待通り動いてしまった。えー。ジャバむずかしいな。
(追記) なんか期待通りに動かない
複数のテストケースでそれぞれ違う値でモックしようとしたら結果がおかしくなる……みたいなのが多発してこれはやばいということになった。調べるとJITが走ったらダメになるみたいな話もあるし、ここで苦労するべきではないと判断。撤退。
*1:今でもそうなのかな? まあ、たぶんそう
okhttpで非同期リクエストを実行するとき実行スレッドはどうなっているのか
複数のホストに並行してHTTPリクエストを送るコードをJavaで書く必要があって、Undertowをサーバに使ってるんでUndertowの http client でもいいかなーと思ってたんだけど、okhttpにも非同期リクエストの機能があるみたい。
ただパッと見て実行スレッド数の設定とかどうなっとるんや、というのが全くわかんなかったのでちょっとコードを追ってみたところ、以下のような感じのコードを発見しました。
呼び出し順としてはの以下ような感じ。
- OkHttpClient.newCall(Request req)
- Call.enqueue(Callback callback)
- RealCall.enqueue(Callback callback)
- client.dispatcher().enqueue(new AsyncCall(responseCallback)); ココ
なんで、この dispatcher() で返ってくるやつの正体を見ればどう制御してるかわかるだろ、って追ってみたらこんな。
https://github.com/square/okhttp/blob/master/okhttp/src/main/java/okhttp3/Dispatcher.java#L63
public synchronized ExecutorService executorService() { if (executorService == null) { executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS, new SynchronousQueue<Runnable>(), Util.threadFactory("OkHttp Dispatcher", false)); } return executorService; https://github.com/square/okhttp/blob/master/okhttp/src/main/java/okhttp3/Dispatcher.java#L63}
ThreadPoolExecutorの引数は corePoolSize, maximumPoolSize, ... なので、なんかもう無限に(ではないけど)スレッド作る感じですね! 気合いが入っている!!
で、これはねーなと思いかけたんだけどちょい上のほうを見ると Dispatcher(ExecutorService executorService) というコンストラクタがあるので、外で設定済みのexecutorServiceを渡してDispatcherを作り、それを OkHttpClient.Builder.dispatcher() に渡して build() すれば設定済みクライアントが作れそう。
ちょっとめんどいな。
EmacsでJava開発をする @ 2017
お仕事でそれなりにまとまったJavaのコードを書くので、ちょっと真面目に手元の環境をアップデートしようと思ったらいろいろあったので、メモを兼ねてまとめる。なお手元の環境のアップデートにともない、次のエントリを大きく参考にさせていただきました。多謝。
qiita.com
なおそれまでの環境は EmacsでJavaを書く - nekop's blog を元にだいぶ前に整備したもので malabar-mode をずっと使ってたんだけど、Java8 Lambdaでインデントが崩れるとかいろいろあってちょっとストレスフルだったのが主なアップデート動機。
環境は OS X El Capitan *1 + Emacs 25.2 で、全面的に MELPA をつかってパッケージ管理やっている。
結論
最終的には ENSIME (の ENJINEモード) を使っている。これでコンパイルエラーを出すとかメソッド名を補完するだとかのエディタ上で最低限欲しい機能はだいたい揃った。ちょいちょい動かない機能とかEmacsを巻き込んでクラッシュする機能とかがあるけど、自分は元々エディタ上で操作を完結させたいとか思わない*2ので、まあこれくらいでいいやと。
その上でコードの自動フォーマットをチーム内で揃えるため、別途コマンドラインツールと git pre-commit hook の組み合わせで自動フォーマッタをかませることにしようとしている。これに使えるものもいろいろ考えたけど、IntelliJ IDEAにコードフォーマッタがあることを知ったのでこれを使うことにした。IntelliJ IDEAはエディタとしては使いたくないけど、コマンドライン起動するためにインストールするくらいはなんでもないぞ。
#!/bin/sh CURRENT_DIR=$(pwd) SETTING=$CURRENT_DIR/misc/airlift-codestyle.xml FORMATTER="/Applications/IntelliJ IDEA CE.app/Contents/bin/format.sh" exec 1>&2 # .java files to be committed files=$(git status --short | grep -E '^[AM] .*\.java$'| cut -c4- | sed -e "s|^|$CURRENT_DIR/|") echo "$files" | xargs "$FORMATTER" -s $SETTING echo "$files" | xargs git add
こんな感じのスクリプトを書いて pre-commit hook として使う。設定ファイルを与えられるんだけど、ここではPrestoとかでも使われてるAirliftの設定ファイルを与えることにしている。なぜか。まあ自分にとってもこのスタイルはそんなに悪くない。あんまり主張が強くないし。
問題はあって、なにしろ(Javaのコードを含んだ)commitのたびに裏側で IntelliJ IDEA を起動するので、遅い。あとなんかログとか警告とかも流れてきてちょっと邪魔い。けどcommitの頻度自体そんな高いもんじゃないし、まあいいかなと思っている。好きなエディタ使えるほうが大事。
ENSIMEの環境設定
正直、これはだいぶ大変だった。が、たぶん最適解が分かってればすぐ終わるんじゃないかなという気がする……。たぶん。基本的には Installation · ENSIME に従えばよい。あとプロジェクトが gradle を使っているので Gradle · ENSIME も。
が、いろいろ試したところうまく動かない組合せが多く、唯一動作したのは ENSIME 0.2.8 (stable) と gradle 3.3 の組合せだけだった。unstable (0.3.0-SNAPSHOT) を使うケースだと gradle 3.5 ではバグってて動かず gradle 3.4 では動くように見えるんだけど、Emacs側で melpa から unstable 版を入れて読み込もうとすると .ensime の形式がおかしいとか言われて動かない。
stable版はどうかと ENSIME 0.2.8 を使おうとしたら gradle 2.4+ との組み合わせだとバグってて動かないので gradle 3.3 までダウングレードしたら動いた。これを melpa-stable 経由でインストールした ENSIME 0.2.8 と組合せるとなんとか全体が動作するようになった。
今のところはバッファ開くたびに M-x ensime して有効にしている。しかしなんか同じプロジェクトのクラスを見付けてくれないことがあったり、build.gradleに設定してある依存ライブラリを見付けてくれないことがあるように見える。なんだかなー。まあ、自分にとってはそこまで致命的ではない。
Meghanada
他の選択肢は? というと、いくつか試してはいる。最初に試したのは Meghanada-Mode で、実際にこれはすばらしくセットアップが楽だった。が、最初に試したときは meghanada-mode を有効にしたあとで C-i したらEmacsごと固まる、という状況で、ちょっとこれは……という感じでいったんやめた。
その後に init.el の大掃除をしたあとでもう一度試してみたら動くには動いたんだけど、機能によってはやっぱり何のデバッグメッセージも無しに固まる症状がちょいちょい見られたりして、きびしい。あと手元ではコンパイル時警告が出てる場所の色付けみたいなのも動いてなかったので、機能として無いのか単に何かがおかしくて動いてないのかは知らないが、あまり便利とは言いがたい状態だったのでいったん使用をやめた。
何しろインストールが楽なので、使えれば使いたいんだけどなー、という状況でした。コードの自動フォーマット機能があるのはすばらしいけど、フォーマッタをどうにかして設定できないかなあ、という気もする。
今後に期待。
Google-java-format
エディタはどうにかするとしてコマンドラインフォーマッタはどうか、と思って見付けたのが google-java-format なんだけど、デフォルトのコーディングスタイルがちょっとアレすぎて使うにはアレ……。2スペとか。
なお --aosp というオプションが最近のバージョンで足されてて、これはどうも Android Open Source Projects 用らしいぞ、ということで試してみたら4スペだし、これはこれでいいかなと思いかけたんだけど、やっぱりちょっとクセが強い感じがした。主張つよくバリバリ修正されるんだけど、改行をやたらアグレッシブに入れるし、その割にここ改行しないんだ? みたいな納得いかない部分がちょいちょいあるし、lambda使ったときにインデントがやたら深くなる傾向があるし、ということで、きびしい。
途中まで使いかけたんだけど IntelliJ IDEA のフォーマッタを見付けたのでそっちに行った。
まとめ
がんばるしかないがちょっとつらい。
(5/29追記)
前のスクリプトだと modified だけど add されてないファイルまでpre-commit hookがgit addしちゃってたのでちょっと直した。
「そのデータ分析基盤、作るか? 使うか?」という話をしてきた
ファンコミュニケーションズさんが自社オフィスで勉強会をはじめるということで、第1回でしゃべりませんかというお誘いを受けたので参加してきた。お誘いありがとうございました!
内容はどうしようかなと思ったんだけど、相談してみたら過去のこのエントリのスタートアップ限定じゃない話とかどうかというものがあり、自分でも面白そうだったので、そんな感じで内容をまとめてみた。
まあトピックと自分の現在の勤務先からしてどうしても内容にバイアスがかかると思われるのはしょうがない……ので割り切った宣伝スライドはまあ1枚入れるとして、それ以外はいちおう公平な議論を目指したつもり。
で、中にも書いてあるけど、明確な結論なんてものはなくて、各社個別の事情にあわせてやりましょう。ただしこのくらいはどうせやらないといけないから、作りだす前に考えといた方がいいですよ、という内容になっている。まあ、やっぱり大変なので大きな企業で数十人単位のチームを作ってやってるところが多いですよねー、という。
やらないといけないことのバリエーション(==complexity)は企業の大小によらないので、どうしてもあまりエンジニアリングチームの大きくない会社だと難しいんじゃないかなとは思います。
とまあ、そんな感じのことをしゃべったり、DokkuやAkkaの話を聞いたり、あとは参加者の人のデータ分析関連のお悩みを聞かせてもらったりで、楽しいイベントでした。
プログラミングを始める動機はどこにあるのか、の話
あるいは「高校生からはじめるプログラミング」の話。
こちらの本をKADOKAWA様からいただきました。ありがとうございます。なぜ自分に……*1などと思わなくもなかったけど、ありがたく眺めさせていただきました。今となってはこういうガチ初心者向けの教本を眺める機会なんて皆無だしなあ。
SAOのコンテンツ力が表紙/裏表紙と章立てのページに発揮されてるけど、他のページはごく普通のプログラミング教本で、特に中身との連携はなかった。これで売上とか変わるのかな。変わりそうだなあ。
で、ざらっと眺めたあと、タイミングよくプログラミングを始める動機ってなんなんだろうな、と思ったので、それに絡めて書く。
本の中身
最近のプログラミングの導入ってそもそも何をやるの、みたいなのがぜんぜん分かってなかったので、ちょっと新鮮だった。思えば技術要素を特定しない「プログラミング入門」の本というのは人生で初めて読んだかもしれん。
章立てとしては以下のような感じ。
- 環境設定とHTMLの基本 (Chrome, VS Code)
- JavaScriptの初歩
- CSS
- JavaScriptによるアプリケーション作成
アプリケーションといってもWebブラウザ上で動く簡単なスクリプトで、要するにすべてがブラウザ上で完結する範囲。読みはじめるまでから読んでる途中でも、これどこまでやるんだろう、というのが分からないまま進んでたんだけど(なにしろ表紙に「N高校のプログラミング教育メソッド」と書いてある)、あとがきに書いてあった。最初の4月から6月のうちにやる部分だそうで。
まあ言ってしまえば本当に初歩の初歩なので、プログラミングというものを全く知らない人がこれに沿って体験してみる分にはいいんじゃないかと思う。演習問題も細かい単位で用意してあって、それも良さそう……たぶん。
プログラミングを始めたい人
ところでこの本を眺めててずっと不思議だったんだけど、これを読む人はどういう人なのだろう? ということ。つまり、対象のよくわからない「プログラミング」とは、誰がやりたいものなんだろう。
もちろんこの本もオビに「Webプログラミングの基本が身につく」と書いてあって、そうかWebプログラミングかと思いながら開いたんだけど、内容には(自分が無意識に期待していた)Webアプリケーションのサーバサイドのコードは登場しなかった*2。
まあそりゃそうか、環境構築とかも大変だからな、とは思うものの、つまり何を学ぶかがわかっていない人がとりあえず開く本として作られている、ということで、そういう本を誰が選ぶの? ということ。
N高校のプログラミングコースの生徒か。そりゃそうだ。
で、じゃあそもそもなんでその人はプログラミングがしたいの? それがわからない……のは、自分にそういう経験がないからなんだけど。
ところで、将来に何をやりたいかという希望が全く無い人に、プログラマはいい職業ですか? と聞かれたら、自分はいい職業だと答えると思う。今の時代、「普通の」プログラマでもあちこち足りてないからまともな勉強をすればまともな給料が(たぶん)もらえるし、職にあぶれることもまだしばらくは無いし、もし向いていて能力を発揮できるならいい待遇もゲットできるから。
あと、たぶん他の高給取りの職業と較べて人生におけるストレスはわりあい低いんじゃないかなとも思うし。
つまり、そういう話を聞いた人がプログラマになるための第一歩としてこの本を読むのかなあ。そうなんだろうなあ。
なにかを作りたい人
「プログラマになりたい人」のことが自分にとってよくわからないのは、たぶん、そう思ったことが自分にはなくて、そもそもやりたいことが目の前にあって、そのための明らかな道具としてプログラミングという手段があったから、しょうがない勉強するか、という経験しかしたことがないからだと思う。そういう人は世の中にけっこう多いんじゃないかなあ。
なんか黒い画面に線が引けるのが面白かったからN88BASICをやったし、Windowsであれこれデータを処理するアプリケーションが作りたかったからVisual Basicやったし、ゲーム作りたかったからC++をやったし、という感じ。そのうちプログラミングをしてるのが割と自然になっちゃって、そのまま仕事に選んだから、仕事を片付けるために、その仕事に対して適切な言語と技術スタックを学んでやっつける、というのを繰り返して今に至ってしまった。
個人的には、プログラミングは作りたいものがあるという状態で、そのための手段としてプログラミングをやる、というのがいちばん効率がいいんじゃないかと思う。技術を学ぶなら目的意識がはっきりした方が問題を発見しやすいし、難しいところでつまづいた時に、それを突破する意欲が湧くから。
とか、ぼんやり考えてたら、今日こんなエントリがTLに流れてきた。
プログラミングが出来れば自分の欲しいソフト作れるからなー。
今あるソフトを弄る事だって出来るし。
たとえば今だとマストドンのクライアント次々に生まれてるじゃん？
プログラミング出来ないと人が作ってくれたものをただ使うしかないんだよね。
でもそれだと自分がピンポイントで欲しいものが無かったり、セキュリティ的に難があったりする。
あープログラミング出来る様になりたかったー。
プログラマーになればよかったー
やればいいのに! 今すぐ始めろ! 作りたいものがあるなら作れ! それはプログラマにとって一番大事なものだぞ!
動機と技術と時間の話
結局のところ、適切な時に適切な方向と量の動機を持てるかどうか、という話なんだろうなという気がする。
働いているときに、それと全く別の趣味としてプログラミングが始められるか、それだけの時間と気分の余裕を持てるかどうかというと、多くの人には難しいかもしれない。大学生ならどうか、高校生ならどうか、中学生なら……と考えてみても、それぞれ人に個別の事情があるだろうから、単純な時期の問題でもないと思う。
だから、目的に特化していない「プログラミング」一般として高校生の頃にやっておくのは、そう考えると、悪いことではないんだろうなと思う。自分だって働きはじめてから必要になった数学やら英語やらの能力については、それこそ高校生の頃にやっておいた下地があるからなんとかなってるわけで、考えると基礎教養というものはそういうものだ。何かをやりたくなって、それがある技術や知識を必要とするときに、しかしその技術や知識をゼロからやり直す時間がその瞬間にあるとは限らない。
将来に作りたくなったものができたとき躊躇せずに実際の作業に飛び込んでいくために、時間がある段階でやれることをやっておく。そういう話なのかなと思うと納得できる。
なんかボヤけた感想だけど、そんなことをあれこれ考えてた。
余談
完全に余計な話だけど「高校生からはじめるプログラミング」というタイトル、これは早いうちから始めるぞ! というニュアンスでつけたんだろうか。
いろいろ話を聞いていると*3小学生の頃にはなんらかのコード片を書いていた、という人もそんなに珍しくはないので、人によって受け取りかたが変わるタイトルだなあという気がする。
CloudNativeCon Europe 2017に行ってきた＆しゃべってきた
うぎゃあ、これ今年の初エントリなのか。なんてこった。
で、FluentdがめでたくCNCF (Cloud Native Computing Foundation)に加わって初めてのCloudNativeConなので、Treasure DataのOSSチームで都合のつく人みんなで参加してきたというやつ。前夜祭的なところで同僚の Eduardo がKeynoteをやったり、Fluentd Salonという枠がつくられてFluentd関連の話をしたり。
自分はそれとは別にTalk proposalを出していて通っていたので、それを話しに行く、というのが個人的には最大の目的。
しゃべってきた
セッションはカンファレンス2日目、全体でいちばん最後の時間枠。正直話すのが終わるまで気が抜けないからあんま好きじゃないんだけど、とりあえず、やるだけはやった。けっこう多い人が来てくれて席がぜんぶ埋まる(70人) + 立ち見(床座り見)がちょっとという感じで、思ったよりいっぱい聴きにきてもらえて嬉しい感じだった。
スライドはこちら。内容としては去年にLinuxCon Japanでやったやつのブラッシュアップ版なんだけど、じつはこの内容は自分の過去のプレゼンのあとにTreasure Dataのブログに載ってHacker Newsでちょっと話題になったり、同僚が別のCloudNativeConで一部をからめた発表をやったりしていたので、そのへんのディテールを再マージしたりして完成度を上げた。
話題としては、特にKubernetesのようなものを使う比較的大規模なコンピューティング環境を用いるようになったとき、どのようにロギングのためのプラットフォームを作り、それをスケールさせ、安定させるか、みたいなことを考えるという感じ。ログの収集と集約、ストレージへの書き込みなどの各部をどう設計するか、何に気をつけるか、みたいな話題を実例も含めて挙げてパターン化して並べた。
35分という時間に対してちょっと盛りすぎになったかなーと思ったけどなんとか時間内に終わったし*1、このtweetのように良かったと伝えてくれる人もいたので、ちゃんとできたんだろうと思うことにした。よかったよかった。
@tagomoris Your fluentd/logging talk was one of the best of the whole #Kubecon imo. Thanks! Maybe publish the slides? <3
— Chris Hager (@metachris) 2017年3月30日
行ってきた
参加者としては、カンファレンス中日の1日目(前夜祭をふくめた2日目)に体調を崩して午後はずっとホテルで寝てたのもあり、Fluentd関連以外はあんまりセッションを見られなかった。残念。Kubernetes関連セッションはだいたい満員で、それ以外の話になるとぐっと空席率が目立つ、みたいな傾向が強いように感じた。
スポンサーブースもKubernetes向けの管理やモニタリングのサービスを提供する会社のブースが目立って、みんなそこで商売やりたいんだなー(他人事)。でも参加者と話すと大規模なノード数でKubernetesを運用しているっていう人はほとんどいなくて(というか話した中には皆無だった)、ちゃんと商売になるんだろうか、とかつい考えてしまう。
聞いたセッションは、うーん、あんま面白いものはなかった……というかこの手のものは日本の面白ソフトウェアカンファレンスで聞く類の面白セッションを期待してはいけない。みなさん頑張っておられますね、という感じ。
しかし実際のところ自分も今回のカンファレンスのセッション採択のレビューメンバーだったりしたので、あんまり他人事ではないのでした。カンファレンスというのは難しいなあ。
しかし会場では飲み物が常に提供され、食べ物も朝食、昼食、あいだのおやつ、など切れ目なく出てくるので、さすが参加費の高いイベントは違う、という感じ。夜にはアルコールも(さすがに本数制限があるが)出てくるもんね。
2日目終わったあとのパーティは別会場(ベルリンのある企業のオフィスらしかったけど、やたらデカい会場だった)に移動して。バス送迎つき*2ですごい。ベルリンのクラフトブルワリーのビールが出てきてすばらしかった。
あれこれ話すと、CNCFに加わったことでFluentdの知名度がだいぶ上がったなーというのと、Treasure Dataという会社の知名度もそれにつれて少しずつ上がってきているのかな、という気がする。EUだと会社は無名だからなあ、カンファレンス参加は割とお手軽に知名度を上げられるチャンスなので、あれこれやっていきたい。もうちょっと同僚を海外のカンファレンスに送り込みたいな。
Fluentdを使っている人、使いたいから教えてくれという人、別の使ってるから今は特にーという人、あれこれだけど、いろいろしゃべってると共通の話題がぽんぽん出てくるのは楽しい。働いている会社が日本の会社に買収されてさーという人がいたり、DST*3まじで最悪という話で盛り上がったり、ロンドンのエンタープライズで政治と古いBSDに苦しんでるんだよという話を聞いておおお……みたいに同情したり、あれこれ。
なんというか、世界のどこに行ってもこの業界はあんまり変わらんなあ、という気がしますね。
カンファレンスTシャツ(スピーカー向けかな?)と、あとはプロポーザルレビューメンバー向けのマグカップ、ニット帽子。これをかぶればキミもCloud Nativeマンだ！
あれこれ
ベルリンは24時間電車が動いているというのもあって、多くの店やレストランが真夜中まで営業しているのが便利でいいな。そしてレストランはことごとく路上にオープンテラス席を持ってて、真夜中だろうとみんな可能な限り外の席で食べるのが普通、みたいになっている。自分はその雰囲気は好きだなあ。東京のレストランも持ってオープンテラス席をつくるべきだと思う。ベルリン、たぶん東京より寒くて雨も多いのにやれてるんだから東京でもなんとかなるってば。
しかし食べ物はというと、まあね、イモと肉だよね。いいけどさ。数日なら新鮮なまま終えられるので。長くなるとちょっとアレな気がするが。探せば中華とかアジア系の料理とか、おいしいレストランはある模様。ベルリンにしばらく住んでたという人にくっついて行ったベトナム料理屋で食べたウドン(の麺をつかった何かの料理)はなかなかおいしかった。
で、ドイツだし、飲み物というと
まあ、ビール飲むよね。
ついでにUKのはなし
せっかく遠路ヨーロッパまで行くので、ついでにお客さんのところに行ってミーティングやってこよう、ということでUKはスコットランド、グラスゴーにも行ってた。まあ仕事はやったとして*4、カレンダー的にちょうどよかったので自分で2泊追加して週末をグラスゴーとエジンバラの観光に使ったり。
エジンバラ、起伏のある地形に古い城塞やらバカでかい教会やら塔やらで、たいへんステキな感じだった。
泊まってたのはグラスゴーで、そっちも観光して回ったけどやっぱり丘やら教会やらがたいへんよい。
でも全体的にエジンバラは観光の街(例えるなら京都)で、グラスゴーはもうちょっと実際的な街(例えば大阪とか?)という感じかなあ。グラスゴーのほうが普通に商売の街という感じで、地元の人が入り浸るパブなんかもあって楽しかった。見た範囲の問題かもしれないけど。しかし道端はグラスゴーのほうが汚ない感じだったりしてね。
でね。UKだしね。
そのへんのパブで昼間とか朝からじいさんばあさんがガンガン酒飲んでるじゃん? まあ自分もビール飲むじゃん?
食べたのは現地名物のハギスやハギス入りハンバーガー、UKなのでフィッシュ&チップス、あとは普通にピザ、ハンバーガー、魚介レストランなど。食べ物はだいたいおいしかった気がする。でもおいしそうな店はだいたいイタリアンとかハンバーガー屋とかで、現地のものは……みたいな気にならなくもないけど。とにかく滞在中に飽きることはなくてなによりだった。
ということで
いや、なかなか良い旅行でした。
2016年を振り返ってみる
2016年のblogエントリを眺めてみたら13本、めっちゃすくなかった……。
年の前半くらいで済むかなと思ってたFluentd v0.14のコード書くのにとにかく1年中かかりっきりになっていて、ほとんどそれだけしかやらなかった。コードはめちゃめちゃ書いた*1からアウトプットが減ったとは言いたくないし、実際大きな成果だったとは思うが、もうちょっとこうバランスの取れた生活ができないものか。ううむ。
Fluentd v0.14
とにかくこれのコードを書いていた。
しかしblogエントリはこれ1本なんだな。とにかくひと段落つくまではドキュメントも後回しの勢いでやってたら年が終わってしもうた。ちょうど年末にひと段落と言えるところまで到達したので、年明けに残りタスクを片付けつつドキュメントを書いて、でひと区切りになると思う。
戯れに fluent/fluentd リポジトリで2016年の自分の変更を数えてみたところ 703 commits +46918, -19050 だったそうな。まだmasterにマージされてないものは入ってないけど。いやー、テスト書きまくったから多いな。*2
その他コード関係
小ネタばっかり。 msgpack-inspect というツールを作って便利!!! と思ったものの、完成した頃には自分の用は既に済んでいて、そのあと一度も使ったことがないというね……。*3
tagomoris.hatenablog.com
tagomoris.hatenablog.com
mrubyと格闘したのはちょっと面白かった。来年もいくらか使いそう。
しゃべってきた
あれこれ。海外のカンファレンスは一度だけかな。国内で英語でしゃべったものはあるけど。
- CROSS 2016に行ってきた＆しゃべってきた - たごもりすメモ
- YAPC::Asia Hachiojiに行ってきた＆しゃべってきた - たごもりすメモ
- LinuxCon Japan 2016に行ってきた＆しゃべってきた - たごもりすメモ
- 松江市でOSSの話をした & Fluentd meetup をやった - たごもりすメモ
- RubyKaigi 2016 に行ってきた & しゃべってきた - たごもりすメモ
- RubyConf Taiwanにいってきた & しゃべってきた - たごもりすメモ
- YAPC::Hokkaido 2016 に行ってきた - たごもりすメモ
仕事で他所の会社の人とかと英語で会話する機会が増えて、海外のカンファレンスでしゃべらないと! みたいな意欲が薄れちゃった感じはする。もうちょっと分散処理関連のカンファレンスにちゃんと行きたいなあ。
あと(主にTDの顧客関係で)呼ばれて他社の社内勉強会でしゃべったことが実は数度ある。毎回話の内容は変えてるんだけど、これは果たして喜んでもらえているのだろうか……。まあ、毎回それなりに(自分が)興味があることをしゃべっているので、いいかなあ。いいかな?
ISUCON6
負けた。人は負ける。
#ISUCON 6 予選を戦ってなんとか通過した - たごもりすメモ
ISUCON6決勝を戦って敗北した - たごもりすメモ
Webアプリケーションの開発・運用から離れて長いし、今年なんかTDの運用すら完全ノータッチでミドルウェア開発しかやってなかったからなあ、というのは言い訳です。ううう。来年はもうちょっとHTTPの気持ちを考えてコードを書く機会が増えるはずなので、もうちょっと、こう、こう。
その他
テキトーな放言ネタは今年はこのひとつだけ書いた。
いろんな人がいろんな元ネタを想像して読んでいたらしいが、残念、全部ハズレです。少なくとも自分のところに聞こえてきた限りは。
来年
仕事のしかたもその他も、今年とはだいぶ方向を変えたいとは思っているので、またあれこれ挑戦することになりそうです。退屈しないなあ。
次の1年もよろしくお願いします。
