ワクチン接種の翌日は安静に過ごそう
スタートから全力ダッシュしすぎるとすぐに息切れするし、昨日は新型コロナワクチンを接種したばかりなので、今日は家で静かにまったりと過ごしました。激しい運動はせず、ガッツリとした勉強もせず、趣味の時間を多めに取るように。趣味の時間ばかりに時間を使っていると「何か勉強しなくて大丈夫かな？」と自分の中の真面目成分が不安になるかもしれないが、そうなったら勉強して自分を安心させればいい。そんな感じにゆるいスタートを切って、今後のロングランに備えるのでした。
新型コロナワクチン接種
ワシはモデルナ製のワクチンを打ちました。注射を打つときの痛みはほとんどなく、打ち終わって15分ほどの待機時間も特に何も変わらず。接種後1,2時間経ってから、あ、少し注射を打ったあたりが少し痛いかも、という感じでした。
その日の夜は、注射を打った側の手をあげる時に痛みで腕が上がりきらず。翌朝は腕がズーンとした感触だった。翌日はなんとなく微熱がある感覚だったので、家で大人しくしておいて良い判断だったと思う。腕を上げない限りは注射を打った箇所は痛くない。
TODO管理の補足
昨日はTODOリストの洗い出しを、カテゴリ分けしながら洗い出すところまでしか書いてなかったので、もっとこういうこともしてますよ、というのを残しておく。
- TODOの洗い出し
- とにかくどんなものも色々洗い出しておく
- （昨日書いたのはココまで）
- 優先順位をつける
- 今回は必須（MUST）のマーキングをしただけ、マークなしのものは「努力目標」
- 必須マークを付けたものは、期限を設定する
- マークなしのものは、放っておくとゼロ実施で終わってしまうので、毎週空きができそうな日にテキトーにプロットして実行してみる
これからさらに、モノによっては細かいステップにブレイクダウンして、ブレイクダウンしたものに期限を付けて管理していく。という、どこにでもありそうなTODO管理ですな。
今日やったこと
- ラジオで英会話のリスニング練習やる（毎週の習慣）
- 「エンジニアの知的生産術」を読了
- 読んだ本のサマリまとめをやった
- PS4の『人喰い大鷲のトリコ』をクリアした
- 壮大で不思議なな世界観の珍しいアクションゲーム。大鷲トリコの優しさに感動する
- 「15時間以内でクリア」のトロフィーもらえた
小さなことでも日々Outputする習慣を
現職の最終出社日を終え、次の職場に入社するまで有給消化の期間に入った。
新型コロナ禍の今の御時世では、旅行に行ったりフラフラと出回ることもはばかられる。かといって、家でひたすらゴロゴロして昼夜逆転な生活をしていたら、社会復帰できないダメ人間になってしまう懸念がある。なので、何かこういう時にしかやれないようなことや、やっておきたいことを決めて、ある程度まっとうな生活を維持継続しつつ、あわよくば身辺を整頓したりスキルアップをしてしまうのはどうだろうかと思った。
つまりはテーマを決めて、読書や勉強をしたり、プログラムをひたすら書いたり、身体を動かして健康を維持したり、ちゃんと趣味の時間を持ったり、メリハリのある生活をしてみよう大作戦というヤツですな。
やることの洗い出し
まずはやることを洗い出します。カテゴリ分けするとこんな感じに
- 現職のまとめ
- 身の回りの整理
- 趣味
- スキルアップ
- 新職場に向けての準備
現職のまとめ
現職で知識経験として得たものを振り返り整理することで、自分の武器を再認識する活動。
- ex. 体系的に知識をまとめる
- ex. 知識経験のマインドマップ化
身の回りの整理
多忙な日々を過ごしていると、ついついそれを言い訳に山積してしまう物事を解消して、スッキリした状態にする活動。
- ex. 未読メールを読み切る
- ex. 旧Macbookを売却する
趣味
凡人のワシには、意識の高い活動だけをストイックに続けるのは難しいので、自分の楽しみに時間を使ってリラックス＆ストレス解消する活動。
- ex. 「人喰い大鷲のトリコ」クリアする
スキルアップ
（直接的に次の職場に活きるとは限らないが）自身のスキルアップにつながる活動。
- ex. 登録セキスペの年間講習をやる
- ex. 書籍を読む（具体的な書籍を列挙）
- ex. あとで読む、を読み切る（具体的なWebSiteを列挙）
新職場に向けての準備
次の職場に行く前にやっておきたい未習得な技術や、家での仕事環境を整える活動。
なぜブログに書くか
何かを習得するというインプットの活動は、アウトプットしてみないと着実に身についたという検証ができない。また、インプットばかりしていてアウトプットする癖を忘れてしまうと、アウトプットできない身体になってしまいそう。なので、どんなに些細なことでもいい、それこそ駄文の日記でも構わないので、これからの1ヶ月間の活動を日々アウトプットすることで、アウトプットするトレーニングも継続的に行おうと思った次第。
何を書いたらいいだろうか
まぁ、ブログなんで好きなことを書けばいい、という結論はあるのですが、三日坊主常習犯である自分に継続させるためにはハードルをとにかく下げるのが大事だよな、と。
- 日記的な内容
- その日、思ったこと、感じたこと、知ったこと
- やったこと
- TODO管理的な内容
- TODOの消化状況を記録
ブログという形でアウトプットを記録することで、達成した内容の見える化、達成感の実感、（この超不定期更新ブログは誰も見てないと思うけど）誰かに見られているというプレッシャーを自分にかける、みたいな効果が生まれることを狙っている。雑とはいえアウトプットしようとすると少なからず「まとめよう」という気持ちが働くと思うので、インプットしたことの整理にもつながると思う。
今日やったこと
- 新型コロナの職域接種（1回目）を実施した。特に副反応なく一安心
- 2回目の接種予約も完了
- 先日折りたたみ傘が壊れたので、新しい折りたたみ傘を購入した
- 古本で を買った
- BOOK-OFFアプリを入れてみた。オンライン会員とでログイン／ポイント同期できた。
- この期間にやりたいことを書き出してEvernoteタスクに登録した
- 未読メールを減らした 400 -> 239(!)
今日思ったこと
- 朝イチでブルブルマシンに乗りながら読書をしたら、読書時間も稼げるし、朝起きの習慣につながるか？
- www.lifehacker.jp
- 朝からジョギングとかやれる気がしないし、これくらいの実現可能で実益もあるようなあたりが丁度いいかな
- 小さいことでも日々アウトプットする習慣を...はてなブログ書くか（この記事につながる）
- 未読メールの整理、あとでじっくり見るかも、と保留して結局見ないパターン多し。今見たら即判断して削除できる
- 定期的に見直して消していけば、ここまで山積せずにすむのに、なんでできないかなぁ
GitHub Japan Constellation Tokyo 2018 〜Day 2 Developers in Business〜
2018/06/13 (水)
9:00 - 17:00 JST
公式サイト：https://githubsatellite.com/
参加申し込み：https://peatix.com/event/366939
ライブストリーミング：https://githubsatellite.com/live-stream/
Twitter HashTag： #GitHubSatelliteTokyo
体調崩したり、ドタバタしていてUPが遅くなってしまい、鮮度も何もあったもんじゃないですが、記録残しておきますー
基調講演：GitHub Enterpriseプロダクトビジョン
公家 尊裕 (GitHub) ジェイソン・ワーナー (GitHub)
（冒頭はDay1と同じ話）
Tokyo向けに作ったロゴ。富士山、東京タワー、桜。桜はブランチを表現。
GitHub上の成長率
- 中国・インドと並んで、日本はTop Growing Countryのひとつ
日本国内IoT市場
- 2017年：6.2兆円
- 電力はスマートメーターへの切り替えが行われている
- 電力自由化後に電気会社を切り替えると、そのタイミングで機器交換される
- エネルギーの利用状況から、生活上の利用傾向分析・推測ができる
- 集めたデータをどう解析して、どんなサービスに還元していくか、がビジネスの勝利につながる
- 2022年：12.5兆円（IDCの予測）
- 2017-2022：14.9% CAGR
日本国内コグニティブ／AIシステム市場
- 2017年：274億円
- 2022年：2947億円（IDC予想）
- 2017-2022：60.7% CAGR
- ソフトウェアの勝負
- 欧米では開発者の奪い合い
- 自動的にエンジニアの給料も上がる（お約束はしませんが）笑
- 欧米では開発者の奪い合い
2030年 IT人材不足
- 79万人（経済産業省）
- 毎年、４〜５万人が不足する計算
- これから若者を育て続けても、間に合う気がしない
- 頑張る？（残業する？）→ 事実上無理
- ツールを使って効率的に開発を進める
- 世界中の色んなエンジニアを集めて、グローバルなチームを作る
- 上記、2. 3. のMix
- GitHubは、4.のアプローチを取っている
GitHub Enterprise
- 日本の企業ユーザの95%が、Enterpriseを利用
- （ここで弊社ロゴ・キター！！）
ジェイソン・ワーナー
Every company is an innovation company
- not software company
- 単なるソフトウェア会社ではイノベーションは起こせない
- 優秀なソフトウェア会社とは？
- 難しい課題のバランスが取れる会社
- セキュリティ
- スケール
- アダプション
- インテグレーション
GitHubの責任
- データ侵害を防ぐ
- コンプライアンスに準拠しつつイノベーションを促進させる
- オープンソースコミュニティへのサポート
- Tokenの漏えい等は自動的に防げたらどうだろうか？
- こういった機能でGitHubは協力できる
- Tokenの漏えい等は自動的に防げたらどうだろうか？
コード革命 → クラウド2.0革命
- Pull Request
- ネットワークエフェクト
- GitHubは統合の支援、ワークフローの管理も支援できる
GitHubがお手伝いできること
- テクノロジーを組織の中でデプロイしやすくする
- 最高の人材を集める
ウェイン・ジン
これから我々がやってくことの紹介
- 4つの投資エリア
- プラットフォーム
- データ
- いかにセキュリティを確保するか
- エコシステム
- いかに拡張していくか
- 開発者
- デベロッパーをなるべく生産性の高い状態にする
プラットフォーム
データ
エコシステム
- GitHubはバージョンコントロールシステムだと思われていた
- コミュニケーション／コラボレーションのツールへと拡大していった
- 今は、マーケットプレイスがあり、サードパーティーの必要なフィーチャーを得ることができる
- アイデア
- コード
- ビルド
- デプロイ
開発者
- GitHubは開発者のためのサービスである
- 開発者の生産性を最大限にする
所感
出だし基調講演はDay1と同じ内容なのかとゲンナリしかけたが、エンタープライズ向けのビジョンや機能の表明により、日本国内は特にGHE比率が高いこともあり、より一層力を入れていくことが感じられた。
ゲスト基調講演：DMM.comのGitHub EnterpriseとCircleCI の活用方法
唐沢 陽介 (株式会社DMM.comラボ)
少ない人員でどうやって生産性を確保しているか？を紹介する。
GHEの構築から運用まで関わっている
- CircleCIの導入・サポートも
- CircleCI1.0を2.0への移行支援
今日話すこと
- （表題）のこと
- GHE導入して1年経って思うこと
GHEの活用状況
- 40くらいの提供サービスのうち、比較的新し目のサービスでGHEの採用が進んでいる
- ほかは、AtlassianのBitbucket（クラウド版）を使っている
- なぜミックス？
- 環境改善チームでBitbucketを試験運用していたら、どんどん現場が相乗りしてきた
- みんな本当はGitHubを使いたかった
- 本気でGHEを導入する検討を始めた
- 4つのサービスが稼働中
- GHE
- CircleCI
- ZenHub Enterprise
- SideCIオンプレミス
社内でおすすめしている利用パターン
- Gitのブランチモデル
- 基本は自由だが、相談が来たらシンプルな２つを紹介する
- Git Flow（簡易版）
- feature / develop / master だけ
- GitHub Flow
- master ブランチへのマージは検証環境へデプロイ
- Tagを打つと、本番環境へデプロイ
- CircleCIのうまい使い方
- ビルド＋インスペクション＋デプロイを実施している
- 素早いフィードバックを得るために
- Docker Executorをつかう
- Cacheを使う
- ダウンロードしたファイルはキャッシュする
- ビルドに必要なライブラリをダウンロードするが、毎回ダウンロードではなく、次回以降は使い回す
save_cache:とrestore_cache:
- Worlflowを使う
- 自動テストと静的解析を並列化する
- テストは全部やるが、静的解析は一部（別条件）など
- 自動テストと静的解析を並列化する
- Machine Executorは非推奨としている
- オンプレ版だと非推奨としている
- ビルドのたびに裏でEC2インスタンスが立ち上がる
- 2分以上必ず待たされる、遅い
- 起動数の変更にサービスの再起動が必要で運用が難しい
- CircleCIですばやくフィードバックループを回す
- 速度を意識していないとすぐに遅くなる
- 少しの工夫で高速化できる
- 困ったらGHEで検索する
jobs ruby filename:config.ymlで言語ごとのビルドジョブ定義を社内で探してベストプラクティスを横展開できる
- ドキュメントはGitHub Pagesで
- GHE → CircleCIビルド → GitHub Pages
- ZenHub Enterpriseで進捗の可視化
- GitHubの中だけで開発業務が回るようになった
導入して1年
- 新規サービスではGHEとCircleCIの採用が進む
- 利用者はサーバやユーザ管理が不要で、すぐにCIを始められる
- .circleci/config.yml でアプリケーションの動作要件が分かる
- 既存プロジェクトも移行できるところから移行
- 悩んでいること
- 対策として個人的にやっていること
- 良いリポジトリを見つけたらスターを付ける
- 少しずつ、この文化が広がってくれれば良い
所感
DockerコンテナベースのCIツールとの連携など、弊社と似たステージにいる認識。すべての既存プロダクトを移行できていなかったり、諸々の課題についても似てより、参考にできるところは取り入れていきたい、リザーブドインスタンスとか。。。
ゲスト基調講演/パネルディスカッション：ソフトウェア開発の変遷と、これから
モデレーター 及川 卓也 (フリーランス技術アドバイザー) 大倉 香織 (株式会社サイバーエージェント) 小林 篤 (株式会社ディー・エヌ・エー) 松野 徳大 (LINE株式会社)
GitHubの10年を踏まえ、今後の10年をうらなう
軸となるテーマ
- 一番進化を感じる技術は？
- 事前に登場や進化を予測していなかった技術は？
- 逆に期待はずれだった技術は？
及川：Git前とGit後で社内の開発は変わったか？ 小林：開発者間のコミュニケーションが多くなった 松野：手元で1回コミットしておけるので、途中の作業を保存しやすくなった。途中からカフェに移動して作業したり、とか。メンバーも分散して作業できるのが嬉しい。 及川：コミュニケーションでいうと、SlackとGitHubをペアで使っているところが多い？ 大倉：GitHubを先に入れたが、Slackに更新を通知させたりして現在は活用している 小林：Chatbotとして「安藤さん」を作って利用している（記事あり）
及川：言語のトレンドとして何が増えて何が減った？ 松野：perlとJavaで開発していた会社が一緒になったのだが、最近はJavaが主流。PythonとJavascriptも増えてきた。Swift/Kotlinもスマホ向けに利用している。 小林：Rubyやgo-lang。最近だとJavaが増えてきている。 及川：最近、Javaが増えた、というのは面白いがなぜ？ 小林：人が増えてくるにつれて、新しい人も理解しやすい意味で、型があったり、キッチリした言語にしようか、という話が出てきた。 大倉：ここ最近はgoが多いが、従来はJavaが多かった。
及川：言語採用はどうしている？ 松野：若い人はperlをあまり知らないので、採用が難しくなる。最近は採用しやすい言語を使うよう考えている 小林：最近はgo-langが流行ってきているので、採用にも効いていると感じられる 大倉：同じく最近はgo中心にプロダクトを構築していて、世の中的にも増えてきている感がある
及川：10年前と今では何が違う？ 小林：インフラでクラウドの進化が大きい、今ではクラウドを選定しないことがほとんど無いくらいになっている 及川：インフラエンジニアの仕事が変わってきている。
及川：10年前に機械学習を意識していたか？それを機械学習またはAIと呼んでいたか？ 松野：10年前は今ほどパフォーマンス広告よりも純広告が多かった。今はどういうユーザが広告をクリックするか？などの分析はやっている。 小林：10年前はAIとか言われていなかった。ルールベースでアルゴリズムを処理する、ベイジアンフィルタをかます、などは昔からあった。それが進化したのが今だと思っている。 及川：Googleの検索だって今となればAIと言われるようなものだが、当時はそういう「ラベル付け」がされなかった。
及川：NVIDIAがこんなに大きくなるとは思っていなかった。 小林：GPUの用途が格段に広がった。
及川：皆様の企業はどういう風に変化しているか？ 大倉：グループごとのCTOが事業に最適な技術を選定するようになってきている。 小林：事業部ごとにCTOを置くようになってきている 松野：だれが開発をリードして、誰が決定してくのか？を明文化するようになってきている 及川：テックリードやCTOという肩書きや役割が明示されるよう、組織の文化が変わってきている。
及川：今、注目する技術？ 小林：自動車産業にむけてのオートモーティブ事業に、ITS（インテリジェントトランスポートシステム）への適用が重要。Uberとかを導入するにあたり、日本は世界に比べて遅れをとっている。土木や都市設計にも関わってくる。次世代の環境を作るためには、日本のITSを底上げしていく必要がある。 及川：日本は要素技術は強いが、応用をする際に、横の連携がまだ足りない感がありますね。 大倉：RPAの導入をしていきたいが、APIが公開されていない（？）など厳しい状況にあるが、できるようになっていきたいと思う。（？） 及川：人間の動きをシミュレートしたり、そういったもので代替されるが、なんとかテックといったものが縦の機能で閉じていて、横の連携をするためにAPIを公開して連携可能にすることで、ユーザーフレンドリーなものが作れるようになっていくのかな、と。 松野：非常に沢山のデータが集まってくる。どういったものを集めて利用していくのか、が重要。気軽に大きなHadoopクラスタを構築できるようになってきたので、その後の扱い方が重要。 及川：データを集めることはできたとして、そのデータをどう扱うのか？が重要だが、データに対するリテラシーはどうやって育てられているか？ 松野：データサイエンティストを積極採用したりしつつ、Tableauサーバなど気軽にBIで分析できる基盤を整えたりしている
①例えば、プログラマとして、どこまでプログラムを書かないといけないのか？ 及川：インフラはほとんどスクリプト一発で実現できることが増えてきている。GitHubのChrisも、将来はコーディングがなくなっていく世界が来ると言っていた。 松野：どういう要件が必要で、どこがどういうコンポーネントで、といった要件を整理するところは少なくとも人がやるんだと思っている。徐々に、ブロックを繋げるだけで実現できる世界が広がってきているのを感じる。 及川：書き方は簡単になってきているが、やろうとしていることが難しくなってきているので、結果的に書く量は変わっていないようにも思える。 小林：自動車産業がなぜこんなに自動化するか？というと、人間が操縦したりすると事故が起きるから。つまり、人間がコードを書くとバグが生まれる、ということの解決としてプログラミングも自動化されていくのではないかと思っている。
小林：RoRなど簡単なものが増えてきた弊害として、裏側の本質的に行われていることを理解していない人が増えてきているのは、どこかで問題につながりうるのではないか。
及川：マインクラフトの話があったが、ビジュアルプログラミングはどれくらい出てきているか？ 大倉：子供向けにスクラッチをやらせてみているが、まだ難しいようだ。子供向けのRubyの本のほうが分かりやすいかと考えている。 及川：ビジュアルプログラミングは、バージョン管理と人とのコラボ（ソーシャルコーディング）が難しく感じる。
及川：将来に向けてインフラエンジニアはどうあるべきか？ 大倉：抽象化されたことで自動化やプログラムで解決されるものが増えてきたが、コードを書くのか、より深い要素技術を理解して身につけるのか、どっちかかと思う。
及川：チェスの大会や、自動運転車の世界でもあるように、機械の横に人間が座って、協力して結論を出していく組み合わせがベストな解決につながる、という世界がしばらくは続くと思う。
②ソフトウェアにより制御可能な世界 SDxやxxx as a service その進化はソフトウェア開発やインフラへどう影響を与えるか （途中、メモれず・・・） 及川：Software eating the world. とも言われるように、ソフトウェアが世界を変える、という流れがしばらく続くかと。
③チーム開発の将来は？VRやARが与える影響は？リモートワークの今後 小林：隣りに座っている人ともSlackで会話する、ということも出てきている。だが直接会って話さないと伝わらない空気感や感覚があるし、初めて会う人がずっとChatというのも抵抗が残るので、対面コミュニケーションはなくならないと思う。 松野：グローバルな拠点でのやり取りはChat(LINE)だったりビデオ会議でやることがある。ビデオ会議でも通訳を通しても通信が不安定だったり、情報が落ちることがある、対面で通訳を通したときの方がまだ安心感がある。今後はVRで徐々に解決されていくのかもしれない。 及川：音声が不安定だと、途切れるのを恐れて、短いフレーズで話す傾向がでてしまい、短い文言での発言だと「怒ってるのかな？」みたいに本来のニュアンスで伝わらないことがある。
最後にひとこと 松野：今後も色んな技術によって、いろいろと便利になっていく、それらに触れられるのが、作る側としても楽しみ。 小林：作り方も高度化している。企画して設計して作って、ではなくユーザ体験とか考慮するようになっている。それらを柔軟に対応できるようになっていきたい。 大倉：今日のディスカッションを踏まえてオートメーション化について今後もディスカッションができると嬉しい。
所感
golang普通に使っている企業が増えてきたなー。生の及川さん初めて見たー（ミーハー心）
GitHubと共に学生を育てる方法
古橋 大地 (青山学院大学)
@mapconcierge
2017年度の大学1年生
文系の学生ですら、ここまではやってるんだな、という話
いつも学生に見せる樹状図
- 生物の進化
- 様々な形で生き残るもの、生き残らないもの
- どういう情報が継承に値するのか？
- どうやって教育していくべきか
教育の中でGitHubを利用している
- GitHubの地図を作っている？
- GeoJSON
- 点情報、緯度＋軽度
- 拡張子は
.geojson
- ベクタデータ全般が扱える
- Github上でレンダリングされる
- 背景地図はGoogleマップではない
- 私達が作っている「OpenStreetMap」
- https://openstreetmap.jp/
- GeoJSON
どんなことを教えているか？
- 課題：XYZタイル画像のデータ仕様を図化しなさい。
- 技術者としてではなく、技術者と一緒に活動できるようになりなさい
キャンパス内でドローンを操作してみる体験
- ドローンレース
- どういう映像がドローンを通して見えるか
- ドローン操作がうまくなる
最先端の技術をどうやって社会実装できるか、を考えられる学生を育成
- OpenStreetMap
- 一億総伊能化
- GitHubに様々な地図情報を提供
Wikipediaを参考にしたモデル
- Free Wiki ...（？）
オープン（＝商用利用可能）
オープンストリートマップ
- 5.0M規模のボランティアの力
- 海外の仲間との情報共有
- 公開にすることで、学生に適度なプレッシャーになる
- 外部の人からコメントが来たりする
- ウェブサイトはGitHub Pages
Gitの仕組みは、Git-it で経験。
- https://github.com/jlord/git-it-electron
- 文系の学生もコマンドを使わせる
- GitHubが使えないことで、そのコミュニティに入れないのは大きな損失である
- 学生に説明するプレゼン資料はSpeakerDeckで公開
- GitHubと空間情報
- GitHubの履歴は就職活動の履歴書にもなる
- 就職活動前から（1年生から）育てていく必要がある
- Issueでのやりとりも、PRもすべてがエビデンスになる
最近は、GitHub Projectでタスク管理
外（社会）と中（大学）をつなぐ架け橋がGitHub
- Publish or Die! （公開するか、さもなければ死を！）
所感
文理系に関係なく、学生にITリテラシーを植え付けようとするその志と、オープンな地図ソリューションで社会貢献しようという情熱が半端なかった。これくらい徹底してGitHub中心に生活させるようにしないと、リテラシーの底上げは実現できないよな、と痛感。
SlerがGitHub Enterpriseを使ったら
原口 猛 (株式会社セゾン情報システムズ)
所属グループ「モダン開発推進」とは？
- 既存のプロジェクトの進め方にプラスアルファをし、いいねを一緒に増やしていく
GHE導入編（SIerでもGHEが使いたい）
- 背景
- いざ導入
GHE運用編（え？運用は私一人ですか？）
- 2年間運用してトラブル０件
- 運用で必要となるのは、定期的なアップグレードのみ
- 運用工数はごくわずか
導入効果
- デイリーコミット（を推奨）
まとめ
- GHEはただのツールではなくプラットフォーム
- 文化を変えるためのプラットフォーム、豊富なプラクティス
- 導入ではなく定着がゴール
運用事例
- 事例１．ペアプロ・モブプロによるシングルブランチ運用
- PRベースじゃなくてFaceToFaceでレビュー
- ブランチはmasterブランチのみ
- 事例２．開発以外での利用例（ポータルサイト）
- GitHub Pages
- 静的コンテンツを簡単に公開
- GitHub Pages
マクニカネットワークス 根本さん
GitHub Enterprise の国内一次代理店
- 導入事例および支援サービスのご紹介
- GHE および CircleCI オンプレ版 の導入支援
所感
GitHub Pages 使っているところが多いなー
弊社でも有効活用しないとなー・・・
GitHub Marketplaceと、開発生産性を向上させる幾つかのSaaSのご紹介
角 幸一郎 (SideCI株式会社)
@sumyapp
コードレビュー支援サービスSideCIのFounder,CEO
背景
- 書籍「クラウド誕生」の出版2009年から9年が経過
- オンプレミスなソフトウェアやソフトウェアのない世界が残っている
- ソフトウェアはお金で買える、開発リソースはお金で買えない
- 開発者は仕事を効率化するために、SaaSやソフトウェアを遠慮なく使える世の中になって欲しい
発表後にやって欲しいこと
- GitHub Marketplaceですぐに使える便利なサービスを知って、使ってみて欲しい
SideCIで使っているサービスは、数多くある
- 10数名規模の会社だが、無数のサービス利用によって生産性を最大化している
GitHub Marketplaceとは？
Marketplaceサービスの紹介
- Coveralls | Code quality
- https://coveralls.io/
- テストカバレッジがいろいろな方法で非常に見やすい
- 行ごと
- ファイルごと
- 時系列
- SideCI | Code review
- https://sider.review/ja
- RuboCopやCheckstyleなどの解析機を使って、コードレビューを支援
- GitHub PullRequestと連動
- コードを解析、問題点をサジェスト
- 静的解析ツールは必ずしも正しい指摘をするわけではない
- 誤検知をCloseする機能あり
- プロジェクト固有のルールも検査できる
- 購入パイプラインによって並列実行も可能
- 今日から sider にサービス名変更
- Dependabot | Dependency management
- https://dependabot.com/
- Dependencyの自動アップデート
- PRを自動で生成
- アップデートでCIが落ちるか？が分かる
- PRを自動で生成
- Rollbar | Monitoring
- https://rollbar.com/
- 例外検知サービス（めちゃ便利）
- スタックトレースが見られる
- ユーザの環境情報も（ブラウザなど）
- 例外のトレンド把握や検索が可能。
- ZenHub | Project management
- https://www.zenhub.com/
- GitHub Issues をボードで表示
- GitHub Projects よりも高機能
- ベロシティ計測、リリース可能日予測
便利なサービスがたくさんある
- 開発生産性を飛躍的に引き上げてくれる
- 簡単に導入できる
- 人の時間は有限。スケールアウトもできない
- SaaSなら人の時間を節約できる
所感
今までは、ほとんど自前でゴリゴリと周辺サービス連携をしてきてしまっているので、マーケットプレイスを有効活用して、楽に（お金で解決して）生産性と品質を確保する選択肢を増やしていかないとな。
GitHubを軸とした開発プロセスのリプレイス
大平 哲也 (株式会社スタートトゥデイテクノロジーズ)
テーマ
- いかに開発者の負担を減らして、楽しく開発できるようにするか
- 主に「自動化」について話します
開発環境を取り巻く状況
- 開発体制
- 基本・内製
- 100名強のエンジニアでサービスの開発と運用。
- 本社と密に連携
- 慢性的な人手不足
- ZOZOTOWNシステムリプレイスプロジェクト
- おおまかな方向性
GitHub導入以前
- 他社のインストール型Git Repositoryを利用
- 様々な問い合わせが発生し、十分に対応しきれない
- サーバが落ちる、ログイン不可、重い
- 社内での運用は人手不足
- インストール版のGit repoだと、各種SaaS/PaaSと連携するために自作○○が必要になる
GitHub機能比較 by スタートトゥデイ（GBHの価格は $21 で、GHEと同じ）
GitHub Business Hosted
GitHubエコシステム
- Wercker（CIツール）
- 自動化
- テスト
- いわゆるUnitTestを実施
- DSLの内容もチェック
- Terraform/Ansible
- コード品質の評価
- push時に品質を自動でチェック
- Code Coverage
- Code Smell
- Duplications
- PRレビューの補助
- SonarCloud（SonarQubeのクラウド版）
- 様々なコードメトリクスを収集
- コード自動生成
- 仕様は一箇所で表現したい
- 仕様を書いたら、そのとおりに成果物ができて欲しい
- Swagger / OpenAPI
- YAML/JSON で仕様を定義
- 定義どおりにコードを自動生成
- Swagger to Mock API
- Swagger to API Code Template
- SpringBootの例（Controller Interface）
- Swagger to API Client Implementation
- Swagger to Spec Document
- API仕様をドキュメント化＋動作確認できる
- Swagger to Postman
- APIテストツールPostman用の設定ファイルを自動生成
- https://qiita.com/moaikids/items/1e05ef2595504689fe3e
- Swagger to JMeter
- 性能テストの元となる設定ファイルも自動生成
- https://qiita.com/moaikids/items/2f0029ea246c5f6818d9
- 成果物のパッケージ
- デプロイ
- ...追いつけず
- テスト
総括
- GitHub Business Hostedを採用することで運用負荷を減らす
- 様々なエコシステムを利用できたので、開発者の生産性を向上
- GitHubをフル活用して開発者が楽しく開発できる環境にしていきたい
所感
k8sを使っている事例を当たり前に紹介されることが増えている気がして、やばい出遅れている感（！）
企業開発に役立つGitHubの最新機能
池田 尚史 (GitHub)
@ikeike443
プリセールスのエンジニア
- ROI計算の支援とかしてる
GitHubとは
- The software development platform
- ソフトウェア時代の主役は開発者であり、それを支援する
- 色んなバリエーションのプロダクトごとに様々な開発手法がある
- あらゆる開発手法を受け止められる開発プラットフォームである
- 10年間に書かれたコード量：500TB
- 昨年1年間のコミット数：15億
- マージされたプルリクエストの数：1億
- 85%のプルリクエストは、実はPrivate（主に企業による利用）
企業利用の選択肢
- GitHub.com Business Hosted
- GitHub Enterprise
- コードベースは同じ
- エンドユーザー視点で同じ機能を提供
- GitHubBH
- GitHub社が運用、マルチテナント、米国
- GHE
- 社内にインストール、御社のポリシーで
代表的な機能
- GitHub Flow（機能というかプロセス）
- GitHubが提唱しているベーシックな開発フロー
- Git Code Repository
- Pull Request
- Issues
- Projects
- 巨大なエコシステム
- 各種ツール、エディタ、チャットツール、CIツールとの連携
企業利用に役立つ機能
- Platform
- Administration
- Org/Team
- Nested Teams
- 権限グループのネスト
- Approval flows
- Teamへのメンバー追加
- Organizationへのサービス追加
- Team Discussions
- チーム単位でディスカッションができる機能
- Organization Permissions
- メンバーの初期権限
- リポジトリの可視性
- Forkの可否
- 2要素認証の使用有無
- Protected Branches
- 特定のブランチを保護し、マージ条件を設定できる
- Code Ownerによる承認を必須に
- CIやテストのパスを必須に
- 特定のチームのみマージ可能
- Nested Teams
- Developer
- Projectsの改善
- 自動化カンバンボード
- Issueのステータスとカンバンの位置移動を連動
- 進捗のビジュアライズ化
- 権限管理
- テンプレート
- キーボードショートカット
- 自動化カンバンボード
- 複数のIssueテンプレート
- ナビゲーションの追加
- 特定言語について、Jumpと編集が楽に
- コメント編集履歴
- Projectsの改善
まとめ
- 企業内開発に役立つ機能
- Issues/Projects/Pull Requests
- Organization/Teamによる権限管理
- 運用管理に役立つ様々な機能
- 今後も進化していきます
- GitHub Changelog で変更点は確認できる
所感
Security Alert / Checks API は待望。
GitHub Enterpriseアドミンパネルディスカッション
モデレーター テレル・ブルーマ (GitHub) 伊集院 圭介 (ブラザー工業株式会社) 井内 聡 (フリュー株式会社) サマーズ ハリス 和弘 (楽天株式会社)
テレル・ブルーマさん @domofactor
１．GitHub導入時点の話 て：導入した理由は？ さ：インフラを導入していく仕組みのリポジトリを管理していくにあたり、GitHubを使えなかったのでGHEを使った て：大規模な企業だが、簡単に導入できたのか？ さ：導入には苦労はなかった 伊：システム的な問題としてプロプライエタリなVCSはWindowsでしか使えず、Mac/Linuxでは別のものを使っていた。ソーシャルコーディングが開発者から求められていた中で、GitHubEnterpriseを使っている他社の事例を見て憧れを抱いていた。そういうCoolなツールを使いたい、という思いが強かった。 井：レビューを強化しようという流れの中で、SVN＋Redmineで行っていたが、GitHubのPullRequestの方が効率的だったので、導入した。.comの利用にはハードルがあったので、GHEを採用した。
て：導入で苦労したことは？ 井：SVNからGitへの履歴を含めた移行はすぐにできたが、SVNの外部参照を多用しており、代替の機能がgitにはなかったので苦労した。最終的にはgit-submoduleを使って実現したが、ディレクトリ構成の変更などを伴い苦労した。また、git自体の理解と習得に苦労した。 伊：プロプライエタリなVCSからの移行だったので、事例がない情報がないので苦労した。ツールを使っていたが、特定条件のリポジトリは必ず失敗する、などが起きて職人芸的にクリアせざるを得なかった。gitに理解のないエンジニアに移行を促す作業は、なかなか骨が折れた。今は古いVCSはシャットダウンできている。 さ：最初は特定プロジェクト向けにgitを導入したが、どんどん周囲のプロジェクトから手が挙がって利用者が増えた。当初はライセンスの購入が追いつかなかった。また、よりオープンに公開する文化にシフトするなかで、秘匿化しなければいけないトークンなどまでオープンにしてしまうことを防止したり、そういったポリシーを定めるのに苦労した。
２．いま時点の話 て：GHE導入して、何が変わりましたか？ 伊：一言で言うと文化が変わった。自分たちで調べてブランチ戦略を考えたり、勝手にPullRequestでコードレビューを始めたり、そういった変化が自然に起きた。 さ：各プロジェクトが自分たちで作っている製品を管理していたが、今は、チームを横断してPRを投げたりするような文化ができ始めている。良い変化だと思う。 井：様々なツールを見ていたのがGitHubに一本化されて効率があがった。またPRの時点で仕様や要求の共有ができるようになった。
て：GHEを管理していて困ったことは？ 伊：ソフトウェア的に問題が起きたことはない。Org/Teamの管理が自分自身でしかできない点が課題。 井：サーバ側でのトラブルはない。gitの勉強コストが困ることがある。git操作での事故がチラホラある。レビューを通すことが必須になったため、本流に入るまでの時間が長くなった部分もある。 さ：弊社はプライベートネットワークとパブリックネットワークが分かれており、それらのインターフェースを毎度設定する必要があり苦労している。今は解決している。
て：管理者からみてGHEのいいところは？ 井：安定しているサービスである。サポートが日本語で対応してくれるのも助かる。 さ：安定性はすごくありがたい。他に使っている他社製品はDockerベースのものが多いが、落ちたりバグったりする。管理者用のドキュメントも分かりやすくていい
て：ユーザの反応はどうですか？ 伊：良好。早く作業ができていい、という声を聞く。GHE内のすべてのコードを検索できるため、社内の特殊なノウハウを探して参考にしやすいのが嬉しい。 さ：使い出すと戻りたくない、という声が多い。 井：リポジトリをまたいだ検索はありがたい。使うべきではない関数の横断検索などは効率的にできた。
（オーディエンスから質問：福留さん）サーバの運用周りについて、手がかからないという話があったが、何か管理面で自動化の工夫をしている点があれば教えて欲しい。 さ：GHEはモニタリングでGraffanaが統合されているが、独自のモニタリングツールと統合したい場合に、モニタリングのAPIを使って情報を吸い出している。
て：これからGHEを導入したい人へのアドバイスは？ 井：PRは開発者にとって大きな変化なので、1つの最善の選択だと思う。 伊：競合製品と比べるのは良いと思うが、結局はGHEに辿り着くと思う。サポートのレスが早い。情報文献も多い。
会場風景
タイムテーブルとフロアマップ（今日はPegasusエリアを使わず）
このクッションを持ち帰りたかった
GitHub Japan Constellation Tokyo 2018 〜Day 1 Community〜 #GitHubSatelliteTokyo
2018/06/12 (火)
11:00 - 20:00 JST
公式サイト：https://githubsatellite.com/
参加申し込み：https://peatix.com/event/366890
ライブストリーミング：https://githubsatellite.com/live-stream/
Twitter HashTag： #GitHubSatelliteTokyo
基調講演：ソフトウェア開発の未来
公家 尊裕 (GitHub) ジェイソン・ワーナー (GitHub)
GitHub サービス開始が2008年、今年でちょうど10年。
GitHubという会社は、コラボレーションとリモートオフィスという考えを大事にしている。全世界に社員がいるが、長い間オフィスはアメリカ１つだった。
2015年、GitHubのアメリカ以外の最初のオフィスができた。場所は、Tokyo。
ソフトウェア開発の未来に貢献していきたい。
今、開発現場で起きていることは？（ジェイソン・ワーナー）
開発者
- 皆様が書いているコードが、今、地球上で大きな原動力となってる。
- ソフトウェア開発者になるのに、今ほどいい環境・状況はない。
より複雑化する開発環境
- 数年前の時点で、平均的な自動車は、1億Stepのコードで動いている。
- 2017年、平均的な開発者は1000以上のクラウドサービスから選定をしている
- 進化は止まらない、追いついていくのは容易なことではない
コミュニティは知識の集合体
私達が最初に作ったもの。
- 信頼性の高いバージョンコントロールシステム、Web経由でアクセス可能なもの。
作ったシステムは、次第にコミュニティを構築していった。
- そしてオープンソースソフトウェアが活発に作られるようになった。
人やデータ、ツール、すべてが繋がっていくことで成長・進化していく。
開発環境の複雑化は止まらない
- アイデア、コード、ビルド、デプロイ
- 無数の意思決定がプロダクト作成までの道のりでは必要。
過去、今日、未来
- 人々が積み上げた試行錯誤を段階的に未来につなげていけるのが、GitHub
ツール・サービスには、あまりにも多くの選択肢が用意されている
- これらをすべて評価してマスターしていくのは不可能
これらの乱立するワークフローを解決するのが、Pull Requestだった。
複雑化する開発環境
- 単純化するプラットフォーム、合理化したソリューションが必要
- ガチガチに固められたソリューション？
より良い開発環境構築のために
開発者感コラボレーションの促進
開発者に必要なのは、より多くコードを書く時間と、ユーザのことを考える時間
新しいテクノロジーは次々と出てくる
ソフトウェア開発が将来どういうかたちになっていくか、は誰もわからない
- どのようになろうと、複雑性を排除してシンプルに開発できる環境を整えることに注力したい
様々な問題を解決するのは開発者の皆様です。
- GitHubはそれを支援します。
日本マイクロソフト株式会社CTO 榊原 彰 氏
設計図共有サイトのファンの皆様、こんにちは（会場爆
すべてがコンピュータ・ソフトウェア産業になっていく。
- それを作り、支えていくのは開発者の皆様です。
マイクロソフトは変わってきた、あなたのお父さんの世代のマイクロソフトとは違います。
- 言っても信じてもらえない人もいる
- 言葉ではなく、行動で示していきます。
GitHubの独立性を保って、すべての開発者が今までどおりGitHubの機能を安心して使っていけるようにする。
- LinkedIn やマインクラフトでも独立性を維持してきた
- これが、我々の今のミッションです。
- これからの我々の行動を見ていただきたい。
empower all developer
- 我々がやりたいこと。
- すべての開発者とともに、未来を作っていきたい。
パネルディスカッション：Rubyが生まれた頃、そしてこれからのRuby
アーロン・パターソン (GitHub) まつもと ゆきひろ (Rubyアソシエーション)
GitHubのソフトウェアエンジニア、アーロン・パターソン
（互いに旧知の仲らしく、2人でのセルフィー撮影に始まり、終始和やかなムードで対談）
あ：GitHubはRubyで書いてあるので、まつもとさんありがとう。
あ：Rubyはいつ生まれた？ ま：1993年です。 あ：どうやって生まれた？ ま：バブル経済が崩壊して景気が悪かった、ソフトウェア会社の社内ツールを開発するチームに在籍していた。そういうツールは売上がたたない。景気が悪いのにそんなことをやってられない、プロジェクトが解散した。社内にはツールのユーザが既にいたので、面倒を見るために残されたエンジニアが2人だけ残った、そのうちの一人。何年もかかって作ったツールを2人ではサポートを回せない。自分で作ったもの以外も多数あったので、基本的にトラブルシュートは「再起動してください」で終わらせていた（笑。上司は兼任で忙しかったが、自分たちには時間があった。誰も管理していない状態、そんな中で作ったのがRuby。 ま：会社で作ったが、著作権の考え方に厳しい時代じゃなかったのと、上司が許してくれたので、退職時に外へ持っていけた。上司が許可してくれなかったら今のRubyはなかった。
ま：GitHubに公開されているRuby/Rubyは、公式のミラーであり、実際はSVNで開発が行われている。 ま：なぜGitHubに移行しないのか？をよく聞かれる。RailsもGitHub。PythonのセントラルリポジトリもGitHub。 ま：RedmineでIssueを管理していて、RedmineとSVNを連携させる作り込みを相当しているので、使い続けるという状態。あと、GitHubサービス自体はOSSではないので、一部のコアなエンジニアが完全オープンなサービスにしかアカウントを作りたがらない、というのもある。そういう人々を離脱させたくない。
あ：まつもとさんがGitHubを初めて使ったのはいつ？ ま：Ruby本体で使えなかったので、アカウントは作ったが、ほとんど使っていなかった。自分用のメールリーダーを自作している、OSSにしていないのでユーザは自分しかいない。それを修正するためだけにPRを3回だけやった。
ま：mRubyは、最近の普通の開発がしたかったので、最初からGitHubにホストしている。やっぱり楽でいい。リポジトリなどを自分で管理するのはよくない、と改めて思った。
あ：Ruby開発のコミュニケーションの問題はあるのか？ ま：Rubyのコアコミッターは100名くらいいる。日本人が半分くらいだが、スーパーアクティブな人が日本人なので、日本人がコミッターであるイメージが強い。 ま：Rubyの開発は、オープンソースだけどクローズドだ、と海外の人で言われた。日本人が日本語でいつの間にか方向を決めてやっている。それ以降、Redmmineにすべて内容をダンプして、公式言語も英語にして、オープンになるよう心がけている。議事録も英語で書いているので、日本語がわからないとRubyができない、という世界にはならないようにしている。
あ：Rubyの未来について ま：頑張って進歩を続けている。RubyやRoRは「ハイプ曲線」を過ぎて、Rubyは死んだ、と言われている（笑 ま：Goなどの静的な型がある言語が持ち上げられてきたので、様々な理由で毎年死んだと言われ続けている（笑 ま：大きなサイトでRubyが使われているのは事実で、そういったサイトをもっと支援したい、と考えている。性能問題が出たときに独自カスタマイズしたRubyを作っている人々が昔はいたが、大体が残っていないと思うし、本来Rubyユーザが汗をかくべきところではないと思っている。 あ：アウトオブバウンズGCの説明。Webサイト利用者にGCによるレスポンス遅延影響を最小化する手法。GitHubで利用することで劇的にUXが改善した。 ま：そういう感じでコアチームの努力によって、Rubyユーザが独自にRubyをパッチしなくてもいいようにするのが責任だと思っている。
あ：プログラミング言語を作るのが好きなまつもとさんの、プログラミング言語のストリームについて教えてください。 ま：言語をデザインする人が、言語をデザインするときにどういう事を考えて設計しているのか、ということが分かるような連載を書いている。そこで作り始めたのがストリーム。まず200行くらいの文法イメージを書いてGitHubにバックアップ目的でアップロードした。特に隠す必要もないと思いパブリックリポジトリにしていたら、次の日に、「まつもとがプログラミング言語を作っている！」というのが見つかって、バズって1000スターくらい一気に行った。。。全然作業途中のものなのに、PRは来るわ、言語のアイコンを作って投げつけられたり、色んなことが起こって、OSS時代の開発は全然違うな、と思った。フリーソフトウェアの時代とは違う。
あ：まつもとさんの開発環境について ま：普段使っているエディタはEmacs。コンパイラーはgcc。 あ：なんでRubyのソースコードの中で同じファイルの中にTabとSpaceが混在しているか？ ま：どっち派の人もコミッタにいるが、最後に触った人の修正した行が、その人の行はその人の流派になる。特に統一しようとしていない。 ま：昔はスペースよりもタブ派だった。データ数が少ないので。最近はスペース派になった。git blame が効かなくなるので、変換するためだけのコミットをしていない。
あ：私は自作キーボードを使っているが、どういうキーボードを使っているか？ ま：Thinkpadのキーボード、マイクロソフトのエルゴノミクスキーボードを使っている。最近はレッツスプリットというキーボードを使っている。タップキーボードを最近買ったが、まだ使いこなせていない。
余談：日本独自文化「笑う」の意味での「草（w）」の話と GitHubの「草（Contribution activity）」の話。（アーロン大爆笑）
所感
話を聞いている雰囲気から、Matzは細かいことを気にしすぎない包容力があるから、Rubyのコミッタを含むコミュニティを「いい感じにゆるく」まとめていけるんだなー
エンジニアにとって窮屈さを感じさせる環境を作らない、というのが非常に感じられる。 でも大事な部分はキッチリ真面目に説明責任を果たすし、Techリードはこうあるべきと感じた。
OpenSTFをオープンした結果
シモ・キンヌネン (Dragon Standard Inc.)
https://github.com/openstf/stf
Co-Founder
- OpenSTFとは？
- 2015年サイバーエージェントがオープンソースした社内プロジェクト
- ブラウザから多数のスマートフォン端末を操作して動作確認ができる
- Control and manage Android devices from your browser.
- 今日は、OpenSTGについては話さない、どのように成長したかを紹介します
- GitHub Starは
- 9345ついた
- 公開後、安心安定の成長
- Fork数、Issue対応数もどんどん増えてる
- PRの数、200弱あった
- 公開前は誰もPRしてくれないのでは、という不安があった
- 公開直後はJumpStartした（知名度が最初にドッと増えた）
- サイバーエージェントというブランドの後押し
- 話題性、日経新聞に載った
- ポイント
- 実際にニーズがあった
- 他のオープンソースのものがなかった
- なぜ成長が進んだか？
- ライセンス：Apache2.0なので、ほぼなんでもできる
- 自然な成長
- インド・中国・ロシアでは意外と人気
- クラウドが安定していない、または信用できない傾向のある国である
- 端末の種類が多い
- 定期的なアップデート
- インド・中国・ロシアでは意外と人気
- 辛くなったこと
- メールボックスの状態が、OpenSTFのメールだけで埋まっている…
- オープンソースのイメージが変わった
- 文化的な違い（サポートの辛さ）
- 他人の時間を大事にしない
- 困ったことがあったら自分で調べるより誰かに聞きたい
- ドキュメンテーションがあっても読まずに直接聞きたい
- （折角用意してある）Issue Template を消す
- 他人の時間を大事にしない
- 言葉の壁
- 何で困っているか、通じないことがある
- 問題を把握するのに非常に時間がかかる
- 詳しい説明がないから何回も同じ情報を聞く必要がある
- Issue Template が理解できない
- 技術の進歩
- 昔、私達しかできなかったことが、新しいAPIのおかげで比較的ラクに
- 他のソリューションもある
- ライセンス
- Apache2.0なので、ほぼなんでもできる
- 私達のものをそのままか、ロゴを変更するだけで売っている会社がある、残念
- 普通に嫌なこと
- 「○○機能ってまだ？」
- 「有料の他のツールでは、それができてるよ？」
- 「じゃ、ほかのものにするよ」
- すべて解決できるわけではない
- 役に立ったこと
- メンバーを増やす
- 昔は厳しかったが今は２〜３回目のPRでPushを許可する（権限を付与して正式なContributorに）
- 最初は怖いかもしれないがGitなのでかなり安定する
- （いざとなれば force push で履歴改変）
- Issue Template をできるだけ短くする
- 何が起きた・何をした・ログの有無
- 考えすぎて無駄に長くすると誰も入力してくれない
- スクロールすると読んでくれない
- もちろんCIを設定する
- （ビルドが落ちても直さない人がいるけど・・）
- Issue が来たら、すぐに対応にかかる時間を判断する
- 3分以下なら、すぐ返事してクローズする
- それ以上なら、あとにする
- CHANGELOG.md をちゃんと管理する
- 何がいつ変わったか簡単に分かるから無駄に聞かれない
- リリースノートでそのまま使える
- 無駄な約束をしない
- 「それ、いつかやるつもり」と言ったら無駄に期待されるので、興味・時間がなかったらハッキリ言おう
- ビジネスをやるつもりがなくてもサポートの値段ぐらいはちゃんと準備しよう
- 高めにすると面倒くさい要求が簡単に回避できる
- メンバーを増やす
- 良かったこと
- 普通より面白い仕事をチャレンジできた
- いいエンジニアと連携できると最高
- いろいろなイベントに招待された
- LA、ロシア、中国など
- 「タイに来てうちの経費で○○機能を作って」という依頼も
- いろいろな会社と連携できた
- 恐ろしいスケールのデバイスラボも見せてくれた
- 仕事にもなった
- たくさんの端末と遊ぶことができて楽しかった
所感
オープンソースプロダクトを扱う身の 生々しい苦労話とやりがいの話。
Matzのストリーム話との共通点は、オープンにすることで多くのフィードバックが生まれプロダクトの成長が加速した、という点かと。
Microservices in ABEJA Platform - 集約と分散のサービス設計
石川 尊教 (株式会社ABEJA)
我々がどのようにマイクロサービスを開発＆運用しているか？
- 3 Topics
- About us
- Technology
- Culture
About us
- Deep Learning のGoogleトレンド紹介
- 2012年付近から、急激に右肩上がり
- 2012年 ImageNet Challenge 2012
- インターネット上にある画像を分類・画像認識をするコンテスト
- 毎年開催されていたが、2012年にブレイクスルーが発生
- Deep Learningモデルが従来の統計的モデルを圧倒
- 認識エラー率は年々低下している
- Abejaも2012年創業
ニューラルネットワークの簡単な説明
- （「ゼロから作るDeep Learning」）
- Data collection
- Annotation
- Training
- Inference
- Re-Training
- に戻る
Abeja は創業6年
Technology
Microservicesとモノリシックサービスの連携
- 30を超えるリポジトリ
- 5つの開発言語
- サービス間は gRPC で通信
- なぜ10名程度の会社でマイクロサービス化を進めたか？
- Complexity（複雑性）
- スケーラビリティが求められる機能
- UI/UXが求められる機能が
- 並列実行のバックグラウンド機能
- Motivation（）
- 開発者は顧客にサービスを届けるのが使命
- 開発者は新しい技術を使いたい、使う機会を得たい
- Microserviceであれば、新しい技術の採用ハードルが低くできる
- No Rules
- 世の中で定められているレベルの最低限のルールを守っているだけで、社内の独自縛りはない
- Complexity（複雑性）
- ARMSの紹介
- モノリシックなGatewayサービスがバックエンドのマイクロサービスのドメインの管理しやすさを後押ししている
- 中央集権的に実現したい機能はここに実装する
Culture
Diversity
- 英語を公用言語としているが、日本語ベースのトレーニングも用意
- Self Starter
- 待ち、ではなく、能動的なキャッチアップと貢献を推奨
- LEAN & Flow
- Waffleをつかったカンバンで朝会を実施
- リモートオンライン会議はZoom
- LEAN開発
- 毎朝のミーティングでカンバンを見ながら同期
- 自分のスキルと興味に応じてタスクを
- 壁の一部がホワイトボードになっていて、すぐに会議が始められる
マイクロサービスアーキテクチャを採用して良かった点
- プラットフォームの構築に向いていた
- 複雑とはいえ、各サービスの役割が明確
- 今のフラットな組織に合っている
- メンバーが固定化されづらい
- 新規メンバーが参入しやすい
- 興味のある言語や分野から入っていける
各サービスをつなぐ中心になるもの、（ARMS）を用意することをオススメする。
GitHub LT大会 ~ 事件は現場で起きている!?
モデレーター 鈴木 順子 (GitHub) アーロン・パターソン (GitHub)
36名の応募者、7名が選ばれた。
GitHubでポータルサイト ドキュメントを運営して幸せになる話
NTT.com 岩瀬ヨシマサさん
https://www.slideshare.net/iwashi86/github-102233959
- GitHub Pages
- GitHub Pagesを使うモチベーション？
GitHub as an Authenticator
Wantedlyオオツボシンペイさん
- 情報共有
- 社員名簿
- 権限管理
- GitHub を使って法務コミュニケーションのスピードを2倍にした話
- 組織上のチームとGitHub上のTeamが対応
- 複数チームの兼務も表現できる
GitHub Teamをベースに認可
- HRのフローに乗るだけで良い
- JOINしたときにTeamに所属させるだけ
- 権限の外し忘れがない
- Orgから外せばすべての権限がrevokeできる
- 特定Teamに入っているとプロダクションへのSSHを許可
- Webhook Token Authentication on kubernetes で
- Teamごとに異なるk8sの操作を許可する
- HRのフローに乗るだけで良い
Summary
- 社員全員をGitHubに入れる
- 組織に合わせてTeamを作成
- Teamに準じて認可する仕組みを
Githubをどうやって初心者に教えるか
湊川あい @llminatoll
「マンガでわかるGit」の著者
http://webdesign-manga.com/git01/
https://www.amazon.co.jp/dp/4863542178
- 土日にブログで書いたGitに関する初心者エントリーがメディアに取り上げられて書籍化
- git教え方いろいろ
- 口頭
- ドキュメントを紹介する
- 聞かれるたびに手を止めて対応
- 「なんかおかしくなっちゃいましたー」
- Gitを教えるのは大変！
- なぜ？
- 初心者にとってGit用語は異国の言葉に聞こえる
- まずは用語を１つ１つ説明していく
- それでもなかなか覚えてもらえない
- ビジュアル化すると理解が早まる！
- 人の脳が見たものを理解するのにかかる →0.1秒
- 脳の50%は視覚関係に使われている
- 文章＋絵だと認識率が圧倒的に高い、という研究結果
- ＋漫画だと
- 時間軸
- 状況
- 登場人物の心理
- を表現できる（私が漫画という手法を選択している理由）
- 漫画でリポジトリを説明してみる
- フォークとクローンを説明してみる
- まとめ
- 学習コストが高いと言われるgit
- ビジュアル化されていれば短時間で理解できる
所感
そういえば、gitの社内説明で絵を何枚も書いたなぁ。
git説明に限らず、ビジュアル化は本当に大事。
GitHubを導入したいとき、どう説得するか
Yahoo! タナカマサユキ
- GitHub使っていて当たり前？
- 導入に向けｍ社内を説得するために戦っている人もいるはず
- 導入の壁いろいろ
- 重要な関係者がGitHubを理解できていない
- うまく説明できない
- GitHubってなに？を改めて考えてみる
- 機能がいろいろある
- Yahoo!のアプリ開発環境で考えてみる
- 「開発業務の起点」
- 開発の中心にいる
- 向き合っている課題
- 大事なのは、導入するサービスを理解し、腹落ちさせること
技術系同人誌執筆のすすめ
イマイケンタさん ＠Henteko07
- I love Developer Tools
- 同人誌は早く出版できて楽しい
- GitHubを使うと複数名の執筆でもうまく書ける
- 商業誌は出版に14ヶ月かかった（経験談）
- 同人誌だと2ヶ月程度でOK
- デメリ：リーチできる人が限られる
- 同人誌は自由（Freedom）
- なにものにも縛られない自由
- GitHub上でどうやって同人誌を作るか？
- ツライ点
- たくさんの画像を扱う書籍
- 画像管理がワケわからなくなる
- デザイン系の本であれば、GoogleDrive＋GoogleDocumentを使ってる
- たくさんの画像を扱う書籍
Mixiにおける技術競技イベント「git challenge」の裏側
Mixi：サトウリョウスケさん
- git challenge？
- 学生を対象としたgitを題材にした競技
- すでに8回開催、のべ168名参加
- どんな問題？
- チュートリアルをみんなで解く
Start OSS Contribution with you know
シバヤマリョウさん @serima
自分にできることからOSSコントリビュートしてみよう
- 初めてのコントリビュート
- CircleCIが1.0→2.0に（2018.8末で完全移行）
- OSSは継続的に開発されることが重要
- コントリビュートしたいな、と思うものがあれば気軽に参加すればいい
- 自分にできることを探す
- Issueを探す（Help wantedラベルは比較的難易度が低い？）
- ソーシャルコーディングを楽しみましょう♪
会場風景
入り口
GitHubグッズショップ
会場案内
GH Satellite : real-time contribution visualizer
Ask GitHubコーナー
CircleCIコーナー
講演会場ではテクノサウンドが流れる
戦利品
ORACLE が CIサービスの wercker を買収
携帯のメールアドレスに迷惑メールが来たので通報した2
今回のメールはこんな感じ。
差出人: <j0a7mwgs7@i.softbank.jp>
日時: 2016年10月19日 19:32:43 JST
宛先: (ワシの携帯メールアドレス)
件名: 【速報】大切なお知らせ（19時32分）
大切なお知らせが御座いますのでご連絡差し上げました。
誠に恐れ入りますが、速やかに通知内容をご確認下さい。
●通知先
(ワシの携帯メールアドレス)
●通知内容
http://vv.wefravs5g.com/bin/campX.php?{怪しいパラメータが沢山}
●期限日時
2016年10月20日木曜日
07時32分35秒迄
何卒、宜しくお願い申し上げます。
------
個人情報を保護する為、メール本文に詳細を記載しておりませんが、
URL（リンク）先は受取人の為の特別な秘密情報を含んでいます。
大切なお知らせの為、通常受信していない場合でも配信しております。
尚、当メールは送信用途のみで使用しており、直接返信されましても確認しておりません。
ご理解・ご協力の程お願い致します。
何者かも名乗らずに、さも大事のように「大切なお知らせ」を伝えたがる連中。通知内容のURLパラメータの多さがウケるw そんな大事なことは、こんな胡散臭いメールでは通知せんわ！
ということで、前回同様に通報しました。
＠2016/10/27追記
読者のどなたかが引用メールにあるURLにアクセスしたからか、続きのメールが届き始めたのでURLパラメータをごっそりマスクしました。
