Modular Monolith はどの辺りから考え始めるものなのか - id:onk のはてなブログ
モノリスでは大変なので、マイクロサービスやモジュラーモノリスにして認知負荷を減らしたり、生産性の劣化に抗いたいという考え方がある。 モジュラーモノリスとは モジュラーモノリスについては、だいたい infoq.com のモノリスシリーズ（？）を読めば良いんじゃないか。 有名なのは Shopify のヤツ。 モノリスとマイクロサービスの中間にある、1 アプリケーションなんだけどモノリスでは無い、アプリ内でモジュール分けされているアーキテクチャのこと。app/ の直下に MVC を置くんじゃなくて、COMPONENTS (例えば billing)/app/ の下に MVC を置く、ようなイメージ。 モジュラーに移行するタイミング 僕の感覚だと、数百モデルは全然モノリスで扱えると思っている。少なくとも 300 models 程度でモジュラーにしていく必要はまったく感じない。 世の中で見つけたモデル
変化バジェットという考え方 - id:onk のはてなブログ
この記事は はてなエンジニア Advent Calendar 2023 の 1/2 の記事です。昨日は id:nakataki の 1904年になりました(dayjsでの年入力の話) - nakatakiの日記 でした。190x 年から脱出できない面白い不具合でした。 変化バジェット 「変化バジェット」という考え方があります。というか世の中には無いんですが、僕は社内でこの概念をよく使っています。 Google 検索 *1 Twitter 検索 私が発した言葉のログしかありません だいたい名前から想像するものと同じなんじゃないでしょうか。組織が変化に対して許容できる予算枠だったり、組織が変化に対して投資する予算枠だったりを指しています。 変化バジェット＝許容量 変化バジェットは、組織が効果的に変化を取り入れ、消化できる能力の範囲を指します。 組織の変化に許容量があるという概念は、組織に対して
Ruby/Rails の勉強に何読んだらいいかと聞かれたとき - id:onk のはてなブログ
「次の職場が Ruby なんだけど」と読み書きそろばんを聞かれたのと、大阪Ruby会議03、大江戸Ruby会議10、Kaigi on Rails 2023 と Ruby/Rails 関係のイベントに続けて参加して、作者の皆さまと会ったので。 「読める」になるために 言語仕様は何らかの本 1 冊の冒頭の方を読めば雰囲気は掴めるだろう。 Ginza Rails27 igaiga - Speaker Deck 著書や技術顧問、健康診断レポート でお馴染みの @igaiga555 さんの作った表で、難易度別にまとまっている。 たのしいRuby か、プロを目指す人のためのRuby入門 が定番かなぁ。 できることを知る るりま (Ruby リファレンスマニュアル) の Enumerable、String Rails Guides の Active Support Core Extensions 日本語
作業者じゃなく開発者でありたい - id:onk のはてなブログ
自分がこうありたいというメモ。 作業者と開発者の違いとして、問題解決への寄与だとか、創意工夫の余地があるかというのがありそう。 これは今 GPT-4 に聞いた。 Q: 作業者と開発者の違いを100文字ぐらいで教えて。 A: 作業者は指定されたタスクや手順を実行する人を指し、特定のルーチンや手順に従って作業を進めることが主な役割です。一方、開発者は新しい製品やソフトウェアを設計・構築する人を指し、創造性や技術的なスキルが求められます。作業者は指示に従い行動し、開発者は新しいアイディアや解決策を生み出します。 単なるタスクの遂行でなはく、より多くの責任とリーダーシップを求めている コードを書くだけではなく、問題解決や創意工夫の余地が多くあるタスクが欲しい 自分のアイディアをベースとして、形にすることで、プロジェクトを完遂したい そもそも何が問題なのかを明らかにするだとか、最適な解決策を見つける
オンボーディングは3ヶ月で3連勝を目指す - id:onk のはてなブログ
先日 ヘンリーで活躍中の id:Songmu を訪問 | はてな卒業生訪問企画 [#3] - Hatena Developer Blog という対談記事でもオンボーディングについて話したんだけど、社内では最近「3ヶ月で3連勝」を標語にしている。 オンボーディングとは 採用や異動などでチームにジョインした後に行う、早期戦力化のための施策のこと。開発環境のセットアップやチームの説明だけじゃなく、戦力になるまでのプロセス全部を指していそう。 僕らは各アカウント作成や開発環境構築はチェックボックス化してドンドン進められるようにしている *1 し、事業の説明、組織の説明、システム構成の説明をする場を設定したり、技術スタックへの入門のための実績解除システムを用意したりしてきた。 これらのドキュメントに従って作業を進め、実績を解除していくことで、作業的・技術的な道標はあるものの、オンボーディングプロセス
デュアルトラックアジャイルとの向き合い方。あるいはエンジニアとビジネスの距離感 - id:onk のはてなブログ
昨日（もう日付余裕で回ってるので一昨日だな）Findy さん主催のイベントで話してきた。 speakerdeck.com 背景 近年「エンジニアは事業貢献してこそ」「エンジニアもユーザファーストでビジネス貢献」といった言説がIT界隈で増えて来ている感じがしている。 ……とたまたま昨日関連してるようなしてないような話をしている エンジニアとビジネスの距離感の難しさ｜ばんくし｜note という記事があったので書き出しを真似してみたんだけど。 昨今、ビルドトラップに陥るな、アウトプットじゃなくアウトカムに着目しろ、って言われることが増えてますよね。でも僕は逆張りして、アウトプットにまず着目しろという声を上げておきたいのです。 開発生産性（いろいろある*1）の話をするときに、ディスカバリーとデリバリーの 2 軸で考えるのはコモディティ化してきたと思う。でも、それによって、デリバリーの重要性が薄くな
ストーリー性のあるプレゼン - id:onk のはてなブログ
発表資料作り、全体的な流れは 1 週間ぐらいかけて構想して、半日使って 15,000 字ほど書いて (コード片含む)、半日使ってスライドに起こす(結果として 6000 字ぐらい使う)、って感じですね。貯めた文字列を組み合わせている最中に構想とは別のストーリーが降ってくることも多い。— Takafumi ONAKA (@onk) July 3, 2018 このツイートの「文字を組み合わせる」のところについて、もうちょっと掘り下げてみる。*1 この記事は はてなエンジニア Advent Calendar 2022 の1月2日の記事です。昨日は id:stefafafan で 『UNIXという考え方―その設計思想と哲学』を読んだ - stefafafan の fa は3つです でした。 3 つのポイント 知っていること 7 割、聞いたことがあること 2 割、知らないこと 1 割 引用しやすいワー
意識的に職位を下げる - id:onk のはてなブログ
僕はチーム join 時に、Docker は初手で剥がすし、GitHub Actions でやっているワークフローの全体像を把握するのを次に行う、というのを基本的にはやっている。これはシステム構成やデプロイ周りの全貌を把握するのが好きなのと、何かが起きたときにコレをやっているのといないのとで問題切り分けの精度に圧倒的な差があるからなんだけど、join 直後にやるのが最適解とは限らない場面もある。 チームの人員構成として、テックリード業を既に担っている人が居る場合、追加人員にはテックリード未満の「プラスの工数として数えられる戦力」となって欲しい。この戦力というのは、「目の前に積み上がった問題を一緒に解いて欲しい」という期待。問題と言うよりも、既にタスクになっているものを消化したい、という期待の方が大きいと思う。 そういう期待があるときには、ちんたら Docker を剥がしている場合ではなく、
期待値をチューニングする - id:onk のはてなブログ
吉祥寺.pm30 で、チューニングがテーマだったので、マネージャとメンバー間で期待値をチューニングするという LT をしてきた。 トークタイトルは熊とワルツを。トム・デマルコの本です。 熊とワルツを リスクを愉しむプロジェクト管理 作者:トム デマルコ,ティモシー リスター日経BPAmazon 「管理」という言葉 「管理」と訳される単語は色々ある goo 和英辞書 によると 〔経営〕management 〔経営，運営〕administration 〔統制〕control 〔監督〕supervision 英辞郎 on the WEB によると administration〔【略】admin. ; adm.〕 caretaking（建物・土地などの） caretaking〈英〉（学校などの公共施設の） charge conduct（業務などの） control custody（大事な物の） d
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
