John Resig released a port of the Processing language to JavaScript. The demos are very inspiring.
web
17
Feb 09
Problems with Hibernate
After 8 months of development of a new project with extensive use of Hibernate I can now tell about my experiences with it. In general, Hibernate is a very useful tool. It saves a lot of time, because you don’t have to write SQL queries. If you make changes, you usually don’t have to rewrite queries, because there are only a few of them. The configuration using annotations is simple and powerful (and I personally prefer it to writing mappings in XML). Hibernate is able to generate database tables from mapped classes automatically and even update them as you add new fields to a class. Hibernate caching facilities are very useful. Finally, Hibernate allows to develop database vendor indepentent applications.
But there are few problems which I experienced:
- The most frustrating is in fact described in the Hibernate docs. An object returned by session.load() isn’t necessarily an object of the expected class:
Cat cat = (Cat) session.load(Cat.class, id); // instantiate a proxy (does not hit the db) if (cat.isDomesticCat()) { // hit the db to initialize the proxy DomesticCat dc = (DomesticCat) cat; // Error! .... }
- No inheritance mapping for value objects: here is the JIRA issue that never gets fixed, and a workaround.
- The strong suggestion in the Hibernate documentation to use a join table for every unidirectional one-to-many association (in the section 2.2.5.3.2.2. “Unidirectional”). Another suggestion is discussed here.
- 2nd level caching should be used with caution: after deleting an object the stale version can still stay in cache which can lead to an ObjectNotFoundException. I found no other solution except disabling the 2nd level cache for the class.
12
May 08
Werkzeug allows debugging a web app directly on an error page
At the Grazer Linuxtage I liked most the Armin Ronacher’s talk about Werkzeug which is a Python library for building web applications that doesn’t limit you in the way you build your web app (like many of the existing frameworks do). Werkzeug is rather a handy set of tools and utilities for making web apps than a framework.
The most impressive part of the talk was when Armin demonstrated the “online” debugging feature on a standard error page generated by Werkzeug. Upon each error the context in which it happens is stored on the server (only if the app is in the debug mode). Thus on the error page itself you can directly interact with the Python interpreter which is “frozen” in the very state in which the error happened. So you can use the full power of the interactive Python interpreter directly on the standard error page. That’s awesome.
21
Nov 07
JSP recursion
If you need to render a tree-like structure here’s a way of implementing recursion in JSP/JSTL:
${node.title}
<div class="children">
<c:forEach var="node" items="${node.children}">
<c:set var="node" value="${node}" scope="request"/>
<jsp:include page="node.jsp"/>
</c:forEach>
</div>The tricky thing is that when you use jsp:include (and for recursion you have to use the dynamic inclusion), normally, you loose all the variables defined in the parent JSP. But if you redefine the variables you need in the “request” scope, then they will be visible in the included JSP too. I assumed that this very JSP is named “node.jsp” and omitted the declarations. Surprisingly, I found neither this nor any other solution on the Web, so I had to invent one.
5
Nov 07
Processing rolling logfiles backwards with Perl
I needed to write a script which runs on the server, gets daily statistics from our rolling log files and sends them by email. The log is splitted into 64Mb files and the total size is limited by 1GB. I didn’t want to parse the whole gigabyte of logs, so I decided to start from the most recent file and read it in the backward order till the previous date. I found two approaches to read file backwards with perl. The first approach is slower but requires a fixed amount of memory (in my case about 2 mins and up to 16Mb RAM):
tie(@lines, "Tie::File", $fname, mode => 0) or die "Can't tie $fname: $!"; $max_lines = $#lines; for ($i = $max_lines; $i; $i--) { if (not &$apply($lines[$i])) { return 0; } }
The second approach is faster but requires at least as much available memory as the size of the log file, in fact more than twice as much when processing several files one by one (in my case, 1:02 min and up to 150Mb RAM):
open(LOG, $fname) or die "Can't open $fname: $!";; @lines = reverse <LOG>; foreach $line (@lines) { chomp $line; if (not &$apply($line)) { close(LOG); return 0; } } close(LOG);
So I chose the first approach, because I thought that stable memory footprint on the server is more important than the time the script takes to complete. Here is the full code for the package I wrote that provides handy functions for scanning rolling logfiles forwards and backwards: logscan_pl.txt
And here is a usage sample:
require 'logscan.pl'; $errors = 0; logscan::scan("Joanna", sub { $_ = shift; if (/(.*) INFO.*Returning error by [([^]]*)].*user=[([^]]*)].*roles=[([^]]*)]/) { my ($time, $uri, $user, $role) = ($1, $2, $3); $errors++; print "$time $uri $user $rolen"; } return 1; }); print "\\n\\nTotal errors: $errors\\n";