How to work with a non-Composer 3rd party library in Laravel

Below are steps that have been working for me when using 3rd party libraries in a Laravel 4 project.

The first step is to add a repository to composer.json:

"repositories": [
  {
    "type": "package",
    "package": {
      "name": "netboy/Image_Iptc",
      "version": "master",
      "source": {
        "url": "https://github.com/netboy/Image_Iptc.git",
        "type": "git",
        "reference": "master"
      }
    }
  }
],

This will allow us to require the library in composer.json:

"require": {
  ...
  "netboy/Image_Iptc": "dev-master"
},

Finally we should add the lib to the autoload section:

"autoload": {
  "classmap": [
    ...
    "vendor/netboy/Image_Iptc/Iptc.php"
  ]
},

And update dependencies:

composer update

How to make Bootstrap look a little less like Bootstrap

Bootstrap (now in version 3) is great, but the more sites are using it, the more the web is starting to look the same. Luckily, with not much work there can be something done to transform the visual style of Bootstrap!

Bootswatch is a site that demonstrates a few interesting interfaces built on the Bootstrap foundation. They all look quite different and have funny names like Amelia, Cyborg or Simplex. Bootswatch is a proof that you can actually get creative when working with Bootstrap. All themes can be downloaded for free.

Taking it a step further Bootswatch can be used to create a customized Bootstrap theme with what the authors call Swatchmaker. You will be modifying two stylesheets (variables.less and bootswatch.less) and building a custom version of the framework.

The documentation is quite clear of all the steps required to build a custom Bootstrap theme and from my experience it all works really well…!

Remove default input styling from WebKit

WebKit automatically adds rounded corners and inset shadows to input elements. You may be tempted to remove the default styling with two prefixed properties:

input {
  -webkit-appearance: none;
  -webkit-border-radius: 0;
}

But, don’t do it!

Unless you want all checkboxes and radio buttons to disappear in recent versions of Chrome and Safari and look really weird on iOs 5/6. A better way of resetting input element styling is to be specific about input type. For example:

input[type=text],
input[type=email],
input[type=tel],
input[type=url],
input[type=search] {
  appearance: none;
  -moz-appearance: none;
  -webkit-appearance: none;
 
  border-radius: 0;
  -moz-border-radius: 0;
  -webkit-border-radius: 0;
}

Testing jQuery code with Mocha, Chai and jsdom

Testing jQuery code (in particular jQuery plugins) can be a lot of fun. Below you will find a few tips on setting up the testing environment on MacOS X and running tests with Mocha, Chai and jsdom.

Mocha vs other test frameworks

Why did I choose Mocha? Jasmine also looks very nice and many people are happy with it, but its development seems to be a little slow lately. Mocha has good documentation and all the features I could ask for, so I decided to give it a try instead. Also let’s not forget Mocha has a nyan cat reporter:

Getting ready

Ideally the jQuery plugin we are going to test should be object-oriented. There are many ready, well-designed boilerplates that help to structure a plugin in an object-oriented way. I found this boilerplate quite useful. But I also wanted it to accept a method and/or options when calling the plugin in this way:

$("element").myplugin();
 
or
 
$("element").myplugin({ option1: true, option2: true });
 
or
 
$("element").myplugin("some_other_method");
 
or
 
$("element").myplugin("some_other_method", { option1: true, option2: true });

Here is a yet another take on a jQuery plugin boilerplate (with inline comments):

https://gist.github.com/3871611

UPDATE, October 2013: Starting a new jQuery plugin? Check out jQuery Boilerplate.

Setting up Mocha

While setting up Mocha I first learned about package.json. This is where we can define all dependencies for our jQuery project. It looks something like this:

{
  "name": "jquery-bar-rating",
  "description": "Minimal, light-weight jQuery ratings."
  "version": "0.1.0",
  "main": "./jquery.barrating",
  "devDependencies": {
    "mocha": "*",
    "chai": "*",
    "jsdom": "*",
    "jquery": "*"
  }
}

With a package.json file in place installing Mocha and all its dependencies is as simple as running “npm install” in the project directory. I assume npm is installed on the system. If not, installing npm is explained on the nodejitsu blog.

Bootstrapping DOM

Usually jQuery acts on DOM elements. But what if we want to execute tests outside of the browser environment, on the command line? jsdom (JavaScript implementation of the W3C DOM) will fill that gap. With jsdom you will be able to bootstrap a DOM by loading a document from an URL with jsdom.env() method or creating it from scratch:

var jsdom = require("jsdom").jsdom;
var doc = jsdom('');
var window = doc.createWindow();

Writing tests

Mocha works with a few different assertion libraries. I picked Chai.js, because I liked its BDD assertion styles. You can choose between “expect” or “should” interfaces for writing tests or mix both. “Expect” interface is recommended over “should”, because it is fully compatible with Internet Explorer once you would decide to run tests in the browser.

describe('bar rating plugin on show', function () {
  beforeEach(function () {
    $('#rating').barrating('show');
  });
 
  it('should be initialized', function () {
    expect($('#rating').data('barrating')).to.be.a('object');
  });
});

Tests should live in a spec file inside the “test” directory. See an example of a spec file with a few Mocha tests.

Running tests

./node_modules/mocha/bin/mocha

Don’t forget to add “node_modules” to .gitignore if you are using git.

More information

Visit Mocha and Chai documentation for more details on writing tests.

Faster web fonts

Browsers can be quite slow in loading and rendering web fonts. Chrome seems to lead the pack in how fast it can handle font loading, although this observation is not backed up by any hard data… Luckily there are a few simple optimizations that can help to make fonts load faster.

What I learned works best (Javascript based solutions aside) is:

1. Caching.
https://gist.github.com/794800

2. Loading fonts early
Moving @font-face declarations to the top of the document before any other scripts or stylesheets.

3. Making sure there are no failed requests.
This sounds like a no-brainer, but the rule is not to link to files that cannot be found on the server. A failed request to a WOFF file or any other font file can really mess up font loading. I always try to double check that all HTTP requests are successful in the Net panel of Firebug.

Further reading:

The following webpage is a true gold mine of information on how to fight the @font-face FOUT (Flash of unstyled text) problem.

http://paulirish.com/2009/fighting-the-font-face-fout/