I am sure this is an error in a UX design that too many are not even aware they need to correct.

If I am reading some text on your page (more than 2-3 sentences) I can’t have this feed constantly moving on the left or right of the text I want to read. I can’t focus if something is moving non-stop so close to where I need to focus.

Like audio can be muted on many sites there should be a “stop the feed” icon/button next to this annoyance.

Am I alone complaining about this?

Wow.

This new type of debugger is something on its own.

It allows you to record your application executing and then replaying it has you need to figure out where the errors are. You simply need to watch their video to get the “wow” factor right away.

It simplifies the code you have to do and gives you a better insight in your application.

I am quite curious to know how it would work on JBoss servers running multiple apps.

http://www.chrononsystems.com/

I have a lot to learn about the pattern and how to be effective at doing continuous delivery of a web app. This presentation is giving a few hints on what you need to be successful:

1. Monitoring
2. Testing
3. Remediation

The monitoring portion is more than just availability. You need to be able to detect any failure quite rapidly otherwise you won’t know to which release to rollback or what to remediate. Monitoring your logs is probably the next thing I need to implement and see how good I can get this. Jez Humble talks about monitoring revenue and it is a great idea for real businesses, it just does not apply to my web app. You can monitor the number of transactions or logins instead of revenue but I will keep that as my next step. Logs first.

Testing, I have a clue on what needs to get done but the cascading of the different type of testing was not something I had in mind until I listened to this presentation. Unit testing is the first step to what needs to get done and I knew that but the next few steps are a bit more clear now.

The remediation pattern that were shown are good ones. Failure does not mean a full code rollback. You can deploy features and turn them on later. I especially liked his Facebook example where the code was there and user loging in were making calls to the back-end without knowing it. This allowed the team to see how the code/app would behave under a more realistic load. That is clever.

Now I have to write down how this is going to change my architecture for this web app. It certainly will improve the plan.