Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Hatena
October 18, 2022

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

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

Hatena

October 18, 2022
Tweet

More Decks by Hatena

Other Decks in Technology

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
  12. 12

  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 終