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

potatotips 49 で発表してきた

登壇 iOS

これはなに

potatotips.connpass.com

なにを発表したの

speakerdeck.com

発表の補足

　@tarunonさんが発表中にツイートしてくれた。５分なので説明を端折ったが、確かに聞いてた人は疑問に思うところだった。@tarunonさんに感謝。

　なお、今回の発表のサンプルアプリは複数のレイアウトパターンを確認したかったのでサンプルではあるけど、結構いろいろ作り込んでる。iOSのレイアウトをコードで書く人、storyboardの人、両方からのツッコミを期待してる。

　また、実はこのテーマにする前の構想では「コードでレイアウトする際の利点・欠点」について発表する予定だった。でも、先日の TRY! SWIFT AFTER TALKS の1日目で @SatoshiN21さんが言いたいことの9割を言ってくれたのでお蔵入りにした。

　なぜ、9割かと言うとレイアウトはライブラリを使わず、標準のNSLayoutAnchorで書く方が今後の開発にはプラスになると個人的に思っているから。

　Cartography や SnapKit や TinyConstraints など優れたAutoLayoutのDSLがあることは知ってる。でも、AutoLayoutそのものの学習コストがそこまで低くないにも関わらず、DSLになると新メンバーの参入障壁になると思った。もちろん、慣れの問題だし短く書けることに越したことはない。

　それ以外は同じような理由でコードでレイアウトを書いてる。

potatotipsで発表して思ったこと

　potatotipsは発表時間が5分と短い。だから、自己紹介の後すぐに結論をまとめたスライドを出した。これは正解だったと思う。でも、早口で噛んだりちょっと時間オーバーしたのが悔しい。potatotipsでは、これまでに有名なiOSエンジニアがたくさん発表してるので結構プレッシャーだった。

　優れた発表者は総じて明瞭で簡潔なスライドできっちり時間内に説明してた。今回のpotatotipsでは@ra1028fe5さんの発表が良かった。*1 *2

　自分の発表は勉強会のハッシュタグを追っていると、勉強になるとツイートしてくれた人がいたので安心した。前回の発表よりも反応があったので嬉しい。一歩前進した。

　でも相変わらず、資料づくりは大変だ。前回に比べて発表時間が半分の5分で、しかもスライドのテーマとか細いところは前回の発表で固まったので内容だけ考えればよいはずだった。それでもサンプルアプリの作成、公式ドキュメントの下調べ、社内のiOSエンジニアにレビューして欲しいので発表前日には完成させる等、やること多い。やって無駄なことは一つもないけど、5分の裏側はいろいろ大変だった。発表者の全員がそうだと思う。

　発表資料の作成もAutoLayoutと同じで慣れの問題だろうか・・・。

終わり

  • 2018年にやりたいことの二つ目を達成した
  • iOSDCまでにより良い知見を発表できるよう精進する

*1:発表内容とは関係ないけど、UICollectionViewにorderableのAPIがなかった時代に、RAReorderableLayout を参考にして実装したのを発表後に思い出した。

*2:自分がiOSエンジニアなのでiOS側の発表にバイアスがかかってるけどAndroidの発表も凄かった

第2回 iOS UI実装勉強会で発表してきた

登壇 iOS

これはなに

  • 下記の勉強会で発表してきた
  • 人生初の社外勉強会での発表だった
  • Speaker Deck にいくつか資料はあげてるけど、他のは全て社内で発表した資料だった

connpass.com

なにを発表したの

speakerdeck.com

発表して思ったこと

　発表てリスキーだなと思う。良い発表ができれば人の役に立ち有名になるだろうけど、間違った情報を発表をすると悪いイメージを与えてしまう。しかも、その場での訂正が難しいのでブログやQiitaよりも影響が大きい。社外だと自分のバックグラウンドを知らない人ばかりなので、共有していない情報が多過ぎてあらぬ誤解を与えるかもしれない。

　だから可能な限り正しい情報を発表するため、資料作成には非常に時間をかける。何度もドキュメントを見て、本当に正しいのかテストを繰り返す。これだとブログやQiitaで書いた方が、間違ったとしても訂正して後で知らせれるかもしれないし、コメントや編集リクエストも来るかもしれない。時間や場所に縛られない。発表で緊張して精神をすり減らす必要もない。なぜ、みんなは知らない人の前で発表したがるのだろうか。

　大げさに書いたけど、そんなことを自分はどう感じるのか確かめたくて、実際に社外で発表してみた。結果は可もなく不可もなく。達成感はあった。今回発表した内容についてさらに詳しくなった。今回の発表内容がどれぐらい役に立ったのかわからないので成果はそれだけだ。それだけと言うと、言い過ぎな気もするが。もしかしたら、自分が気づいていない成功や失敗があったのかもしれない。

　発表のハードルを上げ過ぎている！少しぐらい間違ってもいいのでは？という意見もあると思う。でも、間違った情報を流すことは避けたいし、少しでも役に立つ内容にしたい。そんなモヤモヤを糧にして技術力を上げていく方法をとるのもいいのかもしれない。既にどこかの誰かが発表駆動学習とか言ってそうだ。

まとめ

  • 2018年にやりたいと思ってたことを一つ達成できた
  • 発表駆動学習をもう少し実践してみたい
  • 今年のtry!Swiftには無理だったけど、iOSDCでは何か発表したいと密かに思ってる