コミットしていない変更を間違えて取り消してしまったので復活させる（ことができるかもしれない）
はじめに
git の機能で復活させるわけではないです
Macの標準アプリであるテキストエディットにはバージョンを戻す機能がある
表題のミスをしても復活できないかと検索していくとこんなページを見つけました
ベストアンサーになっていないのに51評価されているものがあったので見てみると、テキストエディットの機能で戻せるかもしれないとのこと
実験として、適当に書き換えたファイルを git checkout した後で保存し、さらにテキストエディットで開き「ファイル > バージョンを戻す > すべてのバージョンをブラウズ」を選択したのですが、目的のバージョンが表示される場合と表示されない場合がありました
皆さんはうまく復活させられることを願っています
SubversionリポジトリをGitへ移管する
はじめに
一昨年末の下書きを見つけ、せっかくなので公開。当時はこれでうまくいきました。
Subversionリポジトリからソースを回収
流れ
- SubversionユーザとGitユーザをマップするファイルを作成
- git svn init
- .git/configにSubversionリポジトリをどのような形式で回収するかを定義する
- git svn fetch
Subversionリポジトリの構成が結構複雑で、branchesの場所を色々定義したいがためにこのような手順になってます。単純な構成（trunkだけとか）であれば直でcloneでもいいと思います。
SubversionユーザとGitユーザをマップするファイルを作成
どこでもいいけど自分はホームディレクトリに作りました。マップしたいユーザが複数いる場合は改行して追加して下さい。
$ vi ~/.svnauthors $ cat ~/.svnauthors svn_user_name = git_user_name <git_user_email>
git svn init
ソース回収するディレクトリでinit。branchesは複数指定可能、今回は無いけどtagsもbranchesとして指定するのだと思われる。
$ git svn init \ > --trunk=trunk/ \ > --branches=branches/branchA/* \ > --branches=branches/branchB/* \ > --prefix=svn/ \ > svn_repo_url
これでカレントディレクトリに.gitが作られるので、それを修正していきます。
.git/configにSubversionリポジトリをどのような形式で回収するかを定義する
$ git config --add svn.authorsfile /Users/murakaming/.svnauthors
$ cat ~/.git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[svn-remote "svn"]
url = svn_repo_url
fetch = trunk:refs/remotes/svn/trunk
branches = branches/branchA/*:refs/remotes/svn/branches/branchA/*
branches = branches/branchB/*:refs/remotes/svn/branches/branchB/*
[svn]
authorsfile = /Users/murakaming/.svnauthors
authorsfileの定義の追加と、branchesをrefs/remotes/svn/直下に置かないようにしています。branches定義の修正はコマンドを使わずエディタで修正しました。
git svn fetch
git svn initしたディレクトリでfetch
$ git svn fetch
なお、途中でfetchが失敗しても再度同じコマンドをうつ事によって失敗したところから再開できます。私の場合はauthorsfileに不備がありましたがauthorsfile修正後に再開できました。
参考というか全て真似した
Vagrantboxを共有するときに色々起きた
はじめに
勉強熱心な友人が、本業でもないのに Web プログラミングを勉強しているので、開発環境整えた VM を渡せば色々教えやすいかなと思ったのが始まり。その時にいくつか問題が出たのでメモしておきます。環境は自分が Mac OS 10.8、友人が Windows 8 です。
問題
package 化できない
Vagrant 1.4.2 のバグです。アンインストールして現状の最新である 1.4.3 を使いましょう。
- 参考
package 化したものを手元で vagrant up できない
とりあえずテストにと手元で vagrant up しようとしたら出来ませんでしたが、エラーメッセージで検索したら助かる情報が。シンボリックリンクを作って Mac アドレスのマッピングを無効にするようです。
友人の環境で vagrant up できない
Vagrantfile に GUI モードで起動するよう記述してもらったところ、仮想化支援機構(VT-x/AMD-V)を有効化できません〜とダイアログが出たので、BIOS 設定を変更してもらいました。
さいごに
何かしら問題が起きるたびにログ出力ありの起動(VAGRANT_LOG=DEBUG vagrant up)しながら探っていく感じでしたが、みなさんの作業ログのおかげで助かりました。ありがとうございました。友人には中学時代にホームページの作り方を教わった恩が有るので少しでも報いようと思います。
Volley 読んだ
はじめに
出遅れた感が凄いけど Google がリリースした Android 用の通信ライブラリである Volley を読んだ。今のプロジェクトの通信部分はかなり軽量で、それはそれでいいんだけど、気を利かせて書くとこうなるっていう指標を知りたくて、その目標は達成できたと思う。
準備
git clone https://android.googlesource.com/platform/frameworks/volley
commit id は faa2a13dce6f8a1022e7cd9f04cdd75bfd280746 です。
ポイント
参考にした記事にある全体の図が凄いわかりやすいので、これである程度詳細まで掴める人も多いと思います。ここにはコード読んでる時に書いたメモを小綺麗にして残しておきます。
com.android.volley.Request
- public Request(int method, String url, Response.ErrorListener listener)
- 通信方式、URL、エラー時のコールバックオブジェクトを受け取る
- その他のもの(成功時のコールバッックオブジェクトとか)はサブクラスでコンストラクタ拡張して受け取る
- abstract protected Response
parseNetworkResponse(NetworkResponse response) - NetworkResponse から JsonObject なりの形にして Response に含めて返す
com.android.volley.RequestQueue
public RequestQueue(Cache cache, Network network, int threadPoolSize, ResponseDelivery delivery)
- このクラスが Volley のコア部分を稼働させるので、キャッシュ方式、通信方式、使用する側へのコールバック方式、あと並列で通信にいくスレッドの本数という、重要なところは全てコンストラクタで受け取る
- それぞれ奇麗にインターフェースが定義されているので、既に用意されている実装クラスを見るともの凄い少ない労力で置き換えができる
public void start()
public Request add(Request request)
- キャッシュを使う必要が無ければ mNetworkQueue、必要があれば mCacheQueue に追加する
private final PriorityBlockingQueue
mCacheQueue; - RequestQueue によって追加され、CacheDispatcher が処理していく Queue
private final BlockingQueue
mNetworkQueue; - RequestQueue or CacheDispatcher によって追加され、NetworkDispatcher が処理していく Queue
com.android.volley.CacheDispatcher
- public void run()
- 無限ループしつつ RequestQueue.mCacheQueue を処理していく。キャッシュが無い、あるいは更新が必要であった場合に通信を行わせるよう RequestQueue.mNetworkQueue に追加したりもする
- キャッシュがあった場合は RequestQueue から受け取った ResponseDelivery に渡す
com.android.volley.NetworkDispatcher
- public void run()
- 無限ループしつつ RequestQueue.mNetworkQueue を処理していく。Network インターフェースの実装クラスを叩いて通信を行うのはここ
- 通信を行って得たレスポンスは RequestQueue から受け取った ResponseDelivery に渡す
com.android.volley.ExecutorDelivery
- public ExecutorDelivery(final Handler handler)
- 受け取った Handler に post する Executor を作成して保持しておく
- public void postResponse(Request<?> request, Response<?> response, Runnable runnable)
- public void postError(Request<?> request, VolleyError error)
- 引数で ResponseDeliveryRunnable を作成して Executor に渡す
com.android.volley.ExecutorDelivery.ResponseDeliveryRunnable
- ResponseDeliveryRunnable(Request request, Response response, Runnable runnable)
- 最後にコールバックされる Request、コールバック関数の引数として渡す Response、更新予約の実行等、コールバック後に実行してほしい Runnable を受け取り保持しておく
- public void run()
- Request へのコールバックや終了処理呼び出し、あれば Runnable を実行しておく
おわりに
Cache とか Network だとかはインターフェース以上のことを説明できなさそうだったので省いてあります。もし読んでみようということになったらとりあえず Volley.newRequestQueue() を見てそこから辿っていくのがよいかなと思います。
複雑な layout.xml が辛い
大体が Activity とそれに表示する layout.xml を作って画面ができていくと思うけど、この layout .xml を Activity が中間層をおかずに触っている場合、もの凄い辛い事になる、というか正直もうなってる。
単体で使い回せるものであれば widget として作ろうと注意が働くけど、それが Activity に対応する layout .xml になると生で触り始めるのは私だけなのでしょうか。
UI 変更する処理に名前を付けてコードの下の方に押しやって頑張ってるけど、同じクラスにフラットに書く事自体が間違っている気がしている。 Android 書いてる人と意見交換したい。
iOS Developer Programを買った
はじめに
自分でアプリ出したいし、それとは別に実機でテストしたい身内ネタが出たのでプライベート用のiOS Developer Programを買った。もう散々既出ネタだと思うので、ざっくりとしたメモだけ残しておきます。
流れ
日本のApple StoreでiOS Developer Programを購入しActivateするまでの全スクリーンショット | MUSHIKAGO APPS MEMOを参考にしたら一度もつまることなくできた。ありがとうございました。流れを引用すると
1. Apple Developerアカウントを作成する。
2. iOS Developer ProgramをJapanのApple Online Storeで購入する。
3. Activation Codeがうまく通らず、サポートに連絡する。
4. サポートからの回答を受け取った後、Safariのキャッシュをクリア。
5. Activation Complete
日本語で名前と住所を登録していたアカウントでゴリ押したので、項番4の前にアカウント情報の変更処理が入った。そこも含めてメモ
1. Apple Developerアカウントを作成する。
元々もってたのでスキップ、でもこの時点で名前と住所をローマ字にしておけばこれから書くメールの流れが一つ消えると思うので時間短縮に繋がりそう。
2. iOS Developer ProgramをJapanのApple Online Storeで購入する。
注文手続きで無駄に配送先住所とか入力させられる。ここもローマ字にすれば後に変更しなくて済みそう...が自分は何も考えず日本語で書いた。クレジットカードで購入。
3. Activation Codeがうまく通らず、サポートに連絡する。
数時間後にメールで届いたActivation Codeをクリックしても上手く行かないので、一度サポートに連絡する必要がある。送ったメールは以下
ご担当者様
お世話になっております。
メールで頂いたActivation Codeをクリックしても、
下記のエラーメッセージが出てアクティベイト出来ませんでした。
―
We are unable to activate your Apple Developer Program membership because we are unable to successfully verify your identity. Please contact us and reference Enrollment ID# XXXXXXXXXX for further assistance.
―
プログラム購入時にメールにて頂いた注文番号は、
WXXXXXXXX
です。
上記の発注番号にてアクティベイトしていただけますでしょうか？
よろしくお願いいたします。
"（Wから始まる8桁の番号）"という文言を削除したのと個別のID、注文番号以外は全て丸写し。これは酷い。
★番外編★ Apple IDの登録情報をローマ字表記に変更
唯一のオリジナル要素（いらない）、上のメールを送ってから半日くらいで次のようなメールが送られてきた。
アカウントの認証をさせて頂く為に、以下のリンク先にて、Apple ID: XXX@gmail.com の氏名／住所情報を、全てローマ字表記へ変更して頂く様お願い申し上げます。
＊都道府県名は、日本語のままで構いません。
Developer Programに紐づいているApple IDの登録情報は、全てローマ字表記にして頂く必要がございます。
https://appleid.apple.com/jp/手順につきましては、下記をご参照ください。
http://support.apple.com/kb/HE40?viewlocale=ja_JPその際に、以下の点にご注意下さい。
所々日本語のままでいいというのが面白いが、UI的にローマ字入力できないので仕方ないのであろう。言われた通り修正して次のメールを送信
Follow-up: XXXXXXXXX
XX様
Apple IDの登録情報である
・名前
・住所（請求先）
・配送先住所
を全てローマ字表記へと変更しました。アカウントの認証をお願いします。
また、変更できていない箇所があればご連絡下さい。
送ってから一時間程度で手続きが終わったとメールが来ました。
4. サポートからの回答を受け取った後、Safariのキャッシュをクリア。
キャッシュ残ってると失敗し続けるらしいです。言う通りにします。
おわりに
これ放っといたら来年も自動で更新されるのだろうか。そこも調べないと
雑記
はじめに
なんとなくブログを書きたくなったので最近ボンヤリと考えていることを書く
勉強の仕方について
アウトプットの仕方についてずっと悩んでいて、少し前までは「お金のこととか一切考えず自分が使いたいアプリ作りながら勉強しよう！」とか考えていたんだけど、最近とてもその気持ちが萎えてきている。
パソコンを立ち上げても、この先やらなければいけないことがぽぽぽぽんと浮かんできてうーんとなってしまう。
それよりかは、仕事で使えるツール的なものを書いて、身近な人からレスポンスをもらった方が気持ちよくなれるのではないかと誘惑にかられてしまう。というか最近はその誘惑に素直に乗っている。
ただ、自分が好きなものを作って、自分で使うという、言い訳とかない世界でのアプリ保守はやりたいんだよなーとか、口だけになっているのが現状。考える度に胸が痛くなるレベル。
これは本当にしょうもないものでもいいからプロトタイプを作らないとトラウマになりそうなのでやることにしよう。
設計の責任逃れ
画面設計でもなんでも、自分が微妙だと思った件については、時間が許すのであれば納得するまで話し合った方がいいんじゃないの的なことをこの間言ったんだけど、奇麗ごといってるなーくらいで終わったぽい。
その時は自分がイラついていたこともあり追求しなかったんだけど、改めて考えみても奇麗ごとでも何でもない気がする。
画面設計の場合で話すと、アプリ固有のUXまで踏まえてキッチリ考えられる人なんてそんなにいないんだから、ワイヤー出した人も絶対の自信なんかおそらくなくて、そこに対して「あーこれはないわー。でも言われたからやるけどさ」なんて考えで実装したら、ほぼ確実に修正が入ると思う。そこでよく聞くのが「だから言ったのになー^^;」みたいな台詞、いやお前ぼやいただけで意見いってねーだろと。
そういう人に、代替案を聞いたり、せめて駄目な理由を聞こうとしてもふんわりとした意見を言うだけで、結局強い意志なんて無いことがおおい。
発言に責任を持たなきゃいけないラインに出ると途端に口ごもるってそりゃあどうなのという感じ。
なんか気がついたら愚痴書いてたけど、まとめると設計について気になるとこがあったら放置しないで話し合った方が、実装 -> 修正の往復も少なくなるし、なにより精神衛生上ずっといいんじゃないかと。もちろん、いろいろ理不尽な理由でイエスマンになるとかはあると思うけど。
