Code By
Lucas Mouilleron

66 projects - An Open Source selection

+ testResponsiveImages

JavaScript 96.5% - CSS 3.5%
Last update : 26/11/2014 - 22:42


Install requirements

  • Install NodeJS :
  • sudo npm install bower -g
  • sudo npm install grunt -g
  • sudo gem install sass
  • sudo gem install --pre sass-css-importer


  • cd _build && npm install


  • modify _build/config.json if needed
  • cd _build && grunt build

+ angularRequireJsBoilerplate

JavaScript 96.9% - CSS 3.1%
Last update : 19/11/2014 - 11:57


  • A nice angular requirejs boilerplate
  • Stack : requirejs, angular, scss, bootstrap, fontawesome
  • Build : install, build, watch, grunt, bower


  • Install NodeJS :
  • sudo npm install bower -g
  • sudo npm install grunt -g
  • sudo gem install sass
  • sudo gem install --pre sass-css-importer


  • modify _build/config.json if needed
  • cd _build
  • npm install && grunt build



  • Debug mode :
    • Launch ndex-debug.html instead
    • index-debug.html loads the non compiled version


  • Add a requirejs module from bower :
    • cd _build && bower install the_module --save
    • Then, add path to _dev/js/libs/vendor/the_module/path/to/jsFile in _dev/main.js in path section and include module name in the requirejs call
  • Add a css from bower :
    • cd _build && bower install the_module --save
    • Then edit _dev/scss/main.scss and add @import "CSS:../js/libs/vendor/the_module/the_css_path/the_css_file_without_extension";
  • Add a public resource from bower :
    • cd _build && bower install the_module --save
    • Then edit build/config.json and update the copyFiles value so the files from the vendor path are copyied in the public assets folder

+ githubManagement

PHP 100%
Last update : 14/11/2014 - 10:19


  • Github projects management and processing for entreprisess
  • Respond on created tags on master branch with processors
  • Processors : per project configuration of standard (clone, build, send, etc.) and custom processors to run against a tag hook
  • Relies on Github user roles and access system
  • Small API : create tags on master, respond to Github web hooks, etc.
  • Miscs : loging


  • api : the public API
  • configs : global config and projects config files
  • clones : temporary repos clones (clones for building then copying to web)
  • envs-assets : projects env specific assets
  • libs : libs
  • locks: the locks folder
  • processors : the processors

Users management

  • Relies on Github user roles and access system
  • Users must have a valid Github account
  • To be able to clone and create tags (with the API or not), a user must be granted access to the repo on Github


  • Tag name syntax : .*--deploy==ENV==TARGET
  • ENVs are defined in $PROCESSOR_AVAILABLE_ENVS in configs/config.php
  • If target is ommited, target = "default"
  • The tag must be created on the master branch
  • Wheter the tag is created from the API or from a local repo (and then pushed), the processing will be triggered
  • For the tag to trigger processor, a webhook must be set on the repo. Our small API can take care of it. cf Route 'Init processing'


  • The available processors are located in processors
  • Processors docs can be found in the headers of the processors/* files
  • The main processor must be called first and calls the next processors configured in configs/owner/repo.json->processors
  • All processors extends Processor class (libs/processor.php)
  • All processors must implement the run method
  • All available properties are the public properties of the Processor class



  • The API is used to respond to the Github webhook
  • It can be used as well to init the webhook config or create tags (without clone the project !)
  • Most API calls require a Github user access token :
  • GITHUB_MASTER_TOKEN user must have access to all repos


  • List repos :
    • GET /repos
    • List all managed repos
  • Create a tag :
    • POST /repos/:owner/:repo/tag :
    • Post params : tag-revision, tag-name, tag-message
    • Get param : github-token (the github token of the user)
    • Example : cf tests/api-tests.php
  • Init repo :
    • POST /repos/:repo/init
    • Post params : none
    • Get param : github-token (the github token of the user) (the user must be part of $MASTER_USERS)
    • Create a repo and init hook
    • Example : cf tests/api-tests.php
  • Init hook :
    • POST /repos/:owner/:repo/hook/init
    • Post params : none
    • Get param : github-token (the github token of the user) (use GITHUB_MASTER_TOKEN if called from PHP for administration purpose)
    • Example : cf tests/api-tests.php
  • Github hook :
    • POST /repos/:owner/:repo/hook/:token
    • Called by github on tag create


  • API tests :
  • Processors tests : php tests/processors-test.php
  • In production mode, use a htaccess or remove this folder
  • Debug tip : tail -f processing-owner-repo.log and tail -f api.log
  • Debut tip 2 : some exec error will go in the apache log : tail -f /var/log/apache2/error_log

Install requirements

  • curl -sS | php
  • mv composer.phar /usr/local/bin/composer
  • Apache, mod_rewrite
  • PHP 5.3
  • Unix system (some processors use cp, rsync, ssh, etc.)


  • composer install
  • mv configs/config.php.sample configs/config.php
  • edit the configs/config.php file :
    • change API_PRIVATE_KEY to a random string
    • set APACHE_HOME to an existing folder and make sure Apache can write in it (or sudo mkdir /ghm-tmp && sudo chmod -R 777 /ghm-tmp (the APACHE_HOME folder, defined in configs/config.php)
    • set ENV_PATH so it contains all binaries that might be called from processors (rsync, scp, git), or build files (npm, grunt, etc.)
    • API_URL is where your api is publicly http available
    • set DEBUG to false in production mode
  • Test :

Git workflow

  • This management method is agnostic of pull requests and branches
  • It just helps deploying the master branch when you want (see Triggering



  • Not yet compatible with Github Entreprise (maybe some API differences)
  • better capture exec ouput un tools->run()
  • Could do ENV detection based on what branch the tag has been created (master -> prod, dev -> dev)
  • log cleanup

+ photoshopTools

Last update : 19/10/2014 - 14:36


List of more or less usefull tests for Photoshop.

Web and app oriented.

Grids and guides

  • Guideguide : Guides generator, loads of configuration (breakpoints, columns, padding, gutters), exports as png and scss, Photoshop 5+
  • Spectrr : Annotation tool (text, spacing, sizes), Photoshop 6+
  • Gridpak : Guides (as image) generator, easy configuration (breakpoints, columns and padding), exports as png and scss, Photoshop 5+


  • Cut and Slice Me : Exports groups and layers automaticaly (trimed transparent pngs), clever method : add "@" at the end of the name of group you want exported, Photoshop 6+


  • Invision : Very easy, cloud, Photoshop auto slicing and sycing, comments
  • FramerJS : Convenient framework (animation helpers, states machine, coffee or js), Photoshop auto cutting
  • Reflow : Adobe tool, connects to Photoshop, simple prototyping features (multiple page), responsive aware, review in browser, Photoshop CC+


  • Web Zap : Layout builder, text layout builder (multiple font swap), UI builder, Photoshop 6+
  • Velositey : Layout builder, guides nice features, favicon generator



+ emailBuilder

CSS 67.8% - JavaScript 32.2%
Last update : 19/10/2014 - 14:33

A grunt based email builder for designing, testing and publishing.

  • Multiple campaigns and email
  • Templates : Ink from Zurb, Mailchimp blueprints
  • Saas, handlebars, inlining
  • Mandrill, AWS S3



  • cd _build
  • npm install
  • cp campaigns/config.json.sample campaigns/config.json
  • Type grunt and follow instructions


  • grunt _build : Builds a campaign to campaign-dist/campaign_name
  • grunt watchit : Watches and builds a campaign
  • grunt prod : Prepare campaign for prod (CDNfys assets) (the campaign-dist/campaign_name html files are production ready)
  • grunt test : Sends a test email of a campaign (requires CDN)
  • grunt send : Sends an email of a campaign (requires CDN)


  • Archives and templates are located campaign-archives
  • Campaigns are located in campaigns
  • One campaign can contain more than one email
  • Configuration :
    • Global config is defined in campaigns/config.json
    • Per campaign config can be overrided : add a config.json file in the campaign folder


  • Emails are written with handlebars format
  • Assets basepath is ./ : <img src="logo.png" height="50" alt="Mailgun"> or <link href="main.css" media="all" rel="stylesheet" type="text/css"/>
  • Templates :
    • Ink framework from Zurb : classes and guidelines doc : in campaigns-archive/_zurb
    • Mailchimp responsive blueprints : sources : in campaigns-archive/_mailchimp
    • Mailgun transactional emails : sources : in campaigns-archive/_mailgun


  • Email sending is taking care by mandrill, which is great
  • Create a manrill account and an API key
  • Configuration : subject, sender, receivers and mandrillKey in config.json (global or local)


  • Uses AWS S3 as a CDN
  • Configuration : set awsKey, awsSecretAccessKey and awsBucket in config.json (global or local)
  • Create the bucket on S3 (the name you defined in awsBucket)


  • Create a test project in Litmus
  • Change the receivers in config.json to the adress given by Litmus

Email design best practices (reminder, as the templates we provide are compliant)

  • Simple and clear subject (not in full caps, no !!!!!)
  • Main information withing the first 300px
  • Linear structure
  • Use a template boilerplate to avoid basic structure mistakes
  • No white text
  • Standard fonts (arial, times new roman)
  • No shapes or images in text background (only plain color)
  • No videos, no javascript
  • Center contents with <center>
  • Use alt attribute for images fallback (no special characters)
  • Inline CSS


+ testFramerJS

JavaScript 99.9% - CSS 0.1%
Last update : 24/09/2014 - 15:05
  • Made with FramerStudio