Don’t flex on sleep

by Patrick Haney via Flickr

A student in Ruby Mendicant University tweeted today that he’s sleep-deprived due to overworking himself for Ruby Mendicant University. I hope I’m not partially responsible for his sleep deprivation, but I feel like I could be.

I might have set a bad precedent by throwing sleep on the RMU sacrificial altar, which is unnecessary, and even counterproductive when trying to attract and coach newer students.

In any situation where compromises must be made, you look for a “flex” point. Often in business decisions, you ask whether you flex on time, quality, or cost. Sometimes you can spend more against a hard deadline, or other times it’s better cut corners to save cost.

Often in life, we don’t put enough thought into the question of which part must flex. I didn’t think much about this during my RMU sessions, but I should have.

In my case, I had these things going on in my life: 1) Work, 2) Family, 3) Entertainment, 4) My RMU ambitions, and 5) Sleep.

It was pretty obvious that the first place that should flex is “entertainment”. I can give up TV & RSS feeds for a few weeks. No problem.

But then I found that I was still underwater. So what flexes next? Do I spend less time with family? No, that’s too important. Work? Not feasible.

That leaves sleep, or my RMU ambitions and my predefined definition of “success”. At that point, the seemingly noble choice is to flex on sleep.

The problem is, sleep should be the absolute last place you flex. Working into the wee hours of the morning has repercussions that actually start a domino effect on all the other places.

You’ve now mortgaged your entire next day: I guarantee you’ll diminish your effectiveness at job, your patience and kindness with family, and even the next day’s schoolwork!

I know this because i’ve now made the same mistake twice. Weeks after my last RMU session, I’m just now catching up on sleep and feeling like myself again.

So why did I flex on sleep? Easy: pride.

My pride wouldn’t let me scale back my RMU ambition. Sometimes pride is a good thing, as it causes us to accomplish things we normally wouldn’t. But RMU isn’t about showing what you can accomplish in a short time, it is about accomplishing what you can in the longer term, and staying on the path to mastery (at least that’s my interpretation).

What should I have done? I should have told Greg I was underwater, and scaled back my ambitions. I’m proud of what I accomplished, but the costs were just too large for my level of effort to have been a good long-term investment.

Sleep is too key a component to your success in too many areas of your life to sacrifice it for short-term gain.

RMU Round 2: What I learned

Note: This is the third of several posts about the philosophical and technical learnings from my Ruby Mendicant University Web Development course:

Part 1: About the course & what it was like

Part 2: A first-timer’s process of styling a site

Part 3: What I learned from the course


While the previous post was about the tools I learned to use, this post is more about my successes, my failures, and the philosophical things I’ve picked up in this session.

My successes & failures:

Styled website WIN.

While I wouldn’t say I could jump in and whip up raw CSS from scratch, with the toolkits provided within Compass, Sass, and Blueprint, I can kick out a decent web stylesheet pretty quickly and without a lot of fuss. Most of the intimidation I felt about CSS was groundless, though it can still be punishing at times.

Web Fonts FAIL.

I tried several things, but couldn’t figure out how to replace my default font (Helvetica) with a font using Google Font Directory. Web fonts became a fight that I’d just have to have another day.

Overlapping styles FAIL.

One thing Compass lets you do is cleanly separate your stylesheet partials on a page-by-page basis, which seems to be how Jordan does his. I opted instead to create partials on a per-type basis (one for forms, etc.), and this bit me badly later.

I altered the styling of my form partial for an entry form, only to go back through my app just as I thought I’d finished to discover I had completely broken my file submission form.

This added lots of extra work when I felt utterly done with the project, and actually led to my epic Git FAIL.


This was the second major time I severely frustrated myself with my lack of Git knowledge. I didn’t realize git -rm actually deletes a file, rather than a reference to a file, and I did a git revert to before I’d fixed a bunch of broken stuff.

In the end, I wound up swearing at my computer a lot and ultimately re-doing a lot of work.

At my next convenience, I’m going to go through Jim Weirich’s Git Immersion, it’s an open tab in Chrome right now, waiting for me to learn how to suck less at Git.

Learning jQuery FAIL.

I had planned on learning jQuery as a part of this course, and it just didn’t happen. I watched a few screencasts and read up a bit, but didn’t find occasion to even dip my toe in the jQuery pool.

GeoKit WIN.

GeoKit is just awesome. It’s one of the nicest, simplest, and most useful web API tools I’ve used so far.

Google Maps FAIL.

I had assumed that someone would have written a nice Ruby API for Google Maps. The answer is “no, go learn Javascript and do it yourself.”

To embed a map, you have to stuff a lot of Google-specific code in your <head>, which doesn’t play nice with the concept of a layout page. It really doesn’t play nice with Haml, so it was back to ERB for me.

Even though I could look up an address and make a map display, wiring them together required a lot of work from Jordan to fix my mistakes.

On confidence:

This was a big confidence booster for me. The only thing standing between me and getting a website done is making the time to do it. If you want something, just do it.

On pacing:

The September session taught me that when you have 3 projects to accomplish, don’t wait until you’ve finished Project 2 to move on to Project 3. Start planting the seeds for all your projects early on, so that you’re not rushed to do 100% of anything in the last couple of days.

Or it *should* have taught me that. Instead, I tried to accomplish my projects serially, spending a few days on Project 1, then more than 2 weeks on Project 2, and less than 48 hours on Project 3. Needless to say, Project 3 was a bust.

On sleep:

Toward the end, I was working until at least 2 or 3 AM every day trying to get my app styled, and sleeping an average of 4 hours a night. Greg told me to ease up, that RMU isn’t meant to upset someone’s life balance. He was right that I was pushing myself too hard, as I have a tendency to fixate on a goal and not let up until I’ve finished, even when that isn’t the wisest course of action.

However, I like the idea of “excess, in moderation”. I pushed it really hard, but not so hard that I’m burned out from further work. Maybe in another 6 months or so, I’ll do another sprint where I immerse myself in learning some new thing or breaking some perceived barrier.

If I could go back and change things, I’d probably have scaled back my ambitions somewhat and pushed the average up to 5 or 6 hours a night. I think people were starting to notice that I was cranky.

“No heroes”

Greg added that RMU isn’t about elevating heroes. I hope my crazed ambition is not perceived as any kind of heroics, because RMU is a pretty personal journey for each student. There is no Honor Roll, there are no gold stars, and there’s no valedictorian. It’s not for one person to try to set a high score. I was striving for a very personal goal, to conquer my hesitance to design a website, and I feel like I (barely) achieved it.

Finally, thanks

Lastly, I want to reiterate my gratitude to Greg for running RMU and to Jordan for his inordinate amount of work in helping me achieve my goal for the session. I still have a long way to go before I’m a “real Rubyist” or a “real web developer”, but I’m much closer than when I got involved in RMU.

RMU Round 2: Process, Tools, & Techniques

Note: This is the second of several posts about the philosophical and technical learnings from my Ruby Mendicant University Web Development course:

Part 1: About the course & what it was like

Part 2: A first-timer’s process of styling a site

Part 3: What I learned from the course


This post is more about the process and technical challenges I faced in creating a full layout for the first time. In my final post on the topic, I’ll share more of the general lessons from this session.

For me, the process went as follows:

1. Mockups

2. Backtrack & fix (set the stage)

3. Create assets

4. Implement styling on page-by-page basis

This, with a lot of reading and learning about tools & technologies I needed to get the job done.

The mockup stage: Balsamiq, etc.

I cannot tell you how critical this is. The mockup stage is the part where you think through all the user’s paths through a site, what they’ll expect, and what context they’ll need to get what they want. You get a sense for visual priority and information design. All before writing one line of code.

The visual context simply cannot be guessed at or thrown in during implementation. My opinion is that if you’re not doing a thorough mockup before coding, you’re probably going to screw something up pretty badly.

I’ve used a lot of different mockup tools, including sharpie/paper, Mockingbird, HotGloo, Keynote UI templates, and iMockups for iPad. Balsamiq is my personal choice. You can learn it in 20 minutes, and cloning your mockup and then exporting a bunch of tabs to .png will save you lots and lots of time. My 2nd choice would be sharpie/paper.

Once it came time to actually style the pages, designing to a mockup didn’t tie my hands at all. It actually liberated me to work within the framework to offer the best presentation possible, without worrying about fundamental questions like whether to choose a 1, 2, or 3-column layout.

It took a few hours to think through properly, but I got those hours and more back when it came time to turn those mockups into styled pages.

The “Fix the broken pieces” stage

So far in my work at the office and in RMU, one consistent theme is that the thinking you put into the mockup stage will reveal flaws in the existing plan or implementation.

In this case, there were unfinished pieces of the app; features that were clearly intended but not built out, like an Announcements feature and a Puzzle Details page. The lesson here (intended or not) was that in order to move forward, you’ve often got to move back and clean up a little bit.

Once this was done, the stage was set for some actual design.

The “create assets” stage

This one seems optional, and Photoshop skills are not necessarily required, but I was sure glad I had them. I didn’t do any high-fidelity mockups or anything, but I did create my logo & background images, and tweak icons.
I also used a nifty little site called Stripe Generator to create repeating stripes, which is usually a laborious process involving Illustrator and/or Photoshop.

Last stage: Styling

OK, enough playtime. Now it was time to jump in and get my hands dirty. And then–

Haml, WTF?

I jumped into the project and immediately came to a screeching halt. Instead of my more-familiar ERB syntax, the views were in Haml.

Immediately, I was faced with 1) converting all the views to ERB, or 2) Learning enough Haml to get by. I figured that converting the Haml to ERB would require nearly as much research as just keeping it, so I decided to stick with Haml.

This was itself a crash course, and I came away both impressed and frustrated with aspects of Haml.

What makes Haml so great?

There are no closing tags. It has a Ruby-esque syntax, and it’s much easier to drop in native Ruby than in ERB. It uses CSS-style selectors. It’s terse, clean, and easy to read, once you’ve got the hang of it.

There apparently used to be serious performance issues, but they’ve since been ironed out, and Haml is about on par with ERB for speed in compiling to HTML.

What makes Haml frustrating?

There are no closing tags. That means that you’re in the realm of “significant whitespace” in your views. Personally, I don’t like having my views fall apart and spit an error at me because of my indentation.

Haml is optimized for cleanliness, not flexibility. Perhaps the most damning thing about Haml is that you can be almost certain that you’ll need to fall back to ERB (or have Haml interpret HTML via plain text, ugh) eventually for some edge case. If it works in HTML, it works in ERB. Not so with Haml. You’ll either wind up twisting something straightforward into knots to fit into Haml’s syntax, or fall back to ERB.

Would I use Haml again?

Basically, Haml is a lot more fun to work with than ERB, right up until it’s much, much worse. One surprising thing is that you don’t have to choose; you can use Haml most of the time and use ERB for your edge cases.

Yes, Haml did add a significant amount of time to my project. But depending on the project, it’s likely I’ll use it again in the future.

Once I got the hang of the markup, it was time to start styling my project. I wasn’t sure where to start, having never styled a page from scratch before.

But after my first go-round with CSS, I started getting really frustrated.

**Does CSS Suck?**

That’s a total troll question, so I’ll rephrase:

How did people do layout before Compass & Sass?

We had a pretty heated debate in the #rmu IRC room about whether CSS sucks. The sticking point was that an educational context basically isn’t a place to say that any given tool sucks.

But it’s a good question: Does CSS suck? Greg Brown has created a layout framework for PDFs in Prawn, which taught him that creating a flexible layout is a hard problem, and CSS has spent 10 years doing a pretty good job of solving that problem.

But Ruby developers used to having a universe of capability and spoiled on the “principle of least surprise” get a rude awakening. CSS is a crappy programming language, if that’s what you’re expecting.

With CSS, I kept having the experience of “tweak, tweak, tweak, KABOOM”. A small change may mean nothing, or that your layout collapses entirely, or your signup form is wrecked because of a seemingly unrelated change for another page.

That said, there are some frameworks that turn CSS into much more of the programming language that developers expect.

In fact, when it’s all working together well, I’d say that Haml/Sass/Compass/Blueprint combo is a pretty friendly way for developers to do design. Here are the pieces, broken down:

Sass: CSS, but like, for programmers. It adds some powerful features to CSS:

Variables (e.g. $light-gray: #f7f7f7)

Mixins (e.g. @include bordered-table)

Nesting & Inheritance (I didn’t use these much)

SCSS: It’s Sass but with CSS syntax. Basically, Sass is for people who really hate braces and semicolons, and SCSS is for people who want CSS compatibility. SCSS seems to have become the de facto standard for new Sass projects.

A very minor gripe is that because of the syntax change, a lot of the tutorials you’ll see will be hard to understand in SCSS, as Sass was the preferred syntax at the time they were written.

Compass: Compass doesn’t do a good job of delineating its role from that of Sass. The fact is, the majority of the benefits they claim come from Sass, but the additions Compass brings make it absolutely indispensable to me now:

The ability to define and mix in partials

Auto-compiling for Rails projects

A whole bunch of pre-defined (and easily configurable) mixins.

Compass gives you a nice framework to start from, and a project folder that is relatively easy to keep clean and organized (though I did manage to mess that up later).

For an example of the benefits of Compass/Sass, if I wanted a drop-shadow and border-radius on a div, first I’d import the partial:

@import "compass/css3";

Then I’d include the predefined mixins in the style for that div:

@include box-shadow;
@include border-radius(10px);

Combined with the ability to define your own mixins, this is a huge time and sanity saver.

Auto-compiling stylesheets is also awesome, because it means every time you save a change, you get real-time feedback, as if you were editing the CSS directly. It also recompiles each time the server is restarted, so every time you push an update to Heroku or it spins up your instance, it throws an error while the stylesheets compile. I’m not sure how to get around this, but it’d be irrelevant if you had a dedicated box that didn’t spin up/spin down like Heroku.

Blueprint: Blueprint exists independent from Compass, but it almost seems like they were destined to be together. It includes some decent defaults for a Grid system, forms, and typography.

960gs vs. Blueprint Grid

Basically, a grid system is a way for you to define the horizontal layout of your pages so they don’t look crappy. They pick a default column count of 24, so you can cleanly split a page into 2, 3, 4, (or 6, or 8 ) columns. It’s configurable, but the default seems like something I wouldn’t be likely to change.

Brian Hogan (PragProg author of “Web Design for Developers”) recommended I choose 960gs over Blueprint’s grid due to 960’s better documentation. However, I hadn’t realized that Compass includes mixins for Blueprint’s grid system.

So I chose Blueprint grid.

To demonstrate how awesome Compass is, I’ll go back to Compass mixins:

Let’s say I want to create a simple 2-column layout with a header, footer, main area, and sidebar. This is a pretty basic request, but handling this in CSS requires a lot of careful pixel calculation and repetitive typing.

Here’s all you’d need to do it with Compass/Blueprint:

.two-col {
#container {
@include container; }
#header, #footer {
@include column(24); }
#sidebar {
@include column(8); }
#content {
@include column(16, true); }

What amazed me is that I was able to get the project completed despite the initial uphill battle of learning these tools. I’ve only scratched the surface of all the amazing things you can do with Sass, Compass, Blueprint, and their associated mixins, but I look forward to using them more in the future.

Seriously, how cool is it to be able to take something from a thought to full visual execution?

That’s not to say the road was perfect. In my next post, I’ll talk about the rest of what I learned, including my EPIC FAILS.

Ruby Mendicant University: Round 2

or: How RMU is teaching me to stop making excuses and get stuff done.

Note: I’m going to break this into several posts about the philosophical and technical learnings from my Ruby Mendicant University Web Development course:

Part 1: About the course & what it was like

Part 2: A first-timer’s process of styling a site

Part 3: What I learned from the course

If you’ve been following this blog for a while, you’ll already know that I participated in the September session of Ruby Mendicant University’s Core Skills course.

Much like the mafia, one doesn’t graduate RMU, you just get pulled in deeper. There are course offerings for alumni that range from more advanced Object-Oriented design practices, writing skills, statistics, and more. After a few months of relaxing mixed with a little bit of mentoring and casual participation, it was time for me to dig back in for the first Web Development course.

This time Jordan Byron (@jordan_byron on Twitter) ran the course, and it was his first time teaching. Anyone who has endeavored to tutor, advise, teach, or mentor knows that this is about an order of magnitude harder than you’d expect.

It was clear that Jordan cared deeply about helping us succeed, but that didn’t change the fact that everyone involved was biting off a bit more than they could chew. But for my part, Jordan’s help meant the difference between success and failure, and I learned a great deal thanks to his oversight and involvement.

For me, I’ve been learning Ruby and web development mostly by myself in my spare time for the last couple of years, and the sudden boost you get by having guided, time-bound projects is staggering. Even having been through it twice, it’s tough to imagine learning so much in less than a month.

Where I started from:

I had zero experience with CSS or true web design before this course. While RMU students must pass a Ruby-oriented challenge to get in, setting a baseline for Gregory Brown to work from, no such bar existed for the Web Development course.

This put Jordan at a bit of a disadvantage compared to the other courses offered within RMU. I showed up with no existing skills, expecting to be tutored in the most basic aspects of styling web applications.

The course:

The course itself was tough. Here were the requirements, roughly, in my words:

1. Submit an existing project for peer review, and review at least 3 classmates’ projects. Keep the discussion relatively high-level, more about frameworks, challenges, etc. rather than implementation details.

2. Take an existing project from barebones functionality to a fully styled site.

3. Create a geo-oriented project using Google Maps or similar geo API.

For me, step 2 took the lion’s share of the time. As it wound up, this list was a little *too* tough, and relatively few (or perhaps none?) completed all the requirements. The session was deemed a good pilot for future sessions, and a lot was learned on all sides.

“Uh oh, I’m gonna drown.”

There wasn’t a lot of additional instruction. There was a goal, and a list of potential resources and tools (put together by Jordan and augmented by the students). Jordan’s work is also open-sourced, so it was possible to go see how he solved similar problems if you were willing to dig into the code, though I discovered this a bit too late.

I quickly realized that I was already in over my head, and this “sink or swim” course would likely see me fail unless I drastically upped my output. For a relatively experienced web developer, this would have been 5-10 hours a week.

But like the core course, I found myself far enough behind that I required about 20-25 hours a week to catch up to where I should have been in starting the course. I’ll talk about why that may not have been such a good thing in the final post.

First assignment: Peer review

The first assignment was straightforward, simple, and fun. Our job was to post some work we’d done, ask questions about it, and comment on the work and questions of our peers.

I wound up commenting on all but two of my classmates’ projects, and hoping in vain that I’d get back around to the other two. I learned a couple of things that I was immediately able to do to improve my site, and saw some cool implementations that others came up with.

I did have to run out and research a little before I felt comfortable answering a lot of the questions. All in all, the first assignment was a bit time-consuming, but not particularly difficult.

Second assignment: Style a website from scratch

I’ll cover this at length in my next post. Basically, it took all but the first few and last couple of days.

Third assignment: Geo-aware application

I basically flubbed the final assignment, having left myself with less than 48 hours to complete it. After Jordan cleaned up my messy code, I got a basic mapping tool running using GeoKit to geocode an address, and Google Maps to display it. All in all, not my finest hour, but I’ll cover a bit of what I learned in the final post.

In Part 2, I’ll go through some of the implementation details, and what I had to learn in order to take a webapp from a barebones implementation to a fully-styled, “invite your friends” site.

I’ll also ask the flame-baiting question, “Does CSS suck?”

The 5 life-changing lessons I learned from RMU

It’s been nearly 2 weeks since I completed my Ruby Mendicant University course and joined the growing ranks of RMU alumni. I’d hoped to put together my thoughts earlier, but the exhaustion has just worn off.

Being on the extreme “novice” end of accepted students, the experience of RMU was more trying (and tiring) than perhaps some others. But experience or no, it’s pretty intense. On the other side of the crucible, I find myself with several lessons I’d managed to escape until now. I thought they’d be worth sharing.

Lesson 1: When you see opportunities, don’t forget opportunities to help.

For those who aren’t familiar, Gregory Brown is a profoundly skilled, pragmatic, and good-hearted developer who saw a big hole in the education of Ruby developers: too many reach an intermediate level and are unable to make further progress.

I must admit that the conniving marketer in me would have seen a very easy way to extract money from the wallets of these budding developers. But Greg’s instincts being more of the “change the world” variety, he saw an opportunity to experiment with the idea that open source ideas can change the face of education.

People that join RMU are taking advantage of one of the best learning opportunities available in the world of programming, and it’s completely free to participate. I hope with that opportunity comes a sense of a longing to help. You may have earned a spot in the program or alumni status, but it’s humbling to think that the community has bought your way into a first-class education.

I think Greg’s passion for contribution to a larger cause is inspiring and contagious. RMU is slated to launch over 100 open source projects in the next year, and there will be ample opportunity to contribute (financially, by volunteering, or on the projects themselves).

Lesson 2: Find an excuse to take the first bite of the apple.

I don’t know if it’s just me, but I imagine that many new programmers are intimidated by the world around them. It sometimes reminds me of what it feels like on the first day of high school. The projects are big and solve complex problems, other programmers are megageniuses, and established community members seem as if they had been assigned that status by deity. Also, some of them have moustaches.

It was a fellow student, Anita Kuno, who worked with me to crack open a relatively complex project and dissect it. At first it looked impossible, and alone, I would have given up. Anita’s advice was to find something I understood and latch on. I did, and was surprised to find a piece I could get my brain around. Then, working my way outward, I figured out the purpose of the program and got to understand its architecture.

That’s the nature of programming, I think, and RMU was the first to bring that out for me. There’s no reason to be intimidated: it may take a little extra work, but it’s not hard to find a way to get your foot in the door.

Whether facing a difficult problem with a blank sheet of paper or a complex project that seems impenetrable, the big revelation for me was “OK, so I can’t solve this. So what can I solve?” After that, it’s just a matter of time and work before the solution unfolds, and it’s profoundly gratifying.

Lesson 3: A working product comes first.

I’ve heard it pontificated, but RMU drilled this into my brain: Priority 1 is to ship. Before RMU, I had 3 or 4 half-products pushed in a mutant state with no ability for people to interact with them.

During RMU I shipped 2 functioning products. They’re proto-sites with no CSS and limited capability, but I learned an incredibly valuable lesson. You should be in a big hurry to make something that sees the light of day, solves a problem, or makes someone smile.

That’s not to say that sloppy code is OK in shipping products; that’s just douchey, especially to newbies like me. But prettifying beyond the point where someone else could read, interpret, and contribute on your project seems a lot less valuable than getting another awesome feature or product shipped in that same timeframe.

Lesson 4: Do not underestimate the power of community.

RMU is not a solo gig. The people I’ve interacted with have taught me nearly as much as Greg. I believe it’s actually engineered that way.

However, I don’t think even Greg anticipated the quality or quantity of response he’d get from community members. The people that have gathered from around the world actively participate in IRC chats, cross-project contribution, impromptu projects, and even contributing to the core of RMU itself… it’s staggering to me.

It’s also been great to see the alumni stick around to help the incoming group with questions and moral support. The community is the culture and the brand of RMU. Ultimately, this community will surpass Greg as the “owner” of RMU (and he’s no stranger to this concept after running several open source projects).

The idea and pitch for RMU was strong enough to attract a passionate group of people, but it’s the people that bind to each other and to a shared goal. These are friends from all over the globe that I plan to stay in touch with indefinitely. How cool is that?

I don’t know what I’m going to do with the rest of my life, but I hope it leverages the good that a passionate, engaged group of people can do.

Lesson 5: Don’t listen to DHH.

OK, that was a blatant poke in the eye. But DHH and Jason Fried would tell you never to launch a product without a business model, and I imagine they’d tell you never to launch a community initiative without a sustainability model.

But if Greg had waited until he had a solid “business plan” behind RMU, it may never have gotten off the ground, leaving the situation in the world exactly as it is. Or it would be drastically different, scaled down, or less ambitious in its goals.

Instead, RMU has already helped dozens of developers “level up”, and created an incredibly tight and productive global community, with tremendous upward momentum.

Sometimes you just have to take a breath and jump, and figure out how to land safely on the way down.

Greg’s fearlessness in tackling the problems that RMU confronts is inspiring. By nature, I’m a cautious cat. I measure two hundred times and cut once. I would rather not participate than risk rejection or looking stupid. I was almost too afraid to become a father. Why should I be afraid of any of that? Being afraid is not how you change the world.

So I guess that’s the real lesson 5: Not just ignoring, but obliterating fear is the only way I’m going to make a dent in my life or in the world.

Thanks to Greg, Jia, Jordan, and everyone that’s contributed to RMU so far, and I hope to pitch in when and how I can.

So yeah, RMU was valuable for me. It’s indisputably valuable for the community. Hope you’ll help keep it going.