By Michael Meeks: Interacting with new Developers …
Four pages of wisdom.
By Michael Meeks: Interacting with new Developers …
Four pages of wisdom.
I’ve been developing web applications for the past few years. Recently, we evaluated many of the web frameworks out there to select one for the next major release of our product.
Wicket was quickly dropped from the list. It’s a nice framework but it lacks one important feature: A library of reusable, cross browser components. Yeah, there are a couple but they are all very basic and building complex UIs with Wicket is done in HTML and that’s just painful.
Roo is too slow and immature and suffers from the same problems as Wicket. Maintaining cross-browser compatibility for a complex web application is something that a small team of developers can’t do anymore today.
GWT was dropped because Vaadin is based on it.
That left Vaadin and ZK.
ZK has a big set of well designed components with a huge documentation how to tweak them. The docs explain in detail how the components are built from HTML elements, which CSS styles are used and how you can override them. There is even a visual CSS editor that helps doing this.
When working with ZK, you often run into situations where something doesn’t work but so far, I’ve found a good solution within a short time. This might also be possible with Vaadin but it didn’t happen for me.
There are a lot of powerful layouts to arrange your UIs. You can cleanly mix ZUL (the UI descriptions) with Java code to get the best from both worlds: A clean UI description and compact code to attach listeners, publish events and connect components.
Also, ZK hides the request cycle. This is one of the biggest source of problems with developers. Yeah, the request/response cycle makes it easier to write web browsers and server frameworks but it’s a major pain for application developers. With ZK, you’re writing code that looks like a desktop application. It’s a bit like GWT in this respect but GWT feels … “proprietary”. In ZK, a lot of the API is public. In GWT, a lot of the API is hidden away in final static factory methods buried in calls between 50 classes.
ZK does have its share of problems, too. Testing is a weak point. Selenium probably works well enough for mouse-driven apps but if you have components which can be controlled by keyboard alone, Selenium doesn’t cut.
The documentation on the web site could be better; for beginners, it’s especially confusing that the documentation for ZK3 and ZK5 is hard to tell apart.
But all in all, I’ve been faster to solve any problem I’ve had so far with ZK than with any other web framework.
If you have the source for the dependency, patching the code is simple: Just create a small Maven project that compiles the source with your changes. Since your changes are probably small, you need only a few tests: What’s the point to test the code that you didn’t touch? Also the build will be simple (just compile the sources for your need, no fancy resource processing/filtering).
But what if you don’t have the sources? Jakub Holý has a solution: Hacking A Maven Dependency with Javassist to Fix It
We understand our limitations. And we build around it. But for some reason when it comes to the mental world, when we design things like healthcare and retirement and stockmarkets, we somehow forget the idea that we are limited. I think that if we understood our cognitive limitations in the same way that we understand our physical limitations, even though they don’t stare us in the face in the same way, we could design a better world.
I think that is a very important point. Software development is a purely mental process. We take ideas, translate them into code. We’re authors, our audience is a CPU. We write in RAM chips instead of on paper. But basically, we’re translators.
Most software developers know their tools but not their own mental limits. Ask yourself: How much brain power does it take to type on a keyboard? Got your number?
It’s about 30%. When you type yourself, you only have 70% of your brain left to think what you’re typing.
Software development is a craft but it’s not like smithery. We had anvils and fire pits at my school. When you work with yellow-hot glowing steel, a five-pound hammer and an anvil, you learn something with your first strike: This is dangerous, this is hard work, this isn’t as simple as it looks, and how fast you’re going to tire.
How do you do that? Because your brain is wired by millions of years of evolution to know such things. Your muscles are designed to give you feedback: Can I outrun my enemy or do I have to make a stand? Forging steel is built into us. The result will vary with clumsiness but every person in my class was able to hit the steel with a hammer. It takes a day to teach someone to write the most simple program in Java but it takes one sentence to teach them how to flatten iron: “Take one of those hammers and hit it here.”
If driving steel is so simple, why are we so bad at software development?
Well, it’s one of those tasks where one brain tries to achieve two conflicting goals: Write software and at the same time watch itself doing it right. It’s a dilemma. You have 70% tops unless you have trouble at home, worry for your job, are hungry or mad at the guy next door yelling in his telephone. How much of the 70% are you going to give to “write software” and how much to “do it right”?
That said, being a software developer, you’re male (98% chance). Males suck at doing two things at a time and you’re already doing at least two. How much good is adding control to the pile going to do?
Probably not much. So what can you do?
First: Don’t forget that you’re limited. Clear your brain. Heed your limits.
Second: Turn your limits into a foundation. Instead of struggling with them, accept them. Use techniques like Test Driven Development to do one thing at a time: Tests answer the “do it right?” part. When you have the test, you can forget about this and go the “write software” part.
Use you limits. They are tools just like everything else.
Another great TED talk: Dan Ariely on our buggy moral code
In a nutshell: What makes people cheat more/less? Key points:
Usually, you can’t have too much memory in your PC but there is one exception: When you have lots but not enough.
That’s roughly 8GB in total which is the amount of real RAM I have installed.
The problem arises when the real memory is exceeded. I do have 8GB of swap but do you have any idea how long it takes to swap out 1-2GB of RAM to a harddisk?
When you have lots of RAM, you don’t think about starting something else which might need lots of memory like GIMP or a video editor or starting WebSphere. All of a sudden, your whole computer freezes and you think “WTF? Did it crash? What’s going on?”
A lot of RAM can be bad 🙂
Like many people, I have a strong opinion about justice. In this time and age, it feels like the legal system, invented to give justice to everyone has become part of the problem. Note that I’m not asking to abolish the legal system – but we should pay heed to abuse nonetheless and think how to prevent it.
WTF? Apparently, the tz database contains record from a book “The American Atlas” for which Astrolabe owns the copyright. So what they’re doing is perfectly legal.
But it smells.