Snippets

対抗して作ってみた。

図書館が便利になった

昔、といっても学生時代は図書館をはしごして週 10冊ぐらい借りていたものですが、最近はちっともいってません。というか、そもそも専門外の本を読まなくなっていかん感じです。電子本も積読状態のものが多くて、これ以上買うのもはばかられる。amazonほしい物リスト には十年来のリストが作ってあるけど、買っても読む確率を考えるとな、と放置中。

というような状態の時に その本、図書館にあります Chrome 拡張にであったのでした。カーリル自体は随分前から登録していたのだけどやっぱり、UIが面倒くさくて使ってなかった。でもこの拡張のおかげで、あっという間に近所の図書館にあるか教えてくれる。貸出中かどうかとかもわかる。自分の住む港区の図書館は予約用のボタンまで付いている。

とはいうものの、予約用にはアカウントが必要で、そこは実際に図書館に行かないとだめなのだった。ということで、やっとこのまえ重い腰をあげて図書館に行きアカウント申請してきた。ホントは近いんだけど、なんかお役所っぽい事務処理が面倒くさくて敬遠してたのはある。

旧態依然とした紙の申請書にいろいろ書いてアカウントできて予約してみると、確かに便利だった。図書館のサイトのUIはダサくて、一々確認の window.confirm がうざいものであったけど、現地行ったりするのに比べれば超便利。思わす調子に乗ってほしい物リストの本をかたっぱしから予約しそうになった。

人気の本は 50番めにならんだりして、ああ、やっぱりそんなもんなんだなあ、と思いつつも、予約できればラッキーぐらいだったので気にはならない。あとは順番が回ったことを知らせるメールを見逃さないようにするだけだ。

そういうわけで手元に以下の2つの本が来たんだけど、問題はちゃんと読めるのかしらん。買った本と違って2週間の期限があるから読める、とかなるといいけど。

www.amazon.co.jp

www.amazon.co.jp

ああ、あと最後になるけど、これも例のアドベントカレンダーの一部です。はい。

Englishing fast and slow

俺の Advent Calendar 10日めの記事です。これ、書かなきゃだめなんですかね。

時間がないので英語に関する与太話を書きます。

仕事柄、受験サプリ のビデオとかを見ることがあるのです。それで高校ハイレベル英語とか、どんなものかと思って見てみると、さすがにハイレベルなことやってます。熟語とか自分が知らないのが結構出てきます。「Turn down」が「断る」だって初めて知りました。文系学生では常識なんですかね。

対象になってる文章も、そこそこ読ませる論説文のようです。で、それをいろいろ文法とかを元に解説していくわけです。複数形がでてくると抽象的な話の導入だとか。

たしかに言われてみるとそうです。無冠詞の複数形がでてきたら、具体的な話はしにくい。なんとなくわかります。

とはいうものの、自分が英語を読むときにそんなことを考えているか、というと考えてません。そんなことを考えつつ聞いたり読んでたりしたら追いつかない。無意識に脳みそが抽象度を挙げてついていってるんだと思います。

最近読んでる Thinking fast and slow でいえば、System 1が判断して先回りしてる。それに対して、講義では System 2レベルで解説して、もっともなことを言っている。言ってることは間違っていない。

でも、そうやって解釈していくのは大変だよなあ、と思います。「てにおは」を、一々アルゴリズムを追いながら選んでるような感じです。System 1に比べて System 2はむちゃくちゃ集中力を使います。やっぱり、英語がそこそこできるようになった今でもああいう講義について行ける自信はありません。

もちろん、理想としてはそういう訓練をひたすら繰り返して System 1に叩きこみ、System 2を使わずに読めるようになるのでしょう。そして System2からそういうルールも忘れ去っていくのが悟りのようなものでしょう。

でも、実際そういう境地になるのに、ああいう言語化されたルールをもって教えるのが近道なのか知らん。教えるからには言語化しなきゃいけなくて、そのために余計な遠回りをしている気がしなくもありません。臨界期前のこどもなら教えなくても学びます。たしかに、受験サプリが対象としてるのは、脳は柔らかいとはいえ臨界期を過ぎた高校生です。彼らには、何もわからずに英文を読み聞き鍛えていくより、ああいうルールをひたすら覚えこんで 1年後だかの試験に備える、そしてごく一部はそれを System 1に定着させるけど多くは忘れていってしまう、というのがベストなんでしょうか。

まあ、英語は役に立つので System 2で解釈できるより System 1で処理できるようになったほうが得だと思います。でも古文とかになったら、System 2で乗り切って忘却してもいいよなあ、というのも納得します。

そこらへんの科目に対する思い入れの違いが、違和感を覚えた原因ですかねえ。

与太話なんでまとめる気もないんですが、まとめとしては、もっと楽に英語を習熟する方法ありませんかね。

ああ、invokedynamicがな

みなさん、invokedynamic知ってますよね。そう、あの Java8の lambdaで使われてるやつです。

と、振ってみましたが、知らない人も多いような気もします。まあ、とりあえず、動的言語を実装するために JVM7から導入された bytecodeだったけど、Java8の lamdbdaの実装にも使われて、実は JVM6レベルである Android Programmerは lambda使えなくて歯噛みしてるやつです。

ちなみに「がな」は「あったらいいなあ」という意味だと昔ならいました。

という書き出しで始まりましたが、俺の Advent Calendar 8日めの記事です。そんなのだれが気にしてるんだ。あと30分で書かないといかん。

invokedynamicの父

今日なぜそのことを書くかといえば、invokedynamicの父、Charles Nutter 来日記念セミナ として「JRuby loves invokedynamic」という講演があったからです。

Charlesは JRubyの創始者ではありませんが、JVM上で動的言語を実装するのが非効率なのに業を煮やして invokedynamicという動的言語を効率的に実装する仕組みを提案し、見事 Java7に導入されることになったのでした。そういう人が日本で話してくれるとなればいかねばなりません。

invokedynamicとはなにか?

古の JVMにはいろいろなメソッド呼び出しに応じて 4つの invoke bytecodeがありました。 invokestatic, invokevirtual, invokeinterface, invokespecialです。それぞれの内容は名前から推測してください。でも、どれも Javaに向いたもので、Rubyなどのような動的言語を実装するには向いてませんでした。

そこで提案されたのが invokedynamicです。知ってる人には inline method cacheを実装するためのもの、といえばわかるでしょうか。まあ、実際のところ method cacheだけのものではりません。methodを選ぶ仕組みを Java言語自体でカスタマイズできる、まるでリフレクションのような仕組みです。でもリフレクションほど協力ではないので、従来の JVMオプティマイズがきき、inline化とかいろいろできるぜ、っていうのが売りです。

どういう仕組なのか?

MethodHandleCallSite ってのが重要なようです。

各 invokedynamic命令には bootstrapというコードがくっついています。これは最初に一回だけ実行され、CallSite (呼び出し場所) を返します。CallSite は以降、invokedynamicを実行するたびに MethdoHandle を返し、JVMはそれを関数ポインタの用に扱ってジャンプします。

CallSite にはいくつかの子クラスがあり、一番単純な ConstantCallSite だと必ず同じ MethodHandle を返すので、JVMはその事実をもとにいろいろ最適化できるというわけです。

この最適化はヒューリスティックにもとづいています。動的言語では、コードの一つの場所で変数の指すオブジェクトの型は実行時までわかりませんが、実際のところ大抵同じ型がくるので一生懸命 virtual tableみたいなものを見るより速くなる、というわけです。Methodhandle自体もいろいろあって、万が一予想外の型がきた時のためにガードをつけたりもできるようです。

JRubyではどうつかっているか

メソッド呼び出し

これはできた経緯からして当然ですね

正規表現とかの定数

コードに現れた正規表現とかを全部コンパイルしておくのはムダです。本当に使うかわからんからです。 そこで、invokedynamicを使い、最初の bootstrapで正規表現コンパイルするようにします。で、bootstrapの返す CallSiteはできた正規表現オブジェクトをいつも返すようにすれば、その後は分岐とかなしに高速に実行されます。さらには HotSpotの最適化が走って、最初からオブジェクトがおいてあったかのようなコードになるのでしょう。

インスタンス変数の参照

Rubyとかは、インスタンス変数を動的に付け加えられます。で、ここのところを一々名前で呼び出してたのでは遅くてたまらないので、invokedynamicでほげほげしてるらしいです。時間がないので端折ります。

どの程度速くなるのか

ちょっと見せてもらったベンチマークでは、invokedynamicを使わない場合に比べて 2から3倍ぐらい速くなっているようでした。

そもそも JRubyは invokedynamicなしでも CRubyより速いので、invokedynamicつきだと 5倍ぐらいになるよ、と。

お気に入りの例として、RebBlackTreeを実装したときに CRubyはもとより、CRuby + C で書いた実装よりも速くなったと自慢してました。ちょっとかわいい。

Androidにいつくるの?

えーと、会場は Oracleのオフィスでした。OracleAndroidの話をするのは禁じられてるらしいです。

というか、そんなの Google次第だよなあ。きっと、なかではもう invokedynamicのある ARTとか動いてて、でも大人の事情で出せなかったりするんじゃないのかなあ。Oracle

でなんとか間に合った。あしたは dageziさんが Sketch+CircleCiというネタで書くらしいです。って3分後だよ。

意識の高いDev

俺の Advent Calendar 7日目の記事です。この書き出し飽きてきました。

さて、みなさん 意識の高いデブtwitterで followされてらっしゃるでしょうか。俺はとりあえず followして、言動に感化されながらも 500円ランチパスポートで適当に選んで食べてる意識の低いデブです。もっと意識を高めないといけないなと、思った次第です。

でも今日はデブの話ではなく Devの話です。先日書いた DevUI の続きのようですけど、実は今日の話の方が先に思いついたものです。

DevOpsは Developerが Operationとくっついて業務を効率化、高性能化して全体の生産性に寄与するというめでたいという話です。と、自分は理解しています。それを s/Ops/UI/ したのが DevUIです。でも DevUIに至る前にいろいろ夢想したものもあったのでネタがてら紹介してみます。

DevHR

文字通り、HR (人事) と Developerをくっつけたものです。よくわからない人事の世界を Devの道具とかを入れてもっと効率化しようと言う。

はっきり言うと HRの世界はいろいろ Dev側にはよくわからん事情がいっぱいです。UIの愚痴をいいましたが、HRに比べればそんなの可愛いものだったと思います。Quipper社では採用とかは比較的 Engineerに納得感のあるように、できるかぎりは Openになるようにやっているのですが、大企業と一緒になったのでそのままではいかない部分もあったりします。成長の痛みといえばそうなんでしょうが、効率的で納得感あり、スケールしつつ法令遵守した体制とかできないのかしらん。そういう願いが DevHRという言葉にこもっています。

もしかして、Work Rulesを読むとそれに準じたことが書いてあったりするんでしょうか?

DevRestaurant

ここはかなり牽強付会です。でも 未来食堂 ってある意味、Dev的な全体最適の考え方を飲食店に持ち込んだ好例ではないでしょうか? おざなりな「他種類のメニューを安く提供する」ことでブラック化しがちな飲食店経営を考えなおした例かなあ、と思います。まあ、店主が元エンジニアだというだけで Devをつけちゃうというのは濫用すぎる気がしますが。

まあ、Devとかいわなくても、実は家族経営の町の食堂とかではこういうことができてたんでしょうねえ。常連客に、それなりにその場であるものでちゃちゃっと作って出しちゃうとか。

DevHealth

実は先日健康診断に行ってきて、中性脂肪の値が大幅な成長を遂げていました。多分、これは最近会社におやつが常備されていること、とくにブドウ糖タブレットが導入されたことが影響してると思います。あれは血糖値を急激に上げるものなので、むべなるかな。

ということで断おやつをして 1週間ぐらいしてからまた採血して値を測ってくれないかなあ、と思うわけです。メタボのための食事療法で結果を見るとか言う悠長なことをやらずに。そのくらいの早い iterationで生活を完全していければライザップなんかめじゃない気もするのです。ハイテクなレコーディングダイエットみたいな。

まあ、本当に目指すべくは短期的なダイエットじゃなく、自分のパフォーマンスをあげる、もしくは維持するべく、ベンチマークとしての数値を図りつつ生活していく、ということの方が重要なのでしょうが。自分を変える最強の食事 なんかはこの系譜になるのかもしれません。

でも、たんなる「体重減らすといいよ」じゃなくて、理屈っぽく疫学的な調査とかも混ぜてやればエンジニアには受ける健康法ができると思うのです。数字を追うのは結構得意だろうし。数字だけになっちゃうのが怖いけど。

まとめ

今回は「Dev」という単語を弄んだ意識の高い(笑)ネタを目指してみましたがいかがでしょうか。読んで 1分ぐらいで忘れてくださっていいのですが、万が一、これをねたにして膨らませてもっと大きなホラにでもしてくだされば幸いです。

DroidKaigiのこと

俺の Advent Calendar 6日めの記事です。昨日は dageziさんの DevUI でした。って、Advent Calendarに登録するの忘れた。いかん。

気を取り直して、今日は DroidKaigi 2016 の話をしたいと思います。

まあ、自分は端っこに参加してるだけなのであまり深い事情をしりませんが、と言い訳をしつつ。

DroidKaigiとは

この DroidKaigi、RubyKaigiをご存じの方はわかるように Androidに関するエンジニアの知見を集めた Conferenceを作りたい、ということで集まったんだと思います。すでに Androidの Conferenceとしては Android Bazaar and Conference (略称ABC) が何回か行われてるわけですが、それとどう違うんでしょう、というのは実は ABCに参加したことがないのでわかりません。ここらへん、いままでコミュニティ活動をサボっていたつけがあります。ただ、イメージとしてはビジネス色がうすい、かつ世界を狙っているあたりが違うのかなあ、という感じです。

で、不肖ながら自分もそのボランティアの末席に加えてもらって、雑事を手伝うと言いつつ、いろんな会社におじゃまして綺麗だなあ、とか思ったりしてるわけです。

現在は、2016年2月の開催を目指して、CFPは終わって、一般参加の申し込み をやってるところです。めでたく早期割引は売り切れて、一般参加ももう少し、というのが現状のようですね。学生枠もちゃんと捌けて欲しいな。

DroidKaigiの運営

まだ 2回しか参加してませんが手作り感が高いっす。いろいろなことが手探りで決まってる感じが高く、ボランティアと言いつつ待っているだけではだめな雰囲気があります。とはいえ、自分もイベントとかを仕切るのは苦手なタイプなのであまり口出せずに歯がゆい感があります。

例としての CFP審査

その例として、本日行った CFP審査会議のことを書こうかと。まあ、こんな下っ端でも CFP審査に出ていいのかな、と思いつつも 90本あまりの CFP (公開されてます) を読み込んで会議に参加してみました。ちなみに CFP募集中も期間も「Kotlin熱いねえ」「Rxなかなか来ないねえ」「そもそも選べるほど来るんだろうか」と中の人としてちょこっと心配してましたが、結果、いろんなジャンルのものが海外からも集まったりしてすげーな、という感じです。自分は、2本しょぼいのを付け加えただけで尽力してないけど。

実際の審査は至極穏やかに行われました。個人的には「なんでこれをいれないんだ! そんなの落とせ!」とか激論が繰り広げられるのかとワクワクしてましたが、非常に民主的に投票で決まっていきました。ちとあっけないっす。個人的には聞きたかったな、というのが落ちたりして無念だったのですが、まあ、仕方ないっす。

それでもなかなか聴き応えのあるものが揃ったと思います。あとはうまく聴衆が重なる分野が同じ time slotにこないといいけど。時間割作成者の気苦労が忍ばれます。

CFP読んでみて

とりあえず今回、CFP読む側に回っての感想がありました。あくまでも個人の感想なので、これが審査する人全員に通用するかはわかりませんが。

  • 前置きは少なめでいい: それなりに審査員は技術がわかった人が読むので背景は少なめでいいのでは。

  • どれだけディープかわかるといい: よく知られたネタでも、じつは深掘りすると面白かったりすることはよくあるので。バズワードを散りばめただけか、それともそこに意外な深い知見があるのかわかるといい。

  • 対象聴衆がわかるといい: 簡単そうな内容でも、初心者用にあえて丁寧にやる、とかだと受ける気がする。

  • 知見的なのは悩む: 一つの分野だけじゃなくて、複数にまたがった話とかだと悩む (Kotlin中心だけど + CI とか)。技術は独立しているわけじゃないんだから、そういう話が必要なのはよくわかる。でもシナジー効果的に話が面白くなったりするのか評価しにくい。どうしたもんでしょうね。

これからが本番だ

やっと CFPの一次審査が終わっただけで、これからいろいろあるようです。特に今回は有料になったので、お金のこととか面倒くさそう。 とはいえ、参加して祭りをつくり上げるのはなかなか緊張感があって面白い感じです。技術ネタ以外でも Android界隈を盛り上げて採用目的、もとい活気のある業界になるといいっすね。

DevUI

俺の Advent Calendar 5日めの記事です。

俺はメインは Androidのアプリの開発をやっています。そろそろ今やってるアプリの骨子の部分はできてきて、で、ちょっと嫌な部分になってきました。UIとかの調整です。

アプリエンジニアの中には、凝った UIを作るのがすきな人もいるのだと思います。でも、自分は苦手です。しかも、Quipper社は自分が人を集めたりしている成果、そういう Android Engineerが集まってきてしまっています。Networkの APIとか、Model Layerで整合性を取るとか、そういうのは得意なんだけど、UI調整というと逃げ腰になるという。まあ、その解消策の一つとして gradle-android-9patch-plugin を作ったりしたわけですが、これは問題の一部を解決しただけでまだまだ苦手感は有ります。

その一つというか大きな要因に、なんでそういう UIにすべきなのかよくわからない、というのがあります。

データベースとかだったら、なんでそういうスキーマにするのか、とかがわかります。今後度のデータが増えていって、どういう情報を見せたいかを考えると、このテーブルを作らなきゃいけないとか。それぞれの技術的選択にどういう得失があってどう決断するかわかります。過去のしがらみとかももちろんありますが、それも技術的負債として将来返済しようと前向きに考えられます。

でも、UIはよくわからんのです。

なんでここでこういう marginが必要なのか、ここの animationはどう動くべきなのか。まあ、画面の遷移ぐらいだと、こうしないと必要な画面にたどり着かないよね、とか判断できるけど、でもやはりわからない点も多い。

あと、やっているうちに考慮していない遷移 (エラーケースが多いけど、それ以外に正常系でも多い) が発生して、そこに対する対処が場当たりっぽいなあ、と感じたり。

で、そういうのはソースにも現れるわけです。最初は conventionつくって ちゃんと意味に則った dimensionとかを予め定義してそれから外れないようにしようと頑張ったりしたこともあったんですけど。 semanticにそういうのをまとめても結局例外とか現れたりして、最初に決めた semanticは何だったのか、ということになる。もう最近はそんなもの抽出するのを諦めて数値ベタ書きになってたりします。UIの refactoringとかできない。そもそも UIの factorってなんだそれ、俺の目には掛け合わされた合成数しか見えないぞ、って感じです。

まあ、ここまで愚痴を延々と書きましたが、そこらへんは Waterfallっぽい開発に毒された脳みそのせいもあるのだと思います。UIについてもコードと同じく継続的に評価と試行を回していくことによって factor outしていく必要があるのだろうなあ、と。

で、表題の DevUIということばにいたるわけです。 DevOpsのように、DevとUIが協調して Iterationを回すことによってお互いに納得しながらいいものを作っていけるのではないかと。

と、最後はちょっとエモくなってしまったので、もっと地に足をついたことを書いたほうがいいのでしょうが、そこまでまとまった tipsがあるわけではなし、ちょっと書けるネタは Sketch 3 Advent Calendar に書く予定なのですみません。まあ、この Advent Calendarやってるうちにも何かトライして面白い結果が出たら書いてみたいとは思います。

でも、考えてみると Webアプリの場合、そこらへんをやってるのがマークアップエンジニアって位置だったりするんでしょうか。どうなんでしょ。

時間切れ

俺の Advent Calendar の 4日の記事です。

と言いつつ、書くネタと時間がなくてこんな時刻になってしまいました。23:30です。 やはり午前中のテンションの高いうちに仕上げないとだめっすね。

きっとちと発想を変えればネタは出てくる気がするんですが、発想を変えるエネルギーがないというか。酒を飲んでしまって、家族もそばに居て、いろいろ無駄な思考を考える部分がない。

とりあえず、書き出してみたらなんとかなるかなあ、と思って書いてみたんですがこんなグダグダな感じです。

いまは、このぐらいでごまかして、ネタになるかもしれないことを今から遊びます。では。