Hiroaki Nakamura さんはインスタンス mstdn.jp のユーザーです。アカウントさえ持っていればフォローしたり会話したりできます。もしお持ちでないなら こちら からサインアップできます。
Hiroaki Nakamura ブーストされました
Hiroaki Nakamura ブーストされました

twitter.com/dgryski/status/863
で知ったんですが
"Introducing Badger: A fast key-value store written natively in Go - Dgraph Blog"
open.dgraph.io/post/badger/
が面白そうです。RocksDBをcgo経由で使うのに疲れてpure goでもっと良いのを書いたという話。
"dgraph-io/badger: Fastest key/value store in Go."
github.com/dgraph-io/badger
Apache2ライセンスです。
Goで書かれたグラフデータベースをBadgerに移行するのも進行中とのこと。
github.com/dgraph-io/dgraph/pu

"Adaptive Gravitational Gossip: A Gossip-Based Communication Protocol with User-Selectable Rates - IEEE Xplore Document"
ieeexplore.ieee.org/document/4

"PeerReviewAGG_01_18_09a.pdf"
cs.cornell.edu/projects/quicks

"CiteSeerX — Using epidemic techniques for building ultra-scalable reliable communication systems"
citeseerx.ist.psu.edu/viewdoc/

プロトコルのドキュメントもありました。NNTPプロトコルをベースに独自拡張も入れているようです。
"nntpchan/protocol.md at master · majestrate/nntpchan"
github.com/majestrate/nntpchan

go nntpで検索してたら
golanglibs.com/top?q=nntp

"majestrate/nntpchan: nntp based decentralized imageboard"
github.com/majestrate/nntpchan
というのを知りました。これは面白そう。

twitter.com/ttkzw/status/86160
私も昔は使ってました。がNNTPについて調べたことなかったなーと思ってnntp scalabilityでググったらこんな記事を見つけました。
"v09, i12: Designing a Scalable NNTP Server Network"
seann.herdejurgen.com/resume/s

Hiroaki Nakamura ブーストされました

CLIベースのDNS設定診断ツール。出力結果を見る限り良さそう。golang実装 / github.com/42wim/dt GitHub - 42wim/dt: DNS tool - display information about your domain

Hiroaki Nakamura ブーストされました

へー切り替えられる / qiita.com/hiromasa-masuda/item Windows 10 での Windows コンテナーと Linux コンテナーの共存方法 - Qiita

Hiroaki Nakamura ブーストされました

"Designing Data-Intensive Applications - O'Reilly Media"
shop.oreilly.com/product/06369
の続きを読んでたらログベースのメッセージキューが出てきて、受信側が止まってもログに書いておいて復帰したら再送できるという話です。マストドンもこういう仕組みになればいいのかなと思ったりしました。

"ソフトウェア開発組織が持つべきカルチャー(17):柴田 芳樹 (Yoshiki Shibata):So-netブログ"
yshibata.blog.so-net.ne.jp/201

コードカバレッジを品質基準にしないというのは私も完全に同意です。こういう不適切な指標を導入してしまうと、必ず独り歩きしてカバレッジを上げるために本末転倒な作業が発生するのが目に見えてます。
以前いた職場でカバレッジを全社的に導入しようという提案があったときは断固反対しました。あくまで参考に見てみるだけなら良いのですが、見てしまうと数値をあげたくなるのが人の性分だと思うんですよね。
カバレッジを見るまでもなく無駄なコードをちゃんと整理していけば、メンテしやすいコードになるわけでそれで充分だと思います。

Hiroaki Nakamura ブーストされました

5月12日に福岡で「さくらのクラウド」と「マストドン」について発表するよ、みんな来てね。

sakura-kyushu.doorkeeper.jp/ev

やってみると3%速くなったもののメモリ割り当てが1つ増えるといういまいちな結果でした。
github.com/hnakamur/zap/commit

Hiroaki Nakamura ブーストされました

golang/depが良くなったらしい。ほほう / sdboyer.io/dep-status/2017-05- dep status - 2017-05-01 · sdboyer.io

go標準ライブラリのlogパッケージと、自作のltsvlogとzap-ltsvで実際にファイルに書くベンチマークもやってみました。
github.com/hnakamur/ltsvlog/bl
zap-ltsvは日時をEpoch形式にすると超高速ですがISO8601形式だとgoのlogやltsvlogより遅いことがわかりました。
現状は
github.com/uber-go/zap/blob/ce
time.Formatを使う素朴な実装なのでgoのlogのコードを使えば改善の余地はあります。

自作のLTSV形式ロギングライブラリも更新しました。
github.com/hnakamur/ltsvlog
Goのlogパッケージの日付フォーマットのコードを頂いて性能改善し、さらに上記のイシューと同じ変更も入れています。
また、functional option patternを使ってAPIを整理したので、時刻とログレベルのラベルを変えたり出力しないように出来るようにしました。

goの標準ライブラリのlogパッケージの時刻のフォーマットにかかる時間を少し改善できたのでイシューを立ててみました。
"log: Optimize formatting time in header with avoiding buffer copy in ioa · Issue #20267 · golang/go"
github.com/golang/go/issues/20