I’m talking about a new venture that my friends @dhosei, @bobmattax, @thisispeter, and I launched a few days ago: http://whyiloveyou.co/

http://whyiloveyou.co/

A long while back, David came to me with an idea. He wanted to be able to queue up and send text messages (SMS) to his wife with short reasons why he loves her. Awww, what a thoughtful guy! But he, like most of us, can be forgetful and he didn’t want to have to remember to send the message every day. It’s not that he doesn’t love her, or the messages he sends aren’t sincere, he can just be forgetful sometimes – which is why his idea resonated with me. I’m really forgetful. And what’s the solution to our communal forgetfulness?

Automation.

Computers never forget. They’re like really lightweight and less-gassy elephants.

Always always automate those repeated tasks! Leon Bambrick has a great “Should I automate it?” calculator – http://nimbletext.com/automate.

David wanted something he could queue up messages in and then let them stream out slowly over time, once per day. Like Buffer, but for sweet sweet love.

I like buffering sweet sweet love. I was in. David and I worked on the initial version of the site, but with my schedule I wasn’t able to get it to a point where we were comfortable putting it out there for public use. In the meantime though, we used it, and it worked great – our wives were happy! Then a few months ago, we talked with Bob and Peter (aka Remora Studio) about joining us and helping us finish off an initial version and they were in too. Perhaps they’re as forgetful as us. Whether they’re forgetful or not (they don’t seem to be) they are a pretty amazing couple of guys. The code & design that went into the site was very impressive – I had a blast just coming along for the ride and watching and learning.

But anyway, the point is that now it’s live – http://whyiloveyou.co/. You can queue up short SMS or email messages to send to your loved one throughout the year! There’s a 30-day free trial for everyone, so really there’s no reason not to give it a shot. And it’s dirt cheap anyway. I’d personally love to hear your feedback, so please sign up and email me at aaronlerch at gmail with any thoughts or feedback.

And of course, here’s the disclaimer:

I first heard the quote from @jsnover: “To ship is to choose.” What a great quote; it’s so true. And it’s especially true for http://whyiloveyou.co/. We’ve got a laundry list of features to implement, and more importantly, improvements to make. We want to walk down that road with our users. The first users to sign up for a service are special people. They care, they understand, and they are engaged. We love those folks. We want those folks. (I, selfishly, want YOU to be one of those folks.)

For example, right now our sign-up process can be confusing. “When does my free trial start? I signed up, but it says I need to subscribe?” Yep, we hear you – we have some work to do there, and we’re doing it. We need folks to participate with us in this early process.

And the best part of all: Valentine’s Day is only 2 days away – so it’s the perfect time to sign up and try out the site. Don’t give Hallmark any more of your money. Spend the equivalent of one card per month with us, and send something awesome every single day.

I get an idea for what usually is a stupid, silly thing, and I feel compelled to work on it. This past weekend I had another “episode” and the result is breaktheicefor.me. (Coming up with a domain name is hard! Why do I even try anymore. My next project will live at [latest git commit id].com – 4654bab.com)

I read about the beertext.us guys, and their super-simple-yet-useful SMS-based app they put together that tells you about the beer you’re drinking. For some reason that I don’t recall I instantly thought about making something similar but for conversation starters. I was probably alone at the moment, wishing I was with a group of people, feeling sorry for myself.

Doing some quick searching showed:

• No existing SMS-based conversation starter services (that I could find)
• A few iPhone and Android apps, some free, come that cost $
• No public datasets to pull from

I ignored the last two bullet points, focused on the first one, and said “Sweet. The world needs this. And it’s up to me to build it.”

Step 1 – Get a number

In the past, this would’ve been the hardest part of the app. Today, with services like Twilio it becomes the easiest.

Sign in to Twilio, purchase a number, and point it to your URL that handles voice or SMS. Bam. Done.

Step 2 – Spin up a Sinatra app on Heroku

For small apps, or APIs, I freakin’ love Sinatra. Add Heroku to the mix and you’ve got the closest thing to heaven a someone like me with only 30 minutes to spare can get. If you don’t know about them, google it, plenty of info out there.

Step 3 – Hook up SMS

I can’t emphasize to you how easy Twilio makes things. Seriously, they are one of my canonical references for a developer-friendly API. When you get an SMS, you can reply simply by returning a 200 response with Content-Type of text/plain, and the body is the response message. You can get fancier with it (using XML to send multiple response messages, etc.) but SERIOUSLY. That’s IT. When’s the last time an API was that easy to integrate with?

And no, I don’t work for Twilio, I don’t get paid by them, in fact I work for a different telephony company so perhaps this is blasphemy. (Different market segments, different targets and audiences, so no big deal. I hope.)

Step 4 – Stand up a single-page website

Again, Sinatra, makin’ things easy for me. Add something like Twitter’s Bootstrap (or whatever other grid/typography framework you want), Google’s Web Fonts (for the love, people, at least customize bootstrap a little), a little jQuery form submit hooked into SendGrid email sending (database? What database?) and #! (shebang! I always thought that was a great way to start a file) you’ve got a simple landing page.

And that’s it! It’s taken me longer to write this post than it took for me to do steps 1-4. SERIOUSLY.

Then I published my app and made tons of cash from it.

Oh wait, except it has no actual content. Yeah, there’s that. Well, I said I’ll deal with it later — I did say that, didn’t I? — and now’s that time.

Step 5 – Content

When I was doing my initial quick-and-dirty research, I came across Chatoms, an app by the good folks at Iconoclast Labs. They even have a RubyMotion vs. PhoneGap smack-down that creates… you guessed it… a mobile conversation stater app. And they have a curated dataset of ice breaker/conversation starters!

I reached out to them to talk about options, and they graciously agreed to give me their dataset. WOW. Talk about classy.

While we were communicating back and forth I remembered what my friend Brandon Corbin told me once about his experiments with Amazon’s Mechanical Turk. In a nutshell, Mechanical Turk is “artificial artificial intelligence” – it’s an interface (and an API) for automating tasks that are performed by humans.

So I signed up, funded my account with a few bucks, and set about creating a simple form people could use to submit an “Ice Breaker”. Here’s what I created, basically:

Pretty simple.

With Mechanical Turk, you can choose options regarding who’s allowed to perform the work (they have to have N-approved tasks in the past, etc. etc.) and you can choose how much you’ll pay per answer. I ran several tests with small numbers of people (2-5) at various price points and “quality” restrictions to see what gave me good bang for the buck, and I settled on 15 cents per answer. I threw a few dozen bucks at it, and ended up with a pretty nice sample of ice breakers.

Some were duds, for example some people answered my example questions. (Um, yeah, not so much. “yes, no, no, yes, yes”) but the nice thing about Mechanical Turk is that I get to accept or reject answers, and I only pay for what I accept.

So, now, I had some additional content – sweeeet.

Step 6 – Profit!

Okay, there is no profit to this. In fact, it costs me every time someone sends or receives a text message through this. But that’s a price I’m willing to pay, at least for the short term. If it becomes popular, which I pretty much guarantee it will, because the world needs it, then I’ll explore options. Until then, I hope you enjoy it.

Interestingly, I actually had a few opportunities to use it after I made it, and it actually. worked. Conversations were started. People talked and engaged. I grew hair back over my bald spot, and my runaway dog came back home. I was shocked. Of course I fully expected this.

13 people chose to spend the whole day on Saturday, December 3rd, in the “common area” at Interactive Intelligence honing their skillz.

By the way, I want to extend a huge thanks to Interactive Intelligence for providing the space, a catered lunch, and some breakfast! It was awesome!

This was my first coderetreat, not to mention the first one I’ve hosted and facilitated. I was trusting Corey Haines’ experience when it came to the format, and I was very pleased with how it went. We did 6 45-minute sessions, each time pairing up and implementing Conway’s Game of Life. People used a wide variety of languages throughout the day: ruby, python, C#, java, javascript, even some C++.

Many of the people were new to practices like pairing, and TDD. We also got to explore a lot of design ideas and look at different ways to approach a problem. I really enjoyed being able to throw in various constraints during each session and then to see how it affected the approaches or designs that people came up with.

Overall, I got very positive feedback – it really seemed like a valuable day for everybody, for a wide variety of reasons. By far, people said that the pairing and the ping/pong TDD were the most enlightening aspects of the day. It was great to have a structured and guided environment for people to explore those concepts that can otherwise be difficult to dig into ad-hoc.

Other things people learned or enjoyed were designing with the Tell, Don’t Ask approach, and getting exposed to some new languages.

Overall I think it was a huge success. Or at least, I was very pleased with how it went and how it seemed to affect people. People grew as software developers today! That’s awesome in and of itself.

Thanks to all who attended!!

I thought it sounded awesome. I have yet to attend a developer event that was comprised primarily of the attendees coding, with the possible exception of some codemash sessions.

Then I saw something about a “Global Day of Coderetreat” — coderetreats organized to occur all around the world on the same day: December 3rd.

And I noticed that Indianapolis was not on the list.

That simply won’t do.

So I’m happy to announce that Indianapolis is going to participate in the Global Day of Coderetreat! My employer Interactive Intelligence (I contend it’s the best place to work in the midwest) has agreed to sponsor the entire event by providing a great space to meet and a free catered lunch! Check out these pics of our offices and in-house cafe on facebook.

You’re probably asking,

“Okay, so what’s a coderetreat anyway?”

I’ll talk about what ours is on December 3rd. I’ve opened it up to 26 people. (I said it was a small group…) You can see more information on the structure here, but the gist is that there is some meet & greet time at the start, an intro, then 5 to 6 sessions (with a long lunch in the middle) of dividing up into pairs and tackling a problem (same problem all day). After each session, we delete all our code, switch pairs, and start over again, but working to grow our designs, and explore alternatives and practices like TDD. This is language agnostic, we just try to make sure each pair knows the same language (regardless of proficiency level.) Then there’s a wrap-up and whoever wants heads out for a beer.

And did I mention it’s all free?

Sound good to you?

Yes? Me too!

See below for ticket info. I want to point out something first, though. With only 26 slots, I want to avoid it filling up quickly with people who won’t show up. So I’m charging $5 to attend. If you attend, you will get a full refund, or you can opt to donate your $5 to the Interactive Intelligence Foundation – a great not-for-profit that helps at-risk youth, especially with technology education.

You can get a ticket at http://coderetreatindy.eventbrite.com/

Any questions? Tweet to me at @aaronlerch or email me at aaronlerch at gmail

Hope to see you on the 3rd!!

Let me emphasize the key points in case they were missed. It was simple, and it just worked.

The 19th century French novelist George Sand once said, “Simplicity is the most difficult thing to secure in this world; it is the last limit of experience and the last effort of genius.”

This is clearly a gentleman who coded against the MSHTML library. I would say I was kidding, except that I’m pretty sure MSHTML was around in the 1800s.

When I saw that Twilio announced that they released an in-browser soft phone and started a 2-week contest around it, I decided to create a simple in-browser ad-hoc conference call tool. My mind immediately went to join.me’s simplicity and just-work-edness. Imitation is the sincerest form of flattery, and with talkasaur.us I am seriously flattering join.me.

There have been a few situations in recent memory where having a tool like talkasaur.us would have been useful:

1. Scott Hanselman wanted to record a group conference call for an episode of his podcast. I think they went through at least 3-5 different services before settling on something, and if I recall correctly (and I probably don’t) even that service wasn’t very satisfactory.
2. Every group video chat I’ve done (which has not been many, admittedly) has ended up requiring me to a) put on clothes, and b) create an account or sign in with an existing account like twitter or facebook. When authentication gets added to the mix, simplicity decreases. Here’s a chart to illustrate, because data doesn’t lie:
   

So thus I decided to pick a horrible time, personally, to spend time on this idea of talkasaur.us – the name of which was conceived at 3AM in a state of delirium and because I’ve always been fond of any “*saur.us” domain for some reason.

The result is “Iteration Zero” – enough to submit my app to the Twilio contest, and test out the waters of interest. It works like this. The homepage gives you two choices: start or join.

When you start or join a conference, you get a view that shows you a few things:

• The current status (“connected”, “disconnected”, etc.)
• Sharing options – you need to invite people to your call, otherwise you could save yourself the time and just talk to the mirror.
• Actions – currently only muting and leaving the conference call (watch this space, though!)
• Participants – a realtime list, see who’s on the call, change your name, etc.

When you leave the conference, you get a single call to action: start a new conference again.

Bam. That’s it! Of course I can already think of features to add, and the list keeps on growing:

• Moderation tools: first person in gets the ability to mute others, kick them out, etc.
• Additional information: because the participant list is updated in realtime, we can display more information such as whether they are muted or not, and (if Twilio can implement my suggestion) even see who is currently speaking.
• Call recording/archiving
• External number integration – not excited about this, but it’s a possibility.
• etc

The whole thing about my idea is that it isn’t brand new, but it’s applying the discipline of keeping things simple and coming out with a better product.

And, because this is my tech blog, I’ll just do a quick list of the technologies I built this site on. Ruby, sinatra, heroku, mongodb (via mongoid), jquery, and of course, twilio. Let me just say, for a simple app like this, these tools were a joy to use, even if I did spend the majority of the time fighting battles with them.

Jared Brown is the founder of Talentopoly.com, a community for programmers, designers, and IT professionals staying current by sharing the best of what they discover online.

I wanted to take a minute to give a glimpse into the platform Talentopoly is built on. A lot of this may not be familiar to non-Rails developers.

The site is hosted on Heroku. I use it for staging as well as production. To say Heroku makes deployment easy would be an understatement. To deploy Talentopoly all it takes is a quick “git push heroku” or “git push heroku-staging”. To setup your project is also one command.

The production server consists of two dynos (Heroku’s term for a virtual server unit) for a cost of $36/mo. This setup can handle dozens of concurrent users per minute. The site regularly peaks at 50 users and doesn’t break a sweat.

Add-ons are Heroku’s way of making it easier to integrate with other services. Often times no configuration is necessary when turning on an add-on.

My staging server mirrors production. It uses the same add-ons. The WebSolr folks were nice enough to setup a free staging instance. So the staging server is free. I populate staging with production data via Heroku’s handy PostgreSQL commands.

Heroku uses nginx as the http server acting as a cache store and reverse proxy. nginx is written in C and super fast. Behind nginx are a load-balanced cluster of Thin servers (modified Mongrel servers) running the application stack. Heroku is constantly monitoring the health of the dynes and will spin up new ones to replace hung processes if necessary.

Other than Heroku non of these things are exclusive to Ruby on Rails developers. The following services help make my life easy.

Search is provided by WebSolr and the excellent Solr search engine. Search is configured on a per-model basis. Only a few lines of code are responsible for making the models searchable. It provides geospatial search as well as full text search. Unlike Sphinx Solr doesn’t rely on fragment indexes. Everything is handled transparently. When new records are added or destroyed the index is updated. WebSolr costs $20/mo. for 75k documents.

The database is a shared PostgreSQL instance on Heroku. It performs well under load. There are other options such as Amazon’s RDS but for simplicity of deployment I have stuck with Heroku’s native solution.

SendGrid handles all the outgoing email. It’s accomplished via a SMTP gateway, which saved time over using their API.

S3 handles user uploaded image assets via the awesome paperclip gem. Paperclip re-sizes and stores the images on S3.

Scribd is used to store and convert uploaded resumes. This is why Talentopoly can accept and properly display so many different file formats.

New Relic is also provided as an add-on. It’s invaluable for investigating bottlenecks. It provides a breakdown of the request stack tracing it through the database.

Chartbeat provides real-time analytics and alerts. I can see how many concurrent users I have on the site, which is useful if it’s seeming slow. Google Analytics gives me the full stats to analyze.

I haven’t had a strong need to implement an in-memory key-value store like Mongo, Memcached, or Redis yet. Though hopefully the increasing traffic on the site makes that a priority soon.

There are other great services, gems, and plug-ins I could talk about but hopefully that gives you a sense for how Talentopoly is built and what it’s like to build a Ruby on Rails app on Heroku.

We recently played yet another prank on my boss. This one probably takes the cake, and it was a ton of fun to pull off. We actually geeked out a bit and we had two hidden cameras, which were automatically recording any motion they saw, as well as live streaming their feeds via ustream.tv. I wrote an app that monitored the filesystem and when it detected a new motion-based recording, it tweeted a frame of the motion. I just subscribed to mobile notifications and I got an SMS with a link to a JPG file every time it detected movement over the weekend. Pretty easy monitoring system!

Check out the video of the prank. His reaction was priceless!
We love to work hard and have a lot of fun at the same time. If this sounds like the kind of software company you’d like to work for, we’re hiring! (Nobody asked me to post that, in case you wondered.)

Either way, Rob inspired me.

Inspired me to, just like Rob, emulate a podcast that has influenced and touched me.

Naturally, or more likely unnaturally, I chose The Writer’s Almanac which I typically hear on NPR (National Public Radio, the public radio station in the United States). It seems to always be on when I’m driving to work and it’s like a seeing a train wreck, you don’t want to watch but you just can’t look away. Few things bore me more than listening to the voice of Garrison Keillor reading, but I can’t seem to stop listening and turn it off.

The Writer’s Almanac has a short but repeatable format: a few minutes of “on this day in [xyz]” followed by the reading of a poem, followed by credits, and capped with “Be well, do good work, and keep in touch.” If you’ve never heard it, give the most recent episode a listen before you keep reading, just so you’re familiar with the format. It only takes a few minutes.

So I dutifully copied that format but gave it a computing focus. Hope you enjoy.

I give you, dear innocent reader, The Developer’s Almanac.

Code well, do open source work, and tweet frequently.

Disclaimer: A long time ago, in a galaxy far away, I helped coordinate the Indy Code Camp. We gave away a few donated copies of NDepend as prizes, and while setting that up, Patrick Smacchia offered me a license if I’d be willing to write about my NDepend experiences on my blog. Having heard about NDepend in the past, I happily took him up on it – making sure it was clear that I would write about my experience regardless of whether they were positive or negative. So this is a “sponsored” post, in that I received an NDepend license, but the license donation did not purchase any of the content of this post.

An astute reader will probably look at the date that I helped with the Indy Code Camp and compare it to the date of this post, and figure out that it was about two years ago that Patrick asked me to evaluate NDepend. And I’m not so happy to say that in those two years, I really didn’t use it. But recently I have more time available to me for doing specifically this sort of thing.

I think Scott Hanselman summed up the initial NDepend experience quite well.

Like PowerShell, the first 10 minutes of NDepend is the hardest. It has to click first. There’s the whole "what the hell am I looking at" process, often followed by the "screw this" declaration, followed by a quick uninstallation and a sense of "what happened."

I’m not going to do a comprehensive overview like Scott or others have done – at this point I just can’t do that as I’m still in kind of the “what the hell is this” phase. But it’s slowly beginning to click. For me, two things that click and help me continue on and work to understand this application.

One, I know I need the information NDepend can give me. I may not understand it all immediately, but I’ve been deep in the code of some applications long enough to see (and write) the good, the bad, and the ugly. I need ways to root out the bad and ugly, without having to dive into all the code in-depth. I also need metrics to help show that the good really is good. Especially when you’re working on a team of several people, each with varying opinions and each who writes their own flavor of code. Just because I don’t like someone else’s code doesn’t mean it’s bad code. Metrics can help me separate my aesthetic or organizational concerns from real problems or smells. And then I can make them write it my way anyway.

Two, and more fun than the first is NDepend’s Code Query Language or CQL. In my opinion, this is an easy “hook” to get someone to look closer at NDepend and get past that 10-minute hump. I have seen a developer’s face literally light up when they hear what CQL can do, especially if they’ve done any work with a database and SQL in the past.

NDepend’s website has the best documentation of CQL, even if the docs feel overwhelming at first. There’s also some information about embedding CQL into your code as in-line constraints that NDepend can enforce during your build, though as others have mentioned it’s not a practical solution.

Of immediate interest to me, due to something I’m doing at work, is catching breaking API changes that might accidentally happen during a maintenance release. Patrick covers how to do this here. But as an example, let’s analyze the breaking API changes in StructureMap between version 2.5.4 and 2.6.1.

Note: I got confused at first, because I put both versions of StructureMap into the same directory and renamed the files to include the version number. NDepend didn’t like this and flagged every single method as removed and added. I’m not sure what I did wrong, but it took a bit to figure out, and it sucks for situations where a version number (or a name change) might cause an assembly name not to match, even though it’s functionally the same.

The first thing to do is select the two assemblies to compare – here I’m choosing StructureMap 2.5.4 on the left, and 2.6.1 on the right.

After the NDepend project has been created, I can press ALT+Q to bring up the CQL editor, and enter the following query:

WARN IF Count > 0 IN SELECT METHODS WHERE
IsInOlderBuild AND IsPublic AND (VisibilityWasChanged OR WasRemoved)

It reads pretty well, especially if you’re familiar with SQL. Literally it’s “warn me if methods exist that were in the older build, were public, and the visibility has changed or the method was removed.”

You can see below, 5 methods were “removed” from StructureMap’s public API – in this case, they are literally removed (and not just made internal or private). That means that upgrading from 2.5.4 to 2.6.1 could mean you have to change or recompile your code.

Likewise you can see that no public types were removed, thus no breaking change exists and the CQL query isn’t flagged as a warning.

This is some powerful stuff, and as I begin to incorporate it more and more into my daily workflow I’ll post about how I’m using it.

The newest version supports a console runner, a stand-alone GUI, and full integration into Visual Studio 2005, 2008, and 2010. For small projects that can exist within a single Visual Studio solution, it’s perfect. For larger projects that span multiple solutions, NDepend still allows you to analyze a set of assemblies, the UI is just embedded inside Visual Studio – and the integration is pretty usable for me so far.

Know your limits.

As I look back over the past year and a half, plus the years leading up to it, I am more and more convinced that this is an extremely important concept to put into practice.

Over the past year+, my team has almost doubled in size (plus an intern or two in the summers). We are all working on different features, but on the same (or similar) products, so we weren’t as “scattered” as we were before I split us up. However, juggling as many balls as we have, being an effective technical manager was becoming more and more difficult for me. Most specifically my organizational skills and managing priorities were lacking. I’ve been working hard to manage the team, manage priorities, and keep my technical chops because like at many software companies that started as a small start-up, the technical manager is implicitly expected to manage and be the technical expert.

Eventually I realized that this lifestyle is ultimately unsustainable, and I couldn’t see a light at the end of the tunnel. That’s bad for me, bad for my family, and bad for the company. I needed to recognize that I was moving well outside my limits. I had to make a decision: stop being a technical expert, and just be a true technical manager, or, stop being a manager and remain as a technical expert.

The decision wasn’t hard… I enjoy code way too much.

Ahhh, this feels so much better! Now I can focus on things that have long interested me but I just plain haven’t had time for. Like, for example, digging deep into NDepend to help keep that 10,000 foot view of our products that I couldn’t do before.