はてなブックマーク

Webアプリを作ってると、HTML/JavaScript/CSSを共通化したくなることがあります。 Yesodでは、これはWidgetって仕組みを使うようです。 なお今回出てくるコードは全て、scaffoldで生成されたソース群がある環境を前提にしています。 Widgetとは？ WidgetについてはYesod Bookに説明があります。 たぶん「hamlet/julius/luciusの３点セットを作ると再利用可能な物が出来る」というところだと思います。 hamletはHTMLのテンプレート、juliusはJavaScriptのテンプレート、luciusはCSSのテンプレートです。 英語は得意ではないので正しく理解出来ている自信はありませんが、大きくは外していないと思います。 試してみたところ、常に３点セットである必要はなくて、１つ、あるいは２つが欠けていてもいいようです。 Widget

Herokuに手を出してからというものの、eclipse+Jettyで開発することが多くなりました。 JettyのおもしろいところはAPIを使って起動用クラスを作ることで、普通のJavaアプリとして起動できることです。 これが便利なところは 起動が速い！ 特別なプラグインを入れなくても、ふつーにeclipseでデバッグできる 組み込み用途に使える などですかね。 同じことはGlassfishでも出来るんですが、Jettyは依存JARが少なくサイズが小さいのでお手軽ですし、GlassfishはAPIが安定していなくって起動用クラスの作成に苦労するんですよね。 そんなわけで今回はeclipse+Jettyのお手軽開発環境を構築する手順をまとめてみました。 例として「sample-web」というプロジェクトを作ってみましょう。 前提 Mavenが導入済みであること http://maven.ap

JAX-RSは素晴らしい仕様です。 しかし、その参照実装であるJerseyでJSONを扱うときには注意が必要です。 けっこうイヤな動きをします。 Listオブジェクトをエンコードしてくれない トップレベルのオブジェクトがListの場合、JSONにしてくれません。 他のオブジェクトのプロパティとしてListを持たせる分にはOKです。 Listの要素数でJSONでの型が変わる 要素数が0のとき⇒null 要素数が1のとき⇒要素そのもの 要素数が2以上のとき⇒配列 となります。 ・・・この仕様が嬉しい人いたら教えて下さい。 サンプル 文字列のListをJSONで返すコードを書いてみます。 直感的な動作は return Arrays.<String>asList(); のときは [ ] return Arrays.<String>asList("a"); のときは ["a"] return Arr

java.util.List#subListメソッドの使い方がまちがっていたためにメモリリークを犯してしまっていた、という話です。 画像の各ピクセルの色を抽出してある法則に並べ替えた後に、先頭の１０個の要素を返す、というメソッドを作るとしましょう。 このとき List<Color> cs = ... Collections.sort(cs, COMPARATOR); return cs.subList(0, 10); と書いてしまうと問題が生じます。csがメモリリークを起こすのです。 java.util.List#subListのJavadocによると、このメソッドはあるリストの特定の範囲を操作したいときの面倒なインデックス計算を省略するためにあるようです。 例えばJavadocの例ですが list.subList(from, to).clear(); と書くとのfromからtoの範囲の要

前回までのプロジェクト構成にミスがありました。 src/java/test下のパッケージが「sandbo.***」になっていました。 正しくは「sandbox.***」です。 さてJPAに入りましょう。 persistence.xmlを書かないといけません。なんかトラブる予感がするなぁ。 DBの選定 DBに何を使うかを迷いますが、組み込みDerbyを使うことにします。 理由は glassfish-embeddedにバンドルされているから DBプロセスを起動する手間が省けるから ローカルPC上で完結するから です。 実際の業務ではDBは製品を使うことが多いですが、問題になるのは複数人で開発するときの干渉です。 出来れば、開発者にローカルな環境がほしいわけで、組み込みDerbyならここが解決します。 これの問題点は「テーブル構造の変更をどうやって共有するか」という点ですが、今回は エンティティ

プロジェクトのプロパティを開く Project FacetsでJPAにチェックを付けてプロジェクトにJAPサポートを追加 プロジェクトのプロパティをいったん閉じる（重要！これをしないとJAPの設定項目が現れない） プロジェクトのプロパティを再び開く Java Persistenceの一番下「Canonical metamodel (JPA 2.0)」でソースフォルダを設定する ついでに「Discover annotated classes automatically」にチェックを入れておくとエンティティを追加したときにいちいちpersistence.xmlを編集しなくていいので便利です。 自動生成されるpersistence.xmlのソースフォルダを変える 上記手順を踏んでJPAサポートをプロジェクトに追加すると、persistence.xml（JPAの設定ファイル）がソースフォルダに作成

Servlet3.0から、HttpServletRequest#getParts()というメソッドが追加され、ついにJavaEE標準でファイルアップロードが使えるようになりました。 JSFと連携する方法を調査したので、過程と結論をメモしておきます。 @MultipartConfigアノテーションの付いたServletが必要 前提として、getParts()を使うには@MultipartConfigアノテーションの付いたServletが必要です。 この制約のおかげで実はgetParts()はかなり使いにくくなっています。 JSFとは連携出来ない？ 私が調査したのはJSFでアップロードファイルを取得する方法ですが、FacesServletには@MultipartConfigアノテーションは付いておらず、また、FacesServletはfinalで継承出来ません。 つまりFacesServlet

去年暮れから仲間と４人でコツコツ作っていた、HaskellによるQiita APIラッパーをついにリリースしました！ 配布サイトはこちら http://qiita.com/items/a0e4d1a105b12467850f こういうライブラリを公開するのは初めてです。 誰かの役に立つと嬉しいですね〜 Herokuに手を出してからというものの、eclipse+Jettyで開発することが多くなりました。 JettyのおもしろいところはAPIを使って起動用クラスを作ることで、普通のJavaアプリとして起動できることです。 これが便利なところは 起動が速い！ 特別なプラグインを入れなくても、ふつーにeclipseでデバッグできる 組み込み用途に使える などですかね。 同じことはGlassfishでも出来るんですが、Jettyは依存JARが少なくサイズが小さいのでお手軽ですし、Glassfishは