1時間に詰め込むはてなインターン2022 技育祭2022秋 / Hatena Intern in 1 Hour Geeksai 2022 Autumn

技育祭2022秋 https://talent.supporterz.jp/geeksai/2022autumn/ での発表です

Transcript

1. 1時間に詰め込む はてなインターン2022 株式会社はてな motemen 2022/10/15 技育祭2022 秋 1
2. 2 おはようございます
3. 3 この時間は… • 2022/8-9 月に実施したはてなリモートインターンの 前半課程をギュッと1時間に圧縮してお届け • 座学多めですが、たまに手を動かします ◦ ターミナルがあるとよき ▪ macOS/WSL/Linux ▪ Docker・gh・ブラウザ • 質問・コメントあればいつでもどうぞ
4. 4 motemen • 株式会社はてな CTO • 学生時代に打ち込んだもの ◦ アイドルマスター • 代表作 ◦ うごメモはてな / ghq
5. 株式会社はてな • 2001年 創業、2016年 東証マザーズ上場 • 従業員 約200名 ◦ うちエンジニア約80名 • ミッション ◦ 「『知る』『つながる』『表現する』で新しい体験を 提供し、人の生活を豊かにする」 5
6. インターネットと地続きな文化 • ハンドル ◦ ハンドルネーム（はてなID）で識別 ◦ 社外のIDをそのまま社内に持ち込むパターンが多い • オープン ◦ グループウェア・社内日記でテキストによるコミュニケーション ◦ 可能ならばインターネットにも • ドッグフーディング ◦ 自分たちで作ったサービスを自分たちでも使う 6
7. はてなの事業 7
8. コンテンツプラットフォーム • いわゆる BtoC • ユーザがコンテンツを発信・拡散 できるサービス • はてなブログ・はてなブックマーク等 • はてな発祥の地 8
9. コンテンツマーケティング • 企業のマーケティングに不可欠なコンテンツ発信による マーケティング活動の支援 ◦ オウンドメディアのトータル支援 • はてなブログの法人プラン ◦ はてなブログをtoBで提供 ◦ はてなブログMedia・Business・ For DevBlog 9
10. • 開発・運用・運営の技術を提供する ◦ サービスの受託・共同開発 ◦ SaaS の提供 • Mackerel ◦ はてなのノウハウをベースにした監視サービス • マンガ・ノベル・ゲーム ◦ ジャンプ＋・コミックDAYS・カクヨム ◦ 任天堂株式会社との共同案件 テクノロジーソリューション 10
11. CTOの仕事 • ソフトウェアに依って立つ企業としての能力開発 • はてなにおいては: エンジニア横断職種組織の長 • 各チームがそれぞれのスコープで課題に取り組む中で ◦ 何を共通化し、何を自律させるか？ ▪ 社内共通基盤やノウハウ共有の仕組み ◦ 中期的なスコープで乗り越えるべき技術的な課題は？ ▪ コンテナ化の号令やセキュリティ強化の体制 ◦ はてなのエンジニアはどうあるべき？ どうやってそうさせる？ ▪ 育成や評価・ヒューマンマネジメント体制の設計 11
13. 10年後の自分をつくる • インターン生たちはいま ◦ 多くはソフトウェアエンジニア ◦ プロダクトマネージャ、CTO、研究者もいる • 技術の変遷 ◦ 2010s: DevOps、GitHub、AWS、JavaScript ▪ (-) LAMP、jQuery、CoffeeScript… ▪ (+) コンテナ、サーバレス、マイクロサービス、React、TypeScript 13
14. ソフトウェアエンジニアとしての基礎 • 技術そのものと、その理論や背景 ◦ どんな技術もいつか廃れていく。抽象的なもの・低レイヤのものは 腐りにくい ◦ ここを抑えることで未知の問題にも応用が効く • リーダーシップ・ヒューマンスキル ◦ システムが解く課題は人間のもの。ソースコードを読み書きし、 運用するのも人間 ◦ ここを避けては、よいソフトウェア開発はおこなえない 14
15. インターンが提供するもの • 知識 ◦ 深く狭く、よりは広く浅く。インデックスを張ってもらう ◦ 表層的なものだけでなく理論や背景も加えて ▪ 技術については、今後も生き残っていく蓋然性の高いものを • 経験 ◦ インターンが提供できる最大のもの ◦ 可能な限り外部への提供を目指し、外部フィードバックを得る ▪ デプロイ可能なチームであればデプロイまで 15
16. 16 はてなリモートインターン2022 • 3週間のカリキュラム ◦ 1週目: 講義&課題 ◦ 2-3週目: チーム配属&開発 • 今日は前半課程のエッセンスをお届けします！
17. 前半課程講義 • Web API • インフラ • コンテナ • マイクロサービス • RDBMS • フロントエンド • Kubernetes • デザイン 17
18. 前半課程講義 • Web API • インフラ • コンテナ • マイクロサービス • RDBMS • フロントエンド • Kubernetes • デザイン 18
19. 19 第1章 コンテナ
20. コンテナとは • Docker で有名 • プロセスを隔離・制限して実行するための環境 ◦ アプリケーションとその依存をパッケージし、実行 ◦ OSや他のプロセスから隔離されている ◦ 軽量で、立ち上げも速い 20
21. Docker を使う • docker pull <image> # 公開されているイメージをダウンロード # イメージ = アプリケーション + 依存 ▪ mysql:8, redis:7, debian:10, … • docker run <image> <command> … # イメージを立ち上げてコマンドを実行 • docker stop <container> # 稼働中のコンテナを停止 21
22. 自分のイメージを作る 22 • docker build <path> ◦ Dockerfile の指示をもとにイメージを作成 FROM golang:1.19 WORKDIR /app COPY . . RUN go mod download RUN go build -o app ./cmd/app ENTRYPOINT ["./app"]
23. 演習: はてなインターン応募課題 (2020) 󰳕 https://hatena.co.jp/intern2020 23
24. 実行例 • プログラムが、実行に必要なファイルを添えて実行された ◦ https://github.com/hatena/apply-for-internship-2020 24
25. コンテナに至る歴史 • 物理サーバ ◦ 1つのOS内で複数プロセスが稼働 ◦ 増減に物理的な作業が必要 • 仮想化 ◦ 物理マシン上にゲストOSを複数稼働 ◦ リソースの融通が柔軟に ◦ アプリケーションそれぞれにゲストOSが必要 ▪ これがオーバーヘッドではあった 25
26. Docker (2013) • dotCloud社（当時）がOSSとして公開 ◦ オーバーヘッド低くプロセスを隔離 = コンテナ ◦ Dockerfile による再現性のある環境構築 • 開発用から始まり、CI、本番にも • ちなみにコンテナ技術は jails, LXC など以前からあった ◦ Docker の開発者体験のよさが奏功した形 26
27. “脱ペット化” from インフラ講義 • 物理サーバー ◦ 名前: aoyama, inunaki, … ◦ どれだけ長く安定して稼働させるかが重要。大切にメンテナンスする • 仮想サーバー ◦ 名前: blog-app-03, bookmark-db-02, … ◦ うまく動かなければ作り直す • コンテナ ◦ 名前: antenna-app-deployment-bc697497b-66qx9, … ◦ 集合として期待した状態になるように維持・収束される ▪ eg. Kuberenetes 27
28. コンテナの使い所 (本番) • 各種クラウドプラットフォームがコンテナを デフォルトでサポート ◦ Amazon ECS, Google App Engine, … ◦ 「コンテナ」のインタフェースが決まっているので、可搬性がある • サーバの負荷など必要に応じてコンテナを増減 ◦ cf. マシン調達 28
29. コンテナの使い所 (開発) • ローカル開発に必要なミドルウェアを起動 • Dev Container でチームで共通の開発環境を用意 ◦ インターンでは GitHub Codespaces を使うところも • コンテナをデプロイすれば、手元と本番の環境を一致させられる • ポートフォリオとしてのコードが Docker で立ち上がったら親切 29
30. Twelve-Factor App • https://12factor.net/ja/ ◦ 環境変数による設定 eg. $PORT ◦ ログは標準出力に ◦ 廃棄可能なものとして扱う ◦ etc. 30
31. 31 第2章 Web API
32. 32 1. HTTP • URL の先頭にでてくるアレ 👉 http://… • HTTP = HyperText Transfer Protocol • ウェブを支えるプロトコル • Web API の基礎を押さえていきましょう
33. 33 HTTPの歴史 − 1991 HTTP/0.9 − 1996 HTTP/1.0 − 1997 HTTP/1.1 − 2009 GoogleがSPDYを発表 − 2013 GoogleがQUICを発表 − 2015 SPDYを元にしたHTTP/2の標準化 − 2018 HTTP-over-QUICをHTTP/3に改名 − 2021 QUICの標準化 − 2022/6/6 HTTP/3の標準化
34. netcat で息吹を感じる 󰳕 % nc hatenablog.com 80 GET / HTTP/1.1 [改行] Host: hatenablog.com [改行] [改行] 34
35. 実行例 % nc hatenablog.com 80 GET / HTTP/1.1 [改行] Host: hatenablog.com [改行] [改行] HTTP/1.1 301 Moved Permanently Content-Type: text/html Location: https://hatenablog.com/ <html> ... 35
36. HTTP のセマンティクス > GET / HTTP/1.1 # Method, Target, Version > Host: hatenablog.com # Header Field < HTTP/1.1 301 Moved Permanently # Version, Status, Reason < Content-Type: text/html # Header Field < Location: https://hatenablog.com/ < < <html> # Content ... 36
37. HTTP プロトコルの進化 • ウェブアプリケーションの高度化により、 プロトコル自体を改善する需要が高まる ◦ メディアファイルの増加、TLS、… ◦ HTTP/1.1 … テキストフォーマット on TCP ◦ HTTP/2 … バイナリフォーマット on TCP ◦ HTTP/3 … バイナリフォーマット on QUIC 37
38. HTTP/2, HTTP/3 • セマンティクスは1.1と同じ • HTTP/2 ◦ ひとつのTCPコネクションの中に複数のリクエスト・ レスポンスを詰める • HTTP/3 ◦ UDP上でTLSを含めた通信を実現 ◦ パケットの順番待ちや暗号化ハンドシェイクを減らす 38
39. 2. API • Application Programming Interface • プログラムのためのインタフェース ◦ ライブラリ対プログラム、 サービス対サービス、サービス対ユーザ • 不特定多数向け (LSUD) or 特定少数向け (SSKD) で性格 が変わる ◦ LSUD: Twitter API、GitHub API ◦ SSKD: スマホアプリ向けAPI etc. 39
40. よくある Web API • REST • GraphQL • gRPC 40
41. (i) REST • HTTPの作法にうまく乗った流儀 • URL is リソース ◦ ユーザ、投稿、タスク、… • GET/POSTなどのHTTPメソッドを動詞に ◦ リソースの CRUD に対応させる ▪ CRUD = Create/Read/Update/Delete 41
42. RESTful API: GitHub POST /repos/:owner/:repo/issues/:issue_number/comments # C: コメントの投稿 GET /repos/:owner/:repo/issues/comments/:comment_id # R: コメントの取得 PATCH /repos/:owner/:repo/issues/comments/:comment_id # U: コメントの更新 DELETE /repos/:owner/:repo/issues/comments/:comment_id # D: コメントの削除 42 • 説明的なURLでリソースが表現されている • HTTPメソッドも直観的
43. GitHub RESTful API を使う 󰳕 43 $ gh api -i -X GET /user HTTP/2.0 200 OK Access-Control-Allow-Origin: * ... { "login": "motemen", "id": 8465, "avatar_url": "https://avatars.githubusercontent.com/u/8465?v=4", "url": "https://api.github.com/users/motemen", ... "created_at": "2008-04-25T08:35:37Z", "updated_at": "2022-08-22T10:44:05Z" }
44. OpenAPI 44 • APIの仕様をYAMLやJSONで記述 • Swaggerというツールセットを使用 ◦ コード生成も可能 • 要求が変化していく中で、実装とドキュメントを一 致させていくことがより重要に ◦ → GraphQL や gRPC では標準のワークフロー
45. REST Pros/Cons • Pros ◦ リソース指向で直接的 ◦ サーバサイドの実装が素直 ▪ 複雑なことをしたければクライアント側で頑張る • Cons ◦ クライアント側で頑張る必要がある ▪ タイムラインのユーザ情報をN回取得しにいく…？ ◦ クライアントの要件に柔軟な対応をしづらい ▪ ?with_user=1 みたいなパラメタが無限に増えがち 45
46. (ii) GraphQL • Meta (Facebook) 製 • クライアント側が欲しいデータを指示する ◦ ラウンドトリップ数を減らす ▪ タイムラインの投稿とユーザの情報をまとめて1リクエストに ◦ オーバーフェッチングを減らす ▪ GET api.github.com/users/motemen のキーは32個もある • レスポンスはJSON 46
47. Schema Definition Language type Query { repository(name: String!, owner: String!): Repository } type Repository { issue(number: Int!): Issue } type Issue { author: Actor body: String! title: String! } type Repository { issue(number: Int!): Issue } 47 • サーバもクライアントも 同じSDLをもとにコード を書く or 生成する
48. GraphQL クエリ 48 query GetFirstIssue { repository(name: "Hatena-Intern-2020", owner: "hatena") { issue(number: 1) { author { login } body title } } } • クエリの形が結果のJSONの 形を規定する ◦ クライアントに必要なデー タを過不足なく取得 ◦ ネストしたデータも一発
49. GitHub GraphQL API 󰳕 % gh api graphql \ -f query='query { viewer { name, repositories { totalCount } } }' { "data": { "viewer": { "name": "Hironao OTSUBO", "repositories": { "totalCount": 443 } } } } 49
50. 演習: はてなインターン応募課題 (2022) 󰳕 https://hatena.co.jp/recruit/intern/2022 50
51. 実行例 • 結果はエラーになりますが… • スキーマ情報からどうクエリしたらいいかわかる 51
52. (iii) gRPC • Google発 • バイナリベースのProtocol BuffersをIDLに • 分散アプリケーションを開発する目的 52
53. RPC • = Remote Procedure Call • プログラム中の一部の手続きを 別のプログラムから実行する仕組み • IDL (Interface Definition Language) ◦ 呼び出す側と呼び出される側の規格 53
54. Protocol Buffers syntax = "proto3"; package account; service Account { rpc Signup(SignupRequest) returns (SignupReply); } message SignupRequest { string name = 1; string password = 2; } message SignupReply { string token = 1; } 54 • 複数の言語のコード（サーバ・ クライアント）を生成 可能 • 多言語サービス間通信に向いて いる
55. それぞれの使い所 • GraphQL ◦ 柔軟かつ効率的にデータを取得したい ◦ 例: スマホアプリやWebフロントエンド向けAPI • gRPC ◦ ネットワーク越しのシステム間で高スループットを実現したい ◦ 例: 社内マイクロサービス間通信 • REST ◦ 単機能と小規模なケースで、上記の複雑さが割に合わない場合 ◦ 例: フロントエンドリッチでない補助的な機能など 55
56. 第1章・第2章 完 • 現代ウェブを支える技術について駆け足で見ました ◦ 興味を持った部分は掘り下げてみてください • コンテナ ◦ 常にこれを使うのがオススメ • GraphQL ◦ フロントエンドリッチなウェブアプリ・モバイルアプリを作るなら 検討の価値あり ◦ ツールチェインにキャッチアップするコストはかかります 56
57. 終章 ソフトウェア エンジニアとして 57
58. 既知の課題から未知へ • 講義パートは既知の課題 ◦ 誰かが解いたことがあり、だいたい何かしら正解がある • 現実世界では課題が未知のものになる ◦ ユーザに届けるもの、検証するもの ◦ 何が正解か (つくるまで|届けるまで) わからない ▪ なんなら変わることだってある ◦ チーム開発を通じて課題を明らかにしていく 58
59. 元来、ソフトウェアは不確かなもの • 形がない、体験を提供する何か。 動いている様子をつぶさに観察することも難しい ◦ 開発の過程で、コードという形で書き残されはする ◦ 設計されているときに、開発チームの頭の中にも現れる ◦ 使われているときに、ユーザのメンタルモデルとして現れる • 「何がほしかったのか」はつくってみないと分からない 59
60. Do: 素早いイテレーションを回す • 不確かなものだから、できるだけ早くフィードバックを得る ◦ 早い段階で見せられるものを届ける ◦ はてなだと1週間～2週間のタイムボックスで考えることが多い 60
61. Do: 他者と関わる • 「早く行きたければ、一人で行け。遠くまで行きたければ、 　皆で行け」 ◦ 大きなものを長くつづけていくには、チームが必要 • 最終的な価値を作りあげるのにも、他者の手が数多く入る ◦ 課題の発見・理解 ◦ 体験のデザイン ◦ ユーザとのコミュニケーション ◦ 事業としての成立 61
62. Do: コードを読む • コードは人間と機械のあいだの言葉 • ……だけではなく、人間と人間のあいだの言葉 • 過去にプロダクトに触れてきたさまざまな人の意図を 周辺から読み取る。本人はもうそこにいないかも 62
63. コードは意外と長生きする • インターンで作った引用機能がつい最近になって書 き直されたはてなスター • 数日間の合宿で作ったデータベーススキーマが 10年生き残ったはてなブックマーク • 長生きしないものも（のほうが）多い 63
64. コードは自分の手を離れてしまう • うごメモはてなの思い出 ◦ 学生の頃からプログラミングが “得意” で、ぼくのかんがえる カッコイイコードを量産していた ◦ はじめてイチから書いたサービスで、愛着もひとしお • 年月を経てコードベースも関わる人も増えてくる ◦ だんだんと同僚が自分のコードで苦しんでる姿を見るように ◦ その頃にはチームを異動していて、直接手が出せない • プログラミングからソフトウェア開発へ 64
65. はてなのエンジニアのバリューズ https://developer.hatenastaff.com/entry/values • プロダクト志向 … 技術そのものよりもユーザへの価値を • コラボレーション … 他職種・他者をリスペクトする • おもしろさ … 創造性と好奇心を大切に • 学びとオープンネス … 深く学び、オープンな態度で共有する 65
66. Do: 楽しんで開発する • なんだかんだ言って、作ってる人が楽しんでることは重要 • つくっている間に創造性が発揮され、最初に想像もしていな かったよりよい解決につながることは多い • はてなはそういう会社だと思ってます ◦ 自分たちが使うものだからこそ、楽しんで作ることができ、 よいものにつながる 66
67. Do: たくさん失敗する • ソフトウェア開発を完全にマスターすることはない ◦ あることができるようになると、他のこともしたくなる • 知識だけではなくアート。経験してはじめて血肉になる • 今のうちにたくさん挑戦し、失敗してほしい 67
68. ソフトウェア開発へようこそ • 他者と一緒に、リアルな課題に臨みましょう • 今後の個人開発やインターンで存分に 楽しんでください 68
69. 69 以上!!!
70. 70 • Hatena Engineer Seminar #22 会社説明資料に載らないはてな @ 10/26 hatena.connpass.com/event/263147/ • 2023年のインターンもお楽しみに！ ◦ @hatenatech でお知らせします 告知
71. 71 終