社内勉強会でライトニングトークしてきた。
フリーテーマだったので何話そうか迷っていたけれど、最近いい感じになってきたチームのコードレビューについて話してみた。
コードレビューを題材にしたものの、チーム開発が単なる個人の集合じゃなくて、コラボレーションが生まれた時に、チームの力は何倍にもなるんだってことが少しでも伝わっていたら嬉しい。
久々に人前で話したけどやっぱり緊張する。。
なお、サッカーチームのたとえの話が一番熱を帯びてたというフィードバックを頂きました笑
QA勉強会に行ってきた #QAアーキ
12/20にQA勉強会に参加してきたので、印象に残ったことや思ったことなどを残しておく。
品質評価に焦点を当てた勉強会に参加したのは初めてだったかも。
テスト観点は意図を明らかにする
- 仕様をなぞるのではなく、意図を明らかにするのがテスト観点
- 仕様書や機能一覧をただマインドマップで表現しても意味がない
- そのテストでは何を気にしているのか、意図を明らかにする
- ✕: 1M以上のファイル、ファイルサイズによる挙動(仕様書のコピーにしかなっていない)
- ◯: ディスクをいっぱいにして動かなくしたい(意図を明らかにする)
- その意図は開発者が気にすることになる
- 観点が正に開発者が気にすることにつながるので、開発・QAのコラボレーションがすごく期待できそう
- 開発者が気になるけども、気付いていない観点をQAが出せるようになったらさらに素晴らしい
- 観点洗い出しができるようになると、設計やレビューでQAが可能になる
品質保証を選択する
- どのQA観点をどう作り込みどう検証するかまとめる→アシュアランスフロー
- どこで何をするか整理すると品質保証が取捨選択できるようになる
- 品質保証は選択ができないといけない
- どこで何を保証するかが整理されていないといけない
- 工程の責務が明らかになれば、自動化の注力先も分かる
- 捨てる選択ができるようにするアプローチはｲｲﾈ!!
スピード感が求められる中でのアプローチ
時間があったので質問してみました。
質問
- QA観点を洗い出して、アシュアランスフローに落とし込むのはとても有用だと思う
- Webサービス開発のようにスピードが求められる場合、QA観点の段階から取捨選択が必要になるのではないか
- そのあたりに何かアドバイスあれば
回答
- 大切にしたいものによって、やり方は色々ある
- 品質に網羅性を求めるのか、機動性を上げたいのか、開発能力を上げたいのかで異なる
- 特にスピードが求められる現場であれば、「これはやらなくていいよね、大丈夫だよね」の納得感が得られるようなアプローチ
- 妖精型
- 気になるところや気にしているところを集めて整理していく
- ティータイムを設けて、最近自分が出したバグを共有する会を設けているところもある
- 決してプロセスを整理したりハンコを増やしたりするものではない
感想
とても有意義で面白かった。
QAと開発のコラボレートが具体的にイメージできるようになったのが一番の収穫かもしれない。
その他メモ
- チェックを増やすと精度は下がる
- （主に上層部批判の）組織論的な話が出るのはどこでもだなぁ
- バグを出したら怒られる、っていうのが無駄なプロセスを増やす根源な気がした
資料
www.slideshare.net
iTunesで曲名がオンラインで見つからなくなった。。
どのタイミングでなったのか分からないけどiTunesでCDを読み込もうとしたら｢このCDの曲名がオンラインで見つかりませんでした｡曲を読み込みますか？｣と言われて曲名が読み込めなくなった。
備忘のための解決策メモ。
発生した環境
対応
下記のファイルを削除する
$HOME/Library/Preferences/
- CD Info.cidb
- com.apple.iTunesHelper.plist
- com.apple.iTunes.plist
- com.apple.iTunes.eq.plist
- com.apple.iTunes.eq.plist.lockfile
- com.apple.mobile.iTunes.store.plist
- com.apple.mobile.iTunes.store.plist.lockfile
多分 ll | grep iTunes とかして、関係ありそうなファイルは削除しちゃうのがよさげ。。
※バックアップ忘れずに
au iphone6s を UQ mobile に乗り換えた
au との契約期間はまだまだ残っていたんだけども、解約金を払ってもすぐに回収できるくらい価格差あるなぁーと思って UQ mobile に乗り換えた。
ただ au版iPhone6sについてはまだもうしばらく使う予定なので、simロック解除して使うことにした。
あんまり詰まるところなかったけど、まとめておく。
simロック解除の申し込み
店頭に行かなくても、「auお客さまサポートサイト」から申し込みできる。
simロック解除する場合の注意事項などは下記に載っている。
なお、すぐに解除されるわけではないらしいので、UQMobile申込みより余裕をもってやっておくようにする。
MNP予約番号発行
店頭に行かなくても、電話での発行が可能。
ポイントくれるとか引き止めのお話をされるけど、断ると発行してくれる。
解約月の割引の扱いとか、基本料金に日割りあるのかとか、解約にあたっての料金の話も詳しくしてくれる。
MNPの予約番号には有効期限があるので注意。 番号や有効期限は電話でいわれるので控えたけれど、その後SMSで送ってきてくれた。
UQ Mobileの申し込み
オンラインで完結する。 便利な世の中になったものだ。。
以降はsimが届いた後の手順。
iPhoneのバックアップ
普段から最低限のバックアップはiCloudなりに取ってるけど、念のため直前にもしておく。
回線切替
my UQ mobile から手続きを行う。
初期IDとパスワードは同封された資料に記載されていた。
同資料の手順に従い回線切替を実行する。
simの差し替え
simが届いたら、差し替える。
下記を参考にやった。
なんと差し替えには専用の器具があったとは。。
プロファイルをインストール
iPhone6s用のプロファイルをインストールする。
Safariじゃないとだめっぽい。
ついでにauのプロファイルはもういらないかー、と削除した。
動作確認
Optional#orElseについて勘違いしていた #java
JavaでOptionalの値取り出しにorElseを利用すると思うんだけど、その動きについて勘違いしていた。
Optional<Long> getId();
こんな感じのメソッドがある時、orElseでの値取り出しは下記の用になると思う。
Long id = getId().orElse(createId());
勘違いしてた所
前述の例の場合、createIdはOptionalがnull(empty)の場合にのみ呼ばれると思っていた。
ところが、orElseの処理自体は常に呼ばれるようだ。
イメージでいうと下記のような。
Long id = getId(); if (id == null) { // nullのときだけ呼ばれると思ってたけど、orElseはそうじゃない！！ id = createId(); }
常に呼び出したくない場合はどうするか
例えばcreateIdの処理コストが高かったりする場合は、都度実行することは避けたい。
その場合はorElseGetを使うことで、Optionalがnull(empty)の場合にのみ呼ばれるようになる。
// orElseGetを使う // OptionalがnullのときだけcreateIdが呼ばれる Long id = getId().orElseGet(() -> createId());
気づいたきっかけ
メソッド呼び出し確認のUnitTestを書いているときに気づいた。
Test書くのって大事だなぁと改めて思うなどした。
参考
JJUG CCC 2016 FALL に参加してきた #jjug_ccc
12/3(土)にJJUG CCCに参加してきたので印象に残ったことや感想など。
#ccc_a1 Be a great engineer!
追いかけるべきトレンドを見抜くには、その本質を見極めることが大事という話だった。
結局これが一番おもしろかったかもしれない。
体物知心理の話
体物知心理の話がとても面白かった。
体: 肉体的優位者が勝つ
↓
物: 物量で勝るものが勝つ
↓
知: 情報を駆使するものが勝つ
↓
心: 人々の心を支配したものが勝つ
↓
理: 真理を手にしたものが勝つ
これは後に出てくるものに先に出てくるものは絶対に勝てないって話らしいんだけど、抽象化すると本当に何にでも当てはまるなぁ、と。
特に物と知の間に大きな壁があるなとは強く感じる。
人がいくらいても、お金がいくらあっても、モノがいくらあっても物量では解決できないであろうってことは想像以上にあるんじゃないかと。
本ぞ忘れるな
守破離には「本ぞ忘れるな（教わった基本を忘れるな）」という教えがあるらしい。
これ初めて聞いたんだけど、大切にしたい言葉。
何かを始める時、いきなり全部守ることができないからいくつか妥協することはよくあるけど、それでなまじっか成功体験をすると守もできてないのに破だとか離だとか語りがちな場合も多い気がする。
技術には必ずニーズがある
この言葉は刺さった。
手段と目的の手段が技術であるんだろうけど、その手段は何かのニーズから生まれているはずで、本質を見誤らなければ手段と目的が合致するということではないかなと。
#ccc_c3 日本でも出来る！最先端のDevOpsを導入する方法
非常にエンターテイメント性が高かった。
まさかコールアンドレスポンスをするなんて。。
日本の生産性が低いという話
なぜ、米国と日本で生産性が違うのかという疑問に対して同じValueに対して作業の物量が違うから、という。
前述の体物知心理の話とつながるなぁ、と思って聞いていた。
物量(体)では情報(知)で戦う人に勝てないよなぁと。
この話は確か牛尾さんのブログでも以前出てきた気がしたんだけど、当該記事がパッと見つけられなかった。
simplearchitect.hatenablog.com
#ccc_m2 Clojure を用いた Web アプリケーション開発について
Clojure言語自体は全くさわったことないんだけど、なんでClojureを採用したのかとか、Clojureの特徴なんかが聞けたらいいなと思って参加した。
Clojureを採用した理由
ブランディングや技術マーケティングのために新しい言語を採用したという側面があるらしい。
なるほど確かに、大量採用は別にして、対エンジニア向けということであると、そういう観点もアーキテクチャ選定なんかに含めていくのは大切なことかもしれないなぁと思った。
古い技術を使い続けるリスクなんかも、実は人が集まらない・離れていくリスクが大きいんじゃないかって考えたりする。
これも物量で解決できない問題なのかなと。
ライブラリとフレームワーク
フレームワークを使うんじゃなくて、ライブラリを活用していくという考え方は新鮮だった。
後から知り合いに聞いたところによると、言語の自由度が高いところなんかも影響してるかもしれないとのこと。
#ccc_f6 JVM言語とJava、切っても切れないその関係
www.slideshare.net
Javaという言語にフォーカスされることがあるけど、JavaのエコシステムのコアがJVMだっていうのは印象に残った。
JavaがあってのJVM言語だし、逆もまた然り。
お互いが切磋琢磨して発展していけるといいなぁ、と。
RubyやJSONなど他の言語が乗りたいと思えるほど魅力的な基盤であるJVMはすごいなと思った。
#ccc_c7 Javaエンジニアのキャリアを考えるパネルディスカッション
当初聞く予定はなくて別の予定入れちゃってたんだけど、パネラーが魅力的だったので、途中まで聞いてきた。
フリーランスや起業という選択肢
フリーランスだと、ホントのホントにコアの部分は触らせてもらえない、という話があってなるほどなぁと思った。
技術一本でいくのか
マネージメントなのか技術なのか、って話があんまり好きじゃなくて。
（理想論とは思いつつ）みんながマネージャーで、みんながプレイヤーっていうのがいいなぁ、って思うので。
ロールとしては必要なのは理解してるんだけど、マネージャーとプレーヤーに壁を作るように聞こえることが多いし。
転職のきっかけ
ヨシオリさんが言っていた自分がヘタになるための転職っていうのはすごく共感する（情熱プログラマーも読んだ）。
けど、それで収入とか待遇がどうなるのかっていうのがとてもシビアな問題だよなぁって思う。
最終的なバランスはもちろんあるんだろうけど、やっぱり自分よりすごい人が近くにいるかどうかって大切なこと。
Javaにこだわっていく？
自分としてはJavaにこだわってるといえばこだわってるし、こだわっていないといえばこだわっていない感じ。
一番得意だっていうのと、思い入れ補正もあって好きだし、自分にとって大切な言語なのは間違いない。
まとめ
いろいろな刺激をもらって、何かと考えたりするキッカケをたくさんもらえて楽しかった。
最近迷っていること: メンバーオブジェクトのアクセサを用意すべきか？ #java #プログラミング
最近迷っていること。
クラスのメンバーオブジェクトのアクセサを直接定義するよりは、隠蔽してあげたほうがいいんじゃないかと思うこと。
最終的にケースバイケースだろうとは思いつつ、気にする観点やポリシーなどはまだまだ引き出しが少ない。
直接アクセス可能にする場合
public class Person { private Phone phone; public Phone getPhone(){ return phone; } public void setPhone(Phone phone){ this.phone = phone; } }
隠蔽する場合
public class Person { private Phone phone; public String getPhoneNumber(){ return phone.getNumber(); } public void setPhoneNumber(String number){ phone.setNumber(number); } }
なぜ隠蔽するほうがいいと思ったか
理由1
phone はPersonが持ち主にもかかわらず、外部から直接アクセス可能になることによって、 phone のコントロールを外部に渡してしまうことになるから。
（Effective Javaでオブジェクトじゃなくて Date#getTime() を返せっていうような話もあったような）
理由2
PersonクラスのクライアントがPhoneクラスについて依存することになるから。
ありだな、と思った意見
phone フィールドを protected にするのはよさそう。
