VOYAGE GROUP エンジニアブログ

voyagegroup_techのブログ
VOYAGE GROUPエンジニアブログです。

Ruby DSLを定義してPowerPointスライドを自動生成する話

こんにちは、モバイルショッピング事業室で働いている小芝です。

先日、NTTレゾナント社のRubyコミュニティ「職場.rb」で講演する機会をいただきまして、Ruby DSLとPowerPointスライドの自動生成についてお話させていただきました。

概要

最近DSLという言葉をよく耳にするようになりました。
しかし具体的にいつどんなときにどのように作ればいいかという情報は少ないように思います。
この講演では、簡単にDSLを定義し扱う事ができるようになる事を狙いとして、下記2点の紹介・解説を行いました。
  1. プレゼン資料を表すDSLを定義し、PowerPointスライドを生成する事例の紹介
  2. 簡単にRubyでDSLを作成・活用するためのポイントの解説

提示資料

またhttp://www.ipad-zine.com/b/814/ にも登録しております。

実はこの資料自体が、このお話の中で解説しているDSLから生成したPowerPointスライドを使っています。(ソースの公開については少々お待ち下さい)

DSL楽しいよ

DSLを定義し動かせるようになると、この手法を様々な状況で応用する可能性が見えてきてとても楽しくなりますので、是非お試し下さい!

もし、いい応用例を見つけたり、逆にうまくいかなかったりしたら、是非その内容を共有してもらえるととてもうれしいです。
一緒にDSLトークをしましょう。

【告知】東京Ruby会議05を開催します

2011年2月4日(金)にECナビを会場として、プログラミング言語Rubyについてのカンファレンスの一つである、東京Ruby会議05を開催します。
まずは2011年2月4日の夜の予定を空けておいて下さい。

最新情報は、東京Ruby会議05公式サイトRuby会議日記にて随時お知らせいたしますので、是非チェックしてください! 
 

ECナビにおける案件管理の歴史 ~Excel/MS ProjectからRedmineまで~

ECナビの子会社のuniameでソーシャルゲームの開発をしている野口(@ntakaaki)と申します。

このBlogを読んでいる方はシステム開発に携わっている方が多いかと思います。
皆さんの会社や所属組織ではユーザーから上がってくる
システムへの新機能の追加や修正をどのように管理されているでしょうか。

最近ではRedmineやTracのようなシステムでチケットを
発行して管理されてるところが多いかと思いますが
ECナビ創業当時の2000年前後には課題管理にツールを使うといった話も
ネットで見かけることも少なかったかと思います。
 
ECナビでは会社の成長とともに膨らむシステムへの追加や修正案件を
どう管理していくか、その過程でいくつかの方法が試されてきましたので
その歴史の一端をご紹介させていただこうと思います。
システム化以前
 
会社創業期の頃は口頭やメールなどで直接エンジニアやデザイナに
修正の依頼が飛んでいきます。
 
この頃は、リーダー格の人が発生した案件をファイルサーバー上の
ExcelやMS Projectで共有というのが多いかと思いますが
  • 書いたはずの内容を他の人に上書きされてしまう
  • 履歴管理、変更管理がしにくい
  • 人によってフォーマットが違ってって読み合わせが大変
などでやはり破綻します。
 
ルールを作る事で、上記の問題は解決できるでしょうが厳密にルールを
周知・徹底させないとなかなかうまく行かないでしょうし、
人や組織がかなりの頻度で変わっていく状態だと 
そのコストも馬鹿になりません。 
それでもこの仕組みは5,60人くらいまでややってたかと思います。

初代管理システム


いい加減どうにかしないとという事でBugTrackシステムで管理するのが
良いんじゃないかという話が上がりました。
当時存在していたメジャーなBugtrackシステムはBugzillaかと思いますが
インストールして試してみたものの、いまいち使いにくいし英語だし
なんだか項目いっぱいあってよくわからないし、という事で自作する事に
なりました。
これが初代の案件管理システムです。
機能としては
  • 依頼内容を入力するフォーム
  • 受け取った依頼を一覧する画面
  • 依頼内容を修正する画面
  • 依頼ごとの掲示板
と、あっさりしたものですが当時としてはこれで十分助かりました。
依頼を受け取った担当部署のリーダーは管理画面で担当者のアサインを行い
アサインされた担当者は依頼毎の掲示板で依頼者とやり取りする事で
依頼の過程を記録に残せて共有などが図れるようになりました。
 
依頼内容もここで一元管理化出来たので、誰が何をやっているのかの
把握がそれまでに比べてずいぶんと楽になったと記憶してます。
 
二代目管理システム

これで大丈夫となったはずなんですが、また問題が持ち上がります。
それは大規模な案件対応とワークフローをつけろという偉い人たちからの要求です。
大抵の細かい依頼内容は頼んだ本人と作業する人間の間で完結しますが
サイトを丸ごと1つ作るような規模になってしまうとそうも行きません。
 
依頼を細かく出すのかそれとも1つの依頼で関係者全員が
そこでやり取りするのかどちらが良いのかという話になってしまいました。
そこでプロジェクト管理システムを作ろうという事になりました。
主な機能は下記になります。
  • プロジェクトの関係者を複数登録でき変更を通知できる。
  • プロジェクト内で異なるトピックごとに掲示板が作れる。
  • ログインすると自分の出した依頼、担当している依頼、自部署あての依頼がわかる。
  • プロジェクトの検索条件を指定でき、且つパーマリンクで保存できる。
  • 小規模案件用に簡易な入力フォームとワークフローも備える。
などの結構便利な作りになっています。
これが出来てからは自分のマイページに出てくる案件をチェックすることで
遅れや問題の有りそうなところの発見がずいぶん早くできるようになりました。
 
ちなみにシステム名をCPO(ChiefProjectOfficer)といいます。
ただ、こちらのシステムは現在のECナビのような複数の部署や子会社が
発生する事を想定したものではなく現在の会社の実態に余りあっていないため
最近では一部でしか使われてないです。

現在のシステム

その後エンジニアを中心にTracが使いたいという声が上がってきて一時Tracが
大量に立ち上がった事もありますが、最近主に使われているのはRedmineです。
Redmineを使うようになったのは、昨年の夏ごろからです。
 
当時私が所属していた部署では細かい依頼が発生する事が多くそれをCPOで
管理してましたが、CPOの入力の手間や案件のやり取りの情報の制御が手間というの
が課題となっていました。

それらの課題を解決すべくRedmineを導入しました。
その後、新規に立ち上がった部署などを中心に使われるようになり
現在はユーザー数が187名、プロジェクト数が123個になってました。

ここまでになってしまうと、一人で管理できるわけもなく、かといって全員を
管理者にして好き勝手にプロジェクトを立てくださいというわけに行かないので
部署毎にRedmine管理者を立ててもらうようにしています。

新規のプロジェクトの設置や新人の追加、トラッカーやカスタムフィールドの追加などは
各部署のRedmine管理者の判断でやってもらい、まれに全体に影響しそうな変更や
例外事項の共有を行うといった形で運営上特に問題なくやれてるかと思います。
 
プロジェクトはTopの直下に部署毎のプロジェクトを設置し、部署毎にもってるシステムや
案件をその下にぶら下げていくような形をとっています。
またアカウント管理も社内のLDAPサーバーと連携するようになってます。
 
Redmineはシステムとしては1つですが
  • プロジェクトの単位でメンバーやチケットを管理できる
  • 管理画面だけでカスタムフィールドや独自のトラッカーを追加できる
  • カスタマイズしても影響が全プロジェクトに波及しない等(一部波及してしまうものも有りますが)
分割統治的な仕組みが非常に良いところだと個人的には思ってます。

現在使用しているRedmineは0.8系なので、どこかのタイミングで1.0系に
移行できたらと思っています。

というわけで、ECナビの案件管理の歴史を振り返ってみました。

Redmine 
 

Amazon S3 を PHP から使ってみた

こんにちわ。ECナビ事業本部の小林です。
9月からECナビに入社し、先日リリースした「ナビバリュー」の開発に携わってきました。

ナビバリューはECナビのサイト上で実施している人気の商品をどのECサイトよりも安く購入できるサービスです。現在のところ、毎週10種類の商品を数量限定で販売していますので、是非毎週チェックしてみてくださいね!!

さて宣伝はここらへんにしておいて、今回ナビバリューを開発するにあたって twitter、 bitly、Amazon Web Service など様々な外部のサービスを利用しています。
そのなかで今回は Amazon S3 を PHP から利用する方法について簡単に紹介をしていきたいと思います。

Amazon S3 って?
今更説明の必要はないかもしれませんが、Amazon が提供する従量制課金のストレージサービスです。詳しくは公式ページへ→ http://aws.amazon.com/jp/s3/

目的
ナビバリューの開発に合わせてユーザーが商品レビューを投稿する際に画像をアップロードできるようになりました。S3はアップロードされた画像の保管場所兼コンンツ提供サーバとして使用しています。自前でストレージを用意するよりは以下のようなメリットが挙げられます。
  • ディスク容量などの物理的な制限を気にせずに済む
  • 専用サーバを用意するより早い、初期コストが安く済む
実際に使ってみる
まず本格的にアプリケーションに組み込む前にファイルをアップロードする簡単なプログラムで試してみました。
  1. SDK
    PHP から利用するには amazon から提供されている SDK を利用させてもらいます。この SDK には PHP から Amazon S3 や EC2 などを使うのに便利な API が含まれています。
  2. 設定ファイル
    ダウンロードした SDK の中に config-sample.inc.php という名前のファイルが含まれており、これが設定ファイルの雛形になります。これを config.inc.php という名前でコピーして、必要な項目を記述していきます。設定に必要な情報は http://aws.amazon.com/ からアカウント→セキュリティ証明書で確認できます。この config.inc.php と SDK に含まれる sdk.class.php を include します。
    include_once "./sdk-1.0.1/sdk-1.0.1/sdk.class.php";
    include_once "./config.inc.php";
  3. バケットをつくる
    Amazon S3 ではバケットというディレクトリのようなものを作成し、そこにファイルをアップロードしていきます。ただしバケットの中にバケットを作ることはできません。また、バケット名は Amazon S3 のサービス内でユニークでなければなりません。ここでつけたバケット名はアップロードしたファイルを公開したときのURLに使われます。たとえば ecnavi-tech-blog  というバケット内に test.jpg というファイルを作成した場合は
      http://ecnavi-tech-blog.s3.amazon.aws.com/test.jpg
    でアクセスすることができます。 バケットを作成するには AmazonS3 クラスの create_bucket を使います。ここではリージョンやアクセス権の指定もできますが、テストなのでとりあえずデフォルトのままにしておきます。
    $s3 = new AmazonS3();
    $s3->create_bucket("ecnavi-tech-blog");
  4. ファイルをアップロードする
    ファイルをアップロードするには AmazonS3 クラスの create_object で、バケット名、アップロード先のファイル名、第3引数の配列でアップロード元のファイル名やアクセス権などを指定します。ここでは/tmp/foo.jpgという名前のファイルをtest.jpgという名前でアップロードしています。またhttp経由で誰でも見られるようにするために、アクセス権はACL_PUBLICを指定します。
    $s3->create_object("ecnavi-tech-blog", "test.jpg", array('fileUpload' => "/tmp/foo.jpg", 'acl' => AmazonS3::ACL_PUBLIC);
    これで3で書いた URL で画像が表示されると思います。
    TIPS
      公開URLを階層構造にしたい場合、アップロード後のファイル名(2番目の引数)を "testdir/test.jpg" などとすると下記のようなURLで公開できます。
      http://ecnavi-tech-blog.s3.amazon.aws.com/testdir/test.jpg
まとめ
アップロードの触りだけでしたが、ドキュメントとSDKに含まれているサンプルコードを一通りながめればその他の操作も特に難なくできると思います。ソフトウェアの開発期間が短かくなっている昨今、このように便利なAPIが用意されているとRESTやSOAPを直接操作することをしなくて済むので非常に助かります。

記事検索
QRコード
QRコード