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

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.

iOS 登壇

これはなに

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

練習会の会場

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のタイムテーブルが決まったので資料作成の計画をたてる

登壇 iOS

これはなに

発表内容

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

  • ぶっつけ本番ありえない
  • プログラミングと同じでデバックやテストが必要
  • 作成から発表まで何時までに何をやるか決める
  • 弊社は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の開発を１人で支えた

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

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

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

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

まとめ

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

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

CircleCI

これはなに

Timezoneを変更する方法

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

support.circleci.com

まとめ

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

余談

Bitriseはどう？

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

iOSDC2018のプロポーザル

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

CircleCI

これはなに

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には警告にesaやwikiへのリンクを追記してる

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.

https://discuss.circleci.com/t/circle-pull-request-not-being-set/14409/11discuss.circleci.com

https://discuss.circleci.com/t/trigger-new-build-on-pr/4219discuss.circleci.com

なぜCircleCIを選択したのか

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

まとめ

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

副業の始め方と副業で得た知見

近況

これはなに

  • 副業を初めて一ヶ月が経過した
  • 副業で始めて給料を得た
  • 開始してまだ一ヶ月しかたってないがそこで得た学びを残す

どんな副業なのか

具体的には言えないのでざっくりと説明したい

  • iOSの開発支援で新機能の開発やバグの修正などが主なタスク
  • 自宅からリモートで平日の週3で2~3時間ほど稼働してる
  • 給料は時給制で値段は言えない
  • 高時給で儲かるような契約ではないが、そこには納得して副業している

なぜ副業を始めたのか

ここからが本題で理由は２つある。

① 本業は辞めたくないけど、本業とは別のサービスを開発したかった

転職はしたくないけど別のことはしたい。そう考える人は多いと思う。 大きな会社だと部門の移動とかで解消できる悩みかもしれない。 でも、今の本業だとそれは不可能なので副業という選択を取るしかなかった。

② リモートで開発を経験してみたかった

リモートで開発したいのは自分が将来、東京以外の場所で働く可能性があるから。 地元が田舎で親の体調によっては将来、実家に戻らざるをえない状況になるかもしれない。 そのリスクが問題になる前に対処できるスキルを持ってないと心配だなと思った。

でも、本業でリモート開発するには色々と越えないといけないハードルが多い。 そこで副業で出来ないかなと思ってたら幸運にもリモートで副業ができるようになった。

どうやって副業を手にしたのか

少し前に connpass で副業に関するイベントがあって参加した。

engineer-parallel-work.connpass.com

このイベントでは副業中のエンジニアが副業に関する知見をLTで発表してた。 内容をまとめると以下のような感じだった。

  • 副業を始めるには周囲に副業したいことをアピールし続けること
  • 副業未経験の人は受託案件はハードルが高いので最初はやめた方が良い
  • 副業未経験の人はスタートアップで開発支援などで参加するのがベター
  • 副業未経験の若者は、副業で儲けようとするのではなく、スキルアップしながらお小遣いが稼げるぐらいの気持ちで始めると良い。後にその経験が大きなリターンで返ってくる。
  • 発表してた人たちは全て知人からの紹介で副業を得ていた
  • 逆にWebサービス等で副業を得た人はいなかった

Webサービス等で副業を開始した人がいなかったのは、この市場が発展途上だからかもしれない。 またイベントのLTで発表できるような人たちなので、そこもバイアスがかかっているだろう。

でも、副業をお願いしたい会社側も見ず知らずのエンジニアに頼むよりは、知人経由での紹介の方が安心なのでやっぱり知人経由だと思う。 そして、自分も知人経由で副業を開始できたので間違いではないと思う。

特に、「周囲に副業したいことをアピールし続けること」 は一番大事というか、これをしないと始まらないので副業したい人は行動しよう。

今の副業で得た知見

最初は副業のメリットとデメリットで書こうと思ったけど、明確にメリットとデメリットに分けられないのでやめた。 メリットとデメリットが混在するというか、その狭間で右往左往するような感じ。 要は、読み手の立場によってどちらにも取れるので知見という言葉で濁すことにした。

知らない慣れてない技術に向かう機会が増える

当たり前すぎるが、これが面白いから副業してる。

本業は自分が書いたコードが多いし環境にも慣れている。 すると、慣れたことでやり続けてしまって成長の機会が減る。

自力で自分の殻を破って成長できる人は素晴らしいが、僕は環境を変えて半強制的に殻を破らざるをえない場所に身を置く方を選びたかった。 それなら転職すればいいのではと思うかもしれないが、そこまでの気持ちが今はないのは既に書いた。

あと、本業と副業で別々の仕事をすると、お互いを比較することで色んな改善策がポツポツと頭に浮かんでくる。 何かと何かを比較してそこに生まれる差分でいろんな気づきを得られるのも大きいと感じている。

もちろん、GitHub上のOSSを見ることで似たような体験を得ることは十分可能なんですが。

確定申告と請求書とかの知識がつく

副業を始めるのが面倒だと思う理由は、確定申告とか請求書とかがイマイチよくわからないからだと思う。 自分もここが心配だったが、知人の助けにより今のところは問題なさそうである。

要するに、ネットバンクで口座を開設してfreeeで開業届けを出して請求書もfreeeで作成するでOKだった。 まだ確定申告という難関を突破したことはないが、とにかく本業以外の収入を計算しやすいようにひとまとめにしておくことが大切で、あとは詳しい人に聞けばなんとかなる。

今までfreeeを使ったことなかったけど、色々便利ですごいなと思ったし、開業届けや確定申告などを自分事として考えられるようになったのは嬉しい。 学ぶ喜びを得ている。

リモートで改めて気づく報連相の大切さ

いつから稼働して、何時に完了して、何をやったのかをわかりやすく伝えないと、副業先の会社の人は心配になる。 当たり前だけど大切なことである。

稼働の開始と終了はslackでやり、開始時に今日の作業内容を簡単に書く。終了時には作業の進捗を書く。 作業の進捗や結果がわかりやすいように、WIPつけたりPRにはスクショなども貼る。

大きめの修正や仕様に大きな変更がありそうなとき、相手側の要望とその対応をまとめてissueにする。 正確にissueにまとめられてると、リモートでもコミュニケーションは比較的円滑にすすむ。 自分以外の人も副業でリモートしてるので、他のメンバーもお互いの作業が把握しやすくなる。

リモートだからとか関係なく、普通にやるべき事だけどその大切さを改めて実感してる。

ささいなことで褒められる

最後は承認欲求が満たされるてやつだ。

副業を必要としている会社は人手が足りてないので、不具合とか色んな問題が放置されがち。 ほんの数分でなおせそうな不具合とかも残ってるので、すぐに対応すると喜んでもらえる。 当たり前すぎるけどやってて楽しい。

まとめ

  • 副業はじめました
  • 副業を始めるには周囲に副業したいことをアピールし続けることが何よりも大切です

余談

今年のiOSDCの開催が発表されたので、発表する内容を準備しないと・・・。

http://blog.iosdc.jp/entry/2018/04/23/100000blog.iosdc.jp