segphault

Really impressive and beautifully designed. I currently use Jupyter, but what you've built feels a lot more polished and elegant.

Any plans to open the source code or make it available in a way that will accommodate self-hosting? I'd really like to be able to use it to interact with systems (like databases, for example) that are on my local network and aren't practical to expose to the public internet.

While it's not JDBC, we are working on an official Java client driver: https://github.com/rethinkdb/rethinkdb/issues/3930

Most of the demos that we publish at RethinkDB use Socket.io or some other similar WebSocket abstraction layer, catering to cases where the user wants to fully host the entire application from end to end.

But scaling a Socket.io application is not trivial, there are users who want a hosted solution for realtime streams so that they don't have to worry about their application falling over if they get too many simultaneous connections.

Granted, the case in the blog post is perhaps a bit contrived. But consider, for example, a scenario where you take a single page web application, deploy it to a CDN, and have all the realtime traffic that it accommodates routed through PubNub's infrastructure. You could make it so that no traffic is hitting your own servers, and you are just broadcasting updates into the PubNub stream from your RethinkDB-based backend. That would be pretty trivial to scale.

And in terms of the speed at which the messages are routed, for the purposes of a liveblog or something of that nature, pushing everything through PubNub isn't noticeably slower than using Socket.io.

Of course, nobody's saying that you should always use PubNub. As I said, we often use Socket.io ourselves. But I do think there is legitimate value in presenting it as an available option.

Really nice-looking application. I don't have as much use for it today, but I would really have loved this back when I was a journalist and had to regularly schedule briefings with foreign companies in different timezones.

This is an interesting idea. I'm not totally sure how I feel about the extensibility, but I really like that the parser can optionally generate a JSON intermediate representation that other tools can easily consume.

As the blog post says, commercial support options and other services will debut alongside the 2.0 release. You can expect more details when 2.0 officially launches.

There's also a new third-party Clojure driver under development: https://github.com/apa512/clj-rethinkdb It's not complete yet, but it's starting to look pretty good.

In a more conventional usage scenario, your application is responsible for picking up updates from the changefeed.

You can see an example here of a node.js app using a changefeed to convey updates to the frontend through Socket.io: http://rethinkdb.com/blog/realtime-cluster-monitoring/

Though, of course, you can also build things other than web apps. Here's a simple IRC bot built with Go that also uses RethinkDB changefeeds: http://rethinkdb.com/blog/go-irc-bot/

I'm really happy to see NativeScript launch. I spent some time experimenting with it while it was still in beta. It's a rather young project, but I think it has a lot potential. Telerik got a whole lot of things right when they worked out the architecture.

Thanks for clarifying. This is a much better explanation than the copy on the website. I could see this being useful for me as a developer, especially if you make it as easy to spin up an isolated virtual Windows/Linux desktop as it is to spin up a server on something like Digital Ocean.

I think you guys might be doing yourselves a bit of a disservice by promoting the hardware before you are in a position to really provide clear information about the actual service and the pricing. It creates a lot of confusion about what it is that you actually offer.

Especially considering the fact that the site recommends a minimum of >20mbps download speed... I suspect that anybody with that kind of connectivity already has a computer.

One more question: how are you handling the Windows licensing?

I build a bunch of small web apps with a pretty diverse range of stacks. I like Dokku because it lets me deploy the apps in a uniform way regardless of what I use to build each one.

It's convenient, but Docker is likely overkill for the kinds of apps that I'm building. I don't have a compelling need to isolate them, I'm mainly taking advantage of the fact that Dokku automates the process of putting together the runtime environment and fetching the dependencies.

Dokku is reliable enough for what I'm doing, but I would frankly be reluctant to use it in production for anything that I really cared about.

It's worth noting that if you wanted to create this kind of real-time app with a Xamarin frontend, you could do it quite easily with ASP.NET on the backend and SignalR.

If you want to learn more, there's a live web chat on Oct 22 with Kurt and Slava, the CEOs of Compose and RethinkDB: http://www.meetup.com/RethinkDB-Bay-Area-Meetup-Group/events...

"If the user hits a URL directly, the HTML will first be rendered on the server for faster load times and easier indexing by search engines."

If I'm understanding this right, it sounds like an incredibly cool feature. Being able to use the same templates for both server-side rendering and a client-side SPA-like experience would be a huge win.

It probably would have been more appropriate for them to call it "Clipped Wings" instead of Flight.

JWT is a fairly elegant choice in cases where you have a session-less API backend that is consumed by an SPA and/or mobile clients.

I've been really pleased with how simple and straightforward it is for implementors. It's good to see it getting more visibility. Thanks to Auth0 for educating the community.

One of my colleagues at Montage Studio was involved in developing the glTF spec. We built a set of open source components that make it easy to load a glTF scene and manipulate the contents with data bindings and CSS transforms: http://montagestudio.com/blog/2014/01/22/build-3d-applicatio...

Those who are interested might also want to check out this recent paper by Brian Coughlin that compares glTF and Declarative 3D: http://mason.gmu.edu/~bcoughl2/cs752/

As a MacVim user, I find this intriguing. It seems to work very well for my needs. I particularly like the built-in Markdown preview.

My only gripe so far is that I'd like to be able to configure additional filtering for the fuzzy file find to, for example, make it automatically ignore node_modules folders.

I've also been following Quill development and it looks very promising.

It's worth noting that the same GoInstant developers have been working on a project called Tandem, which is an OT server implementation that uses the same underlying delta format as Quill: https://github.com/tandem/tandem

I hope that they will continue to work on it as an open source project now that GoInstant is going away.

* The Sails ORM (which is called Waterline) is very light and simple, but it doesn't have the maturity or the same degree of expressive power that you get with ActiveRecord. Associations were recently added and the query system doesn't really let you take advantage of them quite yet.

* There are also subtle differences in behavior that emerge when you use Waterline with different database adapters, so you really need to develop against the same DB adapter that you intend to use in production.

* When you need to customize the behavior of the CRUD methods that Sails gives you by default (like if you need to transform some parameters passed in by the user in the create method), it is often cleaner and easier to do it by applying custom policy methods rather than overriding the actual CRUD method in the controller.

* For a new Sails project, you probably want to start with the new version 0.10 even though it hasn't been officially released yet.

Those are the points that first come to mind. Despite the limitations, I've found it to be a pretty compelling framework. And it's very actively developed, so a lot of the deficiencies are being corrected.

For node-based API backends, I've been using Sails.js or Deployd. In addition to providing automatic RESTful CRUD APIs for your data models, both Sails and Deployd also provide WebSocket interfaces that make it really easy to support real-time capabilities without doing any extra work. It doesn't look like LoopBack does that.

I've been particularly happy with Sails.js as the backend framework for my single-page web apps. I get rid of the Sails view system and use it solely as an API backend. The current 0.10 beta, which adds support for associations in data models, is really nice.

For starters, I really want CoffeeScript's safe accessor operator: "x?.y"

Microsoft is even reportedly considering it* for inclusion in C#, now. I think every object-oriented programming language should have it.

* http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-las...

There are a few handy things that I'd like to see added to Python's syntax. A dedicated operator for matrix multiplication isn't one of them.

Mono's compatibility is quite good across the board, but there aren't a ton of contributors focused on backend stuff. There are gaps in Mono's library stack that are problematic for web applications (e.g. no System.Net.WebSockets last time I checked) but it's not really all that bad.

Microsoft has started making a lot more of the ASP.NET stack open source (EntityFramework, Razor, etc), which I think will help a lot going forward. The real problem is that the ASP.NET happy path is somewhat coupled with IIS and (to a lesser extent) with MS SQL Server. It can be hard to get portability out of the box in some cases, but it depends a lot on what you are trying to do.

It seems incredibly disingenuous to assert that WhatsApp won't collect personal data while sidestepping the question of what happens when WhatsApp identities become correlated with Facebook accounts.

For display purposes, yes. I want better text readability when I'm working on an article. A nice variable-width font, more line spacing, etc. I want my Vim buffer to look as good and be as comfortable to read as a native text editor like Byword.

For formatting, I mostly use Markdown. Ideally, I'd like to see the literal markdown for the paragraph under the cursor, but formatted text for the rest of the buffer. There's actually a script with a pretty good first pass at achieving that kind of Markdown support via Vim's "conceal" feature, but some of Vim's inherent limitations make it imperfect: https://github.com/tpope/vim-markdown/pull/9

I'm hoping that the way neovim decouples the UI layer from the underlying editing engine will make it easier to address issues of that nature.

That's really great! After reading the FAQ, I have contributed $100. Best of luck with the project!

As someone who uses Vim to write articles and documentation in addition to code, I'd really love to see a richer UI with proper support for features like variable-width fonts.

It looks like the developer behind this refactoring effort has some really good ideas for decoupling the Vim engine from the user interface layer. It'd be great if somebody could build a really good cross-platform Qt-based UI on top.

I recently had to disable the Evernote clipper extensions in Chrome after discovering that it is breaking web pages after a recent update. I also continue to be incredibly disappointed with the lousy way that Evernote is maintaining Skitch, which has never worked reliably since Evernote's rewrite of the code base.

I'm a paying customer and depend heavily on the service, but I get really frustrated with the poor quality of the software and all of the engineering problems.

I get the sense that Evernote really doesn't care. They know that their audience is effectively locked in and that there aren't any alternatives that do exactly the same thing, so they just don't have an incentive to fix the bugs. I'm still a user, but I've personally stopped recommending Evernote and Skitch to friends.

I'm one of those people who downloaded the trial, ran it for a few days, and then deleted it. I liked a lot of things about the app, but there were a few bits that I found unintuitive—particularly around managing multiple projects from different sources.

I decided to pass, but I bookmarked it so that I'll be able to find it again in the future if I ever find that I really need a quick way to access my Jira issues from the desktop.

The $49 price is entirely reasonable considering the breadth of the feature set and the target audience, but it does put it outside the impulse purchase comfort zone. It might have been helpful to put it on sale at launch with a discounted price in order to build some traction and lower the barrier to adoption for people who are on the fence.