I have about an hour before the November STL ALT.NET meetup begins, so I thought I would quickly jot down some things on which I have been stewing for the last few months, not because I think you will find them particularly interesting but because writing is therapeutic and often leads to greater clarity of thought.
Who I follow on Twitter, and why
I recently spent some time organizing my twitter feed into lists and browsing Twitter’s “follow” recommendations. Before I follow someone, I browse their current tweets to see if I am interested in what they are saying. I like people who are focused with their content. When I look at a person’s tweets, there is some threshold that I have–some content litmus test that I use–to determine if the bulk of what they write on Twitter is valuable enough for me to follow them. For developers, it boils down to: how much do you tweet about development, or development-related topics? If I glance at a Twitter stream and the bulk of what I see is not related to development, I probably won’t follow the Tweeter. (Is that even a noun?) Another criteria I have is the quality of content people retweet or link to. Twitter can be a tremendous place to find great articles, blog posts, open source projects, etc., but not all content is created equal, and I consider trivial links or retweets to be a form of spam. But again, I have a personal standard for judging what is “trivial” that other people might not agree with.
I would be interested to hear from others who also screen potential Twitter follows, and what methods or standards they use.
I’m not learning Rails
I attended two Ruby conferences this year: Ruby Hoedown and Ruby Midwest. I thoroughly enjoyed myself at both conferences, and I learned a lot. I enjoy Ruby as a language. We use Rake at work, and I enjoy writing Ruby code to make my build tasks easier. Rails is a powerful framework for RAD development, and the sheer volume of helpful gems that are available for Rails is quite impressive. The reason I am not going to learn Rails, however, has nothing to do with the quality of the Ruby language or the Rails framework or the Ruby community (which is fantastic). After stewing for quite some time on my dissatisfaction (or rather, disinterest) in Rails development, I came to a point of self-realization.
I don’t want to learn Rails because I don’t want to write CRUD applications. And Rails is a framework targeted specifically at CRUD developers.
Can you use Rails in a non-CRUD oriented way? Yes–but a significant portion of Rails gems, websites, articles, discussion boards, videos, books, etc. are all CRUD-centric; only a precious few breach convention. And most Rails developers see this strong CRUD emphasis as a feature, and indeed they should, because Rails solves many problems quite elegantly; it is the right tool for many jobs.
So, Rails, it’s not you–it’s me.
I really want to become better at domain modeling
My real passion–one that has been developing for several years in the quiet recesses of my frontal lobe–is domain modeling. The technologies and methods to which I find myself attracted (Domain Driven Design, CQRS, etc.) are all concerned primarily with encapsulating domain logic and separating it from implementation details like persistence, the user interface, remote services, etc. This stands in direct contrast to common CRUD methodologies which often wed, for the sake of expediency and conceptual simplicity, “domain classes” and the UI, persistence, and/or service layers. Both models have trade-offs. But I have been programming in a (more-or-less) CRUD-oriented way for years now, and I want to grow beyond that.
The distinction between these two modes of development became very clear to me at Ruby Midwest, where I watched Uncle Bob give a presentation on this very topic. I realized that (from what I have seen) this discipline is fairly neglected in general business development. Maybe it is just assumed that developers have this knowledge already. I suspect, however, that the familiar nature of CRUD, and the quick gains it achieves in the short-term are the real justifications reasons why most projects start–and remain–CRUD-centric.
As I work through this gradual shift in my development paradigm over the next few years, I will write more about the things I discover.
As always, I’m interested in feedback. Give me your opinions. Really, I can take it (with scotch, on the rocks).