自作DBの本をだいたい完走した

自作 DB を作ろうって洋書をだいたい完走しましたので、感想を書こうと思います。 参考文献とか練習問題は一切やってません。
(だいたいって言っているのは、Ruby への書き換えをしてたんですが、13.14.15 章はアルゴリズムの話で、理屈が理解できれば書き換えしなくてもいいかと思って止めた) link.springer.com

本の感想

年に 1 回くらい自作 XX を始めて、途中で飽きてを繰り返してるんですが、その中でも自作 DB は結構面白かったなというか進めやすかったなと思いました。
理由はいくつかあって

• web アプリケーションエンジニアにとっては距離が近い題材だったので、微妙にしか知らない単語が次々出てきてよかった
• 自作 XX は、初手アセンブラを書かされたりすることがそこそこあって、面白にたどり着くまでに最初の方で心が折られる事が多いが、今回はそんなことがなかった
  • 自作 DB は初手から print debug ができて嬉しい...
• 教育用のコードってことで、仕様が実装しやすい状態になっていてわかりやすかった
  • 自作ファミコンは、(当時のスペックからすると仕方ないけど)すごいややこしかった...
    • 逆に実装しきってしまえば、実際売っているカセットがそのまま動くのは良い(私はその前に力尽きたけど)

具体的な内容としては、ログ周りがどう実装されているとか、Explain を打ったときに裏側でやってそうなこととかの実装がわかっておもろかったです。

進め方

今回は ChatGPT におんぶにだっこで進めました。
以前にもブログを書いたんですけど、英語が得意ではないので翻訳をやってもらいましたが、それなりに自然な日本語で翻訳されるので進みが良かったです。

k-murakami0609.hatenablog.com

また、Java -> Ruby への変換もやってもらって、難しくない部分はかなり精度高く変換してくれたなーという感じでした。
AI が 8 割コードを書く時代が来るって予想されているのもわかるなーって感じです。
ただ、これはコードを書く必要がなくなるという感じではなく、chatgpt 以前にも IDE が 3~4 割コードを書いてくれていると思っていて、それの範囲が広がるだけなのかなという印象を持っています。少なくとも今のところは。

そのほかでは、今回は読書中にメモを取りながら進めたのも良かったなと思っています。
私は悪い意味で文章を斜め読みしてしまって、内容が頭に入ってこないことが多いのですが、メモを取ることで迷子にならずに済んだ気がします。

まとめ

今回時間があったので、集中してガットやってところ 2 ~ 3 週間程度で完走できたので、興味がある人は結構おすすめです。
(GW 中に rust で作ってたけど、1 から作り直した)

次はフロントエンドをちゃんと勉強し直したいけど、何やれば良いのかなやんでいる

GWは自作DBをやってた

年1くらいで低レイヤーとか自作XXにチャレンジすることをやっており、今年のGWは自作DBにチャレンジしていたのでそれについての日記です。(まだ全然終わってないです)

WEB+DB PRESS

最初は WEB+DB PRESS の「作って学ぶ RDBMS のしくみ」をやりました。
WEB+DB PRESS Vol.122 | WEB+DB PRESS編集部 | コンピュータ・IT | Kindleストア | Amazon

この本はわずか100ページ程度で、情報が適切に取捨選択され、全体像が把握しやすくなっています。文章も読みやすく、約2～3時間でざっと読むことができました。
これを実装しても良いんですけど、GWの時間余りそうだな！と思ったので、別途本格的な本を買ってやることにしました。

Database Design and Implementation

続いて取り組んだのは Database Design and Implementation という洋書を購入して、今も読み進めています。 link.springer.com

まずは実装する前にざっくりでも良いので最後まで読んでみようをやっています。 現在はChapter 5のTransaction Managementまで読み終わって、WALとかロックとかの実装がなんとなく理解できたという状態になりました。

で、本の内容については読み終わったら書くとして、今回は進捗が良かったなと思っておりそれについて書いてみます。

今回の進め方で良かったこと

ChatGPT に翻訳してもらって洋書を読む体験が良い

私は英語が得意ではないので機械翻訳に頼って読み進めるしかないのですが、今回 ChatGPT に翻訳してもらいながら洋書を読んだところ、一週間で160ページくらいと私にしてはかなりハイペースに進められました。 最初はDeepLの pdf まるごと翻訳を使って読んでました。 これは言っていることは理解できるが日本語として不自然な部分があり、それが学習のノイズになっていたため途中からChatGPT(GPT-4)で翻訳してもらったところスピードアップできました。

やり方としては1,2センテンスごとコピペして「以下を日本語に翻訳してほしい。${text}」-> 内容を理解するを繰り返してました。 多少面倒ではあるのですが、ChatGPT に翻訳を頼むと本文にないことも付け足してくることが多々あり、一度に翻訳する分量がある程度少ないほうが異常に察知できるので、むしろこっちのほうが楽でした。

また、この本とChatGPTの相性という面でいうと、翻訳が怪しかったとしても最終的には実装を見れば良いので安心感はありました。

長期休暇前に長期休暇中にやりたいことを着手しておく

これまでの経験から、私の長期休暇で進捗が上がらないパターンが2つありました。 一つは「いざ長期休暇になってやってみたらそんなに興味がある内容じゃなかった。そこから他のテーマを探すが見つからない or 見つけるころには長期休暇が終わる」もう一つは「効率良く進める方法を追い求めて色々やった結果、着手する前に燃え尽きる(飽きる)」です。
特に後者に関しては今回も例にもれず Obsidian を使おうとしてみたり、pdf から文章を抽出して ChatGPT に投げるスクリプト書いてみたりしてました。いつもだったらそこで燃え尽きることも多かったです。
しかし、今回はGWの2週間前から取り組んでいたため、一旦ちゃんと燃え尽きた後に再度やる気が出てきて、GWに入るころには「素直に本を読む方が良い！」と軌道修正できたのでGW中は進捗を出すことができました。(最初からそうすればいいじゃんっていうのはそう)

おわりに

あと2ヶ月くらいあれば読み終えそう & 実装もできそうなんですけど、それまでモチベーションが持つかなーどうかなーという感じ。

新人研修で「退職後に電話をかけられたくなかったらドキュメントを残せ」と教えられた

はるか昔、新人研修の2 ~ 3日目にこれを教えられました。
これがすべてではないとは思いますが、ある一側面としてはそのとおりだなと思って過ごしています。

work out loudやPRを一日一個出すみたいな、自分の現在地を発信しながら仕事をすることで似たような効果があるなと思っています。
(今の会社では絶対にそんなことはないけど) チームに情報を残してなくて知っている人が自分しかいないために、体調不良のときも代わりがいないで作業しろと言われるのは困るので、現在地を発信しながら仕事をしたいなーと改めて思いました。

スクラムファーストインプレッション

初めてがっつりスクラムやっているチームで働く機会があったので、スクラムの印象について書いてみます。

思っていたよりはだいぶ良かったというのが正直な感想です。 (以前やったスクラム崩れがあんまり機能してなかったのもあり、あんまり印象が良くなかった)

何が良かったかというと

• プロセスの中にタスクの見積もり(プランニングポーカー)が組み込まれている
  • 見積もりをするためには事前に仕様や設計の方向性が固める必要があり、それが仕組みになっている
  • プランニングポーカーをすることで、実装する前に方向性を修正するチャンスがある
• 未来のタスクを分解しすぎなくてすむ
  • 今までは若いチームメンバーとかは、結構先のタスクまで詳細に分解しようとして苦労していた
    • が、どこまで分割すればという感覚を教えるのが難しい
  • スクラムだとスプリントバックログに必要なものだけ詳細に分割すればいいので、そこの心配がない
• ベロシティを計測しており、何も無いよりは未来の見通しが立つ
• 振り返りに関しては既にやっているが最高

では、自分はスクラムしたいか？というとうーーんとなっています

• タスクを上から順に潰していく必要があるが、好きな順番でやらせてくれって思う
  • 脳内にいくつかタスクを詰め込んだ状態で作業したい
• タスクが個人からチームの持ち物になったり、タスクのサイズが小さくなる
  • 個人的に業務で使う技術は予めがっつり勉強したいと思っているので、どれを深堀りしたほうがいいんだろうって悩んでしまう
  • 俺が作った感が薄れる
• プロセスを決めることでメンバーのアウトプットのクオリティを均質化できるけど、元々質がある程度が揃えられているなら自体がプロセスが重い分遅くはなりそうという所感
  • メンバーのスキルセットによるが、ここまでやらんでいいのでは？と思う
• あと個人的に基本的に管理したくないし、されたくないという感情があるんだと思う

現状の結論としては、マネージャーの帽子を被ると良い手札が増えたなって思いがある。一方でエンジニアの帽子を被るとあんまり興味ないなという感想を持ちました。

過去に所属してたチームに転生したら導入したいもの

これははてなエンジニアアドベントカレンダー2022 41日目の記事です。昨日は id:nakiwo の 1月9日、初代iPhone発表の日にiPhone SDK 2時代をふりかえる - Cocoaメモ でした。

私の初 iphone は 3G のときで、赤外線による連絡先の交換ができずに、相手に負荷をかけてしまったな...という記憶があります。

さて、私は何度か転職をしているため、いくつかのチームを経験しております。
その当時は困っていたけど、今となっては解決策を知ったことの中でコスパが良かったものを列挙してみようと思います。

レビュアーの自動割り当て + slack 通知

これは github の 機能です

自動割り当てを有効化すると、TeamがPull Requestのレビューをリクエストされた場合、そのチームはレビュー担当者から外され、指定されたTeamメンバーの一部がそのTeamの代わりに割り当てられます

Teamのコードレビュー設定の管理 - GitHub Docs

レビューを待っている時間は、開発している中でも退屈な時間に挙げられると思います。
相手が忙しいならまだしも、レビューしてほしいことに気づいてもらえてないってことが多々ありました。

これを導入してからは、レビューの待ち時間がかなり改善しました。 またレビューイを自動で選んでくれるので、レビューの問題点であるレビューしてくれる人が偏るとかも解消してくれるのがありがたいです。

機能フラグ

機能フラグの説明はこのサイトがわかりやすかったです

機能フラグ (一般に機能トグルとも呼ばれる) は、新しいコードをデプロイすることなく実行時に選択機能のオンとオフを切り替える、ソフトウェアエンジニアリング手法です

https://www.atlassian.com/ja/continuous-delivery/principles/feature-flags

たったそれだけ？って感じなんですけど、結構多くの問題を解決してくれております。

一つは、開発完了するまでフィーチャーブランチで作業して、リリースしたいタイミングでメインブランチにマージするという運用をしている時がありました。 ご想像の通り、マージ時にはコンフリクトが大量発生してどうしようもなかったんですが、機能フラグはこの問題を解決してくれます。

あとは、新機能の公開が決まっているときなどは、前日に全ての作業を終わらせて当日はフラグを切り替えるだけにしておくと、当日バタバタせずにすみます。 CDの機嫌によって公開時間が前後するのも防げるのもありがたいです。

さらに、オンとオフだけではなく、管理者限定だけ新しい機能を試せるみたいにしておくと、本番公開前に軽く動作確認などができるもの良い点だと思います。

サーバー監視

所属している会社からポジショントークっぽいけど、導入してない状態でどうやってサーバーの運用するんだっけ...ってなっています。
定期的に ssh でサーバーにログインしてディスク容量を確認したり、悲鳴ベースで対応していたっけなという記憶があるのですが、明らかに監視を入れたほうが日々の運用作業が少なくなって良いかなと思っております。

以上、3点になります！

明日のアドベントカレンダーは同じチームで働いている id:anatofuz です！

仕様や実装方針を決めに行く時に気をつけていること

チームでWebアプリケーションの開発していると、未確定の仕様を確定させたい時、実装の方針に悩んでいる時など、プロジェクトオーナー(相当の人)やテックリードや他のチームメンバーの判断を仰ぎたいときがあります。 その時はなるべく早く返事がほしいし、認識の齟齬から誤った答えが帰ってくることはなるべく避けたいですよね。

私は大抵情報をテキストにまとめて相手に送って返事を待っているんですが、スムーズに返事をもらうために「誰に何の情報を伝える必要があるか考えること」「相手と持っている情報を揃えること」「文章自体の可読性を上げること」を気をつけております。 それぞれについて少しまとめてみます。

誰に何の情報を伝える必要があるか考えること

こういう時の文章構成は大抵「現状の整理や問題点の提示」-> 「解決案の列挙」-> 「意見ください」みたいな流れになっている事が多いです。
解決案にはメリデメを書いており、例えば工数は少なく済むけどユーザー体験は最高とは言えないとか、工数はかかるが今度の拡張性を考えるとやっといたほうが良いみたいな、さまざまなトレードオフが書いてあります。

別の話題として、Webアプリケーションの開発では、最終決定権はプロジェクトオーナーにあるとは言っても、通常時の決定権や責任範囲は分散されているように思えます。 例えば弊チームでは、プロデューサーがお金周り、ディレクターがサービス仕様や工数管理や品質管理、リードデザイナーが体験設計、テックリードが実装方針などなど別れています。

ここで問題になってくるのが、トレードオフが各担当職種の責任範囲をまたいでいることが多いので、誰か一人がOKって言えば方向性が決まるといった話ではなくなっています。 また、それぞれの立場によって判断に必要な情報・不要な情報が異なってきます。

この意識を忘れてしまうと、ディレクターにも知っていてほしい情報をエンジニアだけがわかる文章で書いてしまうことがあったり、ディレクターには不要な情報が多くてどこを読めばいいの？みたいな文章になったりします。そのため、この人にはここを読んでほしいとか、この人にはこの情報が必要だよなみたいなことを考えて文章を書いています。

相手と持っている情報を揃えること

解決案の列挙を行う前に

自分がよくやってしまっていたのは「解決案の列挙」は力を入れて書いたんですけど、「現状の整理や問題点の提示」が疎かになっているパターンです。
これは、情報共有不足だったり、問題について相手が正しく理解できてないみたいな状態を想定しています。
この状態だと、何の解決策なのか理解してもらうことができなかったり、最悪ケースだと前提情報が足りなかったために誤った結論が導き出されたりします。

相手が正しく理解できてないは、あんまりこれだといった対策は思いつけてないです。
今ひねり出したものとしては、エンドユーザーにどう影響するかを説明するのが良いのかなと思いました。
DBがシャットダウンしたと説明するより、ユーザーがサイトを閲覧できませんと説明したほうが伝わりやすそう。

解決案のメリデメには可能な範囲で具体的な数字を書いておく

プロジェクトオーナーはエンジニアでないケースもあるので、例えば「他の案に比べて工数がかかる」と書かれた時に、どの程度が想像するのが難しいことがあります。 具体的に規模感がわかるならN日と書いたり、わからないなら見積もってみないとわからないくらい工数がかかりそうみたいに伝えるようにしています。
工数以外には処理速度とか費用とかでしょうか。UXへの影響とか技術的な負債具合とかは具体化が難しいんですけど、前者なら仮実装したりして伝えたりしています。

文章自体の可読性を上げること

ソースコードは可読性が低いと、このコードで実現したいことは何かを理解するのに時間がかかります。 相談の文章も一緒で可読性が低いと、相手が解読するまでに時間がかかってしまい、返事までの時間がかかってしまったり意図を取り違えたりします。

箇条書きで書くとこんなことを気をつけてます。

• チーム内に既存のフォーマットがあれば利用する
• 話の本線と補足事項はひとまとめにしない
• 文章は意味が伝わるなら、読み飛ばすコストがかかるので短い文章のほうが良い。
• 意味が伝わらないのなら、相手が行間をエスパーする必要があるので省略しないほうが良い

このあたりのことは本が色々出てそうなので、読んでみるのも良いかもしれません。

www.amazon.co.jp

終わりに

毎回こんなことを考えて相談を書いているわけではないんですけど、気をつけていることを書いてみました。
また、つらつら書いたんですけど、結局チームメンバーとの関係性とか慣れとかの部分も大きいので、一概に言うのは難しいよなーとは思いました。

github actions で ci が通ったら reviewers を自動でアサインできるようにしてみた

PR のレビュー依頼したいけど CI 通ってない。CIが通ったら依頼を出そうと思って忘れることがそこそこあります。
そのため github のラベルを付けといたら、CIが通ったタイミングでレビュー依頼を出してくれる君を作りました。

name: auto-assign

on:
  schedule:
    - cron: "*/10 1-10 * * 1-5"

jobs:
  init-echo:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: checkout2
        run: |
          ${{ github.workspace }}/script/ci/cron-auto-assign.sh
        env:
          GITHUB_TOKEN: ${{ secrets.XXX_GITHUB_TOKEN }}

cron-auto-assign.sh

#!/bin/bash

set -x

for number in `gh pr list --search "label:auto-assign" --json number  --jq ".[]|.number"`; do
    gh pr checks ${number} && gh pr edit ${number} --remove-label auto-assign  --add-reviewer ここを書き換える
done

もし Auto assignment を利用していた場合には add-reviewer に team を入れたらランダムにアサインされます.
Managing code review settings for your team - GitHub Docs

悩んだ点は、１つはCIが通ったタイミングで発火するちょうど良いトリガーが見つからなかったので cron で定期実行していることです。
これは何かいい方法があったら変えたいです。

もう一つはgithub cliの不具合でsecrets.GITHUB_TOKENでは権限が足りずに動かないこと。
既に issue になっていますが、不必要に強い権限を要求するようになっているようです。
github.com そのため、暫定的に personal access token を利用して回避しております。

対象のPRを絞る条件は何か甘いかもしれないんですが、今のところは動いていそうな感じです