{"id":950,"date":"2012-10-25T23:17:27","date_gmt":"2012-10-25T23:17:27","guid":{"rendered":"http:\/\/www.sitekickr.com\/blog\/?p=950"},"modified":"2012-10-27T12:44:49","modified_gmt":"2012-10-27T12:44:49","slug":"barricades-robust-web-development","status":"publish","type":"post","link":"https:\/\/www.sitekickr.com\/blog\/barricades-robust-web-development\/","title":{"rendered":"Using barricades for a more robust website"},"content":{"rendered":"

You hear the term robust <\/strong>thrown around loosely. <\/p>\n

\t"Hey Bob, that new app is gonna be robust, right?"
\n\t"Oh yeah Steve, I'm all over that robustness."<\/p>\n

But how many people really understand what they're promising? I certainly didn't used to. If you dictionary.com the word robust<\/strong>, you are told that it means strong<\/span> and<\/span> <\/em>healthy<\/em>. If you try to translate that meaning to software quality, it become a little ambiguous. <\/span><\/span><\/p>\n

Strong.<\/span><\/span><\/strong> Does that mean the software can process a lot of data? Or can support a large amount of concurrent users?
\n\t<\/span><\/span><\/p>\n

Healthy<\/strong>. Are we talking about how many errors occur within the software? Health is perhaps more closely related to robustness, but not exactly.<\/span><\/span><\/p>\n

When talking about software, robustness <\/strong>is how well your code deals with errors, and whether or not the software can continue to run in the wake of an error. Using the healthiness analogy: Your software may be in perfect shape and run error free 99.9% of the time, but how well does it cope when it catches a cold? If your software decides who your best friend is on Facebook, no harm done if an error shuts down the program. But, if your software operates a pacemaker, that .1% probability of an error really shouldn't shut anything down!<\/p>\n

Different web technologies offer different solutions, some not quite as apparent as others. But, beyond syntax and keywords, there are methodologies that provide robustness. The general approach needs to be a little different when working with client-side code as opposed to server-side. On the server side we have more complete error information, as well as logging and notification options that just aren't possible (or are more much more difficult to achieve) on the client side.<\/p>\n

Server-Side<\/h3>\n

On the server side, the first step is to decide what the barricade<\/em> protects. For instance, if you have a two-column website in which both columns are dynamically generated by your server-side code, you might want the content column to be entirely unaffected by any errors that occur in the sidebar. A popular example of this issue occurs within any given WordPress blog. Depending on your PHP error settings, an error in your sidebar will "take down" the entire page. With this possibility, it's in your user's best interest to barricade<\/em> the sidebar from the rest of the site. For that matter, perhaps the footer as well.<\/p>\n

We can do this with our old friend the try\/catch<\/tt> block. By wrapping the entire sidebar code in a try\/catch<\/tt>, we prevent any and all errors from affecting the rest of the site. This still allows our more "fine-tuned" errors to do their job of properly logging and notifying the user of any errors. But, we also have the added comfort of being able to log errors from within the "master" catch block.<\/p>\n

This doesn't even mention the level of security gained by not exposing error information to potential hackers.
\n\t <\/p>\n

JavaScript<\/h3>\n

It seems like every time I come up with a good, solid server-side methodology, it doesn't transfer to JavaScript! With JavaScript, errors are not displayed front-and-center to the user. They are tucked away behind a small warning icon in the corner of the browser. But, that doesn't mean they can't do just as much harm. As with server-side code, one error in your script and that's it, execution stops.<\/p>\n

Of course, we have the same try\/catch capability. We could easily wrap an entire chunk of JavaScript in a nice big try\/catch. But, how many of us want to wrap our entire script in a try\/catch? JavaScript just doesn't have the useful error reporting that server-side languages have, such as context, line number, etc (some browsers support line number). This would be a debugging nightmare, as the errors would no longer be picked up by our browser console – our true friend in the debugging effort.<\/p>\n

JavaScript does, however, treat it's "turn-me-on" tag a little differently than server-side-languages. "turn-me-on", of course, refers to the <script><\/tt> tag saying to the browser, "start parsing JavaScript!". What were you thinking? \ud83d\ude42<\/p>\n

The <script><\/tt> tag is self-contained, error-wise. It is an error barricade <\/em>from the rest of the <script><\/tt> tags. Server languages like PHP or ColdFusion don't provide such a barricade. You can have 30 <? ?><\/tt> directives in one PHP file, even divide them up across multiple files. But an error in one ruins the whole batch. Whereas in JavaScript, an error in one <script><\/tt> tag kills the entire script within, but doesn't affect the other <script><\/tt> tags at all.<\/p>\n

So, how is this useful?<\/p>\n

<script type="text\/javascript">
\n\t    var x = something; \/\/ 'something' is not defined
\n\t    document.write('Why won\\'t my message display, sadness');
\n\t<\/script>
\n\t<script type="text\/javascript"><\/code>
\n\t    pacemaker.keepOnWorking();
\n\t    document.write('I am unscathed by the errors in my document\\'s other script tag!');
\n\t<\/script><\/code><\/p>\n","protected":false},"excerpt":{"rendered":"

You hear the term robust thrown around loosely. "Hey Bob, that new app is gonna be robust, right?" "Oh yeah Steve, I'm all over that…<\/p>\n","protected":false},"author":1,"featured_media":1006,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"amp_status":""},"categories":[5,217,123],"tags":[230],"_links":{"self":[{"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/posts\/950"}],"collection":[{"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/comments?post=950"}],"version-history":[{"count":6,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/posts\/950\/revisions"}],"predecessor-version":[{"id":1007,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/posts\/950\/revisions\/1007"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/media\/1006"}],"wp:attachment":[{"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/media?parent=950"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/categories?post=950"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/tags?post=950"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}