Shibuya.Trac 第10回勉強会に行ってきた

技術 Trac

これが年開けてからの初日記ですね！
あけましておめでとうございます！今年もよろしく！


2月に入ってあけましてもねえだろうとか、6ヶ月近く日記を放置していた事はスルーして。
Trac使ってるエンジニアの端くれとしてShibuya.Trac 第10回の勉強会に行ってきました。
内容・感想を簡単に箇条書き。誤り等のご指摘歓迎。

入場〜開始まで
  • 諸事情で早く着きすぎたので1FのProntで時間潰し
    • 相変わらずいい値段
  • 時間になったので集合場所に移動。誰もいなくて不安な気持ちに
  • すぐにスタッフの方が来られて会場まで誘導
  • 席位置は自由。プロジェクタが2面あったので両方見やすそうな席を取る
  • 司会(riskさん)からデブサミの関係で少々遅れる事が通知。その後周りの方とのご歓談タイム
  • 社会人らしく全員名刺交換。名刺入れすら持たずにそのまま交換する俺の微妙社会人ぶり
  • riskさんからShibuya.Tracの簡単なプレゼン。デブサミで使った物らしい
    • 「渋谷でやらない」
    • 「Tracの話をしない」えー。
  • 神速さん紹介
    • マスコットキャラらしい
  • デブサミ組順次到着。発表者の都合でOかもとさんから開始
「とある券売機の改善記録」- Oかもと さん
  • TracLightning開発者
  • 自分はゲーオタじゃないネタ
    • なぜオタネタを大量に連想して一人テンションが上がる
    • そもそもTDiary使ってる人に普通の人なんて
  • 新規プロジェクト名「Kanon」
    • 突っ込み待ちとしか思えない俺は心が汚れている
    • 検索衝突問題が浮上しそうと要らぬ心配
  • デモOSとしてDebian GNU/kFreeBSD
    • 「マイナーだから問題が起きたらOSのせいに出来る」
      • 突っ込む余地すら無し
  • Scrum用にストーリー・タスクという分け方でチケット管理が可能
  • バックログやバーンダウン等の機能も完備
  • ウォーターフォール用に「KanonNaiagara」も用意
    • これはいいネーミング
  • これらの管理用に、MS ProjectのようなLook&Feelの「KanonProject」も用意
    • 「スーツを説得するためのツール」
    • ガントチャート操作の見た目と、GUI・実タスク間の連携による説得力は凄い。これは本当に上司に対する導入への説得が楽になるんじゃないか
    • ガントチャート操作との連携は、職場で強く要求されていたものの一つであるため非常に興味あり
  • インストールも容易に
    • マルチOS対応
    • TracLightningは非Windows環境には非対応だったため、Debian使用者としてはとても嬉しい
  • 協力者募集
    • 有償サポートも検討中
      • 「金のやりとり前提の方が本気になる」というのはその通りだと思う
    • いわゆる「フリーウェアに対するユーザの質問題」に悩まされてるような空気を感じた
      • ユーザの過剰サポート要求とか、オープンソースでもよくある「お客さん意識」問題は切実みたい
      • 自分もそうなりかねない面はある。自戒
  • 券売機はどこにいったのか
「ぼくとRedmineとBacklogsプラグイン。ときどきアジャイル。」- こくぼ さん
  • 先日生まれた赤ちゃんがバックのスライド
    • 赤ちゃんかわいー
    • でも明度が低くて文字が…
      • 白抜き文字とかの方がよかったかも
  • Backlogsプラグインを使ったRedmineでの開発
  • タスクボード
    • Scrumとあまり縁のない俺がもっとも興味を持った機能
    • 残存タスク(チケット)のステータス視認性を上げる事で、いわゆる「放置チケット」への対策となるのは目から鱗
      • 実際、タスクボードだとかなり各ユーザの入力率が上がるみたい
    • マイルストーン毎に切ればウォーターフォールにも使えそう
    • 縦軸をユーザ、横軸をチケットステータスにすればマネージャ垂涎のアイテムになるんじゃないか
    • 「かんばん方式」への応用も出来そう
    • Tracに移植希望と言ったら「言い出しっぺの法則」で返されそう。でも欲しい…
  • Scrumなのでストーリー・タスクとしての管理機能を実装
  • 必要な機能は改造して実装
  • 予実管理など、あまりScrum的ではない部分も実装している
    • 「形にこだわりすぎず、柔軟に対応する」という姿勢は重要
  • ScrumのNG五箇条とTips五箇条
    • 「ツールを振り回しても振り回されるな」
    • 油断すると手段と目的が入れ替わりがちなのはよくある
LT 「TracユーザからみたMantis」- ゆかわ さん
  • Mantisの紹介と使用感
  • PHPベース
  • プログラム開発のバグ管理に特化している
    • ステータスが豊富
    • まさにBTSという感じ
  • 普通に使用するには入力情報が多すぎるかも
  • 「小さいプロジェクトではチケットステータスはそれ程の種類を使わない」
LT 「Enterprise Redmine」 - ふじはら さん
  • 社内でのRedmine導入事例
  • 大規模になると途端に管理問題が浮上してくる話とその対策
  • 色々身につまされる話
    • 管理コスト削減を前提とした設計は大規模システム運用には絶対必須になる
  • おまけとして「結婚式をタスクとして切り出したらチケット140枚」に笑った
    • 確かにプロジェクトかも
    • 「結婚式のためのタスク管理システム」は意外と商売のネタになるんじゃないか
LT 「モテBTS 〜 Backlog 〜」 - ikikko さん
  • Web開発においてデザイナーもBTSに巻き込もうという話
  • UIの改良やチャット機能等でPC慣れしていないユーザへの対策
    • エンジニアとスーツの知識共有問題としても活用できそう
  • 「デザイナーは美人が多い」→「デザイナーを巻き込めばモテに！」
    • そもそも男性率98%の職場では以下略
LT 「チケット管理システムの戦いはまだ始まったばかり」 - 大澤 さん
  • タスク管理ツール大決戦
  • 気付いた点を決戦Wikiに書いて欲しいとのこと
    • 「これが足りない、あれが欲しい」という内容ならいくらでも書けそう
    • 「自分の使うツールはプラスが見えやすい」との事だが、隣の芝生が青く見える事も多いような
      • Redmineの多プロジェクトのユーザ管理を一元化出来る事がTracユーザから見ると超うらやましい とか
飛び入りLT 川口 さん
  • チケットシステムにおける優先度と終了の重要性について


あっという間の3時間でした。
次回も是非参加したいところ。

StarCraft2はもっとプレイされるべき/Brutal Tips

ゲーム

最強の合法麻薬として名高いStarCraft2ですが、周りにRTSをプレイする奴がいないという罠が。
こんなに面白いのになあ。


なにそれ？という方はpikoさんの動画でも参考に。
D


俺は先日やっとキャンペーンをコンプリート。
playgg配信でやたらKerriganアイコン(難易度Brutal全シナリオクリアで解除)持ってる人が多かったので、うらやましくなってBrutalにチャレンジしてましたが、さすがは最高ランク、まさにM属性向けというレベル。
特に最初のほうのシナリオZERO HOURと最終シナリオAll-inがきつかった。
ZERO HOURは兵種が基本ユニットしかいないのに向こうはBaneまで出して押してくるという状況。
「相手Hatを4つ割れ」という実績なんてBrutalだと考えたくもないレベルです。
All-inに至ってはZergのZergたる理由について、その圧倒的な軍量で身をもって教えられます。
「グラボそろそろ限界だぜ」なんて警告メッセージあるのね…。


ちなみにKerriganアイコンで対人戦やってたら、対戦相手の外人さんにも「おい、All-inの攻略教えてくれ」と言われました。
みんな苦労してるんだなあ。


各シナリオ攻略は色々な方が書いてたり動画があったりするので詳細は省いて簡単なアドバイスでも。

Research

ProtossはScienceVesselとTechReactorが鉄板。この二つが無いと難易度がハネ上がります。残りは好みで問題無さそう。
悩ましいのはAutomated RefineryとCC Reactorのトレード。CC ReactorはAll-inのような使い捨てでSCV使うステージでも有用。Refineryは最大supの節約と、離れた場所でもCC設置・SCV配置無しでガス収集が可能というのが美味しい。
Zergは必須と思われるのがFortified Bunkerであとはお好きな方を。
ちなみにMicro必須で必要操作量がハネ上がるHive Mind Emulatorはあまり人気がないそうですが、コレ滅茶苦茶強いです。しかも楽しい。
これで仲間にしたZergはSupを消費しないため、Sup上限を超えて軍を強化できるというのが大きい。Zergが出てくるステージはこれを前線に配置するだけで笑いが止まりません。
シナリオ"SHATTER THE SKY"でUltralisk8体+BroodLord14体、大量のMuta/Hydra/Roachで相手のZerg陣地を粉砕する様は最高でした。
正直All-in vs Airはこれ無しでクリア出来る気がしません。最後は画面にZergユニットしか残ってなかったし。

大量のZergさんに守られるArtifactの図。Horner船長も呆れ気味


ちなみに味方にしたZergのairユニットはMedicでは回復できません。Medivacならair/ground関係なくOK。

Armory

必須はSCV二倍修理とBunker関連。この二つが無いとかなりキツくなります。次点でMissile Turret強化かな。
あとは好みで。シナリオに対Zergが多いのでAirを重点的に強化するといいかも。
ぶっちゃけ最後の方はめんどくさくなってみんなMass Banshee+Viking(+ScienceVessel)で攻略してたような気がします。SVマジImba。


まあこんな偉そうな事書いててまだ1vs1 Silverなんですけどね！
はやくGoldに上がりたい…

Togetterまとめの戦略感の無さがすごい

揉め事

もはや50%以上は晒し上げ目的で使われてるんじゃないか(それはお前の観測範囲だけだろ問題の例)と思えるぐらいのTogetterですが、なんか揉め事視点的に何にも考えてない感のあるまとめがやたら多い気がします。


自ID率表示グリモンからこっち、「Togetterで楽しい揉め事ライフを！」ってぐらい揉め事に事欠かないんですが、Togetterでの揉め事系の傾向として「まず晒し上げること」が目的になっていて、「その晒し上げの結果がどうなるか」を全然考慮していない(する気がない)揉め事が大半な感じ。
Togetterでまとめる行為自体が強い指向性を持つアクションなんだから、バランス感覚として出来るだけ中立視点に倒すフリだけでもすりゃいいんじゃないかと思うんですが、もうタイトルからして「こいつが悪い！こいつが馬鹿！」と大声で叫んでるまとめばっかり。
そもそも、自ID率が揉め事に大きく関わっているのは、


自IDを多く含む=内容に偏りがあっても気にせず、自己顕示欲が強い=揉め事キャラ


という流れなんで、そんな人のまとめに戦略性が無くても不思議は無いと言えば無いんですが。
晒し上げ(相手への嫌がらせ)だけが目的ならそれでも問題ないんですが、「味方を増やしたい」「論戦に勝ちたい」「色々な人に問題を知られたい」的な方向性を求めるのであれば、「こいつ周りが全然見えないタイプだな」と思われるのはとても大きなマイナスであって、タイトルに皮肉や罵倒を入れたり、投稿者コメントで相手がいかに酷いかを主張したりするのは単なる失策にしか見えません。
それだけ色々やっといて「なんでみんな俺に味方しないんだ！」みたいな言い方する人も多くて、そらそうだろうと夏の日差しの中クーラーの効いた部屋で黄昏れながら思うわけです。


もう少し人狼的というか、「周囲への説得力を前提としたアクション」の上手い揉め事が多くてもいいと思うんだけどなあ。
両手グルグルパンチじゃ喧嘩にもピクルにも勝てませんよ。

BeautifulSoupを使って2つのはてなブックマークで共通するユーザのコメントを抽出してみる

python

Togetterの抽出ネタでも良かったんですが、まずは身近な方で。


BeautifulSoupはpythonのHTML/XMLパーサライブラリで、多少の文法誤りを許容・修正してくれる上に非常に使いやすいおすすめライブラリです。
はてなはAPIがあるんでXMLで叩けばいいんですが、今回は練習も含めてHTMLでやってみました。
まず、はてなブックマークのコメント一覧のHTMLを分析します。

  • 各ユーザは一人毎にli要素にまとめられている。
    • li要素は属性"id"及び"data-user"を持つ
      • "id"には"bookmark-user-[ユーザID]"という値を持つ
      • "data-user"には"[ユーザID]"がそのまま値となる
    • コメントはli要素内、属性class="comment"のspan要素で書かれている

このことを踏まえ、はてブのコメントリストページからIDとコメントを抽出し、IDをキーとした辞書に変換する関数を作ります。

import urllib2
from BeautifulSoup import BeautifulSoup
import re

def get_comments(url):
    soup = BeautifulSoup(urllib2.urlopen(url))
    commentdict = {}
    for user in soup.findAll("li", id=re.compile("bookmark-user")):
        commentdict[user["data-user"]] = ''.join(user.find("span", "comment").findAll(text=True))
    return commentdict

何これ超簡単。
pythonらしくないところはヘタレCプログラマの限界と思って下さい。ジェネレータとリスト内包で一時辞書を作らずそのまま返すほうがかっこいいかも。
基本的なところはすっ飛ばして、BeautifulSoup周りのみ解説。

  • findAllメソッドは対象HTML全体から指定した要素のみを抜き出し、リスト化する関数。上記の通り正規表現も使えます。
  • findAll等で得られた各要素のインスタンスは、属性名を指定すればその属性に設定された値をそのまま得られます。上ではli要素のdata-user属性値(ユーザID)をそのまま辞書のキーとして使用。
  • findAll(text=True)で対象インスタンス以下の全ての値をリストとして得られます。"".joinで繋げれば全部の地の文字列をそのまま抜けます。


あとは二つのURLからそれぞれ上記関数で辞書を作り、重複するIDのみ抽出すればOK。

if __name__ == '__main__':
    import sys
    if len(sys.argv) != 3:
        print "usage: %s [bookmark url 1] [bookmark url 2]" % sys.argv[0]
        sys.exit(1)
    dict_pre = get_comments(sys.argv[1])
    dict_suf = get_comments(sys.argv[2])
    for user in set(dict_pre).intersection(dict_suf):
        print "User : %s" % user
        print "Comment pre : %s" % dict_pre[user]
        print "Comment suf : %s" % dict_suf[user]

二つの辞書の交差(重複)キーを抽出するのにsetを使っています。インスタンス生成を減らすため、各辞書毎にsetインスタンスを作成せず、一つだけ生成したsetインスタンスのintersectionメソッドを使用。これはPython Cookbook 4.17に記載されてます。


あとは二つを繋げて完成。python素敵。
これで今日から貴方もダブスタチェッカー！

iPhone4での再生用動画作成TIPS

iPhone

こんな情報2chなり何なりでいくらでも探せそうですが、自分用にかき集めてきた情報のまとめ。

前知識

iPhone4は公式にはH.264 Main Profile/Level 3.1 対応。
実際にはHighProfileも再生可能。CABACや8x8変換を使っても問題なく再生可能。
液晶の解像度は960x640。16:9を維持した最大解像度は960x540。
この解像度の場合、x264なら--levelオプションで強制設定しない限りLevelは3.1以下に収まる。

TIPS

x264でのエンコードの場合、--levelオプションをつけない事。

前知識で書いた通り、x264で解像度960x540でのエンコードなら、levelオプションをつけない限りは再生可能なlevelに収まります。
下手に--level=4.2なんて付けるとiTunesにはねられたりするらしい。

iTunesに登録出来ない場合はffmpegでmp4コンテナを作り直す

iTunesの「ファイルをライブラリに追加」を選んでもライブラリに表示されない場合に有効。
QuickTimeで再生すると、「ムービーに不正なサンプル記述があります」と表示される。
これは、mp4コンテナ内、AACトラックのパラメータにQTが対応していないフォーマットが書かれている事が原因との事。
(詳細はhttp://mycometg3.blog.so-net.ne.jp/2008-05-11を参考に)
バイナリエディタで該当箇所を書き換えるという手段もあるが、上記サイトにもあるとおりffmpegによる再梱包が簡単確実。

ffmpeg -vcodec copy -acodec copy -i [inputfile.mp4] [outputfile.mp4]

これでiTunesに登録出来れば一件落着。


しかし、「ファイル(フォルダ)をライブラリに追加」→ファイル(フォルダ選択)後、上記理由でライブラリに登録出来ない場合でも、メッセージダイアログ一つ出さずに操作が終了するiTunesのUI設計はアレ方向に凄みを感じます。無言かい。
「ライブラリに登録出来たかどうかは毎回その目で確かめてね♪」なんて一ソフトウェアから言われたらバットでPC粉砕したくなるんですが。
QTのエラーメッセージもなあ。あれを「QTで再生できないタイプのフォーマット記述があります」って読み取れる人はデバッグの英雄になれるよね…

久しぶりなのでiPhone4への文句でも

技術

一ヶ月半も開けておいて大したことは何もしてません！
BeautifulSoupで揉めそうなTogetterスレを抽出するスクリプトとか欲しがる人もいなさそうだしなあ…


せっかくなので何故か入手出来たiPhone4の気に入らないところを羅列してみる。

マルチタスクでの電池消費

どうも、特定のアプリはバックグラウンド上でもCPUリソースを消費するらしく、パワーセーブに移行してもバッテリ残量がゴリゴリ減ることがある。
寝る前に充電完了を確認して、朝見たら100%→72%になってるのを確認。
その日から、必ずバックグラウンドにある全てのアプリを削除してからパワーセーブに落とすハメに。
ただ、起動したアプリは自動的にバックグラウンドに回されるため、アプリ起動事に毎回ダブルクリック→タスク終了の繰り返しをやってるという悲しい現状。
メモリ解放アプリもあるようだけど、現状では安定性に何があるらしく導入には二の足を踏んでいます。
というかバックグラウンドでも常時リソースを食うようなアプリを明示するなり、何らかのアクションでバックグラウンドタスクを一括終了できるようなインターフェースを用意するなりしてくれればいいのに。

iTunes

まあ以前からわかっていましたがiTunes Windows版は本当にクソ。
これはWindowsユーザへの嫌がらせではないかと思う位。
iPhoneを接続している間はWindowsそのものが速度低下するという仕様は本当に勘弁して欲しい。
(ドライバレイヤでiPhoneに対して定期的にPingチェックを行っているような感覚)


極めつけはiPhoneの自動バックアップ機能。
これ、\Documents and Settings以下に強制的にバックアップを作成され、しかも保存先フォルダの変更が出来ないという現代のソフトウェアとは思えない仕様。
しかもバックアップ保存時に対象ドライブの空き容量チェックを行わない上、バックアップを行わない限り同期機能は動作しないという素敵ぶり。当然バックアップ自体のOFFは出来ません。
いきなりCドライブ残量3Gbytesを0byteまで消費し、Windowsの残容量警告ポップアップを大量発生させた揚げ句「同期出来ませんでした」というメッセージ表示に俺の血圧も急上昇。
NotePCを母艦にしてるような人も多い中「iPhoneの容量(16 or 32Gbytes)と同じかそれ以上の空きスペースをCドライブに作れ」という言外のメッセージにApple魂を感じました。帰れ。


シンボリックリンクを作るなり、フリーウェアでバックアップそのものを回避するなりで対策出来るらしいですが、UIをどうこう語るならここら辺ぐらい気を遣って欲しいよなあ…

口蹄疫の防疫進捗について調べてみた

時事

口蹄疫の殺処分が大幅遅れ １ - 松永和紀blog
農林水産省が殺処分を記載してないとの記事ですが、農林水産省の口蹄疫情報ページの中に、各農家別の状態についての記載があります。

宮崎県の口蹄疫に対する防疫措置について：農林水産省
ステータスは5段階で、

  • 処分地未割り当て
  • 処分地割り当て済み(殺処分はしていない)
  • 殺処分中
  • 殺処分完了
  • 防疫完了

の5段階。
上から順番に進行していく形らしい。
Tracのワークフローとかと同じように考えるとわかりやすい。
いままでの農家毎にインデックス番号が振られているので、上記とすりあわせである程度の現状把握が可能です。
せっかくなのでデータをまとめてみました。

2010/5/11現在の口蹄疫 防疫進捗

状態 頭数
処分地未割り当て 16335
処分地割当済み 22319
殺処分中 26679
殺処分完了 300
防疫完了 9922


これを見ると5/11現在で処分処理を開始できていない頭数は4万9千頭前後。
ついでに48時間以内の処分が望ましいとのことなので、処分地割り当て済み・未割り当ての頭数を確認日が5/9より前と後で分けてみた。

日付 頭数
5/8以前に確認 25869
5/9以降に確認 12785

全体割合で言えば3割、2万6千弱の対象家畜が未処分の状態で48時間以上が経過していることがわかる。


とはいえ、正直これを今から二日以内に全頭処分というのはどう考えても困難です。
整備された屠殺場ではなく、外部での屠殺、しかも各牧場の場所が分散している状態では、効率のよい処分は望めないでしょう。
一頭あたりのタクトタイムが二分だとして、一時間で30頭、寝る間も惜しんで12時間労働としても360頭、5ライン構築しても1800頭/dayが限界。
このペースでやるなら5万弱の処分には一ヶ月近い時間が掛かってしまう。
10ラインパラで一頭一分としても7日弱、交替前提で24時フル活動という超非現実的な状況を想定しても4日はかかる計算。
はっきり言って、ここまで膨れあがった数の暴力は、「理想的な処分」はもう不可能な領域に突入してるんじゃないかなあ。


追記:
他の方がグラフを作成していました。
一目で現状の進捗がわかるんで興味のある方は是非下記サイトを確認してみてください。
データで見る口蹄疫対策の緒戦敗北（2010年 宮崎） その３: コンタンのブログ