はてなブックマーク

Node.js 本体で TypeScript ファイルを実行できるようにするプロポーザルが出されているという話が先週あたりから話題になっている。しかしそれほど嬉しいかといわれると、正直いらんなあと思っている。 TypeScriptで簡単なスクリプトを書くときは、長らくtsxを使って実行している。tsxを使い始めるより前は ts-node を使っていたが、tsxを使ってからは何の不満もなく使い続けている。 tsxは内部的にはesbuildでTypeScriptをトランスパイルしていて、型チェックは行わない。tsxのありがたい点は、すべての node コマンドのオプションを tsx コマンドでサポートしていることだ。単純にコマンドを置き換えるだけでいいので、何も新しく覚えることがない。 構造的にはNode.jsの中でswcでJavaScriptに変換されるか、外でesbuildで変換されるかの

コードレビューに限らず、いろいろなレビューがいろいろなプロセスに組み込まれている。だが、レビューにおいて、たとえ内容に瑕疵があっても承認されるなら、そのレビューは単なる形式・儀式に過ぎない。"何かを保障するためのプロセス"としてのレビューを機能させることを目的とするなら、そこには却下の可能性があることが必要条件だ。 保障: ある状態がそこなわれることのないように、保護し守ること。 https://kotobank.jp/word/保障-630029 却下と批判的立場そのようなレビューにおいて、レビュアーは「これは承認しても大丈夫か」と思考する。「承認しても大丈夫だ」という確信を得るということは、裏返せば「却下すべき理由がない」という確信を得ることである。その確信が得られるのは「却下すべき理由を探したが見つからなかった」ときである。つまりレビュアーに承認を求めることは、「却下すべき理由を探す

いわゆる「技術的負債」、あるいは単純に「古いコード」は悪者にされやすい。特に、それを書いたのが現在の開発者とは別人であるなら。（すでに会社にいないなら尚更に） 確かに、古いコードはソフトウェアの品質を上げにくくする。だがそれはコードが古いことが原因ではない。コードの質が悪いからだ。そのコードの可読性が低く、テストが不十分で、変更容易でない、そんな状態のまま古くなったからだ。 一度書いたコードの質があとからよくなることはない。どんな一片のコードでも、書き直される以外に質が上がることはない。（当然下がることもある） 常にいいコードを書けるように励もう。どんなコードも時間とともに老化する。老いに対抗できるのは、絶えずよりよいコードに書き換えていく新陳代謝だけだ。 今日は昨日よりいいコードを書こう。

記事中のURLプレビューをiframeで表示するためのエンドポイントをCloudflare Pages Functionsで実装した。実はこれまで長らくはてなブログのembed APIを勝手に借りていた。倫理的によろしくない面もあったり、パフォーマンスや信頼性の面でもセルフホストしたいと思っていたが、着手するのを先延ばしにしていた。別に技術的に困難なポイントがあったわけではないが、備忘録としてやったことを書く。 /embed エンドポイントの作成このブログはCloudflare Pagesでホスティングしている。Cloudflare PagesのFunctions機能は、デプロイするレポジトリの /functions ディレクトリの中に配置したスクリプトを動的なWorker関数として呼び出せるようにしてくれる。 今回はこの機能を使って、 /functions/embed/index.tsx

この雑記を書く問題意識は、Tailwind CSSに対して向けられている世の人々の不満が、Tailwind CSSがコミットしていることから外れた、お門違いの期待の押しつけになっているのではないかと感じるところにある。 ライブラリやフレームワーク、道具にはそれが作られた目的があり、果たそうとするコミットメントがある。その圏内において果たされていないコミットメントに対する不満は、それ自体の存在意義にかかわる意味を持つが、しかし利用者が一方的に寄せた期待が果たされないことに対する不満はそうではない。 念押しするまでもないと思うが、これはTailwind CSSに対して不満を向けるべきではないという話ではまったくない。むしろ、その不満の下敷きとなっている Tailwind CSS への期待が Tailwind CSS 自体によってコミットされたものでないとしたら、不満を向けてもしょうがないのでは

最近に限らず、ここ数年ずっと目にするし、聞かれることもあるこの話について、いくつかの思うこと、ぼやきを書いておく。あとで参照できて便利なので。 1. あなたが使い始めれば少なくとも昨日よりは広まりますよ好きなら使えばいいと思うので僕には気持ちがわからないのだが、好き・気になるけど流行ってないから使わないという心理があるらしい。企業での判断ならわかるが、個人でそれはまったくわからん。仮にそれがマジョリティだとしたら、使われなければ流行らないのに流行らないと使われない、デッドロックで詰みです。 あなたが使ってみてそのことを発信すれば、少なくとも昨日より世界で一人分は使用者が増えます。その積み重ねでしか普及しません。ですので、流行って欲しいと思うならまず自分から使って周りに広めてください。 2. そもそも「流行っている」とは？僕が思うに、「流行っている」ということと「広く普及している」ということ

タイトルの通り。普通にNode.jsのWebサーバーを立てて実装するときとは違う注意点がいくつかあった。当然制約が強い環境ではあるが、それを差し引いてもCloudflare + Honoは開発・運用しやすいので、結果的には満足している。 ちなみに、公式ドキュメントでもCloudflare WorkersでのBotの作り方のガイドはあるが、これはExpress前提なので、Honoユーザーはいろいろと読み替える必要がある。 https://discord.com/developers/docs/tutorials/hosting-on-cloudflare-workers discord.js は使えないDiscord botをJavaScriptで実装しようと思ったら普通 discord.js を使うが、このライブラリは現状Node.jsランタイムに強く依存しているため、Cloudflare

チームがどれだけ優れているかというレベルは、そのチームの目標にあらわれると考えてみる。 チームのレベルについて絶対的な評価基準を作るのは難しいが、チームが掲げる目標の経時的な推移から、相対的な変化の勾配を評価することはできる。 チームが現在の目標を容易に達成するようになり、より高度な目標を掲げられたら、勾配は上昇する。そのチームはレベルアップしているといえる。 同じ程度の目標を達成しつづけることに甘んじているチームは、勾配が水平に近づく。いわゆるコンフォートゾーンに留まっており、停滞したチームだといえる。 チームが少しずつ身の丈に合わせて目標を引き上げられているかどうか、これはチームが成長しているかどうかを見るバロメータになる。 チームの状態を評価するときには、いまの目標の達成度合いだけでなく、目標の勾配にも関心を向けてみるとよい。また、チームのレベルを上げたいと思っているときには、現在の

Notion Web Clipper でブックマークしたURLを X (以下 Twitter) に自動投稿することを長らくやっている。 https://twitter.com/search?q=%23laco_feed&f=live これまでは自動化に Zapier を使って完結していたのだが、SaaSを使ってTwitterに自動投稿することが難しくなってきた。今年のはじめにはZapierのプレミアムプランが必要になったが、ついに8月末で完全に機能が消えることになった。 代わりのSaaSを探してみたがなかなか見つからなかったのと、Misskeyへのクロスポストを最近別の仕組みで実装していたのと統一して、ついでに Bluesky にもクロスポストしようということで、全部作ることにした。思い立ってみたら一日で出来上がったので、その記録。 ↓実際にクロスポストされたもの（Blueskyはログイン

先日、Trace-based Testingなるテスト技法についてのブログを読んで感動した。（感動しただけでまだ試してはいない。） 何に感動したかというと、トレースによってシステムの振る舞いをテストするというアイデアは、僕がPHPカンファレンス福岡で発表したテストについての基本的な考え方とこの上なくマッチしていて、なおかつ具体的な技法としてトレースをテストに使うという発想は僕の中になかったからだ。あっぱれという感じだ。 PHPカンファレンス福岡では、テストの本質は開発者が安心を得るためのプロセスであり、したがって、「このテストが通るなら本番でも期待通りに動作するはずだ」と思えるようなテストが、テストとしてのパフォーマンスが高いと話した。 Trace-based Testingがもっともよく機能するのは、開発者がデプロイ後にシステムの正常動作を検証するために最も信頼しているものがトレースであ

「どのように小さくリリースするか」ということを議論する以前に、「リリースが小さいとはどういうことか」についての認識を合わせられてなかったら、準備はまったくできてないと言っていい。 何においてもそうである。「どうやっておいしくハンバーグを作るか」を議論するには「ハンバーグがおいしいとはどういうことか」についての共通認識が必要だ。ハンバーグのおいしさについての意見が噛み合ってなかったら、その人達がどれだけ話し合っても「どうやっておいしくハンバーグを作るか」に答えを出せるわけがない。 だから、なんらかのきっかけで「リリースの大小」に問題意識が向いたのなら、「リリースが小さいとはどういうことか」が最初の論点にならなければいけない。（もちろん「リリースとは何を指すのか」についても当然共通認識が出来ていないと意味がないが） 大きい・小さいという尺度は、面積や体積をもった物体同士を比較するのに使われる表

今年に入ってから、オフラインのIT系勉強会や開発者カンファレンスがじわじわと復活してきているが、興味深いと思っているのは、開催にあたってより大きなコストのかかるカンファレンス規模のイベントのほうが、復活のスピードが早いように思われることだ。 逆に小規模の、駅名+技術のような勉強会のほうが復活していないものが多いように感じる。これには会場確保の難しさやオーガナイザーの状況の変化などいろいろな要因が簡単に思いつくが、特に考えてみたいのは「集う」ということそのものの困難さに気付かされているのではないかということだ。 人が集まって何かをイベントを開催するためには、そこに人を「集わせる力」が必要である。大規模なカンファレンスと小規模の勉強会の大きな違いは、その「集わせる力」に対する投下コストにあると思う。より商業的な色合いを持つイベントであるほど、そのコストの多くは「集わせる力」の増強に使われる。集

PHPカンファレンス福岡2023で『DOMのテストがどんどん書きたくなるTesting Libraryの世界への招待』というタイトルの発表をしました。

このブログ https://blog.lacolaco.net は Hugo で生成しており、これまではMarkdownファイルをローカルで手書きして記事を書いていた。そしてより気軽に記事を書ける環境を求めて、 Notion をヘッドレスCMSとして使ってみることにした。ちなみにこの記事もNotionで書いている。 この試みは特に新しいものではないため、それほど苦労せず実現できるだろうと思っていたが、実際に開発してみると思っていたよりも苦労した。そこでこの記事から何回かに分けて、NotionをヘッドレスCMSとして使うにあたっての困難とそれを乗り越えるための工夫について書き残す。 今回の内容はNotionの開発者向けAPIとSDKをTypeScriptで利用するにあたって苦労した点だ。 Notion JavaScript Client公式ドキュメント に書かれているように、Notion A

Angularアプリケーションの状態管理の方法はさまざまな実装がありえるが、その中でも典型的ないくつかのパターンを、それがどのようなニーズがあって選ばれるのかという考察を踏まえながら列挙する。パターンとその特徴を例示するのであって、それぞれのパターンにおける最良の実装を示すものでもないし、これらのパターンに該当しない実装を否定するものでもない。 Standalone Componentsなど、Angularのメンタルモデルが変わっていく兆しを見せる今、これらをまとめておくことは諸々のAngularアプリケーションの状態管理のあり方を見直すきっかけになるのでないかと思う。特に、NgRxがデファクトスタンダードであり唯一の選択肢だと考えている人には、それが単にひとつの選択肢であることを思い出してもらえるのではないだろうか。 コンポーネントクラスによる直接の状態管理一番最初のパターンは、次の例の

https://contrib.rocks はGitHubのAPIから取得したコントリビューター情報からSVG画像を生成している。これまでは SVG.js を使ったTypeScriptでの実装だったが、興味本位でRustで実装したものをWebAssembly(wasm)として実行するようにしたところ、パフォーマンスが顕著に向上したためそのまま採用することにした。 Rustもwasmもまともに触ったのは今回がはじめてだったため、実装には洗練する余地が多分にあるだろうが、この記事ではとりあえず作業の記録を書き残す。 NxワークスペースにRustをセットアップするまずはじめに、Nxのワークスペース内でRustの開発環境を整えた。Cargoにもワークスペース機能があり、複数のプロジェクトの依存関係解決を集約できる。 ドキュメントに従い、ワークスペースのルートディレクトリに Cargo.toml を

TL;DR npm i -D jest @types/jest jest-preset-angular rm karma.conf.js src/test.ts touch jest.config.js src/setup-jest.ts jest-preset-angular プリセットを jest.config.js から読み込む require('jest-preset-angular/ngcc-jest-processor'); module.exports = { preset: 'jest-preset-angular', setupFilesAfterEnv: ['<rootDir>/src/setup-jest.ts'], };

今後は actions/setup-node の cache オプションで事足りるだろう。以下は読まなくていい。 GitHub Actions で継続的インテグレーション・デプロイを構成すると、すぐに問題になるのはキャッシュの活用だろう。 特に Node.js プロジェクトでは NPM から依存パッケージをダウンロードする時間がワークフロー実行時間全体の大部分を占めることも珍しくない。 毎回すべての依存パッケージをインターネット越しに取得することはなるべく避けたい。そこでキャッシュの出番になる。 GitHub Actions ではデフォルトで何もキャッシュされないため、基本的には公式のactions/cacheを使うことになる。 actions/cacheはキャッシュするファイル・ディレクトリを指定し、それにキャッシュキーを紐付けるだけ、という単純なものだ。

Original: Crunchbase And Angular: Why We Made The Transition - Crunchbase Written by: Justin Appler, Director of Engineering, Applications at Crunchbase Translated at: 2021-03-04 2017 年 11 月、Crunchbase.com は新しいウェブプラットフォームでリニューアルしました。何百万人もの Crunchbase ユーザーを新しいサイトに移行しましたが、ダウンタイムはほとんどなく、SEO への悪影響もありませんでした。新しいウェブプラットフォームは今後数年にかけてサイトとプロダクト、そして会社の成長を可能にするために構築されました。 その過程で下した数多くの決定の中で、最も重要だったのは新しいウェブプラット

Angular CLI v11.2 からTailwind CSSの公式サポートが追加された。 コミュニティでは以前から@ngneat/tailwindのようなサードパーティライブラリによってサポートされており、そういう意味では Angular + Tailwind CSS の組み合わせ自体は今に始まったものではない。 とはいえ公式サポートされたことによりこれまでよりも多くの Angular ユーザーが Tailwind CSS を検討するようになるだろう。 この記事では Angular と組み合わせる上での Tailwind CSS の使われ方について個人的な所感をまとめる。 あくまでも所感であり、開発者コミュニティがどのようなプラクティスを支持していくかはまだこれから模索されていく段階であることを念頭に置いてもらえればと思う。 前提として、それなりに持続的な開発を見込む（メンテナビリティ