ライブのチケットをAirtableで管理してみたらわりと良かった

ここ数年は決まった声優さんだけではなく、様々なアーティストのライブに行くことが多くなってきた。ロックバンドのライブは封入先行、オフィシャルHP先行、プレイガイド先行など、予約するタイミングが複数あって、予約先もアーティスト公式/ぴあ/e+だけではなくLINEチケットやなどのチャンネルに分かれている。

そうすると何が起こるかというと、同じライブのチケットを複数の先行予約で購入してしまうということだ。他にも同じ日に異なるライブのチケットを買ってしまうことも出てくるだろう。しかも1枚4000円〜10000円くらいするので、そのようなことがあるとおサイフのダメージが大きい。

防ぐためにちゃんと管理しないと…と思うと出てくるのがこの衝動。

ライブのチケット管理するアプリほしい

— いせ (@iseebi) June 8, 2019

アプリ作ろうと思ったのだけど、いや、どう考えてもそこまでコストかけることか…？Accessの現代版はないものか…？と思っていたら丁度よさそうなAirtableというサービスを見つけた。

airtable.com

2ヶ月ほど運用してみて、わりと良い感じだったので、どう管理しているか紹介しようと思う。

Twitterアプリ経由認証を簡単実装できる軽量ライブラリSimpleTwitterAuthenticationを作りました

仕事でTwitter認証をサポートしたアプリを開発していますが、その認証処理に使われていたライブラリがとても古く、あっちこっち警告出しまくっていたので入れ替えることになりました。

いろいろ考えた結果、小さなライブラリを新しく起こしました。SimpleTwitterAuthenticationと、そのものズバリな名前のライブラリです。

github.com

実のところ、入れ替え先のライブラリを検討したのですが、公式のTwitterKitを使うとTwitterアプリがあれば飛んで、専用のOAuth画面を出してくれるようになっています。しかし、既にdiscontinuing supportと書かれているし、認証のためだけに大型のライブラリを入れるのはビルド時間も延びるのでよろしくない。

このライブラリはTwitterKitのソースを見て同様の処理を実装し、端末にTwitterアプリがあればTwitterアプリに遷移しますし、なければiOSバージョンごとに適切な認証用ViewController(ASWebAuthenticationSession/SFAuthenticationSession/SFSafariViewController)を起動して認証するようになっています。認証に必要な処理だけ書いているので1ファイルのみのシンプルなライブラリになっています。

Dark Modeに対応したTransporterPad v2.1.0をリリースしました

iOS/Androidアプリを簡単かつ複数の端末にインストールできるMacアプリ、TransporterPadを久しぶりにアップデートしました。

今回は再びはやかわさんにご協力いただき、ダークモードに対応させました。

ダウンロードはこちらから

そもそもTransporterPadとは

Macに繋がっているすべてのiOS/Android端末に、指定したIPA/APKを一括でインストールするツールです。

iOS/Android アプリの実機転送は公式の TestFlight などや、DeployGate といった OTA 配信の仕組みが使われることが多くなっています。しかし、そのような環境を構築できない場合もあります。そのときは USB をつないでの転送をすることになりますが、この方法だとエンジニア以外にはハードルが高く、デザイナーやマネージャーが新しいビルドを試しづらい環境だと思います。例えば、Apple ConfiguratorやAndroid Studioは扱い方やファイルサイズの点から、導入が大変だと思います。

また、テスターが複数の実機を横に並べてテストする際、そのインストールは大変な手間となってしまいます。

TransporterPadは小さく、取り扱いも簡単ですので、開発チームの多くの人が手軽にUSB経由の実機転送をすることができます。

その他、下記の資料が参考になると思います。

speakerdeck.com speakerdeck.com

---

ぜひ使ってみてGitHubのスターや感想などいただけますとうれしいです。

macOSアプリに埋め込む実行バイナリのNotarization/Hardened Runtime対応は署名すればOK

昨日の記事で、アプリはHardened Runtime対応されたものの、リソースとして埋め込まれる実行ファイルがHardened Runtimeに対応していない状態だったためNotarizationに失敗していました。

実は、Hardened Runtimeへの対応はアプリのビルド時ではなく、コードサインでフラグを立てることでなされます。

codesign コマンドに --options runtime をつけてバイナリを署名することで、Hardened Runtime対応となります。

codesign --force --options runtime --sign "Developer ID Application: Shin ISE (XXXXXXXXXX)" adb

CocoaPodsなど、Xcodeで処理されているバイナリに関してはXcode側にHardened Runtimeのフラグを立てることで署名されていますが、問題のバイナリはRun Script Phaseでバイナリをコピーするようにしていたので、これらコピーで追加した実行ファイルは独自に署名してやる必要があります。

というわけで、Run Script Phaseにcodesignコマンドの呼び出しを追加しました。--sign の引数は$CODE_SIGN_IDENTITYに置き換えて、このような形にしています。

Visual Studio App CenterでmacOSアプリのNotarizationに対応しようとした

macOS Catalinaから、macOSアプリはAppleによる公証(Notarization)が必須化されます。Notarizationのプロセスではアプリのバイナリを一度Appleに送って、マルウェアなどのチェックを受けます。雰囲気は以下のページがわかりやすいです。

applech2.com

さて、自分もTransporterPadというmacOSアプリを作っています。CIには無料でmacOSアプリのビルドができるVisual Studio App Centerを使っていますが、公式な対応はしばらくかかりそうな様子でした。

github.com

そこで、カスタムビルドスクリプトを使って対応させることにしました。

フレッツ光のIPoEがやたらと遅かったけどプロバイダのせいだった

マンションに標準でインターネットがついている物件を渡り歩いてきたけど、昨年引っ越したときについにインターネット付き物件でなくなってしまったので自前でフレッツ光ネクストを契約した。

その際に、友人から PPPoE で接続していると遅い！IPoE 接続にすべき！みたいなことを聞いていたので、プロバイダには DS-Lite の IPoE のみが使用可能なエキサイトMEC光接続プラン TYPE-D を選んだ。

マンションタイプのVDSLだが、僕の使い方では50〜60Mbpsも出ていれば十分で、実際引越直後は 80Mbpsや90Mbpsという速度が出ていたので十分満足していた。

しかしこの数ヶ月、夜にやたらと遅くなることが増えてしまっていた。Splatoonで回線不安定で切断されることも多くなっていた。そうして、ついに昨日、ようやくウデマエSになったガチヤグラで勝てそうなときに通信が不安定になって我慢できずに対策を練ることにした。

Apple Developer Programが2/27から2ファクタ認証必須になる件

日本時間の2/14の朝、Apple から一つのメールが届いた。

ベッドの中で寝ぼけながら読んでいて、一気に眠気が吹っ飛んだ。2/27 より2ファクタ認証が必須になるという内容が書かれていた。これは大きな問題になるぞ…！と思ってツイートした。

おいおい、Apple Developer Programのログインに「2ファクタ認証」必須化だと？これはマジ勘弁してほしい。
他のところみたくTOTPとかならどんどんやってほしいけど、Appleさんの「2ファクタ認証」は「iCloudログイン済の信頼済Appleデバイス」必須なのがヤバい。

— いせ (@iseebi) 2019年2月13日

当初はこいつはマズイと思ったが、いろいろ問い合わせたり、その後出てきた情報を見た限り、杞憂そうだとわかったのでまとめておく。