RSS Feed Subscribe to RSS Feed

 

Book summary: Chaos Engineering

Chaos Engineering“Chaos Engineering” is a book from O’Reilly (free download), written by folks from the “The Chaos team” at Netflix. It is a GREAT read for anyone interested in resilience engineering. This post is one of my summaries, essentially a cut and paste of the most salient parts (the original is about 16,000 words; this is about 3,000), with some paraphrasing and merging/rewriting of sections for brevity.

(more…)

Tags: , , , , , ,

Post Production Debugging

Monitoring and Observing Your App Post Release

Pre-release tests are essential, but the ability to debug, monitor and observe your application suite post-release is what allows you to detect, and quickly fix, the production problems that will inevitably rise.

(more…)

Tags: , , , , , , , , , ,

URL Encoding

URL encoding, also known as percent encoding, takes certain “reserved” characters and standardizes (or canonicalizes) them.

Why? This is normally done when transmitting data in html forms. For example, the # character has a special purpose in html (as an html anchor) and so is converted to make it clear that it is part of that data, not part of the html document where it is to be displayed.

Another (related) use is for prevention of XSS attacks. If your web page allows a user to enter text (for example, a comments box on a blog), it would be very easy for a motivated user to enter malicious text that will be interpreted as a script.

(more…)

Tags: , , , ,

JavaOne: Comparing Java Web Frameworks

The first talk I attended at this year’s JavaOne was “Choosing Your Java Web Framework” by Richard Pack from salesforce.com

Overall, I found this a really interesting talk. It was lacking in any sales pitch, nor did it have the unquestioning devotion to one particular framework that I felt some of the Java FX talks had. Instead it seemed like an unbiased look at web frameworks in general and a handful of frameworks in more detail, based on Richard’s extensive and hands on experience and SalesForce and Hyperic.
Read more

Tags: , , , , , , ,

GTUG Campout Follow up

I’m currently at the Google Technology User Group Camp out weekend down at Google’s offices in Mountain View. The objective of the weekend is to form a team and develop an application, using Google technologies. The demos are Sunday afternoon.

I joined the Blip Wiki team. A Blip is simply a single message within a ‘Wave’ conversation. A Wiki, of course, is a software tool that allows users to easily create, link and collaborate on documents. So, our goal with the ‘Blip Wiki’ project was to bring the incredible collaboration capabilities of Google Wave (real time updates, autocorrect context sensitive spelling etc) to the easy document setup and linkability of a Wiki.
Although Wave can certainly be used to collaboratively create documents as it is, Wave is inherently conversation focused. We wanted Blip Wiki to be inherently Document focused.

To do this however, we needed to use our own instance of a Wave server i.e. use the Google Wave Federation Prototype Server rather than the regular Wave server hosted by Google. We also needed to come up with a new client (something like tiddlywiki) and, most importantly, ensure our client can communicate with the server. Our project won the award for the most ambitious pitch at the start of the weekend!

Federation Prototype Server and example client

We got off to a good start by getting the Wave Prototype Server downloaded, building and running (it runs on top of OpenFire, a real time collaboration server that uses XMPP/Jabber). We then got the demo wave client running and talking to our server. We managed this by late Friday evening.

Client/Server protocol

Next, we created our own demo client and tried to get it interacting with our Wave server. That is when we started running into problems. First, the client/server protocol has not yet been formalized, and there don’t seem to be any definite plans to do that yet either. For example, although this Client Server Protocol White paper describes a protocol and data model, it does not give any details on the format that should be used, or suggestions on how to use it. There is a lengthy discussion in the Wave Protocol Google Group about this. For example, someone suggests that the client server protocol is just protocol buffers ‘over the wire’. But a protobuf is really just a simple data format, and while I assume ‘over the wire’ means RPC, it is all a bit vague.

Submitting changes

The client/server protocol used in the example client (a “toy’ text client) is for “illustrative purposes only”, according to this doc. We couldn’t seem to find much documentation for it, perhaps because it is not supposed to serve as a standardized example. As a result, we found it difficult to reverse engineer. So, we ended up resorting to using the Client example code to marshal our data to and from the server. The example client code in effect became a sort of interface to the server for us. A client side stub, if you will. (We had this running in the web tier servlet layer).

Receiving updates

So, after we had used the Client example code to submit changes (blip updates) to the server, our next hurdle was understanding the data that gets returned. Ideally, we would like a ‘delta’ of the data. That is, after the server has done it Operational Transformation magic, we would just like the latest and greatest version of the data to display on the client. However, this proved difficult to get from the server. Instead all I could seem to get was a non-delimited complete history of the blip. I admit that this was done using pretty hacky code. I am sure there must be another, better way!

So, we ended up taking a similar approach to the example client, and just displaying the latest submissions.

Demo ready – almost…

Right now, we have a working client and server with updates made on one user’s WikiBlip automatically showing up in another users.

It would have been really nice to be able to deploy our local Wave Server to app engine, but apparently this isn’t possible since the OpenFire jars required aren’t on the whitelist of allowed jars.
It also would have been nice to experiment with our local Wave server talking to the real Google Wave server (e.g. to have a regular wave client user be able to interact with a blip wiki), but apparently this is not possible due to authentication issues.

So, we chose a very difficult task for the weekend! But, we have a working version ready to demo and it has been a great weekend all in all.

Thank you’s

A big thank you to

  • Sriram and Sreejith, my BlipWiki teammates
  • Kevin and Van from the GTUG
  • Stephanie, Brian, Fred and all the all Googlers who made the weekend possible and great!

I will post again later with the results of the demo…

Tags: , , ,

Welcome

Hello, World! Hola y bienvenido. Fáilte. Bienvenue.

Connect with me on LinkedIn, follow me on Twitter, or email at .

Read on for my blog postings, or for details of talks.

Highlights

I’ve been using this blog for over 10 years now (the first post was way back in Apr 08, averaging about one a month since), so it has inevitably become more of a collection than a curation, but in terms of highlights, the topics I give talks on are those that I have researched most, such as this talk on Testing in Production. Some of the posts I’ve either put more effort into, or find myself referring back to are: