static おじさんと呼ばれる人がいたそうだ、あるいはいるそうです。インスタンスの生成を嫌がって、何でも static メソッド にしてしまう人のことです。static メソッドと呼ぶよりも関数と呼んだ方がよいかもしれません。 インスタンスの生成を嫌がるのは、気持ちはわかります。メモリ管理が GC 任せで、速度にどう影響するかわからないのが嫌なのでしょう。現在では、細かいメモリ管理が本当に必要な場合はほとんどないので、ほとんどの場合インスタンスの生成なんて無視してよいでしょう。しかし、ひとつひとつの処理に対してコスト感覚を持つこと自体はよいことです。問題があるとすれば、その感覚が誤っていることでしょう。 ただ、おそらく static おじさんと嘲笑されたのは、コスト感覚の誤りからよりも、未知のものがわからない、覚える気がない態度からでしょう。いつか私も Java おじさんとか Linux

実行可能なテストスクリプト群のディレクトリ構成を定義して、整理するためのフレームワークを作りました。半年ほど前に作ってたやつです。*1塩漬け期間を経たのでリリースとします。 GitHub - fjkz/ttap: ttap: a testing framework with file system hierarchy 日本語 README: ttap/README.md at master · fjkz/ttap · GitHub システムテストを自動化するときに使用することを想定しています。ユニットテストに関しては、便利なフレームワークが既に多くあるので、それらを使えばそれなりに整理された状態を保つことができます。しかし、システムテストに関しては、システム固有の処理があるので、フレームワーク化するのは難しいと思っています。シェルスクリプトなどを駆使して自動化テストを手組せざるを得ない。

小さい頃にノートの隅や地面で良く遊んだ○×ゲームを計算機で解いてみた。 ○×ゲーム程度であれば、スクリプト言語を用いて、かつ枝刈りとかせずに終端までミニマックス法で全探索しても十分に解ける。ミニマックス法というのは、要するに負けない手を打てば勝てるという戦法で、○×ゲームのようなゲームではミニマックス法ですべての局面を調べることができれば、最善の一手が得られることが知られている。 ○×ゲームは両者が最適な手を打てば引き分けとなる。先手に関しては一手目をどこに置いても、引き分けに持ち込むことができる。二手目以降からは、正しく受けないと負けてしまう。したがって、二手目を正しく受けれない可能性があるので、微妙に後手が不利かもしれない。 一手目が中の場合は、後手は隅で受ける必要がある。 初手が隅の場合は、中で受ける。 初手が、辺の場合は、隣の隅か中か対辺に打てばよい。 以下のPythonスクリプト

新しいソフトウェアメトリクスを思いつきました。 ソフトウェアメトリクスとは、ソフトウェアの特性を推定するための定量値のことです。バグの数とかレビューの時間とか開発の過程で得られる値もありますし、テストの数だとかカバレージといったテストを評価する値もあります。ソースコード自体から測定されるものとしては、LOC (Line Of Code)やCyclomatic Complexityがよく知られています。それぞれ、ソースコードの規模・複雑さを示すものです。*1 近年では、ソフトウェアの特性としてソースコードの可読性が重要視されるようになっています。ソースコードは書く時間よりも読まれる時間の方が長い。読むための労力が少ないソースコードは、生産性を向上させ、バグも少なくなります。 可読性を高めるためには、適切な名付けやコメント、明快な処理のフローが必要です。名付けやコメントについては、数値化するこ