Doctrine convention adherence leads to much simpler entity classes, no picky join column specification. A standard bi-directional one-to-many join becomes simply:

<?php
use Doctrine\Common\Collections\ArrayCollection;

/** @Entity **/
class Product
{
    /**
     * @OneToMany(targetEntity="Feature", mappedBy="product")
     **/
    private $features;

    public function __construct() {
        $this->features = new ArrayCollection();
    }
}

/** @Entity **/
class Feature
{
    /**
     * @ManyToOne(targetEntity="Product", inversedBy="features")
     **/
    private $product;
}

Nice and straight forward.

Of course, if you do want to specify the join column manually, it would be:

/** @Entity **/
class Feature
{
    /**
     * @ManyToOne(targetEntity="Product", inversedBy="features")
     * @ORM\JoinColumn(name="product_id", referencedColumnName="id")
     **/
    private $product;
}

The getters & setters can be auto-generated with the following calls from the server’s command line:

app/console doctrine:generate:entities AppBundle:Product
app/console doctrine:generate:entities AppBundle:Feature

Alternatively, modern IDE tools like PHPStorm can also generate the standard for you. Chaining is a great feature to encourage on setter methods, simply return $this after setting an entity property.

Advertisements

Using Twig’s default() filter to avoid “Variable some_var does not exist”

References to undefined variables are a common cause of web pages not displaying when using Twig. A simple mention of an undefined variable can cause 500 errors:

{{ some_var }}

Variable some_var does not exist in..

Whilst turning strict_variables off in the twig config will obviously hide the error and is best for production, during development hiding errors can ultimately making spotting bugs harder. A better solution is using Twig’s default() filter like so:

{{ some_var|default("") }}

This will print the variable if it exists or nothing if it is not defined.
For if statements and loops, there are 3 choices:

  1. The default() filter:
  2. {% if some_var|default(false) %}some text{% endif %}
  3. The fine grain but hideously verbose control of defined:
  4. {% if some_var is defined and some_var %}some text{% endif %}
  5. The empty filter:
  6. {% if some_var is not empty %}some text{% endif %}

There are also lots of other useful tests, filters and functions that Twig provides out of the box, check out their documentation pages for more info. Hope this helps. Please like and share if it does ūüôā

Which Symfony Version number?

The Symfony console provides a -V option. This can be handy for quickly finding out which version of Symfony¬†a system is¬†running but it has moved location a bit over the years (note the¬†uppercase -V or use –version):

$ php bin/console -V
Symfony version 3.1.2 - app/dev/debug

If this produces a bunch of errors about autoload.php then you need to run composer install to install other required parts of Symfony. Whilst if you receive a command not found error then try:

$ php app/console -V
Symfony version 2.7.10 - app/dev/debug

If still a command not found error then try:

$ php lib/vendor/symfony/data/bin/symfony -V
Symfony version 1.4.20

In all versions, running console without -V will produce a long list of all the commands available, along with the version info. This is very useful and really good regular learning exercise, the options really show how Symfony works.

As we can see, the console command moved to the project folder’s bin/ folder as of¬†version 3.0 in Symfony2 versions the console command lived in the project’s app/ directory, whilst¬†if only lib/vendor/symfony/data/bin/symfony exists then you’re using Symfony version 1 (now an obsolete legacy platform)!

Modify XML files using XSLT

XSLT can be great for transforming XML files, especially where information is stored in attributes thanks to the @ operator.

If you have a xml file like:

The elements can be combined into one with multiple attributes, ie:

<collection>
<field row0=”Value0″ row1=”Value1″ row2=”Value2″ row3=”Value3″ row4=”Value4″ row5=”Value5″ row6=”Value6″ row7=”Value7″ row8=”Value8″ row9=‚ÄúValue9‚ÄĚ></field>
</collection>

using the following XSLT:

A web search will reveal many handy online testing tools, such as:
http://xslt.online-toolz.com/tools/xslt-transformation.php

Additionally, many IDEs now come with tools and verifiers build in to facilitate XSLT translation of XML files. As much as we prefer using JSON where possible these days, XSLT can adds an extraordinary amount of functionality and flexibility to XML files.

Changing the default keyboard shortcut of a Chrome Extension

Changing the keyboard shortcuts of some Chrome web browser extensions can be a pain when the preferences option is non-editable in chrome://settings. A some-what longwinded workaround is to edit the source code of the extension directly. Often this is available on somewhere like GitHub.

To change a Chrome extension keyboard shortcut via its source code, the steps are as follows:

  1. Clone the extension source code to your computer
  2. Open the manifest.json file in the extension’s route directory. Edit or add this section:”omnibox”: { “keyword” : “key” }

Where “key” is the keyboard shortcut key itself. As an fyi, Chrome likes to calls its address bar the “omnibox”

  1. In chrome, go to: chrome://extensions/
  2. Delete the old extension (careful of deleting important data if relevant)
  3. Switch on developer mode in top right of page
  4. Select Load unpacked extension... and navigate to the cloned directory
  5. Verify the extension has loaded in Chrome and works correctly
  6. It is a security risk to browse the Internet with Chrome Extensions developer mode left on. Solve this by packing the extension into a single .crx file (a type of .zip file).
  7. Delete the newly created “unpacked” extension and click Pack extension... (you can sign the file with a .pem key but this is not necessary).
  8. Switch off developer mode in top right of page
  9. Nagivate to the directory above the cloned directory
  10. Drag the .crx file produced in the packing step onto the Chrome window
  11. The new extension should now appear on the chrome://extensions/ page
  12. Verify the correct result by navigating to chrome://settings/ -> Manage search engines...
  13. At bottom of page under “Search engines added by extensions” the keyboard shortcut should be updated and extension only appears once

 

You now have a modified keyboard shortcut for a Google Chrome extension. Some installations may experience problems with the browser disabling the extension unless it is officially released through the store (private repos are available). If the extension is disable then a restart of the web browser usually suffices in making the extension work again.

Easily Install Apache Tomcat on Mac OS X El Capitan

Please like or share this article if it helps you. Any problems, ask in comments!

By far the easiest way to install and configure an Apache Tomcat server on a mac is using the open-source homebrew package management suite. If you’re not already using homebrew, check out its popularity on GitHub. It makes open-source package management on mac 100 times cleaner than doing it manually (everything is stored in one place, packages are easy to remove, upgrade and find configs for).

There is a good tutorial here on installing homebrew if you do not already have it.

1)  –  Install Tomcat Server

Install tomcat with the brew install in terminal (as a normal user, not root):

$ brew install tomcat

This will take care of the downloading, installation and configuration of Tomcat and manage its dependencies as well. Take note of the output, brew commands are typically really good at displaying concise but useful info, error messages and help.

Homebrew keeps packages (known as kegs) in the Cellar, where you can check config and data files. It is a directory located at:

$ ls /usr/local/Cellar/

Verify the Tomcat installation using homebrew’s handy “services” utility:

$ brew services list

Tomcat should now be listed here. brew services are really useful for managing system services, type $ brew services --help for more info.

2)  –  Run Tomcat Server

We are going to start the server by executing Tomcat’s Catalina command with the “run” parameter as such:

$ ls /usr/local/Cellar/tomcat/

$ /usr/local/Cellar/tomcat/8.5.3/bin/catalina run

or more generally:

$ /usr/local/Cellar/tomcat/[version]/bin/catalina run

With [version] replaced with your installed version.

The version number and installation directory will have been listed by homebrew at the end of the installation output (typically the last line with a beer symbol in front). Catalina can also be set to start on system launch – although for security reasons we prefer to only run when needed (either using this command or more commonly via an IDE plugin).

Once the server is running you can navigate to the host page at:

http://localhost:8080/

 

3)  –  Configure Tomcat Server

To add and manage applications running on the server you will also need to edit a configuration file:

$ vim /usr/local/Cellar/tomcat/[version]/libexec/conf/tomcat-users.xml

With [version] again replaced with your installed version.

Towards the bottom of this short config file you will see a selection of users – all commented out by default. You need to uncomment one of these and give it the extra role “manager-gui” (preferably also changing the username and password for security). The resultant user entry should look something like this:

<user username="admin" password="password" roles="tomcat,manager-gui" />

After this you can navigate to the page (or click the “Manager App” link on the main Tomcat Server page):

http://localhost:8080/manager/html

Here you can view or delete the included sample application and deploy your own. Usually, it’s easiest to deploy applications in a dev / testing environment using an IDE like PHPStorm or NetBeans however, Tomcat’s web interface is useful also. For reference, deployed applications are usually then located under the directory:

/usr/local/Cellar/tomcat/[version]/libexec/webapps/

 

Please like or share this article if it helps you. Any problems, ask in comments!

Git Workflow for Sprint projects

It was a surprise to find a lack of clear diagrams for using Git properly in Sprint / Agile / Scrum programming environments. Therefore we thought we would take a moment to plot how we’ve always understood the best practice Sprint git workflow:

Git Sprint Workflow diag

As usual develop is the ongoing central branch, with master being the live, most stable branch which is only merged to via release branches and (when necessary) hot-fix branches for quickly fixing critical bugs on the live system. The key difference being that a new branch is created from develop for each Sprint cycle. Features / stories / tasks (here on known as stories) dished out to team members are then created as branches from that Sprint# branch.

If any stories are not completed within the Sprint timebox (e.g. 2 weeks) their branches can be carried over to the next Sprint as necessary. It should also be noted story feature branches can be merged, for example when a story relies on code from another story in the same Sprint. To do this run from the destination branch:

> git pull origin another-feature-branch

During the Sprint, completed¬†stories / branches are tested and if all’s good¬†a pull-request is created, but only during the Sprint Review at¬†the end of the Sprint are¬†the pull-requests (branches)¬†merged back into the Sprint branch and then at the end of the review, the Sprint branch itself is merged back into Develop.

If a release is to happen after the Sprint (and it frequently¬†should if following agile methodology) then the develop branch is tagged and a new “release branch” created from this tag. It is this release branch which is then merged back to master in what is in effect the release of a new version of your software (along with merging back to develop to keep everything in sync).¬†The master branch can then be tagged to create an official “released” version, this tagging should also happen after hot-fix merges.

As is the general idea with Sprint workflows, a new release can be made after every Sprint (maybe skipping the occasional one if the software isn’t ready).¬†¬†We usually make these new increments of the .# numbers, so x.1, x.2 … x.25, x.26 etc. Hot-fixes from master lead to ¬†x.x.# increments, so x.x.1, x.x.2 … etc.

Often during release candidate¬†testing minor bugs and tweaks¬†will arise. Major bugs might require the abandoning of the release branch and new sprint work carried out but¬†for quick¬†fixes,¬†a hot-fix branch can be created off the release branch. This hot-fix branch can be merged straight back into the release branch (and shouldn’t effect the release version number once released).¬†

Modern source hosting environments like BitBucket and GitHub make this whole process nice and GUI based, especially with inbuilt issue-tracking systems, however this can all be done purely from the command line, perhaps tying in with a standalone issue-tracker like Trac, Zendesk or if you want to be really old-school, a simple Excel spreadsheet ;-).

Any questions or comments, please let us know.