株式会社はてなに入社しました
今日はエイプリルフールです。
Instapaperを改めて使い始めた
あとで読む系のサービスは一貫してPocker (旧Read It Later)を使っていたのだけど、単純に追加した記事を読みたいと思った時に、 Instapaperの記事画面の方が読みやすく、ページが長い場合は自動で分割してくれるところがやっぱり良いと思い、Instapaperに戻ってきた。
しばらくはこれで運用してみようと思う。
2020年買って良かったもの
お題「#買って良かった2020」
今年もやっていきます
サービス編
クラウド郵便箱atena
私書箱のようなアドレスが付与されてそちらに郵便物が届くと、スキャンしたり転送したりしてくれるサービス。 自分は自宅と事務所どちらにも導入した。 リモートワークで事務所に行くことが減ったため、郵便物をスキャンして確認できるのは超便利。
途中で料金体系が変わって若干高くなったが、いいサービスだと思う。
青山フラワーマーケット 旬の花定期便
定期的にお花を届けてくれる。 ボリュームもいくつかあって、ライフスタイルコースだと3種類のサイズの花が入っていて飾りやすい。 届ける周期も選べるので、自分の家にあった周期で頼むと忘れた頃にお花が届いて体験が良い。
ガジェット編
デロンギ(DeLonghi) コンパクト全自動コーヒーメーカー エレッタ
コーヒーメーカーはいくつか持っていたが、これを購入したことで圧倒的にコーヒーライフが楽になった。 まずコーヒーフィルターは不要で、お手入れも半自動。 肝心のコーヒーの味だが、その辺のカフェで出てくるのと同じクオリティが家で楽しめる。 エスプレッソ、カフェジャポーネ（アメリカン的なやつ）、カプチーノ、カフェラテなどメニューも豊富。 若干お高いが、リモートワーク生活がかなり豊かになる。
Anker Magnetic Cable Holder
机の上のケーブルがぐちゃぐちゃになったりしないので便利。
山崎実業 手荷物収納ボックス タワー
山崎実業 手荷物収納ボックス タワー ブラック 約W46XD29XH40cm Tower 3545
- 発売日: 2018/04/06
- メディア: ホーム&キッチン
バックパックの置き場に困っていたが、帰宅してこれに突っ込めば床も汚くならないので買って良かった商品。 ブックシェルフとしても使えたり、使わない時は折り畳んで置けるので邪魔にならない。
テスラ モデル3 ロングレンジ
今年は初めて車を購入した。
ロングレンジで、完全自動運転オプションもつけた。
日本だと今のところ自動車線変更、自動駐車くらいだが今後の徐々に解除されていくので楽しみ。
ソフトウェアアップデートがたまに降ってくるんだけど、これはiPhoneの体験と同じでソフトウェアによって体験が後から追加されていくのがすごい。
テスラの場合購入フローがめちゃくちゃアメリカンで、青山のテスラストアで一度試乗した後に、ネットでポチった。
引き渡しも、アプリから車の鍵を開錠して、セルフでピックアップする形だった。斬新。
サポートの電話が繋がりにくいなど色々あるけど、かなり満足している。
ちなみにこのリンクから購入すると1,500 km相当分のスーパーチャージャー無料充電特典がついてきます。 https://ts.la/tatsuya57881
技術顧問としてのお仕事
技術顧問と聞くと何をしているのかわからなかったり、ブラックボックス化していることがあるので、 参考までに自分がどんなことをしているのか紹介してみようと思う。
前提として技術顧問は人によって領域や内容が全然違うこともあるので、事前にどんなことを依頼したいか、できるのか握っておくことが大事だと思う。 あと下記は複数の会社をまとめたもの。
- iOSアプリのコードレビュー
- iOSアプリのCI, CD環境の構築
- Ruby on Railsプロジェクトのコードレビュー
- Ruby on RailsプロジェクトのCI, CD環境の構築
- Ruby on Railsプロジェクトの開発環境のDocker化
- エンジニア1 on 1
- 月一で第三者目線での1on1
- エンジニア目標レビュー
- エンジニア採用サポート
- 技術的な観点での面談に出たり
- 会社イベントでの登壇
- テックブログの記事執筆
- 開発全般の課題整理、推進
- ヒアリング、課題整理、週一で確認
- プロダクトオーナーやスクラムマスターのサポート
- 新規プロジェクトのセキュリティ的な観点でのレビュー
- Slack常駐による技術的質問への回答
自分はこんな感じで幅広くやっているが、技術特化のパターンだとまた違うかもしれない。
スキル見合いという悪習
業務委託などの形式で仕事を募集している会社などをみていると、報酬の欄に「スキル見合い」と書かれているのをみることが稀にある。
スキル見合いとは要するにその人のスキルに合わせて報酬を決めて契約するということだ。
では、そのスキルとはどうやって判定するのだろうか。
だいたいの場合では、募集をしている企業側の担当者の主観で決められることが多いのではないだろうか。
業務委託という性質上、面接に近い厳密なコーディングテストを実施することは難しいはずだ。
業務を委託しなくてはならないくらいなので、スキルを判定することができる人材もそこまで揃っていないケースも多い感じはする。
では、どうしていくべきだろうか。
「スキル見合い」という誰も幸せにならないやり方を捨て、まずはどれくらいの金額であればその業務が気持ちよくできそうか提示してみよう。
もし金額が合わなければそこで終わってしまうかもしれないが、業務の内容を調整したり、金額を交渉したりそれぞれが歩み寄ることが大切だと思う。
企業側にだけ都合の良いやり方は捨て、仕事を請ける側も気持ちの良い習慣が根付くことを願う。
iOSアプリのコードレビューで見ているポイント 2020年5月版
比較的大きめな規模のiOSアプリのコードレビュー をする機会がよくあるため、 どういった点に注意を向けてレビューしているかまとめておこうと思う。 以下は主にGitHubのPull Requestベースでレビューをする場合を想定している。
非コード編
1. 該当のissueがリンクされているか
Pull Requestを出した背景となるissueがあればそのリンクがDescription欄に貼られているか
2. 変更点が簡潔に書かれているか
コードを見ればいいのだけど、変更した内容を簡潔に書かれているとコードレビュー する前にある程度把握することができるので書きましょう
3. スクリーンショットが添付されているか
UIの変更を伴う修正の場合はスクリーンショットを付けた方が良い。 スクリーンショットに関してはいくつか見る箇所があって、
- レイアウトが崩れていないか
- 該当のissueの要件になっているか
4. CIが通っているか
CIが導入されているのであれば、CIのステータスがGreenになっているか
コード編
5. 新しくファイルを追加する場合、適切なGroupに配置されているか
比較的規模の大きいアプリであれば、暗黙的なGroup分けの仕方が存在していると思うので、適切なGroupに配置するか、新しくGroupを切りましょう
6. 目的の修正と関係ないファイルが変更されていないか
よくあるのが、CocoaPodsの Podfile.lcok がなぜか更新されていたり、
関係ないStoryboardで差分が出てしまってコミットされているケース。
後から変更を履歴を追いたい時に不要な変更があると原因の特定が難しくなったりするため、そもそも意図しない変更以外はコミットしない方が良い。 使っているXcodeのバージョンがチームで違っていたりすると、Storyboardを開いただけでdiffが発生したりするので注意。
7. ファイル名、クラス名が適切か
そのファイル名やクラス名を見ただけで役割が推測できたら良い。 できなかったら不適切な名前を付けている可能性が高い。
8. インデントが崩れていないか
プロジェクトが採用しているインデントのルールに沿って改行やインデントされているか。
9. 変数名が適切か
その変数の型と役割を表す名前になっているか。
let image: UIImageView
例えば上の例だと、宣言している箇所ではまあわかるが、他の箇所で image が参照されていると、 UIImage の変数なのかと思えてしまう。
let imageView: UIImageView
とした方が理解しやすい。
10. 循環参照していないか
特にクロージャーを使っている箇所で self が循環参照していないか。
11. 小さい画面の端末が考慮されているか
iPhone SEなど解像度が低い端末で実行した時に崩れたり、意図しない表示にならないか。
12. Forced Unwrapping（強制Unwrap）を使っていないか
実行時にクラッシュしてしまうためOptionalを使いましょう。
13. ライブラリを導入する際は、導入目的が明確か、メンテナンスされているか
UIKitで目的が達成できるのであればライブラリは使う必要はないと考えています。 また似たようなライブラリがあった際は、なぜそのライブラリである必要か説明があった方がいいです。
14. Dark Themeを導入していれば、Themeの切り替えで意図しない表示になっていないか
Storyboard上で容易に切り替えて確認できるので確認しましょう
15. print文などをDEBUGフラグ確認なしに使って、不必要なログを出力していないか
APIのレスポンスなど不要なログは出力しないほうが懸命です。 SwiftyBeaverなどのライブラリを使うのも手です。
まだまだレビュー観点はたくさんあるんですが、 他にもこういう観点でコードレビュー しているなどあれば、コメントもらえると嬉しいです。