トップ «前の日(05-22) 最新 次の日(05-24)» 追記

2003-05-23

_ Opera 6.02 for Mac

いろいろあります Opera ですが、どうやら Mac 版は結局出たようです。OS X で beta を試したときにはそのあまりの重さにめまいがしたものですが、そういえば Classic では試してみませんでした。8.6 から対応ということで、Mozilla, Netscape 7 の重量ブラウザか iCab, Netscape 4 などの先端技術についてこれないブラウザしかない Classic 環境では救世主になって、、、くれないかな?

Tags: Web Tool Apple

2004-05-23

_ CCD vs CMOS

キーワードは

  • 消費電力
  • 処理速度
  • ノイズ(画質)
  • 製造コスト

ですか。画質さえ向上すれば CMOS の方がメリットは大きそうですな。超広域ダイナミックレンジ CMOS とかすでにあるしね。EOS-1 のデジタル版は EOS-1D markII(CCD版)と EOS-1Ds(CMOS版)がある。ということはプロユースでも CMOS が十分に使いものになるという自信があるんだろう。

これらの発売はこの春なので、今後は徐々に高画質版コンパクト CMOS デジカメっつーのが出てくると見てよいかもしんない。

参考

_ モデ意思なしに@/.-j

メタモデしか回ってこないし、知らない分野の話が多いので。

最近は比較的プラスモデが増えているような気がするけど、どうだろう。 そろそろ閾値を元に戻そうかな。

Tags: Community Web

2005-05-23

_ XP vs ソフトウェア工学的な構図になっちゃってる話。

自分の中では「説得スキル再び」な話。

えーと。naoya さんはどこでソフトウェア工学を否定したんでしょうか? 否定したのはウォーターフォールモデルではないのですか? naoya さん自身の言葉でソフトウェア工学について書いているのはこれだけでしょ。

もうひとつ僕が引け目を感じていた原因として、ソフトウェア工学というものを学んだことがないというのもありました。僕は大学で物理を専攻していたこともあって、いわゆるソフトウェア開発の方法論やアルゴリズムといったものをまともに勉強したことがありません。

ソフトウェア工学を学んだことがないことを引け目に感じているだけ。否定的なことを書いているのはここか。

しかし、独創的なソフトウェアを"創りながら創る"という方法においては静的型付けの言語よりも動的型付けの言語の方が有利だと思うし、スーツを着て設計書を書いてからものを作るなんて作業は、今の僕には耐え難い作業です。もう後戻りはできなそうです。

言語の話が一つ、開発体制の話が一つ。ソフトウェア工学そのものはやっぱり出てこない。

ソフトウェア工学そのものは分からなくてもボトムアップ(あえてことの言葉を使いましょう)で XP にたどり着いた、ということですな。

これに対して orionae さんがいやいやソフトウェア工学は大事なんだよと言うのは別に問題ないと思うし、まぁ実際 naoya さんはソフトウェア工学そのものを大事にしているわけじゃーないでしょうな。ないがしろにしているのではないかという指摘は正しいと思います。でも反論のための例の出し方がまるで「XP では欠陥住宅ができますよ」みたいに読めちゃうんだな。この辺とか。

もしある人が「自分は薬品を混ぜていろんな物質を作るのを愛してるんです。

いろんなアイデアがわいてきて、そうやって作ったこの薬はこの症状にはすごく効くんですよ。」って言って提供する薬を、それを作った人が一切薬学や分子工学の知識が無いとわかっていて、あなたは人に薦められますか??

また、ある人が「自分は日曜大工が好きで、どんな家でも作れるんだ。いろいろアイデアが浮かんでさ。こんど10階建てのホテルを自分で作ったんだけど、泊まりに来る?建築工学?構造力学?そんなの好きじゃないからぜんぜん知らないや。」

あなたはそのホテルを責任を持って沢山の人に紹介できますか?

極端なようですが、上記ブログでnaoyaさんが述べられているのは、まさに同じことです。

そして

なぜ設計が必要か。なぜドキュメントが必要か。なぜ静的型付けが必要か。

あれ。ソフトウェア工学の必要性の話が設計、ドキュメント、静的型付け言語の必要性の話にすり替わろうとしている。

ところで。

ソフトウェア工学を押さえておかないとなぜ XP の手法が有効なのかは説明できない。そりゃそうだ。でも現場で生き残るのは理論じゃなくて手法だっていうのも自明じゃないですかね。*1理論ではソフトウェアは生まれないのだから、ソフトウェア工学の必要性を解くためには論破ではなく、アジャイルの手法を選択した経緯をソフトウェア工学の豊富な知識を以て補完して説明してあげる方が有効なんじゃなかろうか。つまり、あなたが否定したつもりのソフトウェア工学で以てあなたの選択を説明することができる、という釈迦の掌論法だ。(くどいようだけど、naoya さんは明確にソフトウェア工学の否定はしてないはず。)

もう一つの方法は、あなた方の知見をみんなで共有するためにソフトウェア工学が役に立つ、というアプローチかな。つまり、「はてなメソッドの確立」のために工学的手法が使えますよ、という話。これはソフトウェア工学の人(って誰)にも Web アプリを開発している他の人たちにも嬉しい話になると思う。はてな内部の人がどれだけ嬉しいかはちょっと分からないけど。

ところで今回あちこち見て気に入ったのはこれ。

ソフトウェア工学について思うこと

まぁ要するにソフトウェア工学について、古くて、今ではそんなに重視されていない話の方が有名になっちゃってるんじゃないかなーと勝手に解釈したんだけど、考えてみたらいわゆる「学」のつくものって多かれ少なかれこの手の問題を抱えているんだよな。みんな学校で習った段階でその分野の情報が固定されて、自分の中で常識化してしまうから。

えーと。

オチがねーな。まいっか。

Tags: ことば

*1 だからこそ ジョエルテスト なんかも大事になってくるんだと思う。

_ ポスドク話。

ドクター取得後の就職にはどんな支援が必要? (/.-j)

結局、どの組織、どの分野でもダメな人がいて、出来る人がいて、ダメな上司、ダメな部下に悩む人が居て、隣の芝生が青くしか見えない人も居る一方で、どうしても自分より下の人間を見つけてこき下ろしたい人が居ると。

まぁいつものスラドのパターンだなと思った次第。ポスト不足なんてどこにでもある話さ。*1

勝手な妄想を並べておくと、年齢、学歴、実績を「順番に積み上げて行く」っていう以外のルートがもっと認知されるべきじゃないかなと思う。キャリアを活かして新天地ってことじゃなくて、いつでも学び直せるしやり直せる世界。まぁ寝言と思われるかもしれないけど、そんなにとんでもない話じゃあないと思うんだよな。

学問の世界は企業に就職したら遠のくのか? 逆に学問を究めようとしている人間は企業社会で通用しないのか? どちらも極端な話だと思う。(それっぽい傾向があることまで否定はしないけどさ。)キャリアパスって言葉があるけど、学問の世界にも企業社会にも、つーかもっと広い意味においても、パスは本来何本も描けるはず。それを狭めているのはスキルや制度だけじゃなくて、自分と周囲の世間体や常識でもある。*2

と、具体的な支援策を書かずに逃げるのであった。だってさぁ、今日やって明日効果が出るような対症療法で解決するとは思えないし。だったら価値観とか、そんなすぐにはどうにもならない話を持ち出してもいいかなーなんて。

Tags: Edu Biz

*1 同じように人手不足もどこにでもあるんだよな。

*2 まぁ学問の世界では起業に相当するパスもないし、いくぶん狭いのはしょうがないけどさ。


2006-05-23

_ prototype.js が MacIE でコンパイルエラー

うーん。一部機能が利用できませんとか言うならいいんだけど、コンパイルエラーじゃ対処のしようがない。

ちょっとの修正で動くという話もあるんだけど、具体的な方法が分からないorz

MochiKit も試してみたけどやっぱダメ。コンパイルエラーっつーのは困るなぁ。はてなとかどうやって対処してんだろ。とりあえずこれも急ぎじゃないので置いとく。

試しに iCab 3 beta を動かしてみたら Classic 版でも OSX 版でもコンパイルエラーは起きない。XMLHttpRequest には対応してないっぽいけど、DOM の操作とかは普通にできた。ただし CSS の解釈にあやしいところがまだある感じ。上のカレンダーのポップアップのポジショニングは明らかにおかしい。しかし Classic版より OSX版の方がバシバシ落ちるっつーのはどうかなぁ…。

Classic をあえて選ぶ人はもうみんな IE 捨ててiCab に乗り換えてくれって言った方がいいのか? まぁ恐らく通用しないんだろうけど、でもあれだ。正直、なんか懐かしくてかわいいらしい感じはするね。

本日のツッコミ(全1件) [ツッコミを入れる]

_ TrackBack [http://aligach.net/diary/20060606.html あーありがち [Ecmascrip..]


2007-05-23

_ PHP を取り巻く人々の思惑の変化とかギャップとか

祭りも収まってきたことだし、その間に読んだり書いたりしたことをもう一度思い返してみる。

自分が書いたものは主に Dan の中の人の発想に同調して「ハッカーが使いたくなる言語か否か」、「『使える』かどうか」だったんだけど、その方向で気になったポイントとしては、

PHP を PHP で拡張できないことに異論を唱える人はほとんどいない

という点。「そこは割り切って使うのが PHP 使い」というのが大勢だったかなと思う。

あとは

  1. 関数ばっかいっぱいあって邪魔くさい
  2. そんなのリファレンス見ればいいじゃん
  3. 名前空間がなくて扱いにくい、一個一個の名前が長くてダサイ

というフラットで巨大な関数群の話。

個人的にはリファレンスとか IDE の補完があればオッケーという話ではないと思うな、これは。予約語もけっこう多いし、そういう意味でも扱いにくいと思う。

たぶん PHP モジュールを作る人が増えてこないのはこの辺も関係してるんじゃないかなぁ。例えば面白いツールがあっても PHP のバインディングだけない、っていうケースは少なくない。PHP 以外を知らない人はこの事実、気づいてないのかな。

それと

  1. Web に特化しちゃってて他のバックエンドツールとか書きにくいじゃん
  2. Web に特化しているからこそ目的を素早く達成できるんじゃないか
  3. Web に特化していることを肯定したうえで、であればもっと素人でもセキュリティを確保しやすい仕組み、あるいはサンプルを提供してくれたらもっといいのに

という特化話。特化していることの善し悪しは要するに目的によって変わってくるのでそこら辺は置いとくとして、自分が気になったのは

本当に特化して楽ちん簡単なのか?

という辺りかしら。

以降はとてもなんとなくな思いつきをダラダラ書くだけなのであまり気にしないでほしいんだけど、ここ数年の PHP 開発の流れって、基本的に大型開発に耐えられるツールを指向していると思うのね。

PHP が Perl で書かれたツールだった頃の話は知らないんだけど、その後の PHP は Perl っぽさというよりは素朴でポインタのない C のような雰囲気を身にまとって C 系のプログラマが移行しやすくなり、その後オブジェクト指向風の機能を追加し、5 ではますます Java 風の機構を取り入れてくる、というのが大まかな流れなわけです。そして今いちばんアツイのは PHP そのものではなく PHP 上に乗っかるライブラリと PHP を利用した Web 開発を支援する環境である、と。つーことは他の言語の流れと基本的にはおんなじところに向かっているように見えるんだな。乱暴に言うとオブジェクト指向を取り入れてライブラリを整理しましょう、という流れ。

もちろん主戦場が Web であるというところは疑う余地はないと思うんだけど、PHP そのものの開発をするうえで Web に特化するということを第一としているのかというと、そうでもないような。というかその辺の機能はすでに実装済みというか*1。で、最近特に問題になることが多いセキュリティ周りは、言語そのもので対応するよりライブラリ、フレームワークで対応する方が効率がいいと判断しているような感じがする。(もちろんクラッシュする類いのものは PHP では対処不能なのでそこは直すけど。)

一方でバージョン 3 の頃のような牧歌的なノリで PHP は導入も簡単で学習コストも低く、初心者にオススメです、という人たちも居て、そういう人たちは残念ながら Web プログラミング特有の難しさにはあまり頓着がなかったりしているように見える。

PHP にいっちょかみする人って、PHP 好き派ときらい派に分かれるのは当然として、PHP は初心者にも簡単でいいよ派と、PHP を大型案件もこなせるツールにしたい派にも分断しちゃってるような、そんな風に見えるんだなぁ。

自分としては「(生の)PHP は Web に特化しているし、簡単でいいんです」、というのは安全なネットワークの中で閉じたツールを作る分には当てはまるけれど、インターネットという危険な大海原では当てはまらないと思うんだな。それでも PHP を薦めるのは

初心者に対してではなくプロの共通語として

なら理解できるかなーと思う。これは PHP くらい使えなきゃダメよと言っているんではなくて、恐らくプロは PHP で書かれたサンプルを読める程度になら半日もあれば到達できるだろう、という感じの意味ね。巨大なライブラリを読みこなせるとか自由に書けるとかいうことではないです。例えば XSS や CSRF 対策の基本はこんな感じです、みたいなサンプルを提示する際に PHP はそれなりに使いやすいんじゃないかな、くらいの意味。もう一つは求人の多さかな。求人の話はニワトリタマゴだけど。

Tags: PHP

*1 例えば cli でも cgi でも mod_php でも fastcgi でも、他のフレームワークなどの助けを借りずに基本的に同じコードが動くのは結構すごいと思う。


2008-05-23

_ 最近見かけた割とまともなWeb制作入門系の本

故あって本屋でWeb制作の入門向けの本を探していて、実際に手に取って確認した中でまともなものをちょっと紹介してみますよ。

全般

ウェブの仕事力が上がる標準ガイドブック2 Webデザイン(益子 貴寛/佐藤 伸哉/浅野 紀予/矢野 りん/植木 真/原 一浩/松村 慎/中村 享介/境 祐司/長谷川 恭久) は数少ない網羅的な本。画像形式とその特徴の違いなど、本来触れていて当然の内容がちゃんと入っている。HTML だけとか HTML + CSS だけとかを扱う本は多い*1が、それだけでは当然 Web の作り手としての知識には十分でない。なのにこういう本が少ないのはとても不思議。ズブの素人の人はいったいそういう大事な知識をどこから得ているの? 学校で教えてくれるの? そんなわけないよね?

じゃあ逆になんでこの本はこんなにしっかりしているんだろうと思ったらそれもそのはず、これは「Web検」の教科書的な位置付けの本なのだ。「Web検」てそう言えば聞いたことあるなーと思ってはいたけど、今サイトを見ると一応試験は始まっているみたい。システム寄りの方はまださっぱり内容もないけど。

社団法人 全日本能率連盟登録資格「Web検定(ウェブケン)」 - Webに関わるすべての人の標準知識

正直Web検には別に何も期待していなかったんだけど、まともに使える本が出るだけでもかなり大きな意味があるような気になった。自分が徐々に、断続的に手に入れてきた知識をまとめて相手に伝えることは難しい。そのまとめの作業をそれなりに肩代わりしてくれる本の存在はとてもありがたい。

制作/デザイン寄り

HTML を組むには以下のような感じですか。

世の中の HTML の解説には、かなりひどい間違いを含むものが大量に出回っていることは皆さんご承知の通り。その一つ一つについてちゃんと検証したわけではないので、ぶっちゃけこの本がそんなに「正しい」かどうかは分からない。基本的には「姿勢」で選んだ。

  • 下手に漫画調にしてごまかしていないこと
  • それでいて図が豊富で分かりやすい
  • スクリーンショットだらけでブラウザの挙動ばかりを気にするのではなく、構造などの基本を大事にしている

てな辺り。

最近 Web の入門系の本なんか見る機会がないから知らなかったけど、探すと結構「Web標準」という言葉を目にする。「あー認知度上がったんだなー。」と感慨ひとしお。そういう中で探すと割とまともな本にたどりつきやすかった。ただやっぱ見やすさ、扱いやすさという、内容以外の要素も重要で、実際上に挙げた本は割と見た目を重視している。要は一人でこの本でめげずに独学していける*2と直感できる本を選んだつもり。

cf.

Tags: Web Book

*1 もっと多いのは Dreamweaver 本。MT, XOOPS カスタマイズ系の本もかなりのもの。

*2 それはつまり自分がこの本を飽きずに読み終えられるかって意味でもある


2012-05-23

_ Capistrano使うときの初歩的な注意事項二つ

  1. ホスト名はみんなが引ける名前をつける
    • 自分だけなら ssh_config で付けられる alias でも接続できるけど、それは共有できない
  2. deploy を実行する機械の時計は正確に合わせておく
    • releases/ 以下のディレクトリは capistrano を叩いた機械の時計をもとにディレクトリを作成するので、未来すぎたり過去すぎたりするとうまく deploy できなかったり次の deploy に支障が出たりする

時間の方は最近こういうのでガードするようにした。これはたまたま LAN 内の NTP サーバに HTTPD も起きていたので、そこから時間を取得して cap 叩いた機械の時計と比較している。

まぁ cap 叩く機械を統一して Webistrano でやりますっていうんならこういうのは要らない。人数が増えて上のようなミスを減らそうと思ったら Webistrano 入れるといいのかも。認証通さないといけないし、deploy のログも残る。

GUI が必要ないなら ssh の proxy とかで同じようなことができるんじゃないかなぁと思ってるんだけど、できるかどうかよく分からないし、そこまで考えるなら Webistrano の方が楽かな。ブラウザでポチポチするのがちょっとダルいけど。