Docker Desktop 4.37.0 から docker desktop
コマンドが追加され、Docker Desktopの起動や終了ができるようになった。
普段止めているので地味に便利。
Docker Desktop 起動。
$ docker desktop start
Docker Desktop 終了。
$ docker desktop stop
コマンド一覧。
$ docker desktop help
Docker Desktop 4.37.0 から docker desktop
コマンドが追加され、Docker Desktopの起動や終了ができるようになった。
普段止めているので地味に便利。
Docker Desktop 起動。
$ docker desktop start
Docker Desktop 終了。
$ docker desktop stop
コマンド一覧。
$ docker desktop help
先日テンプレを元にサイトを生成するという面倒な手仕事をAstroで片付けたのだが、それに付随して、生成したサイトのキャプチャ画像をとるというタスクもあり、こいつも何とか楽をしようと自動化ツールを選定した。
Pappeteer と PlayWright の2つが候補に上がって、両方触ってみたのでメモ。
特にこだわりがなければ PlayWright を使っておけば良いと思う。
Pappeteerがブラウザのオートメーションツールとされているのに対して、PlayWrightはテストフレームワークとして強く売り出している感じ。
ただ、PlayWrightもテスト以外の目的てブラウザオートメーションに使えるし、PappeteerもJestなどのテストフレームワークと組み合わせることができる。
PappeteerはChrome(Chromium)とFirefoxに対応。
PlayWrightはChromium, WebKit, Firefox, Chrome, Edgeに対応し、モバイル端末のエミュレーションもできる。
Pappeteer は TypeScript と JavaScript のみ。
PlayWright は TypeScript, JavaScript, Python, .NET, Java にオフィシャルで対応。アンオフィシャルなものならば Perl や Ruby なども。
ブラウザのオートメーションの観点では、両者ほぼほぼ同じ。Pappeteerの作者がMSに入って作ったのがPlayWrightとのことで、API仕様も大体同じ。
ネットで見かけた比較記事ではPlayWrightの方が使いやすいAPIになっているような記載も見かけたが、Pappeteerの方に一部PlayWrightの改善が取り入れられている節がある。
PlayWrightの方が便利だと感じたことの一つは Auto-wait という機能。
DOM読み込みの遅延、JS処理などで、特定のエレメントが参照できずにエラーになるということが Pappeteer では発生し、適宜スリープ処理を入れる必要があった。
PlayWright では対象エレメントが有効になるまで自動で待ってくれるので、処理を書くのが楽だし、無駄にスリープ処理を入れないおかげでスクリプト全体の速度が上がった。
Pappeteer でも locator では自動リトライをしてくれるらしいが、Pappeteer の locator は使い所が限られる。タイミングがシビアな場面では waitForSelector を使えば良いのだろうけれど、処理が遅くなる感じがするし、あまりそのようなコンテキストをスクリプトに入れたくない。
あと、PlayWright は大体の処理を locator からネストして書けるので楽。
公式サイトだとテストフレームワークとしての利用の案内ばかりだが、ブラウザの自動化だけならば以下でパッケージをインストール。chromium以外を使いたい場合は、playwright-firefoxまたはplaywright-webkitを指定。
$ npm install playwright playwright-chromium
以下のように使用。
import { chromium } from 'playwright'; const browser = await chromium.launch(); const page = await browser.newPage(); await page.setViewportSize({width: 1200, height: 1200}); await page.goto('https://blog.ryhmrt.com/'); await page.locator('#container').screenshot({path: 'blogshot.png'}); await browser.close();
以下でパッケージをインストール。
$ npm install pappeteer
以下のように使用。
import playwright from 'playwright'; const browser = await playwright.launch(); const page = await browser.newPage(); await page.setViewport({width: 1200, height: 1200}); await page.goto('https://blog.ryhmrt.com/'); await (await page.$('#container')).screenshot({path: 'blogshot.png'}); await browser.close();
コードはほとんど同じ。
同じ構成のウェブサイトを一部の内容を書き換えて何回も作る必要があり、設定ファイルを元にサイトを生成するものをAstroで構築した。
今回Astroを使うことになったユースケースは以下の通り
完全に静的な内容だけであれば素のHTMLが吐き出されるだけなので、React系のものと比べると段違いに軽い。
Reactのインテグレーションを追加すると途端に重くなるのでPreactなども検討したが、今回は大した処理ではないし、既存の素のJavaScriptを流用して実装した。
React/Preactだとレンダリングのタイミングもちょっと遅い感じがしたのも一つの理由。
公式が対応しているわけではないが、astro-relative-link というインテグレーションを入れることにより、リソースのパスを相対パスに変更することができた。
やってることは静的ファイルが生成された後、その中に記載されてる href
や src
といったアトリビュートなどの内容を原始的に書き換えている感じで、構成によってはこれがうまく動かないこともある。今回のケースはこのインテグレーションでうまくいった。
尚、SSGのツールをいくつか調べたが、軒並みサイト全体の生成を対象にしており、リンクには絶対パスが使われることが基本。
AstroのGitHub Issueで相対パスへの対応を熱望する人達の声をいくつか見かけたが、ニーズとしてはニッチな方だし、パスの解決に複雑な問題を持ち込むことになるため対応は消極的なようだ。
スタートガイドの以下のページを読めばサイトを作り始めることができると思う。
設定周りを少しいじりたくなったら以下のページと、必要に応じて各APIリファレンスを読むような感じ。
あとは Guides and recipes の項目のページ群も使う機能に絞って読んでおくと良い。
ドキュメントの日本語訳がけっこう進められていて、英語読むのに疲れたりしなくてありがたい。
いろんなライブラリのインテグレーションも用意されているし、自分でビルド時のフックスクリプトを書くのも簡単。
いくつか今回のプロジェクトで役立ったことのメモ。
ビルド開始時にサイトの設定ファイルを読み込み、それをミドルウェアで context.locals
に設定すると、各ページの Astro.locals
でその値を参照できた。
参考: https://docs.astro.build/ja/guides/middleware/
astrobook というものを導入したのだけれど、これがビルド時に有効になっていると余分なファイルが出力されてしまう。
以下のようにしてビルド時に無効になるようにした。
integrations: [ import.meta.env.DEV ? astrobook({ directory: 'src', subpath: 'docs' }) : null ]
参考: https://docs.astro.build/ja/guides/environment-variables/
ビルドの際はnullがインテグレーションとして渡って無視される。この後ろにインテグレーションを書くと、このnullによって後続のインテグレーションが実行されなくなるので注意。
簡単なものならば、astro.config.*
にインテグレーションをインラインで書いてしまえば良い。
Reactのインテグレーションを使っていたりするのだったら、アトリビュートとして渡せば良いのだが、素のJavaScriptだとそうもいかない。
そんな時は以下のように解決できる
--- import planData from '@/data/plans.json' --- <script set:html={`var plans = ${JSON.stringify(planData)};`}></script>
稼働中のDBスキーマをリバースエンジニアリングしてドキュメント生成するようなツールはいくつかあるけれど、フリーで使えて便利なものの一つが SchemaSpy
オフィシャルのDockerイメージがあるので、これで実行するとお手軽
$ docker run --network host -v "$PWD/doc:/output" schemaspy/schemaspy -t pgsql11 -host localhost -db mydatabase -u postgres -p password
最近システムの引き継ぎをしていて思い出したのでメモ
このゴールデンウィークで「Hit Refresh」と「ユニコーン企業のひみつ」という2冊の本を読んだ。
ソフトウェア開発には組織や文化が重要ということは数十年前から言われているけれど、ソフトウェアの重要性が高まる中で、開発の部署やプロジェクトといった局所的な取り組みではなく、会社全体/経営としての取り組みが強く求められているという風潮を感じる。
一年位前に読んだ「ジョイ・インク」も、この2冊と同じようなことを主張しているように思える。
若者が下手に読むと現状との格差に絶望してしまうかもしれないのでお勧めしない。上司や社長の机にそっと置いておく本という位置付けにしたい。
仕事でAWSを使っていくことになったので、自宅で勉強するための個人アカウントを作りました。
http://aws.amazon.com からAWSアカウント作成のボタンを踏んで必要な情報を入力。 登録を進めていると、途中で電話番号を入れて確認の電話がかかってくる手順がある。 アメリカからかかってくるので多分国番号から入力するべき。 080-xxxx-xxxx だったら +81-80-xxxx-xxxx みたいな感じ。
これでルートアカウントが生成されるが、ルートアカウントは普段使うべきではないらしい。IAMで普段使いの管理用アカウントを作成する。
サービス一覧からIAMを選んで、左のメニューからUser、次に Add user ボタンをクリック。
User name は好きなように入力。
Access type は両方チェック。
Console password は面倒なので自動生成で。
Require password reset は自分使いなのでチェックを外した。
次の権限画面では、Attach existing policies directly で AdministratorAccess と Billing を付与。 多分これで何でもできる。
Tagは何もいらない。
最後に出来上がったユーザ情報のCSVを落としておく。 次からはこのCSVにあるURLとパスワードでログインする。
AWSのコマンドラインツールもついでに入れておく。
MacでHomebrewが入っている環境なら以下のようにインストールできる。
$ brew install python3 $ pip3 install awscli --upgrade --user
これでawsコマンドが ~/Library/Python/3.7/bin
に入るのだけれど、ここにはパスが通っていないと思うので。
export PATH=~/Library/Python/3.7/bin:$PATH
を、zsh なら ~/.zshrc
、bash なら ~/.bash_profile
あたりに追記。
次に以下のコマンドで資格情報を設定する。
$ aws configure AWS Access Key ID [None]: CSVに書いてある情報 AWS Secret Access Key [None]: CSVに書いてある情報 Default region name [None]: us-east-1 Default output format [None]: json
これで aws ec2 describe-instances
とかが成功すればとりあえず設定できているんじゃないかと思う。
参考
最近なぜかフィリピンに行くという知り合いが多いので、フィリピン滞在に有益そうな情報を少し考えてみました。
私がフィリピンにいたのは2016年6月までで、基本的にはマカティから外には出ずに活動しておりました。その範囲で見聞きしたり実体験した情報です。
とりあえず最低限これだけあればなんとかなります。
ホテルは多少高くついてもなるべく治安の良いところを選ぶべきだと思います。田舎の方では場所による治安の差はそんなに無いと思いますが、都市部では気をつけたいところです。新宿の表通りと裏通りの治安感を思い浮かべていただければ何となく雰囲気は浮かぶかと思います。
最近はフィリピンも都市部はGoogleMapsのStreetViewでカバーされてますので。通りがどんな感じか、開けた通りでお店があって夕方から夜にかけてもそれなりの人通りがあるところなのかどうかなど、調べておくと安心です。
日本人は事前の手続きをしなくとも、ビザなしで30日間の滞在許可がおります。滞在許可期間内に出国するチケットさえあれば、よほどのことが無い限り入国拒否をされることはないはずです。
帰りの日程がはっきりと決まっていない場合も、仮の滞在スケジュールを滞在許可期間内で立てて、それに合わせて帰りのチケットを持っておく必要があります。JetStartはオプション料金を少し払うと安いチケットでもスケジュール変更可能になるのでよく使ってました。
30日を超えて60日以内の滞在をする場合は、事前に日本のフィリピン大使館で短期滞在ビザを取っておくと、フィリピンで滞在延長手続きをせずに済んで便利です。
滞在延長手続きは、自分でイミグレのオフィスに行くか、旅行代理店に頼むかになります。何度か自分でもやりましたが、イミグレまで行くのもかったるいですし、手続きにも時間がかかるので、オススメは代理店です。
フィリピンの通貨はフィリピンペソです。さっき見たら1円=0.47ペソでした。
以下の種類のお札と硬貨があります。1ペソ=100センタボ
割とどこでも円からペソに換金できますし、ほぼマーケット情報に出ているレートと同じ条件で換金できるので、なるべく円を現金で持って行くのがお得です。
足りなくなったらPLUSやCirrusのマークがある銀行のATMでクレジットカードのキャッシングを利用できます。一回の取引上限は10,000ペソとかだと思いました。
日本で換金して持っていくのは非常に換金効率が悪いのでやめましょう。
余ったペソは10,000ペソを上限に国外に持ち出せます。空港スタッフがX線スキャンでチェックしてイチャモンをつけてくるので、もしペソが余って持って帰りたい人は気をつけるようにしてください。
ごく短い滞在であればローミングで済ませてしまうのもありです。料金は各通信会社のページに載っていると思います。
ネットの使用頻度や滞在日数によっては、SIMフリーの携帯を持っていて(向こうで買っても良い)、ローカルの回線を取得すると安く済むかもしれません。
空港では各回線業者がプリペイドのSIMを売ってますので、携帯を渡してSIM入れてネットの設定までやってもらうこともできます。かわいいお姉ちゃんだったらついでに番号ゲットしてしまえばいいと思います。
5つ星ホテルに滞在するなら迎えを頼めると思いますが、迎えがないならば空港からの移動はタクシーを使うことになると思います。空港で見かけるタクシーにもいくつかありまして、
料金が安い順に言えば、基本的に白、黄色、固定の順です。ただし、ぼったくり遭遇率もその順に高いので、メーターのタクシーに乗るときは、乗る前に「Meter?」とか言ってメーター使うかどうか確認して、走り出したらメーター動き始めたかどうか確認すると良いです。固定料金のタクシーはそうそう問題は起きないと思います。
尚、運ちゃんは英語を解しますが、日本人の発音が通じない可能性は大いにありますので、行き先の名前と住所は紙に書いておいて渡すと良いと思います。
長期滞在ではコンドミニアム(マンション)を借りることになると思います。自分で探すのも良い経験になりますが、知り合いの一人は日系の不動産から仲介してもらってました。英語がそこまで得意じゃ無い方はオーナーと直接やりとりするのはかったるいと思いますので、仲介屋を通すとそこら辺も安心できるかと思います。
携帯は後払いの契約型のものの方が安くなりますし、いちいちロードする必要もなくなるので便利です。個人的な経験からは、外人で国内に住居と職があればすんなりと回線契約できるのではないかと思います。
銀行口座も持っていると便利です。フィリピンでは他行の口座とはやりとりできませんが、自行のATMからはいつでも手数料なしで引き出せます。会社の口座がある銀行支店で店長とかとフレンドリーに話をしていればすんなり開設できるのではないかと思います。
慣れたと思った頃にヘマをする人が多いらしいので、海外で気を引き締め続けるのを忘れずに、と諸先輩が仰ってました。