より少なく、しかしより良く - 「エッセンシャル思考」読んだ - $shibayu36->blog;
エッセンシャル思考 最少の時間で成果を最大にする 作者:グレッグ・マキューンかんき出版Amazon 自分がなんでもやりたいタイプなので、この本に書いてあることは中々刺さった。幸福になるには「より少なく、しかしより良く」を追求すべきという本。プライベートや仕事でとにかく忙しく時間がないと思っている人は読んでみると良い。 印象に残ったのは次のことだ。 現代人の最優先課題は、優先順位づけの能力をキープすること 睡眠不足では一番最初にそこが減ってしまうのでダメ 一流のバイオリニストは1日平均8.6時間の睡眠 & 週平均2.8時間の昼寝。睡眠による並外れた集中力で、1時間あたりの練習効果を最大限にする もっとも厳しい基準でやることを決める 「絶対やりたい」「やらない」の2択にする。やろうかな程度なら却下、イエスと言うのは絶対やるしかないと確信した時だけ 自分の中で最重要基準をひとつ用意し、100点満
Goの学習のため書籍を三冊読んだ - $shibayu36->blog;
A Tour of Goが終わり、もう少しGo自体の深掘りをしたいためGoの書籍をいくつか読んでみたのでメモ。今回読んだ書籍は以下の三冊。 実用 Go言語 ―システム開発の現場で知っておきたいアドバイス 作者:渋川 よしき,辻 大志郎,真野 隼記オライリージャパンAmazon Go言語プログラミングエッセンス エンジニア選書 作者:mattn技術評論社Amazon 改訂2版 みんなのGo言語 作者:松木 雅幸,mattn,藤原 俊一郎,中島 大一,上田 拓也,牧 大輔,鈴木 健太技術評論社Amazon それぞれの感想としては 実用Go言語：業務で使っていると起こるような色んなHowToを大量に提供してくれている。今の段階で全部読むというより、必要に応じて再度読むインデックス的な使い方が良さそう。クックブック的。 Go言語プログラミングエッセンス：最近出た本のため、最近のGoに即した内容を学
ミーティングが効果的になるように、自分がよく使うミーティングテンプレート - $shibayu36->blog;
何かを進めようと思ってミーティングをとりあえず入れるというのをしてしまうことも多いが、適当にやるとミーティングが終わったが何も進んでいないとなりがちだ。そうならないように、自分用のミーティングテンプレートを作っているので、ブログに書いてみる。 ミーティングの用意で心がけること テンプレートの前に、自分がミーティングの用意で心がけることをリストアップする。ミーティングは「何かを先に進める」必要があると考えるため、次のことを心がけている。 何はともあれ「目的」を最初に決める。「〇〇を決める会議」なのか、「〇〇のアイデア出しの会議」なのか、「〇〇の認識合わせの会議」なのか 目的に合った「会議のゴール・完了条件」を決める。ゴールに到達したら成功、到達していなかったら失敗と振り返ることもできる。また、参加者がゴールに集中することで、横道に逸れづらいという効果もある 会の前に参加者にやってほしい「事前
株式会社はてなを退職しました - $shibayu36->blog;
2021年8月13日の本日が最終出社日でした。しばらく休暇を取り、10月から別の会社でエンジニアをする予定です。 はてなには2010年4月にアルバイトとして入社し、2012年4月からは社員として入社したので、アルバイト2年、社員9年4ヶ月と非常に長い間所属した。仕事の中で、周囲の人の優秀さに圧倒されながら学習とアウトプットをし続け、またいろんなチームや職種を経験させてもらえたおかげで、自分自身がかなり成長できた。はてなに入社できたことで、エンジニア経験がほぼないところから大きく成長できたため、誇張なく人生が変わったと思う。 はてなで経験できたこと 本当に色々経験できたのだが、自分の中で本当に良い仕事ができたなーと思ったことはこんな感じ。 世界規模で動く通知システム はてなブログMediaの立ち上げ カクヨムの立ち上げ 魔法のiらんどのリプレース ブログチームでのチーム改善や、Mackere
ペア制度を導入して、開発チーム内の相談しやすさ向上・知見展開・透明性向上を狙う - $shibayu36->blog;
最近プロジェクトマネジャーを担当していた仕事で、開発チーム内の相談しやすさ向上・知見展開・透明性向上・WIPタスク数減少を狙ってペア制度というのを導入した。今回は導入した背景、導入した仕組み、そしてその振り返りについてブログに書いておきたい。 導入した背景 ちょっとした相談のしづらさ 知見展開のしづらさ タスク状況の透明性の不足 WIPなタスクが多く、プロジェクトマネジメントが複雑 ペア制度を導入する ペア制度の振り返り ペア制度を振り返っての点数評価 導入して良かったこと 導入して困ったことや、改善すべきポイント 一人当たりの短期的な開発効率は下がったか？ まとめ 導入した背景 最近はエンジニア6~7人程度のフロントエンドフレームワーク置き換えプロジェクトのプロジェクトマネジャーをやっていた。ペア制度を導入する前は、大体1~6ヶ月程度かかる粒度のタスクを1人にアサインし、人数と同じだけの
AirPods ProとKrispでリモートミーティングの音声を快適に - $shibayu36->blog;
最近家族と同室でリモートワークをしている。自分と家族は別々で仕事をしているので、家族が電話中の時に自分はミーティングをしていることがよくある。その時、家族の声によってミーティングの声が聞き取りにくくなったり、家族の声がミーティングに入ってしまうと、快適なミーティングができなくなってしまう。 この問題に対処するため色々試したところ、AirPods ProとKrispを使うと非常に快適になるということが分かったので紹介。 家族の声でミーティングの声が聞き取りにくくなることを防ぐ これは単純でAirPods Proのノイズキャンセリング機能がかなり優秀なので、それをONにするだけで終了。 Apple AirPods Pro ワイヤレス充電対応 Apple(アップル)Amazon ただノイズキャンセリング機能を使うと自分の声が聞き取りづらくなるという問題もあるので、静かな時は外部音取り込みモードに
部下の困りごとをマネジャーが解決しすぎない方が良い - $shibayu36->blog;
マネジャーをやっていると、1on1でいろいろな困りごとを相談されたり、雰囲気を感じ取ったりで、部下が困っていることがよく見える。その時「頑張ってマネジャーの自分が解決しないと！」と思い、全部自分で解決してしまうことがある。しかしこのようなやり方は正直デメリットが多く、やめたほうが良いと考えている。 これを続けていると、例えば 部下が問題はマネジャーが解決してくれるものと思いすぎてしまう可能性がある。するとこの仕事はマネジャー、この仕事はエンジニアと過度にカテゴリー分けがなされることがある 部下の問題解決能力、相談能力などの向上機会を奪ってしまう 細かい問題を解決しているだけで時間がなくなってしまう 結果的にスケールもせず、解決に取り組めない問題が増えていく 本当に解決すべき重大なチーム課題に取り組む時間がなくなる などといったことが起こりうる。こうなると実際には自分が色々問題を解決できてい
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
0になるくらいなら0.1でもいいから学ぶ - $shibayu36->blog;
以前は、学習するときはきちんと頭に入ることを重視しようという考え方をしていて、パソコンに向かえる時に集中して勉強するようにしていた。最近はその考えを変えようとしていて、0になるくらいなら0.1でもいいから学ぶと思うようにしている。 この考えに変えたい理由は、今は子供が小さく、2人目も産まれたため、育児によって自分の自由な時間が減ってしまったからだ。2人目が産まれて驚くほど自由な時間が減った。大体1日で自由になる時間は、2〜3時間くらい（朝1時間、夜2時間くらい）。この時間で学習も趣味も休息もプライベートのTODOも全て賄う必要がある。ちなみに子供が体調を崩したり、何かイベントがあったりすると時間は全て吹っ飛ぶ。 こんな中、きちんと頭に入ることを重視しすぎると、もう全く何もできなくなってしまうなと思った。そのため、効率が悪くてほとんど学習になっていなくても、0.1でもいいからやるようになった
「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;
最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番
ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;
先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。 DNSについて学んだこと Software Design 2015/4のDNSの教科書が非常に勉強になった。また、 インターネット10分講座：DNSキャッシュ - JPNICも参考になる。 権威サーバとフルリゾルバ まず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。 権威サーバ ドメインの情報を管理し、自分の管理しているゾーンの情報を提供するだけのサーバ 問い合わせたドメインが自分のゾーンの管理下ではない場合、別の権威サーバへ委任するという情報を返す コンテンツサーバとも言われる? 例) co
「みんなのGo言語」を読んだ - $shibayu36->blog;
Go言語の学習のため、A Tour of Goに引き続き、「みんなのGo言語」を読んだ。 みんなのGo言語[現場で使える実践テクニック] 作者:松木雅幸,mattn,藤原俊一郎,中島大一,牧大輔,鈴木健太技術評論社Amazon 「みんなのGo言語」はGo言語を実践的に使うためのTipsがいろいろまとめられていて非常に良かった。Go言語のA Tour of Goをやったけど、次にどうすればよいかわからない、具体的にGoの良い書き方が分からないという人が読むと非常に勉強になりそう。 僕はまだGoをそこまで書いていないので、「第1章Goによるチーム開発のはじめ方とコードを書く上での心得」と「第4章コマンドラインツールを作る」が非常に参考になった。例えば以下のようなものが参考になった(数字はKindleのロケーション番号)。 Goプロジェクトのプロジェクト構成やディレクトリ構成 519, 2389
どうやったら発見した問題をうまく放置できるようになるのか - $shibayu36->blog;
仕事をしていると、様々な問題が発見される。問題を発見した時、とにかくすぐに対処しようとしてしまうことが多い。しかし、そうしていると、タスク量が増えてきたときに問題解決に忙殺され、もっと重要なことに取り掛かれないということが起こりがちである。 「イシューからはじめよ」によると、忙殺されないためには、問題の重要度を見極めて、重要なものだけ重点的に取り組むべきであり、そうでない問題は放置すべきと書かれている。 しかし、そんなことは頭では分かっているのである。それでも問題を見るとすぐに解決しようとしてしまうのである。では、どうやったら発見した問題をうまく放置できるようになるのか。 それについて最近1週間ほど考えていたのだけど、とりあえず以下のことをやってみようという気持ちになった。 それが何か問題かと自問する 問題を少し置いておく 問題を書き出してみて、他の問題と比較する それが何か問題かと自問す
Suffix Trieを使って文字列マッチングする - $shibayu36->blog;
文字列マッチングを行うためのアルゴリズムとして、Suffix Trieを使った探索というものがある。これはテキストからSuffix Trieという構造を作り、パターンをつかってそれを辿ることで、パターンの長さmに対して、O(m)の計算量で探索できるものである。 今回はJavaでSuffix Trieを使った探索をしてみた。 トライ木とパトリシア 先にトライ木とパトリシアについて紹介。 今回Suffix Trieという構造を調べていると、同じような構造としてSuffix Treeというものが出てきて混乱した。よく調べてみると、Suffixの集合をトライ木という構造で実装したものがSuffix Trieで、パトリシアという構造で実装したものがSuffix Treeらしい。 トライ木はnodeを連結していって、その枝に1文字を割り当てて辿れるようにした構造。トライ木は枝に1文字しか割り当てない構
コードレビューを段階的に行ってもらう話 - $shibayu36->blog;
最近コードレビューをどのように回していくかについて考えたことがあったのでブログに書いておく。 コードレビューの目的 コードレビューには誤りの発見以外にいろいろな目的がある。自分の中ではid:hisaichi5518が昔プレゼンでまとめていた目的が結構しっくり来ている。 https://speakerdeck.com/hisaichi5518/kodorebiyufalsehua?slide=8 http://hisaichi5518.hatenablog.jp/entry/2014/10/29/165721 機械的に発見できない誤りの発見 技術力の向上 属人性の排除 コードレビューの目的としては誤りの発見と同様に、技術力の向上や属人性の排除といった教育的側面も重要である。 コードレビューで課題に思っていたこと 自分のチームでは基本的に一人がコードレビューをして、OKだったらmergeをして
最近コード中のTODOコメントの書き方を工夫している - $shibayu36->blog;
コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの
フロントエンド速度改善でやったこと(Expiresヘッダ、faviconのgzip圧縮、JSの読み込み遅延化) - $shibayu36->blog;
フロントエンド速度改善をしようとして参考にしたもの - $shibayu36->blog; という記事を以前に書いたのだけど、結局何をやったか書いて欲しいと社内で言われたので、今回のフロントエンドの速度改善でやったことについて書いてみる。そこまで大したことはやってないので参考程度にどうぞ。 前提 ページのレンダリングが遅いと思い始めたので改善をすることになったのだが、改善をし始めたところChromeのアップデートがあり爆速になってしまった(FirefoxやSafari等はもともと速かった)ので、では明らかにやったほうが良いことだけやりますかという話になった。そのためあんまりbefore/afterもちゃんと取っていないので、今回はやったことの紹介くらいに留める。 やったこと 計測や調査をしてみたところ、以下のようなことはやってしまったほうが良いということになった。 静的ファイルに適切にEx
乱数の性質とセッショントークンの作成 - $shibayu36->blog;
ユーザアカウントのログイン機能とか作ってると、何らかの形でセッション用のトークンを作成する機会がある。今まではこれは適当にランダムな値を利用していればいいんでしょと思っていたのだけど、ちょっと違ったのでメモ。 乱数の性質 http://akademeia.info/index.php?%CD%F0%BF%F4によると、乱数には三つの性質がある。 無作為性：統計的な偏りがなく、でたらめな数列になっているという性質。 予測不可能性：過去の数列から次の数を予測できないという性質。 再現不可能性：同じ数列を再現できないという性質。再現するためには、数列そのものを保存しておくしかない。 この時、少なくとも無作為性のみ満たされていると弱い擬似乱数、無作為性と予測不可能性が満たされていると強い擬似乱数、全てが満たされていれば真の乱数と呼ばれる。ソフトウェアだけでは、真の乱数を作ることができず、真の乱数に
良いビジョンとは何か - ザ・ビジョンを読んだ - $shibayu36->blog;
以前、1分間顧客サービス という本を読んで、「顧客中心のビジョン」を作ることが、熱狂的なファンを作るために必要と書かれていた。チームを自分で率いている以上、チームがどういう価値を提供するのかを示すようなビジョンは必要だと感じた。 チームのビジョンを立てようとは思ったものの、以下のような疑問が出てきた。 良いビジョンとは何なのか ビジョンをどう伝えるか これらの疑問を解決する手助けになると良いと思い、「ザ・ビジョン」という本を読んだ。 ザ・ビジョン 進むべき道は見えているか 作者:ケン・ブランチャード,ジェシー・ストーナーダイヤモンド社Amazon この本は1分間マネジャーシリーズを書いた、ケン・ブランチャードによって書かれた本である。良いビジョンとはなにか、どうやってそのビジョンを作っていくか、などについて、お馴染みのスタイルである小説形式を用いて教えてくれる。ページ数は200ページ強とそ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
notify-issues-to-slackをdockerhubに公開しました - $shibayu36->blog;
