ElastiCache Serverlessは作って放置してるだけで課金される雰囲気があるので気をつけろ

ElastiCache Serverlessを試していてこれはなんかイマイチだなと思ったので記事にした次第。

既に試している人はVPCエンドポイントに見覚えのないリソースが作られていないかを眺めておいた方が良いかと思う。

ElastiCache ServerlessをAWSマネジメントコンソールから作成する際に、ネットワークをカスタマイズするとこんな選択が出てくる。

どうやらここで選択したサブネット毎にリソースへの接続用のVPCエンドポイントが作成される雰囲気がある*1。

このVPCエンドポイントはElastiCache Serverlessと管理が統合されている様子で、手動では消せない。ElastiCache Serverlessを消すとこちらも消える。

インタフェースエンドポイントはリソース毎に月額の料金が発生する（はず）ので、サーバレス＝使わなければ金かからん、という気持ちでElastiCache Serverlessを作成していたらそれなりの金額の月額料金が発生しているかも知れない。

そんな感じ。

---

追記

そもそも使用容量のGB単価が高い&GB単位で切り上げ計算なようで、最小コストはかなり高く、スモールスタートは全く考慮されていない様子だった。

*1:あくまで雰囲気。確証が欲しい場合は各自確認されたい。

好みのシェルエットのガールズプラモを作る

オタクコンテンツで「配色でそのキャラクターが分かるのは優秀なデザイン」と言ったことが話題になる場面がある。特にガンダムのモビルスーツの配色はガンダムオタクには刷り込まれていることもあって分かりやすい。

同様に「シェルエットでキャラクターが分かるのは優秀なデザイン」のようなことも言えると思う。

孫悟空やベジータなど、ドラゴンボールのキャラクターはとても分かりやすい。

比較的最近だとチェンソーマンんかはとても分かりやすいユニークなデザインなのではないかと思う。

で、ユニーク性は兎も角、自分にも好みのシェルエットというものがある。

普段はギャルプラモはパチ組するだけなのだけれど、たまには多少好みに合わせて改造してみようかと思った。

好みを構築するということなら、商品の性質的には30MSが向いているはずなのだけれど、そのためのオプションパーツは全く手に入らないので、入手性が良いコトブキヤ商品で行く。

で、作ったのがこれ。

どーんと構えた「三角形」なシェルエット、「デカい武器」「デカい腕」。多少腕のごつさは物足りないが、まぁまぁ好みのシェルエットのガールズプラモを組めたと思う。

ナイトマスターソードでけーなぁ。これを騎士っぽい感じのギャルに持たせたいなぁ。を出発点に組んだのだけれど、デカすぎて持たせるのは厳しそうだった。幸い中に普通サイズの剣が入っているのでそちらを持つことはできた。

もうちょいでかい剣がセットされるドゥルガーIIを待てばよかっただけなんじゃないの？　と思わなくもないが、結果はともかく作る過程が楽しいので良いのだ。

メカではなく騎士って点で元にするキットが限定され、ロングスカートはプラモを稼働させる上での鬼門なのでもっと限定される。

甲冑っぽいアーマーはドゥルガーIをベースにしてアーマーパーツを好みな感じに組み替えて、ロングスカートはエクスアーマーE（ドレスVer.）を使った。ドレスのエクスアーマーは単品がなく、色も青系（剣の色合わせ）がない。ドレスを剥がれたマジカルバーゼラルド（当然ランナー状態）をどうしようか。とりあえずパチ組はしよう。

組み合わせを考えながらベースキットやオプションを探して組むのは結構楽しかった。

ちょっとだけ写真加工（2023/11/09追記）

剣を光らせたかったので少し写真加工した。

今の時代ならAIに「剣を青く光らせて！」と指示したらもっといい感じにしてくれそうなものだけれど、どういうAIツールなら実現できるかなど分からなかったのでとりあえずは諦めた。

これセイバーでは？

作っているときというか、配色考えているときに既視感があった。

どーんと構えた「三角形」なシェルエット、「デカい武器」「デカい腕」。

この好みは既存作品だと超有名なFateのセイバーがかなり近くて、実際好みのデザインなのだけれど、作品はアニメを斜め見した程度なのが面白い。

https://arcade.fate-go.jp/servant/detail/#!/servantid:00 より

今回はナイトマスターソード合わせで青にして、ベースにしたキットが金髪だった、という事情でめちゃくちゃ寄ってしまった。

好みのルーツ

この辺の好みのルーツには恐らくこの辺りの作品がある。

プリンセスクラウンのグラドリエル

https://pc.watch.impress.co.jp/docs/article/game9712/b_6.htm より

https://dengekionline.com/articles/18802/

www.takaratomy-arts.co.jp

少女とゴツいガントレットと剣のアンバランスさがとても良い。

こちらも実は未プレイ、なんで好きになったんだ？　謎。

スペクトラルフォースのヒロ

https://www.ideaf.co.jp/game/spec/?hard=ps&title=force

https://dengekionline.com/data/news/2006/1/30/21eefd03672edd4e6565a9db3803cf4d.html より

何と武器だけでなく手もデカい。盛りすぎ。

こちらは相当プレイ時間も長い好きな作品。2までが特に好き。以降は作風やデザイナーが変わってほどほど。

コレクションサイズのフィギュアが発売されたことがあって、所有もしてるはずなのだけれど、どこにあるのかは分からない。画像を参照した特典フィギュアはそれのリデコだった気がする。

ほかの好み

他にも好みはあるけれど、今後その好みを投影したときのネタにとっておこうと思う。

が、30MSは好きなキャラを見たてで作りたさもある。早くオプションも流通してくれ。

価値を認める姿勢：Webアプリケーションエンジニアが選ぶ求人条件

自分はWebアプリケーションエンジニアを仕事にしてる。一時期ほどではないが、2023現在は相当な売り手市場で、転職する人も多い。自社でもちょいちょい面接など採用に関わることもある。

今現在ミリほども転職の機運はないのだが、採用する側の立場としても、そのうち求職するかもしれないと想定しても、転職、職場の待遇、条件はまぁまぁ気になる。

となった時に、自分はなんで転職の機運が高まっていないのかとか、求職するとしたら何が大事なのか。少し考えたくなったので箇条書きする。

という備忘記事。

特に職場に満たされていたい条件は

• ITシステムのソフトウェア開発が仕事である
• 開発に当たっては自社の中で一切の技術選定を行える
• 主として利用しているクラウドプロバイダとは最上位サポート契約を結んでいる
• 少なくとも興味を持てる業界である
• フルリモート勤務である
• 給与水準がそれなりに高く、過度にソフトウェアエンジニアを優遇していない

このくらいだろうか。

• ITシステムのソフトウェア開発が仕事である
• 少なくとも興味を持てる業界である
• フルリモート勤務である
• 給与水準がそれなりに高く、過度にソフトウェアエンジニアを優遇していない

辺りは、自分が持つ技能由来の前提とか、信条とか、ライフスタイル的に外せないとか。

• 開発に当たっては自社の中で一切の技術選定を行える

少なくとも自分が意思決定に関与できる状態ではありたい、ってこと。

• 主として利用しているクラウドプロバイダとは最上位サポート契約を結んでいる

仕事を進めるにあたって、一般的なノウハウに比べて、内部事情にも通じている人のサポートを得られる。これが無い状態は考えられない位に便宜が違う。

加えて、見た目上は無形のサポートに金を払っているという事実が分かるというのも大事。ソフトウェアという無形なものの価値を認めていることの指標にもなる。

ITで稼ぐならITに金払う姿勢があるってことを大事にしたい。

そんな感じ。

---

2023-11-13追記

GitHub Copilotないしそれに準じるAIサポートを活用している

これも外せない条件となりつつある。

今後のIT活用に当たって、LLMやその後継技術の活用は不可欠であると感じる。 バズワード（例えばブロックチェーンはインターネット同様に普及する）とは異なる確かな流れを感じる。

---

尚、ブログタイトルは本文の内容を元にはてなブログの「AIタイトルアシスト(β版) 」に考案してもらいました。

記事を書く前につけていたタイトルは「職場の足切り条件」でした。

Contentlayer で Next.js の SSG 向けデータを管理する体験はなかなかよい

タイトルで全てが完結している記事です。

↓これ。

github.com

Next.jsのようなフレームワークで静的なサイトのコンテンツを生成する際には、元となるデータ（よくあるのはお知らせやブログ記事）を何かしらの形で管理しなくてはならない。

どうするのがいいのか？　適当に検索してヒットしたのがContentlayerだったので使ってみて「いい感じだった」ラッキーというわけです。

「データの管理: 所定のディレクトリにMarkdownファイルを置けばそれが個別のページにレンダリングされる」のような感じ。

まだベータ版なのだけれど十分に使って行けるかと思う*1。

この辺の体験が特によかった。

• 導入が簡単
• TypeScriptなら定義したデータに型が付くし検証もされる
• カスタムコンポーネント追加が簡単

*1:ただし破壊的な変更があっても泣かないこと

S3 + CloudFront での静的Webサイト配信への気持ち

AWSで静的なWebサイトを配信したいと考えたらS3 + CloudFrontの組み合わせが向いているのだろう。

ただ、ちょっと思うところはあるのでその気持ちを書く記事。

Next.jsのApp Router下でハッシュフラグメントを得る

どうもNext.jsはURLの#以降の部分、Fragmentを使うことは推奨していないように思える。

前々からそうだったのだけれど、13で準備されているApp Routerではよりその方向性が強くなったのではないか。

Upgrading: From Pages to App | Next.js 辺りが該当する変更で、元々router.asPathで取れていたフラグメントが、usePathnameでは取れなくなっている。

とは言え、Next.js最適化ではないURLの設計をしてしまうとフラグメントを取得したい場面はある。

Next.js+App Router下ではこの位で期待の動作を得られた。

参考: How do I get the pathname with hash. · vercel/next.js · Discussion #49465 · GitHub

import { useParams, useRouter } from "next/navigation";
import { useEffect, useState } from "react";

export const useFragment = function (): [
  string,
  (newFragment: string) => void
] {
  const router = useRouter();
  const params = useParams();
  const [fragment, setFragment] = useState("");

  useEffect(() => {
    setFragment(decodeURIComponent(window?.location.hash ?? "").slice(1));
  }, [params]);

  const pushFragment = (newFragment: string, scroll: boolean = false) => {
    router.push(`#${newFragment}`, { scroll: scroll });
  };

  return [fragment, pushFragment];
};

export default function HogePage() {
  const [fragment, pushFragment] = useFragment();

  return (<>{fragment}</>);
}

とは言え以下の点に気を付ける必要はある。

• サーバサイド処理（SSR/SSG）時は常にfragmentは空
• クライアントサイド処理が行われるタイミングで改めてfragmentが返る

という感じになるから「Next.jsはURLの#以降の部分、Fragmentを使うことは推奨していない」のだろうか。

（どこかに書いてあるのかもしれないが、そこまで追いかけていない）

またuseParamsの振る舞いが変わったら機能しなくなるワークアラウンドである点にも厳しい。

やはりフレームワークを使うならフレームワークの機能内で構成するのが良いのだろう。

Node.js の readdir が便利になっていた

TypeScriptやJavaScriptのリポジトリでちょっとしたスクリプトを書くならまぁNode.jsで動かすのが素直だと思う。

package.jsonに開発用の依存関係を入れればよいわけだし。

先日は「リポジトリ内の画像ファイルをガーっと処理したい」と思ってディレクトリ走査してみたのだけれど、少ないコード量で書けてなかなか便利だった。

File system | Node.js v20.5.0 Documentation

import { readdir } from "node:fs/promises";

const sourceDir = "./";

// 指定したディレクトリ配下のエントリの情報が全部返る
// 画像を処理したいなら後は拡張子で filter などすればよい
const files = await readdir(sourceDir, {
  withFileTypes: true,
  recursive: true,
});

再帰的に取得するオプションはかなり最近の追加（v20.2/v18.17かな）だったようだ。

fs: make recursive readdir algorithms iterative by Ethan-Arrowood · Pull Request #47650 · nodejs/node · GitHub

それ以前はいちいちディレクトリをたどらなくてはならなかったらしい。面倒くさい。実にラッキー。

---

しかし、withFileTypes オプションの有無で返却値の型が変わるのはいかがなものか。恐ろしい世界だ。