I've never used Optimizer+ so I might have to compare it with my nginx/php5-fpm/apc buildouts.
I understand compiling bytecode to memory but I still wish there was a way to write files bytecode files back to the disk in a similar fashion to python.
[] TechEmpower Benchmark Round 6 was due today, but it was re-scheduled to the 25th
[] Symfony should remove High Performance from their homepage title.
We just implemented an internal composer repository for sharing code between our different services. I am surprised composer isn't more popular. I have been developing for a long time and have only recently heard of it.
Agreed! Framework arguments aside, learn how to use Composer. If you haven't played with namespaces, this is a great way to start learning more about them and using them in your own codebase. It also makes it incredibly easy to work with other packages[1]!
Silex and Laravel don't really serve the same purpose. I think both have merits, and it's hard to say a micro-framework like Silex is "better" than a full-featured framework like Laravel, unless you're applying a specific context..
I have mixed feelings about Laravel's use of the facade pattern. On one hand it brings a really simple API, which is great for new users and rapid development. On the other hand, it's hiding away dependencies and making testing slightly more complex. It's seems a bit like hiding behind multiple global service locators.
If you forget to escape even one bit of supplied user data your entire application, server, or possibly even business can be compromised. You need to be extremely disciplined about escaping if you use this antiquated method. There are automated injection tools that will discover and exploit these, it's not even hard.
All you need to do is use a database layer with placeholder values and if you're diligent about encoding everything that way, your chances of being hacked by a simple SQL injection bug are nearly zero. You'll have to make several mistakes before you're in hot water.
`mysql_query` is the worst possible interface to MySQL since it's literally the low-level C bindings ported in to PHP without any kind of enhancement. Those functions were intended for writing more abstract interfaces, not being used directly.
While it is possible to write mysql_query code correctly, it is very challenging and not worth the time when facilities like PDO exist.
Also, if you loathe "over abstracted" database libraries you're probably using the wrong library. A library should make your database interfacing easier, not harder.
It's an unmaintained extension that does not support new MySQL functionality. If you don't want any more abstraction you can use the mysqli_* functions instead.
Wow, PSR-2 (Coding Style Guide) seems fairly extreme (existentially, not in it's specifics which I haven't looked at) for PHP.
Part of me thinks it's odd, considering I never felt all that much freedom to change how I expressed things in PHP (at least not in the slightest compared to Perl).
Another part of me thinks that enough amateur programmers use PHP that some style guide may benefit them greatly. Then again, if people don't come to a better style through experience (or at least an explanation of the benefits or what mistakes it helps prevent) then is it really as useful?
The purpose of the PSRs is to help support and foster collaboration between members of the Framework Interoperability Group (the people who draft and publish the PSRs: consists of medium-to-large PHP projects including Symfony, Amazon, Drupal, Joomla, etc.). Having a common coding standard makes it much easier to publish code as part of other PSRs as questions like "tabs or spaces?" don't have to get rehashed every time a new PSR is drafted.
That's to say PSR-2 is not intended to a be a "best practices" type of thing: it's actually just the result of a survey of member projects at the time with each part chosen because that's what the majority of them did, even if it was just a simple majority or there were member projects were with the majority on, say, tabs vs. spaces but not, say, indentation size. Some of the FIG member projects have adopted it, but several haven't and don't intend to. It's useful if you don't have any other coding standard available, but easily ignored with no loss of interoperability with the other PSRs if you do.
PSR-0 is widely adopted by anything relevant in the PHP ecosystem. Sure, those style guides might not be pitch-perfect but it is time for PHP to step it up and get some uniformity in their codebase. _At least_ adopting PSR-0 would have been a great step towards that.
Uncertain why I am getting downvoted for this (top parent) it is my personal opinion and just because you think otherwise isn't a valid reason.
How does the PHP project adopt PSR-0? PSR-0 is a standard for programs written in PHP; what would they do to adopt it that is in anyway better than the current situation?
Part of PSR-0 is a standard for autoloading namespaced classes, so, if you write you're own autoloader, implementing PSR-0 is neccessary to support loading libraries using that standard.
The situation before PSR-0 was a mess of different, incompatible directory layouts for loadable libraries.
Highlights:
* Opcode cache (https://wiki.php.net/rfc/optimizerplus)
* Generators and coroutines (https://wiki.php.net/rfc/generators)
* "finally" keyword
* Constant array/string dereferencing
* Optimized access to temporary and compiled VM variables. 8% less memory reads.
* Dropped Windows XP and 2003 support.