I found this helpful for centering some links today. It could be used to center any block on a web page, both vertically and horizontally.

Since the Segway first came out, I’ve been one who has believed the Segway will eventually make much more of an impact than most believe today. Tonight, I was reading to my son about the Wright brothers, and just had to share with you some interesting history, that I think is relevant to the Segway and other inventions that many underestimate upon first glance.

Did you know that the first “bicycle” was invented in 1818? It was a two wheeler, moved by pushing with the feet while sitting. Then in 1839, the first pedals were added, but the wheels were still made out of wood or iron, which made for a very uncomfortable ride. In the 1870s, spokes, steering, brakes and chains were added. Finally in 1888 rubber tires were added, and 40,000 bikes were sold in 1890. Five years later, over a million bicycles were being produced.

I’m sure in 1818, not many ever thought that bicycles would become such a common household item. It took over 70 years before the bicycle became what we now know it as.

Coincidentally, we also watched a show tonight about old cars, and they were showing the steam cars and early gas cars. Very interesting to see a steam car as it moved so silently and much faster than I ever would have guessed. And yet, from what I saw on the show, they look to be quite a lot of work to use. Obviously, cars have changed a lot since then, as did bicycles and airplanes.

If you look at the history of most inventions, they follow a similar pattern, usually beginning with the first step looked upon quite skeptically by the masses. But, perhaps now, that you’ve been reminded of the history behind bicycles, maybe you’ll look at the Segway and other inventions with a slightly different point of view.

Now…go invent something!

If you haven’t yet read about Groovy, here is an article on Sun’s web site about it. I like the idea, as you should probably have guessed from my complaints about Java. Just looking at some of the examples reminds me of the fun years I had developing simple things in Perl. No, this won’t replace Java development in general, but it could be used for some very simple applications, from Unix scripts to simple web sites.

Just a thought for Internet Web Development departments. Many times a department will make a decision to use another technology (for example, an open source Java library) which is free. Its quickly implemented, but the department and the company never stop to calculate the true costs. When adding any new technology, there will always be a learning curve, not only for the current employees but also for any new employees brought on in the future (whether out of growth or for replacement). As well, now that an additional skill set, or API knowledge is needed, it might increase what the company has to pay to hire an employee.

The added technology may solve a real problem, and may not cost the department anything up front. But the question is, how much company time and money will it cost down the road? Will it be harder to replace any employees who have this new knowledge? Will other employees in the department need training? How quickly will they be able to pick it up? Will it unnecessarily complicate your application?

All important questions to ask.

In a previous post, I suggested I’d like to see a much looser coupling between the front-end, or GUI portion, of a web app, and the back-end, which handles data persistence, business rules, and all other types of data processing. Really, what I’m suggesting, is that these areas be broken down into separate unique services. The further we break components down, the easier it is to design them, code them, test them, and maintain them (at least to a point, you can go too far with this).

If you aren’t yet familiar with Service-Oriented Architecture, then read this post from several years ago on webservices.xml. It’s a good introduction to the concepts. So far in my experience, I think the GUI is being asked to do far too much; to be far too smart for its own good. I’d rather all the brains of the user interface be provided by services, and the front end simply stick to the role of providing a visual interface to those back-end services.