Go1.16からは go get は使わず go install を使おう - Qiita
この記事はGo Advent Calendar 2020 16日目の代打記事です。奇しくも16日目にGo1.16の話をすることになりました。 【追記】タイトル改題しました 状況が落ち着いてだいぶ経ったのと、未だに多くの方にこの記事を見ていただけていることから、Go1.16での変更というより、今を生きる私達がどうすればいいか、という点にフォーカスしたタイトルに改題しました。本文に変更はありません。一応注記すると、go get が廃止になったわけではなく、普段の開発フローで使うことはまずなくなった、という意味です。（一通り読んでいただければお分かりいただけるかと。） 【追記】Go1.18について ついに待望のGo1.18がリリースされましたね！ https://go.dev/doc/go1.18#go-command そして予告通り go get によるインストール機能は削除されました。どうし
Test Flakiness - One of the main challenges of automated testing
What I would like to see is a breakdown of how many failures fall into which category. And of the above categories, while useful for root cause analysis and eventual fix, for sake of triaging results, and disposition of what to do if hitting such a failure, it seems that whether or not the failure is a true product failure is a HUGE difference from the other three. For the other three, the major r
プロダクトコードの静的解析にhorusecを入れた話 - freee Developers Hub
この記事はfreee アドベントカレンダー16日目です。 みなさんこんにちは。PSIRTというチームでエンジニアをしているlivaです。PSIRTという聞き慣れない単語ですが「Product Security Incident Response Team」の略で、文字通りプロダクトのセキュリティにフォーカスしたチームです。元はCSIRT(Computer Security Incident Response Team)でまとめてやっていたんですが、今年の夏頃から分かれて動いています。業務内容は今までと何一つ変わっておらず、AWS触ったりGCP触ったりプロダクトチームへセキュリティ関係のことで首突っ込んだりとプロダクトのセキュリティに関することは色々やっています。 さて、今回の話題はタイトル通り「プロダクトコードの静的解析」についてです。 今まで各プロダクトごとにツールが運用されていたりいな
Go のGCのオーバーヘッドが高くなるケースと、その回避策 - Qiita
Go のGCのオーバーヘッドについて GoのGarbage Collector (GC)の性能は非常に優秀で、オーバーヘッドが問題となることはあまりありません。ただヒープを非常に多く使っている場合、GCが多くのCPU時間を消費するケースがあります。 本記事では、まずGoのGCの概要に触れ、その後GCオーバーヘッドが高くなるケース、そして回避策を検討します。 本記事は下記記事を大きく参考にしています。素晴らしい記事に感謝いたします。 Avoiding high GC overhead with large heaps 注意点 単に pprof を取得し、GCが多くCPU時間を消費していた場合、必ずしも本記事が扱う、ヒープの多さ依存の問題が原因とは限りません。 GoのGCは、直近のGCを行った結果生き残ったデータ量に対して、新たにアロケートしたデータの量が一定値を超えると実行されます。 1 こ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
