home ホーム search 検索 -  login ログイン  | help ヘルプ

find 検索

81 - 90 / 1297    [|<]  [|<]  [<]  1  2  3  4  5  6  7  8  9  10   [>]  [>|][>|]
タイトル/名前 更新者 更新日
Java/ホスト名, マシン名を取得するメモ msakamoto-sf 2015-03-01 00:38:59
Java/JavaServer Faces(JSF)/調査メモ1 msakamoto-sf 2015-03-01 00:08:52
Java/NetworkInterfaceとMACアドレスの取得 msakamoto-sf 2015-02-22 22:18:21
Java/JavaDB, Apache Derbyの練習とメモ msakamoto-sf 2015-02-21 20:52:45
Java/Classのキャスト, instanceof演算子の代替など msakamoto-sf 2015-02-21 19:42:04
Java/ポストJSP時代のモダンViewコンポーネント : mustache.java msakamoto-sf 2015-02-21 19:41:17
日記/2015/02/18/Mustacheでレイアウト(layout)風味のテンプレート→ギブアップ msakamoto-sf 2015-02-18 00:27:37
Java/CDI(JSR299,JSR346)とDI(JSR300)のメモ msakamoto-sf 2015-02-15 22:06:41
技術/HTTP/REST設計思想の "Stateless" との付き合い方 msakamoto-sf 2015-02-15 20:03:11
Java/JAX-RS/Jerseyで、FilterからResource Classに値を渡せるか msakamoto-sf 2015-02-12 01:19:28
ソート項目 / ソート順     1ページ 件ずつ表示

Java/ホスト名, マシン名を取得するメモ  

所有者: msakamoto-sf    作成日: 2015-03-01 00:30:01
カテゴリ: Java 

実は以前調べたことがあり、間違って System.getenv("HOSTNAME") を使ってしまった。
Facebookで他のエンジニアがLinux前提で /proc/sys/kernel/hostname を読み込む方法使ってたのを見かけ、HOSTNAMEを使う方法を教えたらうまく動かず、今回改めて調べ直したら見事にHOSTNAME使うのはbash依存ということが判明orz.

"InetAddress.getLocalHost().getHostName()"はマシンのネットワーク設定, DNS等によっては失敗したり、期待したものとは異なるものが返ってくる可能性がある。

System.getenv("HOSTNAME") はNGだった。というのは、"HOSTNAME"は厳密にはbashが設定する「変数」であり、「環境変数」ではない。そのため、bash系の設定ファイルによっては、HOSTNAMEが環境変数としてexportされずに、取得できないケースがある。

参考:

unixであれば Runtime.getRuntime().exec("hostname") が無難。これはネットワーク設定ではなくkernelレベルで設定されたマシン名を返す。

Linuxの場合なら、 /proc/sys/kernel/hostname をJavaで直接読み込んでも良い。hostnameコマンドも結局このファイルを読み書きしてるだけ。

参考:

Windowsの場合は、System.getenv("COMPUTERNAME") が使えるらしいが、厳密な調査は出来てない。



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2015-03-01 00:38:59
md5:2ce3dbd031b448a5bb1bb9b84e0afb96
sha1:6d23d3f3138b276a57be1dbe7b7bfb130056460f

Java/JavaServer Faces(JSF)/調査メモ1  

所有者: msakamoto-sf    作成日: 2015-03-01 00:08:37
カテゴリ: Java 

JSFとはどんなものか、いくつかググってみた参考URLメモ。

JavaEEに含まれるHTMLなどの画面系の仕様であり、JSRで調整されている。
また数年ごとにバージョンアップされており、開発のしやすさや機能性は向上している。
JSF 1.x系の時の評判は、一旦忘れて、素直にJSF 2.x系の最新版を調べたほうが良さそう。

JSPとは別物と考え、特にJSF 2.2で入ってきたらしいFaces Flowについては画面遷移の制御で、むしろSpring WebFlowやASP.NETアプリに近いアーキテクチャになってる・・・ような、印象を受けた。

JSF 2.xや2.2系列について、HTML5との親和性が向上した云々:

JSFでのリッチなUIライブラリとして、PrimeFacesというのがある。HTML5にも対応しているらしい。

他にもJBossのRichFacesがあった。

ただ、フロント開発がJavaScriptともに大きく揺れ動いている昨今、HTML5との兼ね合いや、訴求対象の開発者のカテゴリなどで、色々将来どうなの?的な話も見つかる。
例えば以下の記事は、JSFで実際に開発してみて、もう沢山だ!となった人が色々と愚痴をまとめてる。コメント欄も炎上してて、JavaEEのMVC仕様策定者もコメントしてたりで、大変面白いことになってる。

実際にJSFの内部のライフサイクルや、どうデバッグするかの解説記事。これを見るとASP.NETと似通った部分があり、サーバサイドとフロントのJavaScriptサイドの両方の知識が要求されることが分かる。

余談だが、JAX-RSやSpring MVCのちゃんぽん的に、JavaEEでMVC(つまりURLマッピングに基づくアクションコントローラ形式)のフレームワークの仕様化が始まっている。

個人的には、JSFにせよMVCにせよ、どんどん複雑・多様化していくWebフロントエンド技術で、どうしても発生する「複雑さ」をどこに持っていくかの問題になってきてる気がする。
AngularJSなどの最近のWebフロント技術は、基本的にブラウザ側のHTML+JSで複雑さに対応し、サーバサイドはAPIだけに絞る方向に見える。
一方でJSFやASP.NETの世界は、複雑さをサーバサイドの状態管理で対応しようとしていて、そのため、サーバサイドのライフサイクルとフロントエンド側のJSの両方に、微妙に複雑さがまたがってしまってる感じを受ける。
また業務アプリとそれ以外でも断絶はある。消費者向けのコンテンツサイトにおいて、業務アプリのような複雑なUIや画面遷移は必要ない。むしろREST的な世界観を求められるため、状態に紐付いたURLは敬遠される。一方で業務アプリはURLのREST性は不要なので、サーバサイドで状態管理された、非RESTなURLや画面遷移は許容される。また大規模開発をサポートするために、コンポーネント指向の仕様やフレームワークになっていく。

個人的には、もはやWebフロントの複雑性はサーバサイドで状態管理できる範囲を超えていて、JSFや.NET系のサーバサイド+フロントJSで状態管理を連携させるアーキテクチャは、開発者の負担が上がっているのではないかと思う。
むしろサーバサイドはAPIと初期HTMLページを表示するだけのものと割り切り、JS側でDOM構造の状態管理を行う方が、境界が明確で分かりやすい。(学習曲線はこの際無視する)
その上で、消費者向けのコンテンツサイトなどと、業務アプリでの複雑なUIコンポーネント制御とで、使用されるJSライブラリは異なってくるだろう。

・・・とはいっても、JSFはコンポーネント指向+画面フローの制御という点に旨味があるのは確かなで、一緒についてくる「苦味」とどこまで・どの位付き合っていけるかはもう少し勉強してみないと分からなそうであります。



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2015-03-01 00:08:52
md5:b5b7e4afba079d1bef47fbbef494ee66
sha1:177ee255834c09c989ebd31221a272ba3a313ba7

Java/NetworkInterfaceとMACアドレスの取得  

所有者: msakamoto-sf    作成日: 2015-02-22 22:16:28
カテゴリ: Java ネットワーク 

Java 1.6 になり、java.net.NetworkInterfaceクラスでMACアドレスを取得できるメソッドが追加された。

練習:(ほぼITProからのコピペ)



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2015-02-22 22:18:21
md5:56f7b4a66ec1d6bcb6be8512cea355d1
sha1:a3e060af591ca4f9cc15a382474f03421c0c6e93

Java/JavaDB, Apache Derbyの練習とメモ  

所有者: msakamoto-sf    作成日: 2015-02-21 20:52:29
カテゴリ: Java 

  • Apache Derby : JavaによるOSSのRDB製品, APL2
    • http://db.apache.org/derby/
    • 軽量を謳ったJavaによるOSSのRDB製品で、中核となるderby.jarは2MB程度(2015-02時点)。
    • 自分のアプリ内に組み込んで利用できる。一般的にはファイルシステム上にデータを配置するが(JDBCの接続文字列でルートディレクトリを指定)、インメモリでも操作できる。
  • Java DB
    • http://www.oracle.com/technetwork/java/javadb/overview/index.html
    • http://docs.oracle.com/javadb/
    • SunがJDK6からApache Derbyを同梱し、"Java DB"というブランド名にした(らしい)。単純に、JDKをJava DB付きでインストールするとJDKインストール先に"db"というディレクトリが追加され、その中にApache Derbyをサーバとして起動するためのひと通りのjarファイルと起動スクリプトが入ってる。
    • JDK8の時点では、Oracleがサポートして配布してるApache Derbyということになってる。
    • 誤解しそうだけど、JDKをインストールすると、セットでApache Derbyのサーバ実行用のファイルセットがくっついてくる、程度に考えれば問題無さそう。
    • クライアントを開発する場合は、普通にMavenから groupId=org.apache.derby のjarを引っ張ってくることになるので、特にJREがどうとか、クライアントアプリを書くときにどうとか、という話ではない。

参考:

練習:



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2015-02-21 20:52:45
md5:9f06598a6ff8dd6453257aa373cb005c
sha1:d0e6358b66702892a53cb9ab99e1ba71a29fab93

Java/Classのキャスト, instanceof演算子の代替など  

所有者: msakamoto-sf    作成日: 2015-02-21 18:49:58
カテゴリ: Java 

Classのキャストなどで便利そうな Class のインスタンスメソッド3選。

  • Class#isAssignableFrom() : instanceof 演算子と似ているが、isAssignableFrom()のメリットは、検査対象のClassを例えばメソッドの引数などから動的に取ってこれる点。
someMethod(Class superClazz, Object testee) {
    if (testee instanceof superClazz) {

というのはsyntax errorで書けないが、

someMethod(Class superClazz, Object testee) {
    if (superClazz.isAssignableFrom(testee.getClass()) {

と書くことができるようになる。

  • Class#cast() : これもキャストする型を動的に決められるのがメリット。
someMethod(Class castClazz, Object target) {
    Object o = (castClazz) target;

というのはsyntax errorで書けないが、

someMethod(Class castClazz, Object target) {
    Object o = castClazz.cast(target);

と書くことができるようになる。

  • Class#asSubclass() : ユースケースが不明。

最後のがユースケース不明でちょっと使い道が分からなかったけど、とりあえず3種類、テストケースで使い方を練習してみました:



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2015-02-21 19:42:04
md5:b77fd9bf5c8a238c71a710132430b4c1
sha1:e4b46b687a98f00130c4f68276408aef174913cb

Java/ポストJSP時代のモダンViewコンポーネント : mustache.java  

所有者: msakamoto-sf    作成日: 2015-02-21 19:36:15
カテゴリ: Groovy Java 
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2015-02-21 19:41:17
md5:bea81518eb21e741726155dcb7d4edc0
sha1:56d09b374c0debe495530a373351a163f5c5d664

日記/2015/02/18/Mustacheでレイアウト(layout)風味のテンプレート→ギブアップ  

所有者: msakamoto-sf    作成日: 2015-02-18 00:14:22
カテゴリ: Java 

おんなじようなこと考えてる人は沢山いるっぽい。

ただ、今のところ、どれも最終的に取り込まれたのかどうか、状況がはっきりしない、というか各IssueやPull Requestを追いきれてない。

少なくとも公式のmustache(5)のページにはそれらしき機能がまだ解説されてないので、駄目なのかも。

強いて似たようなことが出来るとすれば、

{{#layout}}
body
{{/layout}}
|

にして、layout()メソッドで枠をレンダリングということになるんだろうけど、layout()の中でもまたmustacheのれんプレートを処理するので・・・ああ、結局、やっぱり、mustacheのコンパイルは二回起こるのか。しかも、body側のmustache処理のスタックの中でさらにmustacheが走るので、ちょっと怖いかも。

ソレくらいなら、bodyをcompileしてrenderして、それが終わってからlayoutをcompileしてrenderして、という風に分割した方が分かりやすいし危なく無さそう。

{{>header}}

...

{{>footer}}

みたいなpartial形式にしても良いのだけれど、partialについてのcompile & renderがどうなるか分からんし、割りとこの形での分割は融通効かないのでやめときたい。

実際の、compile & renderにかかる時間は計測するしか無いが・・・最悪、compileしたのをキャッシュしておきたいところだが、スレッドセーフにrenderしてくれないと、タイミングによっては別リクエストのレスポンス内容が混ざるとか困った状況になりかねない。その部分の確証がもてるまでは、都度compile & renderでも困らないといえば困らない。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2015-02-18 00:27:37
md5:fe3858efb17702561eeb42bfe7b3b4c8
sha1:abbf410e4387261340797d7d5b8f84f6d749b877

Java/CDI(JSR299,JSR346)とDI(JSR300)のメモ  

所有者: msakamoto-sf    作成日: 2015-02-15 22:06:00
カテゴリ: Java 

勉強用の、参考URLのリンク集、メモ書きです。

JavaEEのバージョン:

2015-02現在、Java8も踏まえた2.0を策定中らしい。JavaEEに組み込まれるとしたら、JavaEE8からかな?

個人的には以下の記事にある通り、testabilityの向上と依存関係の排除という効果に期待が大きい。

同時に、オブジェクトのライフサイクルや注入されるタイミングなど、CDIの仕様とのすり合わせ・調査などで、CDIのレイヤーに関わる検証やトラブルが増えることも予想される。
また、DIコンテナは便利「すぎる」部分もあると思う。本来の想定範囲を踏まえた上での意図的な逸脱ならまだしも、技術的に可能というだけでイレギュラーな設定や使い方を当たり前のものとしてしまうと、後々大きなトラブルに繋がりそうなので、気にしておきたい。

他参考

近接仕様としてのJSR300 : Dependency Injection for Java

実装の代表

参考:



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2015-02-15 22:06:41
md5:2f633947a1cbe49fb99ae402cbe65ea8
sha1:2f271be177c1d5f57c99aa21253980aed7d5a415

技術/HTTP/REST設計思想の "Stateless" との付き合い方  

所有者: msakamoto-sf    作成日: 2015-02-11 21:34:52
カテゴリ: HTTP プログラミング 

RESTfulなAPIやWebアプリケーションを開発する際に、一つの疑問が生じる。
RESTでは「ステートレス」を重視して、サーバサイドでのセッション管理ではなく、クライアント側で認証情報や状態を保持して、サーバに都度送る方式を唱えている。これはHTTPで実装するなら、Cookieを使ったセッション管理ではなく、BasicやDigest認証など、HTTP認証を使うことになる。
しかし現実問題として、モダンなWebサイトでBasic/Digest認証を扱うことはなく、サーバサイドのCookieを使ったセッション管理を使うことになる。

RESTにおいて、ステートレスという特性と、現実のセッション管理をどうバランシングすれば良いのか?

うまく整理しきれていないが、結論を三行に濃縮してみる:

  1. RESTは2000年前後のWebに対するカウンターパンチとして提唱されたため、恐らく意図的に極端な主張となっている。
  2. RESTは設計思想であり、現場で吟味した上での「おいしいとこどり」でも構わない。
  3. RESTの下に自分たちが開発するWebアプリがあるのではなく、Webアプリ開発を支える設計思想の一つに、RESTの一部を取り込めればそれで良い。

以下、自分なりにRESTについて調べ、上記観点についてまとめた内容となる。

(全て表示する)
プレーンテキスト形式でダウンロード
現在のバージョン : 2
更新者: msakamoto-sf
更新日: 2015-02-15 20:03:11
md5:cb5ec4ae6db370f004f134ddfa6d907a
sha1:3509e86e85b44388ec11a7921808546f89a844a6

Java/JAX-RS/Jerseyで、FilterからResource Classに値を渡せるか  

所有者: msakamoto-sf    作成日: 2015-02-12 01:17:24
カテゴリ: Java 

Java/JAX-RS/Jerseyで、FilterからResource Classに値を渡せるか

イメージ的には、認証系のFilterでHttpSessionからドメインクラスのインスタンスを取り出して、Resource Classに"@Context"か"@Inject"で注入できたらなぁ。

→結論:ストレートにFilterからResource Classに渡すことは多分できない。ただし、FilterからHttpServletRequestにインスタンスを設定することは出来るため、RequestScopeでCDIのProviderを用意して、Resource Classへの注入はFactory側で HttpServletRequest を参照、Filter側でドメインクラスのインスタンスを取り出して HttpServletRequest に設定、みたいなアプローチは多分取れそう(未検証)。

そもそも、FilterとResource ClassではLifeCycleが違う。Resource ClassはRequestごとにインスタンスが生成され、Filterはアプリケーション単位で生成される。
Resource Classに "@Inject" できるということは、それは RequestScope になる。
しかし、FilterはRequestごとにインスタンスが生成されないため、Filterに "@Context" で HttpServletRequest を注入することはできない。
Filterの filter(ContainerRequestContext requestContext) で、ContainerRequestContextに getProperty()/setProperty() がある。
これを使って、Filterの方で HttpServletRequest -> HttpSession -> 認証情報や現在のステートを保持するドメインクラスの取り出し -> ContainerRequestContext#setProperty() (= HttpServletRequestにセット)

  • > Resource Classへの注入時に、RequestScope な Factory で "@Context" で HttpServletRequestを注入し、そこから Filter がセットしたドメインクラスのインスタンスを取り出し、Resource Classに最終的に注入。

・・・できるかな・・・?

なお、"@Inject" の使用自体は、JavaEE6以降のCDIの採用で、GlassFish側でもCDIとJerseyの相互連携が取れるようになったので、仕様上問題なく、思想的にもJavaEEの枠組みに収まっていると思う(こんなこと考える事自体がもう厭になってくる)。

よって、"@Inject" を効果的に使い、HttpSesssion にまつわる煩雑かつコピペの多いコーディングを減らすのは、合理的な判断であると思う。

また、"stateless"を重視してサーバサイドセッションを使わない方針のRESTにおいて、HttpSession=Servletにおけるサーバサイドセッションを使うことの是非については、個人的には 技術/HTTP/REST設計思想の "Stateless" との付き合い方 にて現実優先の結論を出しており、無理にRESTに従う必要はなく、枯れたサーバサイドのセッション管理機構を採用するという判断は十分に合理的であると考える。

Resource Class と Filter のLife Cycle 参考:

Resource Class : リクエストごと。

3.1.1 Lifecycle and Environment
By default a new resource class instance is created for each request to that resource. First the constructor (see
Section 3.1.2) is called, then any requested dependencies are injected (see Section 3.2), then the appropriate
method (see Section 3.3) is invoked and finally the object is made available for garbage collection.
An implementation MAY offer other resource class lifecycles, mechanisms for specifying these are outside
the scope of this specification. E.g. an implementation based on an inversion-of-control framework may
support all of the lifecycle options provided by that framework.

Filter : アプリケーションで一個。

6.4 Lifecycle
By default, just like all the other providers, a single instance of each filter or entity interceptor is instantiated
for each JAX-RS application. First the constructor is called, then any requested dependencies are injected,
then the appropriate methods are called (simultaneously) as needed. Implementations MAY offer alternative
lifecycle options beyond the default one. See Section 4.1 for additional information.

出典 : JAX-RS: Java(TM) API for RESTful Web Services (Version 2.0 Final Release, May 22, 2013)



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2015-02-12 01:19:28
md5:4f2b799e11feef31dfa3aac7919a3ffb
sha1:7fe56a9115f2abe46d2067fe09acb795ac32dc0d