I'm currently working on some Symfony2 bundles and I have one Netbeans project for the main Symfony2 app and one project for the bundle. The bundle files are completely separated from the app and they are just linked (ln -s) together. It works great, except for the case when I need to debug some part of the bundle's code with Netbeans + xdebug. The debugger starts for the "main" project, which is the Symfony2 app, but setting breakpoints with Netbeans (y'know, by clicking the line number) for the bundle doesn't really work, as those are in the other project and not in the debugged one, rendering the whole debugging useless.

The solution is pretty easy actually: instead of setting breakpoints with Netbeans, use xdebug_break() where you want the break to happen and it will happily be caught by the IDE. After the break happened use the "Step into" (F7) functionality to see what's going on.

So, I got a haircut after 8 years.

This is the result. If you want, have a look at the whole album here: There, I fix'd it

I think it turned out pretty damn good.

I've started to play around with Jenkins yesterday and I kinda don't like that it's default home directory is /var/lib/jenkins so I changed it to /home/jenkins, so I'm throwing the steps needed out here for future reference.

First, stop jenkins:

robert@odin:~$ sudo /etc/init.d/jenkins stop

Create the new home directory and move existing stuff from the old home to the new one:

robert@odin:~$ sudo usermod -m -d /home/jenkins jenkins

Now, I didn't manage to set the ENV JENKINS_HOME to the new home, it was always using the old one, so I edited the init.d script:

robert@odin:~$ sudo vi /etc/init.d/jenkins

and in the "DAEMON_ARGS=..." line change JENKINS_HOME env to --env=JENKINS_HOME=/home/jenkins. In the end the whole line reads something like:

DAEMON_ARGS="--name=$NAME --inherit --env=JENKINS_HOME=/home/jenkins --output=$JENKINS_LOG --pidfile=$PIDFILE"

Update on September 20th: Vranac blogged about how to change the JENKINS_HOME properly

Start jenkins

robert@odin:~$ sudo /etc/init.d/jenkins start

and go to http://server:port/configure and verify that jenkins works as before and is using the new home.

Happy hackin'!

OK, here are some tips and resources so you can start helping out and contributing to Zend Framework 2.0 :)

First, here's a nice wiki page with some links on how to start with Zend Framework 2. Be sure to check out the Zend Framework 2.0 patterns tutorial slides and the webinar on the same topic (you need to log in to watch it, but the registration is free, so no excuses).

The development is happening on github, so that's a nice starting point to get your hands dirty with some code. On the wiki there's a Zend Framework Git Guide to get you started. Pay close attention to the "Working on Zend Framework" chapter.

As Matthew noted in this thread you can:

Fix unit tests!

Once you forked and cloned the github repo, cd to the zf2/tests directory and simply make the tests there pass! Of course, there are *a lot* of tests there, so you might want to start with something easy and small; for example I picked the Zend\Dojo component :P

Anyway, once you're in the tests directory, just type:

robert@odin:~/www/zf2/tests$ phpunit --verbose Zend/Dojo

or:

robert@odin:~/www/zf2/tests$ phpunit --verbose Zend/Dojo/DojoTest.php

and watch the tests pass or fail. If they pass, good, if they fail, try to fix them and make them pass! I tell you, it's fun! By using the "--verbose" flag you'll get more (helpful) info about the tests.

Port Zend\Service

I haven't look into it yet, so just quoting from the mailing list:

* Port Zend\Service classes that interest you to namespaces, new
exception usage, etc.

but I believe if you start from the tests for the services too, you should be all set!

Port ZF1 patches to ZF2!

Even if ZF2 is under development, ZF1 is still taken care of: that means, a lot of patches are present in ZF1 which are not in ZF2 (cause they were added after ZF2 branched off of ZF1, obviously...). Some patches will probably not be needed thanks to the rewrite, but some patches will be! So head over to the issue tracker, search for recently (where recently is, say... this year?) resolved and fixed issues, see if they have a patch attached, if yes, open the patch, see if that patch is already in ZF2, if not, add it, issue a pull request, move on to the next issue.

Play with the existing code!

The official Zend Framework Quickstart is also on github, with different features on different branches! Fork it, clone it, test it, make it, break it, fix it... I myself am rewriting a ZF1 based application to ZF2, so you can have a look at that too!

I have also created a few gists about using the new helper loaders/brokers/plugins.

That's it for now, if I remember/find anything else, I'll update the post. Of course, if you have to add something, fire away! :)

Happy hackin'! :)

I've spent this weekend hacking on some unit tests for Zend\Dojo and I ran into an issue where I need Xdebug to, well, debug. Note, that this is not for debugging a Zend Framework application, but for debugging Zend Framework itself. I am using Netbeans + Xdebug to debug regular code, but debugging unit tests was something completely new for me. Turns out, it's not entirely different from "regular" debugging.

Greatest help to figure out this was Raphael Dohms' blog post "Debugging PHPUnit tests in Netbeans with Xdebug". Almost worked out fine, but Netbeans complained about a missing index file and the autoload of files was... not really working. After a bit of poking around, the solution was to go to File -> Project Properties -> Run Configuration and set the "Index File" to /path/to/zend_framework_2/tests/_autoload.php - no more missing index file and the autoload works too!

Starting the debug session stays the same as explained in Raphael's post: click "Debug project" (CTRL+F5), go to the terminal and just type something like:

robert@odin:~/www/zf2/tests$ /path/to/phpunit-debug Zend/Dojo/DojoTest.php

Netbeans will pick up the connection and debugging can start!

Happy hackin'!