スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

レパードにした

サポートされないソフトが増えるなか、めんどくさいのでずーっとパンサー使ったままだったんだけど、昨日とうとうレパードにしました。多分PPCで動く最後のMacOSになるのでしょう。

別にパンサーでなにも不満はなかったのだけど、Firefox3がね、サポートされてなかったんですよパンサーだと。

しかたがないので会社の帰りにレパードかって、ヨドバシのおねーさんに「メモリ512だときついかもですね~」とか言われつつも、とりあえず速攻でインスコ...とおもったらディスクの空きが足りません、とかいわれる。なんだよー、あれま7Gちょっとしか空いてないじゃん。いらないアプリをせっせと消して、いくつも入っていた古いPerlも片っ端からけして... まだ足りない。いまどき30Gしかないんだなこのディスク。えーい面倒だmysqlもけしてmod_perlもけして、.cpanと.cpanplusも消して。やっとできました9Gの空き。

2時間半ほどまってあっさりインストールは完了。firefox3をつっこんで、よしできあがり。これでiPod nanoの母艦にもなれるんだよね、と思いiTunesを立ち上げる。と、QuickTimeが古いのでソフトウエアアップデートをしろ、と言われる。すなおにしたがうと、こんどはOS自体のアップデータやらなんやらでたんまり2G近くダウンロードする模様。はいはい。やりますよ。

するとまたしても、ディスクが足りません、との仰せ。4.5Gくらいないのかよ、と思って確かめると確かにない。あと500Mたりない。しょーがねーなー、あとどこ消せってんだよ。とかブツクサいいつつなんとかディスクを確保し、アップデート実行。

やっとなんとかなりましたよ。 ふぅ。疲れた。もう12時回ってるじゃんか。いい加減寝ないとね。今日は朝から面倒な話があって、だいぶお疲れモードだしな。そんな日にこんなこと始めるんじゃなかった。

しばらく使ってみたけど、メモリは512でなんとかなるっぽい。別に前と同じくらいの体感速度で動いてます。でもディスクはキビシいな。買ってもいいけど中身入れ替えるのがめんどい。アップルストアとか行ったらサービスでやってくれないかなぁ。どなたか楽ちんなやりかたご存知ないですか。

スポンサーサイト

なんでそんなに沢山かくのか

たまにはコード以外のことも書いてみる。なんだかだらだらと長くなってしまったし、 まとまりも全くないので、興味のある方だけでも読んでいただければ幸いです。

仕事として作られているシステムで、なんかそれSLOCでかすぎね? と思うことがよくある。javaで書きました、という案件に多いのだけど、これは俺がjava嫌いなせいもあるかもしれないので、ある程度割り引いて読んでもらった方が良いかもしれない。 でもやっぱり、その外部仕様でなんでそんなにコード書く訳?とどうしても理解できないことはままある。

そんなプロジェクトの実物コードを見たことは、ほんの数回しかないのだけれど、その数少ない体験全てにおいて感じたのは、

  • ●コードの結構な割合が、パターン化されている。そんなことなら、必要最小限の情報だけを書いた記述を読んで、コードを吐いてくれるトランスレータなりコンパイラなり書けば?
  • ●パターン化されていない部分、これはおおむねビジネスロジックとか言われている部分が多いのだけど、それDSL作ってから書いた方がよくね?
  • ●もうちょっとモジュール設計ちゃんとしろよな。
ということ。

話を聞いてみると、最近の短納期化の風潮とあいまって、上記のようなことを考えているヒマも、考えて実装できるクラスの開発者も確保できない、しかたないので「すごくない」プログラマをかき集めて力技でコードを書く、ということになるらしい。

この方法をとると「すごくない」プログラマに何とか保守可能なコードを書かせるためにコーディングルールをガチガチに決めざるを得なくなる。

さらに「すごくない」プログラマってのは、自分が書いてるアプリのユースケースも ユーザ像も知ったこっちゃないぜ!って人が多いので、UIガイドライン程度のドキュメントでは足りず、微細な動きまでキチンと書いた「詳細設計書」なるものを用意するハメになる。そこまで細かく書くのなら、コード書いたっておんなじだろ?みたいな細かい記述をするわけだ。

そしてその設計書をみんなでレビューし、間違っている点がみつかれば同じ様なパターンの場所を探し出してみな同じように直す。 それって、モジュールなりクラスなりあるいはサブルーチンなしでプログラミングしているようなものだよな。しかも設計書ってプログラムみたいに走らせられないので「デバッグ」なんてこともできないわけだ。だから人力でレビューする。

プログラミング言語って、人間はミスすることを前提に静的型システムを導入してコンパイル時に機械的にチェックできることを増やしたり、人間は複雑なことを考えるのが苦手なので、それに対処するためのモデル化機能を提供するために、クラスだの型だの高級言語が備えている種々の機能を備える方向に進化して来たんじゃないのか。

それを全部捨てて、何で日本語と簡単な図と人力で対処しようとするのだろう?コードレビューだって、やり方によってはスキルアップにためにとても役立つ。でもチェックされることがコーディングルールに乗っ取っているか、だけであれば、そんなことは人力でやらずにソースコードリポジトリへのコミットの時にプログラムにやらせとけばイイじゃん。

別にドキュメントは不要だというつもりはない。システム全体がどういうモジュール構造で構成されているのか、とか基本的な設計思想はこうなってます、みたいなドキュメントは必須だと思う。でもコードを読めばわかることはコードに書いておけばいいじゃないの。

まあ、これをやるにはユーザの目的とユースケース、あるはユーザのリテラシ、性能要件、信頼性の要件、なんていうのをちゃんと理解できる人がコードを書く必要があり、そんな人は非常に数が少ないし、いても疲弊しきっているので無理、というのが現実なのだな。

それでもSIビジネスは続けなければならないから、ルールコチコチ、詳細設計書バリバリって方向になるのは仕方ないことなのかもしれない。そして本当はコード書いた方が速い人も詳細設計やらなんやらでコードを各時間はとれず、設計書のレビューとコードのレビューとプロセス数値(バグ発生率とかね)を規定内におさめるのに奔走し、という訳で、「すごくない」プログラマがユーザのことなんかナーンも考えずに書いた大量のソースコードが出来上がる。保守性はもちろんよくないので、次のプロジェクトでは各種ルールは強化され、ルールに合致しているかのチェックのための手間が増え、さらに人手が必要になり、スキルの高いひとは原価も高いので、スキルの低い人を集めてなんとかしようとし、そしてソースは一回り大きくなる。そしてルールが強化され...

この負のループをどこかで断ち切ってやらないと、SIerの3Kとか6Kとかって、どうにもならないと思う。プログラム書いてる作業を「製造行程」と呼んでるうちはだめでしょうな。コードは設計のアウトプット、機械屋さんや建築屋さんが書く図面と一緒、というのが適切だとおもう。プログラムはコピーしても減らないのだから「製造」はしなくていいよね。パッケージだと「量産設計」は必要だと思うけど。

UUID 生成のベンチマーク

uuidの生成の仕方はどれがいいのかな、という訳で色々ベンチとってみた。

APR::UUIDとData::UUIDの比較

my $du = Data::UUID->new;
cmpthese(100000, {
    'APR::UUID' => sub { APR::UUID->new->format;},
    'Data::UUID' => sub { $du->create_str(); },
});

              Rate  APR::UUID Data::UUID
APR::UUID  86207/s         --       -12%
Data::UUID 98039/s        14%         --
Data::UUIDの方がちょっと速い。

Data::UUIDでも毎回newするとかなり悲惨

cmpthese(100000, {
    'Data::UUID new each' => sub { Data::UUID->new->create_str(); },
    'Data::UUID' => sub { $du->create_str(); },
});
                       Rate Data::UUID new each          Data::UUID
Data::UUID new each  1176/s                  --                -99%
Data::UUID          96154/s               8076%                  --

APR::UUIDをbase64_urlsafeしたものと生文字列で生成したものの比較

sub uuid_compact {
    my $uuid = APR::UUID->new->format;
    my $packed = pack("H8H4H4H4H12", split('-', $uuid));
    return urlsafe_b64encode($packed);
}

cmpthese(100000, {
    'APR::UUID' => sub { APR::UUID->new->format;},
    'APR::UUID compact' => sub { uuid_compact(); },
});

                     Rate APR::UUID compact         APR::UUID
APR::UUID compact 32680/s                --              -61%
APR::UUID         83333/s              155%                --
半分くらい遅くなるのだな。

base64_urlsafeなuuidをAPR::UUIDとData::UUIDで作った場合の比較

cmpthese(100000, {
    'APR::UUID compact' => sub { uuid_compact(); },
    'Data::UUID compact' => sub { $dub64->create_b64_urlsafe(); },
});

                      Rate  APR::UUID compact Data::UUID compact
APR::UUID compact  32787/s                 --               -59%
Data::UUID compact 80000/s               144%                 --
Data::UUIDの方はあまり遅くならない。

結論

使えるならData::UUIDを使った方が良さげ。

uuidを短めに

UUIDを短くしようと思って、こんなの書いた。
use strict;
use warnings;
use APR::UUID;
use MIME::Base64::URLSafe;

sub uuid_b64_urlsafe {
    my $uuid = APR::UUID->new->format;
    my $packed = pack("H8H4H4H4H12", split('-', $uuid));
    return urlsafe_b64encode($packed);
}
CPANにある Data::UUID::Base64URLSafeを使えばいいんだけど、APR::UUIDでやりたかったんだよー。それにしてもなんだか遅そうだな。ベンチとってみようかな。
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。