koudenpaのブログ

趣味のブログです。株式会社はてなでWebアプリケーションエンジニアをやっています。職業柄IT関連の記事が多いと思います。

GitHub Pagesのカスタムドメイン設定がデプロイのたびに消えていた話

Tips

GitHub Pagesのカスタムドメインをブラウザ上（リポジトリ > Settings > Pages）でなんとなーく設定していたところ、記事名の通りデプロイのたびにカスタムドメインの設定が消えて github.io に戻ってしまって「なんでやねん？」となっていた。

なんでかは当然ドキュメントに書いてある。

GitHub Pages サイトのカスタムドメインを管理する - GitHub Docs

[カスタム ドメイン] で、カスタム ドメイン名を入力してから、 [保存] をクリックします。 ブランチからサイトを公開している場合は、ソース ブランチのルートに CNAME ファイルを追加するコミットが作成されます。 カスタムの GitHub Actions ワークフローを使用してサイトを公開している場合、CNAME ファイルは作成されません。 公開元の詳細については、「GitHub Pages サイトの公開元を設定する」を参照してください。

GitHub Pagesに特定のブランチをデプロイしている場合、そのブランチのルートにあるCNAMEというファイルの内容がカスタムドメインとして認識されるようだ。

自分のケースでは、GitHub Actionsでのデプロイ対象ファイルのビルド結果をそのブランチにPushしていたので、GUIで設定、作成されたCNAMEファイルがデプロイのたびに消えていたようだった。

デプロイ対象にCNAMEファイルを追加したらカスタムドメイン設定が維持された。

github.com

このカスタムドメインがいつの間にか空白に戻っていて「？？？」状態だった。

葬送のフリーレン人気投票のツイートを収集・集計表示して遊んでいた

Blazor

令和最強のハイファンタジーマンガ葬送のフリーレンがTwitter上でオープンに人気投票をやっている。オープンなら投票状況を見たくなるのが人情である。

またBlazor WebAssemblyなんだ。何かしらのデータセットとチャート系のコンポーネントは相性がいいはずなのでそのうち試しておきたかったところに、ちょうどよい題材があってラッキーといったところ。

まだとりあえず表示しただけなので、インタラクティブに可視化の軸を変えたいと思いつつ、そういうのはスクラッチのWebアプリケーションではなく、適切なデータセットをBIツール（それこそPower BI）に入力するのがいいのではないか？　と思わなくもない状態。投票数がどういう推移をしていったのかは眺めたいので、何かしらの形で処理したいとは思う。

追記：最低限という感じで時刻を遡った結果を見られるようにした。面白い。

https://7474.github.io/Frieren2022Checker/

Twitterをデータソースに遊ぶ際のTipsというか、今後こうしようかなー、を少しまとめておく。

  • 今回の集計の要件
  • アプローチ
    • TwitterのAPIを使って必要なデータ（ツイート）を収集して保存
    • 保存したデータを要件に従って集計
  • オチ
続きを読む

APIドキュメントの書き具合

雑記

これは雑多なメモです*1。

Webサービスを作るぞ、となったときにサーバサイドアプリケーションはGraphQLなりRESTなりのAPIを提供し、クライアントサイドアプリケーション（Webフロントエンドアプリだったりスマホアプリだったり）はそのAPIを呼ぶ。という責務分担をすることが多い気がしている。

そうなった際の責務分担の境界は「GraphQLなりRESTなりのAPI」であることに間違いはない気がしている。

それらのAPIドキュメントが完璧に書かれていれば、理屈の上ではサーバサイドとクライアントサイドのアプリケーションは相互に独立して開発を進められる。

完璧なドキュメントなんて存在しないし、理屈通りにはいかないけれど、それを志向はしたいと常々思っている。

そういう志向においては「APIドキュメントの書き具合」はどのくらいにするのがいいのだろうか。

仕事で開発しているWebサービスについての思案なので以下のようなものになる。

  • 自分はサーバサイドのチーム
  • APIとそのドキュメントのオーナーはサーバサイド
  • Webフロントエンドアプリはサーバサイドのチームが開発・運用
  • スマホアプリは隣のチームが開発・運用

理想はエンドユーザーに提供するAPIのドキュメントのような全てが網羅されている状態だろう。無限の工数があればそうしたいですね。

そんな手間暇をかけるのは現実的ではないので、外から見た振る舞い、外部仕様を丁寧に書く、程度のポリシーで暮らしている。自分はAPIを提供する側だけれど、呼ぶ側としてこのドキュメントをみて迷わずに呼び出せるか？　イラつきはしないか？　を考える。

丁寧に書いていると、自分が実装するときに参考になるのもよい。

外部仕様書として見ると、サーバサイドクライアントサイドとの境界だけでなく、要件との境界、突合せもできて便利。

なので、現実的な落としどころは「外部仕様」を書くように心がける辺りじゃないかな、って思っている。

永遠のTODO ここに例が書かれる

そんな感じ！

*1:普段社内のナレッジベースに書いてるような内容だけれど、別に社外秘ないしブログに書いてしまってもいいだろう

祝ロックマンXファーストアーマープラモ化

雑記 プラモデル

最近どうもお元気が無くて、業務時間内にブログを書くよ活動もサボっているのだけれど（普通に手持ちタスクが掃けていないという事情もあるが）、ロックマンXのファーストアーマープラモ化の報はかなり嬉しかったのでお気持ち高め記事を書いておく。

自分はアクションゲームがさほど得意ではなくて、難易度の高いロックマンシリーズは持っておらず知人宅でプレイする程度だった。しかし、愛読していたコミックボンボン連載の漫画版ロックマンXは大層お気に入りで、特にロックマンX無印は大好きだ。

ボスキャラの狂い具合が良いし、エックスとゼロの友情も熱い。作画の勢いもとても良い。

2以降はどんどんデザインがごちゃついていくパワーアップ形態に対して、無印エックスのファーストアーマーはソリッドなのも好みだ。

そんなファーストアーマーは何故かなかなかプラモ化されなかった。

満を持して来た。という感じなのだ。

正座して待てるほど落ち着きはないので、（偏向メッキの光に惹かれてチャージ版を買っていた）ノーマルのエックスを仕入れてフットパーツのみ入手形態への組み替えに備えた。

後はVAVAと無印ゼロと無印シグマをよろしくお願いします。

振り返ってみるとメッキ版はやはり指を痛めていたようだった。

ゼロを組んでいるときも組みやすさ方面に言及している。

カッコ良すぎか？

VAVA大好き。

なおエックスのライドアーマーは継続して行方不明中である様子。

やはりVAVAもお願いします。

そんな感じ。高まってきた。年明けのフルアーマー発売が楽しみだ！

shop.kotobukiya.co.jp

業務時間内に勉強とか

雑記

ITエンジニア界隈ではちょいちょい業務時間外に勉強する必要の有無が話題になったりする。

これに関しては「IT技術を勉強と思わずに勉強してる」人が最強、以上のものはないと思う。最強かどうかはともかく、自分も興味を惹かれた要素技術は業務時間内外問わずに調べたり試したりしている。

業務時間内外問わず

気になったタイミング、鉄は熱いうちに打つ。単に移り気なだけかもしれないが。

株式会社はてなのエンジニア組織には、10%ルールの類*1があって*2業務時間内に自己啓発OKなので、建て付け上はその時間を当てているという感じ。

自分は仕事と趣味の境界が非常にあいまいなので、担当している仕事に影響を与えない範囲で好き勝手にお勉強している。趣味の時間でもまぁまぁ仕事についての考え事やメモをしたりもしている。「総合的に見たら帳尻取れてるだろう」位の気持ち。

ルールをしっかり運用したい人は、タスク管理ツールなりスケジュール管理ツールなりに「この時間はxxxを勉強する」のようなタスクや予定を入れればいいだろう。

何が言いたかったんだっけな。

「IT企業なら業務時間内に勉強できる制度はあるだろうから、勉強したけりゃそれ活用すりゃいいんじゃないの？」

だった気がする。

この記事も「もくもくブログ執筆会」という予定をGoogleカレンダーに入れてその時間に書いていた。

特に落ちはなし！

*1:調べたら「10%ルール」って名前のルールだった。

*2:採用サイトとかには載ってない気がするけれどまぁ別に隠すもんでもないだろう。多分会社全体の福利厚生制度じゃなくて、エンジニア組織のローカルルールだから載ってない。

クラウドやWebサービスのプレビューとかGAとかについての散文

雑記 AWS

Web界隈ではある機能がプレビュー中だとか、GAされたとかあったりする。

プレビューは「未完成だけれど使ってみてね」状態で提供されること。別の言葉だとベータ版とか。

GAはGeneral Availabilityの略で「一般に提供されるようになった」のような意味らしい。要するにこれからは正式なサービスとして提供するぞ、ということだろう。

そこにどんな差があるのかはサービス次第だけれど、いわゆるWebサービス、SaaSの界隈ではプレビュー版は無償提供するので試してみてくれ。GAしたらお金を払ってね。というものが多いように思える。

他方クラウドプロバイダのプレビュー版は普通に金取られたりして、俺ら金払ってデバッグしてんの？　感がある場合もある。

自分は「枯れたものがいいよね」という感覚と「新しいものは面白いし便利だよね」という気持ちが同居しているので、それを仕事の本番で使うかどうかは別として、プレビュー版を触ったり、GAしたら使ったりしてみたりすることがある。

が、やはり出来立てのサービスは不便だ。

そのサービス自体がGAしていても、周辺のエコシステムが追いついていない場面は多い。

直近だとAWSのAurora Serverless v2やRedshift Serverlessといった既存のデータベースサービスのサーバレス版を少し触っていたのだけれど、やはり不便さがあった。

IaC（Teffaform）プロバイダが未対応でGA直後にはリソースを作成できなかったり、RedshiftにはDMSでデータを投入しようとしたら未対応だったりした。

手堅くいくなら何事もある程度枯れた要素技術を使うのがいいんだろうな。

新しめのものに触れる際にはちょっとした不便さには目をつぶったり、OSSなら自分で対応していくマインドを持っていきたい。

日本の祝日をAsanaに登録する

Tips 雑記

みなさん、来週の月曜日（2022-07-18）が祝日だって知ってましたか？

僕は知りませんでした。僕の所属チームには同じように知らない人が数名いました。

するとどうなるか？　タスク管理ツール上、祝日に堂々とタスクが配置された状態になります。

これは良くない。丸1日予定が狂います。

というわけで、日本の祝日を一括してタスク管理ツールに登録しました。

  • こうなった
  • こうやった
続きを読む