This specification is inspired by and supersedes the [AngularJS commit message format][commit-message-format].
We have very precise rules over how our Git commit messages must be formatted. This format leads to easier to read commit history.
Each commit message consists of a header, a body, and a footer.
| /* (320x480) iPhone (Original, 3G, 3GS) */ | |
| @media only screen and (min-device-width: 320px) and (max-device-width: 480px) { | |
| /* insert styles here */ | |
| } | |
| /* (320x480) Smartphone, Portrait */ | |
| @media only screen and (device-width: 320px) and (orientation: portrait) { | |
| /* insert styles here */ | |
| } | |
The default behavior of Gradle to pick the newest version also applies if a lower version has been declared locally, but another dependency transitively pulls in a newer version. This is in contrast with Maven, where a locally declared version will always win.
For example, if your build.gradle specifies the dependency org.springframework:spring-tx:3.2.3.RELEASE, and another dependency declares 4.0.5.RELEASE as a transitive dependency, then 4.0.5.RELEASE will take precedence:
dependencies {
compile("org.springframework.data:spring-data-hadoop:2.0.0.RELEASE")
compile("org.springframework:spring-tx:3.2.3.RELEASE")
// will select org.springframework:spring-tx:4.0.5.RELEASE
(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.
When hosting our web applications, we often have one public IP
address (i.e., an IP address visible to the outside world)
using which we want to host multiple web apps. For example, one
may wants to host three different web apps respectively for
example1.com, example2.com, and example1.com/images on
the same machine using a single IP address.
How can we do that? Well, the good news is Internet browsers
**~~ NOTE: This is a Stage 0 proposal. ~~**
Please direct all future feedback to that repo in the form of directed issues.
| #!/usr/bin/env node --harmony-generators | |
| var fs = require('fs') | |
| , thunkify = require('thunkify') | |
| , co = require('co') | |
| , readFile = thunkify(fs.readFile) | |
| , fns = ["file0.txt", "file1.txt" | |
| , "file2.txt", "file3.txt"] | |
| co(function*(){ | |
| var contents = '', i |
There was a [great article][1] about how react implements it's virtual DOM. There are some really interesting ideas in there but they are deeply buried in the implementation of the React framework.
However, it's possible to implement just the virtual DOM and diff algorithm on it's own as a set of independent modules.
When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');Those suck for maintenance and they're ugly.
| #include <stdio.h> | |
| #include <uv.h> | |
| static void on_close(uv_handle_t* handle); | |
| static void on_connect(uv_connect_t* req, int status); | |
| static void on_write(uv_write_t* req, int status); | |
| static uv_loop_t *loop; | |
| static uv_buf_t alloc_cb(uv_handle_t* handle, size_t size) { |