TSSJS – Presentation Slides Now Available!

I'm Speaking at TheServerSide Java Symposium Our slides from TheServerSide Java Symposium are now available online for a limited time! You can view the presentations below, or click on the title link to view/download them on slideshare.

1. GWT Roundup: An Overview of Google’s Web Toolkit and Hybrid Integration, presented by Scott Selikoff.

2. Throw Away All The Rules. Now What Process Do You Follow?, presented by Jeanne Boyarsky.

Live from TSSJS – Testing in the Cloud with Andrew

This afternoon I’m live blogging from TheServerSide Symposium, attending “Breaking all the Rules:  The Myth of Testing and Deployment in the Cloud” presented by fellow CodeRanch Andrew Monkhouse.

1.  CodeRanch History
Andrew opens his talk with a discussion of CodeRanch performance, traffic, and memory usage.  He mentions there have been serious issues in the past that haven’t temporarily brought the performance of the website down to a crawl.  CodeRanch uses a fork of JForum (2008) and staffs around 20 developers among 150 moderators, all volunteer participants, to build a custom community-based forum.

CodeRanch developers use a number of test strategies including smoke tests, load tests, and stress test.

2. Redeploying in the Cloud
The focus of Andrew’s presentation will be to demonstrate how CodeRanch would function in the cloud.  He has allocated a “small EC2 instance” (1.7GB memory, 1 compute unit, moderate I/O performance) within Amazon’s cloud that is useful for quick set up, but extremely small for practical use and reliable testing.

3. Benefits of the Cloud
The cloud provides a relatively clean environment in which it is ‘cheap’ to add extra servers, at least compared to running a local test server which may be allocated for additional processes.  Also, tests can run by anyone, anywhere, which is great for a distributed developer team, since Amazon allows you to assign rights to additional users.

You can easily create, set up, and desotry Amazon Machine Images (AMI), so you do not need to get it right the first time.  Lots of backup storage options, depending on your needs.

4.  Dangers of the Cloud
Testing in the Cloud can be difficult.  First off, it is hard to get absolute numbers because of the nature of the underlying change in hardware happening within the cloud.  Second, calibrating results is difficult.  Also, developers have to remember to shut down servers after they are down with them else other developers will run out of resources.  Finally, network traffic does cost money so testing can be expensive, although hardware is cheaper in cloud.

5.  Test Setup
The performance tests were set up into 3 servers, in part because it turned out to be cost effective to set it up this way based on the individual server options.

  • Application Server running CodeRanch
  • Database Server
  • JMeter Test Server

JMeter was used at the testing suite software given its large variety of features, options, and plugins.

6.  Test Analysis
Andrew discussed some items to keep in mind when testing the server and understanding the results:

  • It is quite possible for the Test Server to have greater load than the Application server, so be sure to monitor all your servers!
  • Try different graphs, they may tell you different things
  • JMeter plugins are your friend, they will help you identify problems with your application server and/or test set up.
  • Don’t forget about ramp up times

7.  Where do we go from here?
Automated weekly performance tests using the latest code base.  Add more stress tests.  Andrew comments there are no plans to move the CodeRanch to the cloud at this time given that we require full-time administrators since we don’t have a dedicated, paid team of administrators.

Conclusion
Andrew presents a compelling argument why you should be testing your applications within the cloud.  It provides a sanitary environment in which to perform a large variety of tests across multiuple servers.  I’ve heard arguments of moving application servers to the cloud, but this is the first time I’ve heard it suggested to migrate all automated testing to the cloud.

Live from TSS-JS – jQuery with Bear

Below is a hightlight of a presentation by Bear Bibeault, who gave a break out talk at TheServerSide Symposium entitled “How jQuery Made Bob a Happy Man”.  Bear is well-known author of many jQuery books as well as a moderator on the CodeRanch.

1.  Overview of jQuery
The invention of Ajax has blurred the line between server and client development by providing users a more rich user experience.  jQuery is one of those emerging direct Ajax frameworks.  Bear claims you don’t need to be a JavaScript expert to use jQuery, although you to have some background in jQuery.  Also, there are many plugins that provides a large range of overall functionality.

2.  Do More With Less
jQuery simplifies JavaScript by providing the browser-dependent wrapped in very simple calls.  One line of jQuery often represents dozens of hundreds of lines of JavaScript.  Unlike Prototype, it only uses one namespace $() to simplify coding.  Excellent for finding elements using selectors, whereas in pure JavaScript this would syntactically difficult.

  • Basic Selectors.  The most commons selector can match by ID or component CSS type such as $(‘div’) and $(‘myApplication’)
  • Positional Selectors.  Filtered selection based upon DOM relationships such as $(‘div:first-child’) as defined by CSS3.
  • Custom Selectors.  jQuery-defined filters that inputs things CSS missed.  Example:  $(‘:text:disabled’) [selects all text input elements that are disabled].

jQuery also has a very diverse library for event, click, and click handlers.  Hard to imagine how we ever lived without them.

3.  Plays well with others
jQuery has supported means to give up $() namespace for other tools to use that namespace.  In this manner, jQuery and Prototype can be intermixed.

4.  DOM Manipulation
Variety of DOM manipulation elements such as move/copy, add/remove, style manipulation, position manipulation (helpful for animations), etc.  Variety of integration tools such as GET/POST/PUT/DELETE, etc for server Ajax-based calls.  Includes tools to automatically parse JSON, XML, HTML and can even execute retrieved JavaScript code.

5.  Chaining jQuery
Common jQuery interactions allow you to chain elements such as $(‘myClass’).css(‘color’,’red’).show().appentTo(‘…’).  A little strange to get used but very powerful.  There are some functions that do return values and cannot be chained as this.

6.  document-ready handler
jQuery offers a document-ready handler that fires immediately after the page has downloaded but before the page has fully displayed.  Allows you manipulate items before they have been drawn.

7.  jQuery with JavaScript turned off
One of the design goals of jQuery is to create pages that ‘degrade gracefully’ if the user has turned JavaScript has been turned off.  For example, updating the form action to match a form submit click handler in the event the form is submitted without the Ajax handler being invoked.  Some government groups require pages to work with JavaScript disabled.

8.  More with Plugins
Large variety of plugins available for jQuery that follow similar patterns/structure as the core jQuery API.  Most popular ones are jQuery UI for complex UI widgets, and jQuery Forms for advanced form handling.  There’s also validation plugin to help simplify creating complex form validation logic.  jQuery Templates can be used to create versatile client-side templating.  Finally, there’s LiveQuery for notifications and updates about elements being created and destroyed.

Conclusion
Bear reiterates the point “Do more with less and in less time” and in that jQuery is successful.