koichi222のブログ

Engineer. Love technology & music.

2015振り返り（会社について）

■ 環境
　マンションの一室を抜けだして、うまいこと居抜きで借りられた
　広々としたオフィスに喜んでいたのが、丁度去年の１月だった。


新オフィスに引越しました。 #引越し #快適

koichi saitoさん(@koichi222)が投稿した写真 -


　当時7名だったメンバーも、今ではインターンなども含めると30名弱になった。
　ちょうど昨年末に、新オフィスへの移転を済ませたところである。その新オフィスも既にいっぱいになりそうな気配がある。



　

昨年前半はAkerunという１つのプロジェクトという意味合いが強かったが、後半になるにつれPhotosynthという組織を意識することが徐々に増えていった。
　　
キーワードで言えば、役割の定義と最適化、権限委譲、組織内コミュニケーションと情報共有、ビジョン、ミッション、といったことに頭を捻る時間が徐々に増えていった。

熱量と一体感を保ちつつ、組織としてどうスケールするか、という部分が、今年のテーマかと思う。


■ プロダクト
　昨年は４つの製品を発表することができた。
　　・Akerun
　　・Akerun Remote
　　・Akerun Touch
　　・Akerun Entrance
　どれも思い出のある製品だが、一番はやはり4月にAkerunを発売できたこと。


思い出 #akerun

koichi saitoさん(@koichi222)が投稿した写真 -


この時の経験が自分たちの原体験になっているし、直接経験しているメンバーとして、この時の感覚を残し続けたい。端的に言うと、顧客理解が重要なのは百も承知な上で、自分たちのこだわりをもった、世の中への問いかけがあるものづくりをしたい。顧客に表面的に寄せるのでなく。そうでないとわざわざ起業してやっている意味が無い。

今年は、ようやく立ち上がり始めた事業を、スタートアップたりえる成長スピードにグロースさせていくのが大きなミッションだと思う。


■ チーム
　すごくよかった。総じて働いていて楽しかった。

　自分も含め若いメンバーが多いので、正直未熟な部分は多い。決してスマートではないと思うし、安定感もあるようなないような。
　
　ただ、チーム全員が仕事に対して思いがあって、前向きで、ハードワークを厭わないという環境が本当にすばらしいな思う。これを当たり前と思わずに感謝したい。
　
　たまに気分が乗らない時も、オフィスに行ってみんなと話すと自然とやる気が湧き上がるようなチームだった。


■ PR
　ありがたいことにいろいろ注目いただく機会が多く、スタートアップの中でも
　かなりメディア露出の多い会社であったように思う。賞もいくつか頂いた。

　良くも悪くも目立ってはいたので、PR先行ですね、みたいな声をいただくこともあった。

　語弊のある言い方かもしれないが、
　「世の中を勘違いさせて、世の中が勘違いに気づく前に現実化する」
　というのが、スタートアップのやり方なんじゃないかと思う。
　
　その根本にはやはりAkerunの経験があって、コンセプトと(お弁当箱みたいな)プロトタイプしかなかった段階でも世の中に反響を生むことができ、半年後には製品を発売し、受け入れてもらえたから。だからこのやり方は、自分たちらしい。今年も続けたい。



よく言う話で、スタートアップ創業の２年間は魔法がかかっている、という話がある。
創業直後の会社は自然と周囲を惹きつける魅力とオーラを発し、何事もポジティブに変えてしまう、という意味だ。

Photosynthは創業して１年が経ったが、間違いなくこの１年は魔法がかかっていたし、それによって恩恵を受けていた部分は多かった。

その言葉を信じるのであれば、来年のこの時には丁度魔法が解けることになる。

最後の１年、魔法が解けるまでになにを現実化できるか。確固たるものを残せるようにしたい。

iPhoneアプリのテスト配布方法について

■ どんな配布方法がある？
・Ad hock
App Storeを介さずに、最大100台のデバイスまでアプリ配布可能。
デバイス追加の都度、UDID登録、プロビジョニングファイル更新、リビルド等の作業が必要。
　Ad Hoc での実機テスト方法は幾つかあります
　・サーバーに ipa ファイル上げ、各テスターがそれをダウンロード
　・iPhone 構成ユーティリティーアプリを使う
　・TestFlight というサードパーティーのサービスを利用する
　・ipa ファイルを渡し、テスターが iTunes を使ってインストール
　引用元：https://akira-watson.com/iphone/ad-hoc.html

・test flight
　・配布までのプロセスが簡単
　　・itunes connectの管理画面での配布の設定が可能
　　・testfligtアプリ経由での端末の配布

■ testflightの種類について
　・インターナルテスト
　　・位置づけ
　　　・開発者用テスト
　　・対象
　　　・iTunes ConnectにAdminかTechnicalメンバーとして登録している人
　　　・最大25人
　　　・１人あたり10台までデバイスが登録可能

　・エクスターナルテスト
　　・位置づけ
　　　・リリース前のベータテスト
　　・対象
　　　・apple idをもってる人
　　　・最大1000人
　　・appleの審査が必要
　　　・通常の審査よりも早い、15時間とか
　　　・app storeのリリースの審査と平行して審査を申請することが可能

　★ どちらもios8.0以降の対応のみ

■ これまでtestfligtとの違い
　・これまで
　　・端末ごとにuuidを登録してもらう必要
　・これから
　　・apple id(メールアドレス)でok
　　★apple id持ってなくても大丈夫？
　　　→ エクスターナルテストならok

■ 検討事項
　・ios7.0以前の対応
　　参考：http://stackoverflow.com/questions/17034772/installing-testflight-on-ios-7

■ 手順
・xcodeでソースをArchiveし、submitする（アプリ申請時の時と同じ）
　参考：https://akira-watson.com/iphone/app-upload.html

・itunes connectの管理画面より、testfligtの設定をする
　参考：http://www.toyship.org/archives/1868

【iphone】アプリ初回起動時の判定

iphone app

チュートリアルを出すための判定がしたかったので調べた。

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions

{
    if ([[NSUserDefaults standardUserDefaults] boolForKey:@"HasLaunchedOnce"])
    {
        // ２回目以降の起動時
    }
    else
    {
        // 初回起動時
        [[NSUserDefaults standardUserDefaults] setBool:YES forKey:@"HasLaunchedOnce"];
        [[NSUserDefaults standardUserDefaults] synchronize];
    }
}


参考：ios - How to detect first time app launch on an iPhone - Stack Overflow

簡単！！

【iphone】cocoapod導入で躓いたところ

iphone app

基本的な手順は下記エントリを参考にした。

Objective-C - CocoaPodsでPodの利用＆作成のメモ - Qiita [キータ]

 

  • エラー1

ld: library not found for -lPods

Podsがビルドされていないのが原因。下記サイトを参考にビルドして解決。

CocoaPodsを使ったXcodeプロジェクトの作り方（１） - shigeki.takeguchi.log

CocoaPodsを使ったXcodeプロジェクトの作り方（２） - shigeki.takeguchi.log

CocoaPodsを使ったXcodeプロジェクトの作り方（３） - shigeki.takeguchi.log

CocoaPodsを使ったXcodeプロジェクトの作り方（４） - shigeki.takeguchi.log

 

１点少しハマったポイントを補足しておくと、xcode5の場合はmanage schemeでPodsをチェックしないとshemeが選択できないのでそこだけ注意。

Manage Schemes → Pods Projectにチェック

f:id:koichi222:20131204222049p:plain

f:id:koichi222:20131204222058p:plain

 

  •  エラー2

Pods was rejected as an implicit dependency for 'libPods.a' because its architectures 'armv7 armv7s' didn't contain all required architectures 'armv7 armv7s arm64'

このエントリで解決。

Objective-C - CocoapodsとXcode5の組み合わせでエラー出た+解決した - Qiita [キータ]

 

 

TDDBootCampFukuokaに参加してきたので、TDDについて改めて考えてみた。

f:id:koichi222:20130616161322j:plain

 

 

6/15(土)、6/16(日)の２日にわたって開催された、TDDBootCampFukuokaに参加して来ました。 課題については他の参加者の方が説明されているので、コードだけ共有しておきます。1日目はgithubを使っていなかったため> < 、2日目の分だけ・・・

   https://github.com/shimesaba-type0/ruby_rspec

（ペアの@shimesaba_type0さんがレポジトリ上げてくださいました！）

 

 2日にわたる@t_wadaさんの公演と、その後の課題の実践を通して、TDDについての自分の考えが深まったので、 現時点でのTDDについて理解をまとめておこうと思います。

 ※ 講演の内容のまとめではなく、あくまでも講演を受けての@koichi222の考えです。

 

まず参加前の僕の状態について書いておきますと、

  • 仕事でrails & rspecでの自社サービスを開発
  • ケースの濃淡はつけてもよいが、テストは必ず書くルール
  • テストを書いておくと元の入出力と同じことが保証されるので安心してリファクタできる、というのを一番のメリットに感じていた
  • テストファーストについてはあまりメリットを感じておらず、実装の後からテストを書くことが多かった

といった感じでした。なので

  • テストファーストにこだわる意味って本当にあるのか？
  • うまくテストの強弱の付ける方法はあるのか？

などについて考えるヒントが得られればいいなぁということを参加前に考えていました。

TDDの定義について

 このエントリにおいては、

  ・TDD =「開発者が」「動くキレイなコードを」「効率的に書く」ことを目的としたテストを用いた開発手法

  と定義したいと思います。テストファーストを必須とする狭義のTDDについて言及するときは、明示的に記述することととします。

 

TDDがしてくれること、してくれないこと

まず、誤解していた部分が多かったTDDがしてくれること、してくれないことについて

まとめてみます。 

TDDがしてくれること

・TDDは、開発者が設計をせずに実装をし始めることを防いでくれる

   特にテストファーストで行うTDDの場合にいえることですが、テストを記述する
   ＝設計を記述することになります。（※1）後先考えずコードを書き始めてやみくも
   に突撃することで、後ほど右往左往して苦い思いをした経験がある方も多いと思い
   ます。TDDは設計のプロセスを開発に組み込むことで開発者が無駄な遠回りしない
   ようにしてくれます。

・TDDは、開発者が意図した設計から外れた実装をすることを防いでくれる

   TDDはテストケースとコード実行結果を照らし合わせることで、意図した設計、実装
   の通りにコードが動作していることを確かめてくれます。Red→Green→Refactorの
   サイクルはなるべく早く回すべき、というのはこのフィードバックこまかく受け取る
   ことで異変にいち早く気づき、軌道修正するためです。 

TDDがしてくれないこと

・TDDは、設計と実装の質を保証するのものではない

   TDDによって取り除かれるのは意図した設計、実装になっているのか？という不安だ
   けです。逆に言えば、そもそもその設計がよい設計なのかどうか？という点に関して
   評価してくれるものではありません。これを実感した2日目の課題を例に上げて説明
  します。2日目の課題は、wikiエンジンの実装といういきなり取り組むのは難しい大き
   な問題で、コードを書き始める前にどの項目をどういった順番でどうテストするか？

   について考える必要がありました。参加者の中であった良いアプローチとしては、

   ・まず１行の文字列を入力したらhtmlを返してくれるパーサを実装し、そのループで
 　  複数行の場合を表現しよう

   といったものがありましたが、このように、問題をどう定義し、分割していくか？と
   いう設計のプロセスについてはTDDはヒントを与えてくれるわけではありません。
   あくまでも実装が意図通りになっているかどうかを確かめてくれるだけなので、設計に
   ついて考える能力はTDDとは別で引き続き磨く必要があります。

 

・TDDは、ソフトウェアの品質を保証するものではない

  TDDというのは、開発者が効率的に開発するためのテストを用いた開発方法
  (developing test)であって、ソフトウェアの品質を保証するものではありません。
  そんなのあたりまえじゃん！という方にはここは読み飛ばして頂いて構わないので
  すが、勘違いされやすい部分だと思います。和田さんのプレゼンにあった下のスライ
  ドがわかりやすいです。
  

f:id:koichi222:20130617231916p:plain

tddbc tokyo 1.5 基調講演(http://www.ustream.tv/recorded/15889068)より引用

   

  勘違いされやすい理由として、TDDを行うことで品質が保証される場合もある、
  ということがあります。それは、元々良い設計が意図されていた時です。TDDはその
  意図が実装されているのを保証するものとなるので、結果的にソフトウェアの品質は
  保証されることになります。ですが、それはあくまでよい設計のソフトウェアが品質が
  高いのであってTDDがソフトウェアの品質を高めているわけではありません。

いつTDDするのか？

今で

これはシンプルに答えられます.

  •  開発者が不安があるとき、不安がなくなるまで行う

開発者の不安を取り除くことで、開発効率を上げる、というのがTDDの根本の考え方です。では、テストファーストで行うTDDについてはどうでしょうか？

個人的には、以下のケースは特にテストファーストのTDDがおすすめできると考えています。

  •  プログラミング初心者が設計の習慣をつけるトレーニングがしたいケース
  •  問題が大きすぎるor複雑なため、設計が出来上がって実装するのでなく、設計しながら実装したいケース

まとめ

・TDDは「開発者が」「動くキレイなコードを」「効率的に書く」ことを目的としたテストを用いた開発手法

・TDDを行うことで、設計と実装が意図通りになっているかの不安を取り除くことができ、開発効率が向上する

・よい設計をするための能力を上げるためには、TDDの習得とは異なる部分での努力が必要

 

長くなってしまいましたが、以上が現時点での僕の考えるTDDです。

主張がクリアになるようになるべく曖昧な表現は使わないようにしたつもりですが、

理解が不十分な部分、異論がある部分ありましたらぜひご指摘いただければと思います！！ ※2 

 最後に

普段なかなかTDDについて考える機会をいただいて大変有意義でしたし、

なにより参加していて本当にたのしかったです！！！（懇談会含む）

 

講演していただいた@t_wadaさん、

主催頂いた @Spring_MTほか運営スタッフの皆様、

会場を提供いただいた AIPさん、

本当にありがとうございました！！！

 

次は自分が主催したいなぁ。（ぼそっ

 

※１@t_wadaさんは仕様の記述と言われていたと記憶しているのですが、僕は仕様を実現するためにどのクラスにどのようなメソッドを書き、どんな入出力を返すか考えることは設計の領域と考えているため、ここでは設計の記述と書かせて頂きます。

 ※2 テストに関する書籍は「The Rspec book」を読んだくらいで、TDDに関する書籍はケント・ベック本を読み始めたばかりと基本的にまだまだ勉強不足なので、抜けている観点がある可能性が高いです。。

 

第三回Web若手エンジニア勉強会＆Fukuoka Ruby会議で発表してきた

ブログ書かなきゃ・・・！と思いつ放置していましたが、最近イベントに

続けて参加してきたので、ひとまず資料だけ上げておきます。

 

・第三回Web若手エンジニア勉強会

 

 

・Fukuoka Ruby会議

 

それぞれ刺激を受けるイベントで、本当に参加してよかったです。

しかし、こういう参加レポートをサクッと書ける人が羨ましいｗ

 

 

 

isucon2に参加してきました！

チームルンバとして@kazph @kitanpとisuconに参加してきました！

 

■準備

  •  まずは前回のisucon関連の記事を読みあさる
  • 最初はrubyで行こうかーとなっていたけど、前回のみたらかなり初期性能に差があったのでperlに決定
  • memcachedはどこでつかうんだろうねー
  • リバプロにnginxを立てて、nginxからmemcachedにアクセスして返すのが良さげ（前回のfujiwaraさんの構成を見て）
  •  更新があったタイミングでアプリからmemcachedにセットしよう

 

■当日

  • 初ヒカリエにテンション上がる
  •  NHNさんの受付でムーンと写真を撮る
  •  写真をひと通り撮り終えて席につく
  •  課題発表。今回の課題はチケット販売システム。
  •  スタート！
  •  パスワードのIをl と勘違いしてログインできない（しかも全員w）
  •  @kitanpさんに鍵登録、リバプロのnginxとmemcachedをインストールしてもらう
  •  @kazuphはソースをgit管理下に、その間に自分はアプリとスキーマを確認
  •  @kitanapさんリバプロを nginx に変更、しかし変えたらベンチの結果が大幅に落ちる
  •  keep alivedをいじってみるも改善せず
  •  @kazuph my.cnfをいじるがnginxのボトルネックが特定できないので切り戻す
  •  @kazuphがサイドバーのクエリをmemcachedでキャッシュするように変更
  •  その間に固定値を返すクエリ結果（アーティスト名など）をアプリ内にハッシュで定義して返すように変更（ここでセミコロンを忘れて@kazuphにディスられるw ruby脳ェ・・・）
  •  Devel::KYTProfを仕込んで@kazuphと一緒に遅いクエリを探す　
  •  ベンチを回しながら塩さば弁当をかっこむ
  •  nginxの問題が解決せず、一旦全員で見なおしてみることに。しかし引き続き解決せず
  • nginx諦めてapacheに戻す
  • ベンチのスコアがもとに戻る(800ticektぐらい)
  • @kitanapさんapacheでキャッシュをする方法を探す
  • @kitanapさんのひらめきにより一部のテーブル(order_request)のみMyISAMに変更。
  • ここで初めて1000ticketを突破！！fujiwara組が4000ticket超えているのを横目に小さな喜びを噛み締める
  • @kitanap さんに再起動時の処理を設定してもらう
  • @kazuph memcachedのシリアライザをData::MessagePackに変更
  • 　（参考：http://blog.nekokak.org/show?guid=WHTV83VE4BGhtj8nMSAp_g）
  •  @kazuph サイドバーのキャッシュ時間を1秒から増やすがfailedになったので戻す
  •  @koichi222  クエリ内のORDER BY RAND() の消去
  •  @kitanap @kazuph my.confのチューニング
  •  @koichi222 xslateのcache を2に変更
  •  ここでベンチの結果がベストに！(1188 tickets score:413727)　この時点で真ん中ぐらいか
  •  全員で再起動時の設定を確認 
  •  ただただ祈る

 

■ 結果

  • 277 tickets score:1774419
  •  ( ﾟдﾟ)
  •  ということで、最後の計測のベンチでスコアが急降下しましたorz
  • 原因の特定はできていないのですが、再起動でキャッシュが消えことと（再起動対策してなかった・・・）最後のベンチは並列接続が多かったようなので、そこで対応できなかったのかなと・・・　

 

■振り返り

良かった点

  • 当日のチームのコミュニケーションは比較的よくとれていた
  •  @kitanpさんにjoinしてもらったこと。@kitanpさんががOS,ミドルウェア、自分と@kazuphがアプリメインという役割分担ができたいたのはよかった
  • ハマっているときに@kazuphとペアプロをしたこと。冷静になれてミスがすぐ見つかった
  • 当日超楽しめたこと

 

反省点

  •  戦略がなく場当たり的な対応を取ることが多かった

　〇〇の指標を改善するために、◯◯の変更を加えて、結果〇〇ぐらい改善した。

　というのを積み重ねていくべきだったのですが、計測をきっちりできていなかったため

　ボトルネックの特定ができていないまま思いつく対応をしていく、という進め方に

　なってしまいました。結果仮説がないor正確でない変更を重ねてしまい、どの変更がどれだけの効果があったかも正確に把握できていませんでした。細かい反省はいろいろあるのですが、一番はこれかなと。。

 

他にも自分の開発力の不足、知識の深堀りの甘さなど多くの課題をつきつけられるイベントでしたが、isuconの準備期間、当日は本当に楽しめましたし、参加したよかったと思えるイベントでした！！

 

運営の皆様、すばらしいイベントをありがとうございました！

来年はリベンジしたい！

 

他の参加者のブログはこちら

http://blog.livedoor.jp/techblog/archives/cat_60289063.html