カテゴリー

最新の記事

最近のコメント

最近のトラックバック

月別アーカイブ

ブログ検索

RSSフィード

ブロとも申請フォーム

この人とブロともになる

スポンサーサイト

スポンサー広告
--.--.--
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
にほんブログ村 ベンチャーブログへ

MacBook AirにWindows7を導入

PCとかネットとか
2009.01.19
事例取材の仕事で時々お会いするマイクロソフトの方が「Windows 7はサクサク動く」とおっしゃるので、いま公開されているβ版を試してみることにした。仕事に使っているマシンに入れるのはちょっとアレなので、導入マシンはMacBook Airに決定。もちろん仮想マシンとして導入するのだ。

昨年12月に購入したMacBook Airには、すでにVirtualBoxが導入され、Windows XP Professionalが動いている。Vistaにしなかったのは、Vistaの空きライセンスが手元になかったから。ベジタの頃にXPマシンを数台導入し、いまではそのほとんどが使われていないので、XPのライセンスは余っている。もちろん仮想マシン上でVistaを動かすのは重そうだという理由もあるのだが。

VirtualBoxにWindows7を導入する手順は以下の通り。これから導入する方のために、いくつか注意点も記述しておく。もちろんこれは、自分の備忘録でもある。

Step1
マイクロソフトのサイトから32ビット版のISOイメージファイルをダウンロードする。サイズはなんと2.5GB。私のオフィスのネット環境はマンション共有のVSDL型Bフレッツだが、ダウンロードを完了するのに1時間半近くかかった。

Step2
ISOイメージファイルをMacBook Airに移す。VirtualBoxはリモートDVDドライブを認識しないようなので、USB接続の外付けHDDにいったんコピーし、それをMacBook Airにコピーするという方法を使った。2回コピーすることになるが、1回のコピー時間は3分くらいなので、LAN経由でコピーするよりもはるかに速い。

Step3
VirtualBoxに新規仮想マシンを設定する。マイクロソフトのサイトにある推奨構成に従い、メモリー1GB、HDD16GB、ビデオメモリ128MBに設定する。またCD/DVDドライブとして、先ほどコピーしたISOイメージファイルを指定する。サウンドデバイスはAC97を指定。ネットワークはIntelのギガビットイーサを指定する。Intel以外ではネットワークが認識できないようだ。なおインストール後、メモリー容量を256MBに縮小してみたが、問題なく動いてくれた。

Step4
新規作成した仮想マシンを起動する。自動的にインストールが始まる。画面に表示されるダイアログに従えば、インストールは完了する。途中で2回ほどリブートされたようだ。インストールにかかった時間は約1時間だった。

Step5
インストール後、サウンドデバイスのドライバをオンラインで更新する。こうしないと音が出ない。

以上でインストールは完了。問題なく動いているようだ。下はその証拠写真。画面キャプチャではなく、あえてデジカメで撮影した。MacBook AirでWindows7が動いていることがわかるはずだ。

写真1

ちょっと気になるのは、IEが新しいページを開くときにエラーになり、同じページを再度読み込むと表示されるということだ。これはIEのバグなのか、それとも設定の問題なのか。よくわからない。

それからもうひとつ。仮想マシンのスナップショットを取得して、このスナップショットから仮想マシンを再起動すると、スナップショット取得時刻のままになってしまう。つまり実際とは時間がずれてしまうのだ。

なお、System6時代の古いMacintoshをエミュレートする「Mini vMac」を、Windows7上で動かすこともできた。OSXの上でWindows7を動かし、さらにその上でSystem6を動かしているわけである。

写真2

Windows7の上でMacのSystem6が動いていることと、Windows7とOSXで時刻がずれていることがおわかりいただけるはずだ。

仮想化技術ってなかなか面白い。
スポンサーサイト

ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
にほんブログ村 ベンチャーブログへ

バッグのカスタマイズ

PCとかネットとか
2009.01.08
MacBook Airを手に入れると、やはり毎日持ち歩きたくなる。そこでMacBook Air持ち歩きのためだけに、下の写真のようなショルダーバッグを購入した。価格は6800円。軽くていい。

写真1


しかし使っているうちに不満が出るのは人の性。最初は「シンプルなのがいい」と思っていたのだが、あまりにもシンプルすぎた。

写真2

メインの収納部分にはMaBook Airとノートを入れているだけなのだが、サブの収納部分にはiPod touchやUSB接続型のe-mobile端末、イヤホン、文庫本、ポケットティッシュ等々、まあいろいろと放り込んでいた。そのためどうも、ものが取り出しづらくなっていたのだ。

それではということで、このバッグにポケットを付けることにした。裁縫はあまり得意ではないので、手軽にできる方法がいい。そこで浦和のユザワヤに行き、革とカシメを購入した。

写真3

写真4

まずは革をポケットのサイズにカットし、カシメる部分に小さな穴を開ける。そして下の道具で、バシバシとカシメていくのである。金槌でたたくので音が大きい。近所迷惑を気にしながら、とりあえず26箇所をカシメ終える。

写真5

で、できあがったのがこれ。

写真6

写真7


向かって左側にはiPod touch、右側にはe-mobile端末、そして真ん中はちょっとした小物を入れている。写真ではメンタムのリップスティックが入っているが、今日はイヤホンが収納されている。シロウトの即席仕事にしては、悪くないできだと思うのだが。

これでサブの収納場所がすっきりした。もう少しポケットを増やすのも悪くないなあと思う。でも面倒だなあ、という気持ちもある。

さてどうしたものか。

ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
にほんブログ村 ベンチャーブログへ

MacBook Airを購入

PCとかネットとか
2008.12.23
先週アタマから買おうかどうか悩んでいたが、先週金曜日にMacBook Airを購入した。120GBのHDDモデル。秋葉原のヨドバシで買ってポイントをためようかと思ったが在庫がなく、いつ入るかもわからないということなので、銀座のアップルストアで手に入れた。

MacBook Airがいかに物欲をそそるか、そしていかに所有欲を満足させるものかについては、数多くの方が語っているので省略する。

持ち運びしやすいノートPCを手に入れれば、まずやりたいのがVPNの設定だ。WindowsマシンであればPacketiXでつなげばいい。すでに以前からPacketiXサーバーは用意してあるので、クライアント設定を行うだけだ。しかしPacketiXは、OSXに対応したクライアントがみつからない。そこでLinuxマシンにOpenVPNの環境を構築し、MacBook AirにOpenVPNクライアントを導入することにした。

OpenVPN環境の構築方法は、大きく分けて2種類あるようだ。ひとつはルーティングVPN、もうひとつはブリッジVPNである。導入・設定方法については、以下のサイトが参考になる。

(1)ルーティング型の設定
VPNサーバー構築(OpenVPN)

(2)ブリッジ型の設定
OpenVPNで構築するリモートアクセス環境

PacketiXでブリッジ型のVPNに慣れてしまった身としてはOpenVPNもやはりブリッジ型でいきたい。そこで(2)のサイトをベースに、(1)も参考にしながらOpenVPN環境を構築していった。

基本的にはこれで問題ないのだが、私の環境ではひとつだけ落とし穴があった。それはブリッジインターフェースを生成すると、デフォルトRouteの設定が消えてしまうということだ。そのためVPN環境を有効にして立ち上げると、ブロードバンドルーターの外側からこのマシンのポートが見えなくなってしまうのである。

問題自体は難しいものではない。route addコマンドでデフォルトルートを追加すればいいからだ。今回はブリッジインターフェースを生成するスクリプトに、以下の1行を追加した。

/sbin/route add -net default gw <ブロードバンドルータのLAN側アドレス>



これで一件落着。自宅の無線LANからでも、ものの数秒でオフィス内LANに参加できる。Windowsファイルの共有設定も行っているので、Windowsサーバ上のファイルや、Linuxマシンに設定したSambaのファイルにもアクセス可能になった。アクセススピードも思っていた以上に高速だ。

実に快適なのである。

ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
にほんブログ村 ベンチャーブログへ

Webアプリの難しさ

PCとかネットとか
2008.08.14
5月23日の「ご無沙汰してます。」でも書いたように、ここしばらくLAMP(Linux&Apache&MySQL&PHP)での開発作業を行っています。何を開発しているのかはまだナイショですが、この数ヶ月でいろいろと感じたことがあるので、自分のための備忘録として記録しておきたいと思います。(それにしても「ご無沙汰してます。」って、ひどいタイトルですね。我ながらびっくり。)

基本的にはPHPでのプログラミングが主軸になるのですが、Webプログラミングというのは、想像以上に難しいです。難しいというのは、言語仕様が難しいとか、動作が複雑だとか、概念的に難解といったことではありません。あまりに融通無碍な世界であるため、自分に対して適切な「枷」をかけなければならない点が、難しいなあと感じているのです。しかもどのような「枷」をかけるべきなのか、ひととおりやってみないとわからない。PHPにはいくつもフレームワークが存在しますが、「確かにフレームワークが必要だなあ」と思います。でも私自身は、既存のフレームワークを使う気はないんですけどね。

 というわけで、この数ヶ月で、プログラミングスタイルを何度も変更しています。

 まず最初は書籍のサンプルコードを参考にしながら、フォームを使った会員登録画面を作ってみたのですが、いきなり違和感を感じることになってしまいました。まあ、サンプルコードにありがちな、HTMLとPHPが完全に混在しているコードだったのですが、これではメンテナンスができない、という感じだったのです。PHPって、動くコードを書くのは簡単なんだけど、メンテナンス性を維持したコードを書くのは、なかなか一筋縄ではいきませんね。

 まず言語仕様に問題があります。宣言無しで変数を使うことができ、型付けが非常に緩やかなので、どこでどのような名前の変数を使ったのか、別にドキュメントを残しておかないとわからなくなります。これは「手軽に使える」というスクリプト言語のメリットでもあるのですが、将来の変更を前提にしてプログラミングを考えると、大きなデメリットになります。まあ、ドキュメンテーションをきちんと行えばいいわけですが。でも「ソースそのものをドキュメントにする」という、昔のC言語の発想を引きずっている私としては、ちょっと不満だったりします。変数の頭にすべて「$」を付けるというルールは「なるほどなあ」と感心したりもしているのですが。このルールがあれば、予約語とバッティングすることもないですしね。

 それからWebプログラミングの場合、まずHTMLありき、というのも厄介です。つまりMVCで言えば、何も考えずにプログラミングを進めていくと、どうしてもView主導型になってしまうのです。これもプログラムの見通しを悪くします。まずプログラム構造全体をControl主導型にし、その下にデータモデルとViewが配置されるようなイメージにしないと、なかなか見通しのいいプログラムになりません。そのためには自分でプログラム構造のルールを厳格に決め、そのルールを自分で徹底的に守る必要があります。

 昔のX/Motifのプログラミングでは、このあたりが比較的扱いやすかったような気がします。私の時代は自分で無限ループのメインルーチンを記述し、そこに画面要素とそこで発生するイベントの定義を挿入、さらにコールバックルーチンを別途用意する、という手法が一般的だったような気がします。主役はあくまでもプログラム本体で、画面要素はオブジェクトとして扱えたのです。しかしPHPの場合、イベントは画面遷移を伴うのが一般的です。Ajaxを使えばオブジェクト的に扱えますが、そうでなければ個々の画面要素をPHPからコントロールすることはでませんよね。たぶんできないと思う。(弱気)

 それから画面遷移時の変数の扱いも厄介です。一般的な変数は画面遷移時にすべて解放されてしまうため、スーパーグローバル変数を使わないとステートを引き継げません。例えばフォームに何か入力させ、「OK」ボタンで次の画面に遷移するといった処理を考えてみましょう。もしフォーム入力の内容に誤りがあれば、その内容を保持して元のフォーム画面を再表示すると共に、エラーメッセージを表示したいところです。しかしいったん次の画面に遷移してから元の画面を呼び出すと、フォームフィールドの内容は消えてしまいます。フォームフィールドの内容を次のコントロールに伝達するPOST変数も消えています。最初はフォーム画面の次の画面の中にhidden型のinput要素を記述し、POST変数を維持するようにコーディングしていたのですが、どうもしっくりきません。今ではSESSION変数にフォームの内容を保持し、不要になった時点でunsetしています。でもこれが最善の方法なのか、まだ確信が持てていない状況です。

 というわけで、6月にはコントロールとビューを完全分離するための方法をいろいろと試行し、7月には「だいたいこんなもんだろう」という形を決めています。単純な方法なのですが、ひとつのプログラム(コントロール)の処理を、前処理(主にSESSION変数の確保とPOST/GET変数からの引継)、イベントハンドリング、画面表示用のデータセットの作成、画面表示、後処理、という5つの部分に分け、画面表示のコードをコントロール内に記述しないようにしているのです。画面表示はそれぞれひとつの関数として定義してあり、その内部にHTMLが記述されています(XHTMLと自信を持っていえないところが悲しい)。さらにひとつの画面を構成する機能ディビジョンは、「disp_○○_box.php」という関数にして、画面表示関数から呼び出すようにしました。こうすると画面表示の記述がものすごく短くなり、構造が明確になります。

 画面表示に必要な情報も、最初はグローバル変数やスーパーグローバル変数を画面表示関数の中でそのまま参照していたのですが、これもメンテナンス性を損なう要因なので、引数渡しに変更しています。まあこれは当たり前の措置ですね。前述の「画面表示用のデータセットの作成」の部分でこの引数を作成し、画面表示関数の呼び出しのところで使用するわけです。ひとつの機能ディビジョンに対しては、ひとつのデータセットを引き渡します。もちろんこのデータセットは配列です。それも単純な配列ではなく、C言語の構造体のようなものです。C言語と違うのは、配列の要素の識別を文字列で行っている点でしょう。連想配列って便利ですね。コードの可読性も高くなるし。

 関数の戻り値をどう扱うかも悩み所ですね。関数に引き渡す情報は引数、戻り値は関数そのものの値、というのが妥当だと思うのですが、引数の一部をリファレンス渡しにしてそこに戻り値をセットするというのも、自由度が高くなるので捨てがたい。どちらにするか結構揺れていて、何度も関数を書き直していたんですが、今では「関数の値を戻り値にする」という、ごく当たり前の方法に落ち着いています。引数をリファレンス渡しにすると、自由度は高まるんですが、可読性が落ちるような気がするんですよ。まあこのあたりは、趣味の世界かもしれませんけどね。でも可読性をいかに高めるかは、プログラミングで最も重要なことではないのかなあ。そんな気がします。

 現時点で、MySQLのテーブル数が29、定義済みのファンクション(関数)の数が70ちょっとになっていますが、メンテナンス性はかなり上がりました。トレースログやタイムログのテーブル&関数も作り、ログ取得関数を各関数に仕込んでいるので、デバッグもしやすいです。もちろんシンタックスエラーや未定義インデックスがあれば、PHPそのものがワーニングを画面に表示してくれますが、PHPのエラーが出ている間は「まだまだだめじゃん」ということ。本当のデバッグは、インタープリタからのエラーが出なくなってから始まるんですよね。

 CSSとJavaScriptの勉強も本格的に始めました。CSSは他のサイトの記述を参考に「まあこんなもんかな」というレベルで適当に記述していたのですが、どうも根本的な誤解があったようなので、標準テキストを頭から読むことにしました。恥ずかしながら、かなり間違った使い方をしていたようです。JavaScriptはDOMのコントロールに使う予定です。もちろんAjaxの使用も考えています。CSSハックやJavaScript使用不可の環境との互換性をどうするかも、今後基本方針を決めなければなりませんね。

 ということで、まだ道のりは長そうなのですが、ボチボチやっています。できあがったら公開するつもりなので、乞うご期待。

ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
にほんブログ村 ベンチャーブログへ

カテゴリーとタグ(2)

PCとかネットとか
2008.07.01
え~っと、前回の続きです。タグにはどのような問題があるかという話です。

最近はコンテンツを分類する手法としてタグを使うサービスが増えているのですが、タグにはいくつかの問題があると思います。前回はそのひとつとして、タグの漏れの話をしましたが、それ以上に大きな問題が残っています。それは「局所化」が難しいということです。分類の本質は「見るべき範囲を限定」することで目的のコンテンツにたどり着くまでのコストを抑制することだと前回書きましたが、タグではこれが意外と難しいのです。

タグによってコンテンツを絞り込むには、どのようなタグが実際に使われているのかを知る必要があります。見当違いなタグを指定してしまうと、目的のコンテンツにたどり着けません。タグを付ける側は思いつきでタグを付けられるので気軽なのですが、それを手がかりにコンテンツを探す側から見ると、タグを適切に選択しなければならないというコストがかかるわけです。しかもタグ全体が構造化されていないので、大量のタグの中から目的のタグを探す必要がある。つまり「構造化する必要がない」ということが、タグそのもののファインダビリティを低下させているわけです。

「タグクラウドならよく使われているタグが大きく表示されるよ」という指摘もあるかもしれません。しかし「よく使われているタグ」を見つけだすことは、目的のコンテンツにたどり着くための手法としては十分ではありません。そのタグは多くのコンテンツに付けられているというだけで、他のタグを無視してもいいということにはならないからです。むしろ小さく表示されているタグが、本当に必要なコンテンツに結びつけられているかもしれないのです。

また類似の意味を持つタグをグルーピングできれば、タグを手がかりにした検索の精度も高まるかもしれません。しかしそのためには、タグ同士の関係性を定義する必要があります。これはなかなかコストがかかります。言葉の意味から関係性を定義するには、現在の技術では、どこかで人間の判定が必要になると思われるからです。シソーラス辞書が整備されていれば、ある程度までは自動化できます。しかし上下関係にある言葉は、シソーラスだけでは関係づけることができません。いずれは解決すると思うのですが、現状ではまだ難しいと思います。

もちろんタグやタグクラウドにもメリットはあります。どのタグがよく使われているのかがわかれば、どのテーマに注目している人が多いのかがわかるからです。これはネット上での流行を追いかけている人にとっては、非常に魅力的です。みんながいま何を話題にしているのか、ひとめでわかります。またコンテンツ同士をつなぐキーワードとしてタグを使うことで、類似性の高いコンテンツの間を“サーフィン”することもできます。しかしこのような機能は、目的のコンテンツに低コストでたどり着くためというよりも、たどり着くまでのプロセスを楽しむためのもの、という側面が強いように感じます。いわば「ドンキホーテ」的な面白さです。

このような面白さを否定するつもりはありません。しかしコンテンツのファインダビリティという観点から見れば、あまり効果的なアプローチではないと思います。

私が「コンテンツ群をカテゴリー分けするWebアプリケーション」を作っている最大の目的は、価値のあるコンテンツに低コストでたどり着くにはどうすればいいのか、という課題を解決するためです。カテゴライズはそのための手法として、今なお有効だと考えているのです。

ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
にほんブログ村 ベンチャーブログへ

FC2Ad

相続 会社設立

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。