PHP 10.0 Blog: We are doomed!
451891
In this new post to the PHP 10.0 blog, Stas mentions the "impending doom" of PHP that's been going around the community, including in this post on the TechRepublic site.   He does, however, branch off into something much more interesting that seems to be somewhat ignored by developers - the use of ticks on their code:   This is something named "ticks" - I wonder how many of the PHP developers heard about it and of those how many actually used it. Could it be used for offloading long-running I/O-bound tasks or grouping them together (e.g. so we could wait for DB and HTTP in parallel and not sequentially)? Would there be any use at all for such functionality and if so - how it's supposed to work? I.e. how would you know it's done and how you would collect and use the results?   It's suggested in the comments that it could be used for any kind of application that might need the pseudo-multithreading it offers (including something like scripts needing multiple TCP connections).
475410
On the SitePoint PHP Blog today Troels Knak-Nielsen asks th3e question "what's so bad about the singleton?" For all of its advantages, is there a darker side of the design pattern when it pertains to global variables.   As I have often taken this stance myself, I found it reasonable that I should be able to argue for it, so I'll try to give an explanation. This is also in part a follow-up on my post from last week, in which I present a way to avoid global symbols, without spending much time on why.   He talks about what they are and how they're commonly used - sometimes with some unpleasant side effects because of their use of globals.
611971
Although frankly I really didn't feel the need to read the entire thread, I can tell you that the posting to the PHP 3 mailing list is related to the Smarty Templating Engine back in the day. In fact, I believe this was the original spec Andrei proposed before Smarty even existed. Although I don't remember the exact e-mail, this posting reminded me that there was a point in time I thought exactly this way... quoting myself:
656049
From Dotvoid.com, there's a new posting talking about the continued use of PHP4 by developers and hosting companies and how it's effecting the community as a whole.    It is true that the PHP 5 uptake has been slow. Many internet service providers as well as many developers are reluctant to switch. This is probably, as others have stated, a circular dependency.   As ISP:s are reluctant to upgrade the popular open source projects are hesitant to upgrade. I still think the wrong people are worried. Still PHP 5 is increasing it's share and finally the day will come when version 4 will be considered legacy. Hopefully before PHP 6 is here but not necessarily.    He continues on, talking about what PHP5 is really about (it's not just the objects!) and things that can help make it an easier sell to those still lagging in a PHP4 world - like the Zend Framework.
288007
After long discussions and much opinion being thrown around, Andrei Zmievski points outintegration of namespaces into the upcoming PHP6 release.   Ladies and gentlemen, we have namespaces.   According to the post from  \
761948
A new submission from Ophir Prusak came in this morning about a new article he has posted on his site - Understanding PHP - How did we get here?
575210
Popular posts from PHPDeveloper.org for the past week:PHP-Coding-Practices.com: How I Turned A Slow Array Sort Into A Quick One Using Quicksort AlgorithmZend Developer Zone: PHP Abstract Podcast Episode 4: Planning ProgrammingWeb Development Blog: Save bandwidth with PHProxy and ip2nationJob Posting: Assembleron Ltd Seeks PHP 5/MySQL/Ajax Developers (Reading, UK)PÃ¡draic Brady's Blog: Complex Views with the Zend Framework - Part 6: Setting The TerminologyThe Bakery: Four New Articles - Load Balancing, Request Info, UUID Behavior & Upload ThumbnailsCommunity News: PEAR Installer version 1.6.0 releasedChristopher Kunz's Blog: Building PHP with cURL and libmysqlclient5DevShed: Working with Prepared Queries with PDO Objects in PHP 5Secunia.com: rPath update for gd, php, php-mysql, and php-pgsql
40472
In response to this recent article from the Hiveminds website, Marco Tabini has a few choice words about some of the topics they cover in the article, and cover incorrectly.   Over the last few years, I've made it a point of trying to respond to at least some of the "PHP is dead"-type articles that crop up on the Net from time to time. The latest one comes from Hiveminds and reveals a complete misunderstanding of almost every point it covers.   He notes that though the article seems to be a coherent whole for why PHP is dwindling, it's "based on nothing more than a string of misinformed concepts cobbled together to give the appearance that the author knows what he or she is talking about". Marco comes back against each of the points made in the article, setting things right and eliminating some of the FUD (fear, uncertainly, and doubt) that the Hiveminds article spreads.
629310
You cannot help but like someone like Greg who is honest and humble:  "I am one of the core developers of the PEAR package who has joined the game relatively late... The base PEAR class is one monstrous mistake, and PEAR_Error is pretty close. Everyone knows this. I designed an error class that is much, much more flexible and it is part of PEAR 1.3.1 (PEAR_ErrorStack) - check it out. "  Sadly it's just not true that everyone knows that PEAR class is big mistake (Jeff Moore has more on why PEAR.php is awful).  Given that PEAR is both an important framework and a worthless class, the confusion in names will  definitely  cause the value of the PEAR class to be overestimated. Just read any article on PEAR and you can see what nice words they have to say about the base classes :-(     I once said once that too many PEAR developers were journeymen. This might have offended  some people, but I was trying hard to be diplomatic. I must say that today the PEAR group is definitely more mature, and they have learnt a lot about library design. What would really make my eyes light up  would be an PEAR2 initiative that kept the existing classes, but dropped the bad seeds such as PEAR.php (e.g. the PEAR and PEAR_Error classes).   And in case you were wondering, I do think there's great value in the PEAR DB API. API's are important for interoperatability. For example, ADOdb has a PEAR DB compatibility mode. I would certainly be flattered if PEAR DB had an ADOdb compat mode too :-)
445025
Popular posts from PHPDeveloper.org for the past week:Stijn Leenknegt's Blog: [PHP6] function-return-array idea!GeesNotNerds Blog: Free PHP + Ajax chat appStefan Mischook's Blog: Object Oriented PHP Tutorial Updated - Steps 18 - 22Dave Dash's Blog: SymfonyCampWebDigity.com: PHP geotargeting techniquesEtienne Kneuss' Blog: Late Static Bindings ExplainedDevShed: Handling Static Data with PHP 5PHP-Learn-It.com: Cooking Cookies with PHPMichael Kimsal's Blog: PHP PredictionJob Posting: Steinman Recruiting Seeks Senior Developer (Littleton, CO)
718144
Lukas Smith has posted some ominous thoughts about the future of the LAMP stack in the online development world - specifically asking if the popularity of the grouping could be what might ultimately cause its downfall.   The issue is that there is simply not enough top qualified talent that knows LAMP well enough to hire. Or maybe its just too hard to find them? It seems all the good guys are already hired. As a result companies end up looking for other technology, not because they actually believe that these technologies are any better or worth the license fees that these usually require to be paid up...   He suggests two things that could be possible lead-ins to the "demise" of LAMP - the fact that LAMP just isn't taught along side other languages in school and that, since PHP is only just now getting into the offices of the "major players", there hasn't been enough time to prove to them that PHP has worth in their business.   Be sure to check out some of the great comments on this one.
388816
Popular posts from PHPDeveloper.org for the past week:Dave Dash's Blog: nginx and symfonyZend Developer Zone: The ZendCon Sessions Episode 6: Project Management Methods to Maintain IT StandSitePoint PHP Blog: Tokenization using regular expression sub patternsIT Jobs Watch: Results for PHP Developers in LondonJob Posting: Digital River Seeks PHP Developer (Eden Prairie, MN)Dan Scott's Blog: Oooh...looks like I've got (even more) work cut out for meLeon Chevalier's Blog: Improve website load time by 500% with 3 lines of codePHPWomen.org: elePHPantsPhil Thompson's Blog: 7 PHP functions that saved my lifeStuart Herbert's Blog: Using suphp To Secure A Shared Server
418285
Apparently PHP5 RC3 is going to be the last release candidate. This is supposed to be coming out at the end of this week, so PHP5 will probably be released next month.  It's a bit like looking through a window into a candy store. The sweetener I most look forward to is the improved object assignment semantics.
633181
Gareth Heyes has a new post today talking about one of the vulnerable values in the $_SERVER superglobal - PHP_SELF.   I thought it might be a good idea to gather a few test cases demonstrating the problem. Why PHP allows these URL's is beyond me and it wouldn't take much work to filter out these malicious URL's in the PHP code.   He provides four test cases to show how simple it is to abuse - one using a HTTP header, another pushing XSS through, the third mentions search pages and the fourth a direct code injection.   You can download the code here.
187716
This month's edition of PHP Magazine has been released!
188665
The PHP Community is buzzing about a new article, posted on the O'Reilly Ruby blog, about how the author (Derek Silvers of cdbaby.com) made the decision that Ruby on Rails just wasn't right for the project he was working on.    Back in January 2005, I announced on the O'Reilly blog that I was going to completely scrap over 100,000 lines of messy PHP code in my existing CD Baby  website, and rewrite the entire thing in Rails, from scratch. [...] The first few months showed good progress, and Jeremy could not have been more amazing, twisting the deep inner guts of Rails to make it do things it was never intended to do.   But at every step, it seemed our needs clashed with Rails' preferences. (Like trying to turn a train into a boat. It's do-able with a lot of glue. But it's damn hard. And certainly makes you ask why you're really doing this.)    Recounting the rest of the story, Derek mentions the turning point ("Is there anything Rails can do that PHP CAN'T do?") and the speed at which they were able to make up for the two years of lost development time. To helps others make a decision for their project, he also includes seven reasons why he made the decision to switch back, including:   Our entire company's stuff was in php: don't underestimate integration Don't want what i donÃ¢ÂÂt need I love SQL Programming languages are like girlfriends: the new one is better because *you* are better   There's also been several bloggers in the PHP community that have responded to the article:   Elizabeth Naramore - "Derek Sivers' Article on RoR vs PHP" Paul Jones - "Is there anything Rails can do that PHP cannot do? *No.*" Terry Chay - "Why PHP triumphs over Ruby" Jeff Moore - "Ruby versus PHP or There and Back Again"
259126
In an "interesting" post to The Codist blog, there's one developer's look at PHP and his confession that he'll never quite understand the appeal of the language.   How PHP can be so popular is beyond me; the whole sense of encouraging all of your html, code, bindings, javascript, even sql (as in the below example) into a single file is a nightmare.   He Goes on to talk about his experience with JSP versus PHP and some perspectives on how PHP lacks features he's used to or how other developers he's talked to had similar issues.   One thing that concerns me (and apparently several others in the PHP community) is that he keeps talking about procedural PHP code that's an "all in one page" kind of setup. Well, of course this can get messy quickly - that's no way to code anything, much less PHP. Organization means more than just breaking code up into chunks on your page (though it's a very low-level start). Plus, the sample code he provides is a joke - a PHP developer with a few weeks of experience could push out something 10x better.