Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
1時間に詰め込むはてなインターン2022 技育祭2022秋 / Hatena Intern in 1 Hour Geeksai 2022 Autumn
Hatena
October 18, 2022
Technology
0
130
1時間に詰め込むはてなインターン2022 技育祭2022秋 / Hatena Intern in 1 Hour Geeksai 2022 Autumn
技育祭2022秋
https://talent.supporterz.jp/geeksai/2022autumn/
での発表です
Hatena
October 18, 2022
Tweet
Share
More Decks by Hatena
See All by Hatena
本質を理解してデザインに取り組む / Hatena Engineer Seminar #23 aoym_05
hatena
0
410
はてなリモートインターンシップ2022 Kubernetes 講義資料
hatena
0
93
はてなリモートインターンシップ2022 フロントエンドブートキャンプ 講義資料
hatena
0
120
はてなリモートインターンシップ2022 RDBMSブートキャンプ 講義資料
hatena
0
85
はてなリモートインターンシップ2022 Web API 講義資料
hatena
0
160
はてなリモートインターンシップ2022 インフラ 講義資料
hatena
4
2.2k
はてなリモートインターンシップ2022 マイクロサービス 講義資料
hatena
0
89
はてなリモートインターンシップ2022 コンテナ 講義資料
hatena
0
89
はてなの選考設計、その深奥に迫る! / Recruiment Process Deep Dive Seminar #22
hatena
1
780
Other Decks in Technology
See All in Technology
re:Invent2022 前後の Amazon EventBridge のアップデートを踏まえつつ、情シスの仕事をより楽しくしたい話。 / EventBridge for Information Systems Department
_kensh
2
800
OpenShift.Run2023_create-aro-with-terraform
ishiitaiki20fixer
1
360
YouTuber も編集マンもクラウド使って編集しよう。クラウド編集のキホン
eijikominami
0
120
「一通りできるようになった」その先の話
hitomi___kt
0
150
ユーザーテストガイドライン VERSION 2.0
kouzoukaikaku
0
1.7k
cdk deployに必要な権限ってなんだ?
kinyok
0
210
Deep Neural Networkの共同学習
hf149
0
360
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
3
16k
DNS権威サーバのクラウドサービス向けに行われた攻撃および対策 / DNS Pseudo-Random Subdomain Attack and mitigations
kazeburo
5
1.4k
初めてのデータ移行プロジェクトから得た学び
tjmtmmnk
0
430
オンプレk8sとEKSの並行運用の実際
ch1aki
0
320
2年で10→70人へ! スタートアップの 情報セキュリティ課題と施策
miekobayashi
1
720
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
346
17k
In The Pink: A Labor of Love
frogandcode
132
21k
Infographics Made Easy
chrislema
235
17k
A Tale of Four Properties
chriscoyier
149
21k
Intergalactic Javascript Robots from Outer Space
tanoku
261
26k
The Cult of Friendly URLs
andyhume
69
5.1k
How to name files
jennybc
47
73k
Music & Morning Musume
bryan
37
4.7k
The Web Native Designer (August 2011)
paulrobertlloyd
76
2.2k
GraphQLとの向き合い方2022年版
quramy
20
9.9k
Building a Scalable Design System with Sketch
lauravandoore
451
31k
What's in a price? How to price your products and services
michaelherold
233
9.7k
Transcript
1時間に詰め込む はてなインターン2022 株式会社はてな motemen 2022/10/15 技育祭2022 秋 1
2 おはようございます
3 この時間は… • 2022/8-9 月に実施したはてなリモートインターンの 前半課程をギュッと1時間に圧縮してお届け • 座学多めですが、たまに手を動かします ◦ ターミナルがあるとよき
▪ macOS/WSL/Linux ▪ Docker・gh・ブラウザ • 質問・コメントあればいつでもどうぞ
4 motemen • 株式会社はてな CTO • 学生時代に打ち込んだもの ◦ アイドルマスター •
代表作 ◦ うごメモはてな / ghq
株式会社はてな • 2001年 創業、2016年 東証マザーズ上場 • 従業員 約200名 ◦ うちエンジニア約80名
• ミッション ◦ 「『知る』『つながる』『表現する』で新しい体験を 提供し、人の生活を豊かにする」 5
インターネットと地続きな文化 • ハンドル ◦ ハンドルネーム(はてなID)で識別 ◦ 社外のIDをそのまま社内に持ち込むパターンが多い • オープン ◦
グループウェア・社内日記でテキストによるコミュニケーション ◦ 可能ならばインターネットにも • ドッグフーディング ◦ 自分たちで作ったサービスを自分たちでも使う 6
はてなの事業 7
コンテンツプラットフォーム • いわゆる BtoC • ユーザがコンテンツを発信・拡散 できるサービス • はてなブログ・はてなブックマーク等 •
はてな発祥の地 8
コンテンツマーケティング • 企業のマーケティングに不可欠なコンテンツ発信による マーケティング活動の支援 ◦ オウンドメディアのトータル支援 • はてなブログの法人プラン ◦ はてなブログをtoBで提供
◦ はてなブログMedia・Business・ For DevBlog 9
• 開発・運用・運営の技術を提供する ◦ サービスの受託・共同開発 ◦ SaaS の提供 • Mackerel ◦
はてなのノウハウをベースにした監視サービス • マンガ・ノベル・ゲーム ◦ ジャンプ+・コミックDAYS・カクヨム ◦ 任天堂株式会社との共同案件 テクノロジーソリューション 10
CTOの仕事 • ソフトウェアに依って立つ企業としての能力開発 • はてなにおいては: エンジニア横断職種組織の長 • 各チームがそれぞれのスコープで課題に取り組む中で ◦ 何を共通化し、何を自律させるか?
▪ 社内共通基盤やノウハウ共有の仕組み ◦ 中期的なスコープで乗り越えるべき技術的な課題は? ▪ コンテナ化の号令やセキュリティ強化の体制 ◦ はてなのエンジニアはどうあるべき? どうやってそうさせる? ▪ 育成や評価・ヒューマンマネジメント体制の設計 11
12
10年後の自分をつくる • インターン生たちはいま ◦ 多くはソフトウェアエンジニア ◦ プロダクトマネージャ、CTO、研究者もいる • 技術の変遷 ◦
2010s: DevOps、GitHub、AWS、JavaScript ▪ (-) LAMP、jQuery、CoffeeScript… ▪ (+) コンテナ、サーバレス、マイクロサービス、React、TypeScript 13
ソフトウェアエンジニアとしての基礎 • 技術そのものと、その理論や背景 ◦ どんな技術もいつか廃れていく。抽象的なもの・低レイヤのものは 腐りにくい ◦ ここを抑えることで未知の問題にも応用が効く • リーダーシップ・ヒューマンスキル
◦ システムが解く課題は人間のもの。ソースコードを読み書きし、 運用するのも人間 ◦ ここを避けては、よいソフトウェア開発はおこなえない 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 <image> # 公開されているイメージをダウンロード # イメージ
= アプリケーション + 依存 ▪ mysql:8, redis:7, debian:10, … • docker run <image> <command> … # イメージを立ち上げてコマンドを実行 • docker stop <container> # 稼働中のコンテナを停止 21
自分のイメージを作る 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"]
演習: はてなインターン応募課題 (2020) https://hatena.co.jp/intern2020 23
実行例 • プログラムが、実行に必要なファイルを添えて実行された ◦ https://github.com/hatena/apply-for-internship-2020 24
コンテナに至る歴史 • 物理サーバ ◦ 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. Kuberenetes 27
コンテナの使い所 (本番) • 各種クラウドプラットフォームがコンテナを デフォルトでサポート ◦ 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
32 1. HTTP • URL の先頭にでてくるアレ 👉 http://… • HTTP
= HyperText Transfer Protocol • ウェブを支えるプロトコル • Web API の基礎を押さえていきましょう
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の標準化
netcat で息吹を感じる % nc hatenablog.com 80 GET / HTTP/1.1
[改行] Host: hatenablog.com [改行] [改行] 34
実行例 % 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
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
HTTP プロトコルの進化 • ウェブアプリケーションの高度化により、 プロトコル自体を改善する需要が高まる ◦ メディアファイルの増加、TLS、… ◦ HTTP/1.1 …
テキストフォーマット on TCP ◦ HTTP/2 … バイナリフォーマット on TCP ◦ HTTP/3 … バイナリフォーマット on QUIC 37
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 • gRPC 40
(i) REST • HTTPの作法にうまく乗った流儀 • URL is リソース ◦ ユーザ、投稿、タスク、…
• GET/POSTなどのHTTPメソッドを動詞に ◦ リソースの CRUD に対応させる ▪ CRUD = Create/Read/Update/Delete 41
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メソッドも直観的
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" }
OpenAPI 44 • 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個もある • レスポンスはJSON 46
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 生成する
GraphQL クエリ 48 query GetFirstIssue { repository(name: "Hatena-Intern-2020", owner: "hatena")
{ issue(number: 1) { author { login } body title } } } • クエリの形が結果の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/2022 50
実行例 • 結果はエラーになりますが… • スキーマ情報からどうクエリしたらいいかわかる 51
(iii) gRPC • Google発 • バイナリベースのProtocol BuffersをIDLに • 分散アプリケーションを開発する目的 52
RPC • = Remote Procedure Call • プログラム中の一部の手続きを 別のプログラムから実行する仕組み •
IDL (Interface Definition Language) ◦ 呼び出す側と呼び出される側の規格 53
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 • 複数の言語のコード(サーバ・ クライアント)を生成 可能 • 多言語サービス間通信に向いて いる
それぞれの使い所 • 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/26 hatena.connpass.com/event/263147/
• 2023年のインターンもお楽しみに! ◦ @hatenatech でお知らせします 告知
71 終