シーケンスの代わりにuuidをIDとして使う
stop using numbers as IDs. just use UUIDs. seriously — Postgres: The Bits You Haven’t Found by pvh UUID の違い v1 Generate a UUID from a host ID, sequence number, and the current time. v3 Generate a UUID from the MD5 hash of a namespace UUID and a name. v4 Generate a random UUID v5 Generate a UUID from the SHA-1 hash of a namespace UUID and a name. この内、ID として利用できるのは v1 と v4 の2つ。v1 は最後 48 ビットがハード固有のノー
UUID(v4) がぶつかる可能性を考えなくていい理由 - Qiita
お手軽にランダムなIDを取得したい時にUUIDはとても重宝します。 でもたまに、 「このID(UUID)ってぶつかることない？対策しなくて大丈夫？」 と聞かれることがあります。 それに対して、 「ウィキペディア先生がぶつからねえって言ってたから大丈夫だよ！（＃ﾟДﾟ）」 で切り抜けるのもそろそろ限界のような気がするのでちゃんと調べました。 (もちろんウィキペディア先生を頼りました！) 2つの理論 UUIDの衝突確率について考える上で次の2つの理論が重要になります。 鳩の巣原理 誕生日のパラドクス 鳩の巣原理 鳩の巣原理とは、 m個の入れ物にn個のものを入れるとき、n > m ならば少なくとも1個の箱には2個以上のものが入る 9個の巣箱に10羽の鳩が入る場合、必ずどれかの巣箱には2羽以上入ることになるということです！(ウィキペディア先生) 考えれば当たり前のことですが同様にして考えれば、 「
ソシャゲ開発経験から学んだゲームに Redis を使う際の Tips
近年の KVS では割と Redis が覇権を取っていることもあり(当社比), 社内の多くのプロジェクトで Redis を使用するようになりました. ということでノウハウ的なのも溜まってきたのでまとめたいと思います. (大量のユーザーデータを扱うソシャゲにしか当てはまらない部分もあるかと思います) 単純にパフォーマンスを RDB < Redis と思い込んでとりあえずでキャッシュしない 「Redis は速い」と言われますが, インデックスをちゃんと貼った RDB のクエリも そこまで遅いわけではありません. 結局通信コストの方が遥かに大きいので内部の 取得時間差はトータルで考えると多くの場合誤差です. 特に RDB の主キーのみで取得できるようなデータを Redis にキャッシュすることに メリットはありません. キャッシュするコードを書くコストの方が高くつきます. キャッシュするのは R
サービスクラスについては僕も悪かったと思っているけど、それでもCQSは実現したいんだ - Qiita
このエントリは Ruby on Rails Advent Calendar 15 日目です。（遅くなってすいません） 同時に 14 日目のじょーかーさんのエントリへのアンサーエントリでもあります。 （まあ、じょーかーさんがこの Advent Calendar に登録したときに、タイトルから内容を推察してこれを書くことを決めましたが、実際のところ、あまりアンサーにもカウンターにもなってないし、全然関係ない内容と言えないこともないので、まあサービスクラスについては僕も推奨したことがあるし、僕も反省してるんですよ程度に読んでもらえると幸いです。） まずはじめにごめんなさい 3 年くらい前に僕は Rails にサービスクラスというものを導入するといいことがあるよと書いたのだけど、それからいくつもの Rails アプリケーションを見たり、実際に自分で開発したりして、うーんって思うことも増えてきたので
KPIツリーを作る意味とその作り方 - it's an endless world.
私は以前にグッドパッチというデザイン会社でシニアグロースデザイナーという肩書で働いており、そこで「グロース勉強会」なるものを主催しておりました。 隔週で有志が集まって、そこで私の持っているグロースまわりの知識や経験を一時間ほど共有するだけという会。 ざっくり言うと私が好き勝手に一時間話すだけという会。 はじめはなんとなくで始めたものですが結局は2年弱という長い期間、この会は継続しておりました。 その中で様々な話題に触れたのですが、参加者が一番勉強になったと口をそろえて言うことが「KPIツリー」についての話でした。 この記事ではその「KPIツリー」について私の考えをあらためてまとめておきたいと思います。 KPIとは 念のために。 kotobank.jp 重要業績評価指標。企業などの組織において、個人や部門の業績評価を定量的に評価するための指標。達成すべき目標に対し、どれだけの進捗がみられたか
ソフトウェア開発の基本的な問題〜 18年前からXPが提示するリスクの紹介
自分が、ここ数年アジャイルのトレーニングの際に必ず示している図がある。それが「エクストリームプログラミング」の第一版から第一章で提示されている、ソフトウェア開発に関するリスクについての図だ。 先日、Agile459のオンライン読書会で紹介したら好評だったので図を貼って置くことにする。 念のため、エクストリームプログラミングを読んだことのない人向けに説明しておくと、これらの元ネタは書籍（初版では１章まるごと、第二版・新訳版では１章で部分的に）では列挙されているが、本文に列挙されているだけなので、自分なりに整理してこのような図にしている。 実現できないスケジュールが遅れたり、度重なる遅延で実現の前に資金がなくなりプロジェクトが終わってしまうというリスクがまず最初にある。 動かないなんとか実現しても、欠陥が多くまともに動かなかったり、その結果としてシステムが劣化（＝メンテナンス不能に）になり、作
フロントエンドチェックリスト（日本語訳） - Qiita
GitHubで公開されているフロントエンドチェックリストというドキュメントが、網羅されている内容が幅広く便利そうだったので、日本語に翻訳しました。 日本語版は、以下のGitHubリポジトリにあります。GitHub側と自動的に連携するようにしておりますので、誤訳や誤りなどがあれば GitHub のプルリクエストまたは Issue で報告していただけると幸いです。 https://github.com/miya0001/Front-End-Checklist 日本語版への貢献方法 最終更新日時: 2017-11-19 03:50:47+09:00 (未翻訳) Front-End Checklist The Front-End Checklist is an exhaustive list of all elements you need to have / to test before lau
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Impressions after Vue Conf 2017