サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
パリ五輪
exceptionblend.wordpress.com
Spring Framework 3.1あたりから追加された profile機能について軽く説明します。 profile機能とは、実行環境によって異なるJDBC接続プロパティなどを切り替えるための仕組みです。profile機能を使用すると 1つのapplication contextのxmlの中に、開発用、出荷時用の2つのプロファイルとして設定を記述し、実行時にどちらのプロファイルを有効化するかを指定することができます。 以下にxmlの例を書きます。この例は、開発時のUnitTestではin-memory-dbを使用し、出荷時のAPサーバにデプロイしたときはJNDIでDataSourceを取得するような場合の設定方法です。 プロファイル定義 下記のxmlの beans profile="development" と beans profile="production" を見てください。 <
昼間のお仕事の関係でORMをいくつか触ったので、比較してみることにした。今更なーという感じはするけど、現時点で選ぶなら何なのだろうかと考える人の一助になれば。 ※ 2012/09/18 改訂。Spring DATA JPAと QueryDslについては詳細をGistにあげたので、リンクを貼りました。 Java Persistence API (JPA) JSR-317. 一応JavaEE6の標準になっているが、使いやすいわけではなく補助的に組み合わせて使うライブラリがいくつか存在するのでそれらについて後述。 大まかに、クエリを書く方法は2通り JPQL(SQLに似非の独自クエリ言語)を文字列で書く 例: select o from Order o where o.date < '2012-09-01' Criteria API(メタクラスを生成すればある程度は型安全だが、APIが使いにくい
Eclipseと統合されているのがよいので、Eclipseの拡張機能(Gradle STS Support)を試してみた。 セットアップ Gradleのサイトによると、SpringSourceのSTS(Spring Tools Suite)にGradleサポート機能があり、Gradle機能だけを個別にインストールできるとのこと。Springを使うわけではないのに(いや、使うにしても)重量級のSTSを入れなくてもすむのは助かる。 Gradle STS Supportのインストール方法はGradle STS Support — 2.9.0 — Installation(英語)の通り。一緒に gradle-1.0-mileston-7 もプラグインとしてインストールされるので、gradle自体のインストールは不要(※単なるJavaプロジェクトならこれでも十分だと思うが、実際は gradle-ga
某SIerの「設計書からソースコードを自動的に生成するソリューション」について、エンジニアの間でブーイングの声が広まってる感があったので、ちょっと前に考えたことを書いてみる。 設計書からソースコードを自動生成することの何がイケてないのか。 それは、どんな設計書なら自動的にソースコードを生成出来るのか?ということに尽きる。 ソースコードを生成するということは、結局は変換をするということである。機械的に自動生成が出来るためには、ソースコードに変換するための情報が設計書と自動生成ツールの中に全て揃っていなくてはいけない。つまり、完全に動くソースコードに変換できるような情報をすべて設計書に書かなくてはいけないということを意味するのだ。実行可能な設計書と言ってもいいだろう。 かつての UMLモデリングツールなども MDD(Model Driven Development: モデル駆動設計)を称して、
これです。 まさに「10年くらいまえのJavaの熱気」でした。 自分語りみたいになりそうですが、かつて C++を書いていた頃の自分にとっての Javaと、いま Javaを書いている自分にとっての Scala。これらがとてもカブって感じるのです。書籍から引用してこれを代弁してもらいます。 1995 年にJava が現れたとき、Java は、ポインタやメモリ管理、その他の難解な配管工事のような仕事と戦い疲れたC++ プログラマを救済する言語として歓迎されました。Java は、そうしたプログラマの難題を解決してくれました。 しかし、2008 年現在、もはや下位互換性は意味がありません。 Java は、0 で始まる配列のようなC++ 主義や、プリミティブ型とオブジェクトの区別などの 1995 年には意味があったけれども最近の開発者の生産性に役立たないお荷物であふれかえっています。 ThoughtW
前に書いたもしドメインモデルを日本語コードで書いたらをやってみたが、やはりプログラミング言語は英語圏の人が理解しやすいように設計されていると再認識した。 元々は、機械語を読んだり書いたりしたくないから、日常使う言葉で、あるいはそれに近い言語でプログラミングしたかったから生まれたのだろうけど、たまたま英語圏の人が発明したのか、世界で広く使われているからそうしたのか、いずれにしろ現代のプログラミング言語は自分が知ってる(狭い)限り、「読める」という以上に英語的に「理解できる」表現なのではないだろうかと思う。逆に言うと、普段使っている言語で読み書きする概念をコードで表現やすいということではないだろうか、とも。 (自分が苦労しているのは単に能力が低いからというのもあるが・・・) もちろんあらゆる英語表現をプログラミング言語で書けるわけではないし割り切りはある。だがそれにしても、日本語を母国語にして
QCon Tokyo2011のビアパーティで、Eric Evans御大から「日本語でコードを書くべきだ!」というお告げがあったときいたので、試しにDDDSampleのCargoクラスを日本語化してみた。 public class 貨物 { private 貨物ID 貨物ID; private 位置 出発地; private 経路仕様 経路仕様; private 輸送日程 輸送日程; private 配送 配送; public 貨物(final 貨物ID 貨物ID, final 経路仕様 経路仕様){ this.貨物ID = 貨物ID; this.出発地 = 経路仕様.出発地(); this.経路仕様 = 経路仕様; this.配送 = 配送.導出する(経路仕様, 輸送日程, 荷役履歴.空); } // ... 略 } なんか、目に悪い気がする・・・ 日本語コードの問題 実際書いてみて色々不
このページを最初にブックマークしてみませんか?
『Exception Blend』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く