Kikuchy's Second Memory

技術のこととか、技術以外のこととか、思ったことを書き留めています。

Objective-C で、読み取り専用になるメンバを用意したい

http://www.flickr.com/photos/36352331@N08/3962410821
photo by mh.xbhd.org


データを管理していて、外部からは変更不可能なメンバ変数(プロパティ)を用意したいと思ったことがあると思います。
通常は、データを内部に隠蔽して、getterを通して外部に公開するというアプローチをとりますね。

Objective-Cではどのようにして行うのか、調べました。

想定読者


例えば、書籍を表現するクラスがあったとします。
そこら辺に置いておいた本のタイトルなどはコロコロ変わってもらっては困るので、本が作られたときのタイトルから変化しない物とします。
すると、タイトルなどは読み取り専用である必要があります。

C#では

C#でしたら、以下のように実装します。
getter 構文を使うと綺麗に実装できます。

class Book
{
	// 内部に隠しておくための変数
	private String _title;
	private String _author;
	
	public String Title
	{
		get { return this._title; }
	}
	
	public String Author
	{
		get { return this._author; }
	}
	
	// コンストラクタでデータをセット
	public Book(String title, String author)
	{
		this._title = title;
		this._author = author;
	}
}

このように定義する事で、外部からは Book.TitleBook.Author は読み取り専用になります。

Book aBook = new Book("アジャイルサムライ", "Jonathan Rasmusson");

// 読み取りは可能
String title = aBook.Title;

// 書き込みは不可能(コンパイルエラーになる)
aBook.Title = "アート・オブ・プロジェクトマネジメント";

Objective-Cでは

.h ファイルと .m ファイルにファイルを分けて実現します。

続きを読む

Segue で画面遷移するときにパラメーターを渡してみる

昨日はTableViewを使ったUIを作っていたのですが、おなじみの


テーブルのセルをタップしたら、関連情報が次の画面で表示される


という動作をやってみたかったので色々調べてみました。

大筋

Windows Store Application ならば Frame.Navigate(targetPageClass, parameter) のように遷移用のメソッドで直接パラメーターを渡す事ができ、パラメーターも Page.onNavigatedTo(navigateEventArgs) メソッドの引数から受け取る事ができます*1
引数でパラメーターを受け取ることができるので、どのタイミングでパラメーターが渡って来るのかが非常に分かりやすく、かつスマートです。

しかし、iOSフレームワークにはそういった機能は無いようです。
遷移先のViewControllerにpublicなメンバを作り、遷移前にそこにデータを突っ込んでパラメーターにします。

delegateパターンほど汚い感じはしませんが、うーん、好きじゃないなぁ…


今回は、タップされたセルの番号を次の画面に渡してみます。

環境

手順

昨日の続きです。StoryBoard上にTableViewControllerを配置してあり、次のViewControllerに遷移するSegueを作成済みと仮定します。

移動先をカスタムした View Controller にする

データを受け取るためには、遷移先のViewControllerにパラメーター受け取り用のメンバを作らなければなりません。
そして、テーブルをタップした後に遷移する先のViewControllerが自作のViewControllerであるとStoryBoardに書く必要があります。

という訳で、カスタムしたViewControllerの作成から行ってみましょう。

プロジェクトに、 ViewController を継承したクラスを追加します。
今回は CutsomViewCOntroller という名前にしました。

f:id:kikuchy:20131104224937j:plain

*1:パラメーターは一度シリアライズされるので、基本型以外を渡すのは推奨されていませんが

続きを読む

Xcode 5 + iOS 7 で、StoryBoard + TableView

最近進められていなかった mixi-inc/iOSTraining · GitHub を再開しました。

ところがXcode 5になってから mixi-inc/iOSTraining · GitHub にトライするのは初めてだった上、ドットインストールのiPhoneアプリ入門講座StoryBoard の便利さに気付いてしまった私は、どうしてもStoryBoardを使った開発をしたかったので、StoryBoardを使いながら mixi-inc/iOSTraining · GitHub をこなす方法を探してみました。


今回は 4.1 uitableviewについて4.2 uitableviewとnavigationcontroller に挑戦したので、これを xib を使わず StoryBoard だけでやってみたいと思います。


内容はオリジナルの教材と同じ順番で進めて行きます。

環境

手順

サンプルプロジェクトの作成

4.1 uitableviewについてサンプルプロジェクトの作成の内容を StoryBoard を使って行います。

普通に "Single View Application" を作成します。

f:id:kikuchy:20131103193730p:plain

続きを読む

アクセス解析によるこのブログのアクセス数アップ方法を本気出して考えてみた(11月号)

f:id:kikuchy:20131101182103p:plain


先々月号先月号の続きです。

9月のアクセス解析結果と10月の解析結果を見比べて、もっと多くの人に見てもらうにはどうしたら良いのか考えます。

行動予定

  1. 分析
  2. 改善策の仮説と、施策を立てる
  3. 施策を実行
  4. 仮説の当たり外れを検証

先月号で1と2を行い、10月も3を実行しました。
今月も、先月の数字と比較を行い、この記事で1と2を行って、今月も3を行います。

目的

何度でもおさらいです。
直接的な目的は、もっと多くの人にこのブログを読んでもらうことです。
こんな目的を設定した理由は以下の通り。

  • 何か困ったことがあったときの解決法を探す一助にしてもらう
  • kikuchyの名前を覚えてもらう(パーソナルブランディング
  • 酢ろぐさんみたく、技術系のHow Toをまとめていてなおかつたくさんの人に読んで頂きたい

ちなみにこのブログは、
プログラミングに関するマイナーなトラブルシュートやハウツーを掲載しているブログ
というテーマになっています。

Google Analytics分析の結果

9月と10月のデータを比較しました。

数字の比較

以下の画像をご覧下さい。

f:id:kikuchy:20131101182152p:plain

先月号ほどビックリする勢いではありませんが、確実に右肩上がりです。

続きを読む

エンジニアに読ませたら良いんじゃないかと思う『RUNNING LEAN 実践リーンスタートアップ』

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)



新しいWebサービスやアプリを使ってご飯の種にしようとするなら、ちゃんとビジネスができないといけないと思っています。

『ものを企画して、発注、販売する』
という基本的な商売はやったことがあるものの、ソフトウェアを使ったものでもなく、本格的なビジネスを経験した訳でもありません。

そこで、どうやらビジネスモデルの作り方や、リーンスタートアップについて書かれていると聞いたのでこの本を読むことにしました。


主に印象に残ったのは以下の2項目でした。

  1. MVP (Minimum Value Product)を作る
  2. プランのテストを行う

それぞれについて、順番に説明します。

1. MVP (Minimum Value Product)を作る

http://www.flickr.com/photos/24257141@N05/7269970122
photo by PetitPlat - Stephanie Kilgast


「これでビジネスになるのかどうか」を検証しようと思ったら、最低限はビジネスの元手が必要になるはずです。
ここで言う元手とは、商品やサービスなど、買手に対して提供されるものです。

いかなるビジネスを行うにしても、

独自の価値提案を明確にし、
課題に対する最低限の機能を実装する

ことをすべき、だそうです。

小さいものであれば開発にかかるコスト(時間コスト、金銭コスト)は小さく済ませる事ができますから、万が一「これはビジネスにならない」と判明しても捨てるのは容易だ、ということです。

また、規模が大きく複雑なものは、テストを行いづらいから、という要因もあるようです。

エンジニアとしては、

ビジネスプランにも単体テストが必要で、単体テストを行うためにもクラスの役割ははっきりさせた上で適切な粒度で実装する事!

と言ってもらった方がしっくり来る気がします。

2. プランのテストを行う

http://www.flickr.com/photos/57258627@N00/8154228688
photo by hellocatfood


MVPを構築したら、それが解決する(予定)の問題をどれだけ解決するのか(製品/市場フィット)をテストする必要があります。

その手法として、この本では見込み顧客へのインタビューを薦めています。

インタビューを行うにあたって、

  • ターゲットの探し方
  • 質問する事柄の探し方
  • インタビュー結果の使い方
  • 繰り返しインタビューを行って改善する方法

が書かれています。

やはりプログラミングに例えて言うなら、

ビジネスプラン用のCI(継続的インテグレーション)ツールの紹介と、それを使った開発の進め方について

という内容です。

著者はこの本を制作する際にもこの手法を行っており、その時に実際に行った手順も紹介されています。

読めば読むほど、フレームワークの大枠はアジャイルプロトタイピングと近い印象でした。
もちろん、コンピューター相手にテストを行うのと人間相手に行うのとでは同じように行かないでしょうが、違いと言えばその辺りくらいではないかと思ってしまいます。

エンジニアに読ませたら良いビジネス書

ビジネス、特にリーンスタートアップに興味がある人が読むべき本でしょう。
けれどもむしろ、ベンチャーやスタートアップで働きたいエンジニアに読ませるべき本なのではないかと感じました。

今日日、エンジニアは単なる技術オタクではいられなくなっています。

様々な役割の方々と協力しなければビジネスは回らないのですから、その方々とコミュニケーションをとるためにも知識が無いといけないでしょう。
具体的には、共通言語が必要になります。

エンジニア同士であれば、技術用語という非常に便利な言葉があり、スムーズに会話を行う事ができます。
同じような言葉と、その言葉が運ぶ概念を理解しておけば、スムーズなコミュニケーションが期待できるのではないでしょうか。

今度はデザイン関係の本も読んでみようと思いました。