はてなブックマーク

Go 1.14 で testing パッケージに新しく t.Cleanup(func()) や b.Cleanup(func()) が導入されました。 最初は今まで defer を使っていたところを置き換えられるくらいしか良いところがないかな〜と思っていましたが、想像以上に柔軟な使い方ができるので今まで使用したパターンを書いておきます。 Cleanup の特徴 テストランナーは panic ハンドラがあるので、Cleanup は panic が起きたとしても常に呼び出されます。例えば、以下のコードではちゃんと called が出力されます。 func Test_main(t *testing.T) { t.Cleanup(func() { fmt.Println("called") }) panic("") } The Go Playground 別 goroutine で panic し

Go 1.13 からの新しい errors Go 1.13 からエラー処理が強化され、errors パッケージに As と Is 関数が追加されました。これにより、今までは pkg/errors のようなライブラリを使用しなければ実現するのが難しかった、型情報を保持したままの wrap/unwrap が可能になりました。 サードパーティのライブラリに依存せずに実現できるのは非常にありがたい反面、移行コストが高そうでなかなか移行できていないプロジェクトも多いかと思います。また、pkg/errors ではスタックトレース情報を保持してくれますが、Go 1.13 errors では保持してくれないといった問題もあるため、完全移行が難しいといったケースもあると思います。 pkg/errors の Go 1.13 errors 対応 しかし最近、以下の Pull Request がマージされ pkg

Go でテストを実行する際は動的に生成された main 関数がエントリポイントとなっています。 Go 1.13 からはテスト実行時のテストフラグ (-v や -coverprofile など) の登録がこの生成された main 内で行われるようになったため、 main より先に実行される init 内でフラグの登録を行っているテストではフラグのパースがうまく動かず、テストが落ちるようになります。 たとえば、自分が開発している Evans では golden files testing のために --update フラグを e2e パッケージで用意し、これが有効になっている場合のみ golden files を更新するような設定になっていました。 var ( update = flag.Bool("update", false, "update goldens") ) func init()

これは Aizu Advent Calendar 2019 の 15 日目の記事です。14 日目は uzimaru0000 さん、16 日目は kacky__917 さんです。 はじめに 世の中には日々たくさんの価値ある Web サービスが生まれていますが、その価値を正しく提供するにはアプリケーションが正しく動かなければなりません。 たとえばアプリケーションは適切なユーザに適切なリソースを提供しなければならず、エラーを返す際は十分に定義された仕様に沿って返し、UI 側ではユーザに適切なメッセージを表示しなければなりません。 実際のところ、これらを厳密に実現するのは非常に困難ですが、アプリケーションにはこれら以上に複雑な問題が常につきまといます。 現在の Web アプリケーションはほとんどが分散システムの一形態です。例えばクライアントとサーバや、サーバとデータベースがネットワークを介して接続

Multi-Module Repository Go Modules では Git で管理されているリポジトリ内に複数のモジュールを定義することが可能です。*1 これを利用すると、たとえばプロジェクト内で使う Go ツールの依存管理をプロジェクトのコードとは異なる go.mod で行うことができます。 $ go mod init # create project go.mod $ mkdir tools && cd tools $ go mod init # create tools go.mod $ cat <<EOF // +build tools package tools import ( _ "github.com/rakyll/statik" ) EOF $ go get -tags tools ./... # add tool dependencies to go.mod こ

はじめに 今年の 8 月にリリースが予定されている Go 1.13 では、Go 1.11 で導入された Go modules に加え、Go module proxy といった新しいエコシステムが登場します。 そこで、そもそも Go modules は何を行っているのかや、何ができるのか、どういった要素で構成されているのかを紹介します。 また、古い Go バージョンから Go 1.13 へアップデートする場合や、 dep や Glide といったベンダリングツールから Go modules へ移行する際の懸念点も併せて紹介します。 先日発表した "Go Modules and Proxy Walkthrough" はこのポストがベースになっています。 TL;DR な人はスライドを見るのがおすすめです。 speakerdeck.com Go Modules Go modules という仕組みは

正確には株式会社メルカリに入社して株式会社メルペイに出向、という形です。「株式会社メルカリに新卒入社しました」というエントリタイトルが多かったので重複を避けるためにこう書きました。 4 月に入社してちょうど 3 ヶ月が経ち、無事解雇されずに試用期間を終えたので入社エントリを書きました。 入社するまでのこと メルカリという選択肢をソフトウェアエンジニアとして意識し始めたのは、大学の先輩である upamune さんに紹介して頂いた頃からでした。たしか学部 2 年の冬頃だった気がします。 翌年の初夏頃に yuzushioh と yamashou と知り合い、当時メルカリ・ソウゾウで働いていた yuzushioh くんが tenntenn さんと自分たちを繋いでくれて、その以降しばしば tenntenn さんが会津大学にきてくれるようになりました。 以下は tenntenn さんが初めて会津にきた

最近は設計をする際にできる限り API 仕様を正確に記述するようにしている。このことを意識し始めた大きな要因は主に次の 2 つだと思う。 1 つ目は以前、前職で働いているときに柴田さんに API 仕様の重要性を教えてもらったことから。この時に聞いたことは以下のブログ記事にまとまっているのでぜひ読んでほしい。 yshibata.blog.so-net.ne.jp もう 1 つは、今年の頭に読み終えた A Philosophy of Software Design から。この本では、複雑さを減らすために API の仕様が限りなくシンプルで、多くの機能を提供する deep module を目指すべき、といったことが言及されている。 Go ではドキュメントシステムとして GoDoc が提供されているため、上記のような洗練された正確なインターフェースを記述するためにこれを開発時に利用している。 ロー

fuzzy-finder fzf や fzy、skim などの fuzzy-search (あいまい検索) を提供する CLI ツールの登場により、コマンドラインでの操作はますます表現豊かになっています。 例えば、カレントシェルのコマンドヒストリの一覧から fuzzy-finder を使って選択したり、ghq + fuzzy-finder + cd の組み合わせで選択したリポジトリのあるディレクトリへ移動したりといったケースが挙げられます。 また、fuzzy-finder それ自体をコア機能として組み込んだツールも増えています。例えば、cd コマンドの拡張である enhancd はパスの履歴を保持し、fuzzy-finder を使って移動したいディレクトリへすぐに移動することができます。また、拙作の itunes-cli は、iTunes で管理されている曲の一覧を入力にし、fuzzy-f

fuzzy-finder を構成するアルゴリズム fzy や fzf といった fuzzy-finder を使うと、stdin などからリストを受け取り、ユーザの入力によってマッチする行を絞り込むことができます。このとき、入力文字列の各文字は隣接している必要がありません。例えば、以下の画像のように baz という入力が与えられた時、これにマッチする行が絞り込まれます。また、マッチした行のリストは、入力値に基づいてより最適な順番にソートされて表示されています。同じく以下の画像の例を見てみると、入力後では baz という行が foobarbaz よりもセレクタに近い位置に表示されていることが分かります。このように、入力値が曖昧でも目当ての文字列を即座に見つけることができるのが fuzzy-finder の便利なところです。 上記のような機能は、approximate string matchi

A Philosophy of Software Design 作者: John Ousterhout出版社/メーカー: Yaknyam Press発売日: 2018/04/06メディア: ペーパーバックこの商品を含むブログを見る 170 ページくらいの洋書で、ソフトウェアの Complexity (複雑さ) について扱っている。洋書ではあるけど、難しい表現はあまりなく読みやすかった。 この本の冒頭で、Complexity を「ソフトウェアシステムを理解しづらくさせたり、変更させにくくする、システムの構造に関連するすべての要素」と定義し、それによって引き起こされる問題を述べている。 それ以降の章では、いかにして Complexity を減らすかというところにフォーカスし、モジュールの設計やレイヤーごとの抽象度、エラーの定義とハンドリング、コメントの種類と記述すべき場所など、さまざまな視点か

はじめに ツールのバージョン管理が煩雑 ツールの統一的なインストール方法がない ktr0731/dept Go Modules におけるツールの依存管理 dept を使った依存管理 dept の実装 まとめ はじめに Go プロジェクトでは、しばしば静的解析ツールが使用されます。例えば、自分のあるプロジェクトで考えてみると、ソースコードの整形には gofmt 、lint には golangci-lint/golangci-lint 、モック用コードの生成には matryer/moq 、CI でのリリース作業では mitchellh/gox と tcnksm/ghr が使われています。Go は静的解析を行いやすいプログラミング言語であるため、こうした静的解析ツールは日常的に使用されています。 しかし、Go プロジェクトにおいて、そういったツールの管理に関する問題がいくつか挙げられます。 ツー

これは Aizu Advent Calendar 2018 の 2 日目の記事です。 1 日目は @Ruto009 さんで、3 日目は @ayanoaizu さんです。 adventar.org gRPC-Web is GA! 今年の 10 月末に、gRPC-Web がついに GA (Generally Available) となり、メジャーリリースが行われました 🎉 grpc-web is GA! https://t.co/fnjHwgEWpe Grab it from https://t.co/DVThxsRh3i. Huge thanks to everyone who participated in making this possible!— gRPC (@grpcio) 2018年10月24日 grpc.io gRPC は、HTTP/2 ベースの RPC フレームワークで、I

今年の 8 月 26 日から 9 月 1 日の間、Mercari BOLD Scholarship で Go 最大のカンファレンスである GopherCon へ参加していました。 tech.mercari.com GopherCon 2018 は希望者のみ参加できるワークショップ、3 日間に渡って行われるトークセッション、最終日に行われるライトニングトーク (LT) や Go チームコミュニティにより行われる Go コントリビューションワークショップなどで構成されていました。その他にも Welcome Party などをはじめとする色々なイベントが用意されていました。 実際のスケジュールは以下のページから見ることができます。 www.gophercon.com 自分はワークショップを含む全ての日程に参加していました。以下では参加したワークショップと、特に興味深かったセッション、LT につい

去年の秋頃から作っていた gRPC クライアントツールである Evans が今年に入り、徐々にいろんな方々に使われ始めました。 github.com Issue や Pull Request を頂けてとてもありがたい反面、それらを反映したバグフィックスや機能追加がツールに取り込まれても、ユーザは能動的に GitHub Releases をチェックしなければそのアップデートを知ることができません。 これは開発者的にもユーザ的にも損失です。そもそもユーザがアップデートを利用できるかどうか確認する作業や、アップデート方法に関する知識 (どういった方法でインストールしたかどうかなど) を知る必要も本来は必要ないはずです。 この問題をどうにかしたいと思い、最近は CLI ツールの配布、自動アップデート機構に関するワークフローを整備していました。 そのために使用したツールや開発したライブラリ、その経緯

この記事は Aizu Advent Calendar の 20 日目の記事です。 adventar.org 前日は id:nktafuse の 、 nktafuse.hatenablog.com 明日は id:ywkw1717 です。 ywkw1717.hatenablog.com きっかけ 最近職場で Clean Architecture を取り入れたアプリケーションを Python で書いていて、Go でも書けないか？という試みではじめました。 作ったものは、サーバにアップロードしたファイル自体の改竄を検出できる簡易ファイルアップローダみたいなものです。 github.com 以下では CA について簡単に解説した後、設計・実装する上で悩んだ点などを挙げています。 Clean Architecture 原文と翻訳版は以下。 8thlight.com クリーンアーキテクチャ(The Cl

去年の今頃から毎日 GitHub に commit しようと決心し、最近 365 日を達成しました！ いい感じ なぜかデフォルト表示の方の左上が白くなってますが、ちゃんと一年経っています。 意図 そもそもなぜ始めようとしたかというと、技術の習得には input と output が大事で、input で得たものが output によって定着すると思っていたからです。 output の手段には、ブログや Qiita を書いたり、LT だとかハッカソンでもいいかもしれません。実際、自分も LT でよく発表したりしています。 とはいえ、それらはどのくらい output できているかの可視化ができないので、モチベーションを保つのは少し大変かもしれないと思っていました。 そのため、GitHub の草を output の可視化として利用したらいい感じになるんじゃないかなと思って始めました 🙌 今年の

先日の A(izu)LT 0x09 で「Evans: more expressive universal gRPC client」 というタイトルで発表してきました。 タイトルの通り、gRPC クライアントをつくった話です 🙌 atnd.org ALT は、会津大学の有志によって年に二回ほど開催されている LT (Lightning Talk) 会で、次回でついに 0x0a 回目を迎えます！めでたい 🎉 発表したスライドはアップロードしています。大体のことは以下に載っているけど、ちょっと補足をしておきたいと思います。 speakerdeck.com 後日、Go 1.10 Release Party in Tokyo にて、より整理した内容で発表を行いました。 speakerdeck.com つくったもの github.com Evans の目指したもの Evans は既存の gRPC

この記事は Aizu Advent Calendar 2016 (Qiita) の 17日目の記事です。 前の人は @acomagu1 さんです。 次の人は @noah_orberg さんです。 Neovim 突然ですが、Neovim はご存知でしょうか。 Vim は言わずもがな非常によく知られたテキストエディタの一つですが、Neovim はその Vim をフォークし、モダンなアーキテクチャで再実装したテキストエディタです。 数十年前からの秘伝のタレは美味しいかもしれませんが、数十年前から続くソースコードが美味しいはずもなく、現在ではメンテナンスが大変なようです。 Neovim はメンテナンスの簡略化、効率化も図っており、自身の大きな特徴の一つとなっています。 ソースコードはもちろん OSS で公開されています。 github.com 新しいプラグイン/GUIアーキテクチャ 他の特徴として

明示的に言ってはいなかったのですが、この1ヶ月間、はてなサマーインターン 2017 に参加していました！ 公式のページ 👇 developer.hatenastaff.com TL;DR 用に言っておくと、最高の夏でした！！！ 以下では、そのはてなインターンの思い出を振り返っていきたいと思います はてなと自分 応募 事前課題 前半課程 前半課程の合間 前半課程と後半課程の合間 後半課程 後半課程の合間 環境 感想 他のインターン生の記事 はてなと自分 はてなは、はてなブログ (このブログもそう) や、はてなブックマークとかの Web サービスを作っている会社で、知っている人も多いかなと思います。 自分が一番好き (だった) サービスはうごメモはてなで、小学6年生のころに DSi を買ってもらってうごメモに夢中になっていました。 実際にやっていないとわからないと思うけど、うごメモ → うご

最近、ついに Go (golang/go) にコントリビュートしました！ 正確にはレビュー中で、レビューが通ってもマージされるのは Go 1.10 なので、だいぶ先は長いですが取り敢えず自分のできることは一通り終わりました。 Go ではレビューシステムに GitHub は使っておらず、代わりに Google が開発した Gerrit を使っています。 普段の GitHub を利用したフローと結構異なっていたので備忘録がてらブログに書いておこうと思います。 なお、この記事は 2017 年 7 月 3 日現在のもので、情報が変わる可能性があるので必ず原文も目を通して下さい。 この記事は大雑把に原文を訳したものだと思ってください。 Contribution Guide - The Go Programming Language この記事は自分を含めた英語弱者のための補完記事としての立ち位置でお願

動機 最近のコマンドは大抵サブコマンド形式になっています。 $ docker pull hello-world このように、コマンド名 + サブコマンド + 対象 みたいな形式。 サブコマンドには大きく2種類あって、サブコマンドに動詞を指定するタイプと、リソースを指定するタイプがあります。 感覚的に、コマンドのパターンが多くなってくるとリソースを指定するタイプが主流になっている気がします。 最近だと Docker が以下のように動詞タイプからリソースタイプに移行しつつあるようです (現在はどちらのコマンドも利用できる) $ docker run hello-world # 動詞タイプ $ docker container run hello-world # リソースタイプ 動詞タイプのほうがタイプ数は少ないが、リソースタイプのほうが階層化されているので秩序がある。 とはいえ、割りと頻繁に利