RoyTomeij.com

RubyNation: March 23 & 24

2012-02-16T08:42:13Z

March is going to be a busy month: I'll be speaking at RubyNation (tickets available at the time of writing), which will take place on March 23 & 24 in Reston, VA (USA). It has a great line-up and I'm looking forward to meeting some of our overseas clients. Find a short description of my talk below.

Modular & reusable front-end code with HTML5, Sass and CoffeeScript

Do you know that feeling when you start a brand new project, telling yourself you're going to keep your front-end clean this time, and end up with an impossible mess after just a few weeks? Find out how to keep things tidy using HTML5 and modular Sass & CoffeeScript, for truly reusable code.

Sass doesn’t create bad code. Bad coders do.

2012-02-10T08:01:53Z

I'm no fan of cross-posting, but I feel so strongly about this one that I just need to point you to my article on The Sass Way, in which I debunk some arguments against using Sass. Sorry if you were expecting the essay here: it's just one click/tap away.

Comments are closed here, feel free to comment at the original source.

Wroc_love.rb: March 10 & 11

2012-01-30T06:56:56Z

I'm happy to announce that I'll be speaking at wroc_love.rb, which will take place on March 10 & 11 in Wrocław, Poland. It's going to be a fun little conference (about 250 attendees if I'm not mistaken) and features a line-up with speakers such as Avdi Grimm and Jim Gay. Find a short description of my talk below.

Modular & reusable front-end code with HTML5, Sass and CoffeeScript

Don't use class names to find HTML elements with JS

2012-01-24T16:10:00Z

In the days before HTML5, when we wanted to bind JavaScript events to an element, we would find the element based on its class name (or the rel attribute). After all, using a class name won't invalidate your HTML, is easy to target (specially with a library such as jQuery) and provides a hook for styling. But those days are over with the introduction of better suitable techniques, and using class names to find elements leads to confusion and maintenance issues. For true separation of styling and behavior you should use custom data attributes instead, with added benefits.

It's not "wrong"

In the sense of "not being according the specifications" it isn't wrong (when using HTML5). In the HTML4 specification the W3C is clear on the intended use of the class attribute, saying it should be used "as a style sheet selector (when an author wishes to assign style information to a set of elements)." The HTML5 specification on the other hand, says: "Assigning classes to an element affects class matching in selectors in CSS, the getElementsByClassName() method in the DOM, and other such features." So when writing HTML5, you're creating completely valid code.

Our example

Imagine a situation where you want to apply some interaction to a list of people in various age groups. You have groups of 0 to 9 and 10 to 19 year olds. In your HTML you use class="0-9" and class="10-19". Now you can find all elements belonging to the group of 0 to 9 year olds with $('.0-9') (jQuery syntax), so you can bind an onclick event to them. After a while you decide it's fun to style all children with a playful icon, so in your CSS you add a background image for any elements having the .0-9 class (I know that won't work, as it isn't valid CSS, it's just for illustrative purposes). You're doing test driven development, so you make sure to have a test that validates that the JavaScript interaction on the element behaves as intended. Works like a charm!

The problem

After a while you're replaced or a new developer is added to the team, and the project owner says he would like that little icon we show for small kids to be visible for everyone up to 12 years of ago. Piece of cake for the new guy: just rename the class name 0-9 to the more generic kid in the CSS and make sure the HTML reflects all children up to 12 use this new class name. From all other elements the 10-19 class can be removed; it's inaccurate and not used anyway. Your new guy or girl reloads the page and sees it's all good.

If you're not doing any JavaScript testing, you're already screwed at this point, since there's a fair chance that this change will go into production unnoticed. Looking great, but without the JavaScript events, because there are no elements to find when looking for $('.0-9'). Sure you could expect your developers to hit every single element after making a trivial change, but that would be too expensive (and you know they won't anyway).

Bonus points for you if you run tests against your JavaScript; the above should definitely trigger an error. Now you're tasked with fixing your broken code. Changing your JavaScript to use $('.kid') doesn't work, as it finds more than just children up to 9 years old. Time to add a second class name, reinstating the previous structure. Congratulations: you've spent over an hour on essentially adding kid as a second class name to some elements.

Now imagine that in the starting situation you want to target everyone up to age 12 from your JavaScript. The simple fix is to simply change 0-9 to 0-12 in both your HTML and JavaScript and you're done. Unless you're doing rigorous manual testing, you won't spot what just broke. There's no automated tool out there that will fail on "show playful background image on all children up to 9 years old", which is what will happen when not changing the class name in your CSS as well.

Time to really start separating structure, styling & behavior

You're doing a good job by binding events in your JavaScript instead of using nasty onclick attributes in your HTML; separation of structure and behavior is important for various reasons. Of course your HTML and CSS need to be linked in some form, as do your HTML and JS. But can targeting elements based on their class name really be considered separation between styling and behavior? You're tying all three layers together, leading to the issues outlined above.

Use custom data attributes instead of class names

HTML5 brings the joy of being able to use custom data attributes. I suggest using those exclusively to tie HTML and JavaScript together, leaving class names for styling with CSS. It's a simple solution to a common problem and doesn't require more work than the previous approach. We could just use our kid class name for the background image and add data-age-group="0-12" (or something more generic) to the elements we want to target in JavaScript. jQuery doesn't have any problems with finding all elements in a certain age group with $('[data-age-group="0-12"]'), or if you want any element with a certain data attribute regardless of value, $('[data-age-group]') (this works in IE6 when using jQuery or the getAttribute() method).

Key/value pairs have more semantic meaning

You'll gain more semantic meaning when using data attributes. Where "0-9" could mean basically anything, "age-group" is quite clear on what its value is about. It enables you to add a similar metric later, without refactoring. If you want to add the number of pets someone owns you can just add data-pets="0-9". When using class names, you would have to refactor your 0-9 to something like age-group-0-9 first, change it in your JavaScript and then add pets-0-9 as a second class name.

Data attributes enable a modular approach

When writing a piece of JavaScript that will be reused throughout various of your projects you want something that just works, regardless of styling. Say you created a "plugin" that takes a regular unordered list and displays all items in the list n at a time with some fading effects. When not relying on class names for styling you can just drop this in any existing code, for instance by simple adding data-carousel-items="2" to your <ul>. Your script can find all elements with that attribute and use their values to determine how many items to show at a time, doubling as a config option. It doesn't require any change in the HTML apart from adding that attribute and the CSS can remain untouched.

Let's make this a best practice.

Update: It's slower, and that doesn't bother me

As discussed in the comments, looking up elements by data attribute in jQuery is slower than by class name. In this jsPerf test the $('.class') operation can be performed ± 124,000 times per second. The $('data-foo="bar"']) operation only ± 26,000 times (tested on Chrome). Yes, it's over 70% slower. No, it isn't slow. Imagine there are 2,500 elements to search through; it will take under 100 milliseconds. IE sucks of course, with IE9 handling only just over 7,000 operations/second (sorry for the wait). It works for me.

Modernizr & the Sass parent reference

2011-10-19T21:30:00Z

This technique is very simple, but often overlooked because the parent reference & is mostly used at the beginning of a selector, like:

a
  color: #000

  &:hover
    color: #f00

Since & does nothing more than repeat the parent selector, it gives us an excellent way of easily implementing custom styling based on features detected by Modernizr. Just have Modernizr add class names to your <html>-tag and for instance do the following to only apply the box-shadow if the browser supports it (the box-shadow mixin comes with Compass, the .boxshadow class name will be added to your HTML by Modernizr):

#about

  h1
    border: solid 1px #000

    .boxshadow &
      border: 0
      +box-shadow(5px 5px #000)

This outputs:

#about h1 {
  border: solid 1px #000;
}

.boxshadow #about h1 {
  border: 0;
  box-shadow: 5px 5px #000;
}

A use case would be a fairly large element with a box-shadow, which makes repainting the page on iOS extremely slow. When only using a box-shadow when there's a .no-touch class name, touch devices won't have to deal with expensive shadow calculations.

My ArrrrCamp talk: Stop Swashbucklin' and Shipshape yer Front-end

2011-10-09T14:23:33Z

A few days ago I spoke at ArrrrCamp in Ghent, Belgium. I had heard of the conference before, but never went there during it's prior four years of existence. If those editions were of the same level of quality, I should have. Excellent talks, three tracks, mojito's (no, really) and a proper lunch.

With the introduction of the Rails 3.1 asset pipeline and Sass & CoffeeScript coming with Rails nowadays, this seemed like a good time to speak about the benefits of using front-end meta languages. I added Haml and Compass to the mix to cover the basics for doing all your markup, styling and behavioral coding using meta languages. Some key elements of the Rails 3.1 asset pipeline were discussed, with a strong focus on the new way of fingerprinting files, not using Sprockets for Sass and what actually happens when precompiling assets.

This appearance was my debut speaking at a "real" conference. I've done local user groups and meetups in the past (and got some planned for the near future), but hadn't been asked to speak at a conference with paying attendees before. This new experience can pretty much be summarized in one word: "awesome". The organizers took good care of all and I had a blast with both speakers and attendees, specially Jim Gay (lead developer Radiant CMS) and his wife Amy, Brian Quinn (CTO Spree Commerce) and Marius Marnes Mathiesen (Gitorious).

I'm the first to admit there's room for improvement when it comes to my speaking skills, but after all I'm pretty happy with how it went. Turn-up was fine (I guess half of the attendees attended my talk) and I received positive feedback afterwards. Timing was just right, with enough time for Q&A. While people didn't ask too many questions after some other sessions I attended, there were plenty at mine. Those also gave me a better understanding of the questions back-end developers have when it comes to front-end in general (not linked to front-end meta languages or Rails); food for some blog posts and a new talk I'm going to propose to other conferences (more on that in another post).

The slides are up on Speaker Deck, which looks a whole lot better than Slideshare, and embedded below.

Stop abusing the placeholder attribute

2011-06-15T07:09:51Z

The placeholder attribute saves web developers from using JavaScript solutions to tackle a simple task: display a placeholder text in a form input. Right now though, the bulk of all forms using this attribute is doing it wrong. By using this feature in a way that was never intended developers create confusion amongst visitors, sometimes even leading to unusable forms. On top of that it opens the door for data integrity issues.

According to the W3C HTML5 specification on the placeholder attribute its intended use is clear:

The placeholder attribute represents a short hint (a word or short phrase) intended to aid the visitor with data entry. A hint could be a sample value or a brief description of the expected format.

Meaning you can have a text input that has a label in front of it saying "job title", and a placeholder that says "e.g. CEO and philanthropist". It's a great way to indicate what kind of data, being the format or content, you're expecting from a visitor. The W3C also states:

The placeholder attribute should not be used as an alternative to a label.

And that's where the majority of developers go wrong. They do just that, crippling the user experience.

First, there's missing context. Once a visitor focusses on a form input he has to remember what it is again he's supposed to fill in. It could be some secondary phone number, but was it for his cellphone or office phone? The only way to an answer is clicking outside of the input and giving it focus again. In case he already entered some data, he will need to remove that first.

Then there's validation. After submitting the form something may be wrong. The visitor is often shown an input with a red border and the generic "please check your input", or something more specific along the lines of "please enter your phone number without dashes or spaces" (which is a retarded error, you should fix that for the visitor on the server side anyway). Should we really expect a visitor to copy his input to the clipboard, lose focus, read what he was supposed to enter, focus on the input, paste his original text back in and fix any mistakes?

Last but not least there's the problem of data integrity. For instance, when a form starts with two inputs, for first and last name, a visitor may enter his last name first (in some countries it's customary to enter your last name first). When done filling out the form he glances over it, making sure it looks fine. After submitting there's no error, so apparently we're all good. Now the database has a first name for last name and the other way around.

Bottom line: always provide a label that goes with an input. Yes, you will have to take that into account in your design. Yes, it will make your form take up more space. Yes, it will make it way easier for a user to submit a form. As an added bonus this also works on older, non-HTML5 capable browsers. A form should be perfectly usable without placeholders.

Static site using nanoc

2011-05-27T08:25:46Z

This site now runs on nanoc, a static site generator running on Ruby. The old Wordpress install went out the window and I only migrated two posts; the ones that people are likely to land on via search engines. I chose a static site because that's what all the cool kids have. Besides that I was pretty much done with showing my latest tweet, etc. Just go to Twitter if you want to know. A static site also saves me from any possible security issues (it's all just HTML) and updates to Wordpress and its plugins. Best of all: I can just write my posts in Haml now. Deployment is done by running an rsync task in Rake.

For syntax highlighting I use the CodeRay gem, based on instruction in this post and some Googling. This site is open source, so if you want you may just clone it at GitHub.

As for actual blogging: we'll see how that goes...

The perfect home theater setup with automated downloads

2009-11-18T23:00:00Z

Warning: this post is very much outdated. I will write a new one with more awesomeness soon.

A friend of mine asked me to write about my (near perfect) home theater setup, including the automated downloading of new episodes of TV series. This post is a first attempt, and I will probably revise it numerous times in the future.

Please note that downloading (not distributing) TV series for personal use is legal in my jurisdiction.

My setup involves an HD-Ready TV (720p), Mac Mini, Harman/Kardon 5.1 receiver, SABnzbd+, Eweka, XBMC, MyTvNZB, TheTvDB & more. I will go over it in the following chapters:

hardware & connection
automated downloading
organizing & watching

I assume you already know about usenet, NZB files, etc. If not, start googling.

Hardware & connection

For an excellent image, I have a Sony Bravia HD-Ready TV (720p) connected to a Mac Mini (2007 model; Core 2 Duo, 1.82GHz, 1GB RAM) with a DVI-to-HDMI cable. For audio I have a 5.1 speaker setup, connected to a Harman/Kardon AVR 247 receiver. The Mac Mini is connected to the receiver using the optical out.

The Mac Mini is connected to a 20mbit ADSL connection, although I end up with roughly 17mbit. I connected the Mini with an actual cable, since the internal wifi antenna is kind of crappy. Luckily I already had UTP cabling running through my walls.

To store all TV series I have two 1TB and one 1.5TB Western Digital Elements hard disks connected to the Mini (yes, that's a grand total of 3.5TB). I recently changed the 80GB hard disk in the Mini to a 320GB model, so I can use that one as a temporary storage for downloads. That way the external disks can go to sleep while I'm still downloading, since the internal hard disk will often spin anyway. SABnzbd+ (see below) unpacks the stuff directly to one of the external drives. When a drive is almost full, I tell it to unpack to a new one.

This basically is all there is to say about my hardware. You only need to remember to connect both the video & audio digitally, and don't use the wifi if you want some proper speed.

Automated downloading

This is where the fun starts! When I get up in the morning, yesterdays TV series (the ones I wanted to download) are waiting for me. Downloaded, unpacked, repaired if damaged, moved to the correct location and with downloaded episode information & artwork. Lets start with the setup for downloading.

Since the Mac Mini sits near the TV anyway, idling all day (& most of the night too), this is the machine I use for downloading. I download all my stuff from usenet, by connecting to a paid usenet provider. You want proper retention (the time stuff is available on the server), and Eweka (the one I use) provides over 250 days of it for EUR 7,50 per month. Great deal!

To actually download the stuff I use SABnzbd+, which can download, extract, repair, rename & move your stuff. It uses NZB files as a way of knowing what to download. On one of my external disks I have a "download" directory and a "series" directory. Configure SABnzbd+ so it knows it should download to "download", and move it to "series" after it finishes. Make sure to enable the "TV sorting" feature on the "Config > Folders" tab, so your downloads get organized properly. I use this filepath/filename structure: %sn/Season %s/%sn - S%0sE%0e - %en.%ext. This way your series end up something like this: "Burn Notice/Season 1/Burn Notice - S01E01.mkv" (it doesn't always clean up filenames as nicely as this, but that usually doesn't matter).

Now we have set up the automated downloading and sorting, we have to let SABnzbd+ know what it should download and where to get it. For this I use the RSS feature, to be configured on the "Config > RSS" tab, in combination with MyTvNZB. Go there, select "only show x264 or better" and check all the series you want to dowload. After saving it will prompt you with the url for the RSS feed to use in SABnzbd+. Add it there, and make sure you set the category to "tv".

That's it for the automated downloading! You now have your mean & lean downloading machine setup so it automatically downloads new episodes of your favorite series in HD. You might want to cap the download speed of SABnzbd+ at something around 2mbit below your max, so you still have enough bandwidth for regular ol' web browsing.

Organizing & watching

To keep track of what TV series I have, which episodes are unwatched, read episode summaries and of course actually watch them I use XBMC. Set it up (lots of guides for that, and pretty straight forward too) and tell it that the "content type" of your "series" directory is "TV shows" (get the context menu by right clicking, or holding the "menu" button on your remote until it pops up). You can do this for multiple directories on multiple hard disks, and they will all show up in one combined library. Enable "library mode" and hit "update library". It will now use the excellent TheTvDB webservice to find general information, plot summaries and artwork for your series. If some series don't show up, go to TheTvDB and look it up there; the name probably is slightly different than your directory name. Turn of library mode temporarily, right click the directory and select "change name". Change it to how TheTvDB spelled it, hit "done" and turn library mode back on. After updating your library it will show up.

I have "hide watched items" turned on, so I only see stuff that needs watching. Matter of personal preference. If you want to control your XBMC with a remote, there's a free iPhone app for that in the app store! Of course you can also use the regular Apple Remote, or an all-in-one (I can highly recommend the Logitech Harmony).

I hope this post is helpful in setting up your perfect system. If not, or you need more details, leave a comment!

update: Updated my setup (new hard disks) and added some info on XBMC.

Vodafone Mobile Connect On Osx 10.6 (Snow Leopard) With An E3730 Data Card

2009-09-14T22:00:00Z

After trying numerous "solutions", I finally managed to get my Vodafone "express data card" (the E3730 by Option) to work on OSX 10.6 (Snow Leopard), together with Vodafone's "Mobile Connect" software.

I don't know if this works with all versions of Mobile Connect, but at least it did with this one: Vodafone Mobile Connect 2.11.04.00. After installing the Mobile Connect software (if you don't have it yet), the trick is to "update" the drivers for the data card to the OSX 10.4 (Tiger) version. For this you need to download the Option drivers (Option forgot to add some extensions, so this goes to the proper zip I made after fixing them).

Simply open the dmg, install the 10.4 drivers and you're done (or at least: I was).

PS: NO thanks to the Vodafone help desk, which doesn't know sh*t and has been keeping me and numerous others in the blind since Snow Leopard was released. Spend a few $ on the developer release next time guys!