- Create or find a gist that you own.
- Clone your gist (replace
<hash>
with your gist's hash):# with ssh git clone git@gist.github.com:<hash>.git mygist # with https
git clone https://gist.github.com/.git mygist
diff --git a/builddefs/common_features.mk b/builddefs/common_features.mk | |
index 18f8b0bbfc..4ef3e230e4 100644 | |
--- a/builddefs/common_features.mk | |
+++ b/builddefs/common_features.mk | |
@@ -878,6 +878,10 @@ ifeq ($(strip $(JOYSTICK_ENABLE)), yes) | |
endif | |
endif | |
+ifeq ($(strip $(APPLE_FN_ENABLE)), yes) | |
+ OPT_DEFS += -DAPPLE_FN_ENABLE |
import scala.util.{Success, Failure} | |
val seq=Seq(Success(1), Failure(new Exception("bang")), Success(2)) | |
// all emit List(1, 2) | |
seq.map(_.toOption).flatten | |
seq.flatMap(_.toOption) | |
seq.filter(_.isSuccess).map(_.get) | |
seq.collect{case Success(x) => x} |
<hash>
with your gist's hash):
# with ssh
git clone git@gist.github.com:<hash>.git mygist
# with https
git clone https://gist.github.com/.git mygist
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?
(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.
On the Refinery29 Mobile Web Team, codenamed "Bicycle", all of our unit tests are written using Jasmine, an awesome BDD library written by Pivotal Labs. We recently switched how we set up data for tests from declaring and assigning to closures, to assigning properties to each test case's this
object, and we've seen some awesome benefits from doing such.
Up until recently, a typical unit test for us looked something like this:
describe('views.Card', function() {
var assert = require('assert'); | |
/** | |
* Default pattern | |
* | |
* Inherits properties added to this and prototype | |
*/ | |
// parent constructor: | |
function Parent(name) { |
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.
This article has been given a more permanent home on my blog. Also, since it was first written, the development of the Promises/A+ specification has made the original emphasis on Promises/A seem somewhat outdated.
Promises are a software abstraction that makes working with asynchronous operations much more pleasant. In the most basic definition, your code will move from continuation-passing style:
getTweetsFor("domenic", function (err, results) {
// the rest of your code goes here.
// Source: https://groups.google.com/forum/#!topic/angular/hVrkvaHGOfc | |
// jsFiddle: http://jsfiddle.net/pkozlowski_opensource/PxdSP/14/ | |
// author: Pawel Kozlowski | |
var myApp = angular.module('myApp', []); | |
//service style, probably the simplest one | |
myApp.service('helloWorldFromService', function() { | |
this.sayHello = function() { | |
return "Hello, World!" |