Don’t have a job yet? FOSS it with Symfony2

Today I did not know what to do. I tried some options to get fancy but failed miserably. After some time thinking I went onto the issues list of the symfony/symfony repository looking for something I could do. Usually one waits for Ryan or a hacking day to start looking where to help, but this time it was different. I just needed to survive and feel like I learned that new thing everyday. So this is called `contribute not because my product needs it but because is about passion and moving as a community`.

So I found this (notice @stof has not slammed me yet on the reviews but so far so good):
Screen Shot 2013-06-27 at 1.33.32 AM

Since it was about the console component I thought maybe if I was able to reproduce it I could be in a better shape to at least comment on github with words. At first @stof’s english did not make sense to me, even though it is clear I did not have the background to muster an attempt. I had to reproduce, so I took a pet project folder, write a command on my src bundle folder, read the documentation for the DialogHelper which he mentioned http://symfony.com/doc/current/components/console/helpers/dialoghelper.html and then passed the flag –no-interaction or just -n. Then bingo! First goal was achieved.

Then I knew if I was going to touch code that is on this repo I better make sure I don’t break other tests doing that. I hate PEAR so I would not try to install phpunit on my machine. So I downloaded it as a phar, chmod it and put it on `/usr/bin/phpunit`, cd to the vendor/symfony/…/Console component folder and run composer install –dev. Then run the test suite just for the component and see that it works ok. Later I did add my changes to my now new branch sprouting off of master and then committed and reran the suite to ensure all was good. But lest we skip explaining an important step I will not continue with the changes but with what to do after the problem is reproduced. So after the problem is at hand I stop and search for the class that does have the functionality I was going to modify i.e. DialogHelper. Then I moved to its test class `DialogHelperTest` and start skimming over the tests there. Once I found a pattern to write the failing test that I was interested in things started to unfold. After this red light from TDD I was able to touch the code, add the `$input` argument on the helper dialog methods make it green and also fix the tests that I had broken with this change set.

Finally I ran the command I first wrote to ensure no messups mess my final PR.

Then something interest I saw github gifted me with:

Screen Shot 2013-06-27 at 1.22.05 AM

Here is the link to the PR:
https://github.com/symfony/symfony/pull/8366

Funny as I did not do anything basically. I write this to illustrate how easy could be contributing, even contributions that probably would or would not get accepted such as this one. I know @stof will beat me to death, but it is ok.

Thankful, hope that this helps some of you out there.

Ciao Symfony2, welcome StackPHP Middlewares Part II – Series

Ok so remembering #desymfony there was a talk regarding optimizations by splitting the kernels so we can have decoupled environments and yet still retain performance. Now with StackPHP Middlewares we don’t have the need to do this anymore, I mean not to split into kernels but I mean to create duplicate code on both kernel apps. You ask for performance? Our answer is with a lazy loaded kernel app! Here me again:

$loader = require_once __DIR__.'/../app/bootstrap.php.cache';
Debug::enable();
 
require_once __DIR__.'/../app/AppKernel.php';
 
$app = new AppKernel('prod', false);
$app->loadClassCache();
$lazyFactoryApp = function() { return require __DIR__.'/admin.php'; };
$stack = (new Stack\Builder)
    ->push('Stack\UrlMap', ['/dev_mode' => new LazyHttpKernel($lazyFactoryApp)]
);
 
$app = $stack->resolve($app);
 
$request = Request::createFromGlobals();
$response = $app->handle($request);
$response->send();
$app->terminate($request, $response);

What we have done is to basically lazy load the admin app via a LazyHttpKernel which is not a vertical way of stacking a kernel but a horizontal stacking which is why it is embedded within the UrlMap kernel mapper array. We can now further stack vertically with more middleware separately the admin app or the main app.

//admin.php
<?php
 
use Stack\LazyHttpKernel;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Debug\Debug;
 
$loader = require_once __DIR__.'/../app/bootstrap.php.cache';
Debug::enable();
 
require_once __DIR__.'/../app/AppKernel.php';
 
$app = new AppKernel('dev', true);
$app->loadClassCache();
 
return $app;

Next step is to play with perhaps creating a new stack middleware from scratch. Very thankful!

Departing from Symfony2 into StackPHP Middlewares Part I – Series

Today I have decided to depart from Symfony2. It has to be. The conference #desymfony finished, I am at my room and I was wondering why do I stick to Symfony2 anymore in view of what I will explain as follows:

Well it all starts with this code:

//... stuff in app_dev.php
$loader = require_once __DIR__.'/../app/bootstrap.php.cache';
Debug::enable();
 
require_once __DIR__.'/../app/AppKernel.php';
 
$app = new AppKernel('prod', false);
$app->loadClassCache();
 
$admin = new AppKernel('dev', true);
 
$stack = (new Stack\Builder)
    ->push('Stack\UrlMap', ['/dev_mode' => $admin])
;
 
$app = $stack->resolve($app);
 
$request = Request::createFromGlobals();
$response = $app->handle($request);
$response->send();
$app->terminate($request, $response);

So what I have done here you ask? Basically I have used stack middlewares to basically have a phantom `route` to go in and see the site on development mode, to be able to either reproduce errors in production or to see information on xhprofile or what not.

The stack middleware that I have used is called the url-map middleware. notice that I have two kernels, the kernels could have been totally separate and very different. These are my apps. One is set on development environment and with debug enabled and the other is set on production, this latter is the one facing main bulk of users.

The concept of middlewares is to share functionality across multiple projects disregarding whether they have been written on whatever framework and share it in a way that the functionality lands without a single line of code modification on your apps.

Notice I have used the url-map middleware which is basically mounting the same app but with different settings onto the folder `/dev_mode`. If I run `php app/console router:debug` I will not see the route with `/dev_mode` listed in any of the kernel apps. This path is being resolved by the map I have handed to the resolver stack and I just had to change the app_dev.php, the .htaccess to trim and exchange app.php for app_dev.php, and add these two lines to my composer.json:

    "stack/builder": "~1.0@dev",
    "stack/url-map": "~1.0@dev"

The ultimate result is that when i point my browser to:

http://stack.l/dev_mode/demo/hello/luis  --> I see the development toolbar aka WDT
http://stack.l/demo/hello/luis        ---> I do not see the WDT

I will keep pounding on this since I like it and I am being still favored to do these kinds of good stuffs even though it comes to me very undeservingly. I thank my gracious God for this. Off to random hacks now…