Code By
Lucas Mouilleron

Features

• Simple tests of responsive images with srcset
• Polyfills
• Smashing article
• AlistAppart article

Install requirements

• Install NodeJS : http://nodejs.org/download
• sudo npm install bower -g
• sudo npm install grunt -g
• sudo gem install sass
• sudo gem install --pre sass-css-importer

Install

• cd _build && npm install

Build

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

Features

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

Install

• Install NodeJS : http://nodejs.org/download
• sudo npm install bower -g
• sudo npm install grunt -g
• sudo gem install sass
• sudo gem install --pre sass-css-importer

Build

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

Notes

• Compatible with phantomJS snapshoting
  • Controllers update the data-status of the body tag when they finished
  • cf https://github.com/lucasmouilleron/phantomJSBoilerplate

RequireJS

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

Bower

• 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

Features

• 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

Architecture

• 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

Triggering

• 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'

Processors

• 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

API

Overview

• 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 : https://github.com/settings/applications#personal-access-tokens
• GITHUB_MASTER_TOKEN user must have access to all repos

Routes

• 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

Tests

• API tests : http://public.url.to.the.api.folder.com/tests/api-tests.php
• 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 https://getcomposer.org/installer | php
• mv composer.phar /usr/local/bin/composer
• Apache, mod_rewrite
• PHP 5.3
• Unix system (some processors use cp, rsync, ssh, etc.)

Install

• 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 : http://public.url.to.the.api.folder.com

Git workflow

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

Docs

• Using branches
• Git flows
• GitFlow doc
• Pull requests good practices
• Github Flow
• Hub tool (generate pull requests links)

TODO

• 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

Motivations

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+

Cuting

• 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+

Prototyping

• 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+

Layouts

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

Exports

• SVG export : Exports shapes and group of shapes to SVGs, Photoshop CC+
• Perspective mockup : Exports mockup in perspective, Photoshop 6+

Miscs

• Dream keyboard shorcuts
• Interface Tools : Panel with web design tools shortcuts, Photoshop 6+

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

Installation

• Node.js : Install Node.js
• Grunt-cli and Grunt : npm install grunt-cli -g
• Ruby : Install ruby with RVM
• Premailer : gem install sass premailer hpricot nokogiri
• Mandrill (optional, sends test emails) : Create a Mandrill account
• Litmus (optional, tests email across clients/browsers/devices) : Create a Litmus account
• AWS S3 (optional, CDN) : Create an AWS S3 account

Run

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

Tasks

• 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)

Campaigns

• 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

• 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

Sending

• 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)

CDN

• 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)

Litmus

• 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

Credits

• Heavily based on https://github.com/leemunroe/grunt-email-design
• Thanks to the guys at Zurb

• Made with FramerStudio
• http://framerjs.com