February 18, 2009 at 11:17 pm (Humor)
Step 0: Write just enough code to actually qualify as an open source project. Maybe a little less.
Step 1: Hack together a project website that’s more about SEO than it is about promoting your project. Don’t forget to mention the Killer Ajax Framework which you developed in 2007.
Step 2: Host your project on SourceForge, and ask the SourceForge administrators to artificially inflate your project’s ranking. Because you rock, and they know it!
Step 3: When the SourceForge admins politely tell you to get lost, take matters into your own hands and artificially inflate your project’s ranking yourself by spamming your own forums. Number 1, baby!
Step 4: Take advantage of TheServerSide’s new and improved RubberStampTM editorial process by submitting an eloquent and compelling introduction to your project.
Step 5: Profit, you crazy diamond!
Update (February 15, 2011): Step 6 apparently involves posting spam to the comment section of snarky blog entries which poke fun at your project in thinly veiled language (see below). I’m afraid it’s ironic enough that I’m going to have to leave it! 
February 18, 2009 at 10:26 pm (Note to Self, Oracle)
To find all sessions for a specific user connected via the Oracle JDBC driver:
select * from v$session where username='X' and program like '%JDBC%';
To kill all of these database sessions:
declare
statement varchar(100);
cursor c is
select 'alter system kill session '''
|| sid || ',' || serial# || ''' immediate'
from v$session
where username='X'
and program like '%JDBC%';
begin
dbms_output.enable;
open c;
loop
fetch c into statement;
exit when c%notfound;
dbms_output.put_line('Executing: ' || statement);
execute immediate statement;
end loop;
close c;
end;
This will result in output similar to the following:
Executing: alter system kill session '225,46' immediate Executing: alter system kill session '226,110' immediate Executing: alter system kill session '233,6617' immediate
February 5, 2009 at 2:48 am (HtmlUnit, JavaScript, Rhino)
I’ve been examining HtmlUnit‘s performance from a couple of different angles lately. As a pure-Java headless browser intended for integration testing, one of HtmlUnit’s big draws is improved performance vis-a-vis native browsers and libraries which drive native browsers (Selenium, WebDriver, etc).
One the one hand, it’s easy to see that HtmlUnit reduces overhead by forgoing a GUI. No layouting, no drawing, no problem. If you poke around a little bit, you’ll also find that HtmlUnit does not download most images (there are some exceptions), nor does it download external CSS files if CSS has been disabled — all advantages in terms of network usage.
However, as you get closer to the RIA end of the web application spectrum, these performance advantages become increasingly overshadowed by JavaScript performance. HtmlUnit relies on Rhino to do the JavaScript heavy lifting behind the scenes, so as web applications become more functional, we’re going to be relying more and more on Rhino’s muscle.
Google just released version 3 of their V8 JavaScript Benchmark Suite, which tests pure JavaScript and pretty much ignores the DOM manipulation side of things — making it a perfect worst-case scenario benchmark with which to compare HtmlUnit to native browsers. In other words, if you use HtmlUnit such that all of its traditional performance advantages are negated (unlikely though that may be), how does it stack up against the native browsers?
Not too bad, as it turns out (bigger numbers are better):
The good news is that Rhino is more performant than IE 6 or IE 7, so HtmlUnit still beats these browsers in this unrealistic worst-case scenario.
The bad news is that IE is by far the slowest native browser out there in terms of JavaScript execution speed; we can’t assume that it will remain slow forever… can we?
January 10, 2009 at 9:47 pm (Java, Spring)
If you tell Spring 2.5.6 to scan the classpath for application context XML files and you’re deploying to JBoss 5, you may run into this bug; something to do with JBoss’ new Virtual File System (VFS) and its non-standard URLs. It looks like this issue was caught in time to be fixed for 2.5.6, but I guess the SpringSource guys didn’t have time to test it before releasing — the fix doesn’t really work.
It appears there will be a 2.5.7 release within the next couple of months (see slide 14), but it’s probably going to be the first of the commercial-only Spring releases. However, Spring 3.0 is also due within the next couple of months (see slide 5); let’s hope for a fix then. Otherwise, they may have to take JBoss off of the deploy graph on slide 4 
December 31, 2008 at 12:12 pm (HtmlUnit, Java)
HtmlUnit 2.4 has been released. See the changelog for more information about all of the improvements made since September, when version 2.3 was released. The TSS announcement is probably a good place to comment or ask questions about this release.
It’s exciting to see the steady improvement in JavaScript support. From the HtmlUnit main page:
The unit tests of some well-known JavaScript libraries are included in HtmlUnit’s own unit tests; based on these unit tests, the following libraries are known to work well with HtmlUnit:
- jQuery 1.2.6: Full support (see unit test here )
- MochiKit 1.4.1: Full support (see unit tests here )
- GWT 1.5.3: Full support (see unit test here )
- Sarissa 0.9.9.3: Full support (see unit test here )
- Prototype 1.6.0: Very good support (see unit test here )
- Ext JS 2.2: Very good support (see unit test here )
- Dojo 1.0.2: Good support (see unit test here )
- YUI 2.3.0: Good support (see unit test here )
October 7, 2008 at 2:56 pm (Java, Spring)
A couple of weeks ago SpringSource modified their maintenance policy. The change was a significant move in that it stripped non-paying users of certain perks (rights?), to the point of triggering arguments regarding what, exactly, constitutes an “open source” project.
In an attempt to find a balance between their open source roots and their commercial obligations, SpringSource made a mistake. They’ve now admitted it, and they’ve acted upon that knowledge. Kudos to them.
Back to work.
September 19, 2008 at 11:03 am (Java, Spring)
As per this post on TSS, SpringSource have announced a new maintenance policy:
Customers who are using SpringSource Enterprise, available under a subscription, will receive maintenance releases for three years from the general availability of a major new version. These customers receive ongoing, rapid patches as well as regular maintenance releases to address bugs, security vulnerabilities and usability issues, making SpringSource Enterprise the best option for production systems.
After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. Subsequent maintenance releases will be available to SpringSource Enterprise customers. Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software.
Now, there are only two ways I can read this:
If we take the Spring 2.5.x series of releases as an example, we have the following time line:
Spring 2.5.0: 2007-11-19
Spring 2.5.1: 2008-01-09
Spring 2.5.2: 2008-02-29
Spring 2.5.3: 2008-04-06
Spring 2.5.4: 2008-04-28
Spring 2.5.5: 2008-06-23
Applying the three-month rule to these releases, we can see that the community around this open source project would only have access to Spring 2.5.0, 2.5.1 and 2.5.2 (if we’re generous and round up).
I’m not sure whether or not the community would have access via public source control to the bugfixes included in the subsequent releases prior to the next major release, but as far as I can tell the best-case scenario is that we would have to build the subsequent releases ourselves, rather than just download the JARs directly.
Additionally, this policy takes effect immediately. If you’re not paying SpringSource, you may not get access to the upcoming 2.5.6 release…
Somebody tell me I’m misreading this.
UPDATE: Here.
September 18, 2008 at 12:33 am (Groovy)
I recently had the chance to revisit some Groovy code written last year which makes use of the Scriptom library, a Groovy/COM bridge which allows you to script ActiveX and COM components from Groovy. The code in question was fairly fragile in the worst of ways: it would crash roughly half the time… randomly.
Now, I’m not sure if the crashes were caused by Scriptom or by Jacob, the underlying Java/COM bridge, but after upgrading to the latest version of Scriptom (1.5.4b11, which also uses a newer version of Jacob) all of these crashes have disappeared.
The migration process took a couple of hours, but only because I didn’t read the Migrating from Previous Versions of Scriptom section on this page first; if I had done so, the migration would have been a matter of minutes.
Anyway, kudos to the Scriptom team (which apparently includes Marc Guillemot, a fellow HtmlUnit hacker) on an excellent release of this very useful library!
