エンジニアはもっと図を書こう - 生涯未熟
たまには軽い話題をば。 自分の中で信頼できるエンジニアかどうか？を見極めるひとつの指標で「込み入った議論の時に図を書くかどうか」というのがあります。 今までの経験上、図を書く派のエンジニアは割と良い感じの人が多かったので採用している指標なのですが、何故これが機能しているかというのを改めて考えてみた。 他者の認知負荷を理解している コンテクストを合わせることにコストをかけられる意識がある 自分の思考の整理するツールとして図を扱えている ザッと挙げましたが、この３つが機能している要因なのかなという気がしています. 他者の認知負荷を理解している あれやこれやエンジニア間で技術議論している中で、「Aさんはこの領域に詳しいけどBさんはこの領域にはほどほど詳しいくらいだな」という個々のレベル差に応じて認知の負荷がかかります。ただでさえ議論していると結構なスピードで話が展開されていくので、認知負荷が更に
「もっとCPUの気持ちが知りたいですか？」出版プロジェクトで考えていること｜とげとげP
CPUと親しくなれる！ 「もっとCPUの気持ちが知りたいですか？」出版プロジェクト！ クラウドファンディングを実施中です。この文章を書いている時点で、566名の方に支援をいただき、達成まで残り34名となりました。ありがとうございます。 peaksのクラウドファンディングのページでは、伝えきれなかった話などをかいてみたいと思います。 どこまで知ったらCPUの気持ちが理解したって言える？この本の出発点は「CPU関連の知識ゼロから出発して、どこまでCPUの内部構造を理解したら"CPUの気持ちが理解できた"って言えるのかな？」とふと思った疑問が出発点だったりします。ベースとなる同人誌版を執筆するにあたり「このあたりまで知っておけばよいのではないですかね」と過去の経験からいろいろ考えてみた結果、「パイプライン」「割り込み」など後半の章で解説している機能まで知っておけばよいのでは、となりました。ですの
不満への過剰な共感は状況を悪化させる - Konifar's ZATSU
何かを相談された時、自分は相手の状況や主張にまず共感を示してしまいがちである。嘘をついて同調しているわけではないのだが、この姿勢自体が状況を悪化させることもわりとあるよなと思っていて、雑にまとめておきたい。 たとえば「他チームの◯◯さんが開発の状況を理解してくれていない。理解する気も見えない」といった相談をされたとする。それに対して、「あーなるほど、たしかにねぇ」みたいなことを言った瞬間に、溝を広げることになってしまうかもしれない。 この場合、本来はお互いの歩み寄りが必要な話なのだが、相談してくれた側に寄り添って話すことで当事者間の関係性がよくなるどころか悪化することもありうる。吐き出してスッキリするかもしれないが、根本の解決にはならない。 チームメンバー思いのマネージャーや組織の中の"いい人"ほど、知らず知らずのうちにこの罠に陥りがちな気がする。おそらくコーチングを学んだ人はこういう相談
Fluent Bit入門 - 軽量高速なログ収集ツール - 2021-05-18 - ククログ
1 Fluent Bitとは軽量高速なログ収集ツールです。ElasticsearchやApache Kafkaなどの様々なサービスにログデータを転送できます。 プロジェクト公式サイト GitHubレポジトリ 全体がCで実装されているのが特徴で、RubyベースのFluentdの兄弟プロジェクトという位置づけです。 この記事では、Fluent Bitに関する基本的な質問に答えて、具体的に使い始めるための最初のステップについて解説します。 Fluent Bitのよくある質問 (FAQ) [質問1] Fluent Bitはどこで使われていますか？ 現在はKubernetesのようなコンテナ環境で広く利用されています。 利用例1: AWS FireLens 利用例2: Google Cloud Platform Ops Agent いずれもクラウドプラットフォームが提供しているログの収集・解析サービ
Tests as Documentation - たにしきんぐダム
production code の設計についてはよく議論される一方、ユニットテストをどう書くべきかについてはあまり議論されることが少なく。とにかくカバレッジが高ければヨシみたいな感じで軽く扱われていることが多い気がする。 その結果、テストを書くときやとりわけテストを追加するときに "良くない" 方法でテストを追加/拡張してしまい、メンテナンスしにくく壊れやすい・(未来の自分でも)読んでも何を検証しているのか分からない、テストが落ちても不安だけを煽り何が問題なのか分からない、技術的負債が誕生してしまう。 詳しいことは本 ( XUnit Test Patterns など? 詳しい人は僕に紹介してください)を読んだりチームメンバーと議論するのが良いと思うが、この記事を読んでテストの書き方に対する意識を啓発できたらなと思っている。 理想を述べるのは簡単だけど現実は大変、頑張ろう introduct
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エルザ、Ubuntu搭載の15.6型モバイルワークステーション
