#code-quality

[ Dinle ]

To Join or Not Join

Results of the Code Quality Tools Survey

Batching a Powerful Way to Solve N+1 Queries

Using Polymorphic Associations

Builder design pattern in Ruby

DesignPatterns-Ruby

Evolution of the Heroku CLI

Fabrication vs FactoryGirl

Announcing Hanami v1.1.0.beta1

Ruby Türkiye Meetup

Install Sonar Locally on OSX and Analyze a JavaScript Project

Sonar really shines with statically typed languages like Java and has some very useful analysis it can run for JavaScript projects: critical errors in syntax, code duplication, even test coverage. You can play with all these reports by installing Sonar locally. Thanks to Homebrew it’s not that hard.

(more…)

David Schnepper (DS) gave a talk at Ignite in 2014 titled, "Isn't That Code Dead?". The presentation is a mix of conventional and unconventional; you may embrace it or run away screaming. In either case you will learn something about what is worth trying.

Some of DS's points are uncontroversial. For example, "over time, old code is not exercised, the environment changes and it rusts away."

Other suggestions play with fire. DS recommends that if a software developer suspects that a function is dead, add a tombstone function call (such as `tombstone("2014-10-31")`.

There are several advantages to adding a piece of code that serves as a tombstone:

It signals intent to other programmers.

It gives you a dynamic check, beyond what a basic timestamped comment or static analysis can offer.

It enables automation via additional tooling. The video explains how DS's team have tooling to gather metrics and automatically remove code.

Of course there are disadvantages:

It may tempt people to add tombstones instead of quickly removing dead code.

The run-time cost may be undesirable.

In an ideal world, source control and testing allows old code to be mercilessly removed. For real-world situations that don't quite live up to this goal, the tombstone technique may be useful.

At Imagine Easy, we pride ourselves on building great products on a great foundation. A great foundation means to also focus on code quality, and with said quality, the right amount of tests and (of course) coding standards.

Travis-CI

For continuous integration and continuous delivery, we're hugely invested in a platform called Travis-CI. At the very minimum Travis-CI allows us to run tools like phpunit and php codesniffer on code pushes. On successful builds (and merges) it also hooks into our in-house continuous deployment service (to be show-cased later :)).

Travis-CI is a hosted service — it's in the cloud. When code is pushed, a VM is started and our tooling is run.

In order to keep track of improvements and regressions, we utilize a rubygem called travis-artifacts, which allows anyone to store reports generated on Amazon S3.

travis-artifacts is a neat little tool, however, it comes with a not so small ruby dependency called Nokogiri.

Nokogiri is an XML parser which is probably used inside travis-artifacts or one of its dependencies when they talk to the Amazon APIs to store files on Amazon S3.

Nokogiri

Nokogiri is about 150 MB once installed and needs to be downloaded and compiled during each test run, which implies a considerable slowdown and essentially build backlog when we try to advance.

Since most (if not all) our builds run in a PHP environment, we decided to improve this situation.

travis-artifacts.php

travis-artifacts.php - https://github.com/easybiblabs/travis-artifacts.php

The code is free for use (and open-sourced under a simplified BSD license). We try to mimic the API of the travis-artifacts tool. In a nutshell, here's how you integrate it into your PHP project:

Because the tool is available through packagist, you add the following to your composer.json:

{ "require-dev": { "easybib/travis-artifacts": "~0.2.0" } }

On Travis-CI, ensure development dependencies are installed (in .travis.yml):

before_script: composer install --dev --prefer-dist

To publish build artifacts, add the following:

after_script: ./vendor/bin/travis-artifacts --path=results --root=/home/travis

This assumes that the results from your tools are stored in a results directory.

Along with these modifications to your .travis.yml, our tool expects/uses the following environment variables. In case you have not used travis-artifacts before, the following is also required:

global: - ARTIFACTS_S3_BUCKET=your_aws_s3_bucket - ARTIFACTS_AWS_ACCESS_KEY_ID=your_aws_key - ARTIFACTS_AWS_SECRET_ACCESS_KEY=your_aws_secret

So simple! :) So easy(bib)!

Fin

In summary, we saw between 1 to 2 minute faster builds. Since we try to keep our builds fast (and usually under 5 minutes), this is a hefty improvement!

We hope the code is useful to others.