Gooneys Beer Bash #4 に行ってきた！その１
#gunosybeer
場所：株式会社Gunosy
東京都港区六本木6-10-1六本木ヒルズ森タワー37階
時間：19:30～
テーマはモバイルアプリ✕グローバル！
かなり豪華なメンバーのLTが聞けたので何回かに分けてメモ～
まず最初は、
株式会社Gunosy 開発本部 執行役員 松本勇気氏(@y_matsuwitter)
資料は
https://speakerdeck.com/ymatsuwitter/client-side-log-collection-with-aws-mobile-sdk
AWS Mobile SDK で始めるスケーラブルなログ収集
今までならログ収集って言ったら何かのアクションの時にAPI送るとか
Google Analytics とか使ってたけど、
Google高いし、
ユーザ単位の細かい分析が難しい。
さらに細かくすると通信が激しくなってよろしくない。
あと、サーバサイドで計測するにしてもクライアントの操作パターンとか限りないし
計測イベント的にも情報不足。
クライアント側で多くの機能を作れて、サーバサイドの作業が減らせる！
メインで４つの機能があるけど今日は Kinesis 押し！
詳細は資料を見てくだせー
Kinesis とは
サーバ管理不要な大規模データストリームの集計・変換サービス
要するに、
大量なログの受け皿になり
安定したログデータの配送を実現できる
らしい。
Puree とは
Cookpad社製のクライアント向けロゴコレクタ
ログ送信だけでなく、再送信設定やバッファリングなど有用な機能が多い
Puree と Kinesis でログを送る
複数のログをバッファリングし、Kinesiへのバッチリクエストとして一度で送信
頻度によってバッファサイズを変更して
ログの性質に応じてパラメータをチューニングする。
これでより詳細なログを効率よく、かつ、安定的に取得・解析ができる！
あんまりログとか意識しないでアプリ作ってたけど
サービスには絶対必須だよねー
これを機にログ収集のツールとかベストプラクティス的なものを勉強しようかなー
次回はわくわくさんでおなじみ？
株式会社Lang-8 Androidエンジニア 坂口諒氏です。
では。
Realm meetup #14 に行ってきた！その２
場所
Sansa株式会社
東京都渋谷区 神宮前5丁目52−2 青山オーバルビル13F
植物はデリケートだから触らないでねって。
デリケートな植物を社内に飾るってのがすごい！
そして外部LT枠でアキオ氏(@akio0911)。
生で見るとやっぱり派手！
自己紹介でワロタwww
本名www
普通だな！とか心の中で突っ込み。
で、内容は
体重ウォッチというアプリを作る際にRealmを使用した時の話。
計６回くらいリジェクトされたらしい。
さすがに６回とかされると心折れそうやなー
そのアプリは体重を入力したら、あらゆる画面で自分の体重を表示させ
危機感を煽る感じらしい。
AppleWatchの画面やらウィジェットやら。
最近自分が太ってきたから作ったんだって。ウケまする。
そして他人事ではないでござる。
watchOSとHealthKit。
どっちも使ったことないなぁ
watchOSは直接線を描画できないらしくて
imageで自前で作ったらしい・・・
core plotとか使えないのかよ・・・
iPhoneで作ったデータはwatchにsyncしない
watchからの一方通行だって
面倒くさそう
BLEでもっと簡単に同期できたら良いのに。
swiftTask
これちょっと便利そうだから勉強しとく。
そもそもswiftもまだほとんど手をつけてないけど。
HealthKitが使えなくても同様に使えるようにしとかないとリジェクトかー
ならばHealthKit使わなくて良くね？って思ってしまった。
今回の資料
体重ウォッチにおけるRealmとSwiftTaskの活用
https://speakerdeck.com/akio0911/ti-zhong-uotutiniokerurealmtoswifttaskfalsehuo-yong
Realm Java updates April 2016
https://speakerdeck.com/zaki50/realm-java-updates-april-2016
やっぱり実際に開発した時の体験談は面白いなー
ためになるし、あるあるが良い！
そのあとも色んな人と話せたし楽しかった！
これからもっとこういう場に参加してこう！
では。
Realm meetup #14 に行ってきた！その１
前々から気になっていたRealmのmeetupに行ってきた！
場所
Sansa株式会社
東京都渋谷区 神宮前5丁目52−2 青山オーバルビル13F
色んな見た事ない植物が飾ってあった。
しゃれおつですね。
最初は Realm Swift 岸川克己氏(@k_katsumi) 。
iOSではおなじみの方ですね。
いつも参考にさせてもらってます。
(写真ボケとる・・・)
Realm立ち上げ当時は20人ほどで、今は倍の50人くらいになったんだとか。
組織がデカくなっていくのは結構楽しいって。
そりゃそうだよねー絶対楽しいよねー
そんで次のRealmのアップデートの話。
0.99
Fine grained Notification (スペルミスがあったらスミマセン)
Linking Objects Properties
が追加。
主にバグフィックスのアップデートらしいです。
まだ使った事ないからへぇーとしか・・・
でも話を聞くとなんとなくわかってくる。
少しは自分も成長したなーとほのぼの。
昔だったらポカーンだったはず。
近々サンフランシスコに行くって。すげー
俺その日サンフランシスコに行くから無理だわ。とか言ってみてー
話聞いて最初の印象、
この人絶対面白い人。
Javaとか軽く読めるけど書けない的な。
でも話はなんとなーくわかった。
0.88のアップデートでは
issueにあがってたバグをやっつけたって。
非同期APIを同時に実行するとバグってたって。
さらに
PrimaryKeyのnullを許容。ぬるぽがなくなるのか・・・
コペンハーゲンに行ってきたって。すげー
あ、これこの間コペンハーゲンに行ってきたからそのお土産。とか言ってみてー
そして次が一番面白かったかなー
続きはその２で。
では。
田舎者が都内でウロチョロ働く方法
水戸のSI会社勤務です。
しかし、出向ということで約二年前からiOSアプリ開発者として
都内をプロジェクト単位でウロチョロしてます。
弊社でスマートフォンアプリ開発をすることになり、
プロジェクトを立ち上げたものの、
スキル不足で仕事も取れず、
毎日他部署の仕事をする毎日でした。
そこで、スキルアップするためにも都内に行きたい！
と上長に相談したところ、おkが出たのでアポ取りからスタート。
http://www.k-tsushin.jp/sbc100/
に入っている企業に片っ端からメールを送信。
すると二社からその日のうちに返信が。
二社ともアポを取って担当の方に会いに行きーの
仕事先を紹介ししてもらいーの、面接しーの、決まりーの！
あら、あっという間・・・
(何件か面接落ちたけど)
ちょうどその頃はiOSエンジニアが足りなかった頃なので運良く決まりました。
そこからは契約満了と同時に別案件に入れてもらえたりと本当に運良く二年間を過ごしました。
全て仕事を紹介してくれる企業さまのおかげです。感謝です。
上野、浜松町、水道橋・・・
もちろん必要最低限の結果は出しました。
納期を守るとか、ちょっとした提案をするとか、チームメンバーと仲良くするとか・・・
割と(自分で言うけど)悪い評価ではなかった気がする・・・
スキルは底辺だけど、できる人に聞いたりしてなんとか設計通りできたし。
(クソコードばかりですみませんでした)
だから間を空けずに仕事を紹介してもらえたのかも。
都内は楽しす。
何が楽しいって、すげー人がいっぱいいるとこ。
すげー人が身近にいるだけでやる気とか全然違う！
新しいiPhoneが出るたび時間を忘れてあーだこーだ話ができる仲間が沢山いる！
それがすごく嬉しい。
水戸の会社には一人もいなかったから。
都内が楽しいもんだから、
今年の夏に都内で転職しまする。
グッバイ水戸！
スンマセン上長！
今の会社に一緒に働きたい！って思う人がいないので。
どこか拾ってくれるとこはないでしょーかね？
まぁ、自分で探しますが。
結論
・新しいことを始める時は、先行してる会社に頭下げてお仕事を紹介してもらう。
・先行してる会社にはすげー人がいるのでそこで仕事する。
・最低限の結果を出す。
・楽しむ！(仕事も勉強も)
これができれば割とお仕事がもらえます。もらえてます。
参考にもならないと思いますがわたくしの体験談でした。
では。
言語うんぬんではなく単純にプログラミングスキルが乏しい
と最近感じたのです。
嘘。
前から感じてました。
今更だけど少しずつ勉強してこーと思います。
最近結構やる気出てきたので！
勉強会やら、読書やらでちまちま知識、スキルを上げてくぜよ！
とりあえず、4/21にSansanでRealmの勉強会いくぜよ！
それからこの本で基礎的な勉強するぜよ！
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
今年中にはガチ勢の仲間入りしてーなー
では。
property の使い分け方
参考
http://qiita.com/weed/items/2736582eeb404cb2c1e6
実はつい最近まで_propertyをどこでも使ってました。
だってself. ってつけるのめんどいんだもん。
アンダーバー入れたらすぐ候補出て早いんだもん。
でも、ソースレビューしてもらったら
注意されたのでちょっと調べてみた。
ちなみに他人にソースレビューしてもらうのここで初めて。
超我流でやってたので浅はかだし、いわゆるクソコードばかりだったわ・・・
抽象化とかもここ来て初めて意識したわ・・・お恥ずかしい・・・
(参考引用)
基本的に、
getter/setter/init/deallocメソッドの中でだけ_propertyを使い、
それ以外のときはすべて、self.propertyを使う
のが良いでしょう。
マジで？
なんで？
(参考引用)
getter/setter の呼び出しコストは微々たるものですので、コストと副作用を考えて _property と self.property を使い分けるより、一律で self.property を使った方が楽です。
_propertyは、値を直接割り当てたり取得することしかできません。
これに対し、self.propertyは[self property]を呼ぶことと同じです。このやり方だと、独自のgetterやsetterをつくることができます。
ほへ～～
(参考引用)
独自の getter/setter を作ることで、あるプロパティを読み書きする際に必要な追加の操作を強制できます。
たとえばあるプロパティに値をセットするとき何かのカウンタを必ずインクリメントしなければならないなら、
呼び出し側でカウンタを操作するのではなく独自の setter の中で操作する、ということができます。
object.propertyを呼ぶことは、本質的には[object property]を呼ぶことです。このメソッドをいじることで、独自のgetterやsetterメソッドを使うことができます。
さらに、self.property形式を使うと、単純に変数の値をsetしたりgetしたりすること以外にも良い点があります。
それは、@property宣言の中で適用させた属性（weakやstrongなど）に基づいて@synthesizeが自動的にメモリ・カウンタの増減の有無などを処理してくれることです。
「細かいことは、おまかせ」できるわけです。
なんか色々理由はあるけど、
まとめ！
setter / getter / init / dealloc メソッド以外は
self.property を使え！
こういったベストプラクティスを学ぶのも大切だなーと思いましたとさ。
では。
「チームラボ、スマホアプリチームの面白い仕事のつくり方」に行ってきた！
teamLab Meet-up #5「チームラボ、スマホアプリチームの面白い仕事のつくり方」 - connpass
結構時間たっちゃった・・・
行ってきた！と言っても、現在チームラボのプロジェクトに参画中なので
こっそり忍び込んできた！
LTは、チームラボで最も(個人的に)有名な「秩序がなくともピースは成り立つ」の開発者の坂下渉氏。
面白い仕事のつくり方ということで、
無印良品のプロジェクトを例に発表してました。
http://www.slideshare.net/watarusakashita/ss-60203751
自分の興味のある新しい技術と
お客さんの目的達成を同時にできるような提案を作ったんだとか・・・
この発表はとっても真面目。
チームラボと言ったら猪子さんの飛び抜けた発言がイメージにあったけど、
エンジニアはとっても真面目。
以前のLT時にテクノロジー関係をめっちゃしゃべったら
エンジニアあんまりいなくて滑ってたらしいので
今回は警戒して無難な感じにしたらしい(関係者談)。
やっぱり技術力がある人からの提案って説得力あるよね！
しかも結果も出しちゃうしー
俺も面白い仕事が作れるように精進しないと！
では。
