2nd attempt at this talk idea

talk_submission.md

How RabbitMQ Saved My (S)aSS

What happens to your web app when a databases update fails? Or the email service is unreachable due to network hiccups? Will the front-end survive bad code crashing the back-end? Admit it - the web app will crash and show a useless "server error" message. But there is hope! Messaging servers, like RabbitMQ, work wonders in the face of failure - decoupling processes and allowing for re-try when things come back up.

In this talk, I'll show you how I re-architected SignalLeaf to deal with crashes and sometimes-connected services. You'll hear tales from the trenches of success and failure with RabbitMQ and Node.js. You'll see how a message queue can help you build a more resilliant web app. And you'll clean up your code at the same time! Rejoice as your application architecture improves by leaps and bounds, with RabbitMQ!

If this is related to a well known project it might be helpful to just talk about the details that you solved with it. For example:

Message queues work wonders when dealing with sometimes-disconnected systems. This makes message queues ideal for building both client-side JavaScript apps and performing work in server-side request handlers. By using messaging patterns apps can become easier to build and maintain!

Learn how messaging patterns were put to use by SignalLeaf as its reporting system began to have scaling issues. See real life examples of putting messaging to work by using RabbitMQ to help with email processing, dealing with long running processes, and how to handle integration with systems that may fail on a regular basis. There will be much rejoicing as your system dramatically improves!

i like that approach. it clarifies the intent of the talk. i updated my version with that kind of angle... better?

@derickbailey I think that is a lot better!

I don't often see people talk about themselves in an abstract like you are doing here. Maybe it is more common in other communities, so YMMV. The thing I've tried to remember is that the talk isn't about the speaker (unless it is). Someone reading the abstract will already assume that it is about the speaker's experience.

So, for example, you could rewrite it like this to make it less about you:

Unsuck your Node.js architecture and learn some how to successfully add RabbitMQ to your stack.

But again, maybe it makes sense as-is for your audience intended conferences.

In any event, I think it looks a lot better!

@derickbailey I think this 2nd attempt is a ton better.

I would describe the problem first, before describing what RabbitMQ is built for.

"What happens when the databases goes offline, network hiccups prevent connections to other services, or bad code crashes the back-end application? Messaging servers, like RabbitMQ, work wonders when dealing with sometimes-connected systems - decoupling processes and allowing for re-try on failure."

Anyone else agree?

@jakefolio++

Much better, but still a bit vague. "Unsucking" means a lot of things to a lot people - for instance someone might think oh cool he'll stop using so much JavaScript and to others they might think oh great another SOA/Microservices nut telling me how I'm doing it all wrong.

I sent you an email back but here's what I came up with based on our conversation (putting it here too):

First, let’s tweak the title so it's a bit more appropriate to what you're trying to say:

Message Queues Can Help You Live Longer

or

How RabbitMQ Changed The Way I Do Everything

I read joy and de-stressing when you talk about queues, and you want others to see how their lives can become easier by embracing them.

Now, onto the abstract. I'm taking the email you sent me and squeezing it down. Tweak as you need - but the one thing is please pay attention to the last paragraph and see if you can get specific on it. This is a bit long, but I think that's OK because it's in story form:

Years ago I was building a distributed system that had to accommodate regular network outages - a standalone app that needed to synchronize data with a central server over a problematic network. I thrashed for a while - trying to figure out the best approach - and finally decided to implement a message queue. It solved every problem for me. It was the first time I used a message queue to that extent, and I couldn't believe how simple it made things.

After the success of that project, I realized that message queues were invaluable for everything I work on - from Single Page Apps built with Backbone on the client to my batch processing scheduler running on the server; these apps became easier to build, simpler to maintain, and easier to extend. Now, I’m building epic complex systems in little chunks that are incredibly fun to work on - and I’ve come to realize that I’ve been making my life difficult by creating mountains of business logic that live on the web server - this is craziness!

In this talk I’ll show you what I’ve learned building my business (SignalLeaf.com) using message queues, and how it brought simplicity and joy back to web programming for me. Specifically, I'll show you how I got started using RabbitMQ to solve [problem x] - which worked great. Then we'll explore how I restructured things to further lean on message queues - solving [problem y]. Finally I'll show you three simple ways you can get started with RabbitMQ today - solving common issues you might not even know you had.

Obviously I made up the last part; but the point is that you should be as clear as you can be when it comes to what you're going to talk about and why the audience should care. I'd go to this talk in a heartbeat! I love revelations like this - especially problem/solution stuff from the real world.

So: pick three problems that RabbitMQ solved (these can be slides... should be slides) and then pick a quick code demo for how RabbitMQ can be implemented quickly and easily. I'd love to come watch you do this!

LOL so... I'm installing RabbitMQ right now on my machine :) based on your enthusiasm... This talk is good Derick - hope it gets recorded!

+1 @derick

ok, i'm working on the title a bit... going for something a bit cheeky but still more along the lines of what rob suggested.

also swtiched the first paragraph around like jakefolio suggested

not sure i can go for a full story like you're suggesting, rob. that's a bit long for an abstract, but it's a great story that i will probably use elsewhere :)

MUCH better!

1. remove ", like this".
2. s/sucess/success

:)

Love the title - very good :). Don't like the first paragraph - it's argumentative and can be a bit offhandedly accusatory. What happens if...? is such a firecracker of a sentence; it's the "you can't prove a negative" kind of thing.

I really think you should stay positive; I like this abstract but...

What happens to your web app when a databases update fails? Or the email service is unreachable due to network hiccups? Will the front-end survive bad code crashing the back-end?

With this sentence I'm already formulating my response to you: I'm not an idiot, this isn't my first app. I can handle write failure as well as email not working. Yes, I've got it covered.... You're challenging your audience into a defensive posture - this is offensive by definition.

Admit it - the web app will crash and show a useless "server error" message. But there is hope!

I really don't like that you're assuming that I don't know what I'm doing :). Let's be more positive! Tell me in the first sentence your epiphany!

Last year I saved my business by using message queues. I was quite surprised, and it changed the way I do everything. Maybe it can help you too.

Not offensive - truthful! Hmmmmm maybe I can learn something from this guy who launched a business using message queues... - that's what I would be thinking. Rather than maybe I'll skip this talk from some guy who thinks everyone else is doing it wrong.