RoboGeek

As Blogging Goes Corporate, It Becomes a Full-Time Job Blogging is an interesting trend.  Blogs are just a web site in a given organizational structure, so what's the big deal?  It seems that the big deal is the informality.

As Blogging Goes Corporate, It Becomes a Full-Time Job (By Sarah E. Needleman in Career Journal)

The article describes bloggers who are doing it as an official part of their job.  Largely the positions described are really marketing jobs, with the only twist being that the "marketing" is done via blog rather than the typical methods.


(2005-05-31 15:34:49.0) Permalink Comments [0]

A server-side appframework to assist Swing app development? While browsing the blogs yesterday I came across an oddball proposition.

Namely, they're using Spring, a serverlet app-framework, to make it easier to write Swing applications.  With such a head-twisting idea, one wonders WHY???

In "Remedial Spring Rich Pt 1, Seting up" we see why.

The basic idea is this: developers are often complaining about the complexity of the Swing API… doing simple things is easy, but building real applications involves a very steep learning curve, and is likely to require a lot of application plumbing code (think data binding, wizard effects, registries to store common GUI actions and global references to disparate GUI components). This work is tedious and isn’t the reason you set out to develop a rich client.

Swing app frameworks and containers could solve many of these problems by providing a more high-level API for developing Swing clients, and leaving the tedium (and maybe even multi-threading) to the container or framework. Commonly needed functionality could be more easily plugged into your application. The topic is very sexy at the moment.

Okay, there's a limited number of really brilliant developers, and a larger number of average developers.  To reach the average developers with Swing, the argument goes that Swing needs to have a simpler model.  The difference is probably mostly to do with the threading.

Swing is not thread-safe, because 2D and AWT are not thread-safe.  Hence to make changes to the GUI, the code making the change has to call Swing/2D/AWT methods from the event dispatch thread.  But at the same time long running tasks fired by an event listener are supposed to happen on their own thread, so that the GUI doesn't get blocked while the long running task is running.  For a small scale application this isn't a big deal, but once the application gets big enough the thread issues get pretty large.

The problems of avoiding deadlock are among the toughest in computer science.  The argument I see in the proposals is to simplify certain issues, especially threading, through the use of an appframework.

Comparatively on the server/servlet side of the world, the application developers aren't exposed to grunty thread issues.  The servlet container takes care of all the threading issues, and the servlet developer simply gets called during certain moments in the lifecycle of the application.  This lets the more average programmers write servlets, and apparently the average GUI programmers get stumped by Swing and apparently stomp off in the other direction.

I haven't looked at Spring .. however I've written a few JSP's.  It's clear that servlets probably cannot directly translate directly to a GUI application, and it's just as clear that the general concept ought to be applicable to GUI applications.

The general concept of a servlet is that you write a blob of code that exports a given Interface.  The methods on that interface are called at given moments in the lifecycle of the application.  There is also output from the methods, and that output is automagically gathered up to return it to the caller.  The APPLET model is similar, and is a similar simplification because if the APPLET programmer had to deal with all the idiosyncracies of the various browsers they'd have run off screaming in the other direction long ago.

Just thinking off the top of my head - one could define an interface that allowed binding an Action to an event, and tells the Action one or more GUI elements it is to deal with.  The Action's methods would be called on a worker thread, and the interfacing would take care of exporting calls to change the GUI elements to occur on the event dispatch thread.