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 検索 私が発した言葉のログしかありません だいたい名前から想像するものと同じなんじゃないでしょうか。組織が変化に対して許容できる予算枠だったり、組織が変化に対して投資する予算枠だったりを指しています。 変化バジェット＝許容量 変化バジェットは、組織が効果的に変化を取り入れ、消化できる能力の範囲を指します。 組織の変化に許容量があるという概念は、組織に対して
「キャッシュは麻薬」という標語からの脱却 - id:onk のはてなブログ
これは はてなエンジニア Advent Calendar 2023 の 18 日目の記事です。昨日は id:gurrium による private-isuで70万点取るためにやったこと - ぜのぜ でした。私は 50 万点ぐらいで満足してしまっていたので、しっかり詰めていて凄いなと思う。 developer.hatenastaff.com Web アプリケーション開発において、「キャッシュは麻薬」という言葉がインターネット上をよく飛び交っています。YAPC::Kansai OSAKA 2017 の id:moznion のトークでよく知られるようになったワードじゃないかな。 初出はちゃんとは分からないんですが、少なくとも 2011 年には言われていますね。 「キャッシュは麻薬」とはよく言ったものだ。— TOYAMA Nao (@nanto_vi) November 5, 2011 キャッシ
Mackerel 個人ダッシュボード使いこなし術 - id:onk のはてなブログ
この記事は Mackerel Advent Calendar 2023 の12月1日の記事です。トップバッターいただきます。 お前誰よ Mackerel チームでエンジニアリングマネージャーをやっている id:onk です。最近は特に OpenTelemetry 対応を進めているチームのそばにいます。 今日の話 個人で Mackerel をどう使っているかの一部をチラ見せします。 まずはこのダッシュボードを見てくれ。 我が家のダッシュボード リモートワークになってから快適に暮らすために、気温、室温、二酸化炭素濃度、気圧なんかを測って投稿している。二酸化炭素濃度が上がるとアラートを鳴らして換気するなどのアクションを取りたいし、気圧が急激に下がるときは頭痛ーるのようにアラートを投げたい。というわけで Nature Remo や Netatmo を利用して測定しています。 測っている値は 3 年
手を動かさないマネージャーを試している - id:onk のはてなブログ
2 月から、Mackerel チームの所属になった。 今日から異動して Mackerel チームです。非正規ルートでの要望でもいい感じにやるので何でもください！— Takafumi ONAKA (@onk) February 1, 2023 これを期に、せっかくなのでコードを読まないマネジメントスタイルを試してみようと思って、実践している。 今までは自分が一番プロダクトのコードベースに詳しい状態を作ってきていて、障害対応でも嬉々として先頭に立つようなテックリードスタイルだった。 この姿が天職と思っているが、今までの人生で、コードの細かい話が通じない (というか、共通言語や会話のレイヤーが違う) けれども非常に信頼できるマネージャーと仕事をしてきた経験はあるので、自分も彼らのようなムーブが可能なんだろうかとやってみたくなったのだ。知識欲が減衰した老害化現象ではないと思う。きっと、たぶん。 も
ストーリー性のあるプレゼン - 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 割 引用しやすいワー
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
積極的フィルターバブルで価値観を破壊する - id:onk のはてなブログ
と成長への近道なんじゃないかという仮説。 積極的フィルターバブルとは resize.fm #100 で id:nagayama が語っていた概念。44:10 辺りから。 anchor.fm 新しいことを始めるときに、Instagram でサブ垢を作って、その関係の人しかフォローしない タイムラインは全部スケボーになる 自分の価値観が、いかに板に乗って高く飛ぶか、に変わっていく 業界用語や技術のトレンドとかが自然に入ってくる 以前僕も似たようなことを言っていた。 短期間で新技術を学ぶ技術 from Takafumi ONAKA このときは情報を浴びてインデックスを自分の中に持つことを目的としていたが、いわゆる近接性バイアス、接触頻度が価値観に与える影響というものも大きいんだろうな、と思う。 これを聞いたので、僕も Instagram でサブ垢を作って、#kendama タグで検索して、100
意識的に職位を下げる - id:onk のはてなブログ
僕はチーム join 時に、Docker は初手で剥がすし、GitHub Actions でやっているワークフローの全体像を把握するのを次に行う、というのを基本的にはやっている。これはシステム構成やデプロイ周りの全貌を把握するのが好きなのと、何かが起きたときにコレをやっているのといないのとで問題切り分けの精度に圧倒的な差があるからなんだけど、join 直後にやるのが最適解とは限らない場面もある。 チームの人員構成として、テックリード業を既に担っている人が居る場合、追加人員にはテックリード未満の「プラスの工数として数えられる戦力」となって欲しい。この戦力というのは、「目の前に積み上がった問題を一緒に解いて欲しい」という期待。問題と言うよりも、既にタスクになっているものを消化したい、という期待の方が大きいと思う。 そういう期待があるときには、ちんたら Docker を剥がしている場合ではなく、
放っておくと進まない仕事を進めるために - id:onk のはてなブログ
はてなは 7 月決算なので期のふりかえりをやっていたんだが、今期は「放っておくと進まない仕事を進めるために、時間を確保する」ことで進むようになった期だった。ちなみに前期は「放っておくと進まない仕事を進めるために、締切を設定する (強制力を持たせる)」ことで進めようとしていた期だった。 放っておくと進まない仕事とは、優先順位が低い仕事のこと。やってもやらなくても直ちに影響はない仕事をどうやったら進められるのかというのは長年ずっと課題だったが、やっと自分の中である程度答えが見えてきたかもしれないので記しておく。書き出してみたら至って普通なんだけど、以下をやっている。 見積もる 締切を作る 締切を宣言する 時間を押さえる 見積もる チームで見積もりを行い、まずはタスクの重さや実現方法についての共通認識を持つ。 タスクを分解する、とも言い換えられる。やるべきなんだけど気が重い仕事はとにかく分解しま
使用頻度とコマンド (エイリアス) の文字数を合わせたい - id:onk のはてなブログ
1 文字エイリアスのすゝめ 1 文字エイリアスが好きで、例えば alias s="git status -sb" している。 入社してからの 4 年半で溜めた 53 万行の .zsh_history から集計すると、 $ history 1 | awk '{ print $2 }' | sort | uniq -c | sort -nr | head 121714 g 114128 s 57124 v 34210 cd 26095 tig 23281 rg 11382 plenv 10837 t 9647 :q 6867 ll となった。ちなみに以下の略です。 alias g="git" alias s="git status -sb" function v() {vi -p ${${=*/:/ +}/:*}} alias t="tig" alias :q="exit" alias ll=
期待値をチューニングする - id:onk のはてなブログ
吉祥寺.pm30 で、チューニングがテーマだったので、マネージャとメンバー間で期待値をチューニングするという LT をしてきた。 トークタイトルは熊とワルツを。トム・デマルコの本です。 熊とワルツを リスクを愉しむプロジェクト管理 作者:トム デマルコ,ティモシー リスター日経BPAmazon 「管理」という言葉 「管理」と訳される単語は色々ある goo 和英辞書 によると 〔経営〕management 〔経営，運営〕administration 〔統制〕control 〔監督〕supervision 英辞郎 on the WEB によると administration〔【略】admin. ; adm.〕 caretaking（建物・土地などの） caretaking〈英〉（学校などの公共施設の） charge conduct（業務などの） control custody（大事な物の） d
先回りするコツとミカドメソッドという手法 - id:onk のはてなブログ
実装を進める上で障害になりそうなところを先回りして直してるように見えるけど、一体どうやって検知しているかという話題。 結論から言うと「慣れです」なんだけど、こういう考え方があるよというのを紹介しておく。 mikadomethod.info ちょうど10年ぐらい前に話題になった手法だけど、考え方としてはまだまだ現役です。 概要は本家なりこの辺のリンク先なりを見て貰って。 開発者のためのソフトウェアテストのスキルアップ | Think IT（シンクイット） 大規模コードをリファクタリングする方法『ミカドメソッド(Mikado Methood)』について | Futurismo テストとリファクタリングに関する深い方法論 #wewlc_jp レガシーソフトウェア改善ガイド | Amazon 僕の理解は 1 ループ目 やりたいことを実現するコードを書く ギャップが無ければサクッと実装して終わり
ソフトウェア式年遷宮という概念の歴史と、Hatena::Let での実例 - id:onk のはてなブログ
Hatena Engineer Seminar #17 にて発表しました。 hatena.connpass.com Hatena::Letの式年遷宮 from Takafumi ONAKA www.slideshare.net 発表内容をかいつまんで記事にも書いておきます。 Hatena::Let とは はてラボ のサービスの一つ。 僕も入社するまで、はてラボ == ベータ版、だと思ってたんですが、 ラボならではの挑戦的なサービス 運用費が会社持ちで、会社の名前で出しても良い、はてなスタッフの有志が運営するサービス、という制度 も含んでいます。 で、Hatena::Let は、現在は主に id:onk が開発している、ブックマークレットをかんたんに作成・公開できるサービスです。 ソフトウェア式年遷宮とは 初出は 2013 年の id:kenjiskywalker によるもので、このときはイ
フルタイムでやる仕事を作る #wantedlydev - id:onk のはてなブログ
先日 Wantedly さんのエンジニアリングマネージャー座談会に出演させていただいた。 wantedly.connpass.com テーマは、「エンジニアリングマネージャーの課題を相談したい人が多い」「その相談パブリックにしよう」なので、自分が最近課題に思っている「変化の速度感」についてざっくばらんに会話できたらなーというのが期待だった。 イベント中には、大きく 4 つの話をしたのかな。それぞれ会話の中では話しきれなかったことも補足しつつ書いていく。 技術スタックが違うチーム プロダクトと専門組織のバランス 専門組織を立ち上げるポイント 採用と oss-guild 技術スタックが違うチーム リンク先を見て貰うと顕著に分かると思うけど、はてなでは、そこそこバラバラな技術スタックを使っている。 hatenacorp.jp インフラは AWS、Google Cloud (オンプレはやっと撲滅し
チームに浸透させるのが近年では難しくなっている - id:onk のはてなブログ
昨日「動いたけどチームメンバーを説得するのが面倒で、秘蔵のブランチになってしまう」って言ったけど、この気持ちはどこから出てくるのか。 分かりやすい Cons があると、反発が予想できて、その反発を解決するところまで労力を割くほどの気持ちが無いので困る。「直ちに問題になるわけじゃないが、どちらかというとやった方がいい、でもリスクもある」という選択肢を選べずにズルズルと現状維持に向かう圧力は、ある。チームの同質性が高いうちはほとんど困らないんだが、人数が増えたり、別の職種が増えたりするごとに「面倒」さはどうしても増していく。 我々の信念として以下を持ってはいるが、現状維持に向かう圧力がある中で変化を加えるのはそこそこ労力が要り、閾値を超えると変化が発生しなくなってしまう。 業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。 素早く変えてもし仮にダメだったら素早く
体制を考えるときに意識していること - id:onk のはてなブログ
1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが
AWS Lambda でコンテナに入れた Sinatra を動かす - id:onk のはてなブログ
何番煎じか分からないけど、最近やったので。 前提知識 AWS Lambda + Amazon API Gateway で HTTP リクエストを受け付けることができる AWS Lambda ではコンテナイメージを動かせる New for AWS Lambda – Container Image Support | AWS News Blog AWS Lambda で Sinatra アプリを動かすための公式サンプルがある https://github.com/aws-samples/serverless-sinatra-sample つまりコンテナ化した Sinatra アプリを Lambda 上にデプロイして HTTP リクエストを受け付けることができる。 動かす準備はもう全部整っていて、お手軽そうですね。 Ruby アプリを Lambda で動かすコンテナイメージを作る Sinatra
Slack キーワード通知に設定しているワード 100 連発 - id:onk のはてなブログ
エゴサが趣味なので、社内の Slack のキーワード通知をめちゃくちゃ便利に使っている。 slack.com 何か見ておくと良いことがありそうなものを片っ端から通知するようにしているんだけど、100 個が上限なの知ってた？ 100 個以上設定しようとするとこうなる 僕はこんなキーワードを入れています。適当に分類しながら見てみよう。 自分 onk, o/nk, on/k, おんく, 大仲, onaka, 眼科 自分の名前やハンドルネームを入れておくと、どこかで自分が呼ばれたときに気づけるようになる。 定時外だと親切でキーワード通知避けのために / を入れて発言する人もいるので、それも通知させるためにこういうキーワードになっています。戸籍ネームはほっっとんど呼ばれることは無いんだけど、念のため。 「眼科」は中心性漿液性網脈絡膜症になってるっぽいけど放置してたら T シャツが作られたので、戒めの
アプリ内の日付変更線をズラす系の実装 - id:onk のはてなブログ
例えば日記を書くときに、午前 2 時に書いたものは前日分としたいことがある。またユーザがメチャクチャ多いサービスでは、0:00 を回ったら翌日のログインボーナスを配る、としていると、まだユーザが多い時間にサーバの処理が要求されて大変なので、28:00 を日付変更線にしたいことがある。 こういうときには module AppTime def self.beginning_of_day(time) t = time.change(hour: 4) t <= time ? t : t - 1.day end end を作って、 AppTime.beginning_of_day(Time.current) を使うと「アプリ内の日付変更線では何日なのか」が取れる。 # 02:00 は前日扱い time = Time.zone.parse("2021-01-31 02:00") AppTime.beg
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
