It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.
/* | |
Go on your labels page (https://github.com/user/repo/labels) | |
Edit the following label array | |
or | |
Use this snippet to export github labels (https://gist.github.com/MoOx/93c2853fee760f42d97f) | |
and replace it | |
Paste this script in your console | |
Press Enter!! |
// go on you labels pages | |
// eg https://github.com/cssnext/cssnext/labels | |
// paste this script in your console | |
// copy the output and now you can import it using https://github.com/popomore/github-labels ! | |
var labels = []; | |
[].slice.call(document.querySelectorAll(".label-link")) | |
.forEach(function(element) { | |
labels.push({ | |
name: element.textContent.trim(), |
Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.
For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.
But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.
SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil
(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.
/* | |
Swift Programming Language Guide | |
"A Swift Tour" Solutions | |
https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2-XID_1 | |
These are the solutions to all the "experiments" in the pre-release Swift Programming Guide | |
(released on the same day Apple announced Swift). A couple of things worth noting: | |
1. Swift syntax, e.g. array declarations, has changed since I releasd these. So this code will | |
probably cause some errors when you paste it into a playground. Should be easy enough to fix |
APPENGINE_RUNTIME | python27 |
APPLICATION_ID | s~appid |
AUTH_DOMAIN | gmail.com |
CONTENT_LENGTH | 148 |
CONTENT_TYPE | application/x-www-form-urlencoded |
CURRENT_MODULE_ID | default |
CURRENT_VERSION_ID | appid.370290628632119235 |
DATACENTER | us1 |
DEFAULT_VERSION_HOSTNAME | appid.appspot.com |
HTTPS | on |
from google.appengine.ext import ndb | |
class DynamicPropertyMixin(object): | |
""" Facilitates creating dynamic properties on ndb.Expando entities. | |
Also works on ndb.Model derived classes! | |
Note: keyword args are passed on to the underlying ndb.XxxProperty() class | |
""" | |
def is_prop(self, name): |