Runscope Guzzle Plugin and Runscope Symfony2 Bundle

Update: Here is the blog post from Runscope too!

Screenshot 2013-10-28 23.45.40

Over the weekend I took a stab at writing a Guzzle Plugin for enabling a third party service called Runscope.
I think Runscope is an interesting service to debug/test our REST APIs. I see the future of testing APIs here. So I thought to myself it would be a great idea if we could plug some glue logic to make it readily available in Symfony2 or in other frameworks if we just develop a bundle for it.

Here is the github repository of the Guzzle PHP plugin

And here is the repository for the Symfony Bundle The bundle will require the above repository so you only need to require this repo on your composer. I also direct you to the instructions in the respective’s. The bundle is just the glue to get you started in configuring Runscope into your project for easy of use. Both repos will be improved with time and some PRs. But right now they are pretty usable.

composer require cordoval/runscope-bundle dev-master // and profit!

More work will be done in a later post regarding some interesting applications of this service and bundle.
Please if you find this useful support me with going to and spreading the word of this great book on Symfony2 Ecommerce, or by helping me get to Warsaw for the SymfonyCon 2013 in December, I have a lot of expenses and also I am looking for job opportunities to further my career. I got very sick recently but I am almost completely over a light pneumonia.

Thanks for reading this blog of mine.

I thank the Lord Jesus Christ for motivating this wretched man.

Undeservedly thankful, your friend @cordoval

PS> POC with as test:

~ php app/console demo:cordoval:runscope
  "current_user_url": "",
  "authorizations_url": "",
  "emails_url": "",
  "emojis_url": "",
  "events_url": "",
  "feeds_url": "",
  "following_url": "{/target}",
  "gists_url": "{/gist_id}",
  "hub_url": "",
  "issue_search_url": "{query}{&page,per_page,sort,order}",
  "issues_url": "",
  "keys_url": "",
  "notifications_url": "",
  "organization_repositories_url": "{org}/repos/{?type,page,per_page,sort}",
  "organization_url": "{org}",
  "public_gists_url": "",
  "rate_limit_url": "",
  "repository_url": "{owner}/{repo}",
  "repository_search_url": "{query}{&page,per_page,sort,order}",
  "current_user_repositories_url": "{?type,page,per_page,sort}",
  "starred_url": "{/owner}{/repo}",
  "starred_gists_url": "",
  "team_url": "",
  "user_url": "{user}",
  "user_organizations_url": "",
  "user_repositories_url": "{user}/repos{?type,page,per_page,sort}",
  "user_search_url": "{query}{&page,per_page,sort,order}",
  "code_search_url": "{query}{&page,per_page,sort,order}"

Symfony2 MopaBootstrapBundle is indeed a good bundle, don’t get discouraged and rip the benefits of getting it!

Screenshot 2013-10-25 18.18.54

It has been years since MopaBootstrapBundle was started by my friend Phil M aka @phiamo. At first it feel really interesting, then later as I started learning things, I found hard to use and thought that it was not worth it trying anymore because of the entangling complexities of setting it up and using it. But after a dig into it once more I realized that it was mostly because I misunderstood the usage of the bundle.

@phiamo had added two repositories, one is the MopaBootstrapSandboxBundle which is key to understand MopaBootstrapBundle. He has also added symfony-bootstrap-sandbox which is a Symfony distribution with MopaBootstrapBundle and MopaBootstrapSandboxBundle installed so you can give it a quick go. But if you already cloned and started with SE the standard distribution then no worries. Just plug MopaBoostrapSandboxBundle and it will be your guide within your project.

Usually when someone buys or pays for theming a project we are provided with those templating files and we usually plug them into an accessible route to have them handy within the pages of the project. It is the same approach with MopaBoostrapBundle thanks to the addition of the theming bundle MopaBootstrapSandboxBundle from where we can find all examples to follow.

The instructions on MopaBootstrapSandboxBundle work with some minor tweaks if you started from SE, and works 100% when you start from the bootstrap symfony2 distro.

Basically after configuring all the bundles, you extend from `layout.html.twig` or `base.html.twig` which has ready made blocks to override from. If you go to `myapp.l/app_dev.php/mopa/bootstrap` then you will land in a page with examples for how to do and change things. The pages have the demo and the code in the same page, so it is not difficult. It will tell you how to configure the options with the form builder and with twig views too. It will show you examples and options that are tuned to bootstrap 3.0 (yes it is the most important thing :P) and that will save you a ton of time.

I often heard from some of my colleagues that MopaBootstrapBundle was not good to use because of its complexity, but it was out of ignorance of how it really worked or was meant to be used that I also thought and replicated to myself the same justification for not using it. Now I know and have used it with bootstrap 3.0 and it is a charm.

Feel free to try it, hope this blog post helped.

Also if you are into Symfony2 Ecommerce check this resource

undeservedly thankful, your friend @cordoval

PSR-4 and keeping things simple for the goodness of Symfony2 and allies

Update: I mentioned the great merit of the whole PSR working group and highlight @simensen. In no way I want to just say Beau did it all, but just that he helped with his contribution also. PSR whole group of people are hardworking and they deserve credit for bringing us all the interoperable standards. Thanks.

So I know not everybody is familiar with the inner workings of autoloading goodness that has been going on for a while now. Thanks to PRS0, a standard for defining interoperable autoloaders, we have seen an amazing proliferation of development activity around libraries and tools and what not on the PHP world. Composer itself heavily followed upon these standards and seized the opportunity to make libraries totally interoperable such that we can define a requirements file, aka composer.json, and have the tool place packages under directories and basically use the classes inside these directories as if they were in virtual namespaces ready to be used. That gave rise to the new era of libraries truly shared widely, frameworks being split into components and reused across multiple frameworks, the creation of microframeworks from where to use subsets of components from a larger framework, doing more decoupled development, and what not. Most importantly now we are living and walking in a culture of development that is starting to cherish package design know-how and best practices more and more because of the need of FOSS and in-house reuse.

So the group that helped saving the PHP world, if we want to put it that way, is now coming with a seemingly new PSR4 proposal because we are entering the package aftermath era and we want to get rid of duplicated paths like what composer is doing under our vendor folder like: `vendor/vendor_name/package_name/VendorNamespace/PackageNameSpace` -> `vendor/vendor_name/package_name/ClassOnRootPackageFolder`.
This is just more great news! However sometimes in the making of standards people tend to complicate things unnecessarily, not even willingly but because of nuances of text. Thankfully for our community, people sometimes catch interest on writing things and conveying things in a simple matter. I read and tried to understand the specification for PSR-0 which is very short and it kind of makes sense because it is good and simple. I read also the PRS4 proposal and couldn’t really follow on everything. But as I was trying to understand it, I was referred to a brilliant simplification made by one friend. Thanks to @simensen I think we can pretty much understand PRS4 as a slight modification to the PRS0 and be happy and done with it. I will give you the link i read and I am sure you will find your way to the links to read how he simply put a very short and simple text adding some minor constraints to PRS0 and turned it on a very simple extension that we can now call PSR4.

The communities that are interoperable, symfony2 community among them, can greatly benefit from this simplification, because they will read and understand straightaway what is PRS4 package autoloading and what it entails. Pretty much the thing has even a PR ready so it is about just to convey things clearly and simple. If you are like me, jumpy on supporting the symfony2 community efforts, please do reading and :+1: this great effort that I am sure will encourage guys like @simensen among others who are always bringing us goodness to play with.

Cheers! and encouragements in all good!

undeservedly graced to write this, your friend @cordoval

Ignore Symfony2 PHPStorm files like a pro with global ignoring

Often I see in some projects people keep adding their environment specific ignore files into .gitignore or .git/info/exclude over and over. This is a waste of time and does reveal we don’t know git as we ought to. A good example is for those people using netbeans which I do not recommend, or using PHPStorm and are adding ignoring for files under .idea folder or other netbeans folder. Today I got sick of this and I knew there was a way to ignore globally but did not know how to make it very easily. Found it here Basically:

git config --global core.excludesfile ~/.gitignore_global

This will basically build under your [core] key under ~/.gitconfig the following entry:

        excludesfile = /Users/cordoval/.gitignore_global

Now you can go into .gitignore_global and add the annoying .idea and netbeans folders if you want.

I have added these:

# OS generated files #

Symfony2 has some specific entries provided here, however because I do often develop libraries or that is what i want at least, I prefer to keep it short. The ignores at the symfony2 level should be better handled via de local repository’s .gitignore in this case.

Hope that helps and saves you tons of time.

Encouragements in all good!

Projects Come and Go, Grace makes you whole forever

So I got very sick, still am very, can’t sleep well because is very painful. And I thank God for this miserable day, because at night he let me ran all my exhaust, and now I understood once more his Grace. I found this video which I shared with a friend and watch it online and it was exactly what I was looking for. Nothing is coincidence.

YouTube Preview Image

My whole desire is that you put your faith in Christ Jesus. Ponder the truths of the Bible. Let alone be coward in saying yeah I am too an atheist in this field, just to please some and gain more friends. Just because atheism look enjoyable, just because it seems more people `realize` it does not mean you cannot stand firm because of their peer pressure or their github profiles let alone by their insightful talks. Let them ponder it in their lives. May God lead them. But my whole desire is to keep enjoying my work and share the good news with all grace He has given.

Encouragements in all good.