Wikipediaでも、殴り合うボクシングの語源も箱なんですってね。幸福にはなかなか気づくことが出来ないのは、その方がより生き抜きやすいからだろうか。昼飯を食べながら何気なくネットを徘徊してたらこんなブログ記事をみつけました。トラバ張ろうと思ったけどURLが公開されてなかった。「ググレカス」な世の中だと思ってたんだけど、そういうもんでもないのか。ある程度の開発経験があり、ノウハウや知識もある人にはGoogle先生はとても重宝するツールではあるんだけど、いわれてみれば、新人にはあまりよくないのかな。私が新人時代というと、1998年当時。Webは黎明期といった時期で、当時のWeb検索といえば日本語だと、有名なのはYahoo!とgooくらいだったかな。その頃のYahoo!は登録型であまり有用なサイトはなく、gooはロボット型だったけど、キーワードにひっかかるだけ何でもかんでも手当たり次第ヒットしてたので、その中から使えるサイトを探すのもまた一苦労でした。実は、Google先生が生まれたのは丁度この頃。その頃の調べ物といえば、Webより本でしたね。会社にもプログラム言語の参考書やInside何たらという分厚い技術系の本が何冊もあり、さすがに版は古いけど大体調べ物の用はそれで足りました。足りないときは自分で買ってたしね。わからないことは聞く、という文化が常識的かどうかは会社の風土にもよりますね。先輩が分かりやすく教えてくれればベストなんだけど、そんな先輩がいない、先輩も知らない、先輩がコワイ!教え方が要領を得なくて、自分で何とかした方が良い!というような環境も、中にはあろうかと思います。聞けばいろいろ教えてくれました。参考書も示してくれましたね。今にして思えば良い先輩でした。その先輩の先輩(まぁ私にとっても大先輩)がかなりあたりがキツい人で、その人自身はよくできる技術者として社内でも認められてたんだけど、こと後輩へのあたりとなると、そんなことも知らないの?常識だよ?何勉強してきたの?的な言動をふりまくお人。毎日のように「しごかれて」いました。おかげで、知識はいろいろ身についたようですけどね。教育という意味では悪いことばかりじゃないけど、ただ、彼女の下についた人は、かなりの高確率で会社を辞めていってたのも事実でした。教育というか、後輩に対して特別に何かを教えるということは、あんまりした覚えが無いですね。教える、というよりは、一緒に仕事をする、という感じ。違うと思うコードを書いてたらこれはこうした方がいいんじゃない?という程度かな。私が今も社員で新人を迎えていたら「ググればいろいろ出てくるよ」っていっちゃうな。実際、プログラムひとつとっても昔と今の常識ではいろいろ違う部分もありますからね。少ないリソースの中でポインタを駆使して処理もバイナリのサイズ自体もコンパクトなのが良!とされてた気がするんだけど、最近は違う。それよりも、メンテナンス性の方が重視されて効率よりも可読性の高いコードの方が好まれる。多少は効率が悪くても、それが致命的でなければ読みやすいコードの方が良!となってきてる感。難しい処理はフレームワークが大方やってくれてたり、なので、今はそういう用意されたフレームワークやライブラリをいかに上手く使うかの方が流行りのソリューションということになってる。自分でつくる前に、既にあるものを探せ、なんですよね。いう意味で、開発の場面でもWeb検索というのは非常に有用なツールだと思う。昨今のWeb検索は非常に高性能で、探し方次第ですが回答を見つけるまでの時間を大幅に短縮してくれる。それこそ、私の新人時代、分厚い本で目次を探してページをめくって該当の解説なりコードなりにあたるということを考えるとね。他にもっと適したやり方はないか、ということは自分で考えるなり、或いは聞く相手がいれば聞くなりする必要はあるでしょう。件のブログ主さんは私なぞよりもはるかにキャリアのおありな方のようでおっしゃることも概ねその通りだとは思いますが、わからないなら私に聞け、という態度もどうなのかしら。いや、聞くな!というよりは良いですけど。新人くんが何か調べてることに気づいていて、それを自分なら教えてあげられるとわかっているなら教えてあげればいいのに、と思ったり。自発的に質問させることが重要ということ、か。実際のところ、Web検索ということに依らずとも最近の.NETにしろJavaにしろその他の環境にしろあんまり勉強しなくても、誰でもそこそこ使えてしまうということ自体が今の状況に至ってる要因な気がする。調べればそこそこ動くコードが意外と簡単に書けてしまう。簡単に使えることは、悪いことじゃないですよね。結局、ハサミも包丁も使う人次第。トラックバック(0)政治や選挙の話ばっかりじゃ面白くないですね。ネタの為に、軽くmixiアプリなるものをつくってみました。今日のカルマふつうのWebアプリとかFlashとかと何が違うのかと思ったけど要は、SNSの特性を利用できるWebアプリ、ってことですかね。それの利用シーンがまだいまいち。これは、アプリの利用者よりもアプリ開発者の為の便宜であるという意味合いが強いかな。昨今はmixi以外にもいろんなSNSが乱立しまくっていてそれに対応したWebアプリの為のAPIがバラバラではアプリをつくる側はいちいちそれら個別のAPIを覚えてから開発にかからにゃならなくなる。そこで、天下のGoogle様が、その共通APIを目論んで「OpenSocial」なるものをこしらえなさったのですな。その(1つの)フレームワークさえマスターしておけば、それを利用して機能提供してる幾多のSNSにおいて同じようにアプリがつくれるんだ、というお話。それを今回、mixiも採用しましたよと。その開発者ではないユーザ向けにも結構大きく宣伝をうってる(ようにみえるんだけど)その意図がよくわからん。簡単なんで、あなたもつくってみてよ、といってるのかな。つくるには、まず自分のWebサーバが必要だしJavaScriptの知識も多少は必要。(本当に使えるものをつくるなら多少じゃダメだけど)あれかな。今後はいろんな開発者が標準的なアプリをつくってmixiにも提供してくれるようになる(はず、な)ので、そのアプリを使ってより一層楽しめるようになりまっせってことかな。標準機能だけ使うものなら、確かに簡単に実装できます。何もわざわざ新たなアプリをつくらなくても、mixiで標準で提供されてる機能を使えば十分。それ以上の情報はAPIでも取得できない。それをさらに使えるものにするのは、きっと外部サイトとの連携ってことになるんでしょう。今回私がつくったアプリは、スラドのユーザページに表示される「カルマ」みたいなやつで、そのユーザを別の何か(出鱈目な言葉)で表現するようなただそれだけのお遊びアプリです。(「カルマ」というと、「業」とか「前世」とかの意味ですけどね)中身で何をやっているかというと、まず最初に「〇〇さんのカルマ」という文句を出すためにユーザ情報からユーザの名前を取得して表示して、その後ランダムに登録されている形容詞から1つ選んで、さらにランダムに辞書サイトを選らんで名詞を取得して、それらを連結して1フレーズにして表示、とやっている。この、登録されてる名前をとるところがSNS内部情報で、ランダムに言葉を探してくるところが外部サイトとの連携(言葉の検索と連結は外部スクリプト(PHP)でやってる)ということになってると。そのSNS内部情報は簡単にとれて良いんだけど、やっぱり外部サイトの情報をとってきたりというのはふつうにGETやPOSTで要求を出して、その応答(JSONやDOM等)を解析する形なんすね。それ以外にやりようがないか。結局その外部サイト側でいかに凝ったことをやるかという方が勝負になってくるんじゃないかと。キモはAPIの共通化なんだ、ということならこういう形でスタンダードを目指すというのもアリといえばアリなのかもしれませんね。あと、そういうアプリを、外部サイトだけでなくSNS内で使ったり表示したりできるよ、ということか。ちなみに、共通APIというだけに、これはmixi以外の(OpenSocialを採用している)SNSやGoogleガジェットも同様につくれますね。コードにmixiに依存した部分がなければそのまま他に転用も可能な模様。これはこれで、ひとつの大きな利用価値かもね。トラックバック(0)これはもう結構(我々の業界では)有名な風刺画。わかっていても失敗するのは何故か。結局これは一番初っ端の要件定義がコケているから、というところに落ち着くんじゃないだろうかと。開発側はとにかく要求された機能を実現することを考えるから、ユーザの説いたそのシステムが必要な背景が御座なりになる。要は、そのシステムが実際にどういう使われ方をするものなのか、ということの考慮が、結構設計から抜け落ちていたりするのね。実際に動くモノができてみたところで、ユーザから文句や仕変の嵐を食らうことになると。その最初の(要件定義段階の)合意というのは、そう上手いことまとまることはないんですよね。「んー、多分こういうことなんだろうなぁ?[E:despair]」で進んでいくことがほとんど。最初は実際に動くシステムがない(当然)わけだから、お互いに「絵に描いた餅」の話をしてることになる。これはWebシステムにいえることだと思うんだけど、ユーザは機能よりも結構見た目の方を気にする、ということ。見た目がどうとかいうあたりを実はあまり意識していない。ユーザとしては、機能は結局裏方でしかなく見た目に目立つところをかなり指摘してくる。機能は満たしていて当たり前というところなんでしょうけどね。制御系やってるときはそんなことはあまりなかったんですが、やっぱりWebは基本的に見せるもの、だからなんでしょうね。最近はJSやAjaxでいろんなことができるようになったせいで、お客さんからも、Web上で何でもできるんじゃないの?とか思われていて、GUIも単純なフォームじゃなく、WordやExcelみたいなモノを軽く求められたりする。́・ω・`)みたいな。こんなんがエエゆうてたんやないんかいっ!まぁ、人の欲するところをバッチリ理解できるような能力があれば、それこそマーケティングの神様にでもなれますわね。いうことができるなら、もっと世の中上手く渡ってます。この業界って無理を通してるところがあるのかもね。上手くいくということはないのなら、プロジェクトをいかにデスマに導かないかがPLやPMの手腕なのか。私もこの業界10年近くになるけど、メンバ10人以上の規模のプロジェクトで、万事うまくいったZE!という経験はほぼ皆無です。最後まで平和にやれてるところってあるのかしら。(1、2人程度のプロジェクトなら、何件か平和にやらせてもらったけど。)やっぱり、喫茶店開くしかないすね。別バージョンがあった。トラックバック(0)最近、Webシステムの設計やプログラムをやるようになって、しょっちゅう思うことがあります。それは、「一体、どの言語やフレームワークが良いんだ?」ということ。言語やフレームワーク、そしてDBなども考慮に入れると、これが選び切れないくらいうんとこさあるわけです。言語なら、Java、C#、PHP、Ruby、perlなど。フレームワークは、Struts、ASP.NETなど。DBは、Oracle、PstgreSQL、MySQLなど。あと、最近はO/Rマッピングのフレームワークや、デバッグ、ロギング、AOPのフレームワーク、その他いろいろな支援フレームワークが登場しています。クライアントサイドのスクリプトなども考え出すと、その組み合わせパターンは10や20じゃすみません。私自身、ずっと制御系(非Web)のプログラマだったんだけど、その時代は、こんなことあまり真面目に考えてませんでした。要求された機能が実現できれば良い。選択肢は1択か2択でした。画面制御はDelphi(もしくはVB)で、というようなパターンで、ずっと不自由はなかった。Oracle、たまにSQLServerかSybaseという感じでしたかね。Webも、基本的には「機能が実現できれば良い」と考えてましたが、どうやらそういうわけでもないらしい。最初からガッチリした仕様を決める必要があります。(これがまたなかなか決まらんのですが。「仕様というのはしょっちゅう変わるものである!」という前提で作られるようなのです。ここがまずカルチャーショックでした。制御系でもお客さん次第で多々あることではあったんですが、それはあくまでイレギュラーケースとしての位置づけでした。(散々泣かされましたが。)Webアプリの場合、そのライフサイクルは長くて3年程度、まぁ大体1年くらい周期でリニューアルというケースが多い。細かい動作に関しては日々カスタマイズしたい、というケースも少なくない。そんなんどう対応するんだ?というときに、Webシステムのフレームワークが登場してくるわけですな。昨今、フレームワークというのは、動作設定の集まり、というかお化けみたいなものになりつつあるある気がします。条件や設定などはプログラムの外に出して、プログラムの改変なしに動作を柔軟に(簡単に)変えられる、というものにする方向なのでしょう。Webの場合は、WebのHTMLデザインや細かい動作と、そのバックで動作するプログラムをなるべく切り離す意図で、いろいろ試行錯誤されたフレームワークが作られてるっぽい。制御系でも、設定ファイルというものは存在します。非常に複雑怪奇なシステムを何度か扱ったことがあるんですわ。流れ自体は、設定ファイルのモンスターになりつつある、あの日の苦い思い出がありありと甦ってくるわけですよ。Servletひとつ使うにも、コンテキストの設定ファイルと、web.xmlを書かなければならない。他にもAOPにSpring、独自のJSTLを使うならtaglibも、などなど、こんなにあれこれと設定しなきゃならないなら、さくっとプログラム1行変えた方がはやいよ?と思うことも。素人がそれを把握するのはかなり時間がかかるはずです。最近流行り(?)のRubyだったりするんですね。最初から全部プログラムでもいいじゃん、(よくいじる変数や定数はdefineやstaticで切っとけば良いし)というのは、極端だけど正論ではあるのかも。Webアプリは、長くて3年、大体1年の使い捨てなんだから、その程度のコストしかかけなくても良いものであるべきじゃないか。なれば、RubyやPHPでいこうじゃないかと。Javaなんかで重量級のシステムを組むより、RubyやPHP、或いはperl(JSPやASPのみでも良い)あたりで、ささっと書いて1人月程度のモノで十分。なってくると、昔のCGIに戻るイメージなんですがね。信頼性という意味では、サーバスクリプティングのようなものよりも高いことは高い。スクリプトだとセッションがプロセスとして動作するけど、Javaや.NETなら基本的にWebサーバのスレッドで動作するので、その分リソース消費も少ないし、速度もそれなりに速い。Apache、Tomcatなんかは分散やクラスタリングにも対応してるし。1度に500とか1000とかアクセスがあるような場合は、やっぱりJavaや.NETになるんでしょう。要は、結局ケースバイケースってことか。1度に100アクセスもないようなシステムなら、RubyやPHP、或いはperlなどで組むのが向くのかな。開発やメンテも少人数(1人とか2人とか)、そういうのは、Javaは大仰過ぎでしょう。言語はPHPで、フレームワークもなし、DBもMySQLとかPostgreSQLあたりのフリーなやつでやる、というのが安上がりで良い。C#などになるんだろうか。DBは、コネクションプールやバッチ処理、XMLDBなど、いろいろ強力なツールを使いたいなら、やっぱりOracle、SQLServerあたりになるんでしょう。余計なものはいらなくて普通にRDBで良いなら、MySQLやPstgreSQLでも良いか。ちなみに、mixiはperlとMySQLらしいですね。mixiって、結構大規模なシステムの部類に入ると思うんだけど、よくそれでやれてるなぁ、というのが正直な感想。何かで聞いた話では、ハードウェアを増やして分散させて対応しているということだったけど、それにしても、あれだけのシステムが、Javaはおろか、PHPでもRubyでもないというのが驚きです。スクリプトは、プログラムを簡単に変えられる、というのが最大のメリットだとは思うんですが。処理能力的には、perlではちょっと不安が。私が関わっている今のシステム。一度に500アクセス以上想定の大規模システムの予定なんだけど、これ、まだつくる前なので、JavaにするかPHPにするかなんてあたりも考える余地があるんです。これもやっぱり、仕様は途中で簡単に変わるものだ、という前提で設計せにゃならんのでしょうね。