本の内容が頭に入ってくるのは結局は知見まとめノートを作っている時 - $shibayu36->blog;
最近は読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;に書いているやり方で読書をしている。こういう流れだ。 (1)学びたいと思った知識が書いてありそうな本を2~5冊選ぶ (2)1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく (3)全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱりおもしろいと思ったところは赤のハイライトを付け直す (4)赤のハイライトを眺めて、読書ノートに転記する (5)とくにおもしろい部分については、自分の知見まとめノートにカテゴリごとに整理する しばらくこれを続けて感じたのは、結局のところ(4)〜(5)に至るまで書籍の内容が全然頭に入っていないということだ。(4)(5)の時に、はじめて「書いている内容が言いたかったのはこういうことだったのか」と頭が急に理
git logの内容を検索する-Sと-Gの違い - $shibayu36->blog;
ずっとgit logの内容を検索するときに-Sオプションを使っていたが、実は近いオプションに-Gオプションもあり、探したい内容によっては使い分けないとダメということを初めて知った... 詳しくはhttps://git-scm.com/docs/git-logの-Sと-Gのドキュメントを見てほしい。簡単にまとめると -Sは指定した文字列の出現回数が変わるdiffがあるcommitを検索する -Gは指定した正規表現がマッチする文字列がdiffにあるcommitを検索する ドキュメントの事例部分が結構わかりやすくて、以下のようなdiffがあった場合 + return frotz(nitfol, two->ptr, 1, 0); ... - hit = frotz(nitfol, mf2.ptr, 1, 0); -S frotzで検索をかけると、frontsの出現回数は変わってないのでマッチしない
より少なく、しかしより良く - 「エッセンシャル思考」読んだ - $shibayu36->blog;
エッセンシャル思考 最少の時間で成果を最大にする 作者:グレッグ・マキューンかんき出版Amazon 自分がなんでもやりたいタイプなので、この本に書いてあることは中々刺さった。幸福になるには「より少なく、しかしより良く」を追求すべきという本。プライベートや仕事でとにかく忙しく時間がないと思っている人は読んでみると良い。 印象に残ったのは次のことだ。 現代人の最優先課題は、優先順位づけの能力をキープすること 睡眠不足では一番最初にそこが減ってしまうのでダメ 一流のバイオリニストは1日平均8.6時間の睡眠 & 週平均2.8時間の昼寝。睡眠による並外れた集中力で、1時間あたりの練習効果を最大限にする もっとも厳しい基準でやることを決める 「絶対やりたい」「やらない」の2択にする。やろうかな程度なら却下、イエスと言うのは絶対やるしかないと確信した時だけ 自分の中で最重要基準をひとつ用意し、100点満
クラスター株式会社に入社しました - $shibayu36->blog;
2023/07/01よりクラスター株式会社に入社しました。 corp.cluster.mu 今回もいくつかオファーをもらったが、次の理由からクラスター株式会社へ決めた。 とにかくクリエイターを応援したい 社内にもクリエイター気質の人が多そうだ リアルタイム通信サーバーなど、裏側のシステムにワクワクする VR自体が子供の教育を改善しうる とにかくクリエイターを応援したい 転職活動の際にいろんな転職軸を言語化していたのだが、結局のところ自分がどうしても貢献したいプロダクトでなければモチベーションを保てないと感じた。もう一度これまでの仕事を振り返った時、自分は「漫画家・小説家・ブロガーなどのクリエイターが、自分の作ったプロダクトによって報われた時」に非常に嬉しく感じる1ことに気づいた。 クラスター株式会社は現在clusterというメタバースプラットフォームを作っているが、単純にメタバースプラット
LLMを理解する一歩として「ゼロから作るDeep Learning」をやった - $shibayu36->blog;
LLM、GPT界隈を追いかけていて、GPTの仕組みと限界についての考察（2.1） - conceptualizationという記事を見かけた。これを見たとき、「どういうことか全然理解できない」という気持ちになった。また、その他LLMの解説記事を理解できないことが多く、自分の機械学習知識不足が明確になった。 理解できなかったことは悔しいし、LLMやChatGPTをうまく使いこなすには最低限どのような原理で動いているか理解したいと感じた。そこで一歩目として「ゼロから作るDeep Learning」を完走した。 ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装 作者:斎藤 康毅オライリージャパンAmazon 知識なしからはじめたので時間はかかったが、次のように進めていった。 自分もコードを写経しながら読む レポジトリは https://github.co
「マンガでやさしくわかる認知行動療法」読んだ - $shibayu36->blog;
思考のクセを変化させることで、ストレスを軽減させられると良いなあと思ったので読んだ。 マンガでやさしくわかる認知行動療法 作者:玉井仁,星井博文,深森あき日本能率協会マネジメントセンターAmazon 以下のことを学んだ。 状況確認シートで個人の反応を、認知・感情・行動・身体反応で整理することで、思考のクセを理解することができる さらに、その中で認知や行動はどちらかというと変化させやすい。整理をすることで、認知などをバランスを取れたものにとらえやすい効果もある 状況確認シートは、「不安…どうすれば？」不安なときに試したい基本中の基本のこと - ココロクエスト~レベルアップ心理学ブログ~byねこひげ先生 みたいなところでフォーマットも見れる 認知再構成法を使うことで、バランスの取れた認知に変化させることもできる。自分の認知に対して質問を繰り返し、新たな考え方をピックアップする このやり方の一つ
株式会社はてなを退職しました - $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人にアサインし、人数と同じだけの
睡眠に関する本を読んだ - $shibayu36->blog;
睡眠を学びたいと思ったので読んだ。最近自分が全然睡眠足りてなかったということに気づけて良かった。 スタンフォード式 最高の睡眠 作者:西野 精治サンマーク出版Amazon 睡眠こそ最強の解決策である 作者:マシュー・ウォーカーSBクリエイティブAmazon 「スタンフォード式最高の睡眠」の読書ノート * 睡眠負債を返すには3~4週間程度かかるので、週末の寝だめくらいでは機能しない 569 * 睡眠メンテナンスで意識したいのは「最初のノンレム睡眠」をいかに深くするか 620 * グロースホルモンが最も多く分泌されるのも最初のノンレム睡眠 * 睡眠圧も最初のノンレム睡眠で多くが解消される * 最初の90分を阻害すると、その後の睡眠は計測不能となる程乱れる 634 * 普通の人は最低でも6時間以上は睡眠が必要 644 * 眠りが足りているかの一番簡単な点検は自分の感覚。眠りの前後の「眠さ」 +
継続的に学習するために効いたやり方3つ - $shibayu36->blog;
育児していて時間があまり取れない状況下で継続的に学習するために色々な方法を取り入れているんだけど、その中で最近めちゃくちゃ効いた3つのやり方を紹介。 やりたいことリストを作っておく 今日のTODOリストを作る 2分間コーディング やりたいことリストを作っておく 自分が学習したいことの一覧があると、優先度を決めやすくなり、またやりたいことが1つ終わった後すぐに次に取り組むこともできる。そこで僕はTrelloでリストを作り、とにかく少しでもやってみたいと思った開発や、読みたいと思った本などがあれば追加している。 今日のTODOリストを作る 時間が空いてから「今日はこれから何をやろうかな？」と考えていると、途端にやる気がなくなってダラダラしてしまう。そこで先に今日のTODOリストを作っておくということをやっておく。ポイントとしては 細かい家事やプライベートでやること、勉強すること全て含めて同じリ
読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;
最近以下のような記事や本を読み読書法を変えてみたところ、知識の吸収速度・引き出し速度が上がったと感じるので紹介。 kentarokuribayashi.com 知的戦闘力を高める 独学の技法 作者:山口周ダイヤモンド社Amazon やり方 以下のような流れで読書している。 学びたいと思った知識が書いてありそうな本を2~5冊選ぶ 1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく 全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱり面白いと思ったところは赤のハイライトを付け直す 赤のハイライトを眺めて、読書ノートに転記する 特に面白い部分については、自分の知見まとめノートにカテゴリごとに整理する 学びたいと思った知識が書いてありそうな本を2~5冊選ぶ 自分の中で学びたいテーマがあって本を読むはずなので、そのテーマについて書いてありそうな本
メンターを初めて経験する人に、最初に読むものとしてオススメしている書籍たち - $shibayu36->blog;
社内ではこういうおすすめをしてますね(文字数多いのでスクショで...) pic.twitter.com/uzqCh6zubs— 柴崎優季 (@shiba_yu36) 2020年7月7日 こういうツイートして、そういえば社内でメンターを初めて経験する人にオススメしている書籍たちを外部に公開してないなと思ったので紹介してみます。 メンタリングのスキルを学習する時のキーワードは「コーチング」と考えていて、以下の書籍を推薦しています。上から順におすすめ順になっています。この推薦は網羅的にコーチングを学べると言うより、初めての人でもとっつきやすく読みやすいものであることを意識して選んでいます。また、メンタリングを始めるだけなら、書籍の全部分を読む必要はなく、どこまで読んでおくと良いかも書いています。 エンジニアリング組織論への招待 ザ・コーチ コーチングの基本 新1分間マネジャー エンジニアリング組
TypeScriptの型を手に馴染ませるためにやっていること - $shibayu36->blog;
最近TypeScriptが好きで勉強していっている。しかしなかなか型定義周りが手に馴染まず、少し複雑な型定義を読んだり、自分でユーティリティ型を定義したりすることが難しかった。 そこで型を手に馴染ませるために色々学習をしてみたので、やっていることをメモしておく。 まずざっとTypeScriptの型概要を学ぶ まずTypeScriptでの型を簡単に学ぶには以下の2つの資料がわかりやすかった。 TypeScriptの型入門 - Qiita TypeScriptの型初級 - Qiita ひたすら型演習をする 資料を読むだけでは全く手に馴染まないと思ったので、その後ひたすら型演習をしている。 まずは TypeScriptの型演習 - Qiita 。これは先程の型初級、型入門の記事を書いた人が演習問題を作っているため同じ流れで学習でき、さらに解説編も充実しているので、手を動かしながら学ぶのに最適であ
PullRequestからチーム開発の生産性・健全性を測るCLIツールを書いてみた - $shibayu36->blog;
最近、開発チームの生産性や健全性をどのように計測したら良いかについて興味を持っている。その中で「LeanとDevOpsの科学」の中に書いてあるようなデプロイの頻度・変更のリードタイム・MTTR・変更失敗率の4指標や、開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiitaに興味を持った。 一方、それらの指標を考えてみた時、以下のような点について悩んでいた。 マイクロサービスなどで複数レポジトリとなり、さらにデプロイ手法がそれぞれ違う状況の場合、変更のリードタイム = コミット〜本番稼働までの時間を計測するのがなかなか難しい コミットという単位だとかなり小さく、個々人のばらつきも大きすぎるように感じるので、もう少し良い単位はないのだろうか このような悩みから、PullRequestの単位で集計することで、生産性や健全性をもう少し測りやす
現代のソフトウェア開発を学ぶために「正しいものを正しくつくる」を読んだ - $shibayu36->blog;
最近はいかにエンジニアリングの立場でプロダクトを成長させられるかについて考えている。そこで、現代のソフトウェア開発やアジャイルについて学ぶため、同僚にオススメされた「正しいものを正しくつくる」を読んだ。 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について 作者:市谷聡啓ビー・エヌ・エヌ新社Amazon なぜ現代ソフトウェア開発は難しいのかから始まり、現代ソフトウェア開発の不確実性へ対処するためにアジャイルを利用するという流れになっていて非常にわかりやすかった。また「正しいものをつくる」ことと「正しくつくる」ことをうまく切り分けて説明してくれたので、自分の中で論点を整理しやすかった。 「正しくつくる」部分に関しては、これまで自分も注力してきたところであったので、かなり経験知を言語化できた。一方「正しいものをつくる」部分に関しては、まだ経験が
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
今見ているファイル内をSearchしやすくするVSCode拡張を作りました - $shibayu36->blog;
今見ているファイル内をSearchしやすくする「Search in Current File」というVSCode拡張を作ったので紹介です。 https://github.com/shibayu36/vscode-search-in-current-file https://marketplace.visualstudio.com/items?itemName=shibayu36.search-in-current-file 背景 Emacsにはhelm-occurという拡張があって、インクリメンタルサーチからスムーズにファイル内の検索結果一覧を見れる拡張がある。これが現在のファイルを探索するのに非常に便利で愛用していた。 VSCodeでも同じようなことが出来ないかなと思ったので、勉強がてら拡張を作ることにした。 使い方 Search in Current File - Visual Stu
Nodeのイベントループを理解するために遊んだ & Apolloのテストでawait wait(0)するとなぜデータがロードされるか - $shibayu36->blog;
Apolloを触っていて、テストをするために https://www.apollographql.com/docs/react/development-testing/testing/#testing-final-state を読んでいた。その文章の中で、 MockedProviderをrenderした時はloading状態になる データがロードされた最終状態にするにはwaaitみたいなnpm packageを使って、await wait(0)とかしてね It delays until the next "tick" of the event loop, and allows time for that Promise returned from MockedProvider to be fulfilled. と書かれていて、この文章の意味がわからなかったので、Nodeのイベントループを知
問題意識を感じたときに「効率的に良い状況に変える」ためのアクションリスト - $shibayu36->blog;
自分の置かれた環境で問題意識を感じることってありますよね。例えば 上司全然ちゃんとやってくれないじゃん！最悪！ 会社にこういう問題あるじゃん！なんで直らないの！最悪！ みたいな感じ。 昔はこういう問題意識を持った時、自分で「良い状況に変える」ことに苦労をしていました。しかし、最近は自分の意識を変えることで「効率的に良い状況に変える」ことをしやすくなったなと感じています。そこで今回は、どのように自分が意識を変えたかということと、問題意識を感じた時に最近試しているアクションについて書いてみようと思います。 昔に自分がよくやっていたアクション 問題意識を感じた時、昔に自分がよくやってしまっていたのは 飲み会の場で愚痴る 上司に詰め寄る 問題意識だけを提起する というようなアクションです。このようなアクションをした時、良い上司はちゃんと話を聞いてくれて、実際に問題が解決することも多くありました。
エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
