はてなブログの自動生成アイキャッチでおみくじをひけるようにした

はてなブログの新機能が出てた。 staff.hatenablog.com

htmlとcssを書けるんだから何か変なことできるでしょって思って、おみくじ以外を思いつかなかったのでとりあえずやってみることにした。

実装は chatgpt に聞いたらすぐ答えてくれた。animationで頑張れば良いらしい。

.omikuji {
  font-size: 36px;
  font-weight: bold;
  text-align: center;
  padding: 20px;
  color: #fff;
  background: linear-gradient(135deg, #ff7e5f, #feb47b);
  border-radius: 12px;
  box-shadow: 0 8px 20px rgba(0, 0, 0, 0.1);
  width: 300px;
  margin: 100px auto;
  transition: transform 0.3s ease, background 0.3s ease;
}

/* アニメーションの定義 */
@keyframes fortuneAnimation {
  0% { content: "大吉"; }
  25% { content: "吉"; }
  50% { content: "中吉"; }
  75% { content: "小吉"; }
  100% { content: "凶"; }
}

/* 擬似要素を使ってタイミングによって変わるテキストを表示 */
.omikuji:before {
  display: inline-block;
  content: "大吉"; /* 初期表示 */
  animation: fortuneAnimation 0.1s infinite;
}

同じアイキャッチのhtml/css で別のおみくじの結果が表示されたので、多分うまくいっているんだろうと思っている。(できてなかったらごめんなさい)
アイキャッチはキャッシュされている気はするので、おみくじの結果は見るたびに変わるのではなく、多分記事ごとに結果が変わるのではなかろうか。

動くと思ったけど本当に動いて良かった。実験がうまくいったので後で元に戻しておこう。

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

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

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

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

何が良かったかというと

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

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

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

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