derEremit

#!/usr/bin/env bash
# Generates gource video (h.264) out of multiple repositories.
# Pass the repositories in command line arguments.
# Example:
# <this.sh> /path/to/repo1 /path/to/repo2

RESOLUTION="1600x1080"
outfile="gource.mp4"

i=0

okapies

import scala.runtime.ScalaRunTime

/**
 * A sample code to implement a customized case class manually (for Scala 2.9.2 final).
 *
 * Id has two properties: name and displayName. 'displayName' has default value that
 * is same value as 'name'.
 */
class Id private ( // make primary constructor not to be accessible. (standard case class can do)

MohamedAlaa

tmux shortcuts & cheatsheet

start new:

tmux

start new with session name:

tmux new -s myname

nikcub

In August 2007 a hacker found a way to expose the PHP source code on facebook.com. He retrieved two files and then emailed them to me, and I wrote about the issue:

http://techcrunch.com/2007/08/11/facebook-source-code-leaked/

It became a big deal:

http://www.techmeme.com/070812/p1#a070812p1

The two files are index.php (the homepage) and search.php (the search page)

1wErt3r

;SMBDIS.ASM - A COMPREHENSIVE SUPER MARIO BROS. DISASSEMBLY
;by doppelganger (doppelheathen@gmail.com)

;This file is provided for your own use as-is.  It will require the character rom data
;and an iNES file header to get it to work.

;There are so many people I have to thank for this, that taking all the credit for
;myself would be an unforgivable act of arrogance. Without their help this would
;probably not be possible.  So I thank all the peeps in the nesdev scene whose insight into
;the 6502 and the NES helped me learn how it works (you guys know who you are, there's no 

rxaviers

People

:bowtie:	😄 :smile:	😆 :laughing:
😊 :blush:	😃 :smiley:	☺️ :relaxed:
😏 :smirk:	😍 :heart_eyes:	😘 :kissing_heart:
😚 :kissing_closed_eyes:	😳 :flushed:	😌 :relieved:
😆 :satisfied:	😁 :grin:	😉 :wink:
😜 :stuck_out_tongue_winking_eye:	😝 :stuck_out_tongue_closed_eyes:	😀 :grinning:
😗 :kissing:	😙 :kissing_smiling_eyes:	😛 :stuck_out_tongue:

jedfoster

// ----
// Sass (v3.3.0.rc.1)
// Compass (v0.13.alpha.10)
// ----

body {
  width: 100%;
  height: 10em;
  background: mix(#ff0000, #0000bb, 75);
}

marlun78

# How to install `ipkg` on a Synology DS214

After a couple of days of trying to get `ipkg` woking on my DS214 I found [this article](https://github.com/trepmag/ds213j-optware-bootstrap) by [trepmag](https://github.com/trepmag). It is written for the DS213j, but it’s been working for me and [others](https://github.com/alberthild) for the DS214 too. 

I have done some minor changed to clarify some things, but if you are a Linux guy (unlike me) my changes might be of no use to you. 


## Guide

viktorklang

import scala.concurrent.duration._
import scala.concurrent.ExecutionContext
import scala.concurrent.Future
import akka.pattern.after
import akka.actor.Scheduler

/**
 * Given an operation that produces a T, returns a Future containing the result of T, unless an exception is thrown,
 * in which case the operation will be retried after _delay_ time, if there are more possible retries, which is configured through
 * the _retries_ parameter. If the operation does not succeed and there is no retries left, the resulting Future will contain the last failure.

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.