computer

去年はXperia Tabletsを買ったり、INFOBAR A01をAQUOS PHONE ZETA SH-02Eに変更して、Androidへの依存度を高めた年であった。 会社からはGmailもTwitterもFacebookもアクセスできないので、全部SH-02Eから見ることになる。また、電子書籍はラノベをメインに買っているのでBOOK☆WALKERの比重が高いが、BOOK☆WALKERはPCでは使えない。もう一つのメインのKinoppyはKinoppy for PCがあるのだが、Android版/iOS版/Mac版と異なり外部コンテンツ(PDF, xmdf)を取り込めないのでXperia Tablet Sでの方がメインになりつつある。“ビューワ"としての視点ではスマートフォンとタブレットの手軽さはなかなか悪くないように思える。 でも、やはりPCが好きなのだ。 キーボードとEmacsキーバインドとSKKが好きなのだ。 “ぱそこん"なるものと出会って31年。Micro Emacsに出会って23年。モノホンのEmacsに出会って20年。そしてSKKと出会って18年である。俺とPCとキーボードとEmacsとSKKは親子に近い長いつきあいなのだ。 ぶっちゃけフリック入力も手書き入力もしたくないよ。キーボードでもATOKとかMS-IMEとかGoogle IMEとかは勘弁な。エディタはEmacsかViならOKだが秀丸とか勘弁な。そして日本語入力はSKK。いいよもう死ぬまでSKKで。 モバイルPCを昨年末にVAIO Duo 11に変更したのだけれど、これとSKK日本語FEPの組み合わせは素晴らしい。気軽にWindows Storeアプリでほいほいとコンテンツを見れる上にCPUはCore i7 3517Uで、SH-02EのSnapdragon S4 ProやXperia Tablet SのCortex-A9を圧倒する性能はある。ただちょっと重いけどな。 とにかく、Windows8環境はわりと好きだ。 なので、今年はIntelとMicrosoftの今年の動きには期待したいんだよ。そうそうARMやAndroidやiOSには負けないでほしい。

ARM vs Intelがどうなっていくかはとりあえず気になる。 なぜExynos5250はスマートフォンに乗ってこないのか。なぜARMはbig.LITTLEを持ち出したのか、というあたりを考えるとCortex-A15の消費電力の高さが感じられる。つまり、ARMももう電力の壁にブチあたったということだろう。ARMだから省エネなんて話はもうなくて、ただ半導体プロセスのデキが消費電力を決めてしまう。 Exynos5250はApple A6と同じSamsungの32nmプロセスのはず。Apple A6はクロックが低い(最大1.3GHz)からよいが、Cortex-A15を1.7GHzで動かすのはなかなか苦しいのだろう。できれば28nmで作りたいがTSMCを除く全ファウンドリが28nmで絶賛爆死中なのでどうにもならない。とりあえずbig.LITTLEなSoCが出てこないとCortex-A15はどうにもなるまい。ARMもしばらくSnapdragon S4無双かも。 ただ、次世代AtomのValleyviewコアがCortex-A15よりもかなりシンプルなコアに留まっていそうなことを考えると、IntelはBayTrailとMerrifieldの省エネ性能を売りにして攻勢をかけてくるかもしれない。まあ、22nmのSoCプロセスのデキ次第ではあるけれど、22nmの高速CPU向けプロセスがまあまあ成功しているようなので、爆死まではしないだろうなと予想する。 とりあえずARM勢とIntelでガチ殴りあいしてよい商品が出てくれればよいね。

いろいろあった一年であった。 勤め先の経営状況がアレな感じになって、今年はずっとニュースをにぎわしていたのが印象的。春の業績次第でどうなるやらよくわからん状況ではあるが、まあ、希望退職しなかった(させてもらえない状況だった)のもあるし、とりあえずできる限り頑張ってみましょうかね。 技術的な話。DVGSはBazaarやMercurialを捨ててgit一本にしてみた。これはわりと幸せになれた気がする。まぁ、LinuxのKernelまわりのカスタマイズをしたりする方向なので相性もよい。職場環境のsubversionもgit svn経由で使うのに慣れてしまい、svnを素で使うのがつらい。今後はgitの導入を進めたいね。 あとはAndroid。Xperia Tablet SやAQUOS PHONE ZETA SH-02Eを買って、Androidへの依存度を高めてしまった。主に使っているアプリはGmailとGoogle ReaderとTweakDeckと電子書籍系(Kinoppy&BOOK☆WALKER)という風味で、主にビューワなのだが。どーもスマートフォンにせよタブレットにせよ、これで文章を書きたいとは思えないのだな。 PCはVAIO Duo 11がポイント。こいつで使ってみた限りではWindows8はよいヤツである。Androidのスマートフォンやタブレットと違い、VAIO Duo 11には文章をそれなりに入力できるキーボードがついているし、CPUはぐっと速いので、メインになりうる存在だと思う。11月末に水没させてしまったので、交換品が来るのは1月中旬なのだが、早く帰ってきてほしいもんだ。 とにかく、まあ、来年はPC的にもデジタルガジェット的に面白い一年であってほしい。

手元バージョン管理を全部gitにしてからはや数ヶ月。最初はいろいろとまどったが、案外慣れてしまうものだ。 まず仕事方面。いろいろな都合から会社の中央レポジトリはSubversionなので、gitはgit-svnと共に使っている。最近の仕事はどっぷりLinuxで、gitでさくさくfeature branchを切りかえて作業ができるのは実によい。 仕事で相手をしているSubversionのレポジトリはtrunk/branches/tagsの標準的なスタイルなので、git svn clone時には-sをつけて、リモートのsvnブランチもローカルのgitのブランチとしてcloneしている。 git svn clone -s (subversionのURL) hoge このcloneはかなり遅いが、まあ、一度作ってしまえば、あとは適当に[cci_bash]git svn rebase[/cci_bash]してゆけば更新されるのでさほど困りはしないはず。 さて、そうやってcloneしたレポジトリの上で、何か機能を作りこむ必要があるときは、 git checkout -b hogehoge と作業ブランチhogehogeを作って作業し、確認が終わったら git checkout master して、git svn rebaseして、おもむろに、 git merge --squash hogehoge あるいは git merge ーno-ff hogehoge としてhogehogeブランチの作業内容をマージしてから最後に git svn dcommit して、またgit svn rebaseしつづける定常状態に戻る。dcommit直前まではsvnのことを忘れていられるのがよい。 自宅環境(Windows&FreeBSD)にはsvnはからまないので普通にgitを使っている。自宅サーバにbareレポジトリを作って、そこにssh経由でpush/pullすることで出先からの取得・更新も可能にしているが、運用練習も兼ねてbitbucketに移動したほうが幸せかもしれないと最近は考えている。 LinuxでもFreeBSDでもWindowsでも、シェルにbashかzshを使っている限りは補完が充実しているので、シェルで使うのが一番だ。ただ、作業はEmacs上で行うので、履歴や差分の確認はEmacs上のEggに頼ることも多い。慣れ親しんだEmacsのvc.elライクなキーバインドなので悩まずに済むのがよい。 さて、コマンドラインでgitを使っていてもコミットメッセージはEmacsを使いたいので、core.editorにはemacsclientを指定している。FreeBSDとLinux上のEmacsは(prefer-coding-system 'utf-8-unix)にしているので何もせずに新規バッファを作ればutf-8になるが、Windows環境は諸処の事情でutf-8を最優先にしていないので何もしないとコミットメッセージが化ける。んで、下記のhookを入れている。 (add-hook 'server-visit-hook (function (lambda () (if (string-match "COMMIT_EDITMSG" buffer-file-name) (set-buffer-file-coding-system 'utf-8))))) 職場でもっとgitとgit svnの啓蒙活動をしたいところだなぁ。

気が向いたのでconfigureしてmakeしたらfile.cでエラーが出た。 --- file.c.bak 2012-11-17 02:56:36.102146900 +0900 +++ file.c 2012-11-17 03:14:50.222683100 +0900 @@ -17,6 +17,7 @@ #ifdef __CYGWIN__ #include <windows .h> #include <sys /cygwin.h> +#include <wchar .h> #endif #include "ruby/ruby.h" @@ -3190,7 +3191,7 @@ len = lstrlenW(wfd.cFileName); #ifdef __CYGWIN__ if (lnk_added && len > 4 && - wcsicmp(wfd.cFileName + len - 4, L".lnk") == 0) { + wcscasecmp(wfd.cFileName + len - 4, L".lnk") == 0) { wfd.cFileName[len -= 4] = L'\0'; } #else trunkを見るかんじ、こんな対応でよかろう。