2011年4月23日土曜日

Emacs を Mac で使う

Emacs 23.3 (この記事書いてる2011年4月時点での最新版) を Mac で使うためのメモ。XCode が必要になります。

まずはソースとMac Emacs JP のインライン変換パッチを取得。

curl -O http://ftp.gnu.org/pub/gnu/emacs/emacs-23.3.tar.gz
curl -O http://sourceforge.jp/projects/macemacsjp/downloads/47986/inline_patch-23.2-beta3.tar.gz
tar zxvf emacs-23.3.tar.gz
tar zxvf inline_patch-23.2-beta3.tar.gz

2行目の"curl ~ inline_patch-23.2-beta3.tar.gz"はホントは改行なしの1行です。

続いてインラインパッチを適用してコンパイル。

cd emacs-23.3
patch -p 0 < ../inline_patch-23.2-beta3/emacs-inline.patch
./configure --with-ns --without-x
make bootstrap
make install

これで、emacs-23.3/nextstep に Emacs.app が出来てるので、/Application あたりに持っていけばOK。

あと、~/.emacs.d/init.el に以下の設定を書き込む。

(set-language-environment 'Japanese)
(prefer-coding-system 'utf-8)
(setq default-input-method "MacOSX")

(mac-add-key-passed-to-system 'shift) 

(define-key global-map [ns-drag-file] 'ns-find-file)
(setq ns-pop-up-frames nil)

参考資料

2011年2月26日土曜日

はてなダイアリーから Blogger へ日記をインポートする

はてなダイアリーから Blogger.com に日記データをインポートするためのメモ。

まずははてなダイアリーでデータのエクスポート。自分のダイアリーのトップページから「管理」(画面右上)→「データ管理」(画面左) と進んで、「Movable Type形式」を選択。

続いて、MovableType2Blogger conversion utility を使って、データを Blogger 形式にコンバート。ただし、MovableType2Blogger conversion utility はデータサイズが 1MB以上だと使えないので、 google blog converters appengine をダウンロードしてきて自前でコンバートしないといけません。自分のマシンで使うためには Python とGoogle Data API Python Client Library が必要なので、適当に調達してください。Mac OS X なら Macports あたりを使うのが簡単。

コンバートしたデータは Blogger の「設定」から「ブログをインポート」とやればインポート完了。めでたしめでたし。

……なんですが、はてなダイアリーからデータをエクスポートした時点で、エントリの投稿時刻が 00:xx:xx AM (つまり、"DATE" のところが、"02/26/2011 00:31:14 AM" みたいな感じ) ならば、Bloggerにインポート後の投稿日付がインポート作業した日になってしまうようです。ということで、Blogger 形式にコンバートする前か後かどっか適当なタイミングで日付をいじる必要があります。
夜中に書いたエントリーとか、はてなダイアリーのサービス初期の時点に書かれたエントリー (投稿時刻が 00:00:00AM になる) とか、そのへんは要注意。インポートするエントリーの数が多い人は気を付けましょう。

また、大量のエントリーをインポートしたら、Blogger.com から「スパムの疑いあり」でマークされ、約24時間の間は新しいエントリーを投稿するときに Captcha のクリアを求められたりします。 この間は変なことをしたりせずに品行方正に過ごしましょう。

2011年2月19日土曜日

MacPorts でバイナリを共有する (MacPors 2.0 以降では使えません)

<2011年8月8日追記>
OS X Lion と同時にリリースされた MacPorts 2.0 ではこの手法によるバイナリ共有ができないみたいです。僕自身は Lion とともに Homebrew 使うようになったので、そこら辺の事情はあまりきちんと確認できてません。
一応記録としてこのエントリは残しておきますが、 内容自体はあてになりませんのでご注意ください。
</2011年8月8日追記>

MacPorts は便利だけど、MacBook Air上でソフトのコンパイルまでやる気にはなれないのでなんとかしようぜ、というお話。元ネタは「MacPortsのバイナリパッケージを複数のMacで共有してみるメモ (blog@browncat.org)」から。
想定しているのは、iMac と MacBook Air の両方を持っていて、MacBook Air で使うソフトは iMac でコンパイルしてからインストールしたい、というような状況です。

まずは、MacPorts を iMac と MacBook Air の両方にインストール。

続いて、設定変更。両方のマシンの /opt/local/etc/macports/macports.conf 内にある portarchivemode を yes にしておきます。他の部分は修正の必要なし。

出来上がったパッケージは /opt/local/var/macports/packages/darwin 以下に置かれるので、このディレクトリを適当な手段で共有 (Dropbox で共有されるディレクトリからのシンボリックリンクにするとか)

もうちょっと正確に書くと、 出来上がったパッケージは以下の場所に置かれます。
  • アーキテクチャ依存のパッケージ  /opt/local/var/macports/packages/darwin/x86_64 (古いマシンだと、x86_64以外にPPCとかx86とかもあるのかも)
  • アーキテクチャに依存しないパッケージ /opt/local/var/macports/packages/darwin/noarch

ということなんで、これ以降は x86_64 とか noarch 以下に XXX.tgz という名前のパッケージがどんどんたまっていくことになります。

実際の運用時には、まず 欲しいパッケージを iMac にインストールし、MacBook Air へは、-b オプションを付けてインストール (sudo port -b install &lt;package&gt;) という手順を踏むことになります。2つのマシンのPortsツリーの更新もお忘れなく。

&lt;追記&gt; -b オプションなしでインストールしても、パッケージが存在したらそちらを優先的に使うようです。&lt;/追記&gt;

ー b オプション付けてるのに必要なバイナリパッケージがない場合は、勝手にコンパイルされる……のではなく、インストールが途中で止まります。2つのマシンで同じパッケージをインストールしてる分にはこの問題は起こらないはずなんで、ファイルの同期を待ってもう一回やり直すなりしてください。

また、アンインストールや ソフトの更新などによって使われなくなったパッケージがあっても、自動的に削除されるということはなさそうです (clean オプションを使ってもダメ)。それほど大きな問題にはならないかもしれませんが、時々は気にかけてみてください。

なお、port コマンドのオプションには、pkg とか dmg とかあって、これでパッケージ作って他のマシンにインストールすることもできますよ、みたいなことがドキュメントには書かれていますが、今のところ上手くいってません。

本来ならば、pkgオプションあたりを活用するのが正解なんでしょうけど。

Macで快適なターミナル環境を

Macでターミナル環境を改善するために、いろいろ設定したのでメモ。

とりあえず標準の「ターミナル」でも問題はないんだけど、標準以外で、ということであれば、「iTerm」がおすすめ。
Bookmarks > Manage Profiles... から、"Terminal Profiles" で "Default" を選択し、"Terminal Settings" で Type として "rxvt" を選択すればいい感じですが、このへんは個人の好みということで。
(標準のターミナルなら、環境設定... から、「設定」→「詳細」とたどって、「エミュレーション」内の「ターミナルの宣言方法」で rxvt を選択)

で、~/.bash_profile に以下のように記述。

if [ -f ~/.bashrc ] ; then
    . ~/.bashrc
fi

要するに、~/.bashrc を読み込むだけ。
実際の ~/.bashrc の中身は以下のとおり。

#-*-shell-script-*-

export TERM=rxvt
export CLICOLOR=1


alias rm='rm -i'

alias cp='cp -i'
alias mv='mv -i'

alias ls='ls -G'
alias ll='ls -hl'

alias emacs='open -a /Applications/MacPorts/Emacs.app'

# http://www.unixuser.org/~euske/doc/bashtips/bashrc.html
case "$HOSTNAME" in
    iMac*)
    col=33
    col2=34;;
    MacBook-Air*)
    col=36
    col2=34;;
    *)
    col=32
    col2=31;;
esac

PS1="\[\033[01;${col}m\]\u@\h\[\033[01;${col2}m\] \w \$\[\033[00m\] "

実際には iMac と MacBook Air で設定ファイルを同期させるために、上記の内容のファイルを Dropbox 経由で共有し、~/.bashrc はそのファイルを読み込むだけの内容、という運用にしています。
また、最後の部分 (case "$HOSTNAME" in 以下) は、マシンごとにプロンプトの色を変える設定です。
  • iMac 上では username@iMac ~ $
  • MacBook Air 上では username@MacBook-Air ~ $
  • それ以外のマシンでは username@machinename ~ $
みたいな感じの色分けになります。
MacBook Air から iMac に SSH でリモートログインするような場合でも、プロンプトの色で 自分がどのマシンにいるのか判断できます。

といったような感じで、Mac で快適なターミナル環境を、というネタでした。

2010年12月3日金曜日

民間企業における博士について

このまんまだと、ここのブログは2010年は一度も更新なしで終わってしまうやないか!! ということで、ちょっと真面目な話。10月に一度Twitterで書いたネタとかぶります。

日本国内では博士課程を修了して博士号をとると、そのまま大学の助手 (今は助教) になったり、研究機関の研究者になったり、というのが一般的なキャリアでした。しかし最近は「博士のキャリアパス多様化」ということで、大学のキャリアサポートセンターみたいなところが、民間企業に行ったり、ベンチャー企業を立ち上げたり、という進路を勧めるようになってきています。僕が知ってる範囲だと、九州大学キャリア支援センターとか、京都大学若手研究者キャリアパス多様化促進計画とか。裏を返せば、経費削りすぎで大学がパーマネントの研究者を採りにくい、という事情もあるんですが、それはさておき。

そういう多様化事業でちょっと気になるのが「博士号保持者は民間企業でも活躍できる」という「セールストーク」が勝手に先行してしまっていること。
ただ、あくまでそれは「できるはず」という話。本当に博士号保持者が活躍できるかどうか、もうちょっと具体的に言えば、博士号保持者を取るメリットが企業にあるかどうか、というのはまだ答えが出ていません。
ということなんで、僕も含めて企業で働く学位持ちの皆さんは、ちゃんと仕事して、ちゃんと社内で通用する結果を出しましょう。そうやって学位が「使える」ということを会社に納得してもらえば、下の世代の学位持ちが入ってくるかもしれないし、あと10年ぐらい経って学位持ちが社内の「偉い人」になるようになったら、多分いろいろ変わるかもしれません。

あと、「博士は民間企業でも活躍できる」という話の延長線上で、「博士は研究職以外の職種でも活躍できる」という話もありますが、ちょっとそれは無茶な理屈だと思います。

2009年9月14日月曜日

よくわかる (かもしれない) 建築学

この記事のオリジナルははてなのhakaseグループ日記に書いた「よくわかる(かもしれない)建築学」です。なんとなく持ってきてみました。

建築学はおおまかに次の3つの分野に分かれています。
  • 計画系 ---- 室配置などの平面計画、都市計画、意匠、建築史などに関する研究。
  • 構造系 ---- 鉄筋コンクリート構造などの各種構造や材料関連の研究。
  • 環境系 ---- 熱環境、空気環境、音環境、光環境などに関する研究。
日本建築学会が出版する学術雑誌である日本建築学会論文集もこのジャンル分けに従って「日本建築学会計画系論文集」、「日本建築学会構造系論文集」、「日本建築学会環境系論文集」の3つに分かれています。また、大学の建築系専攻での研究もこの3分類がベースになっています。

計画系は建築学科における花形分野で、安藤忠雄や隈研吾が東大の建築学科の教授やってたり、高松伸が京大の教授やってたり、と「スター教授」がいることも多いです。僕が学生だった時は、計画系の研究室は4回生の研究室配属や大学院入試で人気が集中することが多く、「狭き門」になってました。多分、今もそうだと思います。
ちなみに海外で architecture というとこの分野を指し、engineering とは別物と考えられてます。また、architecture は多くの場合独立した学部で教えられています。

構造系は、純粋に構造計算をやる「構造力学」、各種材料で構成される構造物の構造計算について研究する「鉄骨構造」、「鉄筋コンクリート構造」、材料の力学的特性などについて研究する「建築材料」などの分野に細分されます。また、地震などに対抗するための耐震構造などの研究もこの分野。僕が学生時代に講義を受けた某教授によると、「機械とちがって動かないから、建築の構造力学は簡単」ということらしいです。
海外だと、建築構造力学は civil engineering (土木工学) の一部になってることが多いです。

環境系は、建物内外の熱、空気、音、照明、色彩などが研究テーマ。取り扱うテーマは、各種環境に対する人体の生理反応とか、省エネ住宅のための空調機器の最適制御問題とか、室内照明に対する心理評価とか、かなりバラエティに富んでいます。逆に言うと、あまり建築っぽくない分野でもあります。僕も照明や色彩に対する心理評価に関する研究をやってたんですが、「建築の先生に研究の話をしてもあまり受けないけど、認知心理の先生には受ける」、「研究のための参考文献を探すために、建築学科ではなく文学部の図書室に入り浸る」などの現象が起こっていました。
あと面白いのが、火災関連の研究も環境系に入るということ*2。火災の熱によって鉄筋コンクリートの柱が水蒸気爆発を起こす、みたいな現象の解析をやってたりします。昔、なぜ火災関連が環境系なんだろう、と思って知ってる先生に聞いてみたところ、「温度差の桁が2つぐらい違うけど、現象としては、空調時の壁体内の伝熱と同じだから」という話でした。
海外だと、building science と呼ばれていて、建築学部の一部という扱いになってることが多いようです。
さて。日本の大学の建築系学科の場合、建築士試験の受験資格との絡みもあって、計画系、構造系、環境系のそれぞれについて、バランスよく履修することが求められます。「デザインやりたいから」という理由で建築学科に入ったとしても、基本的な構造計算ぐらいはやらないといけないということです。
また、研究レベルでも、例えばコンクリート内部の熱水分移動*3に関する研究で構造系と環境系の両方の知識が必要になる、みたいなことが起こります。
というわけで、院生時代からあまり建築っぽくない研究を続けた挙句、建築とは関係のない職場に転職してしまった僕のような人間でも、一応図面は描けるんだぜ、というお話でした。

2009年1月31日土曜日

Lux Pacifica 2009が開催危機→代替開催が決定

タイ国内での代替開催が決まったそうです (お知らせ)。

照明学会のWebサイトでもお知らせがでてますが (多分、1月30日の昼間に公開)、2009年4月23~25日にハバロフスク(ロシア)で開催予定だった Lux Pacifica (環太平洋照明学会) 2009 が「開催が困難な状況」ということだそうです。事態収拾に向けてルクスパシフィカ国際組織委員会では折衝中。
「航空券などの手配やロシア照明学会への支払いを中止してください.」という記述もあったり、お知らせのファイル名が
"090423lux_cancel.html"
だったりするので、ほぼキャンセルということになるのかもしれませんが、詳しい状況などについてはこんな辺境のブログではなく、照明学会からの情報を確認してください。

開催まで3ヶ月切った時点でいきなり国際学会がキャンセルというのも、世界的に経済情勢がアレなことになってるからしょうがないか……とかいって「あきらめモード」になるのはよろしくないのであろうなあ。