comix

ジャンプみたいなブログになりたい。

コネヒト株式会社の二代目CTOに就任していました

いわゆる退職エントリーというやつです。

この度4月末にSupership株式会社を退職し、6月にコネヒト株式会社の執行役員CTOに就任しました!*1

ちなみに、コネヒト社におけるCTO交代の経緯や意気込みについては以下の記事にまとまってるので、ここではどちらかというとパーソナルな話を書こうと思います。ですので、僕に興味がない人はここで離脱してもらって もっとためになるブログ でも読んでください!

www.wantedly.com

Supershipでの思い出

今回のCTO就任によるプレスリリースや対談記事で、唯一の心残りがお世話になったSupership(nanapi)についてあまり言及出来なかったことなので、最初にSupershipでの話をします。

ちなみにSupershipへの転職エントリーもあるので、ご興味がある方はどうぞ。

itosho525.hatenablog.com

個人的にSupershipで働けたことは、自分のキャリアの中で大きなターニングポイントだったかなと思います。Supershipに入社する前は受託のお仕事が多かったので「リリース≒ゴール」のような感覚が強かったのですが、Supershipに入ってからは180°変わって「リリース≒スタート」という考えをすることが多くなりました。それは日夜オンライン/オフライン問わず、みんながプロダクトについて議論をわいわい交わしていた影響が大きく、「人の生活に彩りを与えられるプロダクトをつくりたい」と思っていた僕にとってそういった環境は正に求めていたものであり、非常に刺激的な毎日でした。

しかし、その中で辛いこともありました。僕は入社後「アンサー」というコミュニティサービスに長く携わっていて、非常にやりがいを持って開発をしていたのですが、最終的にサービスクローズという結果になってしまいました。クローズした理由は様々あったとは言え、サービスを継続させることが出来なかったという事実に対して自分の力不足を痛感したのを昨日のことように思い出します。

その後、コネヒトでは「ママリ」という別の種類ではあるものの同じコミュニティサービスを開発しているのは何か縁かなと思うし、ママリへのモチベーションはいくつかあるのですが、あの時の悔しさと哀しさを二度と味わいたくないというのも原動力の一つになっています。

そういった辛いこともありましたが、その中でもSupershipは優しい人や面白い人が多く、いい意味でプライベートと仕事の線引なく仲良くしてくれて、トータルで考えると本当にたのしく働けたなと思ってます。というわけで、Supershipでお世話になった皆さんには本当に感謝しかありません。ありがとうございました&これからもよろしくお願いします!

次の10年をどう生きるか?

次に今回何故CTOを引き継いだのかという話をします。

最初に紹介した対談記事でも少し触れているのですが、今回CTOの打診を受けた時、ちょうど社会人丸10年で(ソフトウェア)エンジニア歴も10年になったので、次の10年をどう生きるのがよいのだろう?ということを結構真面目に考えていました。嬉しいことにいくつかお声がけもいただいたり、選択肢として起業というのも割とリアルにあったりしました。*2

しかし、そういった選択肢を考える一方で、今の場所でもう少しエンジニアとしてやるべきことがあるのでは?という気持ちやもっとエンジニアとして頑張りたい!という思いが意外にも沸々と湧いて来ました。「意外にも」と書いたのは、自分からこういう感情が生まれてくることが単純に驚きだったからです。と言うのも、僕は元来エンジニアになりたいという気持ちが学生の頃はそこまで大きくはなく、転職活動が上手くいかない中で「ものつくるのは好きだからエンジニアも面白いかもな〜このままだとどこも決まらないから受けてみよう!」ぐらいの気持ちでこの世界に飛び込んだので、エンジニアとしての拘りはあんまりないと思ってました。

もちろん、自分が 10Xプログラマー だとは思わないです(念の為言っておくと、エンジニアである以上そこを目指してます)が、10年エンジニアをやって、いつの間にかエンジニアとしての矜持が自分の中に芽生えていたのは一つの発見であり、今はエンジニアになって心から良かったと思ってます。エンジニア最高〜。

そんなこともあり、次の10年の最初の一歩をエンジニアとして新しいチャレンジをするというのは自分にとって、チャレンジングではあるものの自然な選択なのかと思うし、あとはやはり、コネヒト社の「人の生活になくてはならないものをつくる」というミッションに自分の人生を捧げる価値があると思ったのが大きいかなと考えてます。

CTOはゴールではない

最後にこれからの話を少し。

CTOになってちょうど一ヶ月経ったのですが一ヶ月の感想は、思った以上に目先のことばかりやってるとあっという間に忙殺されるな!という感じです。*3

f:id:itosho525:20190702004700p:plain
よくあるマトリクス

こういうよくあるマトリックスで言うと、CTOは「重要だが緊急ではない」課題に対して、きちんと時間を確保しないといけないんだろうなぁということを改めて感じたので、これからそういう時間を増やしていく所存です。

ですので、そういう課題を考える時間を増やすためにも、自分が組織の中でボトルネックにならないようするためにも業務でコードを書く時間は徐々に減らしていければいいなと考えています。ちなみに、今年のGitHubの草の様子はこんな感じ。

f:id:itosho525:20190704170021p:plain
2019年の草

草の状況から分かるかもしれませんが、4月くらいからそれっぽい仕事が増えてました。

もちろん、いわゆるマネジメント業務が増えるとコードが書けなくなる問題はあり、腕がなまらないようにする必要性は一エンジニアとして感じてます。*4ですが、やはりCTOとしての役割の一つは経営にエンジニアリングの力を反映させて、事業を成長させていくことだと思います。ですので、CTOになる少し前あたりから会計やファイナンス会社法あたりをざっとですが勉強したり、先月から英会話もはじめたりしているのですが、これからはそういうエンジニアリング以外のスキルや知識も伸ばしていかねばと思ってます。

とは言え、CTOになったからと言って、いきなり何でも出来るスーパーマンになれるわけではないので、変に自分を大きくみせることも小さくみせることもせず、粛々と努力していきたいなと考えてます。CTOがエンジニアのキャリアにおける一つのゴールに思われる方もいるかもしれませんが、個人的にはゴールでは全然なくて、コネヒト社の「人の生活になくてはならないものをつくる」というミッションを実現するための新しいスタートだと思ってるので、これからめっちゃ頑張るぞ!

そして、めっちゃ頑張るには仲間がたくさんいると嬉しいので、少しでもコネヒト社に興味がある方は TwitterFacebook からお気軽にお声がけください!

最後に 例のブツ です。

*1:職務経歴上は転職になると思いますが、2年ほど前からSupershipからコネヒトに出向してて、5月に転籍した感じなので働く環境という面では大きな変化はありません。

*2:余談ですが、起業すると社会的信用失いそうだな〜と思ったので、家を買ったのもこの時期。

*3:6月は引き継ぎのなんやかんやもあったのでそれも忙しさの原因の一つではありましたが、思った以上に忙しかった!

*4:元々インディー開発が趣味なので、週末は割と変わらずコードを書いていますが。

『はじめてのPHPプロフェッショナル開発』という本が出版されます

このたび生まれて初めて本を出版することになりました!

『TECHNICAL MASTER はじめてのPHPプロフェッショナル開発 PHP7対応』というタイトル(以下、プロフェッショナル本)で2019年2月26日(火)に秀和システムさんから発売されます。

会社の同僚と書いたので、是非買ってください!(石直球)

しかし「せっかく買ったのに思ってたんと全然違うやんけ!」となるのも申し訳ないので、プロフェッショナル本がどういう本なのか簡単に紹介したいと思います。

プロフェッショナル本の概要

一言で言うと プログラミングの入門書を読み終えた人が、実際の開発現場で活躍するために必要なアレコレをPHPを題材に解説している本 です。ボリュームは実質390ページほどになります。中身は導入編、入門編、実践編、発展編の4つのパートで構成されています。

最初の導入編では昨今のPHPとそれを取り巻くエコシステムを紹介しており、具体的にはPSRやComposer、PHP7の新機能などを解説しています。

入門編ではPHP質問広場というオリジナルのQAサイトを実際に作っていきます。実装以外にもDockerを利用した開発環境構築があり、設計やユニットテストの方法についての解説もあります。ちなみに、Webアプリケーションの開発にはCakePHP(3系)を採用しています。

実践編ではチーム開発にフォーカスを当て、GitHubやSlackの使い方を紹介しつつ、チーム開発でも特に重要なコードレビューについて解説をしています。更に複数人での開発に役立つツールとしてPHP_CodeSnifferとPHPStanの紹介や昨今のトレンドであるコンテナベースのCI/CDについても触れています。

最後の発展編ではPHPの枠を越えて、障害への向き合い方やSQLチューニングの解説に始まり、実際の運用では重要なセキュリティの話にも触れています。また、最後にOSSへのコントリビュートについても簡単に紹介しています。

つまり、めっちゃ盛り沢山な内容になっております!もう少し知りたい方は最後に目次をまとめておきましたのでそちらも併せてご覧ください。

プロフェッショナル本の立ち位置

まえがきでも触れているのですが、プロフェッショナル本は初心者向けの入門書ではありません。かと言って、PHPの文法書やCakePHPの専門書でもありません。

もちろん、PHPの本ではあるのですが、扱っているトピックが多いので、ややもすると「帯に短し襷に長し」という印象を持たれるかもしれません。ただ、そういう印象はある意味間違っておらず、プロフェッショナル本は 入門書は巷に(特にPHPは)溢れているものの、それを読み終えた初心者が実際の現場で活躍するための次に読むべき本がないのでは? という問題意識から企画が始まっています。

ですので、プロフェッショナル本は最新のPHPを学びながら入門書と個別具体的な技術の専門書との架け橋となる本を目指して書きました。

プロフェッショナル本のポジション
プロフェッショナル本のポジション

想定している読者

上述の内容を踏まえつつ、主な読者としては以下のような方をイメージしています。

  • PHPを触っていたが、最新のPHPは知らない人
  • プログラミングはある程度出来るが、Webアプリケーションの開発業務経験が少ない人
  • 昨今の開発現場で多く採用されているツールや開発プロセス、考え方を一通り知りたい人

もちろん、上記以外の方にも是非読んでいただきたいなと思っています。ちなみに、個人的にはPHPer以外の方にも読んでいただけると嬉しいです。

あんまり想定していない読者

逆に以下の人は難しく感じたり、逆に物足りなく感じたりするかもしれません。

  • プログラミング「超」初心者の人
    • 初心者の方でも理解出来るよう工夫はしていますが、フレームワークって何?Gitって何?というレベルだと少し厳しいかもしれません。
  • モダンな開発現場で何不自由なくバリバリ働いている人
    • コードレビューやテストを日常的に行っており、開発プロセスも自動化されているような現場で働いている人は特に得るものがないかもしれません。
  • CakePHPの詳細な解説を求めている人
    • CakePHPを利用してWebアプリケーションの開発を行っていますが、それだけを目当てに読むと説明が浅いと感じるかもしれません。

フィードバックについて

少しでも誰かの役に立てばという気持ちで一生懸命書きましたが、今回技術書の執筆は全員が初めての経験だったので、もしかしたら読み辛い箇所や間違いがあるかもしれません。初めてということに関して言い訳するつもりはないのですが、イケていないところは真摯に受け止めてきちんと改善していきたいと思っています。

ですので、僕のTwitterでもAmazonのレビューでも何でもよいので感想などフィードバックいただけると嬉しいです。また、プロフェッショナル本に掲載されるコードはGitHubにも公開しておりますので、当該リポジトリにIssueやPull Requestを作成していただいても構いません。また、正誤表に関してもリポジトリ内のWikiを随時更新していく予定です。

github.com

目次

最後に目次を紹介します。前述の通り、幅広いトピックを扱っているので気になる章だけ読むことも可能な構成になっています。

一応、僕が担当した章は★マークをつけておきます。

Part01 導入編

Chapter01 進化するPHP

  • 01-01 PHPの歴史
  • 01-02 PHPの特徴

Chapter02 PHPのエコシステム

  • 02-01 モダンなPHPを支えるコミュニティの力
  • 02-02 PHP-FIGとPSR
  • 02-03 PHPのパッケージ管理
  • 02-04 PHPのアプリケーションフレームワーク

Chapter03 PHPをはじめよう

  • 03-01 エディタ
  • 03-02 DockerでPHPの開発環境を整える

Chapter04 モダンPHPの文法と基礎文法

  • 04-01 基本的な構文
  • 04-02 型と演算
  • 04-03 分岐処理
  • 04-04 繰り返し処理
  • 04-05 関数
  • 04-06 PHP7の新機能

Part02 入門編

Chapter05 チームのための開発環境構築

  • 05-01 開発環境のプラットフォーム
  • 05-02 Dockerで開発環境を立てる際のポイント
  • 05-03 実践的なアプリケーション開発のための環境を作る

Chapter06 設計から始める★

  • 06-01 設計の重要性
  • 06-02 要件定義をしよう
  • 06-03 設計時の注意

Chapter07 CakePHPを使ってみよう★

  • 07-01 実装を進める前に
  • 07-02 CakePHPについて
  • 07-03 テーブル設計とURL設計

Chapter08 質問と回答機能の実装★

  • 08-01 質問一覧画面の実装
  • 08-02 質問投稿画面の実装
  • 08-03 質問詳細画面の実装
  • 08-04 回答投稿機能の実装
  • 08-05 質問/回答削除機能の実装
  • 08-06 テーブルクラスの活用
  • 08-07 バリデーションの実装

Chapter09 ユーザー管理機能の実装★

  • 09-01 ユーザー登録画面の実装
  • 09-02 ログイン画面の実装
  • 09-03 ログアウト機能の実装
  • 09-04 その他のユーザー管理画面の実装
  • 09-05 質問/回答機能をユーザー情報と連携する
  • 09-06 機能改善をしてみよう!

Chapter10 テストコードを書く★

  • 10-01 本書で扱うテストについて
  • 10-02 ユニットテストの必要性
  • 10-03 CakePHPにおけるテスト
  • 10-04 テストの準備
  • 10-05 テストコードの書き方を学ぶ
  • 10-06 テストコードはいつ書くべきか?

Part03 実践編

Chapter11 チーム開発の現場★

  • 11-01 個人開発とチーム開発の違い
  • 11-02 GitHubを使った課題の「見える化
  • 11-03 Slackを使った日々のコミュニケーション
  • 11-04 ツールの選定方法

Chapter12 Pull Request駆動によるコードレビュー★

  • 12-01 コードレビューの必要性
  • 12-02 Pull Requestを利用したコードレビューの方法
  • 12-03 コードレビューをしてみよう

Chapter13 開発に役に立つツール

  • 13-01 なぜツールを使うのか
  • 13-02 PHP_CodeSniffer: コーディング規約チェックツール
  • 13-03 PHPStan: コード解析ツール

Chapter14 継続的インテグレーション

Chapter15 デプロイの自動化

  • 15-01 Webアプリケーションの公開
  • 15-02 ソフトウェアのデプロイメントサイクル
  • 15-03 デプロイ自動化のメリット
  • 15-04 コンテナベースのビルド&デプロイ
  • 15-05 コンテナのデプロイサイクル
  • 15-06 コンテナのデプロイを楽にするオーケストレーションツール

Part04 発展編

Chapter16 障害と向き合う

  • 16-01 障害は突然やってくる
  • 16-02 障害についての重要な考え方
  • 16-03 障害と向き合うためのツール

Chapter17 SQLチューニング

  • 17-01 なぜSQLチューニングが必要なのか
  • 17-02 遅いSQLのパターン
  • 17-03 SQLチューニング
  • 17-04 遅いクエリを検出する方法

Chapter18 PHPとセキュリティ

  • 18-01 セキュリティの基礎知識
  • 18-02 SQLインジェクション攻撃
  • 18-03 XSS攻撃(クロスサイトスクリプティング攻撃)
  • 18-04 CSRF攻撃(クロスサイトリクエストフォージェリ攻撃)

Chapter19 外の世界に飛び出そう★

  • 19-01 OSSへの貢献
  • 19-02 最新情報のキャッチアップ
  • 19-03 更にその先へ

最後に

ここまで読んでくれた方は是非買ってください!

(私的)GoのWebAPI開発における現状: 論理編

この記事は?

インディー開発をしたり、本を読んだり、勉強会に参加したりして、GoのWebAPI開発における自分なりの実装パターンが固まってきたので現状を整理します。

具体的にはORM、フレームワーク、パッケージ構成あたりの話。

ある程度アンチパターンを踏んできてますが、僕自身プロダクションレベルでのGo開発経験がバリバリあるわけではないので、ここは間違ってるぞ!とか自分はこうしてる!など(建設的な)マサカリや大歓迎でございます。

tl;dr

前提

WebAPIの規模

以下のような小〜中規模程度のJSONで話すWebAPIを想定。

  • APIの数は20本前後
  • シンプルなCRUDベースのAPIが多いが、ちょっと複雑なリレーションやビジネスロジックも多少あり。
  • 外部システムとの連携は(システム内の)DBがメイン。しかし、Push通知など外部のAPIと連携する箇所も。

ちなみにインディー開発中心なので、ミッションクリティカルなシステムであることは想定してません。とは言え、ある程度の規模までプロダクションレベルに耐えうるものを想定。(と言うより、そこを目指しています…!)

テクノロジースタック

このあたりは好みもあると思いますが、僕は以下の構成でやることが多いです。

  • Alpine Linux
  • NGINX
  • Supervisor
  • Go 1.11系
  • MySQL 5.7系

上記の環境をDockerで作って開発してます。hot reloadの仕組みを入れるために fresh などを使うのはありだと思いますが、僕はIDEとして GoLand を使っており、ファイル保存時に自動でビルドが走るようにしてます。*1

なお、環境というかインフラはAWSやHeroku、VPS想定。GAE/GCPだとDatastoreを使うことが多いと思うので、また違ってきそう。*2

方針

銀の弾丸はないので、何が正しいか正しくないかは状況次第ですが、アーキテクチャやライブラリの選定基準や開発方針としては以下の2つを意識してます。

  • やりすぎない(オーバーエンジニアリングしない)
    • done is better than perfect!
  • 郷(Go)に従う

現状

前置きが長くなりましたが、ここからGo界隈でよく盛り上がるトピック別に現状を書いていきます。

ORM関連

いろいろ使いましたが、最終的に sqlx に落ち着いています。sqlx自体はORMというよりは database/sql パッケージをいい感じに使えるようにしたライブラリ。database/sql パッケージで頑張るのがGoっぽいとは思うのですが、structへのマッピングを自分でやるのは大変なので、メンテもきちんとされているsqlxを使うようになりました。

ActiveRecordに慣れている人は GORM もアリだとは思うのですが…と言うか自分も最初使ってました。しかし、エラーハンドリングが重要なGoの世界観と合わないと思ってるのと便利な分コードが複雑なので、慣れてきたら薄いライブラリを使うのがいいかなと思ってます。

ちなみに、スキーマ管理は schemalexsqldef がおすすめです。MySQLならschemalexが枯れてて安心感があります。

その他の選択肢

  • xoxo
    • DBから直接Goのモデルを生成してくれる便利なやつ。
  • upper/db
    • それでもどうしてもActive Recordっぽいものを使いたい人向け。

フレームワーク関連

いわゆるWAFは使ってません。フレームワークを採用するのも良いと思いますが、個人的には余計なDSLを覚えずに可能な限りGoだけで書きたいので、現状は使ってません。RubyにおけるRailsみたいなデファクトスタンダードとなるフレームワークが誕生すれば、また別かもしれない。

とは言え、全部自前で実装するのはつらいので、ルーティングは Gorilla/Muxミドルウェアnegroni を利用しています。JSONではなくHTMLをレンダリングするような場合だと、これだけだと辛いかもしれませんが、JSON形式のWebAPIならこれで充分かなと思ってます。

その他の選択肢

  • go-json-rest
    • フレームワークと言うよりルーティングとミドルウェアのライブラリ集+JSONがいい感じに扱えるライブラリって感じです。コードも読みやすいので、最初の選択肢としてはアリかなと思ってます。
  • echo
    • フレームワークを使うなら、パフォーマンスが良好&コミュニティも活発なのでこれが一番いいかな〜。 *3 GAE用のドキュメントが分かりやすかったので、GAEを利用する時にも良いかもしれません。

パッケージ構成

個人的にはGoに慣れてきて、一番困るのがこれかなと思ってます。フレームワークを利用していればまだいいのですが、使ってないと自由過ぎて困ります。ですので、これは今も試行錯誤していますが、最近はいわゆる?レイヤードアーキテクチャ+ポートパターンを採用しています。*4

概要図

こういうやつです。

レイヤードアーキテクチャ+ポートパターン
レイヤードアーキテクチャ+ポートパターン

基本的に通常のレイヤードアーキテクチャのように上から下に流れるようにしてる(下位のレイヤは上位のレイヤに依存しない)のですが、ドメインレイヤーにインターフェイス(ポート)を置くことで、ドメインレイヤだけどこにも依存しないようにしてます。

なお、破線部分については後述します。

フォルダ構成

こんな感じでやってます。

.
├── Gopkg.lock
├── Gopkg.toml
├── application
│   ├── article.go
│   └── user.go
├── config
├── domain
│   ├── article.go
│   └── user.go
├── infrastructure
│   ├── db.go
│   ├── article.go
│   └── user.go
├── main.go
├── presentation
│   ├── controller
│   │   ├── handler.go
│   │   ├── article.go
│   │   └── user.go
│   └── view
│       └── render.go
└── vendor

各レイヤの責務

僕がよく使うRailsCakePHPのようなMVCモデルと比較しながら説明していきます。

プレゼンテーション層

MVCで言うコントローラーとビューにあたる箇所。コントローラーの責務はリクエストを受け取り、それをアプリケーションレイヤで利用出来る形にしてアプリケーションレイヤを操作すること。そして、その結果を(ビューと連携して)レンダリングすること。ここは極力コード量が少なくなるように意識しています。ビューの責務はレンダリングに関すること全般。ただ、JSON形式のWebAPIだとコントローラー側でJSONを出力するだけで事足りることが多いので、あんまり書かないことが多いかも。僕は汎用的なレンダリングのロジックだけ書くことが多いです。

アプリケーションレイヤ

いわゆるサービスクラスっぽい役割をする箇所。アプリケーションレイヤの責務はドメインレイヤとインフラストラクチャレイヤのビジネスロジックを操作すること。ちなみに、DBのトランザクションはここで制御しています。

ドメインレイヤ

みんな大好きモデルを扱う箇所。ドメインレイヤの責務はビジネスロジックの実装を持つことですが、技術的な実装(直接的なDBの操作やPush通知の送信など)は行ってません。また、先述の通り通常のレイヤードアーキテクチャとは異なり、ドメインレイヤとインフラストラクチャレイヤとの間にインターフェイスを設け、技術と実装を分離するようにしています。DBのモデル(struct)はここで定義していますが、インフラストラクチャレイヤで DTO を定義することもあります。*5

インフラストラクチャレイヤ

技術的な実装を扱う箇所。インフラストラクチャレイヤの責務は直接的なDB操作(SQLの実行)やPush通知の送信など技術的な実装を行うこと。通常のレイヤードアーキテクチャでは、インフラストラクチャレイヤはどこのレイヤにも依存しませんが、技術と実装を分離するために必要に応じてドメインレイヤのインターフェイスに依存させています。

オレオレルール

  • 厳密なレイヤードアーキテクチャでは直下のレイヤにのみ依存すると思うのですが、2個下のレイヤに依存するのはある程度OKにしています。
    • これが上記概要図の破線の意味です。
    • 理想は直下のレイヤにのみ依存させるのがベストだと思うのですが、現実問題として厳密にやりすぎると辛いときがあるのである程度は許容してます。
      • ただ、3個下は流石にダメ!(明らかに責務を越えてる)

なぜレイヤードアーキテクチャを採用しているのか?

個人的にはGoで小〜中規模のWebAPIを開発する時にクリーンアーキテクチャはちょっとtoo muchかなと思っています。*6 とは言え、薄いライブラリしか使っていないとMVCモデルでは少し辛いケースが多く、また、テスト観点から技術と実装を分離したくなることが多いので、このようなアーキテクチャにしています。ですので、逆に言うと、フルスタックなフレームワークやORMを使っている場合はMVC(+サービスクラス的なもの)で充分なケースも多いと思います。また、テスト観点だけであれば、インフラストラクチャレイヤがDBのみの場合は、インターフェイスを置かず通常のレイヤードアーキテクチャでもいいかなと思ってます。もちろん、単体テスト時のDBアクセスは低速でアンチパターンですが、RailsCakePHPをこれまで使ってきた身からすると、そこまで違和感ないので。

その他の選択肢

  • 縦割りパッケージ構成
    • レイヤではなく、機能で分けるパターン。具体的にはuser packageやarticle packageを作るパターン。
    • microservies化を想定しているならアリかなと思います。
    • Goっぽいなと思いつつ、個人的には共通処理の扱いが難しいなと思ってます。

パッケージ管理ツール

Go1.12から vgo が正式導入されますが、3rd partyの対応状況を鑑みると、まだ(2019年1月現在)は dep が無難かなと思います。とは言え、今後はvgoを使うのが主流になっていくはず。

最後に

書いてみて、コードがないと分かりづらい気がしたので次はコード編を書いてみたい。その時は今回書けなかったログとかエラーハンドリングのことも書くぞ。

あと、冒頭にも述べましたが、Goは導入事例が増えてきたとは言え、RubyJavaに比べると枯れておらず、ベストプラクティスがそこまで世に出回っていないので、自分なりの考えや現状を書くことで誰かのためになったり、議論のきっかけになったりすればいいなと思ってます。*7

2019年もGoGo!

参考サイト

脚注

*1:単純にMakefike経由でビルドしているだけ。

*2:『Clean Architecture 達人に学ぶソフトウェアの構造と設計』でも言及されている通り、技術的な実装に引っ張られないアーキテクチャが本当は理想なのでしょうが…。

*3:ただ、フレームワークはそんなにたくさんは試していないので、他にもっと良い選択肢があるかもしれない。

*4:この用語は『pospomeのサーバサイドアーキテクチャ』を参考にしています。

*5:このあたりは現在進行系で悩み中です…リポジトリパターンやDAOをどうやって使うとか…難しい…。

*6:もちろん開発するプロダクトや個人/チームのスキルにも依るとは思います。

*7:翻って、そこからまた自分が成長出来ればいいなとこっそりと思ってます。

2018 Retrospective

みんなが2018年の振り返りをやっているので、僕もやってみよう。

どうでもいいけど、昔はみんながやってることはあんまりやらないタイプだったのに、最近流行っているものをやっていないと、自分の感性や感覚がズレて来てるんじゃないか?と思って不安になる。知らんけど。

2018年のよかったこと

  • 7回登壇することができた!
  • Podcastに初めて出演した!
    • 恥ずかしくてまだ自分では聴いていないけど、何人かの人によかったよと言ってもらえたのでよかった! takattata.github.io
  • 南山大学公開講座が最高of最高だった!
  • 30冊ぐらい本を読めた!
    • 今年は読書を習慣付けるために1スプリント(2週間)に1冊本を読むというのにトライしたけど、波はありつつ数はクリア出来たのでよかったかな。

突然の2018年読んで良かった本ベスト3

第3位: 『プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化』

第2位: 『NETFLIXの最強人事戦略 自由と責任の文化を築く』

第1位: 『ナナメの夕暮れ』

2018年のわるかったこと

  • あんまり技術的な挑戦が出来なかった…
    • 特に後半はとあるプロジェクト(これはもうすぐお話出来るのでもう少し待ってけろ!)で忙殺されて、成長実感が関西人くらい薄味。あかん。
    • Gopher道場に参加したりGoでインディー開発をしたりしたぐらいかなぁ。
  • インディー開発のリリースが1つだけだった…
    • しかもチームのやつだけなので、個人では何も出せなかった!これまたあかん。
    • というわけで年末年始は早速インディーやってます。
  • 相変わらず英語を学んでいない…
    • 先月あたりにflamingoデビューしたけど継続していない。まじであかん。
    • 石原さとみさん!僕に英語を!教えて!
  • 海外旅行に行けなかった…
  • というか今年は国内もあんまり行けなかった!お金を貯めないと〜!
  • 来年は海外のカンファレンス行きがてら、観光とかしたい。

【番外編】2018年のプライベートなこと

  • 凄い勢いでBリーグにハマっています🏀
  • 引っ越しが決まりました!

2019年の目標

  • 大きなカンファレンスで登壇(出来るような成果を出す)
  • 英語の技術書をスラスラ読めるようになる
  • インディー開発2本以上リリース
  • 本を最低でも12冊以上読む
  • 引っ越しを無事終える

全体的な抱負で言うと、今年は手広くいろんなことに手を出し過ぎた感もあるので、 来年は少しわがままをテーマに自分が本当にやりたいことだけをやっていきたい! (仕事はちゃんとやるという前提)

ひとこと

今年も大変お世話になりました〜。来年も再来年もよろしくお願いします!

南山大学人間関係研究センターの公開講座に行ったら最高の体験学習が出来た

f:id:itosho525:20181124014917j:plain

はじめに

5億年振りにブログを書くぞ。

今年に入ってから、スクラムマスターをやらせてもらったり、ここ最近はエンジニアリングマネージャーのお仕事をしたりしている。そういう役割を任されるうちに、会議のファシリテーターや1on1のメンターをする機会が増え、組織開発って面白いかもと思い始めた。

しかし、自分の力不足を痛感することも多く、会議に参加している人やチームメンバーに対して、コスト(時間)に見合った価値を提供出来ていないのでは?と思っていた。

そんな中、ヘイシャの人事部長からこんな情報をもらった。

こりゃ行くしかねぇ!って言うか、課題を感じているのに放置するのとかクソダサいし、チームメンバーに対して無責任だし、飛ばねぇ豚はただの豚じゃんかっこわる!と一念発起し、先週末受講してきたので、今回はそのレポートを書きたいと思う。

ちなみに、組織開発と聞くと仰々しいイメージがあるかもしれませんが、普段の仕事をする上でもとても役に立つ講座だったので、エンジニアの方にもめっちゃオススメです。

南山大学人間関係研究センターとは?

僕は組織開発の専門家ではないので、詳細な説明は公式のHPをご覧いただければと思いますが、ラボラトリー方式(自分や他者、グループを成長させるために行動を試みる場)の体験学習という"プロセスから学ぶ学習方法"の研究と実践を行っている教育研究機関です。

その中で、いくつかの公開講座が行われており、今回僕は「人間関係講座(グループ)」という講座を受けました。

ちなみに、恥ずかしながら僕は受けるまで全然知らなかったのですが、南山大学はこの分野で国内トップクラスの権威があるそうです。

どういう講座なのか?

「人間関係講座(グループ)」という名前の通り、グループの中での人間関係について学んでいく講座になります。もう一つ「人間関係講座(コミュニケーション)」という似たような名前の講座があるのですが、こちらはグループよりももう少し小さい単位(1〜2人程度)での人間関係を学ぶ講座のようです(こちらも今度受けてみたいな〜と思った)。

講座の主な目的(学習目標)として…

  1. グループの中で他者と関わる自分の特徴に気づく
  2. コンテント」と「プロセス」とは何かを理解する
  3. グループの中での人間関係(グループプロセス)に目を向ける重要性に気づく

の3つが挙げられています。

こちらも詳しくは公式の講座案内をご覧ください。

当日の講座内容について

講座は土曜日・日曜日の2日間行われます。具体的には、

  1. グループを組んで様々な課題に取り組む
  2. その振り返りをグループで行う

という流れを繰り返しながら、進んでいきます。実習やワークショップばかりではなく、所々小講座という形で理論的の話もしてもらえます。朝から夕方までみっちりやるので、とても濃密です。

学んだこと

メモレベルですが、僕はこんなことを学びました(間違っていたらごめんなさい)。

  • グループで何らかの仕事や課題に取り組むと、どうしても課題の内容そのものに夢中になってしまう。
    • 課題の内容そのもののことをコンテントと呼ぶ。
  • コンテントに夢中になると、他者の気持ちやお互いの関係に目が向けられない。
    • 他者の気持ちやお互いの関係のことをプロセスと呼ぶ。
  • コンテントは氷山の一角で、プロセスはコンテントの下に潜んでいる。
  • プロセスが上手くいかないと、グループのコミュニケーションがうまくいかず、コンテントの結果にも影響する。
    • コンテントが上手くいかないと、プロセスのチェックも疎かになり、悪循環に陥るなと思った。
  • プロセスにはタスク・プロセスとメンテナンス・プロセスの2種類がある。
    • タスク・プロセスはコンテントに直接働きかけるもの。
      • 例: 時間管理、目的や手順の明確化、アイディアをまとめるetc
      • 比較的観測可能。
    • メンテナンス・プロセスはコンテントに間接的に働きかけるもの。
      • 例: 雰囲気、関係性、個々人の様子etc
      • 目に見えないものが多い。
  • 「売上は全てを癒す」という言葉は、コンテントが上手く言っているとプロセスに多少問題があっても気にならなくなることなのかなと思った。
    • でも本当に全てを癒しているのかは怪しいなとも思った。
  • リーダーとリーダーシップは違う
  • リーダーシップとは、コンテントを達成するための過程で、影響を与えている人と受けている人の関係性のこと。
  • リーダーシップはタスクプロセスの中に位置づけられている。
  • リーダーシップにはP機能とM機能がある
    • P機能は情報や意見を求めたり、課題を推進したりといったコンテントに直接働きかけるもの。
    • M機能は雰囲気を和ませたり、励ましたりといったメンテナンス・プロセスを改善するもの。
  • 両方出来る人がいればそれはそれで素晴らしいが、人には得意不得意があるので、グループでリーダーシップの役割分担をするのが良い。
    • 分有型リーダーシップという言うらしい。
    • サーヴァント型リーダーシップはGoodだが、カントリークラブマネジメントはBad。
  • 実際にフィードバックを受けないと、相手の気持ちなんか分からない。

当然ですが、これ以外にもたくさんの学びがありました。

感想

というツイートを終わった直後にしたのですが、本当に最高でした。とにかく実習が多いので、知識が体に取り込まれる感じというか、体で学んでる感覚がありました。

特に僕は振り返りの重要性を改めて感じました。仕事では今もそれなりに振り返りに力を入れていると思っていたけど、どちらかと言うと、タスク・プロセスの改善ばかりやっていたなという反省があり、これからはもっとメンテナンス・プロセスにも目を向けていこうと思いました。そして、そのためには、もっと個人からの個人へのフィードバックをしていかないといけないなぁと痛感。他人の分かった気になってる状況ほど厄介なものはない。

あと、全国津々浦々から様々なバックグラウンドを持った方が集まって来ているので、そういう人たちと触れ合えるのも単純にとても刺激がありました。もっと外に出ていかないと。

ただ、めっちゃ疲れるので、そこだけは予めご注意ください。

でも、とても心地よい疲れだったな。

ちなみに、僕がよく言われたこと

何度もフィードバックを受ける機会があるので、自分の特性を改めて認識したり、発見したりすることも出来ました。初対面の人からも普段よく言われることを言われると、本当そうなんだろうな〜と認めざるを得ない。というわけで、僕がよく言われたことを晒してみます。

  • 最後まで諦めない
  • 落ち着いている
  • ムードメーカー
  • 裏のリーダー
  • フラットに物事をみてる

耳障りの良い言葉が多いですが、それは初対面という関係性の中で言ってもらったことなので、ある程度忖度してもらっていると思います。長所と短所は表裏一体だと思うし、上記の特性も場合によってはマイナスに作用することもあると思うので、気をつけよう。

おわりに

というわけで、本当にオススメです!最後にお金を話をするのもアレですが、これが1万円ちょっとで受けられるのは本当にお得だなと思いました。人それぞれ感想は違うかもしれませんが、少なくとも受けて損はないと僕は言い切れます。

あと、受ける前にこちらの本を読んでおくと、講座の内容がより理解しやすいと思います(これも上述の人事部長に教えていただいた)。

ちなみに、受けるとこんな修了証をもらえます。

f:id:itosho525:20181124014922j:plain

【翻訳版】Docker, Inc is Dead

What's this?

Docker, Inc is Dead の翻訳記事です。

ご本人の許可は取っていますが、僕が英語ペラペラではないため、読み辛いのはもちろん、一生懸命訳してはいますが誤訳・ミスリードなどあるかもしれません。

ですので、100%正確な内容を把握したい方は原文をお読みください。また、ここ間違ってるよ!ニュアンスが違うんじゃない?などありましたらお気軽に(優しく)コメントいただけると幸いです。

Docker, Inc is Dead / Docker社は死んだ

Dockerにとって、2017年は非常に辛い1年だったと言っても過言ではありません。Uberを除いて、より活用され、賞賛され、十分に資金提供を受けたシリコンバレーのスタートアップの中で、Dockerが2017年に行ったような悪手を打ったスタートアップは思い浮かびません。人々は2017年を、ソフトウェアの偉大な一部分であるDockerが悪いビジネスのやり方によって台無しにされ、翌年に終わりを迎えた1年だったと振り返ることでしょう。この記事はDockerがどのようにして良くない方向に進んでしまったか、そして、それを修正しようとする努力があまりにも少なくまた手遅れであった様子を外部から見た回顧録です。

Docker is Good Software / Dockerは良いソフトウェアである

言うまでもなく、Dockerはソフトウェア開発に革命をもたらしました。cgroupsや名前空間、そしてプロセス分離などのLinuxのプリミティブな技術を利用して、それらを単一のツールにまとめたのは素晴らしい功績です。2012年に私は開発環境のポータビリティをより高める方法を見つけようとしていました。Dockerの登場により、開発環境はシンプルでバージョン管理可能なDockerfileになりました。Dockerfileにより PackerやVagrant、そしてVirtualBoxなどのたくさんのインフラツールからDockerに移行しました。DockerのUIは実際かなりよいものです!Dockerはたくさんの応用が出来る良いツールです。Dockerを作った人々は、自分たちが開発したツールをとても誇りに思うべきです。

Docker is a Silicon Valley Darling / Dockerはシリコンバレーの寵児である

Dockerの初期の成功はそれを取り巻く大きなコミュニティを築く会社になることに繋がりました。その初期の成功は資金調達に次ぐ資金調達を促しました。Goldman SachsやGreylock Partners、Sequoia Capital、そして、Insight Venture Partnersのような名立たる投資家がDockerに札束を与えるために列をなしました。現在まで、Dockerは総額2億4,200万ドルから2億5,000万ドル以上の資金を調達しています。

しかし、資金が十分にあり、何が何でも勝とうとしていた2010 年代のスタートアップと同様に、Dockerはいくつかの人事的なミスを犯しました。Dockerは自身の成長にともなって何人かの不快な人を保護しました。これにより私はDocker社のリーダーシップに対して、嫌悪感を感じるようになりました。プロダクトは品質を維持していますが、会社のそのような振る舞いは一切言い訳出来ません。悲しいことに、これはシリコンバレーによくあるケースであり、変えていく必要があります。

Kubernetes Dealt Damage to Docker / Kubernetesの扱いがDockerにダメージを与えた

Kubernetesの登場により、Dockerの運命(悲運)は加速しました。Dockerはオープンソースコミュニティで人気のオーケストレーションツールであるKubernetesの扱いが上手くありませんでした。Dockerが認めたオーケストレーションツールは、自身が持つ(Kubernetesの)競合製品であるDocker Swarmだけでした。この決定はKubernetesが最初にDockerコンテナを好んでいたのにも関わらず下されました。非公式な情報では、Docker Captains は、2017年初頭にKubernetes関連の記事やミートアップ、そして、カンファレンスがDockerによって批判されたことを確認しています。

オースティンでのdockercon17はこの Kubernetes-less を信念にして開催されました。その後、dockercon EU 17では突如DockerはKubernetesに全力を尽くすことを決めました。この突然の変化は、Kubernetesが盛り上がり間もなく優勢になろうというところに参画することを狙ったものでした。これはKubeConとCloudNativeCon North America 2017のスポンサーとブースを持っていたことによって、更に心象を悪化させました。

Moby?

Mobyが発表された4月のdockercon17で、Dockerが何をしているのか誰も理解出来ませんでした。MobyはDockerプロジェクトの新しい上流のものとして説明されています。しかし、Mobyの公開は事前にアナウンスされていませんでした。Solomon Hykesのdockercon17での発表を受けて、GithubでDockerからMobyへのドラスティックな変更が起きたとき、何百万の声が恐怖で叫んだかのようでした。このドラスティックで思慮の浅い考えにより、巨大なリポジトリの名前変更は内部で問題を引き起こし、Githubスタッフによる手動での対応を必要としました。

変更がうまく管理されなかっただけでなく、メッセージも十分に考慮されていませんでした。これは謝罪に繋がり、後に手書きによる変更の説明を求められました。これは既に雲行きが怪しいコンテナ分野とDocker(Moby?)のエコシステムを更に混乱させました。Moby公開の扱いはこの業界で働く人々を困惑させ続けています。これによりDockerブランドが傷つけられた可能性もあります。

The Cold Embrace of Kubernetes / Kubernetesの冷めた受け入れ

Dockerの遅く、気まずい土壇場でのKubernetesの受け入れは、差し迫った崩壊のサインです。Docker Swarmが死んだかどうか尋ねられ時、Solomon Hykesは以下のようにツイートしています。 "DockerはKubernetesとSwarmの両方をファーストクラスの市民として手厚くサポートし、相互作用を与えます。オープンさと選択は全ての人にとって健全なエコシステムをつくりだします。" ここでの問題は、Docker Swarmは完全に出来上がっているわけではないので、そのような状況からは程遠いということです。Docker Swarmのプロダクトチームと一握りのオープンソースのコントリビューターだけではKubernetesのコミュニティに追いつくことが出来ません。DockerのUIと同様にKubernetes UIはかなり優れています。これはコンテナ分野において、Dockerが取るに足りないコンサルティング会社であることを認めているようなものです。

Conclusion / 結論

Dockerの真の問題は一貫したリーダーシップの欠如にあります。組織の中で一人の人物を中心にした戦略的なフォーカスがあったようです。この人物は会社の中核からはかなり遠のきましたが、依然として籍を置いています。会社は再編成を行い、エンタプライズにフォーカスすることになりました。この変化はDockerの投資家にとって理解できるものです(結局会社は信託の責任を負っています)。しかし、この変化は熱狂的な成功によってもたらされたブランドが持つクールな要素を減らすことになります。"偉大な文明は殺されるのではなく、自殺するのだ。"と言われますが、Dockerはまさにそれと同じことをしました。

Bonus: Conspiracy Theory / おまけ:陰謀論

私はTwitterで2017年というDockerの厄介な時期について持論を展開しました。Dockerは自身の会社の終わりが近いことを知っている可能性があります。組織の変更により、Exit予定(買収による可能性が高い)が明らかになり、会社の技術的な中核チームはいくつかの変更を優先しました。CNCF(訳注:Cloud Native Computing Foundationのこと)に containerd に寄贈し、MobyをDockerの上流にして、Kubernetesを受け入れることで、Dockerの人々が行った良い仕事は不朽のものになります。これにより、Dockerの従業員によってなされた技術的な進歩がライセンスによるロックを心配することなく、 OracleMicrosoftのような大規模な会社がDockerを買収することが出来るようになります。これはソフトウェアと企業に両方にとって、ベストな世界です。言うまでもなく、2018年はDockerにとって興味深い年になるでしょう。

Eureka English Evening に参加してきました

f:id:itosho525:20170828002941j:plain

はじめに

先日、Eureka English Eveningというイベントに行ってきました!ブログ枠で参加させていただいたので、当日の様子を簡単ではありますがレポートさせていただきます。

どういうイベントなの?

詳細は下記のconpassのページをご覧いただければと思いますが、端的に言うと、Eurekaさんが企画している技術英語を学ぶための勉強会で、今回はコードレビューがメインのお題でした。

eure.connpass.com

当日の流れ

Presentation

最初はコードレビューで役に立つ単語やフレーズの紹介をしてもらいました。PR(Pull Request)のコードがOKな時、NGな時などシチュエーション別に説明してもらったので分かりやすかったです。

ただ、実はちょっと遅刻してしまったので、最初のほうは聴けていません…。ごめんなさい。

Practice

続いては実践編ということで、練習問題用のPull Requestをグループに分かれて、それを英語でレビューするというグループワークをやりました!5問ほどあり、書いたことのない言語のコードもあったので、英語以前の問題もあったのですが、とても勉強になりました!

※ちなみに事前に英語力のアンケートをとっており、適切にグループ分けをしてもらっているので安心でした。

Performance

少し休憩を挟んだ後、最後は会話練習ということで、再度グループワークでYES / NOゲームを行いました。 お題が定番の動物からプログラミング言語Java, PHP, Ruby, Pythonなど)、OS(iOS, Windows, Linux, Androidなど)など多岐に渡り、面白かったです。

感想

英語系の勉強会は初めて参加したのですが、とても愉しく勉強になりました!よくある技術系の勉強会だと実際に参加しなくても、後からスライドをみればある程度事足りることも多いのですが、やはりワークショップ系の勉強会は実際に参加しないと学べないことがたくさんあるので、そういう意味でも参加して良かったです。

ただ、自分の英語力の低さを痛感しました(一緒にグループワークをした方にはご迷惑をお掛けしたかと思います…)。個人的にはOSSにコントリビュートしたり、OSSを公開したりする際に英語力が必須になるので、そういったことがもっと出来るようになりたいという想いが今回参加したモチベーションの一つだったのですが、もっともっと英語を勉強しなくてはと気持ちを新たにすることが出来ました。頑張るぞ〜。

素敵な機会を与えていただいたいEurekaさん、本当にありがとうございました!第2回目があればまた是非参加させていただきたいと思います!

当日の資料

www.slideshare.net

2016年をフリカエル

あけましておめでとうございます。今年もやらしくお願いします。 そういえば、去年の振り返りをしていなかったので今日は勝手に思い出話に花を咲かせたいと思います。

1月

仕事の引き継ぎでめっちゃ忙しかった記憶。確か最終日までデプロイしてましたね。

本当にお世話になりました!

2月

というわけで、6年近くお世話になった会社を辞めて、転職しました。

itosho525.hatenablog.com

もうすぐ1年経つので振り返り等はその時書きたいと思いますが、いまのところ愉しく働いています。

あ!あと、ディズニーのミラコスタに初めて行きました。お金貯めてまた行きたい。

3月

正確には2月ですが、うるう日限定のWebサービス PRESENT4229 をリニューアルしました。 2012年に初めてつくって、2016年が2度目の運用だったのですが、予想遥かに越える反応をいただいて、本当につくってよかったなと思いました。引き続き4年後(もう3年後)をお楽しみに。

リニューアルの顛末はこちら。

speakerdeck.com

4月

結婚式の準備でめっちゃ忙しかった。徹夜で動画編集しまくってた。 この頃はIntelliJ製品(RubyMine&PhpStromを愛用している)よりAdobe製品を触っている時間の方が長かったな〜。

5月

30歳になった!

パワプロ2016を買ってもらって未だにマイライフやっています。

6月

結婚式を挙げました。

準備とか色々大変だったけど、やってよかったなーと思います。 YDDしながら夫婦仲良くやっています。

YDDについてはこちら。

speakerdeck.com

7月

結婚式の燃え尽き症候群で全く何もしていない。

8月

伊藤直也さんの一人CTO Nightのレポートがめっちゃバズった。書いてよかった〜(こなみかん)

itosho525.hatenablog.com

あとは乃木坂ちゃんのライブに行ったりしてました。

9月

北海道に行ったり、ディズニーシーに行ったり。 東京以外なら札幌に住みたいという思いを強くした。

10月

会社の仲間と Kocoromo というAndroidアプリをつくりました。 (僕はサーバーサイド担当)

iOSはもうしばらくお待ちください。

そして、Mr.Childrenの武道館公演を観に行ったのですが、まさかの最前列でした。 後世にまで語り継ぎたい一生の思い出。

あと、開発合宿にも行った!

rei19.hatenablog.com (一緒に行った会社の仲間のブログを拝借)

11月

PHPカンファレンスにスタッフとして参加しました。 基調講演の司会をするという「貴重」な機会をいただきました。

来年は発表したい!

12月

箱根の温泉でのんびりして、一年の疲れをとりました。

感想&今年の抱負

プライベートではやっぱり結婚式が一番の思い出かな〜。正直当日ってあっという間に終わっちゃうんだけど、それまでの準備が何だかんだ楽しかったし、妻との絆も深まったように思う。

エンジニアとしてはその瞬間その瞬間では全然何もやってねー!って感じで結構焦りを感じたり、ダメだな〜なんて思ったりしてたのですが、こう振り返ってみるとまぁまぁ頑張ったような。 でも、やりたいことの半分も出来ていないので、今年はもっともっと頑張りたいな。

というわけで、今年も来年こんな風に振り返り出来るように平和に元気にたのしく暮らしたいです。