Last month I attended Wordcamp Richmond and saw a great presentation by Christopher Gatewood entitled The Seven Business Pitfalls for Wordpress and Web Professionals. The talk was informative enough that I took copious notes, and I'm publishing them in the hopes that others will benefit. I've since gotten Chris to help me draft some agreements and can tell you he's a great resource for this kind of stuff.
Read more...
Scaling Up Without Growing
Where the Entrepreneur, the Consortium, and the Union Meet
I had a great time visiting my good friend Jim in Charlotte this past weekend while the wives were selling crafts at the Country Living show in Atlanta. Many hijinks ensued, but one of the most rewarding was our discussion of different approaches to co-working, as well as expansions on the concept that could redefine how we work. We come at the conversation from two different angles, and I want to give Jim the opportunity to explain his vision, so I won't go into too much detail about his particular suggestions.
It suffices to say that Jim has been co-working at a local space for some time now. Where he sees opportunity is in an organization that could take care of the administration - invoicing, taxes, space provisioning - leaving freelancers, small proprietors, and other independent developers free to pursue their business. The organization could be run on the mutual model, where all the "clients" are owners.
I'm intrigued by this idea, but I want to skin a slightly different cat. My experience of co-working has been quite different due to Richmond's lack of a dedicated space for it. Our group has had to be more ad hoc, using Twitter and Google Groups to spontaneously organize meetings at local coffee shops on an irregular basis. Everything I've read on starting a co-working venue stresses the need to build the community first, rather than getting the location and expecting people to come to it.
Read more...
Treeoid
Tree hierarchies for your Mongoid::Document objects
I'm a bit late mentioning this, but I released another super-beta gem in the hopes it might help another poor soul: treeoid, the missing "acts_as_tree" library for mongoid. It couldn't be simpler, really: it gives you a "parent" accessor and a "children" collection. On top of that, it provides a scope allowing you to list a set of treeoid objects in hierarchical order, which is perfect for front end integration.
The tests are there but nominal; I'd love to see them fleshed out. I also had some ideas for making it cooler; for example, I keep an array of an object's descendants in the object, allowing me to hierarchically order objects. This opens up some novel means to simplify how I implement the parent and children accessor. Imagine this:
field :ancestry, type => Array # contains ids of all ancestors including self, already exists
# but instead of a parent_id accessor
def parent_id
ancestry.at(-2) # the parent can be fetched from the ancestry list
end
This also allows all descendants of a given object to be easily fetched - if the id shows up in the ancestry, return it! It's this kind of out-of-the-box thinking that has really endeared MongoDB to me. I hope you can benefit from this and help me improve it. Or help with greedy. I'd love to get said help at CVREG's upcoming Why Day hackfest.
RailsConf Dispatch - Test Always?
How not thinking carefully about your test suite can hold you back
There were two conveniently sequential presentations today at RailsConf that reminded me of some thoughts I'd had regarding testing: Michael Feathers' talk on legacy code and Glenn Vanderberg's talk on real software engineering. It seems to me that both talks had a theme in common: what is the function of tests? Why do we want them, what role do they play from an engineering perspective in the larger process, and what precisely are they meant to indicate to us?
Michael at one point talked about the expense of 100% code coverage for tests, instead recommending we test the parts of the code that change the least and are most important. Ugly code in legacy projects has utility, he explained, and untested code is a rational response to churn. Afterwards, Glenn discussed software development in the context of engineering principles from older, more established disciplines like structural engineering, finding areas of similarity, analogy, and abject difference. However, his testing point compared experiments in code to experiments in more physical engineering fields, remarking on how relatively cheap tests are for us. I suppose the common thread I found concerned the emphasis on cost: that what it means for us to do our job well is to do it effectively, and not subordinate our conscience and creativity to a mechanical process.
For some background, I've been practicing behavior driven development for a year or two. I love the confidence that testing gives me, independent of the value to the client. Verifying that my code works is fine and all, but what lets me sleep at night is the assurance derived from approaching a problem in a rational, systemic manner. By moving in small chunks and expressing problems in terms I understand well enough to programmatically recreate, I ground myself in a real comprehension of the system I'm building at the most relevant level and stage. I avoid the confusion of jumping ahead, thinking too large scale or minutely, or making unwarranted assumptions that come back to bite.
Read more...
The first tutorial class at RailsConf on Rails Anti-Patterns has been phenomenal and incredibly validating given my experiences with consulting. Tammer Saleh gave a wonderful talk on how to handle troubled legacy codebases - what he calls "rescue missions". It's particularly relevant for me as much of my early freelance work centered on failing projects I was dumped into.
Because of the success of Rails, there's a lot of shitty code out there for you to fix. The harder issue is figuring out why shitty code was delivered, which can be trickier to figure out than you'd think. It can be really difficult to change the course of a project when much more than merely the code is dysfunctional.
Tammer suggested a ton of coping strategies, many of which end up being good practices for most situations. I'm sharing my cursory notes here in case others are interested. Feel free to strike up a conversation in the comments to explore these points. I'll link to the slides when they become available.
Read more...
If acts_as_enumerated classes are borking when you run your tests, here's a nasty workaround I did that just might work for you:
class MembershipStatus < ActiveRecord::Base
if RAILS_ENV == 'test'
def self.[](label)
case label
when :pending
MembershipStatus.new(:id => 1)
when :accepted
MembershipStatus.new(:id => 2)
when :denied
MembershipStatus.new(:id => 3)
when :invited
MembershipStatus.new(:id => 4)
end
end
else
acts_as_enumerated
end
end
