As of Docker 18.09 there is a much cleaner, natively supported way to achieve what this (and other) workarounds were doing.
See https://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066 for details.
Fitting the pieces together for a smooth, automated and reliable continuous integration or delivery pipeline is hard.
From keeping a good test suite maintained, pulling and building dependencies to deploying via FTP or Git or Capistrano or something else. You may know all the steps there are but once you start, the details can be overwhelming.
One of those details is dealing with private dependencies, for example a composer or npm module you host privately…
A microservice for developing, testing and sending templated transactional emails in your next app
Remove boilerplate SMTP code, take advantage of templates in any language, and fix email client issues with MJML.
The Status Quo
As a developer, having worked on many applications I think I’ve written a “forgotten your password” email a thousand times. The same goes for “Welcome to product X” or “Purchase confirmation”.
These transactional emails are a simple necessity in almost all apps and thankfully they’re not that complex. You just have to write some HTML. And it’s dynamic, so setup a template language, like Twig, Handlebars, or Jinja2.
For good measure, add a plain-text version for old email clients…
This article was originally published at http://adamquaile.com/fieldset-in-symfony-forms on 17th May 2014, but has since been migrated to Medium.
Update: There seems to be an issue where the validation messages don’t appear directly on the relevant fields, but at the top of the form.
Currently, the Symfony Form component has no support for the HTML <fieldset>. There are some solutions for this floating around on the internet^1.
I have created a bundle to leverage this functionality quickly. You can find it on github here
This article was originally published at http://adamquaile.com/running-commands-between-features-and-scenarios-in-behat on 12th Oct 2014, but has since been migrated to Medium.
When using Behat for any application with more than a small amount of complexity, I often find there’s tasks I do time and time again.
Maybe, at the start of the test suite I need to clear my cache; in a symfony environment this might look something like this:
php app/console cache:clear --env=testMaybe I want to reset the database after each feature, or each scenario…
php app/console -e test doctrine:database:drop
php app/console -e test doctrine:database:create
php app/console -e test doctrine:schema:updateSome common ways
Of…
This article was originally published at http://adamquaile.com/composition-over-inheritance-with-doctrine-repo on 16th May 2015, but has since been migrated to Medium.
One of the first things many of us learn when getting to grips with OOP is inheritance. It allows us to reuse code and only modify the bits we need.
This is good, but if you’ve ever worked on a system that’s even moderately complex you may have felt the pain of overuse of this pattern. It can quickly lead to trouble. Most of the time, there is a better way. Most of the time, that way is composition.
