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

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.

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.

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!

I’ve been trying to get a PDF to embed inside of a Web page for most of the day, but I’ve been having problems with most browsers. In IE, the area where the PDF should be is just a blank white box. In Safari, a dialog pops up asking me if I’d like to save the file. Firefox occasionally crashes. Of course Opera works just fine:).

Here’s some HTML that will not work correctly in most browsers:

<p><embed src="/controller/gen/streampdf.html" width="800" height="400"></embed></p>

(Note that in my case I have a server side script that is dynamically generating and streaming the PDF to the browser.)

Here’s the HTML that will work:

<p><embed src="/controller/gen/streampdf.pdf" width="800" height="400"></embed></p>

If you look closely, I changed the extension on the URL to “pdf”. I’m still streaming the exact same bytes with the same response headers, however, having a “.pdf” at the end of the URL apparently makes the browsers happy.

That would have been nice to have known this morning!

I just stumbled across CyTunes.org, a music download site that gives every penny it earns to cancer research. All of the music on the site is original and can’t be found anywere else (take that, iTunes!). Here’s a write up about the inspriational story behind the site.By the way, I came across CyTunes after looking over the agenda for tonight’s (1/27/09) Entrepreneur & Social Entrepreneur Meetup. It looks pretty interesting so I think I’ll go. Hopefully see you there!

This is a quick shout out to the good folks at EAPPS for doing a great job (their support) and providing a bang up service (their hosting).

I use EAPPS for hosting this domain (juliesoft.com) and SendAlong. So far, I only have good things to say about them. They’re really fast with answering support issues (I’ve only had a few, and it’s usually me screwing something up and them cheerfully fixing it for me). Their platform is awesome: it’s virtual, so upgrading/downgrading from one plan to another is only a matter of a few clicks and there are typically no application restarts needed.

Besides their support (which, like I said, is excellent), my favorite part is their servers are managed – that means full root access, even though it’s typically not needed since installing most new applications or upgrades like Tomcat, Apache, etc. is done by going into the Web based control panel and clicking Upgrade – poof, upgrade complete.

FYI, other than being one of their customers, I have no relationship with EAPPS, and no, I’m not getting paid to write this review:).

I had my first experience with coworking last week. All in all, it was very positive and I will definitely be going back for more.

I went to Carrboro Creative Coworking (CCC), which is located in Carrboro in a little office park, not far from Franklin Street. Brian (the owner) has done a great job at creating a wonderful work atmosphere. I’m not going to go into details, but suffice it to say that it’s probably nicer than any regular office I’ve ever worked in. The iPod sound docks and Wii’s in the rooms don’t hurt:).

Rates are good, although I don’t really have anything to compare them against. A ten day pass will run you $100. That’s not bad if you think about it – compare $10 a day to the cost of trying to work in a Panera or Starbucks for the afternoon. After a few cups of coffee and spotty wireless, you’ll be ready to pay for something like CCC.

Brian’s also setting up a lot of activities in the afterhours – like hack fests, trainings, etc.

Oh, and the people that I met were great! If I remember all of their names…Sean, Fred, Gary, and Brian – they were all developers, and all were very enjoyable to talk to. I think a couple might even come to the Triangle microISV Group meetup on the 21st:).

All in all, I can highly recommend Carrboro Creative Coworking. Maybe I’ll see you there sometime…

Skybus is officially closed – as of, well, right now (thanks for the advance notice). I bet they wanted to do this April 1st but were afraid that no one would have taken it seriously.

The official announcement:

Skybus Airlines will cease all operations effective Saturday, April 5.

Skybus struggled to overcome the combination of rising jet fuel costs and a slowing economic environment. These two issues proved to be insurmountable for a new carrier.

We deeply regret the impact this decision will have on our employees and their families, customers, vendors, suppliers, airport officials and others in the cities in which we have operated. Our financial condition is such that our Board of Directors felt it had no choice but to cease operations.

Passengers holding reservations for Skybus flights scheduled to depart on or after Saturday, April 5, 2008 should contact their credit card companies to arrange to apply for a refund. More information for customers and others will be made available on the Skybus web site (www.skybus.com) as it becomes available.

All flights for Friday, April 4 will be completed. Passengers holding reservations on flights for Friday, April 4 should check in for their flight at a Skybus kiosk at the airport instead of the Skybus website.

*sigh* Guess it’s time to call Visa to see if we can get some of our money back.

I just had a blast catching up on RSS feeds over lunch – except I couldn’t tell what news was real and what was fake.

Here are some of my favorites from today, and a few from the past. The funniest ones are in bold.

• SQL on Rails (you must watch the screencast)
• The Commentator – automatically generate code comments
• PairOn pair programming chair
• Luminotes new feature: Import -> Internet
• Stuff White People Like bought by Target
• Jesus found in Java .class file
• Gmail Custom Time
• Amazon’s DCI (Dog Computer Interface)
• PerfectBingoTablePlanMaker released

Andy Glover has a great post about not only continuous integration (the act of having your code base automatically built and tested whenever you commit any changes to it), but continuous production – having your code able to be deployed to production basically at the drop of a hat without manual intervention at any time.

He also lists a lot of great tools that help toward this goal. Some of my favorites that he mentions are: Ant, Junit (hey, Junit finally got a new web site!), DbUnit, FindBugs, Checkstyle, and Cobertura.

He does mention some caveats – he says he wouldn’t expect the production environment to be automatically updated on a code check in, only that it’s good to have that ability (production changes should probably always be initiated manually).

Definitely something to strive for!

Who would have thought that a picture frame could ever be infected with a virus?

We got a very nice frame as a gift this Christmas, and it turns out it’s not feeling so well.

Go figure. Does this mean I need to by McAfee Virus Scan Photoframe Edition?

Here’s some pretty big news:
* Sun just acquired MySQL – about 1 billion bucks – maybe now Sun will change its stock ticker to MYSQL?
* Oracle just acquired BEA – 8.5 billion bucks

Quick update:

I’ve moved my personal blog from SendAlong’s domain over to the Juliesoft.com domain. The blog located at sendalong.com/blog is now the “official” SendAlong blog – it will cover product updates and such for SendAlong.

As long as you’re seeing this post in your RSS reader, you’re already subscribed to the new address for Jon’s blog and don’t need to do anything to resubscribe (thank you, FeedBurner). However, feel free to subscribe to the official SendAlong blog (http://feeds.feedburner.com/Sendalong) to track its release progress.

You are dismissed.