Inverted Triangle CSS (image from http://www.gpmd.co.uk/blog/scalable-css/) Here’s another great interview / practice podcast that we did. This one is with Table XI front-end developer Aly Fluckey and it’s all about how the Table XI team organizes CSS to best manage the demands of a large code base with lots of styles. We try to avoid common CSS problems, mostly involving having to guess what styles will actually be applied to any given element.
We’re preparing to launch a Table XI podcast, the first episode will probably drop in January. But before that podcast launches, I’d like to share some interviews I’ve done with Table XI developers about the tools and practices they use in their day to day work. This week, we have Ed LaFoy, who is Table XI’s Director of Mobile Development. Table XI’s mobile team does amazing work and uses a lot of external tools for testing, interface design, code quality, and beyond.
This is not _exactly_ what the code in question looked like I had a unique career experience this year. After watching this really quite fantastic RailsConf talk from Katrina Owen, I asked if she’d be interested in doing a full-day refactoring workshop for the Table XI developer team. Katrina agreed, and we decided that she would put together a workshop based on refactoring some of our actual client code. I had just the project in mind, and had her look at some specific examples.
It’s a stream, kind of I was reading the ActiveAdmin docs, as one does, when I read that ActiveAdmin, by default, streams CSV data when you request it from your browser, rather than sending it all in one chunk. This means that the Rails server can start sending the CSV data to the client while the file is still being generated. This can make the response much faster. (True fact, I was reading it for my mega-hot best seller Take My Money: Accepting Payments on The Web.
I love this cover, by the way. My new book, Take My Money: Accepting Payments on the Web, is available today. If you have a Rails application that touches money, this book will help you. I hope that this book will help you build your payment application with less stress and fewer mistakes. Here’s why I wrote it: My favorite books and blog posts to write are the ones that I wish I had been able to read when I was starting a new project.
Yikes! So I was giving my talk at Madison Ruby: Epilogue, or “this really is the last one, we mean it everybody”. Watch the whole talk, about doing HR in small consulting shops. About five minutes in I was making a very incisive point about annual reviews when: Gravity is very effective And suddenly, nobody remembers my incisive point about annual reviews. (Which was, for the record, that editing them for a year is kind of soul-destroying, even if everybody involved is basically nice and good at their jobs.
RSpec has options that will help you see your specs more clearly RSpec is a big library and the way you use it makes a big difference in how efficiently you can run specs. It has a lot of default configuration options that are generated when your application is created, but if your application is older than a few months, it’s likely there are some new and useful configuration options that you might like to add.
All your blocks should have whitespace… After two blog posts where I was very non-doctrinaire about really big topics, today I’m going to be absurdly doctrinaire about something trivial. Yep, it’s The Continuing Adventures of the Person Who Cares A Little Too Much About Whitespace. There are about four things that I do which appear to be different from the work setup of nearly every other developer I’ve ever worked with:
It’s my software stack, with complexity! It’s not an unusual observation that there are two major philosophies about designing Rails applications, sometimes called the “Core” and “Prime” stacks. (Specifically, the name Prime stack comes from Steve Klabnik, though he calls the main stake the “Omakase Stack”, from DHH’s Rails is Omakase post) The Core stack is based on the way the Rails core team recommends Rails should be used, and is how Basecamp uses Rails, at least based on David Heinemeier Hansson’s public descriptions.
The testing cycle goes from red to green to red to green One of Kent Beck’s first articles about unit testing is called Test Infected: Programmers Love Writing Tests. It was written, I think, in 1998. What’s interesting about the Test Infected article is how Kent describes the process: “code a little, test a little, code a little, test a little”. Which is backwards. Or not-backwards, depending on your perspective, but in any case, it’s not the TDD process that Kent would eventually describe in the XP book, among other places.