今回の記事は特に私の意見であり、所属会社の意見ではないことをお断りしておきます。 最近になってまたウォータフォール vs アジャイルの議論を見かけることが多くなってきたので、私が勤務する米国の世界規模のクラウドプロバイダーでは2024年現在どんな開発をしているのかをご紹介したいと思います。私はこれが「正解」といいたいのではなく、何らかのポイントが皆さんの何らかの参考になったらいいなと思って筆をとりました。 ちなみに、2016年時点で私のウォータフォール開発に対する考え方は下記のブログの通りで今も変わっていません。ただ、2024年現在だからといってアジャイルをやるべきと思っているわけでもありません。 もし、今ウォータフォールをやっている人がいたら「そんなこと言ってもどうしたらええねん」となると思うので、自分なりの解決方法も考えてみました。 最初に自分的な結論を書いておくと「2024年の開発と

はじめに JavaScript/TypeScript初学者を抜けたあたりの方に向けてTypeScriptの利点や限界、型レベルプログラミングについて紹介します。 TypeScriptはJavaScriptをラップしたライブラリであり、静的な型情報をつけることができます。また、それらの型情報をもとに型を推論し、型違反な代入やプロパティへのアクセスなどをプログラム実行 以前 に検知することができるようになっています。 例えば、動的型付けの言語であるJavaScriptでは、以下の関数のa,bには数値だけでなく、文字列を渡すことができます。数値同士を渡せば加算してくれますし、文字列同士を渡せば文字列連結をしてくれます。 「数値計算用の関数なのに、文字列連結に利用できてしまう」という緩さを開発時にはなるべく排除しようというのがTypeScriptを導入する意義です。 以下、TypeScriptの基

アンケートには、数値で回答をする設問があったり、自由記述の回答をする設問があったりすることが一般的です。 そして、数値の回答に関しては、集計して性別や年代など回答者の属性ごとにスコアを比べたり、質問間の相関を調べて、分析を進めることが可能です。 一方で、自由記述の回答の場合、膨大なテキストデータを眺めるだけで終わってしまったり、アンケートを見た人の主観的な気付きをまとめただけで分析が終わってしまい、「データに基づいた気付き」を得るまでには至らないことも少なくありません。 そこで、今回は自由記述のアンケートデータがあったときに、有用な情報や気付きを得るために実施すべき4つの分析手法を紹介いたします。 1. 頻出単語のカウント 自由記述のテキストデータがあったときに、データ（文章）は「単語」に分け、それぞれの単語の出現回数を集計（定量化）することで、データの中にあるパターンや特徴を掴めるように

はじめに 「ここにプログラマーはいるか？」 ABC 「いません」 「そうか、なら良い、ところでユーザー名の変更につかうメソッドは？」 A 「POST」 B 「PUT」 C 「PATCH」 「Aを連れていけ」 「うわぁああ」 みなさんは連れて行かれるようなプログラマーでしたでしょうか？ 私はつい最近「POST」「PUT」「PATCH」をしっかり説明できないエンジニアでした いままでなんとなくでこれらのメソッドを利用しており、たまたまとあることをきっかけにこのAPIはPOSTかPUTどちらが適切なのだろうかと考えて違いをはっきり理解しました 今回は案外多くの人がなんとなくで利用しているであろうメソッド3つの違いを紹介していきます なぜPOST/PUT/PATCHはあいまになるのか そもそもなぜPOST・PUT・PATCHが混ざってしまいあいまになっている人が多いのでしょうか？ PUTとPATC

『アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明』は不明瞭 ~書籍「Impact Engineering」を読んでみた感想 ~アジャイルポエムプロジェクト管理メンタルケアコミュニケーション 「アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明」 という記事が話題になっています。 言及している著書がCEOを務めているイギリスの調査・コンサル会社であるEngpraxが挙げている元の記事はこちら（その調査自体を行なったのもEngprax社） 記事に書かれていることの考察や要約は下記で分かりやすく纏めて下さっています。 記事への反応 記事への感想・反応はだいたい下記のパターンのどれかに該当すると思います。 失敗の定義は？ そもそもアジャイルできてなくね？ 下記が失敗するのはアジャイルかどうかとは関係

はじめに データサイエンティストのasanoです。 Gitコマンドを学んだあと「Gitブランチ戦略」や「綺麗なコミット」や「プルリクの出し方」など、チームでGitのコード管理を円滑に運用するためのノウハウは実務を通して学ぶことが多いと思います。 実際の業務ではそういった暗黙知になっている部分を認識合わせするために、本記事のようなガイドラインを利用しています。 ※ これを読んでスキルが一朝一夕で身に着くわけではなく少ない時間でも毎日Gitを触る中で身につけるものだと思いますが、学習の一助になれば幸いです。 円滑に運用するために 次の3つをチーム全員で取り組む必要があります。 ①Git運用モデルを取り入れる ②綺麗なコミットを心がける ③適切なプルリクを出す、受ける ①Git運用モデルを取り入れる まずはA successful git branch model (git-flow)を学びまし

はじめに この記事ではQiitaで550本以上記事を書いてきて、アウトプットに関する理論を発信し続けている私(@Sicut_study)がこれまでに発信してきた内容を1つの記事にまとめたものです。 私はプログラミングコーチングJISOUというアウトプット中心の最速でエンジニアとして成長できる教育事業を実施しております。 その中で多くの方と面談をしてきました。これからエンジニアになる人や、一定数経験している人など100人以上の方とお話をさせていただきましたが、エンジニアとしてのキャリアに悩む多くの人が共通した悩みを抱えていました。 勉強しているのだけど身についた感じがしない 自分のサービスを1つもリリースしたことがない(作りきった経験がない) インプットばかりになってしまう(インプットばかりに気づいていない) アウトプットが大事なのはわかるがやり方がわからない つまりエンジニアとして成長でき

エンジニアのみなさま、日々の学習本当にお疲れ様です！ また本記事まで足を運んでいただき本当に感謝です。 約3分程度で読めるので最後まで読んでもらえると幸いです。 はじめに 工数管理はプロジェクトの成功に欠かせない要素です。工数を正確に見積もり、管理することで、プロジェクトの遅延を防ぎ、クライアントやプロジェクトメンバーの信頼を得ることができます。 本記事では、工数見積もりの重要性とその手法、そして失敗しないためのポイントについて書きたいと思います。 「もっとこうした方が良いよ！」 や 「うちの会社ではこの様な考えで取り組んでます！」 があればぜひコメント欄で教えていただけますと幸いです。 工数とは？ プロジェクトや業務を完了するために必要な作業時間のことを指します。 「人日」 や 「人月」 と呼ばれており、1人日は8時間、1人月は160時間（1日8時間、平日20日稼働）で表現するケースが多

対象者 未経験からエンジニアを目指したい！と考えている方 エンジニアになったけどなかなか成長できてないな・・と感じている方 エンジニアになったけど毎日が大変な人 もはや挫折寸前の人 に読んでいただけると嬉しいです！ 自己紹介 株式会社PRUMという会社の代表をしています。岩本です。 https://prum.jp/ SES企業でエンジニアとして就業したのち、ヤフーでもエンジニアとして働いておりました。 2019年、PRUMを創業し組織を５期目の途中で70名の組織まで成長させました。 エンジニアの成長について、誰よりも考え抜いてきた自信があります。 エンジニアと挫折について 僕は、エンジニアになって1年で 「もう辞めたろう、俺には合わん、無理だ」 と思っていました。 1年間、闇雲にものすごいやる気で勉強し続けた自分ですら、そう思いました。 ただなんだかんだ今もシステム開発の業界にいて、もう1

ある日の我が家 ワイ「う〜ん・・・」 ワイ「どないしたら実現できるんやろなぁ・・・」 娘（8歳）「パパ、どうしたの？」 ワイ「おぉ、娘ちゃん」 ワイ「いやぁ」 ワイ「実は、面白いアイディアを思いついてな？」 娘「へぇ、どんなアイディア？」 ワイ「AIと連携した技術記事投稿サイトがあったら面白いんちゃうかな、って」 娘「何だか、フワッとしたアイディアだね」 娘「よく分かんないけど、パパが自分で作ってみたら？」 ワイ「いや、ワイはフロントエンドしかできへんから」 ワイ「記事投稿サイトはちょっと、作る自信ないわ」 ワイ「サーバサイドとか、データベースとか」 ワイ「よう分からんし」 娘「じゃあ、私が作ってあげるから」 娘「要件を教えてよ」 ワイ「AIがいい感じに記事をアレしてくれるサイトや」 娘「いや、だからフワッとしすぎなんだって」 娘「そのサイトを作りたいと思ってるのは、パパなんだからさ──」

※ 最小の意思決定にしては粒度が粗めですがイメージはつくかなと思います 開発プロセスも同様で、目的に対して複数のステップを踏むことがほとんどですよね。リファクタリングであれば単体テストをあてる ⇒ メソッドの内部実装変える ⇒ テストのリファクタリングする、みたいな。 こうした１つ１つの小さな意思決定という単位で履歴（意図）を残すことは、開発者の責任です。なぜなら、変更の差分はPRを見ればわかりますが、「なんでその意思決定（コードの変更）をしたのか？」はコミットメッセージを見ないと分からないからです。そういう意味で、開発者の Why? を把握するために、最終的なPRの差分がどのようにして出来上がったのかを知るために、最小単位の意思決定の履歴はレビュワーが欲しいと思う重要な情報なのです。 コミットメッセージが簡潔で分かりやすい コミットが意思決定の最小単位になっている と関連しますが、意思決

ScalaMasturi 2024で, 拙作の拡張可能レコードのライブラリrecord4sについて発表してきました. 発表で触れられなかった点も補足しながら, 内容を文章にしておこうと思います. とくにrecord4s以外のレコード実装との比較についてはこの記事での完全書き下ろしです. モチベーション Scala 3の標準機能による解決 理想 record4s Tips メソッドの定義 例を使ってJSONをデコード 内部実装 フィールドアクセス レコードの結合 重複キー問題 Scalaの他のレコード実装 shapelessのRecord scala-records Karlsson & Haller '18 record4sのArrayRecord Named Tuples 他の言語での例 PureScript TypeScript Haskell パフォーマンス レコード作成の実行時間

TypeScript は本質的に自分に型が付与されていると思っているだけの JavaScript です。 いくら型を付与しようが、それが実行時に影響を与えることはありません。 コードレビューをしているとここを誤解している人が本当に多いです。何度も解説しているのですが、なかなか浸透しないので、TypeScript におけるバリデーションという視点で記事を書くことにしました。 あと TS でバリデータ使って色々作ろうとしている友人と、プログラミング始めたてで zod と openapi を使っいる友人がいたので、彼らが想定読者です。 型と値の名前空間 TypeScript 上での名前空間(スコープ)は2つに分類できます。 値: 実行時にランタイム上のメモリに存在するもの 型: 静的解析時にのみ参照可能なもの。コンパイル時に完全に消滅する。 TypeScript は基本的に JavaScript

LINEヤフーから日本語CLIPが出ていたので、どうやって使うんだろうと試してたら、なんかめちゃくちゃ便利な画像検索ができてしまいました。 clip-japanese-basic LINEヤフーの日本語CLIP、clip-japanese-baseはこちらで紹介されています。 高性能な日本語マルチモーダル基盤モデル「clip-japanese-base」を公開しました HuggingFaceのモデルはこちら。 https://huggingface.co/line-corporation/clip-japanese-base CLIPとは？ ところでCLIPとは、となりますけど、OpenAIが公開してる、言語と画像を扱える機械学習モデルです。Contrastive Language-Image Pre-Trainingの略らしい。 https://openai.com/index/clip

既存の LLM コード生成の問題 LLM は行カウントやワードカウントが苦手。 例えば自分は SourceMap を扱うコードのテストを書かせようとしたが、モックデータの line:column がガバガバな位置を指してまともにテストにならない。行カウント/ワードカウントができないのはつまり diff がうまく生成できない。 これらの問題があって、コードを生成するパイプラインを組む場合、 全文出力が主流になっている。 ここで何が問題になるかというと、コードが膨らんで来た時に、(書き変える対象が一部だとしても)生成が顕著に遅くなる。うまく生成できなかった時にリトライを繰り返すと、問題がさらに悪化する。 改善手法の提案: 明示的な Line Number の付与 最近の LLM は入力ウィンドウがある程度大きくても、そこそこの速度で応答する。(お金はかかるが...) 問題は生成速度にある。特に

色のカスタマイズ ターミナルソフトウェアには色のカスタマイズ設定が用意されている。macOSのTerminalでは以下の設定画面が用意されている。 Backgroundは背景色、Textは文字色、Cursorはカーソル色、というのは文字通りの意味。 その他は、以下のとおり Bold Textは、歴史的経緯で太字がサポートされていない端末では太字の代わりに色を変えて表示していたため、別の色が指定できる Selectionは、マウスで選択した際の背景色を変え、わかりやすく表示するための色が指定できる（文字の色は変えない） ANSI Colorsは、ANSIエスケープシーケンスにて指定した際の実際の色が指定できる 黒、赤、緑、黄色、青、マゼンダ、シアン、白の計8色が用意されている 8色それぞれに明るい色（bright）を指定した時に表示される色が指定できる 色の種類の指定自体はアプリケーション側

たまには子供以外の事も記録しておく。前職 Xevo 社のレイオフが現実味を帯びてきたのが丁度一年程前の事だ。ちょっと生々しくてまだ面白い話は書けそうに無いが、色々あって今の会社に転職した。去年の夏は失業の恐怖で眠れず深夜の漫画喫茶で過ごしたりやばかった。この業界ではよくある話で私も初めてではないのだが、特に家を買って借金があると冷静ではいられない。結果的には退職金も貰えたし、給料も大して下がらなかったので悩んで無駄だった。 今の会社にはテックリードで応募した。Xevo では管理職だったのでバリバリのICは無理かなーと思ったんだけど、面接が終わってから追加面接があって、やっぱりマネージャやらなくても良いと言われた。私が面接の時にマネージャやりたくない感を醸し出していたのが伝わってしまったのかも。という事で五十代にしてヒラ開発者として復活することになった。さらに入社してみると同僚みんな私以上の

Go Conference 2024に参加/登壇してきました。 gocon.jp 前日のUnofficial Pre Partyから参加させていただき、2日間Goの話題に浸かってしました。 moneyforward.connpass.com 2日に渡って理解した range over func いろいろ楽しかったのですが、印象に残っていることを1つだけを書いておこうかと思います。 Unofficial Pre Party で MakKi さんがrange over funcのエラー処理という具体的なお話をしてもらい、感想戦で大盛り上がりしたあと、Go Conference 2024のトップバッターで tenntenn さんがさらに解像度を上げて紹介してもらえたのことで「range over func完全に理解した」になることができました。 speakerdeck.com docs.goog

Windows 環境で Ruby 3.3 の補完が強化された irb や rbs-inline などの最新の機能を試したいたいときは RubyInstaller を使わずに WSL 経由で入れた方が挙動が安定していておすすめです。 また Ubuntu で snap を使って Ruby をインストールすると標準ライブラリのドキュメントがインストールされず irb の補完時にドキュメントが表示されないため、 rbenv 経由でインストールしています。 動作確認環境は Windows 11 23H2 です。 WSL のインストール(新規) > wsl --install https://learn.microsoft.com/ja-jp/windows/wsl/install これで Ubuntu の安定版がインストールされるはずです。そのまま rbenv のインストールに進んでください。 WS

PHP のメーリングリストから、気になった情報をピックアップします。 Internal Follow up of DateTimeException RFC - Externals PHP: rfc:datetime-exceptions このRFCの実装によって下記の３メソッドはfalseを返さなくなっている Datetime::modify DatetimeImmutable::modify DateInterval::createFromDateString だけど、メソッドのスタブが更新されてないから、ReflectionClassを使うと、falseが返ってきちゃうよというお話。恥ずかしながら、ReflectionClassの挙動に詳しくなかったので驚きました。 この系の実装漏れはいっぱいありそう。それでいて修正自体は簡単そう...チャンス？ PHP: rfc:xmlreader

はじめに 以前紹介させていただき、2022年Qiitaのいいねランキング18位、ストックランキング20位を記録したこちらの記事の続編です！ DevToysはリリース後しばらく定期的なバージョンアップが続けられていましたが、去年の7月からぱったりとアップデートが止まっている状態でした。 リポジトリや作者のXを見るとバージョン２の開発を行っているようで、今か今かと待ち続けていましたが数日前リリース予告のポストを見つけて、今日ついにプレリリースされました！ ということで早速紹介していきます！ DevToysとは DevToysは「開発者のためのスイスアーミーナイフ」の紹介文の通り、開発時によく使うツールを十徳ナイフのようにまとめたアプリとなっています。 JSONの整形とかエンコードデコードetc... プログラミングや保守運用の調査でやりがちな作業をいちいち変換サイトを探したり、エディター拡張機

週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やX.comでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙏 TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチタグ） 🔗Rails: 先週の改修（Rails公式ニュースより） 公式更新情報: Ruby on Rails — Better error message, opt-i

週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙏 TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチタグ） 🔗Rails: 先週の改修（Rails公式ニュースより） 公式更新情報: Ruby on Rails — Better error message, opt

JSer.info #697 - Nuxt 2は2024年6月30日でEnd-of-Life (EOL)となることが発表されました。 Nuxt 2 End-of-Life (EOL) · Nuxt Blog Nuxt 2.xの最終版となる2.18.0が6月末にリリースされる予定となっていて、それ以降はセキュリティアップデートも公式には提供されなくなります。 TypeScript 5.5がリリースされました。 Announcing TypeScript 5.5 - TypeScript TypeScript 5.5では、関数からtype predicatesを推論できるようになり、Array.prototype.filterなどでの絞り込みが簡潔に書けるようになっています。 また、Stage 3のSet Methodsをサポート、JSDocで@import {foo} from "foo"を

JSer.info #696 - Storybook 8.1がリリースされました。 Storybook 8.1 Storyファイルを作成するUIの追加、Subpath importsを使ったモックの対応、Playwright Component Testの対応しています。 pacakge.jsonのimportsフィールドで特定のモジュールを条件分岐して読み分けるための仕組みであるSubpath importsについては、次の記事でも解説されています。 Type-safe module mocking in Storybook Mocking modules • Storybook docs その他には、React 19/Angular 18のサポートなども含まれています。 Turborepo 2.0がリリースされました。 Turborepo 2.0 Turborepoはmonorepo向

Rubyをはじめとする「動的型付け」のプログラミング言語は、ソースコード中に型に関する記述が陽に出てこないことが特徴で、プログラムの実行前に（静的に）型検査をすることはありません。しかし、このようなプログラミング言語においても、大規模な開発における品質の向上や開発体験の改善、実行の高速化のために、静的な解析を活用しようという試みは多くなされてきました。この記事では、動的型付けの言語のための型検査の歴史を簡単に振り返って、現在私が開発しているRuby向けの型検査器Steepとその基盤となっている型記述言語RBSについて説明し、今後の展望を議論します。 著者：松本宗太郎さん（@soutaro） Rubyコミッター。大学院でRubyプログラムの型検査の研究に取り組み、修了後はスタートアップでWebアプリケーションの開発に従事。2017年から型検査ツールSteepの開発を始め、2019年からはRu