“We work 60 hours a week for four months to complete the i.c.stars internship,” says Training Program Manager Deborah Cane. “We work with Fortune 500 companies to understand what it means to be a consultant. We work with local venture capitalists to understand what it means to put together a business pitch. We worked with coaches from across the tech spectrum to work on coding from HTML5 to SQL. And at the end of this crazy rollercoaster of learning, Table XI swooped in! Just talking about where your career can go in an atmosphere like this, sitting at the table with people who dream big for a living, gave us the extra boost we need to go out and conquer that job market.”

We were so excited to be able to arm these students with these kinds of tactics as they head into the Chicago workforce, where there are lots of developer jobs to be had. We’re hoping to do more of these types of sessions in the future; in the meantime, keep your eye out for i.c. stars talent.

Mark + i.c. stars Graduates

Mark + i.c. stars Graduates

Mark + i.c. stars Graduates

The 1996 version of me would never believe 2012. I’ve got Linux on my cell phone, we have an African-American (and Chicagoan!) president, but most improbably, I’m preoccupied by software projects centered around a language I used to loathe: JavaScript.

As cool as JavaScript projects can be, you’d never know it from their names. Is it a competition to see who can come up with the least interesting moniker? An unconcious tribute to the ‘Self’ language, one of JavaScript’s original inspirations? Or maybe nobody puts much thought into naming, choosing to channel their creativity into their code?

While pondering that, I came up with my top 11 favorite nondescript JavaScript project names:

11. Prototype

This is the one that got the ball rolling. Named after a universal JavaScript object property, Prototype was the first serious JavaScript library you probably ever used (let’s pretend those “disable right-click so people can’t steal your precious images” scripts never happened). jQuery may have displaced Prototype in the web developer’s toolbox, but its dreary, Google-hostile name choice continues to inspire.

10. Node

Server-side JavaScript was going nowhere until someone gave it a bland enough name. Ever heard of Spidermonkey? Rhino? No? How about Node?

9. Processing

I expect some pushback here since the Processing project is not limited to JavaScript, but the fact that something so very nondescript found a home in the JavaScript community is telling.

8. Seriously

Seriously.

7. Underscore

It could have been worse. At least it’s not called _.

6. js.js

What else are you going to call a JavaScript interpreter written in JavaScript?

5. Coordinate

When I needed to make up a name for a library to add coordinate properties to HTML tables, “Coordinate” just felt right. It was then that I realized awareness did not make me immune.

4. Ease

I Googled “ease javascript” and had to go three pages deep to find a link to this project’s site, and even then it wasn’t its home page! I think this is exactly where Ease wants to be.

3. Three

Rival JavaScript 3-D graphics projects like Scene and Fusion gave it their best shot, but their names can’t beat the flatness of Three.

2. Language

This is almost too on-the-nose to be real. Since JavaScript is a language, if you Google “javascript language”… I think you see where this is going. The developers of this library are laughing at us.

And my number one favorite creatively-challenged JavaScript project name is………

1. Whenever

Nondescript and noncommittal, nothing beats Whenever, at least until “Whatever” emerges. Actually, I believe “Whatever” may already exist, but only on a level of unexceptionality so unspecific that we can’t perceive it. Until then, Whenever.

Sometimes you need a break from the web, though, so we decided to put our architecture skills to the test and build a massively-multiplayer adventure game: Deepworld.

Deepworld features an online, persistent sandbox universe; anyone can jump in to explore, build, or just hang out with friends. It’s very engaging, and also the most technically complicated setup we’ve ever dealt with. We have dozens (soon to be hundreds) of worlds, all hosted across multiple cloud servers, with things like MongoDB, Redis, and various helper apps in the background.

We opted early on to use Ruby to develop our server code—an odd choice to many in the game industry, but something we are very familiar with. It turns out that EventMachine, the very mature Ruby equivalent of Node.js, is quite fast. With it, we’ve designed our own TCP-based protcol, baking in compression, authentication, and tons of other bells and whistles, as well as TCP testing framework on top of RSpec.

We’re in alpha testing phase right now, with a bunch of regular players in the alpha program. They’ve been building an amazing array of structures and are having an awesome time. We also recently held a Table XI playtesting party, which was great fun!

We’ve launched a Deepworld Kickstarter to help us with our final fundraising push, and have just under two weeks to go. Check it out for more info, thanks for your support, and hopefully we’ll see you in the game!

In our early days, we desperately needed people who could wear multiple hats, and our first employees were defined by their abilities to switch deftly among many roles. We relied on people whose job titles could have been “project manager / user interface designer / account manager / salesperson / cultural compass” or, in my case, “CEO / Dishwasher.”

There will always be switch-hitters in this business, but as we’ve grown, we’ve seen increasing advantages to specialization. Today, we’re mostly hiring people who are relatively focused experts in the crafts of graphics design, business analysis, project management, software development, and quality assurance. We’ve found ourselves learning a great deal from these experts, and rapidly advancing our overall productive capabilities.

At the same time, this type of growth breeds new challenges. In the past, we never had to create processes to coordinate interdisciplinary solutions, which bridge the gaps among business strategy, marketing, design, software development, maintenance, and hosting. Now, we’re implementing new processes and systems to make all this coordination and cross-disciplinary management easier.

Throughout this progress, we’re working extremely hard to maintain the personal touch that our clients expect and deserve. These are all new and exciting challenges for those of us who’ve been around for a long time, and it’s a big part of what keeps life interesting after all these years.

We’re always on the lookout for good people. Visit our job listings to find out more.

Node.js has been getting a lot of buzz recently, but you’re probably in the minority if you have a good idea of how it works and what it’s good for. Node is a server-side JavaScript engine. It takes advantage of the event-driven programming model of JavaScript for use on the server-side. You’re probably familiar with binding JavaScript handlers to client-side events like button clicks, mouseovers, etc. Node allows you to bind functionality to server-side events like a new connection being made or data being received. Node is non-blocking, so it can handle a large number of concurrent connections on the same machine.

Here are a few practical applications of Node.js:

A Successful Web Front-End Refactor

Klout is a company that measures people’s influence based on their activity in social media. We make use of their API at Table XI. Klout was powering a web interface to give users access to their scores with a LAMP (Linux/Apache/MySQL/PHP) stack. They found this was not scaling well as more users accessed the application. They rebuilt this interface using Node.js., and it’s now handling tens of thousands of concurrent users on two servers.

Read more: “The Tech Behind Klout.com”

An API

The social media site Yammer is using Node.js to handle API requests from developers, allowing them to tackle a large capacity of concurrent requests. The API requests are made via JavaScript AJAX calls so both the client and server side are written in the same language.

Read more: “Who Is Using Node.js and Why? Yammer, Boucoup, Proxlet and Yahoo”

Application Metrics

Etsy is using Node.js to push application data to Graphite to produce near real-time graphs of metrics such as login failures. They are using a daemon called StatsD to listen for messages, parse out the metrics, and periodically send the data to Graphite. Node.js’ event-driven programing model lent itself well to this problem.

Read more: “Measure Anything, Measure Everything”

A Fun Example

NodeMap is a real-time app that displays messages from around the world on a map written by Vijay Rawat. It’s a neat way to see Node.js in action.

Read more: Vijay Rawat on Github

Is Node.js for Table XI?

We’re not currently Node.js, but we may find it useful for upcoming projects including an API integration with mobile apps.

Read More:

“Just What Is Node.js?”

“How to Install Node.js”

“Managing Callback ‘Spaghetti’ in Node.js”

$("#foo").click(function () {

bar( "some text #{ something / 2 } a unit" );

});

is more cleanly written as this:

$("#foo").click ->

bar("some text " + something / 2 + "a unit" )

But as I’ve been writing more JavaScript, there are a handful of other neat things I find myself using a lot. Here are a few:

Case

This is a little one, but the switch statement in CoffeeScript is just so nice it’s one of the first things I go to when rewriting old JavaScript. Not only can you rewrite:

if (foo === bar) {

value = thing_one();

} elsif (foo === baz) {

value = another_thing();

} else {

value = somthing_else()

}

as the somewhat terser:

switch foo

when bar then value = thing_one()

when baz then value = another_thing()

else value = somthing_else()

but, since everything is an expression in CoffeeScript, you can just make that:

 value = switch foo

when bar then one_thing()

when baz then another_thing()

else something_else()

The Fat Arrow

The fat arrow (=>) also cleans up a lot. When you use it in an object, that function will be bound to the scope of its caller, which means that you can do something like:

$("p").click ->

    setTimeout (=>

    $(this).hide()

), 10000

Class

Where CoffeeScript really shines is when you start making new classes. I’ve found myself shying away from OO in JavaScript before, because it’s kind of unusual and has a lot of pitfalls. CoffeeScript makes JavaScript’s object and inheritance system useable and fun.

Take this highly contrived example:

class Person

act: (name, action) ->

    action.call()

 

class Child extends Person

act: (name, action) ->

if name == "Drink" and @is_good # the same as this.is_good

alert "No thanks"

else

super name, action

 

f = new Child

f.is_good = false

f.act "Drink", ->

alert "glug glug glug"

The class and super keywords make this so painless, you have no excuse not to write pretty Object Oriented JS in all your projects.

There is tons more to see at Coffeescript.org. What you’ll find, as you start rewriting code into CoffeeScript, is that it really makes the cool parts of JavaScript pop out. If you still haven’t gotten your fill, you can check out underscore.js and backbone.js, both, like CoffeeScript, by the incredibly talented and prolific Jeremy Ashkenas.

So, for many, the question is not, Should I blog? but rather, What do I write about?

Search Engine Optimization (SEO)

One of your blog’s most valuable (and commonly overlooked) functions is its ability to impact SEO, since it gives your site a venue for fresh, keyword-rich content. Whereas homepages or product pages can be difficult to update with detailed copy, a blog allows you to tell a longer narrative that can positively impact your ability to rank for key terms.

We recently conducted a workshop for guests from Chicago’s Neighborhood Parents Network that was dedicated to the importance of blogging for SEO. Here are some of the free tools we recommended that can help you get the most SEO lift from your blog:

• Google Keyword Tool: The big daddy of search introduced this service to approximate search volume and supporting longtail keyword ideas. These words can be used to inform blog topics as well as refine your primary and secondary keyword sets. Once you’ve identified your keywords, make sure to include them in your H1 (headline), H2 (subtitle), and page title tags.

• UberSuggest: This tool recommends keyword opportunities based on real user queries. You can use these keywords and phrases to get inspiration for your next blog post topic or to expand article ideas.

• MyBlogGuest: Linkbuilding is important because it adds credibility to your post and can help drive traffic, but it’s often abused by people writing thin, irrelevant content. MyBlogGuest matches bloggers with quality guest posters and vice versa. The website provides a level of screening and management for guest blogging, and partners you with someone with whom there is a mutually beneficial SEO relationship. (For more on this, and to find other resources on linkbuilding, check out this recent article in Search Engine Watch.)

Keep It Fresh

In addition to helping SEO, blogs are an easy way to feed your website new content, which triggers search engines to crawl your site more frequently. If there were any doubt about the importance of updating your site, Google’s “Freshness” algorithm has drilled the concept home. This update factors recency into the search algorithm as an indicator of relevance. For example, if I’m looking for information about The Taste of Chicago, I want to see this year’s schedule of events, not information from last year. Google will try to display the most recently updated link first.

Granted, boosting your blog rank takes time: SEO is a nuanced practice involving research, testing, and data analysis. But if you’ve already got a blog, start making the most of it…starting now.

If you have more questions about optimizing your blog, drop us a line. We’d love to help!

I caught several good presentations which I feel would be valuable for all developers regardless of their choice of tools (read on for some of my notes below); however, with five talks going on simultaneously for three straight days, I’m sure I missed some great sessions that would have been more applicable to both Python and Ruby. What’d I miss? What talks did you like? Leave your thoughts in the comments or drop me a line at ross@tablexi.com.

All formal talks given at PyCon are recorded and have been posted @ http://pyvideo.org so you can tune in even if you couldn’t attend. I’d definitely recommend checking out the following talks:

1. Stop Writing Classes – Jack Diederich

Takeaways:

• Excess classes = more cost (code costs time to make and time to maintain)
• Namespaces are for preventing namespace collisions, NOT for creating taxonomies
• When coming up with exceptions, try to find one in stdlib first! (165 in python’s stdlib: there’s probably already one which fits your purpose)
• Classes make sense for holding & validating related data but remember KISS

Reflections:

• This happened all the time when I was doing Java for a living (for Steve Yegge’s fine description of the situation in Java, see: “Execution in the Kingdom of Nouns”)
• I’m guilty of this in a couple api-wrappers I’ve built for third party services
• This would be one of the reasons why they’re not open source yet
• Fortunately only one consumer (another app I wrote) so api evolution can happen as needed (not all gem writers are so lucky)

2. Pragmatic Unicode, or, How do I stop the pain? – Ned Batchelder

(Description)

Takeaways:

• Unicode is here to stay
• Unless you learn, you’ll get bitten
• Don’t just use libraries: Know what they’re doing and test them to make sure they do what they say they’ll do
• Build app as unicode sandwich
• Translate at the outside layers of your program (persistence layer and standardize on one format (unicode strings) in your code)
• Test with unicode strings

Reflections:

• Haven’t personally been bitten by text / unicode within core Ruby itself (mercifully haven’t had to dive too deeply into how Ruby handles this stuff); Rails (3) seems to encode/decode input from a browser quite well
• Be very careful of your persistence layer for your backend
• My particular experience: MySQL
• The mysql gem’s default encoding on a connection to mysql = latin1
• Result: When we switched to the mysql2 gem (which uses utf8 as the character set for a connection by default) we discovered issues in our database (utf8 characters that had been wrongly put through MySQL’s latin1->utf-8 conversion) which needed to be fixed
• Thorough writeup on the subject: “Getting out of MySQL Character Set Hell” by Nathan Kaiser

3. Certainty in an Uncertain World: Gaining Confidence through Security Testing – Geremy Condra

(Description)

Takeaways:

• CWE/SANS Top 25 list: check for these and you’re WAY ahead of the game
• fuzzdb for input test cases
• xsser checking for XSS vulnerabilities

Reflections:

• Security should always be a concern when the app is public. Even when it’s not, and the app is just for internal use, I generally:
• –Don’t allow anonymous users to change things (they must login and only admins can create users)
• –”Never attribute to malice that which is adequately explained by [ignorance]” — Hanlon’s Razor
• Just because the client is reasonably sure their users aren’t malicious:
• –Don’t allow admin users to change things that will break the main site functionality
• –Have validations, be strict with them, and test them
• In the past, we used attr_protected liberally on attributes/columns that identify parent records to mass assignment abuse
• Foreign keys on the same
• Moving forward, we should probably just be using attr_accessible on fields that we know we want to mass assign.
• –Higher maintenance code
• –More reasonable expectation of security (same rules apply for admin users of the public websites we produce)
• Rails protections I’m aware of that protect against things on the top 25 list (and have checked out myself in the time I’ve been working here):
• –CSRF: this is something they’re careful with but flaws have been found from time to time
• –XSS (we use Haml for views where all output is escaped by default and try not to show things unescaped)
• –Avoiding SQL Injection:
• *Always pass arguments to .where() (hash or otherwise—NEVER use string interpolation in a where clause); I believe this will use db-level bind variables and escape things appropriately
• *If you offload sorting / grouping to the db, have a whitelist for things that could end up in an ORDER BY or GROUP BY in those clauses and check against it (I don’t think Rails/ActiveRecord escapes these, and thus potential for sql injection still exists)

Don’t Take My Word For It…. Test your Applications heavily!

Here’s some further reading:

2011 CWE/SANS Top 25 Most Dangerous Software Errors
Rails Security Guide

Today, our very first client is still with us, and our staff comprises several people who have been here since the start (or near to it). It’s these kind of lasting relationships that we’re most proud of, along with the cool and innovative work we’ve gotten to do along the way.

Part of the founding ethos of Table XI was that creating an inviting company culture would bring us the best developers. Over the years we’ve introduced daily perks like flexible hours and lunches (catered in-house), plus bigger benefits like retreats to Costa Rica, where we can simultaneously have fun, get to know each other better, and work on interesting company projects. It’s an investment that has brought us incredibly talented people and allowed us to expand our client base and business—the proverbial win-win.

So what’s next for us? Our time in Costa Rica gave some smart people time to work on smart ideas and get experience with new platforms. We’ll foster more of that, while continuing to figure out how to recruit and retain the best talent and apply their skills to the newest technologies. With the industry focusing on social apps and mobile optimized products, we’ll be doing a lot more work in those areas.

We’re incredibly proud of our achievements, and that we were able to make it through the last decade’s tough times without having to cut back on people or benefits. We’d like to thank our clients and employees for helping us get here, and we can’t wait to see what the next ten years will bring.

1. Contrary to popular belief, developers are not allergic to sunlight.
2. Hammocks make good desks.
3. A day iterating on Facebook’s API is a day well spent.
4. When you want a good photo, ask a Schwartz.
5. Jason Pearl builds cloud-based games and Imperial pyramids with equal levels of dedication and ingenuity.
6. Chef Aram has ninja knife skills. And now we all know how to chop an onion properly.
7. Just say no to traveling on the day two major airlines merge.
8. Just say yes when someone asks you if you have a phone in your pocket before they throw you in the water.
9. Meetings are more fun when they happen in pools.
10. The two rarest things to see in the wild: sloths and a John Gore smile.

Contrary to popular belief, developers are not allergic to sunlight.

Hammocks make good desks.

A day iterating on Facebook's API is a day well spent.

When you want a good photo, ask a Schwartz.

Jason Pearl builds cloud-based games and Imperial pyramids with equal levels of dedication and ingenuity.

Chef Aram has ninja knife skills. And now we all know how to chop an onion properly.

Just say no to traveling on the day two major airlines merge.

Just say yes when someone asks you if you have a phone in your pocket before they throw you in the water.

Meetings are more fun when they happen in pools.

The two rarest things to see in the wild: sloths and a John Gore smile.