Apache Isis: ドメイン駆動設計のためのJavaフレームワークRustが再評価される：エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...
Java講座
Java講座 1. ケアレスミスを減らす章 1.1. while ループより for ループ 1.2. 配列を返すメソッド 1.3. チェーンコンストラクタ 1.4. キャッチした例外は必ず使う 1.5. リテラルの比較 1.6. 列挙型の定義 2. 堅牢性を獲得する章 2.1. ユーティリティクラス 2.2. フィールドの可視性 2.3. メソッドの可視性 2.4. クラスの可視性 2.5. 配列フィールド定数 3. 拡張性／柔軟性を獲得する章 3.1. ファクトリーメソッド 3.2. 怠惰な初期化 3.3. 継承はカプセル化を壊す 3.4. 継承の悪い例 3.5. 継承の良い例 3.6. インターフェースの不要な修飾子 3.7. インターフェースで定数定義 3.8. 改行コード 3.9. データの入れ物として使わない 4. 知っていると便
「アジャイルや設計原則まで自然に学ぶことになる」Java入門書、作ってみました - flairDays - てさぐりの日々
拙筆Java入門書の続編が本日発売です!! 前作『スッキリわかるJava入門』の発売から約1年が経ちます。Java入門書は既にたくさんありますので不安でしたが、お蔭様でご愛顧いただけていますこと、ありがたい限りです。 そして本日、無事続編の発売を迎えることができました。 『スッキリわかるJava入門 実践編』 この本は、Javaの基本文法やオブジェクト指向をひととおり学んだという方が次に読んで戴くための本なのですが、ありがちな「Java入門書の続編」とはちょっと違う新しい試みにチャレンジしてみました。 目次でみる「実践編」 今回の『実践編』の最大の特長は、Javaという言語自体の解説だけでなく「Javaを使うために必要な各種周辺知識」も網羅したことにあります。実際に、目次は以下のようになっています。 第1章 文字列の操作 各種操作メソッド / 正規表現 第9章 データベースアクセス JDB
Apache commonsが便利な件（commons-collections編-1） - 都元ダイスケ IT-PRESS
http://d.hatena.ne.jp/daisuke-m/20080702/1214982943 再びユーティリティ系。ということで今回はcommons-collections。 commons-collections は、Javaコレクションフレームワーク（っていうと大仰だけど、要はListとかSetとかMap。以下JCF）まわりのユーティリティ。 ところで、JCFまわりは Java1.4から5.0へのバージョンアップにあたり、ジェネリクスが導入されて、非常に使いやすくなりました。今やジェネリクスのないコレクションなんて、怖くて触りたくない病に罹っている今日この頃です。 しかし、このcommons-collectionsは下位互換を理由にジェネリクス化されていません。ジェネリクス世代としては、敬遠せざるを得ません＞＜。 が、どうやら本家Apacheからフォークしてcommons-c
「検査例外はアジャイルやオブジェクト指向の考えに反するという事実」について一部誤解あり - かとじゅんの技術日誌
追記： id:Nagiseさんからエントリいただきました。 というわけで、ややしつこく感じられるかもしれないけど誤りだと思うところはツッコミを入れさせてもらいます。人に恨みがあるとかそういうわけじゃなくて、説に用事があるってところをご理解いただければ幸いです。 こちらも建設的な議論をしたいと思っているので、もちろん、そのつもりです。 中間のクラスが〜という話題は、開放閉鎖原則を破って境界面に変更を加えた場合に話であって、検査例外が開放閉鎖原則を破るわけじゃない。 なるほど。よくわかりました。 目的と手段で分離してみた場合、「開放閉鎖原則」を「検査例外」を使って破っているだけであって「検査例外」自体の存在が「開放閉鎖原則」を破っているわけでない。「開放閉鎖原則」を破るのは「非検査例外」でもできるわけで、直接の因果関係は成立しないということですね。これは、私の論じ方に問題あったようです。ここに
『黄金の回転』を促進させるEclipseショートカット等についてまとめてみた #tddbc - Diary of absj31
TDD Boot Camp 横浜 Second Seasonにスタッフとして参加してきた #tddbc - Shinya’s Daily Report 先日2012/09/01(土)に行われたTDDBC横浜Second Season内『質問コーナー』にて Q.TDDをEclipseでやる時のオススメショートカットやテンプレートを教えて欲しいです。 A.ググりましょう。的な流れにしてしまい、質問者の方に『え〜(´・З・｀)』と思わせてしまったかも知れず、申し訳ありませんでした。その後1つ参考URLをつぶやいていましたが、このエントリではその辺り、Eclipseにおけるショートカットやテンプレートについて有用なまとめをしているエントリを紹介してみようと思います。 Eclipseショートカット 網羅性と言う点で行くと、下記2つのエントリがとても幅広く、丁寧に解説されていておススメです。 全Ecl
JUnit API探訪：Assertクラス／assertThatメソッド - Diary of absj31
JUnitをより深く知っていこう。と言う事で本丸JUnitのクラスから幾つか機能を探訪していこうかと思います。 org.junit.Assertクラス Assert (JUnit API) 主なメソッドは以下の通り。 メソッド 説明 assertArrayEquals(arrays expected, arrays actual) 配列同士を比較、イコールである場合true assertEquals(Object expected, Object actual) オブジェクト同士を比較、イコールである場合true assertFalse(boolean condition) 条件がfalseである事を検証、falseの場合true assertNotNull(Object obj) オブジェクトがNullで無いことを検証、Nullでない場合true assertNotSame(Object
Java 仮想マシン
ここまで説明してきたクラスファイルが実行時にどのように扱われるか？メモリ上にどのように展開されるか？これらの疑問に答えるためには、まずJava仮想マシン(JVM)の構造を理解する必要があります。 まず、図2.2にJVMの全体の構造を示します。ここに登場する様々なコンポーネントは、一部分はJVMの仕様書で定義されていますが、他の部分は名前だけ、場合によっては名前も載せられていません。この図では、JVM仕様書と現在の実装から、主要なコンポーネントと思われるものを、まとめておきました。では、それぞれのコンポーネントについて、紹介していきましょう。 図2.2 JVM の構造 (1) メモリ領域の構造と役割 JVMを構成するコンポーネントの中でも、特に重要な部分がメモリ領域です。この領域には、その名前が示す通り、JVMが実行中に使用する様々なメモリがまとめられています。図2.3に示すように、その
次世代のモックフレームワークであるJMockitの基本的な使い方 - 達人プログラマーを目指して
以前のモックフレームワークの技術的制約 今まで私が担当してきたプロジェクトにおいては、モックオブジェクトを使ったJUnitの単体試験はjMockとEasyMockのいずれかのフレームワークを利用して行ってきました。しかし、これらのフレームワークはJavaプラットフォームにおけるコード自動生成の考え方の変遷で説明したように動的プロキシーに基づいているため、以下のような制約がありました。 モック化する対象の型はインターフェースを実装しているか、継承可能なクラスであること モック化するメソッドはfinal、static、privateでないこと*1 モック化するロジックはコンストラクターの呼び出しではないこと モックオブジェクトをテスト対象クラスにDIかパラメーター経由で引き渡すことが可能であること モック化する場合はクラス全体をモック化する必要があること（getterやsetterなどは本物の
NetBeansとEclipseの比較 - しんさんの出張所 はてなブログ編
7.1.1と3.7で比較。 IDEAはどーなんだ、と思った人、某氏がやってくれるはずですのでお待ちください。 プロジェクトツリーの見た目 左がNetBeans、右がEclipseです。 見た目はほぼ同じですね。 プロジェクト作成後何もなければ。 で、ユニットテストの作成後。 Eclipse NetBeans ここが大きく違います。 Eclipseは結構昔から大抵のIDEには標準であるテストパッケージ/ライブラリという概念がありません。ソースのルートを複数用意は出来ますが、そこまでです。 一応JUnitを利用すると自動でJUnitのライブラリをつけるか聞いてはきますので、最低限のおもてなしはなんとかしてあるといったところでしょうか。 ソースやライブラリの依存方向のミスが解決出来ないので早く実装してほしい機能No1だと思われます。 ユニットテスト 以下のコードを元にJUnitのテストケースを作
JUnit 強化キャンプに参加してきた #junitbc - Diary of absj31
JUnit 強化キャンプ : ATND 2012/04/07 JUnit 強化キャンプ #junitbc - Togetter (写真：会場となった某漫画喫茶個室内に映し出される実践映像を眺める参加者一同) 私自身、勉強会に於いてテスト関連のイベントには参加しつつも(TDDBC等)、そこから先テストに於いて諸々を(Bootからの次の段階である)ブースト(Boost)出来ていなかったので、このイベントを見つけ次第『これは！』と思い参加してきました。 会場はまんがねっとラウム新宿本店。 自身としては、漫画喫茶で勉強会やるってのは初めてだったので、『(諸々)どうなんだろう？』という気持ちがありましたが、実際やってみると殊の外快適で"これは良い"という感じでしたね。ネット回線(立地上の問題で時々調子が悪い時があった)や部屋に対する定員を上手く調整すれば、利用場所としてはかな〜り良いものになるのでは
Java書籍の選び方 - torutkの日記
ソフトウェア開発プロジェクトに加わるプログラマーは、必ずしも全員が使用するプログラミング言語に習熟しているわけではないのが発端です。 Javaプログラミングに習熟する一環として、専門書籍を読んで学ぶことになりますが、その際どんな本を薦めるかは常に悩みます。 Javaの場合、プログラミング言語の中では出版されている書籍の数が多く、目を通していないものが大半 読む人の習熟度によって、適する書籍の難易度が異なる 習熟度は、最近読んだ書籍「リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法」で紹介されているドレイファスモデルで分類するとよさそうです。ドレイファスモデルは、技能モデルを5段階でモデル化しています*1。 以下に、ドレイファスモデルの技能レベルと、Javaプログラミング技能においてそのレベルで読みこなし自分に取り込むことを目標としたい書籍を記載します。 レベル 名称 こ
Node.js vs Play vs SAStruts - hakobera's blog
前置き Experiences with Node.js: Porting a RESTful Service Written in Java - ZiggyTech 上記記事では、実験的にJava (Jersey + Hibernate on Tomcat) で実装された REST API サーバを Node.js で書きなおしてみたら、少ないリソース（CPU/メモリ使用量）でほぼ同等のパフォーマンスが出せたよ（ただし、O/Rマッパーを使用しない場合）、と書いてあります。この件に関して @koichik さんとやり取りしていた中で以下のような意見を頂いたので、実際にやってみましたという記事です。 @hakobera メジャーってことだと，あの比較が Play ではなく Tomcat なのは正解．日本的には Jersey ではなく Struts (もちろん 1 の方)なら更によかったw 2
XMLをjQuery風に操作できるJavaライブラリ「jOOX」 | gihyo.jp
2012年1月27日、XMLをjQuery風に操作できるJavaライブラリ「jOOX 1.0.0」がリリースされました。jOOXはLukas Eder氏が開発したもので、流れるようなインタフェース（Fluent Interface）（注1）で記述していくことでXMLの走査や編集が行えます。Java 5から導入されたStatic Importをうまく使っており、非常に簡潔な記述を実現しています（リスト）。 Lukas Eder氏はjOOXのように流れるようなインタフェースでラップしたライブラリをほかにも公開しており、SQLのように書けるjOOQやリフレクションを簡潔に表せるjOORなどがあります。jOOXのWebサイトからリンクされていますので、興味のある方はぜひ参照してみてください。 リスト jOOXを使ったコード Document doc = $(new File("foo.xml
プログラミング言語について語るときに僕の語ること - 愛と勇気と缶ビール
僕はしばらく前までプログラミング言語についての議論を戦わすのが好きな人間だった。 今でもそういう会話が嫌いではないとはいえない。というか好きか嫌いかで言うと好きな方かもしれない。今でもそういった会話、「何とか言語はこういうとこがいけない」「それに比べると(俺の使っている)○○言語はうんたらかんたら」というトークは、茶飲み話としてはそうとう楽しいと思う。酒の席で語るにはもってこいの話題だ。でも、それは職業としてエンジニアをやるいい大人がツバを飛ばして語るような話題ではない、と思う。 なぜそう思うか、と問われれば答えは明快で、その言語を使うコンテキストを無視して言語の優劣を語ることには意味がないと思うからだ。 非常に大雑把な括りをさせて貰えば、いわゆるスクリプト言語および動的な型付けを行う言語は、「少数の一定水準を越えたチームが最大限の効率を発揮するために設計された言語」だと思っている。 例え
Java/コーディング規約 - J Wave TOP
Eclipse プラグイン CheckStyle を使ったコードの統一 † 個人的な経験則でいうと、CheckStyle でコードチェックを行うのが効率的でプロジェクト全体に浸透しやすいです。 CheckStyle で警告されるコードがソース管理にチェックインされた時は、そのコード全体を疑う習慣を付けるべきだと考えます。 CheckStyle だけではチェックできない問題を持っていることが多いからです。 ↑ 警告「パッケージドキュメンテーションが見つかりません。」が表示される。 † パッケージに「package.html」ファイルを作成してください。 最初のセンテンス「.」,「。」までがパッケージ一覧に表示される概要となります。 <html> <head> <title>パッケージ概要</title> </head> <body> パッケージ概要。 <p> パッケージ詳細 </p> <
Seasar2と僕 - たけぞう瀕死ブログ
Seasar2徹底入門なる書籍を書かせていただいて言うのもなんですが、正直言って数年前はSeasar2はそれほど好きではありませんでした。そんな僕がなぜSeasar2徹底入門という書籍を執筆するに至ったかという話をさせていただきたいと思います。 Seasar2が大きな盛り上がりを見せていた当時、DIコンテナとしてSeasar2がSpringよりも使いやすいのはわかっていたのですが、Spring（やその他のデファクトな海外製フレームワーク）が使いにくいのであれば、Seasar2などというガラパゴスなフレームワークを作るのではなく、デファクトなフレームワークが使いやすいように本家にコントリビュートしていくことに労力を使ったほうが皆が幸せになれるのに…と思っていました。 また、S2JSF→Teeda→SAStrutsの流れに見えるような一貫性のなさにも困惑していました。当時S2JSFが使用してい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: スッキリわかるJava入門 実践編: 中山清喬: 本
GitHub - goldmansachs/gs-collections: GS Collections has been migrated to the Eclipse Foundation, re-branded as Eclipse Collections. https://www.eclipse.org/collections/
Java コーディングスタンダード CERT/Oracle 版
