Hatena::ブログ(Diary)

見ろ!Zがゴミのようだ! このページをアンテナに追加 RSSフィード

2011-02-21

[][]Shibuya.Trac 第10回勉強会に行ってきた 00:49 Shibuya.Trac 第10回勉強会に行ってきたを含むブックマーク

これが年開けてからの初日記ですね!

あけましておめでとうございます!今年もよろしく!


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用にストーリー・タスクという分け方でチケット管理が可能
  • バックログやバーンダウン等の機能も完備
    • Debian GNU/kFreeBSDで動くなら大抵の環境下で動くんじゃなかろうか
  • ウォーターフォール用に「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時間でした。

次回も是非参加したいところ。

ikikkoikikko 2011/02/22 02:05 詳細なまとめおつです。が、
> 「結婚式をタスクとして切り出したらチケット140枚」
これ、僕じゃないです><
確かふじはらさんですね。

LightningLightning 2011/02/22 07:30 先日はありがとうございました。楽しんで頂けたようでなによりです。

Tracでストーリーボードを実現する方法としては、

[WhiteBoardPlugin]
http://trac-hacks.org/wiki/WhiteboardPlugin

[JamCircleを使ってTracと連携]
http://kompiro.org/jamcircle/en/wiki

などを使えばできると思います。あと、未確認ですが、確か

[IttecoTracPlugin]
http://trac-hacks.org/wiki/IttecoTracPlugin

でもできたと思います。よろしければ試してみてください。

torintorin 2011/02/22 10:37 >Id:ikikko
ぎゃー、すいません。
御指摘通り修正しました。

>Id:Lightning
情報ありがとうございます。
導入しやすそうなWhiteboardあたりから導入テストしてみます。
中規模以上のプロジェクトだと本当に放置チケット問題はついてまわりますね…

2010-09-13

[]StarCraft2はもっとプレイされるべき/Brutal Tips 20:49 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ユニットしか残ってなかったし。

f:id:torin:20100913203625j:image

大量の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に上がりたい…

トラックバック - http://d.hatena.ne.jp/torin/20100913

2010-08-29

[]Togetterまとめの戦略感の無さがすごい 16:59 Togetterまとめの戦略感の無さがすごいを含むブックマーク

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


自ID率表示グリモンからこっち、「Togetterで楽しい揉め事ライフを!」ってぐらい揉め事に事欠かないんですが、Togetterでの揉め事系の傾向として「まず晒し上げること」が目的になっていて、「その晒し上げの結果がどうなるか」を全然考慮していない(する気がない)揉め事が大半な感じ。

Togetterでまとめる行為自体が強い指向性を持つアクションなんだから、バランス感覚として出来るだけ中立視点に倒すフリだけでもすりゃいいんじゃないかと思うんですが、もうタイトルからして「こいつが悪い!こいつが馬鹿!」と大声で叫んでるまとめばっかり。

そもそも、自ID率が揉め事に大きく関わっているのは、


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


という流れなんで、そんな人のまとめに戦略性が無くても不思議は無いと言えば無いんですが。

晒し上げ(相手への嫌がらせ)だけが目的ならそれでも問題ないんですが、「味方を増やしたい」「論戦に勝ちたい」「色々な人に問題を知られたい」的な方向性を求めるのであれば、「こいつ周りが全然見えないタイプだな」と思われるのはとても大きなマイナスであって、タイトルに皮肉や罵倒を入れたり、投稿者コメントで相手がいかに酷いかを主張したりするのは単なる失策にしか見えません。

それだけ色々やっといて「なんでみんな俺に味方しないんだ!」みたいな言い方する人も多くて、そらそうだろうと夏の日差しの中クーラーの効いた部屋で黄昏れながら思うわけです。


もう少し人狼的というか、「周囲への説得力を前提としたアクション」の上手い揉め事が多くてもいいと思うんだけどなあ。

両手グルグルパンチじゃ喧嘩にもピクルにも勝てませんよ。

2010-07-20

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

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


BeautifulSouppythonの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素敵。

これで今日から貴方もダブスタチェッカー!

トラックバック - http://d.hatena.ne.jp/torin/20100720

2010-07-12

[]iPhone4での再生用動画作成TIPS 21:30 iPhone4での再生用動画作成TIPSを含むブックマーク

こんな情報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が対応していないフォーマットが書かれている事が原因との事。

(詳細はエラー:So-netブログを参考に)

バイナリエディタで該当箇所を書き換えるという手段もあるが、上記サイトにもあるとおりffmpegによる再梱包が簡単確実。

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

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


しかし、「ファイル(フォルダ)をライブラリに追加」→ファイル(フォルダ選択)後、上記理由でライブラリに登録出来ない場合でも、メッセージダイアログ一つ出さずに操作が終了するiTunesのUI設計はアレ方向に凄みを感じます。無言かい。

「ライブラリに登録出来たかどうかは毎回その目で確かめてね♪」なんて一ソフトウェアから言われたらバットでPC粉砕したくなるんですが。

QTのエラーメッセージもなあ。あれを「QTで再生できないタイプのフォーマット記述があります」って読み取れる人はデバッグの英雄になれるよね…

トラックバック - http://d.hatena.ne.jp/torin/20100712