システム開発

2009年07月12日

決めの問題

このエントリーをはてなブックマークに追加
仕事でよく「決めの問題」という言葉を耳にする。
 
意味としては、技術的な問題はなく、何らか決めればよい事をさす。
 
例えばプログラムや関数の名前を決めるとか、会議などの議論の場で、その決定に関する討論を中止したい場合に使う事が多いと思う。
 
「決めの問題」と言っている事の大抵は、全く何でもよい、という訳ではないが、ある程度の範囲ではどう決まっても影響が少ない。
 
日常生活で言えば、昼飯をそばにしようかうどんにしようか悩む。
 
その程度の問題だと思う。
 
たとえば名前を決めるにせよ、好みの問題もあるので、各人の意見を聞けばバラバラかもしれないが、各人、どう決められても大抵は問題なく、主張するほどの程度でもない。
 
ただ、議論の場では、そういう好みの問題でも、他人の意見を受け入れたくない、自分の主張を通したいというタイプの人がいたりいなかったりで、あまり時間をかける必要のない藤論に時間が割かれてしまい、もったいないという時に「それは決めの問題だからXXさんが後で決めてくれればよいです。」と討論を中止させる。
 
それはそれでよいのだが、自分が問題と思うのは、その「決めの問題」と言われる問題が、実は検討、討論が必要で、今、決定しなくてはならない問題なのに、決定を後回しにしたいとか、決める責任を誰かに渡したいがために、使われる事。それを恐れている。
 
ささいな事でも、決める事は大事で、そこにはささいながらも考慮や根拠があるべきだ、と思うのだ。
 
自分の判断力、決断力を高めるためにも、決定するめんどくささから逃げてはいけない。
 
そして自分がしっかり責任を持つためにも、どちらでもいいと思えるような、ささいな事でも、なんらかの考慮をしたうえで、決定を下したい。


zeroaka at 20:30|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2009年04月17日

ソフトウェアは工業製品ではない?

このエントリーをはてなブックマークに追加
ソフトウェアは工業製品ではない
http://www.atmarkit.co.jp/news/200904/10/matz.html

これには賛同しかねる部分がある。

確かに、ソフトウェア開発の工程で、コーディングを「製造」と呼ぶのは自分も最初に知った時、違和感を感じた。

普通の工業製品みたく、工場のラインに乗せて、大量生産する事が製造だとしたら、CDやDVDのメディアに焼いてパッケージングするくらいが製造だろ、と。

しかし、ソフトウェアは自動化された工場で生産、製造される工業製品、つまり工場制機械工業で作られるものでなく、すべて手作りの「工場制手工業」で作られる物なのだと考えれば、コーディング=製造でも納得がいく。

手工業で職人たちが作る製品の品質は、職人たちの技術にかかわってくる部分もある。

そういう意味では、コーティング作業を決して軽視してはいけないと思う。

ただ、このまつもと氏の観点は、オープンソースのソフトウェアや、パッケージソフトウェアなど、プログラムのみを生産物として提供するのみの話であって、どうも、工業製品の組み込みプログラムや、明らかに工業製品の一部に組み込まれるべきソフトウェアプログラムまでを意識して発言しているとは思えない。

ウォーターフォール式のSIでのソフトウェア開発等、手順をきっちり踏んだ大規模開発を想定したときに、俗人的なソフトウェアの品質のばらつきはなるべく排除したい。

そう考えた時に、「プログラマはアーティスト」という考えはかなり誤解を生む。

「コードは人を感動させる」というが、感動させること自体はソフトウェアの目的でもなんでもない。

目的の処理を果たすため、安全確実に動くこと。

製品に求められるのは、その部分。

まつもと氏の発言に同意するとしたら、職人芸的な美学、つまり製品への「こだわり」が、結果としてよい品質を生むのだ。

そう解釈したい。

zeroaka at 19:15|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2009年02月08日

やわらかい資料

このエントリーをはてなブックマークに追加
最近、仕事で資料を受けとった際に「この資料はまだやわらかいものです。」という説明をうけた。

要は決定事項でなく素案に近い内容の資料だという意味らしい。

面白い表現なので自分もこれから使ってみたいと思った。

という事でβ版というかまだ完成しきっていないソフトウェアの事を「やわらかいソフトウェア」と呼ぶのはどうでしょう?

英語に直訳すると「SoftSoftware」という事で。



zeroaka at 13:24|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2008年09月28日

無料のサーバ監視サービス DATAHOTEL PATROL

このエントリーをはてなブックマークに追加
無料のサーバ監視サービス
DATAHOTEL PATROL
うーむ、自宅サーバを運営している自分としては、なかなかありがたいサービスだ。

監視内容は今のところping(ICMP)や特定ポートのTCP,UDPの死活監視のみだが、監視のために常に電源やNWが常時接続された別の環境を用意する手間を考えると、それでもありがたい。






zeroaka at 13:27|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2008年09月17日

コンピュータシステムは人が作るもの

このエントリーをはてなブックマークに追加
コンピュータシステムを開発する仕事は、どうも外見の技術ばかりもてはやされていて、実際に作られる過程はどれだけ属人的であるか、あまり注目される事が少ないように思えます。

新しい技術、新しい開発手法、開発ツール、そんな華々しい話題ばかりが雑誌や本に載るものの、コンピュータシステムが作られる過程で、人間関係がどう影響するのか?人柄や個人の性格がどう影響するのか?といった事にあまり着目されていないように思えます。

ヒューマンスキルとか、コミュニケーションスキルとか言うと、これまた横文字にしただけのかっこつけでありまして、意外と実体のない話が多いです。

もっと生々しい、感情的な人の挙動に関する話を話題にした方がよいと思う事があります。

コンピュータシステムを作る人は昔いじめられっこの人が多いのかとか、アニメやマンガばかり見るオタクな人が多いのかとか、そういう人を心よく思わない人がそういう人と同じチームになった場合、どういう問題が発生するのかとか、勝ち負けにこだわる人が人の話を聞かないで暴走するとか、言葉遣いに考慮がなく、ひとの感情を逆撫でして仕様がまとまらないとか、そういう話にもっと焦点を当てるべきではないかと。

なので、コンピュータの技術の話は大好きですが、コンピュータシステムを作る上での問題は技術より人の問題がほとんどのような気がしますので、もっともっと話題にしていきたいと思います。


Meatlook Software

人という肉のソフトウェアをよく見ていきましょう。



zeroaka at 22:10|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2008年09月16日

システム開発とソフトウェア開発の違い

このエントリーをはてなブックマークに追加
ソフトウェア開発とシステム開発ってどう違うのでしょう?
http://questionbox.jp.msn.com/qa600833.html?StatusCheck=ON

と、素朴なQ&Aがあったので引用してみました。

ここで言っているシステム開発のシステムとはコンピュータシステムの事を指すわけですが、私はコンピュータシステムを作ったり、直したりする仕事の一部をしているものの、ソフトウェアは開発していません。

コンピュータシステムとは何かというと、コンピュータを使って何らかの処理を行う「仕組み」のことです。

そして作られたコンピュータシステムは日々、動かして運用していく必要があります。

また、コンピュータシステムを作ったり、運用していくうえでいろいろなものが必要になります。

サーバ、ネットワーク機器、電源、ラック、パソコン、そしてパソコンやサーバで動く市販のソフトウェア、手作りのプログラム、それらすべてを用意するため、それぞれ仕事があり、プログラムを手作りする仕事=ソフトウェア開発はごく一部の仕事にしかすぎないように思えます。

しかし、IT業界というと、プログラムを作る仕事がほとんどと考えている人も少なくないような気がしています。

それは、最もコンパクトに収まるプログラムというものを用意するのに、最も人手を要するからでしょう。

とりあえす、自分の今いる業界は、SEとかPGとかIT業界とかなんだが漠然な言葉でなく、もっと仕事について詳細に分類しないと、どの仕事をやっているか、わからないように思えます。

どういうコンピュータシステムを作っているのか?

そのコンピュータシステムを作る上で、何を自分が担当しているのか?

を細かく考えると、IT業界とひとくくりにしている業界の仕事は、ものすごく細分化されており、千差万別であるように思えてくるものです。


zeroaka at 23:31|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2007年07月16日

イノベーションのジレンマ

このエントリーをはてなブックマークに追加

最近、こんな本を読みました。

イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき

元MSのスーパーエンジニア中島 聡さんのブログ

「MSをやめるきっかけを作った。」

と紹介されていたのでついついAmazonでぽちっと買ってしまいました。

読んでみたら、こりゃ、大手企業を辞めたくなるような内容です。

大手の優良企業が優良であるがゆえに、新興の破壊的イノベーション技術を持つ企業に負けてしまうシナリオを、ハードディスク市場や米国鉄鋼業界、小売業界などの例をとりあげて説明しています。

そして、大手の優良企業がそれら新興企業と対抗する手段についても書いています。

そのシナリオや手段はIT業界ではもう今現在も繰り返されているものです。

ついちょっと前はMS vs Google がそんな構造でしたが、最近はGoogle自身も防衛側にきている感じです。

新興企業を買収してしまうのも対抗手段の一つと解説されており、Googleがやっている戦略に近い感じです。

あと、読んでて面白いなと思ったのは、破壊的イノベーション技術の需要は最初はだれにも予測できない、ということ。

なので、破壊的イノベーション技術を持つ製品は、新しいマーケットを事前に調査して、十分な計画を練ってから作ったり、売り出すのではなく、とりあえず作ってみたものをいろいろどこかに失敗覚悟で売ってみて、新しいマーケットを試行錯誤で作り上げていくのが有効なんだと、著者は語っている。

最近、技術軽視な風潮があって、物を作る技術なんて有り余っている。頼めば誰でもできる。それよりビジネスモデルを考えるのが大事、みたいに考える人がいる。

物がそこに既にあるからこそ生まれる新しいアイデアやビジネスもあるというのに、ビジネスモデルばかりを先に考えてしまうから、似たり寄ったりの戦略しか思いつかないようにも思えます。

もっと物づくりのモチベーションを大事にしたいです。

そして、まずは作れと。

 



zeroaka at 18:09|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2007年06月16日

CMMと品質

このエントリーをはてなブックマークに追加

最近、こんな本を読みました。

ソフトウェア開発のためのプロジェクトマネジメント入門―CMM導入の手引き

この本はソフトウェアのオフシェア開発を主に行っているインドの企業 Infosysが実際に行っているソフトウェア開発のマネジメントプロセスを紹介した本です。

InfosysはCMM(CMMI)レベル5に達していると評価されている企業だそうです。

CMMやCMMIは主にソフトウェア開発の組織の成熟度を示すモデルとしてよく聞く言葉ですが、ISOみたいな認定があるわけではないそうです。
ここでいう、Infosysが評価されたというのは、モデル導入の評価者に評価されたという事らしいです。[参考]

CMMIのモデルを提案したSEIという組織のレポートには、国ごとに導入・評価した組織の数が載っています。(ここのp15)
その数では日本は、インドや中国に負けているみたいです。orz。ちょっと悲しいですね。

日本ではレベル2や3の評価を受けたSIerが多いようですが、ここのモデルの説明を見ると、4以上でないとあまり自慢できるものではない気がするのは気のせいでしょうか?

それはさておき、そんなすごい企業がどんな管理を行っているのかと気になって読んでみましたが、規模の見積り方法、品質管理、進捗管理、要求変更の管理、構成管理のやり方など、おおむね自分が経験した現場で行っている事と変わりませんでした。

しかし、ここが違うなと、大きく関心をもったところは、

1.管理の方法を組織として、統一して実施する。
2.管理方法の効果について、逐次評価を行う。
3.過去のプロジェクトの結果をデータとして蓄積し、次の計画に生かす。

というところです。

開発の現場では管理が行えていても、組織全体、つまり会社として統一した管理がはたして行えている会社がどれだけあるか?
そしてその管理方法について逐次、評価し、結果をデータ化して利用できている組織がどれだけあるのか?とよく疑問に思います。

よく新規顧客のSI案件がデスマーチ化するのは、新しい現場で、プロセスが十分に出来上がらないまま、開発を進める事になってしまう事がひとつの原因ではないでしょうか?

同じ開発現場の二次案件がうまくいくケースが多いのは、現場でのプロセスや、ノウハウが成熟したからだと考えます。

しかし、新規顧客の案件といえども、毎回毎回案件ごとに管理の方法を1から作りだすのはなんて効率が悪いのかと思います。そして、下請けSIベンダなどで、現場や上位SIベンダの管理方法に甘んじて、自らの組織としてのプロセス管理手法を作ろうとせず、結局、人出ししかできないベンダも多そうに思えます。

統一された開発のプロセスやナレッジという物は組織の資産です。

特に、過去のプロジェクトのデータを蓄積し、生かすことは、見積など、計画の予測を立てるのに非常に役に立つはずです。

それがないのに現場任せにして、現場にいるSEが潰れていく・・・というのは悲惨な状況に思えます。(そういう会社はSIベンダではなく、ただの派遣屋さんだと思う・・・。)


さて。では素晴らしい管理方法があれば、じゃあ素晴らしい品質のシステムを作るんだね、という話になりますが、それはそれで違う話なのかもしれません。

システムの品質を示す尺度には、性能、信頼性、保守性、可用性、安全性、そして顧客の満足度やユーザビリティなど、いろいろあると思います。

プロセスの管理さえしっかりしておけば、これら品質もすべてOK。とは単純にはいかないように思えます。

インターフェースのデザインや、いろんなケースを想定したエラーハンドリング、ソフトウェアの性能を上げるアイデアなどマニュアル化した「管理」のプロセスだけでは生み出せない、クリエイティブなものです。

なので、品質をつぶしたバグのカウントなど定型化した分析だけで測定しても、品質の実現を妨げる問題がすべて洗い出せ、ユーザが満足する物が常にできるとも限らないはずです。

とは言え、その中でも出来る限り人に依存しないプロセスを作り、無駄を省くことは、コストを意識する組織にとっては有益な事です。

クリエイティブな作業と思われる部分をマニュアル化してしまうと、新しい事は出来なくなりますし、嫌がる技術者もいるでしょう。

しかし、既にどこかにあるような物を作るのに、毎回、同じようにクリエイティブする「車輪の再発明」のような作業は、楽しい時もあるのですが、やはり無駄に思えて仕方ありません。

車輪の作り方のマニュアルがない自動車屋で「車輪の再発明」作業ばかりで食いぶちを稼ぐ生活は終わりにしたいものです。

 



zeroaka at 18:56|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2007年06月11日

CodeMonkey

このエントリーをはてなブックマークに追加
こんなプログラマは嫌ぁ〜。

猿プログラマの歌

Code monkey - Wikipedia



zeroaka at 23:01|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2007年04月29日

IE6とIE7で検証する方法

このエントリーをはてなブックマークに追加
IE6とIE7で検証する方法

IE7を入れたPCでIE6を動かすスタンドアロン版のIEについて載っています。

参考になりますね。



zeroaka at 02:24|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2007年03月25日

上流、下流、どっちが儲かるの?

このエントリーをはてなブックマークに追加
前回の見積もりの話で、「不確実性のコーン」という図を紹介しました。

システムの開発の工程と見積り精度の関連グラフです。

これにIT業界で仕事を行うときのよくある仕事の分担の例を追記してみました。


不確実性のコーン


さて、この図の分担にある担当ベンダのうち、どこが一番儲かるのでしょうか?

そして、どこが一番もうからないのでしょうか?

この図なしに考えたとき、一番儲けるのは元請けベンダ、そして一番もうからないのは利鞘をたくさん抜かれた末端の三次受け、オフシェアということになります。

しかし、この図を見ると、一番正しく見積もりがおこなえる可能性があるベンダは三次請け、オフシェアのベンダになります。

システムの開発で利益を出すこと。それは求められる品質を持った製品を予算の範囲でいかに原価を抑えて作ることにあります。

そのためには確実な原価の見積りが必要になります。

ということは、これらのベンダの中で確実に儲かる可能性が高いのは三次請け、オフシェアのベンダ、ということになるはずです。
それなのに儲かっていないのはなぜでしょうか?

そもそも下記のような事をしている事が原因かもしれません。

・正しい手法による見積りをそもそもやっていない。

・正確な見積りを出したのにもかからわず、
 受注元の圧力に負けて訂正してしまう。


・正確な見積りの結果、原価がオーバする事が解っていながら、
 全く仕事がないよりかマシと考えて受注してしまう。

これらをやってしまうのは日本の企業が多く、海外の大手オフシェアを行っている会社は、受注元の圧力に負けず、きちんと原価管理をして、確実な儲けを出していると考えられます。

そして、逆に儲からないはずの元請けのベンダで儲かっているところは下記のような事をしているかもしれません。

・工程が進み、原価が予算を上回ることに気づいていながら、
 下請けをうまく説得して、低予算の見積りで仕事を受注してもらう。

・とにかく原価が安い海外オフシェアに早めに出す。

・顧客が原価に対してシビアでないので、
 だいぶ多めの見積り金額で受注している。

さらに見積りもあまり正しく行えそうにないし、あまり元請けベンダのような事もできない下請けベンダあたりは一番損なのかもしれません。

システム開発では、何かと上流が儲かる、上流が偉いという信仰がありますが、ビジネスとして正しく利益を出すことを考えるには、上流、下流のこだわりというものは無くしたほうがよいのではと、最近よく思います。



zeroaka at 05:53|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2007年03月06日

ソフトウェア見積り 人月の暗黙知を解き明かす

このエントリーをはてなブックマークに追加
システム開発を行う人であれば、誰でも悩む見積り。

いわずともなく自分も、その一人。
そんな悩みを解消すべく、こんな本を読んでみました。

ソフトウェア見積り 人月の暗黙知を解き明かす

その中でちょっと気になった内容をいくつかあげてみます。


・不確実性のコーン


 プロジェクトの初期の方が、見積りのばらつきが高く、プロジェクトの工程が進むに従って、
 コーンを描くように見積りのばらつきは減っていく、とうものです。
 こんな感じで。

 これについてはいろいろ考えてしまいますので、別の機会にいろいろ話したいと思います。


・見積りに見落としがちなプログラミング作業以外のアクティビティを見積もろう。


 これは基本ですね。
 開発環境のマシンのセットアップ、ドキュメントレビュー、
 パフォーマンスチューニングなど、よくよく考えてみると、いろいろあったりします。


・即興の見積りが首を絞める。


 よくある話ですね。
 「ざっくりどれくらい?」とさりげなく聞かれて適当に答えてしまい、
 その値があたかも正式な見積りであるかのように一人歩きしてしまい、
 後で正確に見積もってみたら、全然かけ離れて足りない工数で大後悔、
 なんて話はホント笑えません。


・規模の不経済


 ソフトウェア開発の規模は10倍になれば、工数も10倍ではなく、
 それ以上の工数を必要とし、生産性は下がり、単体コストはあがるという不経済が発生します。
 これについての原因の例としてコミュニケーション経路の増加を述べています。
 たとえば、10人のチームのコミュニケーションの経路は45、
 3人のチームの場合は3、よって3倍の人数で9倍の経路になると。
 よって見積りには規模による複雑性を考慮にいれる必要があります。


・見積りの政治力学を減らす


 これはソフトウェアの見積りツールを遣ったり、過去の実績値などを軸にした、
 故意の調節が利かない見積りを作りましょうというもの。
 個人の判断など、調節が利くような部分を見積りに残すと、政治的な圧力で、
 結局、相手が望む数字に近づくようになってしまい、正確な見積りとは
 程遠いいものになってしまいます。


・最良のケースの見積りと最悪のケースの見積りの両方を行い比較する。


 楽観的な考えと悲観的な考えの中間をとるのが効果的、ということでしょうか。
 この本には、見積りから期待ケースをとる公式がのっていましたが、
 その公式の根拠は・・・やっぱり結構適当じゃないかと思ったりして。


・標準的な見積りプロセスを使う


 これは先ほどの「政治力学を減らす」にも通じますが、見積りプロセスを標準化することで、
 プロセス自体についての議論の余地=調整の余地がないようにして、
 故意のアウトプットのコントロールを避けましょう、ということです、
 
・WindowsNT3.1の開発とスペースシャトルの打ち上げプロジェクトの工数

 WindowsNT3.1の開発規模はなんと、2000人年。予算にして、2億ドルだそうです。
 びっくりです。
 スペースシャトルの打ち上げプロジェクトはその10倍の規模。
 最新のWindows Vistaの開発工数は一体どれくらいの規模になっているんでしょうか?


と、以上、気になるところについての感想です。

で、結局読んだ全体の感想というと、見積りというのはあくまで予想で、
100%完璧な見積り方法というものはないのかな、と。
見積りした数値に10%以内の誤差しかなければ十分性格な見積もりだとも、
この本は述べています。
しかし、その10%が、カツカツなシステム開発で、
わずかな利益を出すのに必要な部分なんですよね。

ですが、この本で書いてある対策は200%や300%の見積もりミスによる
大惨事を避けることには十分効果があるように思えます。
そういうデスマーチプロジェクト、世の中には多いですからね。

ではでは。




zeroaka at 02:12|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2007年02月26日

kizasi.jp 今日、ブログで話題になったことって?

このエントリーをはてなブックマークに追加
最近気になるサイトにkizasi.jpというサイトがあります。

巷のブログサイトで流行っているキーワードをランキング表示してくれるサイトです。
サービス内容はテクノラティのキーワードランキングとちょっと近いかも。

ずっと前から、こんなサイトがあったらいいなと思っていたのですが、それ以上に気になるのは、このサイトがCACという、日本の中堅SIerの会社から生まれたからだったりします。

日本の中堅SIerで働く自分としては、いつかこんな新しいWebサービスを立ち上げてみたいかも、と、興味津々なのであります。

こんな開発者さんのインタービュー記事とか特に気になりますね。
「Kizasi Search Engine」開発者/Tech総研

なかなか苦労をされているようで、新しい技術を作る、そしてそれをサービスとして形にするということは根気のいるものだと再認識させられます。

こんなGoogleMapとのマッシュアップサイトも素敵です。

kizasiおでかけマップ

デートコースを考えるときに使うとしよう。

ではでは。



zeroaka at 00:19|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2007年02月22日

Oracle Data Provider For .NET (ODP.NET) と Oracle Objects for OLE (oo4o) の違い

このエントリーをはてなブックマークに追加
最近、今までずっとWebのJava房だったので、Windowsのアプリケーションのアーキテクチャーにはいまいち理解が低いと痛感。

OLEとかCOMとかさっぱりである。

そんなわけで今日もぐぐって調べてみる。

1.掲題の事に関するMicrosoftの分かりにくい説明。
http://www.microsoft.com/japan/msdn/columns/data/data03222001.aspx

2.掲題の事に関するOTNの分かりやすい説明。
http://otndnld.oracle.co.jp/easy/dotnet/oo4otoodp/index.html

結局、自分の知りたいことは内部の細かいアーキテクチャの仕組みより、そのアーキテクチャを選択する理由なのである。

なので、上の2のページのようにアーキテクチャの違いを簡単にリストアップし、それぞれのメリット、デメリットについて説明してくれると分かりやすいですね。

今回ODP.NETとoo4oを比較して、ODP.NETの利点とやらは

・非接続型でのデータアクセス
 (クライアントのメモリ内にデータを蓄積)

・コネクションプーリング

・データ変換等のオーバヘッドが発生しない

というのがキーワードかなと。

ではでは。






zeroaka at 10:38|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2007年02月14日

ASP.NET Ajax の使い方ビデオ

このエントリーをはてなブックマークに追加
“How Do I?” with ASP.NET AJAX

ASP.NET AJAXの使い方のチュートリアルビデオ

CODEZINEで知りましたが、マニュアルやソース読んでもいまいちピンとこないときは、このビデオで見ると分かりやすそう。

Microsoftは自社開発ツールの普及に力を惜しまないなぁ。

VisualStudioも無料のExpress版が登場したし、Javaやオープンソース技術への対抗は本気の姿勢ですね。





zeroaka at 14:48|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2007年02月06日

迷惑な迷惑メール対策 25番ポートブロック(Outbound Port25 Blocking)

このエントリーをはてなブックマークに追加
迷惑メール対策として
25番ポートブロック(Outbound Port25 Blocking)
が巷のプロバイダで最近大流行りである。

この対策って、プロバイダの解説ページには、さも迷惑メールを無くす対策であるかのように説明してありますが、この対策をしたところで海外からの迷惑メールは全く減りません。

この対策は迷惑メールの被害者であるユーザを守る対策ではなくて、プロバイダ自身が迷惑メールの送り元、つまり加害者にならないようにする対策なんですよね。

内容問わず通信を遮断してしまうなんて、自宅でメールサーバを立てていた人にとってはえらい迷惑な話です。

とはいえ、迷惑メールに対策はイタチごっこで100%効果的な対策がないのが現状みたいです。

たとえばPopFileなどに代表されるようにキーワードでスパムを分類するフィルターに対しては画像スパムという技があり、Paranoidチェックなど、ドメインの逆引き、正引き情報をチェックするフィルターには送信元ドメインを偽装するなどの技があります。以下は例で、私のNiftyのアドレスで迷惑メールフィルタを無事、通過してしまった優秀なスパムメールのヘッダをさらします。

--以下、ヘッダ---

Return-Path: ynrhgy6yu4yhhth@yahoo.co.jp
Received: by mbox62.nifty.com id 45c2eabd0d8a7c;
    Fri, 02 Feb 2007 16:39:41 +0900
Received: from mxg506.nifty.com by flt523.nifty.com with SMTP id 45c2eaba21365c;
    Fri, 2 Feb 2007 16:39:38 +0900
Received: from nifty.com ([222.162.249.57])by mxg506.nifty.com with ESMTP id l127dHSB023556
    for xxxxxx@nifty.com; Fri, 2 Feb 2007 16:39:21 +0900
Date: Fri, 2 Feb 2007 16:39:17 +0900
Message-Id: <200702020739.l127dHSB023556@mxg506.nifty.com>
From: 全国未放流収集倶楽部 <ynrhgy6yu4yhhth@yahoo.co.jp>
Subject: ティッシュの用意はよろしいでしょうか?
To: xxxxxxxx@nifty.com

--ここまで---

上記だと
>Received: from nifty.com ([222.162.249.57])by mxg506.nifty.com with ESMTP id l
の部分で222.162.249.57なんてアドレスはniftyでも何でもなく、こんな中国のドメインだったりするわけです。自由に使えるDNSサーバを用いて逆引き情報を偽装しているわけですね。やれやれ。

あと、今後新たに導入されそうな対策技術にはDomainKeyやSender ID、SPFなどがあります。

電子でないリアルの郵便はダイレクトメールが山のように着ちゃったりしますよね。?それと同じで、電子メールには相手を拒む技術が元からないのです。なのでいまさらこういった技術が導入されていくのですが、これからメールサーバを立てる人はここらへんの技術のおかげで間違って迷惑メールにされてしまわないように気おつけましょう。(あれ?)

余談ですが、迷惑メールフィルタなんてプロバイダによっては有料サービスだったりするようです。ケチいですね。
その上、その効果についてもはっきりいって期待できるものではありません。

容量少ない。お金取る。迷惑メールフィルタは使いものにならない、と3拍子そろって有料プロバイダのメールは不便極まりない状況です。

なのでGoogle信者の私としては
大容量(メールが無期限で残る)、タダ、迷惑メールフィルタは100%近い的中率、と3拍子そろったGmailを使わざる負えなくなるわけです。
GmailはWebメールの画面も使いやすいのでメールソフトを使う必要もないぐらいなんですが、メールソフトで送受信する場合はPOPやSMTPの通信がSSL対応していたりします。すごいですね。

おっと、結局Gmailの宣伝をするだけの話になってしまいましたね。

ではでは。




zeroaka at 03:07|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2007年01月15日

高DPI環境

このエントリーをはてなブックマークに追加
WindowsVistaを最近使ってみたが、画面のデザイン以外何が変わったのだろう?
と考え込んでしまう。

まだXPでいいやーと思ってしまうが、逆にその画面デザインの中で、今回注目したい新機能がある。

高DPI環境の対応である。

自分はWebブラウザはFireFox派でIE7なんて重たくて使ってられない〜と思っていたが、Vistaから標準となるIE7がFireFoxより唯一素晴らしいと思う機能がここ。

最近自分は家のリビングで離れた距離からPCを使うため、フォントサイズや解像度(DPI)を大きくして使うのだが、このとき、FireFoxは確かにフォントサイズはでかくなる。
しかし、表示されている画像までは大きくならない。

FF2.png


ところがIE7では画像も大きくなるのである。

IE7


高DPIの対応の必要性はMicrosoftからかなり昔から言われているが、実際、高DPI環境で使っていると、サイズが変わらないとか、画面レイアウトが崩れたりとか、対応していないアプリケーション、Webサイトなどかなり多い。
(Webサイトについてはテーブルタグ、フォントなど、px,point指定しているとこうなる)

実際、高DPI環境の滑らかなフォントを見るととても目に優しい感じで心地よい。

ノートPCや液晶モニタの解像度はどんどん上がり、PCをリビングで液晶TVに映して使ったりとする人も増えそうなので、今後高DPIの対応は備えた方がよいのかな、と

もうすぐ見えなくなってしまうノートPCのピクセル



zeroaka at 10:23|PermalinkComments(1)TrackBack(0)このエントリーを含むはてなブックマーク

2007年01月12日

Urchin

このエントリーをはてなブックマークに追加
全世界の主要企業が認めた最強のアクセス解析 Urchin(アーチン)

Google Analyticsで採用されているアクセス解析ツールである。

最近、仕事で触れる機会があり、そのときはそんなインパクトをうけなかったのだが、Googleで採用されている事例を聞くと、なんかすごいのかも?と思ってしまうのは完全にネームバリューに脳がやられている自分。

最近のGoogleは某MS社みたいにソフトをどんどん買収しているなぁ。
Googleの買収リストと今後の候補

このブログで紹介したBloggerやPicasaも買収物。

買収、合併を繰り返すとオリジナルの部分ってどこよって話だ。
あまりオリジナル部分がどうとか討論する意味はあまり無いんだが、最近のソフトウェアベンダーは合併が進みすぎて、もうどのソフトがどこが作っていたんだか分からない。三菱東京UFJ銀行の店舗が昔何銀行だったか思い出せないように・・・。

思い出

zeroaka at 10:31|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2007年01月11日

ホワイトカラーエグゼンプション

このエントリーをはてなブックマークに追加
巷で議論になっている意味がよくわからん。
まずはホワイトカラーというものの定義から考えなくてはならんと思う。

労働は時間ではない、とここでは言い切ってしまっていますが、デスクワークのお仕事すべてがそうとも限らないでしょう。

システム開発にはアーキテクチャやインターフェースの設計など、創造的な仕事もある一方で、「力仕事」と言われる単純作業も山のようにあるし、システム運用の仕事だとなおさらで深夜のシフト勤務での監視作業ように何も無くても時間を拘束される。

また、成果主義、成果主義というけれど、仕事の成果や仕事をした量なんてそんなに測りやすいものでしたっけ?

システム開発だったら何で仕事の量や成果を測ればよいですかね?

プログラムソースの量?バク摘出数?テスト項目実施数?設計書枚数?レビューでの指摘数?

はたしてそれだけでよい仕事をした、たくさん仕事をした、なんて測れるのかな?

そんな評価を考えるとき、リーダシップとかコミュニュケーションスキルとか、ますます数値化できそうにない言葉を持ち出す人もいる。

そういう人はこんな本を読んで考えてみてくれと思う。

G.Mワインバーグ
「スーパーエンジニアへの道―技術リーダーシップの人間学

そもそも仕事の量や質って、数値化して評価できないものがいっぱいあり、そんな中で唯一時間がすべての仕事で数値化できる指標なんじゃないですかね。

それを仕事量の指標にまずは使うのは全然ありだと思うんですが。




zeroaka at 03:02|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク

2006年04月26日

Network Grep

このエントリーをはてなブックマークに追加

パケットキャプチャのツール

http://ngrep.sourceforge.net/

テキストデータの内容を基にキャプチャしたい場合お手軽でいいね!

解説はこちら

http://www.atmarkit.co.jp/fsecurity/rensai/securitytips/027ngrep.html

 



zeroaka at 13:39|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク