?

Log in

No account? Create an account

ブログ引っ越ししました
karino2
2017年にもなってブログを変えるとか…とか思わないでも無いですが、MeatPieDayベースのブログシステムがいい感じに仕上がったので、正式にそちらに移行します。

新ブログはこちら。

なーんだ、ただの水たまりじゃないか
https://karino2.github.io/

ショートボードを一ヶ月くらい借りる方法は無いものか
karino2
今いる所はそこそこ波のたってる事が多い気がする。
たまたまそういう日が最近多かっただけかもしれないが。
この位波が立つなら、ショートボードがあったら波乗りとか出来るのになぁ。
自分はサーファーって訳でも無いが、9月くらいのあったかさで波が乗れるくらいあってこの位空いてるなら、乗ってみても良い気はする。

地元に帰れば一ヶ月くらい借りる事は出来るとは思うが、伊豆まで運ぶ手段が無いよなぁ
着払いで送る?でも9月もあと二週間か。まぁ今回はいいか。

MeatPieDayのノートをgithubのissueに公開するアプリを書き始めた
karino2
issueからブログにするのはjekyllのマークダウンをCircleCIから回せばそう難しく無さそう、という結論になる。
そこでMeatPieDayのノートをIssueとして公開するアプリを書き始めた。

https://github.com/karino2/Mpd2Issue

画像は結局imgurに送る事にした。画像をissueにドラッグアンドドロップした時の挙動は一通り解析したのだが、一つ通常の方法では取れないtokenが必要なので、やはりそういうのを無理やり取るのも良く無かろう、とい事で。

以前gistに公開した奴だが、例としてはこんな感じになる。

13_3_1のLDS周辺を追う
https://github.com/karino2/karino2.github.io/issues/17

Latex記法の数式が出ないのが計算外だったが、他はだいたいイメージ通りに使えそう。

gistは公開の手間は無いのだが、そこにアップした物が散らばってしまっていまいち蓄積されていく感じが無い。
ブログとか他のにリンクを貼れば良いか、と最初は思ってたが、やっぱりそれではいまいちに思う。
あと、ちょろっとPCとかから直せないのがいまいち。やはりセル単位でweb側でも処理したいよなぁ、と。

現状は本当に単にローカルのipynbを送るだけで、変更したものを更新したりは出来ない。
やはり追記していったものをsync的に追加したり編集したり出来る必要はあるのだが、したらば掲示板とかは編集出来ない事を思えば最初はこの位でも使えない事は無かろう。

ただやっぱりissueでは見るのはいまいちなので、ブログを生成する必要はありそうだなぁ。

Issue Trackerでブログを書きたい!
karino2
図とテキストをまとめたブログを書きたい、と長らく思っていて、いろいろと試行錯誤を繰り返している。

まず、2chmateでしたらば掲示板を使う、というのをやっているが、
http://jbbs.shitaraba.net/study/12706/

これはスレの粒度が少し大きすぎて、自分がやりたい事とは微妙にずれている。
また、あんまり新しいスレは建たないがたまに立つ、という性質から、第三者が見るのがだるい。

MeatPieDayはそうした試みの一つの解答としてかなりゴールに近いが、現在は結果をgistに出している、というのがいまいち。
もっとこう、ちょこちょこ編集したりできたらいいな、と思う。
ついでにgistに散らばってしまうのも良く無い。いちいちブログにリンク貼ったりするのが面倒。

この前の職場ではissue trackerにいろいろ実験をまとめていたが、これがなかなか良い。
Issue Tracker自体の出来が良いし、各Issueは2ch系の掲示板に編集がついた程度の感じで、これだよ、これ、という感じの使い心地はある。
ただissueがどんどん増えていくと見づらいので、各issueを束ねるのはUI的にはちょっと違う気がする。

本当に欲しいのは、各issueを一投稿とするようなブログシステムなんじゃないか、と思い始めた。
各Issue自体はGithubのissueで良い気もする。
ではそれをまとめたブログというとGithubPagesでどうだろう?
CIで自動生成できれば、publishってアプリからやるとなんかcouner.txtの中のテキストをインクリメントして、そいつでCircle CIが走って最近のissueをまとめてブログが生成される、という感じでどうだろう?

追加の変更をどう扱うかが難しいな。
publishってラベルがついたらその時のCIでissueに紐づいたコンテンツが生成されて、編集されるとそのコンテンツがアップデートされる、くらいがいいか。

なんか欲しい物は理解出来てきたしそんな難しくも無さそうだが、2017年にもなって自分の独自ブログシステム作るとかすげーだるい。
どうするのがいいかなぁ。

とりあえずMeatPieDayをissueに投稿出来るようなposterを作って使い心地を確かめるかなぁ。
コード的にはgist ipynbを流用してすぐ作れるだろうし。

ipynb smell(データ分析のcode smellを考える)
karino2
データ分析のコードはいろいろと新しい性質を持つので、従来の良いコードの前提や原則があまり有効で無い。
そこで新しい原則を作りたい。

ソースコードのリファクタリングの時のcode smellを参考に、ipynbのbad smellをまとめて、あるべき姿を提示してみる事を試みる。

ipynb smell「まだらな実行セル」
何かのタスクを実行しようと思ったとする。そこでノートブックを一つ開く。
この時、そのノートブックの中で上から順番にShift+Enterするだけなのが望ましい姿だ。
だが、いろいろな事情により、ノートブックの中程に、実行してはいけないセルがあったりする。
実行するべきセルと実行してはいけないセルが入り混じっていて、人間が選んでShift+Enterしなくてはいけない状態。
これがまだらな実行セル、というipynb smellだ。
一つや2つのセルを飛ばすのはオーケーだ。
ただ、飛ばすセルが三ヶ所になった時は、ノートブックを整理する事を検討しよう。

ipynb smell「実行前のたくさんのスクロール」
何かのタスクを実行する時に、それがノートブックの途中にあり、前半にある多くのセルが不要な事がある。
また、まだらなセルと同様に、何かを実行している時に間に大きく実行してはいけないセルがある。
これが「実行前のたくさんのスクロール」のipynb smellだ。
飛ばす範囲が一画面に治まっているならオーケー。
だが一画面を越えて飛ばす必要がある事に気づいたら、ノートブックの整理を検討しよう

「まだらな実行セル」や「実行前のたくさんのスクロール」は複数のタスクが一つのノートブックに入っている事が原因な事がほとんどだ。
この時は、「タスクごとにipynbを分割」のリファクタリングを行う事で解決出来ないか検討する。

ipynb smell「戻ってくるipynb」
あるタスクを実行する時、複数のノートブックにまたがっている事がある。
この時、所定の順番でシーケンシャルに一つずつノートブックを実行していけるのが望ましい状態だ。
だが、例えばA.ipynbを途中まで実行した後にB.ipynbを実行しなくてはいけない場所があり、その実行を終えた後にA.ipynbの続きを実行しなくてはいけない、という事がある。
これが「戻ってくるipynb」のipynb smellだ。
こうした入り組んだ実行手順は作業の効率低下だけでなく、作業の属人化や過剰なドキュメントを必要としてしまうなど、深刻な弊害を生む事が多い。

この場合はA.ipynbが分割されるべきなのに一つになってしまっている場合に起こりやすい。
ただ分割すれば良い場合と、一つのノートブックにせざるを得ない事情があってコードや「.pyへの括り出し」などいくつかのリファクタリングが必要な場合がある。

ここに挙げたipynb smellは、本家のcode smellと同様、ただちにリファクタリングが必要となる絶対的なルールという訳では無い。
これらのsmellがしたら、何故そうなっているのか、を少し自問する、きっかけと捉えて欲しい。

仕事とお金と生活水準と
karino2
自分は働いても良い、と思う量が昔から結構少なくて、働かなくてはいけない量よりだいぶ少なかった。
でも資産は年々増えていくので、だんだん働かなくてはいけない量は減っていき、たぶん今回の仕事で初めて働かなくてはいけない量と働いても良い量が逆転した、と思う。
働かなくてはいけない量は資産運用の状況に影響を受けるので景気などの影響で増えたり減ったりするのでそう確定的に考える事は出来ないのだけれど。

また、底辺っぽいシェアハウスで貧乏な人たちと生活しているのにも飽きてきた。
最初の頃はいろいろ変な奴とかトラブルとか面白く体験してたが、だいたい一通り底辺系のトラブルを見てしまって、最近はこれまで見たようなのを違う人が違う場所で同じようにやってる、みたいに見えて、見ててうんざりする事の方が多くなってきた。

そんな二つの要素から、生活水準を上げる事でのメリットが増して、下げる事のメリットが低下してきた。
という事で、もうちょっと生活水準を上げよう、と最近は思っている。

とりあえず考えている事。

1. 住居は個室にして、安めのマンスリーマンションくらいまでに選択肢を広める
2. 電車賃や高速はケチらず使う
3. 外食は日常的に2000円くらいまでは気にせず食べる(これ以上はこれまで同様たまの贅沢枠で)
4. iij-mioは6GBにする
5. カフェはケチらない
6. GCPなどもケチらない(程度によるが)

働いている時はもともとこんな感じの生活なのだが、仕事を辞めた後もこの位でいいかなぁ、と思い始めた。
ライフプランとしては、40歳になったら生活水準上げたくなるかもな、と思って計画を立てていたので、想定範囲内ではある。

無理にお金を使おう、という気は無いので、結局安い所に住んだり、安い飯食ったり、した道使ったり、電車乗らずに歩いたりする事はあると思うが、使いたいと思う時には使って行く事にする。

資産や給料を思えばもっと使っても良い気もするが、そこまで労働意欲がある訳でも無いので、とりあえず費用対効果の高い所からゆるめていきたい。

今後のとりあえずの予定
karino2
当初は地元でも帰って海で遊んでるか、と思っていたが、なんか突然涼しくなってあんまり海に入る気分でも無くなったので予定変更。
で、伊豆のゲストハウスに行く事にしました。
仕事の間いたシェアハウスのドミトリーがあまりのも狭くて、反動で次はマンスリーマンションにしたい、と思っていたのだけれど、伊豆の海の方は手頃なマンスリーマンションが無いので、個室のゲストハウスにしました。

日曜くらいに出て、適当に相模湖とかツーリングしつつ二日くらいかけて下田に行く予定です。
今回伊豆を選んだのは

1. 放浪よりも、しばらくどこかに滞在してコード書いたりしたい気分だった
2. 釣りが出来る場所のそばに住みたかった
3. バイクで軽く流せる感じの田舎が良かった
4. 東京にちょくちょく帰れる場所にしたかった

というあたりで選びました。別に千葉側でも良かったのだけど、気分的に伊豆かな、と。
居心地が良かったら今後この辺は滞在先の選択肢に入れてもいいかな、と思っています。

ツーリングの季節なのでツーリングにも行きたいけれど、作りたい物も多いので、その辺のバランスをとっていきたい。

三カ月のお仕事を振り返って
karino2

お仕事が終わったので振り返っておく。

仕事をする前の段階で、Deep Learningの流行を見て、自分も画像関係の機能をいろいろ遊びで作ってみたい、と思っていた。
この手の奴は実際のモデルどうこうよりも前の、画像をロードしたり前処理したり、みたいな所とか、結果を評価すべく可視化したりそれを残したり、といった周辺の所で手が動かない、みたいなのがアイデアを試すのを遅くしがちなので、その辺が既に片付いていて実際のサービスになっている物を見て、それを改善していく事で利点と欠点を見ていく方が最初はいいかな、と思って仕事をしようと思った。

この狙いはだいたい達成出来た。そこは一つ大きな収穫だった。
振り返ってみても、やはり予想通り自分で一からやるよりも、既に動いている実際のコードベースを参考に出来るのは大きい。
また私が入る前の段階で既に、これまでの経験を元にうまく行きそうな事をやろう、という前提で物事が進んでいるので、自然と筋の悪い所で大量の時間の無駄をしてしまう、という事は避けられた。

ただ、この狙い自体は最初の一カ月目くらいでだいたいマスター出来てしまっていた気がする。
勉強としては最初の一カ月で十分だったので、残り二カ月はアウトプットに期待したいな、と自分としては思っていた。

当初考えていた期待アウトプットとしては、

1. 一つ実サービスに使うような機能の改善などをする
2. それと並行して研究っぽい事をいろいろやって、論文一本くらいは書けたらいいな(多少は辞めた後も書くとして)

という考えだった。
最近はもうサービス開発は極めただろう、という事で、いろいろな人と話し合ったりしながら機能とかを考えて実装していく、みたいなのはあまり魅力を感じなくなっていた。
金の為に多少やる位は許す、くらいの位置づけ。

そこで1をほどほどにやりつつ2を頑張るくらいにしたかったのだが、今回は割と1で終わってしまった。
1がその位かかったのは今から振り返るともっともな理由があって、あんまり自分の能力不足という気もしないのだが、2ヶ月も追加で働いた分、自分の側にそれだけの価値があったか?と言われるとちょっと微妙な気がする。
そういう訳で自分のアウトプットとしてはいまいち、という結果に終わった。

三カ月という期間

前回の五カ月は相当うんざりだったので、それを思うと三カ月はずっと良かった。
なかなか三カ月だけ働かせてくれる、という職場は無いので、その辺とても柔軟に対応してくれた今回の会社は、素晴らしいな、と思っている。
ただ、労働意欲的な面からいうと、三カ月でもずっと働くのは多い気がする。
2ヶ月働いて一カ月あけて、もう二カ月働く、とかの方が良かったかもなぁ。

夏に働くのは大分労働意欲が低下するんじゃないか、と心配してたが、今年は雨ばっかであんまり夏だっ!遊ぶぞっ!って感じの天気が多く無かったので、その辺は予想以上に問題無かった。
あと、窓からランドマークタワーが見えるのも宗教上の理由で夏を過ごすのに大変良かった。
夏に働くなら窓から何が見えるか、というのは凄く重要なんだなぁ、という事を学んだ。

機械学習のアウトプットという点では三カ月は相当短くてシビアだな、と思った。
今回アウトプットがいまいちな理由の一つは、三カ月という期間はある気がする。
もう二カ月くらい働くともうちょっと納得いく所まで行けた気もするが、三カ月だと一つ何か予想よりも手間取る事があるとリカバー出来ない。
そして往々にして機械学習のプロジェクトでは予想よりも手間取る物は発生するものだ。

この労働意欲的な事とアウトプット的な事でバランスが取れなくなってきた、というのは自分の今の課題に思う。
望ましくは三カ月くらいでちゃんと期待通りのアウトプットが出せるくらいのエンジニアに成長しているのが理想だったと思うのだが、ちょっとそうはなれていない。
この辺は、去年Androidの本を書くのに一年以上の期間を使ってしまったのも響いているように思う。
この話はポストを改めてまた書いていきたい。


職場環境的な話

オフィスや飲み物などの類は大変良かった。金のかかってる度合でいけばGoogleの方が上だと思うが、金がかかっていれば良い、という物でも無い。
キッチンでみんなで作る、みたいな文化は大変うまく機能していて、職場の魅力の一つとなっていた。
正直この辺に関しては日本企業は外資大手には及ばないという偏見を持っていたが、考えを改めた。
オフィスのロケーションもなかなか良くて、自分が三カ月働き続ける事にそこまで大きな辛さを感じなかった要因の一つに、職場環境の素晴らしさがあったのは間違いない。

設備以外でもあまり細かく管理せず自由にやれて、そんなに小さな企業という訳でも無いのに良くこの環境を維持できるもんだ、と素直に感心した。
そしてそんな中で給料も相当高かったので、本当に大したもんだ、と思った。
正直今回は、自分は待遇の分だけのアウトプットを出していない、と言われても、そう判断されても仕方ないな、と思うレベルではあった。自分としては給料分くらいは働いたと思っているが。

ただ、自分個人の事情としてはもうちょっと論文をたくさん書く職場の方が良かったな、と今から振り返ると思う。
この辺は普通にディープラーニングを活かしたサービスを開発したい、みたいに思っている人なら何も問題無かっただろうが、自分はそうでは無かったので。
研究開発といいつつ普通の開発ばかり、みたいな職場で無かったのは良かった。今回の仕事はほとんどデータ分析の仕事のみで、サービス側やアプリ側は全然触らなかった。ドクター持ってない自分がそういう風に働けるのはありがたい事だ。

チームが立ち上がったばかりなので、チームのフェーズと自分の望みはあってなかったという部分はある。
もうちょっとシニアな研究者が増えるといいなぁ。

論文書く能力を鍛えられなかった

今回の仕事をした印象としては、この三年くらいで論文読んだりデータ分析でやっていく能力はまぁ前線で戦える程度にはなったかなぁ、とは思った。
今自分にもうちょっと欲しいな、と思うのは、論文を書く力だな、と思う。
もうちょっと自分ひとりで論文書いてトップカンファレンスに通せるくらいの論文書き力が欲しいなぁ。

そういう点から振り返ると、今回の仕事では論文書く能力は全然鍛えられなかった。
一年に一回働くとしたらその一回をここで使ってしまって論文書く能力が別段この一年で向上しなかった、という結果になってしまう。それはまずかったなぁ、と思う。二年に一回しか働かないならなお一層そう思う。
もうちょっと皆がガリガリ論文書いて通しまくってる所で働くべきだったと思う。

ただ、そういう職場で働く事は、やるつもりだったインプットと微妙にアンバランスなので、その二つを満たす職場が存在するかは少し怪しい。
でももし存在しないならインプットの方は仕事じゃなくて趣味でやって、アウトプットの方に労働意欲を消費すべきだった気もする。

この辺は働く前に思っていた事じゃなくて働いた結果思った事なので、今回どうすべきだったか、よりは次にどうすべきか、という話かもしれない。


事前準備とか時代にどのくらい自分が適応出来ているか?

前回の仕事ではMap ReduceやHadoop関連、Jupyter Notebook関連、AWS関連、機械学習関連といろいろキャッチアップする物が多くて、結構後手に回り過ぎた感じはあったが、今回はまぁまぁ必要な事はもって行けたかな、と思う。
ディープラーニング周辺は前にもっと準備出来る事もたくさんあったが、それを準備してしまうと働く理由も無くなってしまうので、その辺はあんなもんか、と思う。
職場にキャッチアップする、というよりは、手持ちの引き出しを元に組織のレベルや成熟度に合わせる、という感じだったと思う。

前回の仕事では2010年代の前半のサボりの影響はでかいなぁ、という印象だったが、今回はその辺はもう大丈夫かな、と思う。
結構今の時代に適応したスキルセットになれていると思う。
中期的にはこの辺は満足度は高い。よしよし、という感じ。


総評:楽しく良い待遇の職場で、いまいちなアウトプットだった

まとめるとそういう事になると思う。
もっと自分のアウトプットが良くなるような職場もあるとは思うが、どちらかといえばこの環境で自分の期待する程度のアウトプットが出せないのは自分がふがいない、という方が正しいのは間違いない。
もうちょっと凄い事が出来るデータ分析屋になりたい所だが、自分の今の実力がこんなもんなのは仕方ないなぁ、とも思った。
次はその辺の事をちゃんと踏まえた上で、しょぼい実力の自分でも自分の期待するアウトプットが出せそうな職場を選んで行く必要があるなぁ。

なんとなく後ろ向きな印象のポストとなったが、職場環境自体はかなり良くて、最高に近い環境だったと思う。
正直自分のような正社員で真面目に働くルートじゃない人間がこんな待遇で働ける、というのは、以前は予想していなかった。
ありがたい方向に時代も変わったなぁ、と思う。

問題は、どちらかというと職場どうこうというより自分の現状について、このままの延長ではいかんなぁ、という話なのだろうな。


画像解析を実サービスに使う難しさ
karino2
仕事もあと二週間を切り、そろそろ残った時間で出来ない事も増えてきて終わりを意識してまとめる段階になってきた。

今回の仕事は勉強目的では最初の一ヶ月くらいでだいたいやりたい事はやった感じがあり、残りの二ヶ月はアウトプット的な事を期待したい時期だったのだが、振り返るといまいちぱっとしない。

画像解析の実サービスのリリースに向けて筋道をつけるくらいで精一杯だった。
三ヶ月も働くのだから、これにプラスして一つくらい論文になりそうな事をやって論文を書く筋道をつけるくらいの事までやりたいなぁ、と思っていたのだが。

なんでそういう結果となったのか、いろいろと考えた。
最初は自分の実力不足的な事をいろいろと考えて、そこにはそれなりに反省すべき所もあり、その辺の話はまた別にそのうち書きたい。

ただ、最近はどうもそういう事だけじゃなくて、そもそも画像解析のサービスを作る、というのは、この位かかる物なんじゃないかな、と思い始めている。

もともと「この位はやりたいな」と思う時には、そのタスクの内容について、なんとなく必要な時間みたいなのは心の中で見積もっているのだと思う。で、この心の中の「この位で出来るだろう」という感覚が、実態と結構ずれていたんじゃないか。

そもそもデータ分析を実務に持っていくのは結構いろいろ難しい、という事は理解していたつもりだった。
前回レコメンドでは実サービスに載せていたし、その時ちゃんと片付けるまで5ヶ月くらいかかっている。
同じペースで働いていたらそもそも三ヶ月ではここまでも来ていなくても不思議では無い

ただ、二回目なのともう少し始める前の段階で前回よりはいろいろうまくやったので、前回と同じくらいで片付く仕事なら、それにもう一つ位大きめの事をやりつつ片付けられるくらいの判断で居たし、そこは今振り返ってもそれなりに合理的に思う。
この考えで間違っていたのは、レコメンド系でだいたい考えた規模感というか掛かる時間みたいなので、画像解析系のモデルをサービスまで持っていくコストを考えた所だったんじゃないか。

もともと画像解析に限らず、機械学習系の機能を実サービスに持っていくのは、従来のサービス開発とは大きく違う所がある。
あらかじめは、何が出来るのか良く分からない、という所だ。
だからこれまでのように作りたい物を考えて作っていくのでは無く、やりたそうな事で使えそうな当たりをうろちょろして、偶然行けそうなのに当たったらそれをサービスにする、みたいなやり方にならざるを得ない。
この「やりたそうな事のあたり」の範囲がどの位広いかで、どの位当初考えていた物に近い所に着地出来るか、というのが決まる気がする。

デモでちょっと面白い動きをする所までは結構簡単に行くのだが、それを実際のサービスに載せようとすると、従来のサービスの感覚で機能を考えた時には全然ダメなケースが大量に出てきて使い物にならない。
だから、まずそもそも、サービス側の仕様的な部分で、ある程変な動きを許容するように考える必要がある。
見せ方として、変な動きをしてもユーザーが納得出来るように見せる。
これは実際に使われているサービスだと大変うまくやっている。

一方でやっぱりサービス側の仕様的な所の妥協の余地にも限界はあって、どうしてもここは譲れない、みたいなラインも必要。
ここを頑張らないとちょっと面白い動きはしても、結局使わない物になってしまう。
この頑張りの部分が「JSFを使えばこんなに簡単に以前のペットショップの例が書けます」みたいなデモ的な事と、実際のサービスで必要な物とのギャップを埋める部分に対応していて、ここが結構大変なのはこれまでの開発とそんなに感覚は違わない気がする。
そこはこれまでの経験に前回の仕事で学んだ範囲の補正でまぁまぁ正しく把握出来ていた気がする。

画像解析系が予想よりも難しかったのは、理解しがたい挙動をする度合いがリコメンドより大きい、という所だった。
XGBoostだって変な動きするけど、Inception v3とかの方がよっぽど変な動きをする。
そしてこの度合いはしばしば、実際のサービスでは使い物にならない位変な動きをする。
バグなのかどうかも良く分からない。
この凄く予測不能な動きをする物を抱え込んで実サービスを作る、という事を、良く理解出来ていなかった気がする。

自分の考えだと現時点で画像分析をサービスに組み込むべきか?と問われたら、多くの場合で「組み込むべきだ」と思っている。
凄く多くのケースで実際にとても便利なサービスを作るポテンシャルがあり、大抵のサービスで使いみちがある位多様な使いみちがあると思う。
ただ、多様な使いみちがあるけれど、一方で出来ない物も凄く多い。
ちょうど有理数は無限個あるけれど、実数の方がずっと多い、みたいな話に似ていると思う。
適当にえいっとダーツを投げると、必ず実数の方にあたる。偶然有理数に当たる事は無い
ただ有理数も十分に広い範囲に無限にある。
だから従来の開発とは違う物、と割り切って今の世代に合わせて、多くのサービスに組み込んで行けば良いと思う。

ただ、実際にどういう事が出来そうかを自分らの興味のあるドメインで当たりをつけるだけで、普通に二人月とか掛かる事を覚悟しておく必要はある気がする。
ここを自分は見誤っていた。

なお、この当たりをつける段階でやった事の進捗とかは、全く管理出来る感じじゃない。
優秀な人がリーダーとなってシステマティックに下々の人々にやらせる、みたいなのも出来そうに無い気がする。
ぱっと見良さそうなデモから実サービスまでの間を埋めるのも、従来よりは大分難度が上がる上に、この「ちょうど良い」所のぱっと見良さそうなデモまでたどり着くのも結構大変だ。
既存のいかにも流行ってる話題にそっくりな例であっても、「ちょっとだけ」問題設定を変えるだけで全く予測不能な振る舞いをするので、パクるのも全然出来ない。

この辺の不確定さ、難しさは、「これからはディープラーニングだ!」とか煽ってる人達は、まるで無いかのように振る舞うが、実際に実務でやるなら凄く重要な要素に思う。
しかもこの難しさは、従来のレコメンドなどの機械学習のモデルよりも大分手強くなっている。
まだまだ我々の対応出来る範囲だが、大分やり方や考え方は変える必要がある。

Kotlinを使い始めた
karino2

Googleが正式にサポートすると言ってるので使ってみる事にした。
ソースコード読みアプリを作りたいと思ってたのでそれに使ってみる。
https://github.com/karino2/ZipSourceCodeReading

このアプリについてはもっと出来たらそのうち別にエントリを書く。

これまではGoogleがサポートしない限りAndroidでJava以外の選択肢はあり得ないと固く信じてたので、どんな言語かすら全然知らずにここまで来た。
という事でどんな言語か勉強する所から。

最初は本でも買おうかと思ったが、いまいち良さそうな本が無い。

で、途中まで本家のKotlin Koanをやってみた。
途中でかったるくなる位までやった(1/3くらいか?)
で、その後は本家(以下)のreferenceのpdfをタブレットに入れて、だいたい先頭から読んでる。

https://kotlinlang.org/docs/reference/

序盤の方のイディオムとかはなかなか良く書けていて、ちょっとかったるいが入門書として十分詳しく書かれているので、本よりはこっちの方が良さそう、という結論。

クラスとかプロパティとかdelegateのあたりまで見たあたりで、読むだけに飽きてきたので実際に書き始めている。
以前zipに入ってる将棋の棋譜を検索するアプリを書いた事があったので、しばらくは対応するJavaコードが手元にあるので、移植していく感じに書けて、入門にはちょうど良い。

最初の一時間くらいはちょこちょこ詰まってたが、その後は割とスラスラ書けて、たまに分からない所をリファレンスのpdf読むくらいで十分書ける。
ライブラリやプラットフォームの知識は十分あるので、言語の移行はそう難しくないやね。モダンな言語の経験が何かあれば一日とか2日で十分使い始められると思う。

Kotlinの言語雑感。
なんか凄いScalaに似ててびっくりする。
複雑な所までScalaっぽい。
今時の言語ってシンプルなのが多いので、ちょっと珍しい。
正直こんなに似てるならなんでscalaじゃダメだったんだろう?と思ってしまう。

Scalaってそもそも結構好き嫌い分かれる言語なので、凡庸の代表みたいになってるJavaとは随分毛色の違う言語を持ってきたなぁ、という印象。
もうちょっとJava愛ある人が、better Java的に作った言語だったら、コミュニティ的にももっとすんなり使えただろうなぁ、とは思う。
C言語に対するgoみたいな。

いろんな言語の良い所を寄せ集めてる感じで、いまいち統一感も無い気がする。scalaをperlっぽく発展させてる感じがある。C# とswiftからもいろいろ借用してる感じがある。
こう書くといまいちに聞こえるし実際一目惚れという感じはしないが、IDEがちゃんと快適に動いて、IDEファーストな言語なのは間違いない。
ここが一番大切な所と思うので、そこは満足。IDEの動作がJava並みに軽い。
ビルドはややとろいが、インテリセンスとかは早い。
C# のIDE環境は素晴らしかったが、KotlinでAndroid開発は環境的にも匹敵していて、越えてる部分も多く感じる。

また、自分はC# が長かったから複雑な言語仕様の耐性は結構あるので、大した抵抗も無い。
世の中のJavaプログラマがどう思うかは分からないが、まぁイマドキはJavaプログラマだってJava以外も触ってるだろうから、そんな抵抗無いんじゃないかな。
楽には書けるしコンパイルでチェック出来る度合いもJavaより多い。
随分安全な言語で、変なバグを埋め込みにくい気はした。そこは良いね。

あまりAndroid の事を考えて作った、という感じもしない。
ま、そこはこれからに期待か。
そういう統一感無く生まれて成長してきた物を取り込むのは、逆にGoogleの度量を表している気もする。
そう考えるとAndroidらしいやね。

RxJavaとの相性は凄くいい。
もともとエリックの作った物がscalaっぽい物と相性良いのは当たり前だが、itとかで凄くラムダがコンパクトに書けるしインテリセンスバンザイな感じだし、書いててめちゃくちゃ快適。

最初は別にKotlin流に書かずに、単なるbetter Javaとしても書けるので、とりあえず使ってみてちょっとずつ手持ちの小粋な機能を増やして行く感じでやっていけば良い気はする。

今の所まだちょっと書いただけなので今後全部Kotlinで行くかは分からないけれど、実際にアプリをplay に登録してユーザーの手元で大きなトラブルが無い、とか、過去のコードをメンテしていくのが大変じゃない、とか、そういうあたりがクリア出来たら全部これでいいかな、と思っている。
ま、ダメならJavaに戻ろう、くらいの軽い気持ちで。

Tags: