All that I did is:

1. Download XCode 4 which is a free download from the Mac App Store.
2. Download the Stanford University iPhone and iPad Application Development Collection for iTunes U.
3. Watched the first 2 lectures from the course.
4. Fired up XCode 4.
5. Attempted the Reverse Polish Notation Calculator targeting the iPhone described in the second lecture.

Of course, this was a very simple iPhone application that was built with only about three ours exposure to Objective-C (the programming language), Cocoa Touch (the iOS framework), and XCode (the integrated development environment). It was a fun exercise. However, if you are only familiar with .NET and/or Java there are some uncomfortable moments with the Object-C syntax that you are bound to encounter. Mind you I am a complete novice with the language, the framework, the development environment, and the platform. Nevertheless, these are my experiences.

First things first… The iPhone application makes heavy use of the model-view-controller (MVC) pattern. I like this. I am familiar with the MVC pattern and I can work with that. What was surprising is that the only code I really touched was the model objects and controller objects. The view was entirely created with the visual designer which generated a storyboard file to describe the view. This file is an XML file. This wasn’t difficult to get used to as I only really worked with the native Cocoa view objects. I am curious to find out what the story for creating your own view objects is.

After dragging and dropping controls on the storyboard, I started working with the controller. This experience was mostly clicking and dragging connections from the visual designer to the controller source code and implementing a few properties and methods. Take a moment to review the controller header file:

#import <UIKit/UIKit.h>

@interface CalculatorViewController : UIViewController

@property (weak, nonatomic) IBOutlet UILabel *display;

@end

Even with some exposure to C and C++ over a decade ago, this header file appeared strange to me. It’s purpose is similar to C or a C++ header file as it serves to declare class, type,  function, and constant declarations.

Now look at the source file:

#import "CalculatorViewController.h"
#import "Calculator.h"

@interface CalculatorViewController ()

@property (nonatomic) BOOL userIsEnteringANumber;
@property (nonatomic, strong) Calculator *calculator;

@end

@implementation CalculatorViewController
@synthesize display = _display;
@synthesize userIsEnteringANumber = _userIsEnteringANumber;
@synthesize calculator = _calculator;

- (Calculator *) calculator {
    if (!_calculator) _calculator = [[Calculator alloc] init];
    return _calculator;
}

- (void)viewDidLoad
{
    [super viewDidLoad];
	// Do any additional setup after loading the view, typically from a nib.
}

- (void)viewDidUnload
{
    [self setDisplay:nil];
    [super viewDidUnload];
    // Release any retained subviews of the main view.
}

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
    return (interfaceOrientation != UIInterfaceOrientationPortraitUpsideDown);
}

- (IBAction)digitPressed:(UIButton *)sender {
    NSString *digit = sender.currentTitle;
    if (self.userIsEnteringANumber) 
        self.display.text = [self.display.text stringByAppendingString:digit];
    else if (digit != @"0") {
        self.display.text = digit;
        self.userIsEnteringANumber = YES;
    }
}

- (IBAction)operandPressed:(UIButton *)sender {
    if (self.userIsEnteringANumber) [self enterPressed];
    double result = [self.calculator perform:sender.currentTitle];
    self.display.text = [NSString stringWithFormat:@"%g", result];
}

- (IBAction)enterPressed {
    [self.calculator push:[self.display.text doubleValue]];
    self.userIsEnteringANumber = NO;
}

@end

This is the source file which contains the implementation details of the declarations in the header file. There really is a lot going on in both of these files that are needed to compile the view controller.

To be honest, at first glance I was really confused and it took me some time to understand the high level basics of the syntax and what it was doing. The @notation did not make sense. There are many keywords here that don’t translate directly to C#, or Java. I didn’t understand what the dash (-) in front of method declarations and implementations was for. What was the difference between the @interface structure in the header file and source file? I was really lost. The syntax was extremely foreign. Did you notice all the square brackets?

I will summarize what I can here, but really at this point I would recommend looking at a good Objective-C primer like the Learning Objective-C Primer found the iOS Developer Library. By the way, the documentation packaged with XCode 4 and the developer libraries found in the Apple Developer Center are your friends!

Concepts in the Header File

#import

The header file is small and concise and is not too hard to understand. The first think you should notice is the #import directive. This directive is similar to the using keyword in C#. It tells the compiler that you want to include code defined somewhere else in your header. In my header file, I am telling the compiler to include the UIKit header file where the interface of the UIViewController class is declared.

@interface

The @ symbol indicates a compiler directive. The interface directive is used to presents the class name (CalculatorViewController) and begins the declaration of the class interface. This should not be confused with the concept of an interface in C#.

It is my understanding that the declarations made in the header file are accessible to other header and source files when they are imported.  So in C# terms, you can think of these declarations to have the public visibility modifier applied to them.

@property (weak, nonatomic)

The property directive is a convenient way of declaring a property backed by an instance variable. The closest think I can think of is a the declaration of a property in a C# interface like this (even though it is a really far stretch):

interface IMyObject
{
    Object MyProperty { get; set;}
}

The next thing are the custom options contained in the parenthesis. These options define how the accessor methods behave. If you want to find out more, check out the declared properties documentation.

@end

This directive is used to close other opening directives. In this case, it closes the @interface directive.

Concepts in the Source File

#import

Here we see the #import directive again. In this file we have two of them. The first is the header file for this source file. The second is the header for a Calculator class that is used in the controller.

@interface

Again we see the interface directive. This time it is followed by parenthesis. I have no clue what these are for yet. Again my understanding here is that the declarations in this interface block are only visible to my implementation in this source file (somebody please correct me if this assumption is incorrect). Nothing really new here besides those things I don’t quite get.

Within this interface I declare two more properties and introduce some more custom options. I suppose these would be how you declare private properties in C#. But again it is a really far stretch that is not an accurate translation.

@implementation

The implementation directive is similarly structured to the interface directive as it begins with the presentation of the class name. The difference is that this directive contains the implementation details of the class. It is closed with the @end directive at the bottom of the page.

@synthesize

The synthesize directive the implementation counterpart to the @property directive. This directive tells the compiler to generate the setter and getter methods for the property according to the custom options presented in the interface declaration. In addition, we can also specify the instance variable that backs the property.

- (ReturnType)methodSignatureKeywords:(ParameterType)parameterName moreMethodSignatureKeywords:(ParameterType)parameterName

What the heck is this? Tons of stuff going on here. What you have here is the pattern of a method prototype. It starts with a dash (-) or a plus (+). The dash makes it an instance method while the plus makes it a class method (or a static method). In the first parenthesis we present the return type. This is followed by the method name interlaced with parameter types and names. I found this very hard to read at first. But with a little practice you can get some really readable methods.

When declaring a method with in the context of the the @interface directive you would terminate it with a semicolon. By contrast, within the context of the @implementation directive it is followed by an open curly brace, the method body, and terminated with a closing curly brace.

For instance, take a look at this method:

- (Calculator *) calculator {
    if (!_calculator) _calculator = [[Calculator alloc] init];
    return _calculator;
}

This method specifies the getter method for the calculator property. Yes, the compiler would have created a simple getter for the calculator property since I used the property and synthesize directives. But since I implemented the getter, the compiler will only generate the getter method. But moving on to talk about the method. Here I am declaring an instance method that returns pointer to a Calculator object. The method name is “calculator”. This is followed by curly braces that contain the method implementation details.

A loosely translated C# equivalent might look like this:

Calculator Calculator 
{
    get
    {
        if (_calculator == null) _calculator = new Calculator();
        return _calculator;
    }
    set;
}

I added the auto setter in the translation to give you an idea of what the @property and @synthesize directives did for me in this source file.

Let’s look at one more method in the source file:

- (IBAction)operandPressed:(UIButton *)sender {
    if (self.userIsEnteringANumber) [self enterPressed];
    double result = [self.calculator perform:sender.currentTitle];
    self.display.text = [NSString stringWithFormat:@"%g", result];
}

This example method takes a single parameter. And may be loosely translated to C# like this:

void DigitPressed(UIButton sender)
{
    string digit = sender.CurrentTitle;
    if (this.UserIsEnteringANumber)
        this.Display.Text = this.Display.Text + digit;
    else if (digit == @"0")
    {
        this.Display.Text = digit;
        this.UserIsEnteringANumber = true;
    }
}

You will notice the return type here is void and that is because the IBAction return type is a constant in the UIKit that the compiler translates down to void. The constant is used for integration between XCode and the Interface Builder tools. I probably don’t have this right either, but it is my understanding at this time (again if I wrong please point it out to me).

[targetObject methodSignatureKeywords:parameter moreMethodSignatureKeywords:parameter]

I’m sure you are asking about these now. The brackets are another notation that just did not make sense to me until some discussion in the Stanford lecture discussed them and even then I had to do a little reading in the documentation. The bottom line is this is the syntax for sending a message to an object. You can also think about this notation invoking a method.

So there you have it… my first experience with Objective-C, Cocoa, and XCode. I have much more to learn, but I am really happy that I tried it out. It was fun working with something new. I am still curious about how refactoring will work and I am sure I will miss my ReSharper features (if I do get into this I will probably try AppCode). I am also interested to investigate the unit testing options available.

[Update 4/17/2012] The walkthrough for the iOS calculator is available in PDF on the Stanford Course web site.

Thanks in advance for all your support!

The Problem Described

Take a look at the ASP.NET MVC 3 default route found in the Global.asax.cs file:

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(
        "Default", // Route name
        "{controller}/{action}/{id}", // URL with parameters
        new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
    );
}

This default route will basically allow you access to a resource using the basic URL convention that may look something this: http://localhost/products/edit/1 . However, the default RavenDB auto generated document identifier for the product document ends up looking something like this: products/1. (More information about the RavenDB document identifiers one of the documentation pages. ) So the URL to access that product resource for editing would really have to look like this: http://localhost/products/edit/products/1. Well that doesn’t work for two reasons:

1. The default route will not be matched so the URL will not be routed the correct controller action.
2. The URL is not SEO friendly.

Typically, this can be solved by using a custom route that access this resource by a natural key where the URL would probably end up looking like this: http://localhost/products/product-name/edit. This makes the URL SEO friendly, easy to read, and easy to route. However, there are some situations where the document identifier makes sense and I will continue this post on the assumption that this is the case.

The blog post mentioned above presents two solutions:

• Solution 1 – Change the identity parts separator convention for the RavenDB document store.
• Solution 2 – Modify the ASP.NET default route

Issues with Solution 1

Let’s look at the first solution. The suggestion is to change the identity separator convention from a slash (/) to a dash (-). The convention is really easy to change during the initialization of the document store object.

documentStore = new DocumentStore { Url = "http://localhost:8080/" };
documentStore.Initialize();
documentStore.Conventions.IdentityPartsSeparator = "-";

This makes RavenDB generate document identifiers that now look like: products-1. Now we can generate a URL that will match the default route and may look like: http://localhost/products/edit/products-1. I still find some issues this this. Namely, the URL is still not really SEO friendly and not really human readable. I don’t like the idea of exposing an identifier that was forced on me by RavenDB since it essentially has coupled my URL to the RavenDB identifier convention. It just doesn’t feel right.

Issues with Solution 2

This solution suggests the change of the default route to something like:

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(
        "Default", // Route name
        "{controller}/{action}/{*id}", // URL with parameters
        new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
    );
}

This will allow route to match a URL that looked like the first one: http://localhost/products/edit/products/1. I don’t like this either. While it does allow the default route to match and do its job. The URL is just ugly. It also clobbers the id making the route also match something like this: http://localhost/products/edit/products/more-junk/1. Obviously this is not SEO friendly or human readable. Again, it just doesn’t feel right.

Another Option

After some digging and learning about more about the document identity field, identity type converters, custom identifiers with the document key generator convention, I realized there was a pretty simple alternative to the two options above. But to see it and to understand the simplicity, you have to look at the source of the problem.

The reason that MVC routes are choking on the preconfigured RavenDB document identity convention is because our models included a string based identity property. I realized I had done this on purpose to ease the mapping of the RavenDB document identifier and my object identifier. Take a look at my product object definition:

public class Product
{
    public string Id { get; set; }
    public string Title { get; set; }
    public string Description { get; set; }
    public string ImageUrl { get; set; }
    public decimal Price { get; set; }
}

The shopping cart identifier is a string. Why would it be a string? It could have been an integer or a Guid or something else. It could have even been a natural key of some sort. Or even a compound key. It doesn’t have to be a string. Taking another look at the  IDocumentSession interface we can see we have four load methods available.

namespace Raven.Client
{
  public interface IDocumentSession : IDisposable
  {
    ISyncAdvancedSessionOperation Advanced { get; }
    void Delete<T>(T entity);
    T Load<T>(string id);
    T[] Load<T>(params string[] ids);
    T[] Load<T>(IEnumerable<string> ids);
    T Load<T>(ValueType id);
    IRavenQueryable<T> Query<T>(string indexName);
    IRavenQueryable<T> Query<T>();
    IRavenQueryable<T> Query<T, TIndexCreator>() where TIndexCreator : AbstractIndexCreationTask, new();
    ILoaderWithInclude<object> Include(string path);
    ILoaderWithInclude<T> Include<T>(Expression<Func<T, object>> path);
    void SaveChanges();
    void Store(object entity, Guid etag);
    void Store(object entity, Guid etag, string id);
    void Store(object entity);
    void Store(object entity, string id);
  }
}

After thinking about the difference between the method that accepts a string identifier and the one that accepts a value type identifier, I realized that all I had to do was change my identifier type from a string to a value type and I’m done. No fancy mapping or parsing the document identifier from RavenDB to the web browser and back. No changes to the default MVC route. No changes to the default identity separator convention. It just worked. My URLs are SEO friendly and more readable.

All I had to do was change the object identifier type.

public class Product
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string Description { get; set; }
    public string ImageUrl { get; set; }
    public decimal Price { get; set; }
}

That was easy.

Of course this doesn’t solve everything. What if I really do need a string based identifier? This will probably require tweaking the behavior of the RavenDB client. I also don’t have an answer for compound keys and other natural keys which may not be a value type. Some of these may require more thought from both the RavenDB side and the MVC side of my project. But that is another problem to think about some other time.

1. Remove the MicrosoftMvc*.js AJAX and validation scripts.
2. Update NuGet packages… I do things a little differently here. I completely remove the EntityFramework package (I may add it or another ORM back in later, but that ends up usually in a persistence specific project and it is usually a micro ORM). I also remove jQuery Visual Studio 2010 Intellisense package since the contents are bundled with the updated the other jQuery packages anyway. I remove the jQuery UI package (and add it back when I need it). Update the remaining jQuery and Modernizr packages.
3. Create my own JavaScripts directory to avoid overwrites when updating or installing other JavaScript based packages.
4. Love this tip! Who doesn’t like intellisense?
5. Already did this in step 2.
6. I’m not the sharpest tool in the shed when it comes to CSS. But this tip sounds like a good idea. Wonder if there is a NuGet package for Eric Meyer’s reset.css file?
7. I skip this step. In my opinion, the only models in my MVC project are view models anyway. So I leave the Models folder in my MVC project alone. If my project requires business models, they get placed in a business logic project. If I have persistence models, they get placed in my persistence project.
8. Another area where I am not the sharpest tool in the shed. But I do like fast loading pages, so I am going to try this tip out and put all the JavaScript files that I can at the bottom. Just remember that some do need to go at the top.
9. And yet another tip that I haven’t tried, but plan.

As a recap, tips 1, 3, and 4 make perfect sense. Tip 2 also makes sense, but I tweak it to fit my needs and I suggest you do to. I glaze over tip 5 and skip tip 7 because it was either previously addressed or doesn’t fit my needs. Tips 6, 8, and 9 sound like good ideas and I need to try them out.

At any rate, I was perusing some blog posts there this morning when I came across a couple of e-books they have. One talks about the SOLID principles and the other discusses refactoring. Both are important skills to be familiar with as a programmer. I personally like to read various sources on both of these topics when I get a chance since I like to continuously improve those skill sets. I encourage you to do the same.

• Nerdi - A collection of web development resources. From toolkits, to frameworks, to documentation, and all sorts of goodness.
• Font Awesome - An iconic font.
• kuler - A color scheme generator.

More stuff for me to play with. It’s times like these I wish I had a more innate ability to work with colors and design. It reminds me of the time I attempted to use another color scheme generator and quickly learned that the tool alone would not help my bad design. It only color coordinated it.

As I started my employment, I learned about their core values and was intrigued by the operational transparency. I was skeptical. My life experiences had taught me that core values were ideals which were just printed on paper and available on internal and external company websites. I had also heard the buzz of transparent management but never saw it practiced. Over the past three months, my skepticism has been erased.

Today, I believe in what I do. I am proud of how I do it. There is a different vibe here that I haven’t experienced before. I am surrounded by folks who are driven by a common belief of finding a better way to do business, a better way to build software, and a better way to run a company.

• Polyglot Persistence – Another term I learned from reading Flower’s Bliki at least six months ago or more.
• Big Data - Which is typically used to describe the problem of large data sets which cannot typically be accommodated by today’s traditional relational database systems due to cost, performance, and/or other operational concerns.

Another interesting discussion point, is the interest in other data store models some of which academic circles have previously explored. The recent interest, in my opinion is probably due to the changes in computers and networks since the time when the RDBMS became the preferred standard for data persistence many years ago. Ayende Rahien talks about this on a blog post. Some of different store models available (or in development) current NoSQL systems include:

• Document oriented stores (CouchDB, SimpleDB, RavenDB, Riak)
• Key-Value stores (Redis, Voldemort)
• Tabular or Column oriented stores (Cassandra, Hbase)

There are many more discussions taking place in today challenging how we think about persistence. Even traditional physical persistence mechanism is in question. A few years ago the idea of using anything other than a hard disk or a SAN for persistent storage would have been absurd. However, a physically distributed in-memory non-relational database is a viable option (most likely this option will be geographically distributed).  Other topics of discussion include:

• Clustering techniques
• Distributed systems

Truth is I don’t know what to call this current persistence movement. To me it seems obvious that terms like “NoSQL”, “Big data”, and even “Polyglot Persistence” are insufficient. We are definitely now in a different era  where a new persistence paradigm has begun. The relational database management systems no longer the only option. While those systems continue to have their place in today’s computing era, their market share is starting to shrink. Relational databases may even evolve to take advantage of the advancements made in this area.

The development, discussion, and research of new persistence solutions is happening now! Challenges issued to older traditional persistence systems are inspiring the revitalization, evolution, and enhancement of the existing software. Some of the old and new will survive, a few will thrive, and many will die. These are exciting times!

The Clean Coder

I love long breaks from work! Don’t get me wrong, I also love being a software developer and I am very passionate about creating software. However, long breaks give me an opportunity to spend more time exploring technologies which I don’t use day-to-day at my current job. Long breaks also offer a chance to read a little more than usual. This Thanksgiving break was no different. When I wasn’t preoccupied with the family and other holiday activities, I sat down and read Uncle Bob’s The Clean Coder: A Code of Conduct for Professional Programmers.

It really was refreshing reading another person’s thoughts on what makes a software programmer a professional. In many ways, this topic is tough as it is very subjective. Several published books tackle the topic of software craftsmanship, but not many really dive into professionalism. Throughout the chapters, there is discussion about responsible communication, estimation, and making commitments. Important topics such as practicing, learning, and personal commitments for self-improvement are also covered. Overall, the book is pleasing and easy to read as the author shares plenty of his life experience to illustrate his points.

I think there are some areas where the book falls short. For example, the chapter of estimation discusses our responsibility to communicate honest estimates and suggests including confidence factors to allow the product folk and project managers to do their duties. However, you won’t find detailed discourse on estimation techniques. In the books defense, it is not a book about estimation techniques and perhaps detailed discourse on such techniques is out of scope. In my opinion, the author would have overcome this by including more references to material where the reader can acquire or develop those skills.

On the other hand, other chapters (like the one on practicing) did give enough reference material to satisfy my wish for more information. I also found the Appendix filled with lots of goodies to help expand your exposure to reading material and tools.

Bottom line – I recommend this book to any software programmer who is passionate about self-improvement in the professional sense.