C-FRONT

エモくありたい

Go研修を修了しました

2017/11~2018/4の6ヶ月間、柴田先生のGo研修を受講しました。無事修了したので感想やメモをまとめておきます。

研修概要

こちらの研修を受講しました。 第5期Go言語研修を開講しました:柴田 芳樹 (Yoshiki Shibata):So-netブログ

「プログラミングGo」の書籍を半年間書けて読み、課題もすべて解いていくスタイルの研修になります。 予習時間はすべてプライベートの時間を使って行うこととなっており、私はプライベートの半分以上の時間はこのGo研修の予習に費やしたと思います。

第5期Go研修が終了しました:柴田 芳樹 (Yoshiki Shibata):So-netブログ

振り返り

Go研修で得たことを以下にまとめます。

プログラミング言語の一通りの機能の理解

  • 業務では触れることはなかったであろう分野(complexとかsqrtとかマンデンブロとか…)
  • webクローラー、チャットサーバー、ビットカウント、FTPサーバー等の題材を通して網羅的に言語の機能を触ることができた
  • 上記のような、プログラミング習得時によくある題材を取り組むことで基本的な実装力もついたと思う

「言語仕様」「言語思想」ついての興味/理解

  • 今まで「言語仕様」について気にしたことなかった
  • 特に第一回のJava Pazzlerでどういう仕様に基づいてプログラミング言語が動いているのかに興味を持つようになった
  • Javaとの比較でGoはどのような思想にもとづいているのかを少しだけ理解できたと思う
  • constの型の話、Javaと違って暗黙的型変換はないの話、interfaceが持つ型と値の話等が特に印象に残っている

低レイヤーでどう動いてるのかへの興味/理解

  • 今まで全く意識したことがなかったので、仕組みを理解するきっかけになったことが楽しかった
  • ゴルーチンがOS/スレッドの上でどのように動いているか
  • マルチCPUのキャッシュの話
  • フラグメンテーションの話やJavaとの比較など

その他

  • Githubの草
  • (徹夜で踏ん張る気力)
  • プライベートでほぼ毎日コードを書く習慣ができた
  • Write Code Everydayに挑戦してみたかったので、良いきっかけになった
  • githubでコードを公開することへの抵抗感なくなった

途中辞退者もいる中でなんとか最後まで受講できたのは自分の中で自信になったと思います。 今までJava以外にがっつり触れた言語はなかったので、一つ触ることのできる言語が増えた点でもよかったです。

メモ

以下は研修中に取ったメモを載せておく。 ※あとで追記予定

Picasso 2.5.2→2.71828へのマイグレーションについてのメモ

Picasso 2.71828にバージョンアップする際にissueや関連レポジトリを探しまくったので、どんなことがあったのかと思考フローと調べたこと等を雑に記録しておく。

2.5.2での問題

発端は一部の端末でresize()関数を挟むと画像がロードできない問題があった。(必ずonError()関数が呼ばれてしまう。) 手元で再現したのはOS version 6.0.1、Picasso version 2.5.2。

Some images are errored if .resize() applied · Issue #1514 · square/picasso · GitHub

コメントされている解決策が3.0.0-SNAPSHOTにあげることのみだった。

picasso/CHANGELOG.md at master · square/picasso · GitHub

2018/05/01現在version3.0.0はSNAPSHOTなのでその間使うことができる2.71828というバージョンがあるとのことなので、まずは2.71828にあげることにした。

2.5.2→2.71828への変更

2.71828はそれまでの2.x.xのバージョンとは完全に互換性があるわけではないとのこと。主に変更したものは以下。

  • Picasso.with(getContext())メソッドは削除される。Picasso.get()に変更
  • callbackのonError()メソッドの引数にExceptionが渡されるように

picasso2-okhttp3-downloaderとの相性

buildが通るようになってからいくつかの画像が表示されなくなっていることに気づく。 調べるとcallbackが呼ばれていないことに気づく。

setLoggingEnabled(true);

を使ってログを詳細に出す。

Picasso — Cache Indicators, Logging & Stats

このサイトのように正しく表示される画像は以下のようなログに対して、

D/Picasso﹕ Main        created      [R0] Request{http://i.imgur.com/rT5vXE1.jpg}  
D/Picasso﹕ Dispatcher  enqueued     [R0]+21ms  
D/Picasso﹕ Hunter      executing    [R0]+26ms  
D/Picasso﹕ Hunter      decoded      [R0]+575ms  
D/Picasso﹕ Dispatcher  batched      [R0]+576ms for completion  
D/Picasso﹕ Main        completed    [R0]+807ms from NETWORK  
D/Picasso﹕ Dispatcher  delivered    [R0]+809ms  

表示されていないログは

D/Picasso: Main        created      [R2] Request{}
D/Picasso: Dispatcher  enqueued     [R2]+1ms 
D/Picasso: Hunter      executing    [R2]+2ms 

decoded以後のフローが呼ばれていないために画像が表示されていない仮説が立った。

すべての画像が表示されないというわけではなかった。Picassoインスタンスの違いについて調査すると、downloderでOkHttpClientをセットしているインスタンスは画像が表示されていないようだった。

httpリクエストがエラーで返されているかどうかを見るために、OkHttpClientにHttpLoggingInterceptorをセットするなどして追ってみる。 するとそもそもリクエストされていないようだった。(okHttpClientでリクエストする時のnewCall/executeメソッドは共に呼ばれていなかった)

picasso2-okhttp3-downloader側にもissueはあがっているが、組み込んでいてもうこのライブラリは使う必要がなくなるとのこと。

Compatibility with Picasso 2.71828 · Issue #29 · JakeWharton/picasso2-okhttp3-downloader · GitHub

自分は知らなかったが、OkHttp3Downloaderというクラスはpicassoの中にあるものとjakeのpicasso2-okhttp3-downloaderの中にあるものと複数あって、 元々picasso2-okhttp3-downloaderのものを使っていたのをpicassoの中にあるOkHttp3Downloaderを使うように変更することで解決された。 (微妙にキャッシュ周りなどの実装が違うのだが、どういう背景で複数できたんだろう…)

ちなみに

Picasso.Builder.downloaderWith(OkHttpClient/Call.Factory)? · Issue #1751 · square/picasso · GitHub

このissueでDownloder経由でOkHttpClientをセットするのを削除しようと議論になっている。

Remove Downloader from API. by NightlyNexus · Pull Request #1787 · square/picasso · GitHub

上のissueから参照されているPRで実際にdownloder()メソッドからclient()メソッドに変更されていることがわかる。

この変更は2.71828に入っていないので3系からなのかな。

3年が過ぎた

年度末は胃腸炎になったりバタバタしていて3月中に振り返りエントリを書けなかった。 完全にタイミングを逃したが未来の自分のためにやっぱりまとめておく。

[参考]

1年目 文系からエンジニアになって1年が経っちゃったよ - C-FRONT

2年目 社会人2年目をエモめに振り返る - C-FRONT

業務

担当範囲

所属がちょっとだけ変わり開発担当範囲がAndroid→サーバーサイドに変わった。

Spring Bootのキャッチアップにバージョンアップで理解を深めた話 - C-FRONT

SpringBootについてはもちろん、Webサーバーの仕組みから(apache/tomcatのところから)DBの仕組みについても色々学べた一年だった。 Androidアプリの開発だけだと触れられなかったところにたくさん触れることができて、興味範囲が広がった。 うまく抽象化してラベルをつけられないので、どんなことをやっていたのか・考えていたのか具体的に書き出しておく。

  • SpringBootでのAPIの開発・webアプリケーションの開発
  • SpringBatchを使ったバッチの設計・開発
  • Fitnesseを使用したAPIのE2Eテストについて
  • APIプロジェクトでの単体テストを書くこと
  • カスタマー問い合わせへの対応・それにまつわるデータやログの調査
  • サーバー内のディスク容量・CPU使用量への調査
  • DB周りの問題について(インデックス領域・TEMP領域枯渇への対応)
  • スロークエリの調査(インデックスとはみたいなところから)
  • 本番データからのデータ出力・加工(ひたすらSQL書いたり)
  • DBの定義変更を含むリリース時のフロー(サイト閉塞してのリリース)

みたいなことをやっていた気がする。うまく言い表せられないけどサーバーサイドと言ってもアプリケーションの開発・運用保守/パフォーマンス・チューニング・インフラとかたくさん分野があるということと、少しだけでもその全体像に触れられたところがよかった。 サーバーサイドに変わった時「運用をしっかり経験しないと開発に良い設計に活かせない」とアドバイスをもらったことが印象的だった。地道なことも多いけどアラートの対応したりカスタマーサポートすることでサービスの全体像を把握するのに役立ったかなと思っている。

社内で開催されたISUCONにも参加させてもらい、アプリ開発だけやっていたら絶対に参加していなかったと思う。そしてめっちゃ楽しい。この世界が知れて良かった。

社内ISUCON合宿に参加してきた感想 - C-FRONT

開発プロセス

開発プロセスに関しても考えた1年だったと思う。元々開発プロセスというものはなくて、定期的に企画側から降ってくる案件を開発チームが着手する。案件の粒度や詳細化のレベル感もバラバラ。 やっぱり効率が悪いところもあったので、色々試しては挫折したりで悩んだ1年だった。

どこまで企画側に仕様の詳細化を求めるか

  • 企画側で仕様を詳細化するリソースが残っていない中で、権限は企画側に残ったままの状態に違和感があった
  • 企画側に意思がない場合、開発側である程度裁量を持って決める形にしたかったがうまく整えられなかった

開発プロセスフレームワークを導入するにしても教育が必要

  • スクラムを導入にするにしても関係者全員にスクラムとは何かを理解してもらわなければいけない
  • 例えば開発チームにがっつり時間を割けるPOが必要だが、現実問題無理だった
  • 結局こういうプロセスを大きく変える時は有識者が最初はがっつりトップダウンで教育することが有用そう

決めた改善活動を守る警察みたいな存在が必要そう

  • これからはこういうフローにしましょう、と決めたことを守っていくことは意外と難しい
  • チームで決めた施策の遂行を促す改善警察みたいな存在を作ればよかったな

こういう交通整備をしながら開発もできたらすごく幸せな世界だと思う。けど私にはできなさそうだった。ということがわかった。

業務外

世界が広がった1年だった。

イベントでの登壇

Node学園25時限目でLTしました〜初めての社外LTの振り返り〜 #tng25 - C-FRONT

JJUG CCC 2017 Springで登壇しました~新卒2年目が鍛えられたコードレビュー道場~ #jjug_ccc #ccc_l3 - C-FRONT

Tokyo Android Meetupで初英語プレゼンしてきた - C-FRONT

TDDBCに参加&ペアプロデモをしました #tddbc - C-FRONT

海外カンファレンスへの参加

初めてのサンフランシスコ/海外カンファレンス〜KotlinConf2017に行ってきた〜 - C-FRONT

その他

上以外にもDroidKaigiに運営として参加したり、Goの研修を受けたり(後日書く)、新人育成に携わったり、社内勉強会の運営をしたりした。 良かったのは社外に知り合いがとても増えたことで、会社ではできなかった相談ができたり、特に同じ年代の人にはとても刺激をもらった。

自分のやりたいこと・成長について

そういった社外の同じ年代の人の活躍を見る中で、自分がどうしていきたいかを考えるようになった。 自分の今取り組みたいことは技術力を上げることとプロダクトを開発することだと思った。 開発プロセスの改善や企画側とやり取りするのも有意義だと思うが、なかなか開発にまとまった時間を使えなくなってきて思うように開発できなくなってしまった。それで一時期成長を感じられない時期があって、どういう環境に行ったら良いかウジウジ悩んでいた。

  • 開発業務に専念できる or 企画まで考えられる・手広く関われる
  • 新規プロダクト or エンハンス
  • 会社として力をいれているプロダクトか
  • Androidに戻るか or サーバーサイドを続けるか
  • 社員割合
  • 技術的な挑戦がしやすい・意見が通りやすい環境か

みたいなところを考えた結果、開発業務に専念でき、前からすごいなぁと憧れを持っていた環境に行くことにした。退職ではなく社内の中でちょっと所属が変わった。

この1年で自分には開発以外の業務をやりながら新しい技術もキャッチアップしていくのはとても効率の悪いことだと感じたので、しばらくは開発に専念して自分の技術力を上げることに時間を使っていきたい。自分でも甘えだなと感じている部分はあって、多分できる人は技術向上もマネジメント的なこともできるんだろうなと思うと自分は能力不足だとただただ感じている。

ということで自分で決めた道を正解にしていくぞ!

課題を課題として伝えたい

チラ裏。

最近課題を課題として伝えられていない気がする。課題として伝わっていないことを感じて溜め込んで辛い気持ちが大きくなってきたので整理する。

今までの感覚

スクラムに出会った時、チーム内の問題を事象として見つめる視点が好きだった。それまで「自分が能力ないために」起こっているんだという気持ちが大きかったのであまりそれを課題だ、と自信を持って伝えられていなかった。自分が「困っている」と思っていることそれ自体間違いなく起こっている「事象」なので、課題として障害物リストに挙げること、それを自分の能力や人間とは切り離してチームが受け入れてくれることがすごく心地よかった。 おそらくチームで起こる問題を単なる事象として見つめる前提が共有されていたことも大きいだろう。また、スプリント中に起こった問題は事象のみ障害物リストに書き留めるにとどめ、スプリント終わりのレトロスペクティブ時に一気に振り返ることが、問題を感情と切り離して考えるには十分な時間の空きがあったのも要因かもしれない。課題=よりよくできる改善ポイントとして考えられていたので課題が見つかることも少し楽しんでいたのかもしれない。

チームのことや自分の周りのことでも、課題を見つけてもあまり周りの人に共有も改善もできていない状態にある。自分の中で消化もできていなくて「パワーでやるしかない」「しょうがないとして割り切る」といった解決しかできていない。それで自分ができないことに対してすごくネガティブになってしまう負のループ。多分原因は課題を課題として伝えることがうまくできていなくて、うまく伝わっていないことを感じることが自分の中でも感情と事象を切り離すのを阻害しているような気がしている。ふと自分のことを客観視すると文句を言ってるように見えるのでは?と思うようになってきてしまった。自分の考え方が「プロセス考えている暇があったら手を動かせ派」に寄ったのも大きい気がするが、それはまた別文脈な気がするので別で考える。

今の環境はメンバーも開発プロセスも違うので前提が違うのは当然。問題を事象と見る前提をしっかり強調するのか、改善にフォーカスした言い方にするのかわからないが、問題を文句ではなく事象・改善課題として伝えられるように努めていく。

社内ISUCON合宿に参加してきた感想

社内で1泊2日の合宿形式で行うチューニングコンテスト(通称社内ISUCON)に参加してきた。非常に学びがありモチベーションもあがったので、色々感じたことや新しく知ったことを書き残しておく。

前提知識

アプリケーションの開発経験しかなく「チューニング」に関しては知識なし。Android→サーバーサイドの開発に移った際、開発だけではなくサーバーの運用・保守までできるような知識をつけたいと思っていたのでISUCONのことは気になっていた。

事前準備

とにかくISUCONといっても何をしていいかわからなかったので、過去問を使用してどんなことをするのかについて少しだけ予習してから行った。

github.com

こちらを使用して手元に環境構築してISUCONとはどんなものかを試した。

  • ISUCON4
  • ISUCON6

を試した。ISUCON4はこのままだと動かなかった(2017.12現在)ので注意が必要。 ISUCON4はクエリの実行計画を見てindexを貼ったり等である程度の点数が取れるが、ISUCON6では既にindexが貼ってあるのでアプリケーションのロジックでチューニングする/回によってはネットワークチューニングゲーだったらしいなど、問題によってメインのチューニングポイントが違う、ということを知って絶望したりなどしていた。

当日

金曜13:00-土曜13:00までの24時間の制限時間だった。

今回の題材は以下のものを使用した

https://linotice.tumblr.com/post/158135953789/20170308
linotice.tumblr.com

感想

あまり普段の業務では触らないところ(特にミドルウェアの設定など)を動かしながら触れるきっかけがあったのはよかった。 もちろんミドルウェア/インフラ部分は知識0だから頑張ろうな・・・というのは当然だが、アプリケーション層のチューニングはもっとできたと思う&できるべきだったと思っている。不必要なDBアクセスしている/もっと効率よい書き方がある/DBの非正規化など…。知識としては足りてるはずなのに活かせなかった部分に気づけたのは良かった。

それに普段一緒に仕事していないメンバーとチームを組めたことで、全く自分では到達できない視点に気づくことができた。非常に勉強になった。 点数ではっきり勝ち負けが決まるゲーム性も燃えるし、同じ問題を皆で解くのでチームごとにアプローチが違い、終わった後のネタバラシもかなり盛り上がった。 自分は開発合宿を今まで避けてきたが、かなり楽しかった。

やったことなど

  • mysqlのlogを吐き出すように設定
  • クエリを確認/indexを貼る
  • スロークエリのログ設定/分析
  • モニタリングツールの導入(今回はnewRelic)
  • nginxの静的ファイルの配信設定
  • nginxの静的ファイルのキャッシュ
  • DBの非正規化
  • Mysqlの接続をUnixドメインソケットに変更
  • クエリキャッシュ有効化
  • innotopの有効な使い方
  • mysql→Redis移行
  • アプリケーションロジックの変更

他のチームが行っていたことで参考にしたいこと

  • tcpエフェメラルポートの設定を変更
  • DBのインメモリ化
  • セッションをcookieで持つ
  • テンプレートエンジン捨てる
  • 計測ツールnetdataを有効的に使うとチューニングどころが効率よく見つけられそう(https://github.com/firehol/netdata)

(よくわかってない部分もある)

次回もがんばろうな

初めてのサンフランシスコ/海外カンファレンス〜KotlinConf2017に行ってきた〜

初めて海外カンファレンスに行ってきた。次行く機会に自分でも見直せるように書き残しておく。

www.kotlinconf.com

きっかけ

  • ちょうどGoogle IOがあった時でTLでtwitterでいつも見ている人が皆Google IOに行っていることを知る
  • 自分の会社、他の部署・他の関連会社では同じ年くらいの人も行っていたのでいいなーと思う。
  • 会社で行かせてもらうほど自分に技術やスキルに自信がなかったのですぐには行けないけど、いつか行きたいなと思っていた
  • シリコンバレーや海外で働くことに対して漠然とした憧れはあったけど実際に何が良いのかうまく自分の中で説明できなかった。
  • 「とにかく海外カンファレンス行ってみたい!」何が良いのかも一回行ってみないとわからないでしょう、一回行ったら気が済むのでは、と思っていた。

自腹でもいいから買おうかなと言っている人を見て、そうか。自腹で行っちゃうという手もありなのかと思う。 ということで会社の経費が落ちるかは全くわからなかったけど勢いだけでチケットを買ったところからが始まりだった。(結局会社からいけることになった。本当にいい会社です)

英語とKotlin

仕事で使うこともなく英語/Kotlinは「しようしよう」と言いながらできてなかった。いつかしなきゃな、と思っていたのでKotlinConf行くのを目標に英語/Kotlinのキャッチアップをするというのを11月までの目標にした。

5月にチケットを買ってからDMM英会話に登録した。1日30分ずつレッスンを受けていた。週に5日くらいはできていたと思う。朝早く起きてレッスンを受けることが多かったので早起きできるようになってうれしかった。 CLEMというイベントにいったのがきっかけで英語でLTすることにもなった。

chiiia12.hatenablog.jp

Kotlinは業務で使ってなかったので趣味で自分で書いていた小さいアプリをKotlin化したりしていた。小さいアプリかつ難しいことも何もやってないので、Kotlinができるとは程遠いけど…ここはもうちょっとできたなぁと反省している。

Day1:移動・MountainView訪問

カンファレンスの前日にサンフランシスコ入り。昼すぎに着いたので、直接マウンテンビューに向かいGoogleオフィスを訪問。たまたまGoogleに務める知り合いがマウンテンビューにいたので少しオフィスの中のほうまで見せてもらった。 以下メモ

  • googleのキャンパスは大学みたいな感じ
  • 田舎で車がないと生活できないらしい
  • 知り合いはSF市内に住んでいて、googleが専用のバスを出してくれてるからそれで通勤しているらしい
  • 朝夜は渋滞がすごいらしい。空港からMTVも1hくらいと教えてもらっていたけど実際30分くらいでついた
  • SF市内にもオフィスがあるのでSFオフィスとMTVオフィスを曜日ごとに通い分けているらしい
  • MTVには偉い人がいるからそういう会議を出席するのにMTVに週何日かくる必要があると言ってた
  • キャンパス内にジムや食堂あり。フリードリンクでスナックや飲み物はいつでももらえる。3時くらいに行った時は何人かジムを使ってた。やることやってれば昼間でも自由にジムにいける
  • Google Storeは日曜休み。Tシャツとかマグカップとかgoogle homeとか。Droidくんのぬいぐるみに手を出しそうになったがやめておいた
  • google社員だと1割引きになるらしく知り合いのカードで支払ってもらった(社員証を見せて私の支払いはダメらしい)
  • レジにNo cashと書いてあるのが印象的だった。

f:id:chiiia12:20171119223616j:plain
GoogleStoreでの戦利品

Day2-3:Kotlin Conf参加

Day2-3は本命のカンファレンス参加。受付を前もってしておくpre-registrationというのが前日行われていたらしいが、自分はしていなかったので少し早めに向かったが、受付は一瞬で終わった。写真つきのIDを見せてシールを発行。

f:id:chiiia12:20171119223740j:plain
KotlinConfでのノベルティ達。他にTシャツがある。

セッション

色々わからないことも多かったけど、とにかく全部の時間でセッションを聞きに行った。以下感じたことのメモ。

Day1最初のKeynoteではKotlinの最新事情や今後の展開などが話された。KotlinをMultiplatform化することにすごく力をいれているということが伝わった。サーバサイド・Android・JSだけでなく、iOSの公式サポートが発表されて会場はドっと湧いていた。CommonModuleというフロントとサーバサイドでKotlinコードを共有できるという概念は興味深かった。ちょうど自分のチームが少ない人数でフロントからモバイル・サーバサイドまで開発していかなきゃいけない体制になっていきそうなので、Kotlinで開発することでクロスファンクショナル化をより進められるのかも?などと考えていたりした。

Kotlin1.1から導入されたコルーチンの話題が多かった印象。非同期処理行う時のコールバック地獄をスッキリ書けるんだよみたいな話をIntroduction to Coroutinesでしていたと思う。Springでコルーチンをどう使うかというセッションもあったり、Kotlin製のWebフレームワーク「Ktor」でもコルーチンを使った非同期処理を利用していたり推されている機能のように感じた。何が良さでどう使い分けるのか自分でもわかってない部分があるので、今後ちゃんと理解したいトピックだなと感じた。非同期処理を書く時にはRxJavaを使うことが多かったところをコルーチンが代替するかも、という点で皆の関心度が高かったのではという話を参加者としていた。

Introduction to Coroutines @ KotlinConf 2017

Springの話も多かった。Bootiful Kotlinというセッションが大変人気なようだった。2017/9にリリースされたSpring Framework5にSpring WebFlux機能の追加とKotlinのサポートが入ったことがポイントと理解している。Spring WebFluxのプログラミングモデルの一つである「Router Functions」というアノテーションではなくラムダを通して設定していく書き方とKotlinの組み合わせの相性がよく、よりシンプルに書けるというところが好評どころだった、と私は理解している。

KotlinConf 2017 - Bootiful Kotlin by Josh Long - YouTube

Kotlin製のテストフレームワークであるSpekの話も興味深かった。JUnitでは「コードの繰り返し」「メソッド名が長くなりすぎる」「何のテストをしているかわからない」状態に陥ることが多くSpekはそういった問題点を簡単に解決してくれるといった内容だった。JUnitでもテストの構造化やパラメータ化はできるが、JUnitよりもより覚えやすい・書きやすいというところが良いところなんだと思う。おそらくSpec系のテストフレームワークとできることは一緒なのでは、という認識。なのですが 、Kotlinで書けることがプロダクションコードとのスイッチングコストをより少なくできる点で良いところなんだと理解している。

Testing Kotlin at Scale — Spek #KotlinConf2017 // Speaker Deck

準備と心づもり編

実際にサンフランシスコに行く前に準備していたことと、もっとこう準備しておけばよかったことを備忘録として書いておく。

  • 日中と夜の寒暖差が激しいと聞いたので冬用のコートを用意。会場は屋内だったが、すごく寒かった。一日中コートを着ていても顔が青くなるくらい寒かったので、カイロか何かをいくつか持っていけばよかった。
  • 向こうでの移動はほぼUber/Lyftと聞いていたのでアプリをインストールしておく。空港からすぐ使えるよう、スマホの充電を十分にしておく。
  • テンダーロインという地域は危ないので近づかないよう気をつける。テンダーロイン以外にも重厚なシャッターが閉まっているところがあるので地面を見つめながら黙って早歩きで通り抜ける(とアドバイスをもらった)
  • 21時以降は出歩かない、そもそもあまり一人で出歩かない。気をつけていたけど、夜中の2時まで参加者のみんなで外で飲んだりしたので、みんなで一緒なら大丈夫。
  • ホテルに歯ブラシがないことがあるので持っておく。当然あるものだと思っていて気づいたのが夜中だったので朝コンビニで買えるまで地獄だった。
  • 時差ボケひどいので無理しない。サンフランシスコについた日の夜は夜中に目が覚めてしまいそのまま朝まで寝れなかった。日本と違って体調も崩しやすい& ただのビールだと思ったらアルコール度数10%でした、というパターンがあるのでお酒はいつもより少なめにしておく。夜は寝れないが昼の2.3時の眠気がヤバい。
  • 会場のWifiや電源は日本と違ってあまりアテにできない。

サンフランシスコ/海外事情

Day1のパーティ後に海外の参加者達と一緒に二次会・三次会に繰り出した。 この思い出が特に印象に残っていて、海外でのエンジニア事情について聞けたことが新鮮で刺激的だった。(知人のおかげで一緒に混ぜてもらえた、ありがたい🙇)

カンファレンス参加について

会社で行ってるので帰ったらフィードバックしなきゃいけない、という話をした。 (すべての会社ではないと思うが)話した人の会社では年に100万くらい(金額は曖昧)研修やカンファレンスなど自分で何に使うか決めていいお金があって、それを使って今回のカンファレンスに来たと言っていた。 なので、今回のイベント参加は別に会社にFBする必要もないし、この費用はカンファレンスでも本でも何にでも比較的自由に申請できるんだー、と言ってたのが印象的だった。 今回出会った人たちは、かなりカンファレンスに参加に積極的らしく、日本にもDroidKaigiで来てくれていたらしい。日本でもコミュニティがあると、「次は日本に来てよ!」「いくいく!」て繋がっていくのがうれしかった。恋人同士エンジニアで一緒にカンファレンス参加している人も多い。

エンジニアのキャリアについて

  • ネットフリックスのエンジニアは皆すごい給料高くもらってるらしい。
  • アメリカだとCSを持ってないとエンジニアなれないって聞いた。→「そんなことないよ。本当に今エンジニアの職たくさんあって、特にSFがエンジニアの求人が本当多い」「実際に自分は大学の学士持ってないよー」
  • エンジニアの立場が下になってしまうことがよくあって・・・→アメリカはエンジニアの立場が絶対上。
  • やっぱりエンジニア、コード書かなくなっちゃうことが多いのかな→エンジニアからマネージャーいくこともあるけどエンジニアはそれはそれで評価されてるみたいな。プロダクトマネージャーとかになるエンジニアも多いかも。自分もマネージャーだった時は全くコード書けなかった。けどそれが役割だからit's ok

振りかえり

セッション選び

わかりやすいセッションもあったし、自分の英語力不足であまりついていけないセッションも多かった。 エモい系のセッション(プロセスとか、心持ちとかのことを語る内容だとニュアンスが聞き取れない)はついていけなくなることが多いことにDay1で気づいたのでコードベースで説明してくれそうなセッションに変更したりした。

リスニング

参加前GoogleIOの動画をいくつか見ていてなんとかついていけるかもと思っていたが、自分の想像以上についていけなくて愕然とした。話す練習をしようと思ってDMM英会話を続けていたけどまずはリスニングで聞き取れるようにならないとな、と感じた。(Google IOは皆に理解されやすいように特に英語の表現気をつけてくれているという話をチラッと聞いた)

その他

  • 知らないことばかりだったけど大量の新しいinputの機会になった
  • カンファレンス来ている人皆息を吐くようにコード書いてた
  • githubintelliJの画面しか開いていなかった印象
  • 日本人的には英語喋れないので消極的になりがちだけど本当無駄で向こうの人は全然気にしていない。ウッっとなって喋れないのは誰の得にもならない。
  • KotlinConfに参加していたことがきっかけで同じように参加されている日本の方(話してみたかった)人ともお話ができたのが嬉しかった

最後に

長くなったが、刺激的で色々と感じるものが多かった良い海外出張だった。 もっと頑張らなきゃなという気持ちしかないけど、また日本で頑張って海外出張行かせてもらえるように成長するしかない。

Groovy入門して躓きメモ

Java→Groovy初日で出会ったエラーたちやメモたち。 syntaxもよくわからない中で出会って、解決するのに慣れなかったのでメモしておく。

メソッドの呼び出し間違い

メソッドの呼び出しが間違った時

Caught: groovy.lang.MissingMethodException: No signature of method: hogepackage.hogefile.hogemethod() is applicable for argument types: (java.math.BigDecimal, java.util.ArrayList, groovy.sql.Sql) values: ...

特にクロージャの中でエラーが起きるとクロージャのどこでそれが起きているのかよくわからなくて慣れるまで時間がかかった。

変数の宣言のスコープ

http://d.hatena.ne.jp/Kazuhira/20120318/1332083318

before

def sql = Sql.newInstance()

Map.each{k,v->
    searchUuidByUser(k,v,sql)
}

eachの中からsqlは呼び出せない。

Caught: groovy.lang.MissingPropertyException: No such property: sql for class: hogepackage.hogefile
groovy.lang.MissingPropertyException: No such property: sql for class: hogepackage.hogefile

after

sql = Sql.newInstance()

Map.each{k,v->
    searchUuidByUser(k,v,sql)
}

def をつけているとクロージャ内やメソッド内から呼び出せない。

列名が無効

before

def SELECT_USER_POINT_HISTORY = "SELECT ID,POINT,INSERT_AT from POINT_HISTORY where ID = $userId ORDER BY INSERT_AT"
        List<Point> pointList = new ArrayList()
        sql.eachRow(SELECT_USER_POINT_HISTORY){
            Point dto = new Point()
            dto.type = it.type
            dto.point = it.point
            dto.insertAt = it.insert_at
            pointList.add(dto)
        }
警告: Failed to execute: SELECT ID,POINT,INSERT_AT from POINT_HISTORY where ID = ? AND TYPE != 0 ORDER BY INSERT_AT because: 列名が無効です。
Caught: java.sql.SQLException: 列名が無効です。
java.sql.SQLException: 列名が無効です。

てっきりSQLが悪いのかと思ってタイポかどうか必死に探したけどSQLが悪いわけじゃなかった

after

def SELECT_USER_POINT_HISTORY = "SELECT ID,POINT,TYPE,INSERT_AT from POINT_HISTORY where ID = $userId ORDER BY INSERT_AT"
        List<Point> pointList = new ArrayList()
        sql.eachRow(SELECT_USER_POINT_HISTORY){
            Point dto = new Point()
            dto.type = it.type
            dto.point = it.point
            dto.insertAt = it.insert_at
            pointList.add(dto)
        }

eachRowの中で参照しているit.typeがselectするものに含まれてないため。 エラー行数をよく見るとit.typeを使っている行を指しているのでわかる

for文の抜けかた

https://stackoverflow.com/questions/3049790/can-you-break-from-a-groovy-each-closure 次のイテレートに入るならeachのままcontinueしてもOK そもそもループを中止したい時(Javaでいうbreakをしたい時)はfindにしてその中でtrueを返してループを終わりにする

pointList.find{
                Data data = new Data();
                if(nowPoint<it.point){
                  //breakと同じ。ループを抜ける
                    return true;
                }else{
                    //continueと同じ。
                    return false;
                }
}