しゃべれる理系

Simple TimeKeeper for Happy New Year

noreply@blogger.com (yasulab) — Mon, 02 Jan 2012 06:18:00 +0000

最近、某沖縄でよく使われるという Simple TimeKeeper ですが、先日の大晦日、下北沢OSSCafe の「Just Do(土) It!」というイベントで、HappyNewYear な機能を実装しました。で、今日は、その後日談な話をしようかと。

この新機能では、URLの末尾に次の年を入力すると、上の写真のように、コントロールパネルが消えて、謎のカウントダウンが始まります。ナニを隠そう、このカウントダウンが０になると、"HappyNewYear #{new_year}!!" って感じになるわけですね。

例えば、今年の場合は、今年の12月31日に http://simpletimekeeper.com/#2013 にアクセスすれば、カウントダウンが始まります。ただ、12月31日以外の日に上述のURLにアクセスしてしまうと、Set Time by URL という、URLで時間をセットする機能が代わりに動きます。すなわち、2013秒がセットされてしまいます。ご注意を。

「気付いたらうっかり年を越えてしまった...」なんてことにならないように、今年の年末はこの機能を使って、迫り来る HappyNewYear な雰囲気を存分に味わいましょう！

ちなみにこの Simple TimeKeeper、次のような感じで、iPadでも何でも、http://simpletimekeeper.com/ にさえアクセス出来れば、うまく表示できます。

iPadでも,

大型 Screen でも,

テレビでも,

MacBook でも,

何でも動きます！

ただ、放置していると時差が発生してしまったりも... orz

更新すれば直りますが、まぁデバッグするのは今年の大晦日ですかね。

最後に、使用例のご紹介。この Simple TimeKeeper の HappyNewYear 機能を使って、下北沢OSSCafe な方々と、こんな感じで盛り上がることが出来ました。今年の年末は是非使ってみて下さい。

全然ギリギリセーフではない件 orz orz orz。

録画に夢中で完全に機を逸しました。

今年の年末...ってのは大分遠い話ですが、本来の機能は勉強会などでのタイムキーピングなので、そちらの機能も是非是非。

以上、後日談な話でした。

P.S.

ソースコード（もとい、う◯コード）は GitHub に上がっているので、興味あればコチラも是非。特に、「UIを改善してもいいよー」という方がいれば、是非僕の方までお声かけ下さい。

GitHub - SimpleTimeKeeper
github.com/yasulab/simpletimekeeper

Fluxflex＋Dozens＋ムームードメインで、独自ドメインなWordPress製HPをサクッと作ってみた

noreply@blogger.com (yasulab) — Sat, 24 Dec 2011 11:09:00 +0000

突然ですが、沖縄の（変態）エンジニアが集う eXtreme HAGO というLT大会の公式HPを作りました！

eXtreme HAGO
http://xhago.net/

せっかくHP作ったので、沖縄の~~（禁則事項です）~~っぷりを、このブログで紹介したい...気持ちは山々なんですが、そういう紹介は公式HPに任せておいて、この記事では、そのサイトを作るまでにやったことについて話します。具体的には、WordPress + Fluxflex + Dozens + ムームードメインを使って、独自ドメインのWordPress製HPを作る過程について、サクッとまとめます。

注１：以下の"xhago" という文字列は、自分のプロジェクト名に適宜変換して下さい。
注２：各サービスの登録手続きなどは省力します。全部説明すると長いので。

0. 前提
- fluxflex / dozens / ムームードメインに Sign Upしてること（当然）
- fluxflexの Casual プラン以上の契約をしていること。（じゃないと独自ドメインが使えない）
- 1,000円ぐらい（ドメイン取得代）を持っていること。~~（世の中お金です）~~

1. fluxflex でプロジェクト（"xhago"）を作成します。

2. fluxflex の App Garage から、WordPress(jp) をポチって、"xhago"をターゲットにする。

3. ムームードメインから、独自ドメイン（例："xhago.net"）を購入。

＊xhago.net は既に僕が購入したので、登録出来ません。

4. 言われた通りに登録手続きを行い、「ドメイン取得」まで進む。

5. 「ドメイン取得」時の、ネームサーバを設定する画面で、次のように設定。他は適当に。

（上記は、世界に４つ点在するという伝説の Dozens ネームサーバです。~~四天王？~~）

6. fluxflex から"xhago" -> Admin-> Domain にアクセスし、取得した独自ドメイン名を入力。

7. "Update" をクリックして、出て来た CNAME をメモります。

* "Verify Now"は、ここでは一旦無視します。

8. Dozens にログインして、コントロールパネルから独自ドメインを入力。

9. "xhago.net" -> "Add a record"に進み、次のように設定。"CONTENT"はさっきメモったヤツに置換して下さい。

10. fluxflex に戻り、さっき無視した"Verify Now"をクリックして、"Verified"となったら成功。

追記：TTLが7,200秒になっているため、場合によっては"failed"になることもあります。その場合は、１時間ほどおいてから再度お試し下さい。それでも"failed"になる場合は、もう一度設定した項目をご確認下さい。

11.最後に、取得した独自ドメインのURL（"www.xhago.net"）アクセスし、WordPressの画面が出て来たらOKです。

とまぁ、こんな感じでサクッと独自ドメインのWordPress製HPが作れます。世の中便利になりましたねー。
あとは、WordPressを使って、煮るなり焼くなり好きにして頂ければよいかと。

以上、ご参考になれば幸い。

Xv6 Commentary の Scheduler の章をオレオレ翻訳してみた

noreply@blogger.com (yasulab) — Fri, 23 Dec 2011 03:45:00 +0000

最近よくお世話になっている下北沢OSSCafeで、なにやらSmooth CoffeeScriptの翻訳プロジェクトという、とても面白そうなプロジェクトが走っているみたいです。「すげぇ！僕も参加してぇ！」というわけで、その勢いに追従して（？）、１年前ぐらいに僕がオレオレ翻訳した xv6 commentary の Scheduler の章を公開します。ちなみにこの xv6 とは、教育用のOSで、MIT の強者どもが、OSの授業のためだけに作ったという伝説の一品です。ソースコードは約1万行ありますが、コメントやらなんやらが色々挿入されているので、実際のところは1万行未満です（な、なんだってーΩΩΩ）。

ただ、言い訳ですが、元々は誰かに見せるつもりではなかったので、翻訳は結構適当です。また、xv6 も毎年アップデートされてるみたいなので、可能であれば原本を見た方が良いと思います。とまぁ、そんな状態ではありますが、それでも参考になれば幸いです。ライセンスはMITライセンスだそうです。

Xv6 - Scheduler オレオレ翻訳, Google Docs
GitHub版 (勢いで repos も作ってみたでござる.）

上記のリンクはいずれも"Allow anyone to edit"な状態なので、一応、現状の Snapshot を以下にコピペしておきます。ご参考（になるのか？）まで。

追記：
さっきちょっと確認してみたところ、さっそく章構成やらなんやらが変わってました。５章ではなく４章になってて、タイトルも"Scheduling"になってます。しかも、僕が読んでたときよりもっと図解が多くなってる！ということで、やっぱし英語読める人とかは原本を読んで下さいね。

以下、オレオレ翻訳
=======================

Chapter 5

[Scheduling]

OSは、実際に持っているプロセッサの数よりも多くのプロセスを走らせているかのように見える。プロセス間でプロセッサを、タイムシェアするためには、いくつかの機構が必要である。一般的なアプローチは各プロセスに仮想プロセッサを割当て、OSが仮想プロセッサを多重化させて１つの物理プロセッサに割り当てることである。

Xv6は、複数のプロセスを並列に実行するための機構を持っている。もし二つの異なったプロセスが１つの物理CPUを競合しているとき、Xv6はその２つのプロセスを多重化する。そして、実行プロセスと実行待ちプロセスを、１秒間に複数回スイッチさせている。Xv6は多重化を用いて、各プロセスがそれぞれ１つのCPUを独占させているかのように振る舞っている。これは、Xv6がメモリアロケーターと　HWセグメンテーションを用いて各プロセスにメモリを割り当てたときと似ている。

多重化を実装するためには、いくつかの課題を乗り越えなくては成らない。１つ目は、どうやってあるプロセスと、他のプロセスをスイッチさせるか、である。Xv6はコンテキストスイッチの標準的なメカニズムを使用している。そのメカニズムはシンプルであるが、OSの中では最も難解のコードである。２つ目は、どうやって透過的にコンテキストスイッチを行うか、である。Xv6はタイマ割り込みを用いてコンテキストスイッチを行うという、標準的なテクニックを用いている。３つ目は、プロセスが並列に走るかもしれない、ということである。これによって発生する競合には、ロック機構を用いて対処している。４つ目は、プロセスがその処理を終えたとき、そのプロセスは他のプロセスと共に多重化することができない、ということである。プロセスを消去することは容易ではない。プロセスは自分自身を消去できない。なぜなら、そのプロセスを消去するためには、そのプロセスを実行しなければならないからである。Xv6はこういった問題に対して、出来るだけ直接的な方法を用いて解決しようと試みている。しかしながら、結果的に出来上がったコードは、ややトリッキーである。

一度多重化されたプロセスが実行されると、Xv6はその実行プロセスと他のプロセスとを協調させなくてはならない。しばしば、あるプロセスは、他のプロセスの何らかのアクションの実行が終わるのを待つことがある。その処理が終わったかどうかを繰り返しチェックするために、CPUを無駄に浪費することは無駄である。従って、Xv6はプロセスにsleepという機構を持たせて、他プロセスのある処理が終わるまで眠らせることが出来る。また、他のプロセスは、眠っているプロセスを起こすことが出来る。ただし、プロセスは並列に実行されるため、眠っているプロセスを起こし忘れる危険性がある。そういった問題と解決策の例として
、本チャプターでは、pipeの実装についても触れている。

[Code: Scheduler]
２章では、ユーザスペースにおけるスケジューラについて俯瞰した。本章では、スケジューラのもっと深い部分について触れてみよう。各プロセスは、ブート時にmpmain()を走らせている。mpmain()の最後部では、scheduler()を呼び出している(1263)。

scheduler()は単純なループを実行している(1908)。つまり、(1)次に走らせるプロセスを探し、(2)そのプロセスが止まるまで実行し続ける、ことである。このループの最初部では、scheduler()はsti()を用いて明示的に割り込みを許可している(1914)。これにより、もしHW割込みが処理されるの待っているような場合でも、スケジューラのCPUは、HW割込みを先に処理出来るようになる。その後、スケジューラはプロセステーブルの中から実行可能なプロセスを探す。実行可能なプロセスとは、"p->state == RUNNABLE"となるプロセスのことである。スケジューラが実行可能なプロセスを発見すると、現在のプロセスを変数cpに格納する。その後、スケジューラはusegment()を用いてユーザセグメントを更新し、そのプロセスの状態をRUNNINGにセットする。最後に、swtch()を呼ぶことで、そのプロセスの実行を開始する(1922-1928)。

[Code: Context Switching]
Xv6の各プロセスはkernel stackとregister setを持っている(2章参照)。各CPUはkernel stackを持っていて、スケジューラを走らせるときにそのkernel stackを用いる。swtch()はスケジューラのコンテキスト情報(stack + register)を保存する。そして、現在のプロセスのコンテキスト情報と、次に実行するプロセスのコンテキスト情報とをスイッチする。プロセスがCPUを手放すとき、プロセスはswtch()を呼び出して自身のコンテキスト情報を保存し、returnを用いてスケジューラにコンテキスト情報を返す。各コンテキスト情報はstruct context *よって宣言されている。つまり、関係のある情報の構造体に対するポインタである。swtch()は２つの引数を取る。struct context **oldと、struct context *newである。swtch()は現在のコンテキスト情報を保存し、ポインタをoldコンテキストに格納する。そして、newによって与えられた新たなコンテキスト情報を復元する。

スケジューラのswtch()の振る舞いを追う代わりに、まずユーザプロセスがどのように復元されるかを追ってみよう。私たちは、３章で割り込み処理の末端でtrap()がyield()を呼び出す様子は理解した。yield()は、swtch()を用いて現在のコンテキスト情報をcp->contextに格納するsched関数を呼び出す。そして、スケジューラのコンテキストを情報を、以前保存されたc->contextの状態にスイッチさせる(1967)。

swtch()は、eaxレジスタとedxレジスタを読み込むことで開始する(2202, 2209-2210)。swtch()は、swtch()がスタックポインタを変更する前に、この操作を行わなければ成らない。そして、espレジスタを通して引数にアクセス出来ないようにする。そして、swtch()はレジスタの状態をプッシュし、現在のスタック上にコンテクスト情報の構造体を生成する。呼び出し元が保存するレジスタは、保存される必要がある。つまり、x86の慣習により、ebp,ebx,esi,ebp, そして, espレジスタを保存する必要がある。swtch()は最初の４つのレジスタを明示的にプッシュする(2213-2216)。struct context*は*oldに書かれているため(2219)、swtch()は暗黙的にespレジスタを保存する。また、さらにもう１つ重要なレジスタが存在する。それは、eipというプログラムカウンタである。eipはswtch()を呼び出した命令の場所が保存されている。そして、その命令の場所は、スタックに置ける、ebpレジスタの丁度真上にある。古いコンテキスト情報を保存したら、swtch()は新しいコンテキスト情報の復元の準備を行う。swtch()は、新しいコンテキスト情報を指すポインタを、スタックポインタに移動させる(2220)。新しいスタックは、swtch()が先ほど使っていた古いスタックと同じフォームを持っている。新しいスタックは、swtch()を呼び出す前までは、古いスタックであった。つまり、swtch()は、新しいコンテキスト情報を復元するために、シーケンスを逆転させることが出来る。swtch()はedi,esi,ebx,ebpレジスタの情報をポップし、そして、返り値として返す(2223-2227)。swtch()はスタックポインタを変更し終わったため、各レジスタの値は復元され、戻されたアドレスには新しいコンテキスト情報がある。

私たちの用いる例では、sched()は、c->contextとスイッチさせるためにswtch関数を呼び出した。c->contextとは、各CPUが持つスケジューラのコンテキスト情報である。その新しいコンテキスト情報は、scheduler()のswtch関数の呼び出しによって、保存される(1928)。私たちが追っているswtch関数がreturnされるとき、swtch関数は、sched()ではなく、scheduler関数にreturnされる。そして、スタックポインタは、initproc()のkernel stackではなく、スケジューラのスタックを指すことになる。

[Code: Scheduling]
最後のセクションとして、swtch()の低レベルの詳細を見てみよう。具体的には、swtch()の、プロセスからスケジューラまでの振る舞いと、スケジューラからプロセスに戻ってくるまでの振る舞いを見てみよう。Xv6の慣習として、CPUを手放したいプロセスは、必ずプロセステーブルのptable.lockに鍵をかけなくてはならない。また、取得したロックは必ず解放されなければならない。次に、自分自身の状態(cp->state)を必ず更新し、最後にsched関数を呼び出さなくてはならない。yield関数は、この慣習に従っている(1973)。つまり、sleep()とexit()を実行している。これらの関数は後で見ることにしよう。sched()は自分たちの状況と、その予想される結果に対して、二重のチェックを行っている。というのも、ロックが取得されてからは、CPUは、割り込み不許可の状態で動作しているからである。最後に、sched関数はswtch()を呼び出し、現在のコンテキスト情報をcp->contextに格納している。そして、スケジューラのコンテキスト情報をc->contextにスイッチさせている。swtch()は、スケジューラのスタック情報を返す。これは、スケジューラのswtch関数がスケジューラのスタック情報を返す状況に似ている。スケジューラはforループを繰り返し行い、実行可能状態のプロセスを探す。そして、スイッチを行う。スケジューラはこれらのサイクルを繰り返す。

私たちはXv6がswtch関数の呼び出しを跨いでptable.lockが取得されるのを見てきた。つまり、swtch関数を呼び出す関数は必ずロックを取得していなければならない。そして、ロックのコントロールはスイッチ後のコードを通る。この関数は、一般的なロック機構とは異なる。ロック機構の典型的な慣習は、ロックを取得したスレッドが、そのロックの解放する責任を持つことである。これにより、正しく動作していることを簡単に確認することが出来る。というのも、コンテキストスイッチは、典型的な慣習を破る必要がある。なぜなら、各プロセスの構造体において、ptable.lockは、stateとcontextのフィールドを保護する必要があるからである。ロック機構を用いない場合、コンテキストスイッチ中に、プロセスがyield関数を呼び出す可能性がある。つまり、プロセスの状態をRUNNABLEにして、CPUを手放すためのswtch()を呼び出す前に、異なるCPUがswtch関数を用いてそのプロセスを実行する危険性がある。他のCPUがswtch関数を呼び出すことで、古いコンテキスト情報を使う可能性がある。また、ロック機構を用いない状態では、２つのCPUが同じスタックを同時に使う危険性もある。そして、いずれの状態も正しくない。

この問題を回避するために、Xv6は、プロセッサを解放するスレッドがptable.lockを取得する、という慣習に従っている。そして、そのスレッドが、プロセッサが次に解放するロックを取得する。この慣習を簡潔にするため、スレッドは、sched関数の中で常にプロセッサを手放すようにしてる。これにより、もしあるスレッドが、Xv6がスレッド間をスイッチする部分の行をプリントアウトしている場合、次の簡単なパターンを観測することが出来るだろう(1928,1967,1928,1967などなど)。様式化されたスレッド間スイッチングが起こるプロシージャは、ときどき、対応する２つのco-routinesを参照している。例えば、sched()とscheduler()は、それぞれが互いに参照し合うco-routinesである。

新しいプロセスにスイッチするためのスケジューラのswtch()が、sched関数の中で終わらないケースが存在する。私たちは２章でそのケースを理解した。つまり、新しいプロセスが最初にスケジュールされたとき、そのプロセスはforkret()によって始まる(1984)。forkret()は、ptable.lockを解放を用いて、xv6の慣習に従うためだけのために存在している。それ以外の場合では、新しいプロセスはtrapret()によって始まる。

[Sleep and Wakeup]

ロックは、CPUとプロセスが互いに干渉することを回避するのに役立ちます。また、スケジューリングは、プロセスがCPUを共有するときに役立ちます。しかしながら、今までの内容には、プロセス間の通信を簡単にする抽象化機構はありません。Sleep/wakeup機構は、あるプロセスが何らかのイベントを待つために眠り、そのイベントが発生したら他プロセスがそのプロセスを起こすという機構を用いることで、その穴を埋めてくれます。

具体的な例を見るために、シンプルなproducer/consumerのキューを見てみましょう。そのキューは、あるプロセスが、他のプロセスに対して0でないポインタを送ることを許可します。もしたった１つのsenderとreceiverしかいなく、また、それぞれが別々のCPUで実行されている場合、次の実装は正しいと言えるでしょう。

struct q {
void *ptr;
};

void* send(struct q *q, void *p){
while(q->ptr != 0)
;
q->ptr = p;
}

void* recv(struct q *q){
void *p;

while((p = p->ptr) == 0)
;
q->ptr = 0;
return p;
}

send()は、キューが空になるまで(ptr == 0になるまで)ループする。その後、send()はポインタpをキューの中に置く。recv()はキューが空でない間、ポインタpを外に取り出す。２つの異なったプロセスが走るとき、send()とrecv()は、両方ともq->ptrを編集する。しかしsend()は、ポインタが0であるときだけ、ポインタに書き込む。また、recv()は、ポインタが０でないときだけ、ポインタに書き込む。従って、send()とrecv()は相互にステップを踏むわけではない。

上述の実装は正しいかもしれないが、非常に高価である。もしsenderが時々send()する場合、receiverはポインタの値が変わるまでの間、常にwhileループでスピンし続けなくてはいけなくなるだろう。もしsend()がポインタへ到達したことをreceiverに対して通知する何らかの方法があったのだとしたら、receiverのCPUは、もっと生産的な仕事をすることが出来たかもしれない。sleep()とwakeup()は、そのような機構を提供する。sleep(chan)は、wait channelと呼ばれるポインタ"chan"の上でsleepする。chanは、参照されるためではなく、アドレスとして使われるため、chanはどんな種類のポインタであっても良い。sleep()は、呼び出し元のプロセスをsleepさせ、CPUを他の仕事のために解放する。sleep()は、プロセスが再び起きるまでreturnしない。wakeup(chan)は、chanの上で眠っているプロセスがあれば、各sleep()にreturnを実行させることで、chanの上で眠っている全てのプロセスを起こす。sleep()とwakeup()の機構を使うことで、上述の実装は次のように書き換えることが出来るだろう。

void* send(struct q *q, void *p){
while(q->ptr != 0)
;
q->ptr = p;
wakeup(q); /* wake recv */
}

void* recv(struct q *q){
void *p;

while((p = q->ptr) == 0) /* (1) */
sleep(q); /* (2) */
q->ptr = 0;
return p;
}

このコードはより効率的であるが、もはや正しくはない。なぜなら、このコードは"lost wake up"問題を起こすからである。recv()が、(1)の箇所で"q->ptr == 0"であることが分かり、sleep()を呼ぼうとするとしよう。recv()がsleepする前は、send()は他のCPU上で走っている。つまり、send()がq->ptrを0で無い値に書き換え、wakeupを呼びだしたとき、どのプロセスの眠っていないことが分かる。このとき、recv()は(2)の箇所でsleep()を実行するだろう。recv()はsleep()を呼び、sleepする。このとき、"lost wake up"問題が発生する。つまり、recv()は、既に0以外の値に書き換えられているポインタに対して、sleep()をして待ち続けることになる。次のsend()は、recv()がキューの中のポインタが消費されることを期待して、sleepして待ち続けるだろう。このような現象を、システムがデッドロックしたという。

この問題の原因は、recv()がq->ptr==0のときにだけsleepするという不定状態が、send()が間違ったタイミングで走ることで、侵害されることによって発生される。この不定状態を保持するためには、ロック機構を導入し、呼び出し元プロセスが眠っているときのみsleep()はロックを解放できるようにすれば良い。一度呼び出し元プロセスが再び起こされたとき、sleep()はreturnの直前でロックを取得する。次のコードは正しく、また、recvがwaitしているときも、CPUを効率的に使うことが出来る。

struct q {
struct spinlock lock;
void *ptr;
};

void* send(struct q *q, void *p){
lock(&q->lock);
while(q->ptr != 0)
;
q->ptr = p;
wakeup(q);
unlock(&q->lock);
}

void* recv(struct q *q){
void *p;

lock(&q->lock);
while((p = q->ptr) == 0)
sleep(q, &q->lock);
q->ptr = 0;
unlock(&q->lock);
return p;
}

１つの完全な実装は、receiverが１つ前のsend()の値の消費を待っているようなsend()時においても、sleepできるようにすることだろう。

[Code: Sleep and Wakeup]

Xv6におけるsleep()/wakeup()の実装を見てみよう。基本的なアイデアは、sleep関数で、カレントプロセスにSLEEPINGとマークすることである。次に、sched関数を呼び出し、プロセッサを解放する。wakup()は与えられたポインタの上で眠っているプロセスを探し、発券したらそのプロセスにRUNNABLEとしてマークする。

sleep()は、いくつかの健全なチェックから始まる(2003)。そのチェックとは、カレントプロセスがあることと(2005-2006)、sleep()はロックを通過し終えたばかりであることである(2008-2009)。次に、sleep()はptable.lockを取得する(2018)。このとき、sleepしようとしているそのプロセスは、ptable.lockとlkを両方とも保持している。lkを保持することはcaller(e.g. recv())にとって必要なことであった。カレントプロセスは、他のどのプロセス(e.g. send())もwakeup(chan)を開始することが出来るだろう。このとき、sleep()はptable.lockを保持していて、sleep()は安全にlkを解放することが出来る。言い換えると、ある他のプロセスがwakeup(chan)を開始させたとき、wakeup()はptable.lockを取得できるまでの間、wakeup()が動くことは無い。よって、wakeup()は、sleep()を見失わないように、sleep()の実行が終了するまでの間、待たなければならない。

やや一般的ではない複雑性も存在する。もしlsと&ptable.lockが同じであるとき、sleep()は、&ptable.lockと同様の方法でlkを取得したり、lkと同様の方法で&ptable.lockを解放することによって、デッドロックを起こすかもしれない。この場合、sleep()はacquireとreleaseが互いにキャンセルしてしまったり、また、完全にスキップしてしまったりすることを考えなければならない。

sleep()がptable.lockを保持し、他のどのロックも取得していないとき、sleep()は、sleep channelを記録し、プロセスの状態を変更し、また、sched()を呼ぶことによって、プロセスをsleepさせることが出来る(2023-2025)。

いくつかのチェックポイントを過ぎると、プロセスはwakeup(chan)を呼び出す。wakeup()はptable.lockを取得し、実際の仕事を行うwakeup1関数を呼ぶ(2053)。wakeup()関すがptable.lockを保持するということは、wakeup()がプロセスの状態を操作するという点と、ptable.lockがsleep()とwakeup()が互いに見失い合わないという点から、重要なことだと言える(wakeup1()は分離された機能である。というのも、スケジューラは、既にptable.lockを取得しているとき、wakeup()が実行する必要があるからである。この例は後で見ることにしよう。)。wakeup1()はプロセステーブルを走査する(2053)。schedulerは、適切なchanを持つSLEEPING中のプロセスを発見したとき、schedulerはそのプロセスの状態をRUNNABLEに変更する。これにより、次にschedulerが動作されるとき、schedulerは、そのプロセスが実行可能であることが分かる。

※ 他にも、Spurious Wakeups(偽りのwakeups)という複雑な問題も存在する。

SCR輪講後半
===========
[Code: Pipes]

本章の序盤で私たちが使ったシンプルなキューはオモチャであった。しかし、Xv6が実際に使っているキューでは、readersとwritersを同期させるために、sleep()とwakeup()を使用している。Xv6のキューとは、pipeの実装である。私たちはpipeのためのインタフェースを０章で見た。具体的には、pipeの末端に書かれるバイトは、kernel buffer内にコピーされ、その後、そのpipeの他端から読み出す事が出来る(FIFO Queue)。今後の章では、pipeの周りにあるファイルシステムのサポートについて触れていく。本章では、pipewrite()とpiperead()の実装について見てみよう。

各pipeはstruct pipeとして宣言される。struct pipeはlockとdataバッファを持っている。nreadとnwriteというフィールドは、バッファから読み出した／バッファに書き出したバイト数をカウントする。また、そのバッファはラップされている。つまり、buf[PIPESIZE-1]の直後に書かれている次のバイトはbuf[0]である。しかし、カウンタはラップされない。この慣習により、(nwrite == nread+PIPESIZE)という状態の満杯のバッファと、(nwrite == nread)という状態の空のバッファを見分けるときに役立つ。しかし、一方で、バッファのインデックスの際は、buf[nread]やnwriteの代わりに、buf[nread % PIPESIZE]を使わなければならない。なお、piperead関数やpipewrite関数は、別々のCPUによって同時に呼び出される可能性がある事に注意する必要がある。

pipewrite()はpipeのロックを取得する事から始まる(5230)。ロックを取得する事により、count,dataなどの変数を保護する事が出来る。このとき、例えばpiperead()も同様にしてロックを取得しようとしたとしても、ロックを取得する事は出来ない(5251)。この場合、piperead()はロックが取得出来るまでスピンし続けるだろう(1373)。piperead()が待っている間、pipewrite()は、交互にaddr[0], addr[1], ..., addr[n-1]を書き換える動作を繰り返す(5244)。このループの間、pipewrite()はバッファを満たしていく(5236)。バッファが満杯になった場合、pipewrite()はwakeup関数を呼び出し、sleepしているreaderに対してデータが読み込み待ちであることを伝える。そして、pipewrite()は&p->nwriteに対してsleepを行い、readerがbufferからデータを取り出すのを待つ。sleep()は、pipewrite()がsleepするプロセスの途中で、p->lockを解放する。

p->lockが取得可能なとき、piperead()はp->lockの取得を管理し、その後、pipeからデータを読み出す。具体的には、piperead()は(p->nread != p->nwrite)であることをチェックする(5256)。つまり、pipewrite()は、p->nwrite == p->nread+PIPESIZEのとき、sleepし始める(5236)。従って、piperead()は、forループを抜けると、pipeからデータをコピーし、コピーしたバイト数だけnreadの値をインクリメントする(5263-5267)。最初は、pipeに多くのバイトを書き込む事が可能である。よって、piperead()はwakeup関数を呼び出し、眠っているwriterを起こす。

wakeup関数は&p->nwriteに対して眠っているプロセスを見つけ、プロセスの状態をRUNNABLEに変更する。このとき、眠っているプロセスとは、pipewrite()を走らせていたが、bufferが満杯であるためにsleepしたプロセスのことである。

他CPU上のスケジューラが異なるプロセスを走らせようとしている場合、pipewrite()はすぐに走り始める事は無い。代わりに、piperead()は、piperead関数を再び呼んだcaller関数に戻る。初めてpiperead()がpipe内のバッファを全て読み出したときは、(p->nread == p->nwrite)という条件式が成立する。その後、piperead()は、&p->nread上でsleepし、データが書き出されるのを待つ(5261)。piperead()を呼び出しているプロセスがsleep状態のとき、sleep関数をreturnさせることで、CPUはpipewrite()のプロセスを走らせる(5242)。pipewrite()は、bufferに残ったデータをコピーした後、このループを終わらせる(5244)。新しいデータを待っているreaderが存在する場合、returnする直前で、pipewrite()をwakeup関数を呼ぶ。残されたpiperead()は走り続け、pipeから新しいデータをコピーする(pipe.c/piperead-sleep/)。

[Code: Wait and exit]
sleep()とwakeup()は、キューの実装時に必ず必要というわけでは無い。sleep()とwakeup()は、チェックしたいコードや待つ必要がある状況において、動作する。0章で見たように、親プロセスは、子プロセスがexitするのを、wait関数を呼ぶ事で待つ事が出来る。Xv6においては、子プロセスがexitしたとき、子プロセスはすぐに死ぬわけではない。代わりに、子プロセスはZOMBIEというプロセス状態にスイッチして待つ。親プロセスがwait関数を呼んで、子プロセスがexitしたことを知るまで、子プロセスはZOMBIE状態で待つ。親プロセスが子プロセスを回収したとき、子プロセスが所有しているメモリを解放する。そして、struct procが再利用出来るように準備する。各プロセスの構造体は、p->parentに親プロセスへのポインタを格納する。もし子プロセスがexitする前に親プロセスがexitしてしまった場合は、initプロセスが、子プロセスのexitに対応する。これは、親プロセスが、子プロセスが終了する前にexitしてしまったときのために必要なステップである。全てのプロセスの構造体はptable.lockによって保護されている。

wait関数は、ptable.lockを取得することから始まる。wait関数は、プロセステーブルを走査し、子プロセスを探す。wait関数は、まず、カレントプロセスに子プロセスが存在し、また、そのどれも未だexitしていないかどうかをチェックする。この場合、wait関数はsleep関数を呼び出し、子プロセスのいずれかがexitするのを待ち、ループする。ここで、sleep状態から解放されるlockはptable.lockである。上述したケースは、その一例である。

exit関数はptable.lockを取得し、その後、カレントプロセスの親プロセスを起こす(2126)。exit関数は未だカレントプロセスをZOMBIEプロセスに変更していないので、ロックの取得は未だ早過ぎるかもしれない。しかし、このロック取得は安全である。親プロセスはRUNNABLE状態に変更されるかもしれないが、wait関数にループは、exit関数がsched関数からスケジューラに入り、ptable.lockを解放するまでの間、走る事は出来ない。従って、プロセスの状態がZOMBIEになるまでの間、wait関数がexitするプロセスをチェックする事は無い(2138)。exit関数がリスケジュールする直前で、親プロセスは、子プロセスからinitプロセスまでの全てのプロセスをチェックする。最終的に、exit関数は、shed関数を呼び出す事でCPUを手放す。

スケジューラは、wait関数によってsleep状態に成っている、exitするプロセスの親プロセスを選ぶ事が出来る(2188)。sleep関数の呼び出しは、ptable.lockをreturnする。具体的には、wait関数はプロセステーブルを再び走査し、exitしたプロセス(state == ZOMBIE)を見つける。wait関数は、子プロセスのPIDを記録する。その後、その子プロセスに関わるメモリを解放し、struct procをクリアする(2168-2175)。

子プロセスは、exit関数の中で上述のクリア作業を行う。重要な事は、親プロセスが、親プロセス自身によってp->kstackを解放することである。子プロセスがexit関数を走らせるとき、子プロセスのスタックは、p->kstackとして確保されたメモリに置かれる。子プロセスのスタックは、子プロセスがshed関数のswtch関数を通して解放される。そして、子プロセスの状態を移行する。こうする理由は、(1)スケジューラの処理がスタック上で走っているからである。また、(2)xv6は、sched関数とscheduler関数を相互ルーチンとして管理するからである。xv6は、子プロセスから直接scheduler関数の処理を呼び出す事は出来ない。なぜなら、scheduler関数の処理は、スタック上で走るからである。また、そのスタックは、wait関数を呼んでいる親プロセスによって削除される可能性がある。

[Scheduling concerns] /* 下書き */

- Spurious wakeupsについて
- p->killedのチェックについて
- thundering herdについて

[Real world]

sleep関数とwakeup関数はシンプルで効率的な同期メソッドである。しかし、他にも同期をする方法はある。そのうちの１つは、本章の序盤で見た"missed wakeups"問題を避ける同期メソッドである。オリジナルのUnixカーネルのsleep関数は、割込を禁止する。この方法で同期をすることができる理由は、Unixは１つのCPU上で動くシステムであるからである。xv6はマルチプロセッサ上で動かす事を想定しているため、xv6は明示的なロック機構をsleep関数に導入している。FreeBSDのmsleep関数も同じアプローチを取っている。Plan 9のsleep関数は、callback関数を使っている。callback関数は、sleepする直前で取得する、スケジュール用のロックと共に動作する。具体的には、callback関数は、直前のsleepの状況をチェックするときに役に立つ。これにより、"missed wakeups"問題を避けることが出来る。Linuxカーネルのsleep関数は、waitチャネルの代わりに、明示的なプロセスキューを使っている。Linuxカーネルのプロセスキューは、内部用のロックを持っている。(一見、コードは十分でないように見える。実際にはどうなるだろうか？)

chan関数とマッチするプロセスのために、wakeup関数内で全体のプロセスリストを走査する事は、非効率的である。より良い解決策は、sleep関数やwakeup関数内のchan関数を、sleep状態のプロセスリストを持っているデータ構造体に置換することである。Plan 9のsleep関数とwakeup関数は、待ち合わせ箇所やRendezの構造体を使う。多くのスレッドライブラリは、変化可能な条件としてその構造体を参照する。つまり、sleep関数とwakeup関数の処理はwait関数やsignal関数によって呼び出される。これらのメカニズムは、同様の手法を共有する。具体的には、sleepの条件は、sleepしている間、アトミックに解放されたロックによって保護される。

セマフォは、異なった協調メカニズムである。セマフォは、２つのオペレーション(increment/decrement, up/down)を持ったint型の値である。セマフォは、いつでもインクリメントする事が可能である。しかし、セマフォの値がゼロを下回る事は許されない。よって、他プロセスによってそのセマフォがインクリメントされるまで、ゼロのセマフォをデクリメントはsleepする。そして、２つのオペレーションはキャンセルされる。int型の値は、典型的には、実際のカウンタの値(e.g. pipeバッファのバイト数, プロセスが持っているZOMBIEプロセスの数)と呼応する。抽象化の１つとして明示的なカウンタを使用する事によって、"missed wakeup"問題を避ける事が出来る。このため、wakeupの発生回数の明示的なカウンタが存在する。このカウンタは、条件変数による"spurious wakeup"問題や、"thundering herd"問題を避けることも出来る。

[Exercises] /* 下書き */

sleep関数は、デッドロックを避けるために、(lk != &ptable.lock)であることをチェックしなければならない(2017-2020)。sleep関数は次のコードを

if(lk != &ptable.lock){
acquire(&ptable.lock);
release(lk);
}

次のコードに置き換える事によって、特別な状況を無視する事が出来るだろう。

release(lk);
acquire(&ptable.lock);
.P2

これによりsleepをbreakする。どうやって？

ほとんどのプロセスのcleanupは、exitまたはwaitによって処理される。
上述のケースはexitを使っている。
このとき、freeを使ってはならない。
p->stack
これにより、プロセスは、exit関数はopenファイルの近くにいなければならなくなる。
何故？
答えはpipeと関係している。

xv6においてセマフォを実装すること。
ミューテックスを使っても良いが、sleep関数とwakeup関数は使わないこと。
xv6のsleep関数とwakeup関数をセマフォに置換する。
結果を比較せよ。

[Additional reading]

cox and mullender, semaphores.
pike et al, sleep and wakeup.

コワーキングと沖縄とお仕事募集中

noreply@blogger.com (yasulab) — Fri, 16 Dec 2011 11:51:00 +0000

このブログを書くまでに至った経緯を簡単に説明しよう（キリッ。

最近、Advent Calendar っていうブログのリレーが今流行りらしい。なんか面白そう。
Fluxflex Meetup で知り合った @mzdakr さんが Coworking 版のソレをやってるらしい。
って「Coworking」って何ぞや？まぁいいか。それは置いといて...
ポチッ（イベント参加登録ボタンを押した音）
さて、とりあえず Coworking について調べるか...
OSSCafe と PAX Coworking を訪問。
うおー！Coworking 超面白い！
でも沖縄では未だ Coworking 出来る場所が無いっぽい...
じゃあとりあえず沖縄で広めるか！　　（←今ココ）

...というわけで、今に至ります。ナニはともあれ、まずはブログを書かにゃナニも始まりません。そこで、この記事では、「Coworkingとは何ぞや？」という疑問に答えるべく、初歩的な内容を書いていきます。そして後半では、沖縄におけるCoworkingの現状や、僕がやっている事などについて記します。

で、Coworkingって何ぞ？

僕の乏しい参加経験から勝手に推測すると、Coworkingとは、大中小の組織の規模を問わず、仕事の種類を問わず、各々あるいはグループ毎に、場所を共有して仕事をすることのようです。Coworking Space（Coworkingをする場所）についても、最初のうちは「IT系の個人や小規模な組織のためだけのスペースなのかなー」と思っていたけど、どうやらそういうところではないみたい。実際、コクヨや富士ゼロックス、NECのようないわゆる大手のところでも、こういった Coworking Space を設けて、Coworking を推奨する動きを見せています。なので、個人的には「色々な方々が、色々な方法で、Coworking する」といった理解をしています。

で、どんな人が来るの？

まず、僕のようなフリーランスな人だけが利用するスペースではないことは確かです。グループで、誰かと一緒に仕事をしに来る人もいます。最近は、コワーキングスペースを利用するため、オフィスを引き払った会社もあるようなので、今後は、より色んな形でコワーキングスペースを利用する人達が増えてくるのかもしれません。例えば、学生が勉強しに来るとか、子連れで仕事しに来るとか、etc.。いずれにせよ、僕は多様性のある環境が結構好きなので、こういった動きは、僕個人としては歓迎です。

で、どんな仕事してるの？

Coworking する人も色々いますが、彼ら／彼女らの仕事の種類も色々あります。一見、IT系の人向けの特殊な共有スペースかと思いきや、全くそうじゃないです。プログラマやデザイナだけでなく、コピーライター、ジャーナリストの方々もいます。

例えば、僕が OSSCafe を訪問していたとき、「スクリプトを書きに来ました」という方々と会いました。「なるほどやっぱしIT系の人が来るのね」と僕は思ったのですが、ところがどっこい彼らは全然 Lisp とか Python とか Ruby とか全然書いてない！「おいおいおいどういうことだよ...」って思ったら、コピーライターの業界では、どうやらキャッチコピーを創ることを「スクリプトを書く」と表現するみたいです。長くIT業界に浸かっていると、こういう他分野の表現に出会わないので、刺激的ですね。人も色々、仕事も色々、って感じ。

余談

PAX Coworking にいるときに、こんな会話を聞きました。

1. トゥルルルルル...（電話が鳴る）

2. 「もしもし、社長とお話したいのですが、社長はいらっしゃいますか？」

3. 「えーっと、どこの社長でしょうか？」

4. 「... ... ...」

当然ですけど、Coworking Space には、いわゆる社長な方が結構います。１人とは限りません。こういう、従来の働き方ではありえないような展開と巡り会える環境というのも、Coworking の面白い点の１つではないでしょうか。

ここまでのまとめ

僕はまだまだ駆け出しのフリーランスで、仕事もほとんど沖縄でしか取れていません。しかし、こういった Coworking Space の環境を使わせて頂くことで、能力と実績さえあれば、ネットワーキングがより簡単に出来ると考えています。フリーランスとしては非常に心地良い環境が構築されつつあると感じるので、個人的には嬉しいかぎりです。~~ときどき「もっと安くならないかなー」とか考えたりしますが、つまりは僕がもっと稼げばいいということなのでしょう。~~

"""
↑ここまで東京の話

↓ここから沖縄の話
"""

沖縄の現状

さて、じゃあ沖縄の現状はどうでしょうか？ Coworking するスペースが既にあるかと聞かれると、僕の知る限り、今のところ沖縄には Coworking Space にあたる場所はほとんど無いです。ただ、僕は沖縄に対してヨーロッパに似た雰囲気を感じているので、もし沖縄に Coworking Space があったら、沖縄で「遊び半分、仕事半分」な Work Life Balance が気軽に体験出来て、非常に面白そうな気はしています。

僕は友達もコネも全くゼロの状態から始めたので、沖縄でフリーランスとして活動出来るようになるまでに、少々時間がかかってしまいました。しかし、もし Coworking Space が沖縄に既に出来ていたら、より簡単に、より早く沖縄でフリーランスとして活動出来ていたかもしれません。もしそんな環境が構築出来たら、ちょっとワクワクするでしょう？

なぜ沖縄？

ところで、この記事を読んでいる方の中には、もしかしたら「何で沖縄で活動する必要があるの？」って感じる方がいるかもしれません。そう思った方は、是非 @sayobs さんが書いた記事「沖縄に１ヶ月生活 – ノマドしてきた感想とか」を読んでみて下さい。きっと沖縄で「遊び半分、仕事半分」な Work Life Balance を体験したくなると思います。沖縄に Coworking Space 、あるいはそれに準ずる環境が出来た際には、皆さんも是非沖縄に来てみて下さい。

話を戻して...

現状で、Coworking Space に類するプロジェクトが１つも無い訳ではないです。名前こそ Coworking ではありませんが、それっぽいところ、それっぽい活動はちらほら見受けます。ここでは、その一部をご紹介しようと思います。

1. SHDH Okinawa

例えば、僕もちょっとお手伝いしている活動ですが、SuperHappyDevHouse Okinawa という活動があります。コンセプト自体は Coworking に非常に近いと思います。しかも無料！ただ、開催が月に一回なので、どちらかというと、勉強会と Coworking の中間ぐらいに位置する活動なのかなーと僕は思います。あと、開催地が沖縄の中部にあるので、車が無いとアクセスがつらいのも、やや難しい点です。

2. ギークハウス沖縄

他にもあります。ギークハウス沖縄というプロジェクトです。週末ものづくり講座の受講生が一枚噛んでいるので、僕もちょくちょく現況を聞いています。ただ、こちらはまだオープンしていないので、今後どういった形態で活動が行われていくのかは、まだまだ分かりません。しかし、非常に面白い試みだと思うので、今後に期待です。

3. 名称不明なプロジェクト

で、最後に、僕のプロジェクト。名前は未だありません（Online Study Shared Space? OS3? ）。とにかく、出来立てホヤホヤ。ITカレッジ沖縄という学校の教室が、月・木の夕方と、土曜日を終日借りれそうなので、「そこで何か面白いこと色々やろうぜ」的なプロジェクトです。早ければ来週ぐらいから始まるかもしれないし、永遠に始まらないかもしれません。とりあえず決定している事は、「電源や無線が使える場所を無料で提供してもらえる」ということだけです。

当初は Coworking Space っぽさをバリバリ出そうかなーと思ったのですが、無料で場所を提供して頂く関係で、「（学内外を問わず）学生に何らかのメリットがあること」が条件になります。あと、オープンソースであること。加えて、僕がアッチいったりコッチいったりするので、僕が常駐する事も出来ません。そこで、僕の辿り着いた（とりあえずの、暫定的な）結論は、次のようなスペースを創ることです。

勉強したり開発したり仕事したり出来るスペースだけど、
基本的に一緒に StanfordのOpen Course や MIT／Berkleyの講座を受講したり、
僕が週末ものづくり講座をリモートで講義したりするための、

そんな感じのスペースを創ろうかと考えています。Coworking というよりは、Costudying に近いような感じですかね。ただ、実施されるその瞬間までは、僕の脳内妄想に違いありません。なので、実施されるその日までは、生暖かい目で見守って下さい。

最後に

Coworking Advent CalendarのATNDには、次のような文章が書かれています。

１０分で考えて５分で書く、気軽な内容でOKです。

全然ムリです。軽く１０倍以上の時間がかかってます。来年はもっとサクサク書きたいですね。

ところで、来年の１月末から数ヶ月間シリコンバレーに滞在する予定なのですが、
その資金として、お仕事を絶賛募集中です。リモートでも出来る仕事だと嬉しいです。
仕事とは関係なくても、何か面白そうな話があれば yasulab@gmail.com までご連絡頂けると嬉しいです。
僕の最近の活動記録は http://www.yasulab.com/に書いてあります。

ではでは、皆さんからのお便りをお待ちしております。

Make: Tokyo Meeting 07 に出展してきました！

noreply@blogger.com (yasulab) — Sun, 04 Dec 2011 11:31:00 +0000

「ブログを書くまでが勉強会です」ということで、早速レポート。

Make: Tokyo Meeting 07 に出展してきました！前日に沖縄で終日の講義があったので、若干弾丸ツアー的な部分もありましたが、なんとか間に合いました。

僕が出展した内容は、「週末ものづくり講座」というプロジェクトの紹介です。このプロジェクトは、「とにかく早く作って早く公開する」をモットーに、色んな物を作るプロジェクトです。具体的には、

仕事が終わった後の金曜夜から日曜の終わりまでに, アイデアからプロトタイプまでを一気に作成し, 月曜日にドヤ顔で「こんなん作っちゃったんだぜ（キリッ」と周りの人に発表する.

といった感じで、毎週末活動をします。毎週１作品作るのが目標。

元々（というか元凶）は、ホイッスルアプリが３ヶ月で5万ダウンロードされたことです。小さい成功ではあるけれど、この結果から「サクッと作れるシンプルなモノ(*1)でも、皆が使ってくれるモノは、まだまだ結構あるんじゃね？」と考えるようになりました。

*1 ちなみに、ホイッスル on Androidの中身は30行。

「とりあえず実験してみよう」ってことで、勢いに任せて色々創ってみました。例えば、Simple TimekeeperとかNico Rank Inverterとか。結果としてうまくいったのはほんの少しで、残りのほとんどは失敗でしたが、しかし、やってみるとこれが案外面白い。

面白いので、皆にこの面白さを是非共有したい。IaaSとかPaaSとか、最近はモノを作って公開するための環境が非常によく整って来ているので、もっとアプリ作る人が増えてもいいと思うしね。なので、「じゃあ講座でも開くか」と考え、紆余曲折（告知とか交渉とか）を経て、週末ものづくり講座のカリキュラム（ver. 0.01）を完成させました。これが9月の話。で、10月からITカレッジ沖縄という学校で、実験的な授業がスタート。そして、11月の末に、無事１期生の授業が終わる（←今ココ）。といった感じです。

ちなみに、１期生の作品はコチラで順次公開していく予定です。また、ハッカソンというイベントで、１期生の１人とコラボって作った作品がコチラ。

こんな感じの、わりと勢いと衝動任せのプロジェクトですが、反応は中々良いみたい。社交辞令かもしれないけど、例えば、こんな感じの反応を頂いたり。

最近は、レキサスアカデミーという沖縄のアプリ開発塾みたいなところで、専属講師としてものづくりのアレコレを教えています。定員は15名なんですが、既に満員間近。聴講生（正式な受講生ではないが、興味があるので参加する人）も来るぐらいので、個人的には嬉しい限り。

とまぁ、こんな感じの近況報告を、WIZDOM枠を使わせて頂き、Make: Tokyo Meeting 07で発表させて頂きました。こっちでの反応もいい感じでした。特に、「是非受講したい！」という話を貰えたのは非常に嬉しかったです。今は沖縄を拠点してやっているので、残念ながら沖縄以外では気軽に受講できないけれど、「誰か東京でやってくれないかなー」と悶々とする妄想する今日この頃。

最後に、宣伝ですが、WIZDOMの他のプロジェクトも非常に面白いです。例えば、GPL HouseとかCAPBOTとか。何やらハードウェア系がもっさりある感じなので、ここは是非彼ら／彼女らと情報交換したいなーとか、妄想に耽っています。

# 最近は妄想が酷い...

今年立ち上げた Okinawa.rb でも「クラウドからハンダ付けまで」をモットーに（僕が勝手に）掲げているので、ハード系な人達ともっと交流しなきゃあかんなー、と考えています。

12月3日(土)にIT津梁パーク@沖縄で行われるイベントまとめ

noreply@blogger.com (yasulab) — Thu, 01 Dec 2011 07:13:00 +0000

各勉強会のメーリングリストにも流しましたが、ブログにも掲載します。
興味ある方は是非に。
------------------------------

こんにちは、@yasulab です。

今週土曜日（12月3日）は、IT津梁パークで次のイベントが行われます。

ご都合の着く方は是非是非ご参加を。

10:00-12:00　「アマゾンウェブサービスがもたらすITのニューワールド」

詳細：http://blog.lexues.co.jp/?p=9165

13:00-17:00　Okinawa.rbワークショップ(*1) in Okinawa SHDH (*2)

詳細：http://atnd.org/events/22050

なお、15:00-16:00は、@libkinjo さんによる次の発表があります。

>■SHDH2 でもくもくしたアプリ dont-forget-something の解説

>・見所: accepts_nested_attributes_for, haml, やや力技 jquery などw
>■ロレーヌでもくもくしていた twitter 擬の解説
>・見所: rails 3.1/CoffeeScript/mongo/rspec/spork/factory_girl

モクモクと勉強／開発する際のBGMとしてどうぞ、とのことです。

また、13:00-17:00は、同じ会場で Lexues Academy(*3) が行われます。

週末ものづくり講座(*4)に関するアレコレを僕が話しているはずなので、

興味ある方は覗きに来て下さいね。~~今回は誰でも聴講することが可能です。~~
※追記：いつでも誰でも聴講することが可能です。

ではでは、参加する方は是非当日会場でお会いしましょう。

yasulab

*1 Okinawa.rb ワークショップってなんぞや？って方はこちらへどうぞ。

http://qwik.jp/okinawarb/4.html

*2 Okinawa SHDHってナニ？という方はこちらへ。

https://sites.google.com/site/okinawashdh/home

*3 Lexues Academy

http://www.lexues.co.jp/info/?p=769

*4 週末ものづくり講座

http://weekend-fabrication.yasulab.com/

Androidデザインに関するアレコレ

noreply@blogger.com (yasulab) — Sat, 26 Nov 2011 07:48:00 +0000

最近、Lexues Academy というアプリ開発塾(?)で専属講師的な感じでアプリ開発を教えています。で、その一貫で外部講演がときどき開かれるのですが、先週と今週の外部講演で聞いたデザインの話が結構面白かったです。先週はAndroid女子部部長の @yanorin さんが講演され、今日はAndroid女子部副部長の @yanzm さんのお話をされました。（写真は @yanzm さんの講演の１コマ）

両名ともデザインに関するお話をしていましたが、僕的に特に面白かったのは、デザインするときに役立つツールの話です。覚えてる限りですが、話全体を通して、次のツールが取りあげられていたと思います。順不同。

Android メニュー用アイコン
dafont
OmniGraph + Android Stencil（サンプル）
InkSpace (instead of Illustrator)
Android Icons
Color Scheme Designer
Cacoo - Create diagrams online Real time collaboration!
UI Stencils
Android Asset Studio
Adobe Kuler
Android Developers
Button Maker

他、参考図書など(覚えてる限り)：

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
アジャイルサムライ
Designing Interface
Non-Designer's Design Book

＊ちなみに、当日 @yanzm さんが使った資料(集)はこちらから。

留学中にデザインの授業を取ってから、デザインの勉強を継続的に行うようになったのですが、ツールに関する知識はあんまりなく、留学中も Adobe 以外はあんまり触らなかったので、こういった話は結構新鮮で興奮します。

皆さんのご参考にもなれば幸い。

Quick Start for Public Key Authentication on SSH

noreply@blogger.com (yasulab) — Wed, 16 Nov 2011 16:32:00 +0000

今までのプロジェクトの遺産で、別に公開しても良さそうな簡単な技術の話は公開しましょうねキャンペーン実施中。今回は、SSHの公開鍵設定の話。仕組みとかは原理とかは全部端折ってます。

以下、SSHの公開鍵設定についてのお話。

=======================

ここではSSHの公開鍵設定を原理などを省いて説明します。
Linux/OSXなどのUNIX系のみで有効な説明ですが、Windowsユーザの方はPuTTYのオプション
であるのでググれば説明があると思います。

1. 鍵をつくる
--------------
まず、公開鍵と秘密鍵のペアを作ります。

$ ssh-keygen

オプションがいろいろありますが、詳細はmanしてください。
色々聞かれますが、基本全部デフォルトのままでいいのでエンター押してください。
パスワードが必要なら入力してください。

すると~/.ssh以下にid_rsaとid_rsa.pubというファイルができます。
id_rsaが秘密鍵、id_rsa.pubが公開鍵です。

2. 公開鍵をサーバーに置く
---------------------------
これは任意の方法で行なってください。

$ scp ~/.ssh/id_rsa.pub 112.233.445.566:~/id_rsa.pub

など。

# 112.233.445.566 はお手持ちのサーバのIPアドレスに脳内変換して下さい。

3. 公開鍵をキーチェーンに追加する
------------------------------------
~/.sshの下にあるauthorized_keysに公開鍵を追加します。
サーバ上での自分がログインするユーザのホームディレクトリ以下の.sshです。

$ ssh 112.233.445.566
$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys

以上です。

ちなみに、2. 3. は初回であれば

$ scp ~/.ssh/id_rsa.pub 112.233.445.566:~/.ssh/authorized_keys

のようにひとつのステップで省略できます。

また、~/.ssh/configを以下のように設定しておくと楽です。
(べつにシェルの履歴で簡単に辿れますが)

$ /Users/yasulab/.ssh% cat config
Host hogehoge
Compression yes
Hostname 112.233.445.566
User yasulab

$ /Users/yasulab/% ssh hogehoge

この~/.ssh/configの設定により、以降、hogehoge サーバにパスワード無しでログイン出来るようになります。

以上、SSHの公開鍵設定についてのお話でした。

IDEO訪問記を又聞きしてみた。

noreply@blogger.com (yasulab) — Tue, 15 Nov 2011 17:06:00 +0000

シリコンバレーにあるIDEO本社に行ってきた友達の話を聞いてきました。2010年2月に書いたメモで、元々はSorarierというプロジェクトのメンバー向け情報だったんですが、公開した方が世のため人のためだと思ったので、公開します。ご参考まで。

以下、僕がインタビューして聞いた話のメモを記します。
#1 といっても、１年前ですが...
#2 メモなので、箇条書きがかなり多いです。雰囲気を感じt(ry

[Index]

- Brainstormingについて

- 参考文献

[Brainstormingについて]

Brainstormingのプロセス:

- 1. Listen
- 2. Learn
- 3. Envision

1. Listen

- ユーザインタビューについて

メモ:

- IDEOでは、ユーザインタビューは定性評価と定量評価を以下のように使い分ける。

-- 1. 定性評価: 右下図(縦軸=ユーザ数, 横軸=ヘビーorライトユーザ)の両極端を5人ほどインタビューする

--- 一般的なユーザは「なんとなく」使っているだけ。

--- ある製品を絶対に使わないと決めている人や、使い倒している人は、確固な意志を持っていることが多い。

---- 定性評価では、この意志が参考になる。

-- 2. 定量評価: 大体500人程度を目安ににアンケートを取る。

2. Learn

- 2.1 Post Itの方式で、1.の結果からアイデアを出す。壁にペタペタ貼る

-- このとき、意識的に絵を書くようにする。
＃次の図は文字が多いので悪い例。

-- 2.2 出たアイデアをGroupingする

2.3 各Theme毎に再度アイデアを出す。

2.4 再度Groupingをする。(以後、Groupingとアイデア拡張を繰り返す。)

Point:

経験的に、繰り返しの回数(横軸)とアイデアの質(縦軸)は、ルート関数っぽい。「何回繰り返すか?」が重要。

3. Envision

- 良いアイデアが出たら、早速プロトタイプを作成する。ここではスピード感が大事。

-- プロトタイプの作成を通して、未知の問題を洗い出す。

↓

4. /* ...時間がなかったのでEnvisionまでのプロセスしか聞いてない... */

NOTE: これ以降のプロセスやより詳しいプロセスについては、次の参考文献「Change by Design」に書かれているとのこと。

[参考文献]

- Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation (ハードカバー)

-- Tim Brown (著)

-- URL: http://www.ideo.com/cbd

-- 2010年4月に日本語訳が出るとの噂。

Sinatra + SQLite3 + Hamlで画像アップロードしてみた。

noreply@blogger.com (yasulab) — Sun, 13 Nov 2011 15:05:00 +0000

最近、Sinatraを使いたい衝動に駆られたので色々とSinatraで遊んでます。とりあえず画像をいじりたい＋データベースを使いたい、ってことで Sinatraでファイルをアップロードさせる方法と SinatraからDataMapperを使うを参考にしながら、Sinatra DB Demo with Images を作ってみました。動作イメージが分かりやすいようにモデルはtwitter-likeにしてます。で、DBの中身が分かりやすいようにtableでサクッと区切って表示したりなどやってます。こんな感じです。jQueryとかCSSとかは使ってないので、見栄えはあまり良くないです。

なんとなく、フォームを使ったPOSTメソッド以外にも、GETメソッドを使ったPostも出来るようにしてみました。何故実装したかは不明。悪い実装例（？）。使い方は、'/create'にアクセスするだけですが、RESTful的にはこういう風なGETの使い方はやっちゃいけないかと思います。

'/create' にアクセスして、

その後、ルートディレクトリに戻ると、こんな感じでちゃんとDBにデータが入っていることが確認出来ます。

ちなみに、データベースの中身をいじってデバッグしたいときなんかは、 Lita というデスクトップアプリケーションが便利でした。こんな感じで編集出来ます。

おまけ程度の情報ですが、EmacsでHamlを使いたいときはHaml-modeが便利かもです。設定はこんな感じで。indent-tabs-mode nilを入れないと、Hamlがカオスな反応をするので注意。

(add-hook 'haml-mode-hook
  '(lambda ()
     (setq indent-tabs-mode nil)
       (define-key haml-mode-map "\C-m" 'newline-and-indent)))

以上、Sinatra DB Demo w/ Imagesの概説でした。参考になれば幸い。
とりあえず今後は、DELETEとPOSTメソッドを実装して、なんちゃってRESTfulを作ってみたいかも。

yasulab/simple-db-demo-with-img - GitHub
https://github.com/yasulab/sinatra-db-demo-with-img

第１回 fluxflex meetup in Tokyoで発表して思ったこととかアレやコレや

noreply@blogger.com (yasulab) — Fri, 04 Nov 2011 09:26:00 +0000

はい、今さらなお話です。勢いで "imasara"というタグを付けてしまったぐらいに今さらなお話です。でも、数百人の前で発表する機会なんてあんまり経験して来なかったので、せっかくなので当日までのアレコレや、言い訳や、その後の後日談などを思い出しながら書いてみます。

約１ヶ月前、第１回 fluxflex meetup in Tokyo というイベントがありまして、そこで「GitHub Importを使った fluxflex へのデプロイ例」という内容を発表してきました。元々は、一般参加者として参加するつもりでした。だったんですが、Simple Timekeeper という、fluxflex上で動いているサービスが、幸運にも fluxflex の中の人の目に止まったようです。それで、DMで僕の方に発表の誘いが来て、そして、発表に至ったという感じです。

言い訳をさせて下さい。僕はアイデアが思いついたら可能な限り早く作るのが好きな人間です。だって良いアイデアを思いついたら、早く動いてる姿が見たいじゃないですか。Simple Timekeeper も例に漏れず５時間ぐらいで作ったサービスです。なので、中身を見ると「body bgcolor="black"」とか書いてあるぐらいのウ◯コードとなっています。しかしまぁ、「まずは発表資料を用意するのが優先だ」と考え、というか今さら書き直す時間もなく、気力も無く、クソ◯スのまま発表に至りました。本当はもっとキレイに書けるよ！だからそんな目で見ないで！

ところで、僕はずっと fluxflex のことを「auto-scaling」を推している PaaS だと思っていましたが、いつの間にか軽量なウェブサービス開発者をターゲットにした PaaS にPivot（？）したみたいですね。僕の思い込みかもしれないので、実際のところは今度会った時にでも聞こうかなーと思っていますが、少なくとも僕からしてみたら最高のpivotです。というのも、僕は軽量なウェブサービスをたくさん作ってたくさん失敗するタイプの人間なので、もうアレですね。最高です。「ずっとこの路線で行ってくれたら‥」と密かに願っています。「Pivotしたのかなー」と思った背景は色々とありますが、詳細は後日 Okinawa.rb で発表した fluxflex meetup survey にて。~~地域Rubyの会で最もRubyの話をしない人間とは僕のことです。~~

僕はシンプルなウェブサービスやアプリがもっともっと増えたら良いなーと思っています。それには、僕がZen信者だからとか、そもそも個人でスゴいウェブサービスを作る技術が無いからとか、色々な理由があります。ですが、最大の理由は、スゴいモノじゃなくても、数万ラインのモノじゃなくても、多くのユーザに使ってもらえるイイモノはたくさんあると信じているからです。ホイッスル on Androidを実際に作ってみて、「あ、やっぱいけるじゃん」と確信しました。

でも、僕自身そうでしたが、頭ではそう思っていても、実際にそうするのは、若干の度胸が必要です。だって、まず、失敗することが多い。作っても誰も見てくれないとかザラです。公に自分の失敗を晒すのは、やはり若干の覚悟が必要です。

しかも、ウ◯コードになりやすい。まぁこれは僕だけの特別な傾向かもしれませんが、少なくとも僕ぐらいのスキルでは、ウ◯コード量産機になる度胸が必要だと思います。ウン◯ードでしかも誰も使ってくれないときなんかは、もう完全に涙目ですよ。

「もっとキレイに書け」とか「汚いコードを書くヤツは（ry」みたいな風潮を僕は感じます。企業で、大勢で書くモノを作るときは全く持ってその通りだと思います。でも、個人や小さいチームでモノを作るとき、本当にそうなんでしょうか。あのGoogleですら初期バージョンのコードは酷いモノだったそうです。それなら、凡人の僕が書くコードなんて酷くて当たり前な気がします。なんていうんですかね、フリーミアムが「Freeと1円以上のときは法則が違う」と主張したように、個人や少人数でモノを作るときと、企業や大勢でモノを作るときの法則は違うような気がします。気がするだけです。証拠も何もありません。

「証拠が無いなら作っちゃおう」。そういうのは実験して確かめればいいですよね。ということで、週末ものづくり講座ってのを実際に開いてみました。どうなんですかね。モノ作りと同じで、一般的には失敗する確率の方が多そうです。ですがまぁ、そこらへん色々試してみて、結果を見てみて、その後じっくり考えることにします。

まさか fluxflex の話からモノ作りの話に飛ぶとは僕自身思いませんでしたが、とりあえずここらへんに着地して終わりにしようと思います。

~~そんじゃーn(ry~~

追記：

最近「自分のアタマで考えよう」という本を読んだので、久々に自分のアタマで考えて文章にしてみたんですが、本書でも述べられているように、最初はろくなもんにならないっすね。コード書くのに失敗したり文章書くのに失敗したり、失敗から離れられない今日この頃です。でもまぁ、「失敗しろ」って主張しているようなもんなので、主張してる僕が失敗しないことには始まらないっすね。

Okinawa.rbの勉強会が始まりました。

noreply@blogger.com (yasulab) — Sat, 29 Oct 2011 08:05:00 +0000

最近滅多に書かないブログですが、「ブログを書くまでが勉強会です」というtweetを目にしたので、今日は久々にブログを書いてみる事にします。

2011年の８月頃に立ち上がった Okinawa.rb ですが、段々とメンバーも集まり、また、株式会社レキサスさんから会場を貸して頂けたこともあって、ようやく勉強会が開催出来るようになりました。

第１回勉強会では、Ruby on Rails 3 Tutorialの第１章と第２章を要約したものを扱い、第２回勉強会では、テニスのエントリシステムを題材にしたRailsユースケースなどについて扱いました。勉強会で扱った資料については、Okinawa.rbの公式HP で公開しているので、もしよければご参照下さい。

で、次回の第３回Okinawa.rb勉強会は？ってことについてですが、次回は初心者向けチュートリアル＆玄人向けハッカソンを並行して行おうと考えています。つまり、Ruby/Railsに慣れていない方には、講師と共にRubyMonkや過去の勉強会の資料を使ってRuby/Railsに慣れて頂き、Ruby/Railsに慣れている方には、思うがままに何か作ったり勉強したり議論したり、といった感じの勉強会にする予定です。

というのも、初心者向けにすると玄人な人が来なくなるし、玄人向けにすると初心者な人が来なくなってしまうので、「じゃあ並行してやっちゃえばいいじゃん？」的な考えに基づいています。ここらへんは Try & Error で色々実験してみるしかないっすね。

ということで、第３回 Okinawa.rb 勉強会は、11月５日（土）に開催されるので、もしご都合の合う方いましたら是非是非ご参加を。

第３回 Okinawa.rb 勉強会
http://atnd.org/events/21510

追記：
最近、Okinawa.rbのFacebook Groupが盛り上がっています。
Ruby/Railsだけでなく、GitやStart upの話も投稿されます（主に僕が）。
もしかしたら沖縄に在住していない人でも楽しめるかも。
よければこっちの方も是非是非覗いてみて下さい。

Okinawa.rb - Facebook Group
http://www.facebook.com/groups/194735460599272/

追記の追記：
勉強会の結果はこちらから。

Okinawa.rb公式HP
http://qwik.jp/okinawarb/

yasulab

Nico Rank Inverter

noreply@blogger.com (yasulab) — Thu, 13 Oct 2011 16:28:00 +0000

１ヶ月前ぐらいにtwitterでもつぶやきましたが、Gitoriousをサーバに設置している途中で、「ちょっと息抜きに何か作ろうかなー」と妄想に耽っていたら、気付いたらこんなのが出来上がっていました。

もしよければどうぞ。

Description

Chrome Web Store
https://chrome.google.com/webstore/detail/bkmhgfacjlbplglbimpdbbeligolfadl

ソースコード
https://github.com/yasulab/nico-rank-inverter

アイデアソン（Ideathon）

noreply@blogger.com (yasulab) — Wed, 05 Oct 2011 07:46:00 +0000

需要あるのかどうか全く分からないんですが、衝動的にこんなFacebook Group作ってみました。もし興味あればちょっと覗いてみて下さい。

http://www.facebook.com/groups/227001314022802/

紹介文全文：

時々変なIdeaを思いつくんだけど、すぐその場で書き出さないと忘れる。ただ、誰とも共有しないと、Ideaを見返さなくなる。短時間で頑張ってIdeaを捻り出すよりは、中長期的にIdeaを垂れ流していきたい、そんなオープンソースコミュニティです。

本当に大切なIdeaは自分の心の内に閉まっておいて、「もう自分で実装することはないなー」というIdeaはポイッと投げて下さい。もしかしたら誰かが拾ってくれるかもしれません。

しょぼいモノから壮大なモノまで、幅広くIdeaを出す、はず。

eXtreme HAGO 2 LT 大会アレコレ

noreply@blogger.com (yasulab) — Tue, 30 Aug 2011 11:04:00 +0000

先週末に eXtreme HAGO 2 LT 大会 ( #xHago2 )に参加したので、そのときにやったことや得た情報、感想などのアレコレを忘れないうちにまとめておきます。

やったこと：

xHagoのロゴを作成しました。
発表しました。というかOkinawa.rbの宣伝を思う存分やってきました。
今週末の土曜日(9/3)はOJAG + Okinawa.rbの勉強会があります。是非！
タイムキープ用のWebサービスを作りました。わりと好評だった模様。
ただ、MacBook以外のディスプレイだとレイアウトが壊れるかも。

知ったこと：

琉球大学ではMacを強制的に買わされ＆Emacs+tcshを使わされるらしい。
次回沖縄iPhone勉強会でjQuery Mobileの話をするんだとか。面白そう！
ABC2011sのデザイントラックでも耳にしましたが、まだまだ不具合が多いっぽい。
学生さん達がやる気一杯！ASAPで海外留学or就労して欲しいなー。

気になること：

Tythonの行く末。
自作PCの行く末。
ショートコーダーの末路。

次回は2月頃にあるそうです。参加出来るかどうかは分からないけれども、またフラっと寄れたらいいなーって考えています。

Android Bazaar and Conference 2011 Survey: 10年に１度の変革期を遊びたおすために

noreply@blogger.com (yasulab) — Sun, 28 Aug 2011 06:23:00 +0000

先日、琉球大学で開催された eXtreme HAGO 2 LT 大会 ( #xhago2 )に参加し、表題の内容を発表してきました。内容は、以前登壇したABC2011sというカンファレンスで見聞きしたことに、僕個人の意見を加えたものとなっています。

発表動画：Xhago2nd, Ustream

※始めの部分は録画出来てないようです。ネタを仕込んだのに...残念(´・ω・｀) スライドと当日の反応からネタの雰囲気を感じ取って下さい。

スライド：

Abc2011s survey

View more presentations from Yohei Yasukawa

当日の反応：eXtreme HAGO 2 LT 大会第2セッション, togetter

おまけ：もしもエンジニアが本気でダイエットしたら

※夜の部でネタ発表をしてきました。反応が良かったようなので、後日、目標まで到達したらブログ記事でまとめるつもりです。

Dropbox as a Git

noreply@blogger.com (yasulab) — Thu, 25 Aug 2011 10:02:00 +0000

GitHub.comはとても便利なサービスで、僕もしょっちゅうお世話になっていますが、Private Repositoryを作る時は課金しないとダメなので、ちょっと面倒ですよね。最低でも7$/month支払う必要があるし、Collaboratorの数も制限されてしまいます。

そこで、DropboxをGitとして使えないかなーって思って調べてみたら、なんか普通に使えそうです。

Using Dropbox as a Git
http://tumblr.intranation.com/post/766290743/using-dropbox-git-repository

早速試してみましょう。Mac OS Xでしか試してないので、他のOSでは多分ディレクトリを指定する部分をちょっと修正する必要があるかもです。

0. DropboxとGitをインストール
※Dropboxのディレクトリは"~/Dropbox"に置いてあることとします。

1. レポジトリ用のフォルダを作成

mkdir -p ~/Dropbox/repos/test.git

2. Gitレポジトリを作成

cd ~/Dropbox/repos/test.git
git --bare init

3. テストプロジェクトと.gitを作成

mkdir ~/hoge
cd ~/hoge
echo "hogehoge" > README
git init
git add .
git commit -m "Dropbox as a Git test"

※Gitの性質上、"touch README"だとダメな気がする。

4. Git remoteでDropbox内のレポジトリを登録してpush

git remote add dropbox file://$HOME/Dropbox/repos/test.git
git push dropbox master

5. git clone をしてみる。

mkdir ~/foo
cd ~/foo
git clone -o dropbox file://$HOME/Dropbox/repos/test.git

6. READMEが入ってる"test"フォルダがちゃんとcloneできてたら成功。

とまぁ、こんな感じでDropboxをレポジトリとして使うことができそうです。あとは"repos"フォルダを他の人と共有すれば良いのかな？もしかしたら色々と問題が出てくるかもしれないけれど、問題を発見したら随時追記していこうと思います。

書評：大震災の後で人生について語るということ

noreply@blogger.com (yasulab) — Wed, 24 Aug 2011 07:29:00 +0000

国家のリスクと個人のリスクを切り離すための生き方について説かれた本です。「面白いよ」と友人に勧められたので、初めて橘玲さんの本を手にし、読み始めたのですが、とてもタメになりそうな内容が多く書かれていました。今後の生き方の参考になりそうです。

経済学の用語がちりばめられているので、経済学に慣れていない方にはちょっと取っ付きにくい部分もありますが、できれば、エンジニアやデザイナーなどの手に職を持っている方々に読んでもらいたい一品です。

Far Beyond The Computers

noreply@blogger.com (yasulab) — Fri, 19 Aug 2011 17:07:00 +0000

早稲田大学情報理工学科オリエンテーション2011
Department of Computer Science, Waseda University
（情報理工学科プロモーションビデオ：CSPV）

Credit
- Camera Crew: Akihiro Shimoda
- Music: Akihiro Hayashi
- Director: Yoichi Matsuyama
- Produce: Waseda CS Assistants

中の人曰く、

CSPVは基本的にポストプロダクションはPremiere+After Effectsであっさり塩味です．もっとも，ツールというよりは，Tシャツのデザインや教授の説得作戦，照明や音声など，プレプロダクションと撮影時の素材に割とこだわったものでした．

だそうです。

# あれ、僕の知ってるPremiereと違う...

航空券検索エンジンなどのプロジェクトでデザイナの人達と一緒に仕事するようになってから、僕はデザインにこだわる人がとても好きになりましたし、僕自身そういう人間になろうと日々精進に励んでます。留学中にデザインの授業取ったのは、腕のあるデザイナの人達に感化されたからです。彼らと一緒に何かモノを作っていなければ、きっと留学中にデザインの勉強なんてしなかったでしょう。

複雑で難しい問題を解ければ残りはどうでもいい、という考え方は間違っていると思っています。良いモノを作るためには、考え抜かれた「見せ方」もとても大事な要素だと考えています。

OJAG workshop@Naha Vol.10

noreply@blogger.com (yasulab) — Fri, 19 Aug 2011 08:56:00 +0000

明日はAndroidの会＠沖縄のworkshop( #ojagnaha0820 )の日ですよ。今回はARカメラとか #abc2011s のSurveyとかBlenderな話が聞けるそうですよ。詳細はコチラから。

ちなみに、今回は僕が代理で会を運営することになってます。もし何か分からないことがあれば yasulab@gmail.com か @yasulab までご連絡下さい。ではでは、皆さんの参加をお待ちしています。

# ところで、上記の写真はOISTで撮ったやつです。OISTってリゾート地にあるんですね。近くに運動場とかゴルフ場とかあるし、見ての通り景観も良い感じ。OISTに所属している研究者の７割は海外から来た人で、しかもアジア系ではなく、ヨーロッパ系の人がいっぱい集まっている模様。最初に話した台湾人の研究者の方も中々気さくでナイスな方だったし、なんというか、かなり面白そうな研究機関の匂いがしました。来年から開学して、大学院生（博士課程のみ）を募集するそうです。

Okinawa.rbを立ち上げました。

noreply@blogger.com (yasulab) — Thu, 18 Aug 2011 09:35:00 +0000

沖縄に来てから早くも３ヶ月弱経ってしまいましたが、沖縄って中々住み良いところですよね。海を見ながらプログラミング出来るし、風も心地良いし。でもRubyとかRailsとかが流行ると、もっと住み良いところになりそうですよね。

ということで、Okinawa.rbを立ち上げました。

「沖縄でRuby/RailsといったらOkinawa.rb」と言われるぐらい有名になって、いずれはMatzさんとか召喚出来たら面白そうですね。あるいは、Ruby/Railsを使って沖縄でちょっとしたノマド生活を送りたい人達の足がかりになったらいいなー、と妄想しています。

以下、Okinawa.rbの生息地域です。ご興味あれば是非覗いてみてください。

公式サイト: Okinawa.rb
Google Group(ML): Okinawa.rb
Facebook Group: Okinawa.rb
Twitter Tag: #okinawarb

IRCnet:
Channel: #Okinawa.rb
Server: chat.freenode.net or irc.freenode.net
Port No.: 6665, 6666, 6667
Char Code: UTF-8

また、暫定ではありますが、９月３日、沖縄のIT津梁パークにて初回勉強会を開く予定です。詳細はMLで後日投稿します。もしご都合が合う方は、是非ご参加して頂けると嬉しいです。

よろしくお願いします。

追記：
沖縄に移住するRuby/Railsユーザはそこまでいないかもしれませんが、沖縄に観光などで訪れるRuby/Railsユーザは結構いるんじゃないかと思います。もし沖縄に訪れる機会がありましたら、Okinawa.rbにちょっと顔を出して頂けたら幸いです。

書評：Agile Web Development with Rails (4e)

noreply@blogger.com (yasulab) — Tue, 16 Aug 2011 12:09:00 +0000

三部構成になっていて、始めにインストールやMVCの概念を軽く説明し、次に、Depotというオンラインストアを作りながらRailsの使い方を丁寧に解説している。最後に、Depotを例にしながらRailsの仕組み（e.g. MVCの内部の振る舞い、Caching）と、Pluginsの紹介をして終わる。

RoR3 Tutorialという本では、Herokuやrspecなどの有名どころのツールを使った開発方法を説明しているが、本書では、FixtureやScaffoldなどのデフォルトで備わっている機能を使った開発方法の説明に専念している。

個人的には、洋書ではこのようなサンプルを使った解説が流行っていて、和書では、レシピブック系（e.g. Rails 3 レシピブック、 Ruby on Rails 3 アプリケーションプログラミング）が流行っているような気がするので、うまく組み合わせて勉強すると効率的にRails 3を学べるような気がします。

OAuth on Simple Twitter Bot (2)

noreply@blogger.com (yasulab) — Mon, 15 Aug 2011 10:20:00 +0000

ちょっと @yasulabot というネタbotをつくるためだけに、SimpleTwitterBotを弄り直しました。基本的にはREADMEに書かれている通りにregister_pin.pyを実行すれば、OAuth周りの設定は勝手にやってくれるはずですが、個人的につまずいたポイントをちょろっとリストにしてみます。

- 1. botのtwitterアカウントでログインしたブラウザで、OAuthに登録する事。ChromeならCtrl+Shift+Nで開いたブラウザでbotアカウントにログインして、OAuthに登録すると楽。

- 2. デフォルトのAPIのpermissionは"Read only"なので、APIを通してtweetとかdeleteとかしたいならOAuthの設定画面から、Permissionを"Read & Write"に変更すること。

- 3. たぶん、Windowsだとうまく動かない（Issue 1）。Windows非対応。

基本的にこれらの点に注意して、あとはREADME通りにやれば、自作BotがGAE上で動くような気がします。

README（引用）：


This bot runs in the following ways.



1. Search tweets using 'search_term' in Twitter.



2. Re-tweet the tweets.



In this example, 'search_term' is 'Cafe Miyama',

and you can see how it behaves by checking the following account.



http://twitter.com/cafemiyamabot





HOW TO SETUP:



1. Register your OAuth client on Twitter

URL: http://twitter.com/oauth_clients

NOTE: You MUST change permission settings to "Read & Write" if you wanna update via API.

      The default is "Read Only".



2. Run 'python register_pin.py' and

   use CONSUMER_KEY and CONSUMER_SECRET you got from the registeration.

NOTE: Make sure you are now signing in Twitter as your Bot account when visiting a given URL.



3. Change setting variables (CONSUMER_KEY and CONSUMER_SECRET) in main.py to the given ones.



4. Run Google App Engine dev_server and visit the following URL

URL: http://localhost:8080/cron/update

* If you finish all of your setting, set 'debug_flag' in main.py off.



5. Done!



Enjoy developing your own twitter bot!



YasuLab

yasulab@gmail.com

参考：OAuth on Simple Twitter Bot

SimpleTimeKeeper

noreply@blogger.com (yasulab) — Thu, 11 Aug 2011 16:23:00 +0000

I created a simple time keeper that helps you timekeeping. It can be used for presentations and lightning talks. No software needs to be installed; just visit the website below :)

http://timekeeper.fluxflex.com/

諸事情で今月の #ojag Workshopの仕切りをやる事になったので、当日必要になるであろうタイムキーパーをサクッと作ってみました。よければ使ってあげてください。

Django Tutorial's app (poll) on DjangoZoom

noreply@blogger.com (yasulab) — Tue, 09 Aug 2011 11:54:00 +0000

Railsに夢中で最近Djangoを放置プレイしていましたが、諸事情でちょっと投票Appを作りたかったので、ずっとpending状態だったDjangoZoomに、Django Tutorialの投票Appを乗っけてみました。以下、その手順。

0. 難癖付けて、DjangoZoomのInvitation Codeを催促＆ゲット。
e.g. "俺いま面白いウェブサービス作ってるんだけど、是非DjangoZoomに乗っけたいです！"

1. Django Tutorialを読んで、投票App (Poll)を作成。

2. GitHubに作った投票Appを乗っける。
e.g. https://github.com/yasulab/poll

3. DjangoZoomのDashboardから"Add a new project"を選択。

4. "Repo"の項目にGit Repoを入力。
e.g. git@github.com:yasulab/poll.git

5. Djangoのversion(1.2.5 or 1.3)を指定。他はそのままでok。そしてdeploy開始。

6. deploy後、左ペインから"Create Superuser"をクリックし、ユーザ登録。

7. Djangoのadminページから登録したユーザでログイン。

8. 無事ログイン出来たら成功！あとはお好きなように。
e.g. サンプルサイト

Railsのherokuもそうですが、あるWeb Frameworkに特化したPaaSは、かなりの完成度ですね。汎用的に使えるDotcloudやFluxflexも十分使いやすいですが、deployまでのステップ数と分かりやすさの点から言うと、制約がある分、特化型のPaaSの方がより使いやすいというのが、個人的な感想です。といっても、最初の一歩が大きいか小さいか程度の問題ですので、将来的には、どこまでログを取れるのかとか、ホストの安定性とかが決め手になるのかもしれないですね。

とにかく、今年はPaaSの時代っぽいですね。個人や小規模のチームにとっては、とても良い年になるんじゃないかと思います。