June 12, 2012

美意識

Twitterやっちゃうとブログ書かなくなるといいますが
いやホント全くその通り。

普段思ったことをその場その場で吐き出しちゃうので
たまにはブログでも書こうかなーと思って編集画面を開くも
あれ、やっぱし書くことないな……ってなっちゃうんすね。

今日はサッカーのおかげで職場が早々に捌けて
私もうまうまとそれにのっかって早く帰ることができたので
折角この時間のあるときに何か書いてみようかなと。

タイトル「美意識」。

といっても、ビューチホーなアレとかナルシーなソレとかじゃなく
今回私が考察…妄想してみたのは
私の職業分野でいうコードに関するお話。

ここでいうコードというのはプログラムのことです。
コードといってもケーブルとかCメジャーセブンスとかじゃなく…
あ、もういいですか。そうですか。

あーつまり、コンピュータプログラミングにおける
美というものの追求について、ですね。

ところで、まだ本題に入ってないのにいきなり余談ですが、
私は昔、某ゲーム系専門学校のプログラミングの講師に
採用されかかったことがあります。

あれは私がフリーになる約1年前の話。
当時、私が社員だった会社のブラックっぷりにほとほと疲れて
いろいろ転職活動してる中の選択肢のひとつだったわけですが
ほぼ採用が決まった段になって蹴ってしまいました。

理由はぶっちゃけ薄い給料だったんですが
今にして思えば、そうでなくても蹴ったのは正解だったかなと。
学校にも私にも、お互いにとってね。

正直、当時の私は
人に教えられるほどプログラムに熟練してなかったと思う。
まぁ、教えながら自ら成長するという例もよくありますけどね。

ただ、ことプログラムということになると、
間違った概念や知識を若者に植えこんでしまうというのは
やはりそれほど小さくない罪だろうと思うわけです。

それから1年後にフリーに転身してから今に至るまで
1つの会社にとどまらずいろんな会社でいろんな言語に触れながら
それこそいろんな人の書いたソースを見てきました。

ソースといっても、とんかつとかウスターとかタルタルとか…
あ、もういいですか。そうですか。

ソースというのはソースコードのこと。
コンパイルする前のテキストのことですよ。要はコードです。

中にはなんでそうするのか納得いかないコードもあれば、
そういうやり方もあるのかとひどく感心するコードもあったりで
書く人の考え方や性格なんかもコードの中に見えたりして
それはそれで面白い経験ができたと思っておるわけです。

そんな中で、これはキレイだ!これはふつくしいッ!

などと思えるコードというのもいくつかあり
それらの共通点は何だと一言で形容できないもののありますが
きっと確実にいえるだろうことがひとつある。

それは“単純”であること。

そう、シンプル・イズ・ベスト。 SIMPLE IS BEST!!!
(大事なことなので2回…)

全く同じ要件を実現するコードでも、
よりステップが少ない、より階層が少ない、よりシンプルな方法で
実現されているものの方が「キレイだ」と思える。

これはコードに限らず全ての論理でいえることで、
同じことができるなら、より少ない手順でやれるものの方に
多くの場合選択の価値があるという考え方です。

オッカムの剃刀ですね。
数学や物理学なんかも同じ論理で、より単純な方が真理だとされる。

…という観点で見てですね、
逆に「これは酷い」と思えるコードもやっぱり同程度にあるわけで
やれif文の分岐をこれでもかと幾重にも重ねてみたり、
段々畑かと突っ込みたくなるほど何ブロックも奥まってみたり…

それはそれで見た目に面白くて、ビジュアルでは絶景なんですが
きっとコードとしてはいただけないわけです。

あまりやると一体どれがどの終了ブロックかわからなくなったり、
途中で登場する変数のスコープがどこまでか判別しづらかったり
全く同じ処理が同じブロック内に2度3度コピペされてたり…

まぁとにかく、そんなバグの温床になるようなコードが山盛りで
そんなものが実運用で稼働してるとかいう日常がある。

これ書いたのどう見てもプログラマじゃないだろ!
普段ExcelやWord使ってるアドミニが片手間に書いたんじゃないの?
とか思えるようなシロモノが割りと多いという現実。

もちろん、そんなコードばかりというわけじゃないですけどね。
少なからずそういうコードを見る度に、これホントにプロの仕事?
とか思っちゃうわけですよ。

偉そうですね。私。

ええ、私もそんなにキレイなコードを書けてる自信はないですが
少なくとも自分なりに最適化しようという努力はしてるわけです。

目指すところはシンプルさ。

if else if else if else if ... なんて続く分岐の嵐は
switch にした方が見た目にもキレイだし可読性も上がるでしょう。

もちろん、言語によってはそれが使えない場合もあったり
規約縛りがあったり処理速度が落ちたりすることもあって、
そういうやむを得ない理由なり、if文の方が良いといえる理由なり
何かポリシーがあってのことであれば、それも是だと思います。

例えば、大抵の言語で文字列はswitchの条件に使えないので
そういうのはif else をつなげるしかない。それはわかります。

あと、現実は理想通りまるくキレイにおさまることばかりじゃなく、
後からお客の要求で仕様変更や機能追加を強いられたりとか、
致命的な設計ミスがわかってそう書き直さざるをえなかったりとか、
なるべく影響範囲を狭くするために後付コードにしてあるとか、
カスタムメイクだとそういう事情が多いというのもわかります。

ただ、そういう理由もなしで結果的に実現出来れば良しの精神で
ダダ打ちされたコードというのは、美しくないだけでなく
それを書いた本人さえ誤読しやすく、後でメンテする人とかなおさら…
ってことになってくるわけですよ。

全く考えた後がないコードというのは、大体ぱっと見でわかる。

そういうのを見て何も疑問に感じない人というのは、
きっとプログラマよりも他に向く仕事が何かあるんじゃないのかな?
っていってあげたくなる衝動に駆られるのです。

偉そうですね。私。

ホント、ごめんください。
でもここは私のブログなので、ここでくらい好き勝手書かせてクダサイ。

といっても、これ以上書くことも無くなってきたんですが。

要は、コードを書いた後、もしそれを考える時間の余裕があるなら
たった今書いたそのコードはもっとシンプルにできないだろうか?
と考えて欲しいということです。是非とも。

多分、私が今プログラミングの講師になったら、
下手な自前ポリシーは変化するので(それは学んだ!)押し殺しつつ
とりあえず「シンプル・イズ・ベスト」だけは教えると思う。

これは多分、コーディングに限らない美意識という気がします。

今さらそんなことを思ったって話ですが、
考えてみれば、これってわりと枯れた常識だったりしますよね。


よし、久々に書いたぞ。

| | Comments (0) | TrackBack (0)

December 03, 2009

ググっちゃだめか

不幸にはよく気がつくのに、
幸福にはなかなか気づくことが出来ないのは、
その方がより生き抜きやすいからだろうか。

昼飯を食べながら何気なくネットを徘徊してたら
こんなブログ記事をみつけました。

プログラマで、生きている: ググるな危険
(atmarkit.co.jp)

# トラバ張ろうと思ったけどURLが公開されてなかった。

むしろ「ググレカス」な世の中だと思ってたんだけど、
そういうもんでもないのか。

ある程度の開発経験があり、ノウハウや知識もある人には
Google先生はとても重宝するツールではあるんだけど、
いわれてみれば、新人にはあまりよくないのかな。

私が新人時代というと、1998年当時。

まだWebは黎明期といった時期で、当時のWeb検索といえば
日本語だと、有名なのはYahoo!とgooくらいだったかな。

ただ、その頃のYahoo!は登録型であまり有用なサイトはなく、
gooはロボット型だったけど、キーワードにひっかかるだけ
何でもかんでも手当たり次第ヒットしてたので、
その中から使えるサイトを探すのもまた一苦労でした。

# 実は、Google先生が生まれたのは丁度この頃。

ただ、その頃の調べ物といえば、Webより本でしたね。

会社にもプログラム言語の参考書やInside何たらという
分厚い技術系の本が何冊もあり、さすがに版は古いけど
大体調べ物の用はそれで足りました。

足りないときは自分で買ってたしね。高いんだ、これが。

わからないことは聞く、という文化が常識的かどうかは
会社の風土にもよりますね。

先輩が分かりやすく教えてくれればベストなんだけど、
そんな先輩がいない、先輩も知らない、先輩がコワイ!
教え方が要領を得なくて、自分で何とかした方が良い!
というような環境も、中にはあろうかと思います。

私の場合、1こ上の先輩がフレンドリーな人だったので、
聞けばいろいろ教えてくれました。
で、解らないことは大体この本に書いてあるよ、と、
参考書も示してくれましたね。

今にして思えば良い先輩でした。

ただ、その先輩の先輩(まぁ私にとっても大先輩)が
かなりあたりがキツい人で、その人自身は
よくできる技術者として社内でも認められてたんだけど、
こと後輩へのあたりとなると、
そんなことも知らないの?常識だよ?何勉強してきたの?
的な言動をふりまくお人。(ちなみに、その人は女性)

不幸にしてその人の下についた私の同期がいて、
毎日のように「しごかれて」いました。
おかげで、知識はいろいろ身についたようですけどね。

教育という意味では悪いことばかりじゃないけど、
ただ、彼女の下についた人は、
かなりの高確率で会社を辞めていってたのも事実でした。

で、2年目以降は私も先輩社員になるわけだけど、
教育というか、後輩に対して特別に何かを教える
ということは、あんまりした覚えが無いですね。

一応、私も8年間は社員としてやってたわけで、
新人を迎えるたびにトレーナー紛いのことはしてたど、
教える、というよりは、一緒に仕事をする、という感じ。

まぁ、ちょっと違うと思うコードを書いてたら
これはこうした方がいいんじゃない?という程度かな。

もし、私が今も社員で新人を迎えていたら
「ググればいろいろ出てくるよ」っていっちゃうな。多分。

実際、プログラムひとつとっても昔と今の常識では
いろいろ違う部分もありますからね。

昔はいかに省コード、省メモリで書くかが重視されて、
少ないリソースの中でポインタを駆使して
処理もバイナリのサイズ自体もコンパクトなのが良!
とされてた気がするんだけど、最近は違う。

それよりも、メンテナンス性の方が重視されて
効率よりも可読性の高いコードの方が好まれる。
多少は効率が悪くても、それが致命的でなければ
読みやすいコードの方が良!となってきてる感。

GC全盛の今や自分でメモリ管理する必要もないし、
難しい処理はフレームワークが大方やってくれてたり、
なので、今はそういう用意されたフレームワークや
ライブラリをいかに上手く使うかの方が
流行りのソリューションということになってる。

自分でつくる前に、既にあるものを探せ、なんですよね。

そういう意味で、開発の場面でも
Web検索というのは非常に有用なツールだと思う。

昨今のWeb検索は非常に高性能で、探し方次第ですが
回答を見つけるまでの時間を大幅に短縮してくれる。

それこそ、私の新人時代、分厚い本で目次を探して
ページをめくって該当の解説なりコードなりにあたる
ということを考えるとね。

ただ、検索で出てきたものを何も考えずコピペで使う
というのはさすがにマズくて、そのコードを使うなら、
今の自分のやろうとしていることにマッチしているか、
他にもっと適したやり方はないか、ということは
自分で考えるなり、或いは聞く相手がいれば聞くなり
する必要はあるでしょう。

で、件のブログ主さんは
私なぞよりもはるかにキャリアのおありな方のようで
おっしゃることも概ねその通りだとは思いますが、
わからないなら私に聞け、という態度もどうなのかしら。

いや、聞くな!というよりは良いですけど。

むしろ、新人くんが何か調べてることに気づいていて、
それを自分なら教えてあげられるとわかっているなら
教えてあげればいいのに、と思ったり。

自発的に質問させることが重要ということ、か。

実際のところ、Web検索ということに依らずとも
最近の.NETにしろJavaにしろその他の環境にしろ
あんまり勉強しなくても、誰でもそこそこ使えてしまう
ということ自体が今の状況に至ってる要因な気がする。

だから、ちょっと調べれば
そこそこ動くコードが意外と簡単に書けてしまう。

まぁ、簡単に使えることは、悪いことじゃないですよね。


# 結局、ハサミも包丁も使う人次第。

| | Comments (0) | TrackBack (0)

August 27, 2009

mixiアプリ

政治や選挙の話ばっかりじゃ面白くないですね。

何か別な話でも。

ネタの為に、軽くmixiアプリなるものをつくってみました。

 mixiアプリ : 今日のカルマ

ふつうのWebアプリとかFlashとかと何が違うのかと思ったけど
要は、SNSの特性を利用できるWebアプリ、ってことですかね。

ただ、それの利用シーンがまだいまいち。

これは、アプリの利用者よりも
アプリ開発者の為の便宜であるという意味合いが強いかな。

昨今はmixi以外にもいろんなSNSが乱立しまくっていて
それに対応したWebアプリの為のAPIがバラバラでは
アプリをつくる側はいちいちそれら個別のAPIを覚えてから
開発にかからにゃならなくなる。

そこで、天下のGoogle様が、その共通APIを目論んで
OpenSocial」なるものをこしらえなさったのですな。
その(1つの)フレームワークさえマスターしておけば、
それを利用して機能提供してる幾多のSNSにおいて
同じようにアプリがつくれるんだ、というお話。

それを今回、mixiも採用しましたよと。

なので、特に開発者でない一般ユーザにしてみれば
「ふーん」程度のインパクトのものだと思うんだけど、
どうも mixi が、その開発者ではないユーザ向けにも
結構大きく宣伝をうってる(ようにみえるんだけど)
その意図がよくわからん。

簡単なんで、あなたもつくってみてよ、といってるのかな。

しかし、つくるには、まず自分のWebサーバが必要だし
JavaScriptの知識も多少は必要。
(本当に使えるものをつくるなら多少じゃダメだけど)

あれかな。

こういう形になれば、
今後はいろんな開発者が標準的なアプリをつくって
mixiにも提供してくれるようになる(はず、な)ので、
そのアプリを使ってより一層楽しめるようになりまっせ
ってことかな。

とりあえずつくってみた感じ、
標準機能だけ使うものなら、確かに簡単に実装できます。

ただ、mixi内部の情報を利用するだけなら、
何もわざわざ新たなアプリをつくらなくても、
mixiで標準で提供されてる機能を使えば十分。
てか、それ以上の情報はAPIでも取得できない。

それをさらに使えるものにするのは、
きっと外部サイトとの連携ってことになるんでしょう。

で、今回私がつくったアプリは、
スラドのユーザページに表示される「カルマ」みたいなやつで、
そのユーザを別の何か(出鱈目な言葉)で表現するような
ただそれだけのお遊びアプリです。
(「カルマ」というと、「業」とか「前世」とかの意味ですけどね)

中身で何をやっているかというと、
まず最初に「〇〇さんのカルマ」という文句を出すために
ユーザ情報からユーザの名前を取得して表示して、
その後ランダムに登録されている形容詞から1つ選んで、
さらにランダムに辞書サイトを選らんで名詞を取得して、
それらを連結して1フレーズにして表示、とやっている。

この、登録されてる名前をとるところがSNS内部情報で、
ランダムに言葉を探してくるところが外部サイトとの連携
(言葉の検索と連結は外部スクリプト(PHP)でやってる)
ということになってると。

そのSNS内部情報は簡単にとれて良いんだけど、
やっぱり外部サイトの情報をとってきたりというのは
ふつうにGETやPOSTで要求を出して、
その応答(JSONやDOM等)を解析する形なんすね。

まぁ、それ以外にやりようがないか。

これだと、SNS側の実装というよりは、
結局その外部サイト側でいかに凝ったことをやるか
という方が勝負になってくるんじゃないかと。

キモはAPIの共通化なんだ、ということなら
こういう形でスタンダードを目指すというのもアリといえば
アリなのかもしれませんね。

あと、そういうアプリを、外部サイトだけでなく
SNS内で使ったり表示したりできるよ、ということか。

ちなみに、共通APIというだけに、
これはmixi以外の(OpenSocialを採用している)SNSや
Googleガジェットも同様につくれますね。

てか、コードにmixiに依存した部分がなければ
そのまま他に転用も可能な模様。

これはこれで、ひとつの大きな利用価値かもね。

| | Comments (1) | TrackBack (0)

February 07, 2008

プロジェクト・コメディ

これはもう結構(我々の業界では)有名な風刺画。

project comedy

わかっていても失敗するのは何故か。

結局これは一番初っ端の要件定義がコケているから、
というところに落ち着くんじゃないだろうかと。

つまり、ユーザは本当に作って欲しいものを伝え切れてないし、
開発側はとにかく要求された機能を実現することを考えるから、
ユーザの説いたそのシステムが必要な背景が御座なりになる。

要は、そのシステムが実際にどういう使われ方をするものなのか、
ということの考慮が、結構設計から抜け落ちていたりするのね。

そうしてお互いにすれ違ったまま基本設計、詳細設計に入っていくから、
実際に動くモノができてみたところで、
ユーザから文句や仕変の嵐を食らうことになると。

でも、その最初の(要件定義段階の)合意というのは、
そう上手いことまとまることはないんですよね。

なんべんやっても
「よしっ、客が言いたいのはそういうことダナ!wink
と膝を打つことはまずなくて、
「んー、多分こういうことなんだろうなぁ?despair
で進んでいくことがほとんど。

まぁそりゃそうで、
最初は実際に動くシステムがない(当然)わけだから、
お互いに「絵に描いた餅」の話をしてることになる。

あと、最近わかってきたことは、
特にこれはWebシステムにいえることだと思うんだけど、
ユーザは機能よりも結構見た目の方を気にする、ということ。

開発者としては、機能さえ満たせばいいじゃん?
という方向に傾いてモノをつくってることが大概なので、
見た目がどうとかいうあたりを実はあまり意識していない。

でも、ユーザとしては、機能は結局裏方でしかなく
見た目に目立つところをかなり指摘してくる。
機能は満たしていて当たり前というところなんでしょうけどね。

制御系やってるときはそんなことはあまりなかったんですが、
やっぱりWebは基本的に見せるもの、だからなんでしょうね。

最近はJSやAjaxでいろんなことができるようになったせいで、
お客さんからも、Web上で何でもできるんじゃないの?
とか思われていて、GUIも単純なフォームじゃなく、
WordやExcelみたいなモノを軽く求められたりする。

ていうかね、血の涙を流しながら力いっぱい苦労した末に
Wordみたいな入力やExcelみたいなスプレッドをやっと実現して、
こっちはもう心の中で親指とか立てながら「どうすか!お客さんっ!good
のつもりで見せてるのに、お客さん「ふうんgawk」的な反応だったりして
ショボーン(´・ω・`)みたいな。

こんなんがエエゆうてたんやないんかいっ!

まぁ、人の欲するところをバッチリ理解できるような能力があれば、
それこそマーケティングの神様にでもなれますわね。
てか、ちょっとでもそういうことができるなら、
もっと世の中上手く渡ってます。

基本的にKY。

神でも仏でもない凡人が開発とかやってるんだから、
結構この業界って無理を通してるところがあるのかもね。
バッチリ上手くいくということはないのなら、
プロジェクトをいかにデスマに導かないかがPLやPMの手腕なのか。

もう私もこの業界10年近くになるけど、
メンバ10人以上の規模のプロジェクトで、万事うまくいったZE!
という経験はほぼ皆無です。

私の運がないのか、ヘボいだけなのかはわかりませんが、
比較的大きめなプロジェクトを順風満帆に、
或いは最後まで平和にやれてるところってあるのかしら。
(1、2人程度のプロジェクトなら、何件か平和にやらせてもらったけど。)


やっぱり、喫茶店開くしかないすね。
(しつこい)


( → 別バージョンがあった。)

| | Comments (4) | TrackBack (0)

March 19, 2007

コーヒーか紅玉石か

最近、Webシステムの設計やプログラムをやるようになって、
しょっちゅう思うことがあります。

それは、「一体、どの言語やフレームワークが良いんだ?」
ということ。

同じWebアプリを作るにしても、
それを「何で(どのアーキティクチャで)作るか」というとき、
言語やフレームワーク、そしてDBなども考慮に入れると、
これが選び切れないくらいうんとこさあるわけです。

言語なら、Java、C#、PHP、Ruby、perlなど。
フレームワークは、Struts、ASP.NETなど。
DBは、Oracle、PstgreSQL、MySQLなど。

あと、最近はO/Rマッピングのフレームワークや、
デバッグ、ロギング、AOPのフレームワーク、
その他いろいろな支援フレームワークが登場しています。
クライアントサイドのスクリプトなども考え出すと、
その組み合わせパターンは10や20じゃすみません。

まさに、フレーム問題。

私自身、ずっと制御系(非Web)のプログラマだったんだけど、
その時代は、こんなことあまり真面目に考えてませんでした。

とにかく、要求された機能が実現できれば良い。

そして、私が既に習熟している言語でそれが実現できるなら、
選択肢は1択か2択でした。

私は、C++とDelphi(Pascalもどき)を得意としていたので、
物理層に近い制御はC++(若しくはインラインのアセンブラ)で、
画面制御はDelphi(もしくはVB)で、というようなパターンで、
ずっと不自由はなかった。

DBMSも、商用ということになれば、
大抵はOracle、たまにSQLServerかSybaseという感じでしたかね。

Webも、基本的には「機能が実現できれば良い」と考えてましたが、
どうやらそういうわけでもないらしい。

制御系システムというのは、
大体5~10年程度の耐用年数を考えて設計されるので、
最初からガッチリした仕様を決める必要があります。
(これがまたなかなか決まらんのですが。。)

ところがですね、Webシステムというのは、
「仕様というのはしょっちゅう変わるものである!」
という前提で作られるようなのです。

ここがまずカルチャーショックでした。

まぁ、仕様がしょっちゅう変わるというのは、
制御系でもお客さん次第で多々あることではあったんですが、
それはあくまでイレギュラーケースとしての位置づけでした。
(散々泣かされましたが。)

Webアプリの場合、そのライフサイクルは長くて3年程度、
まぁ大体1年くらい周期でリニューアルというケースが多い。
しかも、細かい動作に関しては日々カスタマイズしたい、
というケースも少なくない。

そんなんどう対応するんだ?

というときに、
Webシステムのフレームワークが登場してくるわけですな。

もともとフレームワークというのは、
使用頻度の高い一連の処理を部品として用意しておいて、
それを使うことで高効率、高品質な開発、保守ができまっせ、
というものなんですが、
昨今、フレームワークというのは、動作設定の集まり、
というかお化けみたいなものになりつつあるある気がします。

つまり、条件や設定などはプログラムの外に出して、
プログラムの改変なしに動作を柔軟に(簡単に)変えられる、
というものにする方向なのでしょう。

Webの場合は、WebのHTMLデザインや細かい動作と、
そのバックで動作するプログラムをなるべく切り離す意図で、
いろいろ試行錯誤されたフレームワークが作られてるっぽい。

しかしね。

制御系でも、設定ファイルというものは存在します。
それはCSVだったり(Win)INI形式だったりするんですが、
これがまたいろいろ柔軟に変えたいという意向を汲み過ぎて、
やたら設定ファイルだらけになって、
さらにその設定ファイルの解釈や意味づけを設定するための
メタ的な設定ファイルまで出てきたりと、
非常に複雑怪奇なシステムを何度か扱ったことがあるんですわ。

今のJavaフレームワークなんかみてると、
フォーマットこそXML形式という今風な姿にはなっているけど、
流れ自体は、設定ファイルのモンスターになりつつある、
あの日の苦い思い出がありありと甦ってくるわけですよ。

Servletひとつ使うにも、
コンテキストの設定ファイルと、web.xmlを書かなければならない。
さらにStrutsを使うならstruts-config.xml、
log用にlog4j.xml、Hibernate用にhibernate.cfg.xml、
他にもAOPにSpring、独自のJSTLを使うならtaglibも、などなど、
こんなにあれこれと設定しなきゃならないなら、
さくっとプログラム1行変えた方がはやいよ?と思うことも。

実際、これは「もうJavaは終わってるよ」
といわれる大きな理由の1つのようで、
それらフレームワークを支える設定XMLの仕様もかなり複雑で、
素人がそれを把握するのはかなり時間がかかるはずです。

そこで、新たな候補生としてあげられるのが、
最近流行り(?)のRubyだったりするんですね。

結局、設定ファイルもプログラマが設定することになるなら、
最初から全部プログラムでもいいじゃん、
(よくいじる変数や定数はdefineやstaticで切っとけば良いし)
というのは、極端だけど正論ではあるのかも。

どうせWebアプリは、長くて3年、大体1年の使い捨てなんだから、
その程度のコストしかかけなくても良いものであるべきじゃないか。
となれば、RubyやPHPでいこうじゃないかと。

Javaなんかで重量級のシステムを組むより、
RubyやPHP、或いはperl(JSPやASPのみでも良い)あたりで、
ささっと書いて1人月程度のモノで十分。

まぁこうなってくると、昔のCGIに戻るイメージなんですがね。

でもまぁ、Java(ASP.NETもだけど)を使ったシステムは、
信頼性という意味では、
サーバスクリプティングのようなものよりも高いことは高い。

スクリプトだとセッションがプロセスとして動作するけど、
Javaや.NETなら基本的にWebサーバのスレッドで動作するので、
その分リソース消費も少ないし、速度もそれなりに速い。
Apache、Tomcatなんかは分散やクラスタリングにも対応してるし。

なので、1度に500とか1000とかアクセスがあるような場合は、
やっぱりJavaや.NETになるんでしょう。

要は、結局ケースバイケースってことか。

多分、1度に100アクセスもないようなシステムなら、
RubyやPHP、或いはperlなどで組むのが向くのかな。

動作をちょっと変えたければ、
設定ファイルをいじるよりもスクリプトを一部変えた方がはやい、
開発やメンテも少人数(1人とか2人とか)、
そういうのは、Javaは大仰過ぎでしょう。

例えば、言語はPHPで、フレームワークもなし、
DBもMySQLとかPostgreSQLあたりのフリーなやつでやる、
というのが安上がりで良い。

そして、同時アクセスが100を超えるとか、
処理能力やシステムとしての信頼性が求められる場合は、
やっぱりJavaや.NET C#などになるんだろうか。

DBは、コネクションプールやバッチ処理、XMLDBなど、
いろいろ強力なツールを使いたいなら、
やっぱりOracle、SQLServerあたりになるんでしょう。
余計なものはいらなくて普通にRDBで良いなら、
MySQLやPstgreSQLでも良いか。

ちなみに、mixiはperlとMySQLらしいですね。

mixiって、結構大規模なシステムの部類に入ると思うんだけど、
よくそれでやれてるなぁ、というのが正直な感想。

何かで聞いた話では、
ハードウェアを増やして分散させて対応しているということだったけど、
それにしても、あれだけのシステムが、
Javaはおろか、PHPでもRubyでもないというのが驚きです。

やっぱり、スクリプトは、プログラムを簡単に変えられる、
というのが最大のメリットだとは思うんですが。
処理能力的には、perlではちょっと不安が。。。

とにかく、当面私が関わっている今のシステム。

一度に500アクセス以上想定の大規模システムの予定なんだけど、
これ、まだつくる前なので、
JavaにするかPHPにするかなんてあたりも考える余地があるんです。

さて、どうしたもんかと。。

これもやっぱり、仕様は途中で簡単に変わるものだ、
という前提で設計せにゃならんのでしょうね。


(しかしなぁ、Web開発の経験1年にも満たない私に設計やらせるか?)

| | Comments (0) | TrackBack (0)

February 23, 2006

つくった方が早かった…

ソフトウェア開発なんてことをしていると、
そのソフトの動作状況を随時モニタしたいなぁ、という
要請が出てくるわけですが、
それがデバッグ環境でない場合にどうするかといえば、
ログで追うしかないわけです。

で、ログファイルを随時読み込んで表示してくれる、
そんなソフトが欲しくなってくる。

UNIXにはtailという機能があるんですが、
Windowsには、それと同等の機能はないわけで、
それでも必要だから、
そういうツールがフリーでいくつか公開されてますね。

でね。

2、3そういうのを使ってみたんだけど、
どうも、どれも重いんですよね。

ログファイルのサイズが500KBとかなってるのも、
まぁ異常なんですがね…(笑)

軽く動くツールがなかなかなくて、
それならば、と、自分で作っちゃた

ここまでログが巨大になると、
実際に見たい情報が埋もれてしまうこともあって、
キーワード強調と、
いらないキーワードを非表示にする機能までつけちゃいました。


こういうソフトで他に良いやつ、
知ってたら教えていただきたいところです。


ま、最近は、必要なツールは、
実は自作したほうが早いかもしれませんな。
(最近のIDE環境は、結構そういうのがサックリつくれちゃうしね。)

| | Comments (0) | TrackBack (0)

May 12, 2005

プログラム言語に関するメモ

会社を辞めないと決まって、新しい仕事をふられたわけですが、
どの言語でやるか?から検討することに。

ちょっと私的感覚をメモっておく。
(決定理由を説明するときの覚書ってことで)

GUIのあるWindowsアプリケーションということで、
現状考えられる選択肢はこんなものか。

・C++(MFC)
・Managed C++(.NET Framework)
・C#(.NET Framework)
・VB.NET
・Delphi6/7
・Delphi2005(.NET Framework)

○C++(MFC, Win32)
制御系の処理では最も標準的で高速。
GUIの作成に難有り(工数面で)。
技術資料は豊富。

既存コードの流用を考えると、この選択肢が最も適かと思うけど、
既存コードの流用は今回あまり考えていないので、
もっと開発効率の良い他言語を選択する方が良いかも。

○Managed C++(.NET Framework)
結局ILなので、純粋なC++よりは低速。
.NETでC++が使用できる。
C++コードを流用しやすい。

C++の拡張と言われているけど、
実際は、.NETで使えるような文法にコンバートされた言語、
という印象がある。
C++でできていたことが、Managed C++ではできないことも多々。
あと、.NETとC++両者の制約を受けて非常に構造が複雑怪奇。
既存コードの流用を考えないなら、選択肢から除外すべき。

○C#(.NET Framework)
CLR開発に最適(.NET専用言語)。
ILなので、C++より低速。
GUIはつくりやすい。

もう最近は、Windowsアプリをつくるならこれが良いように思う。
最初から.NET用につくられた言語なので、
その考え方や文法もわかりやすく、解説書も多い。
ただ、ILであるので低速なのは否めない。
(ネイティブコンパイルする手もあるが)

○VB.NET
GUIはつくりやすい…が、それだけ。

.NETを使うなら、C#の方がわかりやすく使いやすい。
VBと名がついているが、
VB6.0までの考え方は基本的に踏襲されていない。
(予約語や単語レベルではVBなのだが)
今回の選択肢としては、多分あり得ない。

○Delphi6/7
Win32アプリケーションなら、開発効率、実行速度を、
共に高いレベルで実現できる。
私が個人的に、Delphiは使い慣れている。

もうこれは個人の好み。
多分これを使えば、今回のシステムなんて1ヶ月で作れる。
(仕様さえ凍結すれば)
しかし、世間が許さないと思われる…。
もうちょっとBolandがメジャーになってくれたらなぁ。

○Delphi2005
.NET対応したDelphi、らしい(使ったことはない)。

これを使うくらいならC#なのかもしれない。
VB.NETと同じ理屈で。
ただ、個人的に使ってみたい!?


好みでいえば、C++かDelphiが良いのだけど、
C++だとGUI作成で工数がかなりとられると予想されるし、
Delphiは、お上さまが許してくれないと予想(政治的な話)。

C#かなぁ、という感じ。

| | Comments (0) | TrackBack (0)

November 02, 2004

Visual Studio .NETめぇ

何なんだ、この開発環境は!

いや、確かに.NET Frameworkのアーキティクチャは素晴らしいですよ。
オブジェクト指向真っ盛りって感じで。
Javaのパクリだろってツッコミおいとけば、
その使い勝手もかなりイケてると思いますよ。
MSにしちゃあ良いモノつくったなと、認めようかと思ったところで…

 Visual Studio最悪じゃ!

デバッガがデバッグしてると固まる!

しかもOSごと!!

根気よく10分くらい待てば戻ってきますがね…
いっぺん固まると、後は1ステップ進める度に固まるんですよ?

誰が1ステップにいちいち10分も待てますか!!!

電源ブチっと落としたさ。もうっ。

だからDelphiがいいんですよ。
同じ.NET環境でも、多分Delphiの方がイケてますよ。いや絶対!(変な自信)
MSは、どこかに致命的なオチがあるんだよね。いつも。

今は仕事だから仕方なく使ってるけど、
プライベートでは絶対Visual Studioなんか使わないぞ。
少なくとも、このデバッガフリーズが改修されるまでは。

あー今日はもう帰ろ。
かなりブチ切れモード… (`へ´)-3

| | Comments (2) | TrackBack (0)

October 05, 2004

コンパイルエラー?

なめられてるとしか思えん…。

| | Comments (0) | TrackBack (0)

July 30, 2004

でりげー

LNK4210警告が出るのが気になっている月影です。
こんばんは。

今日も.NETとの格闘に終始しちまいました。

本日の議題。
スレッドのコールバックはスタティック関数でないとダメなのか?
これ、私としてもヒジョーに気持ち悪いのでして。
クラスメンバのクセに、自クラスのオブジェクトを直接参照できないって。

つまり。。。

class clsSample
{
public:
 int iData;
private:
 static void ThreadProc();
};

なんてクラスがあったら、ThreadProc()メソッドの中から、
iDataは直接見えないわけですよ。
でも、スレッド立てるときに渡す関数はスタティックでないとダメなわけです。

ここらへんはMSさんも気持ち悪がったみたいで、
.NETでは、デリゲートなるものを生み出したらしい。

デリートではありません。デリート。
ゲですゲ。ゲゲゲのゲ~。

すみません。

delegate と書きます。

__delegate void Func();

と宣言してやって、

Func *fnc= new Func(this, clsSample::ThreadProc)

としてしまえば、ThreadProcはスタティックにしなくて良いと。
で、このfncは、そのままスレッドのコールバックとして渡せるわけです。

Thread *thd = new Thread(fnc);

こうして何となく使い方を覚えてしまうと、
もっといいように使えないものかと、
これが配列にならないかな~なんて考えたりしたわけですが。

こういうコールバックはマトリクス管理にも使えそうなんですが、
関数の数が数だけに配列で管理したいわけですよ。
2次元くらいの。

で、今日は一日そればっかしやってました…。


結局ムリくさ。

そういやガベージコレクションでは、
ダブルポインタ以上は使えないんだったっけなぁ…。

と、覚書き。

はぁ…。
大丈夫か。明らかに見積もりをオーバーしてます。この工数。

今年は夏休みはくるのか?私。

| | Comments (1) | TrackBack (0)