最近、自分のプライベートの開発環境を大きく変えたので紹介する。 先にまとめ プライベートではMacを使わなくなった 家にUbuntuが入ったミニPCを置いた 外からはThinkPad X1 CarbonからTailscale経由のSSHで家のミニPCに接続 購入まで まず、自分にとって最も大きな変化はプライベートでMacを使わなくなったことだ。2013年くらいにプログラミングを始めてからずっとメインのOSはMacだったので、約10年ぶり、ほぼ初めての非Mac環境である。 自分の普段の開発のユースケースは、Webアプリケーション開発とNode.js上で動くソフトウェアの開発、WebKitへのコントリビューション、たまにRustやGoやC/C++で自分専用ツールの開発、くらいなので別にMacで困っているわけではなかった。Web開発やNode.js上のソフトウェアの開発はまあ普通にMacで困らな

2023 年を振り返ります。 仕事 移転したユビーのオフィスにあるかっこいい壁 相変わらずユビーでプロダクト開発エンジニアをしていました。症状検索エンジン ユビーを開発するチームでフロントエンドとバックエンドを書いています。このプロダクト上で、製薬企業向けのソリューションを実現するための開発をしています。複雑なドメイン知識が求められる上に、会社の成長に伴って求められるデータやサービスの信頼性が上がってきていてチャレンジングな仕事だなと思っていますが、頼れる仲間と共に頑張っています。 また、仕事に関する記事をいくつか書きました。 テーブル駆動テストを使った QA エンジニアとソフトウェアエンジニアの連携 開発スピードを維持しながらモブプログラミングを実施した話 そういえば、たまに「どのくらい働いているんですが？」と聞かれることがあるんですが、普通にフルタイムで働いています。大学が忙しいときに

この記事はAlex Rattrayさんの A curious case of the ternaries を、本人の許可を得て翻訳したものです(タイトルは大幅に変えてしまっていますが)。 記事の最後にあるように Google Forms から新しい機能についてのフィードバックを求めています。私以外のメンテナーも読めるようにできるだけ英語で書いてほしいですが、「日本語でなら書いてもいいよ」という人がいたら日本語で書いてもらっても大丈夫です。 三項演算子のフォーマットは長年の課題でした。Prettier の v3.1.0 では新しいフォーマットのスタイルを導入することで、ついにこれを解決しました(訳注: 後述の通り、まだ experimental なので、--experimental-ternaries をつけたときのみ有効になります)。 このブログ記事では、これまでの経緯と背景、実際に触って

2023 年 7 月 5 日に Prettier 3.0 をリリースしました。Prettier 2.0 がリリースされたのが 2020 年 3 月 21 日だったので、実に 3 年以上ぶりのメジャーアップデートとなります。 本当はもっと早くこのブログを書きたかったんですが、やる気が出ずだいぶ遅れてしまいました。 この記事では Prettier 3.0 の主要な変更点を紹介します。 Prettier 3.0 の主要な変更点 Prettier 3.0 はメジャーアップデートということもあって大きな変更がいくつか含まれています。ここでは、そのうちユーザーに直接的な影響がありそうなものを紹介します。 ここで紹介する以外にも大きな変更はありますが、プラグイン開発者向けのものとか、Prettier のソースコード自体が全部 ECMAScript Modules で書かれるようになったとか、ユーザーから

最近、Kohta Ito さんのブログ記事 0 から始める Node.js パフォーマンスチューニング を読みました。Kohta Ito さんは、実践 Node.js 入門 という書籍を執筆されたことでも知られています。 このブログ記事の「framegraph 編」という節では、 Node.js でのフレームグラフの生成方法や見方が説明されています。私はフレームグラフというものを知ってはいましたが、それを見てパフォーマンスの改善に活かしたことはありませんでした。 ということで、Prettier のフレームグラフを眺めてみて、実際にちょっとだけパフォーマンスを改善してみました。この記事では、そのパフォーマンス改善について説明します。 フレームグラフを生成するツール 0x 0 から始める Node.js パフォーマンスチューニング では、フレームグラフを生成するためのツールとして 0x が紹介

先日、TypeScript-ESLintという OSS プロジェクトから $500 いただきました。ちなみに筆者は TypeScript-ESLint のチームに所属しているわけではありません。 この記事では、改めて TypeScript-ESLint というプロジェクトの概要を説明すると共に、筆者が $500 いただいた経緯や、TypeScript-ESLint の運営状況について説明します。 TL;DR 資金に余裕があり、TypeScript-ESLint を使っている個人や企業は TypeScript-ESLint プロジェクトに寄付することを検討してください。 TypeScript-ESLint への寄付は https://opencollective.com/typescript-eslint から行うことができます。 一応明記しておきますが、筆者は今回 $500 いただきました

Node.js の import specifier と ECMAScript の ImportSpecifier 先日 Firefox の JavaScript エンジンである SpiderMonkey の公式ブログに Import Maps についての記事が投稿された。 https://spidermonkey.dev/blog/2023/02/23/javascript-import-maps-part-1-introduction.html この記事は、そもそも ECMAScript Modules とは何かというところから入り、Node.js のモジュールシステムの歴史やブラウザの ECMAScript Modules との関係などを説明した後、本題である Import Maps について解説している。短い時間で読める面白い記事なので、まだ読んでいない人はぜひ読んでほしい。 この

つい先程、https://github.com/prettier/prettier/pull/14212 という Pull Request を next ブランチにマージした。 これは DefinitelyTyped で管理されていた Prettier の TypeScript 用の型定義を Prettier 本体のリポジトリへと移す Pull Request だ。この Pull Request によって、v3 からは @types/prettier をインストールする必要がなくなる。 JavaScript で書かれたライブラリをメンテナンスしている他の人の意思決定の参考になるように、この記事ではこの変更を行ったモチベーションや手法について説明する。 Prettier の JavaScript API の型定義の現状 Prettier は JavaScript から使える API を提供し

Prettier がデフォルトでインデントのためにタブを使うべきかどうか、現時点での私の考えです。 useTabs のデフォルト値を true にするという提案 Prettier には useTabs というオプションがあり、インデントのためにタブを使うかどうかを boolean で指定できます。デフォルトでは false が設定されています。 2 年ほど前に Prettier v2 の準備をしているときに Change useTabs to true by default という、useTabs のデフォルト値を true に設定することを提案する issue が作成されました。 この issue での議論は活発に行われ、建設的なコメントや逆に全く建設的でない人格を批判するようなコメントなど、実に多くの意見が寄せられました。 この issue が作成れたのは v2 をリリースする直前だっ

この記事には誰かを攻撃したり差別したりする意図はありません。もし不適切な表現を見つけた場合は修正しますのでご連絡ください。 「インデントにタブとスペースのどちらを使うのか」というのは昔から何度も議論されてきた問題です。 最初に明確にしておきますが、私個人としてはタブを使おうがスペースを使おうが、プロジェクト内で統一されていれば構いません。 しかしタブには、スペースにはないアクセシビリティ上の利点が存在します。 タブの最大の特徴は、表示幅を自由に設定できることです。 ご存知のとおり、一つのタブに対して実際の見た目としてどのくらいの幅が確保されるかは、テキストエディタなどのコードを閲覧する環境の設定次第です。 たとえば、GitHub は一つのタブをデフォルトではスペース 8 個分の幅で表示しますが、 https://github.com/settings/appearance から自由に変更で

期末テストやらなんやらで忙しく、一週間くらいアドベントカレンダーをさぼってしまいました。この記事も電車の中で書いています。 さて、今日は Node.js ライブラリにおける Pure ESM 対応の話です。 前提 Prettier で採用していた方法を紹介する目的でこの記事を書いています。 Prettier は npm にパブリッシュするときには esbuild でバンドルしていますが、ソースコードは CommonJS Modules で記述されていて Node.js からそのまま実行できます。これは GitHub から直接 Prettier をインストールした場合でも Node.js で動作するようにするためです。 こういったケースはほとんどないと思いますので、ここで紹介する手法で有効である場合は少ないでしょうし、後述しますがデメリットが多いので普通にやらないほうがよいと思います。 世は

この記事を書いているのは 12 月 17 日なのでもう 3 日分書いていないことになりますが、頑張って追いつきたいと思います。 筆者が 2022 年に OSS 活動によって得た報酬を公開します。 前提 筆者はUbie 株式会社のフルタイムのソフトウェアエンジニア兼大学生であり、余暇時間にいくつかの OSS に関わっています。 主に Prettier というコードフォーマッターのメンテナンスをしています。 目的 この記事の目的は、読者の誰かがお世話になっている OSS プロジェクトに対して寄付や貢献をするきっかけになることです。ぜひお願いします。 筆者が受け取っている OSS 活動による報酬には大きく分けて二種類あります。 一つ目は OSS プロジェクトの OpenCollective から分配された報酬です。Prettier の OpenCollective に集まった資金を毎月 $150

ブログを毎日書くというのは、想像以上に大変なんだなあと思い始めています。そろそろ折り返しなのでこのまま頑張ろうと思います。 本日のテーマは Prettier 3.0 です。 Prettier の現在の最新バージョンは 2.8.1 で、そろそろ 3.0 をリリースしたいと考えています。 もともと計画していた変更のほとんどは、すでに next ブランチに取り込まれていて、現在は細かい調整をしている段階です。 そこで、ちょっと早いですが Prettier 3.0 に含まれる予定の変更のうち重要なものをここで紹介します。 Markdown のフォーマットにおいてラテン文字と日本語の文字の間にスペースが入らなくなる 長いこと待ち望まれていた機能だと思います。 私はJavaScriptが好きです が 私は JavaScript が好きです というようにスペースが入ってしまう問題が、ついに修正されます。

大きめのテーマです。もしかしたら「うちでは書いた JS をそのまま配信してるぜ〜」って人もいるかもしれないでが。 最近の Web フロントエンド開発では、書いた JavaScript をそのまま動かさないことが多い 最近のフロントエンド開発ではエンジニアが書いた JavaScript をそのままブラウザで動かすことはほとんどないかもしれません。 例として最近流行のフレームワークを考えてみましょう。Next.js や Remix、Nuxt.js など、いずれも内部的にトランスパイラやモジュールバンドラを使い、エンジニアが書いた JavaScript を別の形へと変換してからユーザーのブラウザで動かすような仕組みになっています。 一昔前だと Next.js のようなフレームワークが今ほど発展していなかったこともあり、webpack や Babel を直接使っていたと思いますが、それも同じです。

学校の課題や仕事をどうしてもやりたくないけど、数時間だけ余裕があって、プログラムは書きたい！というとき、みなさんはどうしていますか？ 最近の自分は ESLint をやっています。ということで自分が実装した変更を紹介していきます。 基本的に、ESLint の Rules ドキュメントを眺めてみて「バグがありそうだな〜」とか、「このルール足りてなさそう！」とか思ったときに Issue を作成して修正する方針でやりました。 ESLint の Contributor Pool プログラム ESLint には Contributor Pool プログラムというものがあります。OSS プロジェクトとしてとても良い取り組みだと思うのでここで紹介します。 Contributor Pool プログラム は、ESLint チームが外部の貢献者に対してその貢献に応じて報奨金を支払うという取り組みです。 私は E

先日 Babel のメンテナーとして知られる Nicolò Ribaudo 氏が次のツイートを投稿した。 We finally finished migrating the Babel monorepo from Flow to TypeScript! It has been a very long process started by @z_bodya, and after migrating package-by-package @JLHwung just opened this PR 😄 pic.twitter.com/WKXxV8x2MY — Nicolò Ribaudo 🏳️‍🌈 • 💙💛 (@NicoloRibaudo) July 23, 2022 そう、JavaScript のトランスコンパイラである Babel のソースコードが Flow から TypeScrip

医療 AI スタートアップ Ubie(ユビー) に 3 月に入社していました。この 7 月で入社してから 4 ヶ月になります。本当はもっと早く入社エントリを書きたかったのですが、だらけていたらなんと 4 ヶ月経ってしまいました。 入社ツイート 誰？ JavaScript やフロントエンドを触っているエンジニアです これまでは筑波大学の情報学群情報科学類(学部)に通いつつ業務委託として働いたり、Prettier や Babel などのオープンソースプロジェクトのメンテナーやコミッターをやったりしていました。 より興味がある人は2021 年の振り返りブログや、私の Twitter を見ていただけると良いと思います(Twitter には日常的なことを書き込まないようにしているのでどういうエンジニアなのかはわかりやすいと思います)。 Ubie って？ Ubie は 2017 年にエンジニアの久保と

@azu さんのブログ記事 Maintainer Month: オープンソースをメンテナンスするコツ を読んで GitHub が Maintainer Month というイベントを主催していることを知りました。 自分は Maintainer Month の Sponsoring の対象でありませんが、自分がオープンソースのプロジェクトをメンテするときに考えていることを書き残しておこうと思います。 オープンソースガイド などにはすごいためになることが書かれていますが、積極的な内容で自分にとっては読むだけで疲れてしまうような内容でもあります。なのでこの記事ではあえて自分が普段考えていることの中でも消極的なことについて書いてみます。 オープンソースのメンテナンスに疲弊している人や、オープンソースに貢献している人、もしくは貢献しようと思っている人に「こんなゆるい気持ちでやってる人もいるんだ」と思っ

この記事では Type Annotations プロポーザルの概要とモチベーションについて説明する。 概要 Type Annotations プロポーザルは 2022 年の 3 月 9 日に Microsoft の TypeScript チームの Program Manager である Daniel Rosenwasser 氏のブログ記事 A Proposal For Type Syntax in JavaScript で発表され、2022 年 3 月の TC39 ミーティングで Stage 1 になった。 Type Annotations プロポーザルは JavaScript に TypeScript のような型注釈の構文を導入する。 たとえば、次のような型注釈を持つ関数宣言などが可能になる。 function hello(name: string): void { console.lo

実は先日リリースした Prettier 2.6 では前のバージョンである 2.5.1 と比べてバンドルサイズが 3MB ほど減っています。 Prettier 2.5.1 のサイズ(20.0MB) Prettier 2.6.0 のサイズ(16.9MB) リリースブログで言及したとおり Prettier 2.6 ではモジュールバンドラーを Rollup から esbuild に移行したので、その影響かと思われるかもしれませんが実はそれだけではありません。esbuild への移行によって減ったバンドルサイズはそれほど大きくはありませんでした。 バンドルサイズが 3 MB 減ったのは泥臭いチューニングをいくつか行った結果なのです。 この記事では Prettier 2.6 で実施したバンドルサイズを減らすテクニックを紹介します。 きっかけ ライブラリのサイズは大きいより小さい方が当然良いですが、その