Category: slider

Trado: PDF Invoice Support

The Trado platform now supports viewing customer order invoices in PDF format. For more information on how to set up PDF Invoices in Trado, check out the trado-pdf-invoice-module repository.

For more information on the Trado platform, please check out the official website:

However, if you would like to check out the Trado source code or perhaps contribute to project, you can do via the public Github repository:

Need help or support with the platform? Please feel free to send me a messagetweet me or create an issue on the Github repository or join our Slack team!

15th January 2017

Includes vs Joins in Rails: When and where?

For the past few months I’ve been hiding away in a cave and working intensely on a not-so-secret project, Trado. So I thought I’d reach out once more to my fellow interwebbers, and share some knowledge I’ve learned on my journey so far.

Now with any e-commerce platform there is bound to be a lot of database relations and models relying on each other for, you guessed it: data, and with many relations come many performance aches and pains. So like any good developer you turn to the Ruby on Rails documentation and stumble upon two very similar yet very promising Active Record methods: includes and joins.

What is the difference between includes and joins?

The most important concept to understand when using includes and joins is they both have their optimal use cases. Includes uses eager loading whereas joins uses lazy loading, both of which are powerful but can easily be abused to reduce or overkill performance.

If we first take a look at the Ruby on Rails documentation, the most important point made in the description of the includes method is:

With includes, Active Record ensures that all of the specified associations are loaded using the minimum possible number of queries.

In other words, when querying a table for data with an associated table, both tables are loaded into memory which in turn reduce the amount of database queries required to retrieve any associated data. In the example below we are retrieving all companies which have an associated active Person record:

When iterating through each of the companies and displaying the persons name, we would normally have to retrieve the persons name with a separate database query each time. However, when using the includes method, it has already eagerly loaded the associated person table, so this block only required a single query. Awesome, right?!

So what happens if I want to retrieve all companies with an active associated Person record, but I don’t want to display any data from the Person table? It’s starting to seem a tad overkill loading the associated table…well that’s where the joins method starts to shine!

If we use the above example again, we can start to see how easily people can become confused between the includes and joins method, when very little has changed:

Visually the only difference is replacing the includes method call with joins, however under the hood there is a lot more going on. The joins method lazy loads the database query by utilising the associated table, but only loading the Company table into memory as the associated Person table is not required.Therefore we are not loading redundant data into memory needlessly; although if we wanted to use the Person table data later on from the same array variable, it would require further database queries.

I’m not convinced, I need some stats…stat!

Recently I fell victim to not using the awesome power behind the includes method in my Trado codebase. I noticed a severe performance leak when monitoring the database queries in my local instance server logs, which is a habit I would advise starting.

The following code in my index method was producing an abnormal amount of database queries, as seen below:



(The database query list was so big I couldn’t fit it in the screenshot!)

As you can see, for every row in the table, it was making two database queries to grab data for the associated zones and tiers tables. When scaled up this starts to become a heavy load on resource with an Active Record loading time of 265.2ms. So in light of preserving scalability and performance in my application, I modified the index method to take of advantage of the includes method for the zones and tiers table associations:



You can quickly see here that the number of database queries has been reduced to an optimised number of just 5, which in turn drastically reduces the Active Record loading time to just 2.8ms – that’s a 99% reduction!

I hope this has been been helpful in explaining the pros and cons of using the includes and joins association methods, and helps you on your path to producing scalable, high performing applications!

28th June 2014

3 Golden Nuggets: Git

Welcome to the second installment of the ‘3 Golden Nuggets’ series. If you’ve yet to read a previous post in this series, it entails three key features within a predetermined subject. This time we are looking at a big player in the SCM (source code management) world, Git. I’ve spent 80% of my development life maintaining, preserving and sharing my codebase through this truly impressive piece of software; from restoring old code to setting up feature branches, Git has been my cyber superhero through it all. Here are a few tips which I think are deemed worthy of mentioning:

Change protocol access to prevent firewall blocking

There has been times where I’ve been up all night trying to solve a bug and every attempt has proved unsuccessful. I then proceed to wake up the next day, still troubled by this problem, eat my breakfast and go to work. Before I know it midday strikes and my only focus for the next 30 mins is to have another crack at this bug; hopeful that a fresh mind will provide a more fruitful conclusion. My attempt is quickly cut short by git clone providing me with an ‘unable to connect a socket (Connection timed out)’ error; further investigation reveals that the corporate firewall at work is preventing me from accessing the git: protocol (9418).

This is usually standard practise for corporate firewalls to block unconventional ports in order to improve security of their intranet. The obvious solution would be to start utilising the HTTP protocol which Git provides. You can achieve this by modifying the git config to perform some basic URL rewriting and force all Git commands to use the HTTP instead of the GIT protocol. Simply issue the following command in your terminal window:

You can then confirm your changes by running:

You’ll see the following line in the output:

If you would like to use a more specific URL in the replacement, you can issue something like this:

In the event of a URL matching multiple replacements, the longest match wins.

Reconcile a detached HEAD

In order for us to understand the problem, we first need to acquire a firm grasp of what a HEAD is and what it means when it is detached.

HEAD is a symbolic name of the currently checked out commit. When a HEAD is not detached it points to a branch’s “ref” and the branch points to the commit, which in turn means the HEAD is “attached” to a branch. When you perform a new commit, the branch that HEAD points to is updated to point to a new commit, and the HEAD follows since it just points to the branch. So to summarise we have HEAD => branch “ref” => Commit which translates to HEAD => refs/heads/master => 23a02924078923f8b62811326d108de991d1a95a. Please note the commit can also be referred to as the current tip or “head” of the master branch.

When HEAD is detached, it points directly to a commit – instead of indirectly pointing to one through a branch. So, in other words a detached HEAD is on an unnamed branch. You can continue to work on a detached HEAD, however you run the risk of losing history along the way.

Your first point of call would be to issue the git rebase command. If you finish the full rebase operation, it will update your original branch with the cumulative result of the rebase operation and reattach HEAD to the original branch. However if the rebase process never fully completed, it will leave you with a detached HEAD pointing to the commit that was most recently processed by the rebase operation.

In our example below the HEAD has detached from your master branch and we are looking to restore the HEAD => master => commit link. To recover a detached HEAD after a failed rebase, you should start by creating a branch that points to the commit currently pointed to by your detached HEAD:

This will reattach your HEAD to the new temporary branch. Next you want to update your master branch to point to the new temporary branch:

The temporary branch has now become redundant as the master branch is now pointing to the same commit so we can remove it:

The final step is to push the reestablished history:

It is likely you will need to use -f (force) to push if the remote branch can not be “fast-forwarded” to the new commit, i.e. rewrote some of the history.

Stashing your work

You’re happily hammering at the keyboard building an awesome new feature for your application and then BOOM, a live bug is flagged. If you’re awesome enough to be a Git user then you needn’t panic. Just whip out your new best friend, git stash.

Think of the stash command as your own personal clipboard in Git – you can stash any working changes in your current branch and return to a clean working directory, so you can start work on something else. You can do everything you would normally do in Git without losing your clipboard; once you’re happy to continue working on those changes, you can simply issue git stash pop on the stash’ original branch to bring back all your changes.

Furthermore you can store a number of stash’ in your ‘clipboard’ and easily issue git stash list to view all the current stash’ – detailing the stash name, branch name and a short description. Utilising the previous stash pop command, you can specify the stash you wish to bring back, e.g. git stash pop stash@{3}. You can find a full list of features over at the Git Documentation.

I hope these have proved useful for you and your development codebase.

05th December 2013

AJAX and JSON error handling on Rails

As most of you know, I have quite the passion for premium user experiences. I believe a user should not just endure a site, they should find it exciting and accommodating during their visit. A good friend to user experience is AJAX; the ability to interact and change content on a web page without being redirected elsewhere or refreshing the page. This, coupled with JSON objects, results in a formidable tool for manipulating your web page on the fly and bringing some life to your site.

I’ve recently been working on a project for an ecommerce CMS using Ruby on Rails, and was looking to enhance my forms with the addition of AJAX validation. In previous projects I’ve used the client_side_validations gem, since it can satisfy my requirements straight out of the box. However, support for the gem has recently stopped and I was quite intrigued in learning AJAX validation on my own, so I looked to AJAX and JSON. The initial idea was upon submitting the form, if the form object failed to save via the controller create method, Rails would throw back a JSON object listing all the validation errors which would then be caught via AJAX and printed to the DOM. Here was my first working attempt:


I could of quite easily ran with this attempt, however in terms of best practise, there are quite a few things wrong with this semantically. You can see here with this implementation it is mixing error handling in a success callback. This results in the ajax call being triggered even when the form has no validation errors, so an if statement is required to check whether there is a ‘data.error’ JSON object produced by the controller. This all looked rather messy and hacky, so I decided to revise the approach and start again.

I started by researching the handling of JSON objects in the controller, in the hope of indicating the type of response the JSON object was declaring. This would mean I would be able to utilise the error callback and only trigger the ajax call if the form produced a validaton error. My second attempt proved to be alot more lean, clean and concise:


As you can see here, the JSON object in the controller is now indicating a HTTP error status (422, unprocessable entity), which means our error callback is called for us. The improved implementation removes the requirement for the if statement and prints out all of the error messages within the JSON object with a for each loop, removing any unnecessary logic.

Lastly, I have utitlised the ‘full_messages’ method to produce an array of full messages rather than just a hash where keys are the attributes and the values are the errors:



27th November 2013