2020-09-10

iPhoneアプリを実機確認するためのApple Developerの証明書更新

iOS Mac

これは何？

iPhoneアプリ開発をする際に、実機を使った動作確認をすると思います。AppleDeveloperにIDが登録されているアプリの場合、AppleDeveloperへの端末登録や証明書の更新など手間がかかったので手順をまとめてみました。

端末登録

Apple Developerへの端末登録時に、実機ビルドする端末のUUIDを取得する必要があります。

確認をするにはXcodeのDevicesから確認をすることができます。

f:id:decoch:20200909140725j:plain

f:id:decoch:20200909140428p:plain

これをApple DeveloperのDevicesに登録をしてください。

f:id:decoch:20200909140431p:plain

f:id:decoch:20200909140434p:plain

f:id:decoch:20200909140437p:plain

証明書更新

Apple DeveloperのCertificates, Identifiers & Profilesから追加したProfileを選択します。

Profileの編集を押下するとDevicesが表示されるので、先ほど追加したDeviceを追加しましょう。

https://developer.apple.com/account/resources/profiles/list

これで追加が完了しました。

各開発者がそれぞれProfileの更新をすれば新しい端末でテストを行うことができます。

まとめ

iPhoneアプリを開発するときは、実機で確認するだけでも結構手間がかかりますね。

fastlane を使えばいろいろ自動化することができますが次の機会にまとめたいと思います。

2020-09-04

HomebrewでMacの初期設定を効率化する

PC Homebrew

なぜこの記事を書いたのか

昨年から職場が変わったり支給されているPCが変わったりでMacの初期設定をする機会が4回ほどありました。

使っているアプリをすべて探してダウンロードすると普通に1日潰れてしまうので、2回目から自動化をはじめました。

今回はその自動化方法をまとめました。

効率化するためにやっていること

dotfilesレポジトリを作成する

自分のPC設定をするためのレポジトリを1つ作成します。

こちらはプライベートレポジトリでも、パブリックレポジトリでもいいと思いますが、機密情報を扱う場合はプライベートにしておきましょう。

シェルの設定 dotfiles に追加する

エンジニアなら、bashの設定なら .bashrc zshなら .zshrc に記述していると思います。

こちらを先ほど作成した dotfiles に追加をしましょう。

他にも vimユーザーなら .vimrc tmux は .tmux.conf の設定をしていると思うので一緒に管理しておくと楽です。

使うファイルをBrewfileでインストールする

f:id:decoch:20200904000918p:plain

一番時間がかかるのがMacないのアプリで使っているものを探してダウンロードする作業だと思います。

homebrew を使ってインストールしているアプリを管理することができるのでその機能を使います。

この機能を使うことでコマンド1つですべてのアプリケーションをダウンロードすることができます。

github.com

簡単なサンプル

tap "homebrew/core"
tap "homebrew/bundle"
tap "caskroom/cask"

brew "zsh"
brew "peco"
brew "tmux"
brew "git"
brew "jq"

cask "iterm2"
cask "visual-studio-code"

PCセットアップ用のシェルスクリプトを用意する

シェルの設定は dotfiles に移動すると使えなくなってしまうのでシンボリックリンクを作成する必要があります。

毎回コマンドを思い出して実行するのは面倒なのでセットアップようのシェルスクリプトを作成していると便利です。

以下に簡単なサンプルを作成しておきます。

ln -s ~/dotfiles/.zshrc ~/.zshrc
ln -s ~/dotfiles/.vimrc ~/.vimrc
ln -s ~/dotfiles/.gitconfig ~/.gitconfig
ln -s ~/dotfiles/.tmux.conf ~/.tmux.conf

brew bundle

新しいPCでやること

ここまで用意できたら新しいPCでやることは簡単です。

作成したレポジトリをcloneして、そのレポジトリないでシェルスクリプトを実行するだけです。

git clone https://github.com/xxxx/dotfiles.git
cd dotfiles
sh ./xxxx.sh

まとめ

Brewfileや.zshrcの管理を行うことでPCの初期設定を自動化できました。IT業界にいると定期的にPCを変えることになると思うので、変更する機会があったら自動化にチャレンジしてみると良いと思います。

2020-08-12

GCP Firestore: データの関係性ごとに適当な設計を考えた

Firebase GoogleCloudPlatform

なぜのこの記事を書いたのか

直近一年間に GCP の Datastore, Firestore, AWS の DynamoDB など色々なKVSを触る機会に恵まれました。もともとRDBを使っていたため最初はKVSの設計にかなり戸惑ってしまいました。これから使う人の参考になればと思い、データの関係性ごとにどう設計すれば良いのか今の考えをまとめました。

Firestore とは

Firestore は、柔軟でスケーラブルなリアルタイムデータベースです。プロトタイプを迅速に作成できるだけでなく、どのような規模の開発にも対応できるスケーラビリティと柔軟性を兼ね備えています。 Firestore はリアルタイムデータベースであるため、クライアントは Firestore のデータをリッスンして、変更が生じたときにはリアルタイムで通知を受け取ることができます。この機能により、ネットワークレイテンシやインターネット接続に関係なく動作する応答性の高いアプリを構築できます。

設計について

1:1 のデータ

基本的に1対1のデータは1つのドキュメント（RDBでいうレコード）に保存する RDBと違ってSchema定義も必要なく、1つのドキュメントで1 MiBまで保存できるのでほとんど気にすることはないと思います。

ただ、RDB違って Field を指定して取得することができないため、住所やパスワードといった機密情報を別のユーザーが取得できるとセキュリティの問題があるため、別の Collection に保存し、セキュリティグループで本人のみデータを取得できるように制約をかけることを検討した方が良いです。

1:N のデータ

Nに上限がある場合

1つのドキュメントに配列として保存した扱うとドキュメントの取得する数を減らせてコスト削減できるため1つのドキュメントにまとめることをおすすめします。

ただ、Nのデータ単体で表示したりソートをする必要がある場合は扱いにくいため別のCollectionにすることを検討すると良いと思います。

Nに上限がない場合

1 MiBの制限に引っかかる可能性があるためSubCollectionや別のCollectionに分けて保存する必要があります。別Collectionにする場合、毎回1のデータを取得しなくても済むように、データのコピーをNのデータに持つことを検討すると良いです。

以下のようなイメージです

purchase
{
  "price": "number",
  "count": "number",
  "purchased_at": "timestamp",
  "user": {
    "id": "string"
    "name": "string"
    "address": "string"
    "phone_number": "string"
  }
}

以下ようにするとN+1クエリが発行されたり、クライアントでデータをくっつける必要が出てきて非効率になるため、仕様上問題がなければ非正規化した方が良いと思います。

purchase
{
  "price": "number",
  "count": "number",
  "purchased_at": "timestamp",
  "user_id": "string"
}

N:N のデータ

N対Nの場合は、1ドキュメントでは表現できないため基本的に複数の Collection を使うことになります。

基本的には新しく関係性を表現するCollectionを作成すると良いと思います。

shops_tags
{
  "shop_id": "string",
  "shop_name": "string",
  "tag_id": "string",
  "tag_name": "string"
}

ただ、シンプルに記述したくて利用頻度が多くない場合は、どちらかにもう片方の配列を保持することでも実現しても良いと思います。

shops
{
  "name": "string",
  "tags": [
    {
      "id": "string",
      "name": "string",
    },
    {
      "id": "string",
      "name": "string",
    }
  ]
}

まとめ

Firestoreの設計をするときに最初に検討した方が良いことをまとめました。
RDBとは考え方が違うので最初は非常に戸惑うと思います。
データの関係性ごとにどう設計するかまとめたので最初は参考にして設計すると良いと思います。

ネット上の記事や、ドキュメントを色々みましたが、以下の動画がかなり参考になったので一度みてみると良いと思います。 www.youtube.com

2020-08-07

トラックポイント付きのメカニカルキーボード Tex Yoda Ⅱ を使ってみた

HHKBを購入してからずっと使っていたのですが、キー配列が特徴的でMacbookのキーボードで作業をするときに打ち間違えが多くなったことや、元々ThinkPadキーボードを使っておりトラックポイントの良さを忘れられず、いろいろ調べていたところTexYodaが非常に気になっていました。

ただ価格がHHKB並みにしますし、最近キーボードを買ったばかりで悩んでいたため、 Twitterで軽い気持ちでTextYoda気になるとのツイートをしたところ友人が貸してくれることになりました。

f:id:decoch:20200807092127j:plain — tex yoda 2

先週末にお借りして、月曜日の仕事から使い始めてみました。 2,3日使ってみたところ、トラックポイントは横スクロールもでき満足しています。感度が良すぎるという人も結構いますが、元々トラックポイントのスクロールスピードを最大にしていたので、私にはちょうどよかったです。

キータッチについては、茶軸のスイッチのものを使っています。 HHKBと比べるとうち心地は少し悪いかなーと思いますが、元々静電容量方式に強いこだわりがあるわけではなかったので概ね満足しています。茶軸だと少し重い感じがするので、私には赤軸の方があってそうです。ここは個人的な好み

不満をあげるとすれば、f1などのキーをfnキーとのコンビネーションで入力する必要があるのですが、この配列がHHKBと違いすぎるため慣れるのに時間がかかりそうです。

キーのリマップの自由度が高いことと、キーキャップをカスタムオーダーサイトもあるので、気に入らない人は自分でカスタマイズすると良いと思います。 https://yoda2.tex-design.com.tw/

総じて、トラックポイント付きのキーボードの中では非常に良いキーボードだと思いました。ただ、一方で最近発売されたThinkPadキーボードも気になっているところではありますw

2020-07-30

作業用にゲーミングチェアを買った話

昨今のウィルスの影響でリモートワークする機会が増えてきたのですが、ソファや食卓で作業をしていると腰に来てしまったので、オフィスチェアの購入を検討していました。

ただ、オフィスで使っていたアーロンチェアは高く買うのを躊躇っていたところ、backspace.fm で有名なドリキンさんが格安ゲーミングチェアの動画を上げていて、お手頃だったのでポチってみました。

www.youtube.com

www.amazon.co.jp

普通に組み立てることはできて、30分程度で組み立て終わりました。中身の六角レンチとサイズが違うパーツがありましたが、100均で買うことができます。

非常に価格が安いのに座り心地は非常に良く、背もたれ調節可能で165度までリクライニング可能で作業用としての機能は申し分がないと思います。

コスパに優れているので、もしリモートワークで椅子の購入を検討している人はゲーミングチェアも選択肢に入れてみると良い思います。

2020-07-23

HKCの34インチのウルトラワイドディスプレイを買った

自宅ではノートPCで作業をしているのですが、うつむき加減で作業をすることになり、肩こりが激しくので、外部ディスプレイの購入を検討していました。

作業スペースが小さかったので、RoostのStandを使って工夫をしていましたが、

大きな作業スペースを手に入れたので画面が多いなウルトラワイドディスプレイをポチッってみました。

www.amazon.co.jp

MacBookと接続するときはUSB TYPE-Cのケーブルを購入して接続しました。

ノートPCと比べると随分楽な姿勢で作業でき、作業スペースも大きくなったので業務効率の改善と肩凝りが改善することを期待しています。

f:id:decoch:20200722143846j:plain — monitor

2020-07-16

iOS Clean Architecture を採用した振り返り

iOS Swift

クリーンアーキテクチャとは

レイヤーアーキテクチャの一種で、ソフトウェアをレイヤーに分離し、依存性ルールに従うことで、テスト可能なシステムを作成することができる。データベースやWebフレームワークのように、システムの外部部分が陳腐化しても、それらの陳腐化した要素を最小限の手間で置き換えることができる。

ことを利点としている。

f:id:decoch:20200715111045j:plain — clean architecture

採用した背景

新しく0からiOSアプリを開発する際に0からアーキテクチャ選定をする機会があった。

その際に以下の2点を選定する判断基準とした。

長期的にメンテナンスできること
人の出入りがあってもすぐに開発できるようになるべく学習コストを下げる

Clean Architecture は

レイヤーを分けてテスト可能にしやすいこと
Rxなどの学習コストが高いライブラリを使わずに開発を行えること

から採用に至った。

アプリの構成

root/
    ├ App/
    │   ├ Infra/
    │   ├ Presenter/
    │   ├ Storyboard/
    │   ├ UseCase/
    │   ├ ViewController/
    │   └ ViewModel/
    └ Domain/
        ├ Entity/
        ├ Repository/
        ├ Service/
        └ ValueObject/

またライブラリを最低限しか使わないようにしたかったので、

並列処理には dispatchGroup 、通信には URLSession を使うなど自前で実装をした。最初作るときは設定が必要だが、Swiftのバージョンをあげる際にライブラリ側の対応を待つ必要があるため、後々のことを考えると良い選択だったと思う。

開発してみて

クリーンアーキテクチャを採用してよかった点は、

テスト可能な構成にできたので高い品質で開発できた点
業務知識をDomain層に集めることができて、似たようなコードがいろいろなところに出てくることはなくなった
機能の変更をするときは変更を局所化できる

逆に悪かった点は

レイヤーを分けるため、作成するファイル数やコード量が増える
新しい機能を作るときは修正量が多く時間がかかる

のようになっています。

ファイルごとに役割が明確になるため、品質が高まり機能の修正はしやすいが、新機能を0から作るときはコード量が多く時間がかかってしまった。

最後に

まだ人が集まっていないアプリを開発する場合は、1秒でも早くリリースしたいと思うので、最初からクリーンアーキテクチャを採用する必要はないと思いますが、

ある程度のユーザが使うことが想定されていたり、高い品質を最初から要求したい場合は採用するのを検討すると良いと思いました。

decochのブログ

フリーランスのiOSエンジニア decoch のブログです