Don't listen to the crowd, they say "jump."
The Aura.Cli package provides the command-line equivalents of web request and response objects. The Context (request-equivalent) object allows insight into the
$_ENV,$_SERVER, and$argvvalues, along with a Getopt object that lets you build and then parse flags and options passed at the command line. The Stdio (response-equivalent) object provides access to to the standard input/output/error streams.
The Aura.Cli package provides the command-line equivalents of web request and response objects. The Context (request-equivalent) object allows insight into the
$_ENV,$_SERVER, and$argvvalues, along with a Getopt object that lets you build and then parse flags and options passed at the command line. The Stdio (response-equivalent) object provides access to to the standard input/output/error streams.
Wrapping up this weekâs âone release a dayâ series is the 2.0.0-beta1 release of Aura.Sql_Schema. You can download it directly or install via Composer and Packagist.
The Aura.Sql_Schema package contains PDO-based tools to read table and column information from a database. If you already use PDO, or if your database abstraction layer of choice uses PDO under the hood, you can feed that PDO object to the Schema object and start reading your table and column information. (Because it is typehinted to PDO, this means the Schema can use an Aura.Sql v2 ExtendedPdo object as well.) The package supports MySQL, PostgreSQL, SQLite, and Microsoft SQL Server.
Our âone release a dayâ series continues with the 2.0.0-beta1 release of Aura.Web. You can download it directly or install via Composer and Packagist.
Whereas the v1 package included controllers, renderers, and other functionality, the v2 package provides only Request and Response objects... You can read more about the distillation of these concerns into separate packages here.
As a side note, you can see from the timing of these recent releases that Aura libraries are completely independent from each other. Thereâs no subtree-split or extract-and-build-for-release processing; each library is completely contained in its own repository, making individual releases through our admin script a trivial matter.
One of the recent problem we can notice is every php framework tries to advertise they are developed from components.
...
The require-dev dependency is when you want to bind other components. The best way is to get rid of the require-dev. The glue package should be another independent package.
...
... learn PHP, and not the magic of a framework. Depending upon the dependencies it will be easy to replace the component. That is the ultimate aim of components, not to trap you.
Emphasis mine. Also this idea from Hari KT: Packagist needs a way to sort dependent packages, independent packages, and framework packages. Via Frameworks Are Good, Components Are Awesome! - Random thoughts | Hari KT.
Continuing our string of library package releases, today we have the 2.0.0-beta1 release of Aura.Router. Given a URL path and a copy of
$_SERVER, it will extract path-info and$_SERVERvalues for a specific route. You can download it directly or install via Composer and Packagist.The Aura.Router package does not provide a dispatching mechanism. Your application is expected to take the information provided by the matching route and dispatch to a controller on its own. You might do this with Aura.Dispatcher or with some other system of your own devising.
In addition to all the standard stuff like adding routes and generating links, Aura.Router has some added conveniences ...
Weâre happy to announce the 2.0.0-beta1 release of Aura.Sql_Query. You can download it directly or install via Composer and Packagist.
This is one of the packages that was extracted from the prior Aura.Sql v1 package. There was some demand for keeping the database connection portions separate from the query builder (and other) portions, thus the splitting-up of the original v1 package.
In addition to the Aura.Autoload v2 âGoogle Betaâ release from last week, we have been releasing v2 beta versions of other packages as well:
- Aura.Includer v2 on Wed, 01 Jan 2014
- Aura.Autoload v2 on Thu, 02 Jan 2014
- Aura.Sql v2 on Fri, 03 Jan 2014
- Aura.Dispatcher v2 on Mon, 06 Jan 2014
Hey, that looks like a pattern: one release per weekday of the new year. Who knows what tomorrow will bring? Regardless, you can see continuing updates on our v2 packages page.
Via Version 2 Beta Releases | Includer, Autoload, Sql, Dispatcher.
I suppose it makes sense that since the the main author behind the PSR-4 Autoloader recommendation is also the lead on the Aura project, that Aura would have the first PSR-4 implementation. You can download it here
and you can find the README here (or in the download, of course):
I expect Composer will have support for PSR-4 soon as well.
Via http://auraphp.com/blog/2014/01/03/first-psr-4-autoloader/.
Long-time readers will recall that I am interested in performance benchmarks as a tool to help discover the outer limits of framework responsiveness. See the blog category along with the most recent measurement report and the GitHub repo for replicating the results on your own.
Benchmarking is useful because it helps you decide if it makes more sense to work on improving your application, improving your framework, or improving your server. If the maximum dynamic responsiveness of the framework in question is 200 req/sec, and you need 300 req/sec, then there is no code you can add in your application to make it go faster in a dynamic scenario; you will have to look at the framework or the server. (Lazy reader who considers himself an unappreciated genius interjects: “But you can cache it!” I said a dynamic scenario, not a static one.)
There’s a lot of emotion and drama associated with benchmarking. The subjects that come in “first place” too often point to it as SCIENCE PROVES WE ARE BEST and the subjects that come in “last place” respond with variations of THIS IS STUPID AND PROVES NOTHING. (That is, until the last-placers run their own benchmarks where they come in first, and suddenly it’s a great marketing point. I’m looking at you, Symfony.) The point in benchmarking is to add information to your decision-making process so you can make better use of your limited resources of time and effort, and choose between competing tradeoffs in a more informed way. Speed alone over-and-above anything and everything is for suckers; it’s an important point, not the important point, when evaluating tradeoffs.
Leaving the elements of drama aside, benchmarking properly is difficult and time-consuming work. For my own limited benchmarks, it took three days or more to properly update, test, run, fix, and re-run to perform them well, even with automated scripts to do the setup and analysis. And that was for the most basic bare bones “hello world” that benchmarks only the dynamic dispatch cycle (bootstrap, front controller, page controller, action method, and view rendering).
Enter the guys at TechEmpower.
They’re doing a series of regular benchmarks that includes not just a double-handful of PHP frameworks, but 90 frameworks/languages/foundations across several languages. They do the basic “hello world” bench in addition to a few others, such as ORM/database speed. They appear to share an approach similar to the one I first published in Nov 2006 and improved with the help of Clay Loveless in Jan 2007. The TechEmpower motivations appear to the be similar to mine as well. They have equalled and then exceeded the efforts that I’ve been able to put forth on my own. From what I can tell it’s really good work.
With that, I am happy to say that I will be retiring my benchmarking project in favor of the TechEmpower one. Until futher notice, I’ll be combining my efforts (such as they may be) with the TechEmpower folks.
Read the Reddit discussion about this post here.