Lukas Smith's Blog: Remember: be nice to byte code caches
105006
In a new post on his blog, Lukas Smith warns developers working with autoload and byte code caches that things may not be as speedy as they might seem.   While it seems kind of nice one must be weary of the idea that they speed up your code. If you are running a byte code cache (which anyone who cares about performance of course does) you will get quite the opposite.   He includes a quote from an IRC log with Rasmus Lerdorf as to the reason why. Mainly, it has to do with the fact that autoload is runtime dependent as opposed to the byte codes which are handled and cached when working with apc.   So, what does this mean for performance? If you really want to squeeze those few extra bits of time out of the execution of your scripts, static includes are the way to go.
668378
On the JSLabs Blog today, there's a new tutorial walking you through the installation of the APC (Alternative PHP Cache) caching system for your PHP installation.   The Alternative PHP Cache (APC) is a free and open opcode cache for PHP. It was conceived of to provide a free, open, and robust framework for caching and optimizing PHP intermediate code.   The installation is pretty simple and, once you get things in place the configuration can start. The tutorial lists out several of the options you can use to customize your installation and a brief paragraph on what each of them do.
680727
In an effort to have a definitive resource to point to when people ask about PHP scaling, Sebastian Bergmann is asking for suggestions and information on the topic in his latest blog entry.    In "The J2EE guy still doesn't get PHP", Harry Fuecks suggests that PHP really needs [someone] to get together and write a detailed paper on how it works and why PHP scales so we can all live happily ever after.   I could not agree more.    Sebastian even notes that just recently, such a document would have come in very handy in a discussion. Unfortunately, he hasn't had the experience needed to make such a paper himself, so he's asking the community to help on the project and give suggestions/comments/offers of help in the comments of this blog posting.
533524
A great presentation by Ilia Alshanetsky from the International PHP Conference 2004. The only thing I would like to point out is that MMCache is still being actively developed, as evidenced by the CVS activity at sourceforge.  PS: You might need to use Mozilla to view this. IE sometimes doesn't work properly. I thought IE was a defacto standard :-)
90155
Based off of a previous article from Mike Willbanks, Stuart Herbert has posted some of his own thoughts on tuning and tweaking your applications for the best performance you can get out of them.   There's some good advice in there, and I thought it'd be a good idea to quickly add a bit more detail about the separate approaches that Mike raises.   He goes over the APC caching, memcache, the "gzip trick", the "Not Modified" header and optimized SQL statements.   He also mentions one thing that Mike didn't mention - a split between static files (no PHP needed) and their dynamic cousins. Having a more pure Apache (no PHP installed) can help give a minute jump in speed that, depending on the size of the site, could really add up from a user's perspective.
548114
Slim gains from low-latency RAM don't justify a steep price.
449834
Sebastian Bergmann has posted the results of some benchmarking on the compilation he's done on the branches of PHP from version 3.0 all the way up to 5.3-CVS.   As people keep asking me for an update to my previous benchmarks (PHP / GCC / ICC Benchmark, PHP 5.1 / GCC Benchmark (Update), and PHP 5.1 Performance, I quickly ran a new benchmark today.   He rendered the results out into a series of charts defining the number of total seconds taken for the compile and how long each of the components took. It's impressive to see how much of a jump there was between the 3.0 series and 4.3.   He also includes his compile settings (and machine information) as well as the numbers for the results if you'd like to graph them out yourself.
457664
In this post on the Zend Developer Zone, Cal Evans takes a look at an article published in a recent php|architect issue from Chris Hartjes about how several recent advancements in the PHP community have helped developers think more in "the Rails way" of development.   Chris does a good job of laying out his points. As with any article of this nature, you are going to agree with some of them and you'll disagree with some of them. However, to get to that point you'll have to consider all of them. That's really the point of the article; making developer sit back and think for a minute. It's well worth the read.   Cal also mentions some of the topics presented in the article including more conceptual ideas like "Convention Over Configuration" and "Rapid Should Mean Rapid".
614738
Matt Wade has posted a quick item to APress' Inside Open Source blog today mentioning an update to an item he'd previously mentioned - issues with the Zend_Cache module.   One of my complaints was the Zend_Cache did not accept lifetimes on a per object basis, but rather the lifetime was at an application level. I just received notice in my inbox that the issue has been fixed! The change is currently in svn, and should be in the 0.80 preview release. Thanks go to Fabien for the fix.   You can download this latest version of the Framework (0.7.0) from the Zend Framework website.
568284
Everyone in the PHP community (as is probably true all around the web) is buzzing about the new offering from Google - the Google Code Search. In the PHP community, the ones talking about it so far include:  Chris Shiflett's look at the security aspect of the search Ilia Alshanetsky's take on the search as it possibly being a hacker's good friend Pierre-Alain Joye's searches for macros and the term "virtual_file_ex" Harry Fuecks' own search for superglobal-related issues Ivo Jansch's happy look into frustrations other developers have had (ex. this search)    Check out this handy tool and see what you think. Does it provide too much access to code that needs to stay out of hacker's hands? Or does it promote the "open" in open source better than most of the tools out there?
540441
Aaron Wormus is back today on the Zend Developer Zone with another in his "Hidden Gems" series. This time, he takes a look at the "Zend Plumbing", those bits of connective code that help you make your Zend Framework applications work.   The functionality that he covers in this article are some of the min parts that a lot of ZF coders use every day and might not know it:  the Zend class (providing a suite of helper methods) built in Wrapper functions:  loadFile loadClass loadInterface isReadable dump exception  the Zend registry  Each of these is briefly described with some sample code for the loadFile, loadClass, exceptions and the Registry to give you an idea of how to use it all. As always, you can check out the Zend Framework website for all the details on each of these functionality bits.
357182
In a new post to his blog, Chris Hartjes, spurred on by an article in the latest edition of php|architect magazine (covering protecting your code), has shared a few opinions starting with a certain paragraph near the end.   To start, I will focus on the paragraph above. What I get out of that is that if only your source was closed and hidden from prying eyes, it would not have bugs in it. Which is, of course, total nonsense. Code has bugs because it's open and they feel safer? There are two kinds of bugs: application bugs (which is the code I would write) and system bugs (in this case, bugs that that appear from PHP itself). I'm sorry, but there is nothing I can do if there is a bug in PHP that causes my application to crash except to point this bug out to the people who have the ability to fix it.   He goes on to talk more about how protection like this (the article talks about using the IonCube Encoder) will not stop someone if they're really determine to get at the code underneath the encryption. His only suggestion is to make an application good enough that people wouldn't want to try to steal it as much and would rather pay for their version.   Encode your stuff if you want, but be aware that the minute you choose to do that you are telling your customers "I don't trust you" and I have a hard time understanding a business model that assumes people are going to want to steal the stuff you sell.
481653
I'm back, with a very interesting topic too!  Joel Spolsky, ex-Microsoft Manager and software engineering guru has a new essay, How Microsoft Lost the API War that is creating quite a big storm in the blogging communitiy.  Joel posits that the priests in the holy Temple of Microsoft have lost their way, because it has split into two factions, and the wrong faction is winning. One faction worships on the alter of backward compatibility, while the other is led by fervent priests who are proselytizing to raise up the new gods of .NET and Longhorn. Joel suggests that the new gods will cause the destruction of the holy Temple because Microsoft's great victories were built on the altar of keeping customers happy with backward compatibility. Furthermore the old gods of the Windows API continue to grow more grotesque and cruel with the passing of time, driving former worshipers into the arms of the friendlier gods of World Wide Web.  This story sounds extremely plausible. I must admit that i fit the profile of the developer who used to develop on the Window's API, is familiar with COM and Win32 who now develops mostly using PHP and Python. However I continue to develop and maintain Windows apps that keep our customers happy, and we still plan to develop new Windows apps. Some points:  Temple of the Blind? Firstly, Microsoft is still a compelling place to work for to people who feel that they can make a difference. The Temple continues to attract talented people with a Unix background. For example we have the recent hiring of Ward Cunningham, author of the Wiki.  Microsoft is still able to keep talented people like Raymond Chen, and others like him who continue to look after the Windows API, and Longhorn apparently will still give high priority to backward compatibility. Open sourcerers like Miguel Icaza are sufficiently attracted to the .NET vision to stake their careers on Mono. Longhorn and .NET are compelling technologies, so even if Win32 is not so cute anymore, M'soft is providing something that remains very attractive.  What i do see M'soft doing wrong is that they aren't disseminating the .NET runtime fast enough. It remains an optional install in XP Service Pack 2 for example. Also their IE dev team appears to be hog-tied due to political reasons; nevertheless IE remains good enough, particularly when I can embed IE as an activeX control, something I cannot do with Mozilla (AFAIK) - Update: I'm wrong.  Temple of the Spider?  Secondly, people don't merely use a web browser. They run the web browser in the OS.  So let me ask you, if you are using DreamWeaver or HomeSite or Photoshop or vi or emacs or Gimp, how many of you are willing to give it up for a java applet (or whatever your favorite technology is) running in your web-browser? Precisely.  Temple of the Abandoned?  Third, Joel makes the claim that developers are not developing to the Windows API. Well he could be right. But I bet a lot of them are still calling Win32.  If you are using a framework or IDE like Delphi or wxWindows (or .NET or VB) then you certainly are insulated from the Windows API, but that doesn't mean that you're not calling the Windows API all the time. I don't see Borland dropping their Windows version of Delphi at any point in time.   In fact, the fact that many developers are using some form of framework is a compelling argument for Microsoft to enhance the .NET framework to attract developers who are using other frameworks.  Today, not that many students learn x86 assembler, but that doesn't mean that Intel lost the CPU wars. Just because fewer people are learning Win32 doesn't mean Microsoft has lost the API wars, if the frameworks run predominantly on Win32.  Temple of the Lost  Joel even warns you in the beginning that "because I'm talking about big trends, I need to exaggerate and generalize". But you still get sucked in because Joel Spolsky is a first-class writer, in the same order as Philip Greenspun or Eric Raymond. That makes him so persuasive and plausible. But this is not Indiana Jones and doomed temples, but Steve Jobs and reality distortion fields.  Other opinions:  Harry Fuecks (PHP is ASP's upgrade path),  Dennis Hamilton (M'soft is just covering all bases), Robert McLaws (Joel is wrong in 7 points), Oliver Travers (the web is not good enough), One Run-time to Rule them all....
688722
Sample code that exploits a yet-to-be-fixed Windows flaw is circulating. Microsoft plans to deal with it on the next Patch Tuesday.
607777
Sometimes developers just don't think about how much trouble they'd cause with a rewrite of existing software. They think that moving up to the latest and greatest is the way to go, and that it makes perfect sense to say out with the old and in with the new. Aaron Wormus disagrees. Well, sometimes - it depends on the circumstances, really.   At ZendCon I talked about "Planning a PHP 4 to PHP 5 codebase rewrite, a practical approach". The talk was based on my own experience, as well as famous discussion of the topic such as Joel Spolsky's "Things you should never do" and the examination of "famous" platform rewrites.   Aaron gives an example of a large company making a move from a COBOL system out to C for a mission critical system. Based on his tale, they didn't put the thought needed into making this move - new development time, keeping old developers on staff, etc - besides the fact that customers don't like change and making a move to another platform is almost definitely going to be noticed by them.
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.
199964
Fluery still roots for JBoss...Edward Tufte mostly likes iPhone interface...mysteries of Linux's /proc files...multicore compression...Actually *using* mammoth telephotos