Posted filed under Ruby on Rails.

designed_scaffold
Railsのscaffoldはとても便利なんですが、人に見せるとき簡素すぎてインパクトが弱いのがネック。元々人に見せる物ではないので、仕方ないのですが。

Ajax Scaffold Generatorとかを使うと「おぉ〜」と言って貰える物ができるんだけど、後々、機能やデザインを変更しようとすると、結構めんどくさい・・・。

という自分の為に、それっぽいapp/views/layouts/*.rhtmlを生成してくれるプラグインを作っています。今のところ、→みたいなサイトがさくっと作れます。

ヘッダのストライプ部分の画像はRMagickで自動生成なので、色を変えるのも簡単。
こういうストライプデザイン以外に、数種類のデザインテンプレを用意したいなと思っています。

「ここのサイトっぽいテンプレが欲しい」とか「最近の流行はこのデザイン」というサイトがあれば、ぜひコメントでお願いします、というか、教えて貰わないと作れないっていうか。

Posted filed under Products, Publications.

今日は文科省の研修で、PukiWikiの話をします。最近は、なんだかスピーカーばかりしていますw
明日もLinuxコンソーシアムで、パネリストをやる予定です。

さて、今日の受講者は主に高校の先生方なので、実際にPukiWikiに触れてもらって、手軽さを感じ取ってもらいたいと思っています。
初めは資料を全部印刷しようと思ったのですが、いま時それも無いだろうということで、ここで公開して、実習時にスクリーン以外に、このページを見ながら実習を進めてもらおうと思っています。

実はPukiWikiの話をするのは、InternetWeek 2004以来ひさびさです。特に実習込みは初めてなので、時間配分が難しいですね。

なお、この講習会では、「PukiWiki入門」を配った上で進めています。このプレゼンをみて興味を持った方は買っていただけると嬉しいです。

Posted filed under Ruby on Rails.

 OSC2007-Kansaiで、北海道と同じようにマッシュアップ+Railsの話しをしてきました。
金曜の午前中にもかかわらず、結構な人が入っていて非常に嬉しかったです。全然いなかったら寂しいなと思ってましたから。

 さて、京都で北海道と同じように「北海道温泉マップ」を作っても面白くないので、京都神社マップとか作ろうかと思ったんですが、さすがにそんな情報を提供しているAPIは無いw
4travelのAPIを駆使してもちょっと難しそうなので、無難に「京都温泉マップ」にしました。

 でも去年、旅行に来たときにも思ったんですが、京都って温泉すくないんですよね。なので、対象を京都府全域にしてなんとかつくりました。

 表示する写真も、北海道ではFlickrでしたが、京都の温泉の写真は全然見つからないので、Yahoo画像検索APIを使うようにしました。こっちの方が精度良いかも。

 今回のソースは下記のURLで公開しています。試してみるときには、じゃらんAPIユーザ登録をし、lib/onsen.rbのKEYに自分のキーをセットしてください。

http://masuidrive.jp/tmp/onsen-kyoto.tar.gz

Posted filed under iPhone.


世の中にはホント賢いというか、良く見つけてくる人がいるなぁ。

実は夢の中でiPhoneをゲットして、夢の中で通勤時に毎日ビデオなんか見ながら出勤しているんですが、どーにもこうにも不便な事が一つあるんですよ。夢の中でね。

iPhoneのsafariは、ズームとか出来て画面が小さいのにかなり実用度高いんですが、なにせwifiに繋いでないとページが見れないってのが、非常につらい。
オンラインの時に複数タブ(?)開いておいて、電車で読もうと思ったら、タブもキャッシュしてくれなくて、開いているタブ以外は全滅。

ユーザが作れるiPhoneのアプリはWebベースだけなのにオフラインキャッシュがないので、ネットが無いところではアプリが動かないという致命的とも言える問題が。アプリはAjaxのみって言うなら、Google Gearsぐらいの機能はつけてほしいなぁ。

と思っていたら、やっぱりちょっとした解決策を見つけた人がいました。
HTMLをbase64でエンコーディングしてブックマークに保存することで、300K以上のHTMLを保存できるらしいです。

早速、先のブログにあったエンコード済みURLをiPhoneのSafariで開いてみました。夢で。右上の写真は念写です。

ブックマークした後に、フライトモードにしてブックマークから呼び出しても、写真のように問題なく動きます。これはすげぇ。使えるかも。


Posted filed under Publications, Ruby on Rails.

明日、7月20-21日はOSC2007-Kansaiに参加するために京都に行ってきます。
前回の北海道と同じでマッシュアップ話です。ただ、前回と同じ北海道の温泉のマップでもヘンなので関西版で別のネタは入れるつもりです。これから。

今度はどっかで「Railsでメシをどうやって食うか」みたいな話しをしたいなぁ。去年は自分で「2006年はRailsの仕事しかしない!」って決めて何とか食えたからな。その辺の話しを中心で。
聞きたい人がいたらコメントください。つかOSCの2日目の空いてる教室でやらせて欲しいなぁw

しかし1日目で平日の午前中。その割に同じ時間帯には強力なネタが並んでる・・・。
これはガラガラになりそうな予感・・・ orz

会社でNEXTWISEのブースも出していて、そこに張り付いている予定ですので、もしこのblogを読んでくれている人がいたら、必ず声をかけてください。たぶん、ブースで仕事してるけど気にせず声をかけてください。

実は新幹線に乗るのが初めて。ちょっと楽しみ。お弁当を買って乗ろう。

Posted filed under Ruby on Rails.

UnitTestしか書かないってスライドに書いたら、コメントとか他のブログで「ちゃんと機能テストも書け」というコメントが多かったので、挑戦することにしました。

テストはrspecにしようかと思ったんだけど、ドキュメントの整備やバージョン間の互換性が不透明だったので、あきらめました。一人でやるなら良いけど、人が増えてくると学習コストもバカにならないので。

Posted filed under Life.

毎日blog書こうと思ってたんだけど、今日はお休み。
色々溜まった個人的な仕事をこなす予定。

mooにシールが登場するらしい。

今までも友人にmasuidriveシールを作ってもらって、色々なモノに貼ってたんだけど、今度はもっと手軽に使えるなぁ。

QRコードにして、全部違うURLのシールとか。

Posted filed under Programming, Ruby on Rails.

 オレンジニュースさん、textfile.orgさんにも取り上げてもらい、masuidrive的プロジェクトの方針が予想以上の反響を頂いてちょっとびっくりしてます。

 この文章自体の前提が普通の会社の組織じゃないので、そのまま参考にはちょっとならないかもしれません。ただ自分の考えをプレゼンにするというのが、すこしでも普及してくれると嬉しいなと思ってます。プレゼン資料を作りつつ、脳内プレゼンをしていると、意外に抜けている自分に気がつくので。

 この対象のプロジェクトメンバーは波長の合う人を社内公募などで募って、そもそもこれを受け入れて一緒にやっていける人を前提に考えています。なのでかなり上段から見たような文章になっていますw ウチの会社自体は、とがった会社ではないので他部署で適用することは、あまり考えてません。

 私が個人でやってきた方法論が、どこまで組織で通用するのか、どこで行き詰まるのかを自分で楽しみにしてます。それを糧にもう少し一般化した方法論が書けないかなとも思っています。

 Tracを重要視するのは、RSSリーダで新しい指示の確認ができるからです。プロジェクトメンバーには、情報収集の意味も含めて全員RSSリーダを常用してもらおうと思っているので。
自分でも社内の他の部署との仕事もあり、情報を一元管理できないと、すでに追えない状況になっています。他部署の方に、「私への指示はTrac経由でのみ受け付けています」とはお願いできないので、まずは自分の部署からという感じです。

 もぎゃさんからリクエストの「subversionでのファイル管理方法」も含めて、もう少し細かい部分も書いていきます。この連休ぐらいには。

Posted filed under Programming, Publications, Ruby on Rails.

そんなわけで、プロジェクトの始まりはTracから。これがないと仕事が始まりません。

Tracが一番良いわけでも無いんだけど、日本語マニュアルがあるところと、ユーザが多いことから、subversionとの連携スクリプトなどが多数公開されているところが、選択理由です。

Railsベースでも複数、プロジェクト管理ソフトが出てきているので、どれか良い物に育ってくれると嬉しいなと思っています。

さて、tracのインストール方法はwebで沢山見つかるので、それを参考にインストール。
Tracは初期設定でも十分使いやすいんですが、チケット登録で担当者をドロップダウンリストにするために設定を変更します。

tracの設定ファイル conf/trac.iniの下記の項目を変更してください。

[trac]
default_charset = utf-8 # 文字コードはUTF-8で

[ticket]
restrict_owner = true # 担当者をドロップダウンリストにする

ユーザ登録は、.htpasswdにユーザを登録後、下記のコマンドを実行して権限を与えます。

trac-admin ./ permission add アカウント名 TRAC_ADMIN

そのあと、このユーザにはログインしてもらい、画面の右上「ユーザ設定」からメールアドレスを登録してもらいます。これを登録して貰わないとチケット登録画面の担当者として選択できません。

あとは、コンポーネントと優先度を変更します。まずは優先度を日本語にします。

trac-admin ./ priority change blocker 今すぐやる
trac-admin ./ priority change critical 急いでやる
trac-admin ./ priority change major 普通
trac-admin ./ priority change minor あとでもいい
trac-admin ./ priority change trivial そのうちやる

次にコンポーネントを変更します。

trac-admin ./ component rename component1 コード
trac-admin ./ component rename component2 仕様書
trac-admin ./ component add 会議 somebody

最後にチケットの分類を変更します。

trac-admin ./ ticket_type change defect 不具合
trac-admin ./ ticket_type change enhancement 機能拡張
trac-admin ./ ticket_type change task タスク

これで完了。もちろん、これもコマンド化してsubversionに入れておきましょう。

あと、メンバーの未処理チケットを簡単に確認できるようにメンバー分だけレポートを登録しておきます。

下記のレポートSQLを「メンバー名の未処理チケット」というタイトルで保存しておくと、メンバーの作業進行具合がわかって良い感じです。

SELECT p.value AS __color__,
   (CASE status WHEN 'assigned' THEN 'Assigned' ELSE 'Owned' END) AS __group__,
   id AS ticket, summary, component, version, milestone,
   t.type AS type, priority, time AS created,
   changetime AS _changetime, description AS _description,
   reporter AS _reporter
  FROM ticket t, enum p
  WHERE t.status IN ('new', 'assigned', 'reopened') 
AND p.name = t.priority AND p.type = 'priority' AND owner = 'メンバー名'
  ORDER BY (status = 'assigned') DESC, p.value, milestone, t.type, time

とりあえずは、ここまで。明日はsubversionとの連携スクリプトですw

Posted filed under Programming, Ruby on Rails.

 初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ本格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、「私がどういう考えで仕事を進めていきたいか」という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど)

 NIFTYさんと仕事した時も、作業に入る前に「今までどうやって遠隔地で仕事を進めてきたのか」をプレゼンしていました。特に初めて仕事をする場合、「今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか」を明確にしておくと、スムーズに仕事を進めることができます。

 仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。

 仕事をする上ではコミュニケーションが欠かせませんが、特に社内のコミュニケーションは口頭による指示が中心になると思います。何か指示をするにしても、「なぜ今その指示をするのか」「これをすると何のためになるのか」と言った背景が全ての指示で語られることはありません。実際、すべてを説明している時間は無いはずです。

 しかし、理由や目的の伝わらない指示は、なかなか思うとおりに実行されません。ここにメンバー間でしっかりとした共通認識があれば「この指示はこの部分に必要なんだろうな」と目的を推測したり、「ここは私ならこう思うから、違う理由を聞いてみよう」などの、アクションが取りやすくなると思います。

 そこで、せっかく個人では無く、会社員として仕事をするので、この共通認識の部分をプレゼンにまとめて、これを基盤に仕事の方針を決めていきたいと思います。とは言っても、初めてこういう事をやるので、まだまだ全然なダメダメな資料です。しかし明示することによって、おかしいところも気がつきやすく、見直しもしやすくなるだろうと思って、ブログに公開することにしました。

 オンラインPDFで公開しているので、もし良ければご覧下さい。

 一緒に仕事をする人には、この資料を読んで「masuidriveなら、こういう風に考えるだろうから、こうしておこう」とか「この指示は、こういう考えでだしたんじゃないかな」と考えて貰えるようになれば大成功だと思っています。

 なにせ会社員経験が浅いので、一般的な会社の仕事の進め方が分からず、この資料のどこに違和感を感じるか、実行するのに何が難しいのか、もっと良い方法はどういう事があるのか、など分からない事だらけです。

 もしこのプレゼン資料をみたら、何かコメントを残して貰えると嬉しいです。ぜひお気軽によろしくお願いします。

 JRubyを中心に活躍されている、大場 光一郎さん <koichiro@meadowy.org>には、資料作成とブログの校正でご協力いただきました。この場を借りてお礼をさせていただきます。