「はじめてのiPhone/iPadアプリ開発」の iOS7/Xcode5対応サンプルコードとサポートページを公開しました

今年3月に出版されたiPhone/iPadアプリ開発の書籍 はじめてのiPhone/iPadアプリ開発―iOS6/Xcode4対応版 (TECHNICAL MASTER) のiOS7/Xcode5に対応したサンプルコードサポートページ を公開しました!

はじめてのiPhone/iPadアプリ開発―iOS6/Xcode4対応版 (TECHNICAL MASTER)

はじめてのiPhone/iPadアプリ開発―iOS6/Xcode4対応版 (TECHNICAL MASTER)

サンプルコード

「はじめてのiPhone/iPadアプリ開発」で取り上げているサンプルコードは大部分はそのままでも iOS7/Xcode5 で動作しますが、

  • ビデオ再生アプリが iOS-SDKの仕様が変わったようで早送り等が出来なくなりました
  • 一部のアプリでは、表示の一部が欠けます

を修正しました。秀和システムのサポートページ からダウンロードできます。

サポートページ

サポートページ では iOS7/Xcode5 で本書内容と関連する、

  • iOS7のフラットデザインとコンテンツ中心の考え方で表示の一部が欠る件の対応方法
  • Xcode5で変わった Constraint(AutoLayout)の配置方法の簡単な解説

を書きましたので、参考にして頂けると良いかと思います。

ssh ログインで ~/.ssh/id_ras が優先されるのを防ぐには

GitLab を開発用サーバーに入れて運用し始めたのですが ~/.ssh/config に接続用の秘密キーを指定しても ~/.ssh/id_ras を使って接続しょうとしエラーになり困っていました。

実用SSH 第2版―セキュアシェル徹底活用ガイド

GitHub風システム、GitLab は ssh 接続のgitコマンドからのアクセス時には、sshのキーを使いユーザーを管理しています。

もし1人のUnix(Mac)アカウントがGitLabに複数のユーザーを登録していて、ユーザーAの公開キーが ~/.ssh/id_ras に対応するもので、ユーザーBの 公開キーが ~/.ssh/id_ras_git の場合を考えてみましょう(各ユーザーのリポジトリーはユーザーだけがアクセス出来ます)。ユーザーBに対応するリポジトリーをアクセスする際に ~/.ssh/config に

Host user-b-repo
  Hostname gitlab.xxxx.com
  User git
  IdentityFile ~/.ssh/id_ras_git

と書き git clone git@user-b-repo:user-b/zzzz.git の様にアクセスすると認証エラーになってしまいます。
ssh に -v オプションを付けて user-b-repo をアクセスしてみると

% ssh -v user-b-repo
OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /Users/aaaaaa/.ssh/config
debug1: Reading configuration data /etc/ssh_config
   ....
debug1: Connection established.
debug1: identity file /Users/aaaaaa/.ssh/id_ras_git type 1    ← ~/.ssh/id_ras_git が使われています
  ...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/aaaaaa/.ssh/id_rsa       ← ここに注目
   ...

なぜか ~/.ssh/id_ras を使って接続しています。この際に GitLab は ユーザーA がアクセスしてきたと解釈し、ユーザーBのリポジトリーにはアクセス権がないのでエラーを返します。

ここ数日悩んでいたのですが、今日判りました。 ~/.ssh/config に IdentitiesOnly yesを追加すれば、指定した秘密キーのみが使われるのでした!


ということで ~/.ssh/config は以下の様に書きましょう

Host user-b-repo
  Hostname gitlab.xxxx.com
  User git
  IdentityFile ~/.ssh/id_ras_git
  IdentitiesOnly yes

Chef を学んで使ってみた

空前の DevOps ブームに乗り遅れてはいけないとChefを学び、お客様の次期サーバーやRuby on Rails教育で使うサーバーを構築してみました。

http://docs.opscode.com/_static/opscode_chef_html_logo.png

感想

今回、お客様の次期サーバーを作るにあたりChefを使ってみたたところ、一度recipesを作ってしまえば サーバー環境が 10 〜30分くらいで自動的に出来てしまうのは画期的だと感じました!

私は教育・開発者なので、新しいサーバーの構築は年に数回、管理しているサーバーは数台程度です。従来はサーバーの構築・管理は手動で行い、作業内容をメモファイルに残していました。また、再度使う可能性があるサーバー環境はEC2のイメージとして保存して来たりしました。
しかし、作業のメモは必ずしも完璧ではないですし、メモを見落としてインストールに失敗する事もままありました。また保存してあるイメージですが、RubyRailsがバージョンアップし教育では使えなくなってしまう事もあります。

手動でサーバー環境を構築しようとすると半日仕事になってしまいますが、Chefがあれば 10 〜30分くらい。しかも勝手にやってくれます。今までは、環境構築がおっくうで一つのサーバーに色々なアプリをrbenvとかを駆使して動かしていましたが、コスト面で問題がなければクラウドVPSでサーバーを立ち上げ、すぐに環境が作れてしまいます。
また、recipe はコードなので少し考えて作っておけば再利用が可能で、新たな環境用に Chef も比較的短時間で作れます。

私のように、頻繁にサーバーを構築する事のない開発者も学んだ方が良い技術だと思います。

学び方

入門

入門は、やはり naoyaさんの 入門Chef Solo を読みましょう。原理的な事から実践的な事までがコンパクトにまとっまている良い書籍だと思います。私は kindle版が出た時に買ってしまったのでMacの横にiPadを置きKindleアプリで見ながら作業をしましたが、今なら 達人出版会からPDF(EPUB)版を買えば PC, Mac で見ながら作業出来るので、こちらがお勧めです。

http://tatsu-zine.com/images/books/78/cover_s.jpg

実際に作ってみる

実際にrecipe作る際には、

Recipe作りの基本

Resources

詳細は、入門書やリファレンスを読むとして、実際に Ruby on Railsアプリを動かすサーバーを構築するにはよく使う 以下のResources (Ruby DSL) を recipe に並べるだけです。

  • package: OSのパッケージ(apt, yum) 等のインストール
  • gem_package: RubyGemsのインストール
  • cookbook_file: 設定ファイル等の作成、用意した設定ファイルのコピー+α
  • template: 設定ファイル等の作成、設定ファイルをテンプレート化(Ruby のERB)出来るの汎用性がある
  • remote_file: ネット上からファイルをダウンロードする
  • file, directory: ファイル、ディレクトリーの作成
  • user, group: Unixのユーザー、グループの作成
  • service: デーモン(サーバープロセス)の起動、停止・・・
  • execute: OSコマンドを実行することで上記の Resources では出来ないような操作を行う

べき等性 (冪等性, idempotence)

Chefのrecipeでは既にrecipeと同じ状態になっている場合は、何も行わないという べき等性を保つようにrecipeを作る必要性がります。
これは、Chef がインストールツールではなく、サーバー等の環境の変更を管理する為のツールだからです。packageをはじめ殆どのResourceは、既にインストールされている場合は何もおきません。
ただし、execute などは自分でべき等になるように作る必要があります、その為の仕組みが幾つかあります。

  • creates属性: executeを実行した場合に出来るファイルを書いておくと、そのファイルがある場合は execute が実行されません
  • only_if, not_if属性: 書かれたRubyの式、またはshellコマンドの文字列を実行した結果で実行する・しないを制御出来ます

Notifies

設定ファイルが作成・変更された時だけサーバーをリスタートする事が良くあります、このような場合は以下のサンプルのように設定ファイルを作るresource内に notifies を書くことで、設定ファイルが作成・変更された時にサーバーのリスタートを実行できます。
ちなみに、service "mysql" do 〜 のactionがnothingになっているので、最初に service "mysql" do 〜 が実行される際には何も起きません。

service "mysql" do
  supports :status => true, :restart => true, :reload => true
  action :nothing
end

cookbook_file "/etc/mysql/conf.d/character_set_utf8.cnf" do
  source "character_set_utf8.cnf"
  owner 'root'
  group 'root'
  mode  0644
  notifies :restart, 'service[mysql]', :immediately
end

Ruby

recipe は Rubyのコードなので、当然 Rubyの式、変数、メソッド(関数)が使えます、何度も出てくるパス名や処理は変数やメソッドを使うとメンテナンス性の高い recipe になります。 ただし、resource内で呼び出すメソッドは libraries ディレクトリーに置きます。

repository > cookbook > recipe

複数のrecipe が集まり cookbook になり、複数の cookbook が集まりrepository になります。 したがって、一つ recipe ファイルはある程度の粒度(作業単位)で書き、cookbook, chef を分ける事が再利用性の高い recipe 作りに役立つと思います。

Chef Cookbooks

http://community.opscode.com に既に作られたrecipe (Cookbooks) がたくさんあります。naoyaさんの本にもChef初心者はCookbooks を使わずに自分で recipe を作った方が良いと書かれていますが、私もその通りだと思います。
一般的にCookbooksにあるものは汎用的で高機能ですが、自分専用の環境を作ったりする際には resouces や LWRP を使い recipe を作った方が勉強になるだけでなく、後々のバージョンアップ等でトラブルが起きにくいと思います。

私の勉強のために iptablesの設定に simple_iptables を使ってみましたが、自分でシンプルなrecipeを書いた場合に比べ良いのかは疑問です ;-)
ちなみに、Cookbooksは http://community.opscode.com/cookbooks ここで検索すると、評価(rating)やダウンロード数が判るので、どれを使うかの参考になると思います。

Vagrant

recipe の作成、確認はローカル(Mac)上のVM(仮想マシン、私の場合はVMWare fusionを持っていたのでこれを利用)で行います。recipeは べき等に出来ているので、OSだけがインストールされた新しいVMから再実行する必要な状況が良くおきます。その際には Vagrant を使うと、コマンド一つで新しいVMが直ぐに作れとても便利です。

Postfix 2.10 から中継制限の設定が変わった (smtpd_recipient_restrictions はダメ)!

Ubuntu 13.04 を使ってRailsを動かす環境を作っていたのですが、ひさびさにはまり何時間もロスしてしまったので書いておきます。

http://www.postfix.org/postfix-logo.jpg

PostfixSMTPで認証を行い任意のIPアドレスからメール中継を可能にする設定は、2.09までは main.cf に

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

と指定します。検索すると、どこにもこの記述ができてきます。しかし Postfix 2.10 では 554 Relay access denied エラーになってしまいます・・・・
以前に設定した Ubuntu 12.04 (Postfix 2.09)の環境では上手く動作します。うぅぅぅ・・

いろいろと検索し、やっと http://www.postfix.org/SMTPD_ACCESS_README.html に答えが書いてありました

NOTE: Postfix versions before 2.10 did not have smtpd_relay_restrictions. They combined the mail relay and spam blocking policies, under smtpd_recipient_restrictions. ....

ということで、 smtpd_relay_restrictions を設定しましょう!

smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Ruby on Rails4.0.0正式版でJSON関連コードが無いキレイなscaffoldを生成する方法

Ruby on Rails4.0.0が正式リリースされましたが、4.0.0RC1 までと JSON関連のコードが無いscaffoldを生成する方法が変わりました ^^;

http://rubyonrails.org/images/rails.png

4.0.0RC1 までは、以下のオプションで JSON関連のコードが無い、きれいな controller と views の *.json.jbuilder が生成されませんでした。

% rails g scaffold todo due:date task:string -c scaffold_controller

しかし、Ruby on Rails4.0.0正式版 (4.0.0RC2から)は上のオプションでは JSON関連のコードが生成されてしまいます。--jbuilder=false を指定すれば *.json.jbuilder は生成されなくなりますが、controller には 醜い respond_to 〜 format.json があります ^^;

コードを見て判った事は、JSON関連のコード生成は jbuilder Gem が行っています。 したがって、Gemfile から jbuilder Gem をコメントアウトしてしまえばOKです。

結論

Ruby on Rails4.0.0が正式でJSON関連のコードが無いscaffoldを生成するには

Gemfile を以下のように変更します

gem 'jbuilder', '~> 1.2'

↓ 変更

# gem 'jbuilder', '~> 1.2'

Rails4.0で rake db:fixtures:load FIXTURES_PATH=spec/fixtures が deprecated と表示された際の対処法

Rails4.0RC2もリリースされましたね!
Rails4.0 で rake db:fixtures:load FIXTURES_PATH=spec/fixtures を実行すると以下のようなワーニングが表示されます。fixtuesの読み込みは出来てますが、気持ち悪いですよね。

% rake db:fixtures:load FIXTURES_PATH=spec/fixtures 
Using FIXTURES_PATH env variable is deprecated, 
please use ActiveRecord::Tasks::DatabaseTasks.fixtures_path = '/path/to/fixtures' instead.

色々と検索したのですが、適切な回答が見つからなかったので、ここに書いて置きます。

暫定的な対応

2013/12/19 Rails 4.0.2 では動作しないようです

fixturesのディレクトリーを指定する FIXTURES_PATHは deprecated ですが、fixtures ディレクトリーの下のディレクトリーを指定する FIXTURES_DIR は、まだ有効です。そこで、これを ../../ と悪用(?) して本来のfixturesのディレクトリー (デフォルトは test/fixures) の外のディレクトリーを指定しています。

% rake db:fixtures:load  FIXTURES_DIR=../../spec/fixtures

たぶん正しい対応


ワーニングに書かれているように、ActiveRecord::Tasks::DatabaseTasks.fixtures_path にfixturesのディレクトリーを指定すれば良いのですが、どこにこれを書いたら良いのかを見つけるのに手間取ってしまいました。

実は、 rake db:〜 の rakeタスクは lib/tasks に db.rake ファイルを書くことで機能を追加・変更できます。

namespace :db do
  task :load_config do
    ActiveRecord::Tasks::DatabaseTasks.fixtures_path = File.join(Rails.root, 'spec', 'fixtures') 
  end
end

2013/12/19 修正
2013/12/25 修正

そこで、 lib/tasks/db.rake ファイルに上のように書いてあげると、通常の rake db:fixtures:load で spec/fixtures から読み込んでくれます。

RubyKaigi 2013の感想など

生まれかわった RubyKaigi RubyKaigi 2013 に参加しました。

http://rubykaigi.org/2013/images/badgeOfficialSponsor.png

今回も私の会社 EY-Office は スポンサー (一番小さいのですが)になりました。 現在のEY-Officeの売り上げのほとんどが Ruby, Ruby on Railsの教育なので当然ですよね ^^)

RubyKaigi全体の感想など

Matz がいる RubyKaigi

今までのRubyKaigiは土日開催が多く、Rubyのパパ Matz(まつもとさん)は宗教上の理由から土曜夜の帰ってしまわれる事が多かったと思います。
しかし、今回は木金土開催だったので、いつもMatzが会場にいました。 にこにこと質問に応じてくれるMatz 、お弁当を配ってくれるHeroku社員のMatz、 ボッチのMatz 。。。 私も Rubyの質問をゆっくりと出来ました。
Matz がいる Rubykaigi は Matz is nice so we are nice. が感じられる良い空間になってたと思う。

みんなと語りあえる Bentou のありがたさ

今回は Heroku が Bentou スポンサーとして、毎日の昼ご飯を提供してくれました。おかげで、お店に行ったりする時間が要らず、いろいろな参加者と話す事が出来、有形無形の得るものがりました。
Herokuさんありがとうございます。Microsoftさんも飲み物ありがとうございます。

しかし、語り合えない

@a_matsuda さんが、なぜ(日本人)みんなは、いつも使ってるモジュールやツールの作者の(外人の)開発者が来てるのに、話さないのかな? と言われ・・・・

その晩、考えました。

  1. 便利に使ってるモジュール・ツールでも、使ってるだけで、そのコードを読んだりしてない。したがって作者も知らない
    • これは、日本人の作者でも同じで、使っていても、そのモジュール・ツールそのものに興味をもっていない事が多い
    • 何か自分のやりた事が出来そうで出来ない時などはコードを読むが、そうい機会はそんなに多くない
  2. 英語力の低さ(低いと思ってる意識)もあり「素晴らしいモジュール・ツールをありがとう」と声をかける事が出来ない
  3. 上の2つが関連し、そのモジュール・ツールに興味があれば、拙い英語でも質問をしたくなるし、技術的な話しなら出来そうだけど、一般的なお話が出来る英語力は無いよ・・・

しかし、技術は圧倒的に英語圏で生まれるいまの時代、このようなチェンスに話しが出来ないのは本当にもったいないよな。
英語がんばろう! コードもたくさん読もう!

Ruby on Railsの人がたくさん登壇

以前より Ruby on Railsの人(と思える人)のセッションが増えたと思います。しかも、彼らの多くも Rubyの事を語っていました。
昔からRubyを使っていた人たちと、Ruby on Railsを使ってる人の溝みたいな物が、凄く小さくなっているように思え嬉しかった。

角谷さんの RubyKaigi

角谷さんは世界で一番 RubyKaigi の事を考え、時間を使っている人だ。 1年の休みを取ってからの 2nd Season の RubyKaigiが現実になり、緊張したり、焦ったりしながらも、輝いてる Kaigi屋の 角谷さんを 久しぶりに見られたのも 嬉しかった。

技術的な収穫

オブジェクト指向の再来

オブジェクト指向が今ほど広まっていなかった昔、一部のエンジニアたちが熱く語っていたオブジェクト指向。時は流れ Ruby on Rails を始めオブジェクト指向は一般的になりたくさんの場所で使われ出してみると、あらたな問題が出てくる・・・ 今回のRubyKaigiでも DCI, Refactoring Fat Models with Patterns、Refinement .... オブジェクト指向の古典と、さらにRubyらしい新しい形の話しが聞けた。今後も楽しみ。

RubyMotion

登場したときに、これは面白い! と思った RubyMotion でしたが、購入後まったく触っていませんでした、今回 RubyMotion がどのような仕掛けになっているのかが判りました。
そしてその面白さに惹かれて、現在あるアイデアを実装出来るのか試しています。Objective-Cが抵抗なく書ける私ですが、案外 面白い事が出来そうだとワクワクしています。

PyPy

RubyKaigi終了後の Tokyu.rbの宴会であった Pythonista の方(すいません名前を忘れてしまいました!)から PyPy の話しを聞かせてもたっら。
PyPyは Python で書いた Pythonの処理系だと思っていたのですが、現在は 動的言語処理系を作るためのフレームワークなのだそうです。LLVMGCCにかわる新しいCコンパイラーではなく、コンパイラーを作るためのフレームワークだというのと同じだそうです。面白そうですね Topaz (PyPyで作られたRuby処理系) もそんなところから生まれて来たんですね、納得納得。

年を取った

Matzの髪の毛や髭に白いものが混じって来て・・・ という話しではなく。3日間の密度の高いRubyKaigiに参加するのは体力が無く3日目は疲れていて、ついつい居眠りをしてました ^^;

歳を取ったなぁ〜 と思い知らされました。 でも老体にむち打って来年も参加します!
来年もスポンサーになれるようにがんばって仕事しよう !!