Let me work on-site for you! (For a few days…)
I’ve been tossing this idea around for a while, but now I’m at a point where I can actually do it thanks to things in life and business stabilizing a bit. I like to travel, I like work, and I’ve been wanting to hang out with more people in person (sitting in my office alone is great most of the time but other times it bites!), so I figure why not combine the three?
The deal
I come to your office and work for you for any number of days (up to 5) at a flat rate. I’ll hack on code, train your developers, pair program, fold your laundry, up vote all your Hacker News posts, make coffee, conduct dramatic readings from the Gang of Four book, whatever you want me to do. The options are (nearly) limitless.
If you want just 1 day, that’s OK. I plan on giving everyone a good chunk of time before hand to familiarize myself with the code, their business, what they’ll be needing, and so on. I’m not going to walk in on the first day with no clue about your business, spend 6 hours learning stuff, 1 hour contributing, and another hour telling jokes about airline peanuts.
The fee right now will be $2,000 per day, which is basically what I charge for 2 days of time right now at $125/hour. To be clear: I give you a (basically) a day’s worth of time off-site reading documentation, talking to your team, looking at your code, getting familiar with your needs and a day on-site actually doing the work. So, basically you’ll be paying what I charge for remote work, except, you know, on-site. This rate might go up in the next round, I don’t know, but since this is sort of an experiment, I figured I’d just stick with what works right now.
When and how?
Well, I don’t know when exactly. My plan is to go to San Francisco for a week sometime soon and work at least 4 of the days of the week. I’m also considering a run in New York City. If you want 4-5 days, we can work something out where I make a special trip just for you (possibly even to places not in NYC or SF, but we’ll have to talk about that :)), but if you want fewer, we’ll have to try to coordinate dates with others who want fewer also.
So, if you’re a company in San Francisco or New York City and could use a little extra Ruby, Rails, iPhone, or whatever muscle, then get in touch.
Bad (or, my unfortunately unfavorable review of Bob Martin’s Ruby Midwest keynote)
Uncle Bob Martin has had a lot of influence on the software development industry over his career. His books are heralded as “landmark” and “essential tome[s].” He is credited as “legendary” (ugh) in his author biography on Amazon. I don’t doubt that he’s an incredibly smart guy from what I’ve read from him. Some of his articles are fantastic reads. But I think perhaps either I haven’t read enough to get a real impression of him, or the conference talk I recently had a chance to watch is significantly more dishonest than his writing for some reason.
I was wandering down a rabbit hole of Twitter/Hacker News discussion, and I kept seeing people linking to his keynote video from Ruby Midwest 2011 as a “very important talk to watch.” I’d sat through at least one (possibly more) of his conference talks before without paying much attention (I unfortunately often find it hard to focus on conference talks), really liked what I heard at his RailsConf 2009 keynote (missed his 2010 one), and since this particular talk was relevant to what I was reading at the time, I figured I’d give it a more attentive watch.
I realize I’m probably going to tick off a lot of people here, but what I heard was seriously troubling. (There’s that and he took time to correct everyone else’s talks at the start of his talk, so I figured turnabout is fair play. :))
I’d heard his talks described as “sermons” before, but I never realized how hand wavey they could be at times (at least this particular one). I had to watch it 3 times to get at his main point, which still (to my ears) doesn’t really have any evidence behind it or meat to it outside of “Uncle Bob says.” Even worse, as I was listening, I kept getting angrier by the minute at the gross mischaracterizations or downright mistruths he was spouting. The following list is just a collection of things I caught on my first couple of listens. Maybe there are more in there, but these were glaring enough to catch my attention.
Assertion: Architecture is about intent, and intent should be evident when looking at a software project, so the Rails directory layout sucks. (around 11:00)
He led everyone to this point by showing them blueprints of buildings, indicating that a building’s purpose should be and is evident by how it is architected. From this, he then makes the logical leap that this should absolutely be true of software, and that when you look at the top level directory of a project, the architecture should be evident, not the framework. His criticism is that when you look at a Rails application’s directories and files, you can readily see it’s a Rails application but not what the application actually does.
Disregarding the fact that having standardized file placement driven by the framework is one of the biggest wins for development teams when using a framework, that’s one of the most bizarre criticisms I have ever heard in a conference talk. I have never in my career worked on a project where I could simply glance at the file layout and discern exactly what the application does. Heck, even in things like XCode or Visual Studio, where one can have a logical layout of the files with smart groupings, I haven’t been able to do that.
The better question is: why would you need to? You’re a developer. You’re going to be building the project out, so you’ll figure out what the app does soon enough. What is more convenient for you: a gangly file layout/”architecture” that is non-standardized, annoying to navigate, and requires documentation for others to navigate or something standard that makes your locating files and important logic in those files that much easier? And even so, as his argument indicates even, file layout doesn’t speak to the functionality of the application. You could just as easily follow his suggestions but put different, unrelated code in the files, and you’d be in a worse position. It’s a foolish, silly criticism that probably sounded better on paper than when it came out in the talk.
The worst part was that at around 28:00 he advocates an alternative directory structure based on the architecture he’s describing in the talk, which has names that are just as or even more opaque: interactors, entities, and so on. He also suggests you’d have interactor files named after use cases (e.g., create_order.rb, fill_order.rb, etc.); I would personally kill myself if I had to navigate a huge project in this structure. I get the idea here, but is the ability to quickly sort of discern what an application does worth making your developer’s life a miserable existence during the other 99.9% of the project? Who would want to figure out in which of the 500 use case files that this particular piece lived in? Nobody, that’s who. This point was one part of the talk where he totally lost me in terms of what he was actually trying to say other than “I needed 5 more minutes of material and this seems like a good place to start the rest of my arguments from.”
Assertion: Views should know nothing about the business objects. (Around 32:15)
Perhaps that’s his opinion on things, but if we’re going to appeal to MVC’s origins and go by standard, accepted definitions, that assertion is just patently false according to much of the authoritative MVC documentation. For example, in the paper where the terminology is finalized for MVC dated December 10, 1979, Reenskaug writes in reference to views and how they get or update data in models:
A view is attached to its model (or model part) and gets the data necessary for the presentation from the model by asking questions. It may also update the model by sending appropriate messages. All these questions and messages have to be in the terminology of the model, the view will therefore have to know the semantics of the attributes of the model it represents. (It may, for example, ask for the model’s identifier and expect an instance of Text, it may not assume that the model is of class Text.)
In the original vision of MVC, the model, view, and controller were separated but communicative. A view can ask request data (or update a model (Heaven forbid!), an action which he derides at about 31:45) as needed for its functionality (so long as it doesn’t violate its role in the triad). Acting as if a view should be and always has been a “stupid piece of tiny code” that is simply feed flat data that it renders is false.
Assertion: You should have “hundreds” of views, not just one view. (Around 30:30)
Again, he harkens back to MVC’s roots and asserts that the Rails way of having one view (the page) is wrong, and according to the original plan, you should have hundreds of views, so MVC is a flawed model for doing things on the web. And again, he is incorrect.
Quoting from How to Use Model-View-Controller, a paper describing the original implementation of MVC in Smalltalk:
Views are designed to be nested. Most windows in fact involve at least two views, one nested inside the other. The outermost view, known as the topView is an instance of StandardSystemView or one of its subClasses.
In the original Smalltalk environments, having an overarching, top-level view for the M-V-C slice you were working with was common (and likely required in most situations). If we envision the page to be the same “object” as a window in the original implementation (which I believe is how it should be viewed), then the pattern fits quite well, especially since partials (and cells if we want to follow his assertion that all views should have an M-C piece to them) provide the same subview functionality. This fact is especially true if we get over the whole notion that the MVC pattern is a totally defined, prescribed Pattern™ that you must adhere to religiously and unwaveringly and instead take it for what it is, which is a loosely defined pattern that describes a way to reduce and manage complexity in systems (post coming about that attitude tomorrow…).
Assertion: Point of writing tests first is to avoid coverage gaps (or just about anything else he said about TDD in the talk).
A lot of his tangent into TDD starting at around 58:00 was silly. First, he asserts that writing tests after the fact is “a waste of time.” Granted, you’re more likely to miss some coverage if you do only that, but who doesn’t write quite a few tests after the implementation? Lay down a solid, basic set of tests covering what you’re writing, then go back and cover the edge cases when you have a clearer picture of the logic and its interactions with other pieces of the system. It’s stupid to act as if writing any tests after the implementation is useless.
Secondly, he asserts that the reason everyone TDD’s is to avoid coverage gaps. Now, I don’t know what sort of Magic Double Dream Hands TDD™ he’s doing, but the only “coverage” gains you’re making by TDD’ing are the kind that don’t matter (i.e., numbers not quality). That’s great that you have 100% coverage, but are your tests actually robust? And, even further, if you’re requiring 100% coverage, are you over-testing things? (If I see a unit test for the existence of an attr_accessor or a constant value one more time, I will scream) These questions don’t seem to faze him however. TDD’ing leads to perfect coverage, which, of course, means impeccable quality tests! </sarcasm>
Assertion: MVC is meant to be used in the small, so Rails does it wrong. (Around 31:30)
This was probably the most frustrating point in the whole talk. He twists and contorts MVC’s role in a Rails application and then muddles the terms of architecture pattern and design pattern to forge a point that Rails usage of MVC is inherently flawed according to how the inventor intended the pattern to be used.
Yes, as he asserts, MVC is meant to be used “in the small” in the sense that it takes one slice of your application, separates its concerns, and then lets you independently manage the complexity of those concerns. He is correct in that it is not necessarily an architecture pattern. But his diagram of how a Rails app looks versus this architecture he’s discussing in the talk is just simply disingenuous.
https://img.skitch.com/20111231-n9qswtxgswfmmb1qq1qgj6c75y.jpg
Not only does he conveniently rearrange the pieces so that it seems disjointed, he also completely pulls it out of the proper place in the architecture diagram to make it seem sloppier than it really is.
Even further, Rails uses MVC in the exact way that the original creator of the pattern intended it to be used. It doesn’t use MVC to handle the entire cycle of interaction in the applicatio (f.e., it doesn’t treat the web as part of the MVC mechanism). When a request comes in (i.e., user input), the input is passed to the controller, which decides what should be done with it, how models should be updated, and which views should be rendered for that particular input from a view. This is nearly exactly how it’s done in Smalltalk, exactly how it’s been done in nearly every other implementation of MVC, and this is exactly the “small” that it’s meant to be used in. It’s not being used to build the framework (i.e., your app isn’t treated as some weird model plugged into one giant MVC mechanism or something), it’s not used as the framework/application “architecture” (that’s actually something akin to a Model2 architecture pattern), and it’s not being shoved somewhere it doesn’t belong. It’s exactly where it’s supposed to be.
In reality, Rails is fairly close to the architecture he discusses. It’s not as decoupled and interface driven as he’d like it to be, but that’s the real rub with this entire talk: he’s complaining about Rails “flaws” that aren’t part of its DNA. It’s like complaining about how a sweater isn’t a very good conversationalist. He ends the talk by harping on the fact that good architecture lets you defer decisions for as long as possible. But here’s a PROTIP: if you’re using Rails, you’ve already let someone else make a lot of decisions for you. That’s kind of the point since Rails is largely a curated set of Rack extensions that help you build web applications. They’ve decided your app layout. They’ve decided you’re going to be using MVC. They’ve decided you’re going to be piping things through a router of some sort and dispatching those requests to objects. All of these decisions and many, many more are already made. So, why waste the effort to whine and complain and hand wave that it’s bad, when you’re doing it to yourself? Pick a different framework or build your own, problem solved.
Seriously, wtf?
Those are just the major points I had issue with. There were several other minor things that grated me:
- At 17:00, he makes the remark that only classes derived from
ActiveRecord::Basego inapp/models, not the business objects he’s describing. I know he was making a sarcastic remark since that’s a general practice he disagrees with, but it (a) fell flat because a bunch of people yelled ‘models’ when he asked the baiting question and (b) is a fairly well known fact these days you can put anything in there that’s a business object. - Around 25:00, he takes issues with “web stuff” like session id’s and so on getting into your business logic. The problem with that is that sometimes you need that stuff. There are many times where I need to know how to handle some logic because of a header or some other payload information from the web.
- Around 33:00 he makes a snide argument that “You gotta know a ton of languages to write a web app.” Seriously? You really only have to know one programming language. If you want your pages to look decent, you need to know one markup language (and optionally know a second programming language if you want some fanciness). What about desktop apps? You need to know a form designer or a mark up like XAML/WPF or how to manage frames and such in code (which isn’t any easier than just learning a stupid mark up language). The criticism is weird because the best part of the web is that we have standard, interpretable languages/mark up usable by clients that don’t require client knowledge of any specific programming language. I can write a web app in Java or Rails and the client, which could be a mobile phone, desktop computer, mainframe in the tundra of Russia, or whatever, doesn’t give a crap which one it is. That’s awesome not annoying.
- Around 40:00, someone mentions they have “too many tests.” He goes on to dismiss that attitude (2 or 3 times actually) as a symptom of slow tests, and continues to point out that you should never get rid of tests, just write faster ones. I hope he’s kidding. I can tell stories of many apps I’ve inherited apps that were way overtested. I’m talking 5,000 Cucumber scenarios for an internal, non-mission critical application over-tested. I mean 22,000 unit tests for 30 models over-tested. I mean if I tweak the content of a constant array, the right tests fail, but I also have to clean 5 other tests where they simply tested the content of the array. That’s over-testing. I could rant about this for a while, so I’ll stop. :)
So, seriously, what happened? I think I’m just so disappointed because I’ve seen better stuff from him, but how have people been pointing to this talk as a really important talk that everyone should watch? I get he wants us to DECOUPLE ALL THE THINGS, but do we look past all this crap to get to a point he could have made much more directly and honestly (and in only about 10 minutes)? Or am I missing some grand overarching sarcasm that has placed me in the unenviable position of being part of the conference session equivalent of Punk’d?
Introducing gem_git: tiny tools for working with gems’ code via Git
We’ve all been there. You’re plowing through your app, in your groove, then you notice an issue with a gem you’re using. In some cases you can work around it (or if you’re desperate/crazy, just monkey patch over it and move on), but more often than not, you want to fork and fix it and/or send a pull request back to the original author. Likewise, I’ve been hankering to hack on some open source stuff lately, and while browsing Github for stuff to hack on is cool, more usually I’m doing something and think, “Hey, it would be cool if this gem did (x)!”
Tracking down a gem’s source usually isn’t terribly difficult, but it’s kind of annoying to go find the URL for the repository, pop that into my Terminal, clone it, and so on. The friction is even more irritating if after hacking a bit I decide to fork it and keep my changes separate. So I decided I’d make things a bit easier.
I hacked out gem_git. Right now it’s just a couple of gem commands to help with hacking on gems. The first one is gem clone, which hits the RubyGems API to find the gem’s source and clones it. So, if you want to clone paperclip:
$ gem clone paperclip
Cloning paperclip from https://github.com/thoughtbot/paperclip...
Cloning into paperclip...
remote: Counting objects: 5231, done.
remote: Compressing objects: 100% (2292/2292), done.
remote: Total 5231 (delta 3582), reused 4377 (delta 2822)
Receiving objects: 100% (5231/5231), 798.34 KiB | 1.25 MiB/s, done.
Resolving deltas: 100% (3582/3582), done.
The next one builds on that and lets you actually create a Github fork. So if I wanted to create a fork of pakyow, I’d do this:
$ gem fork pakyow
Forking pakyow from https://github.com/metabahn/pakyow...
Repository forked, now cloning...
Cloning into pakyow...
remote: Counting objects: 1109, done.
remote: Compressing objects: 100% (461/461), done.
remote: Total 1109 (delta 730), reused 977 (delta 598)
Receiving objects: 100% (1109/1109), 139.93 KiB | 230 KiB/s, done.
Resolving deltas: 100% (730/730), done.
Now I have a shiny fork of pakyow for my own hacking.
Right now there are no tests and pretty poor error handling, but I’ll be hacking on it over the next few days to improve that sort of stuff. Please file any bugs you find on Github Issues and I’ll get around to them.
Also, be sure to clone/fork the gem and send me patches. That would be awesome. :)
Attention API Provider: How to make people using your API love you
At Arcturo, we’ve been working with a lot of remote API’s and big data lately. The more API’s from all over the web I work with, the more I realize how much some companies really get how to build an API that developers love and use all the time, but at the same time, I’m beginning to realize how little thought some teams really put into their API and how it will be used. I rant about this often to Ryan, so I thought I’d go ahead write up a little list of things that API consumers would really appreciate if you’re providing an API.
Keep it consistent.
The number one most annoying thing I’ve encountered is inconsistent treatment of API calls. For example, let’s say I’m working with an API to a library. If I pull a book from the main collection and then a book from the reserve collection, both should contain the same citation information. If both of them, from my end, look like a book but contain different information (or annoyingly differently formatted information), that’s a big usability problem.
Much like we obsess over the user experience on the client side, investing time in your API’s user experience will yield big results in terms of adoption and engagement from developers. Think about what they will be doing and make the path from where they are to where they want to be as frictionless as possible. Giving me inconsistent data is a huge blocker to actually getting things done because not only am I wrestling with the data itself, I’m also trying to figure out what your assumptions about the data are and how they may affect something else I’m doing.
Make it general.
I can’t count how many times I’ve talked to teams who are building an API for internal use and are “just going to give people access to that.” While that turns out well sometimes, in general your internal product, case-specific logic will end up being more annoying to someone attempting to adopt it.
I was working with an API once that kept returning boolean data in different ways among the different calls, and when I inquired as to why that was, I was told that their iPhone app interpreted the data one way, their internal web services another way, and the Ajax calls they were making a different way. Of course, I was building something that cross-cut all the calls used by these services, so it made my life incredibly difficult (I literally eventually built a BooleanParser class or some such silliness to handle all the different states). If you’re building an API for something internal, then keep it internal; just because you can offer an API based on some internal thing doesn’t mean you should!
Keep your information up to date.
Please. Please. I’m begging you. The first thing you should do after changing anything in your API is to ask “Has then been documented and/or covered in our client libraries?” Having your API documentation being out of sync with your actual running API is a death sentence. This situation is becoming more and more of a problem as more sites are adding API’s as a second thought rather than a core functionality. Go ahead and compare your average web application’s API documentation to someone like Twitter who have made their API a core competency (though I could offer them as a counter-example to that about 2 years ago…).
Even more important is to make sure that the code developers are running and working with jives with what you’ve got running on your servers. If the documentation is wrong, that’s not such a huge deal if I can dig around in your client’s source and figure out what changed. But if the client is wrong and the documentation is right (or both are wrong), you’re going to drive me to Bedlam before I figure out you haven’t updated something. Keeping your API releases synced with documentation and client releases will go a LONG way to keeping your API users very happy.
Don’t gimp it.
If you offer an API feature, offer to your clients evenly. I understand “premium API features” and all that jazz make total business sense. I’m all about people monetizing their API’s as much as it makes sense. Where I think you, as a provider, cross a line is offering certain API’s only to your in-house, product bound clients and no others. Not only is it sort of gratingly protectionist to the point of turning off a lot of potential developers, it just doesn’t make any sense. If you’re going to arbitrarily limit the ability to which I can engage your product via the API, you obviously don’t want my competition or my contribution to your ecosystem very badly.
I understand limits in terms of not allowing blatant scraping of data or something that’s core to the viability of your business, but disabling convenient features and neat additions in the name of arbitrary limits is a problem. Twitter, while being fantastically open in a lot of respects, really put a bad taste in developers’ mouths with the whole OAuth/XAuth split for example. Limits like that can easily build up a lot of bad press and kill developer goodwill for very little benefit.
Be prepared for customer service.
As API usage grows, developers will inevitably have questions, requests, problems, and want to chat about their favorite beers from this really cool microbrewery in South Carolina that you just have to try when you get a chance ZOMG. Many API providers simply tell a couple of their developers to answer all of these inquiries just sort of as they have time between all the Real Important Work™. E-mails and support tickets pile up, people get upset, and things explode. No one wants that.
Instead, be prepared to offer actual customer support. Even if it’s one developer whose primary workload is flipped (answer support inquiries first, fix bugs and add features second), then that’s better than treating your existing developers as second class to building stuff. Your developers will thank you and sing the praises of your API team all over. Look no further than Twilio to see this in action; these guys really get it in terms of working with developers directly to make sure they succeed.
TL;DR
Your API developers will appreciate you at least considering their sanity in how you build and operate your API. Thanks.
The Hoedown 2011 Experience, Part 1: Lodging
Well, it’s that time of year again: another Ruby Hoedown coming at you. Registration is open, so head over and register now before we sell out (we’re not THAT far from doing it…).
When I started planning this year, I honestly didn’t know if I wanted to do it. This is the fifth year in a row that I’ve done this conference (and the seventh conference I’ve had a hand in planning over the past few years), and it had become a bit of rote repetition for me. So, like a few years ago when I got bored with charging people, I decided to change it up again. I started pondering a few things. First, what makes a great conference? Secondly, what makes a great regional conference? These aren’t easy questions to answer, especially for someone so close to the experience as I’ve been for the past few years. So this year I sat out all conferences save for RailsConf (and that was because I was speaking) and MagicRuby (for obvious reasons). This distance gave me some time to think about it a bit, and I’ve come up with a couple of core things (if you don’t really give a crap about what I think about conferences in general, you can slide down to the part about the hotels).
First, it needs to be an experience. Not just an experience within itself (i.e., “I went to RailsConf and it was what it was.”), but a truly memory-creating, impact-enhancing, honest-to-goodness experience for attendees. Too many regionals basically try to be a mini-(Ruby|Rails)Conf. I was guilty of falling into that for sure: try to shove as many people in as possible, give them what you expect in a conference (a badge, a t-shirt, a piece of paper telling them what they’ll hear over the next 2-3 days), and hope that you can at least muster a good review from the attendees. I won’t point fingers, because I doubt the organizers who I think have fallen into this trap even realize it as a problem, and that’s OK. If that’s how their conferences want to roll and it’s successful for them, that’s awesome. I’m just tired of trying to do that.
So instead, this year we’re trying to create a really memorable experience for attendees. The one conference that I think nailed this was Ruby Fringe. I attended (and spoke) there, and from the very start, everything had a very nice handcrafted approach. The organizers obviously put a lot of thought into how things progressed and the things that their attendees would see and do during the conference. That sort of thoughtfulness really matters because people tweeted, blogged, and talked about that conference for years after (and still do at times). We’re trying to put that same degree of thoughtfulness into the conference this year, and we hope it shows.
Second, I think regional conferences especially have to play up the “flavor” of their region. I’m always sort of disappointed when I go to a regional conference and I’m not wrapped in the culture and experiences of the region it’s representing. I’ve never put much effort into that. The closest I’ve come has been the general “feel” of the media (effusing the “dirty south” aesthetic that’s popular in a lot of Southern art these days) and hosting at the OpryLand one year. One conference that I think nails this year after year (I’ve only been once but heard from others how great it is at this) is GoRuCo. From the badge (which is handwritten by a local graffiti artist) to the parties (which are held in totally NYC locales), everything screams New York, and it’s awesome.
We’re trying to capture that this year. These few blog posts (today, tomorrow, and Friday) will layout some of the things we have in store for everyone this year. We’re going FULL NASHVILLE, and everyone knows you never go FULL NASHVILLE. But we’re doing it this year, from the food to the venue to the music (that’s right!), it’s going to steep you in the South like we’ve never done before. So, let’s take a look at what we have in store so far…
The Hotels
So in the past, we’ve usually had the conference at a hotel or at the least picked a hotel as “the” conference hotel. This year we’re sort of doing both.
First, the venue has lodging on-site that’s nice and super affordable. Like, $40 a night and you won’t get accosted by a hooker while staying there nice and affordable. Now, the arrangements are sort of spartan (see photo below) and they were previously a dorm, so the bathroom sharing situation might not be ideal for everyone.
But, they were a freaking dorm. What does that mean? Late night hackfests? I think so. Camaraderie not seen since your college days? You betcha. I’m going to place a Dean of Nerds in the dorms to plan activities and answer any questions you may have about the conference (I can’t do this but if you’d like to volunteer, ping me on Twitter or e-mail). I think that people will not only enjoy the price point, but it’ll create a great environment for cool stuff to happen.
For those of you to whom that doesn’t appeal, I plan on staying at the nearby Hilton Garden Inn. It’s only about half a mile away, only $89 a night, and should prove to be a little more luxurious.
Beyond that, there are more luxurious options if you’d prefer to travel just a bit further. Within a mile or so, there’s a super nice Loews hotel and a great boutique hotel named Hutton Hotel. My wife and I stayed there about 2 weeks after they opened and it was really chic and interesting (they used sustainable materials in the construction, so you have bamboo floors, etc.). There are other hotels near that area, too, such as a Doubletree or Hotel Indigo, if those are you thing.
So there you have it. That’s our lodging strategy for this year. Stay tuned for tomorrow’s post on the food and venue!
Authoring eBooks is on sale right now
I dropped the price of my eBook on writing eBooks Authoring eBooks to its lowest ever $19 today. Not sure how long I’ll keep it there, so grab it while it lasts!
RubyRescue.tv - Answering Ruby questions live and on the air every Tuesday (submit a question and win $50 to Amazon)
If you don’t follow me on Twitter and hang on every word I tweet, you may not be aware of RubyRescue.tv (ignore the inaugural episode language; we were too lazy this week to change it ;)). We did an episode last week that went awesomely well.
So awesome, in fact, that we want to make sure this one is super awesome. Submit your questions today and tomorrow using one of the methods on the website and you could win a $50 Amazon Gift Card. We’ll announce the winner on air tomorrow at 2p.m. Eastern.
The Compleat Rubyist is coming to Boston real soon
If you haven’t seen it, the training set that I do with David A. Black and Gregory Brown is called The Compleat Rubyist. Don’t let the word “training” conjure up images of boring lectures and spurious example problems that take you 30 seconds to complete. It’s an intimate, interactive experience wherein we do lecture, but we also provoke discussions, debate amongst ourselves, and give you a one-on-one tour through some of the topics we discuss (which are not presented at a novice level for the most part). No matter your skill level, you can get something out of it because due to the way we scale the content.
So back to my point: we’re coming to Boston soon, and we’d love to see you there. Head over to the signup page on http://thecompleatrubyist.com and use discount code FRIENDINBOSTON to get $50 off.
Hope to see you there!
FREAK OUT (or, I quit my job and what I’m doing next)
It’s my birthday today. I am now 26, and I’ve decided to have a quarter-life crisis.
Most people have these a little earlier in life, but I was too busy or missed out on some of the typical milestone triggers. I don’t drink, so I missed out on my first epic hangover at 21. I haven’t graduate college yet, so I missed out on that at 22. I was already married for 5 years when 25 rolled around and some people decide they are sick being alone in their terrible, worthless existence and get married. If I wait much longer, the moniker “quarter-life” won’t make much sense probably, so I’ve decided this year is the year.
This birthday also marks the end of my first decade of employment in the software industry (that’s weird to say I’ve done anything for a decade straight!). It’s the only job I’ve ever had. I fudged my age to sign up for one of those remote contractor websites when I was 16, and I’ve been hacking code for money ever since.
So what does that mean? Well, I quit my job, plan on moving to Belize to open a writer’s commune/coffee shop/moped repair shop, and have adopted 13 Malaysian children that I will teach to tumble and spin plates in an effort to create “Cirque du Soleil: Belize” some day.
You’ll be glad to know I haven’t given up sarcasm just yet.
I did actually quit my job, though. March 25, 2011 will be my last day working at Intridea, and if all goes according to plan, my last day “working at” anywhere (aside: working at Intridea is pretty neat; if you’re looking for a job, they’re hiring). But I’ve decided that I’m going to quit talking about doing what I’ve always wanted to do, and instead, actually, you know…do it.
I’ve been working in and with consultancies for years now. I’ve had some great experiences (and some not so great), and every time I leave one, I come away with ideas about what a great business can look like and what could really be done better. I’ve also developed some pretty wild ideas, but nowhere I’ve worked has been willing to experiment enough to test them out.
So, I’m doing two things. I’m spinning up my own business with a good friend (Ryan Waldron, excellent Rails developer and killer biz dude), and we’re going to change the world. OK, not actually, but we are going to try some interesting business practices and work processes.
We’re named Arcturo, and you can see our quick cardfolio site I put together if you want to contact us about work (and you know you do); we’re currently open to pretty much whatever sort of opportunity you have available (working directly for clients, working on your product, working with your consultancy, and so on). Our full site is going to be awesome, but I’m just waiting on our illustrator (Steve Thomas) to finish up the graphics.
Secondly, I’m starting a blog to talk about our experiences/experiments and others like them. The blog is The Business Hypothesis. I’m going to blog about what we’re doing at Arcturo and what others are doing in their business.
So, yes. Keep an eye out. I have some other fun things planned, but I don’t want to talk about them until I know, you know, that I can actually do them. :)
My books are on sale today!
Authoring eBooks is on sale for $15, and it will finally reach its full $49 price this weekend.
The Rails Upgrade Handbook is $6, and it will return to its full price of $12 this weekend.
These sales end TODAY, so you’d better snap them up if you want them.
