Behat 2.3-dev + Gherkin 1.2-dev
I’ve just finished i18n refactoring for both Behat and Gherkin.
Now they both use simple i18n.php files containing simple translation
arrays. This switch gave both Behat and it’s Gherkin parser
noticeable performance boost during startup.
Behat’s i18n.php
Behat always had its own translation dictionary, used by its formatters.
Every message, that Behat prints to you, like failed steps or 12 scenarios
failed could be translated with --lang option and translations for this
lived inside i18n/ directory. It was *.xliff files. This means, that every
time you start Behat, it parsed those files with DomXml, which took
some time. Even more than that, xliff is not natural for lot of people and
i think it’s the main reason of low level of contributions here.
Now every single Behat translation live inside one simple PHP file. It’s easier than ever now to contribute - just send a PR with this simple file change and in next release Behat will talk with you in your language.
I’ve transited every translation from old scheme to new one, so everything here should work as expected. Yeah, should…
Gherkin’s i18n.php
Gherkin have more important change. As with Behat, now every translation
lives under the i18n.php file, but in opposition to Behat’s i18n.php
Gherkin’s catalogue is loaded/autogenerated from the cucumber/gherkin
translation dictionary.
It means, that from now on, every *.feature file written for Behat in any of
supported 40 languages would be valid across all languages and Gherkin
implementations. Want to migrate your project from PHP to Ruby? No need
to rewrite *.feature files - you only need to redefine steps and Cucumber
will parse your features succesfully.
Behat\Gherkin’s i18n.php now will be always in sync with cucumber/gherkin,
means, that to fix/update some translation, you need to send Pull Request
here.
It is a great switch for the Behat future, but it also have huge drawback. Behat\Gherkin’s
i18n library have been diverged with Cucumber’s one. It means, that if you’ve
used some different languages for your *.feature files, the chances are, that
you need to fix keywords in them now OR send a PR to cucumber/gherkin
Test your suites
All changes are in develop branch of Behat. To test if your suite is works with
it, simply install dev version of Behat:
$> git clone git://github.com/Behat/Behat.git
$> cd Behat
$> git checkout -b develop origin/develop
$> wget -nc http://getcomposer.org/composer.phar
$> php composer.phar install
After that, you will be able to run Behat with:
$> /path/to/Behat/bin/behat
If you like/don’t like something about those changes, comment in this post. This is the chance for you to change/fix something before Behat 2.3 and Gherkin 1.2 releases.
ctrlp - Fuzzy file, buffer, mru and tag finder for Vim
One of the biggest pain points for folks like me that switched to Vim from TextMate has been a good way to find and open files within a project. The Command-T plugin has kept me mostly happy, even though it requires running Vim compiled with Ruby support.
This weekend at Jesse’s recommendation, I tried ctrlp.vim, a fuzzy file, buffer, Most Recently Used (MRU), and tag finder written in pure Vimscript.
Installation with Janus couldn’t be simpler, just add the line to your
~/.janus.rake:vim_plugin_task "ctrlp", "https://github.com/kien/ctrlp.vim.git"and install with
rake ctrlpOnce you’ve installed the plugin and reloaded Vim, you can invoke with
<c-p>or:CtrlP. Just type your search query and watch how fast you can find and open files in your project. See the README for details on changing key mappings, using RegEx-based searches, and advanced usage.
Source: thechangelog
Latest php on MacOS through homebrew
With INTL, MySQL and PgSQL:
brew install --with-intl --with-mysql --with-pgsql https://raw.github.com/adamv/homebrew-alt/master/duplicates/php.rb
The lost art of making clients happy
First in the series article about BDD for our brand new technical Knp blog
Source: knplabs.com
Behat v2: The OOP powa!
Ok, the week is passed. Time to make a decision. But first, i want to say thank you! Thank you all for awesome feedback about our future and for just being Behat users no matter what amount of time you use it or what usestyle you prefer. Let me make my point clear once again - every user is important for me and Behat community.
Behat: Bye-bye ninja-style Ruby, hello oop-style PHP?
Now, as Behat is mature product, it’s time to listen userbase. Most often feedback is: http://twitter.com/alexandresalome/status/78109547872522240 Which means something like: “Why PHP tool can’t be more PHP and less Ruby style?”. It CAN!
Symfony is a PHP’s Harvey Dent! Because it’s a community PHP doesn’t deserves, but the one it needs right now!
RESTource relations and customizations
On last week we’ve released RestfulControllersBundle, which adds Symfony2 controllers action naming convention & ability to autogenerate routes from this proper action names. And as any proof of concept, it has missing parts, which we mostly implemented now.
Source: github.com
Not tested bugfix is 100 times worse than a problem it tries to solve, because it might introduce new one & you doesn’t know where!
Who Needs Actions When You Got Routes
Really. Who need to name their controller actions, when we got routes?
Why we need to name object methods? It’s because PHP need to identify which one of object methods you call. Why we need to name controller actions? It’s because framework need to identify which action user calls? NO! Framework already knows what action to call thanks to Routing mechanisms.
Source: github.com
