ブランチ切り替えたり、ちょっと修正した時に、build.gradleが変わってしまって、エディタ部分の右上のSync Nowを毎回クリックするのが面倒くさくてショートカットないかなーと思ったら、デフォルトでは設定されてなかったので、設定した。
Keymapでgladle syncとか調べてもらえるとすぐ気がつくと思う。
どういうショートカットキーを設定するのか、非常に悩む。
Syncという事で、
shift + command + s
を設定した。保存っぽい印象になっちゃう気もするなー。と思う今日この頃。
Rebuild.fmに何度か出演している、Higeponさんがオススメしていて、日本語版が出たというので買ってみて読んでる。
ソフトウェア開発者として生きていく為に技術以外の必要な事が一通り書かれているという感じ。もっと早く読みたかったなぁという本。ソフトウェア開発者として生きていくぞ！という気持ちで就職活動してる人とか、新卒数年目の人とか、もうおっさん側の人間だわーという人とか。いろいろな人が読んで役に立つと思います。
まだ最初の方で読み終えるまでには時間がかかりそうだけど、読み終えたらこれはめっちゃいい本だから絶対読んだほうがいいよ！って読んでない人に渡そうと思ってます。Kindle版がないので、読むの結構大変。。。。。
一言で言うと最高なので意識が高まればこのページのリンクから本を購入してみてください:D
Android StudioのPreview版を使っていると、 Instunt runを使うために
Instant Run requires a newer version of the Gradle plugin.
と言われてアップデートしてねと言われてアップデートされる。 けども、まだalpha1とかなので、それはコミットしたくない。
そのまま使いながら開発してると、それがdiffとして出てきてしまうので、そこだけ無視したかった。
参考 http://qiita.com/usamik26/items/56d0d3ba7a1300625f92
設定
git update-index --assume-unchanged build.gradle git update-index --assume-unchanged app/build.gradle
解除
git update-index --no-assume-unchanged build.gradle git update-index --no-assume-unchanged app/build.gradle
具体的にどのファイルが更新されるのかは、環境によって違うかもしれない。
現在assume-unchangedなファイルがあるかどうかは以下で確認出来る
git ls-files -v | grep ^h
assume-unchangedとskip-worktreeの違いについて調べてみようとして、
実際にbuild.gradleが更新されるmergeを行ったのだけども、
どちらのケースも同じような以下のメッセージが出たので違いがよくわからなかった。
僕のテスト方法がダメだったのかもしれない。
error: Your local changes to the following files would be overwritten by checkout: build.gradle Please, commit your changes or stash them before you can switch branches. Aborting
まぁ、参考したqiitaの説明をよむ感じだとassume-unchangedを使っとくのが無難な気がするのでそうしとこうという感じ。
そして、たまにこの設定をしているのを忘れていて、build.gradleを修正したはずなのに、何でgit diffしても変更してない事になっているんだ！！！という事態になる事があるので注意。
前回のお話
前回は過去に6から8にアップグレードしたメモが出てきたので書きました。 今回は8にアップグレードした時にやったことを書きます
butterknife/CHANGELOG.md at master · JakeWharton/butterknife · GitHub
こちらをまず読む。
大きな変更点としては、@Bindが@BindViewに変更になっています。
あとは、unbindの部分。
compile 'com.jakewharton:butterknife:8.0.1' apt 'com.jakewharton:butterknife-compiler:8.0.1'
今回も置換コマンドを使ってやります
perl -pi -e "s/butterknife.Bind/butterknife.BindView/g" **/*.java perl -pi -e "s/\@Bind/\@BindView/g" **/*.java
importの部分の修正と、アノテーションの変更の部分
今までは以下のようにしていましたが、
ButterKnife.unbind(this);
http://jakewharton.github.io/butterknife/#reset
↑によると、以下のようにして対応する必要がありそうです。 これは手作業で直していくのがよさそうかな。。。
public class FancyFragment extends Fragment { @BindView(R.id.button1) Button button1; @BindView(R.id.button2) Button button2; private Unbinder mUnbinder; @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { View view = inflater.inflate(R.layout.fancy_fragment, container, false); mUnbinder = ButterKnife.bind(this, view); // TODO Use fields... return view; } @Override public void onDestroyView() { super.onDestroyView(); mUnbinder.unbind(); } }
という感じで終わりです。僕の作っているアプリではこれの修正で大丈夫そうでした。 さくっと出来るので、やれる時にやっとくのがよさそうです。
ちょっと前に8系が出た今日この頃ですが、6系から7系にアップグレードした時のメモを発掘したのでブログ書いときます。
必要な情報は参考にしたページに書かれてあるので、置換に使ったコマンドだけ挙げときます。
perl -pi -e "s/\@InjectViews/\@Bind/g" **/*.java perl -pi -e "s/\@InjectView/\@Bind/g" **/*.java perl -pi -e "s/ButterKnife.inject\(/ButterKnife.bind\(/g" **/*.java perl -pi -e "s/ButterKnife.reset\(/ButterKnife.unbind\(/g" **/*.java perl -pi -e "s/import butterknife.InjectView/import butterknife.Bind/g" **/*.java
この辺のコマンドを上から順番に流しとけば少なくとも僕の環境では大丈夫でした。@InjectViewくらいしか使ってなかったので移行も比較的楽でした。
※置換コマンドを実行する順番には注意してください
置換の部分に関しては、置換を失敗してもコンパイルの段階でエラーになってくれるので、比較的えいやでやってしまって大丈夫そうかなと思いますたぶん。
Clean Projectとか、Android Studioやエミュレータを一度終了して起動したりとか、 いろいろ試したけどダメだった。 一度この状態に入ると、Instant Runをやめても解決されなかった。。。謎。
File -> Invalidate Caches / Restart
をするとよさそうというのを見つけた
でもこれでもダメな時があった。。。
結果、gradle-wrapper.propertiesに書いてある、gradleのバージョンを現在の最新版の2.11にアップすると解決した。
StackOverFlowのどこかに書いてあったのを見つけてバージョンアップしたけど、どこだか忘れてしまった。。。
個人的にWordPressを使った環境構築をする機会があったのでメモ。 環境構築はするけど、WordPressは殆ど触った事がない人間です。
こちらのページが結構参考になりました。
VCCWとWockerの比較。wordpress開発の新しい選び方。 | codechord
WordPressの開発では、VCCWとWockerというメジャーなものが２つあって、前者はVagrantベース。後者はDockerベース(Vagrantの中でDockerを起動している)のよう。
VCCWはガッツリいろいろなものが揃っているのに対して、Wockerはシンプルで起動も軽量という特徴があります。
僕は両方使ってみた上での比較はしませんでしたが、WordMoveが最初から入ってるのでよさそう。という理由でVCCWを使って環境構築をする事にしました。
こちらを参考にやった。細かい説明は↑に書いてあるのでコマンドだけメモしておく。 Vagrant環境は既に構築している前提。
vagrant plugin install vagrant-hostsupdater vagrant box add miya0001/vccw git clone https://github.com/vccw-team/vccw.git wordpress-sample cd wordpress-sample vagrant up
※vagrant-hostsupdaterの機能で/etc/hostsに設定を入れるので、ルートのパスワードが途中で要求されます
これでしばらく待った後、以下のURLで見れるようになる。
めちゃ簡単だった。
これも先ほど上げた参考サイトに書いてあった。
cp provision/default.yml site.yml
コピーして出来たsite.ymlを編集していく。
この辺を修正しました。
一通り終わったら、
vagrant reload --provision
これで設定が反映される。
WordMoveとはひとことで言うとめっちゃ便利です。
以下の２つのブログを読むとだいたいわかると思います。
WordMoveのDeployはrsyncとFTPの２種類出来るようになっています。
上であげた参考サイトにFTPを使った場合だと、
ただ、やりとりするファイルが多いと接続が切れたりする事があるようです。
こう書かれてあったので、出来ればrsyncでやれたら幸せだなぁと思っていました。しかし、残念ながら、hetemlではrsyncが動かないようでした。（僕が確認した今現在）
vagrantの中でrsyncをコンパイルしてバイナリを作って、それをheteml上で動かします。
vagrant ssh cd /tmp git clone git://git.samba.org/rsync.git cd rsync git checkout v3.0.9 # masterだと最新のautoconfを要求されたので一つ前のバージョンにした ./configure make
これでrsyncというバイナリが作成されます。
heteml上では、自分のホームディレクトリにbinフォルダを作り、そこにパスを通して先ほど作成したrsyncを置きます。公開鍵をheteml上においたり、~/.ssh/configに設定したりしておくのは各自やっておくと便利です。
# hetemlの自分のホームディレクトリ mkdir bin # ↑で作成したbinフォルダにrsyncを置く # 手順省略 # .bashrcに以下を追記 export PATH=$PATH:$HOME/bin # 読み込み直し＆確認 source .bashrc rsync --version # これでバージョンが出れば成功
以上でheteml上でrsyncが動くようになりました
Movefileを編集します。僕の場合は以下のようになりました。
local: vhost: "http://vccw.dev" wordpress_path: "/var/www/wordpress" database: name: "wordpress" user: "wordpress" password: "wordpress" host: "localhost" heteml: vhost: "http://hoge.heteml.jp/vccw-sample" wordpress_path: "/home/sites/heteml/path-to-your-folder/web/vccw-sample" database: name: "_heteml_user" user: "_heteml_user" password: "password" host: "hoge.heteml.jp" charset: "utf8" exclude: - ".git/" - ".gitignore" - ".sass-cache/" - "bin/" - "tmp/*" - "Gemfile*" - "Movefile" - "wp-config.php" - "wp-content/*.sql" ssh: host: "hoge.heteml.jp" user: "hoge" port: 1234 rsync_options: "--verbose"
※パスワードやユーザ名や、port番号などは適当なものに変更しています。また、sshは鍵を通しておく事で、パスワードを記述するがなくなるのでオススメです。
Movefileの設定について詳しく知りたい方は、僕が挙げた参考サイトに解説がのっていたり、VCCWをgit cloneした時にデフォルトで作成されているファイルに説明があるのでそれを参照してください。
hetemlはDBへのアクセスがsshを踏み台にしてDBアクセスしないとダメですが、これもよしなにWordMoveがやってくれているっぽいので感動しました。
vagrantの中に入ってDeployします。
vagrant ssh cd /vagrant wordmove push -wtplv -e heteml
オプション周りはhelpを見てある程度ご察しください。基本的には、git管理されるであろう部分をそのままDeployのオプションに加えているイメージです。
Options: -w, [--wordpress], [--no-wordpress] -u, [--uploads], [--no-uploads] -t, [--themes], [--no-themes] -p, [--plugins], [--no-plugins] -l, [--languages], [--no-languages] -d, [--db], [--no-db] -v, [--verbose], [--no-verbose] -s, [--simulate], [--no-simulate] -e, [--environment=ENVIRONMENT] -c, [--config=CONFIG] [--no-adapt], [--no-no-adapt] [--all], [--no-all]
-eは、WordMoveで設定した名前みたいなものです。stagingとか、productionとか複数設定できるので、非常にべんりー
ちなみに、
wordmove pull --all -e heteml
こうすると、サーバ上のDBやらいろいろ全て取ってきて、いい感じに手元に反映してくれます。これで開発環境すらない環境でもさくっと開発環境が作れるかも！？但し、DBの容量が大きかったり、uploadsフォルダの中に結構ファイルが入ってると上手く動かないかもしれませんねぇ。
注意点としては、↑のコマンドのpullをpushに変えるとローカルの内容を全てサーバ上に反映してしまいます。DB周りはバックアップを取ってくれるらしいのですが、uploadsフォルダなどはどうなんでしょうね。この辺は、誤ってこういう事が置きないようにシェルスクリプトで指定したコマンドのみ実行するなどの対策をしておきたいところです。
一先ず、これでDeployも完了〜
VCCWでは、.gitignoreでWordPressのソースや、Movefileなど、無視するようになっています。git管理しとかないと、チームで共有出来ないので、以下のファイルについては無視しないようにしました。
Movefile www site.yml
また、WordPressのソース自体にも、.gitignoreがあって、.htaccessを無視するようにしていたので外しました。以下の場所にあります。
www/wordpress/.gitignore
.htaccessはApacheだけに作用するものなのでデフォルトで無視するようにしているんですかね？今回はhetemlでApacheなので無視しないようにしました。
以上で一通り終わり！
と思ったけど、VCCWがバージョンアップした時にこのやり方だと、ちょっと面倒くさいかも？という感じ。。
いかがでしたでしょうか？今までWordPress微妙にしか絡んでこなかったですが、WordMoveが便利過ぎてすごい！という感じになりました。今後もあまり絡む機会はないと思うけど、Deployの自動化などは出来そうであればやってみたいなぁと思います。
