Scala + Liftの参考になるサイト

3/27時点(Scala2.8.1.final、Lift 2.2)での参考になるサイトです。
Scala + Liftは、web上で無料で読める書籍が満載です。
Scala + Liftでアプリを作成するなら以下の辺りは一通り読む必要があるかと思います。基本英語ですが。

Lift

  • SimplyLift(英語)

view関係が一通りまとまっている。一番新しい。
http://stable.simply.liftweb.net/

  • Exploring Lift(英語)

Liftについて一通り書かれている。
http://exploring.liftweb.net/master/index.html

一番細かく書かれている、かな。
http://www.assembla.com/wiki/show/liftweb/

  • Lift Demo(英語)

実際に動作するアプリとソースがある。
http://demo.liftweb.net/

liftで作られた簡単なサンプルがある。
https://github.com/tjweir/pocketchangeapp/

  • Scala+Liftによる実践Webアプリケーション開発

http://codezine.jp/article/corner/322

SIerを辞めて、Webの広告屋になりました。

2/15付けで6年間お世話になったSIerを退職して、翌16日からWeb広告とかを行っている会社に入社しました。
これまでお仕事を一緒にさせていただいた方には感謝の気持ちでいっぱいです。
いままで大変お世話になりました。今後とも宜しくお願いします。

会社を移るに当たって、色々悩んだりしたことも多かったので、気持ちの整理をする意味でも、個人的なことですが、心境などを書いてみたいと思います。

正直、いざ会社を辞めるとなるとこれまでお世話になった方や自分の部下などに申し訳ない気持ちであったり自分の判断が正しいのか悩むことも多かったです。
上司が自分のことを高く評価してくれていることも改めて知ることが出来ました。

初めての転職でしたが、すごく寂しい気持ちになったりストレスがたまるので、転職には強い意志が必要だと思います。

これまでどのような仕事をしてきたのか?

簡単に私が今まで携わった仕事を簡単に振り返ってみます。

一番長かったのは、研究開発部門でJavaフレームワークを作ったりしていました。
開発プロセスを考えたり、プロジェクト支援でアーキテクトとして、プロジェクトの立ち上げを手伝ったりとかもしてました。

最近、2年ちょいは、金融系の大規模プロジェクトの立ち上げから携わって、ようやくリリースを迎えました。仕事的にはアーキテクトやPM仕事をしていました。
長期プロジェクトをなんとかリリースすることが出来たということも会社を辞めるきっかけになりました。

仕事以外では、ITProやマイコミジャーナルとかに記事を寄稿したりもしました。
特にITProは1年半くらい連載を書いていました。

技術指向が強いので、これまでやってきた仕事には非常に満足しています。
前の会社は東証一部でそれなりに大きい会社ですが、技術的なことをたくさん学ぶことが出来て、入社して良かったと思います。

なぜSIerを辞めることにしたのか?

いくつか理由はあるのですが、一番大きかったのは、自分のシステムやサービスを作りたいという思いがありました。
SIerだとお客さんのシステムを作って商売をするという業界なので、どうしても受け身になりがちです。

さらにリリースしたあとにお客さんの反応を知ることがあまり出来ないので、作ったシステムがどう評価されているのかわかりにくく達成感を感じにくいです。

SI業界の将来について悲観的だったことも理由として挙げられます。
最近ではオフショアで中国に仕事を投げることが多くなってきました。

正直、中国の技術者には日本人より優秀な人がたくさんいます。
今後は、よりオフショアが増えてくることは、逃れようのない事実だと思います。
そうすると日本人は要件定義や設計とテスト、品質管理を担当することになります。
これまで以上に業務知識が重要になってくると考えられます。
業務が3度の飯より大好きで、同じ業界でずーとシステムを作り続けたい人なら業務に特化できて楽しいと思います。

そのかわり、よその業界のプロジェクトに入ったらまた一から勉強し直しになってしまいます。
ベテランの優秀な技術者でも業界が変わると移動先の業界を何年か経験して来た若手の方が業務知識が豊富で仕事ができるようなことが起こりえます。
そう考えると優秀な人でもそうでない人でも同じように扱える人月の壁を越えることがより難しくなると思います。

クラウドは情報系のシステムで少しずつ増えてくるとは思いますが、まだ本格的に使われるようになるには年数がかかるとは思います。
クラウドでもセールスフォースのような圧倒的に生産性が上がるもの以外のGAEとかが流行って来たとしてもインフラを除いた開発工数はそれほど減らないので、結局はオフショア開発になるような気がします。

もう一つの理由としては、そろそろ私自身にマネージャとしてノルマがかけられて来そうだったことです。

将来、管理職としてノルマを課せられていくのは、仕方がないことだと認識しています。
ただ、私はまだ28歳になったばかりです。

売り上げのノルマがかかってくると、つまらないプロジェクトでもノルマ達成のために受ける必要があります。
正直、まだまだ、面白いプロジェクトに携わりたいしやりたいことをやりたい。

面白くて稼げるプロジェクトを自分でさがして来れれば良いのですが、私にはそこまでのコネや力がまだないです。
営業の方なんかだとわかると思いますが、そもそも仕事を探すことは簡単に出来ることではないです。どんどん私の仕事から技術要素がなくなっていくような気がしていました。

細かく言えば他にもありますが、SIerを辞めることにした理由はざっとこんな感じです。

なぜWeb広告会社なの?

私が転職するに当たって、Web系の会社(ソーシャルゲーム除く)に入りたいと思っていました。
ただサービスが成熟しすぎていないこと(保守ばっかりもやだ)や色々と新しいことに取り組んでいる会社が良いと思っていました。
とはいえ、会社がいつ潰れるかわからないベンチャーもどうかなという感じもありました。

転職活動は、以前から付き合いがあったヘッドハンティング型の人材紹介会社のエージェントの方と進めました。

たまたま、エージェントの方から今の会社を紹介され、話を聞いてみると、「これからは内製で開発したいとか色々新しいものを作ろうとしているとか君みたいな技術指向の人に来てもらいたいとか」という話で面白そうだったので入社させてもらうことにしました。

なので最初からWeb広告の業界に入りたかったわけではないですが、がんばっていきたいと思います。

数日働いてみた感想

内製比率がまだまだ低いので、仕事を受託する側から発注する側になったような感じです。
これからどうなっていくかは私のがんばり次第な部分もあるのでがんばりたいと思います。

あとは、オフィスがおしゃれだったり、無料でコーヒーが飲めたり、服装が私服だったりします。
女の人も多いです。まだほとんど絡みないけど。

だらだら書きましたが少しでも誰かの参考になれば幸いです。今後とも宜しくお願いします。

Javascriptやcssはいつ圧縮するか

ネットワーク負荷を抑えるためにapacheでmod_deflateを使う他に圧縮ツールでJavascriptcssのファイルを圧縮したりしています。

圧縮するツールは、最近だとYUI Compressor辺りがメジャーですが、色々な種類があり、紹介記事などもよく見かけるのですが、現場ではどのタイミングで圧縮をかけたファイルと元々のファイルを入れ替えているのでしょうか?デプロイするたびにHTMLに記述されているscriptタグの記述を変更するのは面倒なので、変更なしに圧縮版と通常版を入れ替えたいところです。

最近の圧縮ツールでは、オンラインとコマンドラインで圧縮出来る場合が多いです。

最近googleから公開されたGoogle Closure Compilerもオンラインとコマンドラインで圧縮することが出来ます。気になっていたのでこないだUTF8のJavascriptファイルをbatファイルからコマンドで叩いて試してみたところ、日本語が文字化けしてしまいうまく使うことが出来ませんでした。YUI Compressorでは、エンコードの指定が出来るのですが、Closure Compilerだとまだ出来ないのかな?という感じです。

でオンラインとコマンドラインのどちらを使うかですが、オンラインで圧縮するのはとりあえず試してみるという感じのときには便利ですが、基本的にはコマンドラインを使うのが便利だと思っています。この辺は開発言語とかによる部分もあるのかもしれないですが。

私の場合は、Javaのプロジェクトなので、EARファイルを作成してAPサーバにデプロイするというスタイルです。

EARファイルを作成する前に元々ある開発用のJavascriptcssファイルをxx.js.bakなどにリネームして退避させて、そのファイルを使用して、元々あった開発用のファイルと同じ名前の圧縮済みファイルを作るbatファイルを作成すれば簡単に入れ替えることが出来ます。batファイル自体は、10行、20行位で簡単に作れると思います。

さらにantやmavenでbatファイルを実行して、さらにEARまで作成してしまえば、圧縮し忘れることなく行うことが出来ます。

クライアントでキャッシュされているJavascriptcssでもWebサーバにアクセスしてしまうので、1つのファイルにまとめてしまうのがよいのですが、1つのファイルにまとめてしまうとscriptタグの記述を変更する必要があったりして、それはそれで不便です。またエラーが発生した場合などに解析が大変になるので、そこまでやるかどうかは、プロジェクトの判断によるところです。アクセスする回数を減らすためにapacheのmod_expiresを使うとよいと思います。

うまくまとまっていないですが、
Q. Javascriptcssはいつ圧縮するか?
A. デプロイする前にJavascriptcssを圧縮するbatファイルを実行して切り替えればいいよ

という感じで終わらせていただきます。

jQuery UIでメモリリークに悩まされる

プロジェクトでjQuery1.3.2とjQuery UI1.7.2を使っている。

UIで使っているのは、dialogとタブくらい。
dialogは、ほぼ全部の画面でボタンを押すと表示させている。登録ボタンの「登録しますがよろしいですか?」や入力内容に変更があった場合に「編集内容を破棄しますがよろしいですか?」みたいな内容を表示させている。

IE8ではあまり増加しないけど、IE6と7ではボタンを押すたびにメモリが増加していって、動きがもっさりしてくる。

メモリリークを調べるために「sIEve0.0.8」を使っている。Drip0.5よりもこっちの方がよさそう。さらっとだけどリークしている場所を教えてくれる。

原因は色々ありそうだけど、UIのdialogの影響が大きそう。

jQuery UIのTracをあさっていると色々メモリリーク関連のチケットが出てくる。いくつかパッチを当てたらだいぶマシにはなってきた。まだこのままリリースするにはちょっと厳しいけど。

今調べていたらいくつか気になるチケットがあった。

Huge memory leaks for all widgets in IE6のパッチは既に当ててたんだけど、IE8でもメモリリークするって書いてある。

あと、Including ui.datepicker.js causes a memory leak in IE6は今見つけたんだけど、ui.datepicker.jsが含まれているとメモリリーク起こすみたい。確かにsIEveで調べていたら、使っていないdateipckerが掛かっていてなんでだろって思ってたんだよね。全部入りのjquery-ui-1.7.2.custom.min.jsを使っているのが悪いみたい。明日対応しよう。

今上がっているjQuery UIのチケットは1.8で解決されるのが多いので、1.8が出たらそっちに乗り換えたほうがよさそう。まだ、1.8a1とかだからリリースされるのは当分先っぽいけど。jQuery UIはまだメモリリークが結構発生するみたいなので、採用する場合は、事前に使う機能がTracのチケットに上がっていないかを眺めてから決めたほうが無難。

最近はメモリリークのほかにクライアント側の性能問題に悩まされている。IE8だとそれなりに動くんだけど、IE6だと目も当てられない。その話しはまた今度。

JavaScript内でJavaEEのオブジェクトを華麗に使いたい

実際に体験した人じゃないとわかりにくいかもしれないけど、
JavaScriptを組んでいるとJavaのセッションスコープにとかに入っているXXっていう値と比較したいなどの場面がよくある。

例えば、ボタンを消したりとか要素を非表示にしたりとか。
初期表示で消すだけでよいならJSPでcタグとEL式なんかをあわせてやればよいのだけど、画面内での操作によっても変わる場合は、JavaScriptを使う必要がある。

JavaScriptJavaの連携は、以下みたいな感じにすると出来ちゃうんだけど、JavaScriptの中にスクリプトレットを書くのはあんまり。

if (aaa == <%= req.getParameter("aaa")%>) {
  // aaaがリクエストスコープに入っているaaaと同じだった時の処理
  // ボタン消したり・要素を非表示にしたり
}

そもそもこんなソースをかけることを知らない人も多いしね。

で、うちのプロジェクトで良く使っているのが、JSP内で一旦hiddenに入れてからそれをJavaScriptで取り出すという方法。

JSP

<input type="hidden" name="aaa" value="${aaa}" id="aaa">

JavaScript(※jquery)

if (aaa == $("#aaa").val()) {
  //
}

うーん。hiddenを使用するのがいただけない。リクエストで飛ばしたいのか画面内で使用したいのかがわからなくなって、メンテナンス性が悪い。なので個人的には、この方法は嫌い。

最近好んで使っているのは、以下のような方法。

JSP

<div id="aaaDiv" style="display:none;"><c:out value="${aaa}"/></div>

JavaScript(※jquery)

if (aaa == $("#aaaDiv").text()) {
  //
}

divを使っているのが微妙なんだけど、画面内で使う値とリクエストで飛ばしたい値を分けられるので、コチラのほうが、hiddenを使うよりわかりやすい。

とはいえ、JSPに余計なソースを記述しなければいけない。もっとシームレスにつなげる方法ってないのかかしら。

Spring 3.0には一応Struts関連のクラスは残されることになったみたい

最近は忙しさにかまけて、ブログをほったらかしにしていましたが、Spring 3.0 RC2が出たので、中身を見ていました。

RC2で最後のはずなので、もうすぐ最終版がリリースされそうです。

Spring 3.0の新機能は、JSR330(@Injectとか)、REST、OXM(Object XML Mapping)、JavaConfig、SpELなど一部の人にとってはうれしいかもしれないけど、
普通にWebアプリを作りたいだけなら、どうでもいい機能が山盛りです。

@MVCは、JSR303がサポートされたので、便利になっていると思います。

で日本では、SIerを中心にまだまだSpring + Strutsの構成が多いのですが、そのStrutsサポートがどうやら復活したみたいです。
(RC1の時点であったかどうかは未確認。)

これまでは、ソースごとさっくり削除されていたのですが、org.springframework.web.strutsというモジュールで復活していました。
ただし、すべてのソースに@Deprecatedがついているので、一応残してやっけど、次は消すからなという感じみたいです。

SIerは、Spring + Strutsの上に独自のフレームワークやら自動化ツールなどを作っているところが多いので、
今のままとどまるか@MVCに移行するか、はたまた全く別のフレームワークに移るのか。

不況で研究開発費とか出なそうだから現状維持になるところが多そうだなぁという感じ。

ぼくはけっこうymirとか好きですけどね。
それじゃあね。

周りが気になるなら入ってくる情報を制限した方がよい

プログラマやデザイナをやっているとPCを利用している時間が多いので、
どうしても入ってくる情報が多くなる。

技術の進化は日進月歩ですぐに新しい話題が上がってくる。
最近だとGAEやAmazon EC2をはじめとするクラウドだったり、
iPhoneAndroidなどのスマートフォンも話題だしHTML5なども熱い。

これは僕自身にも言えることだけど、あたらしもの好きの人にとっては、
情報が多く入ってくることはプラスであり、マイナスでもある。

世の中は、残念なことに一日が24時間と決まっている。
もちろんその中で、睡眠もある程度とる必要がある。

そこそこ忙しい人だと、平日は6時30分位に起きて、家に帰るのは23時位というのは、けっこうざらにある。

そうなってくると自由に勉強できる時間は、限りなく少ない。

そんな人がブログなので著名な人が、iPhoneアプリを作っているのをみて、まねして少しだけ手を出してみたり、
GAEのサンプルを動かしてみて満足したりしていても貴重な時間の浪費でしかない。

すべてが中途半端になってしまう。

以前上村愛子が以下のように言っていた。
私は周りを気にしすぎていた。周りは気にしないで自分のことに集中するようにしたら、結果がついてきた
うる覚えなのでちょっと違うかもしれない)

周りがやっているから自分も見たいな感じで、中途半端に手を出すのが一番もったいない。
やるなら徹底的にやることが重要だ。周りを気にしすぎるとろくなことがない。

IT業界で成功するには、一握りのアイデアと一つのことに黙々と取り組み続けることが出来る人が成功すると思っている。


safariってあんまり使ったことないのですが、最近FireFoxの重さが気になるので、
safari4を試してみようと立ち上げてみたらTop Sitesってのがおしゃれだった。