Feed aggregator

Being the verbose kind, I guess I will put in a summary at the top leaving the original post below for everyone to read all the little details. Essentially the summary is that I (and many other core developers) agree that HEAD/trunk in its current form was stalling future development on PHP. Jani indirectly jump started the discussion of moving this stumbling block out of the way by essentially doing two commits that violate the most fundamental rules of PHP development (and common sense courtesy) we have. I am worried that this will lead to confusion in the user base and other seem to think that the "ends justify the means". I also think that we need clearer processes to make it easier for new developers to have a clear path to follow in order to get things done in PHP.

Full story:
So this all requires a bit of background. I still remember my first contact with a PHP core developer. I do not quite remember the year, but it was quite some time ago. Anyway Jani was great, we filed a bug report on the imap extension. He fixed the bug in no time. IIRC we also ended up sharing a room at the second IPC in Frankfurt I attended. I think only a few years later I realized that Jani is the same guy a lot of people were complaining as being rude. But I guess few of these people realize how much time Jani has spend on verifying bug reports and what a tedious job this is, especially since most bug reports are quite low on the actual relevant details and come with a "fix my code for me, now!" attitude. In other words, I get along fine with Jani and I have great respect for his contributions to PHP.

Next piece of background. I am also one in the long list of people that has made a fool of himself by predicting a release of PHP6 in about 18 to 24 months (quite a few people have given this prediction over the past 3-4 years I guess). I have also been one of the people that has tried to motivated people at various times to finish those last 2% that seem to be missing to complete PHP6 in terms of functionality. As such I have opposed a PHP 5.4 because I felt its time to focus on finish up PHP 6 which we have promised people for so long. After releasing 5.3.0 I was hoping things would happen. But last weekend I came to the realization that we have waited long enough. That even if PHP 6 would be unicode bliss (at least in terms of features, probably not in terms of performance), the fact of the matter is that in all of the many years nobody put in the time to finish it. This imho is an indirect proof that the approach taken apparently does not hold enough merit to the world in general. Furthermore looking at internals since last summer it has been more dead than ever: PHP 6 aka HEAD aka trunk had become such a motivation killer that nothing was happening.

At the same time I knew that suggesting to move trunk to a branch and copying 5_3 to trunk would cause a lot of confusion. Not only among those reading internals, but also that this would quickly make it to the news sites of the world. Call it politics, marketing or just an unwillingness to cause thousands (millions?) of PHP developers distress and uncertainty, but I figured it would be better to propose this with a semi solid plan and giving a number of PHP core developers the heads up that I will bring this to the list, so that they also could prepare themselves. So I started talking to people offlist, either in person, via phone, via IRC/skype or via email with the full intention of going to the list no later than the end of this month, ideally sooner rather than later. I should also note, I do not code C, I also do not consider myself a unicode expert. So if I wanted to present a plan, I obviously needed to talk to people to get my facts straight.

Anyways, this week Jani decided to commit a patch. I guess I didn't mention one more piece of background. Jani had asked to get this patch into PHP 5.3 during the pre alpha stage, but at the time Johannes and I (I was co-RM back then) felt that the patch hadn't been tested enough in HEAD and that while we knew the patch fixes several bugs, we felt the risk of introducing new bugs was too high, especially since Michael who wrote the original patch for HEAD was not always around to fix things. Johannes had tried to get the patch into 5.3 six months earlier, but at the time nobody had time to do the work. So we decided to stick with the known bugs, instead of fixing them and risking new bugs in a very core component of PHP close to going alpha. So basically Jani committed a huge patch into a stable branch, without talking to anyone about this, despite knewing full well that the RM had specifically vetoed this patch in principle. Furthermore the patch from my understanding even breaks the ABI which makes the patch even more a no go.

No

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

I gave my second talk at #ConFoo today, this one was on Searching without the Database. This talk was based on a situation at work where I replaced a MySQL search solution with a Sphinx + Memcached solution for higher performance. If you're interested, here's the slides: Search without the DB - ConFoo 2010.pdf.

If you attended my talk, you can rate it on the Joind.in Page

Matthew Weier O'Phinney as a new post to his blog today looking at a few "do's" and "dont's" when it comes to working with module boostraps in your Zend Framework applications - an apparently somewhat confusing topic for several developers out there.

In Zend Framework 1.8.0, we added Zend_Application, which is intended to (a) formalize the bootstrapping process, and (b) make it re-usable. One aspect of it was to allow bootstrapping of individual application modules -- which are discrete collections of controllers, views, and models.

He talks briefly about why module boostraps are run on every request (getting into some detail on Zend_Application), how you can properly set up your boostrapping process and how you can use plugins to initialize only the things you might need and, as he openly admits, that there's just not a really good way to handle this sort of module funcionality.

Pablo Viquez has put together something that all of the Windows-based Zend Framework developers might find very useful during their next offline (or online, really) development session - a Windows Help file version of the Zend Framework manual.

As you might now, you can view and download the Zend Framework reference manual from the Zend Framework site and download it from the download section, however what I wanted was the Windows compiled version of it (CHM file). In order to get this version you need to compile the documentation, after running into some small issues, I manage to do it, and to save you some work.

He only had to fix an issue with one XML file to correct some escaping in the Zend_Feed_Writer.xml and zend.feed.writer.html files. You can download both the English CHM and the Spanish CHM files depending on your needs.

With the releases in the PHP 5.x series (5.3 and now a newly branched 5.4), people have been left wondering about PHP 6 and the promised Unicode support it will include. Development on that branch had all but stalled out and things weren't looking too good for the method of introducing full Unicode support to the language. Johannes Schluter has some good news, though - the effort has been restarted and a new approach has been decided on.

Yesterday the stagnation created by the situation has been resolved and it was decided that our trunk in svn will be based on 5.3 and we'll merge features from the old trunk and new features there so that 5.3 will be a true stable branch. The EOL for 5.2 has not yet been defined but I suggest you to really migrate over to 5.3, which usually can be done with very little work, as soon as possible.

Discussion are being made about which type of Unicode support will actually be introduced with a "string class" wrapper gathering some support behind it to provide an alternative to the current string handling.

I got shortlisted for Best Technology Blog in the Irish Blog Awards!

Ian Christian has an informative new post for the Symfony developers out there. He's figured out a way to handle uploaded files with Symfony's admin generator relatively easily, changing the filename option.

When a file is uploaded using sfForm in the admin generator, by default the filename that's used is a random string, which can look bad in URLs. If you want to change this, it's not immediately obvious how - but it is incredibly simple.

The Symfony project does have some documentation on the topic, but it's not the easiest to read. It basically boils down to is defining a function in your extended class based on the name of the file where you can change the name however you'd like. Code snippets are included to make the point a bit more clear.

Jani Hartikainen poses an interesting question on his blog today - is it more correct for a function, having failed at its job, to return a value of throw an exception.

You have created a nice, well written function, but you realize you forgot something: The failure case. What should a function do when it fails? There are two schools for this - the "throw an exception" school and the "return an error value" school. But which of these is the correct approach?

He suggests that this debate has stuck around from the time when there weren't exceptions in several popular programming languages and that returning the value was the only valid way. He touches on what an exception condition is (with a few code examples) and situations where each choice might be the right way to go.

Brian Swan has posted the second part of his series looking at the difference between the MSSQL driver and the SQLSRV drivers for connecting to SQL Server databases from PHP (part one can be found here). He gets a bit more detailed in this second post.

I'm aiming to provide a high-level comparison that you might use if you were considering moving to the SQLSRV extension, but I think there is also some interesting information if you are just curious about the differences. [...] In cases where a short note wasn't enough (and there were several of these), I've provided relevant links to topics in the SQLSRV documentation.

He talks about things that one offers that the other doesn't, like prepared statements (sqlsrv) and working with stored procedures (mssql). He also mentions error handlng, persistent connections and scrollable cursors in sqlsrv. Finally he gets into a one-to-one function comparison of the two drivers with the sqlsrv function list coming up a bit short compared to the features of the more recend (and well-supported) mssql driver.

Phil Sturgeon has posted a look ahead at everything you need to know about the next version of the popular CodeIgniter framework, version 2.0.

It has been 6 months since the last CodeIgniter minor update and 18 months since the last major update. Through all this time we were given no information about the next release of CodeIgniter, but finally 2.0 is on the way.

Because of the Ellis Labs move to Mercurial for its version control system (and BitBucket for the repository), it allows for a more "social coding" environment where it's easier for developers to just fork and contribute. Other major changes for this upcoming version include the fact that PHP4 support will officially be deprecated, driver libraries, application "packages", a smaller reserved controller name list and the dismissal of plugins.

Check out the Changelog for more detailed information as things are updated.

Yesterday, I announced the release of the 1.0.0 stable version of the Solar Framework for PHP on our mailing list. (I tagged the release four days ago on Monday, but wanted to time the announcement to go along with my Solar presentation at ConFoo.) You can see the change notes here. The highlights are: Added [...]

Popular posts from PHPDeveloper.org for the past week:

• Brian Swan's Blog: What's the Right Way to Prevent SQL Injection in PHP Scripts?
• Brian Teeman's Blog: Who is the Joker in the Joomla pack?
• PHP.net: PHP 5.3.2 Release Announcement
• CatsWhoCode.com: Getting started with CouchDB: a beginner's guide
• Matthew Weier O'Phinney's Blog: Responding to Different Content Types in RESTful ZF Apps
• Zend Developer Zone: How to avoid Identity Theft in Zend Framework with Zend Auth
• Alvaro Videla's Blog: Erlang as a Fast Key Value Store for PHP
• Site News: Job Postings for the week of 02.28.2010
• Template Monster Blog: It's coming! WordPress 3.0 - Pros and Cons
• Kavoir.com: Just Hashing is Far from Enough for Storing Passwords (Dictionary & Rainbow Attacks)

Yesterday was a quite thrilling day for the PHP development team and led to some imprecise news articles so let's take a look at what happened: Over the last months many of the core contributors agreed that the current approach to bring Unicode into PHP's engine wasn't the right approach and a good thing would be to rethink it from the start. By a provocative move of one contributor the stalled situation got some more movement and Rasmus declared the current implementation to be discontinued to restart.

The past

When the foundation of what should have become PHP 6 was created a decision was made to use UTF-16 as internal encoding for "everything" inside the engine. The choice for UTF-16 was made due to the fact that PHP 6 would use the ICU library which is focused on offering UTF-16 string functions. By using UTF-16 as default encoding we'd have to convert the script code and all data passed from or to the script (request data, database results, output, ...) from another encoding, usually UTF-8, to UTF-16 or back. The need for conversion doesn't only require CPU time and more memory (a UTF-16 string takes double memory of a UTF-8 string in many cases) but makes the implementation rather complex as we always have to figure out which encoding was the right one for a given situation. From the userspace point of view the implementation brought some backwards compatibility breaks which would require manual review of the code. These all are pains for a very small gain for many users where many would be happy about a tighter integration of some mbstring-like functionality. This all led to a situation for many contributors not willing to use "trunk" as their main development tree but either develop using the stable 5.2/5.3 trees or refuse to do development at all.

The present

Yesterday the stagnation created by the situation has been resolved and it was decided that our trunk in svn will be based on 5.3 and we'll merge features from the old trunk and new features there so that 5.3 will be a true stable branch. The EOL for 5.2 has not yet been defined but I suggest you to really migrate over to 5.3, which usually can be done with very little work, as soon as possible.

The future

Right now we're starting different discussions to see what kind of Unicode support we really want. Many contributors react positive on a proposed "string class" which wraps string operations in Unicode and binary forms without going deep in the engine. In my opinion such an approach might also be a way to solve some of the often criticized inconsistencies in PHP's string APIs without the need to break old code. (new code uses the new class, old code the old functions) But that idea is far from a proper proposal or even the implementation, current status is about refocusing the development and get the requirement and design discussions going. By that it's a bit early to decide whether the next version of PHP will be called PHP 5.4, PHP 6 or maybe even PHP 7.

PHP is alive and kicking!

I’ve dumped the old hosting provider, and move the www.fornax.net server to Slicehost. So far, their service and support has been excellent!

Hopefully, everything was migrated across correctly, and all of the RSS feeds still work. Apologies in advance if this post ends up anywhere it should not — please let me know if that’s the case and I’ll be happy to fix it!

On Tuesday, Marco Tabini told us that we were doing it all wrong. He makes some fantastic points about software development overall, and about the state of our profession. This article’s point isn’t to be a rebuttal, but a corollary to what he had to say.’t Marco is right: every one of us is “doing it [...]

In an opinion piece posted to the php|architect site Marco Tabini suggests that we (as developers) are doing it wrong as we move further and further away from the pragmatic side of programming into the abstract.

No matter how advanced the techniques that we use, there is always something that we could be doing better. [...] Which one is right? The real problem is that the answer to that question is, "yes." That's because it lacks a specific context in which it can be inserted.

He suggests that, in our quest to figure out what the perfect case for any situation, we stop focusing on the practicality of writing applications to accomplish goals. Sometimes it's not about getting the right theory behind the code - sometimes it's just doing it.

I see a number of questions regularly about module bootstraps in Zend Framework, and decided it was time to write a post about them finally.

In Zend Framework 1.8.0, we added Zend_Application, which is intended to (a) formalize the bootstrapping process, and (b) make it re-usable. One aspect of it was to allow bootstrapping of individual application modules -- which are discrete collections of controllers, views, and models.

The most common question I get regarding module bootstraps is:

Why are all module bootstraps run on every request, and not just the one for the requested module?

To answer that question, first I need to provide some background.

Continue reading "Module Bootstraps in Zend Framework: Do's and Don'ts"

Zend Framework 1.10 sports a ton of new features, as well as completely revamped online documentation. In this webinar, Matthew Weier O’Phinney, Framework Project Lead, and Ralph Schindler, Zend Framework Software Engineer, will present a synopsis of the new features, discuss the new online documentation system and how it’s built, and answer your questions about the new release….

Brian Moon has a quick post that links to a but of code that gives you a progress bar for the command line that's flexible enough to be used in an number of situations.

Was just looking through some code and came across this function I wrote some time ago. If you do a lot of your processing scripts in PHP like we do, you probably need to know what is going on sometimes. So, I made a progress bar for use on the cli. I thought I would share it.

You can see a demo of it here (screencast) or just download the code. Comments on the post also point out the PEAR Console_Progressbar package and the ez Components class for creating a more advanced progress bar.