はてなブックマーク

はじめに 日々育児、家事と仕事を両立し最新の技術動向もキャッチアップしているパパママエンジニアの皆さまお疲れ様です。 そんな心身ともにぼろぼろな子育てエンジニアのみなさんはPCに向かって作業をしている時間が至福の時となっていることでしょう。 しかし、そんなひと時を邪魔する小さな訪問者が存在するのです。 本記事ではそんなかわいい訪問者を喜ばせてあげるためのTipsをいくつかご紹介します。 対象読者 1 ~ 3歳くらいのお子さんを持つエンジニアの方 在宅で仕事をすることが多い方 最近、仕事部屋に子どもが入ってきて困っている方 とはいえ、かわいい子どもを喜ばせてあげたい方 slコマンド slコマンドはlsコマンドのタイポを矯正するための素晴らしいコマンドです。 MacであればHomebrewでインストールできるので、まだインストールしていない方はインストールしましょう。 実行すると以下のようにS

はじめに この記事を読んでいるみなさんは単体テストの考え方/使い方はもう読まれましたでしょうか？わたしは単体テストの考え方を読んだことでテストに対して漠然と思っていたことが言語化されたように感じ大変感銘を受けました。その勢いで以下のようなzenn本も書かせていただきました。 なのでしばらくはモックを極力使わない古典学派的な思想に寄っていたのですがモックを使ったテストの開発現場のレビューにて 「テスト対象の依存関係をモックにしたらテストすることがなくなりました。」 というコメントをチラッと見かけてしまい、モヤっとしました。というのもその感覚には覚えがあったからでテスト対象のオブジェクトの依存関係が多く、処理内容がその依存関係を手続き的に呼び出しているだけだったりするとそれら全てをモックやスタブに置き換え、期待する動作を自分で設定することになるのでテストが成功しても「そりゃそうだよな」という気

最近業務でgRPCのServer Streamingを使ったリアルタイム処理をGoで書いているのですが複数のゴルーチンを起動した並行処理が絡んできたりと少しコードベースでテストを書くのが大変だなと感じており、前から気になっていたrunnを使ってE2Eテストを書いてみたためその備忘録です。 runnではgRPCランナーが実装されておりStreamingも全てサポートされているのでシナリオ自体は書けるのですがServer Streamingの裏側でRedisを購読しており、RedisにmessageをPublishしないと処理がブロックされてしまうのでgRPCランナー実行中に並行してRedisのPublishをしたかったのですが調べた限りrunnの機能だけでは実現できそうになかったため少し力技でテストを書きました。 もし、もっといい方法あるよという方がいましたらぜひコメントなど気軽にいただける

GoでDBマイグレーションをどうやるのがいいか検討していたところAtlasというツールが良さそうだったので一通り使ってみたまとめです。 対象読者 GoプロジェクトのDBマイグレーションに興味がある人 Atlasの使い方に興味がある人 Atlasとは Atlasはデータベーススキーマを管理するためのツールおよびwebサービスを提供しています。従来までのバージョンによるマイグレーション管理だけでなくDBの理想状態を宣言的に記述することでスキーマを反映することができます。DBの理想状態はHCL、sql、jsonがサポートされています。 Atlasは非常に高機能でCLIツール、GitHub ActionsのようなCI、Terraformプロバイダーなどを提供しています。 Go製のORMであるentで採用されているマイグレーションツールですがent以外のORMと合わせて使用できますし、go-migr

Protocol Buffers(Protobuf)を用いた開発(主にgRPC)にはprotocのようなコンパイラが長い間使われてきました。 コード生成やドキュメントの作成、REST APIとしてのゲートウェイの実装など便利で柔軟なprotocプラグインが利用できる一方、そのためのコード生成コマンドは複雑になりがちです。 こういったProtobufを用いた開発に関わるさまざまな問題をBufは解決するためにBuf CLIやBuf Schema Registry、Connectプロトコルなどさまざまなツールやプロトコルを開発しました。 本書ではBufが開発したさまざまなツールやプロトコルを使用し、現代的でモダンなProtobuf開発について紹介します。

「単体テストの考え方/使い方」という書籍の中でテストの書き方により「古典学派」と「ロンドン学派」に分けられるということが書かれています。 現代の開発現場ではモックを使用したロンドン学派的なテストを書くためにも依存性の逆転を使用したクリーンアーキテクチャのようなアーキテクチャが採用されるケースが多くなってきたなと感じます。 この本ではモックを極力しようしない古典学派的なテストの書き方にこだわったアーキテクチャをGoを使用して再考していきたいと思います。

最近のSpringを使った実装は大体フロントから何かしらで呼ばれる想定のAPI実装が多いけど認証の実装をちゃんとやったことがなかったので色々調べた。 Spring SecurityはSecurityConfigを作って色々設定して独自でUserDetails実装するくらいの知識しかなかったのと以下のような理由で迷宮入りする。 Spring Security5.7で書き方が結構変わってる。 Springで全部書いてる想定のフォーム認証の方法がやっぱり多い。古めの記事は大体そう SPAとかのAPIとしてのSpring Securityの認証記事が少ない。 Spring Securityが基本カスタムして実装するようになってて、自由度が割と高く、書き方が同じものが意外とない。(みんな微妙に違う) Spring Securityが理由でSpringが嫌いにならないように実装方法とポイントを書いてい

一応これの続き 今回の成果物 やりたかったこと kotlin + Spring bootの組み合わせで普段開発をしていてSpringでない軽めのフレームワークで開発したくなった。その候補としてquarkus, micronaut, Ktorを順番に触ってみてその比較、最終章。 ktorとは ピュアkotlinの軽量フレームワーク。quarkus, micronautと違って純正kotlin。kotlin好きのためのフレームワーク。coroutineによる非同期クライアントおよびサーバー処理をかける。安心のJetBrainsが開発をしている。起動も早いためサーバーレス、コンテナ環境でも活用できる。quarkus, micronautがクラウドネイティブ時代のマイクロフレームワークとして誕生したように感じるが、ktorは「軽量で非同期でkotlinらしく」みたいな雰囲気を感じる。純正kotli