I have released a minor update to the sprite-factory ruby gem.

This version adds 3 small features:

Margins and Padding

For any of the layout options, including :packed, you can now add:

• :padding - around the image source and included in the css coordinates of the sprite.
• :margin - around the image source but NOT included in the css coordinates of the sprite.

The :margin option is most useful to avoid the bleeding that might occur when the browser scales to support increased text size or zooming (e.g ctrl+/ctrl-). Depending on the scale factor, the browser may decide to use an extra pixel of your source image leading to the next image bleeding through.

This can now be avoided using the :margin => 1 option to ensure a gap is included around the source image to take into account any bleeding that might occur (usually a value of 1 or 2 pixels is adequate)

This resolves github issue #15

Thanks to @halida for getting this started with github pull request #17

Support for :hover pseudo classes

If you want to specify a psuedo class such as :hover for some of your images, the library will now map -- (double dash) to a colon : in any source image filename. For example, with the following files:

  images/icons/alert.png
  images/icons/alert--hover.png

… the library will generate:

  img.alert       { ... first file  ... }
  img.alert:hover { ... second file ... }

This resolves github issue #14 - ‘handling hover states’

Support for per-image custom selector

If you want to specify a custom selector for each individual image, you can simply name the image files accordingly - the library will map __ (double underscore) to a single space ` ` in any source image filename. For example, with the following files:

  images/icons/div.foo__span.icon_alert.png
  images/icons/div.bar__span.icon_alert.png

… when run without any selector:

  SpriteFactory.run!('images/icons', :selector => '')

… will generate:

  div.foo span.icon_alert { ... first file   ... }
  div.bar span.icon_alert { ... second file  ... }

This resolves github issue #12 - ‘automatic selectors’

Installation

As usual, installation is just a gem away:

$ gem install sprite-factory

And detailed instructions can be found in the README.

Let me know if you have any problems/feedback.

Enjoy!

A little over a year ago I switched to vim as my editor of choice, and at the same time started using tmux to manage a split pane terminal, but I spent so much time getting up to speed with vim that I never really made much of an effort to embrace tmux - I learnt the shortcut key to split the window and that was about it - good enough for a while, but not exactly a power user!

Recently, the Pragmatic Programmers published an ebook by Brian Hogan tmux - productive mouse free development that made me revisit this tool and see what else I could get out of it - and boy, am I glad I did - tmux is a really useful tool, and Brian’s book covers it in an excellent, easy to read, and comprehensive format that covers the following areas:

• Learning The Basics
• Configuring tmux
• Scripting Customized tmux Environments
• Working With Text and Buffers
• Pair Programming with tmux
• Workflows

I have released a minor update to the sprite-factory ruby gem.

This version adds 2 small features:

Suppressing comments

You can now specify --nocomments to the sf script (or :nocomments => true in ruby) in order to suppress the comments that sprite-factory adds to the generated stylesheet.

NOTE: if you already minify your css then you probably dont need this

Support for images in sub-folders

Previous versions assumed that all images lived in a single folder with unique filenames, and the original file name was used as the CSS class to show the correct background sprite image, as shown here:

<img src='s.gif' class='high'>         <!-- e.g. filename was high.png   -->
<img src='s.gif' class='medium'>       <!-- e.g. filename was medium.png -->
<img src='s.gif' class='low'>          <!-- e.g. filename was low.png    -->

This is still true, and is the normal use case, but with v1.4.2 you can now (optionally) include images in sub-folders, for which the relative path name will be used for the CSS class to show that image in HTML:

<img src='s.gif' class='other_high'>   <!-- e.g. filename was other/high.png   -->
<img src='s.gif' class='other_medium'> <!-- e.g. filename was other/medium.png -->
<img src='s.gif' class='other_low'>    <!-- e.g. filename was other/low.png    -->

This also resolves github issue #11 - ‘sprite factory assumes unique basenames are used’

Installation

As usual, installation is just a gem away:

$ gem install sprite-factory

And detailed instructions can be found in the README.

Let me know if you have any problems/feedback.

Enjoy!

After my Christmas visit to the Computer History Museum I picked up a handful of computer history books and wanted to recommend a few of them to any programmers out there interested in how their tools and technologies came about.

Dealers of Lightning

Xerox Parc and the Dawn of the Computer Age

…a fascinating journey of intellectual creation. In the 1970s and ’80s, Xerox corporation brought together a brain-trust of engineering geniuses, a group of computer eccentrics dubbed PARC. This brilliant group created several monumental innovations that triggered a technological revolution, including the first personal computer, the laser printer, and the graphical user interface, only to see these breakthroughs rejected by the corporation. Yet, instead of giving up, these determined inventors turned their ideas into empires that radically altered contemporary life and changed the world

This is one of my favorite computer history books. The Alto was an unbelievably ground-breaking personal computer, and its story, along with other creations at Xerox PARC is full of interesting characters and fascinating stories such as when Gary Starkweather and Ron Rider were inventing the laser printer. Rider was working on the Research Character Generator (RCG) that scanned a computer image line by line in order to generate the position of all the dots the printer needed to print out - when a corporate reshuffle relocated him to another building over a kilometer away with no hard line of communication. Thus leaving the RCG generating data in one building for a laser printer waiting for that data almost a mile away.

“Don’t worry, you’ll be back together again in another year”

I have been neglecting my javascript state machine library for a few months while I wandered the world (of Skyrim!), and a number of feature requests have come in that now deserve a release - v2.1, that closes all the current outstanding github issues.

The code, along with updated usage instructions are available on github.

Enjoy!

New features include:

• Wildcard Events
• No-Op Events
• Custom Error Handler
• Cancelable onleavestate callback
• Other Minor Changes

In my recent visit to the Computer History Museum I had a few hours to pass on a flight from San Jose to Seattle, and I spent it with a new book in the genre of ‘self help for programmers’

• The Art of Readable Code

It’s a really easy read in 14 clean (and short) chapters:

1. Code should be easy to understand
2. Packing information into names
3. Names that can’t be misconstrued
4. Aesthetics
5. Knowing what to comment
6. Making comments precise and compact
7. Making control flow easy to read
8. Breaking down giant expressions
9. Variables and readability
10. Extracting unrelated subproblems
11. One task at a time
12. Turning thoughts into code
13. Writing less code
14. Testing and readability

As a fairly experienced developer, I found it mostly a review of ideas and patterns I have already come to agree with, that the author sums up nicely as:

Code should be written to minimize the time it would take for someone else to understand it

I don’t always succeed in that with my own code, but the further I get in my career, the more I appreciate just how important it is to write code that can be understood, maintained, and enhanced by others.

As such, I pretty much agree with all of the author’s points, and one piece of advice I was particularly happy to see:

Naming Test Functions - Don’t be afraid of having a long or clunky name here. This isn’t a function that will be called throughout your codebase, so the reasons for avoiding long function names don’t apply. The test function name is effectively acting like a comment.

I am usually aggressive about short, but meaningful, names… except when it comes to my unit tests when I sometimes go a little crazy with long descriptive test names, so its nice to read something that helps me understand why I do that!

When I’m learning something new (such as the Android platform), I’ll surround myself with books about that specific technology, but in general I much prefer these kinds of ‘make yourself a better programmer’ books.

If you like these kinds of books, (you are a programmer, right ?), then don’t forget to check out these similar titles:

• Code Complete - Steve McConnell
• The Pragmatic Programmer - Andrew Hunt & Dave Thomas
• The Passionate Programmer - Chad Fowler
• Clean Code - Robert C. Martin
• Beautiful Code - Andy Oram
• The Practice of Programming - Brian W. Kernighan & Rob Pike
• Programming Pearls - Jon Bentley

… and I assume you already own at least 2 copies of the first one on that list :-)

This blog has been quiet for a while…

• Real life has a habit of taking over during the holiday season.
• New work project - getting up to speed on Android programming.
• … yes, I have been playing skyrim.

So I haven’t had much time to write for a while.

However, I did get a very nice break over christmas where I went down to California and managed to finally visit the Computer History Museum - Yes, I am a geek, this is a technical blog, deal with it!

I really, really enjoyed the visit. I had almost the full day, but I wish I had a few more hours - I’ll have to plan a second trip. The museum is very well organized, although I wasn’t always 100% sure I was going in a chronological direction.

Most of the museum is dedicated to the main exhibition Revolution - The First 2000 Years of Computing, taking us through from the Abacus to the World Wide Web:

• Calculators
• Punched Cards
• Analog Computers
• Birth of the Computer
• Early Computer Companies
• Real Time Computing
• Mainframe Computers
• Memory & Storage
• The Art of Programming
• Supercomputers
• Minicomputers
• Digital Logic
• Artificial Intelligence & Robots
• Input & Output
• Computer Graphics, Music, and Art
• Computer Games
• Personal Computers
• Mobile Computing
• Networking
• The Web

I grew up with personal computers in the 80’s, 90’s and beyond, and I’ve read a lot about what I (used to) think of as computing history… Xerox parc, Doug Engelbart and Ivan Sutherland, Homebrew Computer Club and early Apple and Microsoft days… and I went in expecting mostly personal computer stuff, but I now realise that there is much, much more to computing history than just the personal computer.

I mean, of course, I knew of the Babbage Engine, the Eniac, Enigma, Collosus and Cray and such, (not to mention the Abacus and the Slide Rule), but I hadn’t really put them into context until wandering (in chronological order!) through the museum, and it was really fascinating.

I also really enjoyed seeing some of the computers I grew up with, the Commodore64, ZX Spectrum, Amiga, SpeakNSpell, Little Professor… and of course the games, Pong, Atari, PacMan, Infocom…

I have only a few, very very minor negatives:

• Coverage is broad, but not necessarily deep - the nature of museums.
• As a software guy, I thought programming was a bit short changed.
• Wish the store had a larger selection of books.
• They have an awesome programming languages chart on the wall, but not available to purchase (yet).

Even so, I highly recommend any self respecting computer geek taking a day out to go visit in person, or even just online:

• The Computer History Museum
• Revolution - The First 2000 Years of Computing
• The Babbage Engine
• Chess - Mastering the Game
• Other Exhibits

Here are some photo’s of the bits that stood out for me (in no particular order):

Previously, I released an experimental javascript Boulderdash game and promised to write up some articles about how the game works:

• play the game now
• view the source code

The topics I wanted to cover include:

• the game loop
• the game logic
• rendering
• decoding the c64 cave data

So, lets finish up by talking about the Boulderdash cave data…

Decoding the c64 Cave Data

Previously, I released an experimental javascript Boulderdash game and promised to write up some articles about how the game works:

• play the game now
• view the source code

The topics I wanted to cover include:

• the game loop
• the game logic
• rendering
• decoding the c64 cave data

So, lets continue on by talking about rendering the game…

Decoupling the game logic from the rendering code

Yesterday, I released an experimental javascript Boulderdash game and promised to write up some articles about how the game works:

• play the game now
• view the source code

The topics I wanted to cover include:

• the game loop
• the game logic
• rendering
• decoding the c64 cave data

So, lets continue on by talking about the good stuff…

The Game Logic