Some time ago I did a presentation on what the Java Virtual Machine (and to a much lesser extent the Java compiler) do automatically to optimize your code, thus sparing us the hassle (and the resulting ugly code) to do it ourselves. This is intended to be a series looking at what’s done automatically and how this will, can or should affect our coding habits. The first part will have a look at some really old advice from the time, when Java was truly slow. This means the late 1990s when Java was interpreted at runtime and didn’t sport a JIT-Compiler (which was added in J2SE 1.2 (Codename Playground) in December 1998) or even the HotSpot VM (which was released in April 1999 and introduced into Java in J2SE 1.3 (Codename Kestrel) in May 2000).
I was finally able to track down the elusive bug mentioned in last month’s SOTP, where 1:n relationships weren’t displayed correctly after the model of the master component got changed. Since they weren’t updated along with the rest of the displayed data, I was hunting for the place where the model chain was broken. As the model chain was in fact unbroken, this search took me a couple of days but didn’t help at all. The reason why the data wasn’t displayed corretly was the fact that these relations were constructed with a wrong type of model provider and thus a properly chained but completely wrong model was used. Now it kind of works but this spot needs more work done before I’m happy with this.
As a lookout, Wicket-CRUDr will see a change of paradigm. Right now, everything you want scaffolded has to be annotated and everything you want to edit has to be annotated to. This will change so that every method on the wrapper starting with "get" or "is" will result in this property displayed unless annotated with @Ignore and likewise every method starting with "set" will result in this property beeing editable unless ignore-annotated.
Now, that the project is a little more than 7 months old and taking it slow due to other obligations, I’d like to offer a little summary on the current state of the project.
I’ve spent a couple of hours starting a demo application using Wicket-CRUDr to show and keep track of what the framework can do right now. This application is the current Proof of Concept for the project, so whenever I run into an issue, I stop working on the application and fix the framework instead. This is necessary since there is no such thing as a project plan or even QA beyond Unittests. Main issue right now is a bug where somewhere between a displayed object and the list it contains, the model-chain is broken so that the model of the list isn’t updated. Since the framework relies heavily on builders and factories this is quite hard to track (as usual when there are factories involved).
When I found this book at a 2nd hand bookstore, I didn’t really notice the subtitle and since I’m notoriously bad at negotiating, I bought it. Later at home I realized that it was “Eight Sales Strategies to Defend Your Price and Value”, which still might do me some good but starting through the pages my doubt increased as it is clearly addressed at Sales Reps. I decided to join the ride just to see how it turns out and it turned out quite entertaining but only if you’re a evil, black-hearted and nasty wretch like me.
This is the first part of a series I’m waiting to read as soon as it gets published. Most of the stuff isn’t really new but the writeup is nice. It just collects the telltale signs of jobs you just shouldn’t take like getting no coffee, having to wait very long, getting no office tour or seeing all the wrong stuff on the tour. Check the chairs, you’ll spend some time in them, as well as the screens, a second screen or large screens cost a fraction of your pay, so there’s no reason, a company shouldn’t have them. Additionally, the comments add some interesting details like checking the state of the employee restrooms…
On to the good stuff… here’s the link.
And the second part is published too: How to spot a terrible tech boss within SECONDS
It’s an article that’s quite old (as in 4 years right now) but holds true even today. Requiring X years of experience in some more or less arcane field or language wouldn’t do the trick. What separates the good developer from a mediocre one isn’t years of experience in a specific field but an insatiable hunger for new stuff and things to learn. It’s the love to sharpen one’s mind understanding new concepts and toys. A mediocre developer will be happy having mastered one specific task and tends to accumulate years of experience without ever pushing the barriers of his or her abilities where a good one would have tried to push back the boundaries of his or her knowledge at all times and thus have adopted new fields and languages. This doesn’t say he or she would constantly change jobs. A good employer for a good developer would allow (and even support and depend on) this hunger and offer sufficient legroom and breathing space within the organization.
You can’t have the cake and eat it. You can’t have a good developer with a sharp mind and expecting he or she was just sitting at one place for years.
Data Deduplication fascinates me, that’s a fact. As one of the three most interesting topics in the field of software development (with Neuronal Networks and Genetic Algorithms being the other two) it pops up in my head from time to time. When this happened again and I had some spare time, I found this article titled Rabin algorithm – the mother of deduplication technologies” over at the Infineta blog. It offers some basic insights on how Data Deduplication works even if it stays very firmly on the theoretical/mathematical side.