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…

Note: this tip can be applied to a lot of Linux distros, but the Ubuntu on EC2 set up is the one I’m using it on. YMMV

So I’m running some pretty stable Ubuntu instances on Amazon’s EC2. They’ve never shut down unexpectedly, and I rarely need to restart them. This means I’m rarely in the console tinkering around with software packages or worrying about software updates. I needed an easy, hands off way to make sure my instances are running the latest, greatest, and shiniest new software out there. An email every day with packages that need updated would be perfect. Enter apticron.

apticron: easy software updates

The docs on apticron are here, but here’s the gist: install apticron (sudo apt-get install apticron) and you’ll get a daily email with a list of packages that need updated. You can then install the packages yourself as you please (see below on how to automate that too), which I prefer. The daily email even contains the required upgrade commands. How easy is that?

Here’s an example email from apticron:

You’ll probably need to customize the email address that apticron sends its reports to. The file that controls that is /etc/apticron/apticron.conf.

Since the EC2 instances I launch are configured from scratch every time they’re launched, I tend to write scripts to install software like apticron. Here’s my script that installs apticron and updates the email address it uses to something more useful (automatically run at start up thanks to the wonderful runurl):

#!/bin/bash -ex
export DEBIAN_FRONTEND=noninteractive
# Installs apticron
# apticron sends an email once a day listing packages that need updated
sudo apt-get -y install apticron
echo "replacing the default /etc/apticron/apticron.conf with a configured version"
sudo touch /etc/apticron/apticron.conf
sudo rm /etc/apticron/apticron.conf
sudo touch /etc/apticron/apticron.conf
echo "EMAIL=\"me@myawesomecompany.com\"" | sudo tee -a /etc/apticron/apticron.conf

(I’ll be the first to admit that my shell scripting skills could use some improvement. Suggestions welcome, but the above will get the job done.)

Oh, and I mentioned that the updates themselves can also be automated. I’m not comfortable with this yet as I’d much rather review the updates before having them applied, but if you’re interested in automatic updates, have a look at unattended-upgrades.

Happy automating!

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!

A common requirement in webapps nowadays is to switch users between a secure and insecure connection (called protocol switching). For example, maybe your user needs to enter a password, credit card number, or some other sensitive information. Of course, you (and the user) would like that information to be sent securely, which means requiring https. Assuming you’ve already got a server set up with an SSL cert and it’s ready to serve pages over SSL, you’ll need to ensure your webapp serves all secure pages over https. Unfortunately, this isn’t always as easy as it seems. But it’s not too tough either, thanks to Grails and Spring Security.

Here are the requirements for protocol switching:

• Serve secure pages using https, regardless of the link used to get to the page (i.e. http links should be redirected to https)
• Make protocol switching transparent to the majority of your application (i.e. links starting with http:// will automatically get redirected to https:// and vice versa)
• Easy configuration of which resources must be served as secure, insecure, or either (i.e. images, CSS, and JavaScript should be loaded using the same protocol the page uses to avoid nasty browser warnings (see below))
• Security and protocol switching should be handled in a way such that browsers aren’t continuously popping up warning dialogs
• Make it work in Grails

Implementation

There are several ways to go about automatic protocol switching. One of the most popular would be to use Apache and mod_rewrite. That solution works fine, but it’s not portable between different types of servers.

The solution below is pure Java, and is portable between any servlet container. By the way, this isn’t a Grails only solution – this will work with pretty much any Java web stack – the only thing that will differ is how you wire things up. In fact I’ve used this in a regular Spring MVC app with a regular Spring configuration…but I’m only going to show the Grails way to do it today.

Here’s how to get automatic protocol switching in Grails:

• Add a filter definition to web.xml that intercepts all requests and handles the protocol switching and redirecting
• Configure which URLs require which protocol
• Test!

Adding the filter definition

Spring Security has protocol switching built in, so why reinvent the wheel? (Don’t worry, you don’t need to use any other parts of Spring Security to get protocol switching.) Spring Security refers to protocol switching as Channel Security, but don’t worry, it’s the same thing.

If your Grails app isn’t already using Spring Security, add the following dependencies into grails-app/conf/BuildConfig.groovy to have Grails download the required JARs:

grails.project.dependency.resolution = {

	// ...
	// other settings...
	// ...

	dependencies {

		// ...
		// other dependencies...
		// ...

		runtime 'org.springframework.security:spring-security-core:3.0.2.RELEASE' // http -> https redirecting
		runtime 'org.springframework.security:spring-security-web:3.0.2.RELEASE' // http -> https redirecting
	}
}

You’ll need to add a Servlet Filter to web.xml now. There are a couple of ways to do this in Grails, namely writing a plugin that can modify web.xml dynamically, or installing the Grails templates into your app and manually editing web.xml. I had planned on doing the first option (writing a plugin), but it was overkill for this, so I decided against it. I’m glad I did. Installing the Grails templates and modifying web.xml manually is painless.

Run grails install-templates from the root of your Grails project to install the web.xml template (along with a few others). Next, edit src/templates/war/web.xml and add the filter definition and mapping in the appropriate places:

<!-- START: use SSL on secure pages -->
<filter>
	<filter-name>channelProcessingFilter</filter-name>
	<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<!-- END: use SSL on secure pages -->

<!-- ... other filter definitions ... -->

<!-- START: use SSL on secure pages -->
<filter-mapping>
	<filter-name>channelProcessingFilter</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>
<!-- END: use SSL on secure pages -->

Make sure that the filter-mapping is the first filter-mapping defined in web.xml (above charEncodingFilter and sitemesh).

Now to actually define the filter. Define it as a Spring managed bean in grails-app/conf/spring/resources.groovy:

import org.springframework.security.web.util.AntUrlPathMatcher
import org.springframework.security.web.access.intercept.DefaultFilterInvocationSecurityMetadataSource
import org.springframework.security.web.access.channel.SecureChannelProcessor
import org.springframework.security.web.access.channel.InsecureChannelProcessor
import org.springframework.security.web.access.channel.ChannelProcessingFilter
import org.springframework.security.web.access.channel.ChannelDecisionManagerImpl

beans = {

	// -------------------------------------------------------------------------
	// -------------------------------------------------------------------------
	// SPRING SECURITY (CHANNEL SECURITY)
	channelDecisionManager(ChannelDecisionManagerImpl) {
		channelProcessors = [new SecureChannelProcessor(),
							new InsecureChannelProcessor()]
	}
	securityMetadataSource(DefaultFilterInvocationSecurityMetadataSource,
							new AntUrlPathMatcher(),
							ChannelConfig.getChannelConfig()) {
		stripQueryStringFromUrls = true
	}
	channelProcessingFilter(ChannelProcessingFilter) {
		channelDecisionManager = ref("channelDecisionManager")
		securityMetadataSource = ref("securityMetadataSource")
	}

}

channelProcessingFilter is the filter referenced in web.xml. It will use the channelDecisionManager to decide if the current protocol (http or https) needs to be switched to the other. And how does channelProcessingFilter know which URLs require which protocol? securityMetadataSource, of course. By default, ports 80 and 8080 are considered insecure, and 443 and 8443 are considered secure. This means that the defaults should work for both development (8080 and 8443) and production (80 and 443). If you’re curious as to the specifics of what these beans do, check their Javadocs.

Configure which URLs require which protocol

See that call above to ChannelConfig.getChannelConfig()? That’s where the configuration for URLs is stored. Create grails-app/conf/ChannelConfig.groovy:

import org.springframework.security.access.ConfigAttribute
import org.springframework.security.access.SecurityConfig
import org.springframework.security.web.access.intercept.RequestKey

class ChannelConfig {

	private ChannelConfig() {} // prevent instantiation

	static def getChannelConfig() {
		LinkedHashMap<RequestKey,java.util.Collection<ConfigAttribute>> requestMap = new LinkedHashMap<RequestKey, Collection<ConfigAttribute>>()

		// resources that can be served over http or https (typically whatever the containing page is served as)
		requestMap.put new RequestKey("/images/**"), [new SecurityConfig("ANY_CHANNEL")]
		requestMap.put new RequestKey("/css/**"), [new SecurityConfig("ANY_CHANNEL")]
		requestMap.put new RequestKey("/js/**"), [new SecurityConfig("ANY_CHANNEL")]
		requestMap.put new RequestKey("/favicon.ico"), [new SecurityConfig("ANY_CHANNEL")]

		// resources that must be served over https
		requestMap.put new RequestKey("/signup"), [new SecurityConfig("REQUIRES_SECURE_CHANNEL")]
		requestMap.put new RequestKey("/auth/**"), [new SecurityConfig("REQUIRES_SECURE_CHANNEL")]
		requestMap.put new RequestKey("/admin/**"), [new SecurityConfig("REQUIRES_SECURE_CHANNEL")]
		requestMap.put new RequestKey("/app/account/edituser"), [new SecurityConfig("REQUIRES_SECURE_CHANNEL")]

		// resources that must be served over http (basically everything else not already listed above)
		requestMap.put new RequestKey("/**"), [new SecurityConfig("REQUIRES_INSECURE_CHANNEL")] // all other pages should be served over http

		requestMap
	}
}

What’s happening here? First, there’s some horrible nastiness with the definition of the requestMap variable (gotta love generics). This is how your configuration is stored and the format securityMetadataSource expects. Each call to requestMap.put() specifies a URL or URL pattern (Apache Ant pattern style) and its corresponding channel security (i.e. http or https).

There are three options for channel security:

• ANY_CHANNEL – Serve the resource with either http or https – it doesn’t matter. This is good for images, CSS, and JavaScript, which should be served using the same protocol as the containing page.
• REQUIRES_SECURE_CHANNEL – Serve the resource using https. This is what will automatically redirect the user to https when needed.
• REQUIRES_INSECURE_CHANNEL – Serve the resource using http. You don’t want to serve your entire site over https, right?

In the configuration above, I first specified all the resources that are protocol agnostic – images, CSS, etc. Then in the next section I specified all of the resources that must be served securely. Finally, the /** specifies that anything else not already listed above will be served over plain http.

Note that order matters (hence the use of a LinkedHashMap that retains insertion order). Rules should be added from most specific to least specific. For example, if the /** rule was at the very top, it would match every resource request, which would be very bad.

If you want to see the debug output from Spring Security as it makes its decisions about whether or not a resource is being served over the right protocol, add the following to your Log4j config in grails-app/conf/Config.groovy:

log4j = {

	// ...
	// ... other logging definitions
	// ...
	debug 'org.springframework.security'

}

Testing

Since you’re testing your app with https, make sure to start Grails with the -https option:

grails run-app -https

This will automatically set up a fake SSL certificate for your app and run https on port 8443.

You should now be able to go to http://localhost:8080 and see that it is indeed served over http. If you have a sign up page like configured above, navigating to http://localhost:8080 should automatically redirect your browser to https://localhost:8443. Clicking on a link to https://localhost:8443/index should then automatically take you back to http://localhost:8080/index. You’ll also notice that resources like images, CSS, and JavaScript are served using whatever protocol the containing page uses.

Caveats

Did you know that if an HttpSession is created over an https connection that it won’t be available to the user when they go back to regular old http? This means that if you have your user log in using https, when they are redirected back to http, their session will be gone. This won’t be a problem for you if you plan to have users always use https once they’ve logged in. But some sites (flickr, for example) prefer to serve most of their pages using http for performance reasons once the user has logged in securely. There is a trick to allow https -> http session migration, but that’s a topic for a later blog post.

I’ve got a bunch of shell scripts that I use to help me with development of Every Single Shot. Some of these scripts, like starting up a new server instance or redeploying an application, can take a while (10 to 15 minutes). I’ll typically launch a script and then start working on something else, forgetting that the script is even running, only to come back an hour later and realize it completed 50 minutes ago. I needed an easy way to remind myself that scripts are running, or better yet, to alert me when the scripts finish. Specifically, I wanted something audible that would grab my attention right away, so having a shell script send an email won’t cut it in this case. Then I realized how easy OS X makes sound playback from the terminal.

There are a few ways to get your shell scripts to beep or speak. They range from utilitarian to fun, so choose wisely.

Note: I’m using these on OS X – your mileage may vary on other platforms.

Terminal beep

This should work even if you don’t have speakers installed on your system. It’s pretty basic, and often times I don’t actually hear the beep, so I don’t really recommend this option.

If you want your script to beep at you annoyingly, just type printf "\a" and hit enter. You should hear a single beep (are your speakers on?). Of course, that almost never gets my attention, so I usually wind up with something like this is my scripts: printf "\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a" That’s a little better, but we can improve and have a little fun at the same time.

Use the say command

Did you know you can open a terminal on OS X, type in say hello world! and OS X will speak back "hello world!" to you? You can’t get much simpler than that. So instead of using the printf command above, just replace it with something like say every single shot has been deployed to production

If you want to really impress those VCs you’re recruiting, I highly recommend the Trinoids or Zarvox voices (see all voices available in System Preferences -> Speech), as they definitely lend some nerd credibility to your build process. Those VCs will start throwing money at you (this is the part of the blog where you make millions) as they wonder in awe at how you were able to design such a complex system. They’ll be throwing your series B funding at you just as fast as you can say -v Trinoids system is running at peak efficiency or say -v Zarvox Skynet has become self aware. Initiating self defense subroutine

Warning: don’t use the Whisper voice unless you want to be freaked out, especially if you’re working late at night.

Say the command yourself

Or better yet, have your spouse or kid say it for you.

You can use the afplay command to play MP3s or WAVs from the command line. Just record a few messages like "production instance is running" using Audacity (free), save them as WAV or MP3 (you’ll need the lame encoder to save as MP3), store them in the same directory (or maybe a /sounds subdirectory) as your shell scripts with the same names as the scripts except with a .mp3 file extension, and then make the magic happen with afplay redeploy_to_production.mp3

If you don’t want to record your voice but want something a little more personal, you can download free sound effects (I haven’t tried but I assume you can get them in MP3 or WAV format) from Freesound.

If you have ideas on how to accomplish some of the above on Windows, Unix/Linux, or another platform, please leave a comment below!

I gotta run…it sounds like my build just finished!

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…

I didn’t mean to learn anything about customer support – I was just researching the competition.

More precisely, I was researching some indirect competitors for Every Single Shot and I found myself at SmugMug. Although I was looking to learn about the specific features of SmugMug, what I found myself really impressed with was their customer support. I mean, it was good enough that it actually jumped out at me. How often do you find a site and your first thought is, "Wow, they must have great customer support!"? Almost never.

Customer support tips

SmugMug’s approach to support made an impression on me. Here are the observations that I took away from my ‘mugging. I’ll be looking for ways to integrate these into Every Single Shot in the future.

• Be friendly – This seems like commonsense, but for some inexplicable reason businesses feel a need to sound "professional" when talking with customers. Sure, make your website and literature professional. But when you’re talking one on one with customers, be friendly. People don’t want to talk to companies, they want to talk to people. Use down to earth, conversational English. How about this from the SmugMug welcome email: "Need a real person? We’re family-run and love to hear your gushes, gripes and questions so we know what to work on next." That tone sets me at ease and lets me know that these people are here to help. Little touches like these can make all the difference. SmugMug uses this tone throughout their site to great effect.
• Humanize your support team – I really like this touch. I found pictures of the SmugMug team in a couple of different places: the 5 minute getting started video and, my favorite, the super hero pictures shown when sending in a support request.
• Let customers know you enjoy helping them (and actually mean it) – This has to do with the general attitude taken toward customers and support. If you respect and value your customers, it will show. If not, customers will soon become ex-customers. I felt the SmugMug team was genuinely concerned about my experience on their site, and because of this I subconsciously started thinking "I like these guys".
• Let customers feel like part of a group – Watch the 5 minute getting started video. This is how intro videos should be done. It’s narrated by one of SmugMug’s owners in a very casual tone and it has photos of the entire SmugMug team. It made me feel like I knew these people a little, like I was part of their group.
• Set appropriate expectations – This one’s great too, and it’s easily overlooked. When you open a support request, SmugMug lets you know what time it is in "SmugMug land". This helps set appropriate expectations for when you’ll receive a response. "It’s 4:27am SmugMug time and our heros are snoozing…you’ll hear from them by early morning." They’re asleep – fair enough, I can live with that. They’re people, after all (see above points).
• Automate – Here’s another neat touch when sending in a support request: the user’s browser and OS are automatically detected and added to their email. My support query to them automatically had the following added: "Hey Support Heroes, I’m using Chrome on Mac OS." Auto-generating details like this (instead of asking the users to tell them to you, which is way less efficient) can eliminate an entire cycle of the support process, which results in quicker support and happier users. No more asking users what web browser they’re using only to have them reply "Dell" or "purple".
• Provide help documents – Another seemingly obvious one, but a lot of small companies don’t provide any sort of help documents for their product. I see this a lot in small webapps released by one or two people (usually programmers, because we all know programmers hate writing documentation – I’m guilty of this – SendAlong suffered from it). This is a fundamental first step that a lot of companies drop the ball on. SmugMug has a lot of nice help docs. They even go so far as to explain how to write some simple CSS rules.
• Make help easy to access – If you spend a lot of time making your help system awesome, make sure you do it justice by making it easy to find. Link to it on every page, and for added bonus points, make the links smart – don’t just dump them at the help homepage, show them topics related to the page they came from.
• Include a FAQ in your help – You should have the top 5 to 10 questions asked right there at the top of your help homepage. 80% of your users are going to need one of those questions answered, so why not make it easy on them? Bonus: now that you’ve got a FAQ, go through it and see if you can make any of the answers to the questions obsolete by making your product easier to use.
• Let them know if you’re special – It doesn’t hurt to let your users know that you’re better than average. In my welcome email I found out that "80% of customers who have purchased SmugMug accounts in the last 5 years are with us today. We hope you’ll join the family." I immediately thought "Hmmmmm…they must be really good at what they do." And I’m sure that’s exactly what they wanted me to think.

All of this, and I never actually contacted their support team! Based on what I found on SmugMug’s site, I can only assume that their team would live up to my expectations. And that, in a nutshell, is great customer support.

Being nice is good (duh!)

With SendAlong, I violated all of the ideas above with one exception: I was friendly when talking with customers. And I could tell that customers appreciated it. I slowly started to see a pattern in how customers communicated with me.

• Their first email would usually be neutral or somewhat passive aggresive/demanding. "Why doesn’t it have feature X? I need this now."
• I always tried to be as friendly and personable as possible in my replies. "Hey, thanks for using SendAlong! That’s a great question, and…"
• After extended the "there’s a human on the other end and he’s nice" olive branch, the next customer reply was usually pretty friendly. "Ahh, that makes sense. Thanks for letting me know, Jon!"

Come to think of it, maybe those first customer emails would have been a lot friendlier if SendAlong had done a better job in earning users trust before they emailed by taking note of some of the tips above…

What tips can you give for providing great customer service? I’d love to add some of your ideas to the list above and into Every Single Shot as well.

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.

Someone just posted a question over on the Business of Software forum asking for recommendations on books and blogs related to sales. Since I’ve been doing a lot of reading on marketing (I know, marketing isn’t sales, but they go hand in hand), I figured I’d post my reading list so that others might benefit.

Here are the marketing books I’ve read recently:

• Inbound Marketing
• Duct Tape Marketing
• The 22 Immutable Laws of Branding (I recently wrote a summary of this book)

Here are a few books that I haven’t read yet but look good:

• The 22 Immutable Laws of Marketing
• The New Rules of Marketing and PR
• Word of Mouth Marketing
• Crossing the Chasm

Happy reading!

And no, the above are not affiliate links.

What about you? Read any good books (marketing/sales related or otherwise) lately? Leave a quick comment below and share them with everybody.

Starting a business is a lot of work, especially when you’re doing it all yourself. I need all the hours I can get in a day, so I came up with a handy little practice that’s really increased my productivity. Yes, I’d even say it’s doubled it (hmmm…does that mean it was abnormally low to begin with?). Your mileage may vary, of course, but if you follow this advice and stick to it, it’s just about impossible to not see your productivity go up.

The Trick

So what is it? What is the miracle of productivity tips that has naught been divined hence?

Simple: when you sit down to work, set a timer. Work your butt off until that timer buzzes, then take a break. Lather, rinse, repeat until it’s time to go home. Let me explain.

I find I can concentrate steadily for about 2 hours at a time. So I set the timer for 2 hours. Once the 2 hours is up, I take a 15 minute break (using the timer), during which time I’m checking blogs, twitter, Facebook, or most importantly – playing with the dog. Lunch time is a little different – I typically take 45 minutes to an hour. I get in four quality 2-hour work sessions every day with little to no distraction. This, in my opinion, is awesome.

How it Works

Why does this work so well? For me, it’s the assurance of knowing I’ll be able to goof off soon enough. That way, I feel compelled to concentrate for 2 hours because I know I’ll be immediately rewarded at the end of it. But during the breaks, anything goes, and since I’ve just worked for 2 hours, I don’t feel guilty goofing off a bit.

Timers to Try

If you want to give this a try, I can recommend a few timers. If you’ve got an iPhone or iPod touch, just use the Timer app that comes with it (make sure you turn the volume up so you can hear the timer go off). If you run OS X, give a timer dashboard widget a try. There are two that I like: Stop It! (my fav) and Tea Timer. If you run Windows, uhhhh…do you own an egg timer?

Bonus

Bonus tip: write your todo’s for the day down. Tackle the tough creative ones in the morning (especially the ones you’re dreading). You’ll feel a since of accomplishment and be motivated to do the boring stuff. Do the administrative stuff and email after lunch.

Bonus bonus tip: don’t do personal email at work!

What do you think? Do you have any easy productivity tips of your own you’d like to share? Comment below!

UPDATE Looking for more marketing books? Here’s a list of good ones that I’ve read recently (or am planning to read).

I just read The 22 Immutable Laws of Branding and was happy that I set aside a couple of hours to do so.

I’m currently working on a new product and a lot of the material was relevant to me. I’ve read a few books on marketing, but nothing specifically on branding. This book has whet my appetite for more.

Here are my notes:

• Generate publicity, not advertising. Best way to get publicity? Announce a new category, not a new product.
• Claim your product is a "leader", not "better". All products claim they are better, but you can’t argue with leader.
• Own a word. Like "luxury".
• Perception of quality is built by a narrowly focused brand, a high price, and a better name.
• Promote the category, not the brand, and be first in the category so that your brand is associated with the category.
• Expand a brand, reduce its power. Contract a brand, increase its power.
• Welcome other brands in order to build the category.
• Generic brand name = bad
• Select a brand color opposite of that of your main competitor’s.
• Consistency is key. Never change your brand, ever.
• What’s a brand? A proper noun that can be used in place of a word.

UPDATE There’s an excellent article on the Grails website that walks through installing and using STS with Grails support. I recommend you use that guide instead of the one below.

STS 2.2.0 was released today with support for Groovy and Grails development. If you’re new to STS, the route to getting everything working might not be clear. The following walks you through installing STS, the Groovy plugin, and finally, the Grails plugin.

1. First download and install STS. STS comes bundled with a full Eclipse installation, so you don’t need to download Eclipse first.
2. Now for the Groovy plugin (required for Grails). Open STS, and go to Help -> Install New Software. Add the Groovy Codehaus site: http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.5/. Now install the Groovy plugin from the site you just added. I installed 2 plugins actually, the Groovy Compilers and Groovy-Eclipse plugin options. Restart STS when the install is complete.
3. Now you can install the Grails plugin. In STS, go to Help -> Install New Software again. This time choose the Spring Source Update Site for Eclipse 3.5. Under Extensions / STS, choose the SpringSource Tool Suite Grails Support. Install and restart STS.
4. Create a new Grails project by going to the new project wizard and selecting Grails Project under the Groovy folder.
5. The project creation screen will say that you don’t have a Grails installation configured. Just click the Configure Grails Installations… link, then Add, then Browse, and navigate to <YOUR_STS_INSTALL_DIR>/grails-<version> and choose that directory. Then give it a name and click OK.
6. Give the project a name and click OK to create a new Grails project. Give Eclipse a few seconds to finish creating your Grails project and you should be ready to go.

That’s as far as I’ve gotten so far. If you’ve got any tips or advice, please feel free to leave a comment. Here’s to hoping that the Groovy and Grails plugins are high quality!