node_modulesの問題点とその歴史 npm, yarnとpnpm
皆さんnpmパッケージのバージョンを上げるときにハマって依存地獄から抜けられなかったことはありませんか？ 私はあります。 複雑怪奇な依存関係を調べてみようとnode_modulesを覗いてみて、そのカオスっぷりに臭いものに蓋をしたことはありませんか？ 私はあります。 そこでnode_modules以下について調べてみたのですが、node_modulesにどんな問題点があって、npmやyarn, pnpmは何を目指していたのか時系列順に紐解いた方がわかりやすいことに気づきました。 ここでは初期のnpmが抱えていた問題から今に至るまでを順を追って説明します。 するとnode_modulesの仕組みの他に、各パッケージマネージャの方針の違いが見えてくるはずです。 初期の頃のnpm (~2015年以前) この頃はシンプルで、依存関係はそのままnode_modulesのディレクトリ構造に反映されてい
Redis作者自身によるRedisとMemcachedの比較 | Yakst
Redisの作者antirez氏自らによる、memcachedとRedisの長所短所の比較。特に、Redisを単なるキャッシュ用アプリケーションとしてmemcachedと比較することの間違いと、それぞれの向いている使用方法についての私見。 あなたが私と面識があるなら、私が競合製品があることが悪いと考える人間でないことはご存知でしょう。ユーザーに選択肢があることは本当にいいことだと思っていますし、だからこそ他の技術とRedisを比較するようなことはほとんどしませんでした。 しかし、最適なソリューションを選ぶためには、ユーザーは正しく情報を持たねばならないのも確かです。 この記事を書くのは、有名なライブラリであるSidekiqの作者として知られるMike Perhamが、Redisのバックエンドストレージとしての使い方を書いた記事を読んだのがきっかけです。従って、私はMikeがRedisに「反
Facebook photo: サイズアップとアルゴリズムの改善でキャッシュヒット率を上げる - ワザノバ | wazanova
https://code.facebook.com/posts/220956754772273/an-analysis-of-facebook-photo-caching 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約5時間前 Facebookに在籍しているポスドクのWyatt Lloydが、Facebook photoのキャッシュのヒット率を上げる手法の分析結果を論文で発表しています。 2012/12月の時点で毎日3.5億枚の写真がアップロードされている。 写真のキャッシュは、ユーザのブラウザキャッシュ、PoP (アクセスポイント)にあるエッジキャッシュ、Facebookのデータセンターにあるオリジンキャッシュとバックエンド (Haystack)の4段階。 キャッシュの構成図 非モバイルユーザのデータを分析
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベースでユニークキーにUUIDを使うメリットは何ですか？連番やタイムスタンプまたは複合などではいけないのでしょうか？どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。
YAPC::Asia 2011 / 高速化のはなしとか
[Think IT] 【深きプログラミング言語】続・アルゴリズムで頭の体操
