If you write code for a living, you probably follow fellow code-writers (on your favorite following service of choice) and read what they have to say about the new shiny they are currently working on. You probably follow them because they often write about their new shinys. Their new shinys are usually really shiny, and when they release a demo of shiny it’s really freakin' cool.

You probably wish you were coding something new and shiny too. So you read some tutorials and give the shiny a try. But the shiny is just so new and fragile and intricate that you quickly get to a point where you can’t do anything more with it: too confusing, kind of broken. Since you can’t do anything with the new shiny anyway — it sure as hell isn’t going into your produciton environment anytime soon — you put it away.

But other coder people on your follow lister-magigger start playing with the shiny too. Maybe enough people polish up the shine that it’s now showing up on blog posts and at conferences and the like. Pretty soon people start saying that the new shiny is really the New Way, and probably soon the Only Way.

Or at least it seems like it.

So you pick up the shiny shiny again, which is really much more brillant than it was when you first played with it. Maybe you can do more with it this time. Maybe you get lost in the super shininess of it for a whole evening.

But then you go back to working on a project with your non-shinies. Maybe it’s a big big project and now you can’t find the time to get to the shiny again.

Then a year or so goes by. In that year you’ve worked on some projects that were challenging, rewarding, frustrating and exciting, but never with the shiny.

You tried to bring up the shiny on one of your projects, but your teammates decided it wasn’t a good fit.

At this time the shiny has gotten really popular. All the cool kids use the shiny. Everyone else wants to be using the shiny. There are jobs listings in San Francisco for people that can use the shiny.

San. Fran. Cisco.

At this point, you’re obviously falling behind in your industry of code people because you’re not well-versed in the shiny. You start to get anxious about your job. You start to figure out what meatspace events you can skip so you can, finally, spend time getting up to speed with the shiny shiny.

At this point, a lot of what you do just feels like it really really could and really really should be done with the shiny.

At this point, every hour spent coding how you’re coding and not coding in the new shiny way is an hour wasted.

Stop it, please

I find it really tempting to fixate on whatever impressive new bleeding edge thing shows up at the top of a feed. I know plenty of other coders do too. That’s because we shape the news we’re interested in. We post, upvote, and RT the same shit about the same new thang at the same time during the same lull we have in the same project we’ve been working on for the last few months.

I don’t think I’m exaggerating when I imply that many of us seem to hold passionate interest in something for a few mere months before something shiny comes along that seems that much better. Even when we’re getting paid for that passion.

Look, that year that just went by where you managed to successfully do a job where you type all day and make something that makes other peoples' lives better is no minor accomplishment. It’s a fucking successful thing that you did and it is time to be proud of it.

You also haven’t mastered the tools you do every day and you know them a heck of a lot better than you do the new shiny ones, so why not try to refine something you’ve got a decent footing with rather than start all over with something new for the sake of its newness?

This post is a reflection on a recent post on Twitter’s engineering blog about moving some of the client-side UI rendering back to the server, away from Javascript.

Funny enough, I recently burned some cycles experimenting with Backbone, Spine and Ember and decided I couldn’t find any of them useful for me right now. Javascript MVC is the shiny of the moment for me. I felt defeated that I wasn’t going the extra distance to master one of these tools.

Again, NO use for any of them right now, still felt like I should be using one of them.

But straight jQuery is doing me a world of good. It’s a tool I’m very familiar with, but can’t even begin to give a decent explanation on how it works. It’s not shiny anymore, but it works amazingly well, and I need to feel better about the work I do with it.

When Blog Better Boston asked me what I was going to speak about, I said “design hacks” off the top of my head.

As the day approached and I thought more about my audience, I realized that the room would be filled with bloggers of varying degrees of technical proficiency. Something more general was in order.

The presentation wound up being something of a primer on typography & CSS. I wanted to get bloggers to understand any attempts at a redesign should start with the content, and the essence of written content is typography.

Since its relatively easy to play with type in CSS (most bloggging platforms have a user-editable “custom styles” field), I gave a quick overview of what CSS is and how to start experimenting.

We unfortunately started a little late and I hit my time limit before getting too deep into the CSS fun, but I got a couple great reactions from my first real workshop.

My slides really just supported my narration, so they don’t stand on their own well. Nonetheless, here they are:

So Apple updated the iPad the other day?

Yes.

Retina display? Faster? Better camera?

Yep.

The last one was the iPad 2 right?

Yes.

Do you know what they called the new one? The iPad 3? The iPad HD?

The New iPad.

Right.

Yeah. What’s it called?

The New iPad.

That’s what I want to know! What’s the name of it?

What do you mean? The name of the new iPad?

Right. What did Apple name the new iPad?

The New iPad.

Yes. The one they just announced. What’d they call it?

The New iPad.

The new iPad that they just announced.

The New iPad. Yes.

They named it the iPad Yes?

What?

I reached a small, nightmarish victory yesterday while testing some new styles on HipHost in IE: two of my CSS files surpassed Internet Explorer’s CSS Selector Limit for a single stylesheet file: 4095.

Yay!

Fuck.

Hm? What’s this?

Woah.

Bless is a node.js module that checks a CSS file for the IE selector limit. If it reaches it, it breaks it into smaller files and then links them all with @imports in the original foo.css file.

But we’re not running node.js. :(

After extensive Googling, there’s no good equivalent or port of Bless for Compass, Sass, Rails, or even straight Ruby.

From Compass to Bless

As a Compass user, my ideal scenario would be to run a Ruby version of Bless after every compile. A reasonable alternative would be to pass the Compass output to Bless.

Luckily there is a way to configure a callback in our compass.rb, so that certainly puts us on the right path:

on_stylesheet_saved do |filename|
    # do something with fileneame
end

We can then run the Bless executable (blessc) like this:

on_stylesheet_saved do |filename|
    system('./lib/node_modules/bless/bin/blessc',filename,'-f')
end

In the immortal words of the Apache placeholder DocumentRoot: “It works!”

Requisite Gotcha

For HipHost, we’re still on Rails 3.0. That means no asset pipeline, so we’re using the asset packager gem.

For produciton, asset packager takes the stylesheet groups you’ve defined and concatenates and minifies them. It calls these files groupname_packaged.css**, which of course screws up the @import directives Bless was kind enough to create.

My solution was to make a new stylesheet group for foo_blessed1 so at least the Blessed @imports are minified and created for production. I then just go into foo_packaged.css and manually update the path for foo_blessed1.css to foo_blessed1_packaged.css.

UPDATE: Did it.

in vendor/plugins/asset_packager/lib/synthesis/asset_package.rb find the method compress_css and add the following:

source.gsub!(/-blessed\d+/,'\0_packaged')

I’m no Ruby developer…

I took a quick stab at hacking asset_packager to do this for me, but gave up having spent too much time working on this already. Anything I accomplish will probably be pretty specific to our needs and not be worth open-sourcing, but I’ll certainly share my success when it happens.

Mixing Rails and Node.js

This approach obviously creates a non-gem dependency situation for our app. But installing node.js on any major package management system is as to easy to worry much about it:

brew/apt-get/yum install node
curl http://npmjs.org/install.sh | sh

Better solution?

Ping me if you have some ideas. Porting Bless to Ruby feels like the cleanest solution, but I may be wrong. If there’s a better way to glue node modules as dependencies to Rails apps, that could be it too.

Word of OS X 10.8 (kitty code name: Mountain Lion) dropped today. The big summary is its a continuation of the iCloud-ification of your data across all devices.

Part of the announcement was a beta release of Messages.app, formerly known as iChat. Now your iMessage conversation history syncs between your OS X machine(s) and iOS devices seamlessly.

A quick test with a friend and it works as expected. “Holla” jumps up in the conversation on the iPhone, iPad and Air almost simultaneously.

So we started using it while working on our OS X machines. Then the iOS devices went to sleep. Then things got interesting.

With a conversation happening on one device but being synced across many, knowing which device is having the conversation is key to the user experience. Apple figured this out so well that I just had to jubulate in its subtlty with this post.

When typing in Messages.app, iCloud knows your in Messages.app. When typing on the iPad, iCloud knows your on the iPad. When you’re engaged in a conversation on one device, the other devices do not get notified of new messages. This avoids cross-device notification flares currently experienced by calendar alerts, which makes for an especially noisey 9:55 AM for me.

Now say you’re working, working, working and Messages.app is out of focus. At this point, iCloud doesn’t know what you’re up to. A new message comes in. Since iCloud doesn’t know what you’ve done since the conversation stopped it notifies all your devices.

You’re still in OS X so you reply to the message via Messages.app. Now you’ve got notifications to dismiss on your iOS devices, right? Total first-world bummer, right? Nope: iCloud dismisses the notifications across devices once the conversation picks up again.

No extra X-ing out of things. No burnt seconds of your life. Just gets rid of them because it knows you’ve started talking again.

This is a total win. Anyone who’s had an IM client open on an iOS device while signed in on the desktop knows that the scenario of multiple notifications about the same thing at the same is annoying to the point of untenable. Power users might deal with it for its synchronous novelty, but real users won’t.

I imagine the entire minagerie of Notification Center-enabled OS X apps will work this way. Maybe it already works this way on iOS and I just never noticed it (I’m stingy with what I allow in my Notification Center).

Maybe I’ll finally stop being reminded of our daily scrum by three screens at the same time every morning.

Boss: Do we think if we make these changes that this content will now be above the fold?

Me: You know, when I fold my laptop the screen shuts off and I can’t use the keyboard. This is going to be the case for a lot of our users too. It’s good enough content as stands; I really don’t think its worth considering the fold.

Yes, this is obnoxious. No, not all bosses can take a joke.

I’ve got high hopes for TextMate 2, which we know is happening for sure now. But Sublime Text 2 has been my goto editor for the last few weeks now.

Plenty to like, plenty to loathe, but its refreshing and it comes in Cobalt.

But being blessed with a 27" Cinema Display, one particular feature is providing that “I can never go back to a time before this” feeling I haven’t experienced since cold folding: column view. Specifically Columns: 4 ⌥⌘4.

Right now I’m mostly wearing the hat of Front-End Rails Developer at HipHost, which means I’m dealing mostly with four types of files: Controllers, Views, SASS stylesheets, and JavaScript.

Now here’s that wish: four columns + four file types + some light OCD = Assign File Type to Column.

I should be a good developer and just figure out how to make this happen. But then there’s that free time thing…

If anyone’s interested in this, drop me a line. I can at least give a brain dump of my thoughts.

I’ve been using — nay, depending on — SaSS and Compass for at least a year (I’ll get around to contributing, I swear). At the time when I picked it up, I was not familiar with Ruby or YAML, so its indentation-based syntax took a little while for me to wrap my head around.

But HipHost uses Ruby On Rails, so I’ve gotten to know and love Ruby. I took another stab at using the SASS syntax and now I’ll never go back.

The only problem is I’ve got quite a few .scss partials that I need to convert now. Well open up that Terminal; here’s one line of bash to the rescue:

You can replace that first *.scss with **_ or _*.css* depending on what’s in your pwd. Just remember to change your from (-F) argument accordingly.