タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが
設計ナイト2020 を受けて、今どんなアーキテクチャを選ぶべきかという話をしたくなったのだ。 kichijojipm.connpass.com 設計ナイトで高ぶった結果1時間コースの発表資料が完成したので供養場所を探しています。聞いてくれ！！！— Takafumi ONAKA (@onk) 2020年11月1日 お前誰よ 2000年代前半に SI 2000年代後半にブログ、SNS 2010年代にソーシャルゲーム 2020年代に UGC サービス をやってきた人間。数百万〜数億行のデータ、月間数千万〜数十億 imp 程度を主戦場にしています。 今日の話 DDD と PofEAA から学ぶパターン/アンチパターン Rails によって発見された、密結合で速く走れるソフトウェア 今求められているアーキテクチャ 昂ぶって 15,000 字ぐらい書いてしまった。 DDD と PofEAA から学ぶパ
2019-04-01 に「チーフエンジニア」という肩書きを手に入れてしまった。 はてなのエンジニア組織にはチーフエンジニアという役割のエンジニアがいて、評価や採用、その他大小諸々の施策を通じて、技術部門全体の生産性と幸福度を向上させるのがその仕事です。 はてなのエンジニアのバリューズ - Hatena Developer Blog 前職でも新卒採用、中途採用のお手伝いはしていたのだけれど、今は主業務の一つとして担当しているので、僕がどこを見ているのか、というのを書きとめておこう。 履歴書 チラ見しています。 「通勤片道1時間ぐらいかかりそうだけど大丈夫かなぁ？」とか「趣味がルービックキューブじゃん！ はてなの speedcubing 部と戦わせたろ」とかを見ています。 職務経歴書 まぁまぁ見ています。 プロジェクトで使った技術、特にアーキテクチャについてを一番見ていると思います。次にプロジ
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
発表資料作り、全体的な流れは 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 割 引用しやすいワー
僕はチーム join 時に、Docker は初手で剥がすし、GitHub Actions でやっているワークフローの全体像を把握するのを次に行う、というのを基本的にはやっている。これはシステム構成やデプロイ周りの全貌を把握するのが好きなのと、何かが起きたときにコレをやっているのといないのとで問題切り分けの精度に圧倒的な差があるからなんだけど、join 直後にやるのが最適解とは限らない場面もある。 チームの人員構成として、テックリード業を既に担っている人が居る場合、追加人員にはテックリード未満の「プラスの工数として数えられる戦力」となって欲しい。この戦力というのは、「目の前に積み上がった問題を一緒に解いて欲しい」という期待。問題と言うよりも、既にタスクになっているものを消化したい、という期待の方が大きいと思う。 そういう期待があるときには、ちんたら Docker を剥がしている場合ではなく、
昨日「動いたけどチームメンバーを説得するのが面倒で、秘蔵のブランチになってしまう」って言ったけど、この気持ちはどこから出てくるのか。 分かりやすい Cons があると、反発が予想できて、その反発を解決するところまで労力を割くほどの気持ちが無いので困る。「直ちに問題になるわけじゃないが、どちらかというとやった方がいい、でもリスクもある」という選択肢を選べずにズルズルと現状維持に向かう圧力は、ある。チームの同質性が高いうちはほとんど困らないんだが、人数が増えたり、別の職種が増えたりするごとに「面倒」さはどうしても増していく。 我々の信念として以下を持ってはいるが、現状維持に向かう圧力がある中で変化を加えるのはそこそこ労力が要り、閾値を超えると変化が発生しなくなってしまう。 業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。 素早く変えてもし仮にダメだったら素早く
2 月から、Mackerel チームの所属になった。 今日から異動して Mackerel チームです。非正規ルートでの要望でもいい感じにやるので何でもください！— Takafumi ONAKA (@onk) February 1, 2023 これを期に、せっかくなのでコードを読まないマネジメントスタイルを試してみようと思って、実践している。 今までは自分が一番プロダクトのコードベースに詳しい状態を作ってきていて、障害対応でも嬉々として先頭に立つようなテックリードスタイルだった。 この姿が天職と思っているが、今までの人生で、コードの細かい話が通じない (というか、共通言語や会話のレイヤーが違う) けれども非常に信頼できるマネージャーと仕事をしてきた経験はあるので、自分も彼らのようなムーブが可能なんだろうかとやってみたくなったのだ。知識欲が減衰した老害化現象ではないと思う。きっと、たぶん。 も
これは はてなエンジニア 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 キャッシ
「次の職場が 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 のはてなブログ
昨日（もう日付余裕で回ってるので一昨日だな）Findy さん主催のイベントで話してきた。 speakerdeck.com 背景 近年「エンジニアは事業貢献してこそ」「エンジニアもユーザファーストでビジネス貢献」といった言説がIT界隈で増えて来ている感じがしている。 ……とたまたま昨日関連してるようなしてないような話をしている エンジニアとビジネスの距離感の難しさ｜ばんくし｜note という記事があったので書き出しを真似してみたんだけど。 昨今、ビルドトラップに陥るな、アウトプットじゃなくアウトカムに着目しろ、って言われることが増えてますよね。でも僕は逆張りして、アウトプットにまず着目しろという声を上げておきたいのです。 開発生産性（いろいろある*1）の話をするときに、ディスカバリーとデリバリーの 2 軸で考えるのはコモディティ化してきたと思う。でも、それによって、デリバリーの重要性が薄くな
タイトルがすべて。 思いついたら手を動かしてしまう性質なので、秘蔵のブランチを大量に持っている。 秘蔵のブランチというのは、動いたけどチームメンバーを説得するのが面倒とか、テスト書くのが面倒とか、だいたい動いているけどやりきるのが面倒とかで main にマージしていないヤツ。 例えばフレームワークのメジャーバージョン上げるブランチとか、依存ライブラリをより一般的/現代的なものに交換するブランチや、より良い設計を思いついたのでガッと書き換えてしまうブランチが多いかな。 だいたい 1 年所属していると 80 ブランチぐらい溜まるので、週 1 つ以上は何か作りかけてる計算になる。 ローカルブランチの数、プロンプトに出しておくかな……。(秘蔵のブランチが溜まってる— Takafumi ONAKA (@onk) March 28, 2017 もちろん自分でいいアイディアだと思っているから実装している
自分がこうありたいというメモ。 作業者と開発者の違いとして、問題解決への寄与だとか、創意工夫の余地があるかというのがありそう。 これは今 GPT-4 に聞いた。 Q: 作業者と開発者の違いを100文字ぐらいで教えて。 A: 作業者は指定されたタスクや手順を実行する人を指し、特定のルーチンや手順に従って作業を進めることが主な役割です。一方、開発者は新しい製品やソフトウェアを設計・構築する人を指し、創造性や技術的なスキルが求められます。作業者は指示に従い行動し、開発者は新しいアイディアや解決策を生み出します。 単なるタスクの遂行でなはく、より多くの責任とリーダーシップを求めている コードを書くだけではなく、問題解決や創意工夫の余地が多くあるタスクが欲しい 自分のアイディアをベースとして、形にすることで、プロジェクトを完遂したい そもそも何が問題なのかを明らかにするだとか、最適な解決策を見つける
吉祥寺.pm30 で、チューニングがテーマだったので、マネージャとメンバー間で期待値をチューニングするという LT をしてきた。 トークタイトルは熊とワルツを。トム・デマルコの本です。 熊とワルツを リスクを愉しむプロジェクト管理 作者:トム デマルコ,ティモシー リスター日経BPAmazon 「管理」という言葉 「管理」と訳される単語は色々ある goo 和英辞書 によると 〔経営〕management 〔経営，運営〕administration 〔統制〕control 〔監督〕supervision 英辞郎 on the WEB によると administration〔【略】admin. ; adm.〕 caretaking（建物・土地などの） caretaking〈英〉（学校などの公共施設の） charge conduct（業務などの） control custody（大事な物の） d
先日 ヘンリーで活躍中の id:Songmu を訪問 | はてな卒業生訪問企画 [#3] - Hatena Developer Blog という対談記事でもオンボーディングについて話したんだけど、社内では最近「3ヶ月で3連勝」を標語にしている。 オンボーディングとは 採用や異動などでチームにジョインした後に行う、早期戦力化のための施策のこと。開発環境のセットアップやチームの説明だけじゃなく、戦力になるまでのプロセス全部を指していそう。 僕らは各アカウント作成や開発環境構築はチェックボックス化してドンドン進められるようにしている *1 し、事業の説明、組織の説明、システム構成の説明をする場を設定したり、技術スタックへの入門のための実績解除システムを用意したりしてきた。 これらのドキュメントに従って作業を進め、実績を解除していくことで、作業的・技術的な道標はあるものの、オンボーディングプロセス
先日 Wantedly さんのエンジニアリングマネージャー座談会に出演させていただいた。 wantedly.connpass.com テーマは、「エンジニアリングマネージャーの課題を相談したい人が多い」「その相談パブリックにしよう」なので、自分が最近課題に思っている「変化の速度感」についてざっくばらんに会話できたらなーというのが期待だった。 イベント中には、大きく 4 つの話をしたのかな。それぞれ会話の中では話しきれなかったことも補足しつつ書いていく。 技術スタックが違うチーム プロダクトと専門組織のバランス 専門組織を立ち上げるポイント 採用と oss-guild 技術スタックが違うチーム リンク先を見て貰うと顕著に分かると思うけど、はてなでは、そこそこバラバラな技術スタックを使っている。 hatenacorp.jp インフラは AWS、Google Cloud (オンプレはやっと撲滅し
Hatena Engineer Seminar #17 にて発表しました。 hatena.connpass.com Hatena::Letの式年遷宮 from Takafumi ONAKA www.slideshare.net 発表内容をかいつまんで記事にも書いておきます。 Hatena::Let とは はてラボ のサービスの一つ。 僕も入社するまで、はてラボ == ベータ版、だと思ってたんですが、 ラボならではの挑戦的なサービス 運用費が会社持ちで、会社の名前で出しても良い、はてなスタッフの有志が運営するサービス、という制度 も含んでいます。 で、Hatena::Let は、現在は主に id:onk が開発している、ブックマークレットをかんたんに作成・公開できるサービスです。 ソフトウェア式年遷宮とは 初出は 2013 年の id:kenjiskywalker によるもので、このときはイ
本記事は、はてなエンジニア Advent Calendar 2020 の 18 日目の記事です。昨日は id:YaaMaa さんでした。 yaamaa-memo.hatenablog.com 社内チャットではこの話で盛り上がったときにトライ木も作られており、良い頭の体操になっていました。 さて、本題。 Hatena::Let を眺めていて、こんな URL に気づいた。 http://let.st-hatelabo.com/onk/let.iframe?code_id=g5G0uOeEqfcA;key= クエリパラメータにセミコロン……！ パッと考えるとこれは { code_id => "g5G0uOeEqfcA;key=" } となりそうで、というか Ruby で実際にパースするとそうなる。 uri = URI("http://let.st-hatelabo.com/onk/let.ifr
例えば日記を書くときに、午前 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
何番煎じか分からないけど、最近やったので。 前提知識 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
最近買ったイヤホンたち - id:onk のはてなブログ
密閉型イヤホン以外でWeb会議アドベントカレンダーに遅れて参戦！ こういう状態。 ここ3年で増えたヘッドンホホたち SONY WH-1000XM4 www.sony.jp ヘッドフォンですね。2020-09 に買った。 外音取り込みは、外の音が聞こえるイヤホンを↓でいっぱい買ったので、むしろ外音を取り込まないために使うヘッドフォンになった。 ノイズキャンセリングは最高に便利。僕も妻も机を並べて WFH しているので、同時に会議すると声が混ざって困り、この子に付け替えている。 AfterShokz OpenComm OPENCOMMjp.shokz.com 骨伝導。2020-11 に買った。 耳を塞がず (外耳炎にならなくて最高) に外の音が自然に入ってくる (在宅作業しやすくて最高) のはものすごく快適で、しばらく「最高〜〜〜〜！！！」と思って暮らしていた。 完全ワイヤレスではなく、ヘッド
RSpec では context 間の違いを表現するときにのみ let を使う - id:onk のはてなブログ
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
要は以下の記事の繰り返しなのだが。 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/
この記事は はてなエンジニア Advent Calendar 2023 の 1/2 の記事です。昨日は id:nakataki の 1904年になりました(dayjsでの年入力の話) - nakatakiの日記 でした。190x 年から脱出できない面白い不具合でした。 変化バジェット 「変化バジェット」という考え方があります。というか世の中には無いんですが、僕は社内でこの概念をよく使っています。 Google 検索 *1 Twitter 検索 私が発した言葉のログしかありません だいたい名前から想像するものと同じなんじゃないでしょうか。組織が変化に対して許容できる予算枠だったり、組織が変化に対して投資する予算枠だったりを指しています。 変化バジェット＝許容量 変化バジェットは、組織が効果的に変化を取り入れ、消化できる能力の範囲を指します。 組織の変化に許容量があるという概念は、組織に対して
「いつもの」が結構ありそうなので書いておく。 app.rb ペラ 1 でツラくなったときの対策はだいたい sonots パイセンの ちっちゃくはじめておっきく育てる sinatra アプリの作り方 に書いてあって、これは今でも有効なので読んでおくと良いです。 ディレクトリ構成 REPO ├── app.rb ├── bin/ ├── config/ │ ├── database.yml │ ├── initializers/ │ └── locales/ ├── config.ru ├── Gemfile ├── Gemfile.lock ├── helpers/ ├── models/ ├── public/ └── views/ sinatra らしさをなるべく残してある 例えば config/boot.rb を用意するかは非常に悩んだのだけれど、起点は app.rb であって欲しい
id:uzulla、id:moznion と共に curl gotti というチーム名で出場しました。このメンバーでやるのは去年に引き続き 2 回目。 三行で 最高得点 2125 で予選通過ならず 繰り上がり当選した！！！ ほぼいつもの力が出せた。ので実力不足である。。 とても楽しめた良問だった。ありがとうございます 多分この辺の施策をやったんだと思う condition.json を静的に返す 雑に INDEX 張る features の LIKE 検索を正規化して撲滅 xxxRangeId カラムを追加 なぞって検索の N+1 改善 PHP のチューニング DB のチューニング ORDER BY popularity DESC, id ASC をどうにかする DB 2 台構成に Bot に 503 を返す 自分が考えたことや手を動かしたことは分かるんだけど、それ以外のチームメンバーがや
はてなは 7 月決算なので期のふりかえりをやっていたんだが、今期は「放っておくと進まない仕事を進めるために、時間を確保する」ことで進むようになった期だった。ちなみに前期は「放っておくと進まない仕事を進めるために、締切を設定する (強制力を持たせる)」ことで進めようとしていた期だった。 放っておくと進まない仕事とは、優先順位が低い仕事のこと。やってもやらなくても直ちに影響はない仕事をどうやったら進められるのかというのは長年ずっと課題だったが、やっと自分の中である程度答えが見えてきたかもしれないので記しておく。書き出してみたら至って普通なんだけど、以下をやっている。 見積もる 締切を作る 締切を宣言する 時間を押さえる 見積もる チームで見積もりを行い、まずはタスクの重さや実現方法についての共通認識を持つ。 タスクを分解する、とも言い換えられる。やるべきなんだけど気が重い仕事はとにかく分解しま
実装を進める上で障害になりそうなところを先回りして直してるように見えるけど、一体どうやって検知しているかという話題。 結論から言うと「慣れです」なんだけど、こういう考え方があるよというのを紹介しておく。 mikadomethod.info ちょうど10年ぐらい前に話題になった手法だけど、考え方としてはまだまだ現役です。 概要は本家なりこの辺のリンク先なりを見て貰って。 開発者のためのソフトウェアテストのスキルアップ | Think IT（シンクイット） 大規模コードをリファクタリングする方法『ミカドメソッド(Mikado Methood)』について | Futurismo テストとリファクタリングに関する深い方法論 #wewlc_jp レガシーソフトウェア改善ガイド | Amazon 僕の理解は 1 ループ目 やりたいことを実現するコードを書く ギャップが無ければサクッと実装して終わり
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=
Lunatic Squadron 2nd on Twitter: "ウェーク島の海軍部隊では飢餓が蔓延する状況でさえ下っ端への制裁が止むことなく、そのため駆逐艦初月・涼月に乗って最後に到着した体質劣悪な補充兵は全員死んだという話 https://t.co/oNK0E9E1jF"
ウェーク島の海軍部隊では飢餓が蔓延する状況でさえ下っ端への制裁が止むことなく、そのため駆逐艦初月・涼月に乗って最後に到着した体質劣悪な補充兵は全員死んだという話 https://t.co/oNK0E9E1jF
資料は こちら です。 背景 アーキテクチャ的に何かを足したいとき、我々はチーム開発を行っているのだから、チームの共通認識を変えるということになる。認知負荷が高い場合は提案を拒否されてしまうので、認知負荷をできる限り小さくして導入したい。つまり差分の最小化です。*1 現在のコードベースと、入れたいアーキテクチャを対比させつつ、こう導入するのがベストと見切るところが今回のトークの面白ポイントです。 PoEAA のデータソースのアーキテクチャに関するパターン PoEAA は 20 年前の本なので、当時の開発風景を想像できる人と会話しながら読むと良いです。エリックエヴァンスの DDD 本も似た時期ですね。2002 年は Java 1.4 がリリースされた頃。デザインパターンや UML や XML が流行っていた。ライブラリのパッケージマネージャやセントラルリポジトリがまだ無い。*2 再利用性があ
と成長への近道なんじゃないかという仮説。 積極的フィルターバブルとは resize.fm #100 で id:nagayama が語っていた概念。44:10 辺りから。 anchor.fm 新しいことを始めるときに、Instagram でサブ垢を作って、その関係の人しかフォローしない タイムラインは全部スケボーになる 自分の価値観が、いかに板に乗って高く飛ぶか、に変わっていく 業界用語や技術のトレンドとかが自然に入ってくる 以前僕も似たようなことを言っていた。 短期間で新技術を学ぶ技術 from Takafumi ONAKA このときは情報を浴びてインデックスを自分の中に持つことを目的としていたが、いわゆる近接性バイアス、接触頻度が価値観に与える影響というものも大きいんだろうな、と思う。 これを聞いたので、僕も Instagram でサブ垢を作って、#kendama タグで検索して、100
この記事は Mackerel Advent Calendar 2023 の12月1日の記事です。トップバッターいただきます。 お前誰よ Mackerel チームでエンジニアリングマネージャーをやっている id:onk です。最近は特に OpenTelemetry 対応を進めているチームのそばにいます。 今日の話 個人で Mackerel をどう使っているかの一部をチラ見せします。 まずはこのダッシュボードを見てくれ。 我が家のダッシュボード リモートワークになってから快適に暮らすために、気温、室温、二酸化炭素濃度、気圧なんかを測って投稿している。二酸化炭素濃度が上がるとアラートを鳴らして換気するなどのアクションを取りたいし、気圧が急激に下がるときは頭痛ーるのようにアラートを投げたい。というわけで Nature Remo や Netatmo を利用して測定しています。 測っている値は 3 年
エゴサが趣味なので、社内の Slack のキーワード通知をめちゃくちゃ便利に使っている。 slack.com 何か見ておくと良いことがありそうなものを片っ端から通知するようにしているんだけど、100 個が上限なの知ってた？ 100 個以上設定しようとするとこうなる 僕はこんなキーワードを入れています。適当に分類しながら見てみよう。 自分 onk, o/nk, on/k, おんく, 大仲, onaka, 眼科 自分の名前やハンドルネームを入れておくと、どこかで自分が呼ばれたときに気づけるようになる。 定時外だと親切でキーワード通知避けのために / を入れて発言する人もいるので、それも通知させるためにこういうキーワードになっています。戸籍ネームはほっっとんど呼ばれることは無いんだけど、念のため。 「眼科」は中心性漿液性網脈絡膜症になってるっぽいけど放置してたら T シャツが作られたので、戒めの
どこかに書いておかないと確実に忘れて困る。 UHK とは コレです。 ultimatehackingkeyboard.com 割れてる、60%、row-staggered、半田付け不要で、これ以上沼に踏み込みたくない人間には最高です。 v1、v2 と 2 台買ってきた。 UHK 2 台目届いた。茶軸からピンク軸にしました。 pic.twitter.com/apft63dNxW— Takafumi ONAKA (@onk) May 1, 2022 キーマップ 専用アプリでキーマップを変更し、キーボードに書き込める。接続されているキーボードをそれぞれ認識してくれるので、複数台持っていても安心です。 以下に設定していますが、とりあえずで使っているので全然拘れてない。丸 3 年ぐらい使ってて全然カスタマイズできていないのでだいぶ老化したと自分でも思う。 左右の Space（？）手前の謎キーを Mo
夢、テレビを見てたら、onkさんが教育番組の講師としてレギュラー出演していて、言葉の成り立ちに関する歌や踊りを披露される。 色とりどりの衣装に身を包むわけでもなく、いつものRubyKaigiのTシャツにスニーカーでスタジオに登場されていた。 プログラミング好きな人物を増やすには、まずは子供に向けて、そして国語教育をしっかりしなければいけないのだなあ、と感心した。 考察 実際のところ収録にどれくらい時間がかかるのか気になる。毎日10分の番組に出演しながら、フルタイムの仕事と共存できるものだろうか。
はぴば - id:onk のはてなブログ
おはようございます。onk です。2021年12月18日の、朝です。11時なので、朝というか、昼ですね。ここでタイマーをセット。 この記事は、やんちゃクラブリスナー Advent Calendar 2021、18 日目の、記事です。 やんちゃさん、誕生日おめでとうございます 本日 18 日は yancya の誕生日です。 知ったのいつだっけな。 @chiastolite による誕生日 Advent Calendar 界隈でよく話題に上がるので以前からワイワイしている。 adventar.org 誕生日 Advent Calendar、@yancya 氏に取られたｗ— Takafumi ONAKA (@onk) November 4, 2014 @onk 実は同じなんですよねｗ— yancya (@yancya) November 4, 2014 @chiastolite @onk おめでと
gorogoro.rb とは 大江戸Ruby会議08でぺんさんが最後に再生していた頭のおかしい (褒め言葉) Quine。 僕の発表の最後に紹介したごろごろしたQuineコードです #oedo08 pic.twitter.com/mkp8TaVaVt— ぺん！ (@tompng) February 11, 2020 コードはこちら https://gist.github.com/tompng/45d93b3386b5986a94b9c3c8beecba69 実装を見ていく アスキーアートプログラミング構文 まず見慣れた (毎年 Ruby 会議に参加しているうちになぜか見慣れてしまった) アスキーアートプログラミング構文が使われている。 eval((c=%{ ... }).split*'') 詳しくは あなたの知らない超絶技巧プログラミングの世界 の第 2 章を参照だけど、%{} の中がプロ
登壇資料の作り方 - id:onk のはてなブログ
発表資料作り、全体的な流れは 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 に流し込んで すごく雑
去年 に引き続き、今年買ったものコーナー。 はてなに入社して明らかに変わったのが「日常をブログに残すようになった」ことで、その中でも「今年買ってよかったもの」はついタグを追ってしまうし追ったら買っちゃうし経済がどんどん回ってしまう。よくない。 だいたい買った順です。 SmartSleep ディープスリープ ヘッドバンド id:threetreeslight のツイートを見て買った またKoteraさんにデバイス教えてもらった。 Deep Sleepをboostできて睡眠品質向上できるらしい 🤔 毎日のtotal sleep timeが5.5hなので、めっちゃ期待したい。 SmartSleep ディープスリープ ヘッドバンド https://t.co/eNtkK2N6N6 ちょっと高いけど、だめだったら返品できるし買ってみるか。 pic.twitter.com/6pw4zusn54— th
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
体制を考えるときに意識していること - id:onk のはてなブログ
Smart UI パターンが再評価される世界 - id:onk のはてなブログ
書類選考時に見ているポイント - id:onk のはてなブログ
ストーリー性のあるプレゼン - id:onk のはてなブログ
意識的に職位を下げる - id:onk のはてなブログ
チームに浸透させるのが近年では難しくなっている - id:onk のはてなブログ
手を動かさないマネージャーを試している - id:onk のはてなブログ
「キャッシュは麻薬」という標語からの脱却 - id:onk のはてなブログ
Ruby/Rails の勉強に何読んだらいいかと聞かれたとき - id:onk のはてなブログ
branch を寝かせるときは TODO.txt を置いている - id:onk のはてなブログ
作業者じゃなく開発者でありたい - id:onk のはてなブログ
期待値をチューニングする - id:onk のはてなブログ
オンボーディングは3ヶ月で3連勝を目指す - id:onk のはてなブログ
フルタイムでやる仕事を作る #wantedlydev - id:onk のはてなブログ
ソフトウェア式年遷宮という概念の歴史と、Hatena::Let での実例 - id:onk のはてなブログ
クエリパラメータのデリミタに ; を使うこともできる - id:onk のはてなブログ
アプリ内の日付変更線をズラす系の実装 - id:onk のはてなブログ
AWS Lambda でコンテナに入れた Sinatra を動かす - id:onk のはてなブログ
irb に show_source があることをもっと知らしめたい - id:onk のはてなブログ
変化バジェットという考え方 - id:onk のはてなブログ
久々に sinatra app を作った - id:onk のはてなブログ
ISUCON10 予選敗退^H^H突破した - id:onk のはてなブログ
放っておくと進まない仕事を進めるために - id:onk のはてなブログ
先回りするコツとミカドメソッドという手法 - id:onk のはてなブログ
使用頻度とコマンド (エイリアス) の文字数を合わせたい - id:onk のはてなブログ
YAPC::Kyoto 2023 で ORM について喋ってきた - id:onk のはてなブログ
積極的フィルターバブルで価値観を破壊する - id:onk のはてなブログ
Mackerel 個人ダッシュボード使いこなし術 - id:onk のはてなブログ
Slack キーワード通知に設定しているワード 100 連発 - id:onk のはてなブログ
Ultimate Hacking Keyboard のキーマップメモ - id:onk のはてなブログ
にほんごであそぶonkさんの夢 - hitode909の日記
gorogoro.rb を読んだ - id:onk のはてなブログ
今年買ったもの2020 - id:onk のはてなブログ
www.weblio.jp
media-innovation.jp
kabu-motty.hatenablog.com
www.nikkei.com
kon3815.hatenablog.com
takeyu.hatenadiary.org