Ulf Wendel has a new post today with details on using stored procedures with mysqli - not overly difficult if you know how to handle the IN, OUT and INOUT parameters. He includes a few code examples showing how to use them.

Out of curiosity I asked another friend, a team lead, how things where going with their PHP MySQL project, for which they had planned to have most of their business logic in stored procedures. I got an email in reply stating something along the lines: "Our developers found that mysqli does not support stored procedures correctly. We use PDO.". Well, the existing documentation from PHP 5.0 times is not stellar, I confess. But still, that’s a bit too much... it ain’t that difficult. And, it works.

He describes the three parameters (IN, OUT and INOUT) and gives some examples of setting/getting them from your SQL statements. They're all still set up using the query method on your connection as well as handling the result sets that come back and working with prepared statements.

Whether you're just getting into PHP or are a veteran of the language, there's always places to get involved. Greg Beaver gives one such example in this post on his blog talking about helping out with the PEAR or phpDocumentor projects.

He talks about examples where the person basically just sent along the bug fix (or notification) without any preemptive notes. Greg ancourages these kinds of people to just go ahead and fix those bugs, makes those changes, and send along the information. He also reminds those looking for help with bugfixing that there are mailing lists for each project to help with just that. He also talks some about the general state of bugs for the two projects - both with a steady stream of issues rolling in that need taking care of by a code-loving, plenty-of-free-time developer like yourself.

Whether you're just getting into PHP or are a veteran of the language, there's always places to get involved. Greg Beaver gives one such example in this post on his blog talking about helping out with the PEAR or phpDocumentor projects.

He talks about examples where the person basically just sent along the bug fix (or notification) without any preemptive notes. Greg ancourages these kinds of people to just go ahead and fix those bugs, makes those changes, and send along the information. He also reminds those looking for help with bugfixing that there are mailing lists for each project to help with just that. He also talks some about the general state of bugs for the two projects - both with a steady stream of issues rolling in that need taking care of by a code-loving, plenty-of-free-time developer like yourself.

If you haven't already gotten your admission to the php|tek conference happening in Orlando from the folks over at php|architect, you waited a bit too long.

According to this post on the php|architect site, all of the attendee packages have been snatched up - a complete sellout crowd.

Don't worry, though - for those that aren't able to attend, Marcus Whitney, host of the Pro::PHP Podcast will be presenting a special edition podcast shortly after the conference wraps.

If you haven't already gotten your admission to the php|tek conference happening in Orlando from the folks over at php|architect, you waited a bit too long.

According to this post on the php|architect site, all of the attendee packages have been snatched up - a complete sellout crowd.

Don't worry, though - for those that aren't able to attend, Marcus Whitney, host of the Pro::PHP Podcast will be presenting a special edition podcast shortly after the conference wraps.

In this post from Marco van Hylckama Vlieg motivating PHP developers to work harder at their code and move things up to the latest versions.

I placed this entry under 'programming' but it might as well have been placed under 'rants' really. I've been programming PHP for over six years now. It's still definitely my language of choice because of it's speed, ease of use, ease of deployment and last but not least: because of the huge community with all of it's advantages. However there's one thing that's really bugging me lately: PHP is seriously suffering from what a friend of mine called 'the Apache syndrome'. Apache 2.x has been released a long, long time ago. Yet, tons of servers are still running 1.3.x and they probably will continue to do so for years to come.

While this isn't all that serious for a webserver (as long as it serves it's stuff and the server doesn't break it's fine) I believe the case is different with PHP.

He goes on to say that PHP is loosing out on the "coolness factor" to Ruby on Rails, and that most PHP developers out there just aren't taking advantage of the new features/better performance that PHP5 has to offer.

In this post from Marco van Hylckama Vlieg motivating PHP developers to work harder at their code and move things up to the latest versions.

I placed this entry under 'programming' but it might as well have been placed under 'rants' really. I've been programming PHP for over six years now. It's still definitely my language of choice because of it's speed, ease of use, ease of deployment and last but not least: because of the huge community with all of it's advantages. However there's one thing that's really bugging me lately: PHP is seriously suffering from what a friend of mine called 'the Apache syndrome'. Apache 2.x has been released a long, long time ago. Yet, tons of servers are still running 1.3.x and they probably will continue to do so for years to come.

While this isn't all that serious for a webserver (as long as it serves it's stuff and the server doesn't break it's fine) I believe the case is different with PHP.

He goes on to say that PHP is loosing out on the "coolness factor" to Ruby on Rails, and that most PHP developers out there just aren't taking advantage of the new features/better performance that PHP5 has to offer.