私にはこのブログを書く権限がない。

Twitterじゃ書ききれない何かを書くアレ

Semantic WebとLinked Data

最近、Semantic WebとLinked Dataについて触れる機会があったのでメモ的に。ここでは具体的なフォーマット等は述べず、その概要だけに留めておく。
後に具体的なフォーマット等も書く可能性は十分にあるけど。

Semantic Web

Semantic Webとは

Semantic WebとはURI同士の繋がりを主語(Subject)、述語(Property)、目的語(Object)でグラフ的に表現されたものである。
具体的にはRDFと呼ばれる形式で、XMLやN-Triples等のフォーマットによって表現される。
ポイントは、RDBMSのようにバイナリファイルに記録するのではなく、XMLのような人間にとって可読性のあるフォーマットで記録している点である。
機械同士のネットワークだったものに、人間を取り込もうとする新しいWebの形を目標としている。

Ontologyとは

Wikipediaの「オントロジー (情報科学)」によれば

コンピュータ科学 (en:Computer Science)と情報科学 (en:Information Science)において, オントロジ(概念体系) は、あるドメイン内 (en:Domain of discource)の概念とそれらの概念間の関係のセットとしての知識の形式的な表現です。 それは、そのドメイン内のエンティティについての理由付 (en:Reasoning)として使われます。それは哲学用語の(オントロジ) (en:Ontology)から大きく異なります。

おそらく初見で理解できる人間は少ないだろう。
一言で言えば概念及び概念同士の関係を定義したグラフである。ここで「概念」というのは、Semantic Webにおける主語に用いられるクラスのことであり、「概念同士の関係」というのは、Semantic Webにおける述語のことである。
Semantic Webにおいては、こちらもRDFで記述される。つまり、Semantic WebにおけるOntologyとは、主語のクラス及び述語を定義したRDFファイルのことである。
また、述語は既に同じ機能・同じ意味を持つ既存の述語が存在すれば、新たに定義せず、それを使うことが一般的となっている。

Linked Dataとは

Linked Dataとは様々なモノにURIを与え、Semantic Webによってそれらのモノ同士の関係を表現したものである。
従来のデータベースにおいては、「述語」に相当する概念がなかったため、データベースの新しい形として近年注目されつつある。
データをどんどん公開していき、様々な種類のデータをリンクしていこうという思想が根本にある。
その根拠がLinked Open Dataと呼ばれるプロジェクトである。これは、公開されているRDF同士をさらに繋げていくというものである。

ScalaにおけるMapのimmutableとmutable

Scalaはじめました。Javaの面倒な要素を簡単にしていて使いやすいのはいいんだけど、Map(というかCollection)の仕様にはまったのでメモ。

immutableとmutable

Scalaはマルチパラダイム言語といい、手続き型ベースにも書けるし、関数型ベースにも書けるのが特徴である。関数型ベースに書きやすいように、通常Collection(MapやList等)は破壊が不可能なクラスとなっている。これを破壊不可能な(immutable)クラスという。
Scalaでは、破壊不可能クラスを使うことを推奨しているが、破壊不可能な方法を取るのが困難な場合がある。この場合、そのCollectionを破壊可能な(mutable)クラスとして宣言することで、解決できる。
immutableなMapを宣言する時は単純である。

val immutableMap = Map("K" -> "V");

mutableなMapを宣言する時は少しややこしい。

val mutableMap = collection.mutable.Map("K" -> "V");

imutableなMapをmutableなMapにDeeply Copy(Clone)

方法は単純であるが、ぐぐっても変な方法ばかりで、なかなか「コレだ!」というものが見つからない。結局、以下の方法が一番良さそうだ。

val mutableMap = collection.mutable.Map.empty[Any, Any] ++= immutableMap;

mutableなMapをimmutableなMapにDeeply Copy(Clone)

こちらの方法も単純であるが、ぐぐっても変な方法ばかりである。toMapメソッドの存在があまり知られていないのだろうか。

val immutableMap = mutableMap.toMap

MVCとRails

普段Railsで、特にscaffoldを使って何かを作っていると、MVCモデルについて色々誤解してしまうことがある。ちょっと機会が有ったので、ここでMVCモデルについてもう一度復習しておくことにする。

そもそもMVCとは何か

wikipedia:Model View Controllerによれば

Model View Controller(モデル・ビュー・コントローラ; MVC)は、コンピュータ内部のデータをユーザに提示し、それに対してユーザが何らかの指示を出すタイプの、独自のユーザーインタフェースをもつアプリケーションソフトウェアを、以下に述べるようなmodel・view・controllerの3つの部分に分割して設計・実装するという技法、又はそのような構造をいう。

とある。アプリケーションソフトウェアを分割するするのであって、オブジェクトを分割するというわけではないのだ。
つまるところ、1つのビューが複数のモデルを参照しても構わないし、1つのコントローラで複数のモデルを使っても構わないのだ。

Model=レコードではない

再度、wikipedia:Model View Controllerから引用しよう。

Model

そのアプリケーションが扱う領域のデータと手続き(ビジネスロジック - ショッピングの合計額や送料を計算するなど)を表現する要素である。また、データの変更をviewに通知するのもmodelの責任である(modelの変更を通知するのにObserver パターンが用いられることもある)。
多くのアプリケーションではデータの格納に永続的な記憶の仕組み(データベースなど)が使われている。MVCの概念では、データの(UI以外の)入出力は取り扱わないので、データアクセスも本来MVCの概念の範疇を超えるものではあるが、敢えていえばmodelの中に隠蔽されると考えられる。

Railsでは通常、Controller内でデータの書き込みを行い、Modelでは:has_many等のデータに対する属性付与(?)しかコードを書かない。
その上、Model.newによってレコードを新規作成したり、model.save!でレコードを保存している為、Model=レコードだという誤解を産んでしまう(酷い人は、Modelを「データの設定をするための何か」程度の認識かもしれない)。
そのため、Model=レコードと勘違いしがちである。
各ModelクラスではActiveRecordクラスを魔法の言葉のごとく継承しているが、ActiveRecordクラスはデータベースとのやりとりを行うクラスであり、つまりMVCにおけるModelの大部分をActiveRecordが行なっている。
RailsにおけるModelはあくまで「データベースとデータのやり取りを行う」ものであって、「データベース上のデータそのもの」ではないのだ。

Controllerの本来の役割

先ほど、「Railsにおける」というのを強調したが、これには少し理由がある。
Railsにおいて、フォーム等から入力されたデータをデータベース上に保存する際、データベース上に保存する前にデータに何らかの処理を行わなければいけない場合、Controllerでそのデータを処理する人が多いのではないのだろうか。
しかし、この方法はMVC的には全く正しくない。なぜなら、MVCにおけるControllerは「ユーザからの入力を受理する」ということだけが本来の役割であって、データの整形はModelの仕事だからである。
ではなぜ、Controllerでそれらの処理を行う人が多いのだろうか。理由は簡単で、scaffoldによってgenerateされたControllerにおいては「データの整形を行ってからデータベースに保存する」という行為が想定されておらず、model.save!によって受け取った引数をそのまま保存するテンプレートを生成するからである。
MVC的に正しいやり方は「Model内にデータを整形し、保存するというメソッドを追加し、Controllerからそれを呼び出す」ことなのだろうが、それが面倒 or コードが汚くなるという思想があるのだろう。
したがって、Railsにおいてのみ、データの整形をControllerにまかせる、というのが一般的となっている。
Java等の他の言語やフレームワークMVCで書くときは、データの整形はModelにさせるべきなのだ。

最後に

Railsをdisっているような感じの記事となってしまったが、僕が言いたいのはRailsは「Model View Controller」という名称を辞めて、「Data View Engine」のような感じで別の名称にするべきであるということだけであって、Railsを辞めて別のフレームワークを使いましょうというわけではない。むしろ、「Webフレームワークは何が一番いい?」と聞かれたら、真っ先に「Rails」と言えるくらいには自分はRails好きなので、そこだけは誤解しないでいただきたい。

「はじめてのOSコードリーディング UNIX V6で学ぶカーネルのしくみ」を読みました

TLで話題になってた「はじめてのOSコードリーディング UNIX V6で学ぶカーネルのしくみ」を読みました。
いつかはOSのコードを読もうといくつかのカーネル読書系の本を漁っていたことはあるのですが、しくみだけ解説しててソースコードがほとんど乗ってない状態で、あるいは変な訳され方をされていたので挫折しました。
しかしこの本はソースコードと併せて解説が乗っているので、非常に読みやすく、日本人が著者なのでちゃんとした日本語で書かれていたので凄く理解がしやすい本です。
また、アーキテクチャやOSの基本に関する説明もなされているので、知識がなくても読めると思います。
これからOSカーネルの勉強をしたい人には凄くいい入門書になると思いました。

はじめてのOSコードリーディング ~UNIX V6で学ぶカーネルのしくみ (Software Design plus)

はじめてのOSコードリーディング ~UNIX V6で学ぶカーネルのしくみ (Software Design plus)

Rails3.2でLightbox2を使う方法

RailsLightbox2を使うにはちょっとLightbox2のソースコードを書き換える必要があったのでメモ

1. 普通に公式サイトからLightbox2をダウンロード
2. ファイルをコピーする時の場所がかなり重要になってくる。
js/lightbox.js -> {app_root}/app/assets/javascripts/lightbox.js
jQueryを使ってなかったら)js/jquery-1.7.2.min.js -> {app_root}/app/assets/javascripts/jquery-1.7.2.min.js
css/lightbox.css -> {app_root}/app/assets/stylesheets/lightbox.css
images/{next.png, prev.png, loading.gif, close.png} -> {app_root}/app/assets/images/{next.png, prev.png, loading.gif, close.png}
3. コピーしたlightbox.jsを編集。
images/loading.gif
images/close.png
となっているところを、それぞれ
assets/loading.gif
assets/close.png
に変更。こことは全く違う書き換え方なので注意(Rails2とRails3の違い)
4. あとはLightbox2を使いたいviewsでjavascript_include_tagやstylesheet_link_tagを使ってそれっぽく書けば終わり。



2013/01/27追記
表示する画像が単体のときはこの方法でいいのですが、複数の画像で端っこをクリックすると次の画像に遷移する機能を使う時はこの方法だけではダメなことが発覚。
対策としては上記の方法に加えて、lightbox.cssを編集する必要があり
../images/prev.png
../assets/next.png
をそれぞれ
../assets/prev/prev.png
../assets/prev/next.png
にする必要がある。これを行わないと次の画像に遷移することはできるが、矢印が表示されないためユーザは次の画像に遷移させる方法がわからない。

新年の目標

SAO原作を読んでたら年を越してました。
謹賀新年。今年もよろしくおねがいします。

去年は本当に色々ありました。んでまあ当然課題も浮き彫りになりました。
そこで今年の目標を月別に。

1月
Linuxのデバドラ周りの勉強をはじめる。
・詳しくは言えないけど、2月から学外での活動も色々はじまる予定なので、それに備える。
2月
・HACKING:美しき策謀かBINARY HACKSをコンプリートする。

Hacking: 美しき策謀 第2版 ―脆弱性攻撃の理論と実際

Hacking: 美しき策謀 第2版 ―脆弱性攻撃の理論と実際


Binary Hacks ―ハッカー秘伝のテクニック100選

Binary Hacks ―ハッカー秘伝のテクニック100選


・研究室が始動になるそうなので、かなり真面目にOSの勉強にとりかかる。
3月
・いい加減にTOEICを受ける。目標は550点。
HaskellScala辺りを競技プログラミングで使えるレベルにまで持っていく。
・積立貯金をはじめる。
4月
・(一般で院試を受けるなら)院試勉強をはじめる。まずは忘れている数学から。
・(推薦で受けるなら)輪講で読む本を読破する。
RubyC++のテンプレート辺りでメタプログラミングを勉強する。
5月
・自分のやりた気な研究分野の論文に手をだしはじめる。
・(一般で院試を受けるなら)多分最後のTOEICになるので、受けておく。目標は700点。
6月
・研究テーマを決める。(もう遅いか?)
・(推薦で院に行くなら)ここまでに、エレガントな問題解決の問題を半分以上解く。
エレガントな問題解決 ―柔軟な発想を引き出すセンスと技

エレガントな問題解決 ―柔軟な発想を引き出すセンスと技


・(一般で院試を受けるなら)専門科目の勉強をはじめる。
7月
・この時までには論文30本以上は読むようにする。(少ない?)
STL以外のC++にも手を出し始める。
8月
・上旬から卒研中間発表会の資料を作り始める。後にやりはじめると絶対後悔する。
・ここまでに、蟻本二周目かチーター本をコンプリートする。
プログラミングコンテストチャレンジブック [第2版] ?問題解決のアルゴリズム活用力とコーディングテクニックを鍛える?

プログラミングコンテストチャレンジブック [第2版] ?問題解決のアルゴリズム活用力とコーディングテクニックを鍛える?


最強最速アルゴリズマー養成講座 プログラミングコンテストTopCoder攻略ガイド

最強最速アルゴリズマー養成講座 プログラミングコンテストTopCoder攻略ガイド


9月
・卒論のソースコードを書き始める。
・夏休み終了までには論文50本以上は読むようにする。(少ない?)
10月
・卒論の草案を完成させる。
11月
・1つ以上の国内学会のイベントで発表する。
12月
・1つ以上の国際学会のイベントで発表する or 決定する。
・卒論の9割以上を完成させる。

・・・かなり厳し目に見えるところもありますが、まあ目標は目標ですので。
それでは、今年もよろしくおねがいします。