会社を作りました
ちょっと前になりますが、12月12日に株式会社を設立し、フリーランスからしゃちょーになりました。
今年の4月にフリーランスになったばかりなので、まだ１年も経っておりませんがそういう事になりました。
会社名は株式会社ラスカル（Lascal Inc.）といいます。
とあるBtoBのサービス（現在開発中）を世に出すために、法人が必要になったというのが大きな理由です。
なので、まあ実態はフリーランスとあまり変わらずですね。
しばらくはそのサービスの開発に注力することになりますが、落ち着いたらまたお仕事を頂ければと思っていますので、どうぞよろしくお願いします。
開発中のサービスは、中小小売業・飲食業・EC向けのもので、来年早々にはリリースできるように計画しています。
もやっとした情報ですが（笑）ご興味ある方はぜひお声がけください。モニター募集中です。
（喜んでもらえるといいなあ！）
フリーランスになりました
本日付けで株式会社プロフィットを退職しました。
お世話になった方々、本当にありがとうございました。
この場でいくつか書き残しておきたいと思います。
会社を辞めたこと
思えば新卒で同社に入社してから11年も働いていたようです。自分でもびっくりです。
自由な社風のもと、いろいろな事にチャレンジさせてもらえる環境であったことが
長く在籍できた理由であったと思います。
胸のすくような仕事ができたり、社内外に大きな大きな迷惑をかけたりと、
ホントに色々なことがありましたが、全て大きな経験として成長させてもらいました。
ではなぜ今そんな会社を離れるかというと
サラリーマンじゃない事にチャレンジしたかった、からです。
今後はフリーランスのエンジニアとして働いていこうと思っています。
元々、新卒の就職活動の面接でも、いずれは独立したいと言っていたクチで、
とはいえ「独立」が起業なのか、何なのか、よくわからなくなっていましたが
とりあえずはフリーランスで一歩踏み出してみるといった感じです。
まあ、内なる声もたくさん聞こえました。
「その程度の実力でフリーランスとか恥ずかしくないのか」とか、
「独立ってのは目的じゃなくて手段だろ」とか。
けれど、『やらない後悔よりやった後悔をしたほうがいい』と思い、決断した次第です。
ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙしながら、やれるとこまでやってみたいと思います。
Zusaarのこと
ちょうど１年ぐらい前にリリースしたZusaarもおかげさまできちんと稼働しています。
このZusaarは、今後も株式会社プロフィットのサービスとしたまま、僕が外部で保守・開発を続ける形になりました。
デザインを除いては、元々一人でやっていたシステムなので、実質何も変わりません。
サービスの質が急激に落ちるということもありませんので、安心してご利用頂ければと思います。
直近の仕事のこと
実は、年初からソーシャルランチの開発チームに参加しています。
かなりマスコミに取り上げられているサービスなのでご存知の方も多いかと思いますが、
今も取材の申込が止らないみたいです。
ソーシャルランチは、サービス自体はもちろんですが、何より創業者のお二人が素晴らしい。
このお二人にしてこの勢いはさもありなんといった感じです。
光栄な事に、４月からもしばらくはソーシャルランチの開発を支援させてもらえる事になりましたので
微力ながら全力でコミットさせてもらおうと思っています。
ちなみに
ソーシャルランチはクラウド基盤の貸し出しサービス「アップ・エンジン」の上でグーグルの独自言語パイソンが使われていますが、
この分野で遅れをとるどころか先頭を突っ走ってます。
優秀な社員さんを絶賛募集中だそうですので、腕に覚えの有る方は応募されてみてはいかがでしょうか。（あ、今は渋谷に移転しています）
Zusaarというサービスをリリースしました
TwitterやFacebookでは告知させてもらいましたが改めまして、
4/15に新しいWebサービス「Zusaar」をオープンしました。
参加費の決済もできるイベント開催支援サービス「Zusaar」
http://www.zusaar.com/
既存サービスをふまえて
ご存知の方も多いと思いますが、イベント支援ツールというものは、
既にいくつものサービスがあり、実際にご利用なさった事もあると思います。
そんな中で「新しくオープンしたといっても何だパクリじゃないか」と言われれば確かにそうかもしれません。
実際、かなりの部分で参考にさせて頂いたのは事実です。
では、何故そのような状況でこのZusaarを作ったかというと、
既存サービスにおいては、機能の不足からいくつかの問題で困っている方が多く見受けられ、
実際そのニーズを満たすものが存在しなかったことがきっかけでした。
既存サービスの問題点
- 参加者のキャンセルが多く、主催する側の金銭的なリスクが大きい
- 主催者から参加者への連絡手段が乏しく、変更などの通知が困難
Zusaarはこれらの問題点を解決する為に作りました。
Zusaarの特徴
Mixi対応について
Twitter、Facebookと並んで国産のMixiでもMixi Graph APIというものが公開されています。
開発当初、こちらを使ってMixiのアカウントでもZusaarにログインできるようにしたいと思っていました。（というか実際作りました。）
しかしながら、
Mixi Graph APIでは、どのような手段を用いても上記のメッセージ通知機能が実現できないことがわかったため、泣く泣く採用を見送りました。
メッセージ機能は参加者のプラットフォームを問わずに横断的に通知できることに意味があるため、
Mixi対応をするには、メッセージ機能を断念するという事になるからでした。
今後、Mixiのポリシーも変更する可能性があるとのことでしたので、期待して待ちたいと思います。
最後に
開発前、開発中に考えた事をつらつらと書いてみました。
もしよろしければ使って頂けるとうれしいです。
問題点、疑問点、改善点などあればお気軽に @knj77 までご相談ください！
GAEの画像配信を速くする方法
AppEngineに画像ファイルをアップロードする場合、
DatastoreにBlobとして保存し、表示するときはDatastoreから取り出したデータを
Responseに流し込むことで表示するのが今までのやり方でした。
この表示は非常に遅く、問題でした。
SDK1.3.0で追加されたBlobstore APIを使うと、
http://code.google.com/intl/en/appengine/docs/java/blobstore/overview.html
Picassaのインフラから配信されるらしく非常に高速になるとの事でしたが、
Slim3のasStringが動かない（？）、処理結果は必ずredirectしなければならない（validate情報をforwardできない）、など
既存のアプリに組み込むには苦労がありました。
しかしながら、SDK1.4.3に追加されたFileServiceを使うと（Experimentalだけど）
http://code.google.com/intl/en/appengine/docs/java/blobstore/overview.html#Writing_Files_to_the_Blobstore
プログラムから、直接Blobstoreに画像データを書き込むことができます。
FileItem fileItem = requestScope("image");
FileService fileService = FileServiceFactory.getFileService();
AppEngineFile blobFile =
fileService.createNewBlobFile(fileItem.getContentType());
FileWriteChannel writeChannel =
fileService.openWriteChannel(blobFile, true);
writeChannel.write(ByteBuffer.wrap(fileItem.getData()));
writeChannel.closeFinally();
BlobKey blobKey = fileService.getBlobKey(blobFile);
このblobKeyをDatastoreに保存し、表示時には
String imageUrl = imagesService.getServingUrl(blobKey);
のimageUrlを呼びます。
こうする事で、既存のアプリをあまり変更することなく
Blobstoreの高速配信が出来るようになります。
追記
その実例がコチラです。
http://www.zusaar.com/event/agZ6dXNhYXJyDAsSBUV2ZW50GNk2DA
CakePHPのmodelを動的に生成する方法
CakePHP Advent Calendar 2010に衝動的に参加させて頂く事にしました。
http://cakephp.jp/modules/newbb/viewtopic.php?topic_id=2510&forum=16&post_id=6341
しかしながら冷静に考えるとCakePHPにどっぷり浸かったのは1年以上前なので情報が古いかもですがご容赦ください(^^;
申し込んだ当初はDatasourceネタにしようと思っていたのですが
id:kaz_29 さんのすばらしい記事が上がりましたので別のネタにしようと思います。
CakePHPのmodelを動的に生成する
通常、CakePHPを使った開発だと、DBのテーブルの数だけModelクラスを静的に定義するのが普通だと思います。
しかしながら、マスター系のテーブルなどは単純なCRUDしかしないのに同じような作業を繰り返したり、
致命的なのはModelクラスの数が多くなってくるとリクエスト毎に全クラスをロードして遅くなったりする事だと思います。
そこで、以下のように動的に生成することで上の問題を回避できます。
// AppControllerなど、どこかで一度だけ。
loadModel('AppModel');
// Modelが必要な度に。AppModel内でメソッド定義するといいかも。
$name = Inflector::camelize(low($tableName));
$model = new AppModel(array('name' => $name, 'table' => $tableName));
（CakePHP1.3では動作確認できてません。すみません...）
個別ロジックが必要なModelはもちろん静的に定義して、ロジックもガシガシ突っ込んで、
それ以外のModelに関してはこの方法で書くとすっきりします。
徹底すれば、物理的なテーブル定義から解放されて、
論理的なModelの上にアプリケーションを構築できるのが大きいと思っています。
簡単ですがこんな感じでいかがでしょうか。
MA6ひとり反省会
MA6に出した作品が落選したようです。
http://ma6works.mashupaward.jp/oubo/342/
途中から思いつきで参加したくせに、いざ落選してみると、結構ショック。いや、すげーーショック。
応援して頂いた方々、どうもすみません。
絶大な自信があった訳ではもちろんないけれど、出来てみると周りの方々からそこそこの評価を頂いていたので、
ちょっと夢見てた分、反動があった。
そんなこんなで、少し凹んだんだけど、これ以上引きずりたくないのでここにまとめて前に進む！
便利さの欠如
落ちた原因はこれに尽きると思っている。
完全に推測だけれども、MA6の審査ポイントは「便利さ」に重点があったのではないかと思う。
僕の作ったアプリは、見た目の面白さ・派手さを追ってしまって、その点が足りなかったと思う。
「面白いねー、で、結局何に使うの？」という点は自分でも答えがないままになっていた。
「はてブ」をみて思いついたアイデアだけど、現在のはてブはdisりツール、炎上ツールと化している側面もあり。
何かを解決する、改善するアプリではなかった。
→この点は「グループ内での共有メモ」化する事で急に便利になるとは思う。（MA6の期間内では無理でした...）
ここの資料にあるように、 http://bit.ly/bjfvyf
「自分が作りたいと思うサービスと、ユーザが使いたいと思うサービスが一致するよう訓練」
これが決定的に足りてないなーと身を以て実感できた。いい勉強させてもらいました(^^;
上にも書いたとおり、落ちた原因は完全に推測ではあるけれど、
仮に間違っていても、反省点は間違っていないので良しとする！
というか、落ちた原因なんて審査員以外は誰もわからないのでそうするしかないよね(^^;
あるいは、万が一明日以降に入選の連絡があったとしても、
やはり反省点は間違っていないので、ここに残して自戒とする。
