In the week after that, from 30th to July 3rd, I'll be in Israel, thanks to JFrog. This is my first visit to Israel, so I'm really excited. If there are any Hudson users there who'd like to meet up, please let me know, as I'm always interested in seeing different deployments of Hudson and learn from those. Or if you are interested in having me do a short on-site work, there won't be any travel cost, so this would be a good opportunity ;-)
Further down the road, I'll be speaking in JavaOne 2010. Historically we have a good number of Hudson committers/users in JavaOne, so we've been doing some get-together. I hope we can do it again, so please stay tuned as the details of the conference develops over the summer.
Despite all the report comprehension in Hudson, such as JUnit, PMD, FindBugs, etc., log files still hold a special place in terms of capturing what has really happened. Hudson does a bit of AJAX in this space to let you follow output as it comes, but the log is basically just a plain text that doesn't really have structures.
The other kind is more interesting, where we can place anchors (I call them 'notes') at arbitrary points during the output, and those notes can then in turn generate markups. This enables highly context sensitive markups, which I think has a lot of potential.
For example, I started putting a note for every Ant target that gets executed during the Ant execution. I can use this to generate outline for the console output, so that you can jump to the interesting targets, or move up/down to next target very quickly. For simple build scripts, I can let users click the target name and jump to its definition in the build script.
Another place I do this today is when Hudson reports an exception. I can make a stack trace foldable so as not to overwhelm users, and I can also hyperlink each stack trace element to its source file, as a way to encourage people to start hacking Hudson. Or if a build fails, I can present an UI that gives you actions that you might want to take --- 1. edit config, 2. rebuild, 3. report to the admin, etc.
With Maven, where Hudson puts a little spying agent inside the Maven process, I can do even better. For example, wouldn't it be nice if you can hide all the "[INFO]" message with one mouse click? How about a navigation from compilation failure reports to source files? Or if you have an outline of modules that were built and jump to them quickly?
If you are an user, this is just a sneak preview into what will come. If you are a plugin developer, think about all the things you might want to do with this mechanism!
I started working for Sun Microsystems since Janurary 2001, when I first came to the US. During these years I was able to work on many different projects, such as MSV, JAXB, JAX-WS, Metro, GlassFish v3, and Hudson, to name a few, with many great people. It was all quite an enjoyable journey. I won't list all those names one by one here, for it will be too long, but if you are one of them, I think you know that I'm talking about you. As my colleague Abhijit said once, a large part of enjoying your work is the people you work with.
So with a bit of sadness and a lot of excitements, I announce that today is my last day at Oracle.
Where am I heading next? I'm actually starting my own company to take Hudson to the next stage. This has always been in the back of my mind, and I'm very excited that I'm finally doing it. Stay tuned for more details, in a week or so. But in the mean time, if you'd like get any custom development/support done on Hudson, please let me know at firstname.lastname@example.org so that we can start having a conversation.
Even though I leave Oracle, I'll continue to lead the Hudson project. I'll be working with Oracle to transfer the infrastructure services to their IT operations team. There might be some out-of-schedule releases, service disruptions, and other inconveniences during this period, but hopefully things will be back in order relatively quickly.
And finally, big thank you to everyone in the Hudson community, and in a broader java.net community. I wouldn't be here without you guys, and I feel very proud that I'm a part of it. Thanks for your patronage to my projects, and I hope our relationship will continue.
Total of 9 people came and we had a great time talking about infrastructure issues, possible enhancements, design dicussions, exchanging tips and plugins that they've developed, and otherwise building personal relationships. It was a beautiful day outside, and fortunately the meeting room had a lot of Sun lights to create a warm atmosphere.
As for me, I didn't get much hacking done, but that's OK because my job there was to help others more than to get hacking done myself.
At work, I have two monitors hooked up to my workstation, which gives me about 4300x1600 combined screen real estate (one of them had to come out of my own pocket, but that's a separate story.) When I switched from a single monitor set up, my behavior changed a bit.
It used to be that I have most of the applications maximized, and used Alt+Tab to switch between them, most of the time. The screen wasn't big enough to run two apps side by side.
With multiple monitors, this is no longer the case. At least two, more often three applications are visible. Say a maximized IDE on the primary monitor, Gnome terminal on the left hand side of the second monitor, and Thunderbird on the right hand side of the second monitor. This arrangement lets me work on code while loking at the stack trace of an exception in a terminal, or a bug report in the e-mail, etc.
One of the pains I've been feeling is the lack of efficient way to switch window focus to different applications. And when I say "efficient", I mean by using keyboard, without reaching out to a mouse.
Let's say I'm typing an e-mail, and realized that I need to check code in IDE. For me to switch a focus, I have to first hit Alt+Tab, comprehend the list of windows that appears, then hit Alt+Tab a few more times until the right IDE window gets the focus. That's a lot of time and cognitive overhead.
So instead I developed a little script that lets me shift focus by relative directions from the current window. In the above scenario if the IDE is on the left of e-mail, I hit Win+Left, and I get the focus shifted to the left. Ditto for other arrow keys. This turns out to be much more efficient, as the spacial relationship between windows are easier to grasp and something you can see even all the time. I think this would also scale to even larger number of monitors, something which I'd love to have some time in the future.
The script uses a Ruby library that manipulates X windows underneath. It was originally developed by someone else I forgot, and I had since then started to maintain my own fork that fixes various problems. I then wrote more Ruby code that figures out which window is in the general up/down/left/right direction of the current window. This turns out to be a very interesting puzzle, as it has to cope with heuristics. In the current version, the script considers such things as visible regions of each window, their center of gravity, distance and angle from the current window, etc. Another fun part was to think about the algorithm to compute that efficiently, even though the benefit is largely theoretical and not practical, since no one opens 1000 windows. It currently takes O(N3) for the number of window N.
I think there's still some room for improvements, but I'm generally happy with the result. Beyond that, I think this library can be also used for doing all kinds of other Window manipulations that you may think of.
I use the Compiz commands plugin to kick off a script when a particular key combination is pressed. If you are using Linux/Solaris with multiple monitors, you should give it a try, too.