Grace is Not Receiving The Lethal Injection

I have heard some comments about what happened with Troy Davis. Whether this man is innocent or not some people is disputing more the death row penalty rather than what actually happened or the judgement wrong or right.

In this background Grace meant not receiving the lethal injection. Troy perhaps did or did not deserved it. But unfortunately he was killed without a judgement of perfection. Judgement is flaw and certainly one can argue that. However there is a judgement for Troy and moreover on us that is perfect. That ladies and gentlemen is the judgement of God pure and righteous. This judgement brings God’s wrath on all of us justly. There is but one escape and it is found in grace. And grace only flows from a single human-God person, Jesus Christ. If you are not in Him, you certainly fall with everybody else and whether or not you agree or disagree with Troy’s death you deserve, no matter how good your good morals and behavior are, a life sentence of lethal injection, lethal wrath abiding starting since the beginning.

Grace objects then are so much fortunate! Come to Christ!

Sismo Setup As Personal CI: Behat + PHPSpec Powered!

Update notice: I was told by fabpot that: “The command can be any valid script. So, you can run whatever you want here. The best way is probably to create a script and call it as the command to run.”

I struggled several hours with Sismo but got it to do what I wanted.
I went in and configured a config.php file into .sismo/config.php introducing my project not as a github project but as a custom project since everything is local for me for this particular project. I also have it on github but I want to be able to *assert* the situation locally as we are developing with BDD.
So working on a particular branch of my project ‘composition’ I init bare a local repository in a repos folder ‘/home/cordoval/sites-2/repos/bdd-local.git’ and then assign the command to run phpspec on a folder Spec under the corresponding subproject.

<?php
$projects = array();
 
// create a DBus notifier (for Linux)
$notifier = new Sismo\DBusNotifier();
 
// add a project with custom settings
$sf2 = new Sismo\Project('bdd-local');
$sf2->setRepository('/home/cordoval/sites-2/repos/bdd-local.git');
$sf2->setBranch('composition');
 
// builds command for phpspec
$phpspecCommand = '/home/cordoval/sites-2/FormModelProjectBundle/vendor/phpspec/scripts/phpspec.php';
$phpspecFolder = '/home/cordoval/sites-2/FormModelProjectBundle/vendor/PHPAutotest/demo/PHPSpec/MineSweeper/Specs/';
$longCommand = 'find ' . $phpspecFolder . '*.php -exec ' . $phpspecCommand . ' \'{}\' -f documentation --color \\;';
 
// sets command, slug for web interface, links to individual commit, and notifier popup
$sf2->setCommand($longCommand);
$sf2->setSlug('bdd-local');
$sf2->setUrlPattern('http://sismo.local/bdd-local/commit/%commit%');
$sf2->addNotifier($notifier);
$projects[] = $sf2;
 
return $projects;

The setup for the phpspec and behat is custom and it is discussed for a later post. However, it is shown here to show that we are successfully using PHPSpec and Behat on our BDD design cycle with Sismo.

The git post-commit hook used is quoted here commented:

#!/bin/sh
#
# This hook script is called after a successful
# commit is made.

# sets the environment variables for sismo
. /home/cordoval/sites-2/sismo/sismoenv
 
# pushes the latest commit on the current branch whichever this is 
# up to the .git repository that sismo is cloning/fetching?
/usr/bin/git push local
 
# runs sismo with .sismo/config.php configuration (aka Behat, PHPSpec, PHPUnit, or other as sismo is tool agnostic)
/home/cordoval/sites-2/sismo/sismo --verbose build bdd-local `git log -1 HEAD --pretty="%H"` &

I added the push step in order to make it work since without this push step sismo would be cloning (and not sure if fetching after it clones in the first processing step) a repository out of sync since the last commit we made it is still on the working directory and has not been pushed upstream.

Result, it works like a charm.

And on a behat cycle:

I should acknowledge the brainstorming time with NordishByNature on the channels and overall to my God for providing me grace time for this. Currently listening …

Discussing how to BDD Symfony2 Router+URL Mapper

I got a response but still roughly thanks to Marcin Sikon
hmm, maybe this:

$container->get('router')->match('/review')
// result of this function is false or array with '_controller' and '_route',
 
_controller looks like 'Acme\Bundles\DemoBundle\Controller\DefaultController::indexAction'

now you must parse this string for get action and bundle name …

is there a way to have it already parsed through some component…
from kernel $container->get(‘kernel’) get registerBundles and find bundle matching to bundle namespace
any more ideas? anyone?

I got another response from Dmitry Bykadorov:

Finally I’m using this solution:

       $serviceContainer = self::$kernel->getContainer();
       $router = $serviceContainer->get('router');
       $crawler = $client->request('GET', $router-
>generate('admin_blogpost'));

– “Now I’m tesing both controller & routing )”

So in view of this we can do:

Beyond Compare Git Mergetool Settings

From their website:

Diff

Create a shell script file “git-diff-wrapper.sh” with the following content:

  #!/bin/sh
  # diff is called by git with 7 parameters:
  # path old-file old-hex old-mode new-file new-hex new-mode
  "<path_to_bc3_executable>" "$2" "$5" | cat

In a console window enter the command:

  $ git config --global diff.external <path_to_wrapper_script>

3-way Merge (v3 Pro)

In a console window enter the following three commands:

  $ git config --global merge.tool bc3
  $ git config --global mergetool.bc3.cmd "/usr/bin/bcompare \$LOCAL
    \$REMOTE \$BASE \$MERGED"
  $ git config --global mergetool.bc3.trustExitCode true

2-way Merge (v3 Std, v2)

In a console window enter the following three commands:

  $ git config --global merge.tool bc3
  $ git config --global mergetool.bc3.cmd "/usr/bin/bcompare \$LOCAL
    \$REMOTE -savetarget=\$MERGED"
  $ git config --global mergetool.bc3.trustExitCode true

Open Letter On The Behat+PHPSpec Expand-Collapse Methodology

hi,

on another note, i saw your bowling example [_md’s].

I see how behat is very good on one side at the high level. You probably could have designed the class without relying on PHPSpec.

HOWEVER, if you chose to use PHPSpec once you got the red on behat and then came back after you greened all your PHPSpec descriptions just to ensure some adding of scenarios for completeness then it is great.

I believe bowling example is not very clear. But I see two patterns.

When the logic behavior (methods/what it does) described in the scenarios matches closely the class and when scenarios really describe acceptance behavior at a high level and it is not close to class behavior because the logic behavior is not very clear at the moment. This has to do I think with separation of concerns.

When separation of concerns is not clearly laid out or is mixed or embedded neatly into a behavior then it is hard to describe behavior that matches class behavior of the methods. When separation of concerns seems to be easily described with particular scenarios then we realize that separation of concerns has already been decoupled into method-like logic behavior (bowling case).

When separation of concerns is coupled and cannot be decoubled at the high level which is in most cases then extra procedure is followed:

1. PHPSpec will here be more heavily used to attempt the decoupling of the behavior in expected functionality, more and more fine grained each time or at least the description will be able to extend past the behat scenarios and can then describe some borders and more shape to what the class does. This is in all separation of concerns and some more other design.

2. After PHPSpec passes and Class(es) is(are) implemented then next step is to put to the test the Class(es) so designed and behat will fulfill the role of integration scenario BDD process.

So PHPSpec helps with separation and splitting to define finer behavior whereas Behat starts putting things back together to orchestrate things split to a larger view back together.

Expand-Collapse/Separation-Reunion concept of Design which is how things are designed.

I am currently working on a minesweeper example that shows perhaps some more clear this process… not sure how far i can get but i will try to be more clearer hopefully. Great job _md, this is a great advance in understanding these great tools! Behat+PHPSpec FTW.

Please let me know your thoughts!