Scalaz | |||
Symbol | Code | Ascii | Example |
---|---|---|---|
η | 951 | pure | 1.η[List] |
μ | 03BC | join | List(List(1,2,3), nil, List(5,6,7)) μ |
∅ | 2205 | zero | ∅[Int] |
<∅> | empty | <∅>[Option, Int] |
|
∙ | 2219 | contramap | ((_:String).length ∙ (_:Int).toString ∙ ((_:Int) + 6))(5) |
∘ | 2218 | map | (((_:Int) + 6) ∘ (_:Int).toString ∘ (_:String).length)(5) |
∘∘ |
This example pulls together various examples of work with trees in D3.js.
The panning functionality can certainly be improved in my opinion and I would be thrilled to see better solutions contributed.
One can do all manner of housekeeping or server related calls on the drop event to manage a remote tree dataset for example.
Dragging can be performed on any node other than root (flare). Dropping can be done on any node.
Panning can either be done by dragging an empty part of the SVG around or dragging a node towards an edge.
var gulp = require('gulp'); | |
var browserify = require('gulp-browserify'); | |
var concat = require('gulp-concat'); | |
var styl = require('gulp-styl'); | |
var refresh = require('gulp-livereload'); | |
var lr = require('tiny-lr'); | |
var server = lr(); | |
var paths = { | |
js: 'src/**/*.js', |
WebSockets is a modern HTML5 standard which makes communication between client and server a lot more simpler than ever. We are all familiar with the technology of sockets. Sockets have been fundamental to network communication for a long time but usually the communication over the browser has been restricted. The general restrictions
- The server used to have a permanent listener while the client (aka browser) was not designated any fixed listener for a more long term connection. Hence, every communication was restricted to the client demanding and the server responding.
- This meant that unless the client requested for a particular resource, the server was unable to push such a resource to the client.
- This was detrimental since the client is then forced to check with the server at regular intervals. This meant a lot of libraries focused on optimizing asynchronous calls and identifying the response of asynchronous calls. Notably t
In line with current trends toward lean and simple software solutions reviving and repurposing long-established standards (open plain text vs proprietary rich text formats; file-based static site generators vs bloated database-driven CMSs), the present proposal inquires into a method (and its application) to device a lightweight, general-purpose solution for small-scale digital asset management.
No database is to be used, there shall be no external dependencies, all information carriers should be self-containing, and everything would be file-based. The software would build on a (yet to be established) convention of file naming, which would store metadata for arbitrary files inside the file name, advancing its portability across platforms.
Put as a — somewhat far-fetched — YC-style one-liner pitch: this proposal is about *
(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.
(Chapters marked with * are already written. This gets reorganized constantly | |
and 10 or so written chapters that I'm on the fence about aren't listed.) | |
Programmer Epistemology | |
* Dispersed Cost vs. Reduced Cost | |
* Verificationist Fallacy | |
* Mistake Metastasis | |
The Overton Window | |
Epicycles All The Way Down | |
The Hyperspace Gates Were Just There |
/** | |
* Examples of writing mixed unit/property-based (ScalaCheck) tests. | |
* | |
* Includes tables and generators as well as 'traditional' tests. | |
* | |
* @see http://www.scalatest.org/user_guide/selecting_a_style | |
* @see http://www.scalatest.org/user_guide/property_based_testing | |
*/ | |
import org.scalatest._ |
Copy nbflatten.py to somewhere on $PATH. Then, in the root of a git repository, run these commands:
echo "*.ipynb diff=ipynb" >> .gitattributes
git config diff.ipynb.textconv nbflatten.py
When you change a notebook and run git diff
, you'll see the diff of flattened, simplified notebooks, rather than the full JSON. This does lose some information (metadata, non-text output), but it makes it easier to see simple changes in the notebook.
This doesn't help with merging conflicting changes in notebooks. For that, see nbdiff.org.
Disclaimer: This is an unofficial post by a random person from the community. I am not an official representative of io.js. Want to ask a question? open an issue on the node-forward
discussions repo
- io is a fork of node v0.12 (the next stable version of node.js, currently unreleased)
- io.js will be totally compatible with node.js
- the people who created io.js are node core contributors who have different ideas on how to run the project
- it is not a zero-sum game. many core contributors will help maintain both node.js and io.js