shirokurostoneのブックマーク - はてなブックマーク

Modular Monolith はどの辺りから考え始めるものなのか - id:onk のはてなブログ

モノリスでは大変なので、マイクロサービスやモジュラーモノリスにして認知負荷を減らしたり、生産性の劣化に抗いたいという考え方がある。モジュラーモノリスとはモジュラーモノリスについては、だいたい infoq.com のモノリスシリーズ（？）を読めば良いんじゃないか。有名なのは Shopify のヤツ。モノリスとマイクロサービスの中間にある、1 アプリケーションなんだけどモノリスでは無い、アプリ内でモジュール分けされているアーキテクチャのこと。app/ の直下に MVC を置くんじゃなくて、COMPONENTS (例えば billing)/app/ の下に MVC を置く、ようなイメージ。モジュラーに移行するタイミング僕の感覚だと、数百モデルは全然モノリスで扱えると思っている。少なくとも 300 models 程度でモジュラーにしていく必要はまったく感じない。世の中で見つけたモデル

shirokurostone 2024/06/08

architecture

リンク

作業者じゃなく開発者でありたい - id:onk のはてなブログ

自分がこうありたいというメモ。作業者と開発者の違いとして、問題解決への寄与だとか、創意工夫の余地があるかというのがありそう。これは今 GPT-4 に聞いた。 Q: 作業者と開発者の違いを100文字ぐらいで教えて。 A: 作業者は指定されたタスクや手順を実行する人を指し、特定のルーチンや手順に従って作業を進めることが主な役割です。一方、開発者は新しい製品やソフトウェアを設計・構築する人を指し、創造性や技術的なスキルが求められます。作業者は指示に従い行動し、開発者は新しいアイディアや解決策を生み出します。単なるタスクの遂行でなはく、より多くの責任とリーダーシップを求めているコードを書くだけではなく、問題解決や創意工夫の余地が多くあるタスクが欲しい自分のアイディアをベースとして、形にすることで、プロジェクトを完遂したいそもそも何が問題なのかを明らかにするだとか、最適な解決策を見つける

shirokurostone 2023/10/01

development

リンク

git push -f が更に安全になる --force-if-includes - id:onk のはてなブログ

歴史改変、してますか？私は歴史改変が大好きで、毎日 rebase しています。なので割と毎日 git push -f することになっています。口で -f と言っても、実際には --force-with-lease --force-if-includes をしているので、これらのオプションのご紹介。この記事ははてなエンジニア Advent Calendar 2022 の 18 日目です。昨日は id:rokoucha さんで壊れたデータベースとの向きあいかた - rokoucha でした。 qiita.com -f の危険性 ...--F--G--H <-- main という状態で push した後、H をコミットし直したとしよう。 ...--F--G--H' <-- main \ H <-- origin/main このまま H' (main) を origin/main に p

shirokurostone 2023/01/14

リンク

放っておくと進まない仕事を進めるために - id:onk のはてなブログ

はてなは 7 月決算なので期のふりかえりをやっていたんだが、今期は「放っておくと進まない仕事を進めるために、時間を確保する」ことで進むようになった期だった。ちなみに前期は「放っておくと進まない仕事を進めるために、締切を設定する (強制力を持たせる)」ことで進めようとしていた期だった。放っておくと進まない仕事とは、優先順位が低い仕事のこと。やってもやらなくても直ちに影響はない仕事をどうやったら進められるのかというのは長年ずっと課題だったが、やっと自分の中である程度答えが見えてきたかもしれないので記しておく。書き出してみたら至って普通なんだけど、以下をやっている。見積もる締切を作る締切を宣言する時間を押さえる見積もるチームで見積もりを行い、まずはタスクの重さや実現方法についての共通認識を持つ。タスクを分解する、とも言い換えられる。やるべきなんだけど気が重い仕事はとにかく分解しま

shirokurostone 2022/08/20

*work

リンク

branch を寝かせるときは TODO.txt を置いている - id:onk のはてなブログ

タイトルがすべて。思いついたら手を動かしてしまう性質なので、秘蔵のブランチを大量に持っている。秘蔵のブランチというのは、動いたけどチームメンバーを説得するのが面倒とか、テスト書くのが面倒とか、だいたい動いているけどやりきるのが面倒とかで main にマージしていないヤツ。例えばフレームワークのメジャーバージョン上げるブランチとか、依存ライブラリをより一般的/現代的なものに交換するブランチや、より良い設計を思いついたのでガッと書き換えてしまうブランチが多いかな。だいたい 1 年所属していると 80 ブランチぐらい溜まるので、週 1 つ以上は何か作りかけてる計算になる。ローカルブランチの数、プロンプトに出しておくかな……。(秘蔵のブランチが溜まってる— Takafumi ONAKA (@onk) March 28, 2017 もちろん自分でいいアイディアだと思っているから実装している