dominic dagradi

Your Site Doesn’t Know How Big It Is

2012-01-16T11:10:00-05:00

One of the most common mistakes I see in web development is not adequately testing sites for a variety of viewport sizes. It’s more than just incorrect rendering on mobile devices, or looking bad on large screens. Issues with small browser windows are often overlooked in the course of building a site.

I notice this almost daily in my development environment, where I work with two 960px windows side-by-side. In so many sites I visit, I know if I see a scrollbar on the bottom of the page, I’m likely to see a min-width error when I scroll to the right.

Even Google Search gets it wrong. Here’s a screenshot of their search results¹ displayed in a relatively small (720px) window:

So far so good (mostly, but I’ll get to that in a second). What happens when we scroll the page to see the off-screen content to the right?

Uh-oh.

What Happened?

Google made the mistake of not defining the document’s minimum width. Throughout the site, multiple containing elements are given width: 100%, with the intention of filling the entire width of the screen with their content. The common misconception at play here is that width: 100% is the full width of the HTML document, when it actually represents the width of the window/viewport through which the user is experiencing your site². In the example window, any element defined with a width of 100% is really given a width of 720px. Elsewhere in the site, content is defined as wide as 980px, hence the appearance of overflowing its bounds.

In this case, both the “Google” bar at the top of the page and the main search bar are affected. The Google+ navigation overlaps with the menu of Google services, and makes it impossible to reach certain elements. In the search bar, the background stops abruptly before the search button, appearing broken.

This isn’t an isolated mistake. In a few minutes of searching, I found the same problem on many popular sites, including MSNBC, Penny Arcade, NFL.com, and Codecademy.

Simple Solutions

These are obviously large and complex sites. Let’s look at a minimal example. The code below exhibits the same error:

test.html - Example markup and styles

<style>
  #wrapper {
    width: 100%;
    background: red;
  }
  #main {
    margin: auto;
    width: 960px;
  }
</style>

<body>
  <div id="wrapper">
    <div id="main">
      My example content
    </div>
  </div>
</body>

Now, even though our #main div has a defined width of 960px, the background of #wrapper only extends to the width of the window (100% width). Any content in the #main div is visible outside of the wrapper due to the default overflow behavior, which allows content to be seen beyond its container’s boundaries.

All of this is trivially simple to fix though. Just tell the document’s root element what the smallest allowed width should be:

Simple fix

body {
  min-width: 960px;
}

That’s it. The layout and display issues are neatly wrapped up.

On the other side of the coin, sites that are built to be responsive or flexible don’t need to worry about minimum widths - they should scale down gracefully to phone-sized displays. But this presents an equally valid problem on a 2000-3000 pixel screen, where a site can be cumbersome to interact with if a maximum width is not specified (enabled by the aptly named max-width property).

What About Browser Compatability?

You’re safe in all modern — and most vintage — browsers. If IE6 support is still important to you, you’ll need to take the usual steps and employ additional trickery.

It’s safe to assume your work will be displayed on a screen with a reasonable resolution (>= 1024x768), but keep in mind that your users can and will find a way to view it in smaller windows. When you’re building your next site on a giant monitor, remember to drag your window smaller and larger than your comfortable width to make certain that everything is still usable.

Will W3Schools.com ever not be the top hit for a CSS search? One can only dream.↩
width: 100% also works as a relative measure when used on an element contained by another with a set width, but we’re talking about root-level elements in this example.↩

SOPAthetic

2011-12-16T19:00:00-05:00

During yesterday’s discussion of the Stop Online Piracy Act, House representative Steve King had this to tweet:

We are debating the Stop Online Piracy Act and Shiela Jackson has so bored me that I’m killing time by surfing the Internet.
Steve King, R-Iowatwitter.com/stevekingia/status/…

Heckuva job, Stevie.

Needless to say, this is abominable behavior from anyone, let alone an elected official. His response to constituents outraged by his sentiment was simply to say that people “need to get a sense of humor”. It’s nice to see our members of Congress taking their job so seriously.

SOPA aims to provide tools that could be used to easily censor the internet, similar to China’s “Great Firewall”. This sweeping legislation, crafted with little understanding of the issues at hand, could be fatally damaging to the future of technological innovation in our country.

Senator Ron Wyden (D-Oregon) is planning to filibuster the bill by reading the signatures of an online petition. It’s already passed one million signatures, and every voice is important. It’s also not too late to call, email or otherwise get the attention of your representative; Stop American Censorship makes contacting them as easy as filling out a form.

[Update] It looks like the vote on SOPA has been delayed, but that doesn’t mean it’s gone. Rep. Zoe Lofgren (D-California) has been answering questions today on Reddit, and stresses the importance of actually speaking to your representative instead of relying on digital media to get your message across. Both SOPA, and the equally disturbing Protect IP Act, will come to a vote in the near future.

“Read It to Me”

2011-12-01T21:30:00-05:00

Peter-Paul Koch, of QuirksMode, posted earlier this week about Siri and its potential to drive web accessibility. He envisions a horrible-but-possible future for the web, where digital assistants mindlessly reel off the contents of poorly constructed websites. Where I feel Koch misses the mark is in imagining that the future of interacting with the web will be limited by existing paradigms such as browsers and screen readers.

I think that, with rare exception, having Siri read long-form streams of content to a user is a less-than-desirable interface¹. One of its greatest strengths is its conversational style of interaction, providing a back-and-forth dialog that proves exceptionally effective. If Siri is in the middle of reciting a long passage of text, there’s only one option for responding: interrupt it.

Semantics

That’s not to say that there’s not a future for interacting with the web with voice. Rather, it requires constructing websites not only to be accessible for humans, but accessible for machines as well. There already are initiatives to make the web more machine readable, often falling under the umbrella of the semantic web. One of the most promising trends so far is the adoption of microformats, providing machine-readable chunks of data transparently within existing webpages.

But how does that relate to voice? Let’s use Koch’s example of shopping for Christmas presents:

Let’s imagine I’m the developer for QuickChristmasShop.com, and I want to make my product data available so customers can place last-minute orders as they’re frantically driving to the airport.² I know that Siri can find products on webpages that implement the correct microformats, and I mark up the products on our homepage using the hproduct format.

Now, the following interaction is possible:

Me	Siri, I want to buy something from QuickChristmasShop.com.
Siri	Got it. I found 12 products on sale there. - Siri displays a list of 12 products -
Me	Siri, please read them to me.
Siri	Red Widget Blue Widget Deluxe Widget - Siri reads nine more widgets -
Me	Great. Have 2 Deluxe Widgets sent to my house.
Siri	I’ve placed your order for you.

Obviously this is just a hypothetical example, but speaks to the power and potential of making data available in machine readable formats.

To see microformats in action, try searching Google for “chocolate cake”, or any other recipe. Google is smart enough to know about microformats relating to recipes, and provides you extra interface elements to filter your searches (“I want a chocolate cake with pecans!”). The future of accessibility on the web isn’t based in making things easier for humans to read, but in providing machines with enough information to understand what we want.

And it should be noted that iOS already has a best-in-class screen reader built in for the visually impaired.↩
I jest. Siri is a great hands-free interface, but really, pay attention to the damn road while driving.↩

Flexibility

2011-11-14T16:07:00-05:00

Last Friday, Bearded celebrated its third anniversary. It’s been a wild ride, and we’re all looking forward to what the future holds. To mark the occasion, we’ve launched a brand new website with a fabulous responsive design.

Our previous site, launched in November 2009, served us well over the years. But the web has become a more diverse place since then, with screens coming in increasingly varied sizes and touch-based devices more prevalent than ever. Obviously, it was time for a new approach. Enter responsive web design, the idea that a single design can be made to meet the needs of all your users without removing content or building a second layout.

Ethan Marcotte, the champion of responsive practices, recently shared his knowledge in an excellent book: Responsive Web Design. It’s an invaluable resource if you’re ready to get started with responsive designs. If a book is too long for your tastes, check out his A List Apart article for a briefer overview of responsive concepts such as media queries.

The Grid

In searching for a responsive grid system that met our needs, we came across Jonathan Clem’s excellent solution as a starting point for our own work. However, we felt it warranted some changes to better accommodate layouts with variable numbers of columns.

CSS grid systems traditionally define columns with a fixed width for content and a gutter on the right side, then removing the gutter on the last element in a row (typically by adding a “last” class to your HTML). This makes it difficult to allow for an elastic grid that can be easily reflowed. We instead opted for columns to split their gutter to both sides of the element, removing the need to track where any row begins or ends.

A simplified column mixin

@mixin column($cols: 12) {
  float: left;
  width: ($cols * $column + ($cols - 1) * $gutter_width) / $container_width * 100%;
  margin: 0 $gutter/2;
}

Usage

We chose the section tag as our base unit of layout. Let’s see it in action with a simple example:

sample.html

<div class="container">
  <section>
    Some content
  </section>
  <section>
    Some other content
  </section>
</div>

sample.scss

.container {
  @include container;
}
section {
  @include column(6);
}

As you can see, it lets us build completely semantic HTML, while not having to worry about which element appears last in a row. Combined with media queries (which allow us to know the size of the browser’s viewport and apply styles accordingly), it made it exceedingly easy to perfect our layout across a variety of screen sizes.

Get Some Code

I’ve affectionately dubbed our system YARG - Yet Another Responsive Grid, and you can grab it on Github to try it out today. It’s as bare-bones as possible and lacks proper examples and documentation, but it’s working great for us so far.

Like most similar systems, YARG is meant as a starting place for your responsive designs, to be taken apart and modified as you see fit. Go give it a download, and let me know what you think!

Google’s New Clothes

2011-11-05T14:03:00-04:00

Google’s recent focus on bringing a clean, uniform appearance to their web platform was a breath of fresh air from a company that has previously ignored design. Google+ was the first volley, with the rest of the product family being gradually updated to match. This was all great news: the most widely used web products were going to get better with a renewed focus on usable, beautiful experiences.

Clearly beggars can’t be choosers. What Google has finally given us is a mess. Rather than re-imagine how users interact with Gmail or Reader, the entire suite of applications has simply been whitewashed with a muddled skin of black, grey and red.

Sundry Unification

Integrating styles across a platform of previously disjoint applications is a huge challenge. Considering the number of people that had to work together, it’s admirable that all the apps now look like they belong to the same family.

But let’s sweat the small stuff. Attention to detail distinguishes the mediocre from the good from the great.

Three different headers (Google+, Reader, and Gmail)

Did anyone at Google look at the new site designs side-by-side before they were launched? Not only are there two distinct heading styles (white versus grey), but no header or toolbar shares a height between any app.

Lists are even more inconsistent in their appearance and functionality.

Many styles, none the same (Google Docs, Reader, and Gmail)

Pick a list style. Just pick one. Do columns get headings? Do we need the section of the site we’re on? The sidebar can’t decide what width it wants to be, and items that have been viewed aren’t the same color between apps. Even small details like shadows are completely jumbled: Docs shades the items below the heading only, Reader shades the sidebar only, and Gmail puts a shade above the entire page.

I know I’m picking nits here, but for a massive, cross-application UI rollout, I would expect consistency to be a priority. I want to be impressed by how seamless moving between Google apps is; instead I’m stuck wondering what’s going to work differently with this particular app.

Unreadability

Let’s take a look at Reader, the object of the greatest criticism in the last few days. It’s not unfounded: I use Google Reader to read things, and the recent changes have only hurt legibility.

Home page, Article view, and Fullscreen

Google clearly sees the future of the web as black and white. The only color used on the site is red (excluding the homepage title and search button for some reason), leaving content feeling stark. Adding a feed is certainly something I do occasionally, but it doesn’t deserve the same giant red button given to a frequent action such as composing an email. Further down the page, there is little to distinguish one section of content from another, with sidebars blending into both lists of articles and primary content.

Breaking with years of convention, links aren’t highlighted with anything but an underline. I never thought I’d miss a blue link so much, but the endless sea of black text quickly gets difficult to read.

Google has since made the links blue again. Good job guys! It’s a huge improvement, but the problem shouldn’t have made it out the door in the first place.

Previous designs focused on the article by isolating it and deemphasizing everything else with shades of pale blue. Now, an article’s reading area is loosely defined only by the content around it. Even short articles aren’t fully visible on laptop screens, due in no small part to the now substantial site header. Brian Shih, a former Google Reader PM, highlights the difference in height here. According to his measurements, the content area has been reduced by ~100px — 1/8th of my laptop’s total screen height. His full article on the Reader redesign is a deeper look at all the recent design and feature changes.

Switching to fullscreen (keyboard shortcut: F) just gives you the same small block of text extended to an illegible line length, instead of adopting the vastly superior paradigm of Readability or Safari Reader.

A Little Lagniappe: Gmail for iOS

Google also released an official Gmail app for the iPhone this week. It would be difficult to find a better example of putting lipstick on a pig without actually going to a farm and doing it myself. It’s literally just the existing mobile web app, wrapped in an App Store download.

MG Siegler takes care of the criticism here. It’s almost too easy. Google ships a native app, for one of their flagship products, on the largest mobile platform, and they can’t be bothered to test it? Or even write an app that has native scrolling? It’s sloppy and embarrassing. At least it was quickly pulled to fix the bugs with notifications, the only native feature it included.

A Way Out

My trust in Google’s platform has been eroded bit by bit with each successive botched launch and ill-conceived redesign. I don’t have much left. It’s clear I’m not alone in that feeling - it’s a core theme of MG Siegler’s article above, and I’ve seen it echoed by many other voices across the internet. I appreciate that Google is trying new things, especially with design. Their constant see-what-sticks approach, however, burns far more confidence than it creates. I think it’s time for them to take a step back and reevaluate their decisions before blindly charging forward again. There are already genuine offers from former Google designers to come back and help fix problems with Reader et al. Let’s hope they take them seriously.

Beam Me Up, Siri

2011-10-14T17:38:00-04:00

As the new iPhone starts landing in customers’ lucky hands, everyone is making the connection between Siri and the 1987 Knowledge Navigator concept. It’s the stuff of science fiction, teasing us with the possibility that we could create a world smart enough to understand our needs. I can’t begin to express how delightful it is to watch technology catch up to our dreams, one step at a time: we now live on the Starship Enterprise.

Tea. Earl Grey. Hot.

Kyle Baxter calls Siri the future of the web, and I’m pretty sure he’s right. Rather than teaching ourselves to think like a computer, we’re beginning to teach the computer to respond to the way we think. Making information easily available from recognized sources¹ and returning definitive answers democratizes knowledge in a whole new way.

Well, Wolfram Alpha and Yelp. It’s a great start, but I’m looking forward to a proper API. More on that in the future…↩

Designers and Developers Can Be Best Friends

2011-10-11T10:59:00-04:00

I was recently asked how great open source projects can have great design. It sounds like a complicated problem: designers and developers live in two worlds that rarely meet. What can we do to bring better design to our ideas?

As a developer, the desire to work on open source projects comes from a drive to share a particular idea or do some good via code. In doing so, I’m achieving my personal goals, and it feels great.

But how do I convince someone else to work towards my lofty and worthwhile dreams? For free? The same way we convince other developers to work on open source with us: ask for help. There’s a perception that designers aren’t interested in contributing to open software projects, which is wholly false. Any time I’ve wanted help with a project, I’ve had no trouble finding great designers ready to step up for a good cause.

Don’t Be Afraid of Expertise

As much as we like to believe we’re all superheroes, we can’t do everything. Just like you wouldn’t ask a great designer to build a complex Rails app, you’re probably not the one best suited to create a user experience masterpiece. It’s only natural to have multiple participants who are masters of various disciplines.

The process by which we all contribute to open source projects has been normalized over time: find something we can fix, fix it, and send along our changes. Unless you’re a project owner or core contributor, you follow this pattern 99% of the time. Why not just have designers drop a Photoshop file in our mailbox and call it a day, right? Designers aren’t Photoshop factories, wanting to merely spit out static images all day long. They don’t want to do that any more than we want to churn out code and never see it again. The process of creating a design that fully meets the needs of a project requires more than just telling a designer what you want, and handing off completed files.

Stop: Collaborate

Instead of asking for a homepage or a few mockups, invite them to become a core member of your team. Explain the concept of your project and use it as an excuse to get feedback from someone who knows nothing about what you’re doing. Then let them help you make it better. In a recent article reflecting on Google Wave’s rocky conception, Dhanji Prasanna, a former Google engineer, related his experience on the necessity of involving designers:

You need the same mix of experienced talent working in the UI as you do with traditional “serious” stuff. …taking design seriously is not about having a dictator fuss over seams and pixels. It’s about giving it the same consideration that you give any other critical part of the system.

At Bearded, our process revolves around designers and developers working in concert for the duration of building a product. Rather than one party handing off to the other with no feedback, developers offer feedback on project specs and initial design concepts, and designers are able to constantly review, respond to the project in progress, and offer new ideas and suggestions after seeing a concept implemented. Some features from the original designs don’t make it to the final product, and new features proposed by developers get added and designed along the way.

Every project we make is stronger for having feedback from all parties throughout the process. Find help early, and make having a designer the standard going forward.

Designers, You’re Not Off the Hook

Convincing developers to collaborate is only half of the battle. One important aspect of working with open source software is version control. The good news is that it’s not that hard! There’s some great articles targeted at teaching a designer-centric workflow involving git, a simple and popular version control system:

It’s a lot to take in, but it gets better. You don’t have to use the command line; there are great GUI utilities for all the major platforms to make using git easier. If you’re on a Mac, give Tower a shot, or try one of the many other git client available. Windows users, check out this list.

It’s Dangerous to Go Alone! Take these.

Some days, you won’t be able to find a designer. But all is not lost!

Start with a Good Foundation

Twitter Bootstrap is great. Really, really great. It provides a solid visual foundation that is a suitable starting place for most web projects.
Get Inside Their Head

The Non-Designers Design Book comes highly recommended as a resource for the technically minded to get a handle on the thought process that goes into a design.
Learn the Language

Use lynda.com (and, you know, Google) to strengthen your HTML and CSS skills. In order to facilitate communication, both designers and developers need to have a common language to speak. The combination of HTML and CSS does an adequate job of bridging that gap.

Make New Friends

The benefits of great design are too numerous to expound on. A poorly designed project will turn away new users left and right, while great design will draw in larger crowds. Seek out help from designers among your friends and acquaintances, or look online¹ for willing partners in crime.

There are some great social networks targeted at designers, such as Dribbble and Forrst.↩

Hacking Hacker Culture

2011-10-07T17:55:00-04:00

There’s a funny contradiction amongst developers. It’s a mark of pride to work the longest hours, drink the most caffeine, eat at your desk and sleep the least. Essentially, whoever can endure the most punishment gets to be king of the hill. Obviously I’m being hyperbolic, but it’s fascinating that we respect each other’s ability to disregard personal wellness.

In reality, all of these behaviors detract from the quality of work that we produce. The New York Times recently published an article about decision fatigue, explaining why we make poorer choices when exhausted:

It’s different from ordinary physical fatigue — you’re not consciously aware of being tired — but you’re low on mental energy. The more choices you make throughout the day, the harder each one becomes for your brain, and eventually it looks for shortcuts. […] Ducking a decision often creates bigger problems in the long run, but for the moment, it eases the mental strain. You start to resist any change, any potentially risky move.

The notion that, if you stay up just one more hour and have one more Red Bull, you’ll be able to solve that one nagging problem ends up being false more often than not. The deadlines are rarely important enough to risk the bad choices, and a fresh set of eyes in the morning usually solves all conundrums.

The other half of the problem revolves around taking care of our bodies. In The Creative Brain on Exercise, the author relates numerous studies that link exercise and physical activity with increased neuroplasticity, or “the ability of the brain to literally rewire itself”, which relates to both mood and the ability to think creatively. In the same article, he touches on the cultural tropes that may steer so many of us away from exercise:

A large number of artists and entrepreneurs resist exercise as a key element in their ability to do what they most want to do–make cool stuff that speaks to a lot of people. In the case of artists, I often wonder if that resistance is born of a cultural chasm that many artists grew up with, where jocks were jocks, artists were artists, hackers were hackers, and never the twain would meet.

Can we, as a community, dispel the perception that we’ll be better programmers at the expense of our health? Encourage yourself and others to make small changes throughout the day. Instead of having a second or third coffee, take a walk around the block. Instead of doing a ninth straight hour of work, go home and give yourself a break. Or go to sleep, because it’s 4 in the morning. Drink water instead of soda. Eat a salad — it’s tasty.

But I Really Like Red Bull

That’s cool. I really like coffee; it’s delicious, but it’s never helped me solve a problem late at night. When you’re mentally fatigued, there are few alternatives other than rest. Programming¹ is an active and engaging intellectual activity, and once fatigue sets in, you just can’t be your best.

I’ve been eating simpler, healthier foods and making myself get to bed before midnight during the week. My partner and I have been doing yoga as regularly as possible since this spring, and have just started the Couch-to-5k program together. My overall energy levels have significantly increased. I feel less stressed, happier at work, and more full of ideas than any time in recent memory. Eventually, the process becomes more refreshing than painful.

Sometimes it’s hard to make changes on your own. Find someone who also wants to exercise, or who’s interested in sharing the work of cooking healthier meals together. If none of your friends are interested in working out, go to the gym and make some new friends². (If you know me personally, I would love to work out with you!)

Rob Sanheim gave a great presentation about this at RubyConf 2011, inspiring many of my points. The more people working to destroy the myths surrounding hacker culture, the better. His slides are available here.

Also true of designing. And writing. And so many other professions.↩
Every person I’ve ever met at a gym has been kind, courteous and willing to teach. A lot like programmers.↩

Insanely Great

2011-10-05T21:00:00-04:00

My first computer was a Macintosh Plus. My father, a musician, bought it to use as a digital sequencer for creating new compositions. Sitting in his lap at just two years old, I watched in awe as he created incredible new sounds from a plastic keyboard. Playing games on it, I desperately wanted to create new and exciting adventures of my own. That small, gray box with a small, gray screen inspired a sense of wonder and joy that remains with me every time I touch a computer to this day.

Steve Jobs changed my life. He changed the way we interact with the world, and nearly every computer, phone and device today bears his mark in some way, large or small. President Obama expressed it powerfully in his statement this evening:

Steve was fond of saying that he lived every day like it was his last. Because he did, he transformed our lives, redefined entire industries, and achieved one of the rarest feats in human history: he changed the way each of us sees the world.

Thank you, Steve. For inspiring us all to think differently, and create insanely great things every day.

MacRuby Ups and Downs

2011-10-04T14:00:00-04:00

We’ve been building Briquette at Bearded¹ on and off since December 2010. When beginning the project, we chose to use MacRuby as a way to make the project more accessible to our developers that weren’t familiar with Objective-C, and to explore a possible future of native Mac OS X (and iOS) development.

For building new Mac apps, I would recommend MacRuby without hesitation. It delivers on the promise of bringing the best aspects of Ruby to native, desktop app development. Abstracting away from Objective-C’s sometimes-too-verbose syntax is often a joy, and it’s useful to have access to the complete library of both Cocoa frameworks and Ruby gems². It’s a young framework that’s getting better by the day, and the good has consistently outweighed the bad.

But there are drawbacks, especially when using Xcode heavily. I want to touch on some areas that I feel have often been ignored, or covered inadequately, and pour a little cold water on the heads of anyone starting a MacRuby project. But just a little.

Objective-C: It’s Not Optional

One of our goals in choosing MacRuby was to simplify the learning process for developers with minimal experience with Objective-C and Apple’s frameworks. In practice, though, one can’t get by with zero knowledge of Cocoa APIs before diving into the Ruby wrapper.

Cocoa is a verbose framework. It’s actually one of the things I find most attractive about it. Xcode does everything it can to enhance the experience of coding with excellent method suggestions and code completion for Objective-C, but is unable to help in Ruby files. This lack of help, coupled with the need to have a grasp of delegates, actions, outlets, and XIBs/Interface Builder, makes MacRuby more difficult for someone coming from a purely Ruby background.

Deployment in the Walled Garden

Submitting to the Mac App Store can be a complicated process, even when using only vanilla frameworks. MacRuby (and Apple) have made this a moving target, whether it’s Xcode’s failure to sign binaries, MacRuby embedding itself incorrectly, or other build inconsistencies.

With Xcode 4.1, our current process is this:

Archive project with Xcode
Export archive from Xcode’s organizer
Embed MacRuby’s framework and compile the Ruby code from the command line
Manually code-sign app
Manually build installer package and submit with Application Loader

This process has actually gotten more complex over time, and it’s unclear where the fault lies in that. Initially, all building, embedding and compiling took place via Xcode actions, but over time, each step has broken down.

If you’re having any issues deploying, feel free to ping me on Twitter. It might be the subject of an upcoming blog post.

Blindly Debugging

Let’s look at an issue I just had to track down in the production build of Briquette.

10/3/11 1:03:54.260 PM Briquette: /Applications/Briquette.app/Contents/Resources/rb_main.rb:25:in `<main>’: undefined method `[]’ for nil:NilClass (NoMethodError)

That’s not a great error message: rb_main.rb is the root Ruby file of a MacRuby application, and the interpreter (in)correctly catches errors there. Maybe the stack trace will help more…

10/3/11 1:03:54.277 PM Briquette: (
 CoreFoundation                      0x00007fff8f78f986 __exceptionPreprocess + 198
 libobjc.A.dylib                     0x00007fff920c3d5e objc_exception_throw + 43
 libmacruby.dylib                    0x00000001001ec2ee rb_vm_raise + 430
 libmacruby.dylib                    0x00000001000cc6b9 rb_exc_raise + 9
 libmacruby.dylib                    0x00000001001f0c82 rb_vm_method_missing + 562
 libmacruby.dylib                    0x00000001001dc3d4 rb_vm_dispatch + 7828
 libmacruby.dylib                    0x00000001001df640 rb_vm_respond_to2 + 736
 libmacruby.dylib                    0x00000001001dab48 rb_vm_dispatch + 1544
 Room.rbo                            0x000000010898c8d4 Room.rbo + 6356
 Room.rbo                            0x000000010898cc65 Room.rbo + 7269
Room.rbo                            0x0000000108995de6 MREP_81CDDE71AED14C6D8C5A0685717E5E9E + 35574
libmacruby.dylib                    0x00000001001dc919 rb_vm_dispatch + 9177
libmacruby.dylib                    0x0000000100181d02 rb_objc_isEqual + 1842
Briquette                           0x0000000100019d6e Briquette + 105838
CoreFoundation                      0x00007fff8f77f11d -[NSObject performSelector:withObject:] + 61
Foundation                          0x00007fff88ed9830 __NSThreadPerformPerform + 214
CoreFoundation                      0x00007fff8f6fe241 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
CoreFoundation                      0x00007fff8f6fdaad __CFRunLoopDoSources0 + 253
CoreFoundation                      0x00007fff8f7248d9 __CFRunLoopRun + 905
CoreFoundation                      0x00007fff8f724216 CFRunLoopRunSpecific + 230
HIToolbox                           0x00007fff8e9a84ff RunCurrentEventLoopInMode + 277
HIToolbox                           0x00007fff8e9afc21 ReceiveNextEventCommon + 355
HIToolbox                           0x00007fff8e9afaae BlockUntilNextEventMatchingListInMode + 62
AppKit                              0x00007fff8b4abfc5 _DPSNextEvent + 659
AppKit                              0x00007fff8b4ab8c9 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135
AppKit                              0x00007fff8b4a820a -[NSApplication run] + 463
AppKit                              0x00007fff8b72635e NSApplicationMain + 867
???                                 0x000000010462a5ad 0x0 + 4368541101
libmacruby.dylib                    0x00000001001da979 rb_vm_dispatch + 1081
???                                 0x0000000104600c34 0x0 + 4368370740
???                                 0x000000010460059d 0x0 + 4368369053
libmacruby.dylib                    0x00000001001f55f6 rb_vm_run + 470
libmacruby.dylib                    0x00000001000ccd00 ruby_run_node + 80
libmacruby.dylib                    0x00000001001ec021 macruby_main + 385
Briquette                           0x000000010000180c Briquette + 6156
)

That narrows it down a little more. I can at least identify that it’s coming from my Room.rb model (lines 8-10). Better, but not great. The .rbo file extension is a compiled Ruby file, and as expected, being compiled wasn’t its life goal. It’s currently difficult to get good debugging symbols out of compiled Ruby, and the alternative — shipping uncompiled code — is a scary prospect³.

Even while developing, your tools will be limited. You can’t pause your application and step through Ruby code, since the built-in debugger isn’t designed to work with an interpreted language. The working solution is to use the tried-and-true print statement to query application state: effective, but far less valuable than Xcode’s advanced debugging (and profiling) tools.

At RubyConf this past weekend, @brixen’s talk about Nikita and Ruby tools included a great quip:

Ruby has the best tools
No OneEver

Debugging Ruby has never been a pleasurable experience, and it’s no different here. Hopefully future updates to MacRuby can address this with better Xcode integration.

Memory, or a Lack Thereof

@briquetteapp I like you but are you sure you need this much memory? d.pr/tggu
markoatwitter.com/#!/markoa/status/…

@briquetteapp Any upcoming changes around the memory consumption issue? It’s bad here: http://t.co/ay015aI
seeflanigantwitter.com/seeflanigan/status/…

Tell me about it, guys. No, we certainly don’t need all that memory. Honestly, we’re still trying to track this one down, though we’ve squashed quite a few bugs recently. The crux of the issue is that when profiling, as with debugging, we can’t use standard tools to examine what objects our application is leaking. Instruments, Apple’s profiling tool, isn’t aware of Ruby objects and considers them all leaks, making it difficult to extract real data.

The other potential snag is that using MacRuby forces you to require garbage collection in your application. Apple’s garbage collector is lacking, and not all Cocoa frameworks are garbage collection safe. Xcode 4.1, with the new LLVM compiler, does an excellent job of tracking down the latter issue in Cocoa libraries, but determining the source of leaks otherwise is nearly impossible.

Our memory issues could be due to our use of Webkit⁴, bugs in Apple’s garbage collector, leaks in MacRuby itself, or bad design in our Ruby code. There’s just no easy way to find out. I can say with certainty that MacRuby claims ~70-100MB of RAM per process. Where does the rest of it go? We’ll let you know.

Well That Sounds Awful

It’s not.

No really, it isn’t.

This isn’t a condemnation of MacRuby or its effectiveness as a framework. As a developer mapping my Ruby knowledge onto my Objective-C and Cocoa experience, I found some surprises along the way. I do want new MacRuby developers to be informed about potential pitfalls, and be ready for whatever challenges come their way. Despite the setbacks, MacRuby enabled us to rapidly prototype and iterate on an idea, and easily build and submit it to the App Store.

Bearded is where I work. It’ll be on the “About” page once that’s live, but if you’re impatient, check out the great work of all the Beardeds at http://bearded.com.↩
Some gems won’t work quite right. As MacRuby is an implementation distinct from the standard MRI Ruby, compatability issues can arise.↩
You can certainly ship a MacRuby app with uncompiled Ruby files, but it exposes any Ruby source code used by your application. See? Petrifying!↩
Seriously, Webkit is a bad citizen. Have you used Safari lately?↩

1.0

2011-10-03T11:46:00-04:00

Many painters are afraid of the blank canvas, but the blank canvas is afraid of the truly passionate painter who dares – and who has once broken the spell of “you can’t” once and for all.
Vincent Van GoghLetter to Theo Van Gogh

It’s time to scratch an itch I’ve had for a while.

Writing is a challenge to me. Just like in software development, it’s easy to fall into the trap of not being satisfied until something is perfect. More often than not, that leads to never releasing anything.

Seth Godin had a great post recently about barriers to writing, and hitting home the need to practice publicly. Rather than constantly revising until a product reaches an imaginary level of quality, release early, release often, and learn from mistakes and missteps.

So here we are at 1.0 - every post is a new project released to the public, and there will be a new post every (week)day for the next two weeks to get things started. I’m looking forward to talking about technology, code, and the inherent creative processes involved. Watch this space.