WebWorks 2.2
I've always liked WebWorks, though I've only had a chance to use it as a "sample" framework (nothing real-world). The design has always appeared very well done, and the concepts easy to grasp. The sticking point has always been that there never appeared to be enough traction to keep the project up and running.
However, today sees the release of the new version of
WebWorks, version
2.2. This release appears to be in anticipation of the next
Struts release, which will see the two products merge into one (Struts Ti). Where this gets interesting is that Struts Ti has an Inversion of Control (IoC) container -- and guess what it is?
Spring!So, I have to wonder if we won't see the merger of all three products over the next few years into one common, pluggable, framework?
OSCache results
My OSCache mappings have been live now for more than 24 hours, and my benchmarking tool got put to good usage. OSCache is performing miracles, almost.
I took a "random" sampling of about 100 page loads by various users throughout the day, and found that, on average, pages now load 2 seconds faster. Most impressive is that the standard variation has dropped down, meaning that most of the pages load in "about the same time" -- so the user doesn't have some pages loading instantly, and others over a 5 second window. Which can create some confusion.
Overall, it was a great success.
More OSCache
I've spent a few days now (off and on), working with
OSCache -- to try and cache objects at the DAO level. Before you start in on me, please be aware that the code I'm working on is pre-
Hibernate. The DAO's don't have access to the wonderful
EHCache provided via Hibernate. I realize I could move the product over to Hibernate, but that would take a lot longer than two days, most likely.
I just completed the first phase of the project, moving the three objects that do most of the heavy lifting, to use OSCache. The numbers are quite amazing:
No cache: First run: 211,710 ~ 21 sec
Second run: 198,336 ~ 20 sec
Third run: 204,442 ~ 20 sec
Fourth run: 200,189 ~ 20 sec
Fifth run: 195,941 ~ 20 sec
Sixth run: 196,608 ~ 20 sec
Seventh run: 137,639 ~ 14 sec
Eight run: 122,488 ~ 12 sec
Ninth run: 142,241 ~ 14 sec
Tenth run: 209,192 ~ 20 sec
Average: 181,878 ~ 18 sec
Max: 211,710 ~ 21 sec
Min: 122,488 ~ 12 sec
Cache: First run: 218115 ~ 22 sec
Second run: 21 < 1 sec
Third run: 23 < 1 sec
Fourth run: 37 < 1 sec
Fifth run: 12 < 1 sec
Sixth run: 8 < 1 sec
Seventh run: 62 < 1 sec
Eight run: 16 < 1 sec
Ninth run: 6 < 1 sec
Tenth run: 5 < 1 sec
Average: 21,830 ~ 2 sec
Max: 218,115 ~ 22 sec
Min: 5 < 1 sec
That's quite a change. Considering that we do (normally) hit the database between 80,000 and 100,000 times per day, my hope is to drop that number down to under 5,000 using OSCache. So far, it's very promising.
ISBN Update
After my
previous post on ISBN's (via
Seth), I had one of my high-school interns do some digging as to the relevance of Seth's claims, and the feasibility of someone actually attempting to go out and "challenge" the system. I'm not claiming it will be easy.
A fast poll of a few "younglings" shows that they all are well aware of many of the free (and pay) tools online, who seem to be targeting them, but missing the boat. A quick Google shows
eazypaper.com,
noodletools.com, and
easybib.com, among others.
Probably half, or more, of the bibliography touting users in the US are middle-school and high-school students. None of those students likely have a debit or a credit card. So, I would postulate that most of the above companies missed the boat.
Someone else mentioned that
libraryThing.com did everything you needed for a bibliography, which isn't quite the case. However, it certainly appears to be a poster boy for the Web 2.0 application.
Which brings us to ISBN databases. There is no such thing as a singular ISBN database. Doesn't exist. And those that claim to be such things, are incorrect, and behind. Here's why:
- A publisher applies for an ISBN "range", similar to IP ranges, from isbn.org.
- The publisher (if approved) is given an ISBN range, to do with as they please.
- The publisher develops and publishes a book. On the way out the door, it gets an ISBN.
- A library, or Amazon, or buy.com, or someone else, gets a copy of the book, and the ISBN.
- The entity from step (4) updates the MARC record at their library (assuming the entity was a library). This can be fetched using the Z39.50 protocol, or XML, for those who are up to speed.
- Someone (most likely the library of congress) will snatch up the ISBN code, as well as the other information from the MARC record (title, author, etc...).
- Now that the ISBN is public record, and available via your local library, it will be added to any of the online ISBN databases.
The problem, of course, is that steps 4 - 8 can take a long time. More than twelve months. So, someone seeking to advance this incomprehensible mess would need to speed those steps up to ensure that the poor student is able to kick out their bibliography in time.
Now, I'm sure Seth would love someone to come along and completely toss out (or revolutionize) the bibliography. It truly is busy work at the extreme end of the spectrum. Although it could be technically done for the paper-bound book (ISBN searches
are available for the vast majority of books), how exactly does one handle the growing list of web pages, magazines, online books, audio books (
audibles.com), blogs, podcasts, and all of the other sources someone might need to cite?
OSCache
I started today implementing a layer above our DAO layer (for a client) to implement
OSCache -- to reduce some of the load on the aging database (
Informix 7.3). The goal is to be able to create an object cache of POJO's, and arrays (we have a fair number of those -- leftover from when Java's arrays were significantly faster than Java Collections), which are rarely, if ever, modified.
So far, the implementation of OSCache has been minimally complicated. The new "groups" are not well documented in the
API / JavaDocs. However, I think we can manage without the groups for now. Instead, we've abstracted an interface allowing the existing DAO's to decide whether or not they are inside an OSCache container (ie, in a web container, or a shell container), and if they are in a OSCache container, to utilize the cache.
Looks like we'll end up adding about 60 lines of code (including error checking) to each of our 20 DAO's, and one line of code to the actual web layer. Should be fun to look at some benchmarks once it's actually implemented.
Octopus Write Up
Today, I downloaded and fired up
Octopus from
ObjectWeb. I just recently had some issues with Kettle, and wanted to try out another Open Source ETL tool before attempting my own.
I spent a few minutes fumbling with the installation scripts and RPM's (the RPM's don't seem to work on a
Fedora Core 4 system). I grabbed the tar file, uncompressed it, and put it where it should go. Another ten minutes was spent trying to figure out what the developers were
trying to do with the configure scripts.
I got the GUI (OctopusGenerator) up and going as the documentation explained, and spent only a few seconds actually setting up the JDBC connections ... within minutes I actually had the project working.
Although I can see the potential in using this project (or Kettle) -- by the time one has learned the ins and outs of the database, the tool, and built all of the necessary Java transformation / translation classes, you'll certainly wonder why you didn't just write your own. That being said, Octopus has some interesting use of what appears to be Rhino, allowing one to code Javascript transforms. Why not
Beanshell?
Groovy? These might make writing the actual Transforms a little less cumbersome.
We'll probably use it in the future ... as necessity dictates our requirements.
Summer Internship Has Arrived
Our
Lubbock summer internship has arrived!!! We are now accepting (through mid-April) applications and resumes for an internship at our headquarters in Lubbock, TX. I'll be putting up a web page at our web site (
www.resolution.com) in the near future describing the program. In the meantime, here's some quick information . . .
- We're seeking between 2 and 4
high-school or
college students.
- We're seeking students who are "
programmers", "
geeks",
graphic designers, or
marketers.
- We're seeking students who are able to pick up new skills
extremely quickly.
- We're seeking students who like to
read. [You'll get to read a LOT].
- We're seeking students who want to learn real-world
skills.
- We're seeking students who want to work on
real-world projects.
You'll be developing one (or two) real-world applications ... web-enabled applications. You'll be using some combination of
linux,
Java,
Spring,
Hibernate,
PostgreSQL, and
AJAX. You won't need to know most of these to be considered for a spot -- Java is the only initial requirement.
We'll be focusing on user-design, database design, application design (ala patterns), interaction with existing applications (also called integration), and everything else a real-world application needs to focus on.
Summer stipends are
Yet
To
Be
Determined.
Seth Missed Something?
I'm a huge fan of
Seth Godin, and what he's trying to achieve (and perhaps is succeeding).
Recently, I picked up a copy of the
Purple Cow, and managed to read it on a non-stop between Laguardia (NY) and McCarren (Vegas) airports. Very well written, very insightful, and a great read. I recently picked up a few of his other books.
However,
today he managed to discuss something I've helped a few younger friends with myself, ISBNs. And, although he's correct in his discussion of the mentality behind the college and grade-school professors, he did manage to miss out on the
Library of Congress. They have an
ISBN database, complete with (as far as I can see, quickly) all of the [basic] information needed for a bibliography. Granted, if you need 10 books, you'll have to enter the ISBN 10 times, not once.
A quick attempt to query the LOC 10 times, and kick out an RTF / Word document, would be very easy to accomplish, almost trivial. Assuming, of course, that they (the LOC) don't mind you pounding their database.
Octopus
I tried
Kettle yesterday, and after sitting down with it, and its well done
manual (more than 100 pages), I still couldn't get the thing to actually work. It seems it stores the transformations, etc... within a database -- the same database that it actually does the transforms on. However, the scripts for creating the transformation database on
Informix (yes, my client is still on that), aren't working. They work great with
PostgreSQL -- but we're not yet on PostgreSQL.
So ... today we'll try
Octopus.
Graphic Artist
We're currently
hiring for a
graphic artist. Should be able to:
1. Think cohesively.
2. Arrive
ontime.
3. Work in a reasonably professional manner (see #2).
4. Not
complain when the work isn't "easy".
5. Perform amazing feats in
Photoshop, or some other "2d" program (the
GIMP is OK).
6. Use
Dreamweaver to some extent (because people should see your artwork).
7. Use Bryce, Poser, and any other number of
real-world graphical applications.
8. Have a good since of
humor.
9. Not mind me getting on a soap-box.
10. Able to disregard any comments I may make about
higher learning and its uselessness.
Work will include 3d rendering of prototypes, client work (my clients), web site design (please leave flash skills at the door), and dancing on your head. You should become familiar with much of the theory over at
37 Signals before emailing me.
I provide ... money. Health insurance (HSA) if you need it. Flexible schedules. A gym to work out in. Free food (sometimes). A computer to work with. A desk to work on. A chair to sit in.
If you're interested ... email me at
anthony@resolution.com.
Health Insurance
Tom Evslin is spot on today. Spot on.
We spent the first year managing our employees (3 at the time) HMO plan through
FirstCare, and went over to
Covenant Medical for our health care. As soon as we heard about the HSA plans available, I jumped ship, and moved to allow everyone who we employed to manage their own health care.
We now have been using the
HSA -- to our definite advantage. Most of my employees have been slowing hoarding both the employee AND employer contributions. My family (the only one with a wife / children up until recently) have managed to stay ahead of the curve, spending less than we would have with an HSA, even counting prescriptions.
Another major supporter of the HSA program is
Dave Ramsey.Any employer who needs employees (the problem being that most of them don't believe in Tom Evslin), should seriously look at HSA's (the new version of the MSA).
Go capitalism.
