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]!
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.
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.
[] TechEmpower Benchmark Round 6 was due today, but it was re-scheduled to the 25th
[] Symfony should remove High Performance from their homepage title.
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.
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.
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.
If you don't know what you are talking about please stop. What does PSR-x have to do with core? Besides the fact that PSR-0 is broken it doesn't really make sense to expect anything of it in core. PSR-x are some "rules" made up by some creators of frameworks / projects to aid in userland CS / directory structure decisions and please note that not everybody agrees on what they think people should do.
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.
44 comments
[ 5.0 ms ] story [ 104 ms ] threadI don't normally look at most of the articles, but the ones I do read are usually decent!
[1] https://packagist.org/
Is there any small (relatively new) PHP framework that isn't based on Symfony2?
[] TechEmpower Benchmark Round 6 was due today, but it was re-scheduled to the 25th [] Symfony should remove High Performance from their homepage title.
I would love to see an asynchronous database client (for instance Mysql) for it, but for now I use PDO.
its also been a while since I've done web dev.
its also been a while since I've done web dev.
In no small part because novice developers also have a tendency to build queries directly out of $_GET parameters.
While PDO and parameterized queries aren't a silver bullet, simple strings as queries are just a nightmare to do properly.[2]
[1] http://stackoverflow.com/questions/60174/how-to-prevent-sql-... [2] http://www.youtube.com/watch?v=o4dJ7hdA8fs
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.
>ctrl+f "PSR"
>0 results
Into the trash it goes.
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?
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.
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.
The situation before PSR-0 was a mess of different, incompatible directory layouts for loadable libraries.
PSR-0 is broken on machines using filesystems that aren't completely case-sensitive.
Implementing PSR-0 also takes about five lines of code. Sure, it's more boilerplate, but it's not something that needs to be in core.
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.
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.