Aaron Lerch

Today, the Global Day of Coderetreat came to Indianapolis. And it was great.

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 recently came across this thing called a “coderetreat” that Corey Haines puts on. The gist is that it’s a free full-day event where a small group of dedicated-but-busy software developers can come together and work on honing the skill or art of writing software, away from the usual pressures of business.

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 coderetreatindy.eventbrite.com/

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

Hope to see you on the 3rd!!

Both at work and “for fun”, I’ve used join.me for any simple screen sharing needs. I remember the first time I used it. It was simple, and it just worked. You download a small app to share your screen, and everybody else visits a URL and gets instant in-browser viewing.

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.

Today’s post is written by my guest and fellow Indianapolis-ite, Jared Brown. I asked Jared to guest post here because he has created an application using Ruby on Rails, Heroku, and a host of other bits and services that I’ve also been using to bootstrap my new business, beautifulsavings.com which I’ll post more about in the near future. He’s done a fantastic job with Talentopoly, and he’s a developer I respect. Talentopoly is on my short-list when it comes to finding useful tidbits to expand my tech horizons. Check out my profile here.

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.

Every now and then we like to have some fun with our boss. I’ve said it before, and I’ll say it again – he’s a fun-loving guy and we all love working together. Usually when you go on vacation for a week you can expect something to happen by the time you get back. Not too long ago I returned to find my office completely filled with black plastic. I mean it took 6 large garbage cans and a mini-dumpster, tightly packed, to remove it all.

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.)

If you haven’t heard Rob Conery’s excellent new podcast This Developer’s Life then you really owe it to yourself to listen. It’s well done, and very entertaining.

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.

A year and a half ago I wrote about the three little words that are critical for a Technical Manager to understand.

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.

Thanks to everybody who came to the PowerShell talk that Matt Hester and I did at Codemash! If you haven’t heard of Codemash or attended it, it’s an extremely well-done conference in Sandusky, Ohio at a huge indoor waterpark. I brought my whole family (including in-laws) along with to enjoy a vacation. The conference itself draws in all sorts of smart people with all sorts of backgrounds, and there have been many interesting sessions, open space sessions, and conversations already. It’s worth way more than the price of admission. (WAY more.)

We tried to tailor our talk to people who have only heard of PowerShell, and people who have limited experience with it. And that worked great because I think that described the majority of people there. We got a lot of great questions, and of course we went well over our 1-hour timeslot. There’s so much to talk about! I wish we could’ve gotten into more advanced topics like the type system, etc.

For my part of the talk, I presented a few demos. You can download them and the slides below. Briefly, the demos were the following:

Using PowerShell from within applications. I extended the Family.Show example application that Vertigo Software wrote by adding “scripting support” using PowerShell. You can see a screenshot I posted here. I also wrote a simple WPF application that gets a list of processes running on the computer, only including those who have a handle count less than 200.

Simple Cmdlet. I wrote a simple Cmdlet as an example. It’s completely non-functional but I included it here for completeness.

Build Scripts with PSake. I have a simple build script with PSake that doesn’t actually build anything, but shows how to define dependencies, prerequisites, etc.

Windows Troubleshooting Platform + Reference Application. Not included in the download (because you can get the source as-is from codeplex), I briefly covered the PSSymbolStore application. It demos using the Windows Troubleshooting Platform, defining more advanced Cmdlets, and building an application on top of PowerShell at the core. You can browse (and/or download) the code here.
As a note, because of the signing requirements of the Windows Troubleshooting Framework, I will leave the code in the application but will remove any UI that invokes the Troubleshooter. It won’t work on any machine but mine unless I have a trusted certificate, which I don’t.

Download the code and slides from our presentation.

See you next year (hopefully)!

Any desktop application I write from now on will contain these two interfaces. They’re useful enough I thought I should share. Also note, with upcoming improvements in .NET 4.0 (or higher) they might be rendered moot. So far, I don’t think they are, as it’s still difficult to test the code itself that performs asynchronous operations.

First, is an abstraction around the User Interface thread, IUserInterfaceContext. This exists today in the form of SynchronizationContext, but I favor this specific interface because

1. It’s more explicit (the SynchronizationContext applies to more than just the main UI thread) whereas this is very clear what its purpose is.
2. The API is cleaner – passing a “state” is unnecessary with nested closures.
3. It’s easier to grab out of an IoC container. Because a SynchronizationContext is only specific to the context it was created in (which could be a background thread) it’s not meaningful to put a SynchronizationContext argument in your constructor. Which one do you want?

public interface IUserInterfaceContext
{
    void Execute(Action action);
    void ExecuteAndBlock(Action action);
}

Now, any component in my application can execute code on the UI thread extremely easily. I just register the implementation of IUserInterfaceContext (which does use a SynchronizationContext) when my application is started, which is on the UI thread.

The implementation could look something like this:

public class UserInterfaceContext : IUserInterfaceContext
{
    private readonly SynchronizationContext _syncContext;

    public UserInterfaceContext(SynchronizationContext syncContext)
    {

        /* Ensure the SynchronizationContext passed in is the main UI thread context */
        _syncContext = syncContext;
    }

    public void ExecuteAndBlock(Action action)
    {
        if (_syncContext != null)
        {
            _syncContext.Send(s => action(), null);
        }
        else
        {
            action();
        }
    }

    /// <inheritdoc />
    public void Execute(Action action)
    {
        if (_syncContext != null)
        {
            _syncContext.Post(s => action(), null);
        }
        else
        {
            ThreadPool.QueueUserWorkItem(s => action(), null);
        }
    }
}

Secondly, is a more generalized example of Jeremy Miller’s ICommandExecutor, which is even more generalized as the Active Object pattern. I named mine “IAsyncExecutor” because it executes any code asynchronously. The advantage with this approach is that it drastically simplifies test activities to be able abstract multithreading (to a point) and allow a test to run single threaded. That is nothing but pure win. We’ve also found that using the interface makes the code read better than using a bunch of BeginInvoke/EndInvoke’s or the ThreadPool, or an async pattern such as “void FooAsync(AsyncCallback callback, object state);

public interface IAsyncExecutor
{
    void Execute(Action action);
    void Execute(Action action, Action after, bool callbacksOnUIThread);
    void Execute(Action action, Action after, Action<Exception> error, bool callbacksOnUIThread);
}

You’ll notice that IAsyncExecutor looks a lot like IUserInterfaceContext, and in fact, it can use it under the covers if the callbacksOnUIThread is true.

Both of these are simple interfaces, with trivial implementations, but you’d be surprised how often I’ve wished I’ve had them in the past. What are some “core” interfaces/services/etc that you *must have* in your toolbox?