The Zend Framework team announces the immediate availability of Zend Framework 1.10.8 , our eighth maintenance release in the 1.10 series. This release includes around 22 bug fixes. A special reminder to those users of Zend_Service_Twitter , please ensure you upgrade to 1.10.6, 1.10.7, or 1.10.8 ASAP. These releases introduce a change in the Zend_Service_Twitter API that enforces the use of OAuth by default when using methods that require authentication. The change was introduced to help prepare Zend Framework users for the Twitter OAuthcalypse scheduled in 6 days from now on August 31, 2010 . (If you cannot upgrade, there are other ways to integrate Zend_Oauth with Zend_Service_Twitter .)

My latest book on Git, Pragmatic Guide to Git goes on sale today! I'm really excited about this new book. It's the culmination of a year's worth of work on an entirely new format for Pragmatic Bookshelf.

From today's announcement:

Last summer, Pragmatic author Travis Swicegood proposed a new kind of book covering the popular version control system, Git. We thought it was a good idea–so much so that we've launched a whole new series in this format. Check out the details on the series below, as well as Travis' new book, Pragmatic Guide to Git, now available in beta.

Having a good idea is cool. Having a good idea that you can get other people excited about too is even better. I thought I was onto something interesting when I pitched the idea to Prag, and so did everyone else there. A year later and here we are with an entire new series lined up.

Here's the quick description of the new book:

Need to learn how to wrap your head around Git, but don't need a lot of hand holding? Grab this book if you're new to Git, not to the world of programming. Git tasks displayed on two-page spreads provide all the context you need, without the extra fluff.

Article originally from rooJSolutions blog After what seems like forever in design and migration, I've turned on the roojs.com and roojs.org domains, I'm slowly in the process phasing out my old company name - AK BK Consulting, which is now rooJSolutions

David McCandless gave an excellent TED talk on visualization of data. The take-away quote from this was:

Data is the new soil

I love that line. Data gives rise to new ways of understanding something. Presenting something spatially gives you the ability to put it in context more quickly than trying to explain the context.

Take 20 minutes, this video is well worth the time investment:

Zend Framework extension, which provides classes for using and implementing Gravatar's services and features. It consists of HTTP client for performing Gravatar Profile Requests, client for Gravatar XML - RPC API and view helper for rendering Gravatar image URL s.

I don't want to be too alarmist, but try running the following PHP code on your system:

With luck, you'll see “Wednesday 1 February 2040 00:00″ displayed in your browser. If you're seeing a date in the late 60's or early 70's, your PHP application may be at risk from the Y2K38 bug!

What's the Y2K38 bug?

Y2K38, or the Unix Millennium Bug, affects PHP and many other languages and systems which use a signed 32-bit integer to represent dates as the number of seconds since 00:00:00 UTC on 1 January 1970. The furthest date which can be stored is 03:14:07 UTC on 19 January 2038. Beyond that, the left-most bit is set and the integer becomes a negative decimal number — or a time prior to the epoch.

Yes, it's 28 years away and I'm sure many of you think it's ridiculous to worry about it now. However, developers thought that way about the Millennium bug the 1970's and 80's. Also, any web application which handles long-term future events could be at risk. For example, a typical mortgage runs for 25 years. Pensions and savings plans can be far longer.

Will 64-bit save us?

Probably. If you're using a 64-bit OS with a compiled 64-bit edition of PHP, your application shouldn't be affected. I'd recommend you test it, though. A signed 64-bit number gives a maximum future date which is 21 times greater than the current age of the universe — 292 billion years, give or take a day or two.

You can probably sleep at night if you're convinced your financial application will always be installed on a 64-bit system.

Are there alternative options?

Fortunately, PHP introduced a new DateTime class in version 5.2 (experimental support was available in 5.1 and be aware that some methods were introduced in 5.3)…

DateTime does not suffer from Y2K38 problems and will happily handle dates up to December 31, 9999. I might have paid off my mortgage by then!

It may not be worth upgrading existing applications, but you should certainly consider the DateTime class when planning your next project.

Has you experienced Y2K38 problems in your application? How did you fix it?

Related Posts

How To Create an Offline Web Application

Sat Nav – the Killer Application for Offline Web Technology?

PHP is Fifteen Today!

Related posts brought to you by Yet Another Related Posts Plugin.

I confess that i've been hiding under a stone for quite some time when it comes to contemporary html stuff, for most of the things i'm doing on the presentation level even good old html 1.0 would be sufficient if it weren't for the occasinal tabular data ...

So while i know CSS in theory i've never really looked into the black magic of doing CSS layouts and stuff ... until now ...

What i'm up to right now was to produce a small series of step by step examples on how to use OpenLayers to present customized OpenStreetMap based maps, and for that i wanted to have a simple layout like this:

Continue reading "Is it really that hard ...? (or how i finally learned to hate CSS)"

A few years ago I switched to an old fashion safety razor and haven't looked back. The latest entry into the razor market has reaffirmed my decision as the right one.

The new Pro Glide from Gillette only costs less than $10 to purchase. Good deal, right? Nope. The replacement blades cost $3-$4 each! Assuming you get a few weeks out of each blade, you're looking at paying between $6 and $10 every month to use this razor blade.

It's a great deal—for Gillette.

I use Merkur razor. I paid a lot, comparatively speaking, up front but I can buy better quality razors for less than $0.75 each. They last a lot longer and I end up with a much better shave.

I view the trade-off here as the same one you have to look at when deciding what framework you choose to develop your code in. There are a lot of frameworks that provide a lot of help getting off of the ground. It almost seems too easy.

Write your on custom blog in 5 minutes? Sure! Want to have a RESTful API? Add a couple of classes, some new routes, mark as complete.

Look at the framework and read some of the comments from its detractors. Those complaining generally have one of two problems:

They're going to complain about anything, they're just ranting. Ignore these people.

They've hit a legitimate pain point in the framework where they deviated too far from the intended use. Pay attention to what these people are talking about.

If you're application is significantly complex, no off-the-shelf framework is going to do everything you need it to. Some frameworks may even get in the way. Make sure you realize the trade-offs before you commit.

What makes a good framework?

The best ones serve as scaffolding—in the original meaning.

… a temporary structure used to support people and material in the construction or repair of buildings and other large structures.

Put another way for software development:

… helps you ramp up quickly, then gets out of the way.

Historically, frameworks manage the first part of this well. That's where they shine. It's the last part that they've had a problem with.

Django manages both of these well. My one complaint with it is that it manages the latter part better than the first. There's a lot of boilerplate needed to get started, but I can live with that. When my applications outgrow Django, removing Django from the equation is easy with one exception.

Models.

Models are like your razor's blades. Without blades, your razor doesn't shave; without models your application doesn't have any data to work with. The fix I've found works best for me is to keep my models then and put all of my logic for operating on them in other areas of the code base.

This separation helps me keep my business logic portable. I might be using the cheap route to get started, but the heavy lifting goes with me if I decide something else is a better fit.

jQuery is a popular JavaScript library which is used by many developers and applications. While using jQuery you need to write less code, writing functions is less complex and there are a lot of plugins you can use for free in your web application. Even if you code everything by yourself, you need only a few rows of code to create nice and powerful features for your website. If you're in hurry check the jQuery demo page.

Populate select menus with jQuery and Ajax

One of the most powerful jQuery function is the Ajax Suite. This example shows how-to populate a second select menu based on the option from the first select menu.

Just in case we have this select menu with the main categories:

If someone has changed the value for this select menu, we want to show the equivalent menu inside the span element with the ID “subcat”. To do this we use this jQuery snippet that makes an Ajax request to a PHP file called “getSubCat.php”. After the select menu is changed a loading image will show up (in case of slow Internet connections), the PHP script is called and the sub-select menu becomes visible.

Truncated by Planet PHP, read more at the original (another 29362 bytes)

HipHop for PHP, the source code transformer that turns PHP code into C++ code that can then be compiled with g++, can also be used for static code analysis to find problems in PHP source code.

sb@vmware Money % hphp -t analyze --input-dir . running hphp... creating temporary directory /tmp/hphp_Zz7AXg ... parsing inputs... parsing inputs took 0'00" (20 ms) wall time inferring types... inferring types took 0'00" (10 ms) wall time saving code errors, dependency graph and stats... all files saved in /tmp/hphp_Zz7AXg ... running hphp took 0'00" (208 ms) wall time

The script below takes a CodeErrors.js file (which is generated by hphp and in the example above is saved to /tmp/hphp_Zz7AXg) as its input and print an XML document in Checkstyle's format (the same XML format that is also used by PHP_CodeSniffer, for instance). This XML logfile can then be used with Hudson, for instance, in a continuous integration context.

I'm slightly surprised but mostly wildly excited to announce that I'll be the keynote speaker at the PHP North West Conference in October. It is held in Manchester in the UK, which is about an hour from where I live in Leeds, so it is definitely my "home" conference, and this makes me even more excited since I know I'll be in such great company!

The talk is Teach A Man To Fish: Coaching Development Teams and really it's about how a little investment of time or effort can build your existing team into something better - and how that team can then sustain its improvements and continue to raise its performance and the game of the individual team members. All in all I am pretty excited about this talk - as with most of my conference talks, it started life as a rant in a bar, and I'm now excited to be preparing it for a more formal setting!

The event itself is a must-see for anyone doing PHP or allied technologies that can get there (Manchester is pretty central and pretty cheap - if you're in the UK, you have no excuses!). It's a Saturday event, 9th October 2010 and tickets are on sale - the Early Bird prices are still available and we've held the prices as low as possible again, we don't need frills, we just want lots of people to be able to join in! I hope to see quite a few of you there, let me know if you're coming :)

This month Hans Zaunere and Nate Abele will give us a look at the new features in PHP 5.3 and how they're used in production today. Specifically, these NYPHP regulars will cover three new major language features: namespaces, late static binding, and closures. RSVP now for the meeting at IBM in midtown Manhattan on Tuesday [...]

In case you missed it, the PHP team has just released 5.2.14, which effectively ends active support for the 5.2 branch1:

This release marks the end of the active support for PHP 5.2. Following this release the PHP 5.2 series will receive no further active bug maintenance.

The logic behind this decision is… puzzling.

Several large projects—WordPress and Drupal among them—recently announced that they intend to push support for 5.2 into their products with their next major release. For example, Drupal 7 will accept 5.2 features, and the WP folks are just working on EOL'ing their support for PHP 4.

This means that a large number of people are just beginning learning, using and stress-testing PHP 5.2. Remember—these projects have very large user bases, so even moving a small percentage of adopters over to a different platform means a big shift. Perhaps—just perhaps—it might be better to reconsider canning 5.2. If, from a technical perspective, the move from 5.2 to 5.3 is an easy one, there is a huge psychological barrier to finally adopting 5.2 only to have it yanked from under your feet.

The real issue at hand, however, is the fact that these large user communities are not engaged in the PHP world, and vice-versa. Ignoring the hundreds of thousands of Drupal and WordPress integrators and developers is bad for both PHP and for those products; we should, instead, try our best to open a dialogue between all the communities that are centred around PHP and ensure that everyone's interests are properly represented.

This is not to say that the fact that WP has only now decided to move to PHP 5.2 should necessarily affect the progress of PHP, nor that the PHP developers should take a “we don't need you” attitude toward projects that are based on the language. Ultimately, it's up to these projects if they want to actively contribute back to PHP or not, and that is the only way for them to effectively affect the development of the language itself.

However, PHP development is too unevenly connected to downstream adopters. Some—particularly framework makers—have an unusually high level of participation in deciding how PHP evolves, and that needs to change.

At least year's WDC, a small conference organized by Microsoft, I made this very same point and managed to bring a room full of developers into complete disarray in less than five minutes—which means that, in addition to the fact that my ability to drive a bunch of people up the wall in no time flat has not changed over the years, there is plenty to talk about.

[Update: the latest 5.2.x release is 5.2.14, not 5.2.11 as I originally stated. Thanks to Ilia for pointing that out.]

I have been invited to attend the 5th Annual Google Test Automation Conference, better known as GTAC, in Hyderabad, India in October. I am very much looking forward to discuss cutting edge challenges in test automation and evaluate potential solutions, especially with this year's focus on testability.

Another thing I like about this year's GTAC is that the participants are responsible for selecting the presentations for the conference. Here is my submission:

Challenges in Unit Testing PHP Applications

According to TIOBE, PHP is the most popular programming language after C/C++ and Java. The language has made strong inroads into large-scale, business-critical Web systems. In the six years since the release of PHP 5 -- which not only kickstarted the development of PHP-based frameworks for Web development but also the development of tools for dynamic and static testing techniques -- the PHP community as a whole has developed an increasing interest in developing software that delivers the best possible quality.

When PHP developers start to write unit tests they rarely find themselves without any constraints that are imposed by prior work of less than optimal quality. It is a well-known fact that writing unit tests for legacy code is hard. In the case of PHP it can be even harder: the legacy code has not only been written without testability in mind, but it may have been written for earlier versions of PHP that encouraged practices that make the code next to impossible to unit test.

PHPUnit, the de-facto standard framework for unit-testing PHP code, has some unique features not found in other xUnit test frameworks that allow the testing of untestable code. While developers should not use these features (as they are not required when writing tests for testable code), these features ease the pain of writing tests for legacy code and thus help developers get started with unit testing before they refactor the code for testability.

This session, presented by the creator of PHPUnit, highlights the challenges developers are facing when unit testing legacy PHP code. Some of these challenges will be familiar to developers that use other programming languages such as Java but they will see a new perspective on the problem and different approaches to solve it.

Although I am hoping, of course, that my submission will be accepted by my peers, I know that GTAC will be valuable for me even if I do not get to present: the "hallway track" of GTAC 2008 was amazing.

When you look at the list of changes for PHPUnit 3.5, you will see that many of them deal with refactoring to components. Here is an overview of these new components:

• PHP_CodeCoverage

  The collection, processing, and rendering of code coverage information has been factored out into a separate component. A bit more information can be found here.

• PHPUnit_MockObject

  The functionality to automatically generate an object that can act as a test double for a specified original class has been factored out into a separate component. Do not worry, getMock() and related methods will work just as they did in previous versions of PHPUnit. The refactoring, however, makes the usage of other mock object libraries (such as Mockery or Phake, for instance) easier.

• DbUnit

  The database testing functionality that is provided by the DbUnit extension and the respective DatabaseTestCase class has been moved to a separate component. Michael Lively Jr, the author of DbUnit, is now able to make releases of the database testing extension on a release schedule that is separate from PHPUnit itself, meaning that I will be even less involved in its development than I have before.

• PHPUnit_Selenium

  SeleniumTestCase, the Selenium RC integration for PHPUnit, has been moved to a separate component to allow a release cycle separate from PHPUnit itself.

• File_Iterator, PHP_Timer, Text_Template

  Utility methods to collect files and report resource usage as well as a simple templating mechanism have been moved to separate components so that they can be reused by other tools such as phpcb, phpcs, phpcpd, and pdepend.

WooThemes's official Twitter account, in response to a request on whether a site giving away all their GPL'ed themes1 for a low fee is in breach of the license:

[I]t's legit, but we don't promote it as the themes are outdated & may contain malicious code.

So that's it, then: the GPL is great until someone copies your commercial work and openly resells it, at which point making subtly unfounded allegations is the best way to save face.

Time for a new adventure. Last monday, my wife Marjolein and I visited the local Chamber of Commerce to register our new company: Ingewikkeld. We're both doing completely different things, but we've decided to capture both into a single company because it saves us a shitload of administrative work, and since we're married anyway, it doesn't really matter. I (could you have expected something else?) will be offering (PHP) development, consultancy and training services, and my wife will be a baby wearing consultant.

Midgard 8.09 is an industrial CMS that is now in Long-Term Supported stage, with the community maintaining it until 2013. As we all know, performance is a feature, and with a CMS framework that has lived through many changes including transitions from PHP4 to 5.2 and from Classic Midgard era to the modern APIs, there is a lot to do.

For the next 8.09.10 release we decided to put quite a bit of efforts into performance tuning, with some excellent work done by Content Control to simplify ACL handling and cache navigation information. As you can see, the result is quite impressive:

What is left to be done is some work with the multilingual content database queries. After that we should be good to go with what is probably the fastest Midgard1 ever.

Modules are natively supported in Zend Framework, but their implementation is not conducive to flexible autoloading nor the use of namespaces in PHP 5.3. There may be a few contributors out there that will defend the current implementation of module autoloading, but throughout the development lifecycle of the current Model-View-Controller implementation in the framework, poor design decisions have made working with modules less flexible and more frustrating.

The First Problem

The problem stems from the initial decisions about the naming conventions for directories and classes for controllers and views. The convention that controllers would be stored in a directory called "controllers" and views would be stored in a directory called "views" throws any attempt at dynamic autoloading immediately out the window. Instead, this single design decision served to ensure that all attempts to autoload consistently-named module-based PHP classes would require some sort of explicit configuration. As a result, many developers decided to put their classes such as forms, models, and mappers into separate libraries — not very modular, eh?

The Official Solution: AKA The Second Problem

Enter the current implementation of "resource" autoloading. This greatly anticipated addition to Zend Framework was to solve our insatiable hunger for module-specific classes (hereto referred to as "resources"). The immediate effect was our modules could finally autoload our most used module resources. Unfortunately, every single type of resource has to be explicitly defined for each module! To help make this configuration easier, a "module" autoloader was added to Zend_Application that pre-configures common resources such as models and forms. But think of that for a second. An entire class was added to the framework with no other purpose other than pre-configuring options. If that doesn't scream red-flag, I don't know what does.

Let's Talk Solutions

I am extremely opinionated, and I could probably rant for hours about a topic like this, but I digress. Instead, let's look at a proof of concept that I implemented:

http://github.com/epixa/Epixa

The premise is pretty simple: modules should be nothing less than near-independent libraries of code. When modules are treated like libraries in their own right, they gain all of the flexibility and speed that we get from autoloading library files. Better yet, the main autoloader in Zend Framework can handle the autoloading all on its own, which means your module resources can be namespaced.

With extensions in that library, you can achieve a directory structure like the following with little to no configuration:

What We're Missing

This is currently to serve only as a proof of concept, so there is still plenty that can be added. For instance, while I updated the dispatcher so controllers are namspaced like "BlogControllerPost", I did not remove the class loading logic from the dispatcher itself. To separate concerns, the controller class loading should be passed off entirely to the autoloader.

The library also still leaves a lot to be desired when it comes to efficient module bootstrapping and plugin loading. I'll post improvements in both of those regards along with module dependency loading in the near future.

In the meantime, I would love feedback about this approach. If I can refine it a bit further, I plan to campaign for its inclusion as the standard module setup in Zend Framework 2.

Remember pkTail and pkStart and pkTheme?
Today, I'm pleased to introduce pkSFX to you.

All these tools are shipped with the pkTypical pack available at sourceforge.

Well. Imagine that you have written a new application, or a new version of that app, and now is the time to deploy... This is going to be the easiest task of the project, thanks to pkSFX - Yet Another Setup Program!

Read more...

read more

Daniel Stenberg, one of the primary authors of the libcurl library on which the PHP cURL extension is based, was kind enough to comment on and clarify a recent blog post of mine regarding web scraping using the PHP and cURL. He later sent me a tweet to invite me to a new mailing list for web scraping enthusiasts just before tweeting a public invitation. In addition to the mailing list itself, the web site also has links to books (including my book) and popular tools related to the subject. I think this is awesome and I encourage anyone with an interest in web scraping, professional or recreational, to join.

Update: To be fair, a great deal of inspiration for this post came from Ed "Funkatron" Finkler and his session at phpWorks 2008 Picachu pitch-at-ya peek-at-you lightning talk called "Users are Assholes" and later by Matthew Weier O'Phinney's lightning talk called "How to get kicked off my Project." Thanks for the fodder guys!

On all sides of software development, there are annoyances. Some of them go beyond annoyances and into pet peaves. Some of them go beyond pet peeves and incite open war within projects and communities. After witnessing a number of these rants - from developers and non-developers - and even sharing a few myself, I thought maybe I could make the situation better.

Therefore, I present here for comment:

The Ten Commandments of Open Source Software.

0. Thou shalt not ask questions without basic research including documentation and the Google.

I. Thou shalt realize that most developers work on passion and freetime. Thou are not paying them.

II. Thou shalt not criticize code and architectures before seeking understanding.

III. Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

IV. Thou shalt apply patches and updates in a timely manner. Further, thou shalt have a vague idea of when the next release is due-eth.

V. Honor thy developers and designers.

VI. Thou shalt include specific error messages and screenshots when thou hast problems. Thou stating "thy software sucks" is not helpful and angers the Funkatron.

VII. Thou shalt not murder.*

VIII. Thou shalt not copy without respecting both the license and the terms within.

IX. Thou shalt not covet the features and functionality in thy neighbor's software.

Did I miss any?

* No, I'm not kidding.

Monte Carlo simulations are a handy tool for looking at situations that have some aspect of uncertainty, by modelling them with a pseudo-random element and conducting a large number of trials. There isn't a hard and fast Monte Carlo algorithm, but the process generally goes: start with a situation you wish to model, write a program to describe it that includes a random input, run that program many times, and look at the results.

In each case, you're taking a pot shot at the result, and over many iterations you should get a broad picture of the probabilities of certain outcomes. If these match observations of the real situation, your model is a good one. Alternatively, if you can achieve certain results through randomness that others put down to some other factor, perhaps there is more chance in the real situation that others have expected.

As an example, lets imagine visiting an SEO expo, filled with 10,000 SEO experts. Now, 20% of the experts are creative copywriters and link profile experts who will help to make your site more usable, more readable, faster, and help drive traffic from disparate sources as they improve your search profile. The others are clueless keyword stuffers and link spammers, who will turn your site into an real mess.

However, a given rank on a results page is dependent on an awful lot of things - how the site was originally, what other sites are doing, changes to google's algorithms, temporary network and server effects and so on. Because of that, sometimes the bad SEOs get their sites onto the front page, and sometimes the good ones don't. Let estimate that the good SEOs get their site onto the first page under a given term two thirds of the time, while for the bad SEOs it's only one third of the time. Now, whichever SEO you ask claims to be in the good category, of course, so you ask to see the results for the last 5 sites they optimised. If they are all on the first page, can you be confident you've got a good one?

We can set up a monte carlo simulation for that by simply looping over the five sites, and seeing which ones succeed each time, by chance, and which fail. Starting with our total 10,000 SEO population, how many good vs bad SEOs do we expect.