« February 2007 | Main | April 2007 »

Saturday, March 31, 2007

イーモバイル D01NE

イーモバイルのPCカードのやつが届いた.
自宅でさっそく速度を測定してみたところ,以下のような感じ.

レスポンス:

無線LAN経由:6~9ms
イーモバイル経由:70~80ms

スループット:

BNRスピードテスト(下り):698.432kbps(0.698Mbps) 87kB/sec
BNRスピードテスト(上り):259.55kbps (32.44kB/sec)

gooスピードテスト(下り):2.55Mbps

ブロードバンドスピードテスト:
下り受信速度: 1.8Mbps(1.89Mbps,236kByte/s)
上り送信速度: 410kbps(417kbps,52kByte/s)

USENスピードテスト:2.386Mbps


利用者が多くなるともっと遅くなるかもしれないけど・・・

普通にWebとか使う分にはかなり快適.
AirHのような,全体的なもっさり感がなく,普通に無線LANで使っているときと体感速度は変わらない感じ.

sshでリモート接続をすると,AirHの時はラグラグで大変不快だったけど,イーモバイルの方は大丈夫.
ただ,こっちは無線LANと違い,若干ひっかかる感じがあるものの,十分許容範囲.

定額も安いし,いい感じです.

付属のツールも良い感じで,システムトレイのアイコンを右クリックしたメニューに,切断だけでなく取り外し,がある.
切断後,AirHだったら,ハードウェアの安全な取り外しからやらなければならなかったところ,同じアイコンから切断・取り外しとできるのがちょっと便利.

| | Comments (5) | TrackBack (0)

Friday, March 23, 2007

α100の車内広告

山手線の車内広告で,α100の広告があったんだけど,

・70-200mm 1/8000秒
・100mm 1/800秒 マクロ
・25mm 1/100秒

とかの写真が「手ぶれ補正ON」であって,実際に撮影した写真です,とのコメント付き.
その下に手ぶれ補正OFF,でぶれぶれの画像がのっているんだけど・・・
普段あまり望遠やマクロではとらないけど,このくらいのシャッタースピードだったらぶれない気がするけどなぁ...

まぁ,広告だし?(^^;ってことなんだろうか.

| | Comments (0) | TrackBack (0)

Thursday, March 22, 2007

PS3でFolding@home

今日のファームアップで Folding@home に参加できるようになった.
調べてみると,既にPS3のチームもいくつか出来ている模様.
海外の方がアップデートが速かったのかな?

とりあえず,PS3の中で一番上位のPLAYSTATION 3チームに参加中.

こういうのはCPUの性能が良いPS3にはぴったりなのかな.
OS別の性能を見ても,台数の割にかなり貢献できている事が明らかだし.

意外にGPUも貢献している模様.ATIのグラフィックボード用らしい.

| | Comments (0) | TrackBack (0)

Wednesday, March 21, 2007

Microsoftのライセンスって…

SQL Server を利用したいと思ってライセンスを色々調べてみると,これまたなかなかややこしく.

匿名のWebサイトを置くだけであれば問題はないが,普通に会員サイトを作ろうとすると非常に難しい.

・SQL Server にはユーザライセンスとCPUライセンスがあるが,Windows Server にはCPUライセンスが無い.
・匿名のアクセス以外にはCALが必要.
・SQL Server にアクセスするだけでも,Windows Server のCALが必要.もちろん末端のユーザ数でカウント.
・Windows認証じゃなくアプリケーション独自の認証をやっていてもCALが必要.

SQL Server の実行には Windows Server が必須なので,これでは CPUライセンスの意味がほとんど無い...
Windows Server には,CPUライセンスと似たようなエクスターナルコネクタライセンスがあるのだけど,「会社や系列会社の従業員、または同等の職員ではなく、サーバー ソフトウェアを使用したホスティング サービスの提供対象でないユーザー」という限定がある.
つまり,社員や関連会社の社員分はCALを買う必要がある.ということ.

自社の社員分は買ってくれ,というならまだ話はわかるんだけど,関連会社まで買うとなると,これはほとんど不可能な気が.
グループ企業全体でMicrosoft製品を導入しない限り利用不可,という感じだ.
もしくは,サイトの登録時に「自社およびその関連企業の利用を禁止します」と入れるか.
(でもそんなサイト見たこと無い気がする…)

関連企業も,「関連会社」の定義に書いてある感じで判断されて,いくらでも連鎖する仕組みなので,まぁ,うちの会社の場合はまず無理・・・.

色々調べていたら,サービスプロバイダライセンスというのもあって,こっちなら Windows Server も(利用制限付きではあるが)CPUライセンスが用意されている.
ホスティングサービスをやっているところを見てみたところ,Windows Server Standard + SQL Server Standard で月5万くらいの価格(サーバ費別でソフト代金だけで)だったので,それよりも少し安いくらいの価格で利用できる模様.

EULAには明記されていないようだけど,FAQによると,自社および関連会社への利用は「月次発注総数の 50% 未満 (製品ごと) 」に限られているものの,利用可能.
Webサイトを作る業務をしているような会社なら,自社用のサイトもいける,という感じのようだ.
お客様にWebサイトを提供したりはしないけど,自社のシステムは自社で作りたい,みたいな会社は考慮外ということなのかなぁ.

MSのサポートにWebから問い合わせても,あまりまともな回答は帰ってこないし,サービスプロバイダライセンスも結局自分で見つけた.
お客様にサービスを提供するために購入を考えているという話をしているのに,その辺の案内が出てこないのは,やっぱりMS社内でもライセンスに関しては十分周知されてない?のかな.

しかし,ライセンスややこしすぎ…


| | Comments (0) | TrackBack (0)

Friday, March 09, 2007

WISP = Windows + IIS + SQL Server + Perl

OLAPするために SQL Server を色々調べた結果,結構Windows系も便利だなぁと思う今日この頃.
LAMP (Linux+Apache+MySQL+Perl) に対抗して,

WISP = Windows + IIS + SQL Server + Perl

なんてのはどうだろう...
ほとんど聞いたことがないけど,特に社内システムなどにこういう組み合わせは良さそう.

・IIS を利用すると,Windows認証が利用できる.社内にActiveDirectoryが既に稼働していれば,認証の管理が不要.利用者も自分のマシンのログインだけで済むので快適だし,退職者のアカウントの無効化なども一元管理できる.

・SQL Server は管理ツールが非常に使い勝手がよい.ER図を内蔵のツールで書けば,そのままDBと連動する.手作業だと,多数の外部キーを張った状態でテーブル名のリネームをするのはかなり大変だけど,このツールなら普通にプロパティから名前を変えるだけで済む.大変便利.

・Office系と相性がよい.追加のソフトウェアインストールなしに Excel から SQL Server のデータを利用できる.(ただし参照のみ.更新したければVBA書かないとダメ)

ライセンスも,オープンソースのようには行かないけど,Oracleとかよりはだいぶやすい.
既にある程度Windowsを導入済みのところじゃないと,CALが高く付くかもしれないけど・・・

SQL Server というと,テーブルロックへのエスカレーションとか,あまり良いイメージを持っていなかったけど,2005 からはマルチバージョニングに対応していて,OracleやInnoDBのような書き込みと読み取りが競合しないモードも選べるし,マルチバージョニング管理のオーバーヘッドを減らすために DB2 と同じような書き込みと読み取りが競合するモードも選べる.
(オプティミスティックとペシミスティックを選択可能)

そんなわけで,その辺の心配も無用になり,Web系でも書き込みトランザクションを妨害せずに正確な集計などが可能.

この辺に関連して,Tripletailも0.24で実験的に対応しました.
(といってもコードをなおしたのはわたしじゃなかったりするけれど)
Linux->SQL Serverも,Windows->SQL Serverもいけるはず.
文字コード周り,まだ謎なところが多いけれど・・・もっと上手いやり方があったら知りたいデス.


WISPの欠点は,やっぱりライセンスかなぁ.
Windows も SQL Server もかなりややこしい.CAL周り.
まぁ,商用製品だから仕方ないのかもしれないけど.
個人向けに非営利限定とかで Windows Server / SQL Server を格安でライセンスしてくれたらいいのになぁ.
MS信者(?)が増えて売れ行きにも貢献しそうなものだけど...

| | Comments (2) | TrackBack (0)

SQL Server SP2バグ

http://www.microsoft.com/downloads/details.aspx?FamilyID=e2c358a1-ecc4-4c49-8f65-daa6b7800eec&DisplayLang=ja

SQL Server SP2 を当てると,メンテナンスプランの期間の解釈が変わって,2ヶ月保存すべきものが2週間しか保存してくれなくなり,それ以前のデータは消えてしまうとのこと...
MSとは思えないほどのずいぶん過激なバグ...(^^;

今のところメンテナンスプランを使って運用するほどちゃんと管理できていないので実害はなかったけど,明日パッチを当てておこう...

| | Comments (0) | TrackBack (0)

Monday, March 05, 2007

趣味プログラマ歓迎じゃないの?

■趣味プログラマが業界で生きて行くにはに関して思ったことなど...

趣味プログラマの定義って何でしょう?
趣味でもコードを書く人,というならわたしも当てはまりますが,書いてあることとあまりイメージが合いません.

というかうちの会社の大半の人は趣味プログラマになってそうな気がします.
新しい社員が入ったときの自己紹介で,趣味の中にプログラミングを入れない人が珍しいくらいです.
(ただし,わたしがいる事業部の話です.)

以下,うちの会社でのイメージから考えての話です.

しかしいざ現場では元趣味プログラマの独壇場となる現実があるにも関らず、実際問題、面接の場では、趣味プログラマは嫌われます。

というのは世間一般ではそんなモノなのでしょうかね?
わたしのところでは,趣味でやっている人がほとんどなので,嫌われる理由がわかりません.

うちは趣味でPerlやってる人とか歓迎です.

まず、偉い人は、コードの品質なんか気にしません。非効率で拡張性が無くて冗長でバグの温床がいっぱいあっても、仕様を満たしていれば良いコードであり、逆もしかりです。なお、ここでいう仕様は、その場の解釈によって逐次変化します。どんなに手間暇かけた素晴らしいコードであっても、あっさりボツになります。そこで腐ってはいけません。

コードの品質は重要という認識が普通なので,気にしないという会社があることが不思議なくらいですね.
もちろん,品質がいくらよくても,仕様にあっていなければ意味がないので,仕様からずれたものはどんなに素晴らしいコードでもボツにはなるでしょうけれど.

実際に,品質を気にする会社向けに,品質向上支援ツールなんてのもあるわけでして...

仕様がその場の解釈によって変化するのは,ちゃんと仕様書なりで確認するようにすれば防げることではないかと思いますね.
プログラマとしては,受け取った仕様に曖昧な点があれば,早めにそれをはっきりさせるよう心がけるのが一番.
変だと思っているのに黙って受け取っていては,結局自分が苦労することになってしまいます.

偉い人は、コードの品質なんか気にしていませんが、気にしているふりをしないといけないので、行数だのファンクションポイントだのコーディング規則だのといったものを持ち出してきます。その評価基準のもとでは、冗長なコードほど評価されたりしますが、やはり腐ってはいけません。

そういう偉い人がいるのであれば,色々微妙でしょうね...

ファンクションポイントは見積もりをとるためのもの・・・だと思っていたのですが(^^;

ただ,仕事でコードを書く場合,そのコードを自分以外の人がメンテナンスする可能性を常に考えないといけません.
特に趣味プログラマはレベルが高いことが多いので,難しい機能を利用したいと思うこともあると思います.
しかし,仕事で書いたコードは,自分がやめたら他の人がメンテナンスをしていなければならなくなります.
周りの人のレベルが低い場合,周りの人から見れば「訳のわからない汚いコード」という扱いしか受けません.

自分が理解しやすい・美しいと思うコードではなく,周囲の人が理解しやすいコードを書くように心がければ,良い評価になると思います.

また、偉い人の中には、思い出したようにコードを見て、この変数名はこの方がいいんじゃない?と明らかに筋の悪い提案をしてきたりする人もいますが、現実の社会では年上を立てることができなければ生き残れません。すかさず、そうですね流石ですと言いましょう。腐ってはいけません。

年功序列な会社なんでしょうか・・・

うちの会社の場合は,年上の人とか関係なく,普通に色々言い合っています.
というか,普段相手の年齢なんか気にしないので,お互い年上か判断できていないのでは,と思うくらいですが...

偉い人は、時間を気にかけているため、無駄な所で未知へのチャレンジを行うのは無駄と見られます。近代企業に置いて時間はお金と同義語です。チャレンジが許されるのはそれが必要な時のみです。趣味プログラマにとって未知へのチャレンジは動機のかなりの部分を占めるわけですが、ぐっと抑えましょう。しかし、チャレンジなんかしなくていい計画が立てられている筈なのにも関らず、チャレンジが必要な場面は案外頻繁に発生します。謎ですがそういうときは趣味プログラマの能力を最大限に活かし問題解決にあたればそれでいいです。しかし何が正しいかは前述のように解釈次第ですので、大抵の場合は後日あっさりその成果が、やらなくても良かったね、みたいにはなりますが、やはり腐ってはいけません。

チャレンジが必要ないのに,業務に無関係な無意味なチャレンジをするのは,それは無駄と見られても仕方ないでしょうね.
会社は仕事の成果に対して対価を払っているわけで,業務時間はちゃんと仕事をしましょう.

チャレンジが必要なときに,うまく問題解決すれば,それは評価される…と思います.

偉い人は設計を行います。趣味プログラマにはコードを弄りながら設計も同時にやってしまうのが常套ですが、それが通用するのはひとりで全てを行っていたからで、複数人で作業する以上は、設計は事前に済ませておかないといけません。結果、コードに落としにくい設計になったり、コードを書く段階まで穴が見過ごされたりしますが、バグを潰すのは別のフェイズですので、書き直さないといけないことがわかっていても、一応それで実装して、動きを見せてホラ上手くいかないでしょと説得を試みねばなりません。偉い人にとっては設計こそがプログラミングであり、動く所まで出来て初めてデバッグ、となるわけです。その間で発生する作業は以下略で腐っては以下略です。*1

コードに落としにくい設計になっていたり等,設計に不備がある場合や,よりよい設計を思いついた場合は,その場で指摘するべきです.
普通は歓迎されるはずです.
早い段階で設計を直せば,大幅なコスト・時間の節約になりますから.

引用元にあるようなコストを気にする偉い人に対しては,こう直さないとこのくらい余計に作業時間がかかります,と主張すれば,受け入れられると思うのですが...

偉い人が昔書いたコードは財産です。新たなプログラムを書き起こす時も、それを元にしなければなりません。デタラメな命名規則が使われていた場合はそれがコーディング規約となります。明らかに効率が悪い箇所を見つけても黙っておきましょう。趣味プログラマのスキルを持ってすれば素人が書いたコードに継ぎ足していくよりもゼロから書いた方が早いのは明らかですが、他の方々は既にそのコードに慣れてしまっているため、あえて変えようとする方が全体としては負担となりますので我慢しなければなりません。バグを見つけた場合は、それが潜在的なものに過ぎないのか、実際の動作にまで出てきてしまうのかが重要です。表面化しないバグは検証の余地が無いからです。表面化しないなら黙っておくしか無いです。表面化した場合は、鬼の首を取ったように騒ぎましょう。騒がないと、同じコードを元にした別プロジェクトの人が気付いてくれません。それも仕事です。

既存のシステムに手を入れる場合,動いているものは基本そのままにするべきです.

ゼロから新しくコードを書いたら,100%完璧に動作する保証があるなら良いですが,それは不可能です.
書き直したコードにもしバグがあったら,色々と大変ですから.

コードをゼロから書いた方が早い,というのも大抵は間違いです.
そもそもそんないい加減なコードに仕様書はないでしょうから,まず必要な仕様をコードから読み取って,全く同じアウトプットを出すようにしなければいけません.
これはやってみると非常に大変な作業です.

ただし,もし効率を改善できる部分があったり,表面化しないバグがあったのなら,それは適切に報告すべきことだと思います.
システムの改善を提案することができたり,今後システムに手を加えるときに,地雷を踏まずに済む可能性が高くなりますので,偉い人も喜ぶと思います.

----

わたしなりに書くとすれば,こんな感じでしょうか...

仕様書があるよな業務では,仕様書に書いてあるものをそのまま作る必要があります.
お客様とはそういう契約になっていて,違うものを作れば大きな問題になります.
より良くするアイディアがあったり,仕様通りに実装することが難しいことに気づいた場合は,まずお客様と交渉して仕様書を変更する必要があります.
その手順をスキップしてはいけません.

また,仕様書には,多くの場合曖昧なところや,おかしな部分があります.
そういったものに気づいた場合は,なるべく早い段階で内容を明確にして,おかしな部分を修正しましょう.
その際,必ずその修正を仕様書に反映させることが重要です.
仕様書を直さずコードだけ直すと,後で必ず問題になります.
おかしな部分が出てくるのは,仕様をまとめる人の能力のせいだったり,お客様の理解が不足していたりと色々原因がありますが,ゼロにはできないので,そういうものだと思って諦めた方が精神上良いです.

% もし,仕様を明確にすることに偉い人が非協力的な場合は,危険なので逃げた方がよいかもしれません.

コードを書くときは,自分が読みやすいコードではなく,社内の他の人が読みやすいと思うコードを書くように心がけましょう.
多少冗長な書き方だと思ったりしても,レベルを合わせることが重要です.
他の人が読めないコードばかり書いていると,トラブルが起きたときに有給中でも呼び出されるかもしれません.
お客様との契約では平日対応しなければならず,その平日に対応できる人が他にいなければ,普通はそうなります.そこで連絡が付かずにどうしようもなくなると,後々大きな問題になります.

業務中は,要求されている作業を第一に進めましょう.
さっさと仕事を終えて,定時で切り上げて,家に帰ってから趣味のプログラムをしましょう.
仕事中に趣味のプログラムをやっていると,まずいことになるかもしれません.
(ただし,能力があれば多少は大目に見てくれると思いますが,まじめにやってた方がより評価は高いでしょう)


| | Comments (0) | TrackBack (2)

« February 2007 | Main | April 2007 »