That thing I mentioned? Mid-December Barb is due with our first baby. Everything's gone swimmingly so far, and she's in that phase of being happy but cranky due to having constant indigestion and general discomfort.
By choice we don't know yet if it's a boy or girl and while we have a few names on the shortlist, I'll keep those under my hat for now. And the list might change, to which I'm more amenable than Barb just because she's actually prepared for things.
But I think we have a lot of the big decisions made and have been throwing gobs of money at the house to prepare -- the stairs and second floor are now carpeted, and we had some environment people rip out all the drywall in the basement because of some mold. (I didn't want to do it myself and wind up as a CSI-type exhibit.) That said, you're never really prepared.
Nauseating baby photos to follow in a couple months...
No sorting, just to keep it interesting:
Simple Tools For Simple Tasks... With Cool UIs - Romain Guy has been posting some really nifty Swing tools, presentation slides and videos recently. I'm no GUI programmer, but it's not your father's AWT anymore. (He's also got some great photos around too.)
Logs the statement and its duration on a single log line if its duration is greater than or equal to the specified number of milliseconds. Setting this to zero will print all statements and their durations. Minus-one (the default) disables the feature. For example, if you set it to 250 then all SQL statements that run 250ms or longer will be logged. Enabling this option can be useful in tracking down unoptimized queries in your applications.
Auto save is implemented in lots of desktop applications. It's just the idea that every so often (seconds or minutes) the applications will store your work someplace safe, and you can get it back if the application crashes, or if you accidentally close it and click through the multiple 'Are you sure?' dialogs.
But what if you didn't even have a 'Save' option -- why do you even have to manage that? Isn't that why we have computers? Why can't the computer automatically store every change so that you never have to think about it? It's not so far out: Quicken has done this for a long time. It has the benefit of clearly demarcated transactions, but that's just a convenience.
But AFAIK autosave isn't seen so often in webapps. Entire frameworks are built up around translating the bag of text you get when the user clicks the 'Save' button into usable data (e.g., using an actual date object instead of '2006-10-05' or 'next Tuesday'). And the frameworks themselves are typically record- or object-centric, presenting a data record as a consistent, whole item so it can be mapped (with hopefully a minimum of dissonance) onto an HTML form.
What would happen if a webapp dealt with the individual pieces of data, rather than entire records? So if you check a checkbox, we send a message to the server saying, "activate the data element represented by the checkbox"; if you type in a person's name and tab to the next item, we send the name to be updated. If you figure out halfway through your edits that you're editing the wrong record you can just click 'Undo' and it'll roll back your changes since you loaded the form.
Since we're treating the web form as an active data editor we can remove concerns like validation from the browser. And treating data items individually would likely make it easier to create components to handle most of the work for you.
There are certainly problems with the approach. It means you have to version individual fields, which can be an interesting data management problem. (This also has a positive effect: stale-data conflicts become much more granular and easily resolved.) Some pieces of data are combinations of fields which may not make sense (logically or transactionally) to update independently, which means more things to manage. Managing 'Undo' functionality adds complexity as well. And a low-latency, always-on data connection between the browser and server is a requirement -- in fact, it might only work for intranet-type applications.
It's an interesting idea; while I'm not sure it's practical, it's a pretty good usability goal to shoot for.
The Dark Side Of SOA - Not a terribly interesting article (at least not for the 30 seconds I devoted to skimming it), but I think they forgot an option on the last bar chart:
(view image: The real bar chart)
At work I've been working on rearchitecting a server platform for AccuNurse. And as I wrote before I think REST offers a really useful way to let our systems and external systems interact with our data.
While there are layers that sit on top of existing platforms to allow you develop "RESTfully", there are also projects that are built from the ground-up with the REST architectural style in mind.
AFAICT the main REST platform in Java is Restlet. It can run on top of Jetty (5 or 6, the Simple web framework, Async web, or in a servlet container. And while it's currently at 1.0 beta 18 the API still undergoes fairly substantial changes from release to release.
One of the (IMO) glaring omissions is the presence of a sample application that actually does something, even something trivial. The docs talk about how to get the server configured and running, but not so much about how you use the different types of objects to do work.
So I built one, which you can grab from here. And I submitted some minor documentation and code patches. And only then did I think that I should clarify what Vocollect's policy on working on opensource for work purposes. We do have a policy that you can work on opensource software in your own time, as long as it doesn't duplicate what you do at your job. But not what you do on the job.
So I posed the question up the chain. And the answer I got back was very gratifying. Paraphrased, it was: "We have as part of our business plan to lower costs by using open source operating systems and platforms. Part of using open source means participating in the process, which means giving back. So as long as it doesn't take too much time and it's appropriate to work, go ahead."
Show me your flowchart and conceal your tables and I shall continue to be mystified. Show me your tables and I won't usually need your flowchart, it'll be obvious.
I think substituting 'messages' for 'tables' preserves the meaning while bringing it forward into what seems to becoming a service-driven era. Guy Steele did something similar a few years ago, except specifying object interfaces instead. Too much coupling, messages work better
You can tell Perforce to automatically mark certain files as type 'ktext', which is necessary to expand the RCS-like keywords. Unfortunately you have to do this on a per-depot basis and I forget to do so when creating/using a new one. So this post is to remember two things:
This perl script will invoke the 'p4' command-line client to modify the filetype for those file extensions you specify. The only requirement is IPC::Run, which at least on ActivePerl is there by default.
 Technically you don't have to (you can use the '//...' depot map) but if you're working in an org with many different development groups, some of which don't have much contact with one another, it's pretty rude to create a global type map.