このコンテンツは移動しました。約5秒後に移動先へジャンプします。 移動しない時はここをクリックしてください。
Go's interfaces—static, checked at compile time, dynamic when asked for—are, for me, the most exciting part of Go from a language design point of view. If I could export one feature of Go into other languages, it would be interfaces. This post is my take on the implementation of interface values in the “gc” compilers: 6g, 8g, and 5g. Over at Airs, Ian Lance Taylor has written two posts about the i
シリアライズを利用した汎用のオブジェクトのディープコピー処理について整理しました。BinaryFormatterを使用してMemoryStreamに対してシリアライズ/デシリアライズを行いオブジェクトのメモリイメージのコピーを作成するテクニックです。理論上、Serializable属性を付与したすべてのオブジェクトに対してディープコピーが可能になります。 ICloneableインタフェース、MemberWiseCloneメソッドを使用したシャローコピーについては以下の記事を参考にしてください。 ■オブジェクトのコピー。ICloneableインタフェース、MemberWiseClone、シリアライズを利用したインスタンスのコピー。 http://d.hatena.ne.jp/tekk/20091012/1255362429 C# ジェネリック版と拡張メソッド版の2種を用意してみました。 us
BrowserStack にてそれぞれデフォルト設定のブラウザで調査。IE 中心に調べたので他のブラウザは網羅的ではない。あとから補完して別途公開したい。 サマリー 最も一般的な挙動は、追加日時 (おそらく最終更新日時) が古いものを一件削除し、新しいクッキーを受け入れるという、LRU 的なアルゴリズム。ここからブラウザやバージョンによってバリエーションがある。 Chrome は一件ではなく一度に三十件削除する その代わり受け入れるクッキー数は多め バックエンドを Chromium (Blink) に切り替えてからの Opera も同様 古い Opera は、追加しようとしたクッキーを受け入れ、その次に新しいもの一件を削除する。 Safari は単に追加順ではなく独自のソート順でクッキーを管理。その降順または昇順で一件を削除する。 バージョンによって動きがばらばらなので、詳しく調査したい。
Kernel/VM Advent Calender 2013 7日目 カーネル/VMはておくれなすごい人がけっこう集って、ネタとか披露しているようです. 今年のAdvent Calenderも既に濃い内容が集っています. でも、私達パンピーにはカーネルとかちょっと難しすぎてそもそも カーネル/VMという主題自体敬遠しちゃう…… ということで本当にカーネルの第一歩をやってみよう、というのがこの記事です. 記事タイトルはえりっく氏(@siritori)から無断で肖ってます.ありがとうございます 今年の他の記事が高度な内容なので この記事が低レベル(低レイヤということでなく本当に程度が低いという意味で)ですいません. 普段からカーネル/VMに参加してる皆様、さようなら. カーネル/VM界隈わいわいしてておもしろそうだけど怖くて敬遠してる方々、こんにちは. 前置きはこのぐらいで本文行きます. 少々
この記事はパーフェクトRuby Advent Calendar 2013 - Adventar の9日目です。 前の日のエントリーはパーフェクトRuby Advent Calendar 2013(8日目) Let's Sinatra Life - たちブログです。 まだ参加できますので、みなさまもぜひ。 パーフェクトRuby Advent Calendar 2013 - Adventar パーフェクトRubyRubyの仕様に大変詳しい同僚への献本をインターセプトして読ませていただきました。 さまざまな機能をまとめたとてもよい本だと思います。 著者のみなさまの苦労が偲ばれました。パーフェクトRuby (PERFECT SERIES 6)作者: Rubyサポーターズ,すがわらまさのり,寺田玄太郎,三村益隆,近藤宇智朗,橋立友宏,関口亮一出版社/メーカー: 技術評論社発売日: 2013/08/1
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり(ブログ書いてないで原稿書けよ>俺)であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く