SanderMak

Exactly, that's one of the tradeoffs discussed in the article (author here).

Another pattern that might work, which I didn't include in the article, is to scale-out the modular application (assuming it's 'stateless') into several clusters. Each node in the clusters still has the whole modular application. However, each cluster will be responsible for handling a certain part of the API. Then, put a load-balancer/API gateway in front that can route different functional parts of your API to different clusters. Scale up the individual clusters as required by load. Even though all nodes contain all modules, depending on which cluster they're in, only a certain subset of modules really takes up CPU cycles. There's still no node-to-node communication necessary, since all nodes contain all logic.

Certainly not a pattern that's always applicable, but I've used it with success several times for webapps with REST backends.

Devoxx Belgium is a great conf, really good value for the price as well.

I'm biased (currently authoring http://shop.oreilly.com/product/0636920049494.do), but I believe categorising the new module system as just something organisational is a bit too dismissive.

The module system brings two essential features: reliable configuration and strong encapsulation. Both are a boon for modular development and I believe all but trivially small codebases can benefit.

Reliable configuration means every module explicitly describes its dependencies on other modules. This is consistently available throughout all phases: compilation, run-time and even a new phase, link-time (for more information about linking see http://openjdk.java.net/jeps/282). No more classpath hell, and the explicit dependency information allows for new use-cases like linking.

Strong encapsulation brings new tools to truly modularise your application. Combine it with the services mechanism for maximum benefit (see for an example http://branchandbound.net/blog/java/2015/10/osgi-to-jigsaw/). As a side-effect, the platform becomes more secure by virtue of strong encapsulation of 'dangerous' platform internal classes.

Care to elaborate? We're having quite good experiences with it at the moment, but would like to learn from others.

O'Reilly is running a 50% discount on all ebooks: http://shop.oreilly.com/category/deals/cyber-monday.do

(full disclosure: I'm writing 'Java 9 Modularity' with them, available in early access)

> If you’re genuinely satisfied with what you are and what you’re doing, then give those books a wide berth. (Let sleeping dogs lie.)

I find myself doing this. Avoiding books that I think might upset my current reality for no apparent gain. It does make me feel intellectually dishonest, though. As in, I should be able to read anything and handle it rationally.

You should see https://en.wikipedia.org/wiki/Simone_(2002_film), sounds like you'll enjoy its premise.

That idea is beautifully explored in this episode of Black Mirror: https://en.wikipedia.org/wiki/White_Christmas_%28Black_Mirro...

Love this write-up! It reflects my experience in similar situations: getting things up and running from source often too painful.

Problem is, every (build/config/packaging) tool brought in to 'solve' this problem only adds another point of failure and confusion.

We use http://orientdb.com/orientdb/, seems decent so far.

So is there already a solution for https on Github Pages with a custom domain?

Just finished reading Pedro Domingos' book The Master Algorithm, which also features these ideas. I was way more fascinated by his so-called 'data unions' also mentioned in this book: companies empowering individuals to take charge of their digital footprint. Taking on the data-collecting walled gardens that are currently rising up. Much like labor unions represent workers that suffer from a power imbalance, only for the digital native. Lots of food for thought.

There's Model Based Machine Learning: http://www.mbmlbook.com

It played pretty nicely with using map followed by a scanLeft (which prepends its starting element) on the input. Happy accident...

Something like http://pineapple.io ?

Similar experience here: got a draft that was so far off the mark, I declined the opportunity to review. In general their game seems to be quantity over quality.

I'll happily use their open-source tech if it is compelling (e.g. TypeScript). That doesn't make me want to leave OSX as dev platform though.

I believe the arguments should not be available in arrow functions according to the spec. (source: discussion here https://github.com/Microsoft/TypeScript/issues/1609)

Check out this recent discussion on machine teaching: https://news.ycombinator.com/item?id=9114053

Also AtScript, for the upcoming Angular 2.0: https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit9...

Right. I also love 't' to have insta-search on all filenames in the repo. Hit enter once you find the file you want and there you are.

Indeed, that's what my first sentence implies. Note that this doesn't prevent you from lazily loading other JS libs when using them inside Angular modules.

We use angular with RequireJS, though we don't (yet) load any Angular modules lazily because it is not supported by Angular. There are workarounds (like https://github.com/marcoslin/angularAMD) which I have no experience with. We do load external libs (like MathJax, which is comparatively huge) lazily where possible.

Our AMD modules are actually TypeScript modules that generate the AMD wrapper. Works great, and makes for a very clean and modular codebase. In the end, we use r.js to concat and minify most of it (everything except the lazily loaded libs) down to a single file. Including Angular templates, using https://www.npmjs.org/package/gulp-angular-templatecache which can output the templates as initialization scripts inside and AMD wrapper as well.

Somewhat related: Google released a Quantum Playground that includes visualization of quantum states. Pretty nifty: http://qcplayground.withgoogle.com/#/home

Sure, you could obtain a hash out-of-band and pin to that. Not much more convenient given you have to do it for all transitive dependencies and Maven-plugin dependencies as well.

The vulnerability even has a name: Cross-build injection attacks. I wrote about it some time ago [1], [2]. The complete answer includes verifying the (now mandatory) PGP signatures [3] of artifacts in Maven Central. But you need a web-of-trust for that and the whole process is rather impractical currently.

[1] http://branchandbound.net/blog/security/2012/03/crossbuild-i... [2] http://branchandbound.net/blog/security/2012/10/cross-build-... [3] http://branchandbound.net/blog/security/2012/08/verify-depen...

I'm sitting in my garden doing work on a MBP right now. Only 'downside' is I have to sit in the shade. Glare/flare makes it unworkable otherwise. Otoh, sitting in the sun for prolonged periods doesn't sound too good either. I'm perfectly happy with strolling around in the sun while mulling over some problems, then returning back to my laptop.

About TypeScript+Gulp: I was using gulp-tsc, but switched to gulp-type (https://www.npmjs.org/package/gulp-type). It offers incremental compilation and you can disable chasing through all references in the sourcefiles (since with Gulp you already provide all sources in the stream). This sped up our re-compilation times three-fold.

Love the idea! I tried it by searching for Node's require. It did point me to the right source [1], but the usage examples are all minified and unreadable. Might want to check for a maximum size on the usage examples that are presented.

[1] https://sourcegraph.com/github.com/joyent/node/.CommonJSPack...

I thought so too, but then I saw for example this [1]. They use Titan (multi-machine setup) to scale out to 64 billion vertices. Very impressive.

[1] http://thinkaurelius.com/2013/05/13/educating-the-planet-wit...