タグ

ブックマーク / future-architect.github.io (3)

  • Go Tips連載8: logパッケージでログ出力している場所の情報を出す | フューチャー技術ブログ

    Go Tips連載の第8弾です。 Go tipsということで、シンプルネタを投稿します。 検索窓に入れると「printデバッグでいつまで消耗しているの?」とか「printデバッグにさようなら」とかサジェストされつつも、根強く生き残っているのがprintデバッグです。むしろ、非同期だったり並列処理だったりプロセスまたぎ、ホストまたぎが増えてくると、同期的に動くデバッガーが逆に使いにくかったりもありますし、デバッガーを使うにしてもブレークポイントを仕掛ける場所のあたりをつけるためにprintデバッグの力を借りたりもあるし、いっそのことprintデバッグの方が進化しろ、と個人的には思っています。分散トレーシングは進化したprintデバッグだと思っています。 Goでprintデバッグの友といえば標準ライブラリのlogパッケージですね。logパッケージには色々カスタマイズポイントがありますのでそれを

    Go Tips連載8: logパッケージでログ出力している場所の情報を出す | フューチャー技術ブログ
    zetamatta
    zetamatta 2020/09/07
  • Go Tips 連載5: エラーコードベースの例外ハンドリングの実装+morikuni/failureサンプル | フューチャー技術ブログ

    概要TIG DX所属の多賀です。最近は設計をしつつ Go も触れて引き続き楽しく仕事してます。 今回は、errors package を一部利用して、エラーコードベースのエラーハンドリング処理を実装しました。また、morikuni/failure を利用した実装への書き換えも試してみています。 エラーコードベースの例外ハンドリングについて前提としてGoで書かれた HTTP APIサーバーに対してのエラーハンドリングについて記載します。 エラーコードベースの例外ハンドリングについてですが、アプリケーションで発生するエラーを事前にラベリングしてコード化し、コードをもとにエラーハンドリングを実施することとします。発生時の運用対応や影響について、事前に一覧で整理することで、運用負荷を下げる意味があると考えています。(補足: Futureではメッセージコードと呼称することが多いですが、一般的な命名で

    Go Tips 連載5: エラーコードベースの例外ハンドリングの実装+morikuni/failureサンプル | フューチャー技術ブログ
    zetamatta
    zetamatta 2020/05/23
    ユーザに通知するエラーとプログラム内で処理すべきエラーを別に分けるのはあるある。で、前者にIDをつけるというのは、リソースを外部に出さなければいけない仕組み(Visual Studio)ではよくある(resource.hな).
  • Serverless連載3: Goでサーバーレス用の検索エンジンwatertowerを作ってみました | フューチャー技術ブログ

    サーバーレス連載の3回目は検索エンジンを作ってみたお話です。 クラウドサービスが充実してくるにつれて、サーバーレスではいろいろなことができるようになっています。HTTPサーバーは動きますし、RDBやNoSQLなストレージも使えますし、PubSubみたいなサービスも利用できます。これらを駆使するとそこそこ複雑な処理も記述できます。 一方で、上から下までサーバーレスにしようとするとできないものもいくつかあります。例えば、RDBも使えるといっても制約があり、LambdaやCloud FunctionsからRDSやCloudSQLを雑に使うとコネクションを張りすぎる問題があります。LambdaにはRDS Proxyが出始めています。あと、RDBそのものは基的に常駐型なのでサーバーレスではないです。一応サーバーレスなのもありますが、起動時間が結構かかるらしい(自分ではまだ試してないです)。それ以外

    Serverless連載3: Goでサーバーレス用の検索エンジンwatertowerを作ってみました | フューチャー技術ブログ
    zetamatta
    zetamatta 2020/03/27
  • 1