<< Prev Page Next Page >>

スポンサーサイト

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


フォルダ監視している間だけ同期 MonitSync

「フォルダ監視している間だけ同期 MonitSync」
というフリーウェアを公開したよ。おもに自分が使うために。要.NET Framework2.0。
http://tkr.nsf.jp/monitsync/

xcopyとかみたいにどーんと一括で同期するんじゃなくて、起動している間だけ同期する。
NTFSのイベントに100%依存しているので、すごい勢いでドバドバ更新がかかるとイベントが落ちる可能性があります。個人のPCでの利用がいいと思います。

ソース公開…そのうちします。といっても別に見てもなんも面白くないけどね。


渋滞のこと

また広告が表示されてる…書くよう。
それにしてもブログ書く暇もないほど忙しいってどういうことや。

さてこの連休で渋滞に巻き込まれて大変だったという方も多いと思いますがいかがお過ごしでしょうか。とっくりです。(ブランクが長くて切り出し方がわからない)

渋滞に巻き込まれて、イライラを募らせて、
・どこまでいっても1000円なんてやるからこんな渋滞になるんじゃボケ
・うちETCついてないから1000円にならんのじゃ
・ETCつけたくても売ってないんだも~ん
・トラックも1000円にしないと経済効果としては小さいのではないだろうか
などなど、いろんな怨嗟の声が聞こえてくる。

まあね、東京圏に住んでる人にとっては渋滞がすごすぎて車がピクリとも動かないみたいな状況で、腹が立つのでしょう。でもその渋滞作ってるのも1000円に釣られた自分だし、お金がかかっちゃう一番の原因はさっさとETCをつけてなかった自分だし、ここは将来のスムーズな交通のためにちょっと我慢だよっ。ETCが完全普及すれば料金所の渋滞が数分の1になるはずだし、もっと細かい料金体系でちょくちょくサービスされたりもするはずだから。

で、九州では、たぶんほかの地方都市もそうだと思うけど、あの東名高速とか首都高速とかの絶望的な渋滞とはちょっと違う。

いわゆる「自然渋滞」っていうやつで、特徴は、渋滞にはまってから30分ぐらいトロトロ運転になって、完全に止まってしまうことなく、渋滞の先頭まで行くと何事もなく流れ出すので「え?いまなんで渋滞してたの?」という感じで抜けてしまう。

先日も鳥栖ジャンクションの手前で渋滞20kmとかになってるから、そうかジャンクションの合流とか分岐とかで詰まっちゃってるのかなと思ったら、ジャンクション手前1kmあたりで渋滞が終わってた。分岐も合流もすんなり流れてた。え~っ。

そういう自然渋滞は、「渋滞学」で解消することができるらしい。要するにNexcoがちょっと施策を打てば九州の渋滞は根絶できるってことだ。(料金所とかバリアとか、そういう場所の限界流量を越えたせいで後ろが詰まっちゃう種類の渋滞は無理だと思う)
「渋滞学」の権威、西成活裕東大教授が伝授!目からウロコの“究極”の渋滞回避術(日経BP)

まず、渋滞が出来るきっかけは
「流れのスピードが上がってて車間距離が詰まってるときに、誰かがぎゅっとブレーキを踏んだ」
という、たったそれだけのことで、その後ろの車がもう少し強めにブレーキ、そのまた後ろがさらに強くブレーキ、…と連鎖していって、ずっと後ろのほうは止まってしまうということらしい。

じゃあ、なんでブレーキを踏まなきゃいけないかというと、
「速い車と遅い車がいるから」
「無理に割り込む車がいて車間距離が強制的に縮められるから」
ってことだろう。速い車は、自分が渋滞の原因になってるなんて思いもしないだろうけど、みんながぴったり息をあわせて同じスピードで走ってたら車間距離は縮まらないんだから。

「渋滞学」の西成活裕先生によると、時速約70kmで走っているとき車間距離40m以下だと渋滞するらしい。もっとスピードが速いときは車間距離がもっと必要で、もっと遅いときはもっと詰められるってことだろう。一般道の感覚からいくと、時速50kmなら車間距離20mぐらいでも流れられる気がする(交差点も違法駐車もバス停もないことだしねー)。

車間距離が半分(=密度が倍)になってスピードが半分にならないなら流量は大きくなってるので、交通量が多いときは強制的にスピードを落とさせて車間距離を詰めさせることで、渋滞を防げるというか、深刻な渋滞になるところが「ちょっと遅いな」で済むはずだ。もっとも、あまりにスピード落として30kmとかになっちゃったらそれ渋滞と変わらんし、車間距離はある程度以下には縮まないので意味がない。

高速道路のある地点に流入する車の流量(時間当たりの台数)はカウンターでも設置すれば計測できるわけで、そうすると、その流量を渋滞させないために最適なスピードはリアルタイムに計算できるはずだ。

ということは、問題は単純化できて、
「渋滞しそうなほど交通量が多くなったときに、渋滞の原因となりやすい場所で、流れを強制的に遅くする」
ということになるんじゃないか。

それ、F1とかで事故が起こったときに出てくるペースカーで実現できるよね。

「回転灯が回ってるペースカーを追い抜いたらタイホ」っていう法律作っといて、渋滞を起こしやすい地点に10台ぐらいNexco印の黄色い車を投入して、コンピュータで計算して割り出した最適速度で走らせる。もちろんそのエリアをぐるぐる回り続けるのね。

職員がやると人が足りないので、
「車を運転するだけの簡単なお仕事です」
「他人と会話することがほとんどありません」
「好きな音楽でも聴いて、こちらが指示する速度でのんびりとドライブしてください」
「土日だけ働ける方募集」
なんて募集するとわんさか集まるんじゃないかな。

っていう話を、渋滞にはまりながら奥さんとしていた。こういう変な話をウザがらずに乗ってくれる奥さんが大好きです。

何度もいうけど、首都高速とかはぜんぜん種類が違うのでこれ意味ないから。あくまでも地方のまっすぐな高速道路の自然渋滞の話。


スゴいフレームワークの構想(2) 言語はなにに

Webアプリのフレームワークにどの言語を選ぶかは悩ましいところ。

僕の興味は、とにかく楽をしながら、でもできるだけ妥協しないで自分と顧客の納得のいくモノを作ること。Ruby on RailsとかCake PHPとかmojaviとか、レールから外れたらかえってつらくなるみたいなのはイヤだ。


言語そのもの
言語そのものは、Java、Ruby、PHP、perlから選んでみる(Pythonは触ったことがない…)。現時点での慣れについては考慮しない。なんとでもなるから。開発~デバッグ~導入~保守~性能のトータルで考えたときに一番楽な組み合わせを選択したい。.Netは書けるけど、結構気に入ってるけど、環境にお金がかかるのがネックなのでちょっと選択しにくい。零細企業ですから。

ロジックが気持ちよく楽に書けるのはRuby。PHP5もだいぶいいけど、[1, 2, 3]で配列にできたり{a:1, b:2, c:3}でハッシュが作れたりするRubyに比べると全然劣る。多重配列に恐ろしく自由に代入できるところはPHPが便利。

PHPの似非オブジェクト指向的な部分は、僕は実は全然平気。文字列や配列がオブジェクトじゃないと気持ちよさが減るけど、扱う関数がちゃんと用意されてれば困りはしないじゃない?そういう意味でPHPの配列関数の充実っぷりはステキ。

ただ、ぶきっちょな言語=パーズが簡単な言語=エディタ が発達する。EclipseのJavaエディタは数ある言語、開発環境の中でも最強だと思う(それでもJava書くのはやっぱり面倒だけど)。EclipseのPDTはかなりキてる。


性能について
性能を考えるとJavaはつらいところ。メモリがばがば使って1サーバーで捌けるユーザー数が明らかに減るのはきつい。Seasar2がようやくtomcat上でホットデプロイできるようになった、って、そこまでいくのにいったい何MBのクラスをロードするんだろうって。


Viewについて
テンプレートに行く前のロジック部分に、表示のための整形みたいなコードを入れたくない。だってそれはViewがやるべきことでしょ。で、PHPのmojaviみたくViewのために別クラスを用意するってのもめんどくさい。

今のところ僕にとってPHPの魅力はSmartyがあること。僕は新しい言語習得が全く苦にならないからだと思うけど、Model、Controller、Viewを適材適所の言語で書きたい。使いやすいUIを作ろうとすれば、ViewにはViewなりの複雑なロジックを入れなきゃいけなくなることがあるので、RubyのAmritaとかPerlのHTML::Templateとかではまだ足りない。

HAMLは、ちょっとHTMLから離れすぎで自由に書きにくい。テンプレートをWYSIWYGエディタでいじるとこまでは今のところ必要ないけど、あっちでプレーンHTMLとJavaScript書いて実験して、こっちにコピペ、みたいなことはやっぱり必要。

Smarty遅いけど、まああれくらいまでなら許容できる。それにどうしてもレスポンスが必要になるページに限ってPHP直書きに逃げるっていう手も残されてるし。

|encode とかをいちいち書かなきゃいけないのもかったるいけど、他の機能があるから仕方ないか。


Modelについて
RDBの接続が自由に出来るのはどの言語でも同じ事だから、考慮することは特にないと思われる。Javaだとコネクションプーリングがある。PHPもコネクションをある程度使い回してくれる。


うーん、やっぱりPHP5+Smartyかなあ。
Rubyで書きたいんだけどなあ。Rubyで、Railsを越えるフレームワーク作って、地を這うRailsのみなさん、こっちは軽くて速くて簡単なRuby on Wingだぜとかって自己満足に浸りたいんだけどなあ。


Picasa Web Album

なにやらHTMLを貼り付けると何かが起こるようなのでためしてみた。


業務WebシステムのクライアントにFirefoxを使う3つちょいの理由

業務システムがVBからWebへ、移行してきたのにはいくつか理由があった。

最も大きな理由は、

システムを変更する時に全てのPCに再インストールが必要になる

というもの。何百台もになると配布ってホントに大変だから。まずそのPC使ってる人が会社に来てる日じゃないとできないし(鍵の付いた引き出しの中にノートPCがしまってあったりするので)。忙しくてヒーヒー言ってるときに「再インストールしてもいいですかぁ」とか言うと殺意のこもった目でにらまれるし。その他いろいろ。

で、新しく業務システムを作るとき、もし万が一、それが最初のもしくは唯一のWebシステムであるのなら、クライアントとしてFirefoxを強制するっていうのはどうだろうっていうのが提案。最初にFirefoxだけインストールすれば、システムの変更はサーバー側だけ変更すればいいからそれほど痛くない。

もちろんIEを使うのに比べてインストールの手間があるけど。でもFirefoxにすると、うれしいことがいくつかある。

HTML Canvasが使える

11/30追記:ExplorerCanvasを使ったところ、IEでも部分的に動作するようになってスゲェびっくり。あれ。じゃあやっぱFirefoxいらない…?

Operaでもsafariでも使えるらしい。とにかく、ちょっとした図形をJavaScriptで描画できる。これ便利。
「このデータをもとにちょっとグラフ表示とかあるといいねぇ」
「えっ…グラフですか(…ふ、FLASHかな、Java Appletかな、…Active Xはしんどいな…)」
みたいなことはもう考えなくていい。

実例は↓こちら。

HTML Canvasをサポートしていないため描画できません。
売上 仕入れ 利益
本店
本町支店
銀座支店

しっかし、これ作ってみて思ったけど、drawStringが無いのが痛いなあ。むりやりSPAN要素をくっつけて実現したけど。

今回は、HTML Canvasでこんなことできるよって言うだけなので、ソースコードは手抜きも良いとこの汎用性のハの字もないものです。なので、おおっぴらな公開はなし。それでも見る方はそこんとこご納得の上でよろしくです。

tableのヘッダ以外の部分だけ簡単に…スクロールでき…るけど…

いろいろ苦労してたくさんJavaScript書いて、やってる人は多いけれど(僕もやってるけど)、ほんとはこんな基本的なこと、そんなに苦労しないで出来て良いはずなんだよね。

Firefoxではtbody要素にoverflow:scrollスタイルを設定すれば、tbodyの中だけスクロールさせることが出来る。

実例は↓こちら。静的にスタイル設定するとIEでひどいことになるので、Firefoxでだけ何かが起こるようにスクリプト使ってスタイル設定してます。OperaとかSafariとかの人、ごめんなさい。

セ・リーグタイトルパ・リーグ
選手名成績選手名成績
   -最優秀選手   -
  --最優秀新人  --
福留孝介2.351首位打者松中信彦2.324
ウッズ347本最多本塁打小笠原道大132本
ウッズ1144点最多打点小笠原道大1100点
----カブレラ西1100点
青木宣親2192本最多安打大村直之1165本
福留孝介3.438最高出塁率松中信彦3.453
青木宣親141個最多盗塁西岡剛233個
黒田博樹11.85最優秀防御率斉藤和巳21.75
川上憲伸217勝最多勝利斉藤和巳218勝
----最優秀投手斉藤和巳3.783
川上憲伸1194個最多奪三振斉藤和巳1205個
井川慶3194個----
岩瀬仁紀240S最多セーブMICHEAL139S
藤川球児235H最優秀中継ぎ武田久145H
加藤武治135H----

ごめん、横スクロールバーを表示させない方法がわからなかった。このままじゃ使えないね。

Vistaにアップグレードしてもサーバーを更新しなくていい

VistaにアップグレードしたらIE6→IE7に強制的に変更になる。IE6で動いていたJavaScriptが動かなくなるおそれがある。FirefoxはOSのアップグレードとは関係なく同じバージョンが使える。XPとVistaが共存している環境でも問題なく動く。

他のOSでも使える

そんなに大きな意味はないけど。なぜならどうせみんなPowerPointとかExcel使うためにWindowsだから。「仕事上のつきあいだから、ワークってどうですか」


中ぐらいのヤツにとらせろ。

舵をとるのは誰がよいか( ・ω・)ノ<しすてむ開発。さんの記事を読んで最近思うこと。

IT業界所属のSEとは名ばかりの人買い商人とかがシステムの基幹を決める場合がある。
技術者がいない場での夢見るシステム創造会。
体制も開発方針もみんなそいつらが決めて遂行される場合がある。
「夢見るシステム創造会」はナイス。そういうこと、ありますね。
「え、こういうこと簡単にできんでしょ」
「できなくはないけどここでやろうと思ったらものすごい金と時間がかかるってば」
「えーできるって言っちゃったよー」
「言っちゃう前にちょっと相談してよね」
なんて会話は、日本中にあふれていることでしょう。

でも、すこーしだけ違うことを言ってみます。
結論としては。
「レベルの高いのに取らせろ」
コレに尽きる。
でもね。「舵を取る」って結構しんどい作業なわけです。とくにプロジェクトの利害関係者が10人越えるような場合、仕様の折衝をして、仕様書を書いて、最新の状態に保って、みんなのスケジュールを決めて、スケジュール通りに行ってるか毎日チェックして…レベルの高いプログラマーという貴重な、換えの効かない駒をそこで使っていいもんでしょうか。できればそういうプログラマーには気分良く開発に没頭していて欲しいところです。

かといって、ペーペーの新人に毛が生えた程度の人を「舵を取る」役にしてしまえば、他の人たちの開発効率を落とすだけになってしまいます。やっぱりある程度気が利いて手の早さも多少は必要。

そこで、僕はこう言ってみます。
中ぐらいのヤツに舵を取らせろ。舵取りはレベルの高いヤツに相談しながらやれ。



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