afuggini

#!/bin/bash
# file: ttfb.sh
# curl command to check the time to first byte
# ** usage **
# 1. ./ttfb.sh "https://google.com"
# 2. seq 10 | xargs -Iz ./ttfb.sh "https://google.com"

curl -o /dev/null \
     -H 'Cache-Control: no-cache' \
     -s \

afuggini

// this is the background code...

// listen for our browerAction to be clicked
chrome.browserAction.onClicked.addListener(function (tab) {
	// for the current tab, inject the "inject.js" file & execute it
	chrome.tabs.executeScript(tab.ib, {
		file: 'inject.js'
	});
});

afuggini

/*
 * Inspiration (well… copy pasting more or less) from:
 * https://github.com/ScottHamper/Cookies/blob/0.3.1/src/cookies.js#L127-L140
 *
 * Thanks Scott!
 */
(function (global) {
    'use strict';

    var MyModule = function () {

afuggini

files:
  "/tmp/proxy.conf":
    mode: "000644"
    owner: root
    group: root
    content: |

      proxy_send_timeout 600;
      proxy_read_timeout 600;
      send_timeout       600;

afuggini

var defaults = {
    number: 1,
    bool: true,
    magic: 'real',
    animal: 'whale',
    croutons: 'delicious'
};

var options = {
    number: 2,

afuggini

// #1 ES6: if passing one argument you don't need to include parenthesis around parameter.
var kitty = name => name;

// same as ES5:
var kitty = function(name) {
  return name;
};

// #2 ES6: no parameters example.
var add = () => 3 + 2;

afuggini

TL;DR

Meteor is great at sharing code between different builds for different platforms. You can use the same source for your browser builds, server builds, your builds for iOS, Android, ... But how to organize your project to be able to orchestrate your builds for different apps and services from the same source? This post elaborates on the reasons why you need these different builds and how you could accomplish this with Meteor easily.

Use cases: Why would you build different apps?

1. Different apps for different roles

Say you have an app with completely different end user experiences depending on their role. It is common practice to have the user logged in, check her authorization (role) and then setup different routes or load different templates to serve that type of user’s needs. While doing so, all types of users load the same build and the app decides what portions of the build to use and what not to use.

afuggini

{
  "vars": {
    "@gray-base": "#000",
    "@gray-darker": "lighten(@gray-base, 13.5%)",
    "@gray-dark": "lighten(@gray-base, 20%)",
    "@gray": "lighten(@gray-base, 33.5%)",
    "@gray-light": "lighten(@gray-base, 46.7%)",
    "@gray-lighter": "lighten(@gray-base, 93.5%)",
    "@brand-primary": "darken(#428bca, 6.5%)",
    "@brand-success": "#5cb85c",

afuggini

.factory('genericCollectionFactory',function(){

    function Collection() {
      var _items = [];

      function get () {
        return _items;
      }

      function add (item) {

afuggini

Template.foo.helpers({
  data1: function(){
    var array = [];
    var storedData = Session.get("data");
    //underscore
    _.each(Object.keys(storedData),function(key){
      array.push(storedData[key]);
    });
    return array;
  },