アクセス解析によるこのブログのアクセス数アップ方法を本気出して考えてみた(12月号)
今までに比べてちょっと更新が遅くなりました。
の続きです。
過去三ヶ月と11月の解析結果を比べて、もっと多くの人に見てもらうにはどうしたら良いのか考えます。
行動予定
- 分析
- 改善策の仮説と、施策を立てる
- 施策を実行
- 仮説の当たり外れを検証
先月号で1と2を行い、10月も3を実行しました。
今月も、先月の数字と比較を行い、この記事で1と2を行って、今月も3を行います。
目的
何度だっておさらいです。
直接的な目的は、もっと多くの人にこのブログを読んでもらうことです。
こんな目的を設定した理由は以下の通り。
- 何か困ったことがあったときの解決法を探す一助にしてもらう
- kikuchyの名前を覚えてもらう(パーソナルブランディング)
- 酢ろぐさんみたく、技術系のHow Toをまとめていてなおかつたくさんの人に読んで頂きたい
ちなみにこのブログは、
プログラミングに関するマイナーなトラブルシュートやハウツーを掲載しているブログ
というテーマになっています。
アイデアを公開しない理由2つに対する反論
作りたい物が増えても作業に当てられる時間がないのもあって、「やりたいこと・作りたいものリスト」を作って公開することにしました。
kikuchy のやりたいこと・作りたいものリスト #fromEvernote https://t.co/Bf9wnQllSA masuidriveさんに習って公開してみることに。これから随時追加予定。
— 菊池紘 (@kikuchy) 2013, 11月 29
「こんな感じのものをどこかで見た!」
「一緒に作りたいから詳しい事教えて!」
「作っちゃった!」
とかありましたら、是非教えてください。 @kikuchy にリプライを飛ばしていただくか、Facebookでメッセージを送っていただくかしていただければ喜びます。
ちなみに、元ネタは @masuidrive さんのmasuidriveの作りたい物&試作品リストです。
さて、 @masuidrive さんみたくアイデアを公開する人も居れば、一方でアイデアを公開したがらない方もいらっしゃいます。
どうしてアイデアを公開しないのでしょうか。
実際に私が聞いた事、よく言われることについて、私なりの反論をしたいと思います。
理由1: 折角お金になりそうなのに、他の人に見せて盗られたらもったいない
反論: 「それ本当にお金になるの? あなたが勝手に『価値がある』と思い込んでいるだけじゃないの?」
Objective-C で、読み取り専用になるメンバを用意したい
データを管理していて、外部からは変更不可能なメンバ変数(プロパティ)を用意したいと思ったことがあると思います。
通常は、データを内部に隠蔽して、getterを通して外部に公開するというアプローチをとりますね。
Objective-Cではどのようにして行うのか、調べました。
想定読者
- オブジェクト指向については知識がある
- C#, C++, JavaScript のいずれかで、読み取り専用のメンバを持つオブジェクトを作ったことがある
- 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.Title
と Book.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 という名前にしました。
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" を作成します。