Concepts and tools of logging in Java. Javaにおけるログ出力の考え方と道具について説明. CC Attribution Licenseの元に公開します.

Eclipse Kepler (4.3.2) SR2 Packages で説明する Mavenは何が便利? Mavenがjarとかライブラリをダウンロードしてくれる 使いたいライブラリを個別に集めなくてもいい。 使いたいライブラリに関連する別のライブラリも集めなくていいい。 他の開発者にわざわざライブラリを渡さなくてもいい。 ライブラリのバージョンが上がっても、バージョン番号をいじるだけ。 ライブラリの元のソースコードもMavenがダウンロードしてくれる。 Jenkinsを使っていたら、jenkinsはMavenとの連携は簡単。 ダウンロードされたライブラリはローカルディスクのライブラ置き場で保管され、必要に応じて使われる。 Eclipseのビルドパスに勝手に追加してくれる。共同開発者も含めてビルドパス管理不要になる。 複数のプロジェクトのライブラリの種類やバージョンを1箇所で管理できたり
Software design patterns, principles, and snippetsThe best designers will use many design patterns that dovetail and intertwine to produce a greater whole --Erich Gamma Get the book 📖Study the design patterns 💡 IntroductionDesign patterns are the best formalized practices a programmer can use to solve common problems when designing an application or system. Design patterns can speed up the devel
前回のエントリは、OSSとしての説明が抜けていたので、今回、きちんと説明させてください。 Seasar2、S2JDBC(元々Seasar2の一部)、SAStrutsは、これまでも、これからもOSSであり、githubでずっと公開されるので、フォークでも何でも好きにしてください。 Mavenリポジトリ、ドキュメント、MLなどがどうなるのかは、現在話し合っている最中です。方向性としては、現在、Seasar2を利用している人々に、最も影響の少ない選択肢が選ばれるはずです。 Seasar Foundation、Seasar Projectsのクローズの提案をしましたが、これは、取り下げます。 あくまでも、お願いという形でしたが、私がお願いするとかなり強制力を持ってしまうことに対する配慮がかけてました。 2016/9/26にSeasar2、S2JDBC、SAStrutsのメンテナンスを現在のコミッタ
この記事のJMeterは ver 2.12。 テストを一件ずつ実行する 1つのJMeterスクリプトファイルにスレッドグループを複数個並べると、JMeterは2,3個のスレッドグループを並行して実行する。このとき、例えば、ログイン/ログアウトの評価やコンテンツの参照/削除が同時に走ってしまうと情報に不整合が生じ、テストが失敗することがある。 そこで、「テスト計画」の「各スレッドグループを別々に実行」にチェックを入れると、スレッドグループを1個ずつ順番に実行してくれるようになる。 エラーを期待するテスト JMeterのステップは標準では4xxや5xxのレスポンスコードをエラー(レッド)として扱う。しかし、正常系評価ではなく異常系の評価をしたい場合、4xxのレスポンスでグリーンになって欲しいにも関わらずレッドとして表示されてしまい評価結果が見づらくなることがある。そこで4xxや5xx系レスポン
この記事は、JavaとScalaの例外分析・パフォーマンス監視のツール Takapi の blog に投稿されたものです。 Javaのマイクロフレームワークとは何か、推奨される理由とは? どんなプログラミング言語にも、長所と短所はあるものです。例えばJavaは、安全性の高さや、厳しいテストを経ていること、後方互換性などの利点を持つ言語です。しかし、その代償として、アジリティ(俊敏性)や合理性といった面が少なからず犠牲になっています。冗長で、Java自体が肥大化しているという事実も否定できません。とはいえ、新規開発や大規模な開発を行いたい場合、JVM(Java仮想マシン)はバックエンドとして非常に魅力的です。JVMはパワフルな上に、非常に厳しい環境でテストされています。このような利点があるため、結果的にJavaは広く使用され、積極的にデプロイされているのです。 しかし、このJavaの現状を皆
(7/7追記)僕は斜め読みだったんですが、もっときちんと読んだ上で解釈を書いてくれている方がいます。僕も時間をとって全文を読みたいとは思っていますが、まだ時間がかかりますし、yudaiさんの会社の方が妥当性は高いと思いますので、そちらをご参照ください↓ 朝っぱらから色々衝撃が走った第一四半期の最終日ですが、OracleとGoogleの裁判について、どのあたりが問題だったとされるのか気になるので判決文等を読んでみました。 経緯 2010年8月、OracleはGoogleを訴える。当初の争点は特許侵害 (publicKey1) 2012年4月、サンフランシスコ連邦地裁の法廷開始 2012年5月、Googleの特許侵害はないとの陪審評決。ただし、フェアユースは意見が別れる。 2012年6月: Oracle対GoogleのJava/Android訴訟、損害賠償金ゼロで合意。今回議論された37件のJ
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
「DIする」,「インジェクション(注入)する」──新しい技術に敏感なソフトウエア開発者たちの間で使われている言葉である。DIとは,「軽量コンテナ」を実現する新しい設計思想Dependency Injection(依存性注入)の略称である。同じ概念をIoC(Inversion of Control,制御の反転)と呼ぶ場合もある(詳細は後述)。「DIする」と言えば開発者の間では通用するぐらいに,この設計思想は注目されているのだ。 DIが注目される理由は簡単だ。ソフトウエア開発者の開発サイクルを大幅に改善するからだ。筆者が司会を担当した「軽量コンテナ」に関するパネル・ディスカッション(注1)では,DIを適用した軽量コンテナ「Spring Framework」のおかげで「睡眠時間が確保できるようになりました」と複数のパネリストが真顔でコメントしたほどである。DIは,それだけ有効な技術なのだ。 注1
皆さん、はじめまして。本連載を担当するビーブレイクシステムズの山之内と申します。本連載ではO/Rマッピングについて検討していきます。 O/Rマッピング機能を提供してくれるフレームワーク(O/Rマッピングツール)はデータベースと連携するJavaアプリケーション開発において、既に必須となりつつありますが、O/Rマッピングツールはたくさん存在します。 しかし、各O/Rマッピングツールには特徴やクセがあり、実際の開発現場においてどのO/Rマッピングツールを導入すべきか迷っている人も多くいることでしょう。目的にあわせて適切なツールを選択しないと、思ったような効果が得られなかったり、かえって工数が増えたりする状況にもなりかねません。 そこで本連載では、代表的な3つのO/Rマッピングツール(iBATIS、Torque、Hibernate)を取り上げて、実際に各O/Rマッピングツールを利用したサンプルを作
概要 Javadocは、Javaの特殊なコメント。 コメントの書き方がルール化され、それを元に説明書を作成することが出来る。 クラス・メソッド・フィールド(変数)にJavadocコメント(説明)を付けられるので、それらの説明が見られることになる。 Javadocと言った場合、「Javadocコメントの書き方」と、それを元に生成された「API仕様(HTML文書)」のいずれかを指すことが多い。 後者は、Javaの(標準ライブラリーの)API仕様が有名。→Javadocの読み方(入門者向け) Javadocの記述方法はHTMLがベースだが、Java23でマークダウン形式のJavadocが書けるようになった。 [2024-09-22] Javadocの生成方法 Javadoc生成用のコマンドを使って、JavaのソースファイルからHTMLを生成する。 javadocコマンド … これが一番基本 Ec
つい先だって知ったのですが、 Java のメソッドの throws 節では型変数が使えます。 8.4.6 Method throws / Java Language Specification これによって、投げる可能性のある例外の型が使い手側で変えられるようなメソッドを書くことができます。たとえば次のプログラムのように、例外の型と例外オブジェクトの生成を使い手にまかせる汎用の表明メソッドが書けます。 *1 class Checker { static <T extends Throwable> void check(boolean condition, Supplier<T> supplier) throws T { if (! condition) { throw supplier.get(); } } } class SomeException extends Exception {
先日、日本Javaユーザグループ(JJUG)主催のJJUG CCC 2013 Fallで、「ユニットテスト改善ガイド」というタイトルで登壇してきました。自分の経験を元に、ユニットテストをチームや組織へ導入する時に起こりえる問題とその解決のヒントに関するセッションです。本エントリーではそのセッションの内容を再構成して公開します。 はじめに 近年のシステム開発では、ユニットテストや継続的インテグレーション(以下、CI)の導入は必要不可欠と考えられています。とはいえ、どんな組織(チーム)でも簡単に導入できているわけではありません。特に、大きな組織や古くからの慣習を残している組織では導入したくとも中々進まないと感じているところが多いのではないでしょうか?。 私は、これまでに多くの開発現場でユニットテストやCIの導入について推進してきました。成功したケースもあれば失敗したケースもあります。そして、失
SAStruts+DBFluteでの開発が終わり、またCOBOLで書かれたシステムの保守が始まる・・・。 あぁ、楽しかったSAStruts、楽しかったDBFlute、楽しかったJava。 ということで、この辺りで一度、COBOLから学んだことについてまとめてみようと思う。 僕が今、主にかかわっているシステムはクライアント側がVB(Windows)、サーバ側がCOBOL(UNIX)で出来ている。そして更にバックボーンには、メインフレームが構えている。メインフレーム側の構成は主にPL/1+JCLで、もちろんDBは階層型だ。 そんなシステムを2年近く保守してきた中で気付いたことを書いて行こうと思う。 カプセル化やスコープの重要性 今更何を言っているのかと思う方もいると思うけど、マジなんだ。僕が初めて学んだ言語はC言語でそれからC++、Javaと続き、その後LL言語にも手を出し始めた。C++を始め
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く