Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

thin-cacheというキャッシュライブラリ書いた.いつものようにmaven centralにも置いてある.そしていつものようにJava 8以降が対象となっている. maven central Microservicesみたいな感じでサービスを作っていると,他のサーバにrequestを飛ばして得られた値を加工して,あるいはそのまま利用するみたいなコードを書く事が多くなってくる.毎回毎回他サーバにrequestを飛ばして良いのであればまあ飛ばせば良いのだけれど,そうもいかない場合も多い (トラフィックなり応答速度なりの理由で).そういう場合に対策として考えうる手段のひとつとしてキャッシュが挙げられると思う. 今まではそういったキャッシュを良い感じでコントロールするコードを都度都度書いていたのだけれど,それにもそろそろ飽きてきたのでいい感じに抽出してライブラリにした. Javaでキャッシュ回
ゴールドマン・サックス発のJavaコレクションフレームワーク、その7つの特徴と歴史とは:コレクション処理の万能道具箱Eclipse Collections入門(1)(1/3 ページ) 本連載では、ゴールドマン・サックス発のオープンソースJavaコレクションフレームワークであるEclipse Collectionsについて、その概要と歴史、機能を中心に紹介します。これまでのJavaやJava 8のStream APIと比較して何が違うのか。Eclipse Collectionsを例に、読者の皆さんがコレクション処理をより深く理解するための一助になればと思います。 ゴールドマン・サックスが開発し、オープンソースソフトウェア(OSS)として公開したJavaコレクションフレームワーク「GS Collections」が、Eclipse Foundationに移行し、「Eclipse Collecti
JavaのOSSフレームワークとして地位を確立しているSpring Framework。翔泳社では『Spring徹底入門』を刊行しましたが、本書はNTTデータの皆さんが執筆されたもの。NTTデータはなぜ価値あるノウハウを公開し、共有しようとするのでしょうか。今回、本書を執筆された本橋賢二さん、槙俊明さん、池谷智行さん、小島祐介さん、川崎真弘さんにお話をうかがいました。 なぜNTTデータがSpring Frameworkの入門書を手がけるのか? ――『Spring徹底入門 Spring FrameworkによるJavaアプリケーション開発』はNTTデータの皆さん(槙さんは執筆中に転職)が執筆されましたが、最初におうかがいしたいのは、なぜNTTデータがJavaのOSSフレームワークであるSpring Frameworkのノウハウを広めるための入門書を手がけたのかということです。 本橋:NTTデ
なぜ、動的型付けスクリプト言語の流行りから、再び静的型付けの言語が注目されているのか。 型付けの歴史を振り返り、これからの「型」のありかた、それを実装した処理系のありかたについて考えます。
先に書いたリンゴを買う人のように、1つの処理だけで終わるプログラムをシングルスレッドのプログラムと呼ぶ。 しかし、実際にはいくつかの処理を並行して行う。要するに、複数のスレッドが同時に動くことになる。 このように複数のスレッドが同時に動くことをマルチスレッドという。 スーパーに様々なものを買う役目をもった人間がいるようなものだ。 大分簡易化されているが図で表すと次のようになる。 マルチスレッドを使う理由は? 1人の人間がたくさんの物を買うよりも、複数の人間がそれぞれ目的のものを1つ買うほうが早い。 同じように、1つのスレッドで処理を行っていくよりも、マルチスレッドでの作業速度は速くなる。正確には速くならない場合もあって複雑なのだが、速くできる可能性があると思っておけば良い。 また、例えばWordなどでは入力中、同時にスペルチェックが行われていたりする。このように同時進行させられるのが、マル
イントロ 例外処理を書くことはよくやっているのだけれど、その時の主軸となる考え方について、今までなんとなくで行っていた部分が多かった。 毎回考えるポイントは例えば以下のような疑問。 どこのレイヤーで、どこまで例外処理を行えばよいのだろうか? どの例外をキャッチし、どの例外を伝搬させればよいだろうか? 前提条件をチェックし、失敗した場合、例外を出したほうがよいか、nil, false を返すほうがよいか? 例外をどういう単位でラップさせるのが良いだろうか? 例外をチェインし過ぎると却って煩雑になる気がする。どうすれば良いのだろうか。 しかし、この辺りの話って、API の設計だったり、仕様の影響もあるので、都度対応が異なってしまうもの。 したがって抽象化して理解することが難しく感じた。 とてもよく使ってるし、とても大事な事なことなのに。 そんな今更な事で悩んでいた時に、Effective Ja
Googleは、Java APIを使用してモバイルOS「Android」を構築していることをめぐるOracleとの法的な争いにおいて、優勢に立った。 Oracleは、著作権ライセンス料を支払わずに37件のAPIパッケージを使用しているとしてインターネット大手Googleを提訴し、数十億ドルのライセンス料支払いを求めていた。しかしGoogleは、自社による同APIの使用が「フェアユース」に相当すると米連邦裁判所の陪審員団に認めさせることに成功した。 この評決はGoogleにとって大きな勝利である。陪審員団がOracleの主張を支持していたとすれば、この訴訟における次の段階では、Googleが支払うべき対価の査定が始まるところだった。Oracleは、90億ドル以上の賠償金を求めていた。その額は、米国における著作権関連の評決でこれまでに認められた賠償額をはるかに超えている。 しかし、何年にもわた
AndroidにおけるJavaコードの使用は特許と著作権を侵害しているとしてOracleがGoogle(現Alphabet)を訴えてから早6年。米カリフォルニア州北部地区連邦地方裁判所で開かれていた陪審で5月26日、Googleの使用は著作権のフェアユースに該当するという評決が下った。だがOracleはこれを不服としており、まだ終止符とはいえない様相だ。 発端はOracleが2010年に起こした特許訴訟による。当時Oracleは、GoogleがAndroidで1万1500行にもわたるJavaコードを無断使用しているとして90億ドルの賠償を求めた。 Oracleは7件の特許、37件のJava APIの著作権侵害を主張したが、主張は認められなかった。不服としたOracleは2012年にJava APIに絞って上訴。その結果2014年にJava APIは著作権の対象になるとする判断が下った。なお
入門書ではあまりとりあげられない部分を解説するコンセプトの「入門書が教えてくれないJava」シリーズの第二弾。前回は変数についてだった。今回はそのスコープについて取り上げたい。 スコープとは スコープとは大雑把に言えば変数やメソッドなどが見える範囲のことを指す。 Javaの変数のスコープで一番簡単なのはローカル変数で、これは{から}まで(これをブロックという)の中で、宣言した位置より後ろで参照することができる。 public void main(String[] args) { int i1 = 0; // i1はここからmainの}までの間で参照できる if (true) { int i2 = 0; // i2はこのifの}までの間で参照できる } // i2はifの}を過ぎると参照できなくなる i2 = 1; // ← コンパイルエラー } なお、Javaの言語仕様では{}のブロックは
去年Androidソースコードレビューで指摘する事が多い項目まとめという記事を書いた時はアプリ全体を一度に見るような機会が多かったため、内容も大きめのものばかり書いていましたが、最近はプルリクエスト単位でレビューする機会が増えたので細かい項目についてまとめてみようと思います。 ミリ秒で時間を指定する時に自前で計算している 1000L * 60L * 60L * 24Lのようなコード。 TimeUnitを使いましょう。 24時間の場合は以下のように書けます。 TimeUnit.DAYS.toMillis(1L) ある文字列がhttp/httpsで始まるかチェック URLUtil.isNetworkUrl()を使いましょう。 ただしequalsIgnoreCaseで判定してます。 ベースURLにパラメータを付与していってURLを生成したい StringBuilder#append("&key=
一人でプログラムを書いてたりすると、環境によってはあまりコードの書き方には指摘を受けなくて困りますよね。プロになっても、曲がりなりにもちゃんと動くコードを書けてしまうとあまりに当たり前のことなんかは指摘されることも稀で、そのままある程度偉くなっちゃった日には、もはや自分で気付くしかなくなってしまいます。 FindBugsとか、Effective Javaなら使ったり読んでみたり読ませたりすることはできますが、それ以前のところって難しいんですよね。よいコードと言うよりそれが当たり前だと思われているので、指摘するにしても「こうすればいいよ」(アドバイス)じゃなくて「なんでこうしてないの?」(詰問)になってしまいがちです。 そこで、最近そういうJavaニュービーに指摘している(したい)ことの多い、Javaの基礎的な事柄をまとめてみました。ワタシJavaチョットデキルって人は、これ以外にもやりがち
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系レスポン
(7/7追記)僕は斜め読みだったんですが、もっときちんと読んだ上で解釈を書いてくれている方がいます。僕も時間をとって全文を読みたいとは思っていますが、まだ時間がかかりますし、yudaiさんの会社の方が妥当性は高いと思いますので、そちらをご参照ください↓ 朝っぱらから色々衝撃が走った第一四半期の最終日ですが、OracleとGoogleの裁判について、どのあたりが問題だったとされるのか気になるので判決文等を読んでみました。 経緯 2010年8月、OracleはGoogleを訴える。当初の争点は特許侵害 (publicKey1) 2012年4月、サンフランシスコ連邦地裁の法廷開始 2012年5月、Googleの特許侵害はないとの陪審評決。ただし、フェアユースは意見が別れる。 2012年6月: Oracle対GoogleのJava/Android訴訟、損害賠償金ゼロで合意。今回議論された37件のJ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く