Cleaning up heap allocations in GoThis is the 18th article of the Eureka Advent Calendar 2020. Yesterday we had a post from Jun Ernesto Okumura on diversity in Spotify’s recommender systems. IntroductionThanks to efficient in-built memory management in the Go runtime, we’re generally able to prioritise correctness and maintainability in our programs without much consideration for the details of ho

｜DMM inside

Kubernetes Novice #10で発表した資料です。 登壇の動画はこちらからどうぞ。 https://youtu.be/uVKo28HXK2I?t=5718 資料内で紹介しているリンクはこちら 世界に誇れるプラットフォームチームをつくる https://event.cloudnativedays.jp/cndt2020/talks/29 独りよがりのプラットフォーム　https://event.cloudnativedays.jp/cndt2020/talks/30 みなさんが関わるプラットフォーム、もしかして『作っただけ』になっていませんか？ Kubernetesのような、便利ではあるが複雑なプラットフォームが増えるにつれ、単に環境を作るだけではうまく活用されない時代になってきています。 そこで大事なのは、プロダクトを作っていくという意識。そして、それを回していくチーム作りとい

Product-minded engineers are developers with lots of interest in the product itself. They want to understand why decisions are made, how people use the product, and love to be involved in making product decisions. They're someone who would likely make a good product manager if they ever decide to give up the joy of engineering. I've worked with many great product-minded engineers and consider myse

コンウェイの法則とかで、マイクロサービス=組織 という話になることが多いなと感じる。 正解の場合もあるし、不正解の場合もあると思っていて、個人的には小さいチームでもマイクロサービスをやるメリットは技術的にも組織的にもあると思う。 そのメリットを無視してすぐ組織の話に持っていきたくないので、基本分離したくないマンとしての主張を書いておく 技術観点でのメリット いまさら語るまでもないけど、 ドメイン境界の分離 デプロイ独立性 リソースの最適配分 障害の局所化(サーキットブレーカー等) このうち、ドメイン境界の分離だけはモジュラモノリスで対応可能だが、あとの3つにはマイクロサービスが必須。(もっとあるかも) この3つが必要なのにモノリス or モジュラモノリス で進める判断をするということはシステムの表現力を落とすことに直結する。 もちろん、複雑度は増すし難易度も増す。熟練のサーバーサイドエンジ

Feature Toggles (often also refered to as Feature Flags) are a powerful technique, allowing teams to modify system behavior without changing code. They fall into various usage categories, and it's important to take that categorization into account when implementing and managing toggles. Toggles introduce complexity. We can keep that complexity in check by using smart toggle implementation practice

Urvashi Reddy | Software Engineer, Engineering Productivity Team Earlier this year, the Engineering Productivity team at Pinterest published a blog called How a one line change decreased our clone times by 99%. In that post, we described how a simple Git configuration sped up clone times in one of our largest repositories at Pinterest. In this post, we’ll talk about how we significantly decreased

こんにちは、Analytics Infra チームの @yaginuuun です。主にA/Bテスト周りの改善や Recommendation 関連の分析を担当しています。 当ブログは 2021/07/28 に開催された Retty ✕ Mercari Analyst Talk Night! におけるLT内容を改めて少し補足を加えながらブログの形に書き起こしたものです。 当日の資料はこちらです。 A/Bテストとは A/Bテストは Randomized Controlled Trial (RCT) とも呼ばれる効果検証手法です。最も単純な例をあげると、二つの群を用意し片方の群にのみ何かの変更を加えることでその変更による数値変動を評価します。 A/Bテスト自体は医学や農業の分野など幅広く行われています。特に医学の領域においては Level of Evidence という考え方があるようですが、A

他にもまだまだあると思いますが、自分が見たことがあるのは上記になります。 それぞれ見比べてみると、やはりエンコード・デコード両方に対応しているライブラリが人気があるようです。 この中で特に人気のある easyjson , gojay , json-iterator/go でベンチマークをとってみた結果、パフォーマンスの良い順に並べると次のようになりました。 gojay > json-iterator/go > easyjson > encoding/json 設計方針の違いがそのまま速度に現れているようにも見えますが、理論上最速にできるはずの easyjson が遅かったりと実装の良し悪しも影響しているようです。 一番遅いのは encoding/json です。そもそも encoding/json が遅いから新しい JSONライブラリを作ろうとしているはずなので、一番遅いのは仕方ないのです

AILab Creative Researchチームの富樫です。 このブログでは先月末にarxivに投稿された“Item Recommendation from Implicit Feedback”[1]という論文を軸に紹介しつつ、 周辺分野の話題について議論したいと思います。 この論文はitem推薦というタスクにおける手法の各種パラダイムの概観をコンパクトに解説した教科書的内容になっています。 著者はBayesian Personalized Ranking (BPR)[2]を開発したGoogle Research所属のSteffen Rendle氏であり、 長年この分野を開拓してきた権威の一人です。 元論文の内容は元論文を読めばわかることですし、 蛇足かもしれませんが、最近の研究との関連性や議論、個人的な感想などを示すことで、このブログが元論文に対する補足資料のようになることを目指した