mquandalle

There are also a lot of local grants offered by city councils, departements and regions, and they differ in their income conditions. I created a calculator that reference them all : https://mesaidesvelo.fr (in french)

The status page is down as well https://status.npmjs.org

Sure, but the fact that you have to search these commands on a wiki inspires less confidence that if you have a clean documentation with an imperative “type that to install”. That should be fairly easy to implement though.

I’m also not certain about the canonical way to update Docker containers. I feel like we miss a standard “pod” (ie set of containers) orchestration tool (as docker-compose doesn’t really matches production requirements).

Wekan lead developer here. It's good to have some competition, expect to have a one liner installation for Wekan pretty soon :-)

Using global variables isn’t even the worst part. The big problem with this sharing model is that files are loaded in the alphabetical order, thus the only way to control that file a requires file b as a dependency is to give to b a file name that is before a in the alphabet (this is not true for Meteor packages where we can control the file order).

Thankfully MDG plan to address this issue soon.

Wekan author here. On my computer hot reload takes roughly 5s [Thinkpad T440s, ubuntu, 12go of RAM]. I'm not sure if the jade and stylus compilers add some time in the case I only modify JavaScript files, but anyway I plan to migrate these two package to support the new compiler API.

Still 5s is far from ideal considering the development experience with webpack and React hot loader.

Looks similiar to http://www.regexper.com but working fully on the client.

The problem is that most current jQuery plugins modify the DOM. If someone want to use a jQuery carousel, the plugin will add arrows buttons and page indicators in the DOM. Then if the template engine updates one of the carousel slide, these nodes will be removed and the plugin will be broken.

This looks to be a great declarative/reactive template engine. I've been working mostly with the Meteor Blaze template engine the last few months. Both of them use a "normal" template language for writing views and (potentially) let you choose if you prefer writing your templates in Handlebars, Jade, or Haml [0], which I find far more easy to use than React JSX format. I think Blaze beats Hamlet on the runtime rendering engine.

First, Blaze does not require to set a root element in a template, which could be a source of bugs with Hamlet because for instance the `each` child is a template, here is a snippet of problematic example from the Hamlet README:

  - each @items, ->
    .first
    .second

This works perfectly fine in Blaze. IIRC Blaze uses comments node on the DOM that are never rendered in browsers in order to define some "domrange" that keep track of n children in a single parent group.

The second runtime issue in Hamlet appears when a third-party library directly modifies the DOM, without telling the template engine. Basically the modification will be erased on the next template redraw which make this system incompatible with all jQuery plugins for instance. Blaze has "fined grained DOM updates" which mean that the modification of a single element in a template does not require to touch any other node in the DOM. For instance if you have a each loop of inputs, and the user start to enter some data in one input field, and for some reason the template is redrawn the text will stay in the input with Blaze, but will be erased with Hamlet.

Blaze also support reactive SVG (I'm not sure if Hamlet supports it but I haven't seen any particular mention in the code).

I think all of these features can be implemented in Hamlet drawing on Blaze and ReactJS runtimes.

Nevertheless I find the Javascript model declaration cleaner in Hamlet than in Blaze or Backbone or React. The only thing I'm not sure about is writing the js events in the template and not in the model, I actually like having all events of a given template in a single place but I don't have strong opinion on this.

[0]: Meteor support Spacebars (which is quite similar to Handlebars) by default https://github.com/meteor/meteor/blob/devel/packages/spaceba..., and there is also a package for jade https://github.com/mquandalle/meteor-jade (disclaimer: I'm the author). It also seems that it wouldn't be difficult to support other languages than Haml for Hamlet.

There will be no IO function like `http_get_content` because we can't securely rely on them. Instead the method will be to rely on a trusted entity (or a group of trusted entities) to sign an ethereum transaction containing some data that will be used by the contract. For instance you could take a look at Reality Keys, a "trusted data feeds" platform [1].

If you want to reduce the need to trust a single party you can also use a SchellingCoin system, described as a "decentralized data feed" in the ethereum white paper v2 [2].

[1] http://forum.ethereum.org/discussion/comment/180/#Comment_18...

[2] http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-...

This version contains some mistakes and approximations. For a more up-to-date paper you should take a look at the White paper v2 draft [1].

A more formal and technical description is presented in the Yellow paper (also draft) [2].

[1] https://github.com/ethereum/wiki/wiki/Whitepaper-2-Draft

[2] http://gavwood.com/Paper.pdf