Who's calling me?
Status Quo Imagine you’re going to find the caller of the current executing method. To make it even more interesting, imagine you’re going to get current thread’s stack frames one by one and filter them to extract or expose some meaningful information. How would you do these? Before Java 9, there were three different approaches that we could use to solve mentioned problems: Throwable::getStackTrac
Javaの文字列の長さを判定するには - $shibayu36->blog;
自分の頭を整理するために書いておく。正しいかは知らない。 まず前提として、Javaの内部表現としての「文字」は16ビット長のUTF-16ということがある。そうすると、普通に長さを取得すると、UTF-16のサロゲートペアで表される文字は2文字と扱われる。 また、文字には合成済み文字という話がある。「か」の後に濁点を結合することで、「が」を表現するみたいなやつ。 これらから、どこまで考慮して文字列の長さを取得するかでやり方が違う。 UTF-16のサロゲートペアを考慮しない UTF-16のサロゲートペアを考慮する 合成済み文字を考慮する 以下試したサンプルコード。 import java.text.BreakIterator; public class UnicodeCharSample { public static void main(String[] args) { // 𪛀あが St
Androidオールスターズ2016 yanzm
A mini intro to web components, starting from what you (presumable) already know and slowly adopting new vanilla web components features. After that, is shows how to accomplish the same using Polymer 2.0. Intended to be instructor led.
Android Local TestでAndroid固有のクラスをモック化する | DevelopersIO
まえがき AndroidでUnit TestsでAndroid固有のクラス、メソッドを使用していると以下の様なエラーができます。 java.lang.RuntimeException: Method d in android.util.Log not mocked. See http://g.co/androidstudio/not-mocked for details. Unit Testsで、テストするコード内にAndroidのクラスであるLog.d()を使用している時のエラーです。 いちいちLogのエラーのために、テスト時にコメントアウトするのも面倒くさいですし、テストしくにくいからLogは書かないようにするのも、デバックがしにくく開発速度に影響します。 どうにかLogクラスをテストの時に実行されない、またはエラーにならない、モック化したいと思います。 Logのモック化 先人のQii
OutOfMemoryError の調べ方 - Qiita
Java 8 で、 Oracle の JVM を前提とした話です。 Java のメモリ管理 これを知っておかないと、 OOME が起こっても、メモリ内で何が起こっていて、どこを調査すべきで、どのように対処したらいいのかが判断できない。 なので、まずは、そもそも Java がどうやってメモリを管理しているのかを知る。 しかし、実際調べてみたら予想通りというかなんというか、量が多くなってしまった。 なので、個々の用語の説明は末尾の 用語集 に押し込めたので、ここではざっくりとした概要だけ記載する。 メモリの構造 超ざっくりとした、メモリ構造を表した図。 おおきく、ヒープ（Heap）領域とネイティブ（Native）領域の２つの領域がある。 ヒープは Java プログラムが使う領域で、プログラム上で生成したオブジェクトは、このヒープ領域に配置される。 一方、ネイティブ領域は JVM が動くのに必要
Gson.fromJson()でList<T>を返すユーティリティをどうやって定義するか - Islands in the byte stream
google/gson GsonでList<T>をデシリアライズするのがけっこう面倒くさくて、以下のようにしなければいけません*1。 Type collectionType = new TypeToken<Collection<Integer>>(){}.getType(); List<Integer> ints2 = gson.fromJson(json, collectionType); ところが、 List<T> を意味する Type 型を Class<List<T>> と Class<T> から作ることができればハックが不要になるはず！とおもって探したところ、かなりマジカルな方法ながらできるとのこと。 java - Gson TypeToken with dynamic ArrayList item type - Stack Overflow というわけで以下のようなユーティリティ
AndroidStudioのInspectionでコードチェックを楽にしてみた。 - Qiita
前置き チームでAndroid開発していて、コーディング規約作りました。 コードチェックはそれを指標としてやってもらっています。 ただ、最近、コードチェックがコーディング規約を守っているか監視する作業みたいな状態になってしまいました・・・。 コードチェックってクラスの設計だったり、メソッド名のわかりやすさだったり、そういう人間にしか出来ないことをチェックすべきで、メンバー変数がmから始まっていないとか。ifのネストの数が多すぎるとかそういうのは機械的なチェックで行いたくなりました。 そこで、AndroidStudioのInspectionを使って、開発中にセルフコードチェックさせようと考え、Inspectionの調査をし始めました。 AndroidStudioのInspectionでコードチェック楽にしようと思ったのだけど、項目多すぎwすで読み始めて半日以上たってる。まだ半分以上ある・・・
Javaユーザに贈るJenkins 25のTips
July Tech Festa 2013 http://www.techfesta.jp/ の講演資料です。 http://www.techfesta.jp/p/program-2.html#A10 ビジネスの変化するスピードが早い昨今、ビジネスのニーズにマッチしたサービスをより迅速に提供するために、アジャイル開発などと共に継続的デリバリーが注目を集めています。 本セッションでは継続的デリバリーにより届けることのできる価値、及びその技術要素について解説します。 また、継続的デリバリーを実践する上で、Jenkinsは中心となり、エンジンとなります。 Jenkinsで継続的デリバリーを実践するときのポイントを事例ベースで紹介します。 事例はNTTデータならではの超大規模プロジェクトでのJenkinsによる頻繁なデプロイを中心とした事例と、小規模ながら自動テスト、マルチ構成プロジェクトを実践した
要約：知らないと損するアプリ開発におけるStateMachineの活用法 - Qiita
はじめに 「知らないと損するアプリ開発におけるStateMachineの活用法(SlideShare full版)」 という内容でクラスメソッド & ゆめみ 合同勉強会 Developers.IO Meetup 09で発表させて頂きました。 これについての要点をまとめます。 内容 StateMachineとは何か？ StateMachineは簡単に言うとUMLの「状態図（ステートチャート）」の実装です。 状態図による分析・設計は、実は色々な分野で活用されていて、iOS/Android/WebApp などのクライアントアプリでは実は非常に有用なものなのです。 ただ、StateMachineの実装は真面目にやると大変です。 例えば、こんな単純な状態図でも 真面目にJavaで実装すると300行以上になります。 https://gist.github.com/mokemokechicken/9e
コールバックと上手に付き合う - Qiita
コールバック、よく使いますよね。 非同期処理の結果を受け取るには、必ずと言っていいほど付き合うことになるコールバックですが、UI のようにライフサイクルを持つオブジェクトと共存するには、考慮すべきことがいくつかあります。 ここでは、おおまかに、上手にコールバックと付き合う方法を見ていきます。 基本となるポイント なんといってもまず抑えなければいけないポイントは、ライフサイクルを持つオブジェクトとの共存です。世に出回っている様々なコールバック管理のためのライブラリは、このライフサイクルを持つオブジェクトとの共存をいかに楽に、あるいは直感的にするか、ということをもとに作られています。 ライフサイクルとはつまり、オブジェクトが生成されてから消滅するまでの一連の流れのことです。 newしたりallocしたりしたタイミングでオブジェクトが生成され、GC に回収されたりdeallocしたりするタイミン
あなたのJavaコードをスッキリさせる、地味に便利な新API 10選（前編） - Taste of Tech Topics
こんにちは！ アキバです。 ．．．T3ブログは初登場かもしれません。ハジメマシテ。 以後お見知りおきを。 いよいよ、2014年3月、Java8が正式公開されますね。 なんと言っても、Java8の注目機能はラムダ式ですので、ラムダ式や型推論に関する記事は多いです。 世の中で「Java8」と検索すると、皆さんいろいろと記事を書かれているので、おおよその事はこれで分かっちゃうような気がします。 が、 実は地味に便利なAPIが追加されていたりすることを最近知りました。 これはあまり触れられていないぞ、と。 というわけで、このエントリでは、あまり日本語で情報の無い、しかし地味に便利なAPIに実際に触れてみます。 大事なところなので２回強調して書いてみました。 今回は、前編として４つ紹介します。 ※APIの紹介と言いつつ、コードにはラムダ式を使ったコードが普通に出てるので、ご了承ください。 (むしろ、
Bitmap.setPixel()をsetPixels()に変えたら３倍速くなったよ
ずいぶん前に画像をモザイク風に加工するエントリを書きましたが、あれを少しいじったらだいぶ早くなりましたよ、というご報告です。 こんなコードでモザイク処理に350～360msくらいかかってました @Override public void onPictureTaken(byte[] data, Camera camera) { BitmapFactory.Options options = new BitmapFactory.Options(); options.inSampleSize = 8; bitmap = BitmapFactory.decodeByteArray(data, 0, data.length, options); Bitmap b = bitmap.copy(Bitmap.Config.ARGB_8888, true); Log.d("CameraSample",St
きみのインターフェイスの修飾子、冗長なんだけど？ - _development,
内部インターフェイスにstatic修飾子つけちゃう奴 内部インターフェイスは暗黙的にstaticになります。 以下のように、static修飾子を明示したNestedStaticInterface、明示しないNestedInterfaceがある場合、コンパイルされたインターフェイスはともにstatic修飾子を伴います。 package com.uphyca.example.interfacedef; public class EnclosingClass { // static修飾子を明示する public static interface NestedStaticInterface { } // static修飾子を明示しない public interface NestedInterface { } } コンパイルされたNestedStaticInterface public abstra
Android組込みのHttpComponent（HttpClient）の正しい使い方といくつかのtips - terurouメモ
ブログ等に掲載されているHttpComponentのサンプルコードは、重要なところが端折られて紹介されている（というか間違っている事を知らずに書いている疑惑すらある）ことが多いので、正しいサンプルコードを書いておく。 まぁ、ここだけでなくApache HttpComponentsのドキュメントもちゃん読みましょう。あ、Androidのリファレンスにはロクに使い方が書いてないので、あんなゴミだけ読んでてもダメですよ。 要点 ポイントは2つ。 ResponseHandlerを使ってコードを書く HttpResponseの内部リソースを自動で解放してくれるので、ミスがなくなり、コードも簡潔になる。ブログ等ではHttpResponseを使わないコードもよく掲載されているが、リソースの解放処理が記述されていないことが多いのであまりよろしくない。 なお、ResponseHandlerを使わずに自分でリ
Javaコストメモ(Hishidama's Java cost Memo)
//throw-catch Exception t = new RuntimeException(); try { throw t; }catch(Exception e){} ←これをループ //synchronized synchronized(クラス.class) { } ←これをループ try～catchはJDK1.6で速くなっている。 逆に空ループはJDK1.4→JDK1.5で微妙に遅くなっている。とは言っても100万回で1ミリ秒未満なら、他の実行速度に比べると無視できる話だ。 synchronizedはJDK1.5で速くなったのに、JDK1.6で遅くなっている。何が変わったんだろうなぁ？ synchronizedは確かに無処理に比べれば遅いが、インスタンス生成と比べれば、文字列結合2～3個分と同じくらい？ もちろんマルチスレッドの競合の頻度にもよるだろうけど、そんなに目くじら立
Android4.2以上でJavascriptからJavaメソッドをコールするには - hyoromoのブログ
セキュリティ絡みの問題でJavascriptからアプリ上のJavaメソッドをコールする対象へ@JavascriptInterfaceアノテーションを付ける必要があります*1。このアノテーションを付けないとAndroid4.2以上の端末ではJavaメソッドがコールされません。以下、付けてみたサンプルコードです。 // getHogeメソッドはJavascriptからコールされる対象 public class LinkInterface { @JavascriptInterface public String getHoge() { return "hoge"; } } この時にProguard設定に注意する事があります。何の設定もしていないと暗号化され、アノテーションが無効になってしまいます。そこで以下の1文をproguard-project.txtもしくはproguard.cfgに追記すれ
文字列連結と+演算子について整理しておく - 日々常々
何度か書いているけど、整理的な意味で。今後は「このエントリ参照」にするつもりで書いてみる。 文字列連結から見るシステム内で扱う型について - 日々常々 Javaプログラマであるかを見分ける10の質問 に答えてみる - 日々常々 String の連結ネタの続き - 日々常々 前書き Stringなんてboxed primitive*1でもないただのクラスのくせに、中途半端に贔屓されて*2てムカつく*3し、その中途半端ぶり*4がなお腹立たしい……。そして +演算子 で連結して問題が起こるような状況、つまりそんな長々と文字列連結したいような場合は、きっと他の適した型がある。StringBuilderじゃなく、もっと別の何か。業務要件で文字列を組み立てる目的を考えれば、たぶんテンプレート的なものに落ち着くんじゃ無かろうか。ライブラリ的な所でなら逐次書き出し等になるような。どちらにせよ文字列の組み立
画像ダウンロードでAsncTaskを立ち上げまくるのはやめましょう - satohu20xx's diary
ListViewでよくあるサンプルで画像をダウンロードするたびにAsyncTaskをたちあげてる奴があるけどそれはやめましょう @Override public View getView(final int position, View convertView, ViewGroup parent) { ViewHolder holder; if (convertView == null) { convertView = mInflater.inflate(R.layout.search_row, null); holder = new ViewHolder(); holder.Title = (TextView)convertView.findViewById(R.id.textTitle); holder.Thumbnail = (ImageView)convertView.findVi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Eclipseデバッガを活用するための31のtips
https://ryoasai.hatenadiary.org/entry/20110321/1300696942