サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
ドラクエ3
www.javazuki.com
中間操作でなんといっても気をつけなくてはいけないのは、 中間操作メソッドを呼び出しただけでは、 Streamオブジェクトを作っているだけということ。 中間操作メソッドに渡した処理は、 終端操作が呼び出されたときに実行される。 これを忘れてしまうと、 ｢全然うごかねー｣ってことになりハマる。 中間操作の中でも｢filter｣｢map｣｢peek｣が基本で 必ず押さえておきたい。 残りは使えると便利といったところ。
小数がからむ計算の場合、 floatやdoubleを使うとその性質上必ず誤差が出る。 よって、お金の計算などの正確さが必要な場合は BigDecimalは必須。 クラス図は次のようになる。 本体のBigDecimal以外も｢MathContext｣｢RoundingMode｣を利用する。 生成 BigDecimalは｢16種類のコンストラクタ｣or｢3つのvalueOf()｣で生成できる。 どれを使用するかは、次の順に検討する。 文字列を使ったコンストラクタ new BigDecimal(String val) long値を受け取るvalueOf valueOf(long val) long値とそのスケールを受け取るvalueOf valueOf(long unscaledVal, int scale) double値とMatchContextを受け取るコンストラクタ BigDecimal
JavaSE8は、なんといってもストリームAPIとラムダ式。 いろいろとできることが増えたので どこから手をつければよいのか困ってしまうが、 導入経緯を探っていくと理解しやすい。 ここでは、ストリームAPIやラムダ式の周辺が どんな理由で必要になったかを考える。 並列処理にはそれが必要だった 導入経緯をまとめると、次のような話。 (個人の主観的なまとめです。詳細はご自身でお確かめ下さい。) CPUがマルチコア化しているのに プログラム側が対応しきれていないのはもったいない。 並行処理用のAPI(Concurrency Utilities)があるじゃないか。 粒度の大きな処理は問題ないが、 粒度の小さな処理を並列化する場合には使いにくい。 じゃあ、イテレータに注目しよう。 反復されている処理が、簡単に並列化できればうれしい。 イテレータを改良すればなんとかなるのでは。 でも、今の外部イテレー
2014年07月10日 SLF4J+Logback 運用編 効果的に運用したいSLF4J+Logback。 logback.xmlを自動読込されるパスに置く Logbackは、 特定のファイル名で特定の場所に配置しておけば 自動読み込みしてくれる。 自分で設定ファイルを読み込む処理を書く手間が省けるので、 自動読込を積極的に利用する。 自動読込のルールは次の通り。 クラスパス上のlogback.grovy ｢1｣のファイルが見つからない場合、 クラスパス上のlogback-test.xml ｢2｣のファイルが見つからない場合、 クラスパス上のlogback.xml ｢3｣のファイルが見つからない場合、 BasicConfiguratorクラスの設定内容(コンソール出力) クラスパス上なので、 Mavenの構成でいうと｢src/main/resources｣や「src/test/resour
｢logback.xml｣では、次のことを設定する。 ログの出力先と出力のフォーマット ロガー(クラス、パッケージ)ごとの出力レベルの変更 実はlogback.xmlなくても動くが、 使いこなすにはもちろん設定した方がよい。 ちゃんとした詳しい設定方法については Logbackのマニュアル(→こちら)を参照。 具体的な要素(タグ)としては、 次の3種類。 種類 概要
｢pom.xmlの継承(共有)｣や｢プロジェクトフォルダの乱立を防ぐ｣など メリットが多いので、使ってない場合は使うべき。 スポンサードリンク 概要 プロジェクトが大きくなるにつれ、 １つのプロジェクトだけで管理するのが難しいときがある。 例えば、Webアプリケーションを作っていて 途中でバッチも必要になるとする。 こんなときは、Webと混在させるのも変なので 可能であれば別プロジェクトにしておきたいところ。 ただこのとき、新規に別プロジェクトにしてしまうと jarのバージョンであったり共有したい設定があっても 別々に管理しなければならない。 こんなとき、Mavenのモジュール機能を利用するといろいろ解決してくれる。 ｢pom.xmlの継承(共有)｣や｢プロジェクトフォルダの乱立を防ぐ｣など メリットが多いので、使ってない場合は使うべき。 基本 親プロジェクト下に子モジュールがたくさん M
｢MVC｣をWebに対応させた｢MVCモデル2｣(MVC2)がある。 ｢MVC｣は基本的にウィンドウベースのGUIに対応したものになる。 よってWebではそのまま利用できないので、｢MVCモデル2｣が登場する。 ｢MVCモデル2｣もWebシステムではほとんどのベースとなっていて、 こちらをMVCと思い込んでいる人も多いが違う。 ｢モデル2｣のシナリオ モデル2は次のようなシナリオで動作するように作る。 (順番は図の番号と対応しています。) ユーザがブラウザを通してフォームなど入力する。 ユーザが入力したフォームデータなどをHTTPリクエストとして ブラウザがコントローラへ送る。 コントローラがモデルに状態を変更するように依頼する。 コントローラが制御をビューに転送する。 ビューがモデルの情報を取得し、 最新の状態にしたページを生成する。 ページがブラウザに返され、表示される。 ｢MV
このページを最初にブックマークしてみませんか？
『Welcome to nginx!』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
