2012年9月28日金曜日

package名がダサい | Play Framework2.0 ここんがんばれ!(その1)

最近Javaのフレームワーク「Play Framework2.0」を使っております。
http://www.playframework.org/


http://www.playframework.org/

しばらく使ってみて色々と思うところがあったので、今回から書いて行きたいと思います。
Playは最近Version2.0がでたようです。というか、1の時代は知りません。
その特徴とは・・・いまいちよくわからないので調べてみました。
http://gihyo.jp/dev/serial/01/engineer_toolbox/0030
Playは,Ruby on Railsのように簡単なコマンドだけでMVCスタイルのWebアプリケーションの雛形を構築し,開発をスタートさせることができるフレームワークです。
そうだったのか。コマンドベースでモデルとかを作ったこと無いぞ・・・。
ちなみにPlayは Ruby On Railsの設計思想を受け継いでいるようです。

さて、そんなPlay2.0の特徴はと言えば・・・



  • JavaおよびScalaのネイティブサポート
  • 強力なビルドシステムの構築
  • 型安全性へのフォーカス
  • 非同期プログラミングのより強力なサポート
  • データストアとモデルのよりシームレスな統合
とのことです。

  • Java EEを使用しない軽量フレームワーク
  • 軽快な動作
  • 開発環境構築が簡単
  • 他のJavaフレームワークに比べて高い生産性

Scalaのネイティブサポートということで、フレームワーク自体はScalaで書かれています。フレームワークに手を入れようとすると、Scalaで書かなくちゃなりません。

ビルドシステム・・・
play compileでビルドできます。

動作軽快、なんですかね?

開発環境構築は割と簡単です。その後の開発スピードも上がるかどうかは別問題です。


で、実際使ってみてどうよ?というところですが、いいところもありますが、人間どうしても気になるところに目がいってしまいます。さてそんな気になる点をピックアップして行きましょう。


まず、パッケージ名がダサいです。
なんとなく作ろうとすると、

package controllers
package views

みたいなパッケージ名になります。

あれ・・・Javaお得意の
org.apache.common的なパッケージ名はどこ行った・・・?
と衝撃を受けます。

ああ、どうやら僕らは古いしきたりに縛られていたようです。

2012年8月22日水曜日

東京ノマドカフェマップを公開しました。

この度、東京ノマドカフェマップを公開しました。

ノマドは最近バズワードのように扱われていますが、ノマドワーカー向けにはドロップイン利用できるコワーキングスペースなどがあり、そのサポート環境は次第に整ってきています。
そういったノマドワーカーやコワーキングスペースを応援したいと思い、このサイトを立ち上げました。


http://www.rte.jp/

2012年6月17日日曜日

Coworking Conference TOKYO 2012に行って来ました

昨日は品川で行われたコワーキングのイベントに行ってきました。
http://cct2012.coworking-jp.org/

入り口でいきなり名刺を求められちょっと戸惑いました。
ちなみにスポンサーとして、コクヨ、チャットワークが協賛してました。
今までの勉強会とかだとそんなに規模大きくなかったのでちょっと面食らいました。

さて、会場に入ってみるととても大き会場です。そしてスタッフの数が多い。もしここで狩野英明が「スタッフー」って言ったら、大変な数のスタッフが集合することでしょう。

とりあえず席につきます。
広い会場でしたが、席の埋まり具合も結構埋まっていたように思います。

午前中はパネルディスカッションでした。
「いま、なぜコワーキングなのか。そして未来へ」と題して、パネルディスカッションが始まりました。

コワーキングは2年くらい前に初めて日本に導入され、まだまだ歴史が浅いということを知りました。
そしてここ半年急激に盛り上がりを見せているようです。

話しの中で、今まで疑問に思っていた、ノマドカフェとコワーキングの違いがわかりました。
ノマドは移動して一人で作業するイメージ、コワーキングは周りの人と喋りながら作業するイメージといったところでしょうか。

コワーキングが周りの人とディスカッションしながら作業をする、というのが衝撃的でした。でもよくよく考えれば、シェアオフィスとの違いもそこにあるんだろうし当然ですね。
僕自身は週末にノマドするだけなので、まあ一緒の場所でそれぞれ別の作業をしている人、として周りの人やお店の人と話すことなんてまあ無いのですが、コワーキングはもっとコミュニケーションを活発にとっているみたいです。

まずは人のコミュニケーションありきで、それを提供する場所としてコワーキングスペースがあるといった感じですね。コワーキングスペースは結構勉強会とかのイベントをやってますが、その理由がわかりました。

コワーキングという働き方はある意味人のスケールアウトなどがしやすい仕組みなんだろうなと思いました。会社組織化すると一旦増やした人はそうそう減らせなくなるけど、コワーキングだとプロジェクトに合わせて人を増減できるメリットがあるんだなと感じました。

さてそのあとは何故か鏡開き。日本酒が振舞われました。日本酒ハッカソンでしょうか。


午後は各コワークングスペースのブースを回りました。
いくつか気になったところがあったので、今度回ってみようと思います。
どうやらコワーキングスペースのオーナー同士の交流の場にもなっていたみたいです。
なかなかそういう情報交換する機会なさそうですもんね。
来ている人もそういう関係の人が多かったように思います。僕みたいなただの利用者はあんまりいなかった気がします。

やはり下北沢にあるオープンソースカフェこけむさズがきになっています。

オープンソースカフェは普段twitterでフォローしている人とかも結構来ているみたいです。憧れのアノ人に会えるかも!?それに会場には@yandoさんが来ていたので色々話をさせて頂きました。

こけむさズは高円寺にあるコワーキングスペースです。
ドロップイン利用はないかと思っていたけど、どうやらドロップインもやっているらしいので、今度遊びに行ってみたいと思います。

久しぶりに新しい人との出会いを体験できて楽しい一日でした。
結婚してもこういうのに送り出してくれる嫁に感謝。

2012年2月19日日曜日

PHPで何か作ろうかいに参加しました!


昨日は久しぶりにがっつりPHPを触りました。
今年は1ヶ月に1回勉強会に参加することを目標にしているんですが、今月はPHPで開発する会に参加しました。
http://atnd.org/events/24119

先月の勉強会は聴講形式だったんだけど、実際に手を動かすほうが自分にはあってるかも、と思っての参加でした。

新橋についてドキドキしながら会場に到着。
部屋に入るとどうやら僕は2番目に到着。
参加者は全部で15人弱でした。

朝11時に各自テーマ発表をして、そのあとはひたすら開発をします。
PHP以外の言語を触ってる人もいて自由な感じです。
途中でランチを挟んで午後も開発。

僕は実はなかなかテーマが決まらなくて、前々から結婚式関連のサービスをやってみたいと思ってたんですが、勉強会に向けて最終的にこのテーマに決定しました。
テーマの詳細はサービスリリースしたら発表します。

今回はsymfonyを使って開発をしたんですが、symfony2はお作法が多くて、なかなかそのルールに則って開発をするのが難しかったです。
ベタで書けば直ぐなんだけど、Twigの書き方に従うと、とかFormオブジェクトにどう指定を知ればいいんだろう、とか・・・。

まだFacebookでのログインやら1対多によるMapの作り方を勉強していかないと・・・。

そしてなんとしても、リリースまで漕ぎ着けたい!!!

参加者のMac率は思ってたより高くなかったです。
そして年齢層も、自分と同じくらい(だと思う)人が多かったかな。

勉強会の成果発表をして、みんなで飲みに行きました!
いろんな話が聞けて楽しかったです!

そして、意識高い技術者がいっぱいいるなあと感じました。
普段だとどうしても社内だけでの意見交換になってしまうけど、他の会社の技術者と話をするのはとっても刺激になりました!!!
社外の技術者との交流を広げたい、というのもあって勉強会に参加しているんだけど、飲み会で交流を深めることができたのでよかったです。

GitHubでもサービスでも、公開することに意義があるなあと改めて感じました。
もっともっと負けたくない!という気持ちを強く持ち続けていないと。

また参加してみたい!!!
とてもいい一日でした。

主催してくれた@honbinさんありがとうございました!!!

2012年1月21日土曜日

第2回shinagawa.redmine勉強会に行ってきたよ

今日は「第2回shinagawa.redmine勉強会」に参加してきました!
勉強会への参加は初めてでした。有意義な時間が過ごせました!ちなみに場所は品川じゃなく、文京区のIPAでした!

資料はきっとどこかに上がるでしょう。
http://shinagawa.redmine.r-labs.org/projects/shinared/wiki/%E7%AC%AC%E4%BA%8C%E5%9B%9E%E5%8B%89%E5%BC%B7%E4%BC%9A

Ustreamもやってたみたいなので、気になる方はそちらもチェック!ということで、鉄は熱いうちに打て、という事で今日聞いてきたことをまとめます。(1回書いたのが消えたので、簡単に書きます)
解説とそれに対しての僕の感想という対になっています。僕の心に引っかかかった部分だけ取り上げているので、全体的な話の流れは、上記URLの資料から見ていただければと思います。

楽天での数千人オーダーでの運用
・バージョンアップは頻繁にやらないと人がついてこない
うちの会社は1.0のまま(まあ単に僕がアップデートをサボってるだけですが)。プラグインが障害になってる(ロードマップ拡張するプラグインは余り使われてない割にDBを書き換えてるので厄介ですな。消しても誰にも文句を言われなさそうなので消してしまいたい。)。
そろそろここらで一度最新バージョンにしておきたいです。ローカルのVMに同じ環境を用意するのが面倒でなかなか手を付けられないで居るんですが・・・。

・最近はアナログツールを使っている
やはり最後はそこになると思う。
導入して最初の頃は、すべての機能を使おうと思っていたけど、どうやらそれは方向が違うらしい。フォーラム・文章の違いとかね。自分だけつっ走ってみたが、誰もついてこなかったw。プラグインも入れすぎたw。

細かい作業を要求しても、それって本質的ではないんだよなーと、2年使ってようやくわかりました。リリース前日に急激にチケット消化が始まるとかね。(フィードバック待ちを完了にする)結局最終的にうちの会社もチケットには概要を書いて詳しい説明は口頭でやってる感じだな。
一応プロマネはロードマップ画面をメインに見て、開発者はチケット画面をメインに見てる感じです。

そしてやはりRedmineのwikiは使いづらい。
1つのツールにとらわれないことが大事ですね。

まとめ
・使いたくない人も使わされる
Redmineを使わないと悪、と考えてしまいがちだけど、そうじゃないということを考えておかないとですね。
・本当に必要かを考える必要がある。
ツールはあくまでツール。目的を達成するための手段ですね。これつい先日社長に言われたわw。
・個人と対話が重要ではあるが、プロセスとツールは軽視できない。
やはり個人と対話が重要なんだなあと最近思ってることと合致した。おれはプロセスとツールを重視しすぎて人を見てない・・・。チケットコメントで極力支持しようとするけど、変更するファイルのパスとかだけでいいんじゃないかという議論が。
Redmine至上主義じゃなかったのがすごい印象的でした。有りがたかったです。


日本語検索
とりあえず導入が手間そうだった。俺には耐えられない・・・。きっと依存関係でいろいろと試行錯誤されたんだなあと感じました。
CPANですらたるいのに・・・。

ああ・・・添付ファイルも検索できれば便利なのに。なんて考えてた自分。甘かった!
paco(インストールしたライブラリの管理)初めて知りました。
基本yumしか使わないからな・・・。管理できないからソースからビルドしてインストールあんまり使いたくない、と思っていたけど、こういうのあるんですね。


プラグイン開発
rubyもMVC構造なんだね。PHPでCakePHPとかSymfonyとかMVCでの開発慣れてれば結構開発できそう。設計思想さえ把握できれば、ループとかifは覚えちゃえば問題ないから。コマンドでMdel,Controllerが作れるのはいいっすね。あViewもですね。
話がわかりやすかったです。

これって、Model作ったときには直SQLは生成されるんだろうか?DBのマイグレートプログラムは作られるみたいだけど・・・。

既にインストールしてしまったプラグインが作ったSQLをごそっと全部消したいんだが、ALTER文でいいのか、DELETE文でいいのか、DROP文でいいのか、CREATE TABLEしたSQLとかあれば判断できるんだけどなあ。(ロードマッププラグインがここでも懸念なんだよね。既存テーブルを拡張するプラグインはバージョンアップ時の足かせになるわ。あくまでテーブル追加のプラグインだけ今後は使おうと思う。)

ALMinium
初めて知りました。うちの会社のパッケージ名やクラス名にAL使うことが多いので(会社名がaimluckなのでAL)親近感がわきました。
既にRedmineインストールしてあるので、使う場面はないけど。rubyのバージョン依存とか正直しんどいから、こういうのあると便利ですよね。バージョンアップ時にrubyのバージョンも上げないととかだいぶしんどいっす。これもまたRedmineのバージョンアップの障壁ですね。PHPだったら使い慣れてるからいいけど、ruby案件はほぼ無いからなあ・・・。

Subversionもインストールされるっていいよね。とにかく環境準備が大変という最初の障害を下げるのは大切ですよね。Redmineは開発者だけのものじゃないと思うので。(あ、開発者じゃなければ、Subversion使わないか・・・)
うちの会社もお問い合せ対応にも使ってます。過去のやり取りも把握できるので便利ですよね。昔はメールベースのmeruruなるシステム(OSSを拡張したシステム)使ってましたが・・・。
プレゼンが面白かったです。

LT
プロジェクトの火消し
・親子チケットはやめる
納得できました。正直社内で俺以外誰も使ってなかったw。めんどくさいんだよね。しかもキーの依存関係かなんかで、ステータス変更できない、削除できないチケットもできた。
社内ではインターントレーニング用に雛形の親チケットと子チケット4つをコピーするようにしてたんだけど、めんどくさかったわ。チケットコピーだと親子関係設定し直しだったし。今もうやってない。

・カスタムクエリで進捗状況を把握
これはぜひともみんなやるといいのに。他人のカスタムクエリをコピーできれば便利なんだけど。俺の見てる世界をみんなにも見せてあげたい。

僕の場合は複数プロジェクトが進むことが多いので、プロジェクト単位でグループ化して自分のチケットを確認できるようにしています。

同じチームのメンバー(アルバイト)のチケットも同じようにプロジェクト単位で見るようにしています。アルバイトのみんなはコミット権限がないのでみんなが対応してくれたソースを僕がレビューしてコミットしてるんだけど、その進捗確認が簡単にできるようになります。フィードバック待ちになったからレビュー始めるか・・・とかね。まだ作業中で時間かかってるからちょっと様子見るか、とかね。←こっちはあんまりできてない悪い社員です。

PDF日本語文字化け
どうやら一筋縄ではいかないようで。これが出来ればお客さんにそのまま渡せるようになるんだけどなあ。4年間放置って・・・。よくありますよね。

特に炎上しそうなプロジェクトになると、週次レポートを作るようになるんだけど、そのチケットをまとめる作業で金曜の半日が潰れるという。その半日、開発進めたほうがいいんじゃね?的なね。

Graph Activity
・時間・曜日・回数をグラフ化
・夜型人間を改善させる。
こういう集計面白いよね。うちはどんな結果になるんだろう。
アルバイトも多いから、興味深い結果になりそうだけど。

なかなかあれを入力しろ、これを入力しろといっても上手くいかないけど、チケットのコメントはだいたい使われているので、それを解析するのはとっても有効だと思うんです。
Redmineってチケット作ってコメント残すのが主な作業だからね。
解析するために入力する、という流れじゃなく、入力されたものを解析するという正しい流れですね。
いま週3回リリース作業してるから、リリース作業担当者によって、どのタイミングから作業し始めてるか分かるようになるかも。

管理者からのバナー表示
これよさそうだけど、うちの会社でやったら社長になんか言われそう。
個人的にはかなり好き。あんなお知らせされたら、寄付されそう。ポケットマネーで。
うちの会社はツールにシビアなので導入されないかな・・・。まあ人数少ないのでメールでの通知で事足りそう。まあNAS再起動は声かけしてやってるくらいだから。
個人的にはだいぶ好き。ツールは楽しく使わなきゃね。

CandyCane
http://my.candycane.jp/
めっちゃ進化していた!プラグインを管理画面から追加・削除できるのはいいよな。
PHP好きな、CakePHP好きな僕としてはとっても気になる存在です。
rubyのインストール方法を都度調べてるような僕ですから。あ、今度rubyのバージョンアップしなきゃダメ?バージョン低いみたいだけどyumで提供されてるのここまでだからとりあえず動かしてみていい?みたいな感じなので。PHPの方がまだバージョンアップを追えているので。。。



初めての勉強会でしたが、他社の事例・使い方やプラグイン開発方法など知れて楽しかったです。
どうやら悩みはどこも一緒のようで・・・。
まあ一番は使いたいように使うというのがいいのかな。

ツールに使われないように、付き合っていこうと思いました。
なんだかんだRedmine大好きだからなー。目的を達成するためのツールという意識を忘れがちなので気をつけなきゃ。

スピーカー・スタッフの皆様有り難うございました。

@aimluck_iwasaki

***

初めて勉強会に行ったけど、ノートPCを全員が持ってるわけじゃなくて安心した。
そしてMac率高いかと思ったけど、それほどでもなかった(半々くらい?)。でもMacユーザーはAirが多かったようです。

そろそろ次を買おうか(今はポリカーボネイトの白いヤツ)と思っていたので、参考になりました。インチ数はどれくらいだったんだろう?11インチ?13インチ?次買うなら13インチかなあ・・・。ちなみにちなみに、ポリカーボネイトのMacは超絶重かったです。体鍛えてんのか、と思うくらいでした。
アルミ筐体よりは好きなんですけどね。

目が悪いので前の方の席に座ったけど、結果よかった。

初めての勉強会、とってもいい経験になりました!
親睦会には参加できなかったけど、次は参加者ともっと親睦深めて色々話を聞いてみたいと思いました。