ただ、使っている中でどうしても気になる事柄がある。

自動保存

Scribesは次に引用する設計思想によって、わずらわしい手間からユーザーを解放している。

仕事の流れの阻害を最小限にすること、おもしろみのない作業を自動化すること、不要な設定変更をなくすこと、シンプルさに基づいた理性的な編集作業を達成することを目標にしている。この目標を達成するために必要のない慣習は守っていない。
Scribes – Wikipedia http://ja.wikipedia.org/wiki/Scribes

ファイル保存もしかり、ユーザは毎度Ctrl+Sを押下する必要がない(もちろん任意のタイミングでCtrl+Sによる保存は可能)。
最後の入力から一定時間が経過すると自動的に保存される。

これには少し困ってしまう。
例えば、何か一時的なメモを取りたいがためにScribesを開き、書き入れる、自動保存によりファイル化される。デスクトップに。
自分にとって少なくとも2つの点で問題がある。

1. ファイル化するつもりがないのにファイル化されてしまう（破棄して終了するつもりだったのに!）。
2. GNOME3ではデフォルトでデスクトップにファイルが表示されない(~/Desktop/の中身は表示されない)。

なので、いつぞやの覚書が~/Desktop/に入っていたりする。
デスクトップに表示されないので、気づいてすぐに捨てるという事もできない。

おそらくは、『自動保存』というチェックボックスがどこかにあるのだろうと探したが、ない。
Scribesの設定メニューは非常にシンプルで、設定できる事はそれほどない。

困ったので情報探したら Scribes のフォーラムにそのままの話題があった。

Feature request: the ability to turn on/off autosave
https://bugs.launchpad.net/scribes/+bug/368414

「稼働中のサーバースクリプトをScribesで編集するとコーディング途中で保存されて大変な事になってしまうから自動保存とか困る」

この人は自動保存以前に問題が色々あるのだけど、こちらも自動保存で困っているので味方する事にして読み進めた。
驚く事に2009-04-28から始まったこの自動保存に関するスレッドは、実に2年近くもやり取りが成されている。

このスレッドから読み取れた事がいくつかあった。

1. Scribes自体に自動保存を無効にする設定機能は備わっていない事
2. Scribes開発側は今後それを実装するつもりがない事（おそらく未来永劫ない事）
3. 自動保存を無効にする場合のソースコード修正個所
4. 自動保存の有効無効を操作するPluginの存在

解決方法は判明したが、Scribesの精神を受けて、しばらくこのまま使ってみようかと心変わりしたりなんかしてるのだけど頭に来たらすぐ直す。

先日より、Fedoraがブート失敗するようになってしまった。
このまえレジュームの復帰失敗した事があったからそれかなー。

fsckコマンドで何かしろと書いてあるようなのだけど知識が足りない。
exitで抜けるとOSが起動するので、そのまま使っていたが、このままではダメだろうと情報探した。

shell command to fix filesystem
http://ask.fedoraproject.org/question/682/shell-command-to-fix-filesystem

(Fedora16 betaで)tonybrowningさんが同じ問題で困っていた。

fsckによる解決方法が書いてあったのでマネしたら直りました。
fsckにより無事修復されたようです。
なお、「fsckコマンドは場合によってファイル(システム)を破壊してしまうかもしれないのでバックアップ必要マジ」という情報は後になってから知りました。あぶない。

手順：
まず、blkidでブロックデバイスの情報を表示する

次に、fsckにブロックデバイスを与える。

ファイルシステムのチェックや修復が行われる。
/dev/sda2を指定しても同じはず。
LABELにFedora-16とあったから/dev/mapperの方を選びました。

終わったらexitで抜ける。

改めて再起動したら問題の現象は発生しなかった。
ok.

買うの後回しにしようと思ってたけど…。

物理アニメーションをサンプルにしているのが興味深い。

何か書いて(描いて)みようかと思う。

DebianとHTML5。

読むのは週末になりそう。

Debianはまだ一度も触ったことないな。

最初、
OpenCV-2.3.1のプロジェクトをインポートすると、OpenCVのプロジェクトがエラーとなりビルドできない。SampleやTutorialのプロジェクトも引きずられる。
Eclipseのコンソールには以下のメッセージ。

OpenCV-2.3.1のプロジェクトを右クリックして、メニューから
[Android Tools] -> [Fix Project Properties]
で直る。
これ、メッセージの通りであるけど、Pleiadesなどで日本語化してある場合は、
[Androidツール] -> [プロジェクト・プロパティを修正]
となる。

　このファイルは、Dropboxで共有していて、Linux(Edit:Scribes)とAndroid(Edit:Jota Text Editor)で編集しているのだけど、お互いに更新を行い、特定の状況（ファイルの状態）に陥ると上記のようにクラッシュする。

　文字コードはUTF-8。
　vimやgeditでは特に問題なく開ける。
　BOMの有り無しが影響しているのかもしれないと思い、以下の検証をする（この手段で正しく検証できているかどうか自信がない）。

BOMの有り無しに関わらず問題なく開ける。

　ちなみに、Android側で編集した後に発生するかと言えば、必ずしもそうではない。
　常用したいので何とか解決したいところ。

　以前から興味のあったScribesというテキストエディタを使ってみようと思う。
　Scribesは補完機能に注力されたエディタという事で、これはScribes設計思想によるものと思う。

仕事の流れの阻害を最小限にすること、おもしろみのない作業を自動化すること、不要な設定変更をなくすこと、シンプルさに基づいた理性的な編集作業を達成することを目標にしている。この目標を達成するために必要のない慣習は守っていない。
http://ja.wikipedia.org/wiki/Scribes

　ダウンロードページにはFedoraのRPMパッケージへのリンクがあってダウンロードできるのだけど、そのパッケージではfedora16へのインストールがうまくいかない。
　情報を漁ってみると同じ問題で困っている人がいて、最終的に次のコンテンツにたどり着く。
　
http://mystilleef.blogspot.com/2011/04/installing-scribes-on-fedora-and-rpm.html

　ここでは、Fedora15(beta)へインストールに成功したと言っているがFedora16でも同じ。
　以下の手順を踏むとインストール完了となる。この手順は上記コンテンツで示される内容と同じ。

外観は非常にシンプルで、右上の赤いサークルにマウスカーソルをかざすとメニューバーが出現する。
ショートカットが豊富に用意されており、Ctrl+hでチートシートが表示される。

しばらく使ってみようと思う。

　さて、紹介されている手順では、最初に依存問題を解消するためにいくつかのパッケージをインストールするのだけど、今回あえてそれらをインストールせず、make install まで何度も失敗（依存性の問題により）を繰り返しながら、その都度必要となるパッケージをインストールする方法をとった（不要なパッケージをインストールしたくないために）。
　結論として、示されるパッケージ群に過不足はなく、つまりFedora16へのインストールでも上記手順が正しい事がわかった。
　この作業の記録を以下に記述する。上記でインストール完了した人には不要な情報だが、もしもこの解法を知らずにインストールを進め行き詰まっている場合には多少参考になるかもしれない。

　まず、ソースコードをBazaarのリポジトリから取得する必要があり、bzrのインストールから進めていく。

失敗
gnome-common をインストールする

再挑戦

ここでは、glib-gettextやglibではなく、glib2-develをインストールするのが正解。
なお、この時点でautoconfとautomakeも必要なのだが、自分の環境ではインストール済みだったのでインストールしていない。未インストールであればglib2-develと合わせてインストールすること。

再挑戦

intltoolをインストールする。

再挑戦

gnome-doc-utilsをインストールする。

再挑戦

エラーメッセージではpygtksourceview2と言っているが、pygtksourceviewをインストールするのが正解。

再挑戦

OK

この問題はrarian-compatをインストールする事で解消される。

OK

あけました今年もよろしく。

本書は、先日電子書籍版が発売されたばかりですが、紙の本です。

本書は、3Dオブジェクトをいじくり回して興奮する本です。

興奮したいと思います。

Android受託開発の奥義

ビジネス寄りの特集タイトルだけど内容的には、受託開発についての文章は半分にも満たないので、表紙だけ見て買ったり買わなかったりしないこと。

シェルスクリプトの連載始まりました。

　テーマはツリーデータの枝刈りで、かなり昔に作成したWebアプリ 実用 R アナグラミング を題材にしてローマ字アナグラミングのデータ構造をいじくりまわすという趣旨です。

　実用 R アナグラミング は、ANIを(アニ|アンイ)の複数読みができないというバグを抱えたまま数年放置していたアプリなのですが、今回Gunma.webの発表機会もあって取り組んでみました。
　今回作成したライブラリは、まだアプリに取り込んでないのでバグは抱えたままです（というか元の作りが悪くて単純なI/Fの差し替えで対応できない）。そのうち差し替えます。

　今回のソースコードはgithubに置いてあります。disってください。

romaji-anagram
https://github.com/ivoryworks/romaji-anagram

　発表後、具体的な処理について質問がいくつかあって、お茶を濁すような形で説明してしまったのですが、詳しくははコード見てください。ごめんなさい。

　それと、これは個人的なポリシーなのですが、今回のスライドにソースコード載せてません。今後も私のスライドにソースコードが載ることはありませんし、（たぶん）これまでも無かったと思います。
　理由はいくつかありますが、一番大きいのはGunma.webが言語に特化した勉強会でないからです。
　今回の題材はPHPで書いていますが、PHPerのプログラマーの方にも非PHPerのプログラマーの方にも非プログラマーの方にも同じくらいのInputになるように心がけています。
　LTだったら1枚のスライドに長くて十数秒しか割けないとか、スライドなのであまり小さな文字は書けないとか、そもそもコードがダメとか小さな理由はいくつもあるのですが、まあそういった事なので今後ともよろしく。