mumumuの日記: 2009/06

2009/06/29

noncalculating

自分は明確な目的や打算、仁義がない限り、自分から「エンジニアとして」滅多に人に会いに行くことがない。それは出不精であることが大きく影響していたりするが、昨日はそれナシで人を誘って飲みに行った数少ない例外である。

誘われた本人はおそらく意味がわからなかっただろうが、そうやって人と話し、影響を受けることの効用を自分は心のどこかで認めているのだろう。その意味で昨日はとても良い一日であった。ただ、こういう日はこれからもそう頻繁にはないと思う。

自分が話した内容は与太ばかりであるが、彼の話からは多くの刺激を貰った。自分にないものを持つエンジニアであり、かつ誘いに乗ってくれた id:cocoiti たんには心から御礼申し上げる次第である。

2009/06/27

Not yogurt, but kefir

[2009-06-27 17:48:37] <a****> xxx(※外人さん。女性) made some yogurt. just come here and enjoy! ってメールが友達からきたんだけど
[2009-06-27 17:48:48] <a****> それにxxxさんが返事してて
[2009-06-27 17:49:01] <a****> "いいえ、ケフィアです。" とか書いててふいた
[2009-06-27 17:49:11] <b****> ぶ
[2009-06-27 17:49:12] <a****> 日本語苦手ぶってるくせに。。。
[2009-06-27 17:49:19] <a****> ネタを分かっておる．．．．．
[2009-06-27 17:49:22] <a****> しかも本当にケフィアだった
[2009-06-27 17:49:29] <b****> GJ

----

「いいえ、ケフィアです」ネタがわかる外人さんいいねww

2009/06/25

deadline

紙媒体の締切りと戦ったのは数年ぶりだが、こんなにつらかったっけ、、(´ー｀; ) （一行独白

＃明日また第2弾が、、

2009/06/24

Mika Kaneko - Weekend Soldiers

何かを探していたい何かに手を伸ばしたい
何かに惹かれていたい何かに踊らされたい

心を締め付けられそうな夜に溺れていたいだけ

- from City Hunter Sound Collection.

2009/06/23

git(2) - from sourceforge.jp SVN

http://iteman.jp/blog/2009/02/subversiongit-stagehand-testru.html
http://ml.ethna.jp/pipermail/users/2009-June/001138.html

Ethna のソースコードリポジトリを subversion から git に移行した。subversion から git への移行は git-svn を使うのが定番のようになっているが、以下のコマンドを使っても git-svn は指定されたディレクトリ以下のディレクトリ名をブランチにするだけで、tag をうまく扱ってくれなかった

$ git svn clone -T trunk -t tags -b branches svn+ssh://...

このコマンドの実行結果は以下のようになる。タグもブランチとして扱われている

$ git branch -r
* master
  ETHNA_2_1_1
  ETHNA_2_3
  ETHNA_DBLAYER_UNITE_BRANCH
  ....
  tags/ETHNA_2_1_0
  tags/ETHNA_2_3_0

----

これでは話にならないので、svn2git を使った。はじめ gem でインストールしても svn2git が command not found になったので焦ったが、/var/lib/gems/1.8/bin 以下に見つかったので、それを直接実行したところうまくいった

$ gem sources -a http://gems.github.com
$ gem install nirvdrum-svn2git
$ /var/lib/gems/1.8/bin/svn2git http://svn.sourceforge.jp/svnroot/ethna/ethna/ \
--verbose --trunk trunk --branches branches --tags tags

実行中の出力は git-svn と変化ないように見えるが、結果の違いは歴然としている

$ cd ethna
$ git tag -l
 ETHNA_2_1_0
 ETHNA_2_3_0
 ETHNA_2_3_2
  ....
$ git branch -r
 ETHNA_2_1_1
 ETHNA_2_3
 ETHNA_LEGACY_EUCJP_BRANCH

ここまで出来れば、remote を登録してすべてを移行するだけである。

$ git remote add origin USERNAME@git.sourceforge.jp:/gitroot/ethna/ethna.git
$ git push --all
$ git push --tags

----

なお、最初のリンクにも示しているが、本エントリはitemanさんが書いたものをほぼそのまま実行しただけである。元エントリを書いたitemanさんには深く感謝申し上げる次第である。

2009/06/22

misc_register - Linux kernel API

http://d.hatena.ne.jp/TRANSii/20080911/p1

major番号、minor番号をいちいちregister, unregisterしてデバイスファイルをudev経由で作りたくねーよ的な要求は必ずあると思うのだが、さりとて上記のような正規かどうかもわからないAPIを使うのも躊躇われるので悩ましいところである。

----

とはいえ、Linux kernel プログラミングで３分クッキングは素晴らしい試みだと思う。

やってみて思うのは、C言語がたとえわかっていても前提知識が多すぎる。内部のAPIやディレクトリ構造がバージョンごとに当たり前のように変わる。まあ、後者は開発者たちが一致して決めたポリシーだし、今のプロジェクトのまわし方だと十二分に理に叶っていることなので文句はないのだけれども。

前者の前提知識の量にしても、ひるがえってWebを見たところでそれなりにあるわけだから、まぁ、、というところだろうか。

Ethna 2.5.0 preview5 announced

http://ml.ethna.jp/pipermail/users/2009-June/001137.html

今回のリリースの8割以上は俺以外のコミッタのアイディアが詰まったものである。よってリリース作業も彼らの一人にお願いした。よって、このリリースは彼らのものである。リリースオーナーとなった id:maru_cc は本当にお疲れさまでした。

俺はただ、コードを書いたりドキュメントを書いたりしただけ、つまり、手を動かしただけである。

----

汎用ビューによって、HTML以外の出力に関して柔軟な変更ができる余地が開かれた。また、プラグインに関する変更はこれからを見据えたものであり、より使いやすく、配布しやすいものを目指すに当たっての礎となろう。

俺に残された仕事は、AppObject まわりの改善のみだ。これが終われば、晴れて 2.5.0 final を出すことができる。他のメンテナもそれぞれのモチベーションに合わせて改善を加えてくれるだろう。これが成し遂げられれば、Ethnaのメインメンテナからは脚を洗うつもりだ。

2009/06/21

mouse computer: luvbook S

http://www.mouse-jp.co.jp/m-book/luvbooks/

相方の家での作業用ノートとして今までVAIO Type Tを使っていたが、熱暴走でいかんともし難くなったので代替機を考えていたところ、上記をIRCに貼った人がいた。こりゃ安いなあと思って購入してみた。

マシンの重さが1.86kg, バッテリも2時間弱しかもたないのでそもそもガンガン持ち運ぶものではない。だがCeleronながらデュアルコア、そしてメモリも無料で4GBにしてくれたので目的には十分に合うものだ。メモリーカードも数種類に対応していて、なぜか前面にWebカメラもついている。筐体も重いだけあって丈夫にできていて、電源管理をPresentationにすればLinuxでも快適に使える、、はずであった。ちなみにこれで3年保証をつけて7万円である。

----

だが、キーボードのキー配置だけは頂けなかった。「|」を打つキーが左下のZキーの左横についている。そしてバックスラッシュ「\」を打つキーが右のエンターキーの「真下」についていたのだ。それにスペースバーの横にAltキーがなくて非常に使い辛い。どう考えてもプログラマーには向かないというか、有り得ないキー配置である。キーボードに拘るプログラマ、かつkeymapが自由に変更できない人は、絶対にこのマシンを購入しては「いけない」。

Linuxは幸いkeymapを自由に変更できるので、上記の3つのキーの配置は思いっきり変更させて頂いた。こいつらが気持ちよく打てないことには作業効率に影響するからである。

----

結論を言うと、多分プログラマー向きのモデルではなくて、家に置いてホビー的に使う人達向けのものだろうと思う。この手のモノの常として、現物を見られないということがある。当然購入にあたってはそうしたリスクを十二分に考慮に入れる必要がある。

まあ、一応俺の手には収まるものであると言えよう。しばらくお世話になります。

2009/06/16

Ethna 2.5.0 preview4, 2.3.7 announced

http://ml.ethna.jp/pipermail/users/2009-June/001130.html

昨夜メールをひょっと見るとセキュリティバグの報告があがっていて正直寝耳に水であった。ちょっくらテストしてみると見事に開発版、安定版ともに再現してしまった。PHPの配列のキーが入力になっていたことに皆気付いてなかったということで、完全にヤラレタとしかいいようがない。

セキュリティリリースは本来秘密裏に修正し、リリースするまでその内容はバージョン管理システムにさえ一切公にしないというのが通常だろうが、そのための窓口が Ethnaプロジェクトにはなかった。結果として full-disclosure の形になってしまい、リリースを急ぐことになった。リリース作業は意外に面倒な部分が多いのだが、今回は普段の4倍疲れた。俺自分に乙。

----

とはいえ、今週末には開発版の次のリリースが控えている。もうひと踏ん張りである。

2009/06/13

the latest code ...

<mumumu_n> the lastest code cannot disable logging. is it already fixed?
<Sho_> mumumu_n: if it's current SVN code how could it be already fixed?

おまいのコードが仮に最新で、それがバグってるんだったらfixされてるバージョンなんてあるわけないぢゃん、と言われて涙目。しかもバグレポートをfileしてやると思ってsvn upしたら早くもfixされていてさらに涙目（藁

#「the latest code」って言ってしまったのがまずったのよ(´ー｀; )

[memo] bit shift operator

C言語のビットシフト演算子は、左オペレータの幅以上の値を右オペレータに指定した場合、その動作は未定義である。これは規格で定義された動作である。以下、JIS X 3010 2003 (ISO/IEC 9899) P48 より引用する。


6.5.7 ビット単位のシフト演算子
   シフト式：
       加減式
           シフト式 << 加減式
           シフト式 >> 加減式
制約　各オペランドは，整数型をもたなければならない。
意味規則　整数拡張を各オペランドに適用する。結果の型は，左オペランドを拡張した後の
型とする。右オペランドの値が負であるか，又は拡張した左オペランドの幅以上の場合，
その動作は，未定義とする。

----

このことから、ビットパターンを出力する以下のコードは c の値によって動作するか否かが決まる。型によってオペレーターの幅は異なるため、頭の隅にいれておく必要があろう。間違っても俺のように何も考えずに100ビットとかシフトさせようとしないでください(´ー｀; )


#include <stdio.h>

int main(int argc, char *argv[])
{
   unsigned long long a = 65535; // long long は一般に64bitの幅を持つ
   int c;
   for (c = 63; c >= 0;c--) {    // c を 64にすると途端に動作しなくなる
       printf("%d", (int)((a >> c) & 1));
   }
   printf("\n");
   return 0;
}

2009/06/12

23-2

http://www.daily.co.jp/baseball/2009/06/12/0002011246.shtml

プロ野球タイ記録となる１０打数連続安打とプロ野球ワースト記録となる１イニング１５失点。ブラウン監督自ら、この試合はプロ野球ではなく「ラグビー」のようであったとコメントしている。草野球と評さなかっただけ偉いと思う（違

個人的な唯一の救いは、この試合を（テレビやラジオ等を通じて）ライブで視聴していなかったことだろう。仮にしていたら、、多分ラジオかテレビが壊れていただろうから(´ー｀; )

登録: 投稿 (Atom)