Results tagged “Software Development”

I already explained that I use Bit Angle Modulation (BAM) in contrast to Pulse Width Modulation (PWM) in the logic which controls the brightness of individual LEDs in my LED Cube. During the implementation of the brightness routines in my source I realized that it worked pretty as expected at high refresh frequencies but I got very weird results for lower refresh rates.

Especially if I set the brightness to 50% (decimal 128) the LED had a clearly visible on/off-pattern of 4Hz in when running the cube at 1kHz. The explaination of this is pretty straigtforward: when the brightness is 128, standard BAM causes the LED to be active 50% of a full 256-cycle. 1kHz has ~4 full cycles and therefore the LED turns on and off ~4 times/sec.

Wouldn't it make more sense to have the LED alternate on each refresh, so that the average brightness is still 50% but the LED turns on and off with a period of two refreshes instead of 256? Similar to PWM but without the requirement for very high modulation rates?

My overall solution to tackle this issue was to add a simple counter which is increased with each refresh. When it reaches its maximum at 256 it's reset to 0 again. I use this counter to look up a bit-value in a table, which results in the bit to check for in the brightness value in each cycle. I then use this bit to AND it to every single brightness value of each LED and if it's non-zero the LED is turned on for this refresh. The initial values for this lookup table indicate the bit-values and resulting on-time for each bit of the brightness value. See the original code here. Of course this version still suffers from the problem described above, if the value is 50% the LED is on for the last 128 cycles of the 256-cycle period which leads to a slow and visible on/off blinking effect at low refresh rates.

The remedy for this is simple though, as the check-values are already in a lookup table. Just distribute the check-values much more evenly in the table and split up the connected on-time for each BAM-bit across the 256-cycle period. The resulting table is this. In this table every bit-value is strictly evenly distributed and spaced relative to each other so that the same values always have the same period.

The result of this change, which involved the usage of some LibreOffice Calc trickery, now allows for much smoother brightness control at much lower frequencies. Though there are limits to this. If the brightness is 1, it will still cause a visible 4Hz blinking at 1kHz refresh rate of the cube. There's no way around this besides limiting the minimum refresh rate to higher values. But in contrast to expensive PWM and unmodified BAM modulation, this variant should reach a relatively regular ~32Hz flickering already at a brightness as low as 8 (~3%).

So in pseudocode the looping and brightness algorithm for the LEDs works as following:

int counter = 0;
int bamBit = 0;

while (true) {
  // calculate if each LED is on or off during this refresh
  bamBit = getBamBit(counter); // get current BAM bit from lookup table
  for(int layer=0; layer<COUNT_LAYERS; ++layer)
    for(int x=0; x<COUNT_X; ++x)
      for(int y=0; y=COUNT_Y; ++y)
        ledsActive[x][y][layer]  = ledBrightness[x][y][layer] & bamBit;

  // display this refresh

  // reset counter at end of whole modulation period
  if(counter > 255)
    counter = 0;

Update: I'm not sure if this really works in practice as it should in theory. Until today I've used a not perfectly even distributed version of the lookup table (see this version) which I smacked together by just mixing up the values in a much simpler way (splitting the blocks and putting them together in a more distributed fashion) which was much quicker to come up with. Nevertheless I have the impression that the flickering has not smoothened at lower refresh rates and brightnesses as expected. I'll have to look into that sometime in the future again and make a better comparison of both versions. But yet it's still much better than the unmodified BAM brightness algorithm.


Just a quick status update on the progress of the cube since my last post.

On the hardware side there has been activity on two different topics. At first I had the opportunity to analyze my circuit and try to find out what's causing the ghosting effect at higher framerates using a friends oscilloscope. This involved getting comfortable with the usage and application of an oscilloscope in general and then trying to find out the different effects of different measurements and several different wiring variants of the transistors on the board.

From LED Cube Images
From LED Cube Images

This took a good part of a Saturdays afternoon and in the end I was pretty confident that the cause of my problem is that the base of the PNP transistor is not recovering fast enough to the blocking voltage as the IC leaves the pin floating after disconnecting it from GND. Attempts to remedy this with pull-up resistors allowed me to increase the refresh rate of the cube about 10x up to ~1kHz without noticeable ghosting but that's not really sufficient for my taste. My target is to allow up to 50kHz refresh rate on the 3x3x3 cube without noticeable afterglow of the LEDs. On the internet I found several topics where similar problems are discussed and all of them seem to have a common solution: add a Schottky diode to bring up the base voltage level faster. I had no schottky readily available so I unsoldered one from an old PC motherboard and used it to cover one of the three LED layers on the breadboard. Results are promising so far, I hope this still works when all three layers are equiped with a schottky. For now I think I can manage to work with lower cube refresh-rates until I'm able to pick up correctly dimensioned schottkys for all three layers. Until then this will be the situation on a single transistor at 5kHz (Yellow: base current; Green: collector current):

From LED Cube Images

Update: Short explaination to this graph. It was measured by hooking the oscilloscope to the base and collector of one layer PNP transistor. Pull-Ups are in place. Clearly visible (by the "knobs") are the layer switches causing some disturbance each time. When the layer gets activated the transistor instantly switches to conducting mode. But when it is disconnected again, it requires about half of the next layers visible time (~2us) to completely go into non-conducting state again. The faster the refresh-rate the longer the afterglow in each layer...

The last few days I've also been tingerking and thinking of how I could build the cube skelleton. I found no practical way to solder the LEDs together in a stable manner without adding additional wire. So yesterday I purchased a bit of iron wire and tried to solder the first layer. I drilled a few holes in a wooden plate, put the LEDs in it and soldered the LED pins together where possible.

From LED Cube Images

Next I prepared the iron wire, straightened it, cut out the parts...

From LED Cube Images

... prepared them for being soldered together with the LEDs to build the first layer...

From Building LED Cube

... and failed miserably, because the solder did not stick to the iron wire

From Building LED Cube

And I have absolutely no idea currently, what went wrong. Obviously another gap in soldering knowledge which I have to close when I want my next attempt for creating the LED grid to be successful.

At least on the software side there has been much more progress and success. I created a Github project for the LED cube driver software and improved and refactored the whole code several times now. So far I'm pretty confident that I created a quite flexible architecture and codebase so that it should be scalable for the 8x8x8 cube with minimal effort. Furthermore the animation framework is pretty stable and capable enough that I was able to create a new animation from scratch (one where you can move the bright LED using the cursor keys) within ten minutes. Each animation is encapsulated in a single class and completely independent from the cubes real refresh-rate. Notable features of my code which are finished (for now):

  • smooth BAM (Bit Angle Modulation) for controlling the brightness of single LEDs
  • console status output and ...
  • ... keyboard control for the animations, I/O via ncurses library
  • flexible animation architecture, independent from cube refresh rate
  • stable timing framework for controlling animation and cube refresh rates
  • a small set of prototype animations (whole cube pulsating, a single linear moving light, single random LEDs pulsating, a keyboard-controllable light)

This is my long promised posting about my experiences with Eclipse Mylyn. It took quite some time because I did not stick to it all the time but somehow fell back to my old development-habbits where everything and much more was visible on the screen. Maybe this is caused by the always-changing project situation or changing technologies but I cannot completely blame it to that. Nevertheless, let's focus on my experiences :)

Mylyn works by hiding everything from your visual workspace which is not connected to your current task at hand. This means, you only see the files in the Package Explorer and all other many views which were touched during your current task. This also means that you have to create tasks for your work in the Task List, which is a good idea anyway. The Mylyn-filtering is activated in the moment when you click on the small circle next to such a task in the Task List. If you have worked before on that task, your previous state of the workplace (which is called Context here) gets restored, like the open files, the touched methods and landmarks. If this is a fresh task, you're presented with empty views all around. From here you then can open your initial file to work on either by using the "Open Resource" shortcut or by ALT-clicking into the Package explorer, where the hidden files are displayed then.

From that initial file on you just navigate through the structures and methods with your usual Eclipse navigation (F3, STRG-click, or whatever) and Mylyn takes care to just display and highlight the necessary information for your work. It even cleans up the stuff and removes old and never-again places if you didn't came back to them for a longer time. The same thing applies to all content-assists like the method-overview or all of the Find-shortcuts where the list gets two-parted with your context-relevant results at the top and only the remaining hits after a separator.

You can also mark certain methods or files as "Landmarks" which are then displayed in bold text in your Outline or Package Explorer. This is especially handy if you're hunting a bug and found important places you want to remember or where you nailed down the cause but will fix it at a later time.

I also tried to connect my Mylyn Task List with a local installation of Bugzilla to better manage my tasks and make them available even outside of my own workspace. This worked quite good. It's also possible to attach the Context to each task if you're working with an external task repository. This would allow other people on the same repository to open the Context in the same state as it was when you last saved it to the task repo. Easy moving tasks from one person to another :) But we didn't come around to test this, as I've been the only one to work with Mylyn longer than just for a short tryout.

All in all I can say that if you get used to the way how Mylyn hides everything unnecessary from your display and how it presents the important information, the speed of development really goes up and the amount of distraction minimizes. But to get to that point you have to really work through the initial get-used phase which can be somewhat confusing and make you switch back to the previous development-mode where everything is displayed. I also fell into this a few times. But if you stick to it, you'll soon get the benefit of being able to focus!

If you also want to try it out or are just curious how it feels to work with it, take a few minutes and watch the Eclipse Mylyn 3.0 webcast video and read through the Mylyn 2.0 Tutorial (still applies 100% even if it's been written for 2.0) how to get started, you won't regret it!


Last time I've been posting about how you can increase your java development speed by knowing and using common and handy keyboard shortcuts. This time I'll be showing you some plugins which I have used over the time. For most of them I can say that they not so much speed up development but instead raise the quality of your sourcecode by giving you hints or adding certain aspects to testing.

So let's dive in.

Subclipse and Subversive are with high probability the most-installed plugins for distributed development and source code versioning. As Eclipse still does not provide builtin functionality for this (because of some licensing issue), these plugins add the required connectors so that it becomes possible to synchronize your source with a SVN server. Both plugins provide everything needed for most of the SVN tasks and differ just in edge cases or the handling and UI details. I'm personally using Subversive for years now because it has a Checkout-Wizard with more functionality than Subclipse offers but that plugin also has evolved since I checked it the last time. I should give it a try again in the near future.

The JD-Eclipse plugin is a decomplier addon for Eclipse which helps you out if you happen to stumble into Java bytecode eg. during debugging or when you follow references into external libraries. It reconstructs the Java source from the compiled code, so what you get is not the real sourcecode but something which resembles exactly the same function. Nevertheless it's often interesting how the code behind the APIs works you're using. Or, if you're depending on other projects which are currently just closed in your workspace.

Findbugs is a static source-code-analysis tool which checks your sourcecode for common mistakes optimization potential. It covers a very wide range of different bug types and each found bug or issue in your sourcecode has a small description added. Of course, since it's a statical analysis this tool is unable to analyze the whole logic in your sourcecode and therefore may also generate false positives, so be sure to not blindly follow each suggestion. But it's usefulness in general is undeniable.

Also a static analysis is done by Checkstyle but this one focusses less on programming errors but more on the layout of the code and the correctness of the documentation. For example if your javadoc for a method is missing a new parameter which you just added, Checkstyle would highlight this mismatch for you. It has an extensive ruleset so don't be surprised if it makes annotations all over your code if you check it for the first time.

EclEmma and Coverlipse are two plugins which deal with identifying the runtime coverage of your code. They add measuring instruments which allow you to determine which parts of your code are reached by eg. unittests and which parts of your code are still untested and need additional attention. EclEmma is the simpler one of the two but also is faster to get started with. Coverlipse on the other side needs a bit more work to get started but allows deeper inspection and offers a wider range of statistics and visualizations of the covered and uncovered code.

Another tool to aid with testing is Infinitest. It analyzes your JUnit tests and runs them silently in the background after each change in your sourcecode. It adds some intelligence so that only those tests are run which could be influenced by your changes. Furthermore errors in the tests are directly displayed as source-errors in your sourcecode. Of couse, this is only useful if your testcases can be executed fast and do not need an extended time to execute. The plugin has moved from the free Google-Code project to a commercial website but as far as I can see, the plugin itself is for now still available without cost.

If you want to quickly set up a shared task repository for your small team without having to set up a full blown Bugzilla, maybe even with a touch of Scrum, Scrum Vision may be the tool for you. It connects the task management of Eclipse (Mylyn) with a Google spreadsheet which also can be shared with other instances of Eclipse for other developers. The IDE aligns with the Scrum methodology to support agile development. This alignment also propagates in the spreadsheet where you can display reports and have a virtual taskboard and also a Burndown Graph.

If you'd like to close editor tabs the same way as you do in Firefox, by middle-clicking the tab, the Middle Click Closes Tab plugin (although last updated for Eclipse 3.3, it still works with Galileo) enhances your Eclipse with this feature.

As for Mylyn, which is already completely integrated in Eclpse: Since my last post according Mylyn I collected some additional experience with Mylyn. I also connected it to a local instance of Bugzilla to play a bit around with its integration and how it deals with sharing files and context. But I also think that I should use it more again, as I've become a bit lazy with it and fallen back to the previous everything-on-the-screen overloaded development. The promised blog post which hasn't been posted until now is still on my list for the future, when I know even more about Mylyn. But I already can suggest Mylyn as a tool to leverage the development effectivity by helping the developer to focus on the actual task at hand. If you're curious, have a look at the excellent Mylyn 3.0 webcast to get started.

That's it for now. I hope, there is also something useful in this post which is helpful for your Java development with Eclipse.


Since I've started developing Java in Eclipse I have realized that this is in no way different than with most other IDEs: the speed of development highly depends on the knowledge and intuitive usage of keyboard shortcuts.

Occassionally I'm asked to slow down a bit so that one can follow my actions or to tell which shortcut I've just used. For this reason I'm making this small list of those shortcuts which I'm using pretty much all the time.

I've tested these shortcuts specifically on Eclipse Galileo (3.5.1) and on Windows but most of them are also already present on earlier versions of Eclipse. As for other platforms I don't really know if all of them (or even any one of it) are available (or at the same combination). Furthermore many of them should also be present when developing different programming languages than Java but I cannot confirm that. You just have to find out yourself. Just in case you do, please let me know in the comments :)

So without further ado:

Shortcut Function Description
CTRL+SHIFT+ROpen Resourcebrings up a dialog where you can quickly locate any file or resource in your workspace. Wildcards are supported in the search.
CTRL+SHIFT+OOrganize Importscleans up the imports-block at the beginning of the file. Adds missing imports (if neccessary) and removes unused ones.
CTRL+SHIFT+FFormatapplies proper formatting to the source code according to the style-settings in the *Java->Code Style->Formatter* preferences.
ALT+UP/DOWNShiftmoves the current line or selection up or down one line. Very useful for fast relocation of code, much faster than cut/paste if just moving a few lines.
CTRL+ALT+UP/DOWNDuplicateduplicates the current line or selection above or below the current line/selection. Allows the fast population of cases in switch/case statements if they differ just marginally or similar situations like variable-initializer blocks. Beware, that this shortcut is often also overridden by some Intel display drivers. If this one does not work for you, try to turn off or change the hotkey assignment in your display driver helper application.
CTRL+OQuick Outlnebrings up a small dialog which allows to search and navigate the outline of the current file. Just start typing to narrow down the results. Supports wildcards. Pressing CTRL-O again toggles the display of inherited methods.
CTRL+PGUP/PGDOWNSwitch Tabchanges to the next/previous editor-tab.
ALT+SHIFT+LExtract Local VariableCreates a local variable from the currently selected expression. Types are automatically added. Try it on the code 'new HashMap();' to understand how this can speed up your development. Works on variables, static strings, methods with return values, etc.
ALT+SHIFT+IInline Variableopposite of local variable extractions. Replaces all occurences of the currently selected variable with its assigned value. Only works if the value of the variable is set exactly once.
CTRL+ALT+HCall Hirarchyshows all calls/usages of the currently highligted variable/interface/class/method.
F3Open DeclarationJumps to the declaration of the currently highlighted variable/interface/class/method. Similar to holding down CTRL and clicking with the mouse on a variable/interface/class/method.
CTRL+SHIFT+LShow Key AssistDisplays a popup which displays currently assigned keyboard shortcuts. Very useful if you are looking for further shortcuts quickly. A shortcut for shortcuts ;)

There are many more shortcuts available, including the marking and navigation shortcuts which you should know from Microsoft Word, but the above ones are the ones which became ingrained in me and are now speeding up my Java development enormously. Try to get used to them and use them whenever you can and you'll realize that there will be fewer and shorter interruptions to your stream of thought and it also aids your concentration.

If you want to go a tad further and let Eclipse tell you about possible shortcuts (or even force you to use one by cancelling all mouse-events which have a shortcut) you can install the MouseFeed Eclipse Plugin which does exactly this by displaying a small shortcut reminder each time you issue a shortcutted command with the mouse. Although it's a plugin for Eclipse 3.3, it still works with Galileo.

| | Comments (1)

Almost exactly a year ago I joined the developers community on Stack Overflow. Shortly afterwards I posted my opinions on the Stack Overflow system. Today I'm still a relatively regular contributing member on the site and so far I've already earned a batch of badges and I'm approaching 3000 points, where I'll be able to vote on closure or reopening of questions.

Today I still think that the Stack Overflow system is a good one for giving and receiving immediate help on various topics. In my opinion the quality of the answers has improved over the time on common questions as did the response time which is often within the single-digit minute range. You have to have a very, very special problem to not receive a usable answer within a reasonable timeframe.

I'd still recommend this site for all software developers of all experience levels if they're stuck on a problem for a longer time. Most of the time there are people there which already have had the same problem and found a better solution long ago. Take advantage of others knowledge. I personally just enter the site from time to time and look at interesting questions where I already know the answer myself to check back if there are better solutions or different aproaches have worked for others. And just out of curiousity...


I just read the article from Joel Spolsky "The Duct Tape Programmer". I know, the article is already a bit dated but for some reason I didn't come to it earlier. I'd suggest to read the article before reading on here but for the curious ones: "duct tape programmers" are a type of software developers who don't care about mighty frameworks and nifty language features but just hack the code down and get it shipped.

I have to admit that initially my first reaction to that article was that it was complete nonsense and suggested plain crazy stuff. But then I reminded myself that it had been written by Joel Spolsky, a person with a lot of experience who usually writes quite clever and well thought out articles using his knowledge of software development as well as management.

So I reconsidered my initial judgment, read the article again (and even one time more) and tried to have a look at these statements from different angles.

From a modern point of view it looks quite disturbing if someone decides to just crunch code and forget about modularity, fancy stuff like inheritance or clever frameworks and even skip everything near the area of testing your code. It just seems insane to reinvent the wheel or cripple yourself and don't even check the sanity of the outcome. Like a lemming on its march to the cliff.

But then lets look at it from the markets view: customers don't always buy the best products. They buy the stuff which can fulfill their needs. They're willing to live with some rough edges and can also learn to live with restarting the application every now and then and that's why they often just buy the first thing that's available. And if this first thing is not YOURS but your competitors, you'll have a hard time to regain this marked advantage. So just get the damn thing to the customer as early as possible. For many businesses this is the key to keep them alive. And duct tape programmers are what you need to accomplish this as they don't waste much time with bringing in another framework and reworking lots of code but just use their brainpower to get the stuff done. And they're capable of doing it.

On the other side customers tend to get annoyed with your application if it's already out in the market for some time and there is still no update available to smoothen some of the little buggers. Customers are used to upgrade stuff these days every now and then. Now is the time for polishing a bit, take aside some resources, gather the complaints from the customers and do some analysis of the most critical usage scenarios for your application. Now fix the bugs and add tests. That's the time when your defensive developers are in demand. At this time you can invest a bit and solder out the holes and make it maintainable for others but the initial writer of the code. But don't forget to keep your product still up-to-date and a tad ahead of your opponents or you'll hear the roaring sound of them overtaking you on the market faster than you may expect.

I have to agree that this balance between innovation and stabilization is not that easy to find but it's essential to do so and satisfy your customers so you can keep your business running.

My personal conclusion on this topic is, that it's maybe a good thing to have developers of both camps. If you're under business constraints duct tape programmers help you to get the stuff out of the door, but to make it sustainable on the long run for the hard market you need defensive developers to keep the product stable and maintainable. But you also have to take care on this effort and don't spend too much resources on stabilizing or polishing and let your competitors whoosh past.

Still, one hard to tackle problem I can immediately think of is the everlasting conflict situation between the academic developers and the duct tape MacGyvers but that's a bit out of the scope for this posting :)


This Sprint was an unusual one for our team. Firstly most of our team is on vacation and furthermore we're dealing with a project in an area where we have never worked before. Luckilly the project manager for this new project is very helpful and gave us enough assistance that we could handle the planned parts for the project better than we thought.

As of now there should only be minor work left for tomorrow and we expect to be finished with it by tomorrow afternoon which is much better than all our expectations. So today we began with estimation meetings to add some additional work to the current sprint. This is not exactly following Scrum but fits our business needs, boosts our sprint productivity and just does make sense.

I do not know where this excellent productivity originates. One possibility could be that we just overestimated the upcoming work at Sprint-start because we never did something in that direction. Or it could be because the project manager prepared and helped us much more than any other in the past. Admittedly he's much more into the technical stuff then our other project managers. Or it could just be coincidence.

Nevertheless. In my opinion in this sprint I've been much more productive compared to many of the past sprints, except the ones where I've been assigned to another team. I personally think that the reason for my improved performance is that I and a colleague did quite strong and effective Pair Programming. We did that at my computers where my setup allowed us to work on a single screen and computer using two keyboards and mouses. It enabled us to instantly switch the active/passive roles if needed every few seconds. I haven't been that concentrated for quite some time. Also I think if you work together it's the same thing as in sports where you motivate each other.

What I also changed this sprint is that I tried to manage the tasks I take over with Eclise Mylyn. When I started with it it was not very comfortable but after some time, I think one or two days, I got used to it and development became more fluent and I was able to better focus to the task at hand. What helped me with the start was reading some introductory literature like the Mylyn 2.0 Tutorial (still highly relevant even if Mylyn is already at version 3.2) and watching the Mylyn 3.0 video presentation by Mik Kersten. My experiences with Mylyn will be content of another posting some time in the future. Just two things I think which are very important: Create mylyn tasks for issues or other workable topics as soon as they cross your mind and try to keep them focussed and small, maybe so that they can be done in not more than two to three hours. You can group them to larger tasks later.

I'm very curious how the feedback after this sprint from the project managers and development leaders will be and also from the other members of my team. I also hope, that we can maintain a bit of the effectivity from this sprint in the future.


In the last few weeks I've got the chance to look into the sourcecode in a lot of different modules of the product our department is working on. The more code I had a look at the more a certain insight was forming in my head. What I saw when I looked at the different parts of the sourcecode from a lot of different people is, that it's cruical for the maintainability of code to know the advantages and possibilities of the frameworks you're working with. Otherwise you're going to reinvent the wheel over and over again. And I recognized many different wheels in this code.

We're working with Java here and among our used frameworks is also the Apache Commons. It's a framework which greatly eases the solving of common problems every Java developer faces every day. To give examples I'll focus on working with collections here. The Java framework itself has already some convenience methods available when working with Collection classes in the their generic interface classes (like Collection, List, Set or Map) but the Commons Collections Classes provides further methods which cover many day-to-day operations with their xyzUtil classes (see CollectionUtils or ListUtils for examples).

A lot of the operations I came across in our code deal with creation and manipulation of different collections, transforming from/to arrays, intersecting or summing them and so on. Lots of loops and different ways to solve always-repeating problems. With the utility-classes and methods from the frameworks we're using a lot of these sourcecode-parts can be reduced and simplified from up to a few dozend lines to just a few ones or in a lot of cases even a single line.

Not only does this reduction aid the readability and comprehensibility of the code it also makes it more robust as most of the framework-methods are already for example null-safe and thus take the burden of null-checks from the developer. And less code is easier maintainable than endless pages of difficult logic. Of course, the usage of frameworks also requires the developers who get at it later on to have at least a little knowledge of these but the invested time to get familiar with the framework almost always pays off manifold.

PS: Another extremely useful utility class in the Apache Commons is the StringUtils class. Just have a look at the impressive convenience methods in its interface and I bet there are many methods in there which you immediately could use at some places of your code.


As I've just recognized I've forgotten to write a notice here that we've bought a Logitech Harmony 785 programmable remote control.
This thing is quite interesting and fun to play around with, but it's also not so easy to configure as the standard off-the-shelf remote. The only thing is, that the configuration software on the PC is on the one hand not very intuitive and on the other hand... slow... as... hell...

Well at least I can offer a solution against the slowness.

The problem with the Logitech Harmony software seems to be, that Logitech bundles it with an older version of the Java Runtime environment. Something like Java 1.5 or so.
To speed up the software yourself you need a recent Java JRE installed on your computer somewhere, with at least a version equal or greater than JRE 6.
The following procedure is:

  1. Navigate to the installation directory of Logitech Harmony (something like "C:\Program Files\Logitech\Logitech Harmony Remote Software 7")
  2. go into the "jre" subdirectory and delete everything there (or back it up somewhere)
  3. next locate the JRE directory of Java (something like "C:\Program Files\Java\jre6")
  4. copy the "bin" and "lib" subdirectories of the Java JRE 6 directory to the Logitech "jre" directory
  5. finished

When you start up your Logitech Harmony software now, it should feel smother and react faster. I don't know exactly why this works but I suspect that the JRE of Java 6 is more advanced and faster in the areas which are used by the Harmony software than the JRE 5 which comes bundled with the software itself.

This is a relatively easy modification to do but if you're changing the configuration of your remote often, this can be something which helps you to make your changes faster.


Ever had to work with regular expressions and cursed the one who invented this crazy stuff? Well, I had to, and if I had knowledge of The RegEx-Coach at that time, it wouldn't have been such a pain in the a**.

With this tool you can try and evaluate every possible regular expression with every string and follow the evaluation in real time.


Well, last week didn't bring many news: Tuesday I had a talk with my "performance manager" (why do all American companies have such silly titles?) about the goals I've reached in the last year personally and in my job and made up new goals for the future. For the past I think I've met the expectations but my PM thinks I've exceeded them. :) (Not too hard, if I'm the last remaining real developer in my team) For the future I've told him that I'd like it if I could get in touch with developers from our partner-companies and work on cross-company-projects.

Anyone out there who likes to work on a carrier-grade telephone-solution with me?

Anyway, the rest of the week was not that interesting, I've been still trying to optimize our system for SMP environment (AIX, Solaris) in a cross-platform manner. Still too much slowdown on massive parallel access if same heap is used for all threads (possibly false sharing?). Also began organizing the next iteration meeting which was initially set on Thursday but moved to next Monday...


Been on spontaneous vacation for a few days. And being back I had to arrange an 'Iteration meeting'. (Ya know XP?) I think it was not that bad for my first time, perhaps I also have to manage the next one in two weeks.

Ever wanted to throw away all your old code and write it from scratch because it sucks? Don't do it...