Posts tagged php

Bye, bye Eclipse, hello Vim!

10

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 :) .

The fun of migrations, and why they suck

1

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