All Posts in Developers

January 27, 2014 - No Comments!

Coding in Costa Rica: The Developer Exchange Experiment

costa-rica_58Every year, wherever you are on December 13th, there's probably a code retreat happening someplace near you. That's because it's the Global Day of Code Retreat, and this past December, I traveled to San José, Costa Rica, for it. Part of the reason I trekked so far to participate was because Costa Rican software shop Pernix Solutions invited me to be a guest facilitator. On top of that, Table XI and Pernix wanted to try out a Developer Exchange, so this was an opportunity to kill two birds with one stone.

Read more

November 7, 2013 - No Comments!

Tech Tip: Codecademy

codecademy_logo_detailWant to learn some code basics? It’s as easy as opening your web browser.

Confession: I am not a developer. Over time I’ve learned some cursory HTML, but the rest of the coding languages are Greek to me. As a writer among the programmers here at Table XI, I’ve felt a bit guilty about that. I’ve always wanted to get more familiar with code, partly to be able to understand developers better, and partly because it’s time to join the 21st century.

Read more

October 21, 2013 - 1 comment.

From gSchool to Table XI: A New Developer’s Journey

IMG_3078Today I’m a software developer at Table XI, working with some amazing clients, with my first project just recently deployed to production. It’s still hard to believe that only one year ago, I was working as a manager in an operations role at a large daily deals company, and switching careers to become a web developer was not yet on my radar. It all started in early November 2012, when I decided to attend an Introduction to Programming workshop.

I had been interested in web development, but I’d fallen prey to the stereotypes that “only computer science majors can be programmers,” or “you have to be a genius at math.” I hadn't really looked at programming as a viable option, given my background and two liberal arts bachelors’ degrees. Lo and behold, the workshop taught me that not only was I good at programming, but that I loved it, too. The code I wrote in that workshop was as simple as puts and gets methods and some string interpolation, but even being able to write simple methods and see the output come across my screen felt invigorating.

I was already in the midst of exploring a career change, and that workshop sealed the deal: I knew I wanted to learn web development, and I set to work looking at different bootcamp-type course options. I was lucky that a plethora of options existed, from Dev Bootcamp in San Francisco to Starter League in Chicago to Flatiron School in New York, but I decided on gSchool, an intensive six-month course in Denver focusing on Ruby on Rails. I felt gSchool was the best fit for me given the length of the program, a rigorous curriculum taught by seasoned instructors, and the guarantee that if I graduated, I would get a job making a minimum of $60k within three months of graduation or a full refund of my tuition. Additionally, the director, Jeff Casimir, had connections with my previous employer, LivingSocial. He'd run a similar five-month training program for LivingSocial that a few of my friends had been through, so I knew what to expect.

gschoolI moved out to Denver in January of 2013 and started the most intense six months of my life. I knew gSchool was going to be hard and I had mentally prepared to put in 60+ hours per week, but nothing really prepares you for the brain melt of not only learning something totally new, but adjusting to an entirely new way of thinking. Like many of my fellow classmates, I came in without a background in development, and the most challenging part of the program for me was acclimating. Looking back, my assignments now seem almost laughably easy, but they were difficult for someone who was just learning to “think in code.”

I had amazing classmates and world-class instructors though, and with their help I had my “A-ha!” moments where things started to click. The setup of gSchool was a great mix of instructor-led, full group classes, group projects of two to four people, guest speakers, lightning talks, mentoring sessions, and more. The environment was very collaborative, with everyone dedicated to helping their classmates and celebrating each others’ small moments of triumph. It was certainly at times a mentally grueling experience, but with so much support from classmates, instructors, and mentors, we all made it through together and built some really awesome apps along the way.

gSchool Hug

About two-thirds of the way through the course, we had our first individual project since our first month, and like many of my classmates, I felt quite nervous. We knew the project would prove some things to ourselves—either that we knew what we were doing, or that we hadn’t mastered the abilities we’d fought so hard to learn. It was incredibly validating when the former happened, and I was able to build online scheduling from scratch for a website I was creating for my sister, a massage therapist.

For the last month or so of the course, our focus grew to include finding jobs. There were a lot of things I was looking for in a job, both need-to-haves and want-to-haves. I knew I wanted to work for a small- to medium-sized consultancy that was compatible with my testing and pairing philosophies, where there would be many different challenges to learn from. Other big must-haves included being part of an environment that fostered continued learning and had amazing teammates with whom I’d love coming to work everyday. I narrowed my search by looking in a select group of cities, and leveraged my network—including my mentor and instructors—to set up introductions to companies I was interested in.

I talked to plenty of amazing companies, but I knew from the time I had my first phone interview with Noel and Isaac that Table XI was where I was meant to be. The people at Table XI were incredibly smart, but also approachable and helpful, and I knew I would learn a ton from my co-workers. Crucially, the environment seemed very supportive of a junior developer. The projects they were working on were really interesting, and the fact that they worked with nonprofits and community organizations appealed to me and my former life as an organizer for social justice. The company was diverse, and it was palpable that people genuinely cared about the clients they were working with and their teammates in the office. That they were located in Chicago, a city I loved, only added to the appeal. When I was describing the awesomeness of the company to my husband, I kept finding myself saying "Oh! And did I tell you they also..." When I was offered a position with Table XI, I was delighted to accept.

I've been with Table XI just over a month, and I'm happy to report that my exuberance was not misplaced. I have fallen in love with programming all over again, thanks to the project I've been working on, and I have amazing co-workers always willing to help mentor and guide me. As a testament to the skills I learned at gSchool, during my first week I was fixing bugs, and by my second week I was already working on project features on my own. One of my biggest takeaways from my gSchool experience is, for lack of a better phrase, “learning how to learn”—knowing how to read technical documentation and solve a problem on my own, balanced with knowing when to ask a teammate to pair on a problem.

I still have a lot to learn (but what developer, of any level, doesn't?), but the decisions to take the leap, to uproot my life and change careers, and to come to Table XI are the best ones I have ever made for my career. If this is how I feel at the end of month one, I can't wait to see how I feel a few months down the road.

October 3, 2013 - No Comments!

Tech Tip: If This Then That

If This Then That (IFTTT) is a service that lets you create powerful connections between common web services using "recipes" in the form of the simple statement: “If this then that.” If I post a new photo to Instagram, then save a copy of it to my Dropbox folder. If I get an order confirmation email from, then send a copy to my Evernote account. If there's rain in the forecast for tomorrow, then send me a text message. Cool, right? There are 70+ different services available and you need absolutely zero coding skills to start creating your own recipes.

Recipes are unbelievably easy to create—you can build your own or browse the community list to use one that someone else has already built. A few of my favorites include:

  • If "my name is mentioned in our project Campfire chat room" then "send me an email." I'm working on a number of different projects at the moment and can't always keep up with the conversations that the developers have in Campfire. This recipe flags me on a channel that I check more frequently (email) and let's me know that there's something the team wants me to weigh in on.
  • If "it's 9pm" then "send me tomorrow's weather forecast via Pushover." Who has time to keep up with weather forecasts? This recipe reminds me to make sure I have weather-appropriate clothes clean for tomorrow.
  • If "the Chicago Bears have just finished playing a game" then "send me the final score of the game via Pushover." Depending on how the season goes, this recipe may not last through the end of the year.

GDImeetupSince I'd been experimenting with IFTTT recently, it was top of mind when I was recently planning a Code & Coffee meetup for Girl Develop It that we hosted in the Table XI office. It was our chapter's first Code & Coffee and I wasn't quite sure what to expect. We wanted people to be able to "geek out" for a couple of hours in a fun environment, but that can be difficult if many of the people who show up have never actually written any code before.

IFTTT was the perfect thing to get beginners excited about the magic of technology.

The women who decided to spend their geek time hacking around with IFTTT got to be creative, learn some basic logic, and experience the joy that every coder feels when you manage to get something working. It was the perfect way to grab their interest and build their confidence. It worked so well, in fact, that they all decided to take the next step and signed up for Girl Develop It's upcoming Intro to HTML / CSS class!

September 11, 2013 - 1 comment.

How to Run an Effective Retrospective

How to Hold a RetrospectiveRetrospectives have long been an important part of the agile software development process. The team should regularly take some time to reflect on what's working well, what isn't, and make any necessary adjustments. On most of our projects, we do a brief retrospective as part of each iteration planning meeting, which allows us to make course corrections along the way.

Recently, we've had a number of projects wrap up or launch major releases, and we've found it very helpful to take a step back and run slightly longer, more formal retrospectives.

  • Participants: Everyone involved in the project from initial sales pursuit through delivery + 1 Facilitator
  • Duration: 1.5 hours (we had 5-8 people retrospecting 3-4 months of development iterations)
  • Supplies: Whiteboard + markers, IdeaBoardz, video camera + conf call for remote participants (we use GoToMeeting)

Set Context (30 - 45 minutes)

Start by creating a timeline from the beginning through the end of the release. We're a software consultancy, so most of our timelines start with initial client meetings and a discovery phase that we call an Inception. For a product company, your timeline might start with a product manager researching new features. It's important to rewind all the way back to the beginning to make sure people are thinking about the big picture, and aren’t fixated on the last 2-3 weeks worth of work that may be freshest in their minds. It's also helpful to build a shared understanding among everyone in the group, since some team members may have joined or left the project at different times and not be aware of the complete picture.

This is where we use our whiteboard. The facilitator walks the group through creating the timeline and draws important events up on the board. We had one remote participant in one of our recent retrospectives, and she was able to follow along with a video camera pointed at the board. Common events you might want to call out include: when each person joined or left the project; the start of development; the first client showcase; the first time real users started testing; 3rd party integrations; infrastructure upgrades; data migrations; any changes in the client team; and major blockers that were resolved. On one project, we also got to track when the client brought us pies!

Individual Reflection (10 - 15 minutes)

Once everyone is on the same page, you can shift gears into actually analyzing what worked well and what didn't. I prefer to have people do this individually to allow everyone to come up with their own ideas and not be too swayed by the group. If you jump straight to group discussion you run the risk of having the loudest people control the conversation. Whether it's using pen and paper, Sharpies and sticky notes, or a favorite text editor, let everyone think on their own for a little bit. The categories we use are:  "What Worked Well," "What Didn't Work Well," and "What Do We Want to Take on to Future Projects?"

Group Discussion (30 - 45 minutes)

I'm as big a fan of sticky notes as the next person, but they have two downsides: they don't work for remote participants and they're a pain to clean up and transcribe after the meeting is over. Instead, we use a virtual tool called IdeaBoardz. It creates a virtual board of sticky notes that many people can see and interact with at once, and it lets you export the results to a PDF when you're done.

IdeaBoardzThe facilitator leads the discussion, asking people for their "worked wells" and transcribing them one at a time onto the IdeaBoard. Having the facilitator be the one transcribing lets the team focus on their discussion and also keeps some consistency and organization to the notes being captured. Conversation tends to flow pretty naturally as others agree or disagree with a point made and contribute their own points. The facilitator needs to pay attention and make sure everyone in the room (and on the phone) is getting a chance to talk. Move on to the "didn't work wells," and ultimately, establish a list of key learnings that you want to apply to future projects. This third category is where you get the most value from the exercise, so make sure you're capturing these nuggets of insight.

Capturing a list of “what we should do better next time” is a great first step in the continuous improvement journey—but it’s important that you make this your first step and not your only step. At Table XI, our delivery assurance team meets every two weeks to review the outcomes of these retrospectives and implement many of the changes suggested. We then plan to share a condensed version with the entire company at our monthly all-team lunches.

Are you running end-of-project or end-of-release retrospectives? Is there a different format that you've found works well for your teams? Have you found other tools that you like to use? Please share!

Image source: Håkan Forss

September 6, 2013 - No Comments!

Help, My Test Is Failing

xitoeyeHere's the situation. You've written your tests. You run your test suite one last time before checking in, and just when you think you are done, you see the big red F indicating test failure.

"Why Me?" you ask. "What now?"

This video discusses strategies for discovering what may have made your test fail, and for exploring what happens during the test run. If you take nothing else away from this video, learn that sometime in the next six months, there's a good chance that git bisect will save you.

If you're going to be at WindyCityRails this year, be sure to catch my talk "Rails vs. Object-Oriented Design," Fri, Sept 13, at 9am. You can also check out my books Master Space and Time With JavaScript and Trust-Driven Development.

September 3, 2013 - No Comments!

Meet up with Table XI at WindyCityRails

017_windyCityRails_logoDo you have your tickets to WindyCityRails? We do. We’re proud to be sponsoring and speaking at Chicago’s biggest conference for Ruby software developers. If you’re also headed to the South Shore Cultural Center next week, be sure to keep a lookout for a team in green jackets, including two Table XIers who will take the stage during the two-day event.

Why are we so excited for the event? We think this WindyCityRails video sums it up well.

WindyCityRails 2013 from ChicagoRuby on Vimeo.

Table XI Speakers at WindyCityRails:

Greg Baugues, our Director of Client Services, will deliver his talk on Devs and Depression, which covers an extremely important subject that has resonated with many in our industry and earned Greg high praise and a global following. He has now spoken about Devs and Depression at MountainWest RubyConf; LessConf in Panama City, Florida; Scottish Ruby in Perthshire, Scotland; and Distill in San Francisco, to name a few. He’s looking forward to taking the stage a little closer to home this time to deliver his message.

“Software development is a good place for people with depression and bipolar,” Greg says. “It accepts the socially isolated. It accommodates irregular sleep patterns and inconsistent bursts of productivity. It seeks out those with the overconfidence to believe that they can solve problems that others can’t. We need to bring depression out into the sunlight, and make it as acceptable as diabetes or cancer. We need depressed developers to know that they are not lazy or weak, but are suffering from a treatable medical condition.”

You can catch Greg speak on Thursday, September 12, at 3:30 pm.

Noel Rappin, Table XI Senior Developer and Agile Coach, will also take the stage for his technical talk “Rails vs. Object Oriented Design.” This year he’s spoken at RailsConf in Portland, Oregon, and led a Rails workshop at MadisonRuby, but says he always looks forward to WindyCityRails.

“There are always interesting people to meet, and I’m excited to deliver my talk,” Noel says. “Over the past year or two, there’s been a lot of conversation in the Rails community about the applicability of Object-Oriented techniques to Rails applications. This conversation becomes especially important as the Rails community is increasingly managing long-lived applications. Techniques and phrases like ‘DCI,’ or ‘Rails is not your application,’ or ‘Dependency Injection’ get thrown around. All these sound impressive, but if you look to Rails for simplicity, then they may seem like overkill. In part, the techniques are about what kind of design is best suited to planning for unknowable future change. My talk shows how these techniques can be applied in Rails, and how they can help you prepare for the future without making the present complicated.”

Hear Noel Speak on Friday, September 13, at 9 am.

To see the full schedule, visit the Windy City Rails website here.

August 22, 2013 - No Comments!

5 Steps to Writing a Good Support Ticket

You come into work Monday morning and find out there’s a problem with your company’s internal web dashboard. You need to access your data for sales calls this afternoon and can’t do your job without it. You desperately need your support team to deliver a quick solution.

To diagnose and fix the problem, the support team needs detailed information to reproduce the same error you received. The more specific you are, the faster the support team can get you back in business.

A great, informative support ticket answers several questions. Here are the five questions you should ask and answer when submitting a ticket.

  1. How urgent is this issue? Write down your contact information and relative priority of the issue against other outstanding requests.
  2. Where did the error occur? Provide the URL and the browser you were on when you experienced this issue.
  3. What did you expect to happen? Provide details on what you expected to happen versus what actually happened. Break each error into a separate paragraph.
  4. Did you attempt to fix the problem? If you attempted to trouble-shoot, provide the steps you took and their results.
  5. What did it look like on your screen?  Provide  documentation, details and screenshots when possible. If you want to be truly amazing, take a video screencast of the process causing the error.

Check to see if you answered all of the questions above. Add any additional information that might help the support team and send.

Here is an example of a great support ticket:

Subject: Cannot Sign Into Admin Dashboard
Date: 9:03AM Monday, August 1st, 2013

Priority: Highest - this should take ultimate precedence over anything else

Hi John,

I can’t sign into my Admin dashboard this morning (8:30am EST). I wasn’t having any issues this weekend accessing it. This is pretty serious and I need my dashboard to prepare for a couple of big sales calls this afternoon.

From the admin login page, I entered my username and password, hit enter and received the error message below. I’ve been trying for 30 minutes and still can’t login.

I tried a couple of things to resolve this:

  1. I restarted Chrome and tried to login.
  2. I restarted Chrome after clearing my cache and all my cookies. I then started the login process again.
  3. I restarted my computer and went through the process above. No luck.

Here is a link to the error, a link to the login page where I started, and a screenshot of the error.

Support Ticket

Best regards,

Follow these steps, and watch the support roll in.

July 16, 2013 - No Comments!

What I Learned In My First Month At Table XI

Mike GibsonTime goes fast when you're enjoying yourself, and I've been nothing but happy since I've joined the team here at Table XI. I can't believe it's already been a month. Quite a bit has changed in a very short amount of time, so I thought I'd take a breather and reflect back on what I've learned over the past 30 days.


A Well-Maintained Calendar Is a Beautiful Thing

Organization has always been a weak suit of mine. The only method that reliably worked was a combination of Post-it notes, chalkboards, and regular check-ins. That's manageable when your team is four people. But when you've got 30+ and a threefold increase in project count, that doesn't cut it anymore. After my first week I knew that I'd sink or swim on the accuracy of my calendar. I dove in and learned about all of the nifty tricks that Google Calendar has had for (probably) years: viewing your colleagues' calendars, multiple calendar organization, etc. The one tip that has made the biggest difference in my ability to keep a sane mind is to make sure I schedule myself time to work. It ensures I have nice blocks of time every day to hunker down and get done what needs to be done. Just this past week I've felt like I got things under control. Let's see how it feels a month from now.

Culture Isn't Created, It Develops over Time

"Company Culture" is a big deal in our industry. But it's not something that's forced on the people that work for you. It needs to be fostered over time. For all of your blog posts and meetings about creating the best culture in town, you're wasting your time if you don't have a group of friendly, empathetic, and interesting co-workers. That is where company culture thrives, and it's been wonderful to see that first-hand. I knew that working at Table XI would be a blast. It only took me a month to see to what degree.

The Best Way to Learn Is to Work with People Smarter than You

I've actually known this for a while, but it helps to remind yourself every now and then. If you're the smartest person in your office it may be time to find some new surroundings. We've got some of the smartest developers in the city put together in the same room and it's amazing the impact that it has. Not only do you learn tips, tricks, and techniques from them. That's a given. There's something bigger at work, though. It's only been 30 days, but I see myself working harder than I ever have before not to bring the curve down. That's what happens when you're surrounded by people that do such great work. You don't want to be the one to let them down.

Budgets Don't Matter, Problems Do

It's safe to assume that at Table XI we're working on projects that are larger in scope than those we tackled at Love Has No Logic. I was really interested to see what impact that had on the life cycle of the projects we were jumping into. You know what? Budget doesn't matter. Every client I've worked with, whether they had $500 or $500,000, came to us because they had a problem to solve and they're relying on our expertise to solve it. The budget just becomes another tool with which you can work to solve that problem. It's important to remember that lesson, especially as you start to see those 0's on the budget start to multiply. It's been up to me to get over the line-items and stay focused on the problem at hand.


I have a terrible habit. I get tunnel vision. If I'm working on something, I don't see anything else until it's complete. The real world impact of this is that for seven years I quite regularly forgot to eat lunch. That often led to me being extremely cranky in the afternoon and evening as my blood sugar dropped, and it probably impacted some of my business dealings over that time. At Table XI we've got a wonderful chef who comes in and cooks great food for us. When people from outside the company swing by for lunch, they talk about how great the food is. But the best part for me is that it breaks me out of my tunnel vision. Everyday when lunch is ready, Chef Aram walks out and lets us know. Someone at the office last week commented that they had forgotten how to feed themselves. We all laughed at the joke, but in my own mind I flipped it around and realized that in my first month here, I've remembered how to feed myself.

It's been a busy first month, and we've already done so much great work that I can't wait to share. I've learned quite a bit being here, and I'm excited to see what I continue to learn as time goes on. I plan to share more of my lessons in the future.

July 9, 2013 - 1 comment.

FoxySync: How to Synchronize Your Website with FoxyCart

FoxySyncIf you've ever done an e-commerce integration, then you know what a pain it can be. Traditionally you'd build a shopping cart, create a checkout workflow, and integrate with a third party payment gateway. Ultimately you spend a lot of time writing and testing new code for an old task. I've done a few of these integrations, and the last time I did I tried something new: FoxyCart.

I wanted to try FoxyCart because it would allow me to outsource the shopping cart, checkout, and payment gateway integration. As a result I could clean up my code base, reduce my maintenance costs, and setup for an easy payment gateway switch in the future. Making FoxyCart work with my Ruby on Rails app, however, was not a cinch. There were no Ruby gems to work with and examples in Ruby were sparse. I knew I'd have to figure out a lot of the integration on my own so I thought I'd make it easy for the next Rubyist and cut a gem out of the work. That gem is called FoxySync.

FoxySync encapsulates four FoxyCart integrations: cart validation, single sign on, XML data feed, and API communication. Using all together fully synchronizes and secures all communication between your app and the FoxyCart service. Let's take a look at each.

Cart Validation

Since FoxyCart knows very little about your products, it depends on you to post any metadata—including price—when customers add items to a cart. As a default, the metadata is stored as plain text in the web page where the “Add to cart” button lives. This is risky because, if someone knows what they're doing, they could change the price of your product before it’s sent to FoxyCart. To prevent such tampering, FoxyCart offers HMAC product verification, or what I like to call cart validation. The feature works by validating a hash on each piece of metadata to ensure authenticity. FoxySync makes this easy by providing a helper method to generate the correct HTML form variables.

include FoxySync::CartValidation
cart_input_name 'code', 'mai', 'mai'
# results in <input type="hidden" name="code||5651608dde5a2abeb51fad7099fbd1a026690a7ddbd93a1a3167362e2f611b53" value="mai" />

Single Sign On

FoxyCart keeps an account for each user that checks out on your site, but with a good integration, those customers shouldn’t even know they’re using it. That being the case, it's weird to ask them to reauthenticate on the checkout page if they’re already logged into your site. FoxyCart's single sign on feature prevents this weirdness by asking your application to acknowledge authentication before the checkout page is displayed. FoxyCart makes a request to your site and your application redirects back to FoxyCart. FoxySync helps with this handshake by providing a helper method to generate the redirect URL.

include FoxySync::Sso
redirect_to sso_url(params, user)

XML Datafeed

FoxyCart's transaction datafeed feature ensures that your application is notified of sale details after each successful checkout. When enabled, FoxyCart will post to your application an encrypted XML document and expect a particular response. FoxySync helps with this feature by handling the XML decryption and providing a helper to generate the appropriate response.

include FoxySync::Datafeed
receipt = []
xml = datafeed_unwrap params
receipt << xml.customer_first_name
receipt << xml.customer_last_name
receipt << xml.receipt_url
# etc

API Communication

FoxyCart has a robust API that lets you manipulate and retrieve data about your store, customers, transactions, and subscriptions. FoxySync makes working with the API dead simple, so you can easily access this powerful feature.

api =
reply = api.customer_get :customer_email => ''
reply.customer_id # is the customer's FoxyCart id

FoxyCart is a great service for adding sophisticated e-commerce to your website without having to do a lot of the hard work. However, FoxyCart still needs to be integrated, and for Ruby on Rails apps, FoxySync makes that pretty easy.