Today, I submitted a “port” of the same application to the Windows Phone 7 Marketplace. I hesitate to use the term “port” for this though – it was a rewrite of the application. The only thing that remained common was the sound effect files themselves. The development here only took me about 4 hours. Contrast that to four days with the iOS version. To be fair, I spent a few hours finding the audio files the first time around, so the comparison really is the 3 1/2 days of development on the iOS version.

Comparing and contrasting both development environments:

iOS / Xcode 4

Pros:

• Large, established developer community.  Lots and lots of examples on the Internet.
• More users = larger potential market.  This has a negative side too – see the cons below.
• UNIX tools at your disposal, built into the OS.  There are some command line tools that are just invaluable. (sed, awk, grep anyone?)
• Full memory management at your disposal.  If you’re trying to do something that you want to track memory usage explicitly, those tools are there.  This is a double-edged sword, though.

Cons:

• Xcode 4 is just odd.  It uses a “browser” metaphor to code editing.  I kept closing the entire project instead of the source file I was editing.  Tabbed editing is there, but doesn’t work like you’d expect a text editor to work.  This made switching files complicated and mouse-heavy.
• Harder to get noticed in the App Store.  There are so many applications that marketing is even more important.
• It took a few days to get approved as a developer to even submit my app.
• Trying to remember when to [release] or [retain] an object was tricky and led to strange errors in the app.  Widgets would display but not function, the application would crash, etc.
• I crashed Xcode several times when I refactored parts of the application.  Lesson 1: do NOT rename your project within Xcode!
• Random mixing of C/C++ calling conventions and Objective-C message passing.  Not everything is an object.  Some will also argue that this is a feature.

Windows Phone 7 / Visual Studio 2010 SP1

Pros:

• More traditional IDE.  Visual Studio has editor tabs and seems more keyboard-friendly.  This just mostly just an Apple / Microsoft difference in ideology though.
• Visual Studio’s debugger is phenomenal.
• Less applications = easier to get noticed in the Marketplace.
• MSDN is an awesome resource.  I’ve done a lot of Microsoft development over the years, so I’m just used to navigating it and finding documentation there.  (Others will dispute this point, I’m sure.  This is just a preference of mine.)
• Project layout tracks the file system well.  Folders within your solution are truly folders on the file system as opposed to pointers in the project file.
• Approval to the Marketplace and developer program took about an hour.
• C#’s memory model.  If you’ve been working in garbage collected languages for a long time, it just feels natural to you.
• XAML is just cool.  It’s nice to see your UI in one view, with design data bound to it, and the code that generates it side-by-side.  This lets you get into the advanced parts of the UI design easily.  I’m sure Expression Blend will be handy if I ever try to get creative with the UI.

Cons:

• Less users.  The potential market for your application is simply smaller.
• Using Zune software to connect your phone.  This made the MediaElement component of my application not work while connected via USB.  Zune would lock the media library, so the sound files could not be found.  Had to disconnect the USB cable to test audio playback.  This meant I couldn’t use the amazing debugger during that testing.
• Windows Phone is a little more limited than iOS (multitasking, database support) – this reduces what your application can do.  To be fair, this has been resolved in the SDK, and in a few months, users will get these benefits in the Mango update.

Ultimately, both environments are good and bad.  It’s unfortunate that the only real reusable parts of an application are the resources (images, icons, sounds.)  This makes sense in some ways – Apple users expect a certain look and feel towards the application to fit in the rest of the ecosystem, and Microsoft users are no different.

I will probably continue to do development in both environments – after all, the point here is to have users want to buy your applications, regardless of the device.

Make sure you install the dependencies – in my case, I did this:

Next up, modify your settings.py accordingly:

I highly recommend you use SSL though, which changes your connect string to ldaps.

You still need to create a “superuser” when you do your syncdb. In my case, the username was the same as my Active Directory login and password. On your first login, it will fill in your first name, last name and email address in the database properly.

Initially, I had some trouble getting this to work because I was using ‘(uid=%(user)s)’ as my filter. In Active Directory, the user’s login field is called SAMAccountName. Turning on django-auth-ldap logging was very useful here.

Look for more details as we further integrate authentication / authorization into our app.

We stumbled upon this helpful link, but it seemed out of date and had some hardcoded values that didn’t mesh well with our schema.

The modified version now looks like this:

Within my model class, I override the save() method to use this:

You can use ‘default’ as your database_name parameter if you are not using multiple databases in your Django project.

While researching Python web frameworks, I briefly looked at Django, TurboGears and Pylons. I ruled out Django and TurboGears because I made a false assumption that high-level frameworks would be too limiting for our needs. Turns out I had greatly overestimated our “needs.” I reasoned that a lower-level framework like Pylons would be better suited for how we were used to developing web-based applications. I noticed that, over time, we spent an inordinate amount of time reinventing the wheel. How many authentication and authorization frameworks do you really need? The first time you write one, it can be considered interesting. By the 5th time, you’re wondering why you keep doing this.

Last year, I started a small hobby project at home. It’s never gotten very far, because I kept experimenting with different languages and frameworks. I even signed up for a VPS at GoDaddy, which I’m not even using. While this was a fun learning experience, here I am, a year later, no closer to complete with the project than I started.

Back to the drawing board, I decided to take another look at Django. IDE and tooling support has really changed. (Side note, PyCharm is really a great IDE.) Django’s documentation really is top-notch, it’s development and user community is active and thriving, and it’s simply a wonderful framework. In a short amount of time, I feel like I’ve actually made progress on my project. I’m using the Django-nonrel branch with the goal of deploying against Google App Engine by the end of the summer.

Now, at my day job, we’re making a custom content management system for powering one of our sites. There was a lot of talk about using an off-the-shelf product, but by the time we customize it and build modules to meet our needs, we’re no better off than writing an entirely custom solution. We also wouldn’t be serving content directly out of the CMS, so the “buy vs. build” decision was even easier. As soon as I mentioned using Django for development here, several other developers in the room got even more excited about starting this project.

Preheat the oven to 400 degrees.  Heat a medium sized, oven-safe skillet over medium-high heat. 

Cook the bacon, but you don’t want it too crispy.  Remove the bacon and drain the excess fat.  Cook the onion until translucent, and slightly brown.  Remove the onion.

Whisk the six eggs and half-and-half together.  Whisk briskly – you want to get some air into the eggs – they should be frothy.

Add the eggs, onion and bacon to the skillet.  Fold the eggs frequently until the bottom is just set.  Cover with the shredded cheese.  Bake in the oven for 10 minutes, until the edges are golden brown and the cheese is melted.

Cut, and serve!

When I made this, I used a pesto gouda cheese.  It melted well, and added a nice herb flavor to the frittata.  Any good melting cheese would work – my other favorite would be a gruyere.

1 cup ketchup
2/3 cup apple cider vinegar
1/2 cup brown sugar
2 1/2 tsp paprika
1 tsp cayenne pepper (more to taste, if you like a little heat)
1/4 tsp cumin
2 tbsp ground mustard
2 1/2 tbsp garlic powder
1 diced onion
salt and pepper to taste

Combine ketchup, vinegar, paprika, brown sugar, cayenne pepper, cumin, ground mustard, garlic powder in a large mixing bowl.  Whisk together until lumps are removed.  Add salt and pepper to taste.  Add diced onion.  The mixture will seem gritty, but texture will change as it cooks.

This recipe was originally intended for use in a slow cooker (I was making BBQ pulled pork).  If you’d like to use it in other cooking, you can combine all ingredients inside a medium saucepan and heat on medium high heat, stirring, until all ingredients combine.

I’m sitting at my gate at LAX waiting to board my flight to San Jose for the O’Reilly Velocity 2010 conference, the annual web performance conference. My employer, Shopzilla, Inc. is a sponsor of the event this year.  While sitting here, I started thinking about the importance of development and operations and their collaboration.

I’m looking forward to great sessions on both web performance and some operations talks this year. As engineers, it’s important for us to understand both the code and the operational aspects of the designs we propose and implement. Without this basic knowledge, when outages occur (and they will!), you will be ill-prepared to assist your operations teams in recovering from the outage. You cannot adequate plan disaster recovery, nor can you plan for scalability without basic operational knowledge of the systems you rely on.

Basically, walk a mile in your operations teams shoes, see how they fit, and see what sort of systems you’re building that they have to help support and deploy. This will change your perspective on design greatly, it will make you a better engineer, and it will benefit your organization.

At Shopzilla, engineers such as myself regularly work directly with our configuration management, network operations and systems operations teams. Without this direct engagement and collaboration, software releases, outages, and our general software development lifecycle would be quite costly.

One line of the Agile Manifesto really encompasses this idea for me:

[we have come to value] Individuals and interactions over processes and tools

See you at Velocity!