Vagrant - naoyaのはてなダイアリー
先日 Vagrant を触ってみたら便利すぎて鼻血が出ました。しばらく見ないうちに色々進んでるもんですねえ、いやはや参っちゃいました。 Vagrant は仮想マシンの VirtualBox のフロントエンドに相当する、ruby で書かれたツールです。vagrant コマンドなどを使ってコマンドラインから簡単に新しい VM を作れる。 % gem install vagrant % vagrant box add centos http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.3-x86_64-v20130101.box % vagrant init centos % vagrant upこれだけで CentOS の Linux box をローカルマシン内に立ち上げることができる。*1 *2 なにこれすごい。 % vagra
PDL で PageRank - naoyaのはてなダイアリー
id:smly さんが PageRank や HITS を Python で実装 されているのに触発されて、自分も PageRank を Perl で実装してみました。 PageRank の計算の中心になるのは Power Method (べき乗法) です。べき乗法では行列とベクトルの積を計算しますので、手軽に使える行列演算ライブラリがあると楽でしょう。 色々調べてみたところ、PDL (The Perl Data Language) が良く使われているようでしたので、これを選択しました。PDL では各種行列演算が簡単に行える他、文字列評価をオーバーライドして行列の文字列出力を良い具合で定義してくれていたりと、なかなかに便利です。PDL は行列計算以外にも色々な科学技術計算やグラフ描写などの操作をサポートしているようです。 さて、PDL を使った PageRank 計算のコードは以下のように
あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー
お題は「あるプロセスがどの程度の物理メモリを利用したかを知りたい」です。 手っとりばやく知りたいときは top や ps などで調べると良いでしょうか。例えば手元の coLinux で top して M キーでソートすると emacs のプロセスが最もメモリを使っているようです。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1923 naoya 18 0 23120 19m 3096 S 0.0 2.0 0:55.40 emacsメモリサイズは VIRT と RES がありますが、VIRT は Virtual の略で仮想メモリ領域のサイズ、RES が Resident の略で、実際に使用している物理メモリ領域のサイズ。19MB ほど使っているようです。この emacs のプロセスが利用するメモリ領域はざっくり 20MB 程度と
Linux のプロセスが Copy on Write で共有しているメモリのサイズを調べる
Linux は fork で子プロセスを作成した場合、親の仮想メモリ空間の内容を子へコピーする必要があります。しかしまともに全空間をコピーしていたのでは fork のコストが高くなってしまいますし、子が親と同じようなプロセスとして動作し続ける場合は、内容の重複したページが多数できてしまい、効率がよくありません。 そこで、Linux の仮想メモリは、メモリ空間を舐めてコピーするのではなく、はじめは親子でメモリ領域を共有しておいて、書き込みがあった時点で、その書き込みのあったページだけを親子で個別に持つという仕組みでこの問題を回避します。Copy-On-Write (CoW) と呼ばれる戦略です。共有メモリページは、親子それぞれの仮想メモリ空間を同一の物理メモリにマッピングすることで実現されます。より詳しくは コピーオンライト - Wikipedia などを参照してください。 この CoW に
TinyMCE JavaScript Content Editor - naoyaのはてなダイアリー:
とある友人に教えても経ったTinyMCEという WYSYWIGWYSIWYG な HTML エディタライブラリがやばそう。 JavaScript で記述された LGPL でオープンソースな クロスプラットフォームの 多言語対応もしてて 簡単に使える ライブラリ。似たようなものに htmlArea というのがあって結構昔に話題になってたんですが、導入がめんどくさかったりブラウザによってはまともに動かなかったりとか色々面倒な感がありました。TinyMCE の方はと言いますと、Installation instructions にもあるとおり、 <html> <head> <title>TinyMCE Test</title> <script type="text/javascript" src="/js/tiny_mce/tiny_mce.js"></script> <script type=
naoyaのはてなダイアリー - CSS signature
はてなアイデアで、はてなダイアリーの body に CSS signature なるものをつけてほしいという要望をいただきました。(いただきましたというか、ずいぶん前のものがあがってきた、というか。) 恥ずかしながら CSS signature というのは初めて耳にしたもので、最初は何だかわからなかったのですが、どうやら body の id にサイト固有の文字列を振って、ユーザースタイルシートを使いやすくしようというものらしい。(そうとは知らずにidea:5541を id にローカルな名前をつけるっていうのはあまり前例をみないっていうんで却下してしまった、ごめんなさい。) たとえばこの日記なんかだと <body id="d-hatena-ne-jp_naoya">と振っておくと body#d-hatena-ne-jp_naoya { ... }な CSS をユーザースタイルシートに定義して
Account Auto-Discovery を dc:creator から foaf:maker へ - naoyaのはてなダイアリー
Account Auto-Discovery の仕様ではこれまで作者を表すのに dc:creator を使ってきましたが、どうやら foaf:maker を使った方が行数も短いし RDF の構造的にもしっくりきそうだということが分かったので、そのように変更しました。 結果、 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <rdf:Description rdf:about="http://d.hatena.ne.jp/naoya/20050803/1123053496"> <foaf:maker rdf:parseType="Resource"> <foaf:holdsAccount> <foaf:OnlineAccount
Account Auto-Discovery 仕様暫定版 - naoyaのはてなダイアリー
今日はまず結果から書いておこうと思います。昨日の microformats 的にメタデータを囲むという話は採用しない、それからコメントアウトするという話をひとまず置いて、 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <rdf:Description rdf:about="http://www.hatena.ne.jp/info/perl/autodiscovery/test"> <dc:creator> <foaf:Person> <foaf:holdsAccount> <foaf:OnlineAccount foaf:accountNa
Accout Auto-Discovery 仕様修正案 - naoyaのはてなダイアリー
いくつかのフィードバックを受けて Hatena ID Auto-Discovery 改め Account Auto-Discovery の仕様を修正。 まず、 それはともかく、ふと思ったのは、FOAFに対する名前空間指定は無くて良いんだろうかということ。XMLにはそんなに詳しくないのでただの勘なのだが、FOAF内に記述するならともかくとしてXHTML内に記述する訳だから、デフォルトの名前空間をFOAFにすることは出来ないんじゃないかなと考えた。 という名前空間に関する話。その通りなのでこれは即採用です。 あと Trackback で RDF を HTML/XHTML に埋め込む時に，XHTML にはコメントとしてではなく直接埋め込むことを想定していて，現状では DTD 違反になるからコメントでって話だったと思います．だから Trackback ping URI の埋め込みについての話では
続々 Hatena ID Auto-Discovery - naoyaのはてなダイアリー
RFC: 続・Hatena ID Auto-Discovery の仕様 から引き続き Hatena ID を HTML に埋めこむという話。前回のエントリーでは、http://www.hatena.ne.jp/user/naoya など、ブラウザからアクセスしたときに 2xx を返さない URI を用意してきつつ、 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" /> <link rel="DC.creator" href="http://www.hatena.ne.jp/user/naoya" />と HTML に追記するというのでどうだろう、という提案だったのですが、コメントや id:tociyuki さんとのやりとりで上がって来たのが、DC.creator に複数のアカウントを定義したい場合はどうだろう、とい
RFC: 続・Hatena ID Auto-Discovery の仕様 - naoyaのはてなダイアリー
Hatena ID Auto-Discovery の仕様について。長文です。 先日そのページが誰のものなのかを示す識別子を埋め込む仕様を考えているという話を書いた後、さまざまなフィードバックをもらうことができたので、後日Hatena ID Auto-Discovery の仕様というのを書きました。それから新たに幾つかフィードバックをいただきまして、それらを整理しながら方向を修正中です。 しかし、みなさんほんといろいろアドバイスありがとうございます。つくづく自分がウェブの仕様について不勉強だなあと痛感しつつ、ウェブの標準って色々あるんだなあとしきりに感心したり、一人で色々調べてるだけじゃなかなか正解には行き着かないなあというのが正直思ってみたりです。 もとい、 まずそもそも僕が考えた仕様は...という前にまず何をしたいかを明確にしないとですね。僕がしたいのは、はてなダイアリーを含めたインター
naoyaのはてなダイアリー - Hatena ID Auto-Discovery の仕様
前回のエントリーではたくさんのコメント、トラックバックをいただき、ページの中にはてなアカウント名を埋め込む仕様が徐々に固まりつつあります。FOAF を使う、microformats 的解決手段を使う、PI を使うなどいろんな方法があるんだなあと勉強になりました。それから rel="payment" なんて話が海外ではあがっているという事も知りました。 それでどれを採用しようか、というところですが、投げ銭以外の目的でもそのページを書いている人の ID が取得できると将来的に拡がりがありそうだと思い、汎用的な Dublin Core を使った表現方法を試してみています。 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" /> <link rel="DC.creator" title="id:naoya" href="ht
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
