Cygwin環境でgem install するときにいるライブラリ備忘録

cygwin環境つくってRubyで開発するときに、

  1. gem install XXX が失敗する
  2. 依存ライブラリ足りない><
  3. ググる
  4. なんか前にも調べた気がする・・・

ということを何度も繰り返してる気がするので、とりあえず今回ハマったときに必要だったライブラリをメモメモ。

  • Devel/autoconf
  • Devel/binutils
  • Devel/bison
  • Devel/flex
  • Devel/gcc-core
  • Devel/gcc-g++
  • Devel/libstdc++6-devel
  • Devel/make
  • Devel/patchutils
  • Web/wget
  • Libs/libcrypt-devel

gitlabのVMイメージが提供されていた

以前に、Ubuntu上でgitlab構築したんですが gitlab自体は起動してて、ブラウザからアクセスできても、git コマンドでアクセスできなかったんですよね。​
(おそらくsshまわりの問題かと思うんですがめんどくさくなって放置してました^q^)

ちょっと調べなおして使えるようにするかーって思って調べていたら、bitnami でgitlab構築済みのVMイメージがダウンロードできてしまいました。

http://bitnami.com/stack/gitlab

VMPlayerにイメージ読み込ませて、ssh のプロセス立ち上げてキー周りの設定すれば無事ローカルのgitクライアントからpushできるところまでいけました。


公式ドキュメント
http://wiki.bitnami.com/Applications/BitNami_GitLab
http://wiki.bitnami.com/Virtual_Appliances_Quick_Start_Guide#How_to_enable_sshd.3f


キー生成周りはgithubのドキュメントを参考にした
https://help.github.com/articles/generating-ssh-keys


おわり

JPA2.0 のNamedQueryでのカウント

JPA2.0でCOUNTクエリを発行したいときって、CriteriaBuilder経由でクエリを作成するか、NamedQueryでクエリを作成しますよね。

でも、NamedQueryでクエリ作成するときって、COUNT用と普通のSELECT用で2つJPQLを定義しないといけないじゃないですか。

それってDRYじゃないですよね。

普通のSELECT文のNamedQueryからそのクエリで取得可能な最大件数(COUNTの結果)を取得する方法調べてるんですけど知ってる人いませんかね。

setup/tearDown処理の共通化

JUnitで、setupの処理とか共通化したいなーって思ったときに、

今までは、親クラス作って共通化してたんだけど、これはJUnitアンチパターンの一つだということを最近知った。

理由は、テスト書く人が意図せずsetup/tearDownをオーバーライドしてしまうから。


共通化したいときは、@Ruleつかえってことらしいです。

setup/tearDownをfinal宣言すれば防げるけど、柔軟性がなくなるので、@Rule使うほうが良さげ。

今理解している@Rule の使い方は、↓の感じ。

  1. Rule用クラスをインスタンス化して、@Ruleアノテーションつける。
  2. 設定するRuleクラスをカスタムで作成するときは、TestRuleインターフェースを実装する。


あと、@RuleはJUnit4.7以降じゃないと使えなかったはず。

SessionScopedのPreDestroyが呼ばれるタイミング

CDIのSessionScopedアノテーションを付けたBeanのなかに、

@PostConstruct

@PreDestroy

をつけた場合に、PostConstructはちゃんと、セッション生成時に呼ばれるんだけど、PreDestroyがちょっと曲者な感じで、セッション破棄されてから少し経たないと呼ばれない。
(多分だけど、PreDestroyは、finalize メソッド内で呼ばれてて、GCのタイミングに実行されているとか?)

その少しの間に画面上の操作を行うと、セッション切れでエラーになって新しいセッションが生成されるて、そもそもPreDestroyが呼ばれなくなる。

JavaEEのお作法的に、PreDestroy上ではそのSessionScopedBeanの後処理を書きましょう。っていう風に言われているけど、必ず呼ばれる保証がないところにそんな処理は書けないよね。

そんなこんなで、結局セッション破棄時にどうしてもやりたいことは、 HttpSessionListenerを使ったほうがいいのかなと思いました。