Permalink | Leave a comment  »

We sometimes have to get creative when remote pair programming. For example, how do I help debug a problematic Android phone when I'm 2,500 miles away from it? The answer: my pair holds it up to the camera for me to see!

Permalink | Leave a comment  »

Visit http://pivotallabs.com/talks/143-remote-pair-programming-people-and-technology to see a video recording of my Remote Pair Programming presentation.

Permalink | Leave a comment  »

Here is a video screencast of my Remote Pair Programming presentation.

Permalink | Leave a comment  »

On 07/06/2011 I was honored to give a presentation at the Atlanta Software Craftsmanship meetup. here are the slides. I'm going narrate a screencast with these slides soon.

Permalink | Leave a comment  »

Brevity courtesy of my iPhone.

Permalink | Leave a comment  »

Many people have asked me "What does it look like when you remote pair program?"  Well, here you go!

Permalink | Leave a comment  »

On 02/10/2011 I had the pleasure to speaking to a 3rd-year Computer Science class at Southern Polytechnic State University about working remotely.  Here are the slides.

Permalink | Leave a comment  »

Welcome! Interested in remote pair programming? I blog about it at http://remotepairprogramming.com. Read this article there -- "Remote Pair Programming Technology" on remotepairprogramming.com

Since moving to Atlanta, GA six months ago I have been remote pair programming full time with fellow Pivotal Labs developers in San Francisco. Here I describe our setup, alternatives, and why we use the technologies we do.  I'll follow up this post with another outlining the pros and cons of remote pair programming itself.

TL;DR: I Use 'Screen Sharing.app' + Skype

While this has more moving parts and might require more support than other solutions, using Apple's built in Screen Sharing.app (aka SSA) combined with Skype has proved to be the best remote paring technology combination.

Basic Tech

Everyone uses a Mac. Specifically, at the time of this writing, top-of-the-line 27" iMacs. Screen size does matter, but not because more screen real estate is better: if the host screen size is larger than the remote screen, then the remote developer will have to scale their screen in some way, if possible.

Screen Sharing: 'Screen Sharing.app' vs iChat

The two primary options for screen sharing on a Mac are "Screen Sharing.app" (SSA) or iChat. Yes, there are many VNC solutions out there, but these two are the default choices. While iChat's ease of setup and integrated voice chat is compelling, it has fatal flaws.

Pros: SSA

• Stability: SSA has never crashed. Not once. SSA is so stable that it actually stays connected while the host computer reboots.
• Speed: With a fast internet connection, SSA's refresh rate and overall "snappiness" beats other VNC apps.
• CMD + Tab (⌘⇥): As a programmer, I'm constantly switching applications. When I type ⌘⇥ to switch apps, that command runs against the host machine exactly as I expect.
• Screen Options: SSA has many view and quality options. You can choose to scale your window to match the screen size of the host machine, or not. If the host machine has multiple monitors, you can choose to see both or only one at a time. Other screen sharing apps do not have this much flexibility.

Cons: SSA

• No Full Screen: Like most screen sharing apps, SSA runs in a window and does not have a true full screen mode. This means that your SSA session will have scrollbars if the host machine's monitor is the same size or larger than yours.
• Firewalls: The remote machine will likely need VPN access or some other hole in the destination firewall to connect to a host machine.

iChat: Compelling but Fatally Flawed

For a while I was very excited about iChat because it offers an all-in-one (minus video) solution to remote pairing and the lowest barrier to entry. Despite this advantage, infuriating "buffering", lack of stability, and unexplained incompatibilities proved intolerable.

Pros: iChat:

• Easy Setup: Have a Mac? Have a GMail account? You're in business! Add your GMail (or AIM, Mac.com, Jabber) account to iChat, have your remote pair do the same, add them as a Buddy, and right-click to "Share My Screen".
• Voice + Screen: While lacking video, iChat does combine voice chat and screen sharing.
• What Firewall?: I've used this to punch through many firewalls without a VPN connection.
• Full Screen: As the remote computer, the screen sharing takes over your entire screen. If your screen size is the same as the host computer, it's just like you're on that computer (if you ignore the mini version of your own screen in the corner). ⌘⇥ works!

Cons: iChat:

• Freezing, Buffering: All screen sharing sessions have some amount of lag. iChat has an additional anti-feature of buffering: even though you can move the mouse and the cursor is blinking, your clicks and typing are being buffered (not ignored) and eventually come flowing in. Of course, this happens at the most inopportune time: you're working out an idea, coding away, when suddenly, in the middle of a complex piece of logic, everything stops. Inevitably you keep going, praying that you haven't miss-typed, and wait as the last 30 seconds of invisible work appears. Correct your mistakes (quickly!) and repeat. This interruption of flow makes iChat an unacceptable long term solution.
• Stability: Frequent crashes.
• Poisonous Combinations: Sometimes two machines simply will not screen share. Those machines screen share with others, but not with each other. In addition, two machines will cease to screen share with each other after a successfully doing so for weeks. Once this happens, you're screwed. Forever. See code crash log below
• Window Scaling, Multiple Monitors: iChat wants to make sure that the remote machines can see all of the host machine's monitors. If you are on a 15" MacBook Pro and your host has a 27" iMac with a 19" secondary monitor, iChat will scale your screen sharing session so you see two teeny-tiny screens. Host will likely need to disconnect that other monitor.
• No Video Chat: As I said, iChat takes over your screen, obscuring other running applications, such as a video chat.

Note: If iChat crashes with the following error, you're likely doomed.

...

Video Conference Error Report: 411.336209 @/SourceCache/VideoConference/VideoConference-415.22/SIP/SIP.c:2917 type=4 (900A002D/65) [SIPConnectIPPort failed] []

...

Other Screen Sharing Solutions

Meh. They work, but not as well. Check out TeamViewer (no firewall issues!), Chicken, and JollyFastVNC. All lack ⌘⇥ support.

Voice and Video: Skype vs. iChat, GChat

Pros: Skype

• Voice Quality: better voice quality vs. iChat or GChat. 
• Stability: This is relative, as all video chat clients crash on a somewhat regular basis. Here Skype wins on grounds of crashing not as often and its tolerance of configuration changes: switching sound inputs and outputs while calls are in progress. My pair and host in the office switches inputs often: built-in speakers and mic when I need to talk to the group, headset speakers/mic when pairing.

Cons: Skype

• Stand Alone App: As a stand long application, it's one more moving part to manage vs. iChat's integrated screen sharing and voice.
• Version 5: The recent version 5 beta upgrade in incredibly unstable and lacks flexibility: window sizes are too large, video gets out of sync. Hopefully they will fix these issues soon.

IChat, GChat, etc.

They are okay. Voice quality is acceptable but not great. Same with video. Sometimes they handle input/output switching gracefully, sometimes they don't.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

For the last couple of years 40withegg has been running @nakagima’s aintablog Rails-based Tumblr clone software. I owe Pat a huge debt of gratitude for writing aintablog and for integrating my pull requests. I made quite a few tweaks to aintablog, and saw diminishing returns maintaining it. In addition, my hosting service, hostingrails.com, doubled their price. I decided to let someone else do the hard work of hosting my blog and maintaining servers, so I’ve migrated to Posterous.com. While copy-and-pasting all of my content into posterous by hand sounded like a barrel of fun, I decided to automate this effort.

Challenge: My Data

I needed to extract my articles and comments out of aintablog’s MySQL database and import them into posterous. Luckily, posterous has an API and other smart people have written Ruby libraries against that API. I used the sequel gem to connect to my copy of my aintablog database, pull out my articles and comments, and twoism’s postly gem to post those entities to posterous.

Data Dump

First I needed to dump my remote database to a file so I could pull it locally.

# on 40withegg.com
 $ mysqldump -uuser -p aintablog_prod > dump.sql
 $ gzip dump.sql # => dump.sql.gz

Next, I pulled that data dump locally and imported into a database on my machine.

# local machine
 $ scp myuser@40withegg.com:~/dump.sql.gz .
 $ gunzip dump.sql.gz

Then I created the database locally.

$ mysql -uroot -p 
 mysql> create database 40withegg_dev;
 mysql> source dump.sql

Now I had a local database with all my data.

Ruby Setup

It was clear that the easiest way to write this migration program was in Ruby thanks to the supporting libraries I mentioned before. The gist later in this post required the following gems:

gem install sequel
 gem install postly
 gem install rails # only needed active support...
 gem install mysql -- --with-mysql-dir=/usr/local/mysql

Migration Script

The migration script/gist listed here is mostly user feedback and retry logic.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

#!ruby

require "rubygems"
require "postly"
require "sequel"
require "rails" # needed activesupport

DB = Sequel.connect("mysql://root:password@localhost/40withegg_dev")
Postly.config = "config.yml" # see https://github.com/twoism/postly
@site = Postly::Site.find.select{|site|site.name == '40withegg'}.first

def migrate
  articles = DB[:posts].filter(:type => "Article")
  comments = DB[:comments]
  limit = 0
  retries = []
  puts articles.count
    
  articles.map do |article| 
    begin 
      puts "id: #{article[:id]}, title: #{article[:header]}, created_at = #{article[:created_at]}"
      puts "================================="
      puts "create it!"
      markdown = "<markdown>#{article[:content]}<\/markdown>"
      post = @site.posts.create(:title => article[:header], :body => markdown, :date => article[:created_at].to_s)
      puts post

      # the following is some retry logic.
      if(post == nil)
        if(limit < 3)
          limit += 1
          redo 
        else
          retries << article[:id]
          p retries
          limit = 0
          next
        end
      end

      # recreate the comments for the post
      article_comments = comments.filter(:commentable_id => article[:id], :spam => 0)
      article_comments.map do |comment|       
        puts "----- comment -------"
        puts "=> comment id   : #{comment[:id]}"
        puts "=> comment name : #{comment[:name]}"
        puts "=> comment email: #{comment[:email]}"
        puts "=> comment site : #{comment[:website]}"
        puts "=> comment date : #{comment[:created_at]}"
        puts "=> comment body : #{comment[:body].length}"
      
        post.comments.create(:name => comment[:name],
                             :comment => comment[:body], 
                             :email => comment[:email],
                             :date => comment[:created_at].to_s)
      
        sleep 1 # so I can read the output
      end
      sleep 1 # so I can read the output
    rescue => e
      puts "!!!!!!!! had a problem with this one!"
      puts e.message
      puts e.backtrace
    end
  end
end

# show detailed output of one article
def show(article_id)
  article = DB[:posts].filter(:type => "Article", :id => article_id).first
  puts "title: #{article[:header]}, created_at = #{article[:created_at]}"
  puts "created_at = #{article[:created_at]}"
  puts "body: #{article[:content]}"  
end

# comment-in one or both of the following
# show(1997) # display details for one post
# migrate # perform migration 

Issues

I had a few issues along the way:

Issue: Rate Limiting

The posterous API does not allow unlimited posting. I hit the API pretty hard as I was testing my script, and eventually all of my posts started failing. Quick, to the Twitters!

@timeandthinking soon upped my API limit so I could continue. Thanks, dude!

Issue: Posting Errors

Sometimes the API would fail with the following error:

wrong status line: ""

I never figured out what caused this. Inevitably, these were my most popular and complex posts, and since this was a one-off I didn’t want to invest too much time and energy into tracking down 10 failed posts, so I re-posted these by hand via copy-paste. The show(article_id) method in the script helped with this.

Issue: Mad Markdown

I wrote this migration script so I wouldn’t have to recreate all of my posts by hand. Inevitably I needed to hand-tweak about 20% of my posts, and for a frustrating reason: Markdown vs. HTML incompatibility. Posterous supports the markdown formatting language, which is great, because most of my posts are written in markdown. Unfortunately for me, many of my posts are actually a mix of markdown and HTML: YouTube embeds, Flickr photo links, etc. For some reason Posterous’s markdown engine barfs in various ways when it encounters HTML, from ignoring the HTML to prematurely terminating the content at the HTML point. It seems that if you require HTML in your post then markdown is not an option.

Permalink | Leave a comment  »

I’ve been doing a bit of biz-dev lately and found myself using the word “ecosystem” quite a bit. The “startup ecosystem” in Atlanta, the Ruby software engineering “ecosystem”, the Agile development “ecosystem”. The more I use this word to describe the positive aspects of a community the more I dislike it, or perhaps more accurately, the more I feel it inappropriately used. We need a new word.

Ecosystems sound like nice places because they have the prefix “eco” which has been co-opted by marketers and branders to connote responsible behavior. But ecosystems are not good or bad, they just are. Often ecosystems are dangerous places. Ecosystems have predators, parasites, and scavengers. Ecosystems are full of diseases and those whom carry them and infect others. Ecosystems can be unfriendly to non-native species, killing them upon arrival, or can be taken over by invasive species, which kill off what was already there. Ecosystems can have chiggers, for God’s sake. We need a new word.

Thought experiment time. When I say that San Francisco has a thriving startup ecosystem, what am I saying? I’m saying the following things:

• The community is active.
• The community is inclusive.
• The community is communicative.
• The community is supportive.
• The community is giving.

So, word-nerds, if it’s not an “ecosystem” what is it?

Permalink | Leave a comment  »

This evening I went to a Black Eyed Peas concert at Los Angeles' Stables Center… at the Century 20 Theater Complex in Daly City, CA. This was a Fathom Events event, a live concert broadcast to movie theaters across the US, fulfilling one of the promises of the digital movie theater: non-movie digital content streamed to paying customers. How was it?

Overall, it was a pretty good experience. As expected, the audio clarity was excellent, and sounded good on the theater sound system, but not as good as it could have been — read more on that later. Visually, the direction and production (if that’s what you call them) were excellent, much in the style of many modern, sophisticated concert movies or TV specials. I would go again.

The experience could be better, though; following are my recommendations, free of charge!

Louder… LOUDER!

The sound in the theater needed to be much louder, perhaps twice as loud. The audio was broadcast at normal theater levels, which now days is pretty loud — think action-blockbuster loud. While this can sometimes seem overwhelming in a movie, it was not nearly loud enough for a high energy group like the Black Eyed Peas.

Use the Surround Sound System

The theater only played the sound through forward speakers, which was actually rather distracting given how we all expect theater surround-sound. Why didn’t they use the surround sound system to help immerse us in the concert experience? This seems like a no-brainer.

Radio Edit?

Everyone was grooving along to Wil.I.Am’s freestyle when his performance was interrupted by audio drop-outs; the seconds of complete silence were extremely jarring. At first I thought these were technical glitches, but after more followed during IMMA BE I realized that Fathom was trying, and failing, to edit curse words and phrases out of the live stream. I say failing because quite a few sh*ts, f*cks, mo*f*ers, and n*gg*s slipped though.

Fathom: you are not my mother. Absolutely do not censor the audio from the concert — the raw audio is why we’re there!

More Immersion

Part of the concert experience is being part of an excited, hyped-up crowd. We, on the other hand, were in a large movie theater with about 30 other people scattered about. The video quality and production were excellent, almost too good — I had to remind myself that the concert was live and not a pre-produced event. To that end, Fathom should make an effort to make theater viewers more a part of the concert experience, to make the experience more immersive. Here are some ideas:

• Crowd Noise: As I mentioned the theater did not use the surround sound. They should pipe in crowd noise through the side and rear speakers, make it seem like we have front rows seats. Sure, this is akin to the laugh-track trick, but the laugh-track trick works.
• Live Cameras: Incorporate the theater-viewers into the artist’s experience, too! Have cameras in the theaters to broadcast live theater-streams to the concert so the artists can see and interact with them as well as with the crowd in front of them.

Can you Say 3D?

Broadcasting live concerts in 3D has the potential of being a killer app. Wil.I.Am mentioned that the concert was being filmed and viewed in 3D, but this was not an option for us. In-theater 3D concerts could be amazingly immersive.

Permalink | Leave a comment  »

Agile software development teams who pair program often wonder when, and how often, to switch pairs. Teams also often have concerns regarding "owners" of large feature sets and how pair rotation works with them. While there is no definitive correct answer, I have used a pair-rotation schedule that works very well with small teams, especially if those teams are working on large, parallel feature sets. I call it the "2x4" rotation.

2x4 in Action

2x4 pair rotation is pretty simple:

Each developer has a new pair every two days.

"Experts" rotate every four days.

That's it. Here's a video.

(Click here if the video does not show.)

How Your Team Benefits from 2x4 Pair Rotation

The above video described how your team physically implements 2x4 rotation, but why do it?

Knowledge Transfer, for Real

Many teams give lip service to knowledge transfer and shared ownership, but in reality most teams develop specialists and owners. Often these roles develop when one person latches on to a large feature set and doesn't let go: Doug lead the profile page rewrite, and Carrie always works on the social graph. 2x4 breaks this cycle of knowledge silos by both forcing a potential owner to rotate off a feature, and forcing the remaining developer to step up his game and lead the effort for the next two days.

The upshot: the knowledge transfer is *real*. The team is forced, in a healthy way, to really learn the application they are writing.

I'll be honest: rotating off a feature set that I have been working on for 4 days always makes me a little nervous. That's my baby! It is very, very tempting to stay longer, to keep diving deeper, to see it through, to *own it.* And not only that: I get nervous again when I'm the newer member of a pair and the expert rotates off -- didn't I just get here? I'm not an expert yet, and the new guy knows less than I do!

It works out every time. When I first rotate on to a team I feel the weight of being the expert lifted from my shoulders, and new features are a breath of fresh air. When I take over two days later there are rarely issues, and it feels good to wear the expert hat again. Besides -- the developer who just rotated off is sitting five feet away if we have any questions.

Rotate Often, but not Too Much, on a Schedule

Pairing with the same person for two days is ideal: long enough to get into a groove, but not a rut. The pair is almost sure to complete multiple feature stories together, which creates a feeling of joint accomplishment. 2x4 rotation allows a team to adopt a fairly strict schedule without feeling that the pair is being broken up just as they are starting.

The "Working from a Café" Effect

What's the difference between working with a new pair and rotating? What does rotate even mean when there is no large feature set to leave? It might sound silly, but I feel it's important: rotating in this case means working at a different computer. I call this the "working from a café" effect: a change of scenery can do wonders for your creativity and problem solving, even if you are only moving 10 feet.

Even if you have an ideal open, agile workspace, where all of the developer machines are clones, if you work at the same workstation constantly then it will become "yours". You will be less likely to let your pair drive, and more likely to tweak the machine to be less hospitable to your pair. It is important to move around, out of your normal spot, to work from somewhere else to help get the mental juices flowing. If everyone really does have their own computer, swap machines every 2 days.

The Ownership Dilemma

I have spent a lot of time in this article on one theme: breaking the ownership cycle. This is controversial. Without a doubt having an individual developer own specific features or systems has advantages: deep historical knowledge and expertise, speedy implementations, confidence in their results, an many others. As a product or project manager, having an owner also provides accountability and a single point of contact -- your "go-to guy" for Feature X. Some might even say that feature ownership, like any other ownership, is so ingrained in our human nature that it is unavoidable.

You know what? I agree. Some amount of ownership is inevitable.

There is also another undeniable truth: ownership will bite you in the end. We all know it. Anyone who has held a job, be it barista, barber, or bank executive, has watched in horror as an expert left with all of their knowledge, or walked on egg shells when asking a delicate feature owner to please, *please* fix something that only they can fix. "Silo" is a four-letter-word for a reason.

Some ownership is inevitable, but the risks inherent in ownership are manageable. 2x4 pair rotation is an excellent means of managing those risks while gaining the benefit of having multiple experts in a subject area.

Permalink | Leave a comment  »

or: how Twitter-TV will destroy your timeline

I just watched the Mavericks Surf contest live on ustream.tv]. Actually, I didn't just watch: I also chatted, tweeted, bantered, and otherwise interacted with up to 56,000+ others from around the world watching the contest. Without a doubt this was one of most engaging and intriguing merging of social media with a live event which I have ever participated. It was also a very flawed implementation and should be learned from and avoided in this particular form.

A bit about Ustream

Ustream has video. No biggie. The potentially killer app is Social Stream, where users of Twitter, Facebook, AIM, and Myspace can log in using the appropriate account and participate in a live chat-room-like-thing while watching live streaming video of sporting events, conferences, the weather… you name it. Wait, it gets better(?): your chat posts not only update the Social Stream, but also your social network stream: it's a tweet, too!

Tease It Up High And Let It Fly

I watched nearly the entire Mavericks competition, but only peripherally. I was at least as engaged in the Social Stream. People were were ecstatic whenever a rider killed a wave; they went crazy whenever a rider was nearly *killed by* a wave; and they were brutal to the surfer-dude announcers (and to each other). I laughed out loud on many occasions. Also, reading the stream also helped me learn more about the sport and the famous competitors.

Nasty Wipeout

Chat rooms are not timelines… at least not when they cannot be segregated from your public timeline or reassembled back into chat rooms. I was blown away watching users of at least 4 different social networks participate in the live chat stream; it felt very natural to add replies and reactions, and to lob insults and burns. What fun!

There are two compounding problems, though. First, each individual's postings have no persistent tie to the Social Stream. For example, neither Twitter nor Facebook's applications are programed to facilitate a third party's inter-social-network chat framework. This is a more than just a gnarly washout: encouraging the chat-like interactions might might actually damage the participant's credibility back at home. Each comment into the stream is simply a tweet, wall post, status update, etc. That lively banter in the Social Stream turns into a very weird and spammy public timeline. It's reminiscent of listening to one side of a phone conversation, or more like only being able to listen to one person as they meander through a crowded party.

Drop In On A Bomb And Ride It All The Way To The Beach

I love the idea of reducing the barrier to interaction by embracing as many social networks as possible, and also of persisting the conversations. What's needed is some kind of bucketing system to natively support interactions with live events and their participants. I definitely held back many comments during the Mavericks event because I didn't want to pollute my timeline with unintelligible crap. I would have participated in more free-wheeling manner if I knew that my comments were recored, but safely hidden, from my timeline.

Or, all of the companies could agree on a cross-platform conversation model. Okay…

What about getting the hosts or announcers involved? I'm not sure. There was a certain yelling-at-the-TV factor as the crowd harped on the announcers. At one point the announcers themselves noted that people were probably giving them a hard time. We were. It would have been different if they had been able to say "Hey, @joem, STFU!"

Permalink | Leave a comment  »

Joe Moore (original cdwaldi)Once upon a time I was a Firefox fanboy. Screw IE, Firefox is tha BOMB! Firefox was fast and cool and had Firebug and was open source and was screwing over Micro$oft and YEAH! I loved it.

Then two things started happening. First, Firefox started feeling slower and slower with each upgrade, and the glut of extensions I had installed made Firefox feel bloated and hodge-podgy. I loathed closing Firefox because of the inevitable time consuming extension updates upon restart. Make no mistake: Firefox + Firebug + many other extensions have improved my software development life immeasurably, but I was also aware of the heavy tool belt.

Joe Moore (original Lonnon Foster)(Oh, don’t even start about running multiple Firefox profiles. It sucks. Nobody really does that. Thank you.)

Second, I stopped ignoring Safari and now Chrome. These two browsers are snappy, slick, stripped down, start quickly, and are (mostly) extensionless. Sure, they have developer tools built in, but next to a fully loaded Firefox profile they dim in comparison and productivity.

Now I run two browsers: my work browser and my everything-else browser. Firefox is my super-handy, sometimes awkward multitool that has helped me escape many tight spots. Chrome is a Spyderco Delica: simple, sharp, efficient, and opens with a satisfying snick with the flick of the wrist. Use the right tool for the job.

Permalink | Leave a comment  »

Today I watched an intriguing talk titled Do Frameworks Have a Place in Web Development’s Future?, in which Django developer Jacob Kaplan-Moss states flatly, “web development sucks”. He’s right: web development is often difficult, repetitive, and boring. He takes us through the history of web development from the HTML-only stone age, through the less sucky but still terrible CGI and PHP epochs, to the current world of web frameworks, where life isn’t as bad as it was, but it’s not great, either. The talk covers a lot of ground and does not exactly predict the death of web frameworks, but challenges web framework developers think beyond application-based thinking to full-application ecosystem thinking:

• Web frameworks need to be more modular to allow developers to rewrite or swap out pieces of the framework that ultimately fail.
• Web frameworks need to fix concurrency issues to deal with the dying single-threaded world embrace the exploding multi-core world.
• Framework developers need to think hard about the HTML5 spec where the differences between desktop and web applications fade to black.

I completely agree, but this talk really got me thinking about the chatter I’ve been hearing about the death of web frameworks their friends: the RDBMS and the HTML front-end. Frameworks like Rails and Django are bad choices — they can’t scale. You should’t use an RDBMS because eventually you won’t be able to change your schema. I have a response to these statements:

Bullshit.

Not only do frameworks have a place in web-development’s future, but they will continue to grow, become easier to use, become more powerful, and enable innovative people to launch products faster than ever. Here’s why.

Web frameworks are the fastest way to get to market

And succeed, or fail, fast. Or stay alive longer so you can iterate and refine your product and business to fit your customer’s needs. If you have a business idea, a little cash, and zero developers, shops like Pivotal Labs (disclosure: I work there) and Hashrocket can bring you to market using the ARC model (Agile + Rails + Cloud) in a matter of weeks or months. This is not a sales pitch, this is reality. There is no foreseeable alternative for developing web apps quickly, and few startups have the luxury of building for scale on day 1.

Nor should they. I recently had a conversation with a chief engineer for a fast growing company, where he is shepherding a major part of their infrastructure from MySQL to a BigTable-like data store. I asked him strait-up: in his opinion, are relational databases dead? Should startups bypass them and dive into a more scalable solution?

No way, he said. Ease and speed of development make web frameworks with RDBMSs a no-brainer. MySQL got his company a long, long way, and much of the application still runs on it. Needing to migrate away from your RDBMS because of your company’s success is a great problem to have.

Success is not about being as big as Google

Stealing a line from Kaplan-Moss, who stole it from someone else, I can count the number of companies as big as Google on one finger. If one day your company and user-base is so lucky to have a Google or Facebook-sized problem, then you’ll have Google-sized resources to address it. Sit down, take a deep breath, and relax by picking out a private jet before freaking out about how it takes too long to migrate your database.

You can’t fail if you don’t try

Rhetorical question: how many companies would never have been born without web frameworks? If web frameworks were wiped from the face of the Earth tomorrow, which future companies would never exist? Web frameworks will continue to grow and succeed because they enable opportunity. Sure, you can say that they allow for the opportunity to create an unscalable site, but they also provide for the opportunity to create The Next Great Site, too.

Web frameworks are incorporating scalable, modular technologies.

The big ones here are alternatives to the RDBMS. For the most part, these are key-value, document-based data stores, or BigTable implementations. Adapters for web frameworks are already springing up here, such as HyperRecord for hypertable in the Rails world. More adapters and tools will be built in or easy to use plugins as these alternative data stores become more established.

In addition, Rails is already heading in the framework à la carte model with Rails 3: The Great Decoupling. Don’t want ActiveRecord? Dump it.

If you fail because your web framework didn’t scale you probably would have failed anyway

Ouch. Look at Twitter: if you are reading this, you’ve see the Fail Whale. Often. But you still use Twitter, don’t you? Parts of Twitter’s out of the box web framework, Ruby on Rails, did not scale and had to be replaced, and while they did this the site Whaled a lot. Yet people kept coming back and usage and signups soared because Twitter has an amazing product, who’s users are tolerant of it’s growing pains. If you’re users bail on you at the first sign of a slowdown then you users were going to bail anyway.

… But don’t be stupid

Web frameworks aren’t going anywhere and will continue to be the right technology choice for many startups. That said, you can do stupid stuff with them. Not just create stupid products, but developers can write stupid code or pick the wrong framework for the application’s needs. I am not always going to suggest Rails just because I know and love Rails. Sometimes you need to write some Java. Sometimes a RDBMS is not the right choice from the git-go, and developers should be honest and realistic with themselves if that is the case.

So, don’t listen to the web framework FUD, but don’t be religiously dedicated to your framework, either. Have fun writing code.

Permalink | Leave a comment  »

Thanks to the persistence and support of many people the NY MTA has acknowledged that their own claim that I violated their trademark was a mistake.

After contacting me on 09/02/2009, SF Weekly writer Anna McCarthy describd my Muni-shirt story in her article NYC's Metropolitian Transporation Authority Threatens Man Marketing S.F. Muni T-Shirts. In addition, she contacted the NY MTA regarding their insistence that my art infringes upon their intellectual property rights (trademark). Their response -- what trademark violation? Quoting Ms. McCarthy's article:

[In] a recent phone interview, a spokesman for the agency, Aaron Donovan, seemed to backtrack: "We have no claim on Muni's icons, we would need to look into the specifics of this case in greater detail to determine why the letter may have been sent," he said. "The images on Mr. Moore's blog did not appear to show anything that would represent a trademark violation against the New York MTA."

This is an important success against a litigious agency, and will strengthen the case of Chris Schoenfeld of StationStops.com.

The story is not over. As pointed out in the above article, SFMTA is "broadly interested in merchandising as well". While I'm hopeful that SFMTA will not follow NYMTA's lead, I'll be watchful for abusive practices.

Permalink | Leave a comment  »

As my own NY MTA/“MUNI-shirt” story has started to get publicity I am learning that I am not alone in the NY MTA’s crosshairs. The most notable target is Connecticut-based blogger and iPhone app developer Chris Schoenfeld, proprietor of StationStops.com. Chris is also one smart, brave, and feisty guy, who is determined to defend his rights.

Chris developed StationStops for iPhone, which “allows riders of the Metro-North Railroad to check the timetable for regularly-scheduled trains.” Unfortunately, Chris had to maintain the schedule data himself, and he decided to contact NY MTA and see if they could provide metro schedule data in a developer-friendly format.

Big mistake.

Responding to a copyright infringement claim by the MTA, Apple removed StationStops for iPhone from the Apple App Store. Then, the MTA hit Chris with a cease and desist, claiming that StationStops for iPhone “fringes on MTA’s statutory and common law intellectual property rights and is inaccurate, false, and misleading with respect to content pertaining to MTA and MN,” amongst other claims. When Chris tried to work with the MTA, the MTA responded with more legal threats.

Big mistake.

Chris has decided to fight back, and fight back hard. He’s enlisted the EFF for legal support, generated huge amounts of bad press for the MTA (including articles in the NY Post and NY Times), and even been interviewed by local TV news affiliates.

Good luck, Chris! I’m rooting for you.

Permalink | Leave a comment  »

UPDATE 09/09/2009: Added a few more links.

Quite a few blogs and message boards are picking up my MUNI-shirt story. Here’s the rundown so far:

• SF Weekly – “NYC’s Metropolitian Transporation Authority Threatens Man Marketing S.F. Muni T-Shirts – San Francisco News – The Snitch”
• NBC Bay Area – NYC Subway Thinks It’s Muni, Attacks SF Designer
• Muni Diaries – NYC Shuts Down Muni T-Shirt Maker in a Major WTF
• Muni Diaries – More on ‘NYC Shuts Down Muni T-Shirt Maker’
• StationStops – MTA Cyberfraud: The Most Gratuitous Case Yet [SF Parody T-Shirt]
• LIKELIHOOD OF CONFUSION – MTA’s way or the highway.
• War on Photography – More Stupidity from the MTA Legal Department
• subchat.com – NY MTA Claims SFMTA Parody Infringes on Trademarks
• Flickr discussion thread – Flickr: Discussing what dickheads in The NYC Subway

And what about Zazzle.com, where I’ve re-uploaded my content (with lots of new stuff!)? They have reviewed my content and removed one class of item: postage. Why? “Design includes material that Zazzle believes would hurt its reputation.”

Permalink | Leave a comment  »