Hey there! I have been BUSY since the release of Every Single Shot. Here’s a quick recap just to keep you up to date. I can’t stay long – I’ve got more stuff (marketing, coding, brainstorming, and emailing w/customers) to do!!

First off, I’ve been adding a ton of user requests to ESS. All in all, I’ve completed/fixed over 100 new features/bugs in the last month and a half. And that’s only counting what I bothered to enter into my issue tracker. That number would probably be somewhere in the four to five hundred range if I were to examine my notepads.

ESS is profitable and humming along nicely. My customers have been keeping me rather busy with feature requests. I’ve been really pleased at how many of the requests they make are for GOOD features – things that everyone will benefit from having.

Goals for this month include increasing ESS’s traffic, increasing the conversion rate (I’m shooting for 2% conversion to a paid plan), and streamlining things for new users to make it super simple to figure out what they need to do to get all those wedding photos they’d otherwise miss.

Here’s a few screenshots from ESS to wrap up with.

Until next time!

Holla! I just flipped the switch on Every Single Shot 1.0! If it’s on Twitter it must be a fact:

This has been the culmination of a lot of work! Oh sure, it’s still a little rough around the edges for now, but isn’t that part of the charm? I’ve got big, big plans for the future of ESS, and I’m super excited that I’ve gotten this far. I don’t know how else to say it: it’s been a lot of work. Worth it? Definitely!

Technical stuff

What’s ESS built on? What technologies does it use? What methodologies did I use to build it?

The tech

Grails

First and foremost, I used Grails for pretty much everything. I was a Spring MVC veteran for a long time, and let me tell you, I knew my way around that stack inside and out. There was nothing I couldn’t accomplish with it, albeit with a bit of elbow grease usually. I decided to move to Grails for this application b/c it was so similar to Spring MVC in so many ways (it’s built on top of Spring MVC for one), but different where it really counted (i.e. it made the simple stuff really simple, and the tough stuff, well, less tough). I have no regrets and I don’t see myself ever going back.

Grails report card: A++

Amazon EC2 and S3

Can I get another holla! I love love love working on EC2 and S3. Let me put it this way: have you ever used a technology or toolset that just works? I mean, one that always does exactly what it’s supposed to without fail? Well, I hadn’t either until I used EC2 and S3. They are so damn reliable, so rock solid, so well documented and supported. Basically, they’re awesome. I know there are other services out there with more bells and whistles, and I’ll be honest, I had to build a lot of infrastructure in EC2 myself that I wish I hadn’t needed to, but AWS’s stability and predictability more than make up for it. For 10 cents an hour I get a dedicated (virtual) server with lots of RAM, a huge disk, and some crazy fast connectivity. Scripting set up and configuration of servers couldn’t be much easier than with good ol’ runurl. Management of servers is super easy with the command line tools. Rawk on.

Amazon AWS report card: A++

Other tech

Here are some of the other technologies that various parts of Every Single Shot use in no particular order: apt (this is one reason that Linux rocks), Apache 2, apticron, awstools, ec2-consistent-snapshot (Eric Hammond is the man when it comes to EC2 and Ubuntu), Groovy, ImageMagick, Java, Jquery, MySQL, postfix, Subversion (I know, I know…), and Tomcat. All in all you can see there’s not a lot of glamour tools in there, just a bunch of stuff that works.

Methodologies

Gosh, I wish I could be more specific, but I pretty much just had a big list of issues, loosely divided into versions, organized in Jira (I got my Jira license for $10). That’s it. No agile, no scrum, no scragile or whatever. Just cranked through issues.

Here’s something interesting: I used to do a lot of TDD (test driven development). I’ve abandoned that lately in favor of writing tests…never. Actually, since I’ve started with Grails I’ve written a lot fewer tests that I used to with Spring MVC. Part of this is due to the fact that there’s a lot less that needs testing in Grails, and part of it is due to the fact that tests in Grails can be a little tough to write (there’s a lot of meta programming magic happening, and I miss Java autocomplete), and a lot of the tests run kinda slow (the entire container has to start up a lot of the time). Enough about testing though (let the flame wars begin).

I could go on…

Believe me, I have lots more to talk about, lots more I want to say about the 1.0 release of Every Single Shot. But that’ll have to wait. I need to get back to work! 2.0 is calling me…

I’ve just been doing a bit of refactoring on the Every Single Shot sign up page. I started with something that resembled the idea of mad-libs form design:

(click thumbnail for full size image)

I’ve since decided to try amore traditional form layout:

(click thumbnail for full size image)

Do you have a preference? Vote below and let me know what you think!

Total earnings as of March 18th, 2010: $0

In my last ChangeLog I said things were moving slowly – much slower than I would have hoped for. That’s finally changed! Development has really picked up over the last couple of weeks and I’ve been churning out new features and fixing bugs like nobody’s business.

Just ship it!

This week I did just that. On Sunday, March 14th, I released the very first beta of Every Single Shot. Hooray! The feature set is basic at this point, and there’s still a lot missing, but it’s up and running and out there for everyone to see and request a beta account.

It’s always fun wrapping up the first big release of a project. There are so many loose ends to tie up that go completely unnoticed until the last minute. Then it seems like there are 50 little tweaks that need to be made before it’s ready to ship. The ESS beta release was no exception.

On the technical side, I am extremely happy to see how well Amazon’s EC2 is working out. Aside from the ease with which sites can be scaled out, my favorite thing about EC2 might be the fact that starting up a new instance of a server takes it back to a blank slate. This saved me a lot of time and stress when I was trying to install an SSL certificate. I think I trashed 3 or 4 servers before getting everything scripted correctly. After I was done, I just restarted the server, and poof! – I had a fresh server up and running, with no evidence of all of the experimentation I had to do to get the SSL cert installed correctly.

Enough with the technical.

To all those hopeful entrepreneurs out there, coding away at night after their full time job on their pet project – just ship it! Get your project out there, let people see it, and don’t be afraid of their reactions. If you really believe in what you’re working on you have nothing to fear. Negative responses to your work are not negative responses to you – they’re valuable feedback that you can use to make your project better! Don’t assume that everyone will love what you’ve done, or that it will make sense to anyone. Just get it out there and then iterate like crazy. Of course, you need to figure out what it is people do or don’t like about your project, which leads me to…

Usability testing…or Why haven’t I done this before?

Steve Krug is not a rocket surgeon, just a genius. If you don’t know what I’m talking about, go and find out, I’ll wait. If you are a software developer that cares even a little about the user’s experience (and not just your own), go buy both of his books (Don’t Make Me Think! and Rocket Surgery Made Easy) and read them cover to cover.

I did my first usability test yesterday and it went great, and here’s why: I didn’t take it personally. If you have trouble with negative comments about your work, go read Steve’s books. Hopefully they’ll give you some perspective to help you understand that those negative comments can and should be applied positively to your project.

Anyway, back to my first usability test. It really opened my eyes. I’ve got that classic programmer tunnel vision, having worked on ESS day and night for months. Seeing how someone else works through the app was enlightening – I came away with a full page of action items. The wonderful thing about these todos is that they came from someone NOT ME. Someone not invested on the project. Someone with a fresh perspective. They came from a real (potential) user.

My advice: usability testing – do it early, do it often.

If you want to try it yourself, have a look around Steve’s site. Especially check out the checklists and the example video of a usability test he conducted. And then get ready to work on all the action items you collect from your tests.

Up next…

Every Single Shot’s future is pretty clear right now:

• Add features
• Run usability tests
• Repeat

It doesn’t need to be any more complicated than that…

Total earnings as of February 11th, 2010: $0

This week was a lot slower than I had hoped it would be. I don’t think I made enough progress to be able to launch a beta (remember to sign up) on February 15th (4 days from now!) – but I’m still shooting for it.

Safe, secure photo storage

I’ve been working on hooking up Every Single Shot to Amazon’s S3 (Simple Storage Service). This is where all of the photos for Every Single Shot will be stored. According to Amazon, I’m using S3 because it’s secure, reliable, fault tolerant, flexible, competitively priced, and most importantly has something to do with "cloud". I use it because it’s easy to work with, stores data redundantly, cheap, and easy to get started with.

I’m using JetS3t (of course the JetS3t site is completely hosted in S3) to work with S3 from Grails. I love it and highly recommend it. That’s all I have to say about that.

I’ve been able to reuse a lot of code that I developed for SendAlong, which was a huge blessing and time saver (let alone a validation (at least in my mind) that I can write some reusable code – there’s a first time for everything).

If you build it…the build will fail

My continuous integration server is great, but it can be a time suck sometimes (when it rains, it pours). I’d much rather be working on features for Every Single Shot than futzing around with trying to fix an ArrayIndexOutOfBoundsException, but hey, you gotta keep the builds happy.

Once I release ESS and get it somewhat stable I’d love to build in some kind of continuous deployment to my development/release process. Having a build server is the first step towards that, I guess.

Next week’s goals

There’s only one goal I’m focusing on now:

• Release the Every Single Shot beta on February 15th (stretch)

Wish me luck. See you next week!

Total earnings as of February 1, 2010: $0

I’ve been busy the last few weeks working on many of the things it takes to turn Every Single Shot from an idea into an actual product.

The last few weeks of work have been really, really fun. Not only have I been coding Every Single Shot, I’ve also worked on branding and setting up hosting. Every day is a different job and I’m really digging the variety. Here’s what I’ve been working on lately…

Development

Where would a web app be without code, right? I’ve spent a fair amount of time in my IDE hacking away to get a basic app up and running (ESS is written in Groovy and Grails). Here’s what I’ve got so far:

• Public facing marketing site: home page, tour, sign up, contact us
• App pages: photo browser, photo uploader, account settings, and a few others

I’ve still got lots of functionality and features to add in – lots. Security is going to be a big one coming up. Another is integration with Amazon’s S3 (more on that below). Oh, and I also need to remember to add in actual features that users care about as well.

Here’s the current LOC (Lines of Code) count for ESS (from running grails stats):

+----------------------+-------+-------+
| Name                 | Files |  LOC  |
+----------------------+-------+-------+
| Controllers          |    14 |   803 |
| Domain Classes       |    15 |   266 |
| Jobs                 |     2 |    59 |
| Services             |     3 |   105 |
| Tag Libraries        |     4 |   205 |
| Groovy Helpers       |     3 |   116 |
| Java Helpers         |     3 |    81 |
| Unit Tests           |    29 |   374 |
| Integration Tests    |     1 |    40 |
+----------------------+-------+-------+
| Totals               |    74 |  2049 |
+----------------------+-------+-------+

ESS’s code base is surprisingly small right now – that’s part of the beauty of Grails.

Branding with a graphic designer

This marks the first time that I’ve paid someone to help me with my business, and I couldn’t be happier with the job Christine did (and is still doing). And it was fun. Really, really fun. To see an idea go from floating around in my head to something real was a very rewarding experience. I’m so glad I decided to pony up the money and pay a professional to help with the branding and UI – I can guarantee that any design I would have come up with would have scared away any potential customers. Given my target market (young fiancés), I knew the design for ESS needed to look good. Mission accomplished!

Here’s the final logo for ESS that Christine created:

See if you can figure out why I didn’t want to do the graphic design myself from the example below.

I needed to put up one page at www.everysingleshot.com just to collect email addresses for my mailing list. It needed to be simple, quick, and get the job done. Here’s my take (click images for full size screenshots):

And here’s the version I made after some help from Christine:

But Christine didn’t just whip up some nice graphics, she also did great work with helping me define and focus ESS’s brand and marketing message. As a developer first and a marketer last, I can’t understate how important it was to have a creative branding person helping me with this aspect of ESS. I’ve been doing a lot of reading on branding and marketing and I recognize their importance in creating a successful product, so I’m really thankful that Christine was able to help me so much with them.

Contact me (jon at juliesoft dot com) if you’re interested in having Christine do some work for you (I don’t want to plaster her email address on here) – I’ll forward your contact info to her.

Hosting on Amazon’s cloud

I used a combination of cloud (Amazon’s EC2) and traditional (eApps) hosting platforms for SendAlong. It worked well enough, but I didn’t like having to manage the two different environments. Plus, the apps on the different platforms needed to talk to each other, and getting them to communicate reliably all the time was kind of difficult.

This time I decided that I wanted to keep the hosting platform homogenous. I also decided that there were at least a couple of different “cloud” services that ESS was going to use such as storage (like Amazon’s S3) and a CDN (like Amazon’s CloudFront). I researched a few different cloud hosting providers including Amazon EC2, Slicehost, Rackspace, and Joyent. I also found a great performance comparison of some cloud hosting providers.

Amazon and Joyent were the front runners, but I decided to go with Amazon mainly because they’re stable, they’ve been around the block a few times, they’ve got good documentation, they’re fairly easy to use, the nice integration between all of their services…the list goes on. I’m not saying Amazon’s services are right for everyone, but they suit my needs for Every Single Shot really well.

After choosing a hosting provider, I needed to get a server set up. That’s where the real fun came in. (If you didn’t know I was a geek, the last two sentences are all the proof you need.)

I’ve dabbled in Linux and the bulk of my command line experience has been in MS-DOS. I’ve had a Mac for the last year and have gotten a little more comfortable with using a real command line, but all of that experience was nothing when stacked up to what I learned in the last two weeks while trying to build out a server with all the goodies ESS would need on EC2. I wouldn’t have said that I was a command line n00b before two weeks ago, but now I think I can back it up. Where have pipes, grep, and shell scripts been all of my life?

While I was working on configuring an Amazon EC2 AMI to my liking (Apache, Tomcat, MySQL, etc.) I came across a fantastic EC2 resource. If you’re running Ubuntu on EC2, or are trying to figure out what OS to use for your EC2 set up, have a long look at Eric Hammond’s alestic site. Not only has Eric provided some top notch Ubuntu server AMIs, but the Canonical team (the people behind Ubuntu) has really embraced Amazon EC2 and provides several “official” Ubuntu AMIs to get started with. I feel completely comfortable using these things in production – it’s obvious that the Canonical team has put in a lot of work on their Ubuntu AMIs.

The coolest thing about these Ubuntu images (I’m using ami-1515f67c on an EC2 small instance, btw) is that you don’t have to rebundle your own AMI on top of them (if you’ve worked with EC2 in the past you know what I’m talking about, and if you haven’t, then just trust me that this is a good thing). This is where I learned about the wonderful world of apt-get, which handles installing a lot of common software for you. Having used Windows most of my life, I’m still not used to this, but package managers are one of the best things about the Linux platform. Need to install Apache2? sudo apt-get install apache2. Need to install Tomcat6? sudo apt-get install tomcat6. Of course you’ll need to customize the installs sometimes, but that’s just a matter of writing a shell script.

Since there’s no need to rebundle your own AMI, there must be a way to configure the base AMI easily, right? Indeed, and of course Eric Hammond has already taken care of that for me. With literally one command, I can launch an EC2 instance (for test or prod), attach a static IP address to it, attach a persistent EBS volume to it (for storing MySQL data), install every software package I need (Apache, Tomcat, MySQL, etc), check out ESS from source control and build it, and have it up in running in about 5 to 10 minutes. This means that when I’m ready to test a new version of ESS, I can issue a command to do all of the above, plus run through all of my automated tests. As long as testing takes me less than 60 minutes, total cost out of pocket is 10 cents.

Yes, I’ve heard that Amazon’s EC2 isn’t as fast as some of its competitors. I’m willing to live with that for now, especially considering that I can run a new server with 10 times the RAM and CPU power with a single command if I need to.

(I’m going to write another post about EC2 and the other Amazon web services in the future that will have lots more helpful information – so remember to subscribe to my blog if you haven’t already.)

Timeline and goals

I need to get a beta out soon. I’ve been developing in a vacuum for too long. My goal is for a February 15th beta release, then rapid iterations based on user feedback (sign up if you want to help), and then a 1.0 release on April 1st. That should give ESS some time to get a bit of marketing traction before the heavy wedding season starts in May.

I’ve got big plans for ESS, so I’ve set some stretch goals.

• Goal #1: 10% of income will go straight to charitable causes (that’s pre-tax, pre-expense income)
• Goal #2: 100 new paying customers per month by July 1st, 2010

Do you have a suggestion on how I can improve these goals? Leave a comment and help me out!

See you next week!

The past

I’ve been blogging here since December, 2006. In that time, I’ve covered lots of random topics, including building my first product. I haven’t (yet) blogged about shutting it down, but that topic is on the short list to cover soon. The last three years have been good, but things are about to change.

During the 3+ years I’ve been blogging I’ve never had a plan for the blog. If something caught my attention, I wrote about it. There was no such thing as “off topic”, because there was also no such thing as “on topic”. Although it’s been fun for me to write the blog, the quality of the content has suffered for want of editorial direction.

That’s changing as of now, and here’s why.

The present

I’m working full time on a new web app. Every Single Shot isn’t a side project. Among other things, it’s my full time job. Some might call this kind of set up a microISV, some might call it a start up, some might even call it a mom and pop joint (ok, no one would ever call it that). I realize that I’m very, very lucky to have the luxury to be able to work on my business – my dream – full time. I also realize that this is just the kind of thing that a lot of other hackers dream about on a daily basis while they’re stuck at their dead end jobs. This is why I’ll be sharing the details of my adventures from now on.

The future

I’ll be chronicling my journey on a weekly basis, talking about what I’ve been working on, ideas I’ve had, and changes that have happened. That’s why I’ve renamed the blog to ChangeLog. (Actually, I’m not renaming it, I’m naming it. It hasn’t had a name until now because it hasn’t had any direction until now.) Just as a stereotypical changelog is to code, this blog is to me and my business: a place to record changes and happenings of interest.

It will be more than just a ChangeLog, though. I’ll still be talking about Groovy / Grails (Grails is hands down the best web framework out there IMO, and I’ll have words with anyone who says otherwise). I’ll be talking about small business, marketing (lots of marketing), branding, site optimization and testing, e-commerce…the list goes on. But instead of talking about this or that with no context, I’ll filter future posts through the lens of my business and its products. Less noise, more insight – that’s what I’m shooting for.

Since this post is meant to be a turning point in my blogging journey, I thought I’d finish by linking to one blog that has influenced me greatly up to this point. This blog is one of my absolute favorites – the kind I where I read every post from start to finish, regardless of content, because invariably I learn something. You should be reading this blog.

Balsamiq blog – READ THIS BLOG!

(I use Google Reader to manage all of my blog subscriptions. If you’re not using an RSS reader to keep updated on blogs, I suggest you check out Reader.)

If you haven’t already, please consider subscribing to the ChangeLog RSS feed and/or following me on Twitter (@jonchase).

Do you prefer blogs that have a specific focus, or those that are a bit more random? What do you think of the direction I’m going to take my blog? Leave a comment below and let me know.

Cocoon picture courtesy of Greyson Orlando via Wikimedia.