Whether you are starting with or are in a more advanced level. This is for you.
You can setup a github page showing your achievements. This script will count your command occurrences, will push modifications to an html page and award you achievements upon command issuing on cli prompt.
This is an interesting way to learn!
Encouragements!
When integrating bundles from other repositories into our project we would like to have an easy way to get a defacto configuration of the bundle at hand. We could either go jump on github and try to guess the configuration from the `Configuration.php` file within the bundle, but why bother since we have the great and new command `php app/console config:dump-reference NameOfBundle` this can be invoked to display the yml version of a sample default configuration for that given bundle.
By looking at the result of the command we can find out about the available settings in a more human readable fashion. Besides the typical default and mandatory configuration flags there is new information set through methods like *setExample* and *setInfo* which will enrich our `Configuration.php` bundle configuration file used like in the example below:
->scalarNode('access_denied_url')->defaultNull()->setExample('/foo/error403')->end() ->scalarNode('session_fixation_strategy')->cannotBeEmpty()->setInfo('strategy can be: none, migrate, invalidate')->defaultValue('migrate')->end()
If you don’t know what argument to pass or are just exploring you can easily call `php app/console container:debug` to get their service names with which to call the `config:dump-reference` command. Providing human readable default configurations for the users of our bundle will boost its quick usage and adoption.
I have delivered a series of short blog series on git and github usage here that I want to share.
Please go to http://phpperu.org/blog
You will not regret. There is a week worth of research and a short tutorial on hub. I don’t know why I was not using it.
Encouragements in all good.
I recently ran into a nice gist cli tool setup shown here and you can easily jump into its usage from ubuntu box doing:
$ sudo gem install gist $ git config --global github.user "your-github-username" $ git config --global github.token "your-github-token" $ gist - ... // Ctrl+D to finish string
It is so cool, now there is just one thing to look perhaps to a widget on chrome or something.
This is real quick for when you get an exception of the sort of the route problem.
An exception has been thrown during the rendering of a template ("Route "_assetic_817694b" does not exist.") in AlomWebsiteBundle:tylesheets.html.twig at line 1.The solution is simple, just telling assetic to scan that bundle:
assetic: debug: %kernel.debug% use_controller: false bundles: [ AlomWebsiteBundle ] ...
Make sure you `php app/console cache:clear`.
Thanks to josiah for the tip. Encouragements in all good.
PHPSpec now run its own specification examples on itself with the help of composer and travis.
Composer is the tool to automate dependencies. PHPSpec now has a direct dependency on Mockery/Mockery and when installed through composer on can run the tests with `./scripts/phpspec-composer.php spec/` provided previously we have run `composer.phar install`. If you don’t know how to get the install step take a look at the earlier posts that teach you just that.
In order to have a solid stable version of phpspec that can be well tested or rather specified we used `travis` continuous integration service. With travis we are able to tell it to test phpspec specifications in any version of php and in any pre-configured environment.
This is the PR send that implements all the changes: https://github.com/phpspec/phpspec/pull/59/files.
And here is the output on travis:
I would like to strike a note of appreciation to thank deeply the KnpLabs in the US. I lived in the southeast area of the US for 5 years and I feel like I know their kind ways and goodwill of helping others. They not only have worked on giving tutorials or workshops throughout the world in shape of conferences but they have also provided free resources readily available for the avid dispossessed stalker-reader. I am now remembering their help in form mainly of 1) the Christmas gift @weaverryan gave everybody on his free slides with code included, 2) KnpLabps Ipsum demo and repos, 3) One to one help in the old days about how to capistrano deploy symfony2 the right way (disclosed just for me or so I thought), 4) and many many other tips and tricks now in this latest video, like the play.php script (which was not really mind games but really just bringing out what is inside the handle method), and 5) the thing we all know him for, the sf2 `docu`. If I ever come back to the southeast of my second home I would rent a car with my family and drive from South Carolina to Nashville just to greet these guys.
That said, let’s dig once more and dissect for fun the latest knpuniversity tutorial channel:
The tutorial for autoloader was a token of what one could expect of their professionalism in their other extended video Starting in Symfony2 Tutorial. Its make-even-a-3-year-old-child-understand clean type of communication has been compressed in time for the busiest of us and yet still conveys a direct ready-to-apply batch of pro-tip treasures. I myself learned three new things, 1) the tip for debugging right on play.php script unrolling the handle method and recreating the request with Request::createFromGlobals, 2) an easy one, the tip on PHPStorm for Go To Class, and 3) the php app/console doctrine:fixtures:load –append, never used it before even though it was there but I like to know it is there now 
. Of course the other parts of the tutorial are thrilling. Just that I learned it the painful way, being slapped again and again on the mailing list and ignored in the IRC channel. Of course I always get help from the goodies. So that is why I am still alive and learning and now writing this review for what I think is a worth looking tutorials PHP and Symfony Tutorials. My thought is there are a lot of people who know a lot, some more than others, but few teach it to others. Thankfully the symfony2 community does not lack great individuals who like to pass the baton.
I watched the 1 hour video and it felt like it was 10 minutes. I thirst for more of course, but it was so complete and thrilling. It was a gap filling device in my newbie education. It felt so short to me because I enjoyed it so much understanding details in clear and proper conveyed English. Usually foreign developers cut to pieces our loved southern English, and this video just made it justice for once. Communication skills are important and help develop the other side of our brain!
The video also transpires some explanations that drip Symfony2 philosophy, it is a good complement to the series @fabpot is currently writing, you will enjoy his revised written English as much as I do. He is on chapter 7 now so hurry up, they are short and easy to deal with and full of keen ideas.
I stay with the code of the play.php script and I will use it to understand inner parts of the Symfony2 framework more or at least to dig into ideas and try to explore further. I think that a video that shows you how to fish is a good video and this tip aimed in this direction.
It feels good when you understand one thing over and over and more and more. This is the case for Symfony2, it just gets better when you understand it further and further.
In behalf of the Symfony2 Community (yes I often like to take attributions and it is cool with you ), thanks guys for this video and more to come.
We wanted to do something more with composer and so we dug further and found composer allows us to really simplify setup of our phpspec projects.
For our main project we create a composer.json on the root folder of our project as follows:
{
"config": { "bin-dir": "." },
"require": {
"php": ">=5.3.2",
"cordoval/phpspec": "master"
}
}What this will do is to install all dependencies so we can work with phpspec and its dependencies and also have a standalone script with the phpspec version of our like. In this case we are using the only version existent at the time of writing which is `master`. The script linking magic is accomplished by the composer.json in phpspec as shown here:
{
"name": "cordoval/phpspec",
"description": "PHPSpec: The BDD Specification Library",
"keywords": ["bdd", "spec", "test"],
"homepage": "http://phpspec.net",
"license": "MIT",
"authors": [
{
"name": "PHPSpec Team",
"homepage": "https://github.com/phpspec/phpspec/contributors"
}
],
"bin": ["scripts/phpspec-composer.php"],
"autoload": {
"psr-0": { "PHPSpec\\": "src/" }
},
"require": {
"php": ">=5.3.2",
"cordoval/mockery": "master-dev"
}
}Of course you don’t need to write this anymore as it is taken care by us.
Instructions for installing the composer are easy. You can either create the composer.json on your personal project or clone this sample project.
git clone git://github.com/cordoval/phpspec-composer.git cd phpspec-composer
The only thing besides writing the short composer.json above is to install composer. It is simple:
wget http://getcomposer.org/composer.phar php composer.phar install
If you have composer installed as in a development setup like in a previous post you just do `composer install`.
The last command will install phpspec and all its dependencies included in the phpspec composer.json package specification, that is to say: Mockery.
Now run phpspec with:
~ ./phpspec-composer.php -h
Usage: phpspec (FILE|DIRECTORY) + [options]
-b, --backtrace Enable full backtrace
-c, --colour, --color Enable color in the output
-e, --example STRING Run examples whose full nested names include STRING
-f, --formater FORMATTER Choose a formatter
[p]rogress (default - dots)
[d]ocumentation (group and example names)
[h]tml
[j]unit
custom formatter class name
--bootstrap FILENAME Specify a bootstrap file to run before the tests
-h, --help You're looking at it
--fail-fast Abort the run on first failure.
--version Show versionI thank the Lord Jesus Christ. And the opportunity to have received much help through helpful top guys like Stof, Seldaek, igorw and the developers of composer.
This post is about how to set up vespolina project using composer. It is intended mainly for people wanting to setup vespolina sandbox in a snap. When loading dependencies for a project, and in particular with vespolina sandbox which loads 15 vespolina bundles we want to have an easy and standard way of loading not just the vespolina bundles but also all the symfony2 dependencies. For that welcome to composer.
Before we proceed let’s install composer on your system. We don’t want to install it the regular trivial way but we want to set it up so that we can do PRs to the composer repo and help back. So we chose the development setup. The following sets development installation of composer on ubuntu 11.10 latest:
mkdir $HOME/composer cd $HOME/composer git clone https://github.com/composer/composer.git . wget http://getcomposer.org/composer.phar php composer.phar install ln -s $HOME/composer/bin/composer /usr/bin/composer
With this we basically want to create a composer folder at the user home directory level, clone composer there, bring composer to build composer source code dependencies, then symlink the script under composer/bin to a default system wide /usr/bin/composer executable. This is a flexible setup indeed as it will let us run it simply in this way `composer [options]`.
If you are not of the same mind, you can find instructions for other types of installation setups here.
Now that we have our setup ready. We move into our project directory. And also create some helper scripts which we would want to PR composer with. These scripts basically remove the files/folders created by a composer run. The remove script is needed because sometimes we just mess with the dependencies writing the composer.json file and we need to start afresh. The remove script looks like this:
// remove.sh rm -rf vendor composer.lock
Now we are ready to write our composer.json file. There are some gotchas and this is why I wrote this blog post.
The way to add requires to composer.json is to go check the availability on packagist.org and copy the vendor/package_name and do the inserts under require like:
{
"autoload": {
"psr-0": { "": "src/" }
},
"require": {
"php": ">=5.3.2",
"symfony/symfony": "2.1.0-dev",
"vendor/package_name": "master-dev",One can use the command `composer show package_vendor\package_name` in the same way. Be mindful that each package has requirement constraints assigned to packages that the package at hand depends on. If by chance it happens that the package that is depended upon does not match the constraint criteria then the package will not be installed and composer could choose to tell your or not to tell you depending on how bad is the conflict. You may have a successful build of the explicit dependencies but that means little. You will have cryptic errors until:
1. you manually impose the requires as above for the packages depended upon, or 2. you choose the version of package at hand that relaxes the requirements so that its dependency can get installed as well.
There can be a case where #2 above is impossible to meet for a current version or range, and that is more the developer community’s fault rather than yours . Worst case scenario is that you do things manually like I have indicated above.
Two things to keep in mind when writing your composer.json are: First, only bundles need a target-dir key to reproduce the path for their namespace. Second, libraries need PSR-0 key set indicating its top namespace and the root directory (lib, src, or whatever is the case) to ensure they can get loaded but libraries do not use a target-dir keyword.
After you have completed your composer.json it is time to make sure composer not only parses correctly but imports what it says it will import. The command that allows this test is:
composer install --dry-run --dev composer install // <--- this only when done!
The first command is a dry run to test what will happen. The second command is going to run it all the way.
Determining which dependencies did not load from the errors is simple, however it could also be challenging to the newbie just inferring the missing component. In order to troubleshoot further one should take a look at `installed.json` and `autoload_namespaces.php` under vendors directory (notice vendors directory can be configured by the top composer.json and you can read further on packagist.org). Looking at these two files can help you see what is wrong and back port it to your composer.json to make things work.
Once you have at least one composer.json working, even if you have to explicitly tell all dependencies into your composer.json file, you can take advantage of another more powerful tool. The tool is under the command `depends` and it will tell you what packages are affected by the package at hand and which is the required version of this package at hand:
~ composer depends symfony/symfony friendsofsymfony/rest-bundle master-dev requires >=2.1.0-dev doctrine/doctrine-fixtures-bundle master-dev requires >=2.0 snc/redis-bundle 1.0.1 requires >=2.0.4 secotrust/route-statistics-bundle master-dev requires >=2.0.4 doctrine/couchdb-odm-bundle master-dev requires 2.1-dev loso/di-annotations-bundle 0.0.5-dev requires >=2.0.4 cedriclombardot/admingenerator-generator-bundle 1.0.0-BETA-dev requires >=2.0.0
This command is used to simplify our composer entries. If we go one by one, line by line on our requires and run the depends command on every package in each line and make sure to remove the line if we find that there is a package that is listed already on our composer.json that will import the package in the current line. If we do this operation we will simplify our composer.json to a few lines.
And as you can see it will give you which packages depends upon this package named. Of course that is somewhat helpeful (like the show command) so you don’t have to go online to packagist.org and check every package.
There is also a tool to check locally what packages and its versions are installed:
~ composer debug:packages --local local: sonata/admin-bundle master-dev (9999999-dev) local: vespolina/monetary-bundle master-dev (9999999-dev) local: vespolina/ecommerce-flows-bundle master-dev (9999999-dev) local: vespolina/workflow-bundle master-dev (9999999-dev)
Also this can help you further understand the dependencies and ensure we have installed all packages and its dependencies. If some package is missing from this list we know it was not imported by composer due to some internal error.
To avoid unnecessary repetitive downloads, we use the command `composer install –dry-run –dev`.
The process to debug an entry in a composer.json file is the following:
1. add one entry 2. run `composer install --dry-run --dev` and check the list of imported packages is correct 3. if yes then go to 1, else check dependencies, move down (remove to debug), or call it for the day.
In order to aid for huge composer files. We have come with the idea of clusters. Clusters of dependencies that can be grouped and pulled altogether with just one require line. In order to accomplish this we create a composer.json inside an empty project folder, push it to a github repository and then submit it to packagist and registered under vendor_name/cluster-other_name. The next step is just add the require line into our top and project level composer.json. An example of this approach follows:
{
"name": "vespolina/vespolina-sandbox-composer",
"type": "group-of-deps",
"description": "Vespolina Bundles",
"keywords": ["vespolina"],
"homepage": "http://vespolina-project.org",
"license": "MIT",
"authors": [
{
"name": "Vespolina Team",
"email": "cordoval@gmail.com"
}
],
"require": {
"vespolina/store-bundle": "*",
"vespolina/checkout-bundle": "*",
"vespolina/product-bundle": "*",
"vespolina/cart-bundle": "*",
"vespolina/inventory-bundle": "*",
"vespolina/taxonomy-bundle": "*",
"vespolina/order-bundle": "*",
"vespolina/customer-bundle": "*",
"vespolina/pricing-bundle": "*",
"vespolina/fulfillment-bundle": "*",
"vespolina/merchandise-bundle": "*",
"vespolina/taxation-bundle": "*",
"vespolina/workflow-bundle": "*",
"vespolina/ecommerce-flows-bundle": "*",
"vespolina/monetary-bundle": "*"
}
}And inside our project’s composer.json we have the following require entry:
"vespolina/vespolina-sandbox-composer": "*",
There is a word of caution when creating packagist.org repositories for some old projects or projects that are not yet available on packagist.org. That word is to notify and PR the package maintainer to make its package available at packagsit.org. Then you will be able not just include it as a custom repository at the top composer.json level of your project, but you would just include a short require line which will import the package for you and will make your composer.json look much simpler. Right now–and probably always–composer does not resolve repositories recursively, it only does for dependencies available in packagist.org. So it is impossible for composer to resole ALL repositories in ALL packages before starting, and this is the intention of its creators. Therefore the best practice is to inform your package maintainers and to be patient. Do not create temporary repository or namespaces, not even in your namespace, this is not encouraged and will not be tolerated as it will break things for someone who may start depending on your package. Things can go bad for whoever depends on your package and you happen to delete it. So packagist.org is therefore for permanent evolving stuff.
This ends the first part of our series on vespolina and composer. Come back for more.
I thank the Lord Jesus Christ. And the opportunity to have received much help through helpful top guys like Stof, Seldaek, igorw, and asm89 and the developers of composer.
Yes, phpspec requires big time thing. I got frustrated with a segfault problem. And finally it is about php5.3.6 i had installed.
Upgrade here http://www.omaroid.com/installing-lamp-with-php-5-3-6-on-ubuntu-11-04-natty-narwhal/.
After a quick refactoring of the documentation we are eager to deploy the new version of the documentation. This time refactored from xml into rst so that it can be plain, easy to write on the fly, PR’eable on github, and totally updated with nightly builds. We are glad to present:
You will be ripping the benefits of this new way of doing things for your new PHPSpec projects on 2012.
For the Symfony2 community we are bringing the best of PHPSpec and a new way of doing things on 2012.
Encouragements in all good.
Thanks to Behat (everzet) and Symfony2 community for helping us with the way of doing docs the right way.
Working on a PR today I learned some tricks:
// dbu git pull --rebase // lsmith git remote update git checkout -b feature/myAssertFix_clean upstream/doctrine_dbal git merge --no-commit --no-ff feature/myAssertFix git commit -a -m "commit message explaining your changes" git push origin feature/myAssertFix_clean git branch --set-upstream feature/myAssertFix origin/feature/myAssertFix git push origin feature/myAssertFix_clean
Some explanation of the commands above:
1. makes sure local is aware of all the remote changes
2. creates a new local repository based on the state of the upstream repository
3. moves all the code changes from your old local branch to the new one without committing them
4. commits the changes as one commit in the new local branch
5. pushes your new local branch to your repository on github
Special thanks to dbu and lsmith.
We should also remember our two friends:
git rebase -i SHA1 git merge-base branch1 branch2