Kadinche

はじめに縦書きテキストを画像に埋め込みたいと頼まれたので、Python 製の画像処理ライブラリ Pillow を使ってサクッと実装してみました。一応ソースコードは Gist にもアップ済みです  動作環境Python 3.9.5Pillow 8.2.0画像に縦書きテキストを埋め込むまずは今回利用する Pillow を予めインストールしておきます。pip install Pillowその後 main.py を作成して下記を入力します。テキストを埋め込みたい画像を main.py と同じフォルダに sample.jpeg という名前で配置しておきます。main.py# Pillow の利用するモジュールのみをインポートするfrom PIL import Image, ImageDraw, ImageFont# 読み込みたいフォント情報を入力するfont_name = "/System/Library/Fonts/ヒラギノ角ゴシック W0.ttc"font_size = 48 font = ImageFont.truetype(font_name, font_size)# テキストを埋め込みたい画像 sample.jpeg を読み込むim = Image.open('sample.jpeg')d = ImageDraw.Draw(im)# 画像に埋め込みたいテキスト情報を入力する# (後述するが、改行コードには未対応)text = "bifdLcFCKXtFJZmPZhzdefjhhYTtuJPAYsR"# 文章を改行するまでの文字数を入力するsplit_number = 11# split_number で指定した文字数ごとに分割され配列に格納される# ref: https://qiita.com/yasunori/items/551a7c20ef9b81474e2asplits = [text[i: i+split_number] for i in range(0, len(text), split_number)]# 画像の width を読み込み、画像の右端の座標を取得する# top_right_margin には余白を設定する (描画領域の端が画像の端と被ってしまうため)w, _ = im.sizetop_right_margin = 13right_edge = w - top_right_margin# テキストの入力領域に端が赤い四角形を描画するd.rectangle((right_edge, top_right_margin, right_edge - font_size * len(splits), font_size * split_number + top_right_margin), fill=(255, 255, 255), outline=(255, 0, 0))# 分割した文章を上記四角形内に左にずらしながら縦書き入力するfor index, item in enumerate(splits):  d.text((right_edge - (font_size / 2) - font_size * index, top_right_margin), item, fill="black", anchor="mt", font=font, direction="ttb")# 縦書きテキストを埋め込んだ画像を test.png として出力するim.save("test.png")上記ソースコード内で特筆すべき事項として d.text があります。1まず anchor オプション で文字を横中央に寄せて、縦を上端に寄せるよう設定しています。更に direction オプション を利用することで、文字列を縦に入力しています。縦に入力するためのオプションとして ttb を入力しています。実際に main.py を実行した際に生成される画像は下記のとおりです。テキストを埋め込む前の画像main.py を実行してテキストを埋め込んだ画像おわりに今回は Pillow を用いて縦書きテキストの画像埋め込みを実装しましたが、ブラウザベースで埋め込みをやりたい場合は html2canvas からの png 出力ダウンロードで実装できそうでした。(ただその場合は各種ブラウザ対応とかモバイル対応が大変そう。。   )参考リンクPillow — Pillow (PIL Fork) 8.2.0 documentationText anchors — Pillow (PIL Fork) 8.2.0 documentationImageDraw Module — Pillow (PIL Fork) 8.2.0 documentationPillowを日本語縦書きに対応させる - QiitaEmbedding Japanese vertical writing characters into an image using Pillow.当初は multiline_text 関数 を用いて改行にも対応した形でテキスト埋め込みを実装する予定でした。しかし、ValueError: ttb direction is unsupported for multiline text というエラーが発生してしまい multiline_text 関数の利用は断念しました。。   ↩

Pillow を使って画像に縦書きテキストを埋め込む

Learning Architecture, MessagePipe, and VContainer by Creating a Game Requested by My Own Daughter

Reality Captureでの穴埋め例

はじめにPlayFab で CloudFunction を利用しているときに API 制限に引っかかってしまいました。負荷テストをした際に初めて気づいたのですが、公式ページにも言及が無かったため発覚が遅れてしまいました。そのため、PlayFab に依存していた機能を部分的に外す必要が出てきてしまい苦労しました。本記事では、上記のような事態に陥る方を減らすため、API 制限に気づくまでの軌跡を辿りながら、PlayFab の CloudFunction を利用する際の注意点について、記事として残しておきたいと思います。PlayFab の API 制限に引っかかった要因PlayFab の CloudFunction を利用すると、PlayFab 経由で独自 Web API を実行することが可能になります。また、CloudFunction 経由で独自 Web API を実行すると、PlayFab ユーザ情報が含まれたパラメタが含まれた状態でリクエストが飛んでくるため、その情報を利用することでサーバーサイドで PlayFab の操作を行うことが出来るようになり大変便利です。そのため、あるプロジェクトでは PlayFab CloudFunction を Azure Function や AWS Lambda のような FaaS を使っている感じで利用しておりました。そして、その利用の仕方は誤りであったことに後々気づきます...負荷テストを実装するフェーズで CloudFunction を大量に叩いてみるPlayFab の CloudFunction を実行するにあたり利用した PlayFab の API は Server-Side Cloud Script - Execute Function というものになります。同接 2000 人想定で負荷テストのシナリオを実装することが求められていたため、その通りシンプルに 2000 件同時に Server-Side Cloud Script - Execute Function を実行するシナリオを Gatling で組んでみました。すると、何回やっても数十件以上は必ずエラーが発生していることが分かりました。# Gatling で負荷テストを実行した際に 50件失敗している様子================================================================================---- Global Information --------------------------------------------------------> request count                                       2000 (OK=1950   KO=50    )> min response time                                    320 (OK=320    KO=354   )> max response time                                  14459 (OK=9723   KO=14459 )> mean response time                                   998 (OK=934    KO=3485  )> std deviation                                       1510 (OK=1304   KO=4310  )> response time 50th percentile                        545 (OK=543    KO=656   )> response time 75th percentile                       1085 (OK=1077   KO=7209  )> response time 95th percentile                       2243 (OK=2029   KO=10210 )> response time 99th percentile                       7947 (OK=7775   KO=14353 )> mean requests/sec                                    100 (OK=97.5   KO=2.5   )---- Response Time Distribution ------------------------------------------------> t < 800 ms                                          1393 ( 70%)> 800 ms < t < 1200 ms                                 367 ( 18%)> t > 1200 ms                                          190 ( 10%)> failed                                                50 (  3%)---- Errors --------------------------------------------------------------------> status.find.is(200), but actually found 400                        50 (100.0%)================================================================================正直 2000件程度の API アクセスであれば、何の問題もなく負荷テストが通ると考えていたので、この結果には驚きました。原因は何なのか調べたところ、Azure Function で PlayFab ユーザ認証を行うために利用していた Authentication - Validate Entity Token で 503 エラーが発生していることが分かりました。少ない API 実行件数で負荷テストを実行する場合は問題ないのですが、件数が一定数超えたタイミングで 503 エラーが返却されるようになってしまいます。しかし、たまに同じ件数を実行しているはずなのにスムーズに全件 API 実行に成功することもありました。これは何らかのレートリミット等に引っかかっているのかも知れないということで調査したところ、次の事実が判明しました。CloudFunction は FaaS の用途には適さないどうやら PlayFab 公式フォーラムの ある投稿 によると、PlayFab の Server API を呼び出す際は 10秒間に 1000回という制限があるようでした。 そして、この制限を突破するには商用のための契約をした後にインスタンス割当に関する交渉をすることで可能になるかも知れないとのことでした。Servers are rate limited to 1,000 calls per 10 seconds. What jital is highlighting that the per-player rate should be no more than a few times a minute. A server can call at a higher rate, as it is calling for a lot of users, potentially. If you need a higher limit than 1,000 per 10 seconds, you'll want to talk to our sales team about getting on an Enterprise contract so that we can work with you on custom limits. There's an option on the Contact Us form on the main site to message them, if you want to go that route.つまり、普通に PlayFab を利用している限りはプランをアップグレードしようと制限に引っかかるということが分かりました。 また、今年 1月に投稿された内容 を見るに 10秒以内に 5000以上のユーザーがログイン/登録できたとあり、もう API の 10秒間に 1000回呼び出し制限は撤廃されたのかを聞いているユーザがいたのですが、まだ撤廃されていないと返信されていたので偶然だったようでした。ちなみに私も上記が気になったので、セッションごとにレートリミットのかかり方が変わるのか検証するために異なるユーザ情報を用いてリクエスト 2000件を並列に実行してみましたが、503 エラーは変わらず返却され続けていたので、少なくとも私の手元の環境では効果はなさそうでした。No, the rate limits on the Client and Server API calls has not changed. However, the rate limits are currently enforced on a per-server basis. And since the service runs a great many servers for load balancing, it is possible to exceed those limits from time to time.原因の調査中 PlayFab は EC2 の us-west-2 リージョンでリクエストを受けていそうなことが分かったのですが、そのアクセス先のインスタンスがロードバランサによって分散されているため、レートリミットの制限がインスタンス先により、時と場合によって制限されるかどうかが決まってくるのかもしれないとのことでした。以上のことから、PlayFab の CloudFunction については Azure Function や AWS Lambda のような FaaS のような用途には使わず、あくまでもアプリケーションで補助的に利用するための独自スクリプトを動かす程度に留めて利用するのが正解なように感じました。PlayFab のユーザ認証情報である SessionTicket や EntityToken を利用することで、認証周りの実装部分を省くことが出来るかも知れないと思い期待していたのですが、それは別の BaaS を使うか IaaS で自前で作るのが良さそうでした。おわりにAPI の 10秒間に 1000回呼び出し制限については明示的にドキュメントに記載があるわけでもなかったため、気づくことが出来ずプロジェクト終盤で気づくという事故が起きてしまったのですが、私と似たような境遇に陥る人が少しでも減るようにと記事を書いてみました。とはいえ、少し調べれば出てくるような制限だったので純粋に調査不足だったなあと反省しました。。CloudFunction はとても便利ですが、利用する際は API の呼び出し制限等用法には十分お気をつけてご利用くださいませ。PlayFab が便利な BaaS であることに疑いの余地は無いので今後も利用すると思いますが、知見を貯めつつ効果的に使えるよう勉強していきたいと考えております。また何か知見を得たら随時ブログ記事に書き溜めていきたいと思います。参考リンクAzure 関数を使用した PlayFab CloudScript - PlayFab | Microsoft DocsServer-Side Cloud Script - Execute Function (PlayFab CloudScript) | Microsoft DocsAuthentication - Validate Entity Token (PlayFab Authentication) | Microsoft DocsServer API limitations - Playfab CommunityServer API limitations - Playfab Community

📔 PlayFab の API 制限に引っかかった

はじめにJest でクラスの private readonly な変数を差し替えたい時に若干引っかかったのでメモっておきます。タイトルでは Jest とありますが、本記事の内容は JavaScript でモックする際の有効な手法の 1 つとして利用することが可能です。Object.defineProperty を利用して値を差し替える結論から言うと変数を差し替えたい場合は下記のような記述になります。const mockValue = "";Object.defineProperty(service, "privateReadOnlyValue", {  value: mockValue,});ちなみに関数を差し替えたい場合は下記のような記述になります。Object.defineProperty(service, "privateSumFunction", {  value: jest.fn((a, b) => a + b),});各種テストケースで使いまわしているインスタンスの private readonly な変数をモックした場合、値をリストアしたいケースも出てきました。その場合の記述としては、下記が有効でした。// tmpService 変数に service インスタンスを clone して利用するconst tmpService = Object.create(service);Object.defineProperty(tmpService, "privateReadOnlyValue", {  value: "",});おわりにObject.defineProperty と Object.create を駆使すれば大体のケースでは事足りそうです  参考リンクObject.create() - JavaScript | MDNMocking read-only properties for a class · Issue #2227 · facebook/jest

[Tips] Jest で private readonly な値をモックする方法

Sony ELF-SR1の環境構築と実機でサンプルを動かすまで

はじめにReact に highlight.js を組み込もうとしたのですが、若干躓いてしまったので対処法についてメモっておきます。また、React は既にプロジェクトにインストール済みと仮定します。# 一応 React をインストールするためのコマンドは ↓npm i --save react react-domReact に highlight.js を組み込むまずは highlight.js を NPM or Yarn でインストールします。# NPM で highlight.js をインストールするnpm i --save highlight.jsyarn add highlight.jsその後、React ソースコードに highlight.js を組み込みます。ソースコードの該当部分のみを載せると下記の感じになります。import Head from 'next/head'import styles from '../styles/Home.module.css'import React, { useState, useEffect } from 'react';/**highlight.js を import する*/import hljs from 'highlight.js/lib/core';/**シンタックスハイライトしたい言語のみ import として登録する今回は html をハイライトしたかったので xml を import したデザインは highlight.js/styles/~ を変更することで調整可能https://highlightjs.org/ のトップページから各種デザインについては確認可能(コード右下にある style の右側リンククリックで各種デザインのプレビューが可能)*/import xml from 'highlight.js/lib/languages/xml';import 'highlight.js/styles/github.css';hljs.registerLanguage('xml', xml);let inputChecker = null;export default function Home() {  const [user, setUser] = useState('nikaera');  const [previewUser, setPreviewUser] = useState('nikaera');  const [badgeCode, setBadgeCode] = useState('nikaera');  const [style, setStyle] = useState('plastic')  /**  useEffect のタイミングで hightlight.js の初期化を行う。  called プロパティを false にすることで highlight.js で、  コードが変更された場合でも常にシンタックスハイライトすることが可能  */  useEffect(() => {    hljs.initHighlighting();    hljs.initHighlighting.called = false;  });  useEffect(() => {    /**    シンタックスハイライトしたいコード input フォームへの入力内容に応じて動的に変わる    */    setBadgeCode(`    <div>Hello ${user}!</div>  }`, [user, style]);  });  const handleChange = (event) => {    if (inputChecker)      clearTimeout(inputChecker);    inputChecker = setTimeout(() => {      clearTimeout(inputChecker);      inputChecker = null;      setPreviewUser(event.target.value);    }, 1 * 1000); // 1 seconds    setUser(event.target.value);  };  return (    <div className={styles.container}>      <Head>        <title>Highlight</title>      </Head>      <main className={styles.main}>        <h1 className={styles.title}>          Highlight sample        </h1>        <input type="text" value={user} onChange={handleChange} />        <div>          { /* pre -> code タグ内に highlight.js で            シンタックスハイライトしたい内容を出力する */ }          <pre style={{ width: '80vw' }}>            <code className="xml">              {badgeCode}            </code>          </pre>        </div>      </main>      <footer className={styles.footer}>      </footer>    </div>  )}おわりにReact に highlight.js を組み込むやり方は多々見つけたものの、中々上手くできなかったのでメモっておきました。同様のケースで悩んでいる方の助けになれれば幸いです 参考リンクReact – ユーザインターフェース構築のための JavaScript ライブラリhighlight.js

[Tips] React で highlight.js を適用する方法

はじめにHugo で設定した外部リンクを開くときは別ウィンドウで開けるようにしたかったので、Hugo のテーマファイルをオーバーライドして対応しました。外部リンクが設定されているときのみ a タグに target="_blank" rel="noopener noreferrer" が追加されるようにしました。テンプレートファイルは GO の HTML テンプレートで書かれているので、その書式にしたがって a タグの属性を書き換えることで、外部リンクの場合は target="_blank" rel="noopener noreferrer" を追加します。a タグに外部リンクが設定されていた場合は target="_blank" を付与する下記は hugo-PaperMod で、メインメニューの a タグに target="_blank" rel="noopener noreferrer" を追加するときのサンプルになります。layouts/partials/header.html<ul class="menu" id="menu" onscroll="menu_on_scroll()">        {{- range .Site.Menus.main }}        {{- $is_abs_url := or (strings.HasPrefix .URL "https://") (strings.HasPrefix .URL "http://") }}        {{- $menu_item_url := (cond $is_abs_url .URL (printf "%s/" .URL) ) | absLangURL }}    <li>                <a href="{{ $menu_item_url }}" {{- if $is_abs_url }} target="_blank" rel="noopener noreferrer" {{- end}}>            <span {{- if eq $menu_item_url $page_url }} class="active" {{- end }}>                {{ .Name }}            </span>        </a>    </li>    {{- end -}}</ul>おわりにHugo でページを自分の思い通りカスタマイズするためには、ある程度は Go の HTML テンプレートの知識も必要になりそうです...   参考リンクFunctions Quick Reference | Hugo

[Tips] Hugo で外部リンクを target="_blank" で開く方法

はじめにとある事情で MediaPackage のエンドポイント用の CloudFront ディストリビューションを AWS SDK で作成する機会がありました。その際得た知見をソースコードを交えながら備忘録として記事に残しておきます。本記事内容で紹介しているソースコードは Gist にも同じ内容でアップしてあります。ちなみに MediaLive + MediaPackage + CloudFront の構成でインフラ構築したい場合は、CloudFormation が MediaPackage にも対応したので CloudFormation の利用を推奨します。本記事内容はあくまでも何らかの事情で、後から CloudFront ディストリビューションを MediaPackage エンドポイントに紐づけたいケース等で参考になると思われます。実装内容作成したソースコードの内容は下記になります。最下部の createDistributionForMediaPackage が本記事タイトルに該当する関数です。CloudFrontClientForMediaPackage.tsimport { CloudFront } from "aws-sdk";import * as url from "url";import {    CreateDistributionWithTagsResult,    GetDistributionResult,    UpdateDistributionResult} from "aws-sdk/clients/cloudfront";export class CloudFrontClientForMediaPackage {    private cloudFront: CloudFront;  constructor() {    this.cloudFront = new CloudFront({        region: "ap-northeast-1",        apiVersion: '2020-05-31',    });}/** * CloudFront ディストリビューションの情報を取得するために利用する * @param id CloudFront ディストリビューションの ID * @return ディストリビューションの情報を取得する */  async getDistribution(id: string): Promise<GetDistributionResult> {      const distribution = await this.cloudFront.getDistribution({          Id: id      }).promise()      return distribution;  }  /**   * CloudFront ディストリビューションの設定内容を取得するために利用する   * @param id CloudFront ディストリビューションの ID   * @return ディストリビューションの設定内容を取得する   */  async getDistributionConfig(id: string): Promise<CloudFront.DistributionConfig> {      const config = await this.cloudFront.getDistributionConfig({          Id: id      }).promise()      return config.DistributionConfig;  }  /**   * CloudFront ディストリビューションを削除する   * @param id 削除したい CloudFront ディストリビューションの ID   */  async deleteDistribution(id: string) {    const distribution = await this.getDistribution(id);    await this.cloudFront.deleteDistribution({        Id: id, IfMatch: distribution.ETag    }).promise()  }  /**   * CloudFront ディストリビューションを無効化する   * @param id 無効化したい CloudFront ディストリビューションの ID   * @return 無効化した CloudFront ディストリビューションの情報   */  async disableDistribution(id: string): Promise<UpdateDistributionResult> {      const distribution = await this.getDistribution(id);      const config = distribution.Distribution.DistributionConfig;      config.Enabled = false;      return await this.cloudFront.updateDistribution({        Id: id,        IfMatch: distribution.ETag,        DistributionConfig: config      }).promise();  }  /**   * MediaPackage のエンドポイント用の CloudFront ディストリビューションを作成する   * @param id CloudFront ディストリビューションを判別するための ID   * @param mediaPackageArn MediaPackage チャンネルの ARN   * @param mediaPackageUrl MediaPackage エンドポイントの URL   */  async createDistributionForMediaPackage(      id: string,      mediaPackageArn: string,      mediaPackageUrl: string    ): Promise<CreateDistributionWithTagsResult> {    // 1. url モジュールを用いて URL 文字列をパースする    const mediaPackageEndpoint = url.parse(mediaPackageUrl);    /**    2. MediaPackage のエンドポイント URL から FQDN を取得する。    後述する CloudFront ディストリビューションのオリジンのドメイン名としても利用する    */    const mediaPackageHostname = mediaPackageEndpoint.hostname;    /**    3. MediaPackage のエンドポイント URL のフォーマットは    https://<AccountID>.mediapackage.<Region>.amazonaws.com/**** となっているので、    FQDN の先頭部分を文字列分割で取り出すとアカウント ID が取得できる    */    const accountId = mediaPackageHostname.split('.')[0];    // 4. 後述する CloudFront ディストリビューションのオリジン ID として、アカウント ID を利用する    const targetOriginId = `MP-${accountId}`    /**    5. createDistribution ではなく、createDistributionWithTags 関数で、    CloudFront ディストリビューションを作成する。MediaPackage との紐付けにタグを利用するため。    */    return await this.cloudFront.createDistributionWithTags({        DistributionConfigWithTags: {            Tags: {                Items: [                    /**                    !!!!!重要!!!!!                    6. CloudFront ディストリビューションに紐付けたい                    MediaPackage エンドポイントのチャンネル ARN を                    mediapackage:cloudfront_assoc で定義する。                    mediapackage:cloudfront_assoc を定義することで、                    CloudFront ディストリビューションと                    MediaPackage チャンネルを紐付けることが可能となる。                    */                    {                        Key: 'mediapackage:cloudfront_assoc',                        Value: mediaPackageArn                    },                    {                        Key: 'Id',                        Value: id                    },                    {                        Key: 'Product',                        Value: 'product'                    },                    {                        Key: 'Stage',                        Value: 'dev'                    }                ]            },            DistributionConfig: {                CallerReference: new Date().toISOString(),                Comment: `Managed by MediaPackage - ${id}`,                Enabled: true,                /**                7. CloudFront ディストリビューションのオリジンには 2つ設定します。                1つが MediaPackage のエンドポイントに対するものと、                もう 1つが MediaPacakge サービスに対するものです。                基本的には MediaPackage のエンドポイントに対するオリジンを利用します。                例外時に向けるオリジンが MediaPacakge サービスに対するものになります。                */                Origins: {                    Quantity: 2,                    Items: [                        {                            DomainName: mediaPackageHostname,                            Id: targetOriginId,                            CustomOriginConfig: {                                HTTPPort: 80,                                HTTPSPort: 443,                                OriginProtocolPolicy: 'match-viewer'                            }                        },                        {                            DomainName: 'mediapackage.amazonaws.com',                            Id: "TEMP_ORIGIN_ID/channel",                            CustomOriginConfig: {                                HTTPPort: 80,                                HTTPSPort: 443,                                OriginProtocolPolicy: 'match-viewer'                            }                        }                    ]                },                /**                8. CacheBehaviors のいずれにも当てはまらなかった場合の                キャッシュの振る舞いを定義します。                MediaPackage は タイムシフト表示機能を使用する際等で、クエリ文字列に start, m, end を利用しています。                そのため、それらの文字列は WhitelistedNames に含め QueryString には true を指定しておきます。                DefaultCacheBehavior に引っかかる挙動は例外的扱いなので、                使用するオリジンは MediaPackage サービスのものを設定します。                */                DefaultCacheBehavior: {                    ForwardedValues: {                        Cookies: {                            Forward: 'whitelist',                            WhitelistedNames: {                                Quantity: 3,                                Items: [                                    'end', 'm', 'start'                                ]                            }                        },                        QueryString: true,                        Headers: {                            Quantity: 0                        },                        QueryStringCacheKeys: {                            Quantity: 0                        }                    },                    MinTTL: 6,                    TargetOriginId: "TEMP_ORIGIN_ID/channel",                    TrustedSigners: {                        Enabled: false,                        Quantity: 0                    },                    ViewerProtocolPolicy: 'redirect-to-https',                    AllowedMethods: {                        Items: [                            'GET', 'HEAD'                        ],                        Quantity: 2,                    },                    MaxTTL: 60                },                /**                9. CloudFront のエラーコード全ての TTL に 1sec を設定します。                MediaPackage のエラーのキャッシュが長時間持続してしまうと、                その間は MediaPackage で正常に配信できているとしても、                復旧できない状態となるからです。                */                CustomErrorResponses: {                    Quantity: 10,                    Items: [                    {                        ErrorCode: 400,                        ErrorCachingMinTTL: 1                    }, {                        ErrorCode: 403,                        ErrorCachingMinTTL: 1                    }, {                        ErrorCode: 404,                        ErrorCachingMinTTL: 1                    }, {                        ErrorCode: 405,                        ErrorCachingMinTTL: 1                    }, {                        ErrorCode: 414,                        ErrorCachingMinTTL: 1                    }, {                        ErrorCode: 416,                        ErrorCachingMinTTL: 1                    }, {                        ErrorCode: 500,                        ErrorCachingMinTTL: 1                    }, {                        ErrorCode: 501,                        ErrorCachingMinTTL: 1                    }, {                        ErrorCode: 502,                        ErrorCachingMinTTL: 1                    }, {                        ErrorCode: 503,                        ErrorCachingMinTTL: 1                    }                    ]                },                /**                10. CloudFront ディストリビューションのキャッシュの振る舞いを 2つ定義します。                それぞれの設定内容は基本的に DefaultCacheBehavior で定義したものと同様です。                しかし、利用するオリジンは MediaPackage エンドポイントに向けたものを利用します。                1つは Microsoft Smooth Streaming での配信時に利用する                index.ism に対するもので Smooth Streaming を true に設定しています。                もう 1つは上記 Microsoft Smooth Streaming 以外の                全てに当てはまるストリーミングに適用されるものになります。                */                CacheBehaviors: {                    Quantity: 2,                    Items: [{                        MinTTL: 6,                        PathPattern: 'index.ism/*',                        TargetOriginId: targetOriginId,                        ViewerProtocolPolicy: 'redirect-to-https',                        AllowedMethods: {                            Items: [                                'GET', 'HEAD'                            ],                            Quantity: 2,                        },                        ForwardedValues: {                            Cookies: {                                Forward: 'whitelist',                                WhitelistedNames: {                                    Quantity: 3,                                    Items: [                                        'end', 'm', 'start'                                    ]                                }                            },                            QueryString: true,                            Headers: {                                Quantity: 0                            },                            QueryStringCacheKeys: {                                Quantity: 0                            },                        },                        SmoothStreaming: true                    }, {                        MinTTL: 6,                        PathPattern: '*',                        TargetOriginId: targetOriginId,                        ViewerProtocolPolicy: 'redirect-to-https',                        AllowedMethods: {                            Items: [                                'GET', 'HEAD'                            ],                            Quantity: 2,                        },                        ForwardedValues: {                            Cookies: {                                Forward: 'whitelist',                                WhitelistedNames: {                                Quantity: 3,                                Items: [                                    'end', 'm', 'start'                                ]                                }                            },                            QueryString: true,                            Headers: {                                Quantity: 0                            },                            QueryStringCacheKeys: {                                Quantity: 0                            },                        }                    }]                },                PriceClass: 'PriceClass_All'            }        }    }).promise()  }}createDistributionForMediaPackage で作成したディストリビューションは、公式ページに記載された手順 で作成した CloudFront ディストリビューションと同等のものになります。詳細な説明はインラインコメントにて書きましたが、一応補足説明を少し付け加えておきます。随所に出てくる Quantity についてQuantity には Items で指定する項目の数を入力します。 例えば Headers や QueryStringCacheKeys には Items に何も指定していないため、Quantity に 0 を指定します。しかし、AllowedMethods や WhitelistedNames には Items に指定した項目数である 2 や 3 を Quantity に入力しています。Quantity の数と Items の項目数が合わないと、エラーが発生するため、注意が必要です。mediapackage:cloudfront_assoc を定義する意味CloudFront ディストリビューションのタグに mediapackage:cloudfront_assoc で紐付ける MediaPackage のチャンネル ARN を指定することで、MediaPackage コンソールから紐付けられた CloudFront ディストリビューション情報を参照できるようになります。試しに紐づけられた MediaPackage のチャンネルのエンドポイント詳細ページに遷移すると、下記のような画面が確認できるはずです。mediapackage:cloudfront_assoc で紐付いた CloudFront ディストリビューションが確認できるなお、本記事内のソースコードでは他にも Id, Product, Stage といったタグを定義していますが、MediaPackage とは関係無いものなので削除して問題ありません。updateDistribution を実行する際の注意点これは今回の記事内容とは直接関係ないのですが、地味にハマったので載せておきます。CloudFront では createDistribution の時に要求されるパラメータよりも updateDistribution で要求されるパラメータのほうが多いです。 AWS 公式ページの比較表にある通りです。そのため、updateDistribution で設定を一部更新したいだけなのに、とても多くのパラメータを指定する必要があり非常に面倒です。例えば CloudFront ディストリビューションの Enable/Disable を切り替えるだけでも 30 個近いパラメータを指定する必要あります。上記の入力の手間を省くのには getDistribution で取得した既存のディストリビューション情報を改変する形で updateDistribution のパラメータを作成すると楽でした。今回のソースコードの内容を参照すると disableDistribution が該当します。// 1. getDistribution を実行して CloudFront ディストリビューションの情報を取得するconst distribution = await this.getDistribution(id);// 2. CloudFront ディストリビューションの設定内容を取得するconst config = distribution.Distribution.DistributionConfig;// 3. CloudFront ディストリビューションの Enabled/Disabled を切り替えるオプションを改変するconfig.Enabled = false;// 4. 3. で改変した内容を updateDistribution で CloudFront ディストリビューションに反映するreturn await this.cloudFront.updateDistribution({    Id: id,    IfMatch: distribution.ETag,    DistributionConfig: config}).promise();おわりにニッチな内容なので、本記事内容を今後利用するかどうかは分かりませんが、一応得た知見を記事として残しておきました。同様のことを行う必要が出てきた方の参考になれれば幸いです。参考リンクClass: AWS.CloudFormation — AWS SDK for JavaScriptAmazon CloudFront を MediaPackage に使用する - AWS Elemental MediaPackageRequired fields for creating and updating distributions - Amazon CloudFrontCloudFront と AWS Media Services によるライブストリーミングビデオの配信

MediaPackage 用の CloudFront ディストリビューションを AWS SDK で作成する

はじめにChocolatey 自体はとても便利で気に入っているのですが、管理者権限で PowerShell を実行してから都度 choco install ~ するのが面倒すぎて、何か良い解決策は無いかと調べていました。 一応公式サイトにも 管理者以外でインストール可能にする手順 は掲載されているのですが、私の手元の環境だとエラーが発生してしまいセットアップできませんでした。。  しかし、お手軽に管理者以外でもインストール可能にする方法を他に見つけましたので、備忘録も兼ねて記事として残しておくことにしました  対処法PowerShell を起動して powershell start-process cmd -verb runas を実行する別ウインドウでコマンドプロンプトが起動したら choco install gsudo を実行する先ほどの PowerShell で gsudo choco install ~ でインストールが成功するか確認するpowershell start-process cmd -verb runas コマンドを実行すると、別ウインドウで管理者として実行したコマンドプロンプトが起動します。そこで choco install gsudo を実行することで、Windows 版の sudo である gsudo をインストールします。これで gsudo choco install ~ のような形で PowerShell からコマンドを打ち込むことで、管理者として choco install ~ が実行できるようになりました。今後は管理者として PowerShell を起動せずとも各種ソフトウェアのインストールが Chocolatey で可能になります！  おわりにPowerShell については最近使い始めたせいもあって不慣れなため、本記事タイトルの内容をどう実現すればよいか良く分かりませんでした。。ただ sudo のような仕組みが Windows にもあれば、それだけでサクッと解決できそうだなーと思いググっていたら、非常に楽な解決策を見つけることが出来て満足です  参考リンクmacOS（またはLinux）用パッケージマネージャー — HomebrewChocolatey Software | Chocolatey - The package manager for Windowsgsudo - a sudo for Windowsコマンドから管理者モードでWindows Terminalを起動する

管理者以外も Chocolatey でインストールできるようにする

はじめに本記事ではタイトルの内容に加えて ~/.ssh/config に対する基本的な理解を深めるため、各種設定項目に関する説明も付随して行います。GitHub を例に挙げてはいるものの、Bitbucket や GitLab、Git サーバへ接続する際にも利用可能な ~/.ssh/config の設定について記載しております。~/.ssh/config の書き方SSH キーが未登録の場合は 公式サイトの手順 に従って鍵の生成・登録までを事前に行っておきます。まず GitHub へ接続する ~/.ssh/config の設定を見ていきます。GitHub で認証に使用する SSH キーは登録済みで秘密鍵は ~/.ssh/github へ配置している想定です。~/.ssh/configHost github.com    IdentityFile ~/.ssh/github    User git~/.ssh/config の各種設定項目は下記になります。項目説明Hostホスト名を指定するIdentityFile接続時に使用する秘密鍵を指定するUser接続時のユーザ名を指定する設定を行うことで github.com に SSH 接続する際、ユーザ名に git が指定され、~/.ssh/github に存在する秘密鍵を用いて SSH 接続を試みるようになります。早速 github.com 接続時に正しく認証が通っているか確認するため、適当なプライベートリポジトリを git clone してみます。プライベートリポジトリを git clone した実行結果 (成功)無事に git clone できることが確認できたら成功です。接続先に応じて秘密鍵を使い分けたいGitHub で常に同一の秘密鍵を用いて認証を行う際は問題ないのですが、例えば GitHub アカウントをプライベート用と仕事用で使い分けていて、リポジトリ先に応じて秘密鍵を使い分けたいというケースはあると思います。その場合は ~/.ssh/config の設定と git のリモートリポジトリへの接続情報を変更することで対応可能です。例えばプライベート用の GitHub アカウント A と仕事用の GitHub アカウント B が存在するとします。その際 github-A がホストの時は A の秘密鍵を、github-B がホストの時は B の秘密鍵を利用するための設定は下記になります。~/.ssh/config# プライベート用の GitHub アカウントで利用する接続設定Host github-A    HostName github.com    IdentityFile ~/.ssh/github-A    User git# 仕事用の GitHub アカウントで利用する接続設定Host github-B    HostName github.com    IdentityFile ~/.ssh/github-B    User git新たに HostName という項目を設定しました。HostName には接続先を指定します。HostName は何も指定しない場合 Host と同じ値が設定されます。今回は同一接続先に対してアカウントを切り替えたいので、Host にはアカウント識別可能な値 (ex: github-A, github-B, etc.) を、HostName に接続先である github.com を明示的に指定してアカウント毎に設定をわけました。次に git のリモートリポジトリへの接続情報を変更します。~/.ssh/config に User を指定している場合は該当 Host へ接続時に自動的にユーザが設定されるため、接続 URL からユーザ名である git は取り除いても問題ありません。# 現在のリモートリポジトリ URLgit remote -vorigin  git@github.com:nikaera/private-repository.git (fetch)origin  git@github.com:nikaera/private-repository.git (push)# リモートリポジトリ URL を# git@github.com:nikaera/private-repository.git から# github-A:nikaera/private-repository.git に変更する# (ユーザ名の git は変更先から取り除いている)git remote set-url origin github-A:nikaera/private-repository.git# 新たに設定したリモートリポジトリ URLgit remote -vorigin  github-A:nikaera/private-repository.git (fetch)origin  github-A:nikaera/private-repository.git (push)この状態で先ほど git clone してきたプライベートリポジトリ内で git ls-remote origin コマンドを実行してみて正常に結果が取得できれば正しく設定できています。A の接続設定で git ls-remote origin の実行に成功する次に B のアカウント情報で接続を試みます。# 現在のリモートリポジトリ URLgit remote -vorigin  github-A:nikaera/private-repository.git (fetch)origin  github-A:nikaera/private-repository.git (push)# リモートリポジトリ URL を github-A:nikaera/private-repository.git から# github-B:nikaera/private-repository.git に変更するgit remote set-url origin github-B:nikaera/private-repository.git# 新たに設定したリモートリポジトリ URLgit remote -vorigin  github-B:nikaera/private-repository.git (fetch)origin  github-B:nikaera/private-repository.git (push)B には先ほどのプライベートリポジトリの読み取り権限が無い状態で、git ls-remote origin コマンドを実行してみると失敗するはずです。B の接続設定で git ls-remote origin の実行に失敗するこれで今後は git のリモートリポジトリ URL を一度書き換えておくだけで、それぞれ適切な秘密鍵で GitHub 認証する設定ができました。単に Git サーバに SSH 接続する際の設定情報としては、上記項目を抑えておけば問題無いです。しかし、他にも設定したほうが良い項目や、場合によっては設定が必要な項目も存在します。基本的に設定しておいた方が良い項目他に設定しておいたほうが良い項目には下記があります。~/.ssh/configHost github.com    IdentityFile ~/.ssh/github    User git    IdentitiesOnly yes # IdentityFile で指定した秘密鍵でのみ認証を試みる    Compression yes # Git でのファイル転送時に圧縮する項目説明型IdentitiesOnlyIdentityFile で指定した鍵ファイルでのみ認証を行うかどうか指定するboolean (yes or no)Compression圧縮転送を行うかどうか指定するboolean (yes or no)IdentityFile で指定したファイル以外で認証が通ってしまう状況だと、意図したアカウントで適切に認証が通せていない可能性が出てきてしまいます。そのため、特別な理由がなければ IdentitiesOnly には yes を設定しておいたほうが良いです。IdentitiesOnly を no に設定しておくと ssh-add で登録したキーの中からも認証を試みるようになります。また、Compression についても yes に設定しておくことをオススメします。プログラミングを行っているプロジェクトでは、テキストファイルの数が大半を占めるはずなので、圧縮転送を有効にしておいたほうがファイル転送の速度向上を見込めるからです。ただし Compression は大容量の単一のファイルがアップされているなどして、圧縮効率の悪いファイルを含んでいるプロジェクトの場合は逆に転送速度が低下する恐れもあるので要注意です。接続先によっては設定が必要な項目接続先に応じて設定する必要がありそうな項目には下記があります。~/.ssh/configHost github.com    IdentityFile ~/.ssh/github    User git    Port 12345 # 接続先のポートが 22 以外の場合指定する項目説明型PortSSH 接続時のポート番号を設定するnumber (ex: 22, 22222, etc.)例えば自前で用意した Git リポジトリに対して接続する場合、SSH のポートがセキュリティ上の理由等でウェルノウンポートの 22 ではない場合がありえます。その場合は Port を明示的に指定することで接続時のポート番号を適切な値に設定しておく必要が出てくるでしょう。おわりに今回は GitHub へ SSH 接続する際の例を元に ~/.ssh/config の設定方法について書きました。~/.ssh/config で Host の設定は行っているものの、それに応じて git のリモートリポジトリ URL を変更すべき場合もあることを明示している記事が少なかったので書きました。また、本記事では Git 接続時の ~/.ssh/config の設定にフォーカスを当てましたが、~/.ssh/config についてはサーバに SSH 接続して作業する際に設定しておくと良い項目等もあります。~/.ssh/config の各種設定項目について理解していると頻繁に実行するコマンドのコスト削減ができて便利です。特に @oohira さんの こちらの記事 はとても参考になりました。参考リンクGitHub に SSH で接続する - GitHub DocsSSH 接続をテストする - GitHub Docs~/.ssh/config による快適 SSH 環境 - Qiita

GitHub 接続時の ~/.ssh/config の書き方

はじめに深夜過ぎても眠れず今 5:30 くらいです。おはようございます。眠れないので Twitter してたら Qiita で 湯婆婆を実装してみる のが流行っていることを知ったので fish で実装してみることにしました  ちなみにこの流行を巻き起こした第一人者である @Nemesis さんの 元ネタ記事はこちら です  コードyubaba.fishecho 契約書だよ。そこに名前を書きな。# `-P` がプロンプトで入力受付を行うためのオプションで、# `-l` が入力された内容を `current_name` 変数にセットするためのオプションread -l -P '' current_nameecho フン。$current_nameというのかい。贅沢な名だねぇ。# `current_name_length` の値が 1 以下だったらという条件文set current_name_length (string length (echo $current_name))if test $current_name_length -le 1    set index 1else    # 1 から `current_name_length` までの値をランダムに取得して index 変数にセット    # FYI: random コマンドで指定した START より小さい文字数の文字だと    # `random: END must be greater than START` という警告が出てきてしまうので    # 条件文で 2文字以上の場合のみランダムで文字列を取得するようにしている    set index (random 1 (echo $current_name_length))end# `string split '' <分割したい文字列>` で文字列を 1文字ずつ分割して List として characters にセットset characters (string split '' (echo $current_name))# 文字列の中から適当な 1文字をピックアップset new_name $characters[$index]echo 今からお前の名前は$new_nameだ。いいかい、$new_nameだよ。分かったら返事をするんだ、$new_name!!fish のコードは  のようになります。bash で慣れていると冗長な気がしますが、これには fish 特有の仕様が絡んでいます。 fish では string length $current_name のような形でコマンド置換ができません コマンド実行結果を set 等で変数に代入しておいた上で string length (echo $current_name) のような形で実行することは可能ですコマンド実行時にわざわざ random 1 (echo $current_name_length) のような形で echo を挟んで値をセットしているのは上記が理由です。他の部分の解説は大体ソースコード内にコメントを残してあるので省略します   実行結果いきなり "馬" にされてしまった範馬勇次郎 おまけテストで用いていたスクリプトは下記になります  yubaba-test.fish# yubaba.fish と同じディレクトリに配置して `fish yubaba-test.fish` を実行set names テスト jhondoe 漢字 𠮷 🔨 \nfor val in $names    echo $val | fish ./yubaba.fishendまた、空白の例外処理については入れていないため、空白を入力したときの実行結果は下記になります   虚無おわりに眠れなかったおかげで fish の書き方の勉強が出来てよかったです ただ眠くなるまでの暇つぶしのつもりで fish スクリプト & 記事を書いてたつもりが、ずっと PC ガン見してたせいで余計に目が冴えてきました   フルリモート環境とはいえ昼過ぎから MTG があるので一旦寝ときたいと思います (フラグ  あと Qiita で fish のシンタックスハイライトが使えるようになりたい  参考リンクJavaで湯婆婆を実装してみるIntroduction — fish-shell 3.1.2 documentationAllow command substitution with command builtin · Issue #5575 · fish-shell/fish-shell

fish で湯婆婆を実装してみる

はじめにServerless Framework を使っていて、度々デプロイ時に手動で設定していた作業内容を自動化したいなと思い、プラグイン作成の知識習得も兼ねてライブラリを作成し NPM で公開してみました。serverless-amplify-auth 🔑今後も開発する可能性はありそうなので Serverless のプラグインを TypeScript で作成する際の手順をまとめておきました。各手順はザックリと紹介しつつ、主にその過程でハマった点や工夫した点に重きをおいて記事を書いていきます。動作環境Node.js 12.19.0Serverless FrameworkFramework Core: 2.10.0Plugin: 4.1.1SDK: 2.3.2Components: 3.3.0TypeScript で Serverless Plugin を開発する環境を整える本記事の内容を最後まで実践した際の最終的なプロジェクトのディレクトリ構造は下記になります。tree -I node_modules -L 2 ././├── example # ライブラリの動作検証用のサンプルコードを配置するフォルダ│   ├── handler.js│   ├── package.json│   └── serverless.yml├── lib     # src フォルダ内のファイルをコンパイルした結果を配置するフォルダ (ライブラリとして利用する際に含まれるソースコード群)│   ├── index.js│   └── index.js.map├── package-lock.json├── package.json├── src     # Serverless プラグインのソースコードを配置するフォルダ│   └── index.ts└── tsconfig.json基本的には TypeScriptでServerless FrameworkのPluginを書いてみる | Developers.IO の手順をなぞっていくだけで環境構築自体は可能です。そこで、ここでは自分なりに工夫した箇所について記載していきます。まずは、開発に必要なパッケージを下記コマンドでまとめてインストールします。# TypeScript の開発に必要なパッケージインストールnpm i -D typescript# TypeScript の型定義ファイルのインストールnpm i -D @types/node @types/serverless# 今回は AWS プロバイダー向けの開発を行うため SDK をインストールするnpm i --save aws-sdkTypeScript のコンパイル時に必要となる tsconfig.json は下記のように設定しました。tsconfig.json{  "compilerOptions": {    "target": "es6",    "module": "commonjs",    "moduleResolution": "node",    "strict": true,    "strictBindCallApply": false,    "strictNullChecks": false,    "outDir": "lib",    "sourceMap": true  },  "include": [    "src/**/*"  ]}compilerOptions.strict には true を設定しつつ、compilerOptions.strictNullChecks 等には false を設定することで、部分的に TypeScript のコンパイルチェックを外すようにしました。outDir には lib を指定することで、コンパイルされた TypeScript ファイルは lib フォルダに出力されるよう設定しました。include には src/**/* を明示的に指定しており、src フォルダ内の全ファイルをコンパイル対象にしております。package.json の内容は部分的に抜粋し、説明が必要そうな項目について説明いたします。全容を把握したい方は こちら からご確認いただけます。package.json{  "main": "lib/index.js",  "files": [    "lib"  ],  "scripts": {    "build": "rm -rf lib && tsc",    "test": "echo \"Error: no test specified\" && exit 1"  }}main には src/index.ts をコンパイルすると生成される lib/index.js を指定しました。そのため、ライブラリのエントリーポイントは lib/index.js が設定されます。files には lib フォルダを指定することで、TypeScript をコンパイルした結果のみがライブラリのソースコードとして取り込まれるようになります。TypeScript で Serverless Plugin の開発を進める開発環境が整ったところで早速 Serverless Plugin のソースコードを書いていきます。TypeScript のソースコードは src/index.ts に配置します。Serverless Plugin のプログラムを書くsrc/index.tsimport * as Serverless from 'serverless'import {  SharedIniFileCredentials,  config,} from 'aws-sdk'/** * serverless.yml の custom property の型定義 */interface Variables {  value1: string  value2: number  value3: boolean  profile?: string}export default class Plugin {  serverless: Serverless  options: Serverless.Options  hooks: {    [event: string]: () => Promise<void>  }  variables: Variables  /**   * プラグインの初期化関数。   * 注意点として、初期化関数内では serverless.yml 内の変数展開が行われないので、   * ${ssm:~} 等で設定した値を呼び出しても、適切に値が設定されない状態で呼び出すことになる。   */  constructor(serverless: Serverless, options: Serverless.Options) {    this.serverless = serverless    this.options = options    /**     * serverless.service.custom 内の特定プロパティを取得するための記述     * 今回は Serverless のプラグイン名に serverless-typescript を設定したため、     * serverless-typescript 文字列をキーとして指定する。     */    this.variables = serverless.service.custom['serverless-typescript']    /**     * プラグインがフックする関数を指定する。複数指定することも可能だが、     * 今回は before:package:createDeploymentArtifacts を指定して、     * パッケージングの手前の処理を定義した run 関数でフックする。     */    this.hooks = {      'before:package:createDeploymentArtifacts': this.run.bind(this),    }  }  /**  * before:package:createDeploymentArtifacts 時に実行される関数  */  async run() {    /**    * プラグイン実行時に必要となるフィールドがセットされていなければ処理をスキップする    */    if (!this.variables) {      this.serverless.cli.log(        `serverless-typescript: Set the custom.serverless-typescript field to an appropriate value.`,      )      return    }    /**     * this.serverless.getProvider 関数を用いることで、     * デプロイ時のアカウントの各種情報について取得することが出来る     */    const awsProvider = this.serverless.getProvider('aws')    const region = await awsProvider.getRegion()    const accountId = await awsProvider.getAccountId()    const stage = await awsProvider.getStage()    /**     * serverless.yml で指定した値や AWS 情報が取得できているか、     * 確認するために標準出力する     */    this.serverless.cli.log(      `serverless-typescript values: ${JSON.stringify({        stage: stage,        region: region,        accountId: accountId,        variables: this.variables,      })}`,    )    /**     * プラグイン内で処理を実行する際、別の特定 Profile を用いたい際は、     * AWS SDK の SharedIniFileCredentials を用いて切り替えると楽に切替可能。     * その際は process.env.AWS_SDK_LOAD_CONFIG に値を設定しておくこと     */    if (this.variables.profile) {      process.env.AWS_SDK_LOAD_CONFIG = 'true'      const credentials = new SharedIniFileCredentials({        profile: this.variables.profile,      })      config.credentials = credentials    }  }}module.exports = Pluginソースコード内にいくつかコメントを残しましたが、何点か補足の説明をしていきます。serverless.service.custom['serverless-typescript'] を呼び出すことで、serverless.yml 内の下記の記述内容を Object として取得できます。serverless.ymlcustom:    # custom.serverless-typescript 内の定義を Object として取得可能    serverless-typescript:        value1: "value1"        value2: 0        value3: true        # profile: default (optional)this.hooks には必要に応じてフックを指定します。フックの書き方については 公式ドキュメント に詳細が記載されています。フックの種類については Gist でまとめてくださっている方がいました。this.serverless.getProvider('aws') を用いることで、デプロイ時にアカウントの各種情報について取得することが出来ます。この記述を利用することで Serverless Pseudo Parameters のようなシンタックスを自身のプラグインに取り込むことが可能になります。私が作成したプラグインでも serverless.yml で ARN を構築する際に利用していて、index.ts 内で利用しました。また、プラグイン内でデプロイ時とは異なる Profile を使用したいケースもあるかと存じます。それは AWS SDK の SharedIniFileCredentials を用いることで簡易に実装できました。1それでは、次にプラグインの動作検証用コードを example フォルダに配置していきます。Serverless Plugin の動作検証用プログラムを書くexample フォルダ内には検証用プロジェクトを作成するので、その前準備として example/package.json を作成します。# package.json ファイルを作成するcd example && npm init -yexample/package.json ファイルを作成したら開発用のスクリプトを example/package.json に追記します。example/package.json{  "scripts": {    "prestart": "cd ../ && npm run build",    "start": "sls package",    "test": "echo \"Error: no test specified\" && exit 1"  }}scripts 内の prestart は start スクリプト実行前に実行されるスクリプトです。npm start を実行すると prestart でプラグインの build タスクを実行した後、 Serverless Framework のパッケージングを行うことでプラグインの動作確認が行えます。2次に動作検証用の serverless.yml を example フォルダに配置します。serverless.ymlservice:    name: serverless-typescript    publish: false# プラグイン内で利用する設定値を定義するcustom:    serverless-typescript:        value1: "value1"        value2: 0        value3: true        profile: custom_profileprovider:    name: aws    runtime: nodejs12.x    region: ap-northeast-1# プラグインのパスを指定して読み込むplugins:    localPath: '../../'    modules:        - serverless-typescript# 何でも良いので動作検証用の関数を定義する (関数の定義は後述)functions:    hello:        handler: handler.helloexample フォルダ内に handler.js を配置して functions.hello.handler で用いる検証用の関数を定義します。example/handler.js'use strict';// 検証用の関数。serverless.yml 内では handler.hello で参照可能module.exports.hello = (event, context, callback) => {  callback(null, {    statusCode: 200,    body: "Hello World!"  });};上記作業が完了次第、cd example && npm start を実行して動作検証してみます。cd example && npm start> example@1.0.0 prestart /Users/nika/Desktop/serverless-typescript/example> cd ../ && npm run build> serverless-typescript@1.0.0 build /Users/nika/Desktop/serverless-typescript> rm -rf lib && tsc> example@1.0.0 start /Users/nika/Desktop/serverless-typescript/example> sls packageServerless: Configuration warning at 'service': unrecognized property 'publish'Serverless:  Serverless: Learn more about configuration validation here: http://slss.io/configuration-validationServerless:  # src/index.ts 内の this.serverless.cli.log の出力内容# 各種値が正常にセットされていることが確認出来るServerless: serverless-typescript values: {"stage":"dev","region":"ap-northeast-1","accountId":"XXXXXXXXXX","variables":{"value1":"value1","value2":0,"value3":true,"profile":"custom_profile"}}Serverless: Packaging service...Serverless: Excluding development dependencies...標準出力にあるプラグイン内で出力したログから、適切に値が取得出来ていることが確認出来れば OK です。Serverless プラグインの中で AWS Profile の切り替えが行えるか確認してみるServerless プラグインでの Profile の切り替えについて、動作検証がまだ出来ていないので確認していきます。serverless.yml 内の custom.serverless-typescript.profile に設定箇所は既に用意してあるので、~/.aws/credentials に実在する Profile 名を指定します。serverless.ymlcustom:    serverless-typescript:        profile: <プラグイン実行時に使用したい Profile 名>動作検証のため、src/index.ts 内にログ出力の記述を加えます。src/index.tsimport * as Serverless from 'serverless'import {  SharedIniFileCredentials,  config,} from 'aws-sdk'interface Variables {  value1: string  value2: number  value3: boolean  profile?: string}export default class Plugin {  serverless: Serverless  options: Serverless.Options  hooks: {    [event: string]: () => Promise<void>  }  variables: Variables  constructor(serverless: Serverless, options: Serverless.Options) {    this.serverless = serverless    this.options = options    this.variables = serverless.service.custom['serverless-typescript']    this.hooks = {      'before:package:createDeploymentArtifacts': this.run.bind(this),    }  }  async run() {    if (!this.variables) {      this.serverless.cli.log(        `serverless-typescript: Set the custom.serverless-typescript field to an appropriate value.`,      )      return    }    const awsProvider = this.serverless.getProvider('aws')    const region = await awsProvider.getRegion()    const accountId = await awsProvider.getAccountId()    const stage = await awsProvider.getStage()    this.serverless.cli.log(      `serverless-typescript values: ${JSON.stringify({        stage: stage,        region: region,        accountId: accountId,        variables: this.variables,      })}`,    )    if (this.variables.profile) {      process.env.AWS_SDK_LOAD_CONFIG = 'true'      const credentials = new SharedIniFileCredentials({        profile: this.variables.profile,      })      config.credentials = credentials      // Profile が切り替えられたか確認するためにログを出力する      this.serverless.cli.log(`serverless-typescript profile: ${JSON.stringify(config.credentials)}`);    }  }}module.exports = Plugin早速 cd example && npm start を実行して正常に profile が切り替えられていそうか確認してみます。# 成功時の実行結果cd example && npm start# ...# accessKeyId のフィールドに ~/.aws/credentials 内に存在する値が出力されているServerless: serverless-typescript profile: {"expired":false,"expireTime":null,"refreshCallbacks":[],"accessKeyId":"XXXXXXXXXXXXXX","profile":"XXXXXXXXXXXXXX","disableAssumeRole":false,"preferStaticCredentials":false,"tokenCodeFn":null,"httpOptions":null}# ...ちなみに存在しない Profile を指定した場合の出力は下記のようになります。# 失敗時の実行結果cd example && npm start# ...# accessKeyId のフィールドが存在しない時は Profile が正しく設定出来ていないServerless: serverless-typescript profile: {"expired":false,"expireTime":null,"refreshCallbacks":[],"profile":"custom_profile","disableAssumeRole":false,"preferStaticCredentials":false,"tokenCodeFn":null,"httpOptions":null}# ...おわりに今回初めて Serverless プラグインの開発をしてみて、手軽に出来ることが分かったので自動化出来そうな作業は積極的にプラグイン化していきたいなと感じました。プラグイン化した後は Git リポジトリにアップするだけでなく、NPM のパッケージ や GitHub Packages として公開しておくと、後々プラグインを利用する際に便利です。また、公開してライブラリのスタッツを見るのは案外楽しく開発のモチベーションにも繋がるのでオススメです。参考リンクTypeScriptでServerless FrameworkのPluginを書いてみる | Developers.IOtypescript導入したprivateなnpmパッケージの作り方 - 30歳SIerからWEBエンジニアで奮闘How To Write Your First Plugin For The Serverless Framework - Part 1注意点として、SharedIniFileCredentials を用いてプロファイルを切り替える時は、環境変数に AWS_SDK_LOAD_CONFIG="true" を設定する必要がありました。設定しないと ConfigError: Missing region in config というエラーが発生してしまい、プロファイルを切り替えることが出来ませんでした。。 ↩今回は Serverless の before:package:createDeploymentArtifacts フックを利用しているので、sls package コマンドで動作検証が可能となっている。before:deploy:deploy 等のデプロイ中に実行されるフックを利用する際は sls deploy --noDeploy コマンド等で動作検証を行う必要がある。 ↩

Serverless のプラグインを TypeScript で作成する方法

Azure Functions の開発環境を NestJS で構築する方法

はじめにAndroid Studio 4.1系からIntelliJ IDEAのベースバージョンが2020.2に上がったので公式の日本語パックを導入できるようになりました。ですがランタイムが古く文字化けしてしまうので解消します。手順とランタイムの最新バージョンは以下のリンクで確認できます。JetBrainsデスクトップ製品の日本語化Android Studio 4.1 Beta 1で文字化けが発生するJetBrains Runtimeランタイムを変更するPluginsのMarketplaceタブからChoose Runtimeをインストールする。Ctrl + Shift + AでFind Actionを開いてchooseを入力して絞り込む。Choose Runtimeを開いて最新版のJetBrains Runtimeを選択する。現時点で1035.1が最新でした。Android Studioを再起動する。日本語パックをインストールするPluginsのMarketplaceタブからJapanese Language Packをインストールする。Android Studioを再起動する。以上で日本語パックを導入できます。

Android Studio 4.1 RC1で公式日本語パックの導入と文字化けを解消する

はじめに開発中盤で AppSync で開発している最中に追加したデータが、突然 List Query で取得出来ない事態が発生しました...  調査したところ、AppSync のデータソースで DynamoDB のデータソース生成した際に GraphQL を自動生成したのですが、そこにヒントがあることを発見しました結局の所、DynamoDB への理解不足で片付く話なのですが、、何となく AppSync を使っていると遭遇してしまう問題だと思います...   そこで、同じ問題で悩む人を助けられればと思い、記事に残しておくことにしました  DynamoDB に登録されているはずのデータが AppSync の List Query で取得したデータに含まれない事象が発生することがあるAppSync で開発を開始した直後や、登録データ数が少ない間は List Query の filter を用いてデータの絞り込みを行いつつ、正常に意図したデータが取得出来るはずです  しかし、ある日 DynamoDB にデータが登録されているのに List Query の filter で、正常に意図したデータが取れない事象が特定の List Query で発生するようになってしまいました... DynamoDB には channel_id が 42713673-eb21-43ef-bdbc-f460989fb505 でデータが 1件登録されていることは確認済みなのに AppSync の List Query では 1件も取得できないのは何故でしょうか。。？？DynamoDB データソース追加時に自動生成されたリゾルバを確認してみるDynamoDB のデータソース登録時に自動で GraphQL 生成にチェックを入れていれば、AppSync の List Query は自動生成され DynamoDB リゾルバが登録されています  原因調査のため AppSync の裏の DynamoDB リゾルバが何を行っているか中を覗いてみます  を見ると、Scan を用いて filter で検索条件を絞って limit で指定した件数のデータが取得出来るようになっているように見受けられます DynamoDB の Scan の仕様を確認する次に DynamoDB の公式ドキュメント を見て Scan の仕様について確認していきます。早速公式ドキュメントのトップに Scan についての説明が記載されていました  Amazon DynamoDB での Scan オペレーションは、テーブルまたは セカンダリインデックス のすべての項目を読み込みます。デフォルトでは、Scan オペレーションはテーブルまたはインデックスのすべての項目のデータ属性を返します。 を見ると Scan はデフォでレコードを全件取得するような挙動となるようです。結果セットの項目数の制限ドキュメントを読み進めていくと、次に 結果セットの項目数の制限 の項目が目に止まりました  ここで、Scan にフィルタ式を追加するとします。この場合、DynamoDB は返される 6 つの項目にフィルタ式を適用し、一致しない項目を廃棄します。最終的な Scan 結果はフィルタリングされる項目の数に応じて、6 つ以下の項目を含みます。 を見ると Scan の filter を使用した際の挙動として 一致しない項目を廃棄します とあります  AppSync の DynamoDB リゾルバを確認した際、Scan の limit はデフォでは 20 でした。つまり、正常にデータが取得出来なかった AppSync の List Query を元に、実際に実行された DynamoDB の Scan の挙動を推測すると、データを 20件取得した中に該当する channel_id のデータが見つからなかったので空を返したという挙動になりそうです  RDBMS の SQL の Where 句のような、該当する channel_id のデータを 20件まで検索して取得するという挙動を想定していましたが、それがそもそもの誤りだったようです...  スキャンの読み込み整合性更にドキュメントを読み進めていくと スキャンの読み込み整合性 という項目も発見しました  Scan オペレーションは、結果的に整合性のある読み込みをデフォルトで行います。つまり、Scan 結果が、最近完了した PutItem または UpdateItem オペレーションによる変更を反映しない場合があります。詳細については、「Read Consistency」を参照してください。強力な整合性のある読み込みが必要な場合は、Scan が開始する時に ConsistentRead パラメータを true リクエストで Scan に設定できます。これにより、Scan が開始する前に完了した書き込みオペレーションがすべて Scan 応答に含められます。 を見ると RDBMS では保証されている一貫性は無いので、Scan を実行するタイミングによって取得可能なデータは変動する可能性があるということを Scan を用いたデータ取得を行う際は考慮する必要がありそうです 対策方法まず、AppSync の limit がデフォで 20 なので GraphQL クエリの limit を 100 等の、一度の Query で filter で絞り込むデータが十分に取得出来そうな数に設定しておきます1 また、Web アプリケーション等でよく使用される、画面最下部までスクロールした際にロードを行う処理の実装等を考慮した場合、nextToken を用いたページネーションの実装も考慮しておく必要があります   の流れで List Query を実行するようにしておけば、画面最下部までスクロールした際のロード処理が実装可能です  おわりに結果 AppSync というよりも DynamoDB の仕様にフォーカスに当たった記事内容になりました AppSync の DynamoDB リゾルバを雰囲気で扱っていたため起きた問題で、ステージング環境で実際にデータがある程度追加されてきてから問題が発覚したため、個人でデバッグしているときには全く気づくことが出来ませんでした...   また保守運用の観点から予め DynamoDB の設計についても考慮しておいたほうが良いと思われます  公式ドキュメントに DynamoDB の設計のベストプラクティス についての解説ページがあるので読んでおいた方が良さそうです  以上 AppSync を用いる際に DynamoDB リゾルバを自動生成して利用する際は十分にご注意ください  参考リンクDynamoDB のリゾルバーのマッピングテンプレートリファレンス - AWS AppSyncDynamoDB でのスキャンの使用Amazon DynamoDBのNextTokenを使ったページネーションの挙動を調査したDynamoDB を使用した設計とアーキテクチャの設計に関するベストプラクティス大量のデータが登録されている状況であれば Scan の Query から limit は無くしてしまい、一度の Scan で最大の 1.0MBまでのデータを取得するようにして良いかも知れません ↩

AppSync の DynamoDB リゾルバの Scan で意図したデータが取得出来なくなった時の対処法

はじめにAppSync の Lambda リゾルバを書く際に Serverless Framework を使用したのですが、デプロイ後のバグ調査の際、毎回ブラウザから AWS Console を開いて該当 Lambda の CloudWatch のログを見に行くのが面倒でした。。  そのため、エラーレポートの仕組みが欲しくなり、Lambda のエラーを Slack に通知する仕組みを Serverless Framework で実装する方法について調査したので、備忘録も兼ねて記事にまとめました 追記 (2020/08/19)ローカルから Lambda 関数のログを確認したいだけなら、Serverless Framework CLI の logs コマンド もしくは、 AWS CLI の logs コマンド で可能みたいです 動作環境Serverless Framework 1.78.1Node.js 12.18.1Slack Incoming Webhooks 5.0.3AWS SDK for JavaScript 2.518.01. Slack で Webhook URL を発行するまずは 公式サイトの手順 に従って Webhook URL を発行します  無事発行できると、https://hooks.slack.com/services/~~~~~/~~~~~/~~~~~~~~~~~ のようなフォーマットの URL が取得出来るはずなのでメモっておきます 2. 必要な npm パッケージをインストールするSlack の Incoming Webhook の仕組みを使用し、チャンネルにメッセージを送信するための npm パッケージをインストールします npm install @slack/webhook --save3. Slack にエラーレポートを送信する Lambda 関数を作成する (TypeScript)Serverless Framework の handler に Slack にエラーレポートを送信する関数を追加します  handlers/Reporter.tsimport { gunzip } from "zlib";import { IncomingWebhook } from "@slack/webhook";/** * CloudWatch のログ情報 */interface CloudWatchLogContent {  messageType: string;  owner: string;  logGroup: string;  logStream: string;  subscriptionFilters: string[];  logEvents: {    id: string;    timestamp: string;    message: string;  }[];}/** * Lambda リゾルバの型定義 */type LambdaResolver<TEvent = any> = (event: TEvent) => Promise<any> | any;/** * CloudWatch のロググループに出現するエラーを通知する * @param event 該当するエラーログの内容 * @return {object} event オブジェクトをそのまま返却する */export const NotifyError: LambdaResolver = async (event: any) => {/**{  awslogs: {    data: 'H4sIAAA...'  }}CloudWatch から呼ばれた際の event には上記フォーマットでデータが入っている。data 内には Base64 でエンコードされた gzip 形式で圧縮されたデータが入っているので、gzip 形式のデータを解凍しつつ、Base64 デコードを行い JSON 文字列を取得するための関数*/  const gunzipAsync = async (base64Logs): Promise<string> => {    return new Promise(function (resolve, reject) {      gunzip(base64Logs, function (err, binary) {        err ? reject(err) : resolve(binary.toString("ascii"));      });    });  };// 1. Base64 でエンコードされた gzip 形式で圧縮されたデータを Base64 でデコードし、gzip のバイナリとして取得する// gunzipAsync 関数で gzip 解凍して ascii 文字列として取得することで CloudWatch のログ内容を JSON 文字列で取得する  const base64Logs = Buffer.from(event["awslogs"]["data"], "base64");  const uncompressedLogs = await gunzipAsync(base64Logs);  console.log(uncompressedLogs);// 2. 取得した JSON 文字列を CloudWatchLogContent に変換して取得する  const content = <CloudWatchLogContent>JSON.parse(uncompressedLogs);  console.log(content);// 3. 発行した Slack の Webhook URL で IncomingWebhook クラスを生成し、// send 関数で Slack チャンネル名 (ex. #serverless-error-report) と、// CloudWatchLogContent の内容を元に作成したテキストを引数に指定して、// 該当する Slack チャンネルにテキストを投稿する  const webhook = new IncomingWebhook("<1. で発行した Slack の Incoming Webhook URL>");  await webhook.send({    channel: "<通知したいチャンネル名 (例: #serverless-error-report)>",    icon_emoji: "hammer", // icon_emoji パラメタを指定すると Slack へのメッセージ通知の際のアイコンを変更することが可能    text: `*Group*\n_${content.logGroup}_\n\n*Message*\n\`\`\`${content.logEvents[0].message}\`\`\``,  });  return event;};4. 3. の関数をデプロイする関数として追加し、各種 Lambda 関数の CloudWatch のログを監視するイベントと紐付けるserverless.yml に 手順 3. で作成した関数 NotifyError を記載すると共に、監視したい関数の CloudWatch ロググループを events の cloudwatchLog に定義し、filter に ERROR を指定します  これで、該当ロググループに ERROR が含まれていた場合、都度 Lambda 関数が実行されるようになります   serverless.yml#...# 3. で作成した Slack にエラーレポートを送信する関数 NotifyError を functions に追記し、# events を用いて、他 Lambda 関数のロググループに 'ERROR' が出力されていた場合、 NotifyError 関数が実行されるようにするfunctions:#...  NotifyError:    handler: CloudWatch.NotifyError    events:      - cloudwatchLog:          logGroup: /aws/lambda/${self:service.name}-${self:provider.stage}-TestFunction1          filter: ERROR      - cloudwatchLog:          logGroup: /aws/lambda/${self:service.name}-${self:provider.stage}-TestFunction2          filter: ERROR      - cloudwatchLog:          logGroup: /aws/lambda/${self:service.name}-${self:provider.stage}-TestFunction3          filter: ERROR#... が完了したら sls deploy で NotifyError 関数をデプロイします 最後に AWS CLI で CloudWatch にイベントログデータを送信してみて、本当に Slack に通知が飛んでくるか動作確認を行いましょう 注意事項 (複数の cloudwatchLog を定義した場合)events に複数の cloudwatchLog を定義した場合、関数のデプロイ後、AWS Console で該当する Lambda 関数を見に行くと、正しく CloudWatch のイベントが紐付けられていないように見えます 同様のケースが発生している方は他にもいらっしゃるようですが、手順 5. で Slack への通知まで確認出来れば問題なく設定できています 5. AWS CLI を利用してCloudWatch にイベントログデータを送信して Slack に通知が飛んでくるか検証するCloudWatch にイベントログデータを送信するコマンドです  aws logs put-log-events \    --log-group-name '<該当するロググループ名>(例: /aws/lambda/test-dev-TestFunction1)' \    --log-stream-name '<ログストリーム名(例: test-stream)>' --log-events \    timestamp=(node -e 'console.log(Date.now())'),message="This is ERROR"コマンド実行後、AWS Console から CloudWatch の該当するロググループのログストリームを見に行くと、This is ERROR という文字列が出力されている事が確認できるはずです あとは Slack に通知が飛んできたことまで確認できれば動作確認完了です！   おわりにServerless Framework 内で完結する形で、Lambda 関数のエラーを捕捉して Slack に通知を飛ばす方法についてまとめました events には cloudwatchLog の他にも eventBridge というものも指定できます。eventBridge を使用すると CloudWatch 以外の様々な AWS サービスのイベント駆動で Lambda 関数を実行することが可能です events を有効活用することで効率よくイベント駆動の処理を書いていけるので、是非とも有効活用していきましょう！  参考リンクServerless Framework - AWS Lambda Events - CloudWatch LogEventBridgeとLambdaを連携させるServerless Frameworkの設定方法サーバーレスイベントバスのAmazon EventBridgeaws-cliでAWS CloudWatchにログを書き込む

Serverless Framework でエラーを検知して Webhook で Slack に通知を飛ばす方法

はじめにRoslynはC#の構文解析やコード評価を行えるライブラリでC# 6以降のコンパイラでも使われています。Roslynを利用すると構文解析された結果を利用できるので文字列比較や正規表現と比べると解析漏れをなくせます。RoslynのインストールはNuGetで使えますがUnityだと重複するdllがありそのままでは導入できません。それをUPMで簡単に導入する方法が分かったのでまとめてみました。UPM化されたRoslynのドキュメント Code AnalysisUnityでは以下のプロダクトでRoslynが使われています。UPMのImmediate WindowUtf8JsonのUtf8Json.UniversalCodeGeneratorMessagePack-CSharpのMessagePack.Generator環境構築Unity2018.3以上Package Managerから Add package from git URL... できるバージョンでは com.unity.code-analysis を追加するPackage Managerから Add package from git URL... できないバージョンでは Packages/manifest.json に "com.unity.code-analysis": "0.1.2-preview", を追加するインストールできると以下のようにPackage Managerに追加されます。インストールだけではDLLを参照できないのでRoslynを使いたいスクリプトフォルダにアセンブリ定義を作り、以下の設定を変更します。一般 > リファレンスをオーバーライドをチェックアセンブリ参照に Microsoft.CodeAnalysis で始まるdllを追加エディタ拡張で使うならプラットフォームの Editor のみをチェック、アプリ内で使うならデフォルトの 任意のプラットフォーム のままでOKRoslynのサンプルScripting API SamplesとGetting Started C# Syntax Analysisを参考にサンプルを実行してみます。それぞれcode欄に実行または解析するコード、result欄にその結果を表示しています。また実行できるUnityプロジェクトは https://github.com/shiena/UnityRoslynSample にありメニューの Tools > Roslyn Sample を選択するとウインドウが開きます。Evaluate a C# expressionコードを実行します。string code = "1 + 2";var result = CSharpScript.EvaluateAsync(code);Evaluate a C# expression (strongly-typed)ジェネリクスで結果の型を指定してコードを実行します。string code = "1 + 2";var result = CSharpScript.EvaluateAsync<int>(code);Parameterize a scriptクラス定義したパラメータをコードに適用して実行します。public class Globals{    public int X;    public int Y;}string code = "X+Y";var globals = new Globals {X = 1, Y = 2};var result = CSharpScript.EvaluateAsync<int>(code, globals: globals);Query Methodsコードを解析してMainメソッドの最初の引数を出力します。string code =            @"using System;using System.Collections;using System.Linq;using System.Text;namespace HelloWorld{    class Program    {        static void Main(string[] args)        {            Console.WriteLine(""Hello, World!"");        }    }}";SyntaxTree tree = CSharpSyntaxTree.ParseText(code);var root = (CompilationUnitSyntax) tree.GetRoot();var firstMember = root.Members[0];var helloWorldDeclaration = (NamespaceDeclarationSyntax) firstMember;var programDeclaration = (ClassDeclarationSyntax) helloWorldDeclaration.Members[0];var mainDeclaration = (MethodDeclarationSyntax) programDeclaration.Members[0];var argsParameter = mainDeclaration.ParameterList.Parameters[0];var firstParameters = from methodDeclaration in root.DescendantNodes()                .OfType<MethodDeclarationSyntax>()            where methodDeclaration.Identifier.ValueText == "Main"            select methodDeclaration.ParameterList.Parameters.First();var argsParameter2 = firstParameters.Single();SyntaxWalkersコードを解析してSystemまたはSystem.以外で始まるusingを出力します。class UsingCollector : CSharpSyntaxWalker{    public readonly List<UsingDirectiveSyntax> Usings = new List<UsingDirectiveSyntax>();    public override void VisitUsingDirective(UsingDirectiveSyntax node)    {        if (node.Name.ToString() != "System" &&            !node.Name.ToString().StartsWith("System."))        {            this.Usings.Add(node);        }    }}string code =            @"using System;using System.Collections.Generic;using System.Linq;using System.Text;using Microsoft.CodeAnalysis;using Microsoft.CodeAnalysis.CSharp;namespace TopLevel{    using Microsoft;    using System.ComponentModel;    namespace Child1    {        using Microsoft.Win32;        using System.Runtime.InteropServices;        class Foo { }    }    namespace Child2    {        using System.CodeDom;        using Microsoft.CSharp;        class Bar { }    }}";SyntaxTree tree = CSharpSyntaxTree.ParseText(code);var root = (CompilationUnitSyntax) tree.GetRoot();var collector = new UsingCollector();collector.Visit(root);参考リンクUPMのImmediate WindowUtf8JsonのUtf8Json.UniversalCodeGeneratorMessagePack-CSharpのMessagePack.GeneratorUPM化されたRoslynのドキュメント Code AnalysisUnity Roslyn Sample

UnityでもRoslynで構文解析やコード評価したい

はじめにReact Nativeのrun-androidコマンドはPCに接続したAndroid端末すべてにapkをインストールします。一方で--deviceIdでデバイスIDを指定すると特定のAndroid端末だけにapkをインストールできます。ですがデバイスID指定ありとなしでは実行されるGradleタスクに違いがあったので調べた結果をまとめました。バージョン@react-native-community/cli-platform-android: 4.9.0実行されるタスクの調査方法react-native コマンドの --verbose オプションを指定すると実行されるコマンドが分かるのでこれで確認します。デバイスIDを指定しない場合$ react-native run-android --verboseinfo Running jetifier to migrate libraries to AndroidX. You can disable it using "--no-jetifier" flag.Jetifier found 1041 file(s) to forward-jetify. Using 8 workers...info JS server already running.info Installing the app...debug Running command "cd android && gradlew.bat app:installDebug -PreactNativeDevServerPort=8081"app:installDebugタスクが実行されています。これはアプリをビルドして全Android端末にapkをインストールします。デバイスIDを指定する場合$ react-native run-android --verbose --deviceId xxxxxinfo Running jetifier to migrate libraries to AndroidX. You can disable it using "--no-jetifier" flag.Jetifier found 1391 file(s) to forward-jetify. Using 8 workers...info JS server already running.info Building the app...debug Running command "gradlew.bat build -x lint"buildタスクが実行されています。これはアプリのビルド、テスト、Javadocのビルドなどが実行されます。更に--tasksオプションでタスクを指定しても反映されないのでビルド以外のタスクを除外できません。apkビルドだけで特定の端末にインストールしたい現状はオプションなどで変更できないので以下のどちらかしかなさそうです。インストールしたくないAndroid端末の電源を切るかUSBケーブルを抜くnode_modules/@react-native-community/cli-platform-android/build/commands/runAndroid/index.jsのbuildApk内の"build"を"assembleDebug"に書き換える以下のPull Requestが取り込まれるとビルドコマンドが統一されてassembleDebugタスクに置き換わるので将来的には解消しそうです。refactor: unify APK building and installing process #1055

React Nativeのrun-androidはデバイスIDの有無で実行されるタスクが違う

はじめにReact NativeのAndroidプロジェクトで変則的なフォルダ構成だったのでGradleでうまく扱う方法を紹介します。サブフォルダや同じ階層のフォルダの場合はGradleでマルチプロジェクトで実現できます。フォルダ構成myapp/  android/ ★rootプロジェクト    build.gradle    settings.gradle ★これを編集する    app/ ★アプリプロジェクト      build.gradlelibrary/  android/ ★ライブラリプロジェクト    build.gradle設定settings.gradleinclude ':app'// ここから追加include ':library'project(':library').projectDir = file('../../library/android')// ここまで追加参考サイトRequire Gradle project from another directoryGradleでマルチプロジェクト

Gradleで任意のフォルダのプロジェクトを追加する

Unity Androidプラグインの手間を軽減する管理方法

はじめにOculus Storeからアプリを配布する時はOculus Platform APIが必須になっています。そのOculus Platform APIは結果をコールバックで返すので処理が冗長になってしまいますが簡単にTask化できたので紹介します。開発環境System.Threading.Tasksを扱える設定およびバージョンのUnityUnity2017 + Experimental (.NET 4.6 Equivalent)Unity2018 + .NET 4.x EquivalentUnity2019以上Oculus Integration v1.41.0以上コールバックの場合以下はエンタイトルメントチェックのベストプラクティスのサンプルコードです。Oculus Platform APIはIsUserEntitledToApplication()のようにOnComplete()で結果が返ってくるので同様の呼び出しが続くとコールバック地獄になって処理の流れが分かりにくくなります。using UnityEngine;using Oculus.Platform;public class AppEntitlementCheck: MonoBehaviour {  void Awake ()  {    try    {      Core.AsyncInitialize();      Entitlements.IsUserEntitledToApplication().OnComplete(EntitlementCallback); // ここがコールバック    }    catch(UnityException e)    {      Debug.LogError("Platform failed to initialize due to exception.");      Debug.LogException(e);      // Immediately quit the application.      UnityEngine.Application.Quit();    }  }  void EntitlementCallback (Message msg)  {    if (msg.IsError)    {      Debug.LogError("You are NOT entitled to use this app.");      UnityEngine.Application.Quit();    }    else    {      Debug.Log("You are entitled to use this app.");    }  }}Taskへ変換するスクリプティング定義シンボルにOVR_PLATFORM_ASYNC_MESSAGESを追加します。するとTaskを返すGen()メソッドがOculus.Platform.Requestクラスで使えるようになるので以下のように書く事ができます。private async void Awake(){    try    {        if (!Core.Initialized())        {            var initialized = await Core.AsyncInitialize().Gen(); // ここをTask化            if (initialized.IsError)            {                Debug.Log($"failed initialize: {initialized.GetError().Message}");                return;            }        }        var entitlements = await Entitlements.IsUserEntitledToApplication().Gen(); // ここをTask化        if (entitlements.IsError)        {            Debug.Log($"failed entitlement: {entitlements.GetError().Message}");            return;        }        var user = await Users.GetLoggedInUser().Gen(); // ここをTask化        if (user.IsError)        {            Debug.Log($"failed get user: {user.GetError().Message}");            return;        }        Debug.Log($"{user.Data.ID}, {user.Data.OculusID}");    }    catch (UnityException e)    {        Debug.LogException(e);        Application.Quit();    }}更にUniTaskと組み合わせるとタイムアウトも簡単に扱えます。var initialized = await Core.AsyncInitialize().Gen().AsUniTask().Timeout(TimeSpan.FromSeconds(10));1つ残念なのはGen()が返すTaskはTaskCompletionSourceで作られてprivateフィールドにあるのですがTrySetCanceled()を呼ぶメソッドが用意されていないのでCancellationTokenでキャンセルできない事です。どうしてもキャンセルしたい場合はSDKに多少の変更が必要です。

Oculus Platform APIをコールバックからTaskへ変換する

はじめにGitHubの複数アカウントを使い分けるには片方のアカウントでSSH接続する方法があります。ですがGitHubでGit LFSのファイルはhttpsのみでSSHにできないのでダウンロードできません。そこでCredential Managerのnamespaceで複数アカウントをhttpsで使い分けます。必須環境Git for WindowsのインストールウィザードでEnable Git Credential ManagerをチェックしてCredential Manager for Gitを一緒にインストールします。メインアカウントの設定特に設定は不要です。git cloneなどを行って認証するとコントロールパネルの資格情報マネージャーのWindows資格情報にgit:https://github.comが追加されます。サブアカウントでの設定Credential Managerでnamespaceを設定すると資格情報の先頭のgit:が変わり複数のアカウントを使い分けることができます。cloneする時はnamespaceが設定されていないので-c credential.namespaceで指定します。指定する名前はgit以外の英数字なら何でも構いません。git -c credential.namespace=sub clone https://github.com/[name]/[repository].gitダイアログが出てくるのでサブアカウントのアカウントとパスワードを入力します。cloneできたらローカルコンフィグにcredential.namespaceを設定します。cd [repository]git config credential.namespace subpushして失敗しない事を確認します。git pushcloneして認証が通った後に資格情報マネージャーを開くとsub:https://github.comが追加されています。詳しくはCredential Manager for Windowsのcredential.namespaceを参照してください。注意点git configのConditional Includesを使うとgitdir:で指定したフォルダにcredential.namespaceを設定できそうですがCredential ManagerがConditional Includesに対応していないので利用できません。issuesに要望を上げたので興味ある方はリアクションやコメントをお願いします。Add support conditional includes #903参考リンクHow to store credentials for two different github accounts? #749credential.namespace

WindowsでGitHubの複数アカウントをhttpsで使い分ける

はじめにPCに複数のadbやAndroid SDKがインストールされている時に起動中のadb serverと違うバージョンのadbを実行するとadb serverが再起動してしまいます。そのため、なるべく同じバージョンのadbを実行するPowerShellの関数を作りました。スクリプトPowerShellの$profileに以下のスクリプトを追加してadbを実行すると以下の順番でadbコマンドを探します。実行中のadb server実行中のUnityから一緒にインストールしたAndroid SDKのadbAndroid StudioからインストールしたAndroid SDKのadb環境変数PATHのadbfunction FindAdb() {    # find from process list    $adbPath = Get-Process -Name "adb" -ErrorAction Ignore |        Sort-Object Id |        Select-Object -First 1 -ExpandProperty Path    if ($null -ne $adbPath) {        return $adbPath    }    # find from Unity in process list    $adbPath = Get-Process -Name "Unity" -ErrorAction Ignore |        Select-Object @{            label="adb"            expression={                Join-Path (Split-Path $_.Path) "Data" "PlaybackEngines" "AndroidPlayer" "SDK" "platform-tools" "adb.exe"            }        } |        Where-Object { Test-Path -Path $_.adb -PathType Leaf } |        Select-Object -First 1 -ExpandProperty adb    if ($null -ne $adbPath) {        return $adbPath    }    # find from LOCALAPPDATA    $adbPath = Join-Path $env:LOCALAPPDATA "Android" "Sdk" "platform-tools" "adb.exe"    if (Test-Path -Path $adbPath -PathType Leaf) {        return $adbPath    }    # find from path    $adbPath = Get-Command -Name "adb" -CommandType Application,ExternalScript -ErrorAction Ignore |        Select-Object -First 1 -ExpandProperty Source    if ($null -ne $adbPath) {        return $adbPath    }    # not found    return "adb.exe"}function ExecAdb() {    $adb = FindAdb    & "$adb" $args}Set-Alias -Name adb -Value ExecAdb