Don't get me wrong - I always have fun discussions with Ruby conference attendees. But I've been especially impressed with the attendees here, both the New England locals and the out-of-towners that flew in. The folks I've talked to worked in a variety of industries like healthcare, biotech, and in consumer startups. I've also talked to folks working in really diverse teams, from one person to one hundred.
Here are some summaries and slide links for a few of my favorite presentations.
Opening Keynote
Sandi Metz
 |
| Photo Credit: @wickedgoodruby |
This was a compelling keynote that drew parallels between the software engineers of today and the typesetters in the newspaper industry decades ago. Both are stewards of the information age, so to speak, enabling the public to access huge amounts of information. The exact skill sets of both change and are frequently made obsolete. Sandi touched on some truly epic subjects, like getting satisfaction out of life, making every day cont, and embracing the impermanence of both career and life. As with most keynotes, it was grand in scope and depended heavily on the stage presence of the speaker. Sandi kept everyone engaged and I enjoyed it.
Wicked Bad Ruby
Matt Aimonetti
Slides
Matt's talk focused on the concepts of "good" and "bad" code, and what that means for developers. Matt's first point was that there is no such thing as "bad" code, as discussions of "good" versus "bad" are generally relegated to philosophy, ethics and the like. Matt states that code simply works or doesn't.
Along the same lines, developers aren't paid to write good code, they're paid to deliver great products. Matt advised the audience to understand what they're building - the business objectives, the timeline, the proposition value, the players, and the risk factors. Often, the right move isn't the generally-accepted best practice. Oftren, folks proclaiming "you're doing it wrong" don't understand the full context.
Taking a step back, Matt observed that we judge other people all the time, but we don't like to be judged ourselves. As developers, we make rules because of what we perceive we do well, and we think they always apply directly to other people. In other words, "you're doing it wrong because you did it differently than I did."
To sum things up, Matt recommended that we focus on the outcome while learning and improving. As he said, don't think as much about HOW you write the code, think about WHY. All in all, I really like this code craft-focused talk.
PEACE: Program Expertly in Corporations and Enterprises
Steven Haddox
Slides
This was a practical presentation about how to be a productive agile developer in enterprise (i.e. corporate) environments. Steve gave a lot of great advice here, and having consulted in the enterprise myself, many things really resonated with me. The presentation could be summed up thusly:
When working in the enterprise, fight for the following things, in order, until you run out of political capital:
1. Agile project management (and do a one month trial if you don't get buy-in)
2. Provisioned dev, staging and production servers
3. Key-based authentication
4. SCM
5. Issue tracking
6. Documentation/wiki
7. Error monitoring
I'm not sure if I got the ordering exactly right, but agile project management is definitely #1. :)
Naming is Hard
John Yurek
Slides
In this talk, John explored why naming things is difficult in programming. To quote Phil Karlton, "There are only two hard things in Computer Science: Cache invalidation and naming things."
Through some good examples and open discussion, John brought up some great points:
- If you can't name it, it's probably wrong.
- If a method has one primary function, it's easier to name.
- In longer methods, you should extract functionality into aptly-named private methods.
- The act of refactoring and extracting code reveals that code's meaning and intent.
- A test's name should be its justification, not a description of "what" the code does.
As with most of the Thoughtbot talks I've seen, this one had to do with "code as craft." It was a very good mix of both actionable advice and some general topics of reflection for software developers.
Market Analytics in Eve with Ruby
Doug Alcorn
Video (older version of talk)
Doug gave a very entertaining talk about Eve online, a MMORPG with a complex virtual economy. Eve has about 500,000 active accounts, and 30,000-60,000 players online at any one time.
Doug went over some basic information about game mechanics, types of players, and went through some interesting examples of gameplay.
Doug then went into detail on the deep player-driven economy, which is the "bedrock" of the game. Many economists, academics, and virtual traders actually play Eve primarily for the deep virtual economy, and the game's "Chief Economist," employed by CCP Games, is actually an Economics PhD.
Doug gave lots of examples of how items are traded in-game, and then discussed the huge amount of offline data that Eve makes available to players. CCP publishes a large REST API and allows users to scrape the in-game cache for information about item prices and upload to a third-party analytics site. This "cache scraping" is quasi-legal in the Eve world (it's not a bannable offense in itself, but it can contribute to other offenses); lots of players do it upload results to a third-party site to product accurate, real-time market data.
Doug went through some of the Ruby code he's written (namely, a Rails app) to pull in the latest market data, delete the stale data, and analyze the results. I got a chance to speak with Doug for a bit after the presentation, and he talked in more detail about the performance of his Rails application, hosting, and the Eve community in general. It was great to hear about Ruby in the context of online gaming, something we don't experience very often!
Towards Tooling; A Look at what is Missing from our Toolbox
Loren Segal
[Slides Unavailable]
In this talk, Loren discussed tooling in the Ruby language community. He first discussed tooling at a high level, talked briefly about tools that the Ruby community is good at, and finally explored areas where the Ruby community could improve.
Loren's observation: Humans have basically gotten to where they are because of their intellect and tooling. Tooling allows humans to become more efficient and build off the successes of previous generations.
Deployment, ops, testing: These are very good in Ruby.
Visualization, debugging, linting, static analysis: Ruby could be much better.
Loren pointed out that debugging front-end web development in say, Firebug or Chrome inspector, is inherently visual, and works well. Visual Studio has good tools like this, letting programmers visualize the entire call stack and easily trace execution. Ruby needs better tools to this end.
Loren briefly discussed some code complexity analysis tools, such as reek, flog and flay. These detect "code smells" but not common errors. This is in the domain of static analysis, which is lacking in the Ruby world.
Overall
This was a great conference, and even as a local, I'm continually impressed with the skills of developers in the New England area. If you have any of your own summaries or links to video from WGR Conf, let me know!
No comments:
Post a Comment