スキルも経験も積み重ねてきた人が抱きがちな悩みとして、「自分が意見を出すと毎回大きな反論なく通ってしまって不安になる」というのがある。 いわゆるリードができるレベルになると、他のメンバーより視野を広く持って色々なことに考慮した意見を出せるようになる。しかし実際には明確な答えは持っていなくて自信があるわけでもないこともある。 それなのに自分が言ったことがそのまま通ってしまう。発言すると、「たしかに」「そうですね」「いいと思います」みたいな雰囲気になって採用されていくのである。新しいサービスの設計方針の議論、コードレビューでのやりとり、チーム目標を決めるミーティング、さまざまなところでこういうことが起きる。 「本当にこれで大丈夫なのか」という不安も感じるし、「もしかしたら自分が発言することで他の人の意見をふさいでしまったり萎縮させてしまったりしてるんじゃないか」と心配になってくる。人によっては

「クラスメソッドのCDK事情大公開スペシャル#1」での登壇資料です。 イベントURL：https://classmethod.connpass.com/event/332020/

JSConf JP 2021 でトークしたスライドです。 このスライドの内容を文字にしているブログ記事はこちら https://blog.nnn.dev/entry/2021/12/03/123000 トークのアーカイブはこちら https://www.youtube.com/watch?v=5H3Sswp5qYg&t=1155s https://jsconf.jp/2021/talk/testing-approach-to-support-web-front-end-replacement

JJUG CCC 2024 Fall 2024-10-27 https://jjug.doorkeeper.jp/events/177443

誰かがリードしている時に、それを支え、あと押しするような振る舞いをフォロワーシップと呼ぶ。 フォロワーシップについては、Derek Sivers の TEDトーク How to start a movement や あんちぽさんのやっていき、のっていき が自分は好き。研究でいうとロバート・ケリー教授の The Power of Followership の5つの分類が有名。 難しそうに感じるかもしれないが、実はフォロワーシップの実践というのはもっとゆるいところにも現れるものだと思う。自分のまわりの人たちがおそらく無意識的に実践しているように見えることを雑に書きだしてみる。 1. 反応を返す 誰かが発言したり何かを書いたりしたことに対してわかりやすく"反応を返す"という振る舞いは、意外と皆ができていなかったりする ミーティングで最初の挨拶に対して挨拶を返したり、「何か質問や意見ありますか？」

Customer Identity Cloud powered by Auth0 を使ったマルチプロダクト構築の実践と総括

本記事のテーマはGitHub Actionsです。個人的に「もっと早く知りたかった！」と考えているグッドプラクティスを、厳選してお届けします。想定読者は次のとおりです。 普段GitHub Actionsを雰囲気で運用している人 GitHub Actionsをコピペや生成AIで乗り切っている人 他者が書いたコードの意味をより深く理解したい人 本記事でGitHub Actionsの基本は説明しません。グッドプラクティスを含めて基礎から学びたい人は、拙著『GitHub CI/CD実践ガイド』を読んでみてください。GitHub Actionsの基本構文から運用のコツまで、網羅的に解説しています。さて書籍紹介はこれぐらいにして、さっそく本題へ進みます。 GitHub Actionsの設計指針 GitHub ActionsはCI/CDや各種自動化で役立つ、汎用的なワークフローエンジンです。一般的に長期

今まで id:mizdra はターミナルで Git ブランチを切り替えるときに、zsh + peco を使った Git ブランチ検索用のキーバインドを使用していた。 # .zshrc function select-git-branch() { selected_branch=$(git branch | cut -c 3- | peco) BUFFER="${LBUFFER}${selected_branch}${RBUFFER}" CURSOR=$#LBUFFER+$#selected_branch zle redisplay } zle -N select-git-branch bindkey '^b' select-git-branch zsh + peco で Git ブランチを切り替える様子 便利っちゃ便利なのだけど...沢山のブランチの中から「あの時作業していたあのブランチ」

もし世界が消滅して Visual Studio Code の設定が失われてしまった時に、この記事を見ればまた VSCode のカスタマイズが復元できる。 ここでは Visual Studio Code の見た目に影響するものについてのみ 取り上げる。 スクリーンショット Editor Terminal Zen Mode 環境 Visual Studio Code バージョン: 1.94.2 (user setup) コミット: 384ff7382de624fb94dbaf6da11977bba1ecd427 日付: 2024-10-09T16:08:44.566Z Electron: 30.5.1 ElectronBuildId: 10262041 Chromium: 124.0.6367.243 Node.js: 20.16.0 V8: 12.4.254.20-electron.0 OS

ゆめみ/虎の穴ラボさんの「勉強法の勉強会」というのが好きで、そちらをベースに社内の強い人たちへのインタビュー（10名程度）をミックスして、みんながどうやって調査とか勉強とかしているのか、まとめてみました。 インタビュの結果、あまり共通項みたいなものがなく、結局勉強に関しても銀の弾丸はなさそうな雰囲気でした。ので、どちらかというといろんな人のいろんな方法を並べる、みたいになっています。いろいろ詰め込もうとしすぎたのでゴチャった感ありますが、誰かの参考になれば幸いです。 前提など

2024-10-05 YAPC::Hakodate 2024 https://yapcjapan.org/2024hakodate/

GitHub Actions で CI している皆様、こんにちは。 GitHub Actions 便利ですよね。使わない日がないというくらい毎日お世話になっています。 さて、CI といえば良く問題になるのが実行時間。 長い待ち時間は開発効率を下げますし、プライベートリポジトリだと Runner の費用も嵩んでしまいます。 時間を短縮する方法は色々ありますが、一手目によく行われるのが依存パッケージのキャッシュじゃないかなと思います。 例えば Go で開発していると、依存パッケージは ~/go/pkg/mod にダウンロードして保存されます。 これを CI 実行のたびにダウンロードしてコンパイルするのは時間とお金の無駄というものです。 幸い、GitHub Actions には CI の実行間でこういった依存パッケージを保存して再利用できるキャッシュ機能があります。 詳しくは以下のドキュメントを

チームメンバーや他社のエンジニアとの 1on1 の中で、「憧れている人とかいますか？」という話をすることがある。この質問はわりと継続して聞いているなと思ったので雑に書いておきたい。 チームメンバーとの 1on1 で聞くのは半年ごとくらい。目標設定など、たまにはちょっと中長期の話でもしますかってタイミングで話している。いわゆる"キャリア"の雑談である。 自分は「1年後/3年後どうなっていたいか？」みたいな質問がすごく苦手で、うまく答えられたことがない。どうなりたいかを明確にするのは大事なことだと思うけれど、正直3年後とか何もわからんという気持ちになる。自分ができないのでチームメンバーにも聞けない。 そこで、違う聞き方として「憧れている人はいるか？」という雑談をしている。この質問は人によって回答がぜんぜん違うのが面白い。 たとえばiOSエンジニアだと @k_katsumi さんとか。Go書いて

みなさまお元気ですか 暑さも少し落ち着いてきて、ようやく外に出てもいいかなという気になってきました。季節の変わり目体調には気をつけていきたいですね。 実は、一ヶ月くらい前に Linux PC を自作して Mac から移行しました。そのときの考え、その後の感想を残しておきます。 また、学んだことや作業のログを細かく残しておきたいと思います。（どこかの誰かが不安に思ったときに同じ失敗や疑問を経験した人がいて安心してもらえたら嬉しい） Ubuntu のインストール画面 (ベストオープンソースと開発しよう！) 目次 Mac をやめるきっかけ、経緯 Ubuntu に移行して一ヶ月の感想 おまけ1: どのような PC になったか おまけ2: 事前に学んだこと おまけ3: PC の組み立て おまけ4: Ubuntu のセットアップ 加筆/修正 指摘のあった誤字を修正 NVEnc について誤った内容があっ

20240906_JAWS_Yamanashi_#1_leap_beyond_the_AWS_all_certifications

JAWS-UG東京 ランチタイムLT会 #14 での登壇資料です。 動画: https://www.youtube.com/live/cCvONKkW5B8?t=350s (デモは800秒付近から https://www.youtube.com/live/cCvONKkW5B8?t=800s…

あなたがさっきまで読んでいた技術的に役立つ記事は、10年後も使えるでしょうか？ほとんどの場合でいいえ はじめに 短期的に効果的な手法や知識は、ソフトウェア開発の分野において、急速に価値を失う傾向があります。この現象は、私たちが何を重点的に学ぶべきかを示唆しています。最も重要なのは、第一に基本的な原理・原則、そして第二に方法論です。特定の状況にのみ適用可能な知識や即座に結果を出すテクニックは、長期的には有用性を失う可能性が高いです。これは、技術や手法が時間とともに進化し、変化していくためです。 learning.oreilly.com 「API Design Patterns」は、このような考え方を体現した書籍です。しかも480 ページもあります。本書は単なる手法の列挙ではなく、Web APIデザインの根幹をなす原則と哲学を探求しています。著者のJJ Geewax氏は、APIを「コンピュータ

チーム開発でdocker composeを使っている場合、たまにメンバーの好みでアプリケーションをDockerで動かしたい人と、ホスト環境で動かしたい人に分かれます。@zaru 個人的にはアプリケーションはホスト環境で動かすほうがメリットが強いと思いますが、場合によりけりで絶対ではないとも考えています。 当然、チームの中で開発環境は統一したほうが良いのは良いですが、Dockerかホストか選択できてもいいかなということで今回はdocker composeで特定コンテナの起動をオプションにする方法を紹介します。 Docker Composeのprofileオプション やり方は非常にシンプルで、デフォルトで起動させない、つまり起動をオプションにしたいサービスに profiles キーを指定するだけです。 例として以下の compose.yml ファイルで説明します。 app と db 2つのサー

ソート順の選択プルダウンがある一覧系ページを実装するとき、選択肢たちの管理方法に頭を悩ませることが多いと思います。 商品一覧ページの概要 ソート順プルダウンの選択肢たち 上の画像に示したような場合だと、 《クエリパラメータ》と《選択肢》の間の相互変換 ?sort=price&order=desc <--> 「価格が高い順」 《select の状態に使うための文字列》と《選択肢》の間の相互変換 <option value={id}>{label}</option> クエリパラメータが sort order の2つあり、それらをそのまま流用できないので 最低限でも、これらの変換ロジックを用意しておく必要がありますね。 この記事では、このような「選択肢と、それにまつわる変換ロジック群」を整理する方法を、高凝集・SSoT (Single Source of Truth; 信頼できる唯一の情報源)

2024年度リクルート エンジニアコース新人研修の講義資料です