眠る開発屋blog

Hack 85. bash シェルでランダムな数値を生成する

$RANDOMって知らんかった。。。

周回遅れ。

はてなブックマーク Web Hook

フィード方式に比較すると、リアルタイム性や作りやすさ（クエリパラメータだし）ということではWeb Hookみたいな形式に分があるだろうな。

フォント同士を交配させて新しいフォントを作る「genoTyp」が面白い
これ面白いなぁ。

『集合知プログラミング』を読んだのを思い出したので、そこの「遺伝アルゴリズム」を参考にして、それっぽいのを習作としてやってみた。

ルールは、
・まず最初にランダムな５個の数字　x　１００組を生成する。
・５個の数字の積が１０００になれば進化終了。１０００に近いものを優先的に残す。
・１００組のうち、結果がよい（積が１０００に近いもの）５０組を残す。
・突然変異（８割の確率）、交配（２割の確率）で新たに５０組を生成する。
という感じ。

ってかなんだろね、このロジックを試してみるには、積が１０００に近いとかって不適当かもしれんね。
数の並びとかあんま関係ないし。

なんか自明のことな気もするけど、受託開発より自社サービスの開発のほうがなぜ効率がよいのかだらだら書いてみた。

仕様などを企画した人が傍にいるので、分からないことは歩いて聞きに行ける。
作った人も傍にいる。
作ってる会社は作ってるかもしれないけど、聞けば分かるという理由で、ドキュメントが不要。
「こういう企画楽しくてよくない？」という提案とか、開発者の裁量の度合が大きい。
「効果の割には工数が大変だからやめにしない？」とムダな機能も作りこまずに済む。
失敗したときの損失を把握している分、リスクをとりやすい。
同じシステムをずっと改良し続けるわけだから、ノウハウが蓄積される。
自分達の会社のシステムだから、システムに対する愛着が深い。

同じ人間が作り続けるから、新しい技術を学びにくいのでは？って思われるかもしれないが、
クライアントに振り回されて突発的に時間を浪費するってこともないから、新技術を学ぶ為の余裕も作りやすい。
あと、リスクをとった動きができるので、実際の開発にもとりいれやすい。

ってなわけで開発の効率は高いかと思う。
これが具体的にはどういう形になって見えているかというと、
「受託開発の３分の１ぐらいの人数で、３倍ぐらいのスピードで作っている」
というところではないかと。

受託でやらざるを得ないシステム・・・システム事業がコアな業務と考えられてないので外注せざるを得ない・・・があるのも理解できるし、おそらくなくなることはないのだろうが、「毎回違うメンバー、違う要件、違うシステム構成」では効率性は上がっていかないだろう。
そもそも「人月で出した見積もりが通ってしまうビジネス」であれば、効率性を追求するインセンティブは低いといえば低いのかも。

業務アプリの業務部分で、オブジェクト指向なんか使わないよね
Re:業務アプリの業務部分で、オブジェクト指向なんか使わないよね

個人的な感覚だと、プログラムの８割ぐらいはORマッパーが効率がよい気がするけど、残り２割はSQLのほうが効率がいい気がする。
だから基本はORマッパーだけど、要所ではSQLを使うというのが現実的なんじゃないかしら。
その路線を採用しているプロジェクトが大半な気がするけど。

この手のべき論って使い勝手のよい人材の定義でしかない気がするけど、

新人プログラマーがプロのプログラマーとして独り立ちするための7つの条件

これもそういうことなんじゃないのかね。

個人的には、
「技術が好きなこと」
「よい営業パートナーを見つけること」
の２点しかない気がするのだがどうだろ。

/var/wwwにDocumentRootを設定するのを大前提にしたソースって結構よく見る。

まぁ気持ちは分かるのだけどさ。

でも開発環境とかで複数ドメインを動作させるとかそういうことしたいときにすごくめんどくさい。
仮想PC作ればいいのか。
でもIPアドレスがそれほど多く振ってくれるわけじゃなしなぁ。。。
apacheとかのWebサーバのドメイン名称ベースで仮想PCを作れるソリューションってあるのかな。
いやないか。

/home/hoge/html とか、そういう感じで作って欲しいんだけどね。
でも多くの技術書とかISPのマニュアルで、「/var/wwwが直下のディレクトリとなるのでそこに index.html 等を配置してください」というのが普通にあるので、それにならってしまうのだろうなぁ、とか。

他人が作ったプログラムをごにょごにょ改造する仕事ってのが、
年に１度くらいはある気がして、
アクションとかロジックの部分になるべく手を入れたくないから、
JavaScriptでごにょごにょすることが多い。
でも、ベースの思想とかなかなか見え難いから、jQueryとか導入しにくいんだよね。
なのでベタベタなJavaScriptとかに。

あと文字コードがあれれ？ってのも相当よく見かけるのだけど、
Linux上で動作しているハズなのに内部のコメントはSJISだったりとか、
そういうのってカンベンしてほしいなぁというか、
昭和のプログラムというか、３、４年前の書き方のような気もするんだが、なんかいい表現方法ないかしら。

SJISになってしまうのって、Windows上で開発したものをそのまま納品とかしたりするのだろうか。
まぁ本番環境もWindowsであれば問題ないんだろうけどさぁ。

ちょっと厳し目のスケジュールでシステム開発を相談されたとき、
バッファを見て、大体１．５倍ぐらいの納期で答えるのもYesだと思うのだけど、
如何にして作業期間を圧縮するか？と自問自答するのもYesだと思うんだよね。

短い工期だとそれだけ売上が低くなる・・・ってのはまた微妙な話で、
あとは営業がクライアントの懐具合を確認しつつ、向こうが納得できそうな数字を出してくれ、とかそんな感じ。
工期はあくまで参考数字程度にすべきじゃないの、ぐらいにしか思わないのだが。

「システム開発の費用が安過ぎる」と嘆きたくなるときもあるけど、
１０分の１の労力で行えば、相場の２分の１でも利益を上げれる筈だし、
「じゃあどうすれば１０分の１の労力で行うことができるのか？」
「こうすれば早く開発できる！」
とか日々頭を悩まし続けるのもいいんじゃないの、とか思う。

これまたどうでもよいこと。

他の会社が構築したシステムを引き継いで、保守することとかあるのだけど、
ビジネスロジックとかバリューオブジェクトとかきっちり分かれていて、構造的には美しいのだろうけど、
ハッキリ言ってメンテナンスしにくい。
自分自身のコードリーディングの力が不足しているのか？感覚の違いか？
でもWordPressみたいなソースコードのほうがまだ追いやすい印象があるというのはやはり否めない。
個人的に個々のオブジェクトの責務に厳格になりすぎて詳細なレベルで処理を区分するのはあまり好きじゃないんだよね。

エンジニアがタイトル買い、著者買いすべき本

「エンタープライズアプリケーションアーキテクチャーパターン」とか良本だと思うけど、
ファウラーの言うことってOOPの設計屋宗教みたいなところあるよなぁ。
「読みにくい」といったシステムもまさしくそれを踏襲した感じ。
「美しい構造」と「読みやすい構造」と「保守しやすい構造」は違うのかもしれない。
設計ドリブンになると「設計の為にコードが記述される」って性質が強くなり、コードそのものの可読性は下がるのではないだろうか。
設計書がしっかりしてればいい、みたいに言う人もいるだろうけど、「設計書を理解し、コードを理解する」ってのは単に二度手間じゃないの、とか。

正直、設計屋いらない。
大規模は設計屋がいないと難しいというなら、そんな規模の仕事はやらないことにしよう。
そもそも大規模って上流工程でやらないとそれほど儲からないし。
ってか、「大規模」ってウチの職場が手がけることとかあまりないから関係ないだろうし。