Coggeshall.org - PHP

Interesting Developments at Zend

nospam@example.com (John Coggeshall) — Wed, 21 May 2008 07:41:15 -0700

For those of you who haven't been following it, Zend on Monday went through a series of lay-offs which was picked up by the Washington Post. According to the brief article (which was a syndication from TechCrunch) Zend has laid off approximately 25% of their R&D staff in at attempt to become cash-flow positive and potentially line themselves up for an acquisition. I don't have any hard figures as to what that means but I'd estimate that Zend's recovered somewhere between $600-800k in revenues based on an educated guess of the average R&D salary for someone in Isreal (where R&D is based) of $60->$80k USD and the number of people estimated by TechCrunch as being laid off (about 10 people, which sounds right). If I'm anywhere in the ballpark there I think that's a significant recovery for Zend and very well could put them into the black.. Which is why Everyone I've spoken to who is familiar with the subject considers the lay-offs a positive thing (except of course those who lost their jobs -- sorry guys/girls -- I'd love to hire you but I can't open up an R&D shop in Isreal just yet..), but here are some things I've either heard from within the organization or read online which I think are worth commenting on:

R&D wasn't the only department to get hit, although it was clearly the primary focus. The IT department, Business Development, Sales, and Global Services were also affected to a much smaller degree

Despite speculation from Internet News that the most likely buyer is IBM, but I find that very unlikely. I think it is much more probable that Microsoft is the buyer if one exists

Why do I think I'd put my money behind Microsoft instead of IBM? Well, there are a lot of reasons.. Firstly, despite the impression given by the reporter at Internet News, IBM to me has shown more negativity in general toward Zend then it has positive in recent dates. For instance, Project Zero (cited as a positive reason IBM would buy Zend) in my mind is hardly such. If you haven't seen this before, Project Zero is a platform for dynamic languages implemented entirely in Java (one of which is a PHP implementation). The thing is, the PHP which exists in Project Zero is completely incompatible with all of Zend's product line -- hardly something I would say means IBM is trying to align itself with Zend. In reality, I think Project Zero is really a shot at Microsoft's .NET architecture and an answer to the recent moves from Microsoft to port implementations of popular dynamic languages to run in the .NET DLR and IBM's willing to step on Zend's toes to do so. Secondly, while it is true that QEDWiki is a PHP application and built on top of Zend Framework, in recent months I've heard more and more rumors from contacts inside of IBM that QED is going to be re-implemented entirely in Java long-term.. Again, I just don't see how IBM's recent behavior adds up to an acquisition.

That said, I do think Microsoft has a lot of good reasons to add Zend to their empire. Firstly, Zend has been a huge asset to Microsoft through their Technology Collaboration to make PHP a first-class citizen on the Windows platform and get it certified for Windows Server 2008. This partnership, to me, is huge for Microsoft -- to the point I expressed concern over Microsoft's ultimate intentions -- the same justifications for my paranoia could very well be reason enough for Microsoft to acquire Zend. Secondly, I think a Zend acquisition makes a lot of sense to a company like Microsoft if you believe they well ultimately prevail in purchasing all or part of a company like Yahoo! which is entirely based on PHP technologies (incidentally, I don't think Facebook is out of the picture either as a potential Microsoft acquisition target -- they already have an equity-interest there and the Facebook advertising engine could prove equally useful in the battle with Google). Bottom line to me is both of Microsoft's best options to compete with Google are PHP-based technology shops and Zend has been Microsoft's biggest ally in making these two very different technology platforms operate harmoniously -- that's got to be worth a few bucks. Oh, and did I mention that the rumor on the street is that Zend's co-founders Andi and Zeev have been making recent visits to Seattle? Not that it means anything, but it does make one wonder..

Then again, I could be entirely wrong about the whole thing -- it sure is fun to speculate about it though.

West Coast recruiters wanted

nospam@example.com (John Coggeshall) — Mon, 28 Jan 2008 18:48:19 -0800

Zend Technologies is looking for some more PHP rockstars.. If you are interested let me know (john at zend dot com). If you aren't interest but know some *good* recruiters in the SF Bay Area for this sort of thing I'd appreciate it as well!!

Compiling extensions for Zend Core

nospam@example.com (John Coggeshall) — Mon, 07 Jan 2008 18:15:37 -0800

Over the past few months there has been an increasing amount of conversation about Zend Core, especially around how best to compile custom extensions for it. While Core does ship with a large list of extensions (which are all QA'd and supported by Zend) there are times when you would like to include non-official extensions from PECL for various reasons. Since there isn't a great deal of documentation out there about how to do this I thought I'd write a quick tutorial.

Basically, to compile an extension for Zend Core you need to go through the following steps:

1) Download the source of your desired extension
2) Create the ./configure script for the extension as a stand-alone shared lib ("PHPize" it)
3) Compile and install the extension
4) Add the extension to your php.ini file

Where most people get caught up is in step two of this process. So, how does one create the correct ./configure script? In a vanilla PHP from php.net, you would do this by executing the phpize command in the extension's source directory:



$ cd /path/to/my/pecl/ext 

$/usr/local/bin/phpize

When executed, this shell script will execute the necessary commands to prepare the extension for compilation and create a configure script in the extension's directory which you can then use to compile your extension. Think of this configure script as a mini-version of the standard PHP distribution version which only will work for the specific extension you are building:



$ ./configure --enable-my-ext

$ make

$ sudo make install

When building an extension for Zend Core, the process is almost identical. In fact, the only real difference is that you need to use the Zend Core version of phpize (and perhaps provide some paths to certain files)..for example:



$ cd /path/to/my/pecl/ext

$ /usr/local/Zend/Core/bin/phpize

Because Zend Core is installed it a directory under /usr/local/Zend, chances are when you attempt to execute the ./configure script it will complain that it can't find a program called 'php-config'. To get around this, you'll need to make sure you also include --with-php-config as part of any ./configure command you need to compile the extension:



$ ./configure --enable-my-ext --with-php-config=/usr/local/Zend/Core/bin/php-config

$ make

$ make install

For most cases that should be all you need to compile the extension for Zend Core!

If you need to compile a PDO Driver

One of the few exceptions to the directions above is when you attempt to compile a custom PDO extension. For example, many people are interested in compiling the pdo_sqlite drivers for PDO into Core. Unfortunately, currently such a process is not officially supported by Zend. However, if you feel that you are comfortable enough you can "tweak" Zend Core to allow you to do so by following these steps:

1) Determine the PHP version your version of Zend Core uses by viewing the phpinfo() page of Zend Core.

2) Download the same PHP version from php.net (or check it out from the repository)

$ cvs -d:pserver:cvsread@cvs.php.net:/repository co -r php_5_2_5 php-src

3) Copy all of the PDO header files into Zend Core



$ cd /path/to/php-src/ext/pdo

$ mkdir /usr/local/Zend/Core/includes/ext/pdo

$ cp *.h /usr/local/Zend/Core/includes/ext/pdo

4) Use the procedure outlined above for compiling a custom extension for Core to compile a custom version of the PDO base extension (in the ext/pdo directory of your PHP source install)



$ cd /path/to/php-src/ext/pdo

$ /usr/local/Zend/Core/bin/phpize

$ ./configure --enable-my-ext --with-php-config=/usr/local/Zend/Core/bin/php-config

$ make

$ make install

5) Compile your custom PDO drivers



$ cd /path/to/php-src/ext/pdo_sqlite

$ /usr/local/Zend/Core/bin/phpize

$ ./configure --with-pdo-sqlite --with-php-config=/usr/local/Zend/Core/bin/php-config

$ make

$ make install

Note, when doing this process chances are you will have to compile custom version of all PDO-related extensions for compatibility reasons. Once you have everything compiled you can enable the extensions in PHP by modifying the php.ini file (don't forget to restart the server afterwards!). Assuming everything worked as planned, you should be able to see the extension's information within phpinfo() and the Zend Core GUI will show the extension in the extension list (although you will not be able to control it, etc as you would a standard supported extension).

Hope this helps!

Zend_Service_SlideShare approved

nospam@example.com (John Coggeshall) — Mon, 10 Dec 2007 19:39:12 -0800

Today I received an e-mail informing me that my proposal for the Zend_Service_SlideShare component was accepted into the Zend Framework incubator. Woo hoo!

What's the component? If you haven't seen it before, Slideshare.net is an excellent site for hosting various Powerpoint slide shows for public consumption (think YouTube for slide shows). I wrote the component during the my site redesign to host my various slide shows which can be found in the resources section.

While it is not quite complete (everything but uploading slide shows is there), you can check out the source code by pointing your SVN to the Zend Framework Repository. Please use the Zend Framework bug tracking system if you find bugs.

The Microsoft Trojan Horse?

nospam@example.com (John Coggeshall) — Thu, 29 Nov 2007 21:09:58 -0800

Recently I've had Microsoft on my radar a lot, mostly because I'm wrapping up development of the Zend_InfoCard component for Zend Framework, but also because everyone has been talking about the recent release of the FastCGI support in IIS.

Wonderful, now I can also run PHP in a reasonable fashion on IIS -- that's good for everyone right?

I'm not so sure, to be honest. I mean let's face it there is competition out there for the web. A company like Microsoft would be simply neglectful if they didn't do everything in their power to sway, control, and if at all possible dominate this space right? Over the years when it came to public-facing web development PHP has been without a doubt been the leader, but why? I think it has a lot more to do with the fact that Microsoft didn't have a reasonable platform for their web development technologies then it had to do with PHP just being better..

Continue reading "The Microsoft Trojan Horse?"

Making your boss like you more..

nospam@example.com (John Coggeshall) — Mon, 19 Nov 2007 14:45:51 -0800

I've seen this about a million times at various clients working in the services business, so I thought I might take a moment to mention it on my blog -- perhaps someone will find it valuable. From where I stand, there is a huge portion of the development community in general (not only PHP really either) that seem to think their job is nothing more then to write code without consideration for anything else in the organization.

Guess what? Your boss doesn't care how awesome your code is, or how slick your super-duper AJAX auto-complete wiz-bang thing is if you write something which doesn't support the business needs of the company.

Here are some of the classic blunders I've seen:

* Spending two days refactoring a piece of code which not only were they not asked to refactor, but it was working just fine before (no, the fact it was ugly is NOT always a good enough reason to refactor)

* Trying to be the developer version of Vincent Van Gogh -- code can be art, but it is always a means to solve a real business need. Over-architecture doesn't make you look cool, it makes you look like an idiot when the next guy shows you how to solve the same business need in 30 lines of code instead of 400.

* Not understanding you are responsible for your own time lines. I don't care if you have a project manager or not working in the group -- ultimately at the end of the day as the guy writing the code if you say it's going to take 3 weeks to develop something and it takes you 3 months that is entirely your problem. What does that mean? It means when your boss comes over and constantly changes the scope or features of what you are trying to build if you don't push back and make him decide between getting the project done in 3 weeks or his feature that's your fault.

* Know your business - its amazing how many developers are out there writing code without having any idea what-so-ever why they heck they are getting paid to write it. If you can't speak intelligently about the business your company is in and why your application is going to benefit that business for at least 30 minutes then you aren't being a very good developer. We all sometimes like to imagine that the world revolves around us, but let's face it -- you're working in a company and that company is trying to do something which you probably should understand before you try to write the code to do it.

I'm sure there are more if I had more time, but that's good enough for now. Bottom line: Code is not the most important thing in business, even though it might be in OSS. If you want to be a successful professional OSS developer you need to understand both and react accordingly!

Alan has smoked too much PHP

nospam@example.com (John Coggeshall) — Thu, 15 Nov 2007 16:16:55 -0800

Alan, I think you were smoking way too much PHP when you wrote this post.. This in particular really surprised me to hear you say:

"...if there was an apache module that did mysql stored procedure calls based on the request URL, and returned JSON, I suspect PHP would be practically obsolite....."

While I do understand the concept your explaining, I simply can't see how the model is practical at all for two big reasons:

Reason 1: Businesses will never build applications designed to make money when the entire application is transmitted open-source to any client which requests it.

Reason 2: Without a server-side language such as PHP, there is not a viable security model. Javascript data validation is a half-measure at best, and do you honestly believe that it makes sense to use stored procedures written in SQL to scrub data?

While I think Alan really did go a bit off the deep end, he has touched on a pretty interesting point though. While I can't see the server-side ever going away I do think that in the near future the development model will change from what it is today to a completely event-based model based on a json-powered message bus between the client and server. IBM's QEDWiki uses Zend Framework to create such a bus and I have to say it's a very impressive architecture. The idea that PHP programming will for a lot of people resemble Visual Basic is really a lot closer then a lot of people might think.