Introduction: The Uncomfortable Question Software projects are still failing at alarming rates—despite decades of “Agile adoption.” Engineers are burning out in London, Bangalore, New York, and Tokyo. Morale is collapsing. Quality is declining. The methodologies […]
Category: Technical
Is CI/CD Your Savior? Think Again.
A pragmatic look at the hidden costs, the small-batch myth, and why user trust matters more than deploy frequency. I. Introduction “CI/CD will save you money. It will make your team faster. It will eliminate […]
It’s Time to Rethink Agile. The Albatross Method Is the Advanced PM’s Choice.
Why project managers who have outgrown reactive rituals are turning to proactive, component-based engineering. Introduction: A Global Crisis Beneath the Agile Banner Software projects are still failing at alarming rates—despite decades of “Agile adoption.” Engineers […]
Understand Relu as a Piecewise Function
Relu is an activation function defined as:$$Relu(x)=\begin{cases}x, & x > 0 \\0, & otherwise\end{cases}$$. This function has an interesting property that it can act like an open/close switch. To see why, suppose $\vec{x}$ is a […]
Understand Why A Sole Linear Layer Does Not Classify Well
In deep neural network, the most frequently used component may be the linear layer. However, the linear layer itself does not work well as a classifier. In this article, I intend to explain why from […]
バイブコーディングのブームがそろそろ過ぎ去ろうとしているのではないか
動画サイトでは、まだまだバイブコーディングの話題で盛り上げています。しかし、すでにいくつかの楽観視できない結果でデータとして出ています。最近は下記の結果が目に飛び込んできました。 The AI Productivity Boom that Wasn’t | L&DeepDive 要約しますと、ベテランプログラマーであれば、生成AIを使って、20%早くなったという錯覚が生じて、実際は20%遅くなったという結果になった。 これでは、バイブコーディングのきれいな泡はほぼ弾けてしまいました。 バイブコーディングでは、もともとテクにある負債を神速に積み上げることが予見されています。今回の結果を加えて、生産性を落としていることも再度確認されました。 もちろん、生成AIは一つの発展方向ですが、実際のビジネス環境というすごく複雑な文脈(コンテキスト)をどうやって一つの生成AIに低コストに詰め込むことは相当難しいでしょう。 Claude Code社では、80%-90%のコードはAIに書かせていると宣言したことですが、あれば、自社製品作成の一環としてもみなすことができ、通常のプロジェクト開発と比べて、コスト上昇に対する容認度はかなり高いでしょう。 バイブコーディングはプロダクションコードの主力になるまでまだまだ時間がかかりそうですね。
I made a browser extension that helps generate low-code test cases.
Are you a pure programming lover? Or you are someone who dares not to challenge programming? I’d prefer to choose the latter as testers. The reason is that the people who are not programmers tend […]
Rust練習問題：数の整除
問題文 定理：二桁以上の正整数であれば、その一の位を取り除いて、残った数を前記一の位の数字の五倍で割ったら、残りの数が17の倍数の場合かつその場合に限って、元の数も17の倍数である。 例えば、34が17の場合である。なぜなら、3-20=-17が17の倍数である。201は17の倍数ではない。なぜなら、20-5=15は17の倍数ではない。一個正整数nを入力して、あなたの任務はこれが17の倍数であるかを判断することだ。 入力フォーマット 入力ファイルは最多で10セットのテストデータを有する。一セットのテストデータは一行を占める。その行は一個の整数n(1<=n<=10^100)のみがあり、判断待ちの正整数を表す。n=0であれば、終了を意味し、この行を処理すべきではない。 出力フォーマット 一セットのテストデータに対して一行を出力して、相応のnが17の倍数であるかを表す。1が肯定を表し、0が否定を表す。 入力サンプル 出力サンプル 分析 この問題の難点は、nの範囲にある。64-bitの整数型を使っても、表示範囲が最大で20桁の十進数くらいになる。100桁まで昇るnとしても使えない。つまり、プログラミング言語のビルトイン型では、nを表現できない。したがって、nを表現できる型またはそれに類するものを作らないといけない。 また、前記定理によると、nが17の倍数であるかは、nより一桁小さい別の整数で判定できる。 つまり、$n=n_0$が17の倍数という問題が下記の問題に相当する。・$n_1$が17の倍数であるか、さらに次の問題に相当する。・$n_2$が17の倍数であるか、さらに次の問題に相当する。・$n_3$が17の倍数であるか、さらに次の問題に相当する。・……そして、$n_1 > 10 n_2 > 10^2 n_3 > 10^3 n_4 > ……$ すると、ある$n_p$がプログラミング言語のビルトイン型で表現できる大きさになったら、通常の割り算で17の倍数であるかは判定できるようになる。 前記の定理の中に、掛け算と引き算がある。掛け算に参加する数字は小さく、引き算に参加する数字が大きい。このため、大きい数字の引き算を実装する必要があることになる。 回答案
Rust練習問題：弟の算数検査
問題文 弟は100以内の足し算と引き算をやりました。チャックしてあげてください。核問題の形式はa+b=c或いはa-b=c、どれも100を超えない非負整数です。cは弟が算出した回答で、200以内の比数整数であるか、一個の「?」かです。「?」は回答不能を意味します。 入力形式 入力は100行以内とし、EOF記号で終了します。一行ごとに、一問があります。形式は前述規定に則し、いかなるスペースを含みません。入力されたすべての整数に左に不要な0をつけていません。 出力形式 一行のみを出力します。一個の非負整数のみが出て、つまり、弟が正解した問題の数。 入力サンプル 1+2=33-1=56+7=?99-0=99 回答案
Compute Sigmoid Function Smart
The sigmoid function frequently appears in machine learning contexts. It has a simple form: $$\sigma(x)=\frac{1}{1+e^{-x}}$$. A naive implementation in C would be: It looks good, right? No, it is not. When $x << 0$, say […]