ねえぶ

猫好きエンジニアのブログ

先月読んだ本と今月の読書予定(2017年11月)

ブログを引っ越ししましたので,5秒後に移動します

先月の読書予定

先月の読書実績

今月の読書予定

はてブ アプリで自分のブックマークを表示する方法

ブログを引っ越ししましたので,5秒後に移動します

今年からはてなブックマークを使ってみているので,iOSアプリ版をインストールしてみました. てっきりインストールしたらすぐに自分のブックマークが見れるものと思っていましたが,「人気エントリー」とか「注目テーマ」とか共通に見られるエントリが初期表示になっていました. 自分のブックマークを表示させようと思ってもなかなかやり方がわからなかったので,メモしておきます.

自分のブックマークの表示方法

  • まずホーム画面の右下にあるコンパスアイコンをタップします

f:id:ottijp:20171029013255p:plain

f:id:ottijp:20171029013307p:plain

  • 「使ってみる」をタップします

f:id:ottijp:20171029013316p:plain

  • ログイン画面になるので,はてなアカウントでログインします

f:id:ottijp:20171029013342p:plain

  • 自分のブックマークが表示されました!

f:id:ottijp:20171029013357p:plain

ホーム画面のハンバーガーメニューを触ってみたりしてもログインのメニューがなく,コンパスアイコンは現在地周辺に関するブックマークなのかな?と思ってタップしなかったので,なかなか自分のブックマークにたどりつけませんでしたが,なんとか上記の方法で見ることができました📖😆

raywenderlich.com 公式Swiftスタイルガイドを読みました

ブログを引っ越ししましたので,5秒後に移動します

Swiftのスタイルガイドとしてよく挙げられるraywenderich.comの公式スタイルガイドを読んで,参考になったところを翻訳してみました.

raywenderlich/swift-style-guide

このスタイルガイドはMITライセンスです.

Copyright (c) 2016-2017 Razeware LLC
https://github.com/raywenderlich/swift-style-guide/blob/master/LICENSE.txt

Use classes for things that do have an identity or a specific life cycle. You would model a person as a class because two person objects are two different things. Just because two people have the same name and birthdate, doesn't mean they are the same person. But the person's birthdate would be a struct because a date of 3 March 1950 is the same as any other date object for 3 March 1950. The date itself doesn't have an identity.

同一性や特定のライフサイクルを持つものについてはクラスを使ってください.例えば2人の人間は2つの異なったものなので,人間はクラスとしてモデル化します.もし2人が同じ名前と生年月日だとしても,2人が同じ人間というわけではないからです.それとは異なり,1950年3月3日という日は他の1950年3月3日という日と同じオブジェクトであると言えるので,構造体としてモデルするのがよいでしょう.

For conciseness, avoid using self since Swift does not require it to access an object's properties or invoke its methods. Use self only when required by the compiler (in @escaping closures, or in initializers to disambiguate properties from arguments). In other words, if it compiles without self then omit it.

簡潔な表現のために,selfを使うのは避けましょう.Swiftはオブジェクトのプロパティやメソッドの呼び出しのためにselfを必要としません. コンパイラエラーが発生する場合のみselfを使うようにしましょう(@escapingクロージャやイニシャライザにおいて,引数とプロパティが曖昧な場合にそうなります.)言い方を変えると,selfを付けず にコンパイラエラーが出なければ,selfを省略してください.

Unused (dead) code, including Xcode template code and placeholder comments should be removed. An exception is when your tutorial or book instructs the user to use the commented code.

Xcodeが生成するテンプレートコードやプレースホルダコメントを含む使用していない(不要な)コードは削除してください.チュートリアルや本においてユーザにコメントアウトされたコードを使わせる場合は除きます.

For functions with long signatures, add line breaks at appropriate points and add an extra indent on subsequent lines:

func reticulateSplines(spline: [Double], adjustmentFactor: Double,
    translateConstant: Int, comment: String) -> Bool {
  // reticulate code goes here
}

長いシグネチャの関数は適切な長さで改行し,後続の行は余分にインデントを追加してください.

Use trailing closure syntax only if there's a single closure expression parameter at the end of the argument list. Give the closure parameters descriptive names.

引数の最後に1つだけクロージャパラメータがある場合のみ,パラメータ名を省略してください.それ以外の場合はパラメータ名を記述するようにしてください.

Note: The advantage of using a case-less enumeration is that it can't accidentally be instantiated and works as a pure namespace.

注意: case無しの列挙型は間違ってインスタンス化される心配がないため,純粋なネームスペースとして働きます.

このスタイルガイド,こちらで日本語翻訳されている方がいるんですが,Swift3版へのアップデートに追随していないみたいなので,翻訳してみようかな・・・.

GitHubのスタイルガイドなど,他のものも読んでみようと思います.

MacBookProを買いました

ブログを引っ越ししましたので,5秒後に移動します

家ではMacMini(Mid 2011)を使っていて,外で使う用にMacBookAir(Mid 2011)を使っています. ですが,MacBookAirがもうSierraすら入らずXcodeも動作しないので,MacBookProを発注しちゃいました. 今見たらMacBookAirのメモリはなんと2GBだった・・・.少なかったんだなあ.

MacBookProのモデルをどれにしようか迷ったんですが,以下のようなことを考えて13インチの一番安いモデルを買うことにしました.

ユースケース

  • 勉強会やセミナーに出かけた時のメモ取りや検索
  • ちょっとした開発もくもく会とかハッカソンXcodeを使った開発
  • (がっつりした開発や,重い処理は家のMacMiniでやることがほとんどなので,MacBookには要求しないように割り切りました)

主に動かす予定のアプリケーション

スペック

  • 画面サイズ
    • 13インチ
    • 15インチは持ち運びづらいし,パームレスト部が大きすぎて非常に使いづらいので,迷うことなく13インチを選択
  • CPU
    • 第7世代Core i5 2.3GHz(デフォルト)
    • 正直足りるかどうかわからなかったけど,MacMiniCore i5 2.5GHzでXcodeのビルドにそれほど不満が無かったからそのまま
  • メモリ
    • 8GB(デフォルト)
    • 16GBにしようかとおもったけど,これもMacMini(16GB載せている)である程度アプリケーションを動作させていてもApp Memoryは8GBくらいだったら,そのまま
  • ストレージ
    • 128GB(デフォルト)
    • 一番容量を食う写真・音楽・iPhoneバックアップ・VMのデータは入れない予定なので,そのまま
  • キーボード
    • USキー(カスタマイズ)
    • 数ヶ月前に使う環境すべてをUSキーに切り替えたので,これは譲れないポイントでカスタマイズ!

スペックは高ければ高いほどいいけど,ユースケースを考慮してほどほどに抑えようと思ってこのような構成にしました.

カスタマイズしたので出荷まで1〜3日かかるようです. 楽しみ!

iOSDC 2017 Reject Conference day2 に参加しました

ブログを引っ越ししましたので,5秒後に移動します

今年のiOSDC2017に初めて参加してとても勉強になったので,ぜひReject Conferenceも参加しようと思ってたんですが,気づいたらすでにday1は終わっており・・・.

day2に申し込みするも補欠扱いだったので「もうダメかな・・・」なんて思ってた折,当日に繰り上げで参加できるようになったので行ってきました.

サイコーでした!

iOSDC 2017 Reject Conference days2 - connpass

日時

2017/10/20(Fri) 19:20-22:00

場所

セッション

19:20-19:30 カンファレンス・会場説明

  • LODGEとYahooの説明
  • YahooはEC・メディア・FinTechを中心としたデータ収集・解析・サービス展開のサイクルを「マルチビッグデータ」として定義して強みとしてるらしい
  • Yahooの職場はフリーアドレス(うらやましい)

19:30-19:35 SwiftとReactNativeで同じようなUIを作ってみた際の記録 @fumiyasacさん

  • 5分というすごい短い時間でReactNativeとネイティブ実装の比較を説明
  • 懇親会で少しお話できた
    • iBeaconなどの部分はCordovaとか使うのかと思ってたけど,ReactNative+ライブラリ(npm)で可能らしい(ちょっとよくわかってない)
    • ReactNativeはiOS/Androidそれぞれのプロジェクトファイルを生み出す感じ
    • iOS/Androidにそれぞれに依存する部分は共通部分とは別にコーディングできる

19:35-20:05 CodableでAPI通信を再発明 @yutailang0119 さん

  • 標準APIの一部を再実装して何やってるのか理解しようという話(自分には少し難しかった)
  • About the URL Loading Systemが参考になる
  • まだSwift4使ったこと無かったので,CodableがあればSwifyJSON要らないのか?とかがわからなかったけど,懇親会で話した人に教えてもらって少し理解できた
    • モデルを定義してその型に落とすので,ケースによりSwiftyJSONの代わりになる
    • さらにバリデーションも兼ねる
  • 本題と関係ないが,コールバックのクロージャでswitchでerror判定するコードを初めて見て,こんなやり方があるのか!と思った
    • ↓のような感じ
session.download { (data, error) in
  switch (data , error) {
    case (_ , let error?):
      print(error)
    case (data?, _):
      print(data)
  }
}
  • いつもguard letでerrorを判断するような書き方をしていたので,どっちが良いのだろう?と思った

20:05-20:15 休憩

  • Yahooはトイレもきれい

20:15-20:30 API を Firebase Realtime Database に移行する @Shinya Yamaokaさん

  • Firebase Realtime Database (RTDB)のデータをクライアント側でデータ結合する際はRxSwiftのzipが便利
  • RTDBのオススメ・・・のはずが,10月に発表された新しいFireStoreのオススメに・・・
  • RTDBでできなかった外部キー制約的なことやソートはFireStoreでは解消している
  • いま担当しているサービスでFirebaseを使っているので,困っていることとかを懇親会で相談してみた
    • RTDBは検索システムに使える?レンジ効かせられるのは1つのキーだけだし・・・
      • Flashlightというサービスがある
      • RTDBへのデータ操作をElasticSearchに入れてデータを引っ張れるようになる
    • RTDBの構造変更とアプリのバージョンの整合性をどう取るべきか?
      • アプリの方は強制できないので,RTDBの方に下位互換性を保つ構成を取るしかない
    • adminだけアクセスできるとか,グループによるパーミションとか,RTDBに書いたACL定義をFirebaseStorageのセキュリティにも適用できるか?
      • ちょっとこれは答え出ず
  • FireStoreも使ってみたくなった

20:30-21:00 モダンなイニシャライザ @loveeさん

  • イニシャライズの後でプロパティ設定しまくりパターンをなんとかする
  • イニシャライザとセッターをメソッドチェーンにしてクロージャで設定する
  • イニシャライズ時以外にセッターがメソッドチェーンにならないようにイニシャライザ用のタイプを作る
  • さらにそれをテンプレート化したり,フレームワーク化したりする
  • static func `init`()でイニシャライザをオーバーロードするハックが面白かった
  • あと,フレームワークはプロジェクトの参照を置くだけな感じで使えるので,共通コードをフレームワーク化すれば共有できることを知った(いまやってるプロジェクトでは,むりやり1つのプロジェクトの中に共通コードと依存元コードを同居させてしまっていた・・・)
  • プレゼンテーションの動的なアニメーションがかっこよかったので,どんなプレゼンテーションツールを使っているのか懇親会で聞いてみたところ,普通にKeynoteの機能らしい!
    • コード例などは画像化しているのではなく,テキストをKeynoteに貼る
    • トランジション時に座標の変化などであれば自動的にアニメーションされる
    • 今度使ってみようと思った!

21:00-22:00 懇親会・雑感

  • 勉強会とかカンファレンスとかの懇親会に出るのは実は苦手で,iOSDC2017でも懇親会には出ずにそそくさと帰ってしまっていた(恥ずかしい)のだけど,やっぱり社外のエンジニアの人たちと話したいし,今回は気合い入れて出てみた
  • なんとか1人くらいと話せたら御の字かなと思ってたけど,7,8人と話せたうえに,2人とは名刺交換もさせてもらって,すごく有意義だった!
  • iOSに関することだけじゃなくて,ゲームの話とかイヤホンの話とか,普通にコミュニケーションできたのがとても嬉しかった
  • 当たり前だけど登壇者の人もスーパーマンじゃなくて緊張もしてるんだなと気づいたタイミングがあって,すごく安心できた
  • いまいまは技量が足りない気がするけど,登壇する側に立てればもっと自分のスキルが上がりそう
  • 懇親会に入る前(カンファレンス初め)から乾杯の音頭を取ってくれて,お酒飲めたのは良かったと思う(懇親会の導入がスムーズだった)
  • 寿司美味かった🍣
  • パックマンルール(他の人が入りやすいように円にならず一部分空けておく)良い!

Hello world.

ブログを引っ越ししましたので,5秒後に移動します

はてぶのアカウントを作成しました.