2012年5月23日水曜日

Google日本語入力のショートカットキーを変更(Mac)

VMware Fusion上のEclipseでCtrl+Shift+Rがなぜか効かなかったので調べた所、どうやらMac側のGoogle日本語入力の「再変換」とかいう使ったこともないものにデフォルトで設定されていたため、Google日本語入力に横取りされていた。

迷惑なだけなので無効化する。

システム環境設定→キーボードショートカットのアプリケーションの項目で「+」を押して新規追加ダイアログを開く

以下のように入力して追加

  • アプリケーション:全てのアプリケーション
  • メニュータイトル:再変換
  • キーボードショートカット:絶対使わないようなもの(Cmd+Ctrl+Alt+Shift+Qとかw)

これで無事VM側にCtrl+Shift+Rが伝わって、EclipseでOpen Resouceができるようになった!

2012年5月22日火曜日

CygwinのgitからgithubにSSHでアクセス

CygwinでインストールしたgitでgithubのリポジトリをSSHでクローンしようとすると以下のようなエラーが出てうまくいかない。

ssh: Could not resolve hostname github.com: Non-recoverable failure in name resolution

どうやらCygwin最新版のopenssh(5.5以上?)だとCygwinでインストールしたgitからgithubにうまくSSHでアクセスできないことがあるようだ。

http://stackoverflow.com/questions/1493645/git-fatal-remote-end-hung-up

解決策として、代わりにplink(Puttyについてくるやつ)をGITが使用するSSHプログラムとして指定するとうまくいった。

以下簡単な手順。

  1. Puttyをダウンロード。

  2. PUTTYGEN.exeでパブリックキーとプライベートキーを生成、保存。

  3. Githubにパブリックキーを登録。

  4. PAGEANT.exeを起動してプライベートキーを読みこませる。

  5. PUTTY.exeでgithub.comにgitユーザでアクセスできるか確認。

  6. GIT_SSH環境変数にPLINK.exeのパスを指定。

これで無事にSSHでgithubのリポジトリにアクセスできれば成功。

PAGEANT.exeが起動していない状態でgithubにSSHアクセスすると”FATAL ERROR: Disconnected: No supported authentication methods available (server sent: publickey)”と言われるので注意。

参考URL: http://help.github.com/ssh-issues/

2012年5月18日金曜日

GAEで動くプロキシサーバを使ってDropboxのホスティング環境に独自ドメインでアクセス

DropboxのPublicフォルダにファイルを置くと、そのファイルは一般に公開されます。

従って、HTMLファイル等をPublicフォルダに置くだけで、Dropboxを簡易ホスティング環境として使用することができます。

やり方はDropbox 活用術 PART3 – ホスティングとして利用 | Technolog.jp - ICTウェブマガジンを参照して下さい。

ただし、上記サイトにもある通り以下の制限があります。

  • 独自ドメイン使用不可
  • サーバサイドスクリプト使用不可

サーバサイドスクリプトはどうにもなりませんが、独自ドメインの方はいくつか解決策があります。

DropboxのPublicフォルダにindex.htmlを置いた場合、このindex.htmlには'http://dl.dropbox.com/u/1234567/index.html'というURLでアクセスできます。

1234567はDropboxのユーザ番号です。Publicフォルダのファイルのパブリックリンクを見ることで分かります。

従って、ここに'http://example.com/index.html'でアクセスしたい場合、'http://example.com/'へのアクセスを'http://dl.dropbox.com/u/1234567/'に転送しなければなりません。

DNSを直にいじれる環境ではApacheのリバースプロキシやmod_rewriteを使ってどうにでもなりますが、お名前.comのように設定項目が制限されている環境ではこの方法は使用出来ません。

DNSのCNAMEやお名前.comのURL転送ではドメイン部分に続くディレクトリの指定(/u/1234567/など)ができないからです。

今回はこの問題を解決するために、GAE(Google App Engine)で動作するプロキシdropbproxを使いました。

GAEは独自ドメインが使用できるので、独自ドメインで一旦GAE上のプロキシにアクセスし、そこからDropboxのPublicフォルダにアクセスするという仕組みです。

元のdropbproxではディレクトリにアクセスした際にindex.htmlを自動的に表示する機能がないため、今回dropbproxに少し手を加えて'http://example.com''http://example.com/'のようにディレクトリを指し示すURLは、そのディレクトリのindex.html(http://example.com/index.html)を表示する機能を付け加えました。

GAEに詳しくない方はチュートリアルをひと通りこなしてみてください。

設定手順は以下の通りです。

  1. GAEでdropbprox用のアプリケーション作成

  2. カスタマイズしたdropbproxをダウンロード(Google Project HostingからMercurialでもダウンロードできます)

  3. 解凍してapp.yamlとmirror.pyを以下のように編集

    • app.yaml
      • appidを1.で作成したアプリケーションIDに設定。
    • mirror.py

      • DROPBOX_USERに上で説明したDropboxのユーザ番号を設定。

      • DIRECTORIESにindex.htmlを自動的に付加したいディレクトリパスのリストを設定。必ず/から始まる必要がある。例えば’/dir/hoge’と設定しておくと、http://example.com/dir/hogeにアクセスした時にはhttp://example.com/dir/hoge/index.htmlが表示されるようになる。

  4. アプリケーションをローカルでテストしてちゃんとページが表示されるか確認。

  5. アプリケーションをデプロイ。

  6. Google App Engineで独自ドメインを使う - Shin x blogを参考にGAEに独自ドメインでアクセスできるように設定(GAEはexample.comのようなnaked domainからはアクセスできないので、さらに独自ドメインを転送する - Google Apps ヘルプを参考にwww.example.comに転送設定しておく)

以上、かなり面倒ですが全て無料で独自ドメインを使ったDropboxによるホスティングが実現できました。

Dropboxによるホスティングはファイルを変更すればFTPを使用しなくても即座にアップロードされますし、自動的にバージョン管理もしてくれるのがいいですね。

ただ、一度プロキシを介するせいかレスポンスはあまりよくありません。

まあ個人レベルのちょっとしたサイトにはこれで十分でしょう。

アクセスが多いサイトはちゃんとしたホスティングサイトを使用して下さい。

2012年4月19日木曜日

Google App Engine(GAE)、Amazon Web Service(AWS)、Windows Azure、Herokuを比較

最近既存Webアプリをクラウドプラットフォームに移行する際に調査を行ったので、せっかくだから公開してみる。

この4つ以外にも色々なサービスがあるが、知名度と実績からこの4つを選んで重点的に調査した。

ただし、どのサービスもサードパーティのソフト等で実際はこの表に載っている以上に色々なことができるし、料金体系ももっと複雑なので、この表はあくまで参考程度にして、実際に使用する場合は各サービスのサイトで詳細を調べて下さい。

以下に各サービスのメリット・デメリットを簡単にまとめました。

Google App Engine

  • メリット

    • サーバ環境が全て揃っているため、環境構築の必要がない。
    • 無料枠があるため小規模であれば料金が他のサービスより安い。
  • デメリット

    • 独自の仕様が多いためロックインされてしまい、他のサービスに移行しづらい(2011年9月のように突然値上げされても逃げられない)。
    • 学習コストが高い。
    • RDBが使用できない。

Amazon Web Services

  • メリット

    • PaaSとしてJava, PHP、IaaSとしてLinuxとWindows Server両方提供しているので、やろうと思えば何でもできる(VMのレンタルサーバのイメージ)。
    • サービスが豊富。
    • オープンな技術を使用して開発可能。
  • デメリット

    • サービスが豊富すぎて料金体系が複雑。
    • 管理コンソールが使いにくいらしい。
    • 自由度が高い分アプリケーションの管理等を自分でしなければならない(IaaSとして使用すれば当然OSの管理も必要)。

Windows Azure

  • メリット

    • SQL Azureの料金が安い 。
    • Visual Studio、Windows Server、SQL ServerなどのMS製品との相性が良い。
    • オープンソース技術も積極的にサポートしており、オープンな技術を使用しての開発も可能。
  • デメリット

    • 開発環境もサーバもWindowsになってしまう。

Heroku

  • メリット

    • 多くの言語が使用可能。
    • オープンな技術を使用して開発可能。
    • 料金体系がシンプルでわかりやすい。
  • デメリット

    • DBの容量が少ない場合料金がやや割高(5MBまでは無料だが、それを超えるといきなり$15になる)。

何か間違いなどがあったらお知らせ下さい。

2012年4月17日火曜日

MacからWindowsにVNC+SSHでリモートアクセス

色々ハマりどころがあるのでメモ。

WindowsのVNCサーバは色々あるが、今回はRealVNC日本語インストール版を使用した。

VNCサーバ(アクセスされる側)の設定

環境はVista Home Premium 32bit。

  1. RealVNC日本語インストール版をダウンロード

  2. 解凍して中にあるvncjp-4_1_2-x86_win32.exeを右クリックする(そのまま起動してインストールしてはだめ)

  3. 「管理者として実行」を選択してインストール。Vista, 7ではWindowsサービスとしては正常に動作しないため、サービスの登録等はしなくてよい

  4. VNCサーバをユーザモードで起動

  5. VNCパスワードの設定、ポートの設定、Windowsファイアウォールの設定等を行う

  6. 自動起動したい場合はスタートアップにショートカットを登録

VNCクライアント(アクセスする側)の設定

環境はMac OS X Lion 32bit

  1. VNCサーバのIPアドレス(192.168.0.3など)、ポート番号(デフォルトでは5900)を調べる。

  2. Finderで「サーバへ接続」(⌘K)を選択

  3. サーバアドレスに1.で調べたIPアドレスとポート番号を「vnc://192.168.0.3:5900」のように入力

  4. 正常に接続されれば画面共有アプリが自動で起動し、Windowsのデスクトップが表示される。

SSHトンネリングの設定

VNCの通信は暗号化されないので、LAN内であれば良いがインターネット越しにアクセスする場合はSSHトンネリングで暗号化した方が安全だ。

SSHトンネリングの場合はファイアウォールのポートもSSHのポート(22番ポート)を開くのみでOK。

以下はSSHトンネリングを使用したVNCの設定手順。

  1. http://d.hatena.ne.jp/Guernsey/20091115/1258257335等を参考にVNCサーバ側にFreeSSHd等のSSHサーバをインストールし、VNCクライアント(Mac)からVNCサーバ(Windows)にSSHでアクセスできるようにする。

  2. VNCクライアント(Mac)でターミナルを起動し、「ssh -N -L 10023:localhost:5900 192.168.0.3」を実行(このコマンドを実行するとVNCクライアントの10023ポートの通信は192.168.0.3(SSHサーバ)経由でlocalhost(192.168.0.3から見たlocalhostなので、この場合は192.168.0.3と同じ)の5900に転送される)

  3. Finderの「サーバへ接続」を実行する際のサーバアドレスを「vnc://localhost:10023」にして実行

無事画面共有ができればSSHトンネリング成功です。

2012年3月11日日曜日

エンジニアとしての生き方

基本的に技術的な内容しかこのブログには書いて来なかったが、最近すごく共感のできる本を読んで色々考えさせられたので、たまには本の感想も書いてみる。

エンジニアとしての生き方  IT技術者たちよ、世界へ出よう! (インプレス選書)

  • 作者: 中島聡
  • 出版社/メーカー: インプレスジャパン
  • 発売日: 2011/03/11

副題の「IT技術者たちよ、世界へ出よう!」は僕が大学の頃からずっと達成したい思っている目標なので、大いに刺激を受けた。

本には日本の若手ITエンジニアへのメッセージがぎっしり詰まっており、読者層としてドンピシャな僕は共感できるところがありすぎた。

中でも最も共感したのは以下の言葉。

仕事は頼まれなくても自分から喜んで残業するほど楽しい仕事かどうかで選ぶべき

これは本当に心からそう思う。なかなかそんな職に就くのも簡単ではないが、このような仕事をしているかどうかで自分の人生の充実度が大きく左右することは間違いないと思う。

日本でも海外に行ってもこのように感じられるやりがいのある仕事を一生続けていきたい。

また、ブログを実名で書くことの重要性にも言及しており、僕はまだ実名公開までは踏み切れなかったが、今後はもっと積極的にブログも更新していきたい。

現状に閉塞感を感じるエンジニアの人には非常に参考になるのでお勧めです!

これはもっと早く読んでおきたかった。

2012年3月4日日曜日

git status -sで変更のあったファイル一覧を抽出

今のプロジェクトではJenkinsでperlcriticなどのチェックをしているのだが、たまにローカルで確認せずにコミットしてしまってJenkins様がお怒りになるので、git statusの出力結果からソースコードに変更のあったファイルのみを抽出してチェックするようにしてみた。

抽出の仕方は下のような感じ。

git status -s | gawk '{if(match($1, /M|A/) != 0) print $2;}'

‘git status’に-sオプションをつけると「A module.pm」のようにステータスとファイル名の2つのみが出力されるようになるので、gawkでA(Added)とM(Modified)のみのファイルを抜き出している。

これでも実行するのを忘れてコミットしてしまうと意味が無いので、コミットの時は必ずチェックスクリプトを走らせて、警告があるとコミットできないようにすることも考えられるが、それはやりすぎだろうか・・・。