.NETの将来: 型クラスと拡張
将来の.NETの新機能として検討されているのが型クラスだ。shapeと拡張の提案で“shapes”として言及されるように、これによって.NETジェネリクスの可能性は飛躍的に向上する。Mads Torgersen氏は型クラスについてこう述べる。 インターフェイスはオブジェクトのshapeと型のインスタンスである値を抽象化する。型クラスの背後にあるアイディアは本質的に、型のshapeを自身の代わりに抽象化することだ。さらに、あるインターフェイスを実装するという宣言を通じて型をオプトインする必要がある場合、他者が別のコードに型クラスを実装することが可能となる。 型クラスは、インターフェイスにまつわる長年の問題を解決する。インターフェイスは静的関数や演算子のオーバーロードを扱うことができない。これにより、全ての異なる数値型を計算するために同じ関数を数値計算ライブラリで何度も宣言しなければならない、
MySQL のチューニング (ボトルネックの検出) - onk.ninja
MySQL のチューニング (ボトルネックの検出) こんにちは！ onk です。 SAPさんが各社とも「ソーシャルアプリは負荷対策が大事」って言っていますね。 弊社でも mixi アプリ(PC)，mixi アプリモバイルをリリースしたときはお祭り状態だったので， ふりかえりも兼ねて MySQL のボトルネックを調べる方法を書いてみました。 (幸い，モバゲーオープンゲームのリリース時はこれらの経験が役に立ったので何ともなかったです) といっても 9 割方 そもそもサーバの設定がおかしい 更新が多いテーブルなのに MyISAM エンジン for 文の中でクエリを発行 INDEX 張ってない データ量がえらいことになってる 辺りなんですけどねー。 基本は下から まず，ボトルネックを調べるときは下の層から上がっていくのが基本です。たぶん。 なので ssh でサーバに入って (LoadAverage
DDD with RDRA, ICONIX
DDDを具体的なプロセスに落とし込むにはどういう観点が必要だろうか。 - 境界づけられたコンテキストがどこまでの範囲かよくわからない - ユビキタス言語やドメインモデルをどのように発見すればいいかわからない。どこから着手すればいいのか？ - ドメインモデルがただのデータの入れ物になってしまう(貧血…
Rust FFI: Sending strings to the outside world | Huy's Blog
Rust FFI: Sending strings to the outside world Foreign Function Interface (FFI) is the most important feature of Rust to let it live peacefully with the other part of the world such as C/C++, Ruby, Python, Node.js, C#,... The official FFI document is much more improved from before but it still not satisfied the people who want to dig deeper into FFI. Another better source to learn about FFI is The
An Introduction to Linux I/O Redirection | DigitalOcean
Introduction The redirection capabilities built into Linux provide you with a robust set of tools to optimize many workflows. The “Unix philosophy” of software development was to make tools that each do one thing well, and this philosophy has been carried forward to modern command-line tools, which are individually powerful, and exponentially more so when combined. Whether you’re writing complex s
Redisのメモリ使用量がmaxを超えた場合の挙動 - Gaishimo
Redisのメモリ使用量がmaxを超えた場合の挙動について検証してみた。 環境: version: 2.4.16 Redisではタイムアウト時間を設定したキーは時間を超えると自動で削除され、タイムアウト時間を設定しないと永続的に保存される。 また、メモリの空き領域がなくなった場合、期限のあるものから削除されていく(デフォルトの設定の場合)。 注意すべき点は、期限が設定されていないキーは削除対象にならないということである。 実際にその挙動を検証してみた。 まず、検証しやすいようにメモリの使用可能な量を以下の値に設定しておく(redis.conf) #新たにキーを保存した際にmaxmemoryエラーにならないぎりぎりの値 maxmemory 910KB maxmemory-policy は 以下を設定 #LRUアルゴリズムを使用して期限切れになったセットのキーを削除 maxmemory-pol
Redis の maxmemory-policy について - @kyanny's blog
Redis をキャッシュストレージとして利用する場合、 maxmemory によって利用可能なメモリの最大値を指定できる。 maxmemory の値を超えるデータの追加が発生した場合の振る舞いを maxmemory-policy によって指定できる。デフォルトの maxmemory-policy は volatile-lru で、 LRU アルゴリズムに従って古いキーの値が優先的に破棄される。 maxmemory-policy は数種類から選べるが、そのうち noeviction を選んだ場合、古いキーの値は破棄されず、新規追加はエラーとなる allkeys-lru または allkeys-random を選んだ場合、 expire の有無に関わらず、全てのキーの中から破棄対象が選ばれる その他を選んだ場合、 expire がセットされているキーのみが破棄対象となる という違いがある。実装
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
