Development Blog With Code Updates : Developercast.com

Carl, Richard and Mark Miller chat about events that occurred in 2010 that affect the .NET world. From C# to F#, Studio to Lightswitch, Windows Phone 7 to Kinect. What a great year!

On the php|architect blog today Bill Karwin has shared his thoughts on NoSQL and how, despite the popularity of it during 2010, the hype curve is bending and companies are realizing it’s less of the “silver bullet” they expected.

The technology hype of 2010 was clearly NoSQL, which proved to be more of a brand-name than a technical term. Today in his tech blog, Bozho set out his view that NoSQL is probably not a good choice for startups that don’t know yet where their database and application bottlenecks are.

Bill agrees, noting that the adoption of NoSQL technologies caused some major meltdowns when all things weren’t properly considered. He points out that “a little knowledge is dangerous – the more little, the more dangerous” and developers should seriously consider the impact a NoSQL environment should have before jumping in head first.

On Reddit.com there’s a recent post with a question about some of the lesser known PHP tricks that other developers might have picked up out there. The post has pulled in quite a few suggestions including:

• Using predefined interfaces
• The streams API
• Defining constant defaults
• The speed differences in reading parts of arrays
• Boolean attribution

There’s also a full discussion on closures/lambdas that no “features” post on PHP would be complete without. Have some tips to share? Add yours to the post too!

On DZone.com there’s a new tutorial from Giorgio Sironi about reusing closures with the help of functors (a special kind of object instancing done in PHP with the help of __invoke).

I like PHP closures and their superset, anomyous functions, as they implement the Command pattern very well when used correctly. However I feel that sometimes they are: difficult to reuse and difficult to force contracts on. [...] What if we wanted instead, a closure which we can instance even more than one time (maybe with different variables), and that we could type hint?

He shows how to make this possible with a functor created using the __invoke magic method of PHP to handle the request to an object like a function. He includes some sample code to show it in action – a basic callback (SquareCallback) and how it compares to calling a normal closure. It also shows something a bit more technical, an “AdderCallback” class that can be defined as a type hint on a function.

On the Zend Developer Zone today Cal Evans has posted his review of a book by Kevin Schroeder called “You Want to Do What with PHP?“, a look at some of the less commonly used PHP functionality in action.

You Want to Do What with PHP?” isn’t your usual PHP book. I am guessing that even advanced PHP developers don’t have a book like this on their shelves as I’ve never read one that covers quite this variety of material. Kevin talks about a lot of topics that we politely call “Edge Cases” for PHP developers. [...] This book guides you through building things like your own stream handler, asynchronous operations and my personal favorite, writing Daemons in PHP.

Cal covers both the good and the bad about the book. Among the things lacking are no real “ease into it” introduction and a debugging chapter that feels like an ad for Zend Studio. On the good side, the book provides a enterprise-level developer with a whole new toolset they might not have tried out before.

Mike Lively has a new post to his blog today looking at a mocking framework he’s developed to work hand in hand with PHPUnit to make mocking easier and more robust.

I have used PHPUnit heavily now for the last 4 years. As anyone that is heavily involved in writing Unit Tests knows, test doubles (commonly referred to as mock objects) are a necessary part of your toolbox. The mocking options that we used to have for PHP unit testing have traditionally been fairly limited and most all of them in some form or another were ports of JMock. The way PHP operates as well as some decisions made to more closely emulate how JMock does things lead to functionality in the existing mock library for PHPUnit that for some are a hassle.

To help eliminate this hassle, he create the Phake mocking framework – a tool that comes at mocking a different way than the normal PHPUnit procedures. He includes some sample code for a class to test, a simple stub for getting a value and how to use it in a basic test. By calling a “Phake::mock()” on the class to make an object, you can call the method and run a “verify()” to ensure that the results are correct. He talks about some other options that the mocking allows too like calling a “no interaction” method on a mock and argument capturing.

Flyn San has a new post to his blog today about a better Doctrine 2 module he’s created for use with Kohana framework-based applications.

Since releasing my original Doctrine 2 module for Kohana 3 (found here), I’ve done a bit of reshuffling of folders and added some additional features from my old Doctrine 1.2 module. Due to the extent of modifications, I decided to put up a new post with some added information on how to use the new module. For the impatient ones out there, here’s the download link:
Doctrine 2 Module for Kohana 3

He spends the rest of the post explaining the structure of the module, how to get it installed and working and some sample schema files (for Product and Serial tables in yaml) you can import and test with.

Chance Gracia came across an interesting feature/bug when writing up unit tests for his application with PHPUnit. He was throwing an exception from a mock object and based on his annotation the exception is caught no matter the type.

Anyone who has worked with PHPUnit has most likely worked with expected exceptions and mock objects. The nice thing about working with expected exceptions is that we have access to a handy @expectedException annotation. I’ve gotten into the habit of using this for exceptions my fixtures should throw but also for when I’m using a mock object to verify a method call.

Some sample code is included to show his problem – a mock object is created for the “foo” class and a test to see if an Exception type is thrown is included on it. The problem is that the exception thrown isn’t of type Exception, but of type “foo_exception” and the @expectedException annotation tells it to look for the Exception type. Because of this unpredictable behavior, he suggests not using annotations for these sort of tests or it could lead to false positives.

Sudheer Satyanarayana has provided a handy cheat sheet for those using the Zend_Date component of the Zend Framework listing the default values of the constants it provides.

Date and time handling in general is a problem in programming. For PHP programmers, there’s a good library out there that performs all the difficult tasks and provides convenient APIs. Zend_Date has several constants defined. It is good to know what each one of them represents.

You can either come back to this post if you need a reference or you can download the PDF and have it right at your fingertips.

In this new post to his blog Robert Basic takes a look at what he calls a “real gem” in defining the requirements of his application – PHP_CompatInfo.

Last night I was pondering how nice would it be to have a tool of some sort, that would simply spit out what version of PHP does my app require. Something like: here are my .php files, what PHP version and/or extensions do I need for it? First I thought about jumping right in and writing it myself, but hey, this kind of a tool sounds way to useful not to be written already! After a bit of a googling there it was: PHP_CompatInfo. A nice PEAR package that can tell me everything I want about my code and even a bit more.

He includes a code snippet showing it in action. It’s a basic example that defines the driver type to use, options and the directory to parse through (using parseDir() naturally). Other output formats are available too like CSV and HTML.