本の内容が頭に入ってくるのは結局は知見まとめノートを作っている時 - $shibayu36->blog;
最近は読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;に書いているやり方で読書をしている。こういう流れだ。 (1)学びたいと思った知識が書いてありそうな本を2~5冊選ぶ (2)1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく (3)全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱりおもしろいと思ったところは赤のハイライトを付け直す (4)赤のハイライトを眺めて、読書ノートに転記する (5)とくにおもしろい部分については、自分の知見まとめノートにカテゴリごとに整理する しばらくこれを続けて感じたのは、結局のところ(4)〜(5)に至るまで書籍の内容が全然頭に入っていないということだ。(4)(5)の時に、はじめて「書いている内容が言いたかったのはこういうことだったのか」と頭が急に理
より少なく、しかしより良く - 「エッセンシャル思考」読んだ - $shibayu36->blog;
エッセンシャル思考 最少の時間で成果を最大にする 作者:グレッグ・マキューンかんき出版Amazon 自分がなんでもやりたいタイプなので、この本に書いてあることは中々刺さった。幸福になるには「より少なく、しかしより良く」を追求すべきという本。プライベートや仕事でとにかく忙しく時間がないと思っている人は読んでみると良い。 印象に残ったのは次のことだ。 現代人の最優先課題は、優先順位づけの能力をキープすること 睡眠不足では一番最初にそこが減ってしまうのでダメ 一流のバイオリニストは1日平均8.6時間の睡眠 & 週平均2.8時間の昼寝。睡眠による並外れた集中力で、1時間あたりの練習効果を最大限にする もっとも厳しい基準でやることを決める 「絶対やりたい」「やらない」の2択にする。やろうかな程度なら却下、イエスと言うのは絶対やるしかないと確信した時だけ 自分の中で最重要基準をひとつ用意し、100点満
スムーズに進行するためのエンジニアリングタスク分割の工夫 - $shibayu36->blog;
会社の振り返りで「エンジニアリングの作業タスクがうまく分割できていそうだったが、その知見を共有してほしい」と言われたので、自分がどう考えてタスク分割をしているかをこの記事で共有したい。 この記事のスコープとすること・しないこと タスク分割をするときの工夫点 少なくとも1スプリント以内で終わるタスクになっている 完了条件が明確である 開始から終了まで他タスクによる待ち時間がない 他タスクが待ち状態になる時間を最小限にする 自分にとって難易度の高いものが1タスクの中で1つである 初めから完璧なタスク分割を目指さない 工夫を考慮した分割例 まとめ この記事のスコープとすること・しないこと 今回の記事では、あるユーザーストーリーが存在するとして、その設計・実装・テストなどをスムーズに進行するための工夫について書く。 逆に次のようなタスク分割については取り扱わない。 ユーザーに提供すべき価値があると
OpenAI APIで英会話LINE Botを作る with Hono + Cloudflare Workers + Queues + D1 - $shibayu36->blog;
Cloudflare Worker + D1 + Hono + OpenAIでLINE Botを作るを見て、Cloudflare Workersに興味を持った。そこでLINEで英会話や添削ができるbotを作ってみた。 作ったもの こんな形で英会話をしたり、英作文テーマを作ってくれたり、添削をしてくれたりする。 実際のコードは https://github.com/shibayu36/english-line-bot 。このコードをforkしてもらって、LINEチャネルの作成、Cloudflareへのデプロイ、src/prompt.tsのカスタマイズをすると、自分用のLINE botも作れると思う。 利用技術 OpenAI API Hono Cloudflare Workers Cloudflare Queues Cloudflare D1 開発Tips 基本的な作り方は Cloudflar
LLMを理解する一歩として「ゼロから作るDeep Learning」をやった - $shibayu36->blog;
LLM、GPT界隈を追いかけていて、GPTの仕組みと限界についての考察（2.1） - conceptualizationという記事を見かけた。これを見たとき、「どういうことか全然理解できない」という気持ちになった。また、その他LLMの解説記事を理解できないことが多く、自分の機械学習知識不足が明確になった。 理解できなかったことは悔しいし、LLMやChatGPTをうまく使いこなすには最低限どのような原理で動いているか理解したいと感じた。そこで一歩目として「ゼロから作るDeep Learning」を完走した。 ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装 作者:斎藤 康毅オライリージャパンAmazon 知識なしからはじめたので時間はかかったが、次のように進めていった。 自分もコードを写経しながら読む レポジトリは https://github.co
CLIツールを作るとき、ユーザー設定ファイルやデータをどこに配置するか - $shibayu36->blog;
chat-hatenablogをpip installでインストール可能にした - $shibayu36->blog;にてchat-hatenablogをpip installできるようにするとき、ユーザー設定ファイルやデータをどこに配置するかに迷った。このツールでは、環境変数の設定として.envファイルを、ブログデータのインデックスとしてindex.pickleファイルを使っている。 これらのファイルの置き場所について少しだけ調べたので、現状分かったことをメモしておく。 まず選択肢としては二つありそうだった。 ~/.chat-hatenablog/.envと~/.chat-hatenablog/index.pickle 例) ~/.asdf、~/.docker、~/.gemなど XDG Base Directoryの仕様に沿って、~/.config/chat-hatenablog/.en
不確実な状況に耐える力を学ぶ - 「ネガティブ・ケイパビリティ」を読んだ - $shibayu36->blog;
自分は問題解決は得意な方だと思っている。しかし逆に不確実な状況・不安な状況・課題がある状況をそのままにして耐える力をもっと付けたいなと思っている。そこで最近目にした「どうにも答えの出ない、どうにも対処しようのない事態に耐える能力」であるネガティブ・ケイパビリティについて学ぶため本を読んでみた。 ネガティブ・ケイパビリティ 答えの出ない事態に耐える力 (朝日選書) 作者:帚木 蓬生朝日新聞出版Amazon 正直、この本は歴史的な話とか雑談も多く、少し頭に入りにくかったが、一方で示唆のあることを学べた。例えば どうにも対処が難しい課題を見つけた時に、拙速に解決策を見出すのではなく、興味を抱いてその宙吊りの状態を耐えると良い。それによって深い理解に行き着く 問題解決があまりに強調されると、まず問題設定の時に、問題そのものを平易化してしまう傾向が生まれる。この時、複雑さを削ぎ落としているので、現実
「マンガでやさしくわかる認知行動療法」読んだ - $shibayu36->blog;
思考のクセを変化させることで、ストレスを軽減させられると良いなあと思ったので読んだ。 マンガでやさしくわかる認知行動療法 作者:玉井仁,星井博文,深森あき日本能率協会マネジメントセンターAmazon 以下のことを学んだ。 状況確認シートで個人の反応を、認知・感情・行動・身体反応で整理することで、思考のクセを理解することができる さらに、その中で認知や行動はどちらかというと変化させやすい。整理をすることで、認知などをバランスを取れたものにとらえやすい効果もある 状況確認シートは、「不安…どうすれば？」不安なときに試したい基本中の基本のこと - ココロクエスト~レベルアップ心理学ブログ~byねこひげ先生 みたいなところでフォーマットも見れる 認知再構成法を使うことで、バランスの取れた認知に変化させることもできる。自分の認知に対して質問を繰り返し、新たな考え方をピックアップする このやり方の一つ
TypeScriptで「Reactを自作しよう」をやってみた - $shibayu36->blog;
最近2分間コーディングのすすめ、コードを書く習慣のハードルを下げるに触発されて2分間コーディングをやってみている。まずは昔興味が出ていたReactを自作しようをやってみたのでメモ。 やった様子は https://github.com/shibayu36/building-own-react に置いた。メインファイルは https://github.com/shibayu36/building-own-react/blob/main/src/index.tsx create-react-appしたままだと色々おかしくなったのでejectして手直ししたり、JSXのtranspileを置き換えるためにwebpackの設定を少しいじったりしたところが苦労した。そのあたりについては https://github.com/shibayu36/building-own-react/commits/mai
部下の困りごとをマネジャーが解決しすぎない方が良い - $shibayu36->blog;
マネジャーをやっていると、1on1でいろいろな困りごとを相談されたり、雰囲気を感じ取ったりで、部下が困っていることがよく見える。その時「頑張ってマネジャーの自分が解決しないと！」と思い、全部自分で解決してしまうことがある。しかしこのようなやり方は正直デメリットが多く、やめたほうが良いと考えている。 これを続けていると、例えば 部下が問題はマネジャーが解決してくれるものと思いすぎてしまう可能性がある。するとこの仕事はマネジャー、この仕事はエンジニアと過度にカテゴリー分けがなされることがある 部下の問題解決能力、相談能力などの向上機会を奪ってしまう 細かい問題を解決しているだけで時間がなくなってしまう 結果的にスケールもせず、解決に取り組めない問題が増えていく 本当に解決すべき重大なチーム課題に取り組む時間がなくなる などといったことが起こりうる。こうなると実際には自分が色々問題を解決できてい
現代のソフトウェア開発を学ぶために「正しいものを正しくつくる」を読んだ - $shibayu36->blog;
最近はいかにエンジニアリングの立場でプロダクトを成長させられるかについて考えている。そこで、現代のソフトウェア開発やアジャイルについて学ぶため、同僚にオススメされた「正しいものを正しくつくる」を読んだ。 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について 作者:市谷聡啓ビー・エヌ・エヌ新社Amazon なぜ現代ソフトウェア開発は難しいのかから始まり、現代ソフトウェア開発の不確実性へ対処するためにアジャイルを利用するという流れになっていて非常にわかりやすかった。また「正しいものをつくる」ことと「正しくつくる」ことをうまく切り分けて説明してくれたので、自分の中で論点を整理しやすかった。 「正しくつくる」部分に関しては、これまで自分も注力してきたところであったので、かなり経験知を言語化できた。一方「正しいものをつくる」部分に関しては、まだ経験が
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
メンターを初めて経験する人に、最初に読むものとしてオススメしている書籍たち - $shibayu36->blog;
社内ではこういうおすすめをしてますね(文字数多いのでスクショで...) pic.twitter.com/uzqCh6zubs— 柴崎優季 (@shiba_yu36) 2020年7月7日 こういうツイートして、そういえば社内でメンターを初めて経験する人にオススメしている書籍たちを外部に公開してないなと思ったので紹介してみます。 メンタリングのスキルを学習する時のキーワードは「コーチング」と考えていて、以下の書籍を推薦しています。上から順におすすめ順になっています。この推薦は網羅的にコーチングを学べると言うより、初めての人でもとっつきやすく読みやすいものであることを意識して選んでいます。また、メンタリングを始めるだけなら、書籍の全部分を読む必要はなく、どこまで読んでおくと良いかも書いています。 エンジニアリング組織論への招待 ザ・コーチ コーチングの基本 新1分間マネジャー エンジニアリング組
今見ているファイル内を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
エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
macでの定期実行はcronじゃなくてlaunchdを使う - $shibayu36->blog;
手元PC(mac)で、スクリプトを定期実行したいときにどうするんだろう？という気持ちになり、いろいろ調べたところcronとかではなくてlaunchdを使ったら良さそうらしいと知ったのでメモ。 定期実行をlaunchdを使って登録する launchdで定期的にスクリプトを実行 - Qiita が非常に参考になる。基本的にはStartIntervalかStartCalendarIntervalを使ったらcronのように定期実行ができる。例えば10分に一回実行したかったらこんな感じ。 ~/Library/LaunchAgents/com.github.shibayu36.mycommand.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http:
人事の仕事の全容を知る - 「人事管理入門」読んだ - $shibayu36->blog;
評価制度などの仕組みを考えるにあたり、一度人事関連の教科書を読んで全容を知らないといけないなと思ったので、おすすめされていた「人事管理入門」を読んだ。 マネジメント・テキスト 人事管理入門<第2版> 作者:今野 浩一郎,佐藤 博樹日本経済新聞出版Amazon とにかく面白く、教科書的に体系的にまとめられているのに関わらず分かりやすく、読んで非常に参考になった。この本を読むと、人事とはどういう役割なのか、グレード制度とは何か、人事評価とはどういう目的で行われるのかなど、人事にまつわる知識が体系的に身につけられる。そのため、人事部に所属している人にはとにかくおすすめだし、人事に関わってなくとも組織に興味があるならおすすめ。人事に関わる制度を考えるときには何度も読み返したい本だなと思った。 今の自分だと、「第1章 人事管理のとらえ方」「第2章 戦略・組織と人事管理」「第3章 社員区分制度と社員格
AWSのVPC非対応なEC2/RDSをVPC内に移行した手順 - PrePANのインフラマイグレーション - $shibayu36->blog;
http://prepan.org/ というサービスを運営している。このサービスはインフラ周りにAWSのEC2とRDSを使っている。このサービスが立ち上がったのが2011年あたりなのだけど、この時EC2とRDSはまだVPCがない時代(EC2-Classic)で、VPC非対応なEC2/RDS(t1.micro)で動き続けていた。 しかし、VPC非対応時代のt1.microは、今のt2.microと比べてそれぞれ月額$10ずつ程度高い。つまり、同じ構成でVPC対応のEC2/RDS(t2.micro)を使う場合と比べると、月額$20も余計にインフラコストがかかっていた。 これは辛いと思い、EC2/RDSをVPC内に移行した。手順を踏んでやることで、全部でダウンタイム20分位で出来た。そこで今回はその手順について書いておきたいと思う。 元々の構成 以下の画像の通り。 prepan.orgはRout
良かったことは良かったとはっきりフィードバックする - $shibayu36->blog;
最近心がけていることとして、「良かったことは良かったとはっきりフィードバックする」ということがある。 自分がリーダーやマネージャのポジションになった時に、方針やメッセージを打ち出す、チームの開発フローを改善するなどを行うことがあった。この時、何もフィードバックが返ってこなくて、結局良かったのか、それともあまり興味がないのか、実は不満に思っているのか、どれなのかわからず、非常に不安に思ったという経験がある。 逆に自分が伝えられる立場になった時を考えてみると、何かが行われた時、気になることはよくフィードバックするけど、良かったなと思うことは心の中で思うだけでフィードバックしないことが多いと感じた。 そこで最近は、「良かったことは良かったとはっきりフィードバックする」ように心がけている。はっきりフィードバックするというのは、どこが良かったかを出来る限り具体的に相手に伝えるということである。伝える
どうやってIPからMACアドレスを解決するか - ARPの挙動を調べた - $shibayu36->blog;
自分はアプリケーションエンジニアでネットワークを触ることは少ないのだけど、ネットワークも関わるタスクや障害が現れた時に話についていけないのは良くないと思い、マスタリングTCP/IP 入門編を今読んでいる。データリンク層の章まで読み、この章ではデータリンク層の通信ではMACアドレスを用いて通信していると書かれていた。 しかし、読むだけではまだ理解が足りてないなと思い、pingをサブネット内のホストに打ちながらWiresharkでフレームを眺めるということをしていた。特にIPからMACアドレスの解決をどのようにしているのかと思い、192.168.10.7から192.168.10.4にpingしながら、ARPのフレームを眺めていると、 No. Time Source Destination Protocol Length Info 1811 87.235306 Apple_42:64:b2 Ap
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
