Tangible Colors

D'oh

Sat, 12 Feb 2011 09:18:09 -0800

Sometimes, you discover a feature you always thought it didn't exist,
while it was just in front of you. In my case, searching in the
current folder instead of the whole mac by default.

Permalink

The Sorcerer's Apprentice

Thu, 10 Feb 2011 18:01:00 -0800

I'm currently working on a tiny, tiny programming language, Just for fun. There is no intention to use it in the real world, I just find the creation process very interesting (and pedagogic). Two principles:

Purely functional. This means you pass something to the program, and you get a result. That's all.
Stack based, and RPN syntax. Not very intuitive to use, but simple to parse.

Here's what it looks like:

Did I say it's a tiny language not suited for real world use? Remember that.

I called it Maize, and I will write a post soon about this experience. Expect: Ruby, Parslet, sensationalist title about creating your own language, and fun.

Permalink

Why do programmers write apps and then make them free?

Sun, 06 Feb 2011 08:14:00 -0800

Question asked on Redd… eh, on StackExchange. Some of the answers are obvious (“more lines on the résumé”), others are surprising (despair, revenge). My personal take? Collaboration is greater than competition. If you are not convinced of this, you’re not spending enough time on GitHub.

Permalink

Class Variables :(

Sun, 06 Feb 2011 07:57:00 -0800

From Wikipedia:

In object-oriented programming with classes, a class variable is a variable defined in a class (i.e. a member variable) of which a single copy exists, regardless of how many instances of the class exist.

Seems useful. But not everywhere. In fact, depending on the language you’re using, you even might want to avoid them.

As an example of bad use of class variables, I recently stumbled upon a Java implementation of the Minimax algorithm.

/** A Minimax instance represents a single AI entity. */
public class Minimax {

    /** Default depth used by the algorithm. */
    private final static int MAXDEPTHDEFAULT = 4;

    /**  Actual depth used by an instance of Minimax. */
    private static int maxDepth = MAXDEPTHDEFAULT;

    // Constructor, a method executed when creating a new instance.
    public Minimax(int depth) { // Other parameters are omitted for simplicity
        maxDepth = depth;
        // ...
    }
}

(Note: in Java, a variable marked as “static” is a class variable.)

The depth is the number of turns the AI entity can see in advance. It can be viewed as the toughness of an entity: the greater the depth, the farther in the future the AI will be able to see, and the harder it will be hard to beat.

Nothing wrong with MAXDEPTHDEFAULT, because it’s a constant (by the way, the concept of “constant variables” is rather funny). But maxDepth will annoy us. Why? Because we won’t be able to create multiple AI entities with different depths. If we want to watch two AI entities playing against each other:

ai1 = new Minimax(4);
ai2 = new Minimax(6);

The two AI entities, ai1 and ai2, will use a depth of 6. Yeah, even ai1. We can’t test if an AI with a high depth will effectively beat an AI with a low one. We can find worse situations where this kind of class variable is defined in an interface, impeding other programmers' work.

And the solution, in this case, is simple: just remove the static keyword from maxDepth.

Permalink

Chrome 9

Fri, 04 Feb 2011 09:40:00 -0800

Chrome 9 is out! WebGL and Google Instant are among the new features, but the inspector had a facelift too.

Example with google.com:

Permalink

37signals' mobile web framework in CoffeeScript

Wed, 02 Feb 2011 05:53:00 -0800

We knew that 37signals was working on a new CoffeeScript framework for mobile apps. Now we know more, from their blog: It’s called Cinco, and “ties together Backbone.js, Zepto, the Eco templating language, and Stitch.” They still plan to open-source it.

I can’t wait anymore so I already started writing my own CoffeeScript framework which I’m going to use (at least) until they release Cinco.

Permalink

Untitled

Mon, 31 Jan 2011 12:44:11 -0800

Permalink

First steps with CoffeeScript (and how to use it with Rails)

Thu, 27 Jan 2011 01:48:00 -0800

From the CoffeeScript homepage:

CoffeeScript is a little language that compiles into JavaScript. Underneath all of those embarrassing braces and semicolons, JavaScript has always had a gorgeous object model at its heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way.

Gorgeous syntax, and wise additions like list comprehensions, classes, inheritance, implicit return, etc. Being just awful at vanilla JavaScript, I was very interested in CoffeeScript. The version 1.0.0 of the language was recently released, so I decided to give it a try, and it looks like I’m going to stick with it.

http://jashkenas.github.com/coffee-script/ does an excellent job at introducing CoffeeScript, so I won’t try to do better here. Instead, I’m going to focus on:

CoffeeScript with Rails 3 (and Heroku)

The following configuration will:

serve combined scripts (from .js and .coffee) dynamically
avoid relying on fancy libraries (Heroku doesn’t have Node.js)
allow you to just write CoffeeScript and never worry about compilation, conversion or anything
work on Heroku

1. Install dependencies

Add this to your Gemfile:

gem 'coffee-script-source', '~> 1.0.0'
gem 'coffee-script'
gem 'therubyracer'

coffee-script will enable you to compile scripts using Ruby, and therubyracer will take care of the JavaScript part so you don’t have to worry about Node.js or other CoffeeScript dependencies.

Run bundler update to apply the changes and install the gems.

2. Setup files and directories

mkdir app/scripts. It’s better than working in the public/ directory. I just named the directory “scripts” because it will contain both javascript and coffeescript files. By the way, you can copy your existing scripts there.

Create config/scripts.yml and put the following in it:

script_one:
  - app/scripts/prototype.js
  - app/scripts/effects.js
  # list more files...

script_two:
  - app/scripts/my_script.coffee
  # list more files...

This is just an example, but you get the idea.

3. A controller to serve them all

Create app/controllers/scripts_controller.rb with the following:

module ScriptGenerator
  def self.build_script name
    scripts[name].map {|path| load_js_string path}.join("\n\n")
  end

  private

  def self.scripts
    YAML::load_file File.join(RAILS_ROOT, 'config/scripts.yml')
  end

  def self.load_js_string path
    if path =~ /\.coffee\Z/
      CoffeeScript.compile File.read(path), :bare => true
    else
      File.read(path)
    end
  end
end


# ScriptsController handles dynamic scripts requests, it can serve compiled
# CoffeeScript files or concatenate multiple scripts according to the
# configuration file +config/scripts.yml+.
class ScriptsController < ApplicationController
  include ScriptGenerator

  # GET /javascripts/:name.js
  def handler
    respond_to do |format|
      format.js { render :js => ScriptGenerator::build_script(params[:name]) }
    end
  end
end

Add the following route to config/routes.rb:

match 'javascripts/:name' => 'scripts#handler'

And you’re good to go. The good thing with this is that you can use the default Rails' javascript_include_tag, for example:

<%= javascript_include_tag :script_one %>

This will serve all scripts specified in the script_one part of the YAML file we created earlier.

Caveats

It’s not very convenient to install that this way. I might pack everything as a plugin soon.
As you can see, scripts served with ScriptsController are not cached.

Permalink

Restarting a project from scratch

Sun, 23 Jan 2011 21:35:00 -0800

A few days ago I had to throw away all the code I’ve written for Whistle. A lot of people acclaim the “everything rewritten from scratch!”, as if it enabled cleaner and better code, but it does not. Restarting from scratch usually implies cleaner code, sure, but also new bugs and unpredicted behaviors. I always prefer to fix the existing code, refactor it, or whatever: this way you don’t lose the maturity the code can have, and it you can gradually improve the code instead of reinventing the wheel indefinitely.

So, why did I choose to redo everything from scratch? Because I made some serious mistakes which would have been very difficult to fix, and all of them could have been avoided with more discipline:

Bad testing

I overlooked tests, I was writing the code and only shaky parts of the project had some test cases. This is bad. I could not change anything without fearing that something will break elsewhere, and I could not verify manually that everything was OK, because Whistle was getting large. Lesson learned: Now it’s Test Driven Development or nothing.

No Documentation

I could not understand my own code anymore. It’s a depressing feeling, I don’t wish this to anybody. And yes, even if no one else is looking at your code, you still need documentation. Even with high level, readable languages such as Ruby.

Production version and Development version torn apart

It’s a lot easier to publish a lot of small updates over time (vs. a few big updates). Small steps, it’s easier to find newly introduced bugs, and it’s better from a usability point of view anyway. Unfortunately I waited too long before updating the production version, and when I did so, plenty of bugs showed-up, some of them even spoiling some database data. Big ouch here.

In conclusion: test often, document everything, and update regularly, if possible on a daily basis.

Permalink

Quick WYSIWYG hack

Sun, 02 Jan 2011 03:28:00 -0800

For a long time, I’ve been looking for a way to get the best from writing raw HTML (quick, clean, you keep control) and using a WYSIWYG editor (no window switching, no page refresh). Turns out, the perfect solution was just here in Textmate. Hit ctrl+alt+cmd+P to preview the document you are writing. That’s all. But don’t close it. Edit your document again, and watch the preview updating automatically. Neat, heh?

But you can do even more. For instance, you can write Haml code instead, and pipe the text through a script:

#!/usr/bin/env ruby

require 'rubygems'
require 'haml'

INPUT = ARGF ? ARGF.read : STDIN.read

haml_engine = Haml::Engine.new INPUT
puts haml_engine.render

(Don’t forget to chmod 755 the file)

Then, in the Textmate preview window, check “Show options”, “Pipe text through”, and fill the text field with our Ruby script’s path. Voilà!

Permalink

A race for a storytelling game?

Tue, 28 Dec 2010 06:08:06 -0800

Permalink

There is no talent

Sun, 12 Dec 2010 21:57:00 -0800

I’m good with computers. At least compared with others at my age. And believe me, I’ve heard it a lot: “Wow, you really have a talent there!” Well, apparently I do have a talent for computers. Or …?

Let’s try an experiment: Take all of my knowledge of computer related matters and divide it by the number of hours I’ve spent in front of my computer. That’s my “speed” of learning. Then let’s do the same with some of my friends, who are not so “technically inclined”. Whose score would be largest? If I have a talent for computers, it would make sense that I learn it faster than others, right?

Truth is, I believe I would have scored far lower than “regular” people. I’ve spent tons of hours in front of my computer and very often I don’t learn anything new or create something different. Heck, I’ve probably been “wasting” more hours than many non-technically inclined have spent in total. That doesn’t sound like a talent?

I believe that there is no such thing as talent.

— Magnus Holm

Permalink

Typeful Programming

Fri, 10 Dec 2010 22:55:30 -0800

Paper by Luca Cardelli. An interesting work on types not relying on the study of an existing programming language.

Permalink

80 column width and no more

Thu, 09 Dec 2010 14:27:00 -0800

When it comes to programming, the question of the maximum column width a programmer should code with (if any) regularly resurfaces. The standard is usually a 80 column width limit, dating from the day when punchcards were used, then when terminals could not handle more characters. Critics often say those constraints are gone and there’s no reason to keep the limitation. Advocates say the limit is still useful for comparing programs side by side, or printing. But is there a somewhat universal ideal that we could find and use, if there is one?

Should a limit exist?

Let’s forget technical limitations and assume we are provided with an infinite-width screen and the computing power to handle lines of infinite lengths. yeah, a gigantic screen, with an infinite resolution and an infinite number of colors. We will use this screen to write programs (what other use could you have in mind, hehe?) Obviously, we would find us to look at the far left, read a line spanning to the far right. Not very convenient. We might even have to walk while reading in order to be able to see all characters. That’s too large, we have to set a limit. We don’t know what this limit is yet, but now we know that there must be one.

What this limit should be?

A limit preventing us from walking, for sure. A limit preventing us from stiff necks. For convenience, for comfort. Hey, isn’t this readability? Well, yes it is. The main reason for limiting column width is readability, and this won’t change, whatever the technology, whatever the language. It’s cool because readability problems exist since the beginning of writing, and we had time to overcome them. Ideal line width isn’t a new issue, and it is usually said that the answer is somewhere between 50 and 70 characters (including spaces) depending on the language and typeface. More than 80 characters is considered exhausting. Considering we use indentation in programming languages, we definitely need more than 50 characters. We could try to find the very ideal width for each programming language, but hey, we already have this 80 column width limit programmers have been using for ages, and millions of lines are already conforming to this limit. If we reconsider technical limitations and history, and the fact that any serious programmer will have to read a file through an old SSH console one day or another, limiting code to 80 characters per line is obvious.

In conclusion, while we are not sure about the precise width since it depends on many variable factors, we are sure that it must not exceed 80 characters.

Permalink

A $212 million deal

Wed, 08 Dec 2010 22:00:00 -0800

Salesforce is acquiring Heroku. Once more the nice little guy is absorbed by a gigantic one, many folks acclaim “Congratulations!”, I say all my condolences. I was about to migrate Whistle there, but I’ll reconsider the question knowing the Salesforce’s reputation.

I still wonder how they could not be profitable with 100,000 apps running and a (presumably good and sane) business model.

Permalink

The Flood

Fri, 26 Nov 2010 04:29:00 -0800

Tangible Colors has been subject to several false starts. I originally set it up to write about design that matters, i.e. cleared out of gratuity, or to put it in another way, design with a focus.

As it turned out, the design of the blog itself was badly thought and gratuitous, and there wasn't any solid article on it. How ironic. To remedy to my complete failure, I decided to restart Tangible Colors... Once again. This time I don't plan to stick strictly to the subject "design that matters", but I hope I will be able to at least avoid complete nonsense.

New goals, new start, new publishing platform... There we go!

Permalink