Last week, I traveled to Houston. It’s was nice three-hour drive there. During my stay, I needed to grab a quick lunch and ended up at Five Guys.

This was tough. I really like a good burger and I really (and I mean REALLY) like Five Guys.

So I rushed my order and asked for a “Bacon Burger” all the way. Usually, I would order a bacon cheese burger but my Spidey-sense told me to skip the cheese. Then something inside me asked if I could have it lettuce wrapped. The guy who took my order said, “No problem!”. I smiled and paid for my order.

While waiting for my order, I realized that I should have asked for no mayo and no ketchup. I love mayo, but I am not sure it is a good source of fat according to the Primal Power Method. Ketchup has a lot of sugar and was probably a bad idea.

A few minutes later, they called my order. Turns out the ketchup, mayo, and mustard were in separate containers and I enjoyed my lettuce wrapped bacon burger without them.

The other ingredients (grilled mushrooms, grilled onions, and pickles) seemed okay to me. Although I should probably double-check on the pickles and the bacon was probably cured (eat uncured bacon instead), it looks like a Primal Power Method meal is possible there.

• Putting garden beds next to the foundation. The watering caused a lot of erosion that, if continued, may result in costly foundation problems.
• Planting randomly. We planted things we commonly used like Thai chili peppers, Serrano peppers, Habanero peppers, Thai basil, mint, lemon grass, Thai egg-plant, bell peppers as we created the garden beds without planning.

As a result, we are doing some planning while I build out two 12×4 foot raised garden beds about 6 feet away from the foundation. I am using 2×12 pre-treated wood to build the beds and planing on getting about 3.5 cubic yards of garden soil from a local nursery to start the beds.

Other projects this year include:

• Composting bins – we have enough kitchen and garden waste to cut our cost of commercial compost and other garden products.
• Rain water collection system – we spent a lot on water last year and I am confident we can cut it by collecting and using rain water as our primary garden water source.
• Building out Grandma’s pantry – we wasted some of our garden produce this year and want to make the best of this year’s bounty by storing it. Additionally, we always run to the store at the last-minute to prepare our holiday meals and want to get ahead of it this year.

There are plenty of other home projects we want to complete and we may do more this year. But we have to start somewhere, and these three projects are a good spot to start.

More details on each as we roll them out.

Three years ago I stopped focusing on my nutrition and exercise and managed to put on over 50 lbs. Well the time has come again to wage war on obesity and I figured I would openly share my goals and my progress against it.

Now, I am no expert on nutrition or health. So what I do, I do with the goal of living a better life and being a better father, husband, friend, and employee (in that order).

In terms of nutrition, I started eating according to the Primal Power Method a little over two weeks ago and have seen great results.

In terms of exercise, didn’t change a thing. I still try to walk about 15-30 minutes every day. I still try to take the stairs instead of the elevator. I usually park a good distance from my non-home destinations (driving large truck forces that on you anyway). And that’s it.

So, what are my results?

• On January 5th, 2015, I weighed in at 284 lbs.
• On January 12th, 2015, I weighed in at 275 lbs.
• On January 19th, 2015, I weighed in at 270 lbs.

That’s 14 lbs in two weeks.

My goal is to get under 200 lbs. Which means I still have a long way to go. However, I am hopeful after these results and will keep on trucking for now.

I will share some of my challenges along the way. I hope you will take the steps necessary to live better and become an improved version of you.

I will be giving my Up and Running with RavenDB presentation for the third time. Although, I have revamped it by incorporating the feedback I received from earlier events.

Hope to see you at my session!

The Problem

At the root level of my web site, I want to show one view to an authenticated use and a different view to an anonymous user. This is a very common need and feature in many web applications. For example, let’s look at Facebook. When you point your browser to http://facebook.com, you will get one of two things depending on whether you have an authenticated session. If there is no active session, then you are presented with a welcome message which asks you to create an account. If there is an active session, then your get your timeline.

The solution for this from the server-side is actually simple. When the server receives the request for the home page, then we can simply check the session and use it to decide which view to respond with. Done. Easy as pie!

With a SPA, the solution wasn’t as clear. At least not to me with my limited AngularJS experience.

Solution

To be honest, I hope somebody else has a better solution than this to share with me. But this is what I did. I started an app.js file containing some simple AngularJS configuration logic:

The template pulled down by the root route was empty at this point and I was forced to make a choice. Should this template contain the welcome page content? Or should it contain the authenticated user content? Or what?

I decided it would contain the authenticated user content. This is because I expect (well more like hope) that most people who visit my application will log in and use it. This hopeful assumption made sense and so I set out to build my home page controller.

The first thing that I thought I would do was to inject the $http service so I could make a call to my website’s API and get the user’s session object. If I get a session back then I can go ahead with displaying the home page for the authenticated user. If I don’t then I can route them to the welcome page using the injected $location service and ask them to sign up or log in.

At this point my update app.js file looks like this:

Thoughts

This approach is very simple. At the end of the day, it is not really what I wanted. What I wanted to do is to dynamically tell the $routeProvider which tempalteUrl to use dynamically. This is probably due to my experience writing server-side MVC logic to select a view based on the session state. I didn’t like that I now have an extra route for my welcome page. This doesn’t feel right to me. At least, it doesn’t feel natural.

Another approach that I considered after this implementation is using an ngView directive in my template and dynamically setting the templateUrl value using the $scope in the controller. However, I don’t like the idea of branching logic in the controller to populate the scope differently based on the session. That doesn’t feel right either.

So what’s next? Well, I think I am going to stick with this solution for a bit and probably create a session service to get the session object since I will probably need it between various controllers. I will probably also push a response interceptor in the $httpProvider to handle unauthorized responses from the API. While I am not entirely comfortable with this approach yet. It looks promising giving my limited exposure to AngularJS. I am hopeful that a fellow reader may offer some suggestions and/or advice.

This was fun talk that I would like to give again.

Here are the slides from the presentation:

There are a few upcoming RavenDB events that I am very excited to be a part of. Check the links for more information:

• August 23rd: Open House Party with Oren Eini
• August 25th: Getting Started with RavenDB (a Houston Code Camp session)
• September 5th-6th: RavenDB Boot Camp

Hope to see you there!

If you would like to see the source code for the Depot Application in MVC 3 with RavenDB presented towards the end of the presentation, it is available on GitHub.

Don’t forget to check out the upcoming Central Texas GiveCamp! I am really looking forward to seeing the developer community get together to give to charity.

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:

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:

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):

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:

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:

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:

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

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!