IndyNDA

IndyNDA – Windows Phone 7 Application Platform

This month’s IndyNDA meeting is tomorrow, September 9, 2010. Come hear Bill Steele from Microsoft speak about the Windows Phone 7 Application Platform.

Following the main meeting the three special interest groups (SIGs) will meet.

ASP.NET SIG: Continuing work on an ongoing MVC knowledge base application.

C# SIG: I’ll be presenting an introduction to dynamic programming in C#.

SharePoint SIG: Topic to be determined.

Registration opens at 5:30 PM and thanks to our sponsors food and drinks are provided until 6:00.  I hope to see you there.

Location:

Nine Parkwood Crossing
5th Floor Conference Room
900 EAST 96TH STREET
Indianapolis, IN 46240

Advertisements

IndyNDA: MongoDB & Reactive Extensions

The June 10 IndyNDA meeting was one of the most interesting I’ve attended in months.  First, Dennis Burton gave a high-level introduction to MongoDB then for the C# SIG Joel Dart gave a fairly detailed introduction to Reactive Extensions.  I’ve heard a lot of buzz about both of these technologies lately but really haven’t done much investigation on my own so I was glad to see them both in action.  I was inspired to look deeper into both technologies after the presentations.

MongoDB

MongoDB has been getting quite a bit of press lately.  There was even a session devoted to it at IndyTechFest.  Even though I had heard a bit about it and knew it falls under the NoSQL heading I really didn’t know much more than that.  What’s wrong with relational databases?  What does it mean to be NoSQL?  Where does Mongo fit in?  Dennis did a great job answering each of these questions and more.

What’s Wrong With Relational Databases?

Nothing.  The relational model is alive and well and has a definite place in the world of software development.  The problem is that the relational model was originally described in 1970 and hasn’t changed significantly since then but the world has and the types of applications we’re building have changed with it.

Think about some of the decisions that need to be made for a new application (assuming .NET):

  • Which language should it be written in?  C#?  VB?  C++?  F#?
  • What type of UI should it have?  WinForms?  WPF?  Silverlight?
  • If it needs interprocess communication should it use remoting or WCF?

We answer all of these questions and more, then we say “oh, and we need a relational database” regardless of whether it’s the right tool for the job.  Relational databases have been the default answer to the question of how to store the data for years.  The NoSQL family of databases offers an alternative to the relational model that may or may not be the best solution to the problem.

What Does it Mean to be NoSQL?

NoSQL is exactly as it sounds.  NoSQL databases don’t use SQL for storing or accessing data.  MongoDB is a document oriented database.  Unlike a relational database which stores related objects separately and brings them together with joins a document oriented database stores related objects together.  This differentiation does require a change in mindset and terminology.

Relational Document Oriented
Database Database
Table Collection
Row Document

With MongoDB there is no predefined schema.  Databases can be implicitly created just by referencing them.  The same goes for collections.  Need a new collection?  Just specify a name and add a document.  The lack of a predefined schema also means that documents stored within a collection don’t need to follow a consistent structure although they typically will.

Where Does Mongo Fit in?

Mongo is designed for speed and scalability.  This makes it ideal for applications where performance is critical.  The MongoDB web site states that it is well suited for content management, caching, high-volume, and areas requiring a flexible data structure.  That said, given the emphasis on speed and scalability it is not well suited for environments requiring complex transactions such as banking systems nor is it good for problem-specific business intelligence systems.  MongoDB also has very limited support for user security leaving the responsibility for managing security up to the application.

Additional Resources

I’ve starting learning MongoDB and will probably have more posts to go along with what I’m discovering but until then:

Reactive Extensions for .NET (RxNet)

Reactive Extensions (Rx) for .NET is another technology I’ve heard some whispers about but hadn’t really looked into.  So, what is Rx?

The Microsoft DevLabs site states “Rx is a library for composing asynchronous and event-based programs using observable collections.”  What this means is that we can now use a superset of LINQ to respond to events or other asynchronous operations in a declarative rather than imperative manner.

Rx introduces the IObservable<T> and IObserver<T> interfaces which are essentially the opposite of IEnumerable<T> and IEnumerator<T>.  IEnumerable<T> and IEnumerator<T> work with pull-based operations where there is a predefined set of data to work with whereas IObservable<T> and IObserver<T> work with push-based operations where the entire set of data cannot be known in advance.  There is also a specialized ISubject<T> interface that simplifies error handling and completion.

Joel’s first demo really drove home the point of why Rx is often referred to as LINQ to Events.  In this demo he showed a Silverlight application with a red square that he was able to drag around with the mouse.  Rather than having to respond to each MouseDown, MouseUp, and MouseMove event individually and set state flags to manage what should happen within each event handler he showed how Rx enabled handling each of those events within a single LINQ statement that would calculate and project the delta of the mouse pre and post positions and pass the delta to a separate function responsible for updating the position of the box.

Rx really offers a powerful new way to work with asynchronous and event-based programs.  I can already see a few places in some current projects where it would be really handy.  Rx also isn’t restricted to .NET.  There’s already an Rx library for JavaScript!  I’m really looking forward to getting some time for further investigation.

Additional Resources

Indy Code Camp Notes, Part 4

This is part of a four part series of notes I took at Indy Code Camp on May 16, 2009. This year’s Code Camp consisted of five tracks each with five sessions. Track topics were SharePoint, SilverLight and WPF, Data Access, MIX highlights, and best practices. These notes are from the sessions I attended.

These notes are in no way intended to replace attending one of these talks if you have the chance.

Test Driven is Driving Me Insane!

Presented By: Dennis Burton

Dennis’s talk focused on road-blocks to effective Test Driven Development and some common, practical test patterns. My notes are a little sparse on this one since it was the last session of the day and my mind was wandering a bit ;) He had a lot of good examples that I wish I could remember a bit better.

Road-blocks To Effective Up-front Testing

  • Management push-back
    • “Double the code? Are you kidding?!”
    • Project timeline impact due to code changes taking longer while tests are updated
  • Test design issues
    • Long-running tests – ideally each test should run in less than a second
    • Long-setup time
    • Fragile tests – more work is required to keep tests running when changes are made
    • Data dependency issues – tests rely heavily on data specific data, often from a production environment

Common Patterns

  • Dummy Pattern – use when an object is needed only to help construct another object
  • Stub Pattern – use when an object is needed to help construct another object and its state must be verified
  • Mock Pattern – use when testing functionality functionality instead of specific data
  • Spy Pattern – use to add validation to an object that does not implement the required validation. This is typically implemented as a wrapper class that passes values into the type being tested

Recommendations

Indy Code Camp Notes, Part 3

This is part of a four part series of notes I took at Indy Code Camp on May 16, 2009. This year’s Code Camp consisted of five tracks each with five sessions. Track topics were SharePoint, SilverLight and WPF, Data Access, MIX highlights, and best practices. These notes are from the sessions I attended.

These notes are in no way intended to replace attending one of these talks if you have the chance.

Being More Than a Code Monkey: Practicing Beautiful Code

Presented By: Michael Wood – Strategic Data Systems

In this session Michael described some common traits of “ugly” code and presented some guidelines as to what makes code beautiful. Clean Code by Bob Martin is recommended reading for more information on this topic.

Beautiful Code is NOT

  • Hard to follow
  • Hard to extend
  • Something you have to slog through
  • Done with brute force (If it’s really hard to do you’re probably doing it wrong)
  • Code that people run from

Why Should I Care?

  • Working with ugly code can negatively impact project timelines. If code is difficult to understand it will take subsequent developers longer to get to a position to maintain that code. It can also potentially have cross-project impact if previous developers need to be brought in to help explain the code.
  • Code that is difficult to extend will likely require additional refactoring which can possibly seep into additional areas.
  • Like broken windows bad code tends to beget bad code. High quality standards need to be maintained consistently across the application in order to be effective.

Traits of Beautiful Code

  • Self documenting – types and their members should be named according to their purpose. Comments are nice but need to be maintained to be effective as code is changed. By writing self-documenting code the need for comments is significantly reduced if not eliminated.
  • Avoids using magic numbers – anything that could be a magic number should be defined as constant or enum member. Similarly, consider using an abstract class with constant strings to simulate an enum to avoid having hard-coded strings inline.
  • Exceptions carry additional information – the Exception class has a Message property and an InnerException property…USE THEM!

Code Monkey Song by Jonathan Coulton

Michael mentioned this song and video in his presentation so I thought I’d include it. Enjoy!

Indy Code Camp Notes, Part 2

This is part of a four part series of notes I took at Indy Code Camp on May 16, 2009. This year’s Code Camp consisted of five tracks each with five sessions. Track topics were SharePoint, SilverLight and WPF, Data Access, MIX highlights, and best practices. These notes are from the sessions I attended.

These notes are in no way intended to replace attending one of these talks if you have the chance.

Improving Our Craft: A Discussion on Software Estimation

Presented By: Michael Eaton – Validus Solutions

Michael started his talk by tossing out some statistics about project success rates and defining some terms. He then moved on to discussing why we’re so bad at giving good estimates and wrapped up with some ideas for how to improve the estimates we do give. Unfortunately I wasn’t able to capture the exact stats but they were eye-opening to say the least in that in 2006, only 32% of projects were considered to be successful.

Terms

  • Estimate
    • Tentative evaluation or rough calculation
    • Preliminary calculation of cost
    • Initial judgement
  • Target
    • Statement of desirable objective
  • Commitment
    • A promise to deliver

Understanding Estimates

  • The challenge is to determine whether we are supposed to be estimating or projecting to hit a target. If we’re projecting to hit a target do we produce what was expected?
  • Estimates will by their nature, be wrong. We’re providing estimates not exactimates.
  • A good estimate is one that provides a clear enough view of the project reality to allow the project leadership to make good decisions regarding targets.

Why Are We So Bad?

  • Unknown problem domain
  • Vague, missing, or large requirements
  • We forget stuff
  • Overconfidence
  • Insufficient education or practice making estimates
  • Never given a chance to succeed (set-up for failure)

The Cone of Uncertainty

The Cone of Uncertainty states that the actual duration of a project can take up to four times as long or 1/4 as long as expected.

What Can We Do?

  • Stop giving off-the-cuff estimates
  • Communicate
  • Incorporate Agile practices
    • Iterations
    • Daily Stand-ups
  • Decompose the problem into smaller chunks and estimate the chunks
  • Let developers estimate their own tasks rather than having a manager or lead developer provide estimates for the team
  • Estimate end-to-end tasks
  • Learn from your mistakes
  • Keep a log of estimates and periodically review it

Indy Code Camp Notes, Part 1

This is part of a four part series of notes I took at Indy Code Camp on May 16, 2009. This year’s Code Camp consisted of five tracks each with five sessions. Track topics were SharePoint, SilverLight and WPF, Data Access, MIX highlights, and best practices. These notes are from the sessions I attended.

These notes are in no way intended to replace attending one of these talks if you have the chance.

Care About Your Craft: Adventures in the Art of Software Development

Presented by: Tim Wingfield – Quick Solutions

Tim’s talk focused on how to get better results out of each phase of the SDLC. Included here are key points from each section.

Design

  • TDD should not be thought of only as Test Driven Development but also as Test Driven Design
  • Design with the SOLID Principles in mind
    • Single Responsibility Principle
    • Open/Closed Principle
    • Liskov Substitution Principle
    • Interface Segregation Principle
    • Dependency Inversion Principle
  • Design by Contract – TDD can actually force us to do this
  • Avoid programming by coincidence – Understand how and why something works
  • Don’t be a plumber – Chances are good that someone else has had to save the same technical problem so there might already be a framework that can be used and let you focus on the actual business problem at hand
  • Justify technology use – Don’t use a technology just because it’s new, use it because it better solves the problem
  • You Ain’t Gonna Need It (YAGNI)
    • Don’t waste time building features that might be used

Development

  • Quality is not an accident – build it into everything starting with requirements
  • Don’t Repeat Yourself (DRY)
    • Reuse code and avoid copy/paste programming
  • Automate where ever possible
    • Build servers are a great for automation
    • Use code generators to speed up development by automating common coding tasks such as creating properties, creating method stubs, and refactoring.
  • Avoid finger pointing by taking collective ownership – We’re all in it together
    • OUR build broke
    • OUR defect
  • Don’t live with broken windows
    • Bad code begets bad code
    • Fix problems when they’re found (time permitting) rather than letting them propagate
  • Know when enough is enough
    • Perfect is nice but software has to ship sometime

Debugging

  • Someone (QA or a customer) will find a defect
  • When a defect is found, don’t panic
  • Think about the solution before rushing to action
  • Avoid placing the blame and work toward the best solution

Continuous Improvement

  • Always keep learning
  • Maintain a positive attitude
  • Be a mentor
  • Create a culture geared toward continuous improvement
    • Schedule lunch ‘n’ learns
    • Have book reviews