Integration as Composition
Code: Chibrary, composition, design, functional programming, literate programming, pointfree
I’m puzzling over the design for a worker and would appreciate your comments on it. I started with the pain of an ugly test, made an interesting refactoring, and decided to drop the test entirely, but I’m not at all sure this is the right decision.
In my mailing list archive Chibrary, I want to sum up the number of threads and messages in a month to present on archive pages. The
MonthCountWorker takes a
Sym, a unique identifier for a list’s slug + year + month, fetchs the threads for that month, sums them, and stores the sum. The code is trivial, right?:
Two Designs for SequenceIdGenerator
Code: Chibrary, design, object orientation, Ruby, state
In my previous, marathon post on id generation, I mentioned that I was generating unique sequence numbers. It was straightforward to write a class to generate them:
Distributed ID Generation and Bit Packing
Code: bit packing, bit twiddling, Chibrary, concurrency, design, stemwinder
There are two ways for programs to collaborate: they can communicate their shared state or they can partition the work so they don’t need to know each other’s state. As I’ve been rehabbing the code for my mailing list archive Chibrary I ran into this issue, and the design constraints made for an interesting puzzle. I need to generate unique IDs in multiple programs at once, and they need to be short enough to fit in URLs.
Writing is nature’s way of letting you know how sloppy your thinking is.
At more than 3,000 words, this is an unusually long blog post for me. This problem has a lot of considerations to balance (and you’ll see a lot of parenthetical caveats). I like to work through problems by writing out my thoughts, constantly tinkering with possibilities and revisiting ideas in light of new constraints or insight. I thought my (heavily) revised notes might make for an interesting post as I attack the problem from several different approaches and end with a solution that nicely connects theoretical and practical considerations. As a bonus, maybe someone will tell me I’m approaching this all wrong or ignorant of a known best practice for this sort of thing before I go live. With that preamble rambled, let’s dig into the problem.
Extracting Immutable Objects
Code: design, design patterns, email, ListLibrary.net, mailing lists, object orientation, Ruby
In the last few weeks I’ve been rehabilitating some of the first object-oriented code I wrote in the hopes of bringing my mailing list archive back online. Lately I’ve been refactoring some of the earliest, core code: the
Message class. It manages the individual emails in the system and, because I didn’t understand how to extract functionality, had turned into something of a God Class.
Yesterday I tweeted about a really satisfying cleanup:
I liked this blog post Solving vs. Fixing (via). In my first job out of college I did support and maintenance on a medium-sized (250kloc) system that had spent a year looked after by a developer who only fixed things, never solved them. The code had started poor and gotten gotten steadily worse, but I always tried to fix bugs twice and slowly ground out improvements in the system.
I mentioned I’ve learned some rules of how database apps change over time, now that I’ve done a few dozen. They are:
Code: AASM, Bort, ConfReader, design, haml, open_id_authentication, Paperclip, planning, Rails, RailsRumble, resource_this, restful_authentication, RSpec, scheduling, teamwork, web
I failed to launch my Rails Rumble project ConfReader. Why?
This morning, at about 4:30 AM, I awoke and just knew the Right Way to rebuild RegistryPro to be completely reliable, even more compact, and provide meaningful reporting. It would take less than two weeks of coding time and the pitfalls are well-demarcated and avoidable. It would be really great if I’d thought of it two years ago when I still worked there. Thanks, brain.