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:
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 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:
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.
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!