はじめに Spring Social Twitterというプロジェクトがあります。このプロジェクトはSpring-bootでTwitterとOpenID Connectしたり、Twitterのアプリを作ったりするときに使える便利なライブラリです。今回はこちらのプロジェクトを使って、Twitterとアプリ連携をしてみます。 「はじめに」の補足 Janetterなどのツイッタークライアントでやれることは全部できるようになります。プロセスとしては、ユーザーにアプリを認可（Oauth1.0）してもらいアクセストークンを発行します。このアクセストークンを使って、ユーザーのアカウントでツイートを投稿したり、ツイートを収集したりします。今回は以前投稿した、Spring SecurityにFacebookでOpenID Connectする方法、とは違ってOpenID Connectするわけではありません。
2015-05-13 Spring Boot - Hot swapping, Hot deploy (開発中の変更を自動で反映) Java SpringBoot Eclipse と Spring Boot で開発をしていると、アプリケーション（Java）の起動・停止を繰り返すことが多いです。少しでも起動・停止を減らそうと、Spring Boot のマニュアル（Hot swapping）を読みました。 一部要約すると、こんな感じ↓で Hot swapping できるみたいです。 1. IDE（Eclipse）のデバッグで起動する 静的ファイル（JS, CSS, 等）、テンプレート（Thymeleaf, FreeMarker, 等）、Java コード（メソッドやクラスのシグネチャは除く）は、これで Hot swapping されるようです。 2. Spring Loaded を使う Sprin
JMockit の使い方メモ。 まとめといて何だけど、 JMockit が提供している強力な機能はなるべく使わないで済むように設計（実装）することが、理想的なんだろうなと思うわけです。 （たぶん、 JMockit の機能を下手に使いすぎると、可読性が落ちて、テストコードのメンテナンスも大変になりそうな気がする） でも、いざテスト困難な実装とぶち当たったときに備えて、ひと通り機能は知っておいた方がいいとも思うわけです。 ※このメモは ver1.6 の頃のもので 2016年 12 月現在の最新（ver 1.29）とは異なる点が多数あると思われます。JMockit は API の非推奨化→削除もかなり頻繁に行われているようなので、中には最新版では使えなくなっているものもあるのでご注意ください。 #環境 ##Java 1.7.0_40 ##JMockit 1.6 ※一部 1.21 で確認 #インス
私的Java開発をJenkinsでCIするためのbuild.gradleとJenkinsの設定です。要不要に応じて書き換えたり足したりが必要です。特にチェックルール。 環境 Java 1.7 Groovy 1.8.6 Ant 1.9.2 Ivy 2.2.0 Gradle 1.11 Mac OS X 10.9.2 全体の流れ Jenkinsに必要なプラグインをインストール GradleでFindBugs, PMD, CPDを実行するようbuild.gradleを作成 Eclipseでは Jenkinsにいれるプラグイン Gradle plugin - jenkins+gradle連携 FindBugs Plug-in - バグ検知 PMD Plugin - コーディングチェック Violations plugin - 静的レポートの集計表示 JaCoCo plugin - コードカバレッジの
Jacocoプラグインでのレポート Jacocoが出力してくれるhtmlでのレポート Jacocoレポート形式をCoberturaの形式に変換して出力 GitHub - yamap55/jacoco_sample 経緯とか 今の現場ではEmmaを使用してコードカバレッジを測っていたようですが、EmmaはJava7対応していないらしくしばらくカバレッジが測定できていませんでした。 そのままじゃマズイよね。って事で解消するために調べた結果、今はJacocoが定番っぽいので試してみました。 ちょっと前まではカバレッジ測定のツールCoberturaとかEmmaが定番だったようですが、共にJava7に対応していないようです。 が、全て終わってからCoberturaを調べたら数年ぶりに更新されて対応されている？？ Cobertura Jacocoとは Eclipseのプラグインである「EclEmma」
JavaのGUIアプリケーション（ネイティブライブラリ使用）をしばらく実行していると、だんだん重くなり、JavaヒープメモリをJDKのjconsoleツールで調べると、上限に張り付きFull GCが頻繁に発生してますが、グラフが下がらないという状況がありました。 同じくJDKのjvisualvmツールでヒープに占めるオブジェクトを調査すると（「サンプラ」タブの「メモリー」ボタンを押し、ヒープヒストグラムを表示）、あるクラスのインスタンスが100万個以上と同数のjava.lang.ref.Finalizerが存在しています。 ロジック的なメモリリークではなく、GCのファイナライズに関して問題が生じているようです。問題のクラスは、ネイティブライブラリを使用していおり、jconsoleでFinalizerスレッドのダンプを見ると、そのクラスのfinalizeでネイティブ呼び出しをしています。 参
一つのJavaプログラムについて、処理をマルチスレッドで並行性を持つように記述し、複数CPU（マルチコア）上でそのプログラムを実行することにより並列処理を実現しようとした際、ログ出力が実行性能にどれだけ影響を及ぼすのかを把握したい、と考えています。 プログラムの開発（特にデバッグ）においては、ログが使えないと苦労します。ただし、ログを埋め込むと、性能に影響を及ぼします。また、ログレベルを抑制し、実際にはログ出力がなかったとしても、ログレベルの判定処理が動くことで、多少の影響はあります。 最近のログ出力ライブラリはスレッドセーフに作られていますが、それは内部で排他区間を持つことになるので、並列処理においては排他による性能への影響は無視できません。 そこで、同一プロセス内でマルチスレッドにより並行実行するプログラムを作成・実行し、複数スレッドからログを出力すると、実行性能にどれだけ影響を及ぼす
public class foo { final static String bar = "a" + "b"; public foo() { } public String bar(String baz) { return "a" + "b" + baz + "c" + "d"; } } コンパイルしてデコンパイル # javac -version javac 1.6.0_24 # javac foo.java # jad foo.class // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Na
to be the best java client for memcached Maintainers: Greg Whalin (Meetup) Xingen Wang Meng Li Docs: HOWTO 2.5.1 release notes: OPTIMIZATION PERFORMANCE COMPATIBILITY 2.6.x released with following new features: SASL support. A more stable connection pool. 3.0.x released, features = 2.6.x, but you can now get it from maven central, please notice: since the domain danga.com is no more under our cont
App Engine 1.3.1からJavaでも非同期URLFetchが使えるようになって、これまで悩まされ続けていた５秒タイムアウト問題が解消されつつある。 非同期URLFetchは以下のような感じ。 非同期URLFetchのサンプル import java.io.IOException; import java.net.URL; import java.util.concurrent.ExecutionException; import java.util.concurrent.Future; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import com.google.appengine.api.urlfetch.HTTPHeader; im
Firefox使いの私は当たり前のように毎日Webフィードを利用している． RSSというべきか良くわからないのだが，呼称を含め仕様が非常に混乱しているようだ． この複雑な流れと現在の状態はいろいろな所で説明されているが，RSSは開発を終了し，Atomは活発に活動を続けているようだ． この流れについてはDave Johnsonの次のプレゼンが詳しい．*1 http://rollerweblogger.org/page/roller?entry=tri_xml_2006_presentation 最近，Atom1.0がIETFによりRFCとして認められたそうだ． 上の解説にもあるが，AtomはFeed（Syndication)だけでなく，プロトコルの開発も進んでいると聞く． IBM Developer 日本語版 : 大変申し訳ありません。このページは無効です。 Implementing the
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
