HWPS!

もう先々週の話であるが今年も RubyKaigi2010 に参加した。一応金曜日から。

体調不良と暑さにより朝起きれずに午前はほとんど飛ばしてしまったのは残念。 いまだに見逃がしたセッションの動画を全部は見てないのだけど少しずつ見ている。

一番感銘を受けたのは Chad Fowler の講演であり 情熱プログラマ は読むべきだろう。

あとは esolang 話、 LT、esm 社のふつうの開発風景とかは必見だったと言えよう。

いろいろあって懇親会とかはまったく参加してないです。

RubyKaigi の間考えていくつか実行していきたいと思ったことを書いておく。

• 集中して仕事をしてなる早で帰る。
• 技術ネタのメモ書く場所を作る。これははてなの日記 を再開させる方向でよいだろう。
• 計画を立てて新しいことを始める。とりあえず新しい Web アプリを書く予定 (Rails3+MongoDB?) と新しい楽器を始める予定はある。
  • サイトは戦国大戦のサイトなんだけど。;)
• github をもう少し使う。

もっと集中して生きたい。そのための計画を作りたい。

ｰｰｰｰ

そして現地のジュンク堂出張所で買った本たち。

• WEB+DB PRESS Vol.58 – 言うまでもなく Rails3 者は必見
• Rubyベストプラクティス -プロフェッショナルによるコードとテクニック – たぶん今年の Ruby 本の中では必見度高いと流し読みした結果感じたので。メタプログラミング Ruby がちやほやされてたけどそっちの前にこれじゃなかろうか。(メタプログラミング普段からしてるせいで大筋ではあまり新しいことがなかったせいかも…? 同僚には読ませたいんだけど。)
• Rubyで作る奇妙なプログラミング言語 ~Esoteric Language~ – esolang の本が出ていたとは知らなかった。体系的に(?)知りたかったので買ってみた。
• 情熱プログラマー ソフトウェア開発者の幸せな生き方 – 今回流し読みした結果買わざるを得なかった本。買ったあとに Chad Fowler の講演を聞いてそれが正しいと確信した。

ワタクシ情報収集のチャンネルが少ないのでもっと効率的に情報収集できるようにしないとな、と思っております。

普段の情報収集などに長く livedoor Reader を使っていたんだけれども、 最近いろいろ Feed 周りの環境を整理する上で、検索機能はフィードリーダー本体にあった方が(一時期流行った)別途 GMail を使ったやり方みたいな外部に依存しているものより良いだろうということで 結局 Google Reader に移行した。

読んでるフィードのリスト自体はLDRでエクスポート/GReaderにインポートでさくっと実行。

問題は設定。 自分の LDR の使い方は

1. 左ペインに未読のあるフィードタイトルを表示
2. j/k で一気に見て気になるやつだけピンを立てて
3. ある程度まとまったらピンを開いて見る(ブックマークとかその他のオペレーションはこの後)

だったので、このように設定。

• 右上「リーダー設定」
  • スクロール トラッキング「全文表示の場合、スクロールして表示されたアイテムを既読にする。」のチェックを確認
  • ナビゲーション パネルの表示「使用するたびにナビゲーション パネルを表示します。」のチェックを確認
• 「登録フィード」以外のナビゲーションパネルを最小化
• 「登録フィード」の設定
  • 未読件数を非表示 (これは趣味の問題だと思う)
  • ドラッグアンドドロップで並び替え (これも。アルファベット順で並んでる必要なし)
  • 更新されたアイテムを表示

さらに設定だけではピンの再現はできなかったので、ピンの動作を再現する UserScript をインストール。

Pin Extension for GReader for Greasemonkey

UserScript だからピンを保存するわけではないけど、その用途には Star を普通に使えばよかろう。

これをメインのブラウザ (Firefox, Chrome) にインストールして、とりあえず前とほぼ同等の環境は作成できた。

キーバインドがいくつか変わってしまったけれども、それをわざわざ LDR 風にするほど LDR に忠誠心を持っていたわけでもないので慣れることにする。:)

• ピンを立てる p → i
• (未読の)次の記事 s → Shift-n Shift-o
• (未読の)前の記事 a → Shift-p Shift-o

なんか 1 ストローク増えてるけれども、勝手に開かなくなったと思えばそんなにひどくなったとは。どうせ前の記事を最後まで Space で読めば勝手に次へ行ってくれるし。

あとは左ペインを記事の新着順にソートができればより近い UI になるけど、必要なさそうに思えたので特に調べたりせず。

「プランニングポーカー」っていうのは、アジャイル方面の見積りグッズ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ でも紹介されてる。

どう使うかっていうと、ある見積もるべきストーリー群がある時に。

1. それがどのようなタスクであるか話し合い
2. 各自がそのタスクが何「ストーリーポイント」であるかを考えて
3. カードを出す
4. 大きくずれてたら、なぜそうしたかなどを聞いたりして調整
5. ポイント確定
6. 全部終わったら今回のスプリント(=今週あるいは半月などの単位)でどのストーリーまでを消化するか予定を決める。

実際にやっていて、このやり方の重要な点はこういうところだと思う。

• 各自が自分で考えた見積ポイントを出す。
• 時間単位でなくストーリーポイントという抽象的単位(あるタスクに対する相対的見積り)である。やる度に自分のチームはこの見積り方法で週何ポイント消化できる、という精度が上がっていく。実時間でいちいち見積らないところが重要。
• 「大きい見積りは精度が低い」というのが表現されている。ストーリーポイントは基本的にはフィボナッチ数で、13の次は 20, 40, 100。ストーリーを分割する目安にもなる。

ちゃんとしたやり方とか考え方は最初に挙げた「見積り本」に載ってるのでそちらを読むべし。↑間違ってるかもしれないのと、バックログとか優先度の考え方とか前提になることがいろいろ多い。

自分のプロジェクトではカード買うまでは手で紙に書いてやってたんだけど、カード買ったらずいぶん手軽になった気がする。ま、さらに慣れるとプランニングじゃんけんになるらしい けども。

んで、カード購入方法。Mountain Goat Software のサイトから、Planning Poker をカートに入れて、英語で住所とクレジットカード番号を入れて取り寄せるだけである。実際のところ普通に1週間もかからずさっくり届く。送料は高い。1セット$2.50 で10セット注文したけれども、Shipping: $39.85 とな。あと例によって JCB とか使えないから注意。

注文するなら円高のいまのうちですよ(適当)。

あと余ってるんで近いひとで試してみたいという方は連絡ください。w

Python の初歩的小ネタ。

Python では、あるリストの逆順を得るには、破壊的な reverse() メソッドを用いるか、逆順のイテレータを得るreversed()関数がある。

somelist.reverse() # somelist 自体が変更される
reversed(somelist) # somelist を逆順に辿るイテレータを得る

たいていはこの2つで足りるけども、たまーに somelist の逆順のリストが欲しいことがある。その場合は、(まず)つぎの2つの方法がある。

list(reversed(somelist)) 
# あるいは
somelist[::-1]

後者がなんとなくテクニカルっぽいけども、普通に考えて list(reversed(...)) でいいんじゃなかろうか(速度もそんな変わらん)。

もちろん、reversed() で足りるならその方が良いだろう。(リストのコピーしないだろうから)

tiarra の Auto::Random に食わせるソースを出力するためのスクリプトの個人的メモ。俗に言うすももせいゆう機能(わからんて)。

例によって声優相性診断所さんのリストを使わせてもらってます。

#!/usr/local/bin/ruby
# -*- coding: UTF-8 -*- 
$KCODE = 'u'

require 'open-uri'
require 'nkf'
require 'uri'

uri = 'http://' + %w(tomoch s28 xrea com).join('.') + 'ime.cgi' # 本当はちゃんと書いてます.
out = 'va.txt'

vas = open(uri){|f| f.readlines }

lines = vas.collect {|va|
  name = va.gsub(/\<.*?\>/,'').split[1]
  if name
    wikilink = 'http://ja.wikipedia.org/wiki/' + URI.encode(name)
    "#{name}: #{wikilink}"
  else
    nil
  end
}.compact
open(out, 'w'){|f|
  f.puts lines.join("\n")
}

前は wget で一発だったんだけど Wikipedia のリンクが必要になったのでごにょごにょ。

Tags: 声優

gem で入れた nicovideo プラグイン を動画ダウンロード用のスクリプトで使っていたけど、 ニコニコ動画(9)になって動作しなくなっていたのでとりあえずダウンロードだけ動くようにした。(XPath 部分直しただけ)

require 'nicovideo'

module Nicovideo
  class VideoPage < Page
    def parse(page)
      # title
      @title = page.title.toutf8.sub(/#{BASE_TITLE1}$/ou, '')

      # tags
      div = page.parser.search("div#video_tags")
      @tags = div.to_html.scan(/<a href=\"tag\/[\w\%]+?\">(.+?)<\/a>/ou).inject([]) {|arr, v|
        puts_debug v[0]
        arr << v[0]
      }

      # published_at
      str = page.search("div[@id='WATCHHEADER']//p[@class='font12']/strong")[0].inner_text
      tm = str.scan(/\d+/)
      @published_at = Time.mktime(*tm)
    end
  end
end

ダウンロード以外はやっぱり動かないので注意。マイリスト回りのコードにも影響があるので commit しにくいなー……。

Tags: ruby, ニコニコ動画

開発用に英語キーボードな MacBook に Bootcamp で Windows 7 入れてみたわけだけど、 Ctrl と CAPS は当然として、 さりげなく Alt と Command(Windows) キーが普段と違ってしまい開発環境としては如何ともしがたく。

Alt キーはスペースバーの横じゃないとダメなのよねー。

そんなわけでキーバインドの変更が本当に必要になった。

今まで Vista な開発機には XKeymacs 使ってたけど、動作が今一つ自分の理想ではなかったのでそろそろ違うのを選びたかったところ。

というわけで 2000/XP の頃に「窓使いの憂鬱」を使ってたので後継である 「のどか」 をチョイス。 Vista の頃の mayu 後継はドライバ署名でいろいろあった気がしてたけど、最近署名が付いたというのがやはり大きい。

Windows 7 で前述のAlt-Commandキーの交換もできたのを確認して、さくっと PayPal で送金。

現状のほぼ最小設定はこんな感じ。

include "104.nodoka"
include "default.nodoka"

mod alt += LeftWindows
mod windows -= LeftWindows
key *LeftWindows = *LeftAlt

mod windows += LeftAlt
mod alt -= LeftAlt
key *LeftAlt = *LeftWindows

返事が見事に GMail の SPAM 箱に落ちてて正式版の取得が遅れたのは御愛嬌。:)

しかしこれでようやっと Windows7 上での開発のスタート地点に立ったってところだなー。まだ東方星蓮船専用機だし…

Tags: nodoka

久々に Rails アプリいじる。 Rails の scaffold で /adminonly/users みたいなのを定義しようとしたがまじめにやるとファイルの移動+定義変更とか面倒。デフォルトのルールもあるので prefix だけ付けても仕方ない。

……と思ったところでデフォルトルール( /controller/action/id ってやつね)を切ればいいことに気づいた。風呂リフレッシュ大事だわあ。

ActionController::Routing::Routes.draw do |map|
  map.resources :users, :path_prefix => '/adminonly'
end 

どうせ今は ActiveResource 型のルーティングがメインなのだからデフォルトルール的なものは個別に定義すべきであろう。(と言い聞かせる)

開発手法に興味があるなら、まずこの2冊でアジャイル開発に踏み出すのがよかろう。

• アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング
• アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

というか一緒に仕事する人は読んでください > 弊社の人とか。 こういう仕事のやり方はどうだい? というコンサルティングをしてくれる本だと思えば OK だ。

とりあえず「できるところから始める」でいいと思うけど、効率化していくとほとんどのことは 既存のプラクティスに近付いて行くんだよな。プラクティスとして紹介されているだけのことはあるのだ。

いろいろ自分の仕事でやってみて改善されたと思うことは、

• 本質的でない仕事が減った(チケットでタスク管理とか実際面倒でね?)
  • 変化に強くなった: コンピュータでやるより紙のほうが早いことって結構あるんだ
• コミュニケーションが飛躍的に増えた: スタンドアップミーティング、ペアプログラミング、ふりかえり、普段の井戸端会議 etc.etc…
• 楽しく仕事をするのを心がけられるようになった

うちはできてる! と思う人は根本的にそもそも近いんじゃないかと思う。それでも部分的にでも得るものはあるんじゃないかしらん。

褒めすぎたので困ったことも書く。

• チームの理解がないと効果半減…: チームの人の理解は容易なはずだ
• 顧客の理解がないと効果半減…: むずかしい(特に日本では?)
• 壁が必要: 意外に難しい。でかい磁石の付くホワイトボードが最適だが。
• ネットワーク越しは難しい: 無理。顧客も近くに置きたいのにチームも外はなかなか難しい。規模と個人の技量の問題ではあるがー。
• 少しずつ導入してるので慣れるに時間がかかってる。「メンター」であるような精通したコンサルとかいないからねー。

個人的には Trac ステを目標にしてみてはどうか。別に Trac 面倒だと思うけど嫌いなわけじゃないし、 実際全部捨ててはいないんだけども(BTS と Wiki は必要)。

そんなことを作業待ちの間に本読みながら考えておりましたとさ。

Tags: アジャイル

FreeBSD の ports から入れた multimedia/ffmpeg の出力の mp3 がひどいことになっていてなんでだろう、と思っていたがバージョンのせいだった模様。のメモ。

Continue Reading »

Tags: freebsd