OpenJPA errors are sometimes less than informative
When you see OpenJPA error claiming that a column does not exist in database and you clearly see it, make sure the instance field in question is private. At least, packet visibility seems to cause problems in case of annotations at field level. Such an error just ate 4 hours of my time.
This seems to be at odds with JPA 3.0 standard, which explicitly allows protected and packet visibility for instance fields (chapter 2.1). The current OpenJPA documentation for 2.2 release doesn’t list this deviation from standard (http://openjpa.apache.org/builds/apache-openjpa-2.2.1-SNAPSHOT/docs/docbook/manual.html#jpa_2.0_incompatibilities).
Memory usage in Java applications
A long but interesting presentation from IBM about memory usage. It illustrates how basic types can have huge data overhead. For example, a Boolean value is 16 bytes.
A list of amazingly usefull linux commands
The most important is clearly disown. http://www.reddit.com/r/linux/comments/mi80x/give_me_that_one_command_you_wish_you_knew_years/
Algorithm is not
A presentation about maze generating algorithms found on HN. Not only it covers a number of graph theory algorithms but also is notable for interesting slide-based navigation. Canvas is used to illustrate how different approaches work. The html page is surprisingly concise and nifty.
Steve Yegge on Properties design pattern
I have read Steve Yegge’s blog entry on Properties pattern. He claims that the pattern is sometimes called Prototype pattern, but the Prototype lacks flexibility which makes Steve’s idea cool. Essentially it’s like objects without a class. If it is also possible to store functions (lambda expressions?) in the properties so that not only values but also behavior is flexible then possibilities are endless. JavaScript seems to have extensive support for this entire way of design, maybe it’s a way to properly learn it?
Article also mentions a gnu perfect hash implementation.
Resource Acquisition Is Initialization
Short but to-the-point presentation about how to properly manage resources in C++ and Java can be found here. In summary:
- In C++ use destructors, you will get safe and succinct code;
- In Java use the Dispose pattern (a try/finally block right after creating each resource), you will get safe and ugly code.
Also nice quote: “if PHP gets something right before your language does, you should reassess your life goals.”
Common errors in 64 bit programs
A collection of common errors C++ resulting mostly from recompiling them from 32 to 64 bit, brought to you by Intel, can be found here.
