Mon, Jun. 23rd, 2008, 04:47 pm
Dear only reader, :-)
Since I never have the time/patience to blog, I'm starting a "tumblelog" at Tumblr.com:http://dserodio.tumblr.com/
Let's see how that works out.
I'll post some Java 6 gotchas here as I run into them, because I'm getting worse at remembering these kind of details.
javax.xml.parsers.DocumentBuilder#parse(String uri) from Java 5 accepts a filepath like "C:\temp\foo.xml" (which is not a valid URI) while in Java 6 it doesn't.
This problem manifested itself when I tried to run DbWrench in Java 6.
Nice advice on the subclipse-users mailing list by Mark Phippard
- Team -> Create Branch/Tag Specify URL to store it, and be sure to select option to create from working copy. Since your project is still on trunk after this completes, you have to do a Revert to get the project back to a pristine condition.
- Use Team -> Switch when you want to go back to the branch code.
- Do Team -> Update on your project so that your entire working copy is updated to a single, known revision.
- Do Team -> Create Branch/Tag and create a branch directly in the repository using that known revision.
- Do Team -> Switch to swap your working copy to the branch. Since it was already based on that revision, this will be quick and simple.
- Do Team -> Commit to commit your changes to the branch.
- Do Team -> Switch to swap back to trunk.
Why is this "better" when it is so many steps? It separates the creation of the branch from the commit of your changes. This makes it easier to create a patch with your changes, or to later merge them back to trunk. The "easy" method is fast and simple way to stash your changes but it will be harder to later reintegrate those changes to the trunk.
Just came across this "snippet of wisdom" in the Maven
file:// defines the file protocol
file://localhost/ is the root adress on your local system
file:/// is the short form of file://localhost/
file://///server/share/ addresses the "share" of "server" in a Windows network, which is a convenient form of file://localhost/\\server\share\, since the path from your local system to the server's share is \\server\share
Got it? Any other mixture is a concession to user's habbits and may or maynot be supported by the URL parser of your product/app/browser.
Damn! No Callisto today!
Callisto will be delayed for a bit. Unforeseen circumstances.Uncontrollable events. We don't have an ETA yet, but stay tuned forinformation. We do expect it to be released today.
What's scripting? How is it different from programming? The best definition I found is Ward Cunningham's:
I'm interested in scripting as a style of programming instead of a style of languages. You're writing the program to serve YOUR needs, not somebody else's needs so there's a different set of trade offs. We get caught up in serving the needs of our customers that we forget to meet our own needs.
BTW, if you don't know Ward
, he's the "Wiki father", and one of the greatest authorities on Design Patterns.
Fri, Jun. 2nd, 2006, 12:33 pm
I'd read about Spring 2.0 before, but I didn't like what I read. It seems to be moving away from XML-based dependency injection, towards annotation-based. Using Spring annotations in my classes would tie them to Spring, which I don't want, so I was pleasantly surprised when reading the (still-in-progress) What's new in Spring 2.0?
- Easier XML configuration
- Extensible XML support
- New bean scopes
It seems like they haven't got as annotation-crazy
as I'd thought.
Our projects' glossary is currently written in M$ Word. I really, really dislike M$ Word, for a bunch of reasons, mainly:
- It's expensive
- It's proprietary
- It's resource-intensive (aka uses a great amount of RAM)
- Binary document format
- Mixed content and presentation
Our organization has tons of M$ Office licenses, so points 1) and 2) are not so important. Our developer's machines are not exactly high-end, so point 3) is important. But the main problem is that the binary format is not RCS-friendly. The RCS can't diff two different revisions, ergo, can't automatically merge concurrent modifications.
The net effect is that M$ Word documents are often forgotten, because it's such a pain to modify them (in a collaborative environment, of course) that you often procrastinate. Our glossary is completely out-of-date, because no one bothers to update it.
This holds true for all kinds of M$ Word documents, but I decided to begin thru the glossary because it's the most dynamic (text) document we have.
These are the requirements:
- Text-based (of course)
- Open standard
- Easy editing
Last week, I investigated 4 alternatives:
||Simple. Easy editing. Easy cross-referencing (hyperlinking).
||Only works online. Not really RCS-friendly (Trac has own RCS). "Loose" structure.
||Simple. Very readable||Syntax is not as easy as it seems. "Loose" structure.
||Simple. Readable.||Designed for ordered or unordered lists, not "definition lists" (a glossary is a special case of definition list).
|XMLGloss||Specific for glossaries
||Specific for glossaries (won't work for other types of documents). License too restrictive
Today, I remembered about DocBook.
DocBook provides a system for writing structured documents using SGML or XML. It is particularly well-suited to books and papers about computer hardware and software, though it is by no means limited to them.
In theory, it seems like a perfect match. It has a whole lot of glossary-related elements. It's XML-based, so you can leverage your knowledge about XML. So now, I'm looking for DocBook tutorials, tools, anectodes, and glossary examples.
So now the speculation is over. Red Hat bought JBoss. I don't know what Red Hat has been up to lately, so I don't understand what the implications are. After reading half a dozen "JBoss is evil!" rants, I ran across an interesting article
by Timothy M. O'Brien. I'd never seen GPL as "bad", but this article makes a pretty good point about GPL x Apache license.
Currently, we have a single Java web app running. This app's architecture is a mess, because the developer who implemented "the web part" had never done Java webapps before, so he used the only "model" he was used to: PHP.
As a result, there's a lot
of business logic in the JSPs, which makes it pretty hard to test, and it completely ignores that its running inside a container.
The app's security uses a programmatic model, and is pretty badly implemented. The login page creates an "operator" bean and puts it in the
. Then, each JSP has a
tag, which looks for this "operator" bean. If the session has expired, the result is a "InstantiationException: bean operator not found within scope" error.
The error page tries to differentiate between a "regular" error and a "bean operator not found within scope" error using
, which is pretty fragile. The net result is that when the session expires, the user gets a cryptic error page and the app logs an ERROR which is not an error.
I have configured log4j to e-mail me all uncaught errors, which means I'm getting lots of e-mails reporting expired sessions.
I knew this implementation was bad, but the flood of e-mail has made me fix it now
. In a (near) future, we're going to need a SSO
solution, but for now, I'm using plain Servlet CMS
; I hope it won't be too difficult to replace it when the time comes.