サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
買ってよかったもの
onk.hatenablog.jp
この記事は はてなエンジニア Advent Calendar 2023 の 1/2 の記事です。昨日は id:nakataki の 1904年になりました(dayjsでの年入力の話) - nakatakiの日記 でした。190x 年から脱出できない面白い不具合でした。 変化バジェット 「変化バジェット」という考え方があります。というか世の中には無いんですが、僕は社内でこの概念をよく使っています。 Google 検索 *1 Twitter 検索 私が発した言葉のログしかありません だいたい名前から想像するものと同じなんじゃないでしょうか。組織が変化に対して許容できる予算枠だったり、組織が変化に対して投資する予算枠だったりを指しています。 変化バジェット=許容量 変化バジェットは、組織が効果的に変化を取り入れ、消化できる能力の範囲を指します。 組織の変化に許容量があるという概念は、組織に対して
この記事は 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 これを期に、せっかくなのでコードを読まないマネジメントスタイルを試してみようと思って、実践している。 今までは自分が一番プロダクトのコードベースに詳しい状態を作ってきていて、障害対応でも嬉々として先頭に立つようなテックリードスタイルだった。 この姿が天職と思っているが、今までの人生で、コードの細かい話が通じない (というか、共通言語や会話のレイヤーが違う) けれども非常に信頼できるマネージャーと仕事をしてきた経験はあるので、自分も彼らのようなムーブが可能なんだろうかとやってみたくなったのだ。知識欲が減衰した老害化現象ではないと思う。きっと、たぶん。 も
昨日(もう日付余裕で回ってるので一昨日だな)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 なら一生に一度は書くといわれる
と成長への近道なんじゃないかという仮説。 積極的フィルターバブルとは 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 を剥がしている場合ではなく、
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=
吉祥寺.pm30 で、チューニングがテーマだったので、マネージャとメンバー間で期待値をチューニングするという LT をしてきた。 トークタイトルは熊とワルツを。トム・デマルコの本です。 熊とワルツを リスクを愉しむプロジェクト管理 作者:トム デマルコ,ティモシー リスター日経BPAmazon 「管理」という言葉 「管理」と訳される単語は色々ある goo 和英辞書 によると 〔経営〕management 〔経営,運営〕administration 〔統制〕control 〔監督〕supervision 英辞郎 on the WEB によると administration〔【略】admin. ; adm.〕 caretaking(建物・土地などの) caretaking〈英〉(学校などの公共施設の) charge conduct(業務などの) control custody(大事な物の) d
実装を進める上で障害になりそうなところを先回りして直してるように見えるけど、一体どうやって検知しているかという話題。 結論から言うと「慣れです」なんだけど、こういう考え方があるよというのを紹介しておく。 mikadomethod.info ちょうど10年ぐらい前に話題になった手法だけど、考え方としてはまだまだ現役です。 概要は本家なりこの辺のリンク先なりを見て貰って。 開発者のためのソフトウェアテストのスキルアップ | Think IT(シンクイット) 大規模コードをリファクタリングする方法『ミカドメソッド(Mikado Methood)』について | Futurismo テストとリファクタリングに関する深い方法論 #wewlc_jp レガシーソフトウェア改善ガイド | Amazon 僕の理解は 1 ループ目 やりたいことを実現するコードを書く ギャップが無ければサクッと実装して終わり
developer.hatenastaff.com タイトルは前回のゲストの id:hitode909 に合わせた。 blog.sushi.money 自分の声を聞き返すのが苦手なので、自分では Amazon Transcribe で読み返しました。 誰の台詞かの判定もできる 読み返してみたんですが、 プライベートチャンネルに招待されたらとりあえず数年分のログ全部読んだ Slack キーワード通知に設定しているワード 100 連発 - id:onk のはてなブログ みたいな、情報ジャンキーとしての話が目立ってますね。そこそこ得意技です。 異動を計画するに当たって気にしていることとか、技術ブログをレビューするときに気にしていることみたいなのは、それぞれ別にまとめておきたいな。 そんな話をしました。よければ聞いてください。 developer.hatenastaff.com 似た話をファインデ
おはようございます。onk です。2021年12月18日の、朝です。11時なので、朝というか、昼ですね。ここでタイマーをセット。 この記事は、やんちゃクラブリスナー Advent Calendar 2021、18 日目の、記事です。 やんちゃさん、誕生日おめでとうございます 本日 18 日は yancya の誕生日です。 知ったのいつだっけな。 @chiastolite による誕生日 Advent Calendar 界隈でよく話題に上がるので以前からワイワイしている。 adventar.org 誕生日 Advent Calendar、@yancya 氏に取られたw— Takafumi ONAKA (@onk) November 4, 2014 @onk 実は同じなんですよねw— yancya (@yancya) November 4, 2014 @chiastolite @onk おめでと
次のページ
このページを最初にブックマークしてみませんか?
『id:onk のはてなブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く