20220225のiOSに関する記事は6件です。

Github Actions から Autify for Mobile (iOS) テストを実行する

Github Actions から Autify for Mobile (iOS) テストを実行する方法を解説します。 前提 Autify for Mobile(iOS) で Simulator テストを実行する fastlane 設定 Autify へアップロードするために、*.app を生成します。 以下の fastlane を設定します。 Autify は x86_64 Simulator で実行されるため、arm64 ではなく x86_64 の *.app を生成するようにしています。 fastlane/Fastfile lane :build_simulator do gym( scheme: "MyApp", skip_package_ipa: true, # *.app を生成するため、*.ipa は不要 skip_codesigning: true # Simulator 実行のため署名不要 destination: "generic/platform=iOS Simulator", xcargs: "ARCHS=x86_64" # Autify の x86_64 Simulator 向け ) end Github Actions Workflow Workflow を以下のように設定します。 ... jobs: autify: runs-on: macos-latest steps: - uses: actions/checkout@v2 ... - name: Build run: fastlane build_simulator - name: Autify Upload & Run Test env: AUTIFY_UPLOAD_TOKEN: ${{ secrets.AUTIFY_UPLOAD_TOKEN }} AUTIFY_TEST_PLAN_ID: {test plan id を設定} AUTIFY_PROJECT_ID: {project id を設定} run: | export AUTIFY_APP_DIR_PATH=$(echo ~/Library/Developer/Xcode/Archives/*/*.xcarchive/Products/Applications/*.app) # MyApp.app をアップロード envman(){ :; } # autify_mobile_cli の envman エラーを無視 export -f envman response=$(bash -c "$(curl -fsSL https://raw.githubusercontent.com/autifyhq/autify-for-mobile-cli/main/autify_mobile_cli.sh)") result=$(echo $response | tail -n 1 | sed -E 's/^[^{]*({.*}).*$/\1/g') # workaround: API レスポンスだけを取得 build_id=$(echo $result | jq -r .id) # テストの実行 response=$(curl -X POST \ -H "Authorization: Bearer $AUTIFY_UPLOAD_TOKEN" \ -H "Content-Type: application/json" \ --data "{\"build_id\":\"$build_id\"}" \ "https://mobile-app.autify.com/api/v1/test_plans/$AUTIFY_TEST_PLAN_ID/test_plan_results") test_plan_result_id=$(echo "${response}" | jq -r .id) echo "https://mobile-app.autify.com/projects/$AUTIFY_PROJECT_ID/results/$test_plan_result_id" 解説 Autify for Mobile のテスト実行には *.app のアップロードが必要です。 Autify for Mobile CLI を使用します。 Autify for Mobile CLI への入力は以下の環境変数で設定します。 環境変数 値 AUTIFY_UPLOAD_TOKEN Autify Personal Access Token AUTIFY_PROJECT_ID Autify Project ID AUTIFY_APP_DIR_PATH *.app ファイルのパス fastlane からビルドすると ~/Library/Developer/Xcode/Archives/2022-02-25/MyApp 2022-02-25 23.00.00.xcarchive/Products/Applications/MyApp.app が生成されるため、これを AUTIFY_APP_DIR_PATH へ設定します。 Autify for Mobile CLI は Bitrise の envman に依存してしまっているため、Github Actions Support の PR を提出しておきました。https://github.com/autifyhq/autify-for-mobile-cli/pull/5 テストの実行は Autify for Mobile API を使用します。 /api/v1/test_plans/{test_plan_id}/test_plan_results API にアップロード結果の build_id を渡すとテストが実行されます。 Autify のテスト結果は https://mobile-app.autify.com/projects/$AUTIFY_PROJECT_ID/results/$test_plan_result_id から参照できます。 余談 以下の Github リポジトリに Autify 公式の Github Actions 設定サンプルがあるようなのですが、現時点ではサンプルが未完成のようです...
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

GitHub Actions から Autify for Mobile (iOS) テストを実行する

GitHub Actions から Autify for Mobile (iOS) テストを実行する方法を解説します。 前提 Autify for Mobile(iOS) で Simulator テストを実行する fastlane 設定 Autify へアップロードするために、*.app を生成します。 以下の fastlane を設定します。 Autify は x86_64 Simulator で実行されるため、arm64 ではなく x86_64 の *.app を生成するようにしています。 fastlane/Fastfile lane :build_simulator do gym( scheme: "MyApp", skip_package_ipa: true, # *.app を生成するため、*.ipa は不要 skip_codesigning: true # Simulator 実行のため署名不要 destination: "generic/platform=iOS Simulator", xcargs: "ARCHS=x86_64" # Autify の x86_64 Simulator 向け ) end GitHub Actions Workflow Workflow を以下のように設定します。 ... jobs: autify: runs-on: macos-latest steps: - uses: actions/checkout@v2 ... - name: Build run: fastlane build_simulator - name: Autify Upload & Run Test env: AUTIFY_UPLOAD_TOKEN: ${{ secrets.AUTIFY_UPLOAD_TOKEN }} AUTIFY_TEST_PLAN_ID: {test plan id を設定} AUTIFY_PROJECT_ID: {project id を設定} run: | export AUTIFY_APP_DIR_PATH=$(echo ~/Library/Developer/Xcode/Archives/*/*.xcarchive/Products/Applications/*.app) # MyApp.app をアップロード envman(){ :; } # autify_mobile_cli の envman エラーを無視 export -f envman response=$(bash -c "$(curl -fsSL https://raw.githubusercontent.com/autifyhq/autify-for-mobile-cli/main/autify_mobile_cli.sh)") result=$(echo $response | tail -n 1 | sed -E 's/^[^{]*({.*}).*$/\1/g') # workaround: API レスポンスだけを取得 build_id=$(echo $result | jq -r .id) # テストの実行 response=$(curl -X POST \ -H "Authorization: Bearer $AUTIFY_UPLOAD_TOKEN" \ -H "Content-Type: application/json" \ --data "{\"build_id\":\"$build_id\"}" \ "https://mobile-app.autify.com/api/v1/test_plans/$AUTIFY_TEST_PLAN_ID/test_plan_results") test_plan_result_id=$(echo "${response}" | jq -r .id) echo "https://mobile-app.autify.com/projects/$AUTIFY_PROJECT_ID/results/$test_plan_result_id" 解説 Autify for Mobile のテスト実行には *.app のアップロードが必要です。 Autify for Mobile CLI を使用します。 Autify for Mobile CLI への入力は以下の環境変数で設定します。 環境変数 値 AUTIFY_UPLOAD_TOKEN Autify Personal Access Token AUTIFY_PROJECT_ID Autify Project ID AUTIFY_APP_DIR_PATH *.app ファイルのパス fastlane からビルドすると ~/Library/Developer/Xcode/Archives/2022-02-25/MyApp 2022-02-25 23.00.00.xcarchive/Products/Applications/MyApp.app が生成されるため、これを AUTIFY_APP_DIR_PATH へ設定します。 Autify for Mobile CLI は Bitrise の envman に依存してしまっているため、Github Actions Support の PR を提出しておきました。https://github.com/autifyhq/autify-for-mobile-cli/pull/5 テストの実行は Autify for Mobile API を使用します。 /api/v1/test_plans/{test_plan_id}/test_plan_results API にアップロード結果の build_id を渡すとテストが実行されます。 Autify のテスト結果は https://mobile-app.autify.com/projects/$AUTIFY_PROJECT_ID/results/$test_plan_result_id から参照できます。 余談 以下の GitHub リポジトリに Autify 公式の GitHub Actions 設定サンプルがあるようなのですが、現時点ではサンプルが未完成のようです...
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Fast-Neural-Style-TransferをiOS、MacOSで使えるようにする CoreML変換

Fast-Neural-Style-TransferをiOSで使う方法です 変換済みモデル 変換スクリプト 画風変換アプリを作ろう Fast-Neural-Style-Transferは画風変換ができるモデルです。 iOSで使えば画像やビデオの画風変換アプリができます。 CoreMLに変換するとiOS、MacOSデバイスで使える 方法 Pytorch版のリポジトリをクローン、リポジトリのリンクから事前トレーニング済みの重みをダウンロードします。 事前トレーニング済みの重みからモデルを復元します。 from models import TransformerNet import torch transform = style_transform() device = torch.device("cuda" if torch.cuda.is_available() else "cpu") transformer = TransformerNet().to(device) transformer.load_state_dict(torch.load("style-transfer-models/mosaic_10000.pth")) transformer.eval() 変換します。 import coremltools as ct example_input = torch.randn(1,3,960,640).cuda() traced_model = torch.jit.trace(transformer, example_input) mlmodel = ct.convert(traced_model, inputs=[ct.ImageType(name="input", shape=example_input.shape,bias=[-0.485/0.229,-0.456/0.224,-0.406/0.225],scale=1.0/255.0/0.226)]) モデルの入力は正規化されているので、CoreMLの入力も同じように前処理されるように設定しています。 モデルからニューラールネットワークビルダーを作り、出力名を確認します。 spec = mlmodel.get_spec() builder = ct.models.neural_network.NeuralNetworkBuilder(spec=spec) builder.spec.description モデルの出力をRGB画像にするには、出力も前処理に合わせて非正規化する必要があります。 カラーチャネルごとにテンソルを前処理の逆にアクティベートし、再結合するレイヤーを追加します。 var_293は元のモデルの出力名です。 builder.add_split(name="split", input_name="var_293", output_names=["split_1","split_2","split_3"]) builder.add_activation(name="activation_1",non_linearity="LINEAR",input_name="split_1",output_name="activation_out_1",params=[255*0.226,0.485*255]) builder.add_activation(name="activation_2",non_linearity="LINEAR",input_name="split_2",output_name="activation_out_2",params=[255*0.226,0.456*255]) builder.add_activation(name="activation_3",non_linearity="LINEAR",input_name="split_3",output_name="activation_out_3",params=[255*0.226,0.406*255]) builder.add_stack(name="stack", input_names=["activation_out_1","activation_out_2","activation_out_3"], output_name="stack_out", axis=0) builder.add_squeeze(name="squeeze", input_name="stack_out", output_name="squeeze_out", axes = None, squeeze_all = True) 出力をRGB画像に設定します。 from coremltools.proto import FeatureTypes_pb2 as ft from coremltools.models.utils import save_spec builder.spec.description.output.pop() builder.spec.description.output.add() output = builder.spec.description.output[0] output.name = "squeeze_out" output.type.imageType.colorSpace = ft.ImageFeatureType.ColorSpace.Value('RGB') output.type.imageType.width = 640 output.type.imageType.height = 960 save_spec(builder.spec, 'fast-style-transfer-mosaic.mlmodel') Swiftで実行 let model = try! fast-style-transfer-mosaic(configuration: MLModelConfiguration()).model let vnModel = try! VNCoreMLModel(for: model) let request = VNCoreMLRequest(model: vnModel) let handler = VNImageRequestHandler(ciImage: image, options: [:]) try! handler.perform([request]) guard let result = request.result?.first as? VNPixelBufferObservation else { return } let pixelBuffer = result.pixelBuffer 動画に適用 ? フリーランスエンジニアです。 お仕事のご相談こちらまで rockyshikoku@gmail.com Core MLやARKitを使ったアプリを作っています。 機械学習/AR関連の情報を発信しています。 Twitter Medium
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Cisco IOS-XE(IOS)でコンフィグの世代管理・ロールバックの実行

今更ながらIOS-XE(IOS)でコンフィグの世代管理やロールバックを試してみたので結果をまとめました。 今回はCSR1000V(Cisco IOS XE Software, Version 17.03.02)で動作確認を行なっています。 目次 概要 設定方法 archive configの確認方法 ロールバックの実行 所感 参考 概要 archive設定を行うことでコンフィグの世代管理ができるようになります。 最大で14世代までarchive configurationを保存しておくことが可能で、configure replaceコマンドにより任意のarchive configurationの状態にロールバックすることもできるようです。 設定方法 ■ 変更内容 testRT01#conf t Enter configuration commands, one per line. End with CNTL/Z. testRT01(config)#archive testRT01(config-archive)#path flash: testRT01(config-archive)#maximum 14 testRT01(config-archive)#write-memory testRT01(config-archive)#end (補足) path <保存先>: archive config の保存先。ここでは flash: を指定しました。保存先として外部のサーバを指定することも可能です。 maximum <世代数>: 保存するバックアップコピーの世代数の上限(1-14) write-memory: write memory を実行したタイミングでarchive configを作成する設定。 【参考】archive設定で実行可能なコマンド testRT01(config-archive)#? Archive configuration commands: default Set a command to its defaults exit Exit from archive configuration mode log Logging commands maximum maximum number of backup copies no Negate a command or set its defaults path path for backups rollback Rollback parameters time-period Period of time in minutes to automatically archive the running-config write-memory Enable automatic backup generation during write memory 今回は設定しませんでしたが、time-period 1440 で24時間おきにsnapshotを取得する等もできるようです。 【参考】 pathの指定先 testRT01(config-archive)#path ? bootflash: Write archive on bootflash: file system flash: Write archive on flash: file system ftp: Write archive on ftp: file system http: Write archive on http: file system https: Write archive on https: file system pram: Write archive on pram: file system rcp: Write archive on rcp: file system scp: Write archive on scp: file system sftp: Write archive on sftp: file system tftp: Write archive on tftp: file system 【参考】archive config の世代数設定 testRT01(config-archive)#maximum ? <1-14> maximum number of backup copies archive config の確認方法 archive設定を行うことでコンフィグの世代管理ができるようになります。 show archive を実行することで保存されているバックアップコピーの情報を確認できます。 archive設定 有効化前 testRT01#show archive Archive feature not enabled archive設定 有効化後 testRT01#show archive The maximum archive configurations allowed is 14. There are currently 3 archive configurations saved. The next archive file will be named bootflash:-<timestamp>-3 Archive # Name 1 bootflash:-Feb--6-16-05-40.925-0 2 bootflash:-Feb--6-16-10-33.239-1 3 bootflash:-Feb--6-16-27-27.278-2 <- Most Recent 4 5 6 7 8 9 10 11 12 13 14 ロールバックの実行 configure replace <ロールバック先> コマンドによりロールバックを行うことが可能です。 ここでは設定変更後に戻し対応が必要になったというシナリオで、手順を順に追って確認します。 設定変更前 testRT01#show archive The maximum archive configurations allowed is 14. There are currently 1 archive configurations saved. The next archive file will be named bootflash:-<timestamp>-1 Archive # Name 1 bootflash:-Feb--6-16-05-40.925-0 <- Most Recent 2 3 4 (省略) 今回は以下のコマンドを投入してループバックインターフェイスを作成して保存してみます。 testRT01#conf t Enter configuration commands, one per line. End with CNTL/Z. testRT01(config)#interface loopback 1 testRT01(config-if)#ip address 10.1.1.1 255.255.255.255 testRT01(config-if)#end testRT01#show ip interface brief Interface IP-Address OK? Method Status Protocol GigabitEthernet1 192.168.3.101 YES NVRAM up up GigabitEthernet2 192.168.4.1 YES manual up up GigabitEthernet3 unassigned YES unset administratively down down GigabitEthernet4 unassigned YES NVRAM administratively down down Loopback1 10.1.1.1 YES manual up up testRT01#write memory 設定変更後にarchive configを確認します。 testRT01#show archive The maximum archive configurations allowed is 14. There are currently 2 archive configurations saved. The next archive file will be named bootflash:-<timestamp>-2 Archive # Name 1 bootflash:-Feb--6-16-05-40.925-0 2 bootflash:-Feb--6-16-10-33.239-1 <- Most Recent 3 4 (省略) ちなみにArchive#1, #2の差分は以下のコマンドで確認可能です。 testRT01#show archive config differences bootflash:-Feb--6-16-05-40.925-0 bootflash:-Feb--6-16-10-33.239-1 !Contextual Config Diffs: +interface Loopback1 +ip address 10.1.1.1 255.255.255.255 ここでArchive#1のコンフィグにロールバックしてみます。設定が完了するまで1分程度かかりました。 testRT01#configure replace bootflash:-Feb--6-16-05-40.925-0 This will apply all necessary additions and deletions to replace the current running configuration with the contents of the specified configuration file, which is assumed to be a complete configuration, not a partial configuration. Enter Y if you are sure you want to proceed. ? [no]: y The rollback configlet from the last pass is listed below: (省略) 実行後Archive#1のコンフィグがrunning-configに反映されます。 testRT01#show ip interface brief Interface IP-Address OK? Method Status Protocol GigabitEthernet1 192.168.3.101 YES NVRAM up up GigabitEthernet2 192.168.4.1 YES manual up up GigabitEthernet3 unassigned YES unset administratively down down GigabitEthernet4 unassigned YES NVRAM administratively down down たしかに先ほど追加したLoopback1が削除されていました。 write memoryを行っていないので、show archive config differenceからロールバックの内容を確認することもできます。 testRT01#show archive config differences nvram:startup-config system:running-config !Contextual Config Diffs: -interface Loopback1 -ip address 10.1.1.1 255.255.255.255 最後に設定保存を行います。 testRT01#write memory Building configuration... [OK] testRT01#show archive The maximum archive configurations allowed is 14. There are currently 3 archive configurations saved. The next archive file will be named bootflash:-<timestamp>-3 Archive # Name 1 bootflash:-Feb--6-16-05-40.925-0 2 bootflash:-Feb--6-16-10-33.239-1 3 bootflash:-Feb--6-16-27-27.278-2 <- Most Recent 4 (省略) 無事に保存されました。 Archive#1, #3 を比較し、たしかにロールバック前の状態と一致していることが確認できました。 testRT01#show archive config differences bootflash:-Feb--6-16-05-40.925-0 bootflash:-Feb--6-16-27-27.278-2 !Contextual Config Diffs: !No changes were found 所感 archive設定を行うことでコンフィグの世代管理やロールバックを実行できることが確認できました。 これまで本番作業では設定戻し用のコンフィグを準備していたのですが、手動で作成すると手間がかかったり作成ミスも発生しやすいので、ロールバックで対応できると嬉しいですね。 今後はGitとの連携などにも手を出してみたいです。 参考 Cisco IOS XE - Configuration Replace and Configuration Rollback
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[iOS/Android]FirebaseAuthの電話番号認証(SMS)にてボット判定(reCAPTCHA 検証)をなくす方法

概要 この記事ではFirebaseAuthの電話番号認証(SMS)にてボット判定(reCAPTCHA 検証)をなくす方法についてご紹介します。 今回iOS,Androidそれぞれボット判定を消す事が出来たのでそれぞれ解説します! そもそもボット判定とは? 以下のような画面を指します。まずこのような画面が表示されたあとに このような画面が出る場合があります。 これをユーザにサインアップ、ログインしてもらう度に実施してもらうのはユーザビリティ的に微妙なので、 上記の画面を消す設定をご紹介します! iOS まずはiOSから説明していきます。 基本的には公式に書いてあるこちらの記事を参考にしてもらえれば大丈夫なのですが、こちらの記事に書かれていない設定がプラスα必要なのでそちらも合わせて解説します。 Xcodeでプロジェクトのプッシュ通知を有効にする こちらの記事の1.のステップにある通りにプロジェクトのプッシュ通知を有効にしてください。 APNs認証キーを登録する 以下の画像のようにFirebaseのコンソールからAPNs認証キーを登録してください。 Remote notificationsを有効にする 公式の記事だとAPNsを登録するまでやればOKなように書かれていたのですが、プラスで設定を追加する必要がありました…!(ここがハマりました) Background Modes -> Remote notificationsを有効にすることでボット判定が出なくなります! Android Androidは公式に書いてあるこちらの記事の通りに実装してもらえれば大丈夫です! Android DeviceCheck APIを有効にする FireBaseに紐づくGCPプロジェクトを有効にします。 有効にすると以下のように表示が変わります。 アプリのSHA-256フィンガープリントを登録する 上記の設定をすることでAndroidでもボット判定が出なくなります! 基本的には公式の通りにやれば大丈夫なのですが、 iOSのRemote notificationsの部分だけ記事を書いた当時記載がなくハマりました。 以上がiOS,Androidの設定方法の解説になります!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

WidgetKitで天気予報アプリ作ってみた〜記事まとめ〜

はじめに この記事はWidgetKitで天気予報アプリ作ってみたシリーズで書いた記事のまとめです。 記事一覧 1.天気情報取得編 2.位置情報取得 & 保存編 3.Widget Extension追加編 4.タイムライン作成編 5.View実装編 誰かの役に立てば幸いです! おしらせ 現在副業でiOSアプリ開発を募集しています。 ご依頼はTwitter DMでお待ちしております。 ↓活動リンクはこちら↓ https://linktr.ee/sasaki.ken
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む