rossbruniges

Keybase proof

I hereby claim:

• I am rossbruniges on github.
• I am rossbruniges_mns (https://keybase.io/rossbruniges_mns) on keybase.
• I have a public key whose fingerprint is A7C5 EC18 762C 9216 3CAF 6CEB F0FB 66A9 5EE9 9639

To claim this, I am signing this object:

rossbruniges

The Mo-Factor App

In the spirit of Twelve-Factor Apps, this is a list of concrete things that you can do to make your software better. Some of it overlaps with Twelve-Factor Apps, but it's all good.

Uses git/Github

All of our apps will use git and Github for hosting repositories. This gives us a great collaboration and code review tool, an issue tracker, a wiki, and free static web hosting. All MoFactor apps should be owned by the Mozilla organzation

rossbruniges

The Mo-Factor App

In the spirit of Twelve-Factor Apps, this is a list of concrete things that you can do to make your software better. Some of it overlaps with Twelve-Factor Apps, but it's all good.

Comes in 3 types of flavour

• Stable - something like popcorn.webmaker.org this is a high-end, high traffic site and is built to ensure that it can cope with both fast feature iteration and high peaks in traffic.
• Immature - something like source.mozillaopennews.org this is a site in production but development is less regular and traffic less heavy. However if things do need to move quickly, or if we're especting a planned peak in traffic the app can still cope.

rossbruniges

The Mo-Factor App

In the spirit of Twelve-Factor Apps, this is a list of concrete things that you can do to make your software better. Some of it overlaps with Twelve-Factor Apps, but it's all good.

Uses git/Github

All of our apps will use git and Github for hosting repositories. This gives us a great collaboration and code review tool, an issue tracker, a wiki, and free static web hosting. All MoFactor apps should be owned by the Mozilla organzation

rossbruniges

Traceback (most recent call last):

  File "/srv/www/source/vendor/lib/python/django/core/handlers/base.py", line 136, in get_response
    response = response.render()

  File "/srv/www/source/vendor/lib/python/django/template/response.py", line 104, in render
    self._set_content(self.rendered_content)

  File "/srv/www/source/vendor/lib/python/django/template/response.py", line 81, in rendered_content
    content = template.render(context)

rossbruniges

Mozillas-MacBook-Air:tmp mozilla$ HOMEBREW_MAKE_JOBS=1 VERBOSE=1 brew install postgis
/usr/bin/env python -c import numpy
==> Downloading http://download.osgeo.org/postgis/source/postgis-2.0.2.tar.gz
Already downloaded: /Library/Caches/Homebrew/postgis-2.0.2.tar.gz
/usr/bin/tar xf /Library/Caches/Homebrew/postgis-2.0.2.tar.gz
==> Patching
/usr/bin/patch -f -p1 -i 000-homebrew.diff
patching file configure.ac
==> ./autogen.sh
./autogen.sh 

rossbruniges

~/Library/Logs/Homebrew/postgis largest = ```04.make```

brew doctor output:

```
Mozillas-MacBook-Air:~ mozilla$ brew doctor
Warning: /usr/bin occurs before /usr/local/bin
This means that system-provided programs will be used instead of those
provided by Homebrew. The following tools exist at both paths:

rossbruniges

Cases I've been studying:

https://github.com/sbook/jingo-minify
https://github.com/jsocol/jingo-minify

What I want to have:

- serving the assets either has to modify the file name or move them into a sub-folder. I like the idea of sub-folders but not sure if that's hacky or not, I don't really want to munge the file names. Query strings aren't great as not all browsers cache a file with a query string. The sbook version hacks the file names.
- store build data inside of a YAML file - should this include file by file information or just subset by subset, eg css or js?? File by file would provide more control but would that be a bit too much of a performance hit at runtime. To be fair I can't quite grasp what either build script is doing and having that explained might provide helpful.
- parse CSS files to include version-ed file references in there