Hi there!
The docker cheat sheet has moved to a Github project under https://github.com/wsargent/docker-cheat-sheet.
Please click on the link above to go to the cheat sheet.
{ | |
"browser": true, | |
"node": true, | |
"curly": true, | |
"devel": true, | |
"globals": { | |
"ActiveXObject": true, | |
"async": true, | |
"moment": true, |
/** @jsx React.DOM */ | |
define([ | |
'react', | |
'modernizr', | |
'punycode' | |
], function(React, Modernizr, punycode) { | |
/** | |
* Replaces the emojis in a text string with <img> tags |
import React from 'react'; | |
import User from 'user'; | |
import UserComponent from 'user-component'; | |
var user = new User.Model({id: 1}); | |
React.renderComponent(User({user: user}), document.body); |
Hi there!
The docker cheat sheet has moved to a Github project under https://github.com/wsargent/docker-cheat-sheet.
Please click on the link above to go to the cheat sheet.
@holman got a request about our deployment system, heaven
I know it's not a high priority, but has there been any activity on open-sourcing the core Heaven gem?
There is. I've been working on extracting the non-GitHub specific parts into two gems. This first is a CLI portion called hades. The second is an HTTP API portion called heaven.
When you open source something previously used as in internal tool like Heaven, Hubot, Boxen, etc., how do you manage and hook in the parts that need to stay internal?
Normally I focus around four questions:
# | |
# Mac OS-X does not come with the delightfully useful `timeout` program. Thankfully a rough BASH equivalent can be achieved with only 2 perl statements. | |
# | |
# Originally found on SO: http://stackoverflow.com/questions/601543/command-line-command-to-auto-kill-a-command-after-a-certain-amount-of-time | |
# | |
function timeout() { perl -e 'alarm shift; exec @ARGV' "$@"; } | |
## Example usage: | |
# |
<div class="norway"> | |
<style type="text/css"> | |
.norway { | |
position: relative; | |
color: #393939; | |
font-family: 'PFDinTextCompPro-Light', sans-serif; | |
text-shadow: 0px 1px 1px rgba(255, 255, 255, 0); | |
} | |
.b-plan__special-white-edging { | |
background-image: url('http://pst0.iknow.travel.s3.amazonaws.com/koc/white-border.png'); |
/**********************************************/ | |
/* | |
/* | |
/* Crate -- Theme for Chrome DevTools | |
/* Last Update :: September 2013 | |
/* | |
/* based on: | |
/* mnml by Michael P. Pfeiffer | |
/* Based on a Gist by Ben Truyman. Further attr: | |
/* https://gist.github.com/3040634 |
I'm having trouble understanding the benefit of require.js. Can you help me out? I imagine other developers have a similar interest.
From Require.js - Why AMD:
The AMD format comes from wanting a module format that was better than today's "write a bunch of script tags with implicit dependencies that you have to manually order"
I don't quite understand why this methodology is so bad. The difficult part is that you have to manually order dependencies. But the benefit is that you don't have an additional layer of abstraction.