Replace existing code blocks with blockquoted code blocks

find . -type f \( -name "*.coffee" \) | xargs sed -i 's/#\s\s\s\s\s/# >    /g'

Add four spaces to the beginning of every coffee file

find . -type f \( -name "*.coffee" \) | xargs sed -i 's/^/    /g'

Remove preceeding spaces and # symbols from single line comments

find . -type f \( -name "*.coffee" \) | xargs sed -i 's/^\s*#\s//g'

Replace lines that are only made up of # symbols with an empty line

find . -type f \( -name "*.coffee" \) | xargs sed -i 's/^[ \t]*#\{1,3\}//g'

Replace lines that are ony made up of spaces with an empty line

find . -type f \( -name "*.coffee" \) | xargs sed -i 's/^\s*$//g'

Rename all coffee files to litcoffee

find . -type f \( -name "*.coffee" \) -exec rename -v 's/\.coffee$/.litcoffee/' {} \;

Compile litcoffee files

coffee --compile ./

Bonus: SVN Remove all coffee files

svn st | grep ^! | awk '{print $2}' | xargs svn delete

My assumptions are that you do not use any block comments (###) and that you do not have any lines that comment out code e.g. # foo = 'bar'. While these will just get turned into regular text it’s probably a good idea to quickly look through your litcoffee files to make sure that things aren’t messed up. This is especially true if you have block commented out code. In that case you will probably end up with blocks of code that will actually get parsed and break stuff.

Today there many different devices for personal computing: laptops, tablets, smartphones—and we use completely different interfaces for them, even when they come from the same company. Now that seems a little bizarre when you consider that all of these different devices are just different faces of the same thing. You have apps, you have content, contacts, and messages, and you need to access them in a way that suits your situation. That’s why we set out to create something completely new. A family of interfaces for each of these devices. Individually great in their own right, and also coherent as a group.

One OS, multiple expressions

My assumption here is it will work just like Ubuntu for Android:

• Your phone runs Ubuntu, so you can do all the things you would do on a desktop but with an interface that is designed specifically for small-screen devices.
• You can plug it into your desktop computer and continue to work and play just as you would normally—with a mouse, keyboard, and monitor, but powered by your phone.

There’s a cute video about Ubuntu for Android, and there’s a real-life demo that help to explain the concept.

The difference between Ubuntu for Android and Ubuntu for Phones is that the former is just Ubuntu as we know it, but on a phone. Ubuntu for Phones, on the other hand, is still Ubuntu but with a beautiful, phone-centric interface.

Privacy and portability

My biggest issues with computing have always been privacy and portability. Unfortunately, I’ve had to compromise on privacy to achieve portability. This mostly means that I end up using a lot of web-based services for things that I would typically want to keep private, such as email and passwords.

In an ideal world, I could use a desktop app at work, on the road, and at home without ever going on the web, and without having to sync my devices. In reality that syncing process gets really fucked up. I end up emailing myself backups and importing on whatever device I’m working on, or something gets viewed on one computer but becomes unavailable on another. Ubuntu’s new take on personal computing appears to marry the best of both worlds, removing the need for syncing and allowing you to be selective about what you put in the cloud.

Commercial Viability

The downside is that there aren’t any takers yet, and Ubuntu needs full support from carriers and manufacturers to move forward. The upside is that a version of Ubuntu for Phones that runs on the Galaxy Nexus is going to be released in the next few weeks.

Let’s be honest: a commercially-available Ubuntu phone may never see the light of day, even with Ubuntu’s relationship with Dell. But I bet we’re going to see a run on Nexus’ in the next few weeks.

Even though I’ve been doing OOP for some time, I still find myself questioning what I’ve done when it comes to JavaScript. Something about dynamic languages throws me off and I get really sloppy—It’s like JavaScript pulls me into some parallel dimension where I just throw a bunch of unrelated shit into an object and call it good. In the end I have this, thing, with a bunch of semi-related utility functions, but no real objects in the OOP sense of the word. So yeah, as soon as I saw the title I knew it was a must read.

But what I think really did me in was Zakas’ transparency about the whole thing: self-publishing and the extra effort required to do so; the separate formats he wanted to support (yay .mobi!); the fact that it was written in markdown (!); the beta process and updates to final copy; and the pricing structure. Seriously how cool is it that you can pay what you like (within a certain range), and see how much he’s making off each copy sold.

The whole thing is just plain cool. And oh, by the way… it would probably make a great Christmas present (hint, hint).

These days I’m always trying to be conscious of whether my opinion on some topic will add an extra dimension to a conversation that’s already been had a thousand times over; I second guess whether my voice will be heard among the throngs, more intelligent than myself; I worry about the backlog of sub-par posts; even the idea of being helpful to others has become a blocker.

Some days it’s nice to just be real and open and informal. I heart web 1.0.

A tiny bit of history

I started blogging in 2002 on Blogger, just a while before they got bought by Google. When I graduated from college in 2003 I thought it would be an awesome idea to set up a web server in my house. I upgraded my internet service to DSL and put together my own blogging platform. It was awesome until the power went out and my email server shit the bed. After that I started hosting with third parties.

My first post ever

I thought it would be so cool to write a blog as a series of acrostic poems. Besides being a silly idea, it only lasted for about 10 posts. Anyway, don’t judge—the web was much more kind to bizarre forms of self expression back then. At least I had great vocabulary.

On October 20, 2002 I spent half of my work day hunched over a cheap laminate desk at the leasing office where I worked. With pencil and paper I wrote and revised. 10 lines later I had written this, the inaugural post of my soon-to-be epic blogging career (lol):

IN ACROSTIC
It’s a Blog, but not the norm.
Nix all that aberrated form!

A Blog should be in perfect prose
Composed of nicely rhyming rows
Relating facts of daily life
Or lessons learned (from time to time).
So enter here and read along,
To pass the time in clever song—
It’s a Blog but not the norm.
Created In Acrostic form.

I mean now that I’ve re-read the thing, it’s really not half bad. It’s actually kind of a cool way to start blogging.

I was boring until 2006

Regardless of my awesome start, I was pretty boring and stupid until 2006. So I’ll just skip everything up to that point.

In late 2006/early 2007 I ran a whole series about pricing out a website design. It was originally published for my freelance company, Bajooter—I know, it’s a horribly stupid name, but in my defense it was intended to get the attention of the old-folks to whom I was marketing (BTW, it kind of worked, but I sucked at business).

In 2007-2008 I had a total↗ hard-on↗ for Drupal, so I also republished The Secret of Great Small Business Websites wherein I admittedly splooge all over my screen espousing my (brief) love-affair with said CMS.

2009 was the year of minimalism. I sold all of my possessions and stripped my blog down to the bare minimum. Then I wrote a bunch of posts about it, generally obsessing about anything that might be considered superfluous, including navigation, plates, and cups.

Lessons learned

I deleted the shit out of my blog in 2010 and then later regretted that decision. A few days ago I found the backup and that’s when I noticed that I had been blogging for almost one tenth of a century.

So what have I learned after all that time? I’ll tell you:

1. Most of the time I post stupid shit that has no right being published on the interwebs
2. Only a handful of people are actually good at mixing business and personal on their blogs
3. I’ve always been really bad at ending blog posts

# * Defines abstract *primitive operations* that concrete
#   subclasses define to implement steps of an algorithm.
# * Implements a template method defining the skeleton of
#   an algorithm. The template method calls primitive
#   operations as well as operations defined in AbstractClass
#   or those of other objects.
class AbstractClass
  templateMethod: () ->
    @primitiveOperation1()
    @primitiveOperation2()
  primitiveOperation1: () ->
  primitiveOperation2: () ->
# Implements the primitive operations to carry out subclass
# specific steps of the algorithm.
class ConcreteClass extends AbstractClass
  primitiveOperation1: () ->
    console.log "primitiveOperation1"
  primitiveOperation2: () ->
    console.log "primitiveOperation2"

Usage:

concrete = new ConcreteClass()
concrete.templateMethod()

I usually like to make the template method a static method that instantiates the class and runs the other methods. That way there’s no way to fuck it up.

# * Abstract class with static template method
# * Instantiates the class and calls its methods
class AbstractClass
  @templateMethod: () ->
    cls = new @()
    cls.primitiveOperation1()
    cls.primitiveOperation2()
  primitiveOperation1: () ->
  primitiveOperation2: () ->
class ConcreteClass extends AbstractClass
  primitiveOperation1: () ->
    console.log "primitiveOperation1"
  primitiveOperation2: () ->
    console.log "primitiveOperation2"

Usage:

ConcreteClass.templateMethod()

# * Is configured with a ConcreteStrategy object.
# * Maintains a reference to a Strategy object.
# * May define an interface that lets Strategy access its data.
class Context
  constructor: (@strategy) ->
  contextInterface: () ->
    @strategy.algorithmInterface()
# Declares an interface common to all supported algorithms. Context uses
# this interface to call the algorithm defined by a ConcreteStrategy.
class Strategy
  algorithmInterface: () ->
# Implements the algorithm using the Strategy interface.
class ConcreteStrategyA extends Strategy
  algorithmInterface: () ->
    console.log "ConcreteStrategyA"
class ConcreteStrategyB extends Strategy
  algorithmInterface: () ->
    console.log "ConcreteStrategyB"
class ConcreteStrategyC extends Strategy
  algorithmInterface: () ->
    console.log "ConcreteStrategyC"

Usage:

context = new Context new ConcreteStrategyA
resultA = context.contextInterface()
context = new Context new ConcreteStrategyB
resultB = context.contextInterface()
context = new Context new ConcreteStrategyC
resultC = context.contextInterface()

The three-fold nature of responsive design

In my opinion, responsive design is three-fold:

• Layout
• Images
• Typography

Layout is pretty straight forward. Design your breakpoints around the natural flow of your design, not your device or resolution-specific limitations.

Images are more difficult, but a lot of time and attention has been devoted to solving the problems surrounding them (picture, srcset, prefetching, etc.).

Typography seems to have had very little attention paid to it, however. Information Architects have put a lot of thought and effort into it and should be considered required reading on the topic.

The responsive typography use case

The main issue I have with responsive typography as it stands, is that it is typically packed in with layout, e.g. increase the font size based on the resolution of the screen. In reality that is a poor approach. Consider the following examples.

Imagine a user browsing your app on a standard desktop resolution of 1366×768. Then put your app inside a Facebook canvas. You are now nearing the same resolution as a 1st gen. iPad. The current approach says, “scale the text,” but the end user is still on a desktop. They haven’t changed the position of their screen, so why should the text get bigger?

Or what about the Kindle Fire HD? It has a massive resolution of 1920×1200—that’s the same size as my desktop! The user will fall outside of most tablet queries and get a tiny little font that would look great on a desktop, but is awful on a handheld device.

More succinctly, screen size is not a good indicator of how text should be rendered.

CSS media types, for the fail

I think the best solution to the problem is CSS media types. Media types have been around for a while, and they’ve got exactly what we need to address the typography use case, as well as other issues. The W3C sums it up so perfectly in the spec:

One of the most important features of style sheets is that they specify how a document is to be presented on different media: on the screen, on paper, with a speech synthesizer, with a braille device, etc.

Hell, they even outlined my whole thesis:

a document will typically need a larger font on a computer screen than on paper. Therefore, it is necessary to express that a style sheet, or a section of a style sheet, applies to certain media types.

I can imagine it now… slap in a little <link rel="stylesheet" type="text/css" media="handheld" href="handheld.css"> action, or throw in a little @media handheld {} and voila! Beautiful text perfectly scaled to the device the user is on.

Shitty support across the board

Unfortunately, this is not the current state of the web. A List Apart explained the problem way back in 2009 and it’s still largely the same. This is why we can’t have nice things:

Many mobile browsers have implemented this feature, but in different ways:

• Some read only the handheld style sheet.
• Some read only the handheld style sheet if there is one, but default to the screen style sheet otherwise.
• Some read both the handheld style sheet and the screen style sheet.
• Some read only the screen style sheet.

The work so far

There are a few solutions that can ease the pain regarding media types, but there isn’t anything solid yet. I put together the CSS Media Types project on GitHub that has a couple example solutions, a baseline for testing handheld support, and even a Browserscope test.

A call for support

1. I want to make a call to those influential individuals who are shaping the future web: Media queries don’t go far enough without media types. We need media types and we need them to be reliably and consistently applied in all browsers.
2. And to the community at large: we need a polyfill for CSS media types that forces browsers to load and apply stylesheets/media queries consistently, regardless of support. This will get us by until more browser vendors come on board with proper media type support.
3. Lastly, I need more data. Please check out the Browserscope test page on as many random non-desktop devices as you can find. And if you have any resources that may be of help, please let me know. I’ll compile them here as a reference going forward. Thanks!

Continue the conversation on Google Plus or Twitter.

# Defines the interface of objects the factory method creates.
class Product
# Implements the Product interface.
class ConcreteProduct1 extends Product
class ConcreteProduct2 extends Product
# * Declares the factory method, which returns an object of type
#   Product. Creator may also define a default implementation of
#   the factory method that returns a default ConcreteProduct
#   object.
# * May call the factory method to create a Product object.
class Creator
  factoryMethod: () ->
  operation: () ->
    product = @factoryMethod()
# Overrides the factory method to return an instance of a
# ConcreteProduct.
class ConcreteCreator extends Creator
  factoryMethod: (id) ->
    switch id
      when id is 1 then return new ConcreteProduct1()
      when id is 2 then return new ConcreteProduct2()

Usage:

class Client
  @run: () ->
    creator = new ConcreteCreator()
    console.log creator.factoryMethod 1
    console.log creator.factoryMethod 2
    console.log creator.factoryMethod 3

# * Declares the interface for objects in the composition.
# * Implements default behavior for the interface common
#   to all classes, as appropriate.
# * Declares an interface for accessing and managing its
#   child components.
# * Optionally defines an interface for accessing a
#   component's parent in the recursive structure, and
#   implements it if that's appropriate.
class Component
  constructor: () ->
    @list = []
  getComposite: () ->
  operation: () ->
  add: (component) ->
# * Represents leaf objects in the composition. A leaf
#   has no children.
# * Defines behavior for primitive objects in the composition.
class Leaf extends Component
# * Defines behavior for components having children.
# * Stores child components
# * Implements child-related operations in the
#   Component interface.
class Composite extends Component
  add: (component) ->
    @list.push component
  operation: () ->
    console.log @list
  getComposite: () ->
    @

Usage:

# Manipulates objects in the composition through
# the Component interface.
class Client
  @run: () ->
    # Create a Composite object and add a Leaf
    composite = new Composite()
    leaf = new Leaf()
    composite.add leaf
    composite.operation()
    # Add a Composite to the Composite
    composite2 = new Composite()
    composite.add composite2
    composite.operation()