EvilTrout

Had we used raw SQL instead of an ORM we would have had the same issues. All projects are open to this style of bug. The correct thing to do is report, close them quickly and add tests to prevent them from happening again (which we do.)

I think it's a very good point and I doubt I'll do it again.

I'm happy to have many others in the forum space as it legitimizes our cause and pushes everything forward. Our main goal is to modernize forum software and so is yours, so we're fighting the same battle here.

Also there's no way we're backing down on infinite scrolling :)

From a cursory point of view, it seems to have more in common with Disqus than Discourse. It's embeddable, doesn't allow rich posts or markdown or our support for embedding videos, github, wikipedia, amazon, etc.

It's also closed source, although it is free and they claim they'll never insert ads.

I have no idea about their support for the other challenges we've faced such as infinite scrolling that is compatible with the back button.

I am skeptical of redis as their only data store. We use redis too in Discourse but this would demand that all forum content can fit in memory at once, and there is a chance if a server crashes you'd lose so. Not to mention querying it is much more difficult especially when filtering.

Either way, we're glad to have the competition!

$.get("/user/eviltrout.json").then(function(json) { Discourse.User.create(json) });

I'll probably end up writing up an AJAX tutorial because I think a lot of people are underestimating just how simple it is.

The truth is releasing your code is a very scary thing to do. I knew some parts were good, some parts less so.

Posts like this (and their pull requests) have floored me. Grant did a fantastic job refactoring a large chunk of technical debt we'd acquired, and then took the time to write up why he did it in detail.

I really hope this trend of improving something and writing how you did it catches on. I want to see it in other people's code bases too!

Our site is indexable by Google and it doesn't do much fancy. On certain URLs, we generate a small HTML view of the content in the <noscript> tag. You can see this by viewing source or disabling JS in your browser. It's just a simple ERB template in Rails, and uses the same object graph that we serialize via Active Model Serializers.

Google can see it and index it, we've confirmed by searching post launch.

As time goes on we'll probably work more on it to make the SEO even better. As you can imagine it was tough to do when we were in stealth mode ;)

You can like posts in this release, but it's mainly to prevent useless "me too" posts. Users don't have scores. Posts do, but that's just so we can calculate a summary view for mega threads.

Additionally, almost everything is configurable. We give what we consider sensible defaults out of the box, but you can disable/tune a lot right now.

We also integrated features suggested by goons like a global API.

I've been a SA goon for almost a decade. I really want to make this software good. Actually I'll probably post a follow up topic there soon!

Discourse remembers what you've read and what you haven't. You can "like" posts or "flag" them as poor.

Our API coverage is almost 100% - our rich JS client consumes our own API for just about everything, so we actually know it's working because the client wouldn't work without it.

We also have an (admittedly undocumented) plugin system, where you can install rubygems that add or remove functionality from the core app.

It's not much to use, but enough for google to get at the words and links.

We're not sure how well it works since the project was secret until today! We're going to keep an eye on it and adjust for maximum google-fu going forward.

(Shout out to Sam Saffron who implemented this!)

Having said that, this is very much an early beta right now. We expect to get a lot of feedback over the next little while, and we want to integrate that before we release a 1.0 stable that we'd be comfortable telling many people to install.

If you install it now, you'll have a more complicated upgrade path to our 1.0.

There is a little more intelligence as links within a topic just replace the state, but links to other topics push the state.

Also infinite scrolling downwards is easy to implement. Upwards is a huge headache.

2. We use HTML5 replaceState to update the URL as you scroll. Just grab the link from the URL bar and it'll take you to where you left off. Or additionally click the "Share button" for a copy and pastable pop up.

3. Yes we render a lightweight version of the pages in a <noscript> tag for google indexing.

As was mentioned, we have a hosted offering planned so people can set up a forum in a few clicks.

But besides that we actively want to work to make Ruby apps easier to install. Right now they're too hard and we're going to try and fix that.

At the very least we'll offer VM images and install scripts for various cloud hosts.

There are many application developers out there using Rails, PHP or Django who can go years without invoking locks or semaphores due to the strengths of the APIs and frameworks they use.

As they learn and grow as developers, they will be introduced to new problems and solutions. A semaphore can be exotic, not because they've never heard of it before, but because they've not used them very much outside of that one assignment they did in CS 5 years ago.

How about instead of criticizing people's eductions, we encourage them to be mindful about what they don't know, and to learn whatever they can when they get a chance?

In the sentence before I explicitly said I was a newbie to this stuff at the time. Obviously it's not exotic to a more experienced developer :)

My solution is basically the same amount of lines, requires no such changes.

I forgot a very important part of the query:

row_count = Goal.update_all "completed = true", ["player_id = ? AND completed = false", player.id]

If you update where completed = false, the rowcount will only be 1 when the update works.

(I've updated the blog post.)

No, but it encourages a style of development that makes you rely much more on the server side speed than you should. That is the major flaw I was trying to bring attention to.

The general sentiment was supposed to be: interested in turbolinks? Well take a look at THIS first.

Client Side MVC frameworks are certainly not all about speed - they have other advantages such as great organization of your Javascript code, API first development, etc.

One side note: I don't actually hate Turbolinks. If it's working for some people with little effort, more power to them.

I'd just suggest to _anyone_ considering it, you should look into a JSMVC framework first to see all the other benefits you can get.