<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Disqus - Latest Comments for rzei</title><link>http://disqus.com/people/0639b3d5f57b29dd93d32ac6fde5bbd7/</link><description></description><language>en</language><lastBuildDate>Fri, 31 Jul 2009 09:16:06 -0000</lastBuildDate><item><title>Re: Embedded Database Performance: Handle With Care</title><link>http://pramatr.disqus.com/embedded_database_performance_handle_with_care/#comment-21287996</link><description>Good post on interesting subject! Performance problems are easy to overlook when you are doing the best you can to be ready when the deadline closes in.. Especially if you miss testing your system with _real_ kind of workloads and perhaps more importantly workloads that will happen after customer has used your product for one, two, three, N years.&lt;br&gt;&lt;br&gt;As a side note.. Could you fix your "SQL n + 1 selects" link?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">rzei</dc:creator><pubDate>Wed, 11 Feb 2009 15:17:43 -0000</pubDate></item><item><title>Re: What you didn't think you needed to know about hashCode and equals</title><link>http://thinkinginsideabiggerbox.disqus.com/what_you_didnt_think_you_needed_to_know_about_hashcode_and_equals/#comment-3453105</link><description>From a Hibernate users standpoint, could you give an example of a situation where you need to store a hashset of objects of which some are persisted, some get persisted why stored in set and some do not?&lt;br&gt;&lt;br&gt;If you declare that id shouldn't be used in hashCode; in the same way you could say that you cannot use any fields in hashCode, as every one of those can change. &lt;br&gt;&lt;br&gt;Surrogate should be the most stable property of an persist entity as it changes only once.&lt;br&gt;&lt;br&gt;Great post though, too few have been written on the subject.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">rzei</dc:creator><pubDate>Mon, 03 Nov 2008 05:26:12 -0000</pubDate></item><item><title>Re: Brizzled: C# is now a better language than Java</title><link>http://brizzled.disqus.com/brizzled_c_is_now_a_better_language_than_java/#comment-13741083</link><description>All points you make are valid; C# has developed faster than Java. More features always come with cost somewhere. You most likely need support from your IDE to make them usable and understandable -- ie. chances are I wouldn't use a feature of Java that would be cumbersome to use in $my_ide_of_choice (Eclipse).&lt;br&gt;&lt;br&gt;Java has gained rather few language features and as a language doesn't offer many exciting features. That is however the reason why we develop for it. I believe that fewer features and aiming towards correct usage of those features will yield better maintainability in the long run.&lt;br&gt;&lt;br&gt;And of course with .NET you get zero portability and zero good IDE's (for Java you get two do-it-all solutions for *free*). Visual Studio 2005 is no match for either of Netbeans or Eclipse, and what I've read about VS2008 and the upcoming one those are even more slow than the previous ones, with still little functionality for that cost.&lt;br&gt;&lt;br&gt;This is without even mentioning Windows, MSDN licensing costs... (We develop and deploy on Linux most of the time, test also on Windows).&lt;br&gt;&lt;br&gt;I'd like to keep Java simple with limited feature set and use Scala or Groovy for the areas they excel.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">rzei</dc:creator><pubDate>Fri, 31 Jul 2009 09:16:06 -0000</pubDate></item></channel></rss>