アプリの宣伝
たまには自アプリの宣伝をw(このブログに訪れてくれる方自体かなりボリューム低いんですけどねぇーw)
地図DB:
https://play.google.com/store/apps/details?id=jp.gr.java_conf.yamato.android.mylocations
カッコ悪かったアプリのアイコンもマテリアルな感じにグレードアップしました。といってもクソアイコンですが。
地図に自分でマーカーをどんどん立てていけるというアプリです。簡単なようで難しいんですよ。類似アプリすくないですよね。。位置情報を取得しますが、それをサーバに投げたりとかは神に誓ってしておりません。気になる方はWireSharkでも使って解析してみてください。そんな情報を得ること自体、自分にとってメリットとして感じていないので。
自分はスマホで新しいことができたらと、自分なりに提供していくのが何よりも開発のモチベーションとなっています。ものづくりは結構ストレス解消になるんですよ。そういや、ZUNさんの東方紅魔郷も本人のストレス解消で作ったとか。この方はヤバいですね。尊敬できる人のひとりです。
Kotlin
今年のGoogle IOにて、Androidの第一級開発プログラミング言語のひとつとしてKotlinを採用すると発表があったそうです。Kotlinは記述がSwiftに似ていてスッキリ書けるので、なかなかいいなぁと思ってます。
KotlinとSwiftで大きな違いを感じるのは配列の扱いかなと思います。KotlinではJavaの配列、Swiftでは値型(コピーオンライト)ということで、関数に配列を渡すときなどは両者はっきり区別したほうが良いですね。
自分はSwiftの配列に最初違和感覚えたけど、動作原理を知ったら、こっちのほうがより自然なものに感じるようになりました。配列はポインタと思いこんでいたんで、新しい原理を理解するのはちょっと抵抗ありました。
KotlinとSwiftどっちがいいか、まだ良くわかりません。ただ、JavaやObjective-Cは20世紀にできた言語ですので、新しい言語のほうがやっぱスッキリできているんです。もう若くはないですが、両者ちゃんと勉強していかなきゃなぁ。。
プログラムのバグかと思ったら自分のバグだった
くっそー、バグの原因全然わかんねぇーって約数時間粘っていたら。。実は自分のバグだった（自分がプログラムのバグだと思い込んでいた）
いままでの経験上、コンピュータに勝った試しはありません。プログラムは本当に書いたようにしか動かないし、それが崩れたことは一度もありません。
もし、そんなことあったらカオスですね(笑)。プログラムなんか書く気なくすでしょう。
人生の最終結果は死
僕らは生きていますがいつか死を迎えます。どんなに知識を習得してもどんなにお金を稼いでも、物理法則で支配されたこの世界ではその物体は熱エネルギーによるエントロピー増大による死を迎えると思われるのです。人々は神を崇めますが、僕は神は物理法則と考えます。意識が先か物体が先か。。
とにかく、どんなにあがいても死を迎えるのでしょう。だから僕は人生のその瞬間の価値を大切にしたいと思います。たとえ成功しなくても、それはその人の人生です。その人の人生を如何に肯定するか。生きていて良かったと思えるか。物理世界では限りがあるようなこの世界の人生で意味のある行動を少しでも進めていくことが人生なのではないかと思います。
一回きりの人生、楽しく生きましょう！
なーんてね(笑)
FastLruCache
気になってしょうがなかったのでシングルスレッド用のFastLruCache作りました。古い端末ではちょっと早くなった気(？)がします。。
本当は元のソースからsynchronizedだけ外したやつ作っても良かったけど、それもそれでどうかなぁと思ったので若干マイロジックで作ってます。AndroidのLruCacheはAndroidでカスタマイズしたLinkedHashMapを使っていたので、本家のJavaライブラリのLinkedHashMapをベースに作りました。本家のやつは一回で一個しかeldestエントリをremoveできないので、大変トリッキーなコードになってます。trimToSizeで毎回Iteratorオブジェクトを作っているのです。これはこれでどうなんだろうってコードです。JavaのMapはIteratorでしか順序アクセスできないのはどうなんだろうと思う次第です。でもsynchronizedでないLruCacheが試せたので、まぁゆっくり寝れそうです(笑)
LruCache は遅い
自分が初めてGitHubで公開しましたGalleyFragmentでBitmap用のキャッシュとしてLruCacheを使用しました。でも無駄なパフォーマンスを使うことになりそう。なぜならLruCacheはスレッドセーフ（synchronizedの山）だから。自分はシングルスレッド(UIスレッド)でこのクラスのキャッシュ機能使うつもりでいたので、ちょっとショック。でもAPIドキュメントにしっかり'thread-safe'って書いてある(笑)。ソース覗いてみて、この程度のコードならスレッドセーフじゃないやつ自作してもよい感じ。ひまなときやろう！本当にひまなとき！。。複数スレッドでキャッシュ機能を使いたいときにはLruCacheは便利なのかも。。
以下はリポジトリです。
