kurotyannの覚え書き

iOSのこととか、たまにRailsとか。

TwitterKitのサポートが10月末に終了するのでSwifterに乗り換えた話

これはなに

  • 2018年10月31日をもってTwitterKitのサポートが終了する
  • TwitterKitからの移行先をSwifterにした
  • Swifterへの移行方法と、移行以外でハマったこともあったので書いた

TwitterKitのサポートが終了

blog.twitter.com

とても残念ですが2018年10月31日をもって、GitHub上でiOSAndroidとUnityを対象にした本オープンソースに関する質問や問題を受け付けることを終了します。

移行先をSwifterにした理由

  • Swift製でcocoapodsとcarthageに対応してた
  • Twitter認証とつぶやきの投稿のみを実現したくSwifterはそれが可能だった

github.com

ちなみに、Twitterの公式ページにはTwitter関係のOSSの一覧があり、Swifterはそこで紹介されている

ざっくりとしたSwifterへの移行対応

  • 認証処理とつぶやきの投稿をするクラスをGistにおいた
  • 必要ないかもしれないが、Objective-C からも使えるようにした

SwifterWrapper.swift · GitHub

認証処理

// AppDelegate の didFinishLaunchingWithOptions で処理すると思う
SwifterWrapper.share.setup(consumerKey: key, consumerSecret: secret)
func authorize(controller: UIViewControlller) {
    /*
      controller が SFSafariViewControllerDelegate に準拠していると
      Twitterのログイン画面がSFSafariViewControllerで表示される
     */ 
    share.login(controller: controller, success: { (userID, screenName, token, tokenSecret) in
        // 認証成功
    }, failure: { (error) in
        // 認証失敗
    })
}
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
    return SwifterWrapper.handleOpen(url: url)
}

つぶやき投稿

// mediaはつぶやきの添付画像とか
SwifterWrapper.share.postTweet(status: text, media: media)

Swifterへの移行以外でハマりそうなところ

  • callback URLsが6月ごろのGDPR対応でホワイトリスト方式になっており、管理画面のcallback URLsと完全に同じURLでないと正常に動作しない
  • Twitterの公式ページにも説明がある
  • Twitterの公式ページを要約すると、callback URLsには下記のURLを入力するように推奨されている
    • Android twittersdk://
    • iOS twitterkit-CONSUMERKEY://
  • iOSの場合、URLSchemeで帰って来たとき、なぜかCONSUMERKEYが全て小文字になっているので不思議(理由を知っている人が入れば教えてください 🙇‍♂️ )

まとめ

  • TwitterKitからの移行先をSwifterにした
  • Twitterは今後どう発展していきたいのだろうかと少し考えたりもした
  • 直接関係はないけど、Tweetbotのテーマの切り替えが素晴らしい
    • おそらくすべての画面で2本指の上下スワイプでテーマを切り替えられる

iOSDC2018で「iOSでグラフを描くために必要な知識について」というタイトルで発表しました

これはなに

  • iOSDC2018という大規模カンファレンスで15分ほど発表した
  • 想像していた以上に人が来てくれたし、Q&Aで質問もあって嬉しかった
  • iOSDCは学びが多くて素晴らしいカンファレンスでした

目次

書くことが多いので目次をつくった

  • ① iOSDCについて
    • 手に入れたもの
    • iOSDCの感想
  • ② 発表について
    • 発表の資料
    • 発表の補足
    • 発表の感想
  • ③ まとめ

① iOSDCについて

手に入れたもの

 ありすぎて全部写真にとるのは大変なので一部だけ写真にとった。他にもパーカー、マフラータオル、サコッシュとかいろいろある。

f:id:kurotyann:20180902221319j:plain

iOSDCの感想

 素晴らしいカンファレンスでした。3.5日間の長丁場を高いクオリティで運営してくれたスタッフには本当に感謝しかない。大きな会場、WiFi環境、電源、空調、飲食類など私にとっては十分以上のクオリティだった。明日は月曜日だけど、スタッフの体調が心配だ。可能なら仕事せずに休んでほしい。

 具体的にどんな3.5日間だったのかは、#iosdc でツイートを遡ればいいし、Youtubeのチャンネルでオープニングや会場説明が見えるので雰囲気はこれでつかめると思う。また後から発表の動画も去年と同様にアップされると思う。

 

② 発表について

発表の資料

発表の補足

 Q&Aで「グラフを描くのに必要な数学の知識を体系的に学ぶにはどうすればいいか?」という質問がきて、「数学を全体的に学ぶのではなく、自分の描きたいグラフを決めて、それに数学の法則がどのように用いられてるかをググっていく」的なことを答えた。そして、「今回のスライドを作成するのに参考にした資料をあとでブログにまとめて公開する」とも答えたので参考資料を以下にまとめる。

 たくさん参考資料はあるが、やっぱりまずはAppleのドキュメントを見るのが良いと思う。最近更新されてないドキュメントもあるけど、内容は今でも全然通用するので問題ない。あとは、raywenderlich.com のチュートリアルがとても完成度が高いのでおすすめです。

 あとは、私のサンプルプロジェクトをデバックしてどういうとき座標が変わっていくのか確認すると良いです。今回、結構頑張ってつくったので参考にしてくれると嬉しいです。

www.raywenderlich.com

発表の感想

 自分の発表日は最終日だったので、初日から発表当日まで本当に長くてしんどかった。どんどん優秀な人たちが素晴らしい発表してて、それを聞いているとどんどん不安になっていく。まあ、もう発表するしかないんだから、やるしかないなーと思っていざ登壇すると、想像以上に人がいたのでびっくりした。自分と同じ時間にLLDB、モナド、WebRTCなどの興味深い発表があるのにも関わらず、聞きにくれた人たちには感謝しかない。本当にありがとうございました。

 これで「iOSDCで発表する」という今年の大きな目標の一つを達成した!!参加賞はゲットしたので、次はちゃんと何かしらの賞が取れるようにたくさんのことを学んで成果を出していきたい。そして、会社の名前を間違えてツイートされないように弊社を有名にしたい。

③ まとめ

  • iOSDCで発表するという今年の目標を達成した
  • 来年のiOSDCでも発表できるように頑張る
  • スタッフ、スピーカー、参加者の皆さんお疲れ様でした

iOSDC2018の登壇練習会に参加した at Timers inc.

これはなに

  • iOSDC2018の登壇練習会に行ってきた
  • 練習会の終了時間を30分オーバーするぐらいの盛況だった
  • 参加者の発表資料がレベルアップしたはずだ

練習会の会場

  • Timers inc さんがオフィスを提供してくれたありがたい。
  • 恵比寿駅からまっすぐ歩いて5分以内でつく高立地オフィスでした。

mokumoku-ebisu.connpass.com

練習会はどうだったか

 一言でいうと、とても充実した練習会だった。

 参加者全員が2018の登壇者で、レギュラートーク(15 / 30分)とLTもいるので発表時間も網羅されてた。2017に登壇経験をもつ人もいたし、iOSDCスタッフもいたので、当日の情報も色々聞けてよかった。

 全員が本当に熱心にレビューしていた。内容は当日のお楽しみなので伏せるが、ある人の発表が別の人の発表と関係していたりするので、良質なレビューを生みやすい状況になっていた。そのおかげで休憩時間をスキップしても終了時間を30分オーバーするという状態になった。今日、参加した人の発表資料は数段レベルアップした形で当日を迎えること間違いない。

 俺の場合、現在の会社にiOSエンジニアが俺一人しかいないので、iOS関連の知識をレビューしてくれる人がいなかった。なので、今回の練習会はとても助かった。

発表資料の進捗

 ちょうど一ヶ月ほど前に発表資料の作成計画をブログで書いた。

iOSDC 2018のタイムテーブルが決まったので資料作成の計画をたてる - kurotyannの覚え書き

 バッチリ予定どおりには進まなかった。それもそのはず、途中でB'zの30周年ツアーライブと阿波踊りがあったのだ。計画どおりに進むはずがない。 徳島出身のB'zファンには過酷スケジュールだった。

 結局、発表できる状態で完成したのは8/23(木)だった。なので、8/24(金) の定時後に社内のエンジニアに協力してもらって、皆の前で発表してレビューもしてもらった。社内のエンジニアの皆さんありがとう!!発表資料は無事に完成を迎えられそうなので大きく心配することはもうない。

 あとは、「発表時間の15分におさまらない内容をブログに書いて予約投稿する」というTODOが残っている。これはまだ白紙状態でまとめるのに時間がかかりそうで発表当日までに予約投稿できるかどうか怪しい。とりあえず、発表できる状態までは来たので精神は安定してた。

練習会に参加した人のスケジュール

8/30

8/31

9/1

9/2

まとめ

  • Timersのオフィスで登壇練習会を行った
  • 充実した登壇練習会で参加した登壇者の資料はレベルアップしたはず
  • 発表資料はほぼできたので当日皆さん聞きに来てください

iOSDC 2018のタイムテーブルが決まったので資料作成の計画をたてる

これはなに

  • iOSDC 2018のタイムテーブルが公開された
  • 自分のLT15分は最終日の9/2 Track A 15:10~15:30
  • 今から緊張で吐きそうだけど、9/2までにどのように発表準備していくか書き残しておく
  • タイムテーブル | iOSDC Japan 2018 - fortee.jp

発表内容

資料の作成から発表までフェーズにわける

  • ぶっつけ本番ありえない
  • プログラミングと同じでデバックやテストが必要
  • 作成から発表まで何時までに何をやるか決める
  • 弊社はiOSエンジニアが自分しかいないのでレビューが少し心配

草稿スライド ver1

  • 締切:8/2(木)
  • 目次と具体的に何を話すのか理解できるところまで書く
  • 発表時間の15分はこのフェーズではとりあえず無視する

第一回 社内レビュー

  • 日程:8/3(金)
  • 弊社では隔週でエンジニアの定例ミーティングがある
  • そこで草稿スライドをレビューしてもらう

草稿スライド ver2

  • 締切:8/16(木)
  • 成稿スライドに近い状態まで完成させる
  • 発表時間の15分で終わるように意識する
  • 発表時間の15分に終わらない場合、9/2以降にブログにすることを検討する

第二回 社内レビュー

  • 日程:8/17(金)
  • 発表の予行演習
  • 発表時間の15分を計測してもらう

成稿スライド

  • 締切:8/28(火)
  • 第二回 社内レビュー結果を取り込んで完成までもっていく
  • 発表時間の15分におさまらない内容をブログに書いて予約投稿しとく

第三回 社内レビュー

  • 日程:8/29(水)
  • 発表の予行演習
  • 発表時間の15分を計測してもらう

iOSDC 開催期間中

  • 発表を見て「ああ、こう書くべきだったか!」みたいな発見がありそう
  • 発表本番までに直せるところを直してく

本番

  • 💪

まとめ

  • 本業を疎かにせず、計画どおりに進められるように努力する
  • 9/2に良い発表だったと一人でも多くの人に思われるものにする

会社で1QのMVP賞もらった

これはなに

  • 弊社は四半期制で4月始まりなので6月末で1Qが終了する
  • クオーターごとにMVPが表彰される
  • MVPには賞与がある
  • 今回は自分が選ばれた

評価について

採用活動への貢献

他の会社と同様に弊社も採用活動に全力で取り組んでる。しかし、正社員を採用するコストがとても高い。 良い人に出会えるか、出会えたとしても相手がOKしてくれるかどうか、結果に結びつくまでに多くの時間と労力がかかる。

なので、副業で手伝ってくれる人を募集できる採用体制を正社員とは別に整えた。 これは今年から自分が副業をしており、他の会社で働く上で必要な制度や情報を身をもって経験したので弊社にも導入しやすかった。 ココらへんの具体的な取り組みは近々、弊社のTech Blogで書くつもり。

結果的に、数名のエンジニアを副業で採用できて問題なく働いてもらっている。 欲を言うと、そこから正社員として弊社のメンバーになってくれると嬉しい。

iOSの開発を1人で支えた

現在、iOSの開発は私と副業の方の2人でやっている。副業の方を採用するまでは自分ひとりで開発していた。 自分ひとりになったのは2-3ヶ月前に上司が退職してからで、それまでは私と上司の2人体制だった。

自分ひとりになってやることは一気に増えた。特にプログラミング以外の作業の増加が大きかった。 採用面接、プロジェクトのMTG、副業の受け入れ体制など細々したMTGが入り、集中してコードを書く時間が短くなった。

最初は四苦八苦してたものの、現状を打開するためには必要な苦労だと思い、今はもう慣れている。 集中してコードを書く時間も、早めに起床して自宅でコードを書くなどライフサイクルも変えていった。

あとはslackのremind機能をものすごく使うようになった。もうslackのremindなしでは日々の業務は回らなくなっている。

まとめ

  • 弊社に勤務して2年8ヶ月たち、初めてMVPをもらえたので嬉しい
  • 今年から始めた副業の経験が弊社でも良い形で役に立ったのが嬉しい
  • 現状に満足せず、今後も成果だしてく!

CircleCI 2.0のMacOS BuildsでTimezoneを変更する方法

これはなに

Timezoneを変更する方法

  • macosのtimezone設定は、environmentのTZでは有効にならないので注意
  • これを知らずにいろいろ試して3時間ぐらい時間を無駄にした 😭

support.circleci.com

まとめ

  • macosのtimezone設定方法は、 sudo systemsetup -settimezone "$TIMEZONE" だぞ!

余談

Bitriseはどう?

  • CircleCIのXcodeイメージの更新が遅いけど特に困ってないので気にしてない
  • Bitriseの方がXcodeイメージの更新早いのは知ってるけどまた暇なときに考える

iOSDC2018のプロポーザル

CircleCIとDangerでPull Requestの自動チェックをやってみた

これはなに

Dangerとは

github.com

  • DangerはPull Requestの状態をチェックするツール
  • マイルストーンアサインが未設定のとき、マージ先が特定のブランチに向いてないとき、コメントで警告したりPRを失敗させたりできる

Dangerのインストール

  • DangerはRuby製でGemからインストールできる
  • Dangerには複数のプラグインがあり、今回はSwiftLintをDangerで実行させる danger-swiftlint を導入した
gem "fastlane", "2.94.0"
gem "danger", "5.5.13"
gem "danger-swiftlint", "0.16.0"

Dangerの初期化

  • bundle exec danger init するとDangerfileができる
  • DangerfileにはPull Requestでチェックして欲しい状態や条件を記述する
  • 俺はブランチのチェックは警告にしたが、失敗にすると安心で安全な開発環境をつくれると思う
# RPの差分範囲外に対する指摘はすべて無視
github.dismiss_out_of_range_messages

# --------------------
# swiftlint
# --------------------
swiftlint.config_file = '.swiftlint.yml'
swiftlint.lint_files inline_mode: true

# --------------------
# pr title
# --------------------
warn('このPRは作業中です') if github.pr_title.include?("WIP") || github.pr_title.include?("wip")

# --------------------
# base branch
# --------------------
is_to_master = github.branch_for_base == 'master'
is_to_release = github.branch_for_base.include?("release")
is_from_release = github.branch_for_head.include?("release")
is_from_development = github.branch_for_head.include?("dev") || github.branch_for_head.include?("development")

warn('master へマージできるのは release branch のみ(緊急時はOK)') if is_to_master && !is_from_release
warn('release へマージできるのは dev branch のみ(緊急時はOK)') if is_to_release && !is_from_development

# --------------------
# milestone
# --------------------
warn('このPRにマイルストーンを設定してください') if github.pr_json["milestone"].nil?

# --------------------
# assignee
# --------------------
warn('このPRにアサインしてください') if github.pr_json["assignee"].nil?

Dangerの実行

  • 実行方法は色々あるが、今回はfastlaneから実行させた
  • 個人的にツールの実行や環境変数など可能な限りFastfileに記述して、CIはfastlaneの実行とmacOSのセットアップに留めたい派です
danger(
  danger_id: "unit-tests",
  dangerfile: "tests/MyOtherDangerFile",
  github_api_token: ENV["GITHUB_API_TOKEN"],
  verbose: true
)

https://docs.fastlane.tools/actions/danger/#danger

Dangerを導入した目的

  • 目的は新メンバーへのオリエンテーションを少しでも良い感じにすることだった
  • オリエンテーションを「あーでこーで」みたいなレクチャー形式にするのではなく、開発中に気がつける仕組みにしたかった
  • コーディングしてコミットしてPR投げたときに、Dangerの警告で気づける方がスマートだ
  • 必要な情報が知るべきタイミングで共有される仕組みはとても良さそう
  • 実際のDangerfileには警告にesawikiへのリンクを追記してる

CircleCIからDangerを使うとき困ったこと

  • PRをGitHubから新規作成したときにDangerの実行がスキップされる
  • PRを作成した後にコミットをpushするとDangerは実行される
  • CircleCIがPR作成時に該当のPRのURLを環境変数に設定してないからスキップされるようだ
  • CircleCIの中の人曰く、今のところはPRを作った後にリビルドして対応してくれとのこと 😢
    • 解決方法は先頭に書いた!

For now, rebuilding is the only suggestion I have while our engineers look into this further.

discuss.circleci.com

discuss.circleci.com

なぜCircleCIを選択したのか

  • 会社のCIツールを統一したくてCircleCIを選択した
  • しかし、CircleCIにこのような不便さがあるとは知らなかった
  • 個人開発では Bitrise を使っててPRの作成をトリガーに出来たので Bitrise に移行しようかなと心が揺れている 解決できた今はあまり揺れてない
  • せっかくCIツールを統一できて気持ち良い感じだったのに残念
  • 何か良い対策を知ってる人は教えてください 🙇‍♂️ 教えてくれました!

まとめ

  • CIからDangerを使うとPRの状態を自動チェックする仕組みがつくれる!!
  • 必要な情報が知るべきタイミングで共有される仕組みがつくれる!!
  • CircleCIから使うときは、Only Build pull requests を有効にしてPR作成時のスキップを回避しよう!!