Ranting and raving about anything I feel like complaining about.

What I've Been Doing...

by

SYILogo

It’s been a long nine-months and I am excited to be able to talk about what I’ve been working on for the first time. I am working with a small team of people to build a new set of products. But unlike what I’ve been doing in the past, this new set of products is not for developers...

The target of my new project is people who like tattoos (and other body modifications). I found that there wasn’t a good way to share tattoo pictures on the web and on Facebook. That’s what I am tackling. By the end of the year I will be launching this new web application to help people do just that.

This new venture is going for full reach of users. Unlike a typical line-of-business application, this application has to reach the users where they need us. That means we are targeting a wide berth of platforms:

  • Desktop Website
  • Mobile Website
  • Facebook Application
  • Mobile Apps (iOS, Android and WP7)

Our first milestone (to be delivered soon) will be the desktop web version of the product. When the project was started, we had an important decision to make: what platform to choose. We spent some time digging into Ruby, PHP and MVC3 for the web platform. We also spent some time with NoSQL databases to see if they were a good fit for what we needed. At the end of the day my familiarity with the Microsoft stack left me there. Is it perfect, no…it is very usable? Yes.

The Server

The goal of the web platform was simply to get out of our way. On the server, we went for a pretty standard set of tools:

  • ASP.NET MVC3
  • Ninject for Dependency Injection
  • SQL Server 2008 for Relational Storage
  • Entity Framework Code First for Schema Design/Data Access
  • ELMAH and Glimpse for Error Handling
  • AutoMapper for mapping models to entities
  • Squishit for JavaScript/CSS Packaging
  • Amazon S3 for Blog Storage
  • AppHarbor for Cloud Hosting
  • Facebook SDK for Facebook Integration

Some of you may be thinking about our decision to use the Entity Framework for a public facing website where speed and load may be issues. Our goal here was to use the power of Entity Framework’s Code First functionality to help us build our data schema quickly. Remember, we’re a small team so that while ceremony could help us as we grow, we did made some key decisions to speed up development knowing we would be able to refactor it later on. For example, even though we’re using Code First, we kept the data shapes and data access separated from the code so that we could refactor that later (side note: we’ve prototyped going to Dapper as our object builder and we can do it with little change to the code).

An interesting lesson we’ve learned is that since we’ve got a lot of experience with .NET, the server code ended up being 20-30% of the work. The balance of the work was in the client-side development. Now if you’ve been following me the last 1/2 decade, you may be wondering if Silverlight has a story here in the client-side development. In our case, no. Remember, we’re building a set of web sites that have to reach as many people as possible so Silverlight would simply get in the way of that goal. Like I’ve said before, HTML is for sites; Silverlight is for apps.

The Client

On the web side, we’re building HTML5/JavaScript pages. We’ve used quite a few frameworks. These include:

Managing the Project

Our team is a small, but distributed team of people in different time zones. In order to work with the project in a simple way, we needed several things: source control, project management and bug tracking. The tools for the job for us are:

These tools worked well together to help us plan and build our project. What I found interesting is that these tools were all fairly low (or no) cost to get started. FogBugz and BitBucket both have free tiers to help you get started. AgileZen is free for open source projects and I think only $9/month for up to three projects. So the cost of getting started is simply tiny. This was a big help for us.

We’re still very small so there are some missing pieces but for the most part the project has come together with the tools and frameworks staying out of our way.

For me personally, development would have been faster if I had deeper knowledge of the client stack, but it’s been a great way to learn all these great ways of building client-side, rich web pages.

If you have or want tattoos (or piercings or other body modifications) and want to help us beta test the project, head over to the teaser page and join the list of beta testers:

Let me know what you think!

 
 

Comments

Gravatar Best of luck with your venture!
Ian Walker (Posted Wednesday, November 30, 2011)
Gravatar Hi Shawn

Great to see all the technology choices listed here that you have chosen.

I was curious what your development preference was for the iOS and Android mobile apps, are you looking at the Xamarin frameworks or Objective-C and Java ?

Gavin

Gavin (Posted Wednesday, November 30, 2011)
Gravatar Hi Shawn!

The set of development tools you listed above are fantastic and I used most of them in my daily development like [ASP.NET MVC3, EF 4.1, SQL Server 2008 Express R2, Ninject, jQuery and UI [I also like Kendo UI], Modernizr, I also used 'Twitter Bootstarp'] and of course TortoiseHG.

Thanks!
Shahnawaz Khan
http://www.shahnawazk.com
Shahnawaz Khan (Posted Wednesday, November 30, 2011)
Gravatar Gavin,

We haven't decided yet. My instinct since the apps should be pretty straightforward is to go native; but we haven't discounted PhoneGap (e.g. Callback) yet. I like the Xamarian tools but since it isn't a single code-base solution, I don't think that C# helps us a lot. We're probably getting dedicated resources for each of the platforms.
Shawn Wildermuth (Posted Wednesday, November 30, 2011)
Gravatar Thanks for sharing, it's interesting to see your views, moving back into some HTML development after doing so much in the Silverlight space for quite some time (as I have too).

Which IDE(s) are you using?
Justin (Posted Wednesday, November 30, 2011)
Gravatar best of luck, interesting choice of applications.
geordie (Posted Thursday, December 01, 2011)
Gravatar You got over 20 things you gotta update/check for updates, re-test and hope everything plays nice. And for what? Shaving .01 ms off a web page that takes .2 - .5 seconds to load. Are you really going to see that much of a difference that people are going to avoid your website because of load time?
Dan (Posted Tuesday, December 06, 2011)
Gravatar Hi Shawn,

I saw you used Ninject. I hear quite a lot of it the last year. I am used to Unity, but I am now starting with a new application (ASP.NET MVC 3) within a new company with no history on this, so I am reading about different IoC's. If you know Unity, can you tell me why I should start Ninject?

BTW: What Telerik is promising with Kendo Mobile is interesting for the mobile development.
Jaap Mosselman (Posted Thursday, December 08, 2011)
Gravatar Justin, I am using VS to edit my JS. I've looked at others, but right now I am just living without intellisense.
Shawn Wildermuth (Posted Thursday, December 08, 2011)
Gravatar Dan,

I assume you mean EF vs. Dapper. If it is .02 seconds, who cares. If it becomes bigger it becomes a problem. We'll see if we need to move there, but I wanted the flexibility. And yes, consumers do care about load time.
Shawn Wildermuth (Posted Thursday, December 08, 2011)
Gravatar Jaap,

I think of IoC containers as interchangable. We went with Ninject because of the way it can inject into Controllers made sense, but in the big picture having IoC is much more important to us than which one we choose.
Shawn Wildermuth (Posted Thursday, December 08, 2011)
Gravatar I meant the whole thing. I'm probably in the minority on this, but why not just do web forms with basic WCF. You're not going to need that many service calls. Turn off the view state and use some jquery if you need it.

The bottle neck would the size of the images. There's no getting around that. Say you're using telerik components and web forms, the amount of extra java script compared to the picture sizes wouldn't make a difference. Plus it's going to save you a lot of time and maintenance.

With internet and data access speeds only going up, is it wise to care so much about compacting your javascript and css?


Dan (Posted Friday, December 09, 2011)
Gravatar Dan,

MVC for me has nothing to do with performance, but has everything to do with speed of development...especially when you're skinning the site after much of the development is complete. With WebForms it's just too hard to do well.

The reason for the javascript and css compacting is not actually compacting, but packaging. The trick is that by merging all the css/javascript into individual packages, the caching will happen once, instead of re-downloading or downing lots of smaller parts.

At the end of the day, development of this app was easier because of the tooling. That's why we chose it.
Shawn Wildermuth (Posted Saturday, December 10, 2011)
Gravatar Ok I see.

ASP.NET 4.5 does have bundling though:

http://weblogs.asp.net/scottgu/archive/2011/11/27/new-bundling-and-minification-support-asp-net-4-5-series.aspx

What are your thoughts on this compared to the above?
Dan (Posted Saturday, December 10, 2011)
Gravatar Dan,

No opinion...probably similar to how the one I used works. It's not rocket surgery. Since 4.5 isn't released yet, we aren't using it.
Shawn Wildermuth (Posted Saturday, December 10, 2011)

Add a Comment

*
*
*