アプリなら、コメントが見やすい！
トップへ戻る
おすすめのSF小説
blog.shibayu36.org
ANDPADに入社してRubyistになったのでRubyKaigi 2022にオフライン参加してきました。 rubykaigi.org 久しぶりのオフラインカンファレンス参加、本当に楽しかったです。最近オンラインのカンファレンスや勉強会に行っても中々いろんな人と話す機会が持てず、なんとなく行かなくなっていました。今回久々にオフライン開催ということで行ってみたら、久々に会った人と技術的な会話ができたり、ブースでいろんな企業のことを知れたり、ふらっと見てみた発表で異常な技術が発表されていたりと、楽しいことが盛りだくさんでした。オフラインとオンラインのハイブリッド開催は非常に大変だったと思いますが、運営の皆様ありがとうございました。 印象に残っていること 今回視聴者として印象に残っているのはこの辺り。 久々に技術でねじ伏せる人たちを生で見れたのが良かった。自分もまだまだ技術を学ばないとという気持
開発生産性を高めるヒントを最前線で働くエンジニアによる取り組みから考える会 - connpassのイベントで、「今の生産性向上活動で大切にしている考え方 〜開発チームに属した改善活動から得た気づき〜」というタイトルで、開発生産性に関する発表をしてきました。 speakerdeck.com 自分はこれまで、10年近く開発チームの中からボトムアップでチーム改善・生産性改善をしてきました。例えば、GitHubを使った開発フロー改善、チームごとの開発生産性の定量化・可視化、バリューストリームマップを使った、開発フローのボトルネック発見、CIの高速化などによる生産性改善、Findy Teamsを使った生産性可視化と改善などです。 それらの活動では失敗も成功もありました。その体験から、改善活動をしているときに裏で大切にした方が良い考え方についても明確になってきました。 そこで今回は、「今の生産性向上
yigarashi.hatenablog.com これが良い話だなと思ったので感想メモ。 「安定させる」のは良い。安定しないならチームの開発フローに問題が起こっていることが多く、「なんでブレちゃうんだっけ？」という議論からチームの課題が見つかることが多い。安定させるという考えなら変なハックが起こらない傾向にある印象 「上げる」は難しい。これまで、「上げよう」とした時に、ベロシティは基準によって変わる相対的指標なので、上げようと意識するとどれだけ気をつけても無意識にハックしてしまう経験がある。例えば 完了条件には完全に明文化されていないような地味かつ大切なポイントが終わっていない（例えばコードのメンテナンス品質が思ったより低い）時も、上げる意識だと終わりにしてしまいたくなる 考慮もれを見つけた時に、そのタスクで終わらせる意識ではなく、新タスクを作ってそっちで倒す意識になりがち 何となく、悲観
自分はこれまでの仕事で、バグ修正や機能追加でPullRequestを送るときに、考慮の抜けもれやケアレスミスが非常に少ない方であると思っている。振り返ってみて、これは自分に課している習慣が大いに効いていると思っているので、メモしておく。 毎回のcommit時 必要な部分だけをgit addし、git diff --cachedによって差分をセルフコードレビューした上でcommitする PullRequest作成時 filesの内容をセルフコードレビューし、直した方が良い部分は直す + わかりにくい部分にGitHub上でラインコメントを行う + コード上にコメントを残した方がいいならコメントする ユーザーの導線に影響するコードなら、必ず自動テストだけでなく、自分自身でユーザーの行動をトレースし、違和感がある部分が存在しないかチェックする。チェックした流れについては、PullRequest上に
RuboCopはキャッシュファイルを作成し、2度目以降の実行を高速化するのですが、GitHub Actionsでキャッシュを利用するために工夫が必要だったのでメモしておきます。 小規模なプロジェクトの場合 小規模なプロジェクトでRuboCopの実行時間がある程度ありキャッシュを利用したい場合は、キャッシュのvalidityチェックは完全にRuboCopにお任せし、すべてのGitHub Actionsでキャッシュを作ってしまうやり方がオススメです。理由は、小規模な場合キャッシュサイズが問題になるケースは少なく、全部キャッシュした方がシンプルかつメンテナンス性も高いためです。 参考の設定はこちら。 steps: ... - name: Cache rubocop uses: actions/cache@v3 env: cache-name: cache-rubocop-v1 with: pat
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon 読みました。非常に良かったので、スケールする組織をどうやって作るか考えている人は一読すると良さそう。とくに4つのチームタイプ、3つのインタラクションモードについて知れたのが良かった。 チームトポロジーは、チームファーストアプローチを適用し、4つの基本的なチームタイプと3つのインタラクションパターンを示す。この方法に従うと、生み出されるソフトウェアのアーキテクチャが明快で持続可能になる。結果的に、チーム間の問題を有用なシグナルとして扱えるようになり、組織の自律操舵を促す 4つの基本的なチームタイプ ストリームアラインドチーム：ビジネスの主な変更フローに沿って配置されるチーム。職能横断型で、他のチームを待つことなく、利用可能な機能をデ
GitHub Actionsのjobが失敗した時に簡単にSlackに通知する方法を探していたら、Slack公式のツールを使えば結構簡単にできたので共有します。Slack Workflowとslack-github-actionを組み合わせると良い。 できたもの ジョブが失敗した時だけ、以下のようにSlackに通知される。 やり方 Slack Workflowでパラメーターを付けられるwebhookを用意する GitHub Actionsで失敗時のみwebhookに通知する Slack Workflowでパラメーターを付けられるwebhookを用意する まずはSlack Workflowでパラメーターを付けられるwebhookを用意する。Workflowで用意すると、管理も簡単だしCollaboratorも付けやすい。 Workflow BuilderでCreateボタンを押し、Workfl
本当に最高の本でした。マイクロサービス化に取り組んでなかったとしても、規模が一定以上大きいプログラムのリファクタリング手法としても勉強になるので、みんな読みましょう！少なくともマイクロサービス化をしていきたいと思っていて、この本を読んでないならば、まずは一旦手を止めて関係する人全員でこの本を読んでから再度手を動かす、くらいでも良いレベルと感じました。 モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド 作者:Sam NewmanオライリージャパンAmazon この本を読んでいると、マイクロサービス化をしたいときは、必ず以下の手順でやっていくべきと感じました。 目的を明確にする 達成したいことは何か？事業が達成しようとしていることにあった一連の成果が目的でなければならない。これは、システムのエンドユーザーへのメリットを説明する方法で明確にできる その目的を達成するために、な
最近妻が子育てに関する書籍を出版したので宣伝です。 モンテッソーリ教育の研究者に学ぶ 子育てがぐっとラクになる「言葉がけ」のコツ (コミックエッセイ) 作者:てらいまきKADOKAWAAmazon この本は子育てで自分たち夫婦が「子供に伝わり、かつ自分たちもラクになるために、どうやって声がけしたら良いか」と悩んでいることを、モンテッソーリ教育の研究者である島村華子先生に質問して教えてもらうというコミックエッセイです。例えば、 子供に伝わりやすい褒め方はどのようなものか どうやったら子供も一緒に片付けをしてくれるのか 保育園で起こった出来事を教えてもらうにはどうしたら良いか 子供に一緒に遊んで欲しいと言われた時に、親はそんな気分じゃない時はどうすれば良いか といった内容を教えてもらいました。 聞いた内容を実際に試したところ、もちろん育児において全てうまくいくということはなく、うまくいったりい
ユーザー設定画面にMFAの設定画面があり、それが設定されているときだけログイン後にMFAのフォームを出したいという要求はよくある。これをAuth0を使っている場合に達成したかった。しかし、Enable Multi-Factor Authenticationなどを見ても、全体に有効/無効しか切り替えられないようで困っていた。 いろいろ調べたところやる方法が分かったのでメモしておく。 ユーザー向けのMFA設定画面を自分のアプリケーションに実装する方法 まずユーザー向けのMFA設定画面を自分のアプリケーションに実装するには、Auth0のMFAリソースに対する権限を持ったアクセストークンを取得する必要がある。詳しくはManage Authenticator Factors with Auth0 MFA APIに書かれているが Auth0のApplication設定画面でGrant TypesにMF
あまり知らないコードを触るときに、周りのコードを参考にしたいことが多い。しかし、そのコードの技術スタックに詳しくない場合、どのコードは筋が良いかというのが全く分からないことがある。そういう時に、その分野に知見がある人が書いたコードを参考にしながら学習したい。 そのように知見を素早く吸収するために、git grepの結果に、その行を書いたAuthorを表示するとどうかと思ったのでやってみた。 git-grep-with-author #!/bin/bash git grep -n "$@" | while IFS=: read i j k do author=$(git blame -L $j,$j $i --line-porcelain | grep '^author ' | cut -d' ' -f2-) echo -e "$i:$j:$author:$k" done 例えばRailsの
開発組織をスケールする方法を学びたい - 「ユニコーン企業のひみつ」を読んだ - $shibayu36->blog;に引き続き、開発組織が拡大しても、一人当たりの生産性を落とさずに、かつ顧客にとって本当に必要なものを作り続けるにはどうしたら良いのかのヒントを得るために、「Scaling Teams 開発チーム 組織と人の成長戦略」を読んだ。 Scaling Teams 開発チーム 組織と人の成長戦略 (Compass Booksシリーズ) 作者:David Loftesness,Alexander Grosseマイナビ出版Amazon めちゃくちゃ良かった！この本では、組織のスケールで重要な局面を採用・人事管理・組織・文化・コミュニケーションの5つとし、それぞれに対して何を気をつけるべきかについてまとめてくれている。特に自分の興味と合致する「採用」「組織」の部分は本当に参考になった。例えば
VSCodeでrubocopを使って自動フォーマットをしているのだが、フォーマットが本当に遅くてめちゃ困っていたのが完全に解決して感動したので記事だけ共有。 dev.to formatに3秒くらいかかっててマジつらい...って感じだったのが1秒未満とかになったので本当に最高。 Before After
OSS活動とか仕事をしてる時に、PRをチェックアウトするのだるいなと思っていた。そこで「今いるレポジトリのPR一覧をmodified順に出力し、pecoで選択したものをcheckout」出来たら便利だろうということで作った。 できたもの やり方 まずhubとpecoをインストールしておく。 zshを使っているならこんな感じで定義し、 function peco-git-recent-pull-requests () { local selected_pr_number=$(hub pr list --limit 40 --sort updated --format "%pC%>(8)%i%Creset %t (by @%au)%n" | peco | sed -r 's/^ +#([0-9]+).*$/\1/') if [ -n "$selected_pr_number" ]; then
開発組織が拡大しても、一人当たりの生産性を落とさずに、かつ顧客にとって本当に必要なものを作り続けるにはどうしたら良いのか考えている。その一環として「ユニコーン企業のひみつ」を読んだ。 ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方 作者:Jonathan RasmussonオライリージャパンAmazon スケールするための重要なポイントについて非常によく学べた。書いてあることを自分の中で咀嚼して、スケールするためのSpotify流の方法を自分の言葉でまとめてみるとこんな感じ。 スクワッド・トライブ・チャプター・ギルド チームを、少人数の、職能横断で自律した、必要な権限を持った、自己組織化されたものにする 開発からメンテナンスまで一気通貫し、学びを蓄積できるように ミッションだけが設定されており、優先順位決めややり方は自分たちで決められる。長期的な視点にも立てる
今回は入社した会社の携わる業界理解ということで、「建設DX デジタルがもたらす建設産業のニューノーマル」を読んだ。 建設DX デジタルがもたらす建設産業のニューノーマル 作者:木村 駿日経BPAmazon この本からは、建設業がこれから5年ほどで直面する課題や、今後の建設業でのトレンド・新技術について学べた。特に業界課題を把握できたことは、顧客の本当の課題への理解の手助けになると思う。印象に残った or 自分の中の気付きは以下の点。 建設業がデジタル技術を大胆に取り入れなければ解決しない3つの時限爆弾 2024/4以降に建設業にも適用される時間外労働の上限規制 建設技能者（職人）の大量離職問題。14年度に343万人いたが、25年度までに109万人いなくなる 24年ごろからはゼネコンの技術者も一斉定年退職（バブル入社組） 建設業は「単品受注生産」「屋外生産」といった背景から、製造業と比べて生
「THE MODEL」読んだ - $shibayu36->blog;に引き続きSaaSを学ぼうということで、カスタマーサクセス──サブスクリプション時代に求められる「顧客の成功」10の原則を読んだ。なぜSaaSやサブスクリプションモデルではカスタマーサクセスが重要なのか、そもそもカスタマーサクセスとは何か、カスタマーサクセスがもたらすものは何か、カスタマーサクセスで追いかけるべき指標は何か、カスタマーサクセスを行う上で大切にすべき原則は何か、といった内容を学べた。 カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則 作者:ニック・メータ,ダン・スタインマン,リンカーン・マーフィー英治出版Amazon 特に印象に残ったのは以下の部分だった。 サブスクリプションモデルの浸透によって、たくさんの顧客に継続的に販売しなければならなくなり、カスタマーサクセスの重要性が増
SaaSをちゃんと学び直そうということでTHE MODELを読んだ。SaaSに関する営業活動のやり方全体を学べた。 THE MODEL（MarkeZine BOOKS） マーケティング・インサイドセールス・営業・カスタマーサクセスの共業プロセス 作者:福田 康隆翔泳社Amazon 以下の内容が個人的に印象に残った。 営業活動をマーケティング、インサイドセールス、フィールドセールス、カスタマーサクセスマネージャーと顧客の状況ごとに分業するモデル 商談に至らないリード、失注、未フォローを再び商談化のプロセスへリサイクルする。ビジネスが続けば続くほど効果的となる 人間はグループに分けられると敵対しやすい。関係を良好化するには、接触回数増加・コミュニケーションの内容改善だけでは不足。共同で作業することによって達成可能な共通の目標が有効 読書メモ * あれば便利だが、なくても業務が回るものは、その必
2021/10/01から株式会社アンドパッドに入社しました。初めての転職なので緊張しているけれど、早めに馴染みたい。 andpad.co.jp 転職活動をしている中でいくつかオファーをもらっていたが、以下の理由で株式会社アンドパッドに入社を決めた。 裏側よりの難しい課題をクラウドネイティブな設計で解決するタスクができそう 組織規模が急拡大していて、組織マネジメントの経験が深まりそう 採用フローがしっかりしていて、今後も良い人がどんどん入ってきそう 裏側よりの難しい課題をクラウドネイティブな設計で解決するタスクができそう これまでのエンジニア経験の中ではインフラ〜フロントまで全体的に触ってきたが、自分の中ではインフラ領域〜バックエンド領域の中間くらいのエンジニアリングに最もモチベーションが湧いていた。またクラウドネイティブな設計をもっとできる機会があればなあと思っていた。 このように考えてい
2021年8月13日の本日が最終出社日でした。しばらく休暇を取り、10月から別の会社でエンジニアをする予定です。 はてなには2010年4月にアルバイトとして入社し、2012年4月からは社員として入社したので、アルバイト2年、社員9年4ヶ月と非常に長い間所属した。仕事の中で、周囲の人の優秀さに圧倒されながら学習とアウトプットをし続け、またいろんなチームや職種を経験させてもらえたおかげで、自分自身がかなり成長できた。はてなに入社できたことで、エンジニア経験がほぼないところから大きく成長できたため、誇張なく人生が変わったと思う。 はてなで経験できたこと 本当に色々経験できたのだが、自分の中で本当に良い仕事ができたなーと思ったことはこんな感じ。 世界規模で動く通知システム はてなブログMediaの立ち上げ カクヨムの立ち上げ 魔法のiらんどのリプレース ブログチームでのチーム改善や、Mackere
最近プロジェクトマネジャーを担当していた仕事で、開発チーム内の相談しやすさ向上・知見展開・透明性向上・WIPタスク数減少を狙ってペア制度というのを導入した。今回は導入した背景、導入した仕組み、そしてその振り返りについてブログに書いておきたい。 導入した背景 ちょっとした相談のしづらさ 知見展開のしづらさ タスク状況の透明性の不足 WIPなタスクが多く、プロジェクトマネジメントが複雑 ペア制度を導入する ペア制度の振り返り ペア制度を振り返っての点数評価 導入して良かったこと 導入して困ったことや、改善すべきポイント 一人当たりの短期的な開発効率は下がったか？ まとめ 導入した背景 最近はエンジニア6~7人程度のフロントエンドフレームワーク置き換えプロジェクトのプロジェクトマネジャーをやっていた。ペア制度を導入する前は、大体1~6ヶ月程度かかる粒度のタスクを1人にアサインし、人数と同じだけの
以前Pull Requestから社内全チームの開発パフォーマンス指標を可視化し、開発チーム改善に活かそう - Hatena Developer Blogの記事で、開発パフォーマンスを可視化する話を書いた。その後、バリューストリームマップを作り開発フローの課題を洗い出して、チームの改善を行い、そして開発パフォーマンス指標で効果を検証する取り組みを行ったので、その経験についてブログに書いておく。 前回の記事のサマリー バリューストリームマップを作り、開発フローの課題を発見する バリューストリームマップとは何か チームのバリューストリームマップを作る バリューストリームマップから課題を見つける 見つかった課題を解決する 開発パフォーマンスの指標で改善結果を振り返る まとめ：データを根拠にチーム改善するという進歩 参考 前回の記事のサマリー 前回の記事を前提として書くため、簡単にサマリーすると 開
最近リモートワークでしばらく暮らしたところ、オフィスの時より人によって成果の差が出やすいと感じている。また昔からリモートワークしてきた人の様子を見ていると、仕事の進め方がうまいと感じることが多い。このことから、リモートワークに重要なスキルが何かあるはずだと感じていたのだが、自分の中でちゃんと言語化できていなかった。 そこで以下の資料を読み、少し言語化してみたのでメモ。 リモートワーク大全 作者:壽かおりポプラ社Amazon Effective Remote Working - Speaker Deck いくつか読んで、自分の中で以下のキーワードが重要なのかなと考えている。 セルフマネジメント モチベーション・集中力コントロール メンタルケア タスクマネジメント コミュニケーション こまめなアウトプットによる状況の可視化、それによる信頼の醸成 曖昧でない言葉で全てを伝えるコミュニケーション
睡眠を学びたいと思ったので読んだ。最近自分が全然睡眠足りてなかったということに気づけて良かった。 スタンフォード式 最高の睡眠 作者:西野 精治サンマーク出版Amazon 睡眠こそ最強の解決策である 作者:マシュー・ウォーカーSBクリエイティブAmazon 「スタンフォード式最高の睡眠」の読書ノート * 睡眠負債を返すには3~4週間程度かかるので、週末の寝だめくらいでは機能しない 569 * 睡眠メンテナンスで意識したいのは「最初のノンレム睡眠」をいかに深くするか 620 * グロースホルモンが最も多く分泌されるのも最初のノンレム睡眠 * 睡眠圧も最初のノンレム睡眠で多くが解消される * 最初の90分を阻害すると、その後の睡眠は計測不能となる程乱れる 634 * 普通の人は最低でも6時間以上は睡眠が必要 644 * 眠りが足りているかの一番簡単な点検は自分の感覚。眠りの前後の「眠さ」 +
Twitterとかで見かけて気になってたので読んだ。 独学大全――絶対に「学ぶこと」をあきらめたくない人のための５５の技法 作者:読書猿発売日: 2020/10/21メディア: Kindle版 習慣レバレッジ、カルテ・クセジュ、検索語みがき、目次マトリクスあたりが自分の中で興味深い技法として知れたのが良かった。 読書メモ * 習慣レバレッジ：自分のやりたい独学を、いつもやっている日課をトリガーに引っ掛けて習慣づける 1489 * 1. 一日のうち頻繁に行う習慣（例: スマホを見る、トイレに入る）を選ぶ * 2. その習慣の直前に新しい習慣を行う。簡単ですぐ取り掛かれて短時間で終わるもの（例: 英単語1個覚えるなど）。習慣を作ることが目的なので、覚えきれなくても良い * 3. 2を繰り返し、少しずつ重い習慣に変えていく * 現状のグラフ化や目標などを壁に貼っておくと、誰かの目に触れるかもしれ
プロフェッショナルSSL/TLS 作者:Ivan Ristić発売日: 2018/06/04メディア: 単行本（ソフトカバー） 最近ふとSSL/TLSの仕組みについて知りたくなったので、「プロフェッショナルSSL/TLS」を読んだ。 かなりいろんな話題を網羅していて、かつ具体的な設定例なども書かれていて良かった。TLSに関する仕事をするときや、SSL/TLSやHTTPS周りで何回かハマったことがあるなら非常にお勧めできる。 仕組みを理解したいなら1章 SSL/TLSと暗号技術・2章 プロトコル・3章 公開鍵基盤が参考になった。実運用なら8章 デプロイ・9章 パフォーマンス最適化・16章 Nginxの設定あたりが参考になりそう。またTLS周りでハマった時のトラブルシューティングには12章のOpenSSLによるテストが使えるだろう。 ただ最新のTLS 1.3に関してはそこまで多く言及はなかった
育児していて時間があまり取れない状況下で継続的に学習するために色々な方法を取り入れているんだけど、その中で最近めちゃくちゃ効いた3つのやり方を紹介。 やりたいことリストを作っておく 今日のTODOリストを作る 2分間コーディング やりたいことリストを作っておく 自分が学習したいことの一覧があると、優先度を決めやすくなり、またやりたいことが1つ終わった後すぐに次に取り組むこともできる。そこで僕はTrelloでリストを作り、とにかく少しでもやってみたいと思った開発や、読みたいと思った本などがあれば追加している。 今日のTODOリストを作る 時間が空いてから「今日はこれから何をやろうかな？」と考えていると、途端にやる気がなくなってダラダラしてしまう。そこで先に今日のTODOリストを作っておくということをやっておく。ポイントとしては 細かい家事やプライベートでやること、勉強すること全て含めて同じリ
2分コーディングの一環でNext.js + Prisma + NextAuth.js + React Query で作るフルスタックアプリケーションの新時代をやった。とにかく簡単に認証 + DBアクセスがあるアプリケーションを作ってvercelにデプロイできるサンプルが出来て非常に良かった。趣味プロダクトをちょっと作ってみるのに良さそう。 shibayu36/next-prisma-auth-tutorialに試した例を置いているので参考にどうぞ。 やれたこと Googleのアカウントを使ってサインインし、TODOを追加できるアプリケーション herokuのPostgreSQL dbをデータソースとして動くアプリケーションをvercelにデプロイ 作業メモ prisma、migrationのツールも入ってるし便利すぎる。 migrationしたけどpsqlでdocker内にアクセスできなか
最近はリモートワークが主体で、みんなで集まっての同期的コミュニケーションがやりづらくなり、他の人の非言語情報を受け取ることも困難になった。その結果として、自分がチームで改善提案をした時に、周りの人からコメントを受け取る、提案に対する温度感を探るということが難しくなった。 改善提案にこのような課題があったので、リモートワークに合わせた方法を探り、まず改善提案の議論をテキストで非同期に行うというやり方を行ったので紹介する。その過程で自分が作った提案のテンプレートも共有するので、参考にしてもらえると嬉しい。 課題: 現在の働き方でも改善提案に対するフィードバックをもらいやすくしたい もう一度課題をまとめる。 自分がチームの改善提案をした時は、チーム内の意見や反応を見ながら、より改善提案をブラッシュアップして実施したいと考えている。つまり開発フローなどチームの改善提案でもコードレビューと同様、コメ
次のページ
このページを最初にブックマークしてみませんか？
『$shibayu36->blog;』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
