$30 off During Our Annual Pro Sale. View Details »

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

    View Slide

  2. 2
    おはようございます

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  7. はてなの事業
    7

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  12. 12

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  19. 19
    第1章 コンテナ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  31. 31
    第2章 Web API

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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/

    ...
    35

    View Slide

  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/
    <
    < # Content
    ...
    36

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  69. 69
    以上!!!

    View Slide

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

    View Slide

  71. 71

    View Slide