この記事はGo2アドベントカレンダー2019の11日目の記事です。今年の春ぐらいから、sqlparserを Go で書いていて、作った parser を使っていくつか Utility 系のツールを書きました。簡単に書いたものの紹介と、Parser を書いた上での感想・反省点なんかを書いていこうと思います。

この記事はTypeScript アドベントカレンダー7 日目の記事です。 昨日はmasanori_msl さんの記事でした。TypeScript の Doc Comment の仕様として、TSDocがあります。 TSDoc 自体の仕様はinitial の draftも出ていない状況で、エコシステムが整いきっているとはまだ言い難い状況ですが、 すでに VSCode ではその Syntax Highlight に対応しているなど、今後は TSDoc が TypeScript の Doc Comment の標準的な仕様になるかと思われます。

PostgreSQL を冪等に管理できるツールを Go でフルスクラッチで実装してみました。 機能としてはsqldefとほぼ同等のものになります。 ただ、SQL Parser を PostgreSQL 向けに独自実装しており、`sqldef`より PostgreSQL に寄った内容になっています。作ったものはこちら。

TypeScript 向けに CommandLine Parser を作りました。 何が TypeScript 向けなのかというと、自分で定義したフラグに型をつけることができ、コマンドの本体を実装する際に、推論して出してくれます。 この記事ではこのツールの簡単な説明と、達成したかったこと 2 点Flag を型推論が効くようにする

このブログの実行環境として、Next.js と mdx を用いています。Next.js は公式で mdx のプラグインを提供していますが、 Syntax highlight などの細かい挙動は調整する必要があったので、その Tips をまとめておこうと思います。mdx とは、ざっくりいうと、`markdown`の中で`jsx`が使える仕組みです。 これにより、通常の Markdown だけでは表現できないようなリッチな見た目を提供することができます。 例えば、Link をリッチに見せる component の microlinkを使えば、 通常の`a`tag ではなく、下のように見せることが出来ます。

せっかく`.dev` ドメインをとったので、個人のブログをはてなから独自で管理するものに移しました（これ）。 最初はGatsbyを使おうかと思ったけれども、 なんだかんだで自分で書いても自分用のユースケースは満たせると思ったし、 いろいろ触ってみたい技術もあったので、 Next.jsと使ってブログサービスを書いてみました。

2018 年のアウトプットをまとめた上で、2019 年何していくのかをいくつかまとめていきます。去年は業務で書いたコードからいろいろ切り出して、公開したものが多かった。特に、自動生成や静的解析周りのツールを多く作った年になった。FE 向けバリデータ。去年作ったものの中で一番好き。紹介記事はこちら。JSer.infoでも触れて頂きました。

これを作っているときに、もともとのagreedとswaggerの型の帳尻を合わせるために、TypeSASTをいじっていろいろやりました。 そのときに調べたことなどをメモ代わりにまとめます。この内容は調べたこと+僕独自の解釈が入っている可能性があり、正確ではないかもしれませんが、ご了承ください。TypeScript Compilerを使うことにより、TypeScriptのASTの解析や編集などを行うことができます。linterや、静的解析、自動生成系のツールを作る際によく使う機能です。 例えば前述のagreed-typedではTypeScriptの型定義やコメントをASTを解析することにより抜き出し、そこからOpenAPI2.0(Swagger)を生成しています。 実際のアプリケーションコードを書く際には全く触れることはない（また、触れるべきではありません）機能ですが、用途を絞って活用することにより、利便性の高いツール群を実装することができます。

Go 言語の話です。 過去の記事でも触れたDave Cheney 先生の記事や、各種の error handling best practice でも触れらているように、Go の`error`は、そのまま return せず、`errors.Wrap`などで annotate すると良いとされています。 ですが、人間（というより僕）の心は弱いもので、つい手癖でそのまま`return err`してしまいます。これをいちいちソースコードレビューでチェックするのは辛いので、静的に検査できるツールを作りました。 またgo の analysis に関する記事を読んで、せっかくなので`anaysis`にも対応させました。 今回の記事ではツールの紹介と実装の紹介をします。

Goの1.11から`wasm`向けのバイナリを吐けるようになりました。 `wasm`上でパーサを実行し、GoのASTをビジュアライズするものを作ったので、その紹介をします。 作ったものはこちら。Goに限らない話かもしれないですが、コード自動生成や、静的解析系のツールを実装しようとする場合、ASTを扱うことがよくあると思います。 ASTを直感的に扱えるようになるためには相当な慣れが必要になり、はじめのうちは、コードがどういったASTにパースされるのかを把握するために、逐一`print`するなどして確認していました。 この作業の効率を上げるために、ASTのvisualizeをするツールをせっかくなので自分で作ってみることにしました。

この記事はGo2アドベントカレンダー14日目の記事です。GoのErrorハンドリングについては、これまでにも様々なパターンが発表されてきました。 今回は独自定義のエラーについて、これまでのパターンをまとめた上で、その実現をeasyにするgenerrというツールを作ったので、その紹介をします。Goのエラーハンドリングの中で、カスタムな`error`型を用いるパターンは比較的広く知られているかと思います。 その中からいくつかのパターンを紹介します。

agreed-typedというツールを現在開発中なので、その紹介をします。自分は普段バックエンドを書いているエンジニアで、フロントエンドエンジニア向けのツールであるagreedをメインで活用することはないのですが、APIのドキュメンテーションや、バックエンドとフロントエンドのAPIの整合性をとるという観点から、agreedを補完するためのツールとしてagreed-typedを開発しています。 その背景と、agreed-typedで実現したことを紹介していきます。

少し前にフロントエンドのjs向けvalidatorフレームワークの favalid というものを作ったので、その紹介記事を書きます。フロントエンドというかjs向けvalidatorといえば joi や yup 、v8nといったようなライブラリがありますが、それらに比べると機能を大幅に削り、とにかく軽量なのと関数型ライクなAPIがfavalidの特徴です。デフォルトのバリデーションメッセージすら入ってないので自分で定義しないとダメです。 ユースケースやコンフィグによりますが、最小構成でwebpackでbundleすると、1kbくらい。機能を色々盛り込んでも~10kbくらいになるかと思います。gzipを効かせれば容量は更に削減されるかと思います。

多くのプログラミング言語で `assert` というメカニズムが実装されています。 `assert` はプログラムを記述する人が、絶対にコードのこの場所ではこの値が入ってくる、という意志を表明するための仕組みです。 例えば、以下の `add(a, b)` のコードを見てみると、この `add(a, b)` では、２つの引数、 `a` `b` に数値以外の値が入ってきた場合、特に何か特別な処置をしない限り `Assertion Error` を発生させ、プログラムを終了させます。試しにやってみると