技術は世界を救う。たぶん。
※この記事は丸太式 Advent Calendarの18日目です
Javaに組み込めるミドルウェアを調べてみました。
それぞれ解説リンクを掲載していますので、参考にご覧ください。
Javaだといろんなミドルウェアがあるのが”当たり前”みたいな感じがして、本格的な入門にもハードルが高いのが現状だと思います。
特にJavaEEになると、日本語の書籍がほぼ無いのもあって業務で使わない限りなかなか勉強する機会が無いですね・・・
※この記事は丸太式 Advent Calendarの17日目です
バックエンドはJavaで構築することが前提です。今Javaプログラマなので。
クライアント <- JSON -> Web <- JMS -> AP <- JPA -> DB
「なんていうか・・・すごく言葉にしづらいんだけど・・・・・・あんまりまとまっていませんね！」
タイトルに「2014.12」って付けてしまったので、またそのうちやるかも。
※この記事は丸太式 Advent Calendarの16日目です
IT技術者の定年は35歳であるという節、いわゆる「35歳定年説」がありますが、試しに検索してみると「本当だった」という声と「嘘だった」という声が両方とも見られます。
個人的な見解ではありますが、「35歳定年説」は嘘だと思っています。
まず、日本社会は年功序列の考えがまだまだ強く、IT企業であっても例外ではないということがあります。
会社側が”35歳定年”になってしまうキャリアパス、つまりマネジメントへの道しか提供していない為にこのような俗説が出現したのでしょう。
ただ、35歳だろうが45歳だろうが、途中で技術から離れてしまう様な人は技術者では無いと思っていますし、それまでどれだけの功績を残していても認識を改めることになります。
技術から離れてマネジメント側につく人は、技術にさほど興味が無かったのでしょうね。
本当に技術に興味があれば、現場から離れることはないでしょう。
確かに”プロジェクトマネジメント”は誰かがやらなければならないことですが、だからといって技術から離れるくらいならそんなものは技術者じゃない人に任せておけば良いのです。(技術を知らない人がマネジメントするという問題もありますが、技術から離れてまでマネジメントに専念するならあなたは技術者ではありません)
以上、個人の見解でした。
私が35歳になるまでまだ10年以上ありますが、そのときになっても同じような意見が言える技術者でありたいです。
※この記事は丸太式 Advent Calendarの15日目です
業務でHibernateを使っていますが、これまでは弊社内の大半の実装に合わせてこんな感じでCriteriaを書いていました。
Criteria criteria = session.createCriteria(Hogehoge.class); criteria.add(Restrictions.eq("userCode", userCode)); criteria.add(Restrictions.in("fugaCode", fugaCodes); criteria.add(Restrictions.ge("targetYearMonth", targetDate); ProjectionList projectionList = Projections.projectionList(); projectionList.add(Projections.sum("days").as("days")); projectionList.add(Projections.sum("hours").as("hours")); criteria.setProjection(projectionList); criteria.setResultTransformer(CriteriaSpecification.ALIAS_TO_ENTITY_MAP);
今日は実装中に仕様追加が発生したので、ストレス解消を兼ねてスピード重視で実装したら、いつの間にかメソッドチェーンで書いていました。
Criteria criteria = session.createCriteria(Fugafuga.class) .add(Restrictions.eq("userCode", userCode)) .add(Restrictions.in("fugaCode", fugaCodes)) .add(Restrictions.ge("targetYearMonth", targetDate)) .setProjections(Projections.projectionList() .add(Projections.sum("days").as("days")) .add(Projections.sum("hours").as("hours"))) .setResultTransformer(CriteriaSpecification.ALIAS_TO_ENTITY_MAP);
流れるように実装できたので、自分にはメソッドチェーンの方が向いているようです。
弊社のコーディング規約に特に記載が無ければ、今後ともメソッドチェーンで書きたいですね。
Criteriaをメソッドチェーンで書くと、次のような利点があるように思います。
* (作るべきSQLが見えているなら)流れるように書き表すことが出来る
* わざわざcriteria(変数名)や;(セミコロン)を書かなくて良い
* ProjectionListを変数に格納しなくても良い
* Eclipse等のIDEで整形すれば、適度にインデントが設定されて見やすい
「俺ならこういう理由でこうしたい！」という話があれば、是非お聞かせください。
※この記事は丸太式 Advent Calendarの13日目です
IT系書籍専門の中古買取・販売で有名な電脳書房さんが、14日まで対象の書籍が半額になるキャンペーンを実施しています。
普段からほとんど汚れがない古本を扱っているので、これはかなりお得ですね。
さて、何を買おうかな？
※この投稿は、丸太式 Advent Calendar 2014の11日目です
世の中に公開されているOSSのJavaライブラリは、大抵MavenやGradle等の構成管理ツールで管理できます。
しかし、自分で作ったライブラリや会社の都合で公開できないライブラリを使う場合、自分でJarファイルを追加したり、依存関係を管理しなければなりません。
Javaは1個のライブラリが大量の依存ライブラリを必要とすることもよくあるので、これは非常に面倒です。
そこで今回は、OSSのMavenリポジトリ実装である”Sonatype NEXUS OSS”にライブラリを登録する手順の1例を(かなりざっくりと)紹介します。
※ソースが用意できる場合、pom.xmlを作ればビルド・デプロイをmvnコマンドでやれます。
バイナリのJarを調達します。ソースやJavadocのJarを追加で調達すればEclipseやNetbeansなどのIDEで便利になりますが、今回はとりあえずバイナリだけ登録します
追加したいライブラリのためのpom.xmlを作ります。
依存しているJarがMaven Central等でホスティングされていれば、その依存関係も記載します。
NEXUSにログインし、repositoriesを開きます。
NEXUSは標準で「3rd party」というリポジトリが用意されているので、これを選択します。
下側に出ている「Artifact Upload」タブからデプロイできます。
GAV Definitionで「From POM」を選択するとファイルアップロード用のフィールドが表示されるので、先ほど作ったpom.xmlをここで指定します。
「Select Artifact(s) to Upload」ボタンからアップロードするJarを選択して「Add Artifact」ボタンを押すと、その下のグリッドに表示されます。
pom.xmlとJarを選択・追加したら、「Upload Artifact(s)」ボタンをクリックすることで、アップロードが完了します。
デプロイした物を利用するには、pom.xmlにNEXUSのリポジトリを設定して参照できるようにします。
初期状態のNEXUSには{NEXUSのURL}/content/groups/public/というリポジトリが有り、これを指定すると色々と幸せになれる層ですよ。
※この投稿は、丸太式 Advent Calendar 2014の10日目です
ビジネスルールエンジンについて、しばらく考察を続けています。
今日は(あまりまとまっていませんが)現状のメモをまとめておきます。
どれくらい先になるかはわかりませんが、将来的に整理しなおすつもりです。
アプリケーションとは独立した、ビジネスルールを処理するための仕組みや実装を、ビジネスルールエンジン、または単にルールエンジンという。
基幹業務パッケージの導入においては、導入先の企業の業務フローに合わせたカスタマイズが必要となる。
特定の業種に対して横展開で受注を獲得しているパッケージの場合を考えてみる。
各企業向けのカスタマイズ部分を基となるコードに密結合させてしまうと、似たようなカスタマイズを繰り返し行うことになりかねない。
このような場合にルールエンジンの概念を導入すると、工数を削減できる可能性がある。
例えば、画面の入力値をバリデーションし、結果に応じてデータを修正し保存する処理があったとする。
この処理をビジネスルールとすると、バリデーション、データの修正、保存の三つに分けることができる。
これらをルールエンジン上に構築することで、アプリケーションの更新とは別にルールの組み替えや追加が可能となる。
先述の例で言うと、データを保存した後に”特定のユーザに対してメールで通知する”という処理を追加する場合、ルールエンジンではあらかじめ規定しておいたルールを追加するだけで良い。
※この投稿は、丸太式 Advent Calendar 2014の9日目です
今日はJJUG CCC 2014 Fallの参加レポート3本目です。
R1-6 Concurrent Mark-Sweep Garbage Collection 再入門
by 久保田 祐史さん (@sugarlife)
Minor GC: Eden -> Survivor 0, Survivor 0 -> Survivor 1
CMS GCは安定していない。失敗してSTW:Stop The Worldを伴うFull GCが発生することがある
Full GC (with STW): 全領域がGC対象
Promotion failed, Concurrent mark failed
Minor GC (promotion): PromoteされたサイズはNew領域の差分 – 全体の領域の差分
CMS GC: initial mark
STWをかけて、ルートオブジェクトから直接たどれるオブジェクトをマーキング
Full GC: concurrent mode failure: CMS GC中にもう一度CMS GCが発生しようとした場合
GC locker: GCを止める機構。HotSpot初期化や、JNI API呼び出しの一部
※この投稿は、丸太式 Advent Calendar 2014の8日目です
自分で作った物のJAR(fat jarではない)をMavenリポジトリにデプロイしておけば何かと便利な気がしたのと、ExCellaをMavenで管理できないのはやっぱり不便なので、自前のMavenリポジトリを用意してみました。
% bin/nexus start startの部分をconsoleにすれば良かったはず。※この投稿は、丸太式 Advent Calendar 2014の7日目です
NetBeans 8.0.1でJPAの持続性ユニットをHibernateを使うようにして作成すると、EntityManagerFactoryでEntityManagerを作れない。
※Persistence Unitを正しく指定しても、見つからない旨の例外が発生する
NetBeansが生成するHibernate向けのpersistence.xmlの内容で、providerにorg.hibernate.ejb.HibernatePersistenceが設定されるが、このクラスは@Deprecatedでありなにやら挙動が違うらしい。
persistence.xmlのproviderに、org.hibernate.jpa.HibernatePersistenceProviderを設定する。
このクラスは、org.hibernate.ejb.HibernatePersistenceのJavadocに記載されている、代替となるクラスらしい。