9.10 64bitで日本語環境を整備

ubuntu

Ubuntuの64bit版デスクトップで日本語環境を整備する手順。64bit版には日本語Remix CDがないけれど、有難いことにJapanese Teamのリポジトリにはちゃんと64bit版バイナリも用意されてるので、通常版をインストールした後、Japanese Teamの追加パッケージ利用方法に沿って設定を行えば、日本語周りもまったく問題なく使えるようになる。
この辺は先日も書いたところで、基本的に Ubuntuの日本語環境 | Ubuntu Japanese Team の手順に従えばOK。気をつけるところは、手順４の「言語サポート」を開いたときに、「言語のインストールと削除」で「日本語」にチェックを入れてインストールすること。「言語サポート」で既に「日本語」が選択されているので油断しがち。ここまで実施してログインし直せば、英語と日本語が混じり合ったアプリケーションとかシステムメニューが全部日本語化されるはず。
次に入力系。9.10からibusが標準IMになったが、これをSCIMに戻したい場合、上記リンク先の手順５でインストールされる「日本語環境セットアップヘルパ」を使ってSCIMをインストールします。[システム]-[システム管理]-[日本語環境セットアップヘルパ] を起動し、「scim-anthy, scim-bridge-client-gtk」にチェックを入れてダイアログを進めます。途中でIPAフォントもでてくるので、必要なら入れましょう。インストールが終わったら、[システム]-[システム管理]-[言語サポート] の「キーボード入力に使うIMシステム」で「scim-bridge」を選びます。
最後、ログインし直せば、日本語Remixと同等の環境が64bitでも使えるようになります。Japanese Teamに感謝！！

おまけ

SCIMでは初期状態でZenkaku_HankakuキーでIMのOn/Offを切り替えられる他、Ctrl+Spaceでも同様のことができます。また、AnthyがCtrl+Jを奪ってたりしてますので、[システム]-[設定]-[SCIM入力メソッドの設定] を開いて、フロントエンド→全体設定、及びIMエンジン→Anthy→キーバインドを確認して、自分が慣れたショートカットがIMに奪われていないことを確認しておくことをお勧めします。

Ubuntu 9.10 Karmic Koala 64bit 版をインストール

linux

先月末に Ubuntu の最新版である 9.10 (Karmic Koala) がリリースされましたね！早速自宅のノートPCにインストールしてみました。

そもそもなぜ64bit版をインストールするのか

64bit版を使う動機として「物理メモリを3GB以上認識しない」っていうのがあるけれど、9.10 には linux-generic-pae という、PAEが有効になったkernelが用意されている（Use More Than 3GB Of RAM In Ubuntu Karmic Koala 32bit ~ Web Upd8: Ubuntu / Linux blog）ので、メモリだけであれば32bit版で問題ない。自分も最初は32bit版を入れたのだけど、linux-generic-pae を有効にすると、プロプライエタリなハードウェアドライバが軒並み動きませんでした。。うちのノートPCはプロプラドライバがないと無線LANが使えなかったので、この時点で64bit決定。この辺は、お使いの環境にてUSB起動とかで試したらいいんじゃないでしょーか。

64bit版のインストール手順

まずは普通にインストール。この辺はどこかで詳細な解説があるはず。インストールが終わったら、Ubuntu Japanese Teamのリポジトリを追加して、日本語環境を整備する。Ubuntuの日本語環境 | Ubuntu Japanese Team の下の方にある 方法２・Japanese Teamのパッケージレポジトリを追加する の手順に従うだけでOK。最後に システム - システム管理 - 日本語環境セットアップヘルパ を実行して、必要なものをインストールする。
いじょ！細かい設定とかはまた後日。

9.10 のいまのところの使い心地

スラドではバグだらけとか言われちゃってる 9.10 ですが、よくなったところもありつつ、確かに細かいバグが多い気がします。SDカードを差したままだとサスペンドできないとかは結構重傷です。他にも、isoイメージからのUSBインストールディスクの作成ができなかったりしました。逆に、Firefoxが標準で3.5系になったとか、グラフィックカードのドライバがすんなりインストールできて、しかもちゃんと動くってのは、確実に良くなったと思います。
日本語入力まわりは、SCIMからibusになって、現時点では機能ダウンです（ibusの初期エンジンがanthyじゃないってのも、印象が良くない）。ここは日本語環境セットアップヘルパからSCIMをインストールすれば解決できるのですが、今後 ibus が標準になっていきそうなので、しばらく我慢して慣れる、っていうMっ気たっぷりな対応もありかもしれませんね。

全体として、まだあまり使い込めてないですが、既に9.04を使っていて設定諸々移行がめんどくさいなら、そのまま9.04を使いつづけた方がいいと思います。これから初めてUbuntu使おうと思ってるなんて人は、9.10は飛ばして10.4まで待った方が良さそうです。細かいバグは9.10でも改善されていくので、2ヶ月くらいしたら使いやすくなってるかもしれませんが、結局LTSである10.4の方が品質はいいはずだし、今9.10を入れても半年後にはアップグレードしなきゃいけなくなるので、インストールしてトラブって・・っていう苦労があまり報われない気がします。。

Modeling Forum 2009に行ってきた

modeling

先日六本木ミッドタウンで行われたModeling Forum 2009に、午後から行ってきました。会場はスーツを着た40〜50代のおじさまで溢れており、セッション中にノートPCを開く人など皆無で、開始5分で寝始める人も多く、技術系カンファレンスとの違いをまざまざと感じてきました。
# 寝てるおじさまは何しにきてるんだろう？この不景気に余裕があってうらやましいなぁ。

ただ、そんなカンファレンスの中でとても勉強になったのが、日揮情報システム株式会社の岩田アキラさんによる「BPMN 2.0に見るプロセスモデリングとデータモデリングの接点」というセッション。最近仕事でBPMN書いたりBuriのXPDL書いたりしてたこともあってBPMN 2.0に興味が出てきていたところに、の岩田さんが講演するということで、とても楽しみにしていたのでした。

セッションはのブログ記事＋αという内容。BPMN 1.0は図の書き方の仕様のみでファイル形式に関して何ら規定していないため、ツール間の互換性もなければそのまま実装に移すこともできなかったわけですが、BPMN 2.0のワーキンググループにツールベンダーが入ったことで、より実装を意識した仕様が盛り込まれたそうです。
セッションのテーマである、プロセスモデリングとデータモデリングの接点でいうと、BPMN 2.0では画面や帳票、サービス呼び出し時の入出力メッセージなどもXMLで定義することができるようになりました。つまり、「仕事がどう流れるか」だけでなく「仕事で何が流れるか」も明確に書くことができるようになった、ということです。
これは結構重要だと感じていて、BPMNを書いている時点から「何」に着目することを意識させられるようになったことは、大きな変化になりそうです。自分がこれまでBPMNを書いていた時には、スイムレーン間でメッセージが送受信されることで満足してしまい、実際にそこで何が流れるのかは、後のフェースで詳細化していました。そうすると、BPMNとデータモデルを別々に作ることになってしまい、２つの間で齟齬が発生して詳細設計で気づくといった問題が発生しがちでした。BPMNを書いているときから入出力I/Fのデータモデリングをすることで、後工程で発生する問題を未然に防ぎ、さらにお互いを補完し合うことで図の理解力が上がる、という効果が期待できるのではと思います。
実際これはBPMNの問題ではなく、自分の書き方というか、設計の進め方の問題ですので、BPMN 2.0を待たなくともすぐに実践可能です。そして、このような意識の変化を生み出すということが、BPMN 2.0の隠れた効果になるのではと思います。
この他にも、自分はこれまで概念データモデルでもDBを意識したモデリングをすることが多かったのですが、画面や帳票、メッセージも概念データモデルに含めていいんだ、ということに気づかされました。自分にとって、大変ためになったセッションでした。

2009-11-19 追記

Modeling Forumのほぼ全セッションが、オンラインで聴講できるようになりました！BPMNに興味ある方必見です！-> http://www.idg.co.jp/expo/mdl/2009/seminar.html
BPMN 2.0以外にも、「ファシリテートされた要求ワークショップ:力を合わせてニーズを定義する」とかオススメです。要求開発ワークショップの進め方 ユーザー要求を引き出すファシリテーションや、実践ソフトウェア要求ハンドブックの著者による講演です。

会社マスタを継承を利用してモデリングする

DB modeling

パッケージソフトのマスタなどをのぞいてみると、よく「得意先」「請求先」「支払先」「仕入先」「出荷先」などのテーブルがありますよね。これらのテーブルは、大体どのパッケージでも同じように、それぞれ「会社名」「コード」「連絡先」というカラムを持っています。これらカラムをそれぞれのテーブルで持ってしまっているがために、会社名が来年の四月から変わるぞーって時に、いろいろなテーブルを修正するとか、納品書は新しい会社名なのに請求書を出してみたら古い会社名になっていて、修正伝票を起こして再度請求書を出力するところからやり直し、といった作業が発生してしまいます。
だったら、ここはオブジェクト指向的に、「会社」という親エンティティに基本的な属性を集約し、「請求先」「支払先」などは「会社」を継承した子エンティティとして定義したらどうでしょうか。責務が集約されていれば、上記のような問題は解決するはずです。現実の世界でも、「請求先」や「支払先」というモノがあるわけではなく、１つの「会社」というモノが、請求という業務から見たときに「請求先」になり、支払いという業務から見たときに「支払先」になるだけですよね。
であれば、我々が構築する業務システムにおいても、「会社テーブル」と「請求先ビュー」「支払先ビュー」としてモデリングすべきです*1。
このようにしておけば、企業が行う業務領域が広がったときにも、「旅行代理店テーブル」や「宿泊施設テーブル」などを追加することで、既存のテーブル構造に影響を与えずに対応できます*2。既存の会社マスタに「旅行代理店フラグ」を追加するだなんて、最低な対応だと思いませんか？

もちろん、このような設計を行うということは、その企業の基幹業務にまで深く踏み込むことになるので、企業側に相当な予算が、構築するベンダー側に相当な覚悟が、それぞれ要求されることになります。これをフルスクラッチで開発する案件なんぞそうそう無く、あってもパッケージの方が実績*3があったり導入効果の予測が立てられるという判断になり、なかなか難しいですね。

*1:ビューで実装することに問題があれば「会社テーブル」と１：１で関連する「請求先テーブル」「支払先テーブル」でも構わない。実際ビューよりも関連テーブルのほうが良いと思う

*2:他のサブシステムで「旅行代理店テーブル」を使わないなら、利用するサブシステムに定義すればよい

*3:赤信号みんなで渡れば〜、という意味で

iPhone 3GSではBluetoothイヤホンのリモコンが使えない

日記

って、知らんかったー！会社帰りにヨドバシ行って、店員さんに聞いて初めて知った！
リモコンくらい無くてもーって一瞬思ったけど、そのうちApple直々に出すんだろーなーとか考えたら萎えてきたので断念。
せっかくヨドバシまで来たのに。仕方ないからかわりにドラクエ買っちゃったよ・・・

TwitterのつぶやきをSkypeのムードメッセージにするGroovyスクリプトを書いてみた

Groovy Twitter Skype

Skype4Javaをダウンロードして、skype/release/skype_[linux|osx|win32].jar をクラスパスに通すか、~/.groovy/lib にコピーする。で、末尾のソースを twitod.groovy とか適当なファイルにコピーして、

groovy twitod.groovy [twitterのuserid]

で実行。最初だけ、Skype側で確認メッセージが出るので許可する必要有り。

import groovy.util.XmlSlurper
import com.skype.Skype

if (args.length < 1) {
    println "usage: groovy twitod.groovy userId"
    System.exit(1)
}

def mood = Skype.getProfile().getMoodMessage()
if (mood == null) mood = ""

def url = "http://twitter.com/statuses/user_timeline/${args[0]}.rss"
def xml = url.toURL().text

def rss = new XmlSlurper().parseText(xml)
def m = (rss.channel.item[0].title =~ /^${args[0]}:\s+/)
def tweet = m.replaceAll("")

if (!mood.equals(tweet)) {
    Skype.getProfile().setMoodMessage(tweet)
}