Developer Tips

Profi-Tastatur für Entwickler: Das Swiss Developer Keyboard

by

Das Swiss Developer Keyboard ist eine speziell für Schweizer Programmierer und IT-Nerds entwickelte Tastatur. Keiner der großen Hersteller hatte eine gute mechanische Tastatur mit einem Schweizer Layout. Daher habe ich selbst eines kreiert, das ich der Schweizer Entwicklercommunity nicht vorenthalten möchte.

Sie können es gleich hier kaufen.

Das Keyboard ist so ausgelegt, dass Sie mit verschiedenen Betriebssystemen (MacOS / Windows / Linux) arbeiten können.

swissdevkeyboard

Weitere Funktionen, die ich hinzugefügt habe

Schweizer Layout

Da die meisten europäischen Sprachen einige zusätzliche Zeichen in ihrem Alphabet haben, sind die Tasten, die auf der US-Tastatur für Entwickler nützlich sind (Klammern, Schrägstriche usw.) mit diesen Sonderzeichen ersetzt. Die Zeichen, die wir wirklich ständig brauchen, sind daher nur über eine Kombination aus Shift und Alt Tasten erreichbar.

Es ist ziemlich schmerzhaft, so auf einer Schweizer Tastatur zu programmieren, und für eine Weile habe ich mein Layout auf Dvorak umgestellt.

Das funktionierte gut, solange ich in meinem Büro an meinem Computer saß. Aber beim ersten Besuch eines Kunden lief es spektakulär falsch ab. Ich konnte ihre Tastaturen nicht benutzen, so sehr war ich an das Dvorak-Layout gewöhnt. Nur schon ein Passwort einzugeben, das nicht auf dem Bildschirm angezeigt ist, wird zur Herausforderung.

Daher ist meine Empfehlung, sich an das Layout des jeweiligen Landes zu halten, damit Sie jede Tastatur beim Kunden vor Ort nutzen können.

Mac OS Mapping von “Entwickler-Charakteren” auf der Tastatur

Apple platziert seine Sonderzeichen an anderen Stellen als die Standard-PC-Tastatur. Normale Leute bemerken das nicht, aber Entwickler brauchen ständig ‘spezielle’ Zeichen – zum Beispiel \ oder { oder ~. Diese sind nicht auf der Apple Tastatur eingraviert. Meine Lösung war ein ein Spickzettel mit den Positionen dieser Zeichen.

Farbhilfe für korrektes Zehnfingersystem

Entwickler sind ständig am Tippen. Je schneller sie das Zehnfingersystem beherrschen, desto effizienter können sie kodieren. Nun gibt es einige Tasten, wo ich immer unsicher war, welchen Finger eigentlich der richtiger ist. Wird ‘B’ mit der rechten oder linken Hand getippt? Und was ist mit den Zahlentasten 1 und 2? Diese Tastatur benutzt einige Graustufen, um eine visuelle Hilfe für die korrekte Fingerstellung zu ermöglichen.

Zusätzliche Pfeile auf hjkl (hilft beim Benutzen vom Texteditor ‘vi’)

vi ist ein sehr alter, sehr schneller Texteditor und auf allen Unix / Linux-Servern universell vorhanden. Man navigiert mit den normalen Tasten zu verschiedenen Teilen des Textes, und hjkl sind die Tasten, die für die grundlegende Bewegung (einem Schritt) verwendet werden. Ich vergesse immer, welche Taste welche Richtung ist, also habe ich ein paar Pfeile auf diese Tasten gelegt.

Gute Ergonomie – kein Nummernblock

Es ist wichtig, Verletzungen am Handgelenk zu vermeiden – die Maus sollte so nah wie möglich an der Tastatur sein. Deshalb ist der Zahlenblock böse und Sie sollten auf jeden Fall Ihre Zahlen per Zehnfingersystem eingeben. Irgendwann denkt man nicht mehr drüber.

Funktionen, die vom Hersteller, WASD, bereitgestellt werden.

Diese Tastatur wird von WASD hergestellt, einem amerikanischen Hersteller hochwertiger Tastaturen nach Maß. Die zugrundeliegende Hardware ist die V2-Tastatur, die mit den folgenden Super-Features ausgestattet ist:

  • Sehr robust – es ist eine solide Tastatur
  • Schöne Cherry MX Schalter. Ich empfehle die klaren Schalter, wenn Sie etwas Ruhe brauchen, und die blauen Schalter, wenn Sie einen lauten Klick mögen (nicht gut für offene Büros)
  • DIP-Schalter, mit denen Sie die Tastatur auf der Hardware-Ebene ändern können. Meine Favoriten:
    • Umschalttaste auf Strg. Gibt Ihrem kleinen Finger viel Erleichterung!
    • Integrierte Funktionsbefehle Wenn Sie sich den Navigationsblock ansehen (Bild auf, Bild ab, usw.), sehen Sie, dass es eine Überlagerung für Wiedergabe / Pause, Lautstärke usw. gibt. Diese Tasten senden mit der Fn-Taste die tatsächlichen Hardware-Codes für Medien Steuerung.

Preis und Bestellung

Der Preis für die Tastatur beträgt ca. 200 USD (inkl. Versand in die Schweiz). Es ist nicht günstig, aber ein schönes, langlebiges Stück Hardware.

Sie können hier die Tastatur von WASD bestellen.

Why do Software Developers always squawk when inheriting a foreign codebase?

by

The first thing that Software Engineers do when they inherit a codebase that they haven’t written is to squawk loudly.

This is terrible! That’s not the way to do it! We need to re-write this completely!

I recently had an experience when a project manager suddenly lost his developer and asked me to take over. ‘Here is the list of requirements from the customer, they’re just small changes’.

I said ‘OK, I’ll give this a look, doesn’t look too difficult‘. And then I started looking into the code, and I started grumbling more and more. There were no comments. No source control. No test code. The code I had in front of me what not working correctly, and I had no access to a codebase which was working. And within the code, there were so many times when I was thinking ‘Oh no, why would you do that? I’d really do it differently’.

So I promptly squawked. And the project manager expressed his incredulity. ‘It’s always the same with developers! They always complain of code that they haven’t written themselves!’.

So, here’s a little guide to explain why this happens.

We’re not masons.

That’s the crux. The job of building walls is well defined, and if a wall is not complete, you can hire another mason to finish the job. He’ll come to the site and the tools that he sees are familiar and he can start right where the previous person stopped. Easy.

That’s not how it works with software. There is a wide range of ways you can solve something, the wider since we basically can write your own tools. Another persons’ building site is going to be completely unfamiliar.

So here are my insights for non-developers, in the hope that you will get over the impression that we are whiners, and understand that software development is not masonry.

Software is easier to write than to read.

After about six months, even the code you have written yourself becomes more difficult to read. A good developer will be writing his code not just well enough for the machine to understand (bad developers stop at that point), but well enough for humans to understand.

This is a pretty accurate picture of what it’s like reading other people’s code from somebody else:

http://i.imgur.com/UGv2WaB.png

Software can be really badly written, and you can’t see it from outside.

This rejoins the points I was making in a previous post. Here we’re talking about maintainability, the ease with which a particular codebase can be modified.  Here are some best practices which you should insist that your developers follow:

  • One is to separate the responsibility of code into little independent boxes, which only do one specific thing. If you need to change something, there is only one place to look for. This is called modularity and follows the concept of separation of concern.
  • Another one is having Source Control. This shows all the changes that have been done on the codebase over time, including who did it, and enables us to revert code to what it was in the past (when a bug has been inserted, for instance.)
  • Automated tests make every small bit of the code run through its logic, often by trying to make it break. There is one thing that we software developers are scared of, and which happens a lot: we change a bit of code here and then notice that loads of other bits of code are no longer working. Automated tests enable you to be able to make bold changes because you immediately get feedback on whether you’ve broken something.
  • Finally, documentation really helps. And please note that I’m not talking about some separate Word Document that was once done for the client, I’m talking about comments explaining why things were done in a particular way embedded within the code.

If a software developer inherits a codebase which didn’t follow these guidelines, then that code is going to be a pain to maintain and to change. And as a developer, it’s a large source of frustration because we are in effect far slower at delivering changes than our predecessor, and our customer is not going to be impressed.

So, if you are a customer, request that these basics are followed, or else you’ve got a bad case of developer lock-in, where Bob is the only person who can maintain the code.

In conclusion:

If you are a customer and switch developers or provider for a project, you’ll have to factor in some budget and time just for the new developer to get acquainted with the project. You’ll also see that it will initially take longer to effect changes, depending on how well and maintainable the software was written in the first place.

 

Software is an iceberg. You’ll get hurt by the submerged parts.

by

Software Quality is an iceberg.

The tip of the iceberg is the small part sticking out that everybody can see. A non-IT person judges software with a far smaller subset of criteria than an IT professional: Functionality, performance, and usability.

To a normal user, the interface is the software. I regularly have to choke off exasperated comments when a customer tell me ‘but it’s only one extra button‘.

Lurking beneath the murky waters are those criteria which only IT professionals see: reliability, maintainability, security.

End-users should not be expected to see these ‘underlying’ aspects, but if the decision-makers (i.e. the ones with the purse string) don’t see under the water, you’re doomed to produce bad software. Tell-tale signs are:

  • There is no budget for IT maintenance
  • The only time fresh money is given is for new functionalities – money is never given for a functionality-free maintenance
  • Projects get stopped as soon as the software is barely out of beta testing. Finally, as a programmer, you’ve produced software that works, but in your mind, this is just a first version. There are lots of bits and bobs of useless code left in your software, debug code that writes to system.out, the object and data structure is a mess and could be optimised, you’ve yet to apply a profiler to your code to see where are the bottlenecks. And then the project gets stopped: ‘it works well enough’. That is very upsetting, and possibly one of the main reasons that in-house IT jobs are far less attractive than IT jobs within software companies.

If you recognise yourself as a company, then you should give more power to the IT department. Too many companies treat IT as a necessary, needlessly costly evil. IT should be an essential, central part of your company strategy. There is no other region of a company’s activity which gives you more of a competitive edge.

Too many companies (and I am looking at banks and insurances in particular) have failed to see that they are, essentially, a software company. You need to have a CIO who understands his trade, and accept that he is going to spend money for stuff which doesn’t make sense to you, or at least doesn’t seem to change anything.

If you are only ready to pay for the IT stuff which is visible – more functionality, for instance, but no money for a refactoring exercise which would add stability but not change the functionality, the accumulated technical debt is going to bite you at some point. It might be that an application gets exponentially difficult to change, or it might be that you have a massive data loss that you can’t recover from because the backup software was not up-to-date and nobody did an actual restore as part of regular maintenance.

If you are a developer, and you find yourself in such an environment, you’ll have to go guerilla. You’ll need to surreptitiously improve your code whenever you have the opportunity. Try to leave any code you touch a little bit better than before. Notice duplications and remove them. If you didn’t understand part of a code, then document it after you have understood it. If variable names are unclear, then rename them to something better. It’s an thankless occupation, because there is the risk that you break things that were working, and nobody will really care that you reduced the codebase by half, but it will help you progress and it will increase the quality of your work.

IT is surprising in that often the perception of quality is completely at odds with real quality, because of this iceberg effect. I once used to work in an environment where colleagues were doing terrible things – changing code directly in the production environment, and only doing quick-and-dirty cosmetic patches, but were actually perceived by the customers as delivering excellent quality, because the response times were so fast.

Loop elegantly through a JavaScript Array

by

I’ve been reading JavaScript Enlightenment to try and understand the language. There is beauty, and power, hiding behind the covers of JavaScript, but I haven’t clicked yet. I still don’t really get prototypal inheritance and what ‘this’ really means. There is power in understanding closure and scope, too, I am sure. This small book is recommended to see where the beauty is.

20943392

I’d like to share one bit of code which I found elegant: looping through an array:

[code language=”javascript”]
var myArray = [‘blue’,’green’,’orange’,’red’];

var counter = myArray.length;

while (counter–) {
console.log(myArray[counter]);
}
[/code]

It relies on the fact that integer values that are not 0 or -0 are ‘truthy’.

Tim Tripcony’s incinerate function elegantly batch recycles Domino Objects in Java

by

I recently was surfing through Stackoverflow and I hit a response from Tim Tripcony on this post: What is the best way to recycle Domino Objects in Java Beans

He published a small helper function to recycle an arbitrary number of Domino objects. It’s so simple, and so well written, that I thought it deserved a post of its own. Here it is in all its glory:

[sourcecode language=”java”]
private void incinerate(Object… dominoObjects) {
for (Object dominoObject : dominoObjects) {
if (null != dominoObject) {
if (dominoObject instanceof Base) {
try {
((Base)dominoObject).recycle();
} catch (NotesException recycleSucks) {
// optionally log exception
}
}
}
}
}
[/sourcecode]

And it’s used like this:
[sourcecode language=”java”]
Database wDb = null;
View wView = null;
Document wDoc = null;
try {
// your code here
} catch (NotesException ne) {
// do error handling
} finally {
incinerate(wDoc, wView, wDb);
}
[/sourcecode]

I find the function elegant in many ways; the function and the variables are clearly named, Tim uses variable-length argument lists (thats the Object… part with the ellipsis), the new for-each iteration, plus there is some humour. Thanks, Tim.