Today I attended the JFall 2008. Another instance of the conference of the NL-JUG aimed at all the Java programmers in Holland. Since two of my colleagues got the last two tickets I had the pleasure of walking to the location with only one of them, the other one missed his train.
Anyhow, let us see what the day has given us.
Duane Nickull was the first speaker of the day. He shared his view on what web2.0 and SOA was. We saw many slides (with many boxes and arrows) explaining which entities play a role in these types of technologies. Unfortunately, his presentation was a little abstract, because I didn't notice any concrete examples (maybe I missed them though). On the other hand, his anecdotes were nice and interesting. The one that I liked the most was about a company that is trying to apply the open-source software development way of contributions to the making of movies. Deciding what is in a movie sure sounds fun to me, so there should be some kind of business model in there right?
The second talk I attended was given by Allister Smith and was titled "pragmatic Java". Hoping on a presentation full of pragmatic solutions for common problems, I was a bit disappointed when the talk compared Java to languages such as Phyton and PHP. An example program was given in Python and then redone in Java using the spring-framework. Naturally, the Java example was much more bloated. After this, an example of a Java implementation was given in which the typing was essentially stripped away (by using only Objects) and value-passing was done through Maps and Lists. The speaker had a good point in the sense that this can be just as quick and short as a scripting language, but using Java for this just feels wrong. It is an example of using a language because of the language, not because it has the features you need for a project.
The last talk before the lunch was an introduction to the Java Memory Model. Peter Veentjer (who seems to know a lot about these things) gave a nice tour around some of the pitfalls of Java concurrency. Although the talk was a little low level, it was really understandable. I do not have to deal with concurrency at the moment, but some of the pointers are good to keep in the back of your mind during development. Certainly a useful presentation.
Right after the lunch the evangelists of Sun gave the second keynote of the day. Normally I do not really like these kind of talks because they can feel like you are watching a long tv-commercial without seeing something useful. However, I was pleasantly surprised that the demo's showed some really nice stuff (besides being slick of course). It turns out that in the new version of JavaFX it is possible to drag applets from your browser to your desktop and still work! There must be some real-world usage scenario's for that I guess. Also, a demo was given of alternative ways to use your Wii-mote. Definitely a better talk then I had expected.
After the demo I was quick enough to sneak into the presentation of Huub van Thienen about closures in Java. I was lucky to have a seat because the room was really packed with people. Huub gave a really nice introduction into what closures are, and how they could be used in Java. His presentation showed the pros and cons without giving away his own opinion. Actually, he even promised a candy-bar for the person that could guess his opinion about the subject. I still do not know :(. Even though I knew most of the thing already (because of knowing Haskell), I think this was the best presentation of today.
As a last presentation I attended a Hands-on-lab about dealing with legacy code. Since we are usually analyzing legacy code for customers, I thought it would be nice to hear other peoples opinions about the subject. The set-up of the lab was really nice, first some explanation, then some coding, some more explanation and so on. Unfortunately, we ran out of time in the end, but it was still a nice experience. I also relearned one of my pitfalls during the session. When trying to fix a bug I tend to first figure out how to fix a problem, than actually fix it, and later on write a test for it. Usually, I also try to run the test without the fix to see whether it fails, but sometimes I forget. To counter this I should first write a test, and then fix the problem. However, sometimes it is too tempting to just fix the problem :)
All and all it was an interesting day. No real eye-openers, but certainly not a complete waste of time. On to the JSpring I would say!
Focussing on the problem
After a solid month of being a part-time PhD I have gotten many tips (and comments) on kick-starting my project and doing research in general. Currently, my goal is getting a clear picture of the problem that I want to solve. I know that there is a problem (and I have a vague notion about how to describe it) but getting a clear definition is not something that comes easily.
On the other hand I am not afraid of spending time on finding the problem. When the problem is clear it is usually easy to think of scenario's that can solve it (although actually executing these scenario's might be tricky).
And focusing on getting the problem straight is also not bad for presentation purposes. Several of my colleagues (and other people as well) explained to me that during a presentation it is very important to explain the problem that you solve. Also, and this is something that I usually forget to think about, it is important to explain in which cases your solution is not going to work.
It does not matter that this might take up a big chunk of your time because most people probably do not (completely) understand your solution anyway. As long as they know which problem you have solved under which conditions, they are going to be happy. More details about how the solution works can always be read in a paper, or discussed over some beverages.
So, back to the literature study it is! By the way, if anybody has a nice suggestion to keep track of interesting research papers online, please let me know!
On the other hand I am not afraid of spending time on finding the problem. When the problem is clear it is usually easy to think of scenario's that can solve it (although actually executing these scenario's might be tricky).
And focusing on getting the problem straight is also not bad for presentation purposes. Several of my colleagues (and other people as well) explained to me that during a presentation it is very important to explain the problem that you solve. Also, and this is something that I usually forget to think about, it is important to explain in which cases your solution is not going to work.
It does not matter that this might take up a big chunk of your time because most people probably do not (completely) understand your solution anyway. As long as they know which problem you have solved under which conditions, they are going to be happy. More details about how the solution works can always be read in a paper, or discussed over some beverages.
So, back to the literature study it is! By the way, if anybody has a nice suggestion to keep track of interesting research papers online, please let me know!