AWSのサービス終了の操作

サービス終了時のAWSの片づけmemoです。AWSサービス機能は多数に分かれていて、どれかどう料金に影響かるのか判断が難しいため、それぞれでのサービスで掃除しました。「システム名を定義できて各サービスを紐づけでき一括削除」とできるようになるとGoodですね。

管理 -> モノ の一覧から、名前の左にチェックを入れて、削除 を選択します。設定のExcportはないようです。潔く削除です。注意点はサーバ毎に設定があり、「東京」以外にも使っていたらそちらも削除です。初期ログインでなぜか「バージニア州」に飛ぶことがあり、残骸が残っていました。


Lambda -> 関数 の一覧から、名前の左にチェックを入れて、削除 を選択します。Application Composer にエクスポートより関数をエクスポートできるようですが、S3(ストレージ) サービスが対象となるようです。ブラウザ上のLambdaエディタからドラックして、ローカルのテキストエディタへコピぺするのが手っ取り早いのようです。

レイヤー( 共通化ライブラリ的なもの ) も残っていたら削除します。こちらは「ダウンロード」からPCローカルにExportできます。バージョンが複数あると、バージョン毎に削除操作が必要です。


DynamoDB -> テーブル の一覧から、名前の左にチェックを入れて、削除 を選択します。Create文等にエクスポートは無いようですが、どこぞやにBackupするか聞いてきます。面倒なのでやめておきます。削除は少し時間がかかります。しばらく 削除中 の表示となります。


AWS Backup -> バックアッププラン から、設定ずみりバックアッププラン を選択し、削除を選択します。バックアップルールリソースの割当て も同時に削除されます。

AWS Backup -> バックアップボールト より、ボールト名 を開き、復旧ポイント名のチェックをいれて 全てを削除 を選択します。件数が多い場合は、一覧の表示件数を100件に切り換えてから操作します。

AWS Backup -> 保護されたリソース に Backup されたデータが残っています。前述のバックアップボールトで削除されます。


API Gateway -> API より、API を一つづつ選択して削除を選択します。こちらもエクスポートは無し。一回の操作で削除できないことがしはしば。数回繰返していると削除できました。


AWS Amplify -> すべてのアプリ から 対象のアプリを開き、削除を選択します。「バックエンド環境があるます」と警告がでます。問題なければ操作を進めます。1分程度かかりました。アプリ表示が残っている場合は、AWS Amplify からWEBページを再表示します。


Amazon S3 -> バケット から、パケットを開いて削除を選択します。


何度か調査で使いましたが、特になにもしなくて良いようてです。実験コードの掃除はしていたかと思います。


インスタンスの一覧では、削除の項目は見当たらず。インスタンスを終了だけしておきました。


ここには色々な権限の情報が残っています。IMA -> ロール を選択し、自分でつくったロール名だけチェックを入れて削除を選択します。

IMA -> ポリシー は、自分でつくったポリシー(タイプの列がカスタマー管理)だけチェックを入れて削除を選択します。ここは一件づつしか削除できません。


S3 よりも高度なストレージです。機能調査に一時使いました。使ったあと掃除していたようです。


バーチャルPC ですかね。機能調査に一時使いました。削除しておきます。

これでAWSサーバの掃除ができました。

以上、結構手間がかかります。半日仕事です。サーバ停止工数も見積に含めましょう。

WordPress のテーマScaffoldで投稿者を非表示にする

他のテーマでは、メニュー項目から投稿者表示をOFFできるようですが、テーマScaffold での情報がありません。調べてみました。テーマは吊るしで使ってるものだと思います。

htmlのコード展開をみると、”byline” “author vcard” のタグつけされています。

WordPress左メニュー「外観」→「カスタマイズ」→「追加CSS」から以下を追加しても効果なし。

動的生成されているなら、phpスクリプト内にありそうです。WordPress左メニュー「外観」→「テーマファイルエディタ」からphpを一つづつ開いて検索してみると以下の場所でした。

編集部を以下のようにコメントアウトして保存します。

これで投稿者名は非表示となりました。

他のテーマでは、cssやメニュー項目から投稿者表示をOFFできるようですが、テーマScaffold では phpスクリプトの修正が必要なようです。

TestFlightにてXamarinアプリをiPhoneにインストールするまで3:XcodeのIPAをUploadを試す

前回記事

次に Xcode で生成した IPA を TestFlight で Uploadとしてみます。 基本的なことができるかトータルの環境をチェックしてみました。Xcodeのバージョンは 14.2 です。

Xamarin.iOSアプリをiPhone上でデバックする場合、先にXcode Projectでダミーアプリ作って iPhone にインストールし、同じハンドル識別子で Vusual Stduio で Project を作り本アプリをiPhoneにインストールします。(当手順のMicrosoftドキュメントはこちら) そのダミーアプリTestFlight で Upload してみます。

デバッグ用のまま Upload すると、CFBundleIconName と 何か画像がないとエラーがでます。

以下のように処置していきます。xcodeの右ペインの「TARGETS」をアプリ本体を選択 → 「General」 → 「App Icons and Launch Screen」→ 「App Icons Source」 にチェックを入れます。この辺りの仕様は、folder指定にの場合があるなどXcodeのバージョンによって変遷があるようです。

Store公開時のアプリアイコンを割当てます。画像は1024×1024で作成し、Projectメニューから既存ファイルの追加で追加しておきます。左ツリーからアプリ本体の「Assets」を開き、「AppIcon」をクリック、AppIconのエリアに画像をドラックします。

Store公開時のアプリサンプル画像を割当てます。画像は、端末機種に合わせて数サイズ作り、Projectに取り込んでおきます。左ツリーからアプリ本体の「Assets」を開き、「Default」をクリック、Defaultのエリアに画像をドラックします。

AccentColor」は未処置でよいようです。

Apple Developer WEBページで、「Capabilities」を”App Attest”、「Distribution」を”App Store Connect”に切替えます。詳しくはこちら同じです

xcodeのメニュー「Product」→「Archive」で公開用buildを実行します。Archive画面が表示されたら、右側の「Distribute App」を押し、Uploadを開始します。

一分程度待ちます。なんと Upload は成功しました。

App Stroe の WEB ページを確認してみると、Uploadされています。

以上のことから、Xamain.iOS側の要因でUploadできない可能性が高いそうです。次回パート4に続きます。

TestFlightにてXamarinアプリをiPhoneにインストールするまで2:XcodeのUpdate後、Xamarinでビルド不能

前回記事

前回から、一か月後、’24年1月21日にアプリを改修してVisual Stdio 2019 For MAC でビルドし、Xcode経由でApp Store へ更新アップロードを試みましたが、エラーとなりました。

一月前はできていたました。弊方の MAC Book Pro 2015 Early で使える iOS Monterey  では、Xcode 14.0 止まりと認識していたのですが、 Xcode 14.2 までUpdate可能となっていたので、「2024になり Appleサーバ が変わり Xcode と互換がなくなった 」のかと、Xcode 14.2 に Update しました。

しかし、Visual Stdio 2019 For MAC 「xcrun: invlid active developer path:」なるBuildエラーが発生しました。

他WEB記事情報によると、コマンドラインから「xcode-select install」を実行すると解消されるとありましたが改善せず。

どうもXcodeに応じた「コマンドラインツール」が必要という理屈のようです。Visual Studio 上にも警告が出てており、そこから「今すぐインストール」を選択しましたがエラーでました。

Xcode 14.2 コマンドラインツール」は、dmg形式のダウンロードもあるので、そちらをインストールしてみても解消せず。

八方塞がりになりましたが、xcode-select コマンドのオプションを観察し、直観でリセット「sudo xcode-select -r」を実行すると解消しました。この時sudo は必須。以下、その時の bash history の内容です。

Visual Studio でBuild時、「Apple SDK Not Found」的なエラーも発生しました。これは Xcode 14.0 → Xcode 14.2 にUpdate にともないSDKパスが変わってしまったようです。これは Microsoft の WEBに説明がありました。Appleのケア不足でがっくりしているところ、Microsoft のケア深さに感銘。メニュー「Visual Studio」→「ユーザ設定」→「SDKの場所」→「Apple」にて、「場所:」を「/Applications/Xcode.app」に変更します。

これで Xcode 14.2 でビルドがとおりました。

しかし、App Store への Uploadエラーは解消せず。パート3につづきます

SHマイコンのC言語組込み関数set_imask中身は?

SHでC言語で作る場合の割り込み禁止は、set_imask関数 です。最近の他ルネサスマイコンでの _EI( )、_DI( ) のように気軽に呼出してよいのでしょうか? アセンブラならシステムレジスタの 割込マスクBit 3つを立てるだけなので、一行で済むはずですが、、、

set_imask() のアセンブラ展開は、

むろん set_imask() はライブラリではなく、直接アセンブラにインライン展開されています。SHは、システムレジスタを直接更新しないポリシーみたいですね。

SH-2A、SH2A-FPUユーザーズマニュアル ソフトウェア編」によりますと、

命令ステート数
システムレジスタ読出し2
20bitデータ転送1
マスク値(レジスタ同士の)の加算1
システムレジスタ書込み 3
7

所要時間は、7ステート × クロック分解能 。100MHzだと、0.07usec。アプリケーションにもよりますが、負荷を気にして使う必要はなさそうです。

しかしながら実際のところ1usオーダーで消費しているように見受けられます。SHの5段パイプラインがこの場合止まってしまうとすると、0.07 x 5 = 0.35usec、もろもろでざっくり 0.5usec。msecオーダーの制御周期であればよいですが、100usec、50us制御周期の場合は厳しくなりそうですね。

他マイコンですと、メインコントロールレジスタに1bit割禁フラグがあって、アセンブラ一行でビット操作命令で割禁フラグを上げ下げできます。RL78なら、

知らずに同じ感覚で念のため程度でset_maskを多用していたら、知らずに性能を圧迫してしまいます。デリケートな割禁部は、後からメンテする人は恐ろしくて外せないでしょう。お困りの方はご相談ください。