読者です 読者をやめる 読者になる 読者になる

ジョイ・インクを読んだ #JoyInc #ポエム

「ジョイ・インク 役職も部署もない全員主役のマネジメント」を読んだ。

ある意味ぶっ飛んだ会社の話。

突拍子もないいくつもの仕組みが、「なぜ、そうするのか」次々に裏付けされていく。
どういう文化にしたいのか、どう向かっていくのか。

そして終盤、筆者のエモーショナルなメッセージは胸を打つ。

そうだよ、仕事には喜びがなければいけない。

成功が幸福を運んでくるのではない。
幸福になると成功するのだ。

人生の終わりに、「もっと家族との時間を過ごしておけばよかった」なんて思うことがあってはいけない。

喜びを目指そう。
自分を、家族を、仲間を、ユーザーを、喜ばせよう。

明日家を出て仕事に向かう時、思わず口笛を吹いてしまうような喜びを。

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

JavaのStreamで独自ソート #java

sortedにComparator

Streamで独自ソートするにはsortedにComparatorを渡してやればOK

List<Person> personsSortedByName = getPersons().stream()
  .sorted(new Comparator<Person>() {
    @Override
    public int compare(Person person1, Person person2) {
        return person1.getName().compareTo(person2.getName());
    }
  }).collect(Collectors.toList);

Lambdaで書けます

List<Person> personsSortedByName = getPersons().stream()
  .sorted((person1, person2) -> person1.getName().compareTo(person2.getName()))
  .collect(Collectors.toList);

Comparator#comparing が使えます

List<Person> personsSortedByName = getPersons().stream()
  .sorted(Comparator.comparing(Person::getName))
  .collect(Collectors.toList);

逆順にしたい

逆順にしたいときは Comparator#reversed を使えばOKです。

List<Person> personsSortedByName = getPersons().stream()
  .sorted(Comparator.comparing(Person::getName).reversed())
  .collect(Collectors.toList);

参考

www.task-notes.com

SpockでオーバーロードされたメソッドをMockする #spock #groovy

JavaオーバーロードされたメソッドをMockしようとしても、うまくMockできないことがある。
どちらのメソッドを呼べばいいかわからないからだと思う。(たぶん)

下記のようなメソッドをMockしたい場合の対応。

public String doSomething(String arg1)
public String doSomething(String arg1, String arg2)

仮引数を明記する

オーバーロードされたメソッドをMockするには、Closureの仮引数を明記することで、対応可能。

// これだとうまくMockされない
doSomething(*_) >> {'もっくできないー'}

// 仮引数を明記するとうまくいく
doSomething(*_) >> {param1 -> '引数1個の方'}
doSomething(*_) >> {param1, param2 -> '引数2個の方'}

MissingMethodException

なお同じテストメソッド内で、両方のメソッドを呼ぼうとすると MissingMethodException が発生することがある。
※Mockしているのが片方だけであっても発生する

groovy.lang.MissingMethodException: No signature of method

これはMockしている引数を明示すると解決できる。

doSomething(_ as String) >> {param1 -> '引数1個の方'}
doSomething(_ as String, _ as String) >> {param1, param2 -> '引数2個の方'}

参考

hideoku.hatenablog.jp

ORマッパーへの違和感が少し晴れた気がする

前からあった違和感

(リレーショナル)データベースのモデリングドメインモデリングは違うっていうのを前から思っていて、それからDBとドメインのオブジェクトをそのまま結びつけるようなORマッパーにはずっと違和感を覚えていたのだ。

だからMyBatisみたいなSQLマッパー(っていう呼び方が合ってるのかは分からない)の方が好きだったりする。
必要に応じてドメインモデルへの詰め替えをデータアクセスレイヤでやることも抵抗ない。

じゃあその違和感って何だろう

これまでは、「データベースにとっての最適化とドメインモデルは必ずしも一致しないから」っていう表現をしていたんだけど、先日たまたま会社の研修が大きなヒントになって理解が進んだ。

データはそれ自体では意味を持たない

講師の方が「データ」と「情報」という表現をしていて、

データ: それ自体では意味のないもの 情報: データを加工して意味(価値)を持たせたもの

あぁ、なるほどな、と。
データベースのモデリングはデータを扱うもので、ドメインモデルは情報を扱うものなんだな、と。
そりゃあ違うよね、と。

※講義の内容はデータベースに特化したもので、自分の中で勝手につながっただけである

まとめ

実際にはデータベースに全く要件的な(意味のある)要素が入ってこないなんてことはありえないし、システムの規模やフェーズによっては敢えて2つのモデリングを切り離さないという選択もあると思う。
それがORマッパーなのかもしれない。
詳しくないけど、Railsなんかもそうだよね多分。

ただデータ周りを整理や設計する時だったり見直す時、データと情報ってことを意識すると結構役に立つかもしれない。

いずれにせよ、自分の中では割りと大きめなブレークスルーだったかも。

SpringBootのWebAPIでResponseのJSONをPretty Printにする #springboot

SpringBootでWeb APIを作ってる時に、ResponseのJSONをPretty Printにしたくなった時の対応。

やりたいこと

こういうのを

{"hoge":[123,456],"huga":"Yeah!","piyo":{"code":"AA1234","name":"Bob"}}

こういう感じにしたい

{
  "hoge" : [ 123, 456 ],
  "huga" : "Yeah!",
  "piyo" : {
    "code":"AA1234",
    "name":"Bob"
  }
}

結論

ObjectMapperをカスタマイズする。
カスタマイズにはいくつか方法がある。

application.ymlを変更する

spring.jackson.serialization.indent_output=true にすれば、それだけでOK

YAMLだとこんな感じ。

spring:
  jackson:
    serialization:
      indent_output: true

ObjectMapperを自前で用意する

独自Serializer等のために自前でObjectMapperを用意していたりすると、前述の方法は使えない。

Primaryにしている自前のObjectMapperに対して、Pretty Printを有効にしてやる必要がある。

/**
 * 独自ObjectMapper
 */
@Bean
@Primary
public ObjectMapper jsonObjectMapper() {
    ObjectMapper mapper = new ObjectMapper();
    mapper.registerModule(myModule());

    // Pretty Printにする
    mapper.enable(SerializationFeature.INDENT_OUTPUT);
    
    return mapper;
}

独自ObjectMapperを活用しつつ、application.ymlで変更できるようにする

ObjectMapperのカスタマイズ具合にもよるのかもしれないけれど、やっぱり設定ファイルで気軽に変更できるようにしたい。

そういう時はSpringBootを真似してObjectMapperを生成してやるとよさそう。

/**
 * 独自ObjectMapper
 */
@Bean
@Primary
public ObjectMapper jsonObjectMapper(Jackson2ObjectMapperBuilder builder) {
    // Jackson2ObjectMapperBuilderを引数に追加
    // Bootを真似してObjectMapperを生成
    ObjectMapper mapper = builder.createXmlMapper(false).build();
    mapper.registerModule(myModule());
    
    return mapper;
}

こうすると、最初と同じようにapplication.ymlの変更でPretty Printを切り替えられる。

参考

Developers Summit 2017に行ってきた(2日目) #devsumi

デブサミ2日目も行ってきた。 参加したセッションのメモと感じたことなど。

codezine.jp

1日目はこちら。

su-kun1899.hatenablog.com

No-Ops で大量データ処理を簡単に実現する - Google Cloud Platform で実現する次世代データ処理基盤

www.slideshare.net

感じたこと・考えたこと

データ基盤作るのってすごく楽しそうだけど、データは分析して情報になって初めて価値を生むので、直接価値を生むわけではない。
データの世界でエンジニアとして力を発揮したいなら、そこの間を埋めるところ(機械学習なのかAIなのか分からんけど)まで踏み込んでいかないといけないんだろうな。

  • コンテンツに差が無い→UXで差別化→分析が大事→分析にかけられる時間を多くしよう
    • 例えば音楽のストリーミングサービス
    • なるほど
  • なんでも自分たちで作っちゃうGoogleさんかっこよい。。
  • 可視化ツールで最初に出てくるのはやっぱりTableauなのね
  • Google Data Studioはアップを始めた模様?
  • 変なクエリ投げると金額がかなり変わってくるの怖い(今は定額のプランもある?)

Memo

  • No-Ops
    • ユーザのオペレーションが不要という点ではサーバレスに近い
  • なぜデータなのか
    • 音楽ストリーミングが無数にある中で何を選ぶか?
    • コンテンツに差は無い
    • UXで差別化
  • No-Ops
    • 分析に費やす時間を増やす
  • GCPで提供されるサービスのユーザは1Billionを越えた
  • Googleのデータセンターは15箇所
    • GCP用のデータセンターを増やしていく
  • ネットワークが大事
    • ネットワーク機器自作
  • Borg
  • そもそも自分たちで使うために15年以上データの問題に向き合ってきた
    • 論文を発表してOSSにつながっていったり
    • Managed Serviceとして提供したり
  • ビッグデータのライフサイクル
    • 収集→処理→保存→分析
  • 収集
    • Cloud Pub/Sub
    • ストレージが一番多様性がある。どう吸収するか
  • BigQuery
    • フルマネージドDWH
    • SQL使えて高速
    • 必要な列をフルスキャンする
    • 中身はテーブル構造なので、データは構造化する必要がある
  • Dataflow
    • データの構造化する
    • MapReduceだけではひとつの処理しかできない
    • データパイプラインを整理する
    • ストリーミング処理もできるように
  • クラウドプロバイダは成熟してきた
    • コストが下がり、信頼性が増し、様々なサービスが提供されるようになった
    • 物理マシンを所有して運用することは競争優位にならない

コンテナをフル活用した現場

感じたこと・考えたこと

技術スタックの種類をやたらめったら増やすのは反対だけど、柔軟に特性を活かした選択できるのは素晴らしいことだと思う。
Wantedlyすごいなー、マイクロサービスやるための基盤整った(整えた)感じした。

  • 技術スタックを切り離してルール化しているところのバランスがとてもよい
  • モニタリング・ロギングを統一するのマイクロサービスだと大事よね

Memo

  • Wantedlyの目指すところ
    • ビジネスSNSへの進化
  • アプリケーションのルール
    • The Twelve-Factor App
    • Heroku元から使っていた
  • 設定は環境変数で指定
  • ログをファイル出力でなくSTDOUTにする
  • ステートレスな状態にする(データを置かない)
    • 用途の違うプロセスを複数起動させない
      • アプリとnginx一緒のコンテナにしたりはだめ
  • コード化
    • Docker化
    • どの言語でも共通の実行方法にする
      • script/bootstrap, script/server
    • doc/はドキュメント置き場
    • health check => 共通の死活監視洋エンドポイント
    • インフラ操作するものはCLIツールにする
  • リリースまでに時間がかかる
    • Dockerfileをアプリエンジニアが書くのは大変
    • コンテナをサーバに乗せるまでの準備が多い(Monitor, Logging, etc…)
    • Kubernetes導入
      • 「アプリがどこで動いているか」という世界から「どう動いているかだけを意識する」世界へ
      • 変化に強いインフラ
  • モノリシックを避ける
    • 新しくサービスを作る時、コード追加より新規リポジトリ作成の方がよいという雰囲気作り
  • CI/CD共通のルール
  • 共通のダッシュボード
  • CapstranoのdeployからKubanetesのdeployになったので、技術制約が緩和された
  • Kubanetesがアプリケーションエンジニアからすると使いづらかった
    • 自分のアプリだけ操作したいのに。。
    • MicroServicesを支えるMicrtotools
    • ラッパーコマンドを作った
    • Kubanetesの管理サーバーを用意した
  • Kubanetes入れなかったら全部Railsで書かなきゃ行けなかったはず

正しくプロダクトを作り、リリースプランニングするためのプロダクトオーナーの役割とは

感じたこと・考えたこと

そもそもでプロジェクトを成功させるっていうのがスタートラインな中、チーム(とその周辺)の学習と成長を前提にするとプロジェクトが結果うまくいくという考え方は、ともするとプロジェクト成功の優先度が下がったように見える。
その考え方を理解するのは大変だけど、理解しないと前提条件が揃わないので、対立につながりがちだよなぁ、と思うなど。

  • JIRAのレポーティング便利なんだけど、当然何かしらの入力値が必要になる
    • 現場のメンバが必要を感じていないのに、チケットに色々な値を入力することを強制するようなことはしないでほしいなと思う

Memo

  • プロダクトオーナーのお仕事
  • 見積もりはある時点での情報に基づく最良の推測でしか無い
    • 見積もりはコミットメントではない
    • コミットメントにしてしまうと誰も幸せにならない
      • デスマーチ化していく
      • 要員の追加は時間をより遅らせる
      • バッファの肥大化
    • スケジュールを守らないのではなく、最新の見通しを常に共有して、トレードオフを提示するということ
  • 見積もりは規模で行う
    • Velocityで進捗を測る
  • リリース日とスコープが固定されているのはありえない
  • 実績値で予測するから精度が上がる
  • JIRAのレポーティング機能が強力
    • 順調なら、見といて下さい、で済む

まとめ

本当は他にもセッション聞いてるんだけど、パワーが足りない。。
今回もたくさん刺激をまた自分の現場で頑張ろうと思う。

Developers Summit 2017に行ってきた(1日目) #devsumi

今年もデブサミに行ってきた。
一日目に参加したセッションのメモと感じたことなど。

codezine.jp

確実に良くするUX/UI設計

感じたこと・考えたこと

コアコンセプトを決めて一貫性のあるポリシーでプロダクトを磨き上げていくことは大切だなと思った。
検証と学習が軸になるのは、いつでもどこでも変わらない。

  • アプリ開発10箇条いいなぁ
  • 大体うまくいかないときというのは問題が複雑に絡み合ってるから、外部から大きな力を入れるというのは手だよなぁ
  • 実装を進めてからデザインに落とし込むアプローチはよい
  • フォードの話はいろんなところで聞くけど、好きだなぁ
  • コアコンセプトみたいなものを定義していくのは大切だし効果的だと思う
  • バッターボックスに数多く立つの大事
  • サービスとしてのコアが固まったら機能で小細工する必要はないんだよなぁ

リニューアルはどんなに丁寧にやっても何かしら失われる価値がある 構造を整理し矛盾を外し、リリース後に補完していく

「リニューアル」を「何かを変えること」に置き換えるといろんなことに当てはまる気がした。

Memo

  • なぜ大幅リニューアルは失敗しやすいのか?
    • 思いつきでリセットするから
  • ダメPDCA
  • 実生活だと意外とできてる
    • 結婚式のスピーチ
    • 実生活は皆試したがる
      • 車の試乗、ワインの試飲、物件の内覧。。
  • まず軽く試す、ダメなら辞めるか変える
    • 事前調査
    • 複数の実験
    • 利用者テスト
    • 改善
  • 日経電子版リニューアル事例
  • 100徳ナイフを作ろうとしていた
  • コアコンセプトを決める
  • アプリ開発10箇条
  • 事前調査
    • ユーザ調査のコツ:ユーザの発言を無条件に聞かないこと
    • ドクターになる
      • 患者がガンかもしれない、といった時に抗がん剤を投与するのはヤブ医者
    • 「競合が何をやってるか?」ではなく「競合がなぜやっているか?」を調べる
    • 徐々に制度を上げるプロトタイピング
    • 論理構造やレイアウト構造を決めてからデザインを作る
      • 実装→デザインの流れ
  • ユーザテスト
    • 場合によっては強豪のサービスもユーザテストする
    • ユーザーの言ったことより、ユーザーのやったことに注目する
  • リニューアルはどんなに丁寧にやっても何かしら失われる価値がある
    • 構造を整理し矛盾を外し、リリース後に補完していく
  • プロトタイピングの期間は約6ヶ月
  • 試せば必ずよくなる。その時間を惜しんではいけない
    • バッターボックスに数多く立つ
  • 良いコンテンツやビジネスモデルがあれば、機能で小細工する必要ない
    • 検証と吟味を行い、ど真ん中に豪速球を投げるのが重要

Google のインフラ技術から考える理想の DevOps

www.slideshare.net

感じたこと・考えたこと

スペシャリティは必要なんだけども、たしなみとして網羅的なスキルセットは必要なんだと思う。
バランス悪い自覚はある。がんばろう。
あとGoogleやっぱすげぇ。

  • 開発・運用・基盤とチームは分かれていても、スキルセットは同じ。共通言語があるということ。
  • Googleのデータ処理技術すごい。。全部自分たちでやってるんだもんなぁ
  • 難しかったけど、すごいってことは分かった
  • 知識としてのフルスタック。がんばろう。がんばる

Memo

http://www.slideshare.net/enakai/googledevops

  • DevOpsなんぞや
  • Googleにも運用チームはある
    • Site Reliability Engineering
    • 開発者と同じスキルセット+インフラの知識
    • 運用作業は、業務時間の50%以下
      • 他は効率化・改善のためコード開発にあてる
  • 運用は大変。バーンアウトを防ぐ
  • 徹底的に合理的
  • 完全なフルスタックチームは難しい
    • レイヤーごとの責任分界
    • 本質的でない依存関係をなくす
    • インフラ・開発・運用
  • 知識としてはフルスタックを目指そう
  • コンテナは昔から使ってた
    • データをコンテナに保存するのはアンチパターン
    • スケールしづらいし、ポータビリティも落ちる
    • OSレイヤは基盤チームがみる。責任分界
  • GFS
    • データフローとコントロールフローを分ける
  • BorgをOSSとして再実装したものがKubernetes
  • Bigtable
    • アプリケーションエンジニアが基盤を正しく理解して使っている
    • 知識としてのフルスタック

市場で勝ち続けるための品質とテストの技術

感じたこと・考えたこと

LEAN XPすごくよさそうと思った。
体系立ててまとめてる本とかないのかな?

  • 具体的なシナリオ考えるのイメージ湧くのでとてもよい
  • プロダクトマネージャは相当センスが求められる気がする
  • LEAN XPとてもよさそう
  • じゃんけん見積もりいいかも
  • コードの共同所有という考え方、チーム開発だと大事だよね
    • Javadocのauthor、個人的にはいらないと思っている
  • 組織とは何だろうか
    • 何に向き合うかの価値観は組織に対するスタンスが現れる
    • 人と組織もエンジニアリングの範囲だと僕は思う
    • 問題があるなら解決したい

Memo

第一部
  • ヤフオクアプリ
    • ビルド時間の増加
    • 不十分な単体テスト>リードタイム増加
    • 市場で勝ち続けるための品質とテストの技術
  • Pivotal LabでLEAN XPを学んだ
  • ペアプロ
    • 機能とペアを紐付け
    • ペアは片方をDailyで入れ替える
    • 仕様に詳しくなる
    • 技術力の底上げ
  • バックログマネジメント
    • ペルソナからシナリオを抽出、シナリオをストーリー(タスク)に
    • Gherkin format
  • じゃんけん見積もり
  • より小さくより価値の高いもの順に
  • コードカバレッジの罠
第二部
  • テスト自動化
  • まずはユニットテストから
    • 導入がしやすく、効果が高い
  • テスト自動化のピラミッド
  • Cyber Dojo
  • 即実戦で鍛える(プロダクションコードでやる)
  • 体感してから理論を覚える
  • ステークホルダー大杉問題
  • 当たり前のことが当たり前にできないとき、組織に何かしらの問題がある

IoTへのWeb側からの関わりかた

感じたこと・考えたこと

自分の今の関心はあんまりIoTにはないんだなぁ、と思った。

  • 楽しいよ、面白いよ、というのが伝わってるセッション。
  • 興味があったら自分でやってみたらいいよ、ということなのかなと。
  • 具体的な知見もたくさんあってよい

Memo

  • Web系とハード系は大きな違い
    • 開発環境
    • 時間
    • コスト
    • 総じて物理なのでハード系のほうが大変
  • 技術はお金になる
    • 海外からお菓子送られてきた
  • ダイエットの知見
    • 豆腐キムチと豆腐ふりかけチーズ
    • ココナッツオイルダイエット(危険)
    • チアシード
    • もやし炒め
    • 3食ドリンクだけ
  • なぜつくるのか
    • 面白そう、楽しそうだから
  • どう勉強するか
    • Web系とハード系は別々の世界
    • 越えられない山
    • 独力でがんばる
      • 感電するTry&Error
    • コミュニティに参加して知見を得る
  • まず何から始めるか
    • 光るものは正義
    • LEDをチカチカさせる
  • Web/ネット系のノウハウは全く使えない
  • パーツがやたらと多い・やたらと小さい
  • デバッグがひたすら大変: print最強
  • Amazon Dashの衝撃

「ITエンジニアに読んでほしい!技術書・ビジネス書大賞 2017」プレゼン大会

感じたこと・考えたこと

全部読みたくなった。。

  • “凡事徹底と主体性、他人の尊重” その通りかも

Memo

技術書部門
  • ゼロから作るDeep Learning
    • 作る発見
      • 作れないものは理解できない
    • 動かす発見
      • Githubでコード公開しているので手元で試せる
    • 分かる喜び
      • 本質はシンプル
    • 作る経験はコピーできない
  • 暗号技術入門 第3版
    • 中学生でも読める
    • 難しい数式ではなく図表
    • 内容は妥協せず、最新の情報まで扱う
    • 3版でアップデートしている
  • 新装版 達人プログラマー 職人から名匠への道
    • プログラマ有志と編集者によって新装版が発行された
    • 訳文や造本が全体に細かく見直された
    • 時代背景には注意する
    • 他の本と併せて読むと良い
ビジネス書部門
  • なぜ、あなたの仕事は終わらないのか
    • 著者がすごい
      • 学生時代に3億円稼いだ
      • MS辞める時はCEOが直接引き止めに来た
      • ホリエモンが絶賛
    • 著者の時間術
    • 編集者が1ヶ月実践した
      • 10年で初めて仕事を残さずに帰郷した
      • 7年位ほぼ土日も休んでいなかったのに、売上は1.5倍になった
      • 半年の世界一周の度に行く休みを取れるようになる!
    • 要点は選択と集中
      • いかに仕事を減らすか
  • ITエンジニアが覚えておきたい英語動詞30
    • 名詞は実は普段から使っている
    • 米国では海外からのエンジニアが増えている
      • 必ずしも英語が得意なわけではない
      • そういう人たちが使っている英語をまとめた本
    • 英語は動詞が中心、動詞力を高めると表現力が高まる
    • 必要なのはTOEICの高得点ではなく、ミニマムな動詞力
  • 最強の働き方
    • ビジネス書は焼き直しや中身の無いものが多い
    • 最高水準のものを作りたいとの気持ちを込めている
    • 著者は一流のプレーヤーではなかった
    • どんな業界・職種にも当てはまる優先順位の高いものをまとめた
    • 読みやすく思い出しやすい構成にしている
    • 1ページに必ず1ユーモアを入れている
  • まとめ
    • 凡事徹底と主体性、他人の尊重
    • 得意なこと、好きなこと、必要とされることが噛み合えば一生続けられる

まとめ

f:id:su-kun1899:20170216215814p:plain

やりたいこといっぱいあるなぁ、と思ったので、ちゃんとやりたいことに時間を使えるようにしないとなぁ、と思った。
やりたいことはやらなきゃいけないことでもあるのかもしれないけど、やらなきゃいけない、っていう気持ちより、やりたいっていう前向きな感情の方が大きいので、健全になったなぁと思う。
やりたいこととやらなきゃいけないことが一致しているというのは素敵なことだな。

明日も参加予定。楽しみです。