Goodbye, Zend

Ok, the title kind of says it all – this has been known to some for a few months now, but for the sake of clarifying things up, I’m leaving Zend – or to be technically accurate, has already left.

This was not an easy decision for me, as Zend has been for more than 6 years not only my employer but also my school, my workshop and a little bit of home as well. This sounds like bullshit – but since I started there as a first-level support engineer and am leaving as a co-Product Manager for the company’s flagship product, I think it’s fair to say I gained as much as I contributed.

However, it’s time to move on for me. I’m looking into doing my own things at my own time, and being my own boss. I want more free time to experiment, play and pursue my hobbies and silly ideas.

In recent years the company took some directions I was not 100% happy with, and being responsible for realizing some of these ideas, it was hard for me to stay at my role. I started thinking what I want to do next – and was offered a couple of very tempting roles within Zend – but then I realized that really, I want to make a bigger change.

And here I am.

For the last couple of months I have reduced my role at Zend to a 2-day consulting position, and will continue to consult Zend on a part-time basis for at least a few weeks.In the rest of my time, I plan to think, read, paddle, rest, blog more and work on some ideas I have. I plan to keep contributing to the PHP community, and specifically to Zend Framework 2.0.

Will I chicken out in 3 months and decide to get a real job again? Maybe… but I plan to make the most of my time until then.

How much is listening to your customers worth?

I normally don’t write about work. The reason is that I feel that the slight chance that someone might feel I’m being biased towards a product that comes from the company I work for and dismiss my thoughts as “guerilla marketing” is not worth it.

However, I’m going to make an exception – and that’s because I prefer selling Zend here rather than doing it on Lukas Smith’s blog :)

Lukas raises the question of what commercial PHP distribution should be used as an alternative to RHEL outdated packages. My answer on that would be, surprisingly – use Zend Server! (well, …once it’s out of beta, of course).

Lets put the features and SLA you get from Zend Server aside for a moment.

The real reason I think you should use Zend Server is because the Zend Server product manager (hey, that’s me!) reads your blog. I’m serious about this.

I’m not sure I can quantify this, but I think that a vendor that listens so closely to what potential users (and the community) has to say is worth quite a lot in the long run. And yes, Zend has not been perfect in listening to the community – but I can honestly and whole-heartedly say that we are trying harder. The recent feedback on Zend Server gives me the feeling that we are doing ok too.

Debugging CLI PHP with Zend Server and PDT on Linux and Mac

I’m working on a small PHP application and a big part of it are some CLI scripts which will be executed in the background. Some of these scripts are quite complex, and I got to a point where I need to use a debugger in order to figure out what’s going on.

I started hacking around with my locally-installed Zend Server CE and Zend Studio. I always knew how to manually start CLI debug sessions with Zend Studio (well, I knew, but forgot ;-) ), but then I figured, why not write a small shell script to automate the process, and learn a little about the Zend Debugger protocol on the way?

Here is what I did:

First, create the following shell script. I placed it at /usr/local/zend/bin/php-dbg (alongside the other Zend Server executables, which if you use Mac OS X will be at /Applications/ZendServer/bin):

#!/bin/sh

# Wrapper script for debugging PHP CLI scripts with Zend Studio
# Tested with Zend Server 4.0.0 Beta and Zend Studio for Eclipse 6.1.1
# Shahar Evron [shahar.e at zend], 2009-02-20

# Defaults
DFLT_PORT="10137"
DFLT_HOST="127.0.0.1"
DFLT_PARAMS="debug_fastfile=1&use_tunneling=0"

# Load Zend Server environment variables
. /etc/zce.rc

# Did the user specify the debug host / port?
if test "x$DEBUG_HOST" != "x"; then
  if test "x$DEBUG_PORT" != "x"; then
    QUERY_STRING="&debug_port=$DEBUG_PORT"
  else
    QUERY_STRING="&debug_port=$DFLT_PORT"
  fi

  QUERY_STRING="$QUERY_STRING&debug_host=$DEBUG_HOST&$DFLT_PARAMS"

# If no host/port were specified, try to auto-detect
else
  QUERY_STRING=`wget http://localhost:20080/ -O - 2> /dev/null`
  if test $? -ne 0; then
    # Fall back to defaults
    echo "Unable to auto-detect Zend Studio settings, using defaults" >&2
    QUERY_STRING="&debug_port=$DFLT_PORT&debug_host=$DFLT_HOST&$DFLT_PARAMS"
  fi
fi

DBG_SESS_ID=`date +%s`
QUERY_STRING="start_debug=1&debug_stop=1$QUERY_STRING&debug_session_id=$DBG_SESS_ID" 

QUERY_STRING=$QUERY_STRING $ZCE_PREFIX/bin/php -c $ZCE_PREFIX/etc/php.ini $@

Going over this code might teach you some surprising things about how Zend Debugger and Zend Studio talk to each other ;) I’m not going to go into the details now, but if you have questions feel free to ask.

Next, make this script executable – just run ‘chmod +x <path-to-script>‘ – and you’re good to go.

Here is how to use it:

  • If you have PDT or Zend Studio running locally (on the same machine as the server), just run:

    # /usr/local/zend/bin/php-dbg <script you want to debug>

    That would just work in most cases – if it works you can stop reading now ;-)
  • If you are running the script on a server, but your PDT / Zend Studio is on a different machine (in the same LAN – no NAT or firewall!) you can simply specify the IP address or host name of the machine that runs PDT / Zend Studio as the DEBUG_HOST environment variable. For example:

    # DEBUG_HOST=10.1.2.3 /usr/local/zend/bin/php-dbg <script you want to debug>
  • If you are running the script on a remote machine (as above) and your Zend Studio listens on a port other than 10137, you can also pass the DEBUG_PORT environment variable to override the default port.
  • Also, don’t forget to make sure that the machine that runs your Zend Studio is in the list of allowed debugging clients. You can check it at the Zend Server GUI on Server Setup -> Debugger.
  • If you are running the script on a remote host and there’s a firewall / NAT between you and the server (e.g. you are in an office LAN, trying to debug a script on a remote production machine which is not in your subnet) you’ll probably need to use SSH remote port forwarding to forward connections to your PDT / Zend Studio. I won’t get into how to do it right here – unless you insist.
  • If you want to only type ‘php-dbg’ when running instead of the full path, you can place the file in your $PATH (e.g. in /usr/local/bin) or even better, Add /usr/local/zend/bin (or /Applications/ZendServer/bin) to your $PATH – you can do that by adding the following line to ~/.bashrc:

    PATH=$PATH:/usr/local/zend/bin

Upon running the script, a debug session should simply pop-up in your PDT / Studio and you’ll be able to debug. How cool is that?

BTW: This has been tested with Zend Server 4.0.0 beta1 and Zend Studio 6.1.1. It should work with other versions of Studio as well. In fact, it can also work without Zend Server as long as you have Zend Debugger installed – but why ruin a perfectly good plug?

If you improve the script or find bugs, let me know! Also, if you know how to get the same thing going with xDebug, let me know and I’ll add it to the script.

Finally, it’s out: Zend Server

I normally try not to write about work related stuff… but this is a special occasion.

Zend Server is finally out for public beta. o/

I was working so hard on this for the last year, It kind of feels like I’ve just crapped an Elephpant ;)

Seriously now, I really like this product. I think it has great potential. I know a bunch of very good people who worked very hard on it, and deserve every bit of gratitude. We went over some rough times at Zend and we still were able to release this wonderful product! I’m so proud… :)

Attending Adobe Max next week

As part of my job at Zend, I was invited by Adobe to Adobe Max in San Francisco – how cool is that? It’s a huge conference (thousands of participants – nothing like any PHP conference I know!) with so many presentations to sit in it’s just hard to choose.

Of course, I am no designer and tend to stick to the server side – so for me choosing was easier, but still confusing.

In any case if you are there, or in down town San Francisco, come and say hi!

ZendCon 2008 Slides

Well, ZendCon is over and it was much fun! I got home today (well, does 4:30 am count as “today” ?) and am still very tired – I had to stay around after the conference for some meetings (yes, the title “manager” causes some PITA even if you do not really manage anyone) which was a bit exhausting but fruitful never the less.

I gave this presentation about Zend Platform:

It’s the first time ever I’m giving a presentation about proprietary Zend technology in an open-source conference so I was a bit nervous – but to my surprise I got a full room (I estimate some ~100 people were there, and only a few Zenders) and there seemed to be a lot of interest. In general this ZendCon felt a bit more “business-oriented” than usual, but still had a good mix of community and hacker-spirit to it.

Another thing is that Siddhartha – our VP of Sales for North America actually HUGGED me after the talk. He was sitting in the room and the guy knows a lot about selling Zend Platform – but I suppose that hearing the value of the different features and some good example use cases for Zend Platform from a technical perspective gave him and the rest of the sales team some good insight into what customers are looking for in such a product.

Anyway enjoy the slides and if you have questions just post a comment. I will probably post some more about the previous week – if only I will be able to get my hands off my new iPod Touch ;)