View に渡す Context には注意しようと思った

View を生成するときに必要な Context で嵌りましたのでメモ。
2.x系のときに作成したアプリを 4.x系にしようとしたとき Theme は Holo.Light なのに
Dialog で表示される EditText の背景色が Holo.Light ではありませんでした。

原因は EditText を生成するときに渡す Context が Holo.Light を設定した Context では
ありませんでした。
作ったアプリの Theme は Activity ごとに設定しており、Application では Theme を何も
設定していなかったのでこのようなケースでは Activity を渡す必要がありました。
問題となっていた部分では getApplicationContext() を渡していました。

アプリケーション全体で共通の Theme を設定しておいたほうが得策だったと思いました。
今後のアプリ作成に生かしていこうと思います。

java.exe が終了できずに Java Update を実行できなかったとき

Java の更新があったので早速、実行してみようとすると java.exe が残っているので
終了してくださいと表示されていました。
思い当たる節は無かったのですが、タスクマネージャーのプロセスを見てみると
確かに java.exe が実行中だったのでプロセスの終了で終了させてから再度実行すると
まだ解決せず java.exe を終了してくださいと表示されました。

色々と確認していたところ Jenkins Slave をサービスで実行していたことを思い出しました。
Jenkins Slave をサービスとして稼動させていたのでプロセスを終了してもサービスを停止
しなければ何度でもプロセスは復活していました。
サービスを一時的に停止させてから実行してみると無事に更新できました。

Ansible で UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7

Ansible で次のエラーに遭遇しました。

UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position 16: ordinal not in range(128)

調べてみると ": " が原因でした。

# ": " が含まれている
lineinfile: dest=/etc/aliases regexp="^#root:.+marc" insertafter="root: root@example.com" line="root: root@example.com"
# ": " を ":\ " に変更
lineinfile: dest=/etc/aliases regexp="^#root:.+marc" insertafter="root:\ root@example.com" line="root:\ root@example.com"

ダブルクォテーション(")で括れば解決できるというページもありましたが、私の場合は
\を追加してエスケープすることで解決できました。
(内容に誤りがありましたので、追記しました)

Ansible は YAML で記述するので今回は YAML のフォーマットに引っ掛かったようです。
気付くまでに 1時間くらい費やしてしまいました。

仕事を楽しくするマウス使わないで Google 検索の4ステップ

Google で検索結果を見るときに画面をスクロールしたり、検索結果サイトのリンクを
クリックするには、いつもマウスを使っていましたが、最近になってマウスを使わなくても
リンクをクリックしたり、ページ移動できることを知りました。

方法は簡単で

1. アドレスバーまたは検索ボックスで検索条件を入力
2. 検索結果が表示されたら Tabキーを1回押すまたは Tabキーを1回押して
   上下キーのどちらか片方を押す
   
3. するとキャプチャの赤枠内のように右向きの矢印が表示されます
4. 上下キーを押すと矢印がページ内の検索結果ページのリンク位置へ移動します

別タブでリンク先を表示するには Ctrlキー + Enterキー
新規ウィンドウでリンク先を表示するには Shiftキー + Enterキー
Enterキー でリンク先を表示します。

Windows 環境で確認しました。
Mac 環境でできるか分かりませんが、できる場合は教えていただけると嬉しいです。

今まで検索した後はマウスに手を伸ばしていて、キーボードから手が離れるのは嫌だなぁと
感じていたのですが、この tips があればキーボードから手が離れる回数が減るので助かります。
今までも Tabキーを押すことで移動はしてくれましたが、そんな所に移動しなくても良いのに…と
思っていたので。

ちなみにこの tips は Chrome、IE で動作するようです。
Firefox で試してみましたが、反応しませんでした。

環境
Windows7
Chrome
IE11

Android Studio のカラーテーマに目に優しい Solarized を設定する

今回は Solarized という目に優しいカラーテーマを Android Studio で利用してみます。

Android Studio でカラーを変更しようと思うと Settings > Colors & Fonts からできますが
変更できる項目が多いので 1から始めるとなると結構、労力が要ると思います。

簡単に導入できないか探してみたところ GitHub で IntelliJ IDEA 用が公開されていました。
Android Studio のベースは IntelliJ IDEA の Community Edition だったはずですので
これを利用させていただこうと思います。

README.md にインストール方法がありますが、Android Studio の場合は少し異なるので
導入したときの手順を残しておきます。

1. Solarized Dark.icls、Solarized Light.icls をダウンロード
2. ダウンロードしたファイルを Android Studio の設定情報が保存されているフォルダ
   %USERPROFILE%/.AndroidStudioBeta/config/colors に配置します。
3. Android Studio を起動(または既に起動している場合は終了して起動し直す)
4. Settings > Colors & Fonts の Scheme name から Solarized DarkまたはSolarized Lightを
   選択して Apply で適用

手順は Windows 環境を対象にしています。

前はコントラストが高い設定でも平気でしたが、最近はコントラストが低いほうが見やすいと
感じてきていたのでありがたいです。
職業柄、目を酷使するので助かります。

環境
Android Studio 0.8.9

プログラミング中にネーミングを考えるときに参考になったサイト

私の場合、プログラミング中にいつも悩むのがネーミングです。

フォルダ名やファイル名、クラスにメソッド、変数といたるところで名前をどうしようか
いつも悩みます。

名前をつけるときには英訳サイトを駆使したり、今まで作成したものを流用していました。
そんなとき、デベロッパーのためのネーミング辞書 codic というサイトを知りました。
このサイトを知ってからは名前の付け方のレパートリーが増えました。

候補が見つからないときもありますが、そんなときは別の方法を探せばいいのですから。
ユーザー登録すればネーミングを提案することもできるようです。

実のところ、自分でこういうWebサービスを作ってみたいなぁと思っていたのですが
先を越されてしまいました。残念。

Git で master ブランチに merge されたらデプロイするというフローが面倒臭いと言われた

複数人でとあるシステムを開発しているとき、共有で使用されている開発環境がありまして
システムの確認にはこの開発環境を利用しています。
(よくある構成かと思います)

普段、開発環境にシステムを反映するときにはファイルをアップロードするのですが、複数人で
開発していること、ファイルのアップ漏れや意図しないファイルの上書きによる問題の発生を
予防したかったので Git のブランチが merge されたら開発環境に反映される仕組みを導入して
おりました。
(仕組みについては今度投稿したいと思います)

この仕組みを導入して半年以上経っていましたが、上述の懸念事項は発生しませんでした。
merge は誰でも出来るようになっているのですが、メンバーが Git について詳しくないこと、一応
私がシステム開発を主動するポジションでしたので merge は私が行っていました。

ある日、システムの修正が発生し、対応は出来たのですが対応自体は他のメンバーが行っていて
いつも通り私が merge して開発環境に反映しました。
すぐに修正できる内容だったのですが、開発環境への反映がすぐに行われなかったので
統括している方に何故、すぐに反映されないのかと聞かれました。

そのとき、この仕組みのことを説明すると何でそんな面倒臭いことをしているんだと言われました。
正直、こっちが「えっ？」って思いましたが、堪えました。

この仕組みを利用しなければ、複数人で作業するときには冒頭の懸念事項があるので
都度、他メンバーに知らせたり、ファイルが上書きされるものなら元に戻したりする必要が
あって、そのときはロスが発生して無駄な時間を費やすのに。

コヤツは何を言っているんだ？自分には関係無くてもチームとしては関係あるんだよ！
チームの他のメンバーのこと考えているのか？と思いましたが、口には出さず堪えました。

モヤモヤした気持ちを鎮めるために、今まで開発環境への反映にどれだけの回数が
実行されたか確認したところ数百回行われていました。

この数を見て私は面倒臭いとは思いませんでした。
むしろ、この回数分はロスが発生する可能性を防げたと思いましたし、そう自分に言って
気持ちを鎮めました。