tl;dr: speakers.io is an app to connect speakers and conferences. It’s going to be awesome.
I’ve been a conference organizer for almost 6 years now (and a speaker for slightly longer), and year after year I’ve hit the same points of friction in my work. Seeing someone encounter the same thing with BritRuby made me realize that we could fix it! Partially, at least.
I had a long diatribe written about how everyone should stop forcing their priorities on event organizers and likewise organizers should find ways to include more people and people shouldn’t whine about people being passionate about diversity, but really it can just boil down to this: stop being a jerk.
If you think that statement could be about you, then it probably is. So, stop it. And let’s get back to organizing mindblowing Ruby events that include everyone.
So, how does speakers.io help that happen?
So watching this whole BritRuby thing, I kept thinking, “couldn’t we solve part of this with software?” When I sit down to consider who to invite to speak at my events (the keynote, typically), it would be really nice to not only get information about a presenter, but be able to know if they’re interested in speaking, available to come, and then reach out to them easily. If we had this utility with a lot of speakers on it (including men, women, children, alien, golden retrievers, and anyone else who could operate a mouse) that was easily navigable, searchable, and so on, it’d make it way easier for organizers to hunt down some great, diverse speakers?
Likewise, when I’m looking to apply to some conferences, it’s difficult to get a definitive list of what’s available, what I’d be interested in, and where my talks might fit. What if there was a list of conferences that made it super easy to submit talks to?
As a speaker and organizer, I look at services like Speaker Rate and Lanyrd and see the value somewhat. There’s a lot of information available on there and it’s a pretty neat way for a speaker to build a profile. I think if I attended more conferences rather than speaking or organizing them, I’d probably derive more value from it. But I’ve always felt that they weren’t serving the right audience (or that the right audience in my mind wasn’t intended to be served but should be).
These apps represent some great tools for attendees to schedule things, get the scoop on a speaker, rate them and give feedback and so on, but they’ve historically not been very helpful in terms of creating a community for conference organizers and speakers to work. I’d like to change that.
The first sort of “arm” of speakers.io is the organizer-speaker. First, obviously, we’ll let speakers build profiles of talks with links and such to videos/slides/whatever so an organizer can review their past work. The profile will also contain information like topics the person is interested in discussing and their schedule (always frustrating to ping a speaker, wait a week, and then find out they’re not available!). Organizers will be able to search for speakers and get results that only include speakers available on your event date and boosted by diversity index (if a speaker has provided that information), topic expertise (judged by tags and number of presentations on a topic), and so on. Then organizers can issue “talk requests” for a speaker or even a specific talk. Did you see a great talk by Zach Holman at TrollConf? You can request that he give that talk at your event next month, or you can request he come speak with some notes about what you’d like to see. You and Zach can work together then to put together an awesome talk description to work from.
We’ll also be exposing some simple CFP functionality for organizers. Speakers will then be able to search events by topic, location, dates, and so on, then submit a talk to multiple CFP’s at once (or submit a previously presented talk in one click). Organizers can then filter and transform their submissions on axes like “only show first run talks,” “sort by numebr of presentations,” and so on.
The second arm is the speaker-speaker functionality. I really like the concept of SpeakerConf, in that it’s a number of speakers getting together to present, hone their ideas, and practice their craft. Why not re-create that in software?
Speakers will be able to create a talk on speakers.io that isn’t published to the public, and then invite other speakers to come and collaborate on it with them. The vision here is still a bit ethereal, but basically, I want speakers to be able to help other speakers create better presentations through sharing slides, video, code, etc. Like I said, I’m still hammering out the vision here, but it will end up in there!
OK, there is no and. That’s it. I want to keep the tool simple and focused. I’m fine with farming out slide sharing to Speaker Deck and selling tickets to one of the many fine ticket sellers. It doesn’t need to be a universal tool. The point is to connect organizers to a wider array of speakers than they may have encountered otherwise and to connect speakers to events they may not even be aware of.
“Is this a business or whatever?” No, I’m over the moon with working at GitHub. It’s just something I’m doing on the side to make things easier: it’s free and always will be. I don’t know about going open source or not (that’s because I don’t want to manage it, not because I necessarily want to keep it secret), but I’m going to push this out soon and see what happens beyond that.
So, head over to speakers.io and sign up. I had hoped to have an alpha version out to start getting speakers into and such, but I got bogged down a bit this week, so no such luck. I should hopefully have a basic version done by next Monday so we can start playing with it! Hit me on Twitter at @jm if you have any other cool ideas (or want to do a UI design for it…I can send wireframe ideas!).
I love surfing Twitter, checking Facebook, and hanging out on Reddit/Hacker News/etc. as much as the next person, but I’ve got to be honest: you guys can kind of be douchebags. Pair that with the constant cycle of terrible news being pumped out of CNN, FOXNews, and friends, it makes me feel pretty bad about the world when I go through my morning reading cycle.
Of course, the solution is easy: give it up. Right. So, I’ll unplug from the world, stop associating with most people, and simply live in a silent bubble of limited information for the rest of my life. That works great for some people (the Information Diet is a “thing,” remember?), but that’s not how I roll. I love absorbing information. Learning is exciting for me. But, the (seemingly) recent trend of Twitter arguments, crappy news, fear-driven reporting, and general crappery and loud-mouthiness associated with a lot of non-traditional news outlets (e.g., TechCrunch) has really started to affect my mood. I’m more on edge. I’m quicker to get grumpy.
So, I’m forcing myself to do some Happiness Therapy™ everyday. I’ve started a newsletter called Good Morning, Interwebs, which will drop a little packet of positive into your inbox every morning. By making myself seek out positive news, good things going in the world, and other stuff that will generally make me smile, I’m thinking it’ll make me feel better about things in general. I’ve tried things like this before, but I quit quickly. “OK I’ve had a few days of this, great, OK, done.” But with the added pressure of “people expect this in their inbox tomorrow morning,” I can’t skip out on it quite as easily.
You can subscribe with this form:
So, go forth and enjoy. I’m not sure how this is all going to take shape, but hopefully it’ll add a bit of positivity to your morning before you wander out into the vast wasteland of negative, attention-hungry (ZOMG DID YOU KNOW ANOTHER PERSON GOT SHOT IN YOUR CITY? YOU DO NOW. BE AFRAID), and frankly exhausting media. :)
Ever since launching Railcar, I’ve been getting a lot of questions about why I’m building it, how I’m approaching things, how people can help, and so on, so I thought I’d take a few minutes and share some things with you.
The main reason is that the Kickstarter pointed to a real need that I didn’t realize still existed. I’ve become so separated from what it means to be “new to Rails” that I didn’t realize it was still a problem to get a Rails setup going on your machine, but thinking back on it, it was and still is a bit of a nutty process. It’s not just the installation of stuff, but the whole environment around the application. How do you start it up? Why can’t I just stick it in my Apache root and let it go? Why do I have to configure a database file? Migrations? What is all this? I forgot how much cognitive friction really exists there that things like Locomotive removed when I was first starting out. I had some spare time, experience building desktop apps, and some ideas about how it should work, so why not hack on something?
Now, as I’ve learned more about Tokaido’s approach, I’m really glad that I started building something else. Statically linking everything is good for the tools to get started (for example, we’re going to make it such that you don’t have to compile anything to get started with Rails and SQLite), but offering everything statically linked is just going make things difficult. There’s a reason that Apple doesn’t like you to statically link things on OS X (go ahead, try it; there’s no crt0.o for a reason). You can find their reasoning through a quick Googling (unfortunately, the original page explaining it appears to be gone now), but essentially they force you to dynamically link to the system libraries and kernel (even in static mode). Their position is that purely static linking is a Bad Thing because things can change and break under your code (e.g., moving a piece of functionality from the Mach kernel to userland). Plus, if part of the reason you don’t want people to have to compile things is the file size of the GCC package, you’re not going to help that with statically linking everything. Locomotive was about 100MB, and I think that’s probably the absolute minimum file size you’ll be able to pull off if you go that route. Why not have them download ~150MB and be able to install anything they want?
Which leads to my second issue: discouraging people from using the tools they will be using in the “Real World” is a bad thing. Yes, it’s great to have a one click thing that you can develop in and really learn with, but your team will not work that way. No matter how good you make it, I seriously doubt that experienced developers will use a GUI tool for something that can live and work better with a CLI. Rails developers use homebrew. Rails developers use compilers. Rails developers encounter problems with installing gems sometimes. After a certain point (i.e., once they move beyond their first few learning apps), attempting to hide these details from people learning isn’t helping them learn. This issue is especially controlled thanks to homebrew and their extensive list of patches and OS X-specific fixes for many libraries. And these are not problems you will solve, unless you think you’re more talented than the thousands of developers from the past 20+ years who have attempted to solve it in every programming language ever used in a *nix environment.
Look, I don’t think what Yehuda’s doing is wrong or that Yehuda is wrong. That’s not what this is about. I see this as the exact same situation as bundler/isolate, Merb/Rails, Sinatra/Ramaze, whatever/whatever else. There are alternative ways to approach the same problem. My philosophy is that I want people to use Railcar until it doesn’t work for them anymore, at which point they can click the forthcoming “install to system” button and go about their merry way. His approach is probably different.We appear to be taking two valid approaches, and I’m sure different people will gravitate to one or the other. That’s fine.
So, what am I doing exactly? Currently, I have a usable isolated app environment living in the repository. It’s written in MacRuby using XCode and Interface Builder (I don’t have any interest in using HotCocoa because I like pretty interfaces and it’s incredibly hard to build those in HotCocoa). On the first run, it will install Homebrew, RbEnv (Why RbEnv? I could quickly figure out how it worked and its flexibility will make it easier to drop binary installs in. I’m not opposed to using RVM at all, but RbEnv was just easier to figure out and easier to hook with my code. Patches accepted :)), Ruby, and some default packages.
Once it’s bootstrapped, you can install popular packages in Homebrew, install various Ruby versions, generate (or drag in existing) applications and launch them with various options. It’s a little rough, some things aren’t quite wired up, but it’s definitely a good MVP build right now I think.
Currently everything builds from source, but I’m working on a setup for binary installations for Ruby and SQLite. I’m also setting up (later today, hopefully) a repository for a very, very small collection of statically compiled gems for SQLite, RMagick, and a few others. Basically, I want to put the most popular gems in there so that in their initial learning, there won’t be a ton of issues. I’m also going to invest some time (or invest some money in having someone else) in converting a few gems to rake-compiler to make a lot of things with respect to compilation that much easier.
Once the binary installs are in place, I want to polish up the whole UI, put some nice icons in (those are in the works!), and get it really released as a product unto its own. Then, I want to get to work on an educational piece that will either be part of the Railcar app itself or a separate application. Basically, I want to make the documentation accessible, provide a number good on boarding tutorials, help with common errors, offer a “help search” that will search the mailing list, Stack Overflow, etc. to help find the best answer, and so on. I haven’t decided the best place for that; I’m gravitating towards a second app so that you don’t have to use Railcar, but we’ll see.
You can contribute code, for sure! I’m going to work on adding some tickets to Github today for some things that need to be done, but you’ll find a few
TODO: type things sprinkled throughout the code. There are also a few rough areas that I’d like to smooth out that don’t really conform 100% to the Cocoa way of doing things (e.g., I should be binding the per-application settings using Core Data probably), but those issues are minor. Feel free to refactor/add/improve anything that you see. I know MacRuby pretty well, but I’m not the most expertest expert. I know some people were saying things like ARC were creating issues for them, so if I have a weird build setting in XCode, please feel free to correct it and send me a pull request. Oh, and tests. We need some of those.
Secondly, if you’d like (and don’t feel compelled at all), you can contribute monetarily. While everyone likes money (and it would be amazing to get a little boost around tax season), I don’t really care about it, I’m not “seeking” it, I don’t need it to keep working on the project, but I’ve gotten a number of requests for a PayPal button or whatever, so here you go:
Depending on the amount I gather, I plan on investing part of the money back into paying others to improve things like rake-compiler, Rails documentation, and so on. I’ll send you a sticker for contributing if you don’t mind providing your address on the page after you finish with PayPal. Please pardon the payment going to my business’s PayPal account. My wife uses my “main” PayPal account extensively for her business, and I don’t want to risk PayPal freaking out and locking it up. If you’d prefer not to use PayPal, I can figure out something else if you’ll e-mail me.
Well, I’m going to keep hacking. Getting people to help finish up a few loose ends would be great so we can get it into the hands of people to use. Anything you can do to contribute to that (even filing a Github ticket with a great idea), would be really helpful. I’m available via e-mail or Twitter if you wan to chat about any ideas/issues you can foresee.
I’ve been dealing with recruiters for a long time. Not the good kind that offer you awesome jobs, but the crappy kind that mailbomb you with irrelevant positions. I’ve been receiving their e-mails and such for years and years now, and eventually I decided I’d afford them the same courtesy they afford me and simply write a form response for the ones that annoy me. I posted it on Twitter yesterday after using it to respond to a recruiter who offered me a junior PHP/C# position (tech I haven’t worked with for 5+ years) that required relocating to a crappy area for terrible pay. The response has been one of three things:
The first two I expected, but I must admit, I didn’t expect the latter from anyone but recruiters (and trust me, three recruiters felt it their duty to let me know what they thought via e-mail; I can’t express how hard it was to not respond with my form response but I was civil :)). So, I felt like maybe I should explain some things about recruiting, because I’m not sure many of the people who were upset by it have actually experienced what a lot of people experience with recruiters.
Disclaimer: The following doesn’t describe every recruiter on the planet. It does describe at least 90% of the ones I’ve interacted with, but I talk about some of the good ones later on.
I put “recruiters” in quotes there because the modern day recruiter is little more than a spammer who has legal authority to spam you. I’m almost surprised some of them haven’t taken to appending male enhancement ads to their job e-mails to make a little side cash. Essentially, they have big databases of resumes that I’m guessing are usually purchased rather than built given how out of date some of the information is in there (we had an old cell phone number that we kept around for a while and we’d still get calls on it 2 years after I’d taken it off my resume). They’re probably tagged somehow or searchable by some means. Recruiters take a job listing, search for keywords in their resume database, and e-mail everyone who could possibly match those keywords. Everyone. Even people like DHH, who obviously isn’t looking for a job.
So, why am I so offended by this practice?
Never has a single industry disrupted the general flow of my life so much as recruiting. That’s probably an exaggeration, but honestly, it’s a bit much sometimes. Here are some examples:
You can point to those and say “oh, those are the bad ones!” but frankly that’s how most of my interactions with recruiters go, especially when it comes to phone pushiness. The point is that this boorish behavior isn’t really abnormal.
The worst part is that 3 for 3 yesterday in the recruiter responses, they all blamed me. “Well if you wouldn’t post your resume on your website, we wouldn’t e-mail you.” “If you didn’t mark yourself as ‘for hire’ on LinkedIn or WorkingWithRails, we couldn’t call you.” Are you kidding me? PROTIP: I am for hire. I run a consulting business. I’ve actually gotten 2 contracts from people pinging me from those mechanisms. I’m not going to act as if I’m full up on work just so you won’t spam me. That’s just ridiculous, self-absorbed martyrdom. Even further, just because I post some information publicly that doesn’t give you the right to spam with tenuously related information. I mean, what if I spammed you with some recruiter related product? Or what if I started a recruiter recruiting firm and just totally bombed you with e-mails about positions in it? I guarantee you’d cry foul then.
Recruiting as it’s currently practiced can’t possibly work very well. Maybe it does. Maybe they have enough resumes built up that they’ll get a few hits that are actually viable. I doubt that happens most of the time given the amount of repeat job spam I get, but it’s always possible.
But even so, they’re not doing their job as it’s supposed to be done at all. Part of the job of a recruiter is (theoretically) screening candidates on some surface level. I did an experiment a couple of years ago by responding to 3 job spams I totally wasn’t qualified for: one was a position using R or SAS or something like that at a financial firm, one was a C++ position at a games company, and one was a low-level network engineer position at some MegaCorp™. Every time the recruiter merrily passed on my information to the client, selling me up as a great candidate, and so on. My resume said nothing about any of this stuff. No experience, no education. Nothing. So, not only are these people not good at screening candidates to spam, they’re also terrible at even telling whether a candidate is legitimate. I felt bad telling the firms they’d been duped into accepting a lead on a crappy candidate. Two of the companies never responded at all, but the MegaCorp™ HR person told me they never expected high calibre candidates from recruiters anyhow.
The way it’s currently done, recruiting is totally useless. What do recruiters offer beyond what a job board posting would offer? I’d even venture to guess that a job board posting would have a better return since the people looking at it and applying are actually looking for another gig. Spam recruiters are simply leeches, middle(wo)men who take a big slice for being a reverse job board.
Recruiting isn’t always like this, though. In Real Recruiting™, recruiters actually spend time evaluating candidates (not just e-mailing anyone who matches some keywords), searching out people who fit the position they’ve been tasked with filling using information gathered from their own experience and their network (not just doing a Google search for a resume and passing it on), getting to know the candidates (not just merrily passing them along after the first response), and then making an informed and pointed recommendation to their client.
That’s how it works in corporate America. Do you think when a big corporation decides they want to hire a new CEO that their recruiter mailbombs everyone who has CEO experience? No, they have an informed process to make educated recommendations to the board. For example, when Apple recruited John Sculley to be their new CEO, they spent a lot of time evaluating his effects on the company, what he would bring to the table, how it could shape Apple, help tame Steve Jobs, and so on. Now, granted most developer positions don’t carry that much gravity in a company, but a little consideration of the position and background of the candidate would be nice.
When I’ve shared some of these thougts with recruiters, I often get back, “But that’s not sustainable! I don’t get paid enough for that!” Then let me be clear: Maybe you don’t have a real business. It’d be great if I could sit on the side of the road and sell small carvings I make from the rinds of watermelons, but hey that’s not sustainable either. The hard truth is that you don’t make enough to do that because you don’t offer any value beyond a job board, and job boards are cheap. I posted a job on one job board, got 20 credible leads (and about 10-15 not-so-credible ones). Would a recruiter have turned that around for less than $300? I doubt it.
In this Era of the Internet, a lot of “connector” businesses are finding themselves replaced by websites these days. Phone companies are finding stiff competition requiring staff reductions for things like directory assistance, driving directions, and so on. The Internet has democratized information access and inter-personal connections to the point that middle(wo)men like recruiters are a fading industry. Want to save yourself some cash? Want a programmer that does Java? Post the job on a board and do some searching on a community site. You’ll find people who are doing interesting things and probably looking for work.
So, I hate blog posts that just complain the whole time and offer no concrete solutions. How can recruiters start actually offering value?
Anyone can do what I just described above (Google and e-mail someone). The CTO, the team manager, the little HR lady who always offers you a peppermint when you visit her office, they all know how to do that. The value a recruiter can offer in knowing the tech, actually being able to evaluate candidates, talk intelligently with the client and candidates, and so on is nearly immeasurable. I really think a firm of tech-educated recruiters who have real chops (or at least some knowledge), who can connect with both sides, and can actually make educated recommendations would be a real winner.
Don’t have the time or inclination? OK, understood, but then hire someone. I tell you what: Arcturo will pre-screen all your candidates for $500 (i.e., toss out actual crap) and technical screen them for $100 a pop. I’m sure a number of other firms would do the same. Even better, talk to the client’s current team or leadership about people and things they’re looking for outside the job description. I talked to a recruiter at Square who was totally doing it right. She had dug up a few people to talk to, and then she went to the team there (who would know who has good technical chops) and said, “What do you guys think?” They helped her narrow her list down, and she contacted each of these people personally. That is doing it right.
Don’t form e-mail bomb me. It’s just offensive that you can’t be hassled to at least compose at least a semi-personal e-mail. That carelessness was the genesis of my form response: they’re taking less than a second to compose a message to me, so I’ll afford them the same courtesy while also registering my displeasure. I’ve only gotten a single response to my form e-mail, and that was simply “OK.” Usually they don’t respond, which, to be fair, is the intended effect.
But had they reached out to me like a person, made me feel like they had done any degree of research at all, had actually evaluated whether I would even fit the position at all, I would respond differently. If a recruiter has any familiarity with me at all (even “I saw your Github account” is passable in some cases), I’d be a lot more civil. The CTO at Mixbook did a great job with this. He’d looked over my blog, seen my Github, and contacted me because he thought I’d be a good fit (I’m guessing he didn’t have much success because they’ve now hired a recruiter who is spamming people like DHH). But even so, I thought that was a great approach, and were I looking for a job and to relocate, I’d have definitely responded to him.
If my resume says nothing about SAS or SAP, then why are you e-mailing me leads dealing with those technologies? If my experience listing tells you that I haven’t touched C# in any real capacity in years, then why are you e-mailing me about a “C# Expert” position (well, I’ll you why, because they’re not reading the resume, but still). Evaluate the information you have available to you before you even reach out. It’ll pay off for you.
I also can’t tell you how irritating it is to get an e-mail with something like “We need a developer for a Rails project. It pays $27,000 a year with no benefits and requires at least 4 years experience with Rails and 6 in web development. Oh and you’ll need to be in (Atlanta|NYC|San Francisco|Seattle)” (not an exaggeration). Who would take that position? Sometimes recruiters need to learn to say “NO” to crappy companies trying to hire like that. Candidates would respect you a lot more if you wouldn’t toss this utter crap our way. I know right now the economy is still pretty unstable and some people would be happy to have that job, but if the requirements and the compensation don’t match up at all, then that’s a huge red flag for candidates.
So, that’s my speel on recruiters. I’m sure I’ll be “blacklisted from [another recruiter’s] extensive network” as I was yesterday. I’m totally sure I’ll “regret saying such things in public.” OK, not really. I feel like I’m being fairly reasoned here given the amount of stupidity and abuse I’ve put up with over the years.
By the way: I’m on vacation right now (thanks Tumblr post-queue!). If you e-mail, comment, tweet, etc. and I don’t respond, I’m not ignoring you. Well, I sort of am, but only because I’m probably on the beach or floating in the middle of the Caribbean. Sorry, the Internet reception’s not real good out here.
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?
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.
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.
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.
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.,
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.”
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.
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…).
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!
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.
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.
Those are just the major points I had issue with. There were several other minor things that grated me:
app/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.
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?
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
$ 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. :)
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.
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.
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!
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.
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.
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.
Your API developers will appreciate you at least considering their sanity in how you build and operate your API. Thanks.
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…
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!
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!
Powered by Tumblr; designed by Adam Lloyd.