■_
毎日一回は傍若無人な運転の自転車にぶつけられそうになってるような気がする。 一遍くらい反撃したい。
最初の三国志(光栄のゲームね)のマニュアルに、 「このゲームはC言語を使って開発されました」といった感じの文章が載ってたような 記憶がかすかにあるんだけどどうだったけか。
信長の野望(PC-8001版?)はBASICも使ってたような気が。
日本語むずい。 校閲と校正の違い 校閲 とは - コトバンク 査読 とは - コトバンク
2011年05月19日
■_
How Garbage Collection differs in the three big JVMs Application Performance, Scalability and Architecture ? The dynaTrace Blog How Garbage Collection differs in the three big JVMs 三大 JVM でガーベジコレクションはどのように異なっているのか by Michael Kopp, May 11, 11 Most articles about Garbage Collection ignore the fact that the Sun Hotspot JVM is not the only game in town. In fact whenever you have to work with either IBM WebSphere or Oracle WebLogic you will run on a different runtime. While the concept of Garbage Collection is the same, the implementation is not and neither are the default settings or how to tune it. This often leads to unexpected problems when running the first load tests or in the worst case when going live. So let's look at the different JVMs, what makes them unique and how to ensure that Garbage Collection is running smooth. ガーベジコレクションについての articles のほとんどがSun の Hotspot JVM が the only game in town でないことを無視しています実際には、IBM の WebSphere や Oracle の WebLogic を使ったときはいつでも異なるランタイムの上で実行することになるのです。ガーベ ジコレクションの concept が同じであってもその実装は同じではないし、デフォルトのセッテ ィングやチューニングのやり方も違ったものです。このことは、最初のロードテストを実行した ときやワーストケースの場合に頻繁に予期しない問題につながりますですから、複数の異なる JVMについて、それぞれを特徴付けているものやどのようにしてガーベジコレクションがスムー スに実行されることを保証しているのかについて確認することにしましょう。 The Garbage Collection ergonomics of the Sun Hotspot JVM Sun Hotspot JVM のガーベジコレクションの使い勝手 Everybody believes to know how Garbage Collection works in the Sun Hotspot JVM, but lets take a closer look for the purpose of reference. 誰もが Sun のHostspot JVM でガーベジコレクションがどのように動作しているかについて 知っていると信じていますが、reference のため詳細に見てみることにしましょう。 The memory model of the Sun Hotspot JVM Sun Hotspot JVM のメモリモデル The Generational Heap 世代別ヒープ The Hotspot JVM is always using a Generational Heap. Objects are first allocated in the young generation, specifically in the Eden area. Whenever the Eden space is full a young generation garbage collection is triggered. This will copy the few remaining live objects into the empty survivor space. In addition objects that have been copied to Survivor in the previous garbage collection will be checked and the live ones will be copied as well. The result is that objects only exist in one survivor, while eden and the other survivor is empty. This form of Garbage Collection is called copy collection. It is fast as long as nearly all objects have died. In addition allocation is always fast because no fragmentation occurs. Objects that survive a couple of garbage collections are considered old and are promoted into the Tenured/Old space. Hostspot JVM は常に Generational Heap を使っています。オブジェクトはまず young generation、その中でも Eden area に割り付けられます。Eden spcae が一杯であった場合には young generation ガーベジコレクションが引き起こされます。このとき、少数の生き残ってい るオブジェクトは empty suvivor space へコピーされます。さらに、前回のガーベジコレクシ ョンで Survivor にコピーされていたオブジェクトがチェックされ、そのうちの生きているもの が同様にコピーされます。その結果、オブジェクトはひとつの survivor にのみ存在するように なり、eden と他の survivor は空になります。このような形式のガーベジコレクションは copy collection と呼ばれます。このやり方はほぼすべてのオブジェクトが死んでしまっている場合 に高速です。それに加え、断片化(fragmentation)が起きないので割り当てが常に高速です。数 回のガーベジコレクションを生き延びたオブジェクトは old と見なされ、Tenured/Old space へ と promote されます。 Tenured Generation GCs The Mark and Sweep algorithms used in the Tenured space are different because they do not copy objects. As we have seen in one of my previous posts garbage collection takes longer the more objects are alive. Consequently GC runs in tenured are nearly always expensive which is why we want to avoid them. In order to avoid GCs we need to ensure that objects are only copied from Young to Old when they are permanent and in addition ensure that the tenured does not run full. Therefore generation sizing is the single most important optimization for the GC in the Hotspot JVM. If we cannot prevent objects from being copied to Tenured space once in a while we can use the Concurrent Mark and Sweep algorithm which collects objects concurrent to the application. Tenured space で用いられるマークアンドスイープアルゴリズムはオブジェクトをコピーしない 点が違っています。以前のわたしのポストの一つで見られるように、ガーベジコレクションは多 くのオブジェクトが生きているときには時間がかかります。結果として、GC を tenured で実行 するのはほぼいつでも高価なものであり、それがわたしたちがGCを排除しようとする理由です。 GC を排除するためにオブジェクトは、オブジェクトが permanent でありさらに tenured が一 杯でないことが保証されているときにYoung から Old にのみコピーされることを保証すること が必要となります。したがって、generation sizing は Hotspot JVM における GC に対する single most important optimization です。 Tenured spaceへオブジェクトがコピーされるのを防げなければ、 アプリケーションと並列にオブジェクトを collect する 並列マークアンドスイープアルゴリズムを使えるのです。 #どーもわからん Comparison of the different Garbage Collector Strategies 異なるガーベジコレクション戦略の比較 While that shortens the suspensions it does not prevent them and they will occur more frequently. The Tenured space also suffers from another problem, fragmentation. Fragmentation leads to slower allocation, longer sweep phases and eventually out of memory errors when the holes get too small for big objects. suspensions を短くすることは GC を阻害しない上に、より頻繁に GC が実行されるようになる でしょう。Tenured space もまた別の問題、断片化 (fragmentation) を抱えています。断片化 は時間の掛かる割り付けや長時間のスイープフェーズを引き起こし、さらにはホールが大きなオ ブジェクトに対して小さすぎる場合に out of memory エラーにつながります。 Java Heap before and after compacting compacting 前後の Java のヒープ This is remedied by a compacting phase. The serial and parallel compacting GC perform compaction for every GC run in the Tenured space. Important to note is that, while the parallel GC performs compacting every time, it does not compact the whole Tenured heap but just the area that is worth the effort. Worth the effort means when the heap has reached a certain level of fragmentation. In contrast, the Concurrent Mark and Sweep does not compact at all. Once objects cannot be allocated anymore a serial major GC is triggered. When choosing the concurrent mark and sweep strategy we have to be aware of that side affect. これは compacting phase によって改善されます。serial compacting GC と parallel compacting GC はTenured space 上で実行される GC すべてに対して compaction を実行します。 注意しておくべき重要なことは、parallel GC が毎回 compacting を実行するけれどもそれは Tenured heap 全体を compact するのではなくcompact を実行する価値のある領域に対してだけ 行うということです。実行する価値のあるとはヒープの断片化がある程度のレベルに到達したと いうことです。対照的に、並行マークアンドスイープではすべてを compact するわけではありません。 もはやオブジェクトを割り当てできなくなると、serial major GC が発動します。 並行マークアンドスイープ戦略を選択したとき わたしたちはその副作用に注意しなければなりません。 The second big tuning option is therefore the choice of the right GC strategy. It has big implications for the impact the GC has on the application performance. The last and least known tuning option is around fragmentation and compacting. The Hotspot JVM does not provide a lot of options to tune it, so the only way is to tune the code directly and reduce the number of allocations. second big tunig option はしたがって、正しい GC 戦略の選択です。この選択肢にはGC がア プリケーションの性能に与える impcat に対して big implications がありますlast and least known tuning option は fragmentation や compacting に関するものです。Hostspot JVM は多 くのチューンの選択肢は提供していませんから、取りうる唯一の方法は直接コードをチューンし て割り当ての回数を減らすというものです。 There is another space in the Hotspot JVM that we all came to love over the years, the Permanent Generation. It holds classes and string constants that are part of those classes. While Garbage Collection is executed in the permanent generation, it only happens during a major GC. You might want to read up what a Major GC actually is, as it does not mean a Old Generation GC. Because a major GC does not happen often and mostly nothing happens in the permanent generation, many people think that the Hotspot JVM does not do garbage collection there at all. Hotspot JVM にはもう一つスペースがあります。 それは、わたしたちが何年もの間愛することになった Permanent Generation です。 このスペースはそういったクラス群の一部であるクラスや文字列定数を保持します。 ガーベジコレクションが permanent generation で実行されますが、 これは major GC の間でしか発生しません。 あなたはMajor GCが実際にはどういうものであるのか、Old Generation GC と どのように違うのかをを丹念に調べたくなるかもしれません。 major GC は頻繁には発生せず、また、permanent generation ではほとんどまったく発生しないので、 多くの人は Hotspot JVM はガーベジコレクションをまったく行わないものだと考えています Over the years all of us run into many different forms of the OutOfMemory situations in PermGen and you will be happy to hear that Oracle intends to do away with it in the future versions of Hotspot. 何年もの間、わたしたちはみな PermGen における OutOfMemory situations をさまざまに異な る形で経験していて、Oracle がHotspotの将来のバージョンでそれを取り去ろうとしているとい うのを聞いたときはあなたもうれしくなるでしょう。 Oracle JRockit Now that we had a look at Hotspot, let us look at the difference in the Oracle JRockit. JRockit is used by Oracle WebLogic Server and Oracle has announced that it will merge it with the Hotspot JVM in the future. さてここで Hostspot に注目して Oracle JRockit との違いを見ることにしましょう。 JRockit は Oracle WebLogic Server で使われていて、 Oracle はこれと Host JVM を将来マージするだろうとアナウンスしています。 Heap Strategy ヒープ戦略 The biggest difference is the heap strategy itself. While Oracle JRockit does have a generational heap it also supports a so called continuous heap. In addition the generational heap looks different as well. 最大の違いはヒープ戦略それ自身にあります。 Oracle JRockit が generational heap を持っている一方で continuous heap と呼ばれるものもサポートしています。 それに加えて、generational heap は looks different as well です。 Heap of the Oracle JRockit JVM Oracle JRockit JVM のヒープ The Young space is called Nursery and it only has two areas. When objects are first allocated they are placed in a so called Keep Area. Objects in the Keep Area are not considered during garbage collection while all other objects still alive are immediately promoted to tenured. That has major implications for the sizing of the Nursery. While you can configure how often objects are copied between the two survivors in the Hotspot JVM, JRockit promotes objects in the second Young Generation GC. Young space は Nursery と呼ばれ、それは二つのエリアしか持っていません。最初に割り当て られたときオブジェクトは Keep Area と呼ばれるエリアに置かれます。他のすべての生きてい るオブジェクトが即座に tenured へ promote するのに対し、Kepp Area にあるオブジェクトは ガーベジコレクションの間は考慮されません。 That has major implications for the sizing of the Nursery. #Nursery の sizing に対して #major implications (密接な関係) があります。 Hotspot JVM では二つの survivors の間でオブジェクトがどのくらい頻繁にコピーされるのか を configure できるのに対して、JRockit は second Young Generation GC にあるオブジェク トを promote します。 In addition to this difference JRockit also supports a completely continuous Heap that does not distinguish between young and old objects. In certain situations, like throughput orientated batch jobs, this results in better overall performance. The problem is that this is the default setting on a server JVM and often not the right choice. A typical Web Application is not throughput but response time orientated and you will need to explicitly choose the low pause time garbage collection mode or a generational garbage collection strategy. この違いに加えて、JRockit は young オブジェクトと old オブジェクトを区別しない完全に continuous な Heap もサポートしています。スループット指向のバッチジョブのような一部の シチュエーションでは、これは better overall performance な結果をもたらします。問題なの は、これがサーバーJVM のデフォルト設定であり、しばしば正しい選択でないということにあり ます。典型的なWebアプリケーションはスループット指向ではなくレスポンスタイム指向であり、 low pause なガーベジコレクションモードか、さもなくば generational なガーベジコレクショ ン戦略をexplicitly に選択する必要があるでしょう。 Mostly Concurrent Mark and Sweep おおよそ並列なマークアンドスイープ If you choose Concurrent Mark and Sweep strategy you should be aware about a couple of differences here as well. The mostly concurrent mark phase is divided into four parts: もし 並列マークアンドスイープ戦略を選んだのなら、ここに挙げた相違点にも注意すべきです。 ほとんどの並列マークフェイズは四つのパートに分けられます: * Initial marking, where the root set of live objects is identified. This is done while the Java threads are paused. イニシャルマーキング ここでは生きているオブジェクトの root set が identify されます。 これは Javaのスレッドが pause している間に行われます。 * Concurrent marking, where the references from the root set are followed in order to find and mark the rest of the live objects in the heap. This is done while the Java threads are running. 並列マーキング ヒープ上で生きている残りのオブジェクトを発見してマークをつけるために root set から 参照する。これはJavaスレッドが実行されているときに行われます。 * Precleaning, where changes in the heap during the concurrent mark phase are identified and any additional live objects are found and marked. This is done while the Java threads are running. Precleaning これは concurrent makr phase 中のヒープの変更を identify し any additional live object の検出とマークを行います。これは Java のスレッドが実行されているときに行 われます。 * Final marking, where changes during the precleaning phase are identified and any additional live objects are found and marked. This is done while the Java threads are paused. Final marking precleaning phase の間の変更を identify し、そこで追加された生きているオブジェクト を検出してマークします。 The sweeping is also done concurrent to your application, but in contrast to Hotspot in two separate steps. It is first sweeping the first half of the heap. During this phase threads are allowed to allocate objects in the second half. After a short synchronization pause the second half is sweeped. This is followed by another short final synchronization pause. The JRockit algorithm therefore stops more often than the Sun Hotspot JVM, but the remark phase should be shorter. Unlike the Hotspot JVM you can tune the CMS by defining the percentage of free memory that triggers a GC run. この sweeping もアプリケーションの実行と並列に行われますが、Hotspot は対象的に二つのス テップに分割しています。最初にヒープの前半を sweeping します。このフェイズの間、スレッ ドはヒープの後半に置くオブジェクトの割り当てを許されます。短い synchronization pause のあと後半が sweep されます。これにもうひとつ別の short final synchronization pause が 続いています。したがって JRockit のアルゴリズムではSun Hotspot JVMよりも頻繁にストップ しますが、remark フェーズは逆に短いものになっているはずです。Hotspot JVM と異なり、GC を実行する引き金となるフリーメモリの割合を定義することでCMS を tune 可能です。 Compacting コンパクティング The JRockit does compacting for all Tenured Generation GCs, including the Concurrent Mark and Sweep. It does so in an incremental mode for portions of the heap. You can tune this with various options like percentage of heap that should be compacted each time or how many objects are compacted at max. In addition you can turn off compacting completely or force a full one for every GC. This means that compacting is a lot more tunable in the JRockit than in the Hotspot JVM and the optimum depends very much on the application itself and needs to be carefully tested. JRockit は並行マークアンドスイープを含むTenured Generation GC すべてで compacting を行 いますその compacting は portions of the heap に対してインクリメンタルモードで行われま す。ここで、percentage of heap that should be compacted each time や how many objects are compacted at maxのようなさまざま options を使ってチューンが可能です。 さらに、すべて GC に対して compacting を完全に禁止したり強制的に行わせることもできます。 これは Jrockit の compacting は Hotspot JVM よりも格段に tunable であり、 その optimum はアプリケーションそのものに強く依存したものなので 慎重にテストする必要があることを意味します。 Thread Local Allocation スレッドローカルな割り当て Hotspot does use thread local allocation, but it is hard to find anything in the documentation about it or how to tune it. The JRockit uses this on default. This allows threads to allocate objects without any need for synchronization, which is beneficial for allocation speed. The size of a TLA can be configured and a large TLA can be beneficial for applications where multiple threads allocate a lot of objects. On the other hand a too large TLA can lead to more fragmentation. As a TLA is used exclusively by one thread, the size is naturally limited by the number of threads. Thus both decreasing and increasing the default can be good or bad depending on your applications architecture. Hotspot はスレッドローカル割り当てを使っていますが、ドキュメントでこれに関する記述を何 かしら見つけることやチューンのやり方は難しいです。JRockit はデフォルトでスレッドローカ ル割り当てを使用します。これはスレッドに一切の同期を必要としないオブジェクトの割り当て を許可します。これには割り当て速度に対する利益があります。TLA の大きさはconfigure 可能 で、大きい TLA は複数のスレッドが大量のオブジェクトの割り当てをするアプリケーションで beneficial かもしれません。その一方で、大きすぎる TLA は一層のフラグメンテーションに直 結します。TLA は一つのスレッドにより排他的に使用されるので、その大きさはスレッドの数に よって自然に制限されます。したがって、デフォルトを増減することはアプリケーションのアー キテクチャ次第で良いことにも悪いことにもなる可能性があります。 Large and small objects 大小のオブジェクト The JRockit differentiates between large and small objects during allocation. The limit for when an object is considered large depends on the JVM version, the heap size, the garbage collection strategy and the platform used. It is usually somewhere between 2 and 128 KB. Large objects are allocated outside thread local area in in case of a generational heap directly in the old generation. This makes a lot of sense when you start thinking about it. The young generation uses a copy ccollection. At some point copying an object becomes more expensive than traversing it in ever garbage collection. JRockit は large オブジェクトと small オブジェクトとで割り当てを別にしています。オブジ ェクトが large と見なされる境界は JVM のバージョン、ヒープのサイズ、ガーベジコレクショ ンの戦略、プラットフォームといったものに依存します。この境界は通常 2Kバイトから128Kバ イトの間にあります。 Large objects are allocated outside thread local area in in case of a generational heap directly in the old generation. large オブジェクトはスレッドローカル領域の外に割り当てられます generational heap に直接 This makes a lot of sense when you start thinking about it. young generation は copy collection を使っています。 いくつかの点で、オブジェクトをコピーすることは traversing するよりも高価になります No permanent Generation And finally it needs to be noted that the JRockit does not have a permanent generation. All classes and string constants are allocated within the normal heap area. While that makes life easier on the configuration front it means that classes can be garbage collected immediately if not used anymore. In one of my future posts I will illustrate how this can lead to some hard to find performance problems. そして最後に、JRckit が permanent generation を持っていないことに注意する必要があります。 すべてのクラスと文字列定数は通常のヒープ領域に割り付けられます。 While that makes life easier on the configuration front it means that classes can be garbage collected immediately if not used anymore. 使わなくなった場合に即座にクラスを回収可能にできることを意味しています。 いずれ、これがいくつかの検出がどのようにして難しい性能上の問題につながるのかについて 説明するポストをしようと思います。 The IBM JVM The IBM JVM shares a lot of characteristics with JRockit: The default heap is a continuous one. Especially in WebSphere installation this is often the initial cause for bad performance. It differentiates between large and small objects with the same implications and uses thread local allocation on default. It also does not have a permanent generation, but while the IBM JVM also supports a generational Heap model it looks more like Sun's rather than JRockit. IBM の JVM は JRockit と多くの特徴を共有しています:そのデフォルトヒープは continuous なものです。とくに WebSphere のインストールにおいてこれはしばしば bad performance の initial cause となります。同じ implications を持った large object と small object は区 別され、デフォルトではスレッドローカル割り当てを使用します。また、IBM JVM は permanent generation も持ちませんが、JRockit よりは Sun のものにより似ているものです。 The IBM JVM generational heap Allocate and Survivor act like Eden and Survivor of the Sun JVM. New objects are allocated in one area and copied to the other on garbage collection. In contrast to JRockit the two areas are switched upon gc. This means that an object is copied multiple times between the two areas before it gets promoted to Tenured. Like JRockit the IBM JVM has more options to tune the compaction phase. You can turn it off or force it to happen for every GC. In contrast to JRockit the default triggers it due to a series of triggers but will then lead to a full compaction. This can be changed to an incremental one via a configuration flag. Allocate and Survivor は Sun JVM の Eden and Survivor のように振る舞います。新しいオブ ジェクトはあるエリアに割り付けられたあと、ガーベジコレクションによって他のエリアへコピ ーされます。JRockit はこれと対象的に gc に従って二つのエリアを切り替えます。このことは、 オブジェクトは Tenured に promote される前に二つのエリア間で複数回コピーされることを意 味します。IBM JVM は JRockit のように、compaction phase を tune するためのより多くのオ プションを持っています。すべてのGCに対して禁止をしたり実行を強制したりできます。 In contrast to JRockit the default triggers it due to a series of triggers but will then lead to a full compaction. これは configuration flag を通じて incremental なものに変更可能です。 Conclusion 結論 We see that while the three JVMs are essentially trying to achieve the same goal, they do so via different strategies. This leads to different behaviour that needs tuning. With Java 7 Oracle will finally declare the G1 (Garbage First) production ready and the G1 is a different beast altogether, so stay tuned. 三つのJVMが本質的には同じゴールを目指している一方でそれぞれが異なる戦略の元にそれを行 っていることを見てきました。これはチューニングが必要な異なる振る舞いにつながります。 Java 7 で Oracle はようやく G1 (Garbage First) が production ready であることと、 G1 が a different beast altogether, so stay tuned であることを宣言しました。 If you're interested in hearing me discuss more about WebSphere in a production environment, then check out our upcoming webinar with The Bon-Ton Stores. I'll be joined by Dan Gerard, VP of Technical & Web Services at Bon-Ton, to discuss the challenges they've overcome in operating a complex Websphere production eCommerce site to deliver great web application performance and user experience. Reserve your seat today to hear me go into more detail about Websphere and production eCommerce environments.
■_ DRM解除
ついった上でも情報が流れてましたが
Gmail - O'Reilly Japan News 第159号 - hogemuta@gmail.com ■Event/News オライリー・ジャパンに関連するイベントや、コミュニティによる イベントの情報です ----------------------------------- ●オライリー・ジャパンのEbookがDRM Freeになります 2011年5月より、オライリー・ジャパンで販売するEbookをDRM Free化 します。これによって、これまで禁止されていた印刷、テキストの コピー、注釈やしおりの追加等が自由に行えるようになります。 DRM Free化にあたって、サーバ上のプログラムを変更いたします。 そのため2011年5月23日（月）、Ebook Storeを一時クローズいたし ます。メンテナンス中はEbookのご購入ができなくなりますので、 あらかじめご承知おきください。
■_ ねた
こういう流れ好きｗ
：【ナポレオン】長谷川哲也32【笑う殺し屋】 416 名無しんぼ＠お腹いっぱい [sage] 2011/05/18(水) 21:16:01.53 ID:Qsnr0hPf0 Be: 店員：「焼肉のタレをどうぞ」 タレーラン：「タレいらん」 417 名無しんぼ＠お腹いっぱい [sage] 2011/05/18(水) 22:21:39.01 ID:G8fB/eEI0 Be: 山田君>>416の財産全部没収して 418 名無しんぼ＠お腹いっぱい [sage] 2011/05/18(水) 22:24:39.67 ID:vr4aODnJ0 Be: フランス人民を凍死に至らしめようと画策した罪で市民>>416の全財産を差し押さえる 419 名無しんぼ＠お腹いっぱい [sage] 2011/05/18(水) 22:29:07.37 ID:sHRj2pv40 Be: 死 刑 420 名無しんぼ＠お腹いっぱい [sage] 2011/05/19(木) 00:17:21.56 ID:4GFKBYJw0 Be: 兄は>>416を逮捕する気よ 421 名無しんぼ＠お腹いっぱい [sage] 2011/05/19(木) 00:27:07.30 ID:fZA7ONfs0 Be: >>416は前線の一歩前だ！ 422 名無しんぼ＠お腹いっぱい [sage] 2011/05/19(木) 00:43:24.25 ID:OfBLRRhf0 Be: >>416を法の外におけ！！ 423 名無しんぼ＠お腹いっぱい [sage] 2011/05/19(木) 02:06:46.74 ID:r1V9NeUc0 Be: >>416が買占めたレスは ご近所の３６人で分配する 424 名無しんぼ＠お腹いっぱい [sage] 2011/05/19(木) 02:40:13.59 ID:fdxgLin80 Be: てめェはクビだ！ >>416 425 名無しんぼ＠お腹いっぱい [sage] 2011/05/19(木) 04:33:20.35 ID:tk+n1d1G0 Be: その寒さでナポレオンを敗退せしめた>>416は、人々から冬将軍から呼ばれることになった 426 名無しんぼ＠お腹いっぱい [sage] 2011/05/19(木) 09:26:07.09 ID:sFQLGGRe0 Be: >>416が愛するのは市民と革命だ、誰かではない 427 名無しんぼ＠お腹いっぱい [sage] 2011/05/19(木) 11:38:37.44 ID:eop4nYQq0 Be: ダヴー！>>416の教育がなっとらん！ 428 416 [sage] 2011/05/19(木) 19:02:14.76 ID:Cw58avfJ0 Be: おまえらチームワーク良過ぎだろうｗ 429 名無しんぼ＠お腹いっぱい [sage] 2011/05/19(木) 19:02:48.02 ID:fxcX9jNf0 Be: >>428 俺は嫌いじゃないぜ 430 名無しんぼ＠お腹いっぱい [sage] 2011/05/19(木) 20:15:55.56 ID:PrUXrwNi0 Be: 余計な 執政など 無いよね シェイエス
■_
- wrong, rogue and booklog - sandvineが発表したネットワークトラフィック
- Why is Python better than Perl? : Python
- Interview with Ken Thompson | Dr Dobb's Journal
- ITトレメ Ruby技術者認定【Gold】試験 － ＠IT自分戦略研究所
- “ポストPC時代”はPCの死ではない――米Forrester予測 - ITmedia エンタープライズ
- Suica、PASMOなどIC乗車券10種、全国で相互利用可能に - ねとらぼ
- Pg.pm は、見捨てられたのですか？ - 質問・相談ならMSN相談箱
- Opera/Firefox Javascript engine differences - Stack Overflow
- 「last year」と「the last year」は違う - CNET Japan
![Software Design (ソフトウェア デザイン) 2011年 06月号 [雑誌]](http://ecx.images-amazon.com/images/I/51jeHImbo9L._SL160_.jpg)
