Google I/OでLG G Watchをもらったのだけど(※画像は僕の手ではない)、見た目がどうもおもちゃっぽい。 それで「腕時計 バンド」で検索して上に出てきた丸ビルにあるアルキメデス・スパイラルっていう時計屋に行ってきた。 バンドを変えてもらったら愛着が出て、今までだったら充電忘れた→めんどくさい→まあ付けなくていいかって扱いだったのが、ちゃんと充電して付けようって気持ちになりました。 ちょっとしたライフハックでした。 賛否両論あるAndroid Wareですが、雑に通知を送ってもそれなりに表示してくれるし、書こうと思えば好きに画面が書けるし、新しい知識を必要とせずにアプリが作れるし、設計は悪くないんじゃないかなって思う。 Android Wearはダサいという声をよく聞くけど、モトローラはデザインに力を入れてて、5月にフェイスのデザインコンテストをやってて面白いなーって思いながら

さっそく自分のアプリにMaterial Designを適用しようとしてAndroid Lでしかテーマが使えないとか、サポートライブラリがうまく動かないとかで挫折したみなさんこんにちは。 自前でゴリゴリテーマを書いたり、サポートライブラリのバージョン指定を + にしてたらいつの間にかバージョン上がってて破滅した、なんてこともありそうですし、僕はまだ様子見てます。 ただし、Material Design自体がAndroid専用のものではなく汎用的なデザインガイドラインなので、新しいSDKやライブラリを使わなくてもガイドラインに従うことでそれっぽく見せることができます。 Introduction - Material Design - Google design guidelines にはアニメーションやエフェクト以外にも、タイポグラフィの扱い方、余白の取り方、Dividerの使い方などがありま

社内には障害が起こったりすると、次回失敗しないように "Failure teaches success" っていう知見を蓄積するシステムがあるのだけど、この度 プライベートで書いてるアプリ で障害を起こしてしまったので、知見をブログに書くことにしました。 概要 今日の夕方にmiyagawaさんからAftershowが表示されないと連絡をいただきました。 発生原因 アプリ内でのデータの持ち方にいろいろ問題がありました。 Rebuild.fm for AndroidではEpisodeは端末のsqliteに保存していて、ActiveAndroidで読み書きしていましたが、リスト表示するために何かのカラムでソートする必要があったのだけど、日付は "Jun 15 2014" みたいに入ってくるからソートしづらいなと思って、urlを見てたら "http://rebuild.fm/10" みたいにスラッ

当方Androidエンジニアをしておりますが、プライベートでアプリを作るとき、画像リソースについてはAndroid組み込みのものを使ったり、Fontawesomeを使ったり、フリー素材を使ったりしています。 しかし配色はインターネットに落ちていなくて、自分でやるとイマイチで、いい感じにしたいという気持ちがありました。 そこで、調べたり試行錯誤をして知見が得られたので、配色に悩むエンジニアのために共有します。 3行まとめ デザインはセンスで行うものではなくロジックで成り立ってる、つまり努力でなんとかできる Color Scheme Designer 3 便利 配色を学ぶのには下のスライドが一番分かりやすかった 色彩センスのいらない配色講座 from Mariko Yamaguchi STEP 1. 対象に興味を持つ 〜〜で必要だから勉強しなければって始めてたものが長く続いたことがないので、

関数型LT大会で「実社会の問題を解決する関数型言語」というタイトルで発表しました。 というのも、会社で「すごいHaskellたのしく学ぼう！」の輪読会をしていて、最初こそ10人以上の人が参加していたのだけど、章が進むごとにどんどん人が離脱していって、主催者としてはなんとか完走したいという思いがあったので、調べたのですが、 ヒアリングから、この二つの線がクロスしたときに、人は離脱するという知見が得られました。 ということで、Haskellに対して実用性を見出したいと思いながら半年を過ごしたのですが、実用的 = 仕事で使うということであれば、今の現場でHaskellに移行するのは現実的ではありません。 でも、Haskellには関数型言語のエッセンスが詰まっていて学びが多かったと思っていて、直接的には使っていないけど、概念として役立つことがあると思ったので、それを伝えるために今回文章に起こしまし

前日にE2Eのテストの知見共有会に出て、その翌日にAndroidのテスト勉強会に出たので思ったことなど。 どこまで自動化するか UIテストの自動化がコストと見合うかという議論をしてて、UIテストって価値ある状態を維持するコストが高かったり、テストの実行に時間がかかったり、プロジェクトによるところもあるけど、うまく回すの難しいから無理に自動化しなくてもいいのではという感じになった。 特にAndroidは、RobotiumやらuiautomatorやらSelendroidやら、あるいはその上のレイヤーのAppiumやCalabashとか、いろんなツールがあるのだけど、結局どれが生き残るのか全然読めないし、意気揚々と導入したフレームワークが数カ月後にDeprecatedになって大爆死なんてことがカジュアルに起こり得るので、特定のフレームワークにあまり依存したくない。 それでどうしたらいいかという

今まではいかに綺麗なプログラムを書くかっていうことに時間に割いてきたのだけど、最近デザインの重要性をひしひしと感じるようになり、本当にユーザーが求めるものって何なのか知りたくて、デザインリサーチをすることになりました。 そこで、本を読むなどして調べたことをまとめました。 デザインリサーチとは 様々な方法論を用いて、製品やサービスの現在、または将来のユーザーや環境を詳しく調査し、分析を行うことである。 わざわざデザインリサーチをする理由 "エンジニア、デザイナー、営業担当部の人たちが、自分たちは客にとって役立つことを知っていると思い込んでいる。特別な観察力と経験のあるデザイナーならこれは本当かもしれないが、そんな人たちは非常にまれで、しかも成功した人々は、注意深い観察と、特定の文化や環境にいる人々の理解とによって、自分たちの感を「訓練してきた」だけなのです。" デザインって才能がある人しか出