コーディング規約とかガイドとかって難しいよねという話

注：細かくてどうでもいい話です

Cookpadの規約スタイルガイドについての話
https://github.com/cookpad/styleguide

[SHOULD] ハッシュのキーを Symbol にして良い場合は、文字列よりも高速に lookup できるので積極的に Symbol を使うこと。

ここの箇所、言いたいことは分かるんですがちょっと誤解を招くなと思った
具体的には

  • 「可読性と一貫性」*1を目的にしているならパフォーマンスの話をするのはおかしい
  • ハッシュのlookup速度が問題になるケースはかなり少ないので、一般的な状況ではキーをSymbolにすることにパフォーマンス上の優位点はない
  • SymbolはGCされないので新しいSymbolがガンガン作られる状況(ex. ユーザからの入力を.to_symする, 巨大な文字列の集合を.to_symしたものでハッシュをつくるなど)ではメモリリーク*2が発生する。

という問題があると感じた。

で、r7kamuraさんに聞いてみたところ
いくつか勘違いしていたことに気づいた

  • ガイドなので規約ではなく必ず守らなければならないものではないらしい*3
  • ずっとリテラルの話をしていてのこの節なのでインスタンスではなくリテラルの話だとわかるはず（つまり空気読めていなかった）

こうしたらいいんじゃないかなという解決策

↑のようなことを丁寧に書くとクソ長くなってしまうのでもっと率直な理由にすればいいのでは

[SHOULD] ハッシュのキーを Symbol にして良い場合は、タイプしやすいしかっこいいので積極的に Symbol を使うこと。

*1:https://github.com/cookpad/styleguide/blob/master/ruby.ja.md#%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB

*2:これを厳密な意味でのメモリリークというかは知りません

*3:じゃあmustとか書かないほうがいいのでは

Conference With Developers 2 を開催します

iOS

2月1日にConference With Developers 2というイベントを開催します。


昨年に引き続き今回は、

という、iOS界で今をときめく/不動の大御所な皆様にお話しいただきます。


LTも募集中ですのでぜひご参加ください


http://confwd2.peatix.com

そして老害になる

闇 Advent Calendar 2013の7日目として老害化の話をします。



ベンチャーじゃなく大企業につとめてよかったことは、さまざまな技術バックグラウンドを持つ人と仕事ができていることだ。


色々な流儀や文化の人たちと接し、ぶつかることで自分の視野がどんどん広がっていくのを感じている。


昔話をすると、学生時代、自分は主にRubyを書いていてJavaやPHPをダサいものだと考え、時にはそれを口にすることもあった。
しかしdisるための根拠などをしっかりと持っていたわけではなく、なんとなくで
最新技術=かっこいい、べんり
古い技術=ださい、めんどくさい
と考えていた


社会人になってからダサいと思っていたまともなPHPの書き方を知りそれはそれで悪くない、むしろRubyよりすぐれだところもたくさんある素晴らしい道具と知った。


逆にcoolだと思っていたnode.jsやCoffeeScriptに手を焼き、PhoneGapのような技術で作られたプロダクトに苦しめられもした。
それらをiOSネイティブに書き換えていく作業をするなかで見た目だけで敬遠していたObjective-Cの思想が大好きになったりもした。


DB設計の正しいやり方を身につけ、それまでに自分がActiveRecordのmigrationで適当につくったものがいかにひどいものだったかも知った。


経験を積めば積むほど、今まで自分がバカにしていたものがいかに優れているかがわかるようになったし、逆に今まで無条件で最高だと考えていた技術の欠点も見えてきて、新しい技術が単に新しくてcoolそうだというだけで飛びついたりすることは減ってきた。


エンジニアは気付けば新しくて楽そうなものに流れる傾向がある。
しかし、最高のまともなエンジニアになるためには新しいもの、古いもの、有名なもの、無名なものをイーブンに評価できるようになるべきでなのではないだろうか。


そう考えもあり、最近はC++をずっと勉強していて楽しい。Javaも深く知りたい。他にも知りたいことがたくさんある。


しかし、そういうことをやっているとどんどん周囲と考えが離れていくのを感じる。技術の話をしても噛み合わないことが増えてきているような気がする。


Rubyやnode.jsかじったやつが使ったこともないのにPHPやJavaを叩いてるのを見るとぶん殴りたくなる。
RDBの大した知識もないのに「MySQLはめんどうそうなので、MongoDBを使おう」などと提案されると軽蔑してしまうしそいつとは仕事したくない。


このままいくと将来こんなことを言ってしまうかもしれない
「プロダクションでnode.js使うの？いいけど何か問題が起きたとき対応できるの？nodeのソースコードすら追えないじゃ困るじゃん。C++も読めないのに偉そうなこと言うなよ」


そして老害になる

iOSの隠しフォント,ヒラギノ角ゴW1を使ったアプリが審査通った件

iOS

Animetick for iOS 1.2が審査に通り、リリースされました
このアプリでは隠しフォントっぽいヒラギノ角ゴW1を使用しています。


.HiraKakuInterface-W1, .HiraKakuInterface-W2というフォントは
iOSの標準API(UIFont#fontNamesForFamilyName:)では取得できないため
Private APIにあたり、Appleの審査で落とされる可能性が指摘されていました

ソースコード

https://github.com/yayugu/animetick-ios/blob/v1.2/Animetick/Views/ATTicketCell.m#L23

参考

iOS 7 の隠しフォント， ヒラギノ角ゴ W1/W2 を CSS で指定する
iOS7のフォントについて

注意

私がセーフだったからと言ってあなたのアプリもセーフとなる保証は全くない

意識高いiOSアプリのつくり方

Objective-C iOS

基本編

1. Objective-Cで書く

Obj-C使いたくないが諦める

結局Obj-C使うのが一番楽であることに気づくのだ

2. Xcodeを使う

VimとかEmacsとかAppCodeで書きたいが諦める

結局Xcode使うのが一番楽であることに気づくのだ

設計編

3. 仕様とUIをしっかり設計してから実装する

きちんと設計しないとあとから大量の手戻りが発生して泣きたくなる。

  • 技術的に可能なことをやろうとしているのか
  • 基本的な画面設計
    • メインのビュー部分
    • ナビゲーション方法（TabBarなのかNavigationBarなのかNavigationDrawerなのか）

くらいは最低限調査・設計しておく

4. フレームワーク的ライブラリを使わない
  • UIKitは既に十分にフレームワークになっており、新たな思想を持ち込む必要はない
  • Reactive Cocoaを使うのはUIKitのMVCをよくよく理解してからでも遅くない
  • BlocksKitはbad parts. 古典的delegateを使用したほうが見通しもメモリ管理も良くなるケースのほうが多い
5. なるべくWebViewは使わないようにする
  • デバッグが難しくなる
  • Obj-Cとのブリッジ部分がバグの温床になりやすい
  • 使う場合はデータのやりとりは最小限に

クラス設計編

6. ViewControllerには最低限の責任しか持たせない。ModelとカスタムViewを積極的につくる

こんなViewControllerはクソの山だ!

  • 1000行超えてる
  • JSONをパースしている
  • JSONをパースしただけの生dictionaryを直接読み取り・操作している
  • subViewの見た目（colorとかframeとか）を操作している
  • 別のviewControllerと密結合してdisappearなときにも仕事をしている

続き：あとでかく

引っ越した #tqhouse

卓球ハウスというシェアハウスを作って引越しました。


最近引きこもりが加速して外出するのもダルくなりました。


家でイベントを開けば外出しなくてもいいことに気づいたのでイベントできるようにリビングが広めの一軒家を借りました。


さっそく、今週末は「ミルキィハッカソン」をやります。


ミルキィホームズを見ながらハックするナイスイベントになる予定です。


こういうひどいイベントどんどんやって行きたい