2014-01-17

Objective-C の NSMutableArray の簡単な作り方

Objective-C ではサイズを変更できない配列 (NSArray) と、サイズを変更できる配列 (NSMutableArray) がある。Objective-C の参考書を読むと、Array の作り方として次のようなコードが書いてある。

NSArray* array = [[NSArray alloc] init];
NSMutableArray* mutableArray = [[NSMutableArray alloc] init];

これは本当に初歩的な書き方。Objective-C 2.0 (今の iOS 開発なら、Objective-C 2.0 がデフォールトになってる) なら、もっと簡単な Array の作り方がある。

NSArray* array = @[];

Array は大きさを変えられないので、実際のコードでは次の様にデータを入れて初期化する。

NSArray* array = @[@"foo" @"bar" @"hoge"];

Array はこんなにシンプルな書き方があるのに、MutableArray にはないものか... と諦めていたら、簡単な方法を見つけた。mutableCopy を使う。

NSMutableArray* mutableArray = [@[] mutableCopy];

Array を作って mutableCopy で mutable 化する。なんとシンプルな!!

蛇足ながら初期値を持つ場合のコードは...

NSMutableArray* mutableArray = [@[@"foo" @"bar" @"hoge"] mutableCopy];

NSMutableArray はサイズ 0 のものを作って、アイテムを push していくからあまり使わないけどね。でも、シンプルな NSMutableArray の作り方は覚えておいて損はない。

2014-01-16

Ruby の正規表現マッチには名前が付けられる

こんなことをやろうと思った。

文字列に「集合場所 ○○」と記入されていたら、○○の部分を抜き出すコード。

最初に思いついたのが、こんなコード。

if /^集合場所 (.+)/ =~ string
  p Regexp.last_match(1)
end

これは何とも読みづらい。最近の Ruby はマッチする () に名前を付けられると聞いた。さっそく試してみる。

if /^集合場所 (?<meeting_place>.+)/ =~ string
  p meeting_place
end

これは見やすくなった!!

蛇足: リファクタリング

コードは一応完成したけれど、一応入力ミス対策も入れておく。集合場所を半角スペースではなく全角スペースやタブで書く人もいるかもしれない。

if /^集合場所[   ](?<meeting_place>.+)/ =~ string
  p meeting_place
end

半角スペース・全角スペース・タブが入ってるけど、見た目で分からない。その上、誰かがソースコードを tabify したらタブが消えてしまう。ここは空白を表す [[:blank:]] を使う。せっかくなので複数スペース対策も入れておこう。

if /^集合場所[[:blank:]]+(?<meeting_place>.+)/ =~ string
  p meeting_place
end

やあ、人によっては「空白区切り」と言っているのに「:」を使うかもしれない。最後にその対策も入れておく。

if /^集合場所[[:blank:]::]+(?<meeting_place>.+)/ =~ string
  p meeting_place
end

半角と全角のコロンも入れた。これで完成。ちょっと見栄えが悪いけど、マッチした文字列との対応が分かり易いのが良いね。

chef の Directory リソース

chef の Directory レシピは次のように書く。

directory /path/to/dir do
  action :create
end

ところが、これは mkdir /path/to/dir とするようなもので、/path/to/ までディレクトリーがある場合は良いけれど /path/ までしかディレクトリーがない場合は to ディレクトリーがないと言ってエラーになる。

mkdir -p /path/to/dir のように、深いディレクトリーもちゃんと作成したい。

そういう場合は、recursive true オプションを加える。

directory /path/to/dir do
  recursive true
  action :create
end

ハマッたので、メモ。

2014-01-09

remote で削除されたブランチをローカルにも反映する

Qiita にやり方が書いてあったんだけど、自分のブログにも書いとかないとすぐ忘れちゃうんでメモ。元ネタはこちら。

この記事が書いてる通り、リモートのリポジトリーでブランチを誰かが削除しても、ローカルにはブランチが残ってる。これは気持ち悪い。そこで、誰かがリモートでブランチを消したら、ローカル環境にも反映させたい。

remote が origin だとした場合、次のコマンドでローカルのブランチも消せる。

$ git remote prune origin

ちなみに、リモートのブランチを消す方法は次の通り:

$ git push origin :branch

消したいブランチ名の前に : (コロン) を置くのがコツ。

せっかくなので少し解説すると、git で branch を push する場合、次のようにする。

$ git push origin local-branch-name:remote-branch-name

つまり、ローカル・ブランチとリモート・ブランチの名前は変えられる。けど、普通、ブランチ名を変える必要はないので、こうなる。

$ git push origin branch-name:branch-name

branch-name を二回書くのは煩わしいので、上のコマンドは下のコマンドと同じという扱いになっている。

$ git push origin branch-name

さて、話は戻ってリモート・ブランチを消す方法。空のブランチをリモート・ブランチに push すればいい。「空のブランチ」は空白で良いので、結果、コロンをブランチ名の前に置いたらリモート・ブランチが削除できたようなコマンドが出来上がる。

$ git push origin :branch

以上。

Emacs の M-! にはコマンド補完が利く!!

Emacs ではワンライナー (一行だけのコマンド) を走らせるのに M-! が使える。コマンド名は shell-command。

M-! を打つとミニ・バッファーに Shell command: と表示されるので、任意のコマンドを入力する。「make」でも良いし、「gcc foo.c」でも良いし、「echo hello」でも良い。RET キーを押すとコマンドが実行され、結果が出力される。

この M-!。コマンド補完が利いたらどれほど便利か。そう思っていた時期が、ぼくにもありました。では、M-! にはコマンド補完が利くと? はい。M-! にはコマンド補完が利きます。

いつの間に... 知らなかったよ。

コマンド補完が利くと便利なのは、カレント・ディレクトリーに置いた自作スクリプトを走らせる時かな。

ぼくは、このブログの記事をエディターで書いて Blogger にコピペしている。書いた記事ファイルは git server にアップしている。一々、アップするのも面倒なので、こんなスクリプトを書いている。ファイル名は git-blog.sh。

#!/bin/sh
date=`date +%Y-%m-%d`
git add -u
git commit -m "blog entry $date"
git push origin master

変更を git add して、commit して、push する shell script。ブログの記事を書き終える度にターミナルからスクリプトを実行するのが面倒だった。でも、今は Emacs からコマンドを実行するのもたやすい。

M-! ./g<TAB>

これだけで git-blog.sh という長いコマンド名を打つことなくスクリプトを実行できる。Emacs 万歳!!

2013-12-18

OS X 10.9.1 リリース — Dvorak ユーザーよ! 戻ってこい

昨夜、MacBook Air の OS を 10.9.1 にアップグレードした。

日本語入力問題が解決していたので、ここに報告する。

どんな問題?

キーボードの種類を「日本語」と「他のキーボード」で入れ替えた時に、「日本語キーボード」のキーボード配列が「前のキーボード」の設定に引きずられる。

これは日本語キーボードと US キーボードを使っている人には困らない現象。US キーボード以外を使っている人達には泣きそうな仕様変更だった。

US キーボード以外というと何があるのか? フランス語を使う人は、フランス語のアクセント記号を簡単に入力できる様にフランス語用キーボードがある。これは US キーボードと少しキー配置が違う (主に記号部分)。同様にイタリア語、スペイン語、ロシア語などなど同様の問題を抱えていた。

この対処法は一つだけ。US キーボードを入れて、日本語キーボードに移る前に一度 US キーボードを選択する、というもの。キーボード入力など息をするように行なっていた者には苦行以外の何ものでもなかった。

更に、一般の US キーボードとは違う配列を使う人間は泣きそうになった。

例えばぼくは Dvorak 配列を使っている。一般の US キーボードは Qwerty 配列というのを使っているけど、Dvorak 配列は全くキーの配置が違う。例えば、左手のホーム・ポジションには左から「aoeui」という風に母音が並んでいる。

英文を打つ時は Dvorak 配列を使うぼくも、日本語ローマ字入力する時は Qwerty 配列を使う。そもそも、キーボード配列とインプッド・メソッドは別レイヤーの存在。これを一緒にしてしまったので、一部の (そして少なくはない) 人達が困り果てた。

問題解決

OS X 10.9.1 では、このキーボード問題が解決された。喜ばしい。これで Mac で入力するのが辛い日々からお別れできる。OS X 10.9.1 の改善点は色々あるけれど、この問題に悩まされていた人達にとっては、この修正こそ最大の改善と言えると思う。

ref.

2013-12-15

社員として自宅勤務をやってみた体験談

ぼくが今、勤めているアクトインディ株式会社ではエンジニアとデザイナーに自宅勤務が許されている。自宅勤務は、リモート勤務・在宅勤務とも世間では言うのかな。最近では米 Yahoo! が在宅勤務を禁止にして話題になった。

ぼく自身の視点から、在宅勤務制度を利用してのメリット・デメリットを書く。

基本的なルール

自宅勤務を行なうに当たって、社内ルールがある。

  1. 自宅で勤務を行なうに十分な環境を整えていること
  2. 上長に許可を得ていること
  3. 他の人との作業に支障が出ないこと

自宅勤務制度は、ぼくが入社した時に既にあった。「自宅勤務で 2、3 倍のパフォーマンスを出す」というエンジニアが始めたのがきっかけと聞いている。彼は十分な成果を出すことで、自宅勤務する権利を得た。後から入ったエンジニアやデザイナーは、彼の成果を継承する形で「自宅勤務」が使えている。

自宅勤務は大低、入社 2 か月くらいの経って、その人の仕事振りを見て許可が下りる。人によって自宅勤務を選ばない人もいる。「自宅勤務に自分は向かない」「自宅勤務より会社の方が集中できる」等々、自分でジャッジしている。

仕事振りが良くても自宅勤務が出来ない場合もある。それは、自宅に勤務する環境が整っていない場合。開発用のアプリが入っていない、環境構築が出来ていない、セキュリティ・ソフトが入っていない等々。セキュリティ・ソフトなどは会社側が用意できるけど、自宅マシンがデスクトップの場合は環境構築の段階でつまずくケースもある。

周りから認められ、開発環境も整ったら、大低週頭に誰がどの日に自宅勤務するかを話し合う。基本、週二回の自宅勤務が認められている。仕事の進捗と周りとの関係から自宅勤務する日は多くなったり少なくなったりする。自宅勤務でパフォーマンスの上がる人は、突発的に忙しい時に一週間丸々自宅勤務に当てるケースもある。社内でのコミュニケーションが多く必要な場合は、自宅勤務する日を一日に減らしたり、0 にする場合もある。そこら辺は、各自の作業内容と状況に応じて変えている。

ぼく自身の自宅勤務

ぼく自身は、自宅勤務したからといって 2 倍のパフォーマンスを上げたりは出来ない。そんなスーパー・エンジニアじゃない。でも、自宅勤務するメリットは享受している。

第一に通勤時間の消滅。ぼくは今、朝、一番乗り換えが良い時間帯に出社しているけれども、それでも自宅・会社間で 90 分かかっている。帰宅時は、各駅停車や乗り換えの便の関係で 2 時間近くかかる。この通勤時間がなくなるのは大きい。普段よりもフレッシュに仕事を開始できる。開発効率は当然上がる。帰宅に体力を使わないので、翌日の出社が普段より少し楽になるのも嬉しい余録。

第二にリラックスした空間。会社には会社なりの緊張感がある。それはそれで良い。けれど、リラックスした空間で作業することで生まれるモノもある。それは思考の余裕だったり、集中力だったり、様々。ぼくのケースを言えば、ぼくは音楽が好き (see life@aka, 安宅の音楽日記)。BGM をかけながら作業をするのが好き。とてもリラックスできる (ちなみにヘッドフォンが苦手なので会社では音楽をかけていない)。このブログも音楽をかけながら書いている。リラックスした空間と、集中が高まることで音楽が耳に入って来なくなる瞬間、どちらも好き。

第三に邪魔されないエンジニア・タイム。最低限、Skype などで連絡は取り合っているけど、それ以外の接触がない。ロジックを考えたり、新しい事を挑戦するのに試行錯誤する時、誰にも邪魔されず集中できる時間が確保できるのは嬉しい。

iOS 開発での一例を挙げてみる。デザイナーに他の仕事が入っていて来週までこちらの開発に関われなくなった。その週、ぼくはデザイナー不在でも行なえるコーディングと、デザイナーの人が作業に入った時に必要と思われる下調べを行なった。そして自宅勤務に当てた二日間には Core Data 周りのコーディングを行なった (Core Data は iOS を始める人にとって最初の関門だと思う)。翌週、ぼくはデザイナーと一緒に仕事をした。下調べのおかげでデザイナーの要求に応えたり、逆にエンジニア側の要求をデザイナーに伝えることが、比較的スムーズに行なえた。その週はデザイナーとのコミュニケーションを多くする方が作業効率が上がったので自宅勤務は申請しなかった。

ぼくにとって、自宅勤務は倍とはいかないまでもパフォーマンス・アップに繋がる良い効果をもたらしている。ただ、振り返ってみると、ぼくは自宅勤務の日に、重いタスクの片付けや下準備を多くやっていたように思う。そうすることで、自宅勤務が明けた後、「普段の会社の業務」がよりスムーズになるように調整していた。逆を言えば、会社の中で途中の割り込みが入ると困る作業を入れていた。

変則的なリモート勤務

リモート勤務を自宅以外で行なったこともあった。

ゴールデン・ウィークや夏期休暇中のこと。連休と連休の間に平日が入ることがある。ここに全て休みを入れれば幸せなのかもしれないけれど、そこまで休みも取れない、仕事に軽くタッチしないといけない... なんて状況もあった。こういう時に、リモート勤務を使わせてもらった。

具体的には、ぼくは長期休暇に実家の新潟や生まれ故郷の香川へ帰省する。当然、長く休めれば休めるほど家族と過ごせる時間が増える。悲しいことに、大きめの休みが平日で泣き別れになっていた。そこで、休みが始まったら帰省。一日、休みをもらって、残る平日をリモート勤務。開発環境 (ノート PC) とネット環境 (モバイル WiMAX) があればどこでも作業はできる。そして後半の大きな休みに入って、余裕を持って帰省先から戻る。

大きなタスクがなかったのも幸いだったけど、大きな休暇を取りつつ、長期休暇特有の浦島状態にならないメリットは大きかった。

自宅勤務をしないという選択肢、自宅勤務のデメリット

今、ぼくは自宅勤務をしていない。これから数か月は自宅勤務をしないつもり。

というのも、仕事内容が少し変わった。

会社でコミュニケーションを取る方が、自宅勤務よりも捗る。だから、自宅勤務をしていない。

自宅勤務はエンジニアにとって「有効な手段」ではあっても、「最良の手段」とはならない。ケース・バイ・ケースで有効活用する時を選ぶのが良いと思う。

最後に自宅勤務に向かないケースやデメリットを書いておく:

  • 他人とのコミュニケーションを密に取る必要がある場合
  • 仕事に対して自分が未熟である場合
  • 自宅での作業が向かない場合 (アパートの隣の家に友達が来たのか、騒がしかったことが一回)
  • オフィス街と違って、住宅街のランチは時間がかかる (ことが多い)
  • 一人で作業していると寂しくなる時がある
  • 社内に持ち込まれたお土産やおすそわけにありつけない!! (数に余裕があると残ってる場合もある)

2013-12-09

社内で chef-solo 勉強会を開いた

2013-12-09、chef-solo の勉強会... というか「入門の入門」をプレゼンした。

内容は伊藤直也氏の「入門 Chef Solo」をよりシンプルに噛み砕いたもの。

入門Chef Solo - Infrastructure as Code
入門Chef Solo - Infrastructure as Code

とはいえ、工夫もある。同書が発売されたのは 2013-03-11 (Amazon の書籍情報による)。それからまだ一年も経っていないのに、同書の内容は古くなっている。

同書の発売に少し先がけて、ruby 2.0.0 がリリースされた。Vagrant は gem ではなくパッケージ提供されるようになった。Sahara は今や gem ではなく Vagrant の plugin となっている。そして、ruby 2.0.0 で chef がインストールできないという困った事態。それも、現在最新の chef-solo 11.8.0 では解決してしまった。

chef は進化が早い。chef は専門用語が多い。

Chef Server や knife-solo といった上級編も魅力に映る。けれど、初めて chef-solo を触った時、そういった上級編の情報はぼくにとって混乱の元でしかなかった。

今回のプレゼンでは「入門の入門」とタイトルにうたった通り、本当に chef-solo を始める人向けに最小限の情報を伝えるようにしてみた。だから、レシピの書き方は書いても、attribute の説明はしていない。Template と File の違いは書いたけど、実際のコードは説明していない。

機会があれば「Chef-solo 入門」なんて勉強会を社内で開いて、Attribute の使い方や実践的なレシピのコードリーディングなどできれば... いいな。

chef-solo 関連のエントリー

2013-12-05

コミュニケーションが下手だよね、って話

先日、友達と話をしていて「コミュニケーション能力」について話題が及んだ。

コミュニケーションにも色々あって、場の雰囲気を左右するものから、プレゼンテーションで発表するモノローグ的なものまで幅広い。今回、焦点を当てたのは「自分の意見を言う」コミュニケーションについて。

ぼくは、「自分の意見」を言うのがとても下手。

理由を友達に尋ねてみたところ、ぼくは強めに意見を出すとき「何か固執しているように見える」という。思い入れの強さが、意見を偏光させてしまう。ぼくの態度がどういう反応を周りに引き起こすかというと、「公平な意見を述べているように見えない」。

なるほど。流石、高校時代からぼくを知っているだけあって、よく見てる。思い当たる節が沢山ある。

この手のコミュニケーション能力不足は、普段、あまり顔を出さないから性質が悪い。強い主張をしなきゃ、と思う時に悪癖が表に出る。周りの信頼を少し失う。自分の言葉が軽くなる。意見が、意図が、伝わらない。もっと強く主張する。更に周りの信頼を失う。負のスパイラルに入っちゃう。

かつて、あるプロジェクトでぼくが何度言っても方針転換できなかったことを、後からやって来た人の一言が変えてしまったことがある。思えば、彼の話し方は偏りがなく事実だけを言っていた。

自分をどう変えてゆくかはこれからの課題。自己啓発本の類で、「上手く上司を説得する方法」なんて沢山あるけれども、その歯車を壊してしまう要因が自分自身にあるのだから困っちゃう。自分がどうでも良いと思ってることに関しては公平な意見なんて普通に言える。でも、思い入れのある事案に対しては、「言葉」が歪む。プレゼンの様に準備するものなら、「固執」を排することもできる。でもミーティングの中などで話し合う時は、つい熱くなってしまう。

必要なのは客観性ある意見の出し方。

それが何時でも言えるようになりたい。まずは、常に自分の発言を意識してゆくことから始めるしかないのかな。

読者へ

自分の意見が通らない・軽く見られる・信用されていない、と感じているなら周りの人に聞いてみると良いかもしれない。自分の発言が公平性を欠いていることがあるか? と。まずは意識しないことには始まらない。

2013-11-27

Nexus 7 (2013) + Android 4.4 KitKat を ART ランタイムに変えてみる

Nexus 7 (2013) に Android 4.4 KitKat がやって来た。

KitKat には、Dalvik ランタイムに代わって ART ランタイムも利用可能になっている。えっと、大雑把に説明すると、Android は Linux をベースに Android アプリを Java で動かしている。この Linux と Java アプリ (Android アプリ) の仲介をするのがランタイム。今まで Google は Dalvik ランタイムというのをずっと使っていた。それを ART ランタイムに置き換えようとしているらしい。

KitKat ではその先進機能を開発者向けに利用可能にしている。

新しもの好きなので、さっそく試してみる。

開発者向けオプションの表示

Nexus 7 (KitKat) の設定アプリを起動しても、「開発者向けオプション」が表示されない。というのも、「開発者向けオプション」が隠し機能なため。コツさえ分かれば、すぐに開発者向けオプションは表示できる。

設定アプリより

  • システム > タブレット情報 > ビルド番号

このビルド番号を複数回タップする。すると、「これでデベロッパーになりました!」と表示される。

一つ画面を戻れば「開発者向けオプション」項目が現れている。

ART ランタイムの設定

設定アプリから開発者向けオプションを選択。

「ランタイムを選択」という項目があるのでタップ。ポップアップから「ARTを使用」を選択する。

Android が自動で再起動する。意外と待たされるので、ティータイムでもどうぞ。

再起動したら Android は ART ランタイムで動いてる。

ART ランタイムにするとアプリの起動が早くなったり、逆に遅くなったり、起動しないアプリがあったり、今々あるらしい。人柱的な実験オプションなので、ART ランタイムを試す人は自己責任で。

ref.