So-net無料ブログ作成
検索選択
システム開発 ブログトップ
前の10件 | -

SAKURA VPS を借りて最初にやったことメモ [システム開発]

 久しぶりにLinux を触ろうと思ったらあまりに久しぶりでまともに触れなかったので、恥を忍んでBlog 勉強シリーズとして SAKURA VPSを借りてやったことをメモ。このレベルかよとか思われること必置だと思うがめったにやらないことはこうやってメモを取っておかないと毎度同じ苦労をすることになるので書き残しておくことにする。さらについでに覚えられればそれに越したことはないw

 基本的に学習目的なので、具体的な目標というものはあまりなくなんとなく外向けのサービスが作れるレベルまでの設定を一通りやっておきたいという感じ。

1.SSHクライアントのインストール
 筆者の環境は基本Windows Client なので、定番のTeraTermをダウンロードしてインストール。クライアントPCにSSHクライアントすら入ってないのかよとかの突っ込みはなしでw

2.SAKURA Internet で契約
 VPSサービスの紹介ページから 1.0G プランを選択して契約。VPS はもちろんSAKURA事態のサービスが初めてなので初回2週間無料。初契約だったので住所やクレジットカード等の番号入力を行って自動採番されるID/サービスコードのメールと、サービスコード/サーバのIP/rootパスワードが記載されたメールをもらう。

 この時点でいそしんでTeraTermでつなぎに行って失敗。ping すら返ってこないことでサーバを起動するというフェーズが必要だということに思い至る。 orz.

3.サーバの起動
 届いたメールをろくに読まないというのはいつものことなのだが、よく見ると2通目のメールにVPSのVPSコントロールパネルのURLが記載されているではないかw。早速URLをたどってサーバを起動し、無事にping の返信確認に成功。

4.サーバのIPアドレスを手持ちのドメインに登録
 さくらVPSで提供されるのはグローバルなIPアドレスである。ドメインを持っている(DSNサーバはレンタル)ので A レコードとして登録し、VPSのコントロールパネルで逆引きの設定。この順番を逆にやろうとするとSAKURA の逆引き設定で正引きができないといって怒られる。

5.サーバにログイン
 とりあえずこの時点でTeraTerm から root 権限でサーバにログイン。やっと入れたよ. . .
 ついでに以下のコマンドを実施して 一般ユーザを追加してパスワードを設定。
#adduser myaccount
#passwd myaccount


6.サーバに関する初期設定
 なにが驚いたって20年くらい前とはいえ数か月はメインエディターとして使っていたviのコマンドをろくに覚えていなかったことw(基本はemacs ユーザなので...)。一応カーソルの移動(h,j,k,l)や編集(i,I,a,A)、ワード削除までは覚えてたけど1文字削除(x)は出てこなかった orz. のでこのページをみがてら思い出して各種Configファイルを編集することに。

 まずは/etc/ssh/sshd_config の設定で以下の内容を編集
編集前編集後内容
#Port 22Port 10022sshの通信ポートをデフォルトから変更
#PermitRootLogin yesPermitRootLogin nossh でrootアカウントによるログイン禁止

 その後、以下のコマンドでsshd を restart!
# /etc/init.d/sshd restart

 次に、SAKURA社長blogをみて各種デーモンを停止しようとしたが、chkconfig コマンドがない. . .man には出てくるし、探してみると/sbinにあるんだけど、標準ではpath は/sbin/ にとおってないと思って調べてみたら、一般ユーザから su した場合は /sbin/に pathがとおってないらしい。なるほどそれは妥当かも..

7.パッケージ管理について勉強
 筆者がUNIX をまともに触っていた頃っていうのは仕事で触っていた期間は数か月しかなくしかも相当昔の話である。趣味でLinux を触っていた際もSlackwareとかまだパッケージコマンドなんてものがないディストリビューションでRPM何ぞやの世界の人間である。なので基本的なところからちょっとお勉強。

 参考にしたのは以下のページ
  ・@it yumコマンドでよく利用するコマンド
    RPM知らない人間がYUMかよとか言われそうですが... 基本コマンドを知る。
    でも、check-update と list updates の違いがよくわからない。
  ・@it Linux Tips インストール/RPM
    Tips を眺めてパッケージ管理の片りんを探る

 でもとりあえず yum check-updates で出てきた内容を更新かけていいのかがわからない... orz
 でも、VPSコントロールパネルで「OS再インストール」メニューがあって簡単そうなので、とりあえずやってみるw
> yum -y update
 2012/1/3 時点でのパッケージのアップデート対象は 212で、新規インストールが6らしい。 全部やるのに数分しかかからなくてむちゃくちゃ簡単だったが、正直にいって大半がなんだかわかっていない。運用環境のサーバを多数構築する場合はその時点の最新でそろえると立てた日付ごとに内容が異なってしまうので、こんな単純に全部アップデート!なんてかけるべきではない。運用環境のバージョンはプロダクション/テストを含めてその日時点の最新ではなく全環境でそろえる必要がある. . .

 なのでとりあえず、ここではOSを初期状態に戻したうえでもう一回チャレンジ!とりあえず今日はここまで。

勉強になりました!

Simple is best.
--
butineko

正味10ツイートでクラウドを紹介してみる [システム開発]

 またもTwitterネタを転載です。

1年前にクラウドと呼べるようなものは、amazon ec2/s3, Google App Engine, SalesFource の3社だけでした。いまではメーカーも提供していますが、まともなのは 上記3社+Microsoft Azure くらいなものだと思います。
でも最初の3社でも提供しているレベルはまちまちで、当初Amazonは分散DB+インフラがメインで、googleやSalesForceはそれに加えて分散処理が可能なプラットフォームとその開発環境を提供しています。
一般的に言われるクラウドの特徴のひとつが課金単位で、レンタルサーバのサーバ1台/月でいくらだったのが、クラウドではCPU利用時間、帯域利用時間、データ保存時間など分単位、MByte単位で課金されるのでちょっと利用から大規模利用まで利用分だけ課金されるので余剰が出にくいです。
クラウドのもう一つの特徴がリニアにスケールするプラットフォームとその開発環境です。
いままではサーバにPHPやJavaでプログラムを書いた場合、そのCPUが満杯になるとサービスが停止します。その分散にはWeb/Ap/DBサーバの分離という垂直分散やレイヤ4スイッチによってWebサーバを何台も配置する水平分散など結構手間をかけて負荷分散を行ってきました。
で、環境がそろったGoogle App Engeineを例にして負荷分散をどうすればいいかというと、1.アプリつくる 2.Google App Engineに配置する とこれだけで自動的にアプリケーションのCPUやデータベースディスクアクセスを...
たったこれだけの処理で、何百台、何千台のマシンを使って負荷分散してくれるんです。
娘がうんちらしいので中断。
たとえば、企業で1週間のキャンペーンで1週間だけ膨大なサーバが必要になったとしてもレンタルや購入では無駄が多く、膨大なアクセスをリニアにスケールする仕組みを作るには結構な技術が必要でした。
あ、うんちから復帰です。
それを、print("Hello World!!") みたいなプログラムをクラウドに配置するだけで、数万アクセス/秒のアクセスでも耐えられる仕組みになったんです。
娘のうんち処理を含めて30分でわかるクラウドおしまい。

Simple is best!
--
butineko


クラウドだからできたのか? [システム開発]

 2010年4月21日付の日経新聞朝刊の1面の記事について電車の中から立ちながらtweetした内容だが、tweetしっぱなしにするのがもったいなかったのでblogにも転載します。

エコポイントシステムで、大手ITが最低3か月は欲しいと言った事に対してセールスフォースが1ヶ月でできたのはクラウドだからじゃない。クラウドのほうが技術的な要件が少ないのは確かだが、要は要件を満たすエンジニアがいたからだ。 今日の日経朝刊、クラウド広がるより

要件を満たすエンジニアさえいれば普通のDCでも構築できるし、いなければクラウドだってできはしない。メディアがどう叫ぼうが残る技術は残るし、残らないものは残らない。流行りでスーツを踊らせても判断を誤る人が増えるだけだ。


favやRTとかしてくれた人ありがとう。

Simple is best.
--
butineko

『豊田通商社長が語る「普通の会社のITの話」』 について考えてみた [システム開発]

 ITメディアの記事にあった『豊田通商社長が語る「普通の会社のITの話」』について、エンジニアとして勝手に記事の内容を考察してみたくなったので記録する。先に断わっておくと、私は豊田通商を含む商社のシステムを知らないし、考えながら書いた記事なのでまとまりがない。

 まず、トヨタ自動車から2001年に移籍した清水社長は、2001年の移籍当時のITシステムの状況を以下のように語っている。
「悲惨なレベルのIT」
「2000年に独自会計システムの導入を目指したが失敗」
「他社の10年は遅れている」
 とまぁ、悲惨な状況に見えたそうだ。また、清水氏は2001年当時のシステムの失敗をこう分析している。
 独自システム開発では、「(ユーザー部門の)要望を聞き入れすぎてプロジェクト管理が機能せず、最後に品質が確保できなくなった」

そこで実施したのが以下の内容。
「情報システム部では限界があると判断しIT推進部を発足」
「会計システムにはSAPを導入」
「5年で150億のIT投資を決断」
「トヨタグループの自動車関連部品のグローバルSCMを展開」
 上記のことを実施して「ITを強みとして強化した」とまでは書いていないが、「そう読み取って」という感じの記事である。

 上記の内容だけをインプット(前提)として2001年当時に何が問題だったのかを勝手に推測してみることにする。※ことわっておくが、以下は清水社長の短い発言を基にした記事をインプットとして得られる内容を考察しただけで、当時の豊田通商のシステムおよび関係者がそうであったということではない。

・除外要因
 まず失敗の要因として関係なさそうなものを除外すると「トヨタグループの自動車関連部品のグローバルSCMを展開」は除外となる。売れるサービスをつくってロイヤリティが入ってきたのは成功要因ではあると思うが過去の失敗とはあまり関係がない。

・普通の会社の情報システム部
 次に、発言内容を考える前に「普通の会社のシステム部」を考えてみる。元来システムというものは目的を達成するために存在するものだが、その為には人間の言葉を理解しない機械に対して、機械の言葉であれこれと指図する必要があり、大きなシステムを作る場合は機械と会話できる稀なスキルを持つ人を多く集めないと出来ない為、そういう人を集めたり育てたりするのが「普通の会社のシステム部」だ。
 こういう意図で集められた人員は機械と話をすることが得意な人間は多くてもそれ以外のスキルを求めても難しいのは容易に想像がつく。わかりやすい例でいいかえると、海外の人とコミュニケーションをとる為につくられた翻訳部に、戦略的な仕事や翻訳という仕事と関係はしていても門外漢のこと(例えば洋書の小説を作れとか)を求めるには普通無理があるのだ。

・発言について考えてみる
「(ユーザー部門の)要望を聞き入れすぎてプロジェクト管理が機能せず、最後に品質が確保できなくなった」

 これは当時の会計システムの失敗の理由だが、会計システムというのは多くの部署と人がかかわるシステムで、ユーザー部門はそれぞれ自分達があるとよいと思う機能をどんどん要求してくる。システム部は限られた予算や人員の中で会社を上から俯瞰する立場でもないにもかかわらず、どの部門の要求は受け入れてどの部門の要求ははねのけるという選択をしなければならない。
 そういった判断はおおむね会社に必要な機能を優先というよりは、声の大きな部門(人)の要求をのみがちになり、声の大きな人ばかりだと多くの機能要求を受け入れざるを得ない状況となり、機能が肥大化するのである。  システム部としては機能が肥大化すればするほど、設計が複雑になり多くの要員や予算が必要になるのだが、通常予算はプロジェクト発足時に決められており予算の増額は容易なことではない。

ここで「XPエクストリーム・プログラミング入門」のケント・ベックの言葉を紹介
第4章 4つの変数より
コスト、時間、品質、スコープ
このモデルでのソフトウェア開発ゲームのやり方は外部の力(ユーザ(顧客))、管理者が3つの変数の値を決める。開発チームは残った番目の変数の値を決めることになる。

 これにならって、犠牲となったのが品質だったのだろう。ユーザ部門の権力が強い場合は陥りがちな問題である。

・解決への道
 これに対して「情報システム部では限界があると判断しIT推進部を発足」で、「普通の会社のシステム部」の問題を克服し、ユーザ部門との交渉に負けない『人』を配置する。
 次に「会計システムにはSAPを導入」で『モノ』を配置。これによって会計システムの構築スピードをあげることが可能になったのだろう。ちなみに上場企業の会計システムはどこでも似ているようで実は結構大変なカスタマイズが必要だ、過去の決算と齟齬がないように会計基準を合わせる必要があるし自社の強みとなる業務システムとの連携も必要だ。
 最後に「5年で150億のIT投資を決断」で『金』と『時間』を設定して、少々のオーバーな要望であろうが品質を確保するのに足るものをそろえて解決に至ると読んでみた。
 結果を出した経営者の話を真に受けて参考にするかどうかは置いておいても、元記事にも書いてあるように失敗した話を参考にするのは為になるように思える。


XPエクストリーム・プログラミング入門―変化を受け入れる

XPエクストリーム・プログラミング入門―変化を受け入れる

  • 作者: ケント ベック
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2005/12
  • メディア: 単行本


Simple is best.
--
butineko

自宅の仮想化環境をVMWare系に統一してみようかと奮闘中です。 [システム開発]

Mac ソフトのことなら act2.com えー、自分の個人宅ではマシンがそれなりの台数があるにもかかわらずハードウェアの仮想化環境も必要でありマシンの数はともかくOSの数なんてまともに管理できていない状況です。どうしてこんな状況かというと、仮想化環境を時代の流れとか仕事の都合とかMACでモバイルとかお金払いたくないとか...そんあなこんなで行き当たりばったりに導入してしまった経緯があります。

 個人で乗せるのであればコストは最重要項目なので、ちょっとばかし使いにくいとかよりもこっちのほうが大事だったりするわけですが、さすがにごちゃごちゃになりすぎてそうも言ってられなくなりつつあるのでVMWareへの統一を考えています。

まず各仮想化環境導入の経緯をすこし. . .

 最初に導入したのはWindowsに乗せるならということでMSのVirtualPC(当然ただになってから)です。しばらくこれを使っていたのですが、次にMacにVMを乗せる必要に迫られSun のVirtualBox(当然これもただ)に行き着きます。となるとWindows環境もあわせようとなってWindowsもVirtualBoxを入れたりしてVMの種類が増えていきます。

 しばらく運用しているとしているうちにハイパーバイザー型なるものもただで利用できるようになり、サーバを立てる必要になると、MSのHyper-Vも試そうかと準備まではしたのですが、またVHDのMS系に戻るのか?MSはMAC製品やめちゃったし統一できんじゃん。と思いとどまって考えてみているうちにVMWareへの統一に思考が傾いていきました。

選択肢はVMWare以外なし!?

 実はハイパーバイザ/Windows/Macのそれぞれで仮想環境をつくろうとした場合、その3つに最新の製品を提供しているのは実はVMWareしかありません。VMWareを利用するならどの組み合わせが安くすむのか?使いやすいのかという選択肢を検討してみることにしました。

 まず、x86系のハイパーバイザーの選択肢は、VMWare ESX(有償)とESXi(無償)があります。まだどちらも環境構築をしたことはなく使い勝手は良くわかりませんが、ESXは値段を調べるだけでも面倒そうなのでESXi確定です。(ちなみに後で調べたら今日現在では15万くらいでした。)

 次にWindowsのデスクトップ環境ですがこれはいくつか選択肢があり、メリデメがあります。

1.VMWare Workstation(有償、今日現在は26K程度でした)
 有償版のデスクトップ用の製品で使い勝手もよさそうなのですが、ちと高い。
2.VMWare Player(無償)
 VMWare Workstationの機能限定版で、既存の仮想環境の再生のみで新規の構築ができません。また構築後のOSにインストールする必要があるVMWare Toolsも付属しません。
3.VMWare Server(無償)
 運用向けの製品で、新規の仮想環境の構築や再生も可能でVMWare Toolsも付属するので、VMWare Playerと一緒に利用する上での障害もなくなります。しかし、運用用途向けの製品であるため、開発などでサーバにしょっちゅうログインするような環境には向かず動かしっぱなしの環境に向いています。

 MAC用のVMWare Fusionも有償(Amazonで11K程度)であることはわかっていたので、実はこの時点で一旦Mac環境の統一をあきらめて、ESXi+VMWare Server(仮想環境構築用)+VMWarePlayer(実行環境用)という方向で構築を進めたのですが、たかだかVM構築の為だけに使いづらいVMWare Serverのインストールをしなければならないというネックがあり、なんとかならんのかともんもんとすごしていたところ、なんと限定ながらVMWare Fusionのダウンロード版ならリーズナブルな金額で購入可能なことを知りました。

 5000円程度の費用はかかりますが、これならHyperviser/Windows/MacをすべてVMWareで統一でき、VMWare Playerの足らない部分もVMWare Fusionで補うことが可能とです。今はサーバをESXiサーバにリプレースすべくマザーを選定中の段階で、ここからしばらく忙しくなりそうなかんじです。

 MacとWindowsの両方でVMWareを使いたい方お勧めです!

 Act2のキャンペーンの概要
  VMWare Fusion ダウンロード版(パッケージなし)
  VMWare Fusion3への無償バージョンアップ
  限定1000本

VMWare Fusion 2 icon

Simple is Best
--
Butineko

ソースコードのコメントについてちょっとしみる事がかいてあった [システム開発]

アンドリュー・ハントとデビッド・トーマスの名著「達人プログラマー」に、ソースコードのコメントに関する記述があったのだがしみる内容だったのでメモ

達人プログラマー―システム開発の職人から名匠への道

達人プログラマー―システム開発の職人から名匠への道

以下P.253からの抜粋
 一般的にコメントは「何故」それを行うかという目的やゴールを記述すべきです。既にコードが「どのように」それを行うかということを表しているため、コメントでそれを記述するのは無駄な事であり、DRY原則に違反する行為となるものです。

 ソースコードへのコメントは、技術上のトレード・オフ、意思決定の理由、却下された代替え案、といったようなプロジェクト資料のどこにも記述されない難解なポイントを記述する為のものなのです。

 これはクラスや関数ヘッダーに書かれるような機能概要ではなく、ソースコード中に埋め込まれるコメントについて記載されたものだ。
 新人の頃はどんな内容をコメントとして残すのかよく悩んだものだ。今では感覚的にどんなコメントを残す/または残さないかはわかったつもりだが、人にアドバイスをする時にもやもやとした思いをうまく表現できずに困ったこががある。
 内部的にもやもやとしていた点について、明快で適切なコメント記述のデジタル表現を見つける事ができた為、あとはこの内容を適切に伝えられれば後ろを歩く人から白い目でみられることもなくなるだろう。

 新人の頃は仕様通りの内容をどうやってソースコードに落とし込むかが本人にとっての問題領域であった為、ソースコードの内容をそのままコメントとして残すことがしばしばあった。
 例えば、初めて調べた言語の機能やライブラリのリファレンスの内容などだ。これらは知らないプログラマーには多少役に立つかもしれないが既知のプログラマーにとっては邪魔ものでしかなく、知らないプログラマーもリファレンスを見ればわかる事である。少なくとも未来の自分にとってもあまり役に立たないものだ。
#ただ、新人のころは普通のプロがラマーが書かないコードを常に書いているものなので、処理したい内容を書いておいてくれれば、後に適切にリファクタリングする為に役に立つ可能性はある. . .

 コメントとして残すべき内容は、「プログラマーは通常なら違う書き方がをするが、あえて別の書き方をした」とか「記述方法や処理方法にいくつか選択肢がある場合にあえてその方法を選択した理由」などだ。
 私が記述して役に立ったと思う内容はSQLのパフォーマンスチューニングの内容だ。たとえばJOINや大規模なSQLの一発発行をさけてあえて複数回に分けた場合や、Where句に記載すればSQLでフィルタリング可能なのにあえてコードで判別した場合などだ。
 適切なテストケースやデータに対して複数の処理方法を試し、パフォーマンステストの結果該当のコードを選択している場合が多いが、こういったコードにコメントがないと後のメンテナーはコードの内容に対して疑問を持ち、下手するとリファクタリングと称してデチューンされる可能性がある。
 逆にコメントがなかった為に自らデチューンしてお客さんに迷惑をかけた事もある。(自分ではコードを短くしてリファクタリングしたつもりだったのだが. . .)

 要するに「[あえて]こういったコードを書いた」場合に「[なぜ]こういったコードを書いた」のかをコメントとして残しておくと有用なわけだ。

 本書の著者が伝えたい内容はもっと多義にわたるが、あえて外れたところで感心してしまったので紹介がてらメモしておきました。

【Tips】Windows Vistaでハードリンクやシンボリックリンクを作成する方法メモ [システム開発]

 Vista機でハードリンクシンボリックリンクを作成するためのメモ

 WindowsNT系のOSはNTFSによってずいぶん前からファイルディレクトリのハードリンクやシンボリックリンクが作成可能だったが何かと使い勝手が悪かった。2000はリソースキットが必要だし、XPのfsutilコマンドは実行に管理者権限が必要でかつコマンドが面倒(fsutil hardlink create newfile orgfile)といろいろと問題があったのだが、Vistaでようやくまともに使えそうになったのでメモしておく

・ハードリンクの作成方法
C:>mklink /H 作成ターゲットファイル オリジナルソースファイル


・シンボリックリンクの作成方法
C:>mklink 作成ターゲットファイル オリジナルファイル
C:>mklink /D 作成ターゲットディレクトリ オリジナルディレクトリ


 試してみたところmklinkの実行やハードリンクの作成には管理者権限は必要ないが、シンボリックリンクの作成には管理者(もしくはなんらかの)権限が必要なようだ。

 とりあえずハードリンクが気軽に作れれば事足りるのでこれ以上の深追いはなし。

--
butineko


利益優先の度が過ぎるMicrosoftのシェア低下をを望む [システム開発]

 個人的には今だに多くのMicrosoft製品を利用しているし、過去の功績としては大きなものがあると思っているが、最近のこの会社は過去の遺産から搾り取れるだけ取ろうとしているのが目に付き、忠誠心を持つユーザーをもどんどん手放すような方針が垣間見えるが大丈夫だろうか?

 会社の利益の出し方はいろいろだが、たとえばこんな利益の出し方がある。
  「イノベーションによる先行者利益」
  「低価格化およびシェア拡大による寡占利益」
  「独占による排他的利益」

この業界での例を挙げると、
 「イノベーションによる利益」はWalkmanやiPodなどの画期的デバイスの開発や、googleによる検索技術の開発など、広く受け入れられる価格で登場するとユーザから多くの賞賛が受けられ、ついでに先進的なブランドイメージというおまけもついてくる。

 「低価格化によるシェア拡大」は、時代によりIBMに対するCompaqであったりCompaqに対するDellであったりするが、たいてい商品のコモディティ化/低価格化を伴うため大きな賞賛を受けることも先進的なブランドイメージがつくこともないがユーザには喜ばれる。

 「独占による排他的な利益」とは、ユーザが安易に他製品に切り替えられないことを前提に、高単価を維持したり、いらない機能を抱き合わせることによって違う分野のシェアを伸ばしたりする方法で、あくどかったり度が過ぎたりすると、お上に怒られたり訴えられたりする。また、この手法は「既得権益」とよばれすこぶるユーザの受けが悪い上、場合によってはブランドイメージを傷つけることにもなる。

 「独占による利益」は利益の最大化を目指すとすれば間違いとはいえないが、ユーザ受けを考えるとあまりよい方法ではなく今のマイクロソフトはまさにこの手法のオンパレードだ。

 Windows 7について前評判がよいようだが、6つのエディションはどう考えてもマイクロソフトの利益を優先するためにしか見えずユーザに平均単価を上げる為と受け止められても仕方がないだろう。Windows7にせSnow Leopardにせよ、エンジニアから見ればブラッシュアップOSは明らかに買いの対象だが、Vistaゆずりのこのエディション構成は全面的にMacOSへの移行を考えるかの瀬戸際である。

 (新興国向けのstartarはともかく)エディションは基本的に2つEntepriseとProfessionalあれば十分で、価格はProfessionalがVista HomeBasec並 EnterpriseがVista Professional並としても利益の確保は十分に可能であろうし、付加価値を認めてほしいなら Plus!のように別売にすればよい。

 一般企業がクライアントOSをMacやLinuxに変えるのは大変だろうが、一般ユーザのEarlyAdapterはすでにWindowsから離れ始めている。今のWindowsに現在の高価格を訴えるだけの価値はすでにないように思えるのだがいかがだろうか。

好評「Windows 7」が阻む「Vista」企業導入--MSはアップグレードスキップに警告
Vistaにおける問題点をすべて解決しているわけではない、とSchuster氏は言う。企業は、XPからWindows 7へ移行するには、XPからVistaへの移行と同様のアプリケーションの互換性問題を克服しなければならない。Windows 7は、Windows Vistaと高い互換性を持つように設計されているが、XPからVistaへの移行を難しくしている問題は、XPからWindows 7への移行の場合も同様に発生する。

Vistaをスキップしようとしているユーザーへ
 上記のとおりXPからの互換性問題は7もVista同様に発生するとマイクロソフトも認めている。VistaをSKIPしようがしまいが互換性問題にあたるのであれば、評判が悪く先にサポートが切れるVistaを導入する理由はどこにもない。少なくともWindowsから逃げられない立場でここまで待ったのであれば遠慮なく7まで待つべきである。
--
butineko
 

DIとAOPがくっついている必然性について [システム開発]

今日は JJUGの基礎セミナーで「DIの基礎」について聞いてきました。

 DIやAOPは概念的には把握してたんですが今まで結局のところ利用する機会がなくて、懇親会で実践的なところがちょっときけたのはもらい物でした。セミナーの内容については気が進んだらまた書きたいと思います。

 で、懇親会で隣に座られたJavaが非ネイティブでまもなく上場されるネットベンチャーの方が座っていらっしゃっていろいろと積極的に質問されていて答えた内容をひとつ披露します。

 JavaのメジャーライブラリとしてSeasar2やSpringがあるが両方ともDIとAOPがくっついているのは何でかって話がありました。その場であまりうまく答えられたかどうかは聞いた人にまかすとして、この2つの内容がくっついてるのは偶然の要素と必然の要素があって、でも機能的にくっついていることのメリットってあんまりないんじゃないかと話してきました。

 まず偶然の要素としてはアーキテクチャとして同じような時期に注目されたこと。ここには2つがくっつくことのメリットはありません。

 次に必然の要素としてJavaを利用する限り両方ともコンテナという概念が必要だったことが上げられると思います。もちろんAOPにはJavaSDK5のアノテーションとか非コンテナ系の実装も可能でしょうが、コンテナという仕組みを利用すると、バイトコードや言語仕様をいじらなくてもJDK1.4で実装できてしまったりします。で、DIコンテナとAOPコンテナを別々に実装すると競合とかいろいろなことを考えなくてはならなくなってめんどいので、「じゃ、はやってるんだし一緒に実装したら都合がいいんじゃないか」的な発想でくっついているのではないかと思います。

 実際のところSpringにしてもSeasar2にしても、技術的な発展の流れを抑えているわけではないので間違っているかもしれませんが、くっついていることで実装がきれいとかコード量が減るとか、技術的に必然的なことはあまりないんじゃないかと思えたしだいです。

Simple is best.
--
butineko


今日のモチベーションを維持する為に(中島 聡 出版記念トーク&サイン会) [システム開発]






 今日、life is beautifulのブロガー中島聡さんのトーク&サイン会に参加してきた。私がもっとも尊敬するエンジニアで、本にサインしていただく際に一言お話しする機会があったにもかかわらず、まともに会話できなかった自分がなんともふがいなく自己嫌悪しているところです。「エンジニアとして大変尊敬しています」 -> 「どういった点でですか?」 -> 「常に新しいことを... しどろもどろ」といった感じで気の利いた会話どころか尊敬している点をまったく表現できなくて残念でならなかった。

 帰り道テンションが落ち着いたことろで、まともに会話できていたら何を伝えたかったのか(どういった点を尊敬しているのか)を考えてみた。

まず、
 ・半端でないハイレベルエンジニアである(当たり前のようにハイレベルである)
 ・高いビジネススキルを持ち合わせている
 ・人の心を動かす文書を書き続けられること

とこまでは今まで思っていた点だが、
これに加えて今日お会いすることで自分の中でしっくりきた点として

 ・強い芯をもっていること
 ・本人自身におもてなしの心があふれている

という点を本人には伝えたかった。

 対談相手の海部美知やアスキーの遠藤編集長が話しているときも常ににこやかな表情をして、自分が話すときもユーモアにあふれた会話に富んでいる。またサイン会の際には、サイン希望者が話しかけると気さくに質問を返したり「あなたに興味があります」ビームが発散されていた。

 今日のトークの収穫としていろいろな「言葉」があがるが、これらはみなひとつひとつを取り上げてエントリーにしたいようなねたばかりだが、今日のところは忘れないように列挙しておき、自分の中で消化できたら少しづつ書いてみたいと思っている。

中島聡語録


マイクロソフトねた
「マイクロソフトではみんな頭がゲイツになってく」
「ミニゲイツ」(遠藤さん)
「変人と普通の人の間の『プチ変人』はいっぱいいてよい」



会社と従業員の関係について
「『普通そういうことはしないよ』という言葉の暴力」
  最初に就職した会社を辞める際に辞表を受け取ってもらえなかったときのエピソード
「ITゼネコン」
  SIベンダー全般のことだとおもうが、官僚接待の例をだしていたのは元いた会社のことか?
「エンジニアの幸せを伝えたい」
  Googleの売上げのうち9割の価値はエンジニアが作っているが、ITゼネコンの売上げの価値の9割は営業が作っている。
「日本人はナイーブな人が多い」
「上司がいやで『上司が悪い』というだけでは思考停止だ。上司がいやなら上司の上司にかけあえ」
「私は上司を二人クビにしている」
「上司と部下の関係」
  アメリカの会社は上司と部下の関係が強く、上司が会社を移るとみんなで出て行く
「技術を引っ張っているのは会社ではなく人である」
   (RISCの論文を出している会社が何社あっても、結局同じ人が書いている)
「会社は乗り物でしかない」
「会社の目標のためにはガソリンが必要でそのためにはまず最初に設ける必要がある」



エンジニアとして
「エンジニアはもっとビジネスを意識すべきだ」
「一定量のトラフィックを100台のサーバでこなすか、1台のサーバでこなせるかを決めているのはエンジニアである」
「その人にとっての財産は『会社を作ったときに来てくれる人がどれだけいるか』や    同僚が会社を作った時に『きてくれ』といわれるかどうかで、それは人生の武器になる」
「時間給のビジネスはいずれインドや中国と同じレベルになる」
「英語がなければ始まらない」
「なにかをきっかけにして変わる必要を感じたらとにかく続けること」  続けること、続けること、続けること
「継続しないと価値がない」



ついでで申し訳ないが海部美知さん語録
「プチ変人」
「シリコンバレーというぬるま湯」
「こんなんでいいのかっていうくらいぬるいですよね」
「そういう時代が来るかこないかではなくて、やるかやらないかです」


海部さんの発言でシリコンバレーにおける「エンジニアのぬるま湯」というのがあったのだが、
ぬるま湯という表現を海部さん自身が批判的につかっていたのか、
それとも肯定的に使っていたのかがよくわからなかった。

メモを元におこしているので一部発言者が違うかもしれないが、その点はご容赦!


前の10件 | - システム開発 ブログトップ
メッセージを送る
RSS RSS

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。

×

この広告は1年以上新しい記事の更新がないブログに表示されております。