サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
デスク環境を整える
onk.hatenablog.jp
この記事は はてなエンジニア Advent Calendar 2023 の 1/2 の記事です。昨日は id:nakataki の 1904年になりました(dayjsでの年入力の話) - nakatakiの日記 でした。190x 年から脱出できない面白い不具合でした。 変化バジェット 「変化バジェット」という考え方があります。というか世の中には無いんですが、僕は社内でこの概念をよく使っています。 Google 検索 *1 Twitter 検索 私が発した言葉のログしかありません だいたい名前から想像するものと同じなんじゃないでしょうか。組織が変化に対して許容できる予算枠だったり、組織が変化に対して投資する予算枠だったりを指しています。 変化バジェット=許容量 変化バジェットは、組織が効果的に変化を取り入れ、消化できる能力の範囲を指します。 組織の変化に許容量があるという概念は、組織に対して
これは はてなエンジニア 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 Advent Calendar 2023 の12月1日の記事です。トップバッターいただきます。 お前誰よ Mackerel チームでエンジニアリングマネージャーをやっている id:onk です。最近は特に OpenTelemetry 対応を進めているチームのそばにいます。 今日の話 個人で Mackerel をどう使っているかの一部をチラ見せします。 まずはこのダッシュボードを見てくれ。 我が家のダッシュボード リモートワークになってから快適に暮らすために、気温、室温、二酸化炭素濃度、気圧なんかを測って投稿している。二酸化炭素濃度が上がるとアラートを鳴らして換気するなどのアクションを取りたいし、気圧が急激に下がるときは頭痛ーるのようにアラートを投げたい。というわけで Nature Remo や Netatmo を利用して測定しています。 測っている値は 3 年
「次の職場が 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 日本語
2 月から、Mackerel チームの所属になった。 今日から異動して Mackerel チームです。非正規ルートでの要望でもいい感じにやるので何でもください!— Takafumi ONAKA (@onk) February 1, 2023 これを期に、せっかくなのでコードを読まないマネジメントスタイルを試してみようと思って、実践している。 今までは自分が一番プロダクトのコードベースに詳しい状態を作ってきていて、障害対応でも嬉々として先頭に立つようなテックリードスタイルだった。 この姿が天職と思っているが、今までの人生で、コードの細かい話が通じない (というか、共通言語や会話のレイヤーが違う) けれども非常に信頼できるマネージャーと仕事をしてきた経験はあるので、自分も彼らのようなムーブが可能なんだろうかとやってみたくなったのだ。知識欲が減衰した老害化現象ではないと思う。きっと、たぶん。 も
資料は こちら です。 背景 アーキテクチャ的に何かを足したいとき、我々はチーム開発を行っているのだから、チームの共通認識を変えるということになる。認知負荷が高い場合は提案を拒否されてしまうので、認知負荷をできる限り小さくして導入したい。つまり差分の最小化です。*1 現在のコードベースと、入れたいアーキテクチャを対比させつつ、こう導入するのがベストと見切るところが今回のトークの面白ポイントです。 PoEAA のデータソースのアーキテクチャに関するパターン PoEAA は 20 年前の本なので、当時の開発風景を想像できる人と会話しながら読むと良いです。エリックエヴァンスの DDD 本も似た時期ですね。2002 年は Java 1.4 がリリースされた頃。デザインパターンや UML や XML が流行っていた。ライブラリのパッケージマネージャやセントラルリポジトリがまだ無い。*2 再利用性があ
昨日(もう日付余裕で回ってるので一昨日だな)Findy さん主催のイベントで話してきた。 speakerdeck.com 背景 近年「エンジニアは事業貢献してこそ」「エンジニアもユーザファーストでビジネス貢献」といった言説がIT界隈で増えて来ている感じがしている。 ……とたまたま昨日関連してるようなしてないような話をしている エンジニアとビジネスの距離感の難しさ|ばんくし|note という記事があったので書き出しを真似してみたんだけど。 昨今、ビルドトラップに陥るな、アウトプットじゃなくアウトカムに着目しろ、って言われることが増えてますよね。でも僕は逆張りして、アウトプットにまず着目しろという声を上げておきたいのです。 開発生産性(いろいろある*1)の話をするときに、ディスカバリーとデリバリーの 2 軸で考えるのはコモディティ化してきたと思う。でも、それによって、デリバリーの重要性が薄くな
Test which reminded me why I don't really like RSpec | Arkency Blog (日本語訳:Rails: RSpecが好きでないことを思い出したテスト(翻訳)|TechRacho by BPS株式会社) を見ての感想。 元のコードのイマイチなところは 4 つあって、 params を before で書き換えている *1 it "will succeed" の文言 it { is_expected.to be_success } と expect(result.success?).to eq(true) が混ざっている let が不思議な順序で連発されていて事前条件を読み解けない すべて、これによって何をテストしているのかが分かりづらくなっているという問題を引き起こす。 params を before で書き換えている let(:pa
YAPC::Kyoto 2023の採択トークが決まったようですね。面白そうなトークが沢山あってすごいですね。 blog.yapcjapan.org 私のトークも採択されました。ありがてぇ! こういう話をします。 ORM - Object-relational mapping はてなの Perl プロダクトは薄いフレームワークを志向して、データベースとのやり取りに DBIx::Sunny や DBIx::Handler::Sunny を用い、主に SQL を書いて暮らしていました。最近、私はこの世界に ORM を持ち込みました。 PofEAA によるデータソースのアーキテクチャの 4 分類、我々が何を考えてどのパターンを選んだか、必要になって書いたプラグイン等、ORM の無い世界に ORM を入れていくに当たって考えたことと、その実践。 Perl Monger なら一生に一度は書くといわれる
発表資料作り、全体的な流れは 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 割 引用しやすいワー
と成長への近道なんじゃないかという仮説。 積極的フィルターバブルとは resize.fm #100 で id:nagayama が語っていた概念。44:10 辺りから。 anchor.fm 新しいことを始めるときに、Instagram でサブ垢を作って、その関係の人しかフォローしない タイムラインは全部スケボーになる 自分の価値観が、いかに板に乗って高く飛ぶか、に変わっていく 業界用語や技術のトレンドとかが自然に入ってくる 以前僕も似たようなことを言っていた。 短期間で新技術を学ぶ技術 from Takafumi ONAKA このときは情報を浴びてインデックスを自分の中に持つことを目的としていたが、いわゆる近接性バイアス、接触頻度が価値観に与える影響というものも大きいんだろうな、と思う。 これを聞いたので、僕も Instagram でサブ垢を作って、#kendama タグで検索して、100
密閉型イヤホン以外でWeb会議アドベントカレンダーに遅れて参戦! こういう状態。 ここ3年で増えたヘッドンホホたち SONY WH-1000XM4 www.sony.jp ヘッドフォンですね。2020-09 に買った。 外音取り込みは、外の音が聞こえるイヤホンを↓でいっぱい買ったので、むしろ外音を取り込まないために使うヘッドフォンになった。 ノイズキャンセリングは最高に便利。僕も妻も机を並べて WFH しているので、同時に会議すると声が混ざって困り、この子に付け替えている。 AfterShokz OpenComm OPENCOMMjp.shokz.com 骨伝導。2020-11 に買った。 耳を塞がず (外耳炎にならなくて最高) に外の音が自然に入ってくる (在宅作業しやすくて最高) のはものすごく快適で、しばらく「最高〜〜〜〜!!!」と思って暮らしていた。 完全ワイヤレスではなく、ヘッド
TIL merge commit は親が 2 つ (以上) あるので、revert するときはどちらの親に戻したいかを -m (--mainline) で指定する。 起きたこと 「意図せず feature branch を main に混ぜて push しまった」と呼ばれて飛び出したんだが、コミットツリーがこうなっていた。 525adcbf69 ●─╮ [main] {origin/main} Merge branch 'main' of ... de745c8669 │ ∙ commit for main 2060e2be19 │ ∙ commit for main 813528befb ∙ │ commit for feature 9ed9cb80a9 ∙ │ commit for feature 9f8e1bb2e1 ∙ │ commit for feature 元々の main 最
要は以下の記事の繰り返しなのだが。 k0kubun.hatenablog.com Kaigi on Rails _2022_ new というイベントの LT で、メソッド定義を探ろうという話があった。 speakerdeck.com Rails のソースをシュッと眺めに行くという、非常に尊い良い発表でした。 Object のことは Object に聞け、は Ruby の非常に面白いところなので、Method を取り出して source_location を尋ねるのは一度体験して感動して欲しいんだけど、実務だとタイプ数の少ないやり方も知っておくと更に便利に使えるのでご紹介。 irb の show_source も武器に加えてあげたい #kaigionrails— Takafumi ONAKA (@onk) October 9, 2022 Pry の $ https://github.com/
僕はチーム join 時に、Docker は初手で剥がすし、GitHub Actions でやっているワークフローの全体像を把握するのを次に行う、というのを基本的にはやっている。これはシステム構成やデプロイ周りの全貌を把握するのが好きなのと、何かが起きたときにコレをやっているのといないのとで問題切り分けの精度に圧倒的な差があるからなんだけど、join 直後にやるのが最適解とは限らない場面もある。 チームの人員構成として、テックリード業を既に担っている人が居る場合、追加人員にはテックリード未満の「プラスの工数として数えられる戦力」となって欲しい。この戦力というのは、「目の前に積み上がった問題を一緒に解いて欲しい」という期待。問題と言うよりも、既にタスクになっているものを消化したい、という期待の方が大きいと思う。 そういう期待があるときには、ちんたら Docker を剥がしている場合ではなく、
吉祥寺.pm30 で、チューニングがテーマだったので、マネージャとメンバー間で期待値をチューニングするという LT をしてきた。 トークタイトルは熊とワルツを。トム・デマルコの本です。 熊とワルツを リスクを愉しむプロジェクト管理 作者:トム デマルコ,ティモシー リスター日経BPAmazon 「管理」という言葉 「管理」と訳される単語は色々ある goo 和英辞書 によると 〔経営〕management 〔経営,運営〕administration 〔統制〕control 〔監督〕supervision 英辞郎 on the WEB によると administration〔【略】admin. ; adm.〕 caretaking(建物・土地などの) caretaking〈英〉(学校などの公共施設の) charge conduct(業務などの) control custody(大事な物の) d
developer.hatenastaff.com タイトルは前回のゲストの id:hitode909 に合わせた。 blog.sushi.money 自分の声を聞き返すのが苦手なので、自分では Amazon Transcribe で読み返しました。 誰の台詞かの判定もできる 読み返してみたんですが、 プライベートチャンネルに招待されたらとりあえず数年分のログ全部読んだ Slack キーワード通知に設定しているワード 100 連発 - id:onk のはてなブログ みたいな、情報ジャンキーとしての話が目立ってますね。そこそこ得意技です。 異動を計画するに当たって気にしていることとか、技術ブログをレビューするときに気にしていることみたいなのは、それぞれ別にまとめておきたいな。 そんな話をしました。よければ聞いてください。 developer.hatenastaff.com 似た話をファインデ
発表資料作り、全体的な流れは 1 週間ぐらいかけて構想して、半日使って 15,000 字ほど書いて (コード片含む)、半日使ってスライドに起こす(結果として 6000 字ぐらい使う)、って感じですね。貯めた文字列を組み合わせている最中に構想とは別のストーリーが降ってくることも多い。— Takafumi ONAKA (@onk) July 3, 2018 ツイート貼り付けたら書きたいことが終わってしまった。 ↓は資料の作成途中の姿。↑で 15,000 って言ってるけど、余裕で超えてるな。 $ wc 20220305_yapc_japan_online.md 409 970 26111 20220305_yapc_japan_online.md 喋るといいんじゃないかってことを、とにかく書き出してまず文字数を稼いで 一度 k0kubun/md2key で Keynote に流し込んで すごく雑
この記事は、はてなエンジニア Advent Calendar 2021 の 18 日目の記事です。 昨日は id:dekokun の bitcoinのfull nodeをAWSでなるべく安く運用してみる - でこてっくろぐ ねお でした。 full node の存在知らなかったし EBS SC1 を使うって発想もなかった (最近 gp3 以外選んでない) ので面白かった。Bitcoin 思ってたより善意に支えられてるんですね。 dekotech.dekokun.info さて本題。 はてなスタッフの日記 はてなスタッフは、だいたい個人ブログを持っています。また、技術ブログと日記とを分けずに一つのブログに書いている人もそこそこ多くいます。僕も分けてないので年末は「今年買ったもの」を投稿していたりする。今年も書きます。 onk.hatenablog.jp 技術記事を Hatena Develo
次のページ
このページを最初にブックマークしてみませんか?
『id:onk のはてなブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く