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