Daniel Spiewak

Hey Hugo,

I've somehow become a bit of a devil's advocate for Java lately. Thanks for pinging me - happy to offer a few thoughts.

I've not actually tried using Jersey/JAX, but it looks like a very clean setup for quickly writing low-latency JSON APIs. I'm impressed by the Getting Started example (here: https://jersey.dev.java.net/use/getting-started.html) and find the use of decorators to specify path, methods, and content types creative.

As for the rest, keep in mind that you don't have to use anything that you don't want to. I've done a fair amount of Java development and never actually used Hibernate, Maven, or JBoss. For the most part, the complexity that these tools can introduce, while great for many projects, kind of scares the crap out of me. Like you, I'd always go for the simplest workable solution available.

Jetty is a very nice, simple alternative to Tomcat/JBoss, though I find Tomcat to be rather nice myself. One thing I've come to love about Java deployment is that you're literally deploying just one file (a .jar or .war) rather than hundreds.

If you're looking for a nice, clean ORM, check out ActiveObjects by @djspiewak. Its design is based on the active record pattern, and it's very easy to get up and running with about any database as a backend. I used this on a large project ending a few months ago and had a great experience with it. Daniel's also available via Twitter and IRC and tends to be happy to offer an answer to a quick, informed question. …

> 6 months is a very optimistic scenario ;)

Oh.

> A guy responsible for OT in Google Wave wrote once that he spent 5 years on it and it still does not work well in all cases. After 3 years of struggling to get it right, we know what he meant.

...Wow, I see.

(As an aside, I think it's really sad Wave's "cool" UI was never properly released.)

> Anyway, I believe that you can find a good entry point to OT here: http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation. It gives a nice overview of the problem – in a human-readable language – but it’s only the beginning of the journey.

I actually think this is one of the articles I found a while back. I agree that it's very thorough and in-depth, and, uh, I've managed to get slightly further into it before I started hitting PgDn repeatedly and my eyes glazed over than when I read this a few months ago! :)

> The original OT implementation has been designed for linear documents – texts. It does not fit very well with tree structure – you don’t want elements (tags) to intersect after resolving collision. It also does not fit undo where the order matters.

Ooooooooh yowch.

> For sure, operational transformation is not a closed subject, which you can just learn. It is an open problem with many cases still unsolved. If you are looking for a good topic for a thesis, I would recommend it :)

Hah!

When I was exploring OT a few months ago I also explored alternatives such as realtime…

A number of years back, I wrote an OT implementation in Clojure/ClojureScript as a hobby project [1] and learned a lot along the way. I even extracting out the core client/server implementations to their own package [2].

It's an incredibly fun topic, and one that's also really challenging. It also gave me first-hand experience with fuzz-testing where I could simulate all kinds of concurrent-edit conflicts and ensure both clients came out with the same end-result. While the end client/server implementations are working, it was a lot more effort than I anticipated building a full-fledged editor on top. I was too stubborn at the time to attempt to integrate with existing RTEs though, so the most notable part of the project was the core lib, not the end product.

For those interested in implementing it for themselves, I can't recommend this piece [3] by @djspiewak enough.

[1] https://github.com/jahfer/ot
[2] https://github.com/jahfer/othello
[3] http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation

Coincidentally, today is the first day I'm seriously looking into Scala, and I think his points serve well to temper one's approach to language.

I think Scala is an admirable and ambitious effort to allow oo + func programming on the JVM. I also got the impression that the type system is "good enough" for most DRY efforts. But then, my background in this area is virtually non-existent.

Depending on what sources you learn from, you don't need to learn all the intimidating language features in the beginning itself. I am currently working through [1] - well written, but slightly outdated. [2] is where I got oriented initially.

It's also great that they do well to come within striking distance of Java in performance (this is not my impression of Clojure). Another super cool approach seems to be that of Mirah (no special runtime, Ruby-like syntax).

[1]: http://www.codecommit.com/blog/scala/roundup-scala-for-java-refugees
[2]: http://grahamhackingscala.blogspot.com/2010/12/guide-to-learning-scala-by-graham.html

6 months is a very optimistic scenario ;) A guy responsible for OT in Google Wave wrote once that he spent 5 years on it and it still does not work well in all cases. After 3 years of struggling to get it right, we know what he meant.

Anyway, I believe that you can find a good entry point to OT here: http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation. It gives a nice overview of the problem – in a human-readable language – but it’s only the beginning of the journey.

The original OT implementation has been designed for linear documents – texts. It does not fit very well with tree structure – you don’t want elements (tags) to intersect after resolving collision. It also does not fit undo where the order matters.

For sure, operational transformation is not a closed subject, which you can just learn. It is an open problem with many cases still unsolved. If you are looking for a good topic for a thesis, I would recommend it :)

Thank you very much! It was definitely one of the most fun features to build.

I started working on this on March 15th, and the past few days was about testing everything, preparing the release and squashing bugs. The advantage of this type of functionality is that there are tons of high quality papers and articles already written on the subject, especially this one helped me a lot: http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation. There were a lot of sleepless nights involved too.

I'm not sure about the VS Code and Atom teams, but I imagine that there are more constraints and there is more functionality to implement since they work with hundreds of potentially big files. I think those factors make it harder to implement this functionality than in the case of CodeSandbox.