Take a look overhere for more info: http://www.eclipse.org/community/ Here is a direct link to the PDF file containing the article.

Here are a few shots of the evening.
University session
University Session
University session

I am very curious about this. If the quality is good (how can it be for so little money) it is a bargain! Any thoughts on this will be much appreciated. Especially on how they can do this for such a small fee.

Within my employer I have been active for a thing called the “Rich Client Niche”. It is sort of an extra hours activity where we try to set company wide guidelines/standards and help RCP newbies on their way. And I am getting the feeling that it is starting to work, colleagues are aware of the niche and are actively requesting assistence and knowledge. In the past year we as the Rich Clien team have been able to get more attention to rich client Java development within our company. Especially at managerial level interest is growing into the potential opertunities in this area.

To support our activities into this year the decision was made to send me and perhaps another colleague to the EclipseCon 2007. I am very much excited about this, I am hoping that because of this we are able to get out competence level to the next level. Also I am very curious to talk to people about potential business opertunities focussed around Eclipse RCP. Drop a line if you will be there as well. I’m especially interested to learn if any other dutch colleagues at other companies will attend.

The project is about building an application with which the Dutch railways and any other user of the Dutch rail infrastructure should be able to plan all infrastructure, trains and personnel. Now from what I have heard, the way the Dutch railways are operated is almost unique on a global scale. Yes, you’ve read correct. Most rail infrastructure is used in a strict corridor like fashion, a train moves from A to B and B to A, all day long. But here in the Netherlands it really is a network problem. Everything, and I really mean everything crosses each-other at stations and other significant places. Now think about this for a while and let it sink in. Now I don’t know how things work in other countries, and frankly I don’t really care too much about that either. The project I’m in is trying to help planners for the Dutch situation.

Now, not only does the infrastructure need planning, the trains themselves have to be planned as well. Trains need maintenance, and at the start of the day the right equipment has to be available at the right places. Preferably with as little empty night time movements. Starting to feel a bit complex now. Well, that’s not all. Someone has to be on those trains to drive them, and let’s not forget the men and women who check your ticket. In the Netherlands a train is not allowed to depart with passengers without a conductor. Now think about this, personnel should start the day as close to “home” as possible and end up as close to home at the end of the shift as well. Oh and the machinist has to be certified for the type of train he’s running and be certified for the tracks he’s running on too.

Short version, this sh#t is complex. And the coolest part is, the entire effort is starting to feel like it’s going into it’s final stage of development. Sure there will be bugs to fix and deadlines to be met, signals are indicating that crunch time is near. I’ve been on this project for a good one and a half years now. But the effort started like a whole bunch of years ago. Last time I heard it was like 5 or 6 years ago that the first preliminary studies were conducted.

My role in this whole thing? I’m just one of the many hard working developers. My role is mainly focussed on UI and graphical display of data. Questions? Just ask, I’ll see if I can answer them.

• Basic web application
• AJAX
• Netbeans/Eclipse Rich Client
• Swing/SWT application

(This list is Java oriented.)

All of these have advantages and disadvantages. The list above can be divided into two main categories. To no surprise these are Web and Desktop. Anyway, right now I’m working for my employer on a document which ellaborates on these differences. Also I’ve submitted a proposal to the NL-JUG’s upcomming J-Fall to do a talk about this subject for my employer. I hope they’ll agree with me that it’s an important subject to reflect on a bit.

Wait a second.

Before moving on to something else it would be nice of you to actually make your app available to your users.

Let’s see. This one should be a bit of a no-brainer according to most people. Usually people start blabbering about how easy it is to deploy and maintain a web application. While this is true most of the time, things do tend to get a bit more complicated with Web 2.0. Things like Javascript and browser versions come to mind. And Rich Clients are supposed to be hard to deploy.

Let’s see what deployment and maintenance means. Mr. sys-admin likes to receive a shiny package with a clear description about how to do something as to get the functionality available to the end-user. This can mean a lot of things. Perhaps a copy paste deployment, some scripted system configuration or even good old “click here, type that, wait a bit, click some more, etc…”.

Either the “stuff” has to get on a web-server or it has to get on a desktop. Both of these you can make as advanced as you would like. It even depends on the skill and tools available for system maintenance.

See, most Java Rich Clients involve nothing more then unpacking a zip file and making sure a suitable Java runtime is available. No sweat there, especially when applications can be pushed centrally. You could even make a nifty installer, but all you need is to get you Swing or Eclipse application on the desktop machine.

Now for Web Application this holds true too. Get it on a server, perhaps you can create a nice installer or a WAR file. The only difference is that you only have to do it once. (Uhm, what about clusters?) The hard part is usually not in the end user interface, either desktop or web based. It’s the back-end services that are hard to do. You also need to get the business services deployed and you should tweak the application server accordingly.

So when it comes to deployment, I doesn’t really make a difference to me. Both Web 2.0 and Rich Client deployment has to be done RIGHT. That’s all there is to it. If the target platform supports some kind of standardised packaging system, THINK ABOUT USING IT. It will save you a lot of headache, because you decide what gets done at deploy time. You don’t want to make a nervous end-user or lazy sys-admin jump through a bunch of hoops. They’ll make mistakes and start complaining about your application before even using it. That’s like giving yourself a disadvantage.

Next up after deployment is maintenance. Same goes here. Use standard mechanisms. Provide a complete installer package which removes (sets aside) the old installation and replaces it with the latest one. You already have that installer in your build, so why not take this single extra step. By automating things you get to keep control. For Rich Clients, use the provided mechanisms like Eclipse update sites or Webstart for Java Rich Clients. It might be a bit harder to get into yet another framework, but it pays off. What would be easier then having the end user Clients update themselves? How do you think an end-user feels when you are able to update their app without any pain? They think: “Wow, they really did a pro job.” They even get some time to get a cup of coffee.

So in the end, I don’t feel there is all that much difference between deploying and maintaining a Web 2.0 or Rich Client. If you’ve got another opinion, please, post a comment. Discussion and other views are a good thing.

To center one control on a view we actually added 3 extra empty composites to push things to the right spot. This got to be easier to do.

Suggestions are very welcome.

Just import this project set into your Eclipse install and you are ready to go. You will be asked for CVS credentials. Just enter anonymous as a user-name and leave the password field blank or enter your email address.

Now you’ve got a sweet little application to molest to your hearth’s content. Complex enough to feel real, but small enough to get into in a short time-span.

Compared to previous Eclipse OSX releases Eclipse seems a lot more polished now. Sure there are some gripes, like scroll-bars appearing in the description field of the new project wizard. But it is getting better and better. Guess I will be doing some Wayne Beaton inspired evangelising on my current project next week. (Basically this would mean raising my hands into the air, exclaim why I think Eclipse is best, then kindly respond to all questions being asked. I won’t go swimming in a frozen lake though.)

I have been goofing around a bit last night, I smacked together some user interfaces with VE. Which is also part of the Callisto release. It seems to work ok, but still it doesn’t have the flexibility of rolling the views yourself. I’m not sure yet if I really like Visual Editor, but the rest of Callisto: Awesome!

Take a look over here for his response.

It’s about ways to properly architect an Eclipse RCP application.

Simple: Hack to span an Eclipse RCP screen accross more than one monitor. Don’t ask me why, it wasn’t my idea. I’ve just seen this in code somewhere.

Here’s how it works:

Mess up the Window.getInitialSize() so it takes all your screen real estate into acount, you’ve got two displays 1200 pixels wide? Ok, then we make the initial size’s width 2400. Don’t forget to mutilate alter the Window.constrainShellSize() method accordingly, else Eclipse will act up a bit. (How naughty.)

Now comes the best part. make sure you filter any occurences of SWT.RESIZE when Window.setShellStyle(int newShellStyle) gets called. Yes I said filter. Imagine some gullable developer passing by who thinks restricting window resizing is an excelent end-user screw.

Did I mention that all this was achieved by some aspectj crosscutting??

In the end, it works, sort of. Maximizing is disabled and resizing is disabled. So you end up with a huge piece of crap window plastered all over your screen real estate. You see, users are just dumb people. Letting them decide how to set their window sizes can only result in trouble. Well, atleast that seems to be the idea.

I hope you all got the point that I think the above is an “excellent” idea. (No, ofcourse I don’t think the above is a good idea.)

Credits to Wayne Beaton’s blog entry for mentioning this excellent news. I wouldn’t have known otherwise. It seems that it is useful to put in radar reports when you come across something ugly in OSX. The Apple devs won’t prioritize an issue when few reports come in on it. So if sh#t hits the fan when devving an Apple app. Report!!

Now if someone could convince Mr. Beaton to actually get a Mac, that would be great. Perhaps some of his Eclipse enthousiasm will rubb onto his Apple system usage. Eclipse is great, but Eclipse on a Mac, is even better. (Because even an Eclipse/SWT UI remains butt ugly on Windows.)

Anyway, I’ll be doing all kinds og GUI related work based on Eclipse 3.0.1 RCP (Rich Client Platform). Never done that before… This will look good on my resume.