ikeike443のブログ

ソフトウェアビジネスに関心がある系のブログ

GitHub Actions について3連トークします

ご縁があって、デベロッパーサミット、CI/CD Test Night、Jaws Daysの3ミートアップ/カンファレンスでGitHub Actionsについてトークさせてもらうことになりました!

event.shoeisha.jp

testnight.connpass.com

jawsdays2019.jaws-ug.jp

よろしくお願いします!

最近読んだ本

『サルたちの狂宴』というFacebook内幕暴露本を読んだ。ザッカーバーグ含め登場人物が全員実名で出てくるわけで、Facebookの当時の実情が垣間見えて面白いです。

ですがこの本はFacebookの暴露本というよりも、むしろ作者のシリコンバレーでの奮闘記といった趣の方が強く、ある種の青春小説的にも読めます。当初ウォール街でクォンツをやっていた作者が一念発起して西海岸に移住、はやりのイケイケベンチャーに転職するも失敗、そこで知り合ったプログラマーを引き抜いて自分のベンチャーを立ち上げ、Yコンビネータで資金調達し、という話です。最近はシリコンバレー景気も陰りが見え始めていますが、この本はまだまだ元気だったシリコンバレーの活気を生に感じていた作者の体験をそのまま書いているので、読んでいて非常に生々しく、楽しめます。

Facebookの話が出てくるのは後半で、紆余曲折あってベンチャーを売却してからFacebookに転職し、Facebook Exchangeを開発することになった話に入ってからです。Facebook Exchangeもなかなか意欲的な広告プロダクトだったと思うんですが、結局終了してしまいましたね。この本を読んでているとあれがどうしてうまくいかなく、結局閉じる羽目になったのかがなんとなく分かる気がしてきます。

単なる暴露本というよりも、シリコンバレー青春活劇、みたいなノリで読めるのでおすすめです。ちなみに原書のタイトルは "Chaos Monkeys" で、ナードならニヤッとくるタイトル。

サルたちの狂宴 上 ーーシリコンバレー修業篇

サルたちの狂宴 上 ーーシリコンバレー修業篇

サルたちの狂宴 下 ――フェイスブック乱闘篇

サルたちの狂宴 下 ――フェイスブック乱闘篇

その『サルたちの狂宴』の中で紹介されていたので読んだのが『フラッシュボーイズ』。今度映画化するらしいですね。これもノンフィクションですが、一昔話題というか問題になった、超高速取引の実態が分かります。コロケーションとかいって取引所のすぐそばにサーバを置かせるサービスなどを今でも証券会社は堂々と売ってますが、それが何を意味していたのかがよく分かります。この本はそんな超高速取引の実態に一人対抗し、公平な取引所の開設を目指した人の話です。ブラッドカツヤマさんという日系カナダ人のかたですね。

forbesjapan.com

ただ、超高速取引も最近はうまくいかなくなったようで、回線の速度を利用してさや抜きするようなことはだんだん下火になるのかもしれません。

jp.wsj.com

最後は『教養のグローバルヒストリー』という本で、これは単に世界史の教科書を読みやすく書き直したものなのですが、一貫して陸上および海上ネットワークの歴史として世界史を捉え直しているところがユニークで、モンゴル帝国によるユーラシア大陸統一が陸上ネットワークによる東西連結を達成し、ヨーロッパの発展を促したこと、それによってヨーロッパが発展したことで海上ネットワークがユーラシアとアフリカ、アメリカ大陸をつなぐことに成功し、一気にグローバル化が加速して現代に至っていること、などがざっくり分かります。

入門監視をいただきました

翻訳者の松浦さんとは職場が実は同じなのですが、彼から掲題の書籍をいただきましたー。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

自分みたいな監視の素人にとってはすごく読みやすく、理解のしやすい本だったと思います。作者の方はなかなか自身のご意見をお持ちの方で、一貫した思想でもって全体が書かれているので単なるハウツーものにならず、一貫した考え方を学べます。作者のNagiosに対するツンデレ感も見所です。

ツールの使い方や設定の仕方みたいな説明はほぼなく、監視とは何か、何を考慮しどう構築すべきか、という内容の本です。若干我々の書いた『チーム開発実践入門』に通じるものがあり、この作者とは仲良くなれそうだなと思いました。 世の中の技術書はハウツーものがちょっと多すぎるように感じているので、この本のように一段上のメタな視点で書かれたものがもっと増えるとうれしいなと思います。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

WASEDA NEO で講座を持つことになりました

とある縁で、早稲田大学が社会人向けに運営しているWASEDA NEOというスクールにて講座を持つことになりました。

エンジニアではない一般のビジネスパーソンの方に、ソフトウェアエンジニアが実践しているドキュメント管理、バージョン管理、タスク管理のノウハウを紹介し、実践的に学んでもらうという講座です。メールとExcelで案件管理をしていて何がなんだかわからなくなってしまっているような方にとって役に立つ内容になっています。

ワークショップ形式で実践的な内容にするべく準備中です。受講者の方の現場での悩み事も取り入れながらダイナミックに授業ができればともくろんでいます。

毎週火曜日朝7時20分開始、全5回で27000円という価格になっています。下記に内容説明がありますので、皆さんの周りの非エンジニアの方でご興味がありそうな方がいればぜひ紹介してください。

wasedaneo.jp

Peatixから申し込むことも可能のようです。

184b15.peatix.com

ソフトウェアエンジニアが普通に行っていることが一般のビジネスパーソンにも広まれば、社会全体の効率化にもなりますし、いい効果を生むのではないかと思って活動しております!

よろしくおねがいします。

マイクロソフトに行ってきた

写真はレドモンドにあるマイクロソフト本社の31番ビルディング

去年の話になりますが、11月にMicrosoftにてDevOps関連のSE*1を集めたミートアップ兼トレーニングイベントがあるから、GitHubからも何人か選抜して参加してみてよ、というオファーがMSからあったようで、私もAPACの代表として選抜されて行ってきました。ちなみにGitHubからは全部で10名のSEが参加しましたが、MSからは総勢50名ほどでした。MS内でもかなり絞って人を選抜していたようです。ちなみにMS Japanからも一名いらしていました。

内容については細かいことはここでは書けないんだけど、逆にそんなに秘密にするようなこともなくて、世界各国に散らばるAzureDevOpsのSE代表に対して最新機能の紹介と、AzureDevOpsを売る際のノウハウを共有するみたいな場でした。我々GitHubは特別ゲストとして招かれた格好で、特段AzureDevOpsを売るように言われているわけではないです。

MicrosoftはDevOpsに関しては現在一生懸命キャッチアップしているところという印象がありました。ただ流石にエンタープライズに強いだけあって、AzureDevOpsという製品は、権限周りやADとの連携などエンタープライズでは求められる機能への目配せはされている印象ですね。製品としては悪くないので、Azureを中心に据えるような構成を考えているのであれば良い選択肢ではないでしょうか。Repoの出来は正直良くないので、そこはGitHubにしたほうがいいとは思うけど。これはポジショントークと取られてもしょうがないけど、そうではなくて、イチ開発者としてマジにそう思います。

セッションの中では、世界各国のSEが実際に現場で苦労していることを直接そのセッションを担当しているプロダクトマネージャー(が多かった)に対してフィードバックするケースが多く、非常に勉強になったのも事実です。この分野ではMicrosoftさんはまだまだ新参なので、非常に苦労しているようですが、参加している人たちはみな前向きで、いい印象を受けました。

参加者の中にはXamarinでNat*2と一緒にMSに参加した人もいて、MSはすごくいい会社だよ、と強調していたのも印象に残りました。確かに、10年前まであった非常にEvilな印象というのはだいぶ薄れてきたのかなーとは感じます。実際そのイベントに集まっていた人たちは、選抜された人たちということもあるでしょうが、非常に頭がよく前向きでまたいい意味で従来のMSとは印象が違う人が多かったように思います。

思えば、Herokuもあのセールスフォースに買収されてずいぶん経つけれどもサービスとしてのHerokuがなにか劇的に変わったということはなく、でもゆるくセールスフォースファミリーの一員であるという事実があるなあと。Herokuはアイディアをすぐ形にしてデプロイできるプラットフォームとして、当初は何かを作り出したい個人や、スタートアップをメイン顧客に発展していたわけですが、大企業であるセールスフォースに買収されたあとも変にエンタープライズっぽくなることなく、うまく運営しているなと思います。GitHubMicrosoftもそんな関係になるんじゃないかなと思っています。

GitHubもHerokuも、Google Apps (G Suite) やSlack, そしてもちろんAWSなどのその他様々なSaaS, PaaS, IaaSは皆2005〜2009年位の間に一斉に世に出てきて、スタートアップやアーリーアダプター(日本だとWeb系企業とか)が取り入れて成長していったわけだけど、そんなアーリーアダプターたちも10年経ってみんなそれなりの規模のエンタープライズになっているわけで。段々と、これらイケてるツールを作っていた僕らも、使っていたみなさんも年を取り、社会に対して負う責任も大きくなり、小さなスタートアップだった会社も何千人、何万人と抱える大企業になってきたこの10年。だんだん製品に求められる機能だったり、会社/業界に必要な人材だったりというのも様変わりしてきたのかなということを感じます。

かつて、IBMやオラクル、SAP、MS(!?)といったプロプライエタリな企業が業界を引っ張っていた時代があって、それを支えていたエンジニアたちがいた時代が80年から90年代だったとすると、GitHubやHeroku, Slackみたいなツールは2000年代から登場した比較的新しいツールで、新しいコンセプトで社会や企業のあり方を大きく変えてきたわけですが、かつての世代がその後下の世代から見て、あらゆる角度で硬直していったかのように見えたのと同じように、僕ら2000年代の世代も気づかずにそういう扱いになるのでは、みたいなことを最近感じることがあります。

Microsoftは社内でYammer*3やTeamsといった自社製ソーシャルメディアチックなツールを使っているわけですが、MSの規模でこれらのツールを全社規模で運用しているというのがすごい。MSはグローバルで何万人と社員がいるわけですが、全員Teamsでルックアップして、メッセージのやり取りができるというのはちょっと衝撃的でもありました。「うちは1万人近くいる大企業だからこういうツールはなじまないんだ」みたいなことを言う方は洋の東西を問わずいらっしゃいますが、MSができるんだから、取り組んだほうがいいのでは、とも思います。

ただ、MSの規模だと、Slackみたいなゆるいツール(そこがいいのですが)では管理しきれないのも納得できて、この規模で効果的に運用して、ソーシャルメディア的なパワー(社員がみな自律的にコラボレーションするパワー的な?)を引き出すには、ちょっと違う次元の機能が必要なんだなということがよくわかりました。

GitHubも私が入社した300人足らずの頃と今とでは規模が違うわけで、段々今までとは違うレベルの悩みがでてくるだろうし、会社の文化も作っていかないと行けないんだろうなということを感じます。同世代の企業たちも、Slackを始めとして今年続々IPOするという噂が流れています。また足元ではそもそもこのシリコンバレーバブルがそろそろ弾けるんじゃないか感が感じられる昨今です。そろそろ次のフェーズなのかもしれません。

今日のブログは特にオチはないですがこのへんで。

シアトルに行ったので、アーロンとエビちゃんに会ってきました。ブラジル料理を食べましたが、美味しかったです。アーロンは翌日に日本語検定試験を受けるとかで、若干ナーバスになってたようでしたが、付き合ってくれてありがとう。

*1:Solutions Engineerの略で、他社だとセールスエンジニアと呼んだり、AWSだとSolutions Architectとか呼んだりする職種です(MSでは呼び名は様々あって一様ではない)

*2:Nat Friedmanは元XamarinのCEOで、今年からGitHubの新しいCEOになりました

*3:YammerもMSに買収されていたことをみんな覚えているだろうか

Cloud-infra audio ポッドキャストに出ました

知り合いの中丸くんの紹介で、ポッドキャストに出てきました。

『Track-27 Github 池田さんはソリューションエンジニア』のメモ – cloudinfra-audio

GitHubのソリューションエンジニアとしてやってることとか、日本市場の状況とか、GitHub AppsやGitHub Actionsの話、などなどしています。 ただ僕に脱線グセがあるせいか、話がそれまくりました。パッケージソフト開発をやってたときのブランチングの話とかもしてます。

当日は風邪をひいていて、かなりの鼻声ですが。。咳き込みまくってたのにポッドキャストでは咳が入ってないことに驚きました。編集の力すごい!

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

GitHubツールビルディング ―GitHub APIを活用したワークフローの拡張とカスタマイズ

GitHubツールビルディング ―GitHub APIを活用したワークフローの拡張とカスタマイズ

ChatOps関連のメモ

最近SlackのCTOが日本で取材を受けたりして下記のようなコメントをして話題になりましたね。 f:id:ikeike443:20171217163031p:plain www.businessinsider.jp

僕もメールはゴキブリみたいなもんだってのには同意なんだけど、それとは全然関係なく、Slackの存在感が増すにつれ最近のChatOps事情が気になったのでちょっと調べてみた。これはその備忘。

ChatOps

ChatOpsってのは多分、一応GitHubが最初にいい出したもののような気がする、わからないけど。ChatOpsの象徴であるHubotは2011年にOSSになってます。

hubot.github.com

チャットボットを使って便利に楽しく仕事しようぜ、っていうコンセプトですね。日本でも世界中でもHubotの上にいろんなアプリが作られたと思う。 でもチャットボットって今やHubotだけじゃなくいろんなやり方で作れるのね。

Slack Bot

Slackそれ自体に、Botフレームワークがあります。Events APIってのをリッスンして、いろいろおもしろいことをやれるようになってる。 例えば、チャンネル上の誰かの発言をひたすらオウム返しするボットなら、Slackの設定画面でリスナーのURLをまず下記ページを見て設定した上で、 https://api.slack.com/events-api#subscriptions

下記のようにEvents APIをリッスンするサーバを書けばいい。(Sinatra使ってます)

post '/listen_to' do
  params = JSON.parse request.body.read
  return params['challenge'] if params.has_key?('challenge') #Botの最初のセットアップ時に必要なレスポンス
  return if params['event'].has_key?('bot_id') #自分自身にオウム返しをしないようにチェックしてる
  return if params['event']['text'].start_with?("/") #スラッシュコマンドを除外

  uri = URI.parse("https://slack.com/api/chat.postMessage")
  request = Net::HTTP::Post.new(uri)
  request.content_type = "application/json"
  request.add_field("Authorization", "Bearer <TOKEN>") 
  request.body = JSON.dump({
    "channel" => params['event']['channel'],
    "text" => params['event']['text']
  })

  req_options = {
    use_ssl: uri.scheme == "https",
  }

  response = Net::HTTP.start(uri.hostname, uri.port, req_options) do |http|
    http.request(request)
  end
end

適当なコードなのは勘弁してほしいけど、EventをリッスンしてPOSTメッセージをSlackから受け取ったら、その内容をそのままSlackのchat.postMessageというAPIを使って返すだけ。かんたん。 今までずっとHubotを通してSlackボットを作ってたので、Slack自体にBotフレームワークがあることに気づいたのは最近です。

ちなみに備忘だけど、Hubotを使ってSlackと連携する際には下記のフレームワークを使うと楽です。

slackapi.github.io

DialogFlow

チャットボットを作ろうと思ったら、やっぱり近頃流行りの人工知能的なアレをやりたいよね。昔懐かしの人工無能でもいいんだけど、ともあれ。 Googleapi.aiを買収して、カンバンのつけかえをしたDialogFlowを使うのがやはりストレートでしょうか。これ系で今Googleに勝てるプラットフォームはないと思う‥ちなみに5月にGoogleI/Oに行ったときにもこれをいじって遊んだ。日本語にも一応対応しているのがポイント高い。

GUIでポチポチ会話のパターンみたいなのを入れておくと、いい感じに喋ってくれます。バックエンドで機械学習してくれるみたいで、だんだん賢くなるのではないかと期待させる。機械学習と言われるとなんでもできるように感じさせるマジック!

dialogflow.com

実はDialogFlowにSlack連携があるの知ってました?

DialogFlow -> Slack

DialogFlowで作ったIntentをSlackに連携するボタンがあって、それを押してSlack側で認証してあげると、Slack内でDialogFlowがボットとして会話の相手をしてくれます。 f:id:ikeike443:20171217165436p:plain

先程のオウム返しSlackボット(Slack API Tester)と同じ部屋で会話してやるとこんな感じになる。 f:id:ikeike443:20171217165811p:plain DialogFlowBotさん、Slackボットのことは無視するのね。

HubotにもDialogFlowとのIntegrationがあるといいね。

DialogFlow -> Google Home

DialogFlowで作ったIntentはGoogle HomeのActionとして使える。さっき見せたDialogFlowのIntegration画面にGoogle Assistantというのがあるから、そのボタンを押して支持に従うと、Google Homeを通してDialogFlowと会話ができる。 Google HomeのテストもWebで簡単にできるように作られてていい感じ。 f:id:ikeike443:20171217170428p:plain

Probot

ところでGitHubは最近、Hubotの延長となるOSSプロジェクトを始めていて、GitHub.comにGitHub Appsとしてインストールして、BotにIssueの掃除をさせたり、何かアラートを出させたり、ってことができるようにしている。 Probotっていうんだけど、意外と日本では知られてないので、一応ここで言及しておきます。

probot.github.io

GitHub Enterpriseでもいずれ使えるようにするんじゃないかなーと思う。 ProbotもDialogFlowやGoogleHomeと連携できると楽しいよね。

結論

は特にないんだけど、ただのメモだから。 まあ思ったのは、HubotやProbotとDialogFlowのインテグレーションをイケてる感じに作れると、Google Homeを通してデプロイを指示したり、GitHubにたまってるIssueを整理したり、今週のTODOを確認したり、できそう。Pull Request上でProbotに何か指摘されて、そのコンテキストをSlackに持ち込んでBotと会話して問題解決するとか、その結果をGoogle Homeを通して音声で受け取るとか、色々やれそうだよね。

どのデバイス、プラットフォームから話しかけても、適切なコンテキストを適切に引き回して、仕事をサポートしてくれるといいなあ。Google Homeに話しかけて仕事をスタートして、その同じコンテキストを前提にしてSlackで会話し、GitHub Issue上で会話し、みたいにできると楽だなあ。