Tweet
Tweet

Slide 1

Slide 1 text

1時間に詰め込む はてなインターン2022 株式会社はてな motemen 2022/10/15 技育祭2022 秋 1

Slide 2

Slide 2 text

2 おはようございます

Slide 3

Slide 3 text

3 この時間は… ● 2022/8-9 月に実施したはてなリモートインターンの 前半課程をギュッと1時間に圧縮してお届け ● 座学多めですが、たまに手を動かします ○ ターミナルがあるとよき ■ macOS/WSL/Linux ■ Docker・gh・ブラウザ ● 質問・コメントあればいつでもどうぞ

Slide 4

Slide 4 text

4 motemen ● 株式会社はてな CTO ● 学生時代に打ち込んだもの ○ アイドルマスター ● 代表作 ○ うごメモはてな / ghq

Slide 5

Slide 5 text

株式会社はてな ● 2001年 創業、2016年 東証マザーズ上場 ● 従業員 約200名 ○ うちエンジニア約80名 ● ミッション ○ 「『知る』『つながる』『表現する』で新しい体験を 提供し、人の生活を豊かにする」 5

Slide 6

Slide 6 text

インターネットと地続きな文化 ● ハンドル ○ ハンドルネーム（はてなID）で識別 ○ 社外のIDをそのまま社内に持ち込むパターンが多い ● オープン ○ グループウェア・社内日記でテキストによるコミュニケーション ○ 可能ならばインターネットにも ● ドッグフーディング ○ 自分たちで作ったサービスを自分たちでも使う 6

Slide 7

Slide 7 text

はてなの事業 7

Slide 8

Slide 8 text

コンテンツプラットフォーム ● いわゆる BtoC ● ユーザがコンテンツを発信・拡散 できるサービス ● はてなブログ・はてなブックマーク等 ● はてな発祥の地 8

Slide 9

Slide 9 text

コンテンツマーケティング ● 企業のマーケティングに不可欠なコンテンツ発信による マーケティング活動の支援 ○ オウンドメディアのトータル支援 ● はてなブログの法人プラン ○ はてなブログをtoBで提供 ○ はてなブログMedia・Business・ For DevBlog 9

Slide 10

Slide 10 text

● 開発・運用・運営の技術を提供する ○ サービスの受託・共同開発 ○ SaaS の提供 ● Mackerel ○ はてなのノウハウをベースにした監視サービス ● マンガ・ノベル・ゲーム ○ ジャンプ＋・コミックDAYS・カクヨム ○ 任天堂株式会社との共同案件 テクノロジーソリューション 10

Slide 11

Slide 11 text

CTOの仕事 ● ソフトウェアに依って立つ企業としての能力開発 ● はてなにおいては: エンジニア横断職種組織の長 ● 各チームがそれぞれのスコープで課題に取り組む中で ○ 何を共通化し、何を自律させるか？ ■ 社内共通基盤やノウハウ共有の仕組み ○ 中期的なスコープで乗り越えるべき技術的な課題は？ ■ コンテナ化の号令やセキュリティ強化の体制 ○ はてなのエンジニアはどうあるべき？ どうやってそうさせる？ ■ 育成や評価・ヒューマンマネジメント体制の設計 11

Slide 12

Slide 12 text

12

Slide 13

Slide 13 text

10年後の自分をつくる ● インターン生たちはいま ○ 多くはソフトウェアエンジニア ○ プロダクトマネージャ、CTO、研究者もいる ● 技術の変遷 ○ 2010s: DevOps、GitHub、AWS、JavaScript ■ (-) LAMP、jQuery、CoffeeScript… ■ (+) コンテナ、サーバレス、マイクロサービス、React、TypeScript 13

Slide 14

Slide 14 text

ソフトウェアエンジニアとしての基礎 ● 技術そのものと、その理論や背景 ○ どんな技術もいつか廃れていく。抽象的なもの・低レイヤのものは 腐りにくい ○ ここを抑えることで未知の問題にも応用が効く ● リーダーシップ・ヒューマンスキル ○ システムが解く課題は人間のもの。ソースコードを読み書きし、 運用するのも人間 ○ ここを避けては、よいソフトウェア開発はおこなえない 14

Slide 15

Slide 15 text

インターンが提供するもの ● 知識 ○ 深く狭く、よりは広く浅く。インデックスを張ってもらう ○ 表層的なものだけでなく理論や背景も加えて ■ 技術については、今後も生き残っていく蓋然性の高いものを ● 経験 ○ インターンが提供できる最大のもの ○ 可能な限り外部への提供を目指し、外部フィードバックを得る ■ デプロイ可能なチームであればデプロイまで 15

Slide 16

Slide 16 text

16 はてなリモートインターン2022 ● 3週間のカリキュラム ○ 1週目: 講義&課題 ○ 2-3週目: チーム配属&開発 ● 今日は前半課程のエッセンスをお届けします！

Slide 17

Slide 17 text

前半課程講義 ● Web API ● インフラ ● コンテナ ● マイクロサービス ● RDBMS ● フロントエンド ● Kubernetes ● デザイン 17

Slide 18

Slide 18 text

前半課程講義 ● Web API ● インフラ ● コンテナ ● マイクロサービス ● RDBMS ● フロントエンド ● Kubernetes ● デザイン 18

Slide 19

Slide 19 text

19 第1章 コンテナ

Slide 20

Slide 20 text

コンテナとは ● Docker で有名 ● プロセスを隔離・制限して実行するための環境 ○ アプリケーションとその依存をパッケージし、実行 ○ OSや他のプロセスから隔離されている ○ 軽量で、立ち上げも速い 20

Slide 21

Slide 21 text

Docker を使う ● docker pull # 公開されているイメージをダウンロード # イメージ = アプリケーション + 依存 ■ mysql:8, redis:7, debian:10, … ● docker run … # イメージを立ち上げてコマンドを実行 ● docker stop # 稼働中のコンテナを停止 21

Slide 22

Slide 22 text

自分のイメージを作る 22 ● docker build ○ Dockerfile の指示をもとにイメージを作成 FROM golang:1.19 WORKDIR /app COPY . . RUN go mod download RUN go build -o app ./cmd/app ENTRYPOINT ["./app"]

Slide 23

Slide 23 text

演習: はてなインターン応募課題 (2020) 󰳕 https://hatena.co.jp/intern2020 23

Slide 24

Slide 24 text

実行例 ● プログラムが、実行に必要なファイルを添えて実行された ○ https://github.com/hatena/apply-for-internship-2020 24

Slide 25

Slide 25 text

コンテナに至る歴史 ● 物理サーバ ○ 1つのOS内で複数プロセスが稼働 ○ 増減に物理的な作業が必要 ● 仮想化 ○ 物理マシン上にゲストOSを複数稼働 ○ リソースの融通が柔軟に ○ アプリケーションそれぞれにゲストOSが必要 ■ これがオーバーヘッドではあった 25

Slide 26

Slide 26 text

Docker (2013) ● dotCloud社（当時）がOSSとして公開 ○ オーバーヘッド低くプロセスを隔離 = コンテナ ○ Dockerfile による再現性のある環境構築 ● 開発用から始まり、CI、本番にも ● ちなみにコンテナ技術は jails, LXC など以前からあった ○ Docker の開発者体験のよさが奏功した形 26

Slide 27

Slide 27 text

“脱ペット化” from インフラ講義 ● 物理サーバー ○ 名前: aoyama, inunaki, … ○ どれだけ長く安定して稼働させるかが重要。大切にメンテナンスする ● 仮想サーバー ○ 名前: blog-app-03, bookmark-db-02, … ○ うまく動かなければ作り直す ● コンテナ ○ 名前: antenna-app-deployment-bc697497b-66qx9, … ○ 集合として期待した状態になるように維持・収束される ■ eg. Kuberenetes 27

Slide 28

Slide 28 text

コンテナの使い所 (本番) ● 各種クラウドプラットフォームがコンテナを デフォルトでサポート ○ Amazon ECS, Google App Engine, … ○ 「コンテナ」のインタフェースが決まっているので、可搬性がある ● サーバの負荷など必要に応じてコンテナを増減 ○ cf. マシン調達 28

Slide 29

Slide 29 text

コンテナの使い所 (開発) ● ローカル開発に必要なミドルウェアを起動 ● Dev Container でチームで共通の開発環境を用意 ○ インターンでは GitHub Codespaces を使うところも ● コンテナをデプロイすれば、手元と本番の環境を一致させられる ● ポートフォリオとしてのコードが Docker で立ち上がったら親切 29

Slide 30

Slide 30 text

Twelve-Factor App ● https://12factor.net/ja/ ○ 環境変数による設定 eg. $PORT ○ ログは標準出力に ○ 廃棄可能なものとして扱う ○ etc. 30

Slide 31

Slide 31 text

31 第2章 Web API

Slide 32

Slide 32 text

32 1. HTTP ● URL の先頭にでてくるアレ 👉 http://… ● HTTP = HyperText Transfer Protocol ● ウェブを支えるプロトコル ● Web API の基礎を押さえていきましょう

Slide 33

Slide 33 text

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の標準化

Slide 34

Slide 34 text

netcat で息吹を感じる 󰳕 % nc hatenablog.com 80 GET / HTTP/1.1 [改行] Host: hatenablog.com [改行] [改行] 34

Slide 35

Slide 35 text

実行例 % 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/ ... 35

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

HTTP プロトコルの進化 ● ウェブアプリケーションの高度化により、 プロトコル自体を改善する需要が高まる ○ メディアファイルの増加、TLS、… ○ HTTP/1.1 … テキストフォーマット on TCP ○ HTTP/2 … バイナリフォーマット on TCP ○ HTTP/3 … バイナリフォーマット on QUIC 37

Slide 38

Slide 38 text

HTTP/2, HTTP/3 ● セマンティクスは1.1と同じ ● HTTP/2 ○ ひとつのTCPコネクションの中に複数のリクエスト・ レスポンスを詰める ● HTTP/3 ○ UDP上でTLSを含めた通信を実現 ○ パケットの順番待ちや暗号化ハンドシェイクを減らす 38

Slide 39

Slide 39 text

2. API ● Application Programming Interface ● プログラムのためのインタフェース ○ ライブラリ対プログラム、 サービス対サービス、サービス対ユーザ ● 不特定多数向け (LSUD) or 特定少数向け (SSKD) で性格 が変わる ○ LSUD: Twitter API、GitHub API ○ SSKD: スマホアプリ向けAPI etc. 39

Slide 40

Slide 40 text

よくある Web API ● REST ● GraphQL ● gRPC 40

Slide 41

Slide 41 text

(i) REST ● HTTPの作法にうまく乗った流儀 ● URL is リソース ○ ユーザ、投稿、タスク、… ● GET/POSTなどのHTTPメソッドを動詞に ○ リソースの CRUD に対応させる ■ CRUD = Create/Read/Update/Delete 41

Slide 42

Slide 42 text

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メソッドも直観的

Slide 43

Slide 43 text

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" }

Slide 44

Slide 44 text

OpenAPI 44 ● APIの仕様をYAMLやJSONで記述 ● Swaggerというツールセットを使用 ○ コード生成も可能 ● 要求が変化していく中で、実装とドキュメントを一 致させていくことがより重要に ○ → GraphQL や gRPC では標準のワークフロー

Slide 45

Slide 45 text

REST Pros/Cons ● Pros ○ リソース指向で直接的 ○ サーバサイドの実装が素直 ■ 複雑なことをしたければクライアント側で頑張る ● Cons ○ クライアント側で頑張る必要がある ■ タイムラインのユーザ情報をN回取得しにいく…？ ○ クライアントの要件に柔軟な対応をしづらい ■ ?with_user=1 みたいなパラメタが無限に増えがち 45

Slide 46

Slide 46 text

(ii) GraphQL ● Meta (Facebook) 製 ● クライアント側が欲しいデータを指示する ○ ラウンドトリップ数を減らす ■ タイムラインの投稿とユーザの情報をまとめて1リクエストに ○ オーバーフェッチングを減らす ■ GET api.github.com/users/motemen のキーは32個もある ● レスポンスはJSON 46

Slide 47

Slide 47 text

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 生成する

Slide 48

Slide 48 text

GraphQL クエリ 48 query GetFirstIssue { repository(name: "Hatena-Intern-2020", owner: "hatena") { issue(number: 1) { author { login } body title } } } ● クエリの形が結果のJSONの 形を規定する ○ クライアントに必要なデー タを過不足なく取得 ○ ネストしたデータも一発

Slide 49

Slide 49 text

GitHub GraphQL API 󰳕 % gh api graphql \ -f query='query { viewer { name, repositories { totalCount } } }' { "data": { "viewer": { "name": "Hironao OTSUBO", "repositories": { "totalCount": 443 } } } } 49

Slide 50

Slide 50 text

演習: はてなインターン応募課題 (2022) 󰳕 https://hatena.co.jp/recruit/intern/2022 50

Slide 51

Slide 51 text

実行例 ● 結果はエラーになりますが… ● スキーマ情報からどうクエリしたらいいかわかる 51

Slide 52

Slide 52 text

(iii) gRPC ● Google発 ● バイナリベースのProtocol BuffersをIDLに ● 分散アプリケーションを開発する目的 52

Slide 53

Slide 53 text

RPC ● = Remote Procedure Call ● プログラム中の一部の手続きを 別のプログラムから実行する仕組み ● IDL (Interface Definition Language) ○ 呼び出す側と呼び出される側の規格 53

Slide 54

Slide 54 text

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 ● 複数の言語のコード（サーバ・ クライアント）を生成 可能 ● 多言語サービス間通信に向いて いる

Slide 55

Slide 55 text

それぞれの使い所 ● GraphQL ○ 柔軟かつ効率的にデータを取得したい ○ 例: スマホアプリやWebフロントエンド向けAPI ● gRPC ○ ネットワーク越しのシステム間で高スループットを実現したい ○ 例: 社内マイクロサービス間通信 ● REST ○ 単機能と小規模なケースで、上記の複雑さが割に合わない場合 ○ 例: フロントエンドリッチでない補助的な機能など 55

Slide 56

Slide 56 text

第1章・第2章 完 ● 現代ウェブを支える技術について駆け足で見ました ○ 興味を持った部分は掘り下げてみてください ● コンテナ ○ 常にこれを使うのがオススメ ● GraphQL ○ フロントエンドリッチなウェブアプリ・モバイルアプリを作るなら 検討の価値あり ○ ツールチェインにキャッチアップするコストはかかります 56

Slide 57

Slide 57 text

終章 ソフトウェア エンジニアとして 57

Slide 58

Slide 58 text

既知の課題から未知へ ● 講義パートは既知の課題 ○ 誰かが解いたことがあり、だいたい何かしら正解がある ● 現実世界では課題が未知のものになる ○ ユーザに届けるもの、検証するもの ○ 何が正解か (つくるまで|届けるまで) わからない ■ なんなら変わることだってある ○ チーム開発を通じて課題を明らかにしていく 58

Slide 59

Slide 59 text

元来、ソフトウェアは不確かなもの ● 形がない、体験を提供する何か。 動いている様子をつぶさに観察することも難しい ○ 開発の過程で、コードという形で書き残されはする ○ 設計されているときに、開発チームの頭の中にも現れる ○ 使われているときに、ユーザのメンタルモデルとして現れる ● 「何がほしかったのか」はつくってみないと分からない 59

Slide 60

Slide 60 text

Do: 素早いイテレーションを回す ● 不確かなものだから、できるだけ早くフィードバックを得る ○ 早い段階で見せられるものを届ける ○ はてなだと1週間～2週間のタイムボックスで考えることが多い 60

Slide 61

Slide 61 text

Do: 他者と関わる ● 「早く行きたければ、一人で行け。遠くまで行きたければ、 　皆で行け」 ○ 大きなものを長くつづけていくには、チームが必要 ● 最終的な価値を作りあげるのにも、他者の手が数多く入る ○ 課題の発見・理解 ○ 体験のデザイン ○ ユーザとのコミュニケーション ○ 事業としての成立 61

Slide 62

Slide 62 text

Do: コードを読む ● コードは人間と機械のあいだの言葉 ● ……だけではなく、人間と人間のあいだの言葉 ● 過去にプロダクトに触れてきたさまざまな人の意図を 周辺から読み取る。本人はもうそこにいないかも 62

Slide 63

Slide 63 text

コードは意外と長生きする ● インターンで作った引用機能がつい最近になって書 き直されたはてなスター ● 数日間の合宿で作ったデータベーススキーマが 10年生き残ったはてなブックマーク ● 長生きしないものも（のほうが）多い 63

Slide 64

Slide 64 text

コードは自分の手を離れてしまう ● うごメモはてなの思い出 ○ 学生の頃からプログラミングが “得意” で、ぼくのかんがえる カッコイイコードを量産していた ○ はじめてイチから書いたサービスで、愛着もひとしお ● 年月を経てコードベースも関わる人も増えてくる ○ だんだんと同僚が自分のコードで苦しんでる姿を見るように ○ その頃にはチームを異動していて、直接手が出せない ● プログラミングからソフトウェア開発へ 64

Slide 65

Slide 65 text

はてなのエンジニアのバリューズ https://developer.hatenastaff.com/entry/values ● プロダクト志向 … 技術そのものよりもユーザへの価値を ● コラボレーション … 他職種・他者をリスペクトする ● おもしろさ … 創造性と好奇心を大切に ● 学びとオープンネス … 深く学び、オープンな態度で共有する 65

Slide 66

Slide 66 text

Do: 楽しんで開発する ● なんだかんだ言って、作ってる人が楽しんでることは重要 ● つくっている間に創造性が発揮され、最初に想像もしていな かったよりよい解決につながることは多い ● はてなはそういう会社だと思ってます ○ 自分たちが使うものだからこそ、楽しんで作ることができ、 よいものにつながる 66

Slide 67

Slide 67 text

Do: たくさん失敗する ● ソフトウェア開発を完全にマスターすることはない ○ あることができるようになると、他のこともしたくなる ● 知識だけではなくアート。経験してはじめて血肉になる ● 今のうちにたくさん挑戦し、失敗してほしい 67

Slide 68

Slide 68 text

ソフトウェア開発へようこそ ● 他者と一緒に、リアルな課題に臨みましょう ● 今後の個人開発やインターンで存分に 楽しんでください 68

Slide 69

Slide 69 text

69 以上!!!

Slide 70

Slide 70 text

70 ● Hatena Engineer Seminar #22 会社説明資料に載らないはてな @ 10/26 hatena.connpass.com/event/263147/ ● 2023年のインターンもお楽しみに！ ○ @hatenatech でお知らせします 告知

Slide 71

Slide 71 text

71 終