So I’m finally at Zend Con, and guess what, got the first problems. Even I’m Zend Certified and a Dev, I’m not allowed to go to the ZCE Meeting as I just have the exhibitor badge. I just wonder why it’s called ZCE Party than if ZCEs are not allowed to attend. Thanks to Cal, I was able to attend, and it was really a great party. Thanks Zend. Nervermind, so I have more time to finally fix some bugs and go to the lobby afterwards.
So following the tradition of announcing the own talks:
I’m going to hold a talk at IPC (end of october) about a particular of database partitioning: sharding and I’m going to Zend Conf, even not holding a talk there. So looking forward to meet people there.
“Every language has an optimization operator. In C++ that operator is ‘//”
When it comes to choose a operating system to run PHP applications often Linux is the choice. PHP, it’s buildsystem and it’s extensions are developed and optimized to run under Linux (and Unices). There are several reasons that Linux is the better supported operating system. Maybe due to historical reasons, maybe most of the core developers work und Linux (rumours were afloat that this is not quite true) or maybe just because the extensions finally run on a Linux server, so therefore it only counts if it runs under the target system.
This is actually the reason to not even try to compile my ktaglib extensions under Windows. Well but this approach is doomed to fail as most of the developers out there use Windows as their operating system. Therefore they are not able to run the extension and might not be able to ingerate your extension into their application. So actually I ended up booting up windows again (well after searching for the harddisk that contains a running windows) and try to compile it. Otherwise my fellow collegues wouldn’t be able to fix my buggy PHP code.
I remember compiling extensions under Windows a year ago, which actually doesn’t seems to be very easy for me. Since then a lot changed. Ongoing pecl2 efforts from Pierre with great help from Elizabeth and Rob now makes compiling on Windows without deeper knowledge about the Windows buildsystem easy. They carry together various notes about the build dependencies in the official php wiki. Furthermore Elizabeth recorded a video showing how to compile PHP on windows in a few minutes. So I actually ended up going to the pecl2.php.net page and just get the necessary libraries, put them into the right directory and compile PHP the same way as under Linux.
This helped to actually get ktaglib running under Windows. Just take the taglib windows port from the taglib website and compile your windows ktaglib using the PHP windows build system. Maybe the new scripts from the php-internals-win repository, that Pierre recently commited, help you to get you way through. It’s really amazing to concentrate on the work and not trying to get a buildsystem working.
ktaglib is a PHP binding for KDE’s taglib that helps you to read id3 tags and audio information from MP3s or OGGs. The current version is 0.0.1a1 and can be downloaded at http://pecl.php.net/package/KTaglib
I recently discovered bitbucket.org which is a polished hosting platform for mercurial. It is pretty much like github.com but much smaller. I really like the idea and the implementation of having a cooperative platform which allows you to watch and fork projects. So that’s why I moved my hgbookmarks implementation from freehg.org over to bitbucket.org with a free account.
But the best thing is that it is still very familiar with the main developer jesper hanging around in the #mercurial channel on freenode. He actually changed a few things on my repository as I’m too lazy to setup them up in the first time. Thanks for that.
Hopefully it will grow like github. Well at least I’m thinking about getting a $5/month account on it.
hgbookmarks is a implementation if git-styled branches for mercurial. It allows to create local bookmarks on certain commits that move forward with any commit. You can merge and update those bookmarks. You can think of bookmarks as named commit sha1s
Again, git vs. SVN. Last time, it was big win for git. And guess what, git will strike again.
I mean nobody is perfect (expect Linus, but there is just one – as he mentioned once), so we actually fail writing bugfree code. Therefore we end up sitting in front of a huge code base trying to figure out what’s wrong. Thanks to our agile development process we usually end up fixing code we are not into.
So the facts:
bisect
Okay, if we drop 1. and 2. we still have to find out what went wrong. So as we tend to get our evening beer fast and don’t want to waste time, we use git bisect to find out when the problem was introduced.
Assume following commit history:
a –> a’ (bug introduced) –> b –> a” –> c
When we bisect the problem, we will end up doing a quick search on the commits, marking buggy commits/trees bad and those that work fine good. This means, we mark c as good, then git will take us to a. We mark that commit as good, which will git move to b. If we mark b bad, git knows that a’ must introduce the bug. Than just view the diff and you might know where to find the bad code and how to fix it.
Well, as long nobody trashed the history with their ‘fixed a hundred bugs’ commits, containing like thousends of unrelated changes. In those cases, just bisect your collegue. git vs. SVN: 2:0
take it with humour
I used git for the last 6 month in a big project. The project itself is not maintained
in git but in subversion as this is what developers know and what project leaders like to use
for several reasons.
In fact it’s not a bad idea to actually use subversion as version control system, particularly if
the developer are used to it. Well, I don’t care about that. Thanks to git-svn I could use
git as my subversion frontend. For sure, the distributed architecture of git didn’t help me that much when it comes to exchanging changes as I was the only developer using git.
But thanks to the repository format and git rich featureset, I found myself using git in a
much more productive way than people could use subversion.
Pickaxe:
What I really love is pickaxe. You can use that feature by passing -S to git log causing the log
to search for the string in the commit history and display all the commits that contain these changes.
Actually one of our developers had a problem with a blur event in the java script code, causing
all forms in the script to lose their focus all the time. He was just searching for the point all the
time as going through the commit messages was obviously too much time consuming (with about 100 commits per day). To make a long story short: I’m really a Javascript dumbass, but I just picked the
latest commits having a blur in their name with git log -Sblur and I found 2 promising commits. Showing him the commits actually solved the problem. He just missed one point in the thousands lines
of Javascript containing the blur event that caused the problems. Okay so here are the statistics for that event: Subversion with incremental search, but Javascript knowledge: 3hours. Git without any knowledige and a lazy person using it: 10mins. GIT vs. SVN: 1:0
Approaching the 5.3 release of PHP, a lot of features were introduced
and discussed at the internals mailinglist. This includes closures, traits
and various other patches. Some of these patches are on hold and not yet
applied. Therefore only a few people can take a look at the new features. Particularly because they scare patching PHP themselves or they run into troubles while patching. To make those patches available for a wider audience
I start maintaining a PHP 5.3-exp branch containing experimental features and
patches.
Who is the audience:
The 5.3-exp branch is available at:
http://git.experimentalworks.net/php-exp.git
Latest tarballs are available at:
http://git.experimentalworks.net/php-exp.git
Please notice that experimental patches are untested and therefor can cause
problems. Also notice that I cannot guarantee that the patches run under every
platform supported by PHP. The patchset is tested under a recent Ubuntu Linux
system with latest re2c and librarys from the Ubuntu repositories.
Comments are welcome
Well finally gc-utils turns 6 month old. It started as a small script to wrap my usual command line of git-cvsimport. After getting nerved by specifying the GIT_DIR all the time the script started to grow to do help me importing repositories. Since that a lot changed and gc-utils is now on version 0.2.2. And the best: thanks to Adam Mercer we finally have a macport.
Okay, there wasn’t a blog entry on git for quite a while, but well, here it is. This time about the incredible INDEX mechanism and git add -i. Read the rest of this entry »