- Separate front end "client" deployment and build process from backend deployment.
- Not necessarily have to create two completely distinct applications (because of authentication difficulties etc), but could go in that direction if needed.
- Migratable to from the asset pipeline & compatible with rails.
- Support coffeescript, sass compilation.
- Allow lightweight "staging" clients to be deployed using the existing backend. Ideally even use the production backend with a development client.
- Fast compilation and deployment.
/** @jsx createNode */ | |
function createNode(tagName, attrs, ...children) { | |
const node = attrs || {}; | |
node.name = tagName; | |
if (children && children.length > 0) { | |
node.children = children; | |
} | |
return node; | |
} |
Here's where I am at with things for Float:
- done a load of stuff with backbone, and it's what we use in production
- played with ember, but nothing too serious. Thinking it might be good for Float, but it's got a steep learning curve initially, so it may never happen.
Having read http://trek.github.com and worked through the examples, and compared it to what I've done in backbone. My thoughts are:
scrub-anchor "com.apple/*" | |
nat-anchor "com.apple/*" | |
rdr-anchor "com.apple/*" | |
rdr-anchor "forwarding" | |
dummynet-anchor "com.apple/*" | |
anchor "com.apple/*" | |
load anchor "com.apple" from "/etc/pf.anchors/com.apple" | |
load anchor "forwarding" from "/etc/pf.anchors/mitm" |
- Team Dashboard - http://fdietz.github.io/team_dashboard/
- Geckoboard - http://www.geckoboard.com/ - Slick data dashboards.
- Leftronic - https://www.leftronic.com/ - Similar, doesn't seem quite as organised looking
- Dashing - http://shopify.github.io/dashing/ - Simple metric dashboards by Shopify. Widget list
- HighCharts - http://www.highcharts.com/ Not very inspiring but very widely used & performant
- Google Charts - https://developers.google.com/chart/ Again, not very inspiring but can be customised
- Flot - http://www.flotcharts.org/ Gorgeous slick HTML5 graphs
rdr pass on en0 inet proto tcp to any port 80 -> 127.0.0.1 port 8080 | |
rdr pass on en0 inet proto tcp to any port 443 -> 127.0.0.1 port 8080 |
On Twitter the other day, I was lamenting the state of OCSP stapling support on Linux servers, and got asked by several people to write-up what I think the requirements are for OCSP stapling support.
-
Support for keeping a long-lived (disk) cache of OCSP responses.
This should be fairly simple. Any restarting of the service shouldn't blow away previous responses that were obtained. This doesn't need to be disk, just stable - and disk is an easy stable storage for most server
from fractions import gcd, Fraction | |
def intSqrt(n): | |
""" | |
Computes the integer square root of n, i.e. | |
the greatest x : x*x <= n | |
""" | |
x = n | |
y = (x + n // x) // 2 |
This was originally posted on 2011-04-05 to http://andrewho.co.uk/weblog/vim-pathogen-with-mutt-and-git
For a long time I've used vim as my editor for both composing messages in mutt
and commit messages for git. I do this with the following line in my
~/.muttrc
(and a similar one in my ~/.gitconfig
:
set editor = "vim -c 'set wrap tw=76 fo=toqwal12 nonumber spell' +1"
Recently I refactored my vim configuration files using Tim Pope's excellent [pathogen][1] script. Doing so required me to place the following lines in my