2011-07-24

分散型バージョン管理システム勉強会＠京都を開催しました

勉強会

始めは通常のセッション形式で開催しようと思いましたが、告知後にワークショップ形式に変更して開催しました。

当日はgitとmercurialのワークショップの予定でしたが、急遽bazaarのワークショップも追加で行いました。

最初はgitのワークショップからで、講師は [twitter:@__papix__] さんです。
対象はgitを全く使ったことのない人がgit初心者になるというのが目標ということでした。随所にネタが入った資料で非常に面白かったです。ただ、写真を取るのを忘れてしまったのが失敗です。

次は当日急遽行うことになったbazaarのワークショップで、講師は [twitter:@aroma_black] さんです。

本当にいきなりだったので、bazaarのチュートリアルを使ったワークショップとなりました。 bazaarのチュートリアルは日本語訳もあり、よく出来ている感じでした。

スイーツタイムが無いと女性エンジニアが来てくれないらしいので、bazaarのワークショップが終わった後の休憩でスイーツタイムを挟みました。ちなみに今回は女性の参加者はいませんでした。

最後はmercurialのワークショップです。講師は私 [twitter:@naoina] が担当しました。

が！進行していく内に解説する順序がおかしかったり、名前付きブランチの説明が無かったりと資料が色々と不十分だと感じました。なんとかその場で説明をつぎ足したりでしのぎました。

また、LTの発表者は [twitter:@ramusara] さんと [twitter:@_likr] さんの2名でした。

時間が余ってしまったので私もLTをしました。それでもまだ余ってしまっていたので、kyoto.py の告知、Sphinx の紹介、rst2hatena の紹介などをしました。

懇親会への参加はワークショップ参加人数の半分以下でした。思ったより少なく意外でした。

また、ワークショップ終了後に色々と話した結果、次のPython関連のイベントは2011/9/24に開催しようかという運びになりました。まだ確定ではないのですが、その日に何かできるように調整していきたいと思います。

最後に、これを期にみなさん分散バージョン管理を活用してもらえるようになれば嬉しいです。

2011-06-26

「ささやかなVim勉強会」に参加しました

Vim 勉強会

http://atnd.org/events/16581

Vimの勉強会への参加は以前の Yokohama.vim #0 以来です。
主催者は @lnial さんで、会場は立命館大学びわこ・くさつキャンパスでした。USTREAMは会場の回線事情によりできなかったようです。
せっかくなので今回はLTをしてきました。

全体的に初心者向けの勉強会でした。ですが、自分自身全然使っていない機能やキーバインドが出てきたりして勉強になりました。

途中ペアを組んで、 Vim戦闘力*1 が高い人が逆に低い人に教えたり、近い人同士では学び合うという形で進みました。最初は「二人組つくってー」というぼっちフラグビンビンの言葉が主催の @lnial さんから発せられましたが、ぼっちが出なくて本当によかったです。

また、私はVim戦闘力が400にも関わらず何故か一番戦闘力が高かったです。どうしてこうなった。
懇親会ではVimやキーボード、Lang-8の話などがありました。その中でなんとArch Linuxを使っている方がいてかなりテンションが上がりました。でも、主催者が懇親会の半分ぐらいでつぶれてたのは内緒。

まぁ、次回の開催もあるでしょうから(適当)、ぜひまた参加したいです。

*1:.vimrcの行数がそのまま戦闘力になる。私は空行、コメント行を除いてカウントしています。

2011-06-12

Python京都勉強会開催しました

Python 勉強会

http://atnd.org/events/15598

思い立ったが吉日で、関西でPythonのイベントが少ないなら自分でやっちゃいなYO！という電波を受信したので開催に至りました。
会場は丹波口駅から徒歩5分の京都リサーチパークさんの会議室をお借りしました。

メインスライド

LTの冒頭は見たことがある方もいるかも知れませんが、決してパクリではありません。オマージュです。

以下勉強会の様子

2011-05-18

GPTZFSBoot/RAIDZ2 on VirtualBox

FreeBSD

環境:

FreeBSD 8.2-RELEASE amd64
VirtualBox 4.0.6

VirtualBox上で http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ2 に書いてある方法で構築してブートすると

ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS
ZFS: unexpected object set type lld
ZFS: unexpected object set type lld

FreeBSD/i386 boot
Default: z:/boot/kernel/kernel
boot:

というエラーが出てブートできない。調べたところVirtualBoxのBIOSがディスクを1つしかレポートしないためRAIDZ/RAIDZ2ではブートしないらしい。
で、解決方法。http://lists.freebsd.org/pipermail/freebsd-emulation/2010-September/007991.html で示されてるパッチを当てたブートコードを使う。

手順としては、http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ2 の手順のうち "chroot /zroot" したあとで

Fixit# cd /usr/src
Fixit# fetch http://people.freebsd.org/~pjd/patches/bios_numdrives.patch
Fixit# patch -p0 < bios_numdrives.patch
Fixit# cd sys/boot
Fixit# make obj && make depend && make && make install

ここまでできたら新しいブートコードを書き込む。

Fixit# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad0

上記ブートコードの書き込みをRAIDZ/RAIDZ2で使うディスク全てに行い、あとはwikiに書いてある残りの手順を行えばVirtualBox上でRAIDZ/RAIDZ2のZFSBootができます。

2011-05-09

PyBG関西勉強会#2に参加しました

Python 勉強会

http://atnd.org/events/15188

関西でのPython関連の勉強会は少ないので、Python好きな自分としては逃せないだろうと思い参加してきました。
実は当初はこの勉強会の日まで帰省している予定でしたが、IT勉強会カレンダーで見つけて帰る日程を1日早めたりしたのは内緒。

最初の座談会という名の質問タイムでは、主催の@tkroroさんが風呂蓋のついたiPad2でスライドを表示してました。この時間で分かったことは自分以外Python3を使ってる人がいないということでした。本当にありがとうございました。

勉強会の内容としては、スライドで発表する通常の勉強会形式とは違って各個人が課題を決めて自由にやるという内容でした。自分は終始Jythonを検証してました。まぁ、正直Jythonは起動が遅すぎて毎回立ち上げるようなものには使えないという結論に相成りました。他の方は、自作のDjangoアプリを1.3対応にしていたり、みんPyを読んで文字通り勉強していたり、GAEでアプリをつくったりしていました。

また、始めの質問の「勉強会のあとは必ず懇親会に参加する」に全員が手を挙げなかったにも関わらず、全員が勉強会終了後の懇親会に参加してました。みんなツンデレなんですね、分かります。

最後に、どうも定期開催をしようと考えておられるようなので、京都のいちPythonistaとして期待してます。

2011-04-29

Buffalo WLI-UC-GNをLinuxで使う

Linux Memo

WLI-UC-GNってのはBuffaloのUSB無線LANアダプタです。

BUFFALO Air Station NFINITI 11n/g/b USB用無線子機 WLI-UC-GN

出版社/メーカー: バッファロー
メディア: Personal Computers
購入: 40人クリック: 503回
この商品を含むブログ (44件) を見る

これがどうもうまくLinuxで動かなかったのですが、なんとか安定動作にこぎつけたので備忘録。

環境:

Arch Linux x86_64
Kernel 2.6.38.4

不具合:

APは検索できている(無線LANアダプタ本体は動いている)のにAPに繋げない
WPA2などの認証が通らない

調べて分かったこと:

WLI-UC-GNはどうやらRalink RT3070っていうチップセットを使ってるらしい
だけどLinuxではRT2870で認識されている
ドライバはrt2870staというカーネルモジュール
rt2800usb、rt2800lib、rt2x00usbをmodprobe.confのblacklistに入れればいいという情報があったが、改善せず

解決方法:

/etc/modprobe.d/modprobe.confにblacklist追加

/etc/modprobe.d/modprobe.conf:

blacklist rt2800usb
blacklist rt2800lib
blacklist rt2x00usb
blacklist rt2x00usb

起動時の読み込みモジュールを追加

/etc/rc.conf:

# Arch Linuxでの設定なので、使っているディストリでの設定方法に読み替える
# 32bit環境では aes-i686
MODULES=(aes-x86_64 mac80211 ......)

既知の問題:

前述の方法でも起動直後やハイバーネートからの復帰直後は認証付き(WPA2など)のAPに繋げないことがある

既知の問題の解決方法:

一旦インターフェースを無効化した後に接続

% sudo ifconfig wlan0 down

私はwicdをAP自動接続で使っているため、最初繋げない→インターフェース無効化→インターフェース有効化→繋がるというプロセスが自動で走り、繋がるまでタイムラグがある。

ちなみに、Ralink公式から出ているrt3370ドライバ(rt3070ドライバを含んでいる)は地雷だった。APに繋ごうとするとよくわからんエラーがdmesgに無限ループで出てた。ifconfig ra0とかも返ってこず、sudo rebootもできなくなった。

あと、有線LANを繋いだまま使うと繋げなかったりするかもしないかも。

2011-03-29

1ヶ月後でも読めるソースコードの書き方

Program

あなたはコードを書くときに何を重視して書きますか？実行時の速度だったり、拡張のしやすさといったところですか？
今回は読みやすいコード(=readable code)についてです。
私が考える読みやすいコードとは以下のようなコードです。

関数(メソッド)名が適切に付いている
コーディングスタイルが一貫している
コメントが少ない

では、ひとつずつ例を挙げていきます。

関数(メソッド)名が適切に付いている

check_member()は特定のユーザーがメンバーかどうか判定する関数とします。

if (check_member(user)) {
    ......
}

上記のcheck_member()はif文の中で使用していることからbooleanが返ってくるだろうと予想できますが・・・駄目っ！この名前では、どのような時にtrueが返ってくるのかは関数の中身を見ないと分かりません。このように何かを判定するものには以下のようにisやhasを接頭辞として付けるべきです。

if (is_member(user)) {
    ......
}

このような名前を付ければ、中身を見なくてもuserがmemberである場合にtrueが返ってくると分かります。コードを読む目的がこのチェック関数ではない場合、中身を確認しなくてもよくなった分だけ次々と読み進められます。

コーディングスタイルが一貫している

既存のコードを修正または追加する場合などに気をつけて欲しいことです。
対象のコードがどんなに気に食わないカッコの書き方をしていようが、インデントがタブ(またはスペース)じゃなかろうが、命名にアンダースコアを使いたくなかろうが、既に書かれてあるコードにスタイルを合わせてください。あなたがどんなに優れたコーディングスタイルで書いたところで、全体で一貫しているコーディングスタイルを崩すことはコードを読みにくくするだけです。
どのぐらい読みにくいかというと、ほのぼの物語だと思ったら3話で突然魔法少女の頭が食べられたり全く救いの無い設定だったアニメの展開ぐらい読みにくいです。

for (int i = 0; i < n; i++) {
    for(int j=0;j<m;j++)
    {
        ......
    }
}

int hoge(int x, int y) {
    ......
}

int
hoge(int x, int y)
{
    ......
}

上記の例だけではそれほど読みにくく感じないかもしれないですが、読むコードの量が増えれば増えるほど読みにくくなります。
色々なスタイルが混じったコードは特定の意味の文や式の記述パターンが増えるので、読む上での判定パターンも増えます。結果として読むのが遅く(=読みにくく)なります。if-elseをたくさん連ねるのは遅いのと同じです。

コメントが少ない

これには賛否両論あるかと思います。一概には言えませんが、私はコメントが少ないほうが読みやすいと思います。例えば

if (check_member(user)) { // userがmemberならhoge()を実行
    hoge();
}

int has_car = true; // 車を持っていればtrue

というコードの場合、check_member()を前述のis_member()にすればコードがそのまま意味を表すようになるので、最初のコメントは要らなくなります。
次のコメントも要りません。変数の名前を適切に付けているため、コードそのものがコメントの役割も果たしているためです。コードを見れば(≠読む)分かることをコメントに書くのは冗長で無駄無駄無駄無駄です。
また

int flag;
......
// 1: mode A
// 2: mode B
// 3: secret mode
flag = 1;

のようなコメントであれば、まず1、2、3の定数に名前を付ければコメントなしで意味が分かるようになります。

const int MODE_A = 1;
const int MODE_B = 2;
const int SECRET_MODE = 3;

flag = MODE_A;

コメントがなくても可読性は落ちていません。
名前を適切に付ければコメントはかなり減らせると思います。コメントというものは得てしてほとんど(あるいはまったく)メンテされません。メンテされないコメントほどアテにならないものはありません。いつでも動いているコードの方が正しいので「コメントがアテにならないならコードをコメントにすればいいじゃない」というわけです。
逆にコメントを付けるべきところは、カリカリにチューニングしていて一見してなにをしているのか分からないコードや、理由があってわざと効率の悪い方法や無駄なことをしているところなどです。後者などは後々リファクタリングの名のもとに削除されかねませんので、コメントを付ける意味があります。

読みやすいコードまとめ

名前重要。名前重要。大事なことなので2回書きました。一貫したコーディングスタイルを前提に、名前を適切に付けてコード自体をコメントにするように心がける。それでも分かりにくいところはコメントを付ける。
それではよいコードリーディングライフを！