http://enbug.tdiary.net/20060722.html#p01
たしかに Python、Ruby があれば Perl は不要かも、
とか思えるぐらいになってきたのよね。
可読性という意味では Python のほうがあきらかに良いし、
書きやすさ、という点では Ruby のほうが勝ってる。
Web でちょっとしたことをするには PHP が一番楽。
Perl の良いところは、
- どこでも使える
- CPAN が便利
- そこそこ速い
という点だと思うんだけど、
今じゃ他の言語も遜色なくなってきてるんだよね。
awk みたいに、ゆっくり一線から引退する、というのは
わりと現実的にありそうなシナリオかもね。
個人的には大好きなんだけどなあ。
http://www.geoap.jp/
路線検索、目標物検索、のような高度な地図サービスを、
Web サービスで使えるサイト。
Google Map と連携するサンプルなんかもある。
いろいろ応用できそう。
http://d.hatena.ne.jp/mkusunok/20060728/se
放っておくと優秀な技術者がますます情報サービス産業を去り,
或いは優秀な新卒はこの業界を目指さなくなるだろう.
ここなんかも同じことを言ってるな。
優秀なエンジニアから引退していく、日本のIT業界
http://www.13hz.jp/2006/07/post_521d.html
でも、それで何が問題なんだろう、という気もしてたり。
日本の情報サービス産業が、世界のダイナミックな動きに、
全然ついていけてない、っていうのはもはや明らか。
待遇も技術レベルもいまいちすぎなところ多すぎ。
そういう会社から人がどんどんいなくなって、
会社が潰れちゃう、というのはある意味正しい気もするのよ。
で、そういう会社に吸いこまれてたコンピュータエンジニアが、
普通の会社で働いて、エンドユーザのレベルが上がれば、
そっちのほうが世の中的には良いんじゃない?
今まで仕方なくコンピュータエンジニアをやっていたという人は、
他の仕事をしたほうが多分幸せだと思うしね。
それでもやっぱりコンピュータエンジニアが天職な人は、
Google みたいに、ちゃんとエンジニアの心を理解してくれそうな、
まっとうな会社で働けば良いのさ。
日本の情報サービス産業がいまいちだとしても、
他の国の情報サービス産業はどんどん伸びてるわけで、
働く会社には全然困らないはず。
ひょっとして暴論言ってる?
暴論を続けると、、、、、
何をすべきか、とアイディアを出すのはとても重要なんだけど、
実装しないと話にならないんだよね。
ちょっとした出来心で、エンジニアの幸せのための仕組み作りの
実装に関わっちゃったのはそういう理由だったりもする。
様々なことがあったおかげで、全然実装が進んでないんだけど、
誰か私の後を引き継いで実装を進めてくれる人いないものかのう。
やる気ある若者求む〜。
http://phpspot.org/blog/archives/2006/07/webchorizo.html
proxy として動作するのか。
お手軽で良いな。
http://www.radiumsoftware.com/0607.html#060731
Typed assembly language (TAL) は RISC 命令セットに基づいた
静的型付き言語である。
型安全な低レベル言語という意味では Java 仮想マシン言語
(JVML) に近い位置付けになるが, JVML よりも厳密な形式化が
なされており,なおかつ汎用性に富んでおり,それでいて
ターゲット言語(アセンブリ)に近いという特徴を持つ。
ハードウェアに近いところのコンピュータ言語も、
着実に進歩してるんだなあ。
JVML みたいな層がボトルネックになる可能性は高そうなので、
ここのレイヤが速くなれば、全体的に速くなりそう。
ハードウェア化というトレンドを考えると、
ハードウェア化しやすい言語セット、というのも
当然研究されてるんだろうなあ。
http://wota.jp/ac/?date=20060727#p01
Ruby 本より多くなりそう。
すごいいきおいだな。
http://blog.goo.ne.jp/v6arano/e/dbf78b8e452758d47e6c4343cd5f0a42
「マルチメディア切り札、統合ISDN網であらゆる種類の
トラフィックを統合的に、効率的に配信できるようになる・・・」
いたたー!
「電話も進化する。」 テレビ電話、会議電話、自動車電話・・・
といろいろ写真や イラストつきで。自動車電話とかはステアリングの
中央部に電話機が内蔵されている(笑)。
しかし、さすがに「電車の中でメール、ゲームやってたり、
音楽きいてたり」、「コンビニで支払いしてたり」がないのは
仕方ないにしても、どこをみても単に「歩きながら電話」という
シーンのかけらもない。いたたー!
未来予測って難しいよなあ。
15年後はどうなってるんだろう。
わくわくする。
http://artifact-jp.com/mt/archives/200604/rentalroom.html
会社の会議室が使えれば一番楽なんだけど、
使えない場合もあったりするわけだ。
ゲームのオフ会とかね。
ここに書いてある URL をメモメモ。
T's BUSINESS TOWER
http://www.tsrental.jp/
会議室ドットコム
http://www.kaigishitu.com/
JMA貸会議室サーチ
http://www.jma-m.co.jp/index.php
TKP貸会議室ネット
http://www.kashikaigishitsu.net/
Regus Japan
http://www.regus.jp/products/meetingrooms.html
http://www.onflow.jp/blog/archives/2006/02/mod_proxy_balan.html
コンテンツを圧縮する mod_deflate なんかも併用すると、
帯域にやさしいのか。へえ。
mod_deflate
http://httpd.apache.org/docs/2.2/ja/mod/mod_deflate.html
関連)
mod_proxy_balancer 小技集 --> [2006-07-20-8]
http://www.xdelta.net/blog/FreeBSD/2006/07/27/p208
たしかに
- /usr/ports/UIDs
- /usr/ports/GIDs
ができてるな。
http://postfixvirtual.net/
Postfix で Virtual Domain を運用するときに
参考になりそうなページ。
http://d.hatena.ne.jp/naoya/20060729/1154139996
この辺考えると、マシンも安いし簡単に DB を増設できる今の時代、
ある一定規模以上のトラフィックのあるサイトでは
MyISAM で CPU に優しいシステムを選択するよりかは、
マシンリソースを消費してでも並行性の高い
InnoDB を選択するほうが、総体でのパフォーマンスは
良かったりするんじゃないかなあという疑問がふつふつと
沸いてきます。
たしかにそんな気もする。
検証きぼん。>その筋の人達w
http://japan.cnet.com/news/ent/story/0,2000056022,20154608,00.htm?ref=rss
via http://www.rubyist.net/~matz/20060629.html#p01
オープンソースのソフトウェアは、
多くのボランティアに支えられてるので安心です、
っていう意見を良く聞くけど、
その意見は、なんだか無責任な気がするんだわ。
それだけじゃなくて、今的じゃないと思う。
コンピュータソフトウェアを使った商売は、
良くわからない権利やブランドにお金を払う、という時代から、
人の活動そのものにお金を払う、という時代へ、
確実に移ってきていると思う。
ソフトウェアを使うには、保守をするコストっていうのが
絶対にかかるわけで、そのコストは様々な要因により積算される。
出来の悪いソフトウェアを使って、しかも単一のお客さんにだけ、
スペシャルサービスで提供してりすると、
保守コストが馬鹿高くなっちゃうのは当然のこと。
必ずしもオープンソースだから安くなるってわけじゃあない。
ただ、オープンソースのソフトウェアの場合は、
お客さんからすると、見ようと思えば中身が見えるわけで、
どの部分にお金を払うか、というのを客として納得しやすい。
売る方としても、お金がかかる部分もお客さんにちゃんと
説明できるわけで、そのコストはお客さんに納得ずくで
負担してもらいやすい。
場合によっては第三者によって監査してもらうことも可能だしね。
売る方としては、必要なお金は取れるけど、ぼりにくいわけだ。
必要なものにはお金を払う、というのはあたりまえなことで、
保守が必要ならそれにお金を払うのは当然だよね。
保守する能力を持たずに、ボランティアに保守を期待する、
言いきっちゃう姿勢は、客をナメてるとしか思えない。
でも今だに平気でそういうことを言う SIer はまだまだいるのよね。
http://homepage2.nifty.com/m_kamada/docsproc/asmurr.htm
via http://www.rubyist.net/~matz/20060726.html#p02
コンピュータでの浮動小数点数の取扱いは、
IEEE754が一般的なんだけど、こんな考え方もあるのか。
ちなみに IEEE754 の詳細は wikipedia とかにあるね。
Wikipedia - 浮動小数点数
Wikipedia - IEEE754
URR は日本人によって考案された表現方法で、
考案された当時の技術では実装が困難だったために、
規格化されなかったものらしい。
読んでみるとわかるけど、まさに天才的。
長所
- オーバーフローやアンダーフローが事実上発生しない。
32 ビットの URR で表現できる数値の最大値は 10 進数に
1 億桁以上の数になる
- ±1 の近辺で精度が非常に高い
- データのサイズに関係なく一定のフォーマットである
精度を下げるときは末尾を切り捨て、
精度を上げるときは末尾に 0 を補うだけ。
- 大小の比較が符号つき整数と同じ手順でできる
- 符号の反転が符号つき整数と同じ手順でできる
短所
- デコードがやや面倒。
- 例外的な表現を入れる余地がない
IEEE 754 で言うところの NaN(非数)を表現することができない
http://blog.gcd.org/archives/50603640.html
まさしくその通りだと思う。
プログラミング=設計、なんだよね。
ちょっとでもプログラミングをしたことがあるなら、
設計は済んでるから、後はコードを書くだけ、
とか言えないと思うんだけどなあ。
コードを書く、っていうのはおそろしく自由な行為で、
設計書を書いたから、中身が一緒になるなんてことは
絶対にないわけだし。
ひょっとすると、上流設計、詳細設計とか、
そういう用語がいけないのかもね。
あたかも設計とプログラミングが別物であるかのような
誤解を生んじゃう気がする。
んー、極端なことを言うと、設計っていう言葉を
使わないようにすれば良いのかもしれないな。
どの工程でも「プログラミング」と言っちゃう、とか。
概要設計 --> 概要プログラミング
詳細設計 --> 詳細プログラミング
こんな風に言いかえちゃえば、プログラマ、というのものが、
コンピュータをちゃんと使う鍵であることが良くわかるはず。
コンサルなんかも、
業務コンサル --> 業務プログラマ
システムコンサル --> アーキテクチャプログラマ
こんな風に言いかえちゃう。
思いつきで書いたけど意外と良いアイディアかもな。
SE なんていうわけのわからん用語を使うぐらいなら、
何をプログラムする人かをちゃんと言うほうが良いと思うね。
極端なことを言うと、
プロマネ --> プロジェクトプログラマ
営業 --> コストプログラマ
こうも言えるか。
そもそも仕事って、すべてプログラミングだよね〜♪
Firefox をインストール。
拡張機能は以下を選択。
Talkback
SurfKeys
function for keyconfig
Tab Mix Plus
uri statusbar
All-in-One Gestures
Greasemonkey
Stylish
Tab Sidebar
Google Notebook
Google Toolbar for Firefox
Google Browser Sync
VideoDownloader
ASnumber
加えて、以下のように設定。
- すべての新規ウィンドウをタブで開く
- 新規タブを現在のタブの直後に開く
- 新規ウィンドウに開く筈だったタブにフォーカスを移動させない
ThinkPad X60s 1702C4J
昨日注文した X60s が届いたので早速セットアップ。
軽くいじってみた X60s の印象。
- 軽い!。1.29 kg なんだけど持ち易いのでもっと軽く感じる。
もちろん X22 とか X31 より圧倒的に軽い
- 小さい。X22、X31より一回り小さい。
- USB が 3ポートもあって便利
- IEEE 端子もくっついてるので中継とかに使えそう
- SD カードスロットがあるのが便利
- ThinkPad っぽいしっかりした作り。
ハードディスクもすぐ交換できたりメンテナンス性も良い。
- 無線LANのハードウェアスイッチがあるのは良いかも
- 指紋センサーが格好良い。ログインが楽ちん。便利。
- Core Duo やっぱり速いわ。
- 最初にインストールされてるソフトウェアがかなり多い。
- Google のツールが最初から入ってる。
Google デスクトップ、Google ツールバー、Picasa2。
- バックアップツール、デフラグツールが入ってるのも嬉しい。
すぐにデータセンターで作業をする必要があるので、
最低限必要なツールをインストール。
具体的には以下をインストール。
- UTF-8 TeraTerm Pro with TTSSH2
- XKeymacs
- skkime
- Sleipnir
残りは後で。
それぞれの説明は以下。
UTF-8 TeraTerm Pro with TTSSH2
http://www.forest.impress.co.jp/article/2005/08/04/utf8_teraterm.html
なんと TeraTerm の新しいものが出ていた。
フルパッケージなのでインストールも楽ちん。
タブで切り換えもできたり。便利すぎ。
Putty みたいに、エスケープシーケンスの扱いがあやしい、
なんてこともない。
激しくお勧め!
XKeymacs
http://www.cam.hi-ho.ne.jp/oishi/
Emacs で生活している人にはこのツールは必須。
パワポだろうがワードだろうが、Emacs キーバインドで、
使えちゃうのはとっても便利。
skkime
http://www.tatari-sakamoto.jp/~tatari/skkime.jis.html
漢字変換は、やっぱりSKKでしょ。
そのうち POBox(--> http://pitecan.com/OpenPOBox/ ) に
乗り換えようかと思ってたりもするんだけど、
まずは慣れたものを入れておかないと。
辞書は、SKK 辞書のページから
SKK辞書
http://openlab.ring.gr.jp/skk/wiki/wiki.cgi?page=SKK%BC%AD%BD%F1
- 基本の SKK-JISYO.L.unannotated
- jinmei
- geo
- propernoun
- station
- zipcode
- office.zipcode
これに加えて顔文字辞書も追加、と。
エモジオ2.3.4 for SKK
http://www.bookshelf.jp/pukiwiki/pukiwiki.php?SKK%20%BC%AD%BD%F1#content_1_5
Sleipnir
http://www.fenrir.co.jp/sleipnir2/
Firefox と違って、環境構築の手間がほとんどいらない。
最近はほとんど Firefox で生活してるんだけど、
とりあえずインストール。
http://adiary.abk.nu/about.html
adiaryは、Pure Perlで動作可能なフリーのblog/web日記システムです。
- インストールは比較的簡単です(tDiary並だと思います)。
- 外部データベースなしでも動きますし、また外部データベースとして
PostgreSQL または MySQL を使用することも可能です。
- cgi として動かしても(Movable Typeとは違い)まともな速度で
動くように注意して設計しています。
- blogシステムとしてはめずらしく(?)
mod_perl2, mod_perl2 with worker MPM(スレッドモデル),
SpeedyCGIに正式対応しています
(注:FastCGIは書き間違えでした。大変失礼しました(汗))
- ソースとデザインがスケルトンシステムにより分離しています。
全体的な構成はMVCモデル的であり、デザインの変更が
比較的容易に行えます
(がスケルトンのドキュメントが未整備です、ごめんなさい)。