Why Not Emacs?

Every now and then a “hardcore” programmer comes and mocks you for using a “sissy” tool like Eclipse or IntelliJ. Real programmers use emacs and vim. If you are lucky and the other developer has some arguments and social skills, you are not mocked, but rather explained how you are wasting a lot of precious time with your IDE and once you get used to emacs or vim, you’ll realize how irreplaceable they are – it will be like going into the 3rd dimension and wondering how you’ve ever lived in 2D. Zoom out. Eclipse and IntelliJ are pretty much Java-oriented (though there are plugins for other languages). So if you are using ruby, python, php, or whatever, then probably emacs is the best thing you can get. But let’s see what you absolutely need your editor/IDE to do for Java: debug – number one priority. If you can’t put a breakpoint and run your whole application in order to simulate a specific case, then you are left with poor man’s System.out.println(..) quick navigation through the code – if you can’t go to a class with 5 keystrokes (no mouse), if you can’t go back to where you previously edited, if you can’t see which classes subclass a given class or, most importantly – see which methods call a given method, then your code analyzing efficiency drops remarkably. And in a typical software project you read and analyze existing code way more often than you write new code refactoring – you want to change a name of a method. Add or remove arguments. Move a class to another package....

What Is Challenging For Developers?

In a previous post of mine I asked the question: do programmers get bored? And yes, sometimes they do, especially if there are no challenges. But the usual software project out there is trivial – implementing business case after business case. But programmers still find challenges even in the trivial applications and websites they are writing: Complex user interface – implementing a complex UI on the web is a good challenge – often good components come out of that, that are later open-sourced and have the potential of getting popular. And if you are really good, you may solve a problem that many people have and make your component a standard solution. Architecture – if a system is big, the architecture matters. Separating components and deciding on the way they communicate is a challenge that requires both advanced skills in concrete technologies and the ability to get a good overview on a complex system. Big data – if you are lucky enough to work at a company that handles billions of records, you would be required to solve problems related to that previously unusual amounts of data. That requires deep understanding in databases and strategies for distributing and synchronizing data. As a result tools or even new databases can emerge. Look at Cassandra, for example, which was initially developed inside Facebook. Algorithms – it is rare that a business application requires complex algorithms, but in case there is, this is a great point for putting your efforts into and get satisfaction from your work. For example, you can optimize the delivery routes of a transport company, which in turn...

Not All Optimization Is Premature

The other day the reddit community discarded my advice for switching from text-based to binary serialization formats. It was labeled “premature optimization”. I’ll zoom out of the particular case, and discuss why not all optimization is premature. Everyone has heard of Donald Knuth’s phrase “[..] premature optimization is the root of all evil”. And as with every well-known phrase, this one is usually misinterpreted. And to such an extent that people think optimizing something which is not a bottleneck is bad. That being the case, many system are unnecessarily heavy and consume a lot of resources…because there is no bottleneck. What has Knuth meant? That it is wrong to optimize if that is done at the cost of other important variables: readability, maintainability, time. Optimizing an algorithm can make it harder to read. Optimizing a big system can make it harder to maintain. Optimizing anything can take time that should probably be spent implementing functionality or fixing bugs. In practice, this means that you should not add sneaky if-clauses and memory workarounds in your code, that you shouldn’t introduce new tools or layers in your system for the sake of some potential gains in processing speed, and you shouldn’t spend a week on gaining 5% in performance. However, most interpretations say “you shouldn’t optimize for performance until it hits you”. And that’s where my opinion differs. If you wait for something to “hit” you, then you are potentially in trouble. You must make your system optimal before it goes into production, otherwise it may be too late (meaning – a lot of downtime, lost customers, huge bills for hardware/hosting)....

Generating Music

Recently I’ve undertaken a personal project (computoser) that is a bit strange. I tried to write software that generates music at random. Good music, that is, because “random” usually generates noise. The idea, of course, is not at all new – there has been research on the topic and there is software that attempts to generate music. I generally group this software in three categories: software for helping composers – it’s the composers who handle most of the things, but the software can suggest some motifs, variations, etc. to help the composer programs that take functions or other mathematical concept and try to transform it to frequencies, based on some arbitrary mapping programs that generate music adhering to composition rules Out of these three, the first one is very specialized and not suitable for a large audience, and the second is not producing results that a sane person would listen to (the mathematical/physics rules that these algorithms try to employ are already used at the lower level of music – e.g. note frequencies double each octave; additionally, the mapping between the functions/sequences to notes are often arbitrary, so even though the the Fibonacci numbers are “nice”, there is no definitive way of mapping them to music that is guaranteed to sound good). The third group can generate “listenable” music, but it needs to properly define the rules that composers adhere to when writing music. Some of these programs use fractals, other use pictures, text, or whatever to generate music. In fact, these are all different ways to seed the random. So, I obviously I went for the third option,...

Don’t Use JSON And XML As Internal Transfer Formats

You have a system that has multiple components and they have to communicate. They do that either via internal web services or using a message queue. Normally, you would want to send (data transfer) objects from one component to another. Three typical examples: a user has registered and you send a message to a message queue and whenever the message is consumed, an email is sent to the user. The message needs the user at least the email and names of the user. if your layers communicate via web services for some reason (rather than live within one JVM), on registration the web layer needs to invoke a back-end service and pass a User object. you store objects in some (distributed) in-memory cache in order to reduce redundant calls to the database (assuming you map your database results to objects in some way, either an ORM or some mapper, but this is done in the majority of cases). So when a request arrives asking for a user profile, you check if it’s present in the cache, and if it is – you get it from there, rather than hitting the database. In order to achieve these things you need to serialize the objects to some format that will then be deserialized on the other end. Many frameworks include XML and JSON serializers and they are used in many examples online. Therefore people are inclined to use JSON or XML for these purposes. And that’s not a good idea. Using these formats internally has no benefit – you don’t actually need the serialized objects to be human-readable, and if you...

Do Web 2.0 Companies Really Have The Best Technical Talent?

There are a lot of cool companies with products on the web that millions of people are using. I’ll wondered whether I should labeled them “web 2.0″, “silicon valley”, “cool startups”, or something else, but I think it’s clear which ones I’m writing about. The assumption is that these companies attract the best technical talent. And even despite my criticism of their interview process, I still used to think that indeed the best developers and software engineers go to these popular web companies. But due to a couple of observations, I’m no longer certain. These companies have been making junior-developer mistakes in many areas and I can’t imagine that a “top talent” could allow this to happen. What raised my concerns is security. And it’s not computer-science heavy-cryptography-algorithm-design type of security. It’s the simple web security that every developer out there should actually know – how to store passwords. I was astonished to learn that Yahoo, LinkedIn, and recently Pandora were revealed not to be hashing and salting the passwords, which lead to password leaks. (Note: the case with Pandora is a bit less trivial as noted in the HN comments). It’s the bare minimum thing you should do, and any sane developer who sees that the company stores passwords in plaintext, or uses MD5 hashes, or doesn’t add salt, should just go and fix that (with management approval, yes). “Legacy” is not an issue here – you can hash&salt plaintext passwords, and you can add salt to a hash the next time a user logs in (by getting his actual password on login in order to generate a...