# TODO: | |
# Runner like https://github.com/elixir-lang/ecto/blob/master/lib/ecto/migration.ex (does it have state?) | |
defmodule Ecto.Runner do | |
def start_command({:create, table}) do | |
IO.puts "create table: #{table}" | |
end | |
def subcommand({:add, column, type}) do | |
IO.puts "add column: #{column}(#{type})" |
// Simple wrapper to use bootstrap's grid system to position elements side-by-side | |
var VerticalFieldsElement = React.createClass({ | |
render: function() { | |
return dom.div( | |
{ className: 'clearfix' }, | |
React.Children.map(this.props.children, function(child) { | |
if(!child) { | |
return child; | |
} |
I've been looking for the best Linux backup system, and also reading lots of HN comments.
Instead of putting pros and cons of every backup system I'll just list some deal-breakers which would disqualify them.
Also I would like that you, the HN community, would add more deal breakers for these or other backup systems if you know some more and at the same time, if you have data to disprove some of the deal-breakers listed here (benchmarks, info about something being true for older releases but is fixed on newer releases), please share it so that I can edit this list accordingly.
- It has a lot of management overhead and that's a problem if you don't have time for a full time backup administrator.
type alias Bounds = { | |
left : Float, | |
right : Float, | |
top : Float, | |
bottom : Float | |
} | |
bounds : Bounds | |
bounds = Bounds 0 0 0 0 |
Hello, visitors! If you want an updated version of this styleguide in repo form with tons of real-life examples… check out Trellisheets! https://github.com/trello/trellisheets
“I perfectly understand our CSS. I never have any issues with cascading rules. I never have to use !important
or inline styles. Even though somebody else wrote this bit of CSS, I know exactly how it works and how to extend it. Fixes are easy! I have a hard time breaking our CSS. I know exactly where to put new CSS. We use all of our CSS and it’s pretty small overall. When I delete a template, I know the exact corresponding CSS file and I can delete it all at once. Nothing gets left behind.”
You often hear updog saying stuff like this. Who’s updog? Not much, who is up with you?
function makeStyle(defaults, tagName) { | |
tagName = tagName || 'div'; | |
var Style = React.createClass({ | |
getDefaultProps: function() { | |
return assign({}, defaults); | |
}, | |
render: function() { | |
var style = assign({}, this.props); | |
delete style.children; |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
In many production systems you'll want to have one module capable of talking to many potential implementations of a collaborator module (e.g a in memory cache, a redis-based cache etc). While testing it's useful to control which module the module under test is talking to.
Here are the approaches I can see. The two points that seem to divide the approaches are their tool-ability (dialyzer) and their ability to handle stateful implementations (which need a pid
).
Modules are first class, so you can pass them in. Used in EEx, where passed module must implement a behaviour.
(function() { | |
// Do not use this library. This is just a fun example to prove a | |
// point. | |
var Bloop = window.Bloop = {}; | |
var mountId = 0; | |
function newMountId() { | |
return mountId++; | |
} |