The Software Devotional

Speaking at VSLive New York

Last week I learned that I would be speaking at VSLive in New York this fall. I will be presenting two talks on Wednesday, September 10. One talk is entitled "Microsoft's Patterns and Practices - More Than Just Good Advice" and the other is "Fall in Love with Visual Basic All Over Again - Visual Basic 9". In the patterns talk my goal is to not only educate attendees about the functionality present in Microsoft's patterns and practices libraries but also to try to convince the listeners that it isn't worth spending time rebuilding these same tools - use your developers' time to build products that add business value. My talk about VB9 will cover many of the new features added in the latest release of VB, along with some features that come as part of Visual Studio 2008. I don't plan to cover the LINQ features in VB9 as I am sure you will see more LINQ presentations than you care to think about.

Book Report: No Fluff Just Stuff Anthology, 2007

I missed the first version of this book, No Fluff Just Stuff Anthology, 2006, but I have vowed to try not to miss any future releases. No Fluff Just Stuff Anthology, 2007 is a pretty good book by one of my favorite publishers: Pragmatic Programmers. If you have interests in software development outside the world of .NET, this book provides a broad introduction to lots of hot tech topics, albeit mostly in the worlds of Open Source and Java development.

Called "A Technical Conference to Go!" by one Amazon.com reviewer, this book is a collection of bite-sized articles covering a wide array of software development topics and range from mostly philosophical to hands-on how-tos. I found about a half-dozen interesting topics and was enlightened in some way by most of the others. Most .NET and Windows developers would typically stay far from this book simply because most of the content is so far from any topics of practical use. However, if you are an avid reader and try to stay on top of the world of software development outside the boundaries of Microsoft, take a look at this book.

I don't often include the table of contents from a book, but I want you to get a feel for the breadth this book covers:

• Chapter 3 - Learning to Love JavaScript
• Chapter 4 - The Joys of Continuations and Asynchronous Architectures
• Chapter 5 - The Case for Groovy
• Chapter 6 - Give It a REST
• Chapter 7 - Guerilla Testing with Cobertura, TestNG, and EasyMock
• Chapter 8 - An Introduction to the Google Web Toolkit
• Chapter 9 - Web Testing with Selenium
• Chapter 10 - IntelliJ Tips, Tricks, and Techniques
• Chapter 11 - Pragmatic Tips, Tricks, and Techniques: Eclipse
• Chapter 12 - Improving Code Quality Using Automation
• Chapter 13 - Capistrano: Application Deployment and More
• Chapter 14 - Bootstrapping Agility
• Chapter 15 - The Software Engineer's Guide to Usability
• Chapter 16 - Integrating Ruby with Your Legacy Code
• Chapter 17 - Executable Documentation with FIT and FitNesse
• Chapter 18 - Introducting the iBATIS Persistence Framework
• Chapter 19 - Data Access Using Spring, Hibernate, and JDBC
• Appendix A - The Authors Speak

The No Fluff Just Stuff Software Symposium Series is a series of technical conferences whose topics cover the gamut of software development and are delivered by some of the biggest names in the industry. This book is organized similarly. From the NFJS site:

The No Fluff Just Stuff Software Symposium Series is designed to cover the latest in trends, best practices, and newest developments in Enterprise Java, Java/Groovy, ESB/SOA, Ajax, Web Services, Agility, and Architecture. Our commitment is to provide the very best in terms of speaker quality and overall conference experience.

In the remainder of this post, I will discuss my favorite chapters ("Learning to Love JavaScript" and "Bootstrapping Agility") and some that I found interesting or ripe for recommendation ("Give It a REST" and "An Introduction to the Google Web Toolkit").

Favorite Chapters:

"Learning to Love JavaScript" - Chapter 3, Glenn Vanderburg

Glenn opens the chapter explaining why many Java developers missed the boat on JavaScript. Arguably, JavaScript was poorly named, baring only superficial resemblance to Java. Early implementations of JavaScript were plagued by problems that undoubtedly drove off many potential Java converts.  First, early implementations were plagued with technical problems. Add to the technical problems the issues caused by various browser incompatibilities, and JavaScript was positioned to be hated by many developers. In addition, JavaScript became the de facto manner in which many sites adding very annoying actions such as scrolling banner and other visual effects - big turnoffs for technical types.

There also existed a sociological issue that JavaScript helped exacerbate. At the time JavaScript was beginning to become more widely adopted, many new 'developers' had recently shifted career gears to get into the web development game due to rapidly elevating salaries and high demand in the job market. This caused many people to quickly 'learn' JavaScript from snooping into the code borrowed from other web sites. Combined with the lack of good JavaScript books, the new class of developers were learning bad techniques and subsequently building buggy web sites.

Despite these issues, around 2000, JavaScript began to get traction when its communications capabilities were tapped to build a new class of remote scripting libraries.  These were early versions of what is now known as AJAX. Around this same time, the netWindows project was started in an attempt to build a rich GUI environment that would operate inside web pages. The netWindows project developed later into the Dojo project, which is one of the most widely used AJAX toolkits available today. Finally, when Google developed Gmail, Google Suggest, and Google Maps, all but the blind could see that this was a whole new world of web. This pioneering work has transformed the Internet and how it is used.

Glenn goes on to describe his epiphany when he began thinking in Java and realized that much of beef he had with JavaScript is caused by what he calls missing limitations present in Java and other programming languages. He describes an application that we wrote using JavaScript, and the mistakes he made writing it while using JavaScript but thinking in Java.

This was an interesting chapter to read. I haven't read an overview of the history of JavaScript and it was interesting to understand the background events that influenced the development and adoption of JavaScript and to put my own memories of experiences with JavaScript into place in his timeline.

"Bootstrapping Agility" - Chapter 14, Venkat Subramaniam

This was easily my favorite chapter in the book. Venkat is the author of one of my favorite 'development practices' books, Practices of an Agile Developer and this chapter is another great work on a similar topic.  The book discusses the 'things' a good developer does to be 'agile', while this chapter discusses how we can address architecture in an agile way.

What does an agile architecture look like? It is the product of agility at every step in the process of building software: planning, architectural development (including the role of architects), modeling, design, development, and testing. In short, an agile architecture is one that is able to (and does) undergo an evolutionary life cycle. The best architecture will be designed by someone (or a team) who knows the most about the problem at hand (all other things being equal), it only makes sense that your design team will get progressively better at building a suitable architecture. In order to leverage this increased understanding, the architecture must have been designed such that it can readily evolve as the problem becomes better understood and, perhaps, more generalized.

In the chapter, Venkat discusses some of the practices that agile architects exercise when designing a system:
Never Design Alone
I can't say it better than Venkat does in his chapter (p 199): "A design is an idea that you arrive at based on what you know.  As what you know changes, the design will have to change as well. This is the evolutionary nature of design. You constantly evaluate your design and make adjustments. Refactoring is a continuous activity. Since the design depends on your knowledge and perspective, you have a better shot at arriving at a good design when you involve multiple people in the desing activity - never design alone. Design must be carried out by a small group of developers working closely with each other. A better design emerges when intelligent people are involved in passionate discussions."

You Aren't Gonna Need It - YAGNI
Einstein often made the argument that simplicity is no simple matter. He was arguing that the underlying design of the physical laws of the universe had to be quite simple, and that it was only our limited observations that complicated the elucidation of the simple laws. From the design perspective, our goal should be to design the system as simply as possible. The problem is that software architects and developers believe they can predict the future of a product's functionality and have become notorious for over-engineering solutions to problems. One common software development practice is to design a system to be more flexible than is required. The basic problem with this idea is that it is sometimes difficult to know ahead of time what flexibility will be required, meaning that the original solution might solve a need that never arises or solves the need inappropriately. The term YAGNI (You Aren't Gonna Need It) was coined to help prevent unnecessary design and development activities geared toward functionality that isn't required.

Don't Repeat Yourself - DRY
In short, each piece of functionality and each piece of information should have a single authoritative definition.  When the same information or functionality is repeated throughout a system, the system becomes fragile and maintenance becomes a problem.

Single Responsibility Principle - SRP
Each function should have a single responsibility. Despite the intuitive feeling that this over-complicates a system and adds an endless collection of functions and classes to an otherwise simple project. However, through appropriate organization and naming, these issues can be much more easily managed than a smaller number of functions that perform multiple activities.

Notable Chapters:

"Give It a REST" - Chapter 6, Brian Sletten

Good reading for anyone who doesn't quite understand the debate between the REST and WS camps.

"An Introduction to the Google Web Toolkit" - Chapter 8, David Geary

Having never used the GWT, it was interesting to see the basics of the toolkit and what pieces of common web based tools Google has made considerably easier.

Resources:

• No Fluff Just Stuff Site
• No Fluff Just Stuff Software Symposium Series
• No Fluff Just Stuff Anthology, 2007
• No Fluff Just Stuff Anthology, 2006
• Practices of an Agile Developer

Speaking at CodeStock 2008

Yesterday I received word that I would be speaking at the upcoming CodeStock 2008 conference in Knoxville, TN. CodeStock is one of a growing number of smaller regional conferences organized by passionate developers and/or local user groups. The size of these conferences make them fun to speak at and attend. Unlike other conferences that cost a fortune, take you out of the office for a week, and require you to fly to other states (maybe you like those things), conferences like CodeStock are short (1 day for CodeStock) and are held close to where you live and work. Try one out before signing up for a big national conference.

I will be giving a talk about one of my favorite topics: Amazon's web services framework. I will be covering the ins and outs of using S3, SQS, and SimpleDB from a .NET app.

According to the CodeStock web site:

CodeStock's mission is to bring the best and brightest code experts to East Tennessee for a one day conference open to all developers. This is not a trade show with slick salesman giving prepared demos - this is a gathering of real programmers learning about the latest in technology from each other. Sign up now to learn how you can join us for CodeStock 2008!

Register for CodeStock today. The cost is only $25.

New AWS High-CPU EC2 Instance Types Announced

Amazon announced today the availability of new instance types for EC2. Previously, EC2 instances were heavier on memory allocation than the new High-CPU instances. The new instance types, dubbed "High-CPU Instances" scale the processor count, or EC2 Compute Units, more quickly than memory. The proportion of CPU/memory in the High-CPU instances is considerably higher. Processor intensive applications that don't require substantial memory allocations can now be run on fewer instances, meaning they can be operated at a lower cost.  Using the "Standard" instance types, the cost per EC2 Compute Unit (without respect to other factors) was $0.10/hour. The High-CPU Instance types cost only $0.04/hour to operate.  Again, the rough pricing is subjective to the application's need for other resources such as RAM, disk space, I/O performance, and perhaps the advantage of running on a 64 bit platform. Keep this in mind when you compare the per-Compute Unit prices above.

Take a look at the instance types that were added:

High CPU Medium Instance
	$0.20 / instance hour
	1.7 GB of memory
	5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each)
	350 GB of instance storage
	32-bit platform
	I/O Performance: Moderate
High-CPU Extra Large Instance
	$0.80 / instance hour
	7 GB of memory
	20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each)
	1690 GB of instance storage
	64-bit platform
	I/O Performance: High

Compare the "High-CPU Extra Large Instance" to the standard "Extra Large Instance" shown below:

High CPU Medium Instance
	$0.20 / instance hour
	15 GB memory
	8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each)
	1,690 GB instance storage
	64-bit platform
	I/O Performance: High

Amazon defines a compute unit as follows (taken from here). Refer to Amazon's description of instance types for more details.

EC2 Compute Unit (ECU) - One EC2 Compute Unit (ECU) provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.

Get some. :)