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