Bye, bye Eclipse, hello Vim!


Today I did something I wanted to do for a long time: to throw away Eclipse. I’ve been using Eclipse for PHP development for some time now, and it always didn’t really feel good. It was a constant pain in the ass. And a few times, it really seemed to fail to do what it should do: work!

The irritation always started right away: if you want to use Eclipse, it first has a load screen, that needs about 20 seconds to load your workspace. But then it isn’t over yet. It still needs to process all your projects before you can actually start using it. Ok, you could do some work while it was loading your projects, but it was awfully slow during that times.

After a while, when it was loaded, you could start programming. Great, but there were some general annoyances. First of all, autocompletion, I loved the feature. But the problem was, that when I typed a bit of text, and hit <Ctrl>-Space, it took a while before Eclipse brought up the autocompletion. Another very annoying thing, is that it sometimes had random slowdowns. You would type some stuff, and then you had to wait 30 seconds, and then you slowly saw your text being printed to the screen, character by character. In the meanwhile, I already saved the file and switched to Firefox to test my changes. Obviously, the changes didn’t work, because eclipse didn’t quite manage to save the file yet.

So, a while ago, somebody said that the PHP plugin for NetBeans was a lot better. So I tried NetBeans. But after a ‘sudo apt-get install netbeans’, there was one obvious (and bad) problem: my font settings weren’t used in NetBeans! It seemed like that is a general problem with Java when you’re running Compiz. But I wasn’t throwing away Compiz in favor of NetBeans. Also, Eclipse is Java too, so in my opinion, NetBeans probably could do the same thing.

So today, I finally decided to go with vim. Eclipse was just being too slow again. I made the decision that I won’t touch Eclipse for one month, and that I will use vim as replacement during that time. Lets hope I don’t come back crying to Eclipse. Though I don’t really think that will happen (vim really has some great features, and can do (almost) anything that Eclipse can). Also, I used matthew’s blog for a nice start to PHP programming with vim, and I hope I can keep going to use vim for this month :) .

Why in hell’s name we should learn C in the first year of Computer Science


Currently, I’m following college on Computer Science, in the Netherlands. And one of the things I hate about it, is that they weren’t able to teach me anything in the semester I’m there. I just go there, drink my PiƱa Colada, and sometimes I write some code in C#. C# is easy for me, and for the rest of the class. For me its really easy, when you consider when I did some Java programming. For the rest of the class, even the guys who didn’t have any programming experience at all, its easy too. Too easy.

Some people actually think that its supposed to be that easy, because nobody will be able to learn it otherwise. But then think about this: only about 2-3 people in my class (including myself), are able to actually tell you exactly what happens when you press the run button in Visual Studio. The rest of the class will just say that it runs the program you just typed. They never even heard of a compiler!

At start, this isn’t a problem at all, they are able to function perfectly in the college’s ecosystem, because they get the right job done. But later, when they have to use different programming languages, where they don’t get a shiny IDE like Visual Studio. They get in trouble because they don’t know how what compiling is, and how the hell they are supposed to do that.

Further on the road, there are more problems. They are so used to the fact that everything ‘just works’, they don’t take into account how fast something will be when you deliver something to customers who actually use the software. When you learn to write software like we do, you only program with small and simple examples. Yes, that is how its supposed to be done, but we did never learn to think about performance scaling. So, when a customer loads your program with 100MB of data (instead of the 5KB you fed to it), he will probably run out of memory, because you just stored everything in both variables and a database and it worked fine.

All these problems are very easy to overcome, when you just teach young students about what the memory is right away. Even better: learn them C. Then they need to manage the memory right away, and then they also know how some things that might seem as simple statements in C#, actually are very complicated things. This way, they think better whats behind some functions, and they actually think about the available memory, instead of mindless loading everything in the memory when it might seem usefull.

The fun of migrations, and why they suck


A lot of web developers know them, migrations. Migrations are the type of things that look very robust and easy to use when you read about them. The idea is that you got a set of revisions of your database, so you can maintain a history of your database structure. The thought behind it, is that if one of your fellow developers on your project makes a very stupid database edit, you can just revert it with the blink of an eye.

And now we’re going back to the real world. In the real world, we use SCM (Source Code Management) tools. And this means in a lot of situations, that you are doing stuff that is already there! And not only you’re duplicating behavior that already exists, but you also make the process more error-prone.

Like for instance, you’re using the SCM Git. And you are writing a migration, and you commit it. And then you pull from one of the other developers in the project. And then it seems that he also has made a new migration! Which means you got merge conflicts. So, what would you do then? You can rename one of the files, but which one gets which migration number? This isn’t really a big problem when you are working with just the two of you. But for bigger projects, it could be a huge problem when the maintainer pulls from a few developers, who all created a new migration. Then you need to do a lot of work to figure out in which order they should run.

But there is still some light on the end of the tunnel. Some projects like Ruby on Rails or Doctrine use timestamps as migration numbers. Because the chance that two developers commit exactly the same migration number is very thin, you would not have version control conflicts. Yes, they are right with that. But it only makes the problem worse. Because now the order of the migrations is purely determined by the time that each programmer creates the migration, not in a logical order.

Now the project maintainer pulls from those developers, and sees that there are no merge conflicts. Then he asks the migration tool to migrate the database. And it seems that all those migrations except for one fail! Why did this happen? The first migration simply dropped a table that the other migrations builded further on!

So, I’ve done my words about the pain of migrations, so I should also give a better solution. Well, this is actually quite easy, use one database schema instead of a revision system inside of a revision system. Let your SCM handle the differences between them, because that is exactly where an SCM is meant for. And of course there can still be conflicts. But instead of thinking in which order they should run, you only have to think about the database schema, which is much easier.

Go to Top