ffreire

IMHO this works to Scala's detriment. I very much enjoy Python and Clojure precisely because they have one, generally accepted way of doing things. Is it a silver bullet? Of course not, but this works for me 9 times out 10 and I find that coming back to my code later (or sharing with colleagues) is far easier because most code will be structured in a familiar way and therefore take less time to understand the unique bits that solve the problem at hand.

This is anecdotal, but I've come to really appreciate the subtle syntax changes that Clojure has adopted. With an editor that provides support for "rainbow" parenthesis I've found Clojure to be the most readable of all the Lisps I've had the pleasure of working with (Guile and Racket among them).

As referenced in this article[0] a major blocker for shipping newer versions of the command line toolchain is the fact that newer versions of these tools moved to an incompatible GPLv3 license.

[0]: http://robservatory.com/behind-os-xs-modern-face-lies-an-agi...

There are plenty[0] of examples on the github page for Om.

[0]: https://github.com/swannodette/om#applications-built-with-om

Have you messed around with om-tools[0] from Prismatic? It provides some more tooling to make working with Om a little bit easier.

[0]: https://github.com/Prismatic/om-tools

We've been bitten by this as well. We started several projects within a few months of each that also used what we believed to be similar enough versions of Play but there are just enough inconsistencies between versions of play (and Scala language versions as well) to make it exceedingly frustrating to work with.

Then you may not be aware of Mozilla's continued interest in WebComponents[0][1].

[0]: http://mozbrick.github.io/ [1]: http://www.x-tags.org/

ReactJS is a solid solution if you need to ship something _today_, but I think the trend will continue towards WebComponents as they become standardized across vendors (if not Polymer then x-tags, if not x-tags then... etc). In that sense, it's better to familiarize oneself with the technologies that we'll be seeing more of in the future just as we did with new HTML5 elements a few years ago.

@jastanton phrased it nicely in another comment here: https://news.ycombinator.com/item?id=7971847

Perhaps the biggest concern right now is vendor buy-in from other browser vendors such as Microsoft and Apple. It appears that React, at least for the time being, is a more immediate and practical approach to composing UIs.

I'll still be mixing Polymer into internal/side projects to keep up to date on its status, but I don't think I'll be pushing anything public facing for the foreseeable future.

I think you're confounding Polymer with Paper. The core Polymer elements that have currently been released make no assumption as to your UI preference, which means you can style them individually as you please.

I've been creating my own Polymer elements for an internal project and have been pleased with the result so far. We've got some particular branding requirements that I've been able to reproduce to great effect. I think as long as you stay away from the messy parts of Polymer (such as making XHR requests in the DOM) then you may find the experience more agreeable.

Well, there's this little blurb in the faq[0], not sure if that helps you any.

[0]http://www.polymer-project.org/resources/faq.html#xtags

What would you say about Clojure, then, where one of the big selling points is concurrency?

This could, perhaps, initially be implemented as a plugin that inspected/listened for link clicks and forwarded them to your application of choice. I believe VLC is capable of opening streams without too much hassle (not sure about other players).

Sounds like a fun weekend project, at any rate!

Sure, but unless I'm misunderstanding the parent commenter they were asking for a vim plugin, not a neovim plugin right?

Have you given YouCompleteMe a shot? http://valloric.github.io/YouCompleteMe/

I'll keep my eyes peeled, then!

I'd actually be extremely interested in hearing more about your experiences with HealthCare.gov. I'm working on implementing test infrastructure for my current employer and would love to learn from folks more experienced than myself about the process!

I'm just assuming here, but I think the parent commenter was referring to the fact that not every programmer needs to know SEO, since there are several disciplines that don't depend on search engine results.

Clearly the next iteration needs to include democracy/anarchy modes.

The only other competitor that I am aware of is Moodle[0].

[0] http://moodle.com/

Ben Noordhuis: http://blog.nodejs.org/2013/12/03/bnoordhuis-departure/

I suppose I'm not really seeing the benefit here --don't nodejitsu, heroku, and others have the same "always on" policy?

I don't mean to rail against you or the service, but I am genuinely curious to see what I get for $50 a month (which AFAICT is more or less the same as nodejitsu and heroku). As MathewPhillips mentioned in my previous comment, it sounds like nodejs-cloud isn't targeting individual developers so much as it is pursuing small businesses and above.

It's an Instagram for code blocks.

For that price, how is nodejs-cloud differentiating themselves from the competition? Right now I can deploy a "small app" to nodejitsu for only $3/month...

The advantages being that >50% of the help documentation (and forum posts) cover some derivative of Ubuntu. You also have the added benefit of installing software through PPA's which are essentially mini-repositories that 3rd parties maintain (i.e. back in Ubuntu 10.04 VLC was stuck on an older version that would not play 10-bit MKV files properly, so I simply installed their beta-channel PPA and everything worked perfectly).

I also know of several colleagues that use and enjoy Ubuntu (because Unity notwithstanding, the distribution is pretty solid) with an alternative environment like xmonad.

My experience with Debian is limited to servers, but I'd imagine a lot of the creature comforts of Ubuntu are missing on Debian when used as a personal OS.

What's worked for me has been to read the archlinux.org homepage before I upgrade (maybe once every few days). If there are any breaking changes they are listed along with the recommended method for handling them. If I somehow fat finger a command and it doesn't go smoothly then all I have to do is jump in #archlinux and my issue is resolved in under an hour.

YMMV of course but I've found the entire Arch experience to be pleasant and it fits my work flow, but I understand that it doesn't fit everyone's.

There seems to be some very positive buzz around this screencast mentioned both in the OP's blog and around HN in general: https://peepcode.com/products/emberjs . I found it particularly instructive but found that it only scratched the surface of this new framework. At least, it scratched enough off the top that I feel comfortable rooting through source and API documentation to figure out the rest. YMMV, of course.

Depends on the channels you participate in. I tend to stick to the *dev channels, which have always leaned towards civil discussion.

I agree with ginko, is there some supporting evidence you have that points to support from NVIDIA?

If so, that's a pretty interesting development.

---

EDIT: Thanks for the update ElliotH!