最新の技術トレンドをエンジニアの視点で捉え、
なるだけ簡単にわかりやすく紹介して行きます。
メジャーなものからマニアックなネタまで、
テクニカルオールラウンダーなナビゲータが幅広くお伝えします。
ナビゲータ：渡部克治(ワタナベカツハル)
2009年03月31日
不況？恐慌？
どちらにせよ、今の世の中は大変な事になっています。
こんな時だからこそ、この時期をどう過ごすかで今後が大きく変わるものです。
成長するITエンジニアと成長しないITエンジニア、違いは何でしょう。
業務外でも積極的に技術を学ぶ
業務とは関係のないことであっても、技術を積極的に学びましょう。
資格や試験をきっかけにするのもアリですが、それらは本質ではありません。
学習効果を高めるためには経験の累積が重要ですが、業務で経験できる事はたかが知れています。
今、ノウハウや機会は組織の外に散らばっています。これをいかに効率的に拾えるかが、成長の鍵です。
新しい技術にチャレンジする
新しいことを恐れずチャレンジしましょう。
新しい分野の技術は、習得している人間が少ないため、相対的に有利になります。
今までのやり方に固執してはいけません。今の常識や世の中は変わっていきます。
変化に取り残されないためには必要なことです。
過去の歴史に学ぶ
新しいことばかりを追求せずに、過去も学びましょう。
世の中の大枠は、過去の繰り返しです。これは技術についても言えることで、
画期的と思えるものであっても実は過去の技術の流用だったり、大元の思想が同じだったりします。
過去、現在、未来と、時間をかけて歴史を学び続ければ、それが経験となります。
IT技術者以外にも当てはまるような気がしますが、
意外と続けることは難しいものです。
自分の将来像を思い描き、それに向かって日々努力しましょう。
2006年9月から、約3年に渡って投稿してきましたが、
今回が「エンジニアの視点」としての最終回になります。
長い間、ありがとうございました。
"エンジニアはどうするべきか"の詳細へ»
2009年03月19日
世間の認識と脅威レベルのギャップ——XSSは本当に危ないか？
http://www.atmarkit.co.jp/fsecurity/column/kawaguchi/013.html
今やエンジニアであれば誰でも知っていると言って差し支えないかもしれない、
クロスサイトスクリプティング（XSS）。
# ただし、正しく理解し、説明できる人間は未だ少ないのかもしれませんが…。
記事の内容は、XSSは危険だと過剰に煽られている感がある、とのことですが、私はそうは思いません。
確かに一般的なリスク分析では影響度と発生確率から考えて低リスクと考えられるかもしれませんが、
それは「今現在」の話であって、将来に渡ったリスク分析ではありません。
現在、大小内外様々なシステムにおいて「Web化」は規定路線であり、発生確率は日々高まっています。
また機密情報を扱うような重要なシステムでも「Web化」されていますので、影響度も高くなっています。
リスクマネジメントはPDCAサイクルによって実施され、評価、改善されていくのですが、
Webのイノベーションの進歩の早さにこのPDCAサイクルが追いつけない可能性が高く、
そうすると切り離せない技術コンポーネントであるJavaScriptなどでのリスク、
特にXSSのリスクが高まります。
皆がそう考えているのかは知りませんが、
そういう現状がある以上XSSへのリスク評価が過剰であるとは思えない訳です。
"本当のリスクとは何か"の詳細へ»
2009年03月13日
興味深い記事比較。
景気後退の中、活況を呈するITアウトソーシング業界
http://www.computerworld.jp/topics/econo/135969-1.html
「目下、大手アウトソーシング企業は好調だ。新しい見込み客から次々と引き合いが舞い込んでいる。市場の減速はいまだ見られない」と、市場調査会社Gartnerのリサーチ担当副社長、ベン・プリング（Ben Pring）氏は語る。
専門性・顧客満足・効率性の向上がSIerを救う
http://itpro.nikkeibp.co.jp/article/OPINION/20090312/326435/?ST=solution&P=1
下請けでは経営が立ちゆかなくなりつつある。手掛けるプロジェクトの数が減ってきた大手SIerは内製化を進めたり、中堅・中小SIerとの取引を減らし始めたりしている。ある大手SIer幹部は、こういった動きを受けて、人月単価の引き下げを了承する企業も出ていると話す。
クラウド、SaaS、オフショアと、海の向こうではアウトソースが活発化しているようですが、
一方で国内は、コスト削減・効率化を名目にインソース化が進んでいるようです。
そんなに日本国内企業は海外の企業と比べて、無駄や非効率が多かったのでしょうか？
程度の違いこそあれ、ITを使っている前提では業務効率にさほど大きな違いはないように思えますが…。
この不況下でも売上を伸ばしているところは伸ばしていますし、
周囲の環境への適合が違うだけで、同じセールスアイテムでも売れる売れないの結果が違います。
結局、経営と人に対する考え方、サービスに対する考え方、が決定的に違うことが原因なのでしょう。
個人的には、これを機に国内のゼネコン体質と人月主体の考え方もそろそろ壊滅して欲しいところです。
"不況下におけるアウトソースとインソース"の詳細へ»
2009年03月03日
ある程度のシステム規模になれば、ネットワークインフラを効率的に管理するために、
いわゆる「運用監視ツール」が使われます。
これは、基本的には独自のエージェントプログラムやSNMPなどのプロトコルを使って、
サーバやネットワーク機器の状態を監視、統合管理するソフトウェア群です。
OpenView（HP）
https://h10078.www1.hp.com/cda/hpms/display/main/hpms_home.jsp?zn=bto&cp=1_4011_306__
JP1（日立）
http://www.hitachi.co.jp/Prod/comp/soft1/jp1/index.html
Tivoli（IBM）
http://www-06.ibm.com/jp/software/tivoli/
あたりが有名どころです。
# OpenVIewってブランド変更されていたようですね。今知りました（苦笑）
# 「HP Software」と言うようです。現場ではOpenViewのままでしょうが…
オープンソースでも、
Nagios
http://www.nagios.org/
Zabbix
http://www.zabbix.com/
などが有名です。
（小規模かつ昔前なシステムなどではMRTGやBigBrotherなどが現役の所もまだあるかもしれません）
これらのように有償、無償含めて様々ありますが、実のところ、これと言った決定版は無く、
導入されているソフトウェアは組織によってまちまちです。やはり肝となるのは、
これらのソフトウェアで集めた情報をどうやって上手く運用するか、になります。
障害検出やその対応、連絡、エスカレーションなど、運用のフローが重要です。
最近のBPM（Business Process Management）などを見ていると、
今後はそういう支援も運用監視ツールがしてくれるようになるのかもしれません。
"運用監視ツールの将来像"の詳細へ»
2009年02月17日
エンジニアにはCLI（Command Line Interface）大好きの人間が多いはず。
今日はこんなサイトを紹介します。[via 100shiki]
http://www.commandlinefu.com/
コマンドライン一行で色々やれる知識を共有するサイトです。
ありふれたものもありますが、中には感心する程、面白いものもあります。
私が気に入ったのはこれ。
$ python -m SimpleHTTPServer
カレントディレクトリのファイル一覧をHTTP（ポート8000）で参照できるようにします。
http://hostname:8000/でアクセスすればファイルが取得可能になります。
セキュアではありませんが、わざわざWebサーバを入れなくともHTTPでファイルを送れるのは便利。
他にも色々ありますのでエンジニアであれば、初級者から上級者問わずおすすめです。
"CLIの鬼"の詳細へ»
2009年02月12日
ふと目に止まった記事。
Linuxに勝てなかったPlan 9
http://www.atmarkit.co.jp/news/analysis/200902/09/future.html
Plan9…。いつぞやのオープンソースカンファレンスで盛り上がっていたのを思い出します。
Plan9を知らない方は、Wikipediaを参照してもらうこととして、
2002年以来、開発が止まっているとは知りませんでした。
しかし、「未来の技術」とか「ベターソリューション」の多くは、現行技術やコモディティ化した一般技術を置き換えるほどに良くはない、という一般論には妥当性があるかもしれない。
good enough。そういえば、Economistでも見た記憶があります。
Less is Moore
http://www.economist.com/opinion/displaystory.cfm?story_id=12932356
ムーアの法則とNetbookの話。「less is more」と掛けているあたりセンスがいいですね。
仮想化やSaaSも“good enough” computingとして挙げられています。
これから新しいソリューションやサービス等を考える場合、
bestを知りつつ、それをgood enoughに落し込むのが成功への近道なのかもしれません。
"ITビジネスのヒント徒然"の詳細へ»
2009年02月03日
Linux, Apache, MySQL, PHPを使った
Webアプリケーションシステムの開発手法をLAMP開発と呼びます。
Wikipediaによると、98年にドイツのコンピュータ雑誌で提唱されたのが起源だそうです。
MySQLがPostgreSQLになったり、PHPがPerl、Ruby、Pythonになったり…と
コンポーネントが若干変わることはありますが、私の知る限りでは、当時からの意味合いとして、
オープンソースコンポーネントの寄せ集めWebシステムをLAMPと呼んでいたように思います。
# LAPP/LAMRなどの呼び方もあるようですが、あまり一般的ではないような…。
一方でWISA、なんて表現もあるようです。（個人的には初めて聞きましたが…）
Windows, IIS, SQL Server, ASP.NET。
うーん。
ここ数年のトレンドとしては、
Ruby on RailsのようなRapid Frameworkでアジャイル開発が人気ですが、
フレームワークまで突っ込んで考えるよりも各コンポーネントだけを気にすればよいため、
LAMP開発の方がアジリティが高かったりする場合もあるのですが…（苦笑）
まだLAMP開発が現役で組まれているところも多いようです。
結局、実装の良し悪しは設計次第なので、出来ることなら良く考えてから作り始めたい所ですね。
"オープンソース開発手法あれこれ"の詳細へ»
2009年01月27日
この時期のインフルエンザよろしく、
USBメモリにも感染するウィルスであるDownadupワームが猛威を奮っていますが、
金融系ならともかくUSBメモリを明確に禁止している所は、まださほど多くはありません。
思えばネットワークに繋ぐだけで感染するBlasterワームが蔓延した頃、
それまではノートPCなどを組織のネットワークに繋いで使用することが出来ていましたが、
Blasterワームをきっかけに、一気に「PC持ち込み禁止」の組織が増えました。
残念なことですが、恐らくは今回のワームに関連して、
しばらくすればコモンセンスが形成され、「USBメモリ禁止」の組織が増えるのでしょう。
セキュリティと利便性はトレードオフ、そういう考え方をしている限り、
あれも禁止これも禁止と、自らを縛りつづけることになります。
利便性を保ちつつ、安全性も確保する。
テクノロジーはそのためにあり、それを実現するのが技術者です。
運用でしか対応できないのは、技術者の怠慢だと私は思います。
Downadupの駆除方法
http://www.symantec.com/ja/jp/security_response/writeup.jsp?docid=2008-112203-2408-99&tabid=3
AutoRunの無効化
http://www.us-cert.gov/cas/techalerts/TA09-020A.html
"テクノロジーは何のためにあるのか（Downadup対策）"の詳細へ»
2009年01月16日
Nortel NetworksがChapter 11（米連邦破産法）を申請したそうです。
http://www.nikkei.co.jp/sp2/nt242/20090114AS2M1403J14012009.html
奇しくも、昨日まで同社のスイッチであるAlteonをいじっていた個人的事情も関係しますが、
老舗なだけに、少々驚きました。
米国の金融危機の影響から、不動産、金融、自動車以外に、
ついにIT業界にもこの再編の大波がやってきたのかもしれません。
日本国内の多くのシステムインフラは、
ノーテルに限らず海外ベンダーの機器に依存しているため、影響は避けられないでしょう。
# トップシェアの某社が倒れたらとんでもないことになりそうですが…
どこかが買収するのかもしれませんが、今後に要注目です。
"ノーテルが破産"の詳細へ»
2009年01月08日
何かしらのセキュリティ要件で、「暗号化をしているから大丈夫」という事を聞くことがあります。
セキュリティ意識の高いユーザであれば、そんなことはないことはよくよく承知の事ではありますが、
リテラシーの低い人間を相手にする場合は、これで通ってしまうケースがよくあります。
魔法の言葉「暗号化」。
これだけで安心してしまうユーザが如何に多いことでしょう。
ITにおける暗号の仕組みの多くは、「計算の複雑さ」を根拠にしています。
時が経つにつれ計算機の処理能力が上がるため、暗号の仕組みは相対的に複雑でなくなります。
また、その仕組みそのものに問題が発見される事もあります。
セキュリティ界隈ではMD5アルゴリズムはもはや信用ならない物として知られていましたが、
今回、MD5を利用している証明書（SSL）を偽造することが現実的な時間内で可能であること
の実証デモが行われました。
また、Netcraftによると、14%のWebサイトがMD5を利用した証明書を使用しているとか。
http://news.netcraft.com/archives/2009/01/01/14_of_ssl_certificates_signed_using_vulnerable_md5_algorithm.html
「暗号化」＝「安心」ではないという意識が必要で、
これらの啓蒙を行うことは、我々エンジニアの仕事の一つなのかもしれません。
"暗号はいつまでも暗号ではない"の詳細へ»
