Seasar Conference 2009 Springで発表してきました
「Seasar2 みんなでやれば こわくない」というタイトルで開発事例を発表してきました。
http://event.seasarfoundation.org/sc2009spring/Session#hall3
こういう場で発表者側として参加したのは初めてだったのですが
とても楽しかったです!
円滑に進めてくださったスタッフの皆様にも感謝。
聞いてきたセッションのメモ
・S2ClickをはじめとするSeasarファミリーを活用したアジャイルシステム開発事例
エクセルのテスト、感じるところは同じなんだなー
残念ながら時間切れだったのでプレゼン資料で勉強してみる。
・Web サービスの育て方 - チョイスタディの場合
似たような構成だったので参考になりました。
mayaaはうちが使いこなせてないだけな気がする。
・ひがさんのBigTableのお話
GAE/J自体ちょろっとしか触ってなかったのでさっぱり理解できず。
もうちょい触ってみよ。
template1の削除
template1の初期化方法について。
ここにあった。
http://www.postgresql.jp/document/pg831doc/html/manage-ag-templatedbs.html
Hudson
Hudsonメモ
こちらを参考に。
Hudsonを使ったアジャイルな開発入門:特集|gihyo.jp … 技術評論社
Hudsonのダウンロードは下記が最新版へのパーマリンクになってます。
http://hudson.gotdns.com/latest/hudson.war
ダウンロードしたら
java -jar hudson.war
をすればlocalhost:8080ですぐ実行。
ヘルプは
java -jar hudson.war --help
ポートを変えたい場合は、
java -jar hudson.war --httpPort=60000
設定とかはホームディレクトリの.hudson/以下にできるみたい。
あとでのぞいてみよう。
FreeBSDを始める際に注意すること
最近ノートPCをFreeBSDにしてみたのですが、なかなか大変だったのでハマった箇所など。
適宜追加していこうと思います。
・portsの更新はcvsupじゃなくてportsnap使う
・portsdb -uUとか、pkg_db -aFは必要になったら勝手にやってくれる
man portsdbを参照。
・ハンドブックは日本語版と英語版を見比べながら読むこと。
日本語版は内容が若干古いです。
たとえば、Xのインストールの解説だと、日本語版ではXFree86の解説ですが、
http://www.jp.freebsd.org/www.FreeBSD.org/doc/ja_JP.eucJP/books/handbook/x-install.html
英語版だとXorgの解説になっています。
http://www.jp.freebsd.org/www.FreeBSD.org/doc/en/books/handbook/x-install.html
日本語版の解説は若干翻訳が追いついてないようなので、英語版を見比べて読んだほうがよいと思います。
・google先生に聞くときは検索オプションで日付指定する。
結構古い内容が上位にでてきたりします。
portsの更新方法でcvsup使ってる内容があったりportsnap使ってる内容があったりで、どっち使ったらええねん!とかなり迷いました。できるだけ新しい内容がひっかかるように検索オプション>日付で範囲指定して検索したほうがよいと思います。
・迷ったらman
man portsdbのように、man "コマンド名"と打つと説明がでてくるので説明を読みましょう。
英語ですが、ちゃんと書いてあると思います。
・インストールの際に参考にしたサイトとか
FreeBSD Daily Topics|gihyo.jp … 技術評論社
http://nhh.mo-blog.jp/ttt/
春木屋
最近のトレンドがどこかにまとまってたらいいのになー
freebsd-users.jp的なものがあれば。。。
Kansai.pmいってきました。
今回も空前のMUSHOKUブームw
・セキュアコーディング(AzureStoneさん)
・Plaggerプラグインの作り方(hashyさん)
・ハローワーク
・イベント各種あったけど作り方はソース嫁
・updateフェーズはフィルタ系
・customfeedよりWeb::Scraper
・ししゃもとかMixiCommentとか
・mixiは投稿3秒規制
・Seren Bach(hashyさん)
・自己紹介略
・sb開発研究所のWeblogツール
・sb::Plugin->register_pluginとかでプラグイン登録する
・typeでいろいろ師弟
・タイムキーパーは初音ミク
・CGI::Application(はしもとさん)
・ムショク
・メソッド追加はExportするだけ
・イベントハンドラ系はExporter継承してadd_callbackで
・Error.pm(ビンゴ中西さん)
・Javaライクな例外処理
・try,catch,otherwise,finaly
・独自の例外もかける
・Thrift(伊藤直也さん)
・クロス言語RPCフレームワーク
・サービスレベルでの結合
・IDLでインターフェース定義
・FacebookはWEBサーバ10000台だとか
・タイムキーパーむかつくw
・続・脱KENT様スタイル(AzureStoneさん)
・自宅警備員
・こりん星にはサーバがいっぱい。
・前回の復習
・具体的に何をするというより周りを巻き込むためのその一みたいなかんじ
・PersistantPerl(TAMASHIROさん)
・mod_perlみたいなの
・アルゴリズムがすごいなーと思った。
・emacsでPerl(antipopさん)
・これからはvim
・Ackとかflymakeとかperl-complationとか
・MocoよりPoco
Smartyで文字列テンプレート
テンプレートファイルつくるほどでもないってときに。
register_resource()すればいいのか。
http://www.smarty.net/manual/ja/api.register.resource.php
require 'Smarty/Smarty.class.php'; $s = new Smarty; $s->template_dir = dirname(__FILE__); $s->compile_dir = dirname(__FILE__); function string_get_template ($tpl_name, &$tpl_source, &$smarty_obj) { $tpl_source = $tpl_name; return true; } function string_get_timestamp($tpl_name, &$tpl_timestamp, &$smarty_obj) { return true; } function string_get_secure($tpl_name, &$smarty_obj) { return true; } function string_get_trusted($tpl_name, &$smarty_obj) { } $s->register_resource("string", array("string_get_template", "string_get_timestamp", "string_get_secure", "string_get_trusted")); $template = <<<END konnnitiha! konnnitiha! konnnitiha! konnnitiha! END; $s->display("string:$template");
デフォルトで組み込まれてたらいいのになー
逆ブレスト
とにかく徹底的に批判する。批判以外は絶対にしない。問題点を洗い出すのが目的。
問題点はたくさんあるんだけどプロジェクトはイケイケドンドンで「これ絶対やばいよな。。。」と心の中では思っている場合や、
問題点を指摘してるだけなのに、
「対案もねーのに文句言うな」「じゃあどうすんの!?」と問い詰められたり
「そんなにネガティブになることないよ、もっと自信もとうよ!」と見当違いの慰めをもらったりする場合に有効かもしれない。
ブレストで「批判を絶対しない」ことで豊富なアイデアが生まれるように、
逆ブレストでは「対案がなくても指摘する」「変な慰めをしない」ことで今後発生する可能性のあるトラブルをリストアップできる。
アイデア出すときに勇気がいるように、問題点を指摘するっていうのもストレスかかるんですよね。
すぐには解決できそうにないけどこういう問題があるよ、念頭に置いといてねっていうのが言い出しにくかったり、
対案考えるのがめんどくさくなって結局いわずじまいとか。
どうすればいいのかなーと、なんとなく考えてみたのですが、
フェーズをきっちり分けることが有効ではないかなと思うのです。
1)アイデアを出すフェーズ
ブレストする。批判しない。徹底的にアイデアを出すことに集中する
2)問題点を洗い出すフェーズ
逆ブレストする。とにかく問題点を洗い出す。「対案もねーのに文句言うな」とか絶対言わない。
3)解決策(対案)を考えるフェーズ
問題点をどうやって解決するか、解決できるかどうか、あとからでも対策可能なのかなどなど。
大事なのはアイデア出しと問題点のリストアップと対案を考えるフェーズを分けて、各フェーズではそれだけに集中することかなあと。
特に問題点を指摘するのと対案を考えるのを分けるのが大事ですね。
やっぱり対案とセットだとめんどくさいし。
もし時間がなくて対案を考えるフェーズが実施できなくても、
ある程度トラブルを想定できるので冷静に対処できたり、リソースの確保がしやすかったりとかするかもしれない。
あとからあとからトラブル続発ってのはもういやだ。。。