A-Liaison BLOG: ��の検索結果

検索キーワード「��」に一致する投稿を関連性の高い順に表示しています。日付順すべての投稿を表示

2010年12月29日水曜日

はじめての iPhone 開発時にお勧めの本 3 冊

2010/12/29追加: 本を追加したり中身を最新のものにしたりしました。

@monjudoh に社内チャットで

[10/09/17 17:18:12] 文殊堂: heyあきすて
[10/09/17 17:18:32] 文殊堂: iPhoneアプリ開発でいい本とかある?
[10/09/17 17:19:42] akisute: yoじゅどうもん
[10/09/17 17:19:43] akisute: たくさんあるぜ
[10/09/17 17:19:52] wozozo ☿: yo
[10/09/17 17:19:53] akisute: なんかみんなから同じ質問されるからブログに書くわ

とか言われたので、お勧め本をまとめてみることにしました。2年前にも似たようなものを書いたような気がしますけど、2年が経過していますから、いろいろと状況も変化していますしね。

詳解 Objective-C 2.0 改訂版
荻原剛志
ソフトバンククリエイティブ 2010-12-17

by G-Tools

2年前にも詳解しましたがこいつはバイブルです。改訂版になってBlockがらみの記述が増えたり、iOSについての言及が増えて、さらに良書になりました。四の五の言わずに買っておくと良いです。ただし、どちらかというとObjective-Cに焦点を置いている本であり、iOSで何ができるか、ということについてはほとんど記載がないので注意してください。

はじめてのiPhone3プログラミング
Dave Mark Jeff LaMarche 鮎川不二雄
ソフトバンククリエイティブ 2009-12-17

by G-Tools

こちらは iOS のバイブルです。初めて挑戦する人に最適ですが、ある程度熟練した人が見ても発見がある良書です。およそ必要なことはすべて得られると思います。

iPhoneプログラミングUIKit詳解リファレンス
所友太京セラコミュニケーションシステム株式会社
リックテレコム 2010-01-12

by G-Tools

UIKitに焦点を置いて書かれている本です。図解が多く、全くiOS開発をしたことがない人でもどのようなUI要素が使えるのか見て学べるため大変おすすめです。

2009年9月13日日曜日

iMacもSnow Leopardにしてみた

MacBook Airに引き続き、iMacのほうもようやくSnow Leopardに乗り換えてみました。

■ユーティリティとか動くの？

USB Overdrive: 動きました！一番気がかりだったので嬉しいです！
Shades: こちらも動作しました。Snow Leopardで多少マシになった輝度設定ですが、まだまだ明るすぎるので重宝しています。
ただし、画面右上のアイコンをクリックして表示されるスライダーが動きません。輝度設定を変更したいときは、システム環境設定のパネルからShadesを直接起動して変更する必要があります。まぁ、その程度なら全然OK！
MenuMeters: やっぱりダメでした。残念ですが忘れようと思います＞＜

■その他、iMacの気になるところ直った？

画面の輝度が明るすぎる: 多少マシになってます。一番最低まで下げれば、以前よりはまぶしくない（気がします、単にコントラストの設定が2.2になったせい？）。でもまだまぶしいです、引き続きバグチケットをAppleに投げてきます。
マウス: 相変わらず加速度がオフに出来ない糞仕様です。反応速度自体はマシになっていますが・・・しかも困ったことに初代Macintoshからこうらしいです、伝統だとか。改善されることはなさそうです＞＜ USB Overdrive様々。
ExposeとSpacesのマウス操作仕様: 困ったことにSpacesのマウス操作が微妙に変わっています。Spacesをボタンで起動した後、開きたいSpaceを「左クリック」しない限りSpaceが切り替わらない仕様になってしまいました。いままでは「Spacesの起動ボタン」でもSpaceが切り替わっていたのですが。Exposeは従来通りなので差異が発生してます。地味に困るのでこれもバグチケット投げないと。

2011年11月19日土曜日

UIWebView.scrollView に対して KVO を使うと色々面白い

iOS 5より、UIWebViewにscrollViewプロパティが追加され、たとえばスクロールを無効にしたりステータスバーをタップしても一番上に戻らないようにしたりなど、UIWebViewのスクロール周りの処理を外から自由に触れるようになりました。ですが便利なのはこれだけではありません。KVOの仕組みを使うことで、さらにUIWebViewを便利に使うことができます。ここでは私が使っている中で一番のおすすめをご紹介します。

■UIWebViewの描画しているHTMLのcontentSizeを非同期的に、リアルタイムで取得する
UIWebview.scrollViewのcontentSizeプロパティは、UIWebViewの描画しているHTMLの大きさ（contentSize）と同じ値になります。この性質を利用して、contentSizeプロパティにKVOを貼ると、UIWebViewの描画しているHTMLの大きさ（contentSize）が変わったタイミングで通知を受け取ることができます。こんなコードになります。

- (void)viewWillAppear:(BOOL)animated
{
  [self.webView.scrollView addObserver:self forKeyPath:@"contentSize" options:0 context:NULL];
  [self.webView loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://akisute.com"]]];
}
- (void)viewWillDisappear:(BOOL)animated
{
  [self.webView.scrollView removeObserver:self forKeyPath:@"contentSize"];
}
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context
{
  NSLog(@"%s", __func__);
  NSLog(@"  * contentSize = %@", NSStringFromCGRect(self.webView.scrollView.contentSize));
}

このテクを使うことで、例えばUIWebView自体をスクロールさせないようにした上で通知を受け取ってUIWebViewのframeをどんどん更新するようにし、UIScrollViewの中に埋め込んでしまってUIImageViewやUILabelのようにして使うみたいなUIを作ることが簡単にできます。HTMLの高さに依存するコードも作れますし、なかなか面白いですよ。iOS 5はもちろん、iOS 4でも動作します。（余談で解説）

■余談
UIWebViewのscrollViewプロパティは実はiOS 4のころからPrivate APIとして存在します。ですがiOS 5よりパブリック扱いになったおかげか、iOS 4向けのアプリでscrollViewプロパティを触っていてもリジェクトされたりクラッシュすることなく普通に使えるので非常に嬉しいです。iOS 3では使えませんのであしからず。

2010年8月29日日曜日

自分なりの iPhone アプリ開発手法とかこだわりとか書いてみた

Twitter で vの人こと @voluntas さんに無茶振りされたので、自分なりのポリシーとかこだわりとか開発手法とかをまとめてみることにしました。今仕事で iPhone アプリの開発を主にやっているので、 iPhone アプリに関する内容が多いですが、それ以外の開発でも使えると思います。

あまり技術的な内容やツールに関する内容はありません。それらは別エントリーにまとめようと思います。

■大前提: 自分を知る
まず何はなくともこっからです。なんだか開発とか全然関係ないじゃないか、怪しい自己啓発じゃねえかと思われるかもしれませんが、敵を知り己をを知れば百戦危うからずと昔のエライ人も言ってます。それにそもそも私がどのような人間なのかを理解しないと、せっかくの開発手法もそのまま真似してはうまく合わない・上手く回らない・賛成できないということになりますので、非常に大事だと思います。ということでさっそくまとめてみました。

恐ろしく几帳面である
A型人間です。
Java とか大好きです。逆にカオスなコードが苦手で、 PHP とかは敵です。
掃除してない @feiz や @shin_no_suke の机とか見てると勝手にゴミを捨てたり掃除したくなります。
Typo とか見つけたら人のコードでも勝手に直します。 Typo するのが嫌なので毎回変数名を決める前に英語辞書を引きます。
ゆとりである
一日の労働時間は八時間までよねー（キリッ
なのでとにかく楽をしたがりです。
そもそも体力が小学生並なので徹夜仕事とかできません。そのような事態に陥らないような仕事の進め方が必要になります。
やたらこだわる
好きなモノは徹底的に好きで嫌いなモノは徹底的に嫌いです。なので評価が極端で言動が偉そうです。すみません＞＜
一歩間違えるとただの頑固者になるので気をつけています。
言動は偉そうだけれども中身は非常に臆病者で弱い
なのでゆとりを失うと一気に迷走します。余裕を常に持てるようにする必要があります。
また周りの皆さんの支援ないと生きていけないと思っていますので、「生意気だけれどもイイ奴」ぐらいのポジションに落ち着きたいと思ってます。
iPhone は俺の嫁、 Cocoa Touch は神環境
もう二度と iPhone の無い世界には戻れません。
10年後ぐらいにはまた別の面白いものがあると思いますが、今のところは iPhone が一番面白いです。

似たような方は私と同じやり方を真似してもいいし、真逆な方は私のやり方と真反対をやればうまくいくのではないかと思います。

■三つの大戦略
私がどういう人間か分かったところで、次は今の仕事のやり方に関して最も根底にある三つの大戦略をまとめてみました。この大戦略にはほとんどツールや言語の話が登場しません。それらは時代が変われば変化してしまうからです。それよりもむしろ、どういう考え方やポリシーで仕事をすれば最も開発生産性が上がるか、というところに着目しています。

徹底的に几帳面にやる
楽をする・楽しむ・楽をさせる・楽しませる
二度とガラケーには戻らないと決心しその通りに行動する

徹底的に几帳面にやる
几帳面なのが武器なので、それを徹底的に生かす方針で開発を進めます。また几帳面さは Objective-C と非常に相性がよいです。たとえばメモリリークが発生してから調査すると非常に大変ですが、発生する前に防ぐことができれば生産性がそれだけ高まるはずです。また KVC/KVO や Core Data など動的言語のような処理を行う箇所では一文字のスペルミスが発見しづらいバグにつながるため、スペルミスチェックを行ったり、命名規則の策定をしたりする必要がありますが、このとき几帳面さが効果的に働きます。
また、余りつまらないところでミスを連発するとテンションも下がるしリズムも崩れ、余裕が無くなってしまい結果として悪いモノができあがってしまうので、それを防ぐためにも几帳面にやるのが効果的だと思ってます。
なにより、これが一番大事だと思うのですが、几帳面にコードを書くのが自分にとって一番楽しく、モチベーションが上がります。つまり逆に言えば、リズミカルにどんどん細かいところを気にしないでガーッとたくさん作るほうが楽しくリズムに乗れてモチベーションも上がる人でしたら、そのようにする方が良いと思います。

楽をする・楽しむ・楽をさせる・楽しませる
四楽運動です（何それ
要するに、

自分が楽したい、仕事量は減らして簡単にしたい
仕事は楽しんでやりたい、面白い技術を使ってやりたい
でも自分ばっかり楽したら申し訳ないし楽した分だけしっかりやって楽をさせてあげよう
それにせっかく作るなら楽しいモノを作った方がいいに決まってるからそうしよ

ということです。
この方針に従うと、私の場合、楽ができて楽しいだけではなく、「このようなすばらしい環境で開発させて貰ってありがとう」という感謝の気持ちと「それなりの成果を出さなくてはならない」という責任感が自然と発生するため、非常に開発効率が高まるようです。

二度とガラケーには戻らないと決心しその通りに行動する
うちの会社でもガラケー向けのWebアプリの開発をやっていて、その際の苦労話を聞く機会があります。また、企画やお仕事の提案などでGREEやモバゲーなどのガラケーアプリを見せて貰うことがあります。そのような経験から思うのは、

ガラケーはIE6とか比較にならないほど苦労するくせにどうしようもないユーザー体験しか提案できない最悪の開発環境

だということです。たとえばメールの文字コードの扱いとか、特定の機種だけ動かないとかで50台以上の実機でテストしないと駄目とか、Flash lite 1.1はまともに使えないからサーバー側でバイナリ操作してSWFを生成して送り返しているとか、そんなネタを聞くたびにこう、ふつふつとしたものが沸いてきます。
その上お金になるからかバッドノウハウだからか知りませんが、驚くほど情報が出回っていない。調べてもなかなか分からない。とにかく開発者に優しくありません。なによりバッドノウハウを運用しても楽しくない上にイライラして嫌なムードになってしまいます。
確かにガラケーの環境はお客さんからお金を取りやすく儲かりやすいため、会社で取り組むには非常に好都合であるとは思うのですが、やはり私は開発者の身である以上、素直に開発者に優しく、さらには素晴らしいユーザー体験を提供できる環境を選びたいのです。さらに思うだけでは駄目で、実際に iPhone の開発で仕事を取って継続的にお金を稼げるようにしなくてはならないので、そうなれるよう実際に行動する必要があります。

■「徹底的に几帳面にやる」を達成するための戦略

面倒くさがらずにリファクタリングする
リファクタリングは大事です。納得いくまでリファクタリングします。一文字Typoしたら名前変更、名前が後から気に入らなくなったら変更、クラスの構造を変更、メソッドをパブリックに変更、エトセトラエトセトラ。リファクタリングは他の人がコードを読んだ時の理解を助けてくれるだけではなく、自分自身がリファクタリングのためにコードを理解することになり、今後の設計に役立ちます。自分の考えを整理するという意味でも大事だと思います。
細かくスタートして、ちょっと作って確認し、またちょっと作って確認して繰り返す
特に iPhone での開発は小規模で変更や追加が多く、アップデートも頻繁。必然的にアジャイルな開発が要求されます。そしてなにより、テストケースを書いてテストドリブンで開発するだけの時間的余裕がありません。そんな贅沢なやり方ができるのは長期でずーっとやっていくWebサービスや大規模なシステムだけで、作ってすぐ放棄される事が多い iPhone の開発にはテストドリブンは全く向いていないと思っています。
しかしながら、品質は当然担保しなければなりません。そこで私は小さく作ってすぐに作った箇所を確認し、また少し作って確認・・・という手法をとっています。正しく作る単位をモジュール化することができれば、一端テストしてその部分の品質が保証されればその後の開発ではテスト済みのモジュール内の事は考えなくて済むからです。テスト自体が大変でコストがかかるので、やはりコーディングの段階で几帳面にバグを出さないようにするというのが一番に思えます。
一番面倒で難しそうなところからスタートする
ほとんどの技術者の方はこのような手法を取られていると思うのでわざわざ書くほどのものでもないのですが、それでも一番面倒で難しそうなところからスタートする手法は非常に有効です。上記の手法とも合わせ、一番難しそうなところ一番最初に小さくスタートしてすぐにテストし、品質を保証してしまうのが最も有効です。全体の２割のコードに全体の５割ぐらいの時間をかけて作り、残りの半分はコピペしてプロパティをちょっと書き換えるだけでざざーっと作れるようなところにしてしまう、というのが理想だと思ってます。

■「楽をする・楽しむ・楽をさせる・楽しませる」を達成するための戦略

取捨選択をする
ソフトウェア開発で楽をするための一番よい方法は、作らないことです。取捨選択を適切に行ない、不要な枝を切り捨て、必要な枝・競争力のある枝にすべてのエネルギーを集約することで、個性的なアプリを作り出すことが出来ます。個性的でないアプリは供給過多の市場に埋没します。さらに取捨選択は作業をすすめる最中でも大いに役立ちます。たまにお客さんから「あれもなる早、これもなる早、全部最優先で」とかいうお前日本語間違ってるだろといわんばかりの指示が飛んできたりしますが、これは全く話になりません。「最たるもの」とは常にひとつしか存在しないもので、だからこそまずそれから仕事にとりかかることができ、余計な仕事の順序選択思考を避けることができるのです。私自身が優先順位をつけたり指示を出したりする際にも、最優先がひとつ、次に優先がふたつ、それ以下はすべて後回しか切り落としです。そもそも、三つよりたくさんを記憶して同時に処理できる人はまれです。
偉い人の作ったフレームワークとかライブラリをどんどん使わせていただく
ソフトウェア開発で楽をするための二番目に良い方法は、すでに完成しているものを取り込むことです。ということで、フレームワークやライブラリなどは積極的に活用します。ライセンスには気をつけないと大変なことになりますので注意ですが、これらのフレームワークやライブラリは私よりも遥かにすごい人達が時間と手間をかけて作り上げられ、テストもしっかり行った上で公開されているものが多いので、私自身が実装するよりも遥かに信頼できると思っています。もちろん人が作ったものなのでバグや合わない仕様はたくさんありますが、ソースコードを読んで修正すればよいのです。ゼロから自分が作るよりは断然良いです。
とにかく自動化する
とかく人間というのは、単純作業をミスすることにかけては超一流です。頻度の差こそあれ誰しも必ず単純作業をミスします。さらに単純作業は集中力という貴重なリソースを消費します。
二回以上繰り返す単調作業は自動化する。それがたとえ、ソースコードをzipで圧縮してメールでお客さんに送るといった簡単な作業であったとしても、自動化しておくのは非常に役に立ちます。単純作業を避けることで生まれた余剰集中力を、別のところに振り分けることができます。
自動化する手法がわからなかったら調べて勉強します。ここでちょっとわからなくて面倒だからと避けると後から地獄を見ますし、成長できないので、意地でも調べます。
自分に要求されている責任範囲以上の仕事を引き受けて楽をさせてあげる
私は最初の会社の新人教育の際に、「自分が要求されている以上の仕事をしろ」と繰り返し教えられました。実際最初の会社はどちらかというとブラックに属する部類だと思いますし、こういう教えは社畜だの何だのと言われているようですが、私はこの「自分が要求されている以上の仕事をしろ」という考えが好きです。
確かに前の会社で仕事をしている間はこの考えは嫌いでした。なぜなら仕事がつまらない上に余計なことをすると怒られる職場だったからです。バグだらけの共通ライブラリを修正したら余計なことをするなと怒られ、酷い出来栄えのJavaScriptを救済するためにjQueryを突っ込んでみたらこれまた余計なことをするなと言われ。まったくどうしろと・・・。
しかし今は違います。仕事の内容は全部任せていただいていますし、効率化も推奨されています。画像リソースがお客さんからやってこなければ自分で作り、画面の仕様が決まらなければ私が決めて作ってお渡しし、セールスのためにアプリレビューを行ってくれるブログ一覧をまとめてお渡しするなど、とにかく仕事が円滑に進むと思えばなんでもやります。面倒なときもありますが、それより相手の仕事が遅くってイライラして「あいつが悪い、あいつのせいでプロジェクトが失敗した」とか考える方が嫌です。それにちょっと勝手にやりすぎたかと思っても、意外なほど喜んでもらえます。
ただし、何でもかんでもこの方法で一人で引き受けていると私の仕事量が破綻するので、この方法で引き受けるのは一過性の仕事だけにしています。定期的にやらなくてはいけない仕事は自動化するか、やり方を教えてあげてやってもらいます。
細部にこだわれるだけのスケジュール上の余裕を常に持つ
リファクタリングしたり、自分に要求されている範囲以上の仕事をすると、どうしても当初見積りより遥かにたくさんの時間がかかることになります。それにプロジェクトには絶対にトラブルが付きものです。ということで、時間的なゆとりが必要です。私は見積りを提出する際に、自分で余裕を持ってできる見積りに、さらに1.5をかけて提出したりします。提出するときにはこれ時間がかかりすぎじゃないかと言われないかヒヤヒヤしますが、バグを取ったりクオリティを上げたり、突然湧いたトラブルに対処しているうちに、最終的にはそれで大体丁度良くなるので不思議です。お客さんにとっても納期遅延が発生しないため、今のところ大変ご満足頂いております。
特に iPhone アプリはこの余裕を持ってアプリのクオリティを上げる方針が有効に働きやすい気がします。修正が比較的簡単ですぐに行えるWebアプリに比べ、リリースを急いだとしても、ひとたびバグが原因でリジェクトされるとリリースが一週間遅れ、醜いアプリをリリースするとレビューで酷評されと、ろくなことがありません。

■「二度とガラケーには戻らないと決心しその通りに行動する」を達成するための戦略

ガラケーの仕事は意地でも断る
「ガラケーは嫌いだけれど、仕事だからしょうがないし・・・」冗談じゃありません。幸いにして iPhone 開発で人材募集をしている会社さんも増えましたし、フリーで出来るお仕事の量も増えています。口だけでなくて行動でやらなければなりませんので、まずガラケーの仕事をお断りです。
せっかく無理言って iPhone のお仕事をやらせてもらっているので、とにかく全力でやる
とまぁこんな具合で無理わがままを通しまして何とか iPhone のお仕事を頂きましたので、その分きっちりお仕事して成果を出して次があるようにしなければなりません。こうして後ろを断つとやっぱりやる気が出ます。また、損益にも気が向くようになります。なにせ赤字垂れ流しではあっという間にガラケーに逆戻りです。利益を出さなくては話になりません。
自分に要求されている責任範囲以上の仕事をやる
一番信用できて一番自分の思い通りに動くのは自分です。まず自分がやることで成功が近づくと考えています。と同時に一番信用できないのも自分なので、人におまかせしたり既存のライブラリなどを活用したりというのも必要になります。なんかすごい矛盾してますが、とにかく自分が一番信用できるけど一番信用できないのです。
次の仕事を持ってきてもらえるように売上とかまで気にする
「開発は物つくるまでが仕事、売るのは営業の仕事・・・」ガラケーでやってください。 iPhone 開発者の人は少人数かフリーの人が多いため、みなさん作ったものを売るところまで考えてらっしゃるようです。ただし、あくまで開発者の立場として売上を気にすることです。本職の営業や企画の方がいらっしゃるときに、私が営業や企画の真似事を始めると破綻します。
以上のようなわがままを聞いてくれる環境に身を置く
「んなもんお前に言われなくてもわかってるわ！そんな理想的な環境あるわけねえ！」すみません、ごもっともです＞＜
結局良い環境で仕事するのが一番で、良い環境は良い人脈と人付き合いがあれば勝手にやってくるみたいなので、まずは勉強会とかに参加しまして良い人付き合いをするのが一番の近道かなぁと思います。
成果はきっちりアピールする
成果はアピールしないと次につながりませんので、きちんとアピールします。幸いにして私は口から先に生まれてきた人間なので、大声で騒ぐのは得意です！しかしアピールというのはやり方を間違えると単なるスパムや嫌がらせに成り下がってしまいます。TPOをわきまえて正しく成果を大声でアピールしましょう。
たとえば @iphone_dev_jp に「新作アプリをリリースしました！」なんて大声で流してもイラッとされるばかりですが、リリースして培った経験や技術情報、お役立ち情報を流せば「あいつはできる」と思ってもらえるわけです。

■チームで作業する際の戦略
ここまでは主に自分自身に関する内容の戦略でした。が、実際の仕事はもちろん自分ひとりだけではなく複数の関係者やチームのみなさんと進めることになります。ということで最後にチームで作業する際に私の考える戦略をまとめてみました。

大前提: 人数は少なければ少ないほど良い能力は高ければ高いほど良い距離は近ければ近いほど良い
これが大前提です。とにかくコストを最小限に保ちつつ、時間あたりの開発能力を最大にする必要があります。大規模開発等では当てはまらないかもしれませんが、仕事の総量が比較的少なめで予算が少なく納期が極めて短い iPhone 開発では、開発・デザイナーあわせて殆どの場合３人以内で足ります。その分各個人の責任範囲が非常に広くなるため、すべてのチームメンバーにそれらの責任を全うできるだけのスキルが必要です。誰しも限界があるので最終的には人に聞いたり頼ったりすることになると思うのですが、どこまで個々人が自分自身で調べて解決できるかというところが大事だと思います。何かあったらすぐ頼るような状態では生産性が落ちます。
「距離は近ければ近いほど良い」というのは物理的にも精神的にもです。物理的に近いほうがやりやすいというのは、極端な例で言えばお客さんが隣のフロアにいるとかです。何か困ったことが発生したときに、メールのやり取りや電話口でのやりとりで解決するより、走って行ってその場で手取り足取り説明したほうが断然早いしうまくいきます。精神的に近いほうがやりやすいというのは、仲がいい方がチームのムードも良くなるし対立が発生しづらいからです。個人的には、良いチームにはデルタフォースとかSASのような特殊部隊のイメージがあります。あのへんの特殊部隊の人が語るチームマネジメント本とか講演会とかあればいいなぁとか思います。
少数・精鋭・見知った仲でチームを結成する
- 少数になるようにする - 必要最小限の人以外を入れない
- 精鋭になるようにする - 可能であればそうするのがよいが、できる範囲でやるのであれば、同じ程度の実力の人を集めてチームにする
- 見知った仲になるようにする - まず知り合う、勉強会とかに行く、一緒に遊ぶ、共通の趣味嗜好を持つ、距離の近いお客さんを選ぶ
人を増やすのは比較的簡単ですが、減らすのは恐ろしく難しいです。人が増えると責任が薄まります。「俺がいなくてもどうにかなる」と気づいてしまうとヤル気が極端に下がりますし楽しくありません。もちろん、人が足りなくて毎日徹夜しないと追いつかないような状態になっているのはダメで、バランスが重要ですが、基本ほんの少しだけ足りない側に倒すほうが良いかと思ってます。
チーム全体が精鋭になるようにするというのは、できるのであればそれが最も素晴らしいことだと思いますが、まぁ現実的に考えて難しいと思います。そんな手段があれば私がまず知りたいです＞＜で、現実的な作戦としては、チーム全体の実力をできる限り均一化すると言うことが挙げられます。チームメンバーの実力にほとんど差がない状態が、一番チームメンバー個々の能力を最大限に発揮させ、責任感を最大限に発揮させることができると思うからです。一人だけ精鋭がいてもその人に負荷と責任が集中し、他の人はアイツがいるからと思ってしまいます。逆に一人だけおちこぼれるとみんながその一人のせいにして責任を放棄します。
見知った仲になるようにするために、例えば社内で月一ピザでも食べながら勉強会をやるとか、誰かの家に飲みに行くとか、お昼ごはんを一緒に食べるとか。ここが一番難しい気がしますが、一番大事なところだと思います。仲がよければちょっとやそっとのミスや負荷があっても許してあげられるようになります。逆に険悪になるとほんの少しのミスや負荷が許せなくなり、さらに事態が悪化します。
ただし、仲が良いのと馴れ合うのは絶対に違うと思います。馴れ合い始めると新しい人が入ってこれなくなり、仕事に張りがなくなります。これもバランスですね。
開発チームとステークスホルダーが直接コミュニケーションできるようにする
いくつかプロジェクトをやって気づいたことがこれで、開発チームとステークスホルダー（最終決定権保持者、各種画像リソースなどのリソース提供者）の距離が遠いとプロジェクトが失敗しやすくなります。距離が遠いというのは、間に仲介役 - たとえば営業の人だとか - が入るということです。人ほど信用ならない情報伝送経路はありません。必ず情報の劣化・嘘の混入・膨大な遅延が発生します。このような伝送経路を使うのをやめて、直接ステークスホルダーの人とSkypeでやり取りできるようになると、効率が格段によくなります。ミスも発生しません。
それでもどうしても何ともならないとき
- 人数が増えてしまった - チーム/責任範囲を分割して可能な限り少数にする、または別の仕事を取ってきてそちらにチームを分割する
- スキルが低い人と一緒に仕事をする必要がある - 低い人の理解に全員が合わせる。
- 顔も名前も知らない人がチームに入ってきた、どうしてもウマが合わない人がいる - そこでどう仲良くなるかというのが本当にカッコイイ大人のやることではないか（キリッ
- 物理的に距離が遠い - ツールを最大限に活用する。ツールを導入できるように先方をうまく説得する。
- ステークスホルダーと直接話しにくい - 無理矢理にでも直接話すのを試みる
すみません、かなり無茶苦茶です＞＜というのも私自身ここに書かれているような事態にうまく対処できないからです。実際これらの問題をうまく乗り切られる人は、人間力があるといいますか、磨かれた大人であるといいますか、優れたマネージャーさんであると思います。現実問題、こういった問題は数限りなく存在しますので、具体的な対処策は私自身学び取りたいところです。ですが、絶対に勘違いしてはならないのが、これらはあくまで「対処療法」であって、「根本的な治療」ではないということです。最初から対処療法が必要でないような環境を作るために尽力し、そのような環境で仕事をしていれば、これらの問題はそもそも発生せず、そのため余力を生むことができます。発生した余力はさらに理想的な環境を整備するために使ったり、自分自身のスキル向上のために使えます。
これを体の健康にたとえるならば、毎日暴飲暴食せず野菜を取り適度な運動を行ない十分な睡眠をとることで病気にならない様にするのが一番であって、自堕落な生活を送った結果重い病気にかかったので医者に行って治してもらうというのを繰り返すようでは体がどんどんぼろぼろになっていきます。体の健康に例えると、前者を行う人が尊敬され後者は笑いものにされるのですが、チーム運営となると前者は魔法か理想論と馬鹿にされ後者の出来る人が大人だと尊敬されているようで、どうも私はしっくりきません。何事も予防する、予防できる環境を作るのが一番です。発生してから耐えるのは美徳ではなくやむを得ないことです。
課題: どうしても合わない人をどう追放するか
これは世界全国、人とチームがある限りの永遠の課題だと思います。本当はこんなことをしないでよいのであれば理想なのですが、それでもどうしても人が余ったりチームに合わないからという理由で人を外さなければならないことがあります。アメリカ人みたいに非情にズバズバ首を斬ると、後から衝突が発生したりチームの財産を平気で奪って逃げたりされます。かといって日本人みたいに何時までも何時までも衝突を恐れて首を切れないと、チーム全体の死活に関わります。まったく、どうするのがいいんでしょう・・・＞＜

■まとめ

３行でまとめると、楽しく生産性の高い仕事をするには、

責任感を持つ/持たせるのが大事
ゆとり大事
バランス大事

こんなところですかね。

2009年7月19日日曜日

iPhone OS 3.0のTableViewでscrollEnabledをNOにするとtableView:didSelectRowAtIndexPath:が機能しない

http://forums.macrumors.com/showthread.php?t=470266

OS2.2のころはscrollEnabledをNOにしても正常にdidSelectRowAtIndexPathが動いていたので、これは正直結構困ります。仕方がないのでscrollEnabledを使うのを回避して、スクロールするように戻しました。OS 3.1では直っているとよいのですが。

2010年10月5日火曜日

Android のメモリ管理は大変です

■理想

AndroidってJavaだからメモリ管理なんてしなくてもいいよね！！

なんて思っていた時代が私にもありました・・・

■現実

    @Override
    protected void onDestroy() {
        super.onDestroy();
        // 画面が回転した時など、Activityが破棄されるときに呼び出されます
        // すべてのメモリはここで開放します
        // - 特に危険なのが内部クラス（MyWebChromeClientなど）、正しく開放しないとActivityが開放されません
        // - セットしたbackgroundのcallbackもnullにしないと開放が行われません
        // - webViewのdestroy()を忘れると後からGCが走ったときにVMがクラッシュします
        this.webView.stopLoading();
        this.webView.setWebChromeClient(null);
        this.webView.setWebViewClient(null);
        this.unregisterForContextMenu(this.webView);
        this.webView.destroy();
        this.webView = null;

        Drawable backgroundDrawable = this.backgroundViewGroup.getBackground();
        backgroundDrawable.setCallback(null);
        this.backgroundViewGroup.setBackgroundDrawable(null);
        this.backgroundViewGroup = null;
        this.mainViewGroup = null;
        this.anotherViewGroup = null;
    }

これだけやらないと平気でクラッシュします。マジです。しかもGCが走るまでクラッシュしないとかそういう厄介すぎる現象に２回ほど遭遇しました。

WeakReferenceとか使えばいいんでしょうけど面倒なんですよねぇ。

■Google曰く

http://d.hatena.ne.jp/nakamura001/20101002/1286015483

iPhoneより普通に厳しい気がするのは気のせいでしょうか

■結論

AndroidはJavaではないのできちんとメモリ管理をしましょう！

2013年5月2日木曜日

Parse.com の Cloud Code ハマりどころ

Parse.comのCloud Codeを触っていてハマった点や気づきにくい仕様を列挙させて頂きます。

■Parse.Cloud.useMasterKeyを呼び出すことで特権ユーザー権限になれる

Cloud Code上でACLによるアクセス制限を無視して現在のrequest.userとは関係なしにデータを操作したいということが多々あるかと思います。そのような場合は以下のようにリクエスト処理の先頭でParse.Cloud.useMasterKeyメソッドを呼び出してください。

useMasterKeyの効果は呼び出された瞬間からリクエストが終了するまで有効です。

■Parse.Cloud.beforeSaveやParse.Cloud.afterSaveはData Browserから直接Rowを追加した場合にも呼び出される

これは意外とハマりどころです。例えばData BrowserからUserを追加した時などにUserに対してつけておいたParse.Cloud.beforeSaveが発動するなどしてよく発生します。Data Browserから直接Rowを追加した場合、request.userはnullになりますので注意してください。また追加元がData Browserなのか普通のクライアントなのかを判定する手段が用意されていないため、処理を分岐させたくなるととたんに話が面倒なことになります。

2008年10月12日日曜日

テスト投稿

Bloggerの機能を試してみる
ソースコードはどれぐらい入れられるのか
クロスブラウザ対応は？

普通のテキスト　太字　斜体　文字色

左揃え

中央

右揃え

両端揃え・・・はうまくいかないな

番号リスト
リスト
リスト

引用
これがうまくいくとすごく助かる
if __name__ == '__main__':
sys.path = EXTRA_PATHS + sys.path
script_name = os.path.basename(__file__)
script_name = SCRIPT_EXCEPTIONS.get(script_name, script_name)
script_path = os.path.join(SCRIPT_DIR, script_name)
execfile(script_path, globals())

画像を追加してみたい

ちょっと大きいかな
引用はうまくいかないのでpreタグを試してみる

if __name__ == '__main__':
    sys.path = EXTRA_PATHS + sys.path
    script_name = os.path.basename(__file__)
    script_name = SCRIPT_EXCEPTIONS.get(script_name, script_name)
    script_path = os.path.join(SCRIPT_DIR, script_name)
    execfile(script_path, globals())

2009年1月26日月曜日

ThinkingRockを使ってGTDを初めてみました

最近はタスクが多すぎる！！
Remember The Milkだけではもう限界！サブプロジェクトすら作れないし・・・リストにはいつもタスクがあふれている！
そこでGTDを本格的にやってみる
でもOmniFocusは高くて躊躇
と思ってたら救世主登場、その名はThinkingRock
Javaなのでマルチプラットフォームなのもいい感じ

ThinkingRockというJava製のGTDアプリケーションを最近使い始めました。
同時並行で5つぐらいのプロジェクトを抱えており、さすがにRemember The Milkだけでは仕事を背負いきれなくなってきたのが始めたきっかけです。

このアプリの特徴を一言で表現するなら、

超本格的、でも簡単

これです。

実は私、GTDについてはウェブで聞きかじった程度の知識しかありません。
しかしこのThinkingRock、
「思考を集めるための画面」
「集めた思考を仕分けするための画面」
「仕分けした思考をプロジェクトやアクションとして管理するための画面」
が明示的に分離されており、
何を入力すればよいかもはっきりと決まっているので、後はヘルプを見ながらそれに従って項目を入力したりタスクを仕分けしていけば厳格にGTDに乗っ取ったタスク管理が自動的にできてしまうといった作りになっています。

このように、GTD全体の構成を表したOverviewが用意されております。

ヘルプにもGTD関連の情報が満載で、
わからないことがあれば頼りになります。
（たいていこういうツールのヘルプって頼りにならないので、驚きでした）

ヘルプ画面はこんな感じです。英語ばっかりで難しいですが・・・読めないことはないです！

サブプロジェクトとかも作成でき、コンテキストも作れて高性能でいい感じです。
気に入ったので職場のWindowsマシンにも導入しました。

2009年9月3日木曜日

Python 2.5系列ではrepr()でunicodeを返すといろいろトラブルが起きる

Django（正確にはapp engine patch）のmanage.py shellで遊んでいるとき、とあるクラスを生成すると必ずUnicodeEncodeErrorが発生していることに気づきました。具体的には以下のような感じ。

>>> from game.models import *
>>> hts = HeroTemplate.all()
>>> ht = hts.fetch(1)[0]
>>> ht.template_name #問題なし
>>> ht.name          #問題なし
>>> hero = Hero(
... name=ht.name,
... symbol=ht.symbol,
... max_life=ht.max_life,
... life=ht.max_life,
... max_move=ht.max_move,
... move=ht.max_move,
... weapon=None,
... item=None,
... )
>>> hero             #ここでUnicodeEncodeError
>>> ht.createHero()  #上記と同じ処理をやるメソッド、これもUnicodeEncodeError

原因を調べていてわかったのですが、Python 2.5系列では__repr__()がunicodeを返すようにしてしまうとトラブルの元になってしまうようです。
参考にしたサイト：
http://d.hatena.ne.jp/alisue/20090402/1238690818

たとえば、

>>> class Abesi:
...   def __repr__(self):
...     return u'¥u3059¥u305a¥u304d¥u3044¥u3061¥u308d¥u30fc'
... 
>>> abesi = Abesi()
>>> abesi #UnicodeEncodeError

これを実行するとabesiを表示しようとしたタイミングでエラーになります。環境はWindowsXP上のCygwin 1.7 + Python 2.5.4で、ターミナル上ではshift_jisを使っています。始めっからターミナルがutf-8を扱えるような環境なら__repr__()でunicodeを返しても上手くいくかもしれません。
しかしながらどこの環境でも動くとはいいがたい状態なので、

__str__()と__repr__()はstrを返す
__unicode__()はunicodeを返す

Python 2.5系列ではこのルールを守っておいたほうが無難のようです。Python 3.0からはunicodeがデフォルトになるらしいのでこんな面倒ごとをいちいち考えなくてもよいのでしょうか？いまだにPython 3.0試していませんが、ちょっと興味が湧いてきました。

■っていうかそもそも
Djangoのdjango.db.models.Modelクラスは特にオーバーライドしなくても綺麗な__repr__()を出力してくれるので、デフォルトの__repr__()を使えばよかった＞＜

2012年11月12日月曜日

Unity 3.5 以下でプリプロセッサ定義を上手く使う方法

C/C++/Objective-Cベースのプロダクトのビルドシステムを構築するときに大変便利なのがプリプロセッサのdefineマクロです。defineマクロを使って環境を切り替えたり不要なログコードを削除したりなどは皆さんよくやってるかと思います。C#にも同様のプリプロセッサ定義が用意されているみたいですので、こちらを使ってUnityプロジェクトのビルドシステムを構築できないかと思ってやってみました。

■プリプロセッサ定義の使い方 (Unity 4以降)

Unity 4.0よりプリプロセッサ定義がUnity本体によってサポートされるようになりました！ビルドスクリプトからも自由にアクセスが可能になっており、非常に簡単に扱うことが可能です。
詳しくはけいごさんのブログに完璧にまとめられていますのでそちらをご覧ください。
http://anchan828.tumblr.com/post/32669868103/define

■プリプロセッサ定義の使い方 (Unity 3.5以降)

ここからが本題になります。Unity 3.5以前はプリプロセッサ定義を公式にサポートしていません。そこで以下の４種類のファイルをAssetsフォルダ直下に置くことでプリプロセッサ定義を読み込ませます。

/Assets/smcs.rsp (C#用)
/Assets/gmcs.rsp (C#エディタスクリプト用)
/Assets/us.rsp   (UnityScript、俗にJSと呼ばれている物用)
/Assets/boo.rsp  (Boo用)

このrspファイルにはC#コンパイラのコンパイラオプションとして渡すオプションが記述できます。ですので http://linux.die.net/man/1/mcs などに列挙されているコンパイラオプションであればひと通りなんでも使用可能です。今回はプリプロセッサ定義をやりたいので、以下のように書けばOKです。

-define:DEBUG

複数の定義が書きたい場合は、

-define:DEBUG -define:USE_DEV_SERVER

のようにスペースで空けて複数記載するか、

-define:DEBUG
-define:USE_DEV_SERVER

のように改行して複数記載するか、

-define:DEBUG;USE_DEV_SERVER

のようにセミコロンで列挙して書くことができます。注意点として、C/C++/Objective-Cのdefineマクロと違って

-define:DEBUG=1

のように値を定義することはできないみたいです。あくまでシンボルを作るだけみたいですね。

以下Twitterでのやりとりです。

@akisutesama -define:HOGE -define:FUGA みたいに書けば複数定義出来ますよ。行を分けてもOK。ただしレスポンスファイル(rsp)を修正したらスクリプトは再コンパイルされる必要があるのでスクリプトをすべて再インポートしてください
— Hiroki Omae (@pigeon6) November 9, 2012

@akisutesama 念のために書いておくと.rspファイルはヘンな黒魔法ではなく応答ファイル(response file)といって、要するにコンパイラに渡すコマンドラインオプションをファイルに書いておけるという方式です。なので中身はただのC#コンパイラオプションでございます
— Hiroki Omae (@pigeon6) November 9, 2012

はい、mcsのmanページでよいと思います。オプションに関する情報ではないですがこちらも未読なら読んでおくと良いと思います mono-project.com/CSharp_CompilerRT @akisutesama: @pigeon6 ですよね、コンパイラオプションですよね？ってことは…
— Hiroki Omae (@pigeon6) November 9, 2012

@akisutesama 応答ファイルの利用はUnity的には公式機能ではないので、あまりやりすぎないようにした方がよいです。Unityはビルド時にコードの最適化を行ったり、特にiOSではAOTをやったりと結構事後処理を頑張っているので、そこでおかしくなる可能性はあります。
— Hiroki Omae (@pigeon6) November 9, 2012

さて、これでプリプロセッサ定義はバッチリできるようになったのですが、問題はこれをビルドごとに書き換える方法です。最初はビルドスクリプトでこのrspファイルを書き換えていたのですが、どうもこれをUnityが全く認識しないのです。普通にファイルをただ書き換えてもダメなようです。

そこで黒魔術を導入します。以下のスクリプトで使われているコードを利用して、無理やり書き換えた後のrspファイルをUnityに認識させます。
https://github.com/prime31/P31UnityAddOns/blob/master/Editor/GlobalDefinesWizard.cs#L131

AssetDatabase.Refresh();
reimportSomethingToForceRecompile();

private void reimportSomethingToForceRecompile()
{
 var dataPathDir = new DirectoryInfo( Application.dataPath );
 var dataPathUri = new System.Uri( Application.dataPath );
 foreach( var file in dataPathDir.GetFiles( "GlobalDefinesWizard.cs", SearchOption.AllDirectories ) )
 {
  var relativeUri = dataPathUri.MakeRelativeUri( new System.Uri( file.FullName ) );
  var relativePath = System.Uri.UnescapeDataString( relativeUri.ToString() );
  AssetDatabase.ImportAsset( relativePath, ImportAssetOptions.ForceUpdate );
 }
}

これでC#で書かれたコードに対しては無事にrspファイルへの変更が反映されるようになります。

しかしながら更に落とし穴があります。UnityScript(JavaScript)で書かれたファイルに対してはこの黒魔術が効きません。したがってUnityScriptで書かれたファイルに対して動的にus.rspファイルの定義を適用することができないようです。すべてのJSファイルに対して上記の黒魔術を適用しても効果がなかったため、おそらくダメだと思われます。

■結論

UnityScriptは使わないようにしましょう。

2009年11月23日月曜日

Mac OS Xには最初から/usr/share以下にmaven2やantが付いてくる

先日のScala Hackathon #1にて初めて気づいた驚愕の事実。なんとMac OS Xには最初からJavaの開発ツールが付いてきていたのでした。

akisute ~$ mvn --version
Maven version: 2.0.9
Java version: 1.6.0_15
OS name: "mac os x" version: "10.6.2" arch: "x86_64" Family: "mac"
akisute ~$ ant -version
Apache Ant version 1.7.0 compiled on July 20 2009
akisute ~$ which mvn
/usr/bin/mvn
akisute ~$ which ant
/usr/bin/ant

ちょっとmaven2のバージョンが古いですが、普通に使う分にはたぶん問題なさそうです。ちなみにこれらのツールは/usr/share以下に用意されています。

akisute ~$ cd /usr/share
akisute share$ ls
NotificationServer/       distcc_compilers          info/                     sandbox/
Ssh.bin                   doc/                      java/                     screen/
TargetConfigs/            emacs/                    junit/                    sdef/
aclocal/                  enscript/                 langid/                   servermgrd/
aclocal-1.10/             examples/                 libiodbc/                 skel/
ant/                      file/                     libtool/                  snmp/
apr-1/                    ftpd/                     locale/                   statsCollector/
autoconf/                 gdb/                      man/                      swig/
automake-1.10/            germantok/                maven@                    tabset/
bakefile/                 gprof.callg               mecab/                    tcsh/
bison/                    gprof.flat                misc/                     terminfo/
caldavd/                  groff/                    mk/                       texi2html/
calendar/                 gtk-doc/                  openmpi/                  texinfo/
cracklib/                 gutenprint/               openmpi-default-hostfile  uucp/
cups/                     heapdiff/                 openmpi-mca-params.conf   vim/
cvs/                      hiutil/                   openmpi-totalview.tcl     xcode-select/
derby/                    httpd/                    podcastproducer/          zoneinfo/
dict/                     icu/                      ri@                       zsh/

おお、他にもderbyとかありますね。TomcatやJettyのようなサーブレットコンテナがないので、そのまますぐにWebアプリ開発とはいきませんが、なかなか面白そうです。

・・・む、ひょっとしてこれ常識ですか？＞＜

2009年4月12日日曜日

Mac OS XのBlogライター、Petrus Bloggerを試してみる

Blogger付属のWYSIWYGエディターを使っていると、Preタグの中身の空白が消えたり化けたりすることがあることが分かったため、やむなくBlogger付属のエディターを使うことが出来なくなってしまいました。

そこで、外部のBlogエディターを導入してみることにします。

■タイトルのテスト
タイトルはfontタグになるみたいです

目についた機能を列挙してみると、

Bloggerの機能と連携していて、アプリケーションのメニューからBloggerのDashboardを一発で開いたり出来る。過去記事の編集も可能
HTMLタグの入力補助や入力補完は一切無い
画像のアップロード補助も一切無い
BloggerのLabelに関しては完全にサポートしている、入力補完はないが入力補助がある

@interface PreTagTest
    NSString *test1;
    id delegate;
@end

@property (retain)NSString *test1;
@property (assign)id delegate;

画像アップロードテスト

↑Edit > Upload Photoを実行するとこのリンクが自動的に張られるのですが、見ての通り表示できません。

Blog > Albumsを押すとアルバム全体が開くので（全体です、二度目以降はキャッシュしているみたいですが、1回目はむちゃくちゃ待たされます）、それから写真を選んでPicasaのページを開き、さらにそこから自分でリンクを拾ってきてようやく表示できます。
使い物にならん・・・orz

ううん、なかなか便利なんですが、編集機能がちょっと弱すぎる感じがしますね。せめてタグの挿入ぐらいはしてくれないとなぁ。画像もドラッグ＆ドロップでサクッと入れたいです。

2012年5月5日土曜日

Mono の System.String と string の違いについて調べてみた

MonoとかC#とか初心者なのでSystem.Stringとstringの違いがよくわからず、気になったので調べてみました。

以下のページのベストアンサーが一番わかり易かったです。
http://okwave.jp/qa/q7225655.html

ちょっと転載します。

string と System.String は型として使われる限り単なる別名なので同じものです。
foo.System.String みたいなものが用意されて foo 名前空間内から使うような場合は異なりますが，特殊例過ぎるのでこれは考えないものとします。
コンパイラは，ソース上の型として string と書かれているものは，System.String とかかれているものとして処理します。
# 正確には "System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" という型 (.NET 4 の場合)

これは，SDK 付属の逆アセンブラでコードを見ると，string を使っても System.String を使っても同じコードになることから確認できます。

同じように，int は System.Int32 の別名ですし，bool は System.Boolean の別名です。

使い分けは，特別決まりはありません。
唯一，メソッド名等に使う場合には言語固有の名称を避ける (CLR の名前を使う)，というのはあります。
MSDN: 一般的な名前付け規則
http://msdn.microsoft.com/ja-jp/library/ms229045.aspx
具体的には，
・ToInt
よりも，
・ToInt32
の方が好ましい，ということです。
# 上側の名前付け規則だと，Visual Basic においては ToInteger であるべき，となる。

私は，static メソッドの呼び出しに使う場合は CLR の名前を使い，それ以外では言語固有の名称を使っています。
書籍によっては，常に CLR の名前を使うべき，という物もあったりします。
# が， for (Int32 i = 0; ……みたいなコードはほとんど見ません。

自分なりの物でいいので，統一したルールを用意しておくのがよいでしょう。
# 常に言語固有の名称でもよいと思います。

そもそも.NET Framework (とMono) は実装言語に依存しないような作りになっている (CLRというやつ?) のでこのような仕組みになっているようです。なるほど。 int, bool, string はC#の型で、 System.Int32, System.Boolean, System.String はCLRの型なわけですな。勉強になりました。

2014年9月30日火曜日

GitHub:Enterprise 環境下では CocoaPods を 0.34.0 以上にアップデートしてはいけません

タイトルの地点で結構出落ちですが、本日少々厄介な問題にぶち当たってしまったので共有いたします。

発生条件

CocoaPods 0.34.0以上を使用し、GitHub:EnterpriseのgitリポジトリをPodSpecないしSourceリポジトリとして使用している場合に発生します。

発生する問題

CocoaPodsのgitを利用するアクションが全く成功しなくなります。具体的にはpod install, pod updateなどが全く通りません。

問題の原因

公式ブログにあるとおり、0.34.0以上からCocoaPodsは高速にgitリポジトリをcloneするため--depth 1 (shallow clone) オプションを採用するようになっています。しかしながらGitHub:Enterprise側の技術的問題なのか、GitHub:Enterprise内のgitリポジトリに対するhttpないしhttps経由でのshallow cloneが成功しないため永遠にpod installやpod updateが終わりません。

対処方法

CocoaPodsを当面の間0.33.1のまま運用する。0.33.1を指定してインストールするときにはこちらのQiita記事が参考になります。
http/httpsではなくssh clone URLを使用する。sshだと問題が起きないとの報告があります。GitHubに問い合わせてみたところやはりhttp/httpsのみで問題が発生するようです。
ssh cloneがネットワーク上の問題などで使用できない場合、最後の回避策として:tagや:branchを使用しないで:commitを直指定するように社内のPodspecを書き直す。

根本的にはCocoaPodsかGitHub:Enterpriseかいずれかが修正されるのを待つしかありませんが、CocoaPods側としてはあまり積極的に対応する気がないようなので、GitHub:Enterprise側に対応を期待するしかないでしょうか。もちろん全てのGitHub:Enterprise環境下で発生するとは限りませんが、いずれにせよ注意する必要があります。

2014/10/01追記

GitHub:Enterpriseに問い合わせてみたところ、こちらは既知の問題であり現在修正中で、次のリリース時に修正されるそうです。次のリリースが社内環境にデプロイされるまでの辛抱ですね。

こちらからは以上です。

2009年3月19日木曜日

Your mobile device has encountered an unexpected error (0xE800003A)

いつになってもこのエラーの対処法が覚えられなくてGoogle先生にお尋ねすることになっているので、ここに備忘録を記しておきます。

１．info.plistのBundle identifierとProvisioning ProfileのApp Identifierを一致させる

これはネットのどこを見ても書いてある情報なので大丈夫だと思いますが一応。
面倒ならば、裏技的手法として、Provisioning ProfileのApp Identifierを*だけにするという手段があります。こんな風に。

ABCDEFGHIJK123.*

この方法だとオープンソースのプロジェクトを拾ってきたときでもすぐに実機インストールすることができるので、いちばんお勧めかもしれません。

２．クリーニングする（Shift+Command+K）

で、１．は毎回試すのですが、それでもうまくいかないので次はこれ。クリーニングを行います。
もしくはプロジェクトフォルダ以下のbuildディレクトリの中身をすべて消してしまっても同様の効果が得られます。

今のところこの二つを試したら毎回うまくビルド出来ているので、とりあえずはこれで大丈夫かと思います。

2009年8月23日日曜日

vimのProjectプラグインまとめ

今回のPython Hackathonで大活躍してくれたProjectプラグインについて適当にまとめ。

■プラグインのダウンロードはこちらから
http://www.vim.org/scripts/script.php?script_id=69

■まずはこれを読む
http://d.hatena.ne.jp/hidde/20080930/1222776171
http://d.hatena.ne.jp/hirono_hideki/20090816/1250365295
http://blog.kaihatsubu.com/archives/001438.html

■覚えておかなくてはならないコマンド
\c　対話的に新しいディレクトリをプロジェクトに追加する。
\C　\cと同じだが、指定したディレクトリ以下のすべてのディレクトリを再帰的にプロジェクトに追加する。
\r　現在カーソルがあるディレクトリの中身を再度読み込みなおす。プロジェクトの設定を変更したときやファイルを追加したときなどに実行する。
\R　\rと同じだが、指定したディレクトリ以下のすべてのディレクトリを再帰的に読み込みなおす。
\w　現在開いているファイルを閉じる
\W　すべての開いているファイルを閉じる
Space　プロジェクトウィンドウを最大化する。もう一度押すといつものサイズに戻る。
以上、これだけ！

■使うときのコツ
\Cや\Rなどを使って新しいファイルをプロジェクトに取り込んだら、プロジェクト自体を:wして保存するのを忘れないようにする。

2010年2月20日土曜日

hg clone で巨大なリポジトリを取得するときは --debug オプションが便利

参考にしたページはこちら。
http://mercurial.selenic.com/wiki/Clone

mercurial hgを使っていると、特にバイナリでサイズの大きいファイルを頻繁に変更するようなリポジトリ（たとえばFlashとかflaとかflaとか）はすぐにサイズが肥大化して、cloneに時間がかかるようになってしまいます。このような巨大リポジトリのcloneの進捗状況を表示できないかと思い調べてみました。

結論から言いますと、今のところそのようなコマンドは用意されていないようです。そこで代わりに--debugオプションをつけて実行するとよいと公式ページに説明がありました。

> hg clone --debug http://www.selenic.com/repo/hello my-hello
using http://www.selenic.com/repo/hello
sending between command
sending heads command
requesting all changes
sending capabilities command
capabilities: unbundle=HG10GZ,HG10BZ,HG10UN branchmap lookup changegroupsubset
sending changegroupsubset command
adding changesets
add changeset 0a04b987be5a
add changeset 82e55d328c8c
adding manifests
adding file changes
adding Makefile revisions
adding hello.c revisions
added 2 changesets with 2 changes to 2 files
updating the branch cache
updating to branch default
resolving manifests
 overwrite False partial False
 ancestor 000000000000 local 000000000000+ remote 82e55d328c8c
 Makefile: remote created -> g
 hello.c: remote created -> g
getting Makefile
getting hello.c
2 files updated, 0 files merged, 0 files removed, 0 files unresolved

全体の進捗がわからないのでいまいちですが、何も表示されないよりは格段に良くなりました！

2009年5月7日木曜日

Windows起動時にhal.dllが見つかりませんと言われた場合の対処法

久しぶりにBootCampでWindows XPを起動しようとしたら、hal.dllが見つかりませんといった具合のエラーメッセージが表示されてうんともすんとも言わなくなってしまいました。dllが破損したのかと思い調べてみたところ、このエラーメッセージはC:¥boot.iniファイルの設定が破損された場合に表示されるメッセージだと言うことが分かりました（さすがマイクロソフト、エラーメッセージの意味不明さには定評があります）。なるほど、確かにboot.iniファイルが消えてました。

修復するにはWindows XPをCDから起動して、回復コンソールを立ち上げます。画面の表示に従えば大丈夫だと思います。
回復コンソールが起動したら、以下のコマンドを入力。

bootcfg /list

これで起動設定（boot.iniファイルの中身）の一覧が表示されます。私の場合は、boot.ini自体が存在しないので、設定がありませんと怒られてしまいました。
設定が破損しているのを確認したら、以下のコマンドで修復を行います。

bootcfg /rebuild

途中、3回ぐらい選択肢が表示されますが、以下のように回答します。

インストールをブート一覧に追加しますか？: YES
ブートIDを入力してください: 適当でかまいません。MacでBootCampしている私の場合はWindowsと入力しました。普通のWindowsマシンの場合にはWindows XP Professionalとか入れておくとわかりやすいのではないでしょうか。
オプションを指定してください: /fastdetect

これで完了です。あっさり終了するのでちょっと拍子抜け。あとはコンピューターを再起動すれば問題なくWindows XPが起動すると思います。

2012年3月4日日曜日

Unity 3.5でバージョン管理をする

およそコンピュータを使った仕事に該当するものでしたら何でも、複数の人物が同時に作業するための何らかの仕組みが必要になるのは、コンピュータを使った仕事に関わっている人でしたら皆ご存知かと思います。特に開発業務といえばgitやhgといったバージョン管理システムの出番になります。そういうわけで今回は Unity プロジェクトでのバージョン管理について一ヶ月間ほどやってみた結果をご紹介したいと思います。

■Unity 3.4以前の場合

そんな暗黒時代のことは忘れましょう。

■Unity 3.5以降の場合

Unity 3.5から新しい仕組みが導入され、 Unity Asset Server というビルトインの ~~ボッタクリ~~ バージョン管理システムを使う以外に、好きなバージョン管理システムを使ってUnityのプロジェクトをバージョン管理することができるようになりました。これを使わない手はありません。まずは公式のガイドを見てみましょう。
http://unity3d.com/support/documentation/Manual/ExternalVersionControlSystemSupport.html

これによると、以下の手順を踏むのが良いようです。

メニューの Edit -> Project Settings -> Editor から、 Version Control の Mode という項目を探し、 Metafiles を選択する。これで外部のバージョン管理システムが導入できるようになります。このチェックを入れると、
- Libraryディレクトリが重要なメタデータを管理するディレクトリではなくただのキャッシュディレクトリになり、バージョン管理をしなくてよくなる。
- 新たにAssetsディレクトリ以下のすべてのファイルとディレクトリについて.metaファイルが生成される。
- 新たにProjectSettingsディレクトリが生成される。
メニューの Edit -> Project Settings -> Editor から、 Asset Serialization の Mode という項目を探し、 Force Text を選択する。この手順はどちらかと言うとおまけです。これを実行すると、ほとんどのAssetファイルがバイナリではなくテキスト形式で保存されるようになり、diffやmergeが行えるだけではなく差分だけをコミットするようになるためバージョン管理システムが扱うデータ量が減ります。
プロジェクト配下のAssetsディレクトリとProjectSettingsディレクトリをバージョン管理システム配下に追加する。それ以外のファイルは追加しなくて良い。

たったのこれだけです。なかなか簡単そうですね！ということで早速やってみました。

・・・ところがぎっちょん、実際にやってみると出るわ出るわ問題の山。

■.metaファイルがどこからともなく勝手に生成される

これが最大の問題です。外部バージョン管理をするためにUnityが.metaという名前のメタファイルをテキスト形式で生成するのですが、コイツがトラブルを起こしまくります。

ファイル削除時に.metaを消すのを忘れて、同じ名前のファイルをあとから作成しようとして.metaがぶつかりトラブルになる
ファイルも.metaもバージョン管理下から確かに消したはずなのに、なぜか.metaファイルだけが勝手に復活している
ブランチを移動すると急に.metaファイルが湧いてきて、ブランチのマージ時に衝突する

主要な原因はUnityが空のディレクトリから.metaファイルを生成しているためです。以下のようなケースで、中身が空のディレクトリというのは容易に生成されてしまいます。

gitの場合: gitはディレクトリをバージョン管理対象に含めないため厄介なことになります。通常はgit pull時にmerge/rebaseが実行され、その際に空になったディレクトリは削除されるのですが、merge/rebaseの最中に衝突が発生したりすると問題が大きくなります。merge中に裏でUnityが動いていると空ディレクトリの.metaがその場で生成されて、考えるだけでも恐ろしいことになったりします。
通常はこれで問題ないのですが、merge/rebase時に衝突が発生していて、裏でUnityが動いていたりすると酷いことになるみたいです。
hgの場合: hgはgitと同様にディレクトリがバージョン管理対象外なのですが、hg update時に空になったディレクトリをきちんと削除してくれます。これはupdateがworking directoryの中身を指定されたリビジョンの状態にするから、という認識です。gitと違いpullやupdate時にmerge/rebaseを実行しないためトラブルになりづらいのか？などと考えてますが実際に苦労したわけではないのでよくわかりません。おそらくgitよりはトラブルになりづらいとは思います。
1および3にupdateすると、きちんとFolderやOtherFolderが削除されてくれます。いい感じ。
svnの場合: ディレクトリもバージョン管理の対象にするので問題ありません。以下の図を参照。
r2のような削除の仕方をするとFolderが残ってしまうためFolder.metaが生成されてしまうのですが、普通はディレクトリを消したときはr4のような削除の仕方になるので問題がないはずです。

また中身が事実上空なディレクトリ（すでに使われていない.metaしか入っていないディレクトリなど）が亡霊みたいにさまよっていて延々と自身の.metaを書き出し続けたり、善意で予め作っておいた空ディレクトリが.metaを吐き出していることを知らずコミットされては削除されを繰り返していたり、二人が同時にディレクトリを削除しようとして片方のコミットが衝突して結果が壊れてしまったりなど、枚挙に暇がありません。

元ファイルを移動したり削除した際に.metaを消さなくてはいけないというだけでも極めて面倒で、相当なトラブルになりました。そもそもがUnityを使っているプロジェクトのメンバーが全員バージョン管理システムに慣れていないため、とりあえずバージョン管理システムのGUIツールがいうがままに変更を全部コミットするだけという具合の運用に。.metaだけが延々と残って衝突が繰り返されるという悲惨な状況が発生してしまうこととなりました。これはUnityのせいではなくメンバーがバージョン管理の考え方を正しく理解していないのが問題なのでツールは何を使っても発生しうるのですが、.metaがなければここまで問題は拡大しなかったと思います。

いっそignoreしてしまいたいぐらいなのですが、この.metaにファイルごとのメタ情報が全て詰まっているため、当然ignoreするとプロジェクトがブッ壊れます。これはひどい＞＜

本家のドキュメントで例にされているのがgitでもなくhgでもなくsvnであるあたりを見ると、なんだかsvnで動作させることしか考えてなさそうな印象です・・・

■.unityファイルがマージできない

.unityファイル自体はテキスト形式にできるのですが、中で使われているAssetのIDがちょっと触れただけでものすごい勢いで変化したり、他人の環境では別の値になったりするため、殆どの場合マージできません。iOSプロジェクトのxcodeprojファイルみたいな感じです。こればかりはマージを諦めるしかありません。

■まとめ

最初はgitを使って管理をしていたのですが、上記に挙げたような問題が多発しまくって回らなくなってしまいました。別のバージョン管理システムを使うことも検討したのですが、そもそもメンバーのバージョン管理に対する知識が足りていない上に.metaが存在する以上hgやsvnに変えても問題が根本的に解決しそうにないと判断し、結局社長に頼んでAsset Serverを購入して試してみることになりました。がっかしです＞＜ですがAsset Serverならば.metaを使わないでバージョン管理できるので問題を根本的に解決できそうです。

逆に言えば.metaに気をつければそれ以外の箇所ではgitでもあまり問題になりませんでした。バイナリを大量に扱うため重いのではないかと懸念されていましたが、github経由ででも問題なくpush/pull出来る程度の重さにしかならなかったです。ということで.metaとうまく付き合えるチームメンバーが揃っているのであれば、Asset Serverなしでも十分やっていけるのではないかと思いました。

個人的にUnityでバージョン管理をする際におすすめする外部バージョン管理システムはsvn、可能であればPerforceです。git/hgのようにブランチを主体とするバージョン管理システムはブランチを切り替えた瞬間に.metaに殺されるケースが多々あるため、ブランチの使用そのものが非推奨となり、力が発揮できません。mergeについてもバイナリファイルやmergeできないテキスト形式のファイルが多くて結局意味がない気がします。どうしても分散VCSを使いたい！というならhgをお勧めします。ブランチ切り替えは常にupdate -Cすることで対応できるかなと。bazaarはわからないのでノーコメント。gitはpull時の衝突の最中に裏でUnityが動いていて大爆発するケースがあったのでやめておいたほうが良いです。hgなら少なくともpull/update時に爆発することはないはずですからね。

次はAsset Serverを試してみて、使用感を書いてみようかと思います。果たしてお値段に見合った効果は得られるのか！？乞うご期待です！

登録: 投稿 (Atom)