Improving my keyboard

Because I'm living in France, all my computers have a standard French keyboard layout. It is based on the azerty layout, with all the frequent French characters in easy access (eg: é, è, à, etc).

It is different from a classical qwerty layout in various ways, the most notable being that the numbers on the number rows are activated by pressing Shift. On a classical qwerty keyboard, pressing the 2 key will issue a 2. In my case it will issue a é. I need to press Shift+2 to get a 2. And AltGr+2 gets me a ~.

Why am I talking about that ? Because I'm also a developer, and I write code everyday. And code is not like prose, the characters with special meanings are not the same. We use and abuse (, {, ;, -, _ or [. Some of these characters I use very often, and due to my keyboard layout, I often need to press Shift or AltGr to get the needed char.

This, of course, struck me as not very productive. There has to be a better way. So I dig up a bit and found xmodmap that is used by linux to bind a keycode to a keysym. A keycode is what is send to your OS when you press one of your plastic keys on your keyboard. One physical key on the keyboard equals to a keycode. Each keycode can have one or several modifiers (like Shift, Control or AltGr). And each of combination of keycode + modifier(s) equals one keysym, which usually translate to a character, but can sometime have special meaning (like Return, Backspace or the F keys).

With xmodmap, you can manually configure which keycode sends which keysym. So I've updated my own xmodmap to move some of the special chars I use often to place I can access easily without having to move my hands too much.

To do that, I mostly took advantage of the AltGr modifier that is currently underused. This modifier is mostly applied to the number row (and pressing AltGr and anything on the number row is not the easiest thing to do).

The most important change I made is to add AltGr+i to create a - (dash) and AltGr+o to create a _ (underscore). Those two chars are overused when coding, and having them on those keys allowed me to type them much much faster without having to move my hand on the keyboard.

The others little changes I made were to add AltGr+h as # (hash, the mnemonic is that a capital H looks a bit like a #). Following the same idea I put the pipe | on AltGr+j. I also put \ on AltGr+u. These are keys easily accessible and I use them often.

Finally, the last two important bindings are AltGr+r to produce a `. The default French keyboard layout does not have a key for the backtick, so creating mine was a huge timesaver. The last one is AltGr+q to get a ~ (tilde).

I also tried to put [ and ] respectively on AltGr+k and AltGr+l but I never use them.

You find below the xmodmap I use. Put it in a ~/.xmodmaprc file and run setxkbmap fr && xmodmap ~/.xmodmaprc to apply them.

keycode 27 = r R r R grave
keycode 30 = u U u U backslash
keycode 31 = i I i I minus
keycode 32 = o O o O underscore
keycode 38 = q Q q Q asciitilde
keycode 43 = h H h H numbersign
keycode 44 = j J j J bar
keycode 45 = k K k K bracketleft parenleft
keycode 46 = l L l L bracketright parenright

As I recently had to work on a Windows machine, I installed AutoHotKey and created this little script to emulate the same shortcuts :

<^>!r::Send ``{Space}
<^>!u::Send \
<^>!i::Send -
<^>!o::Send _
<^>!q::Send `~{Space}
<^>!h::Send {#}
<^>!j::Send |

This little changes were a huge timesave for me, hope they gave you some ideas too.

Windows filepath too long when deleting node_modules

I'm currently forced to develop on Windows. And it hurts. I feel like a clockmaker forced to work with gloves and blindfolded. I keep hitting strange and weird Windows limitations that are real productivity killers.

The most recent was not being able to delete a folder because its filename was too long. Wait, what ? As soon as you start using npm and download a bit of modules, you'll most certainly end up with a node_modules folder that's too long for Windows to handle.

But npm is clever, and it can circumvent this limitation. So, whenever you want to delete a node_modules folder and Windows won't let you do it, use npm. Update your package.json to remove every element in dependencies and devDependencies and run npm prune. This will empty your node_modules folder.

You're welcome.

Setting all inputs as $dirty in AngularJS 1.2

By design, in Angular, all forms and inputs are $invalid by default. They are also $pristine, meaning they haven't been touched. So if you need to display an error message next to a field, you not only have to check if the field is $invalid, but also if it's $dirty.

Now imagine you load your page, containing a form. You have several fields, and none have any validation rules applied (no ng-required, nor ng-pattern). At this stage, you form is $invalid, because at least on of its fields is $invalid.

Each field will switch to $dirty when a value is typed in it. Switching to $dirty will also trigger validation rules (if any), and updating its $valid/$invalid property accordingly. When all fields will become $valid, the parent form will also automatically become $valid.

The problem with that is when you want to submit your form without entering anything in any of the fields. Your form is considered $invalid. You have to manually focus each field and enter a value to make it become $valid.

I haven't found a nice way in Angular to trigger validation rules on all fields of a form at once, to recalculate its validity. What I've found is that if I update the viewValue, then the field becomes $dirty and validation rules kicks in and can pass my field to $valid. So updating the viewValue with itself (thus, not changing anything) becomes a hackish way to trigger validation.

So I coded the following method. It takes a $scope as argument and will loop through each form in the scope, and trigger each field validation in this form through the setViewValue hack explained above. It will also handle nested forms.

function setAllInputsDirty(scope) {
  _.each(scope, function(value, key) {
    // We skip non-form and non-inputs
    if (!value || value.$dirty === undefined) {
      return;
    }
    // Recursively applying same method on all forms included in the form
    if (value.$addControl) {
      return setAllInputsDirty(value);
    }
    // Setting inputs to $dirty, but re-applying its content in itself
    if (value.$setViewValue) {
      return value.$setViewValue(value.$viewValue);
    }
  });
}

Note that it does some weak duck typing to check if an element is a form or an input by checking for some methods. This will easily break, so be careful.

Sass UTF-8 encoding on Windows

Ever had your UTF-8 string wrongly encoded in your output .css files when using Sass ? Well, it might be an issue with the way Sass determines the encoding of your files.

Starting from Ruby 1.9, Sass will now try to guess the encoding of your sources files before processing them. The algorithm used is defined in the documentation but comes with a few caveats.

It will first check for the BOM in your file, and if found will consider the file as being UTF-8. Using BOM is a very bad practice when dealing with UTF-8 and you should absolutely not include it.

So, if no BOM is found, Sass will then look for a @charset definition. It looks for it exactly as the very first character on the very first line of the document. If not found, it will then use the Ruby default encoding.

And when you're on windows, the default encoding is usually CP1252. And in the end, you end up with every UTF-8 char encoded as three separate CP1252 chars.

Solution ?

Well, as adding a BOM is definitely not possible, you could add a @charset rule on top of EVERY SINGLE SASS FILE. Which is not a good solution either. Changing the encoding OS-wide is not better.

What you can do is force the output encoding with the -E switch when using sass on the commandline : sass -E utf-8 main.css. And this will correctly convert everything.

Unfortunatly, if you're using Compass in addition to Sass, there is no easy way to pass this switch to the underlying sass. What you can do instead is editing the config.rb file that comes with your Compass project and add the Encoding.default_external = 'utf-8' line. This will change the Ruby default encoding and output utf8 correctly.

But hey, what if you're using compass through the grunt-contrib-compass task ? There is no config.rb file that you can edit, and the task does not expose the needed configuration switch. Your only solution is to use the raw option to pass the Encoding.default_external config.

{
  options: {
    raw: 'Encoding.default_external = \'utf-8\'\n'
  }
}

Mind the \n at the end and the quote escaping. This is needed for the task to correctly parse.

Hope this helped. Note that all this tweaking is not necessary if you're using Ruby 1.8.

Getting up to date on CSS

I have been coding in CSS for a few years. I started when IE6 was the major browser but had to stop when HTML5 started to became a buzzword. Too bad. At that time, I had a job where I mostly handled server-side stuff and couldn't really keep on the newest CSS topics. Then I took a year off abroad.

Now that I'm back, I decided to get up to speed with all the goodness the CSS world now has to offer. I decided to rewrite the default Hyde theme of this blog with my own to better understand how it's done. Here is what I learned along the way.

SCSS

This is the first time I'm using a preprocessor, and the simple joy of being able to use variables and mixins is great. The nesting is nice but I try not to use it too much. I'd rather have a OOCSS naming convention than too much hierarchy in my selectors.

Autoprefixer

I added autoprefixer instead of SCSS mixins to handle cross-browser compatibility as it seems a more future-proof approach. It leaves the underlying SCSS files simpler to read.

Fonts

I grabbed a font on FontSquirrel to use on the titles. I simply copy-pasted the relevant CSS code, but still do not understand all the details of it. I'll have to read a bit more to really understand the browsers it covers.

rem

I started using rem units as most as I could. This really removes the burden of having to handle the math involved in using em. I still had to use px for media-queries, though.

media-queries

I still struggle in remembering which one of max-width or min-width I need to use in a given context, but otherwise media-queries are great. I coded first for the perfect (or optimal) layout, and then added media-queries to handle bigger and smaller screens.

In my case optimal means enough space to display the sidebar and the text in a way that's easily readable. I then transformed the sidebar into a header for smaller screens, and even added a menu icon to display the menu on really small screens.

It's nice how SCSS lets you define media-queries inside of selectors, and using variables for you breakpoints. This really fluidified the way I write code.

CSS tricks

I had to resort to two small CSS tricks (or mind puzzle) for this new design. I like bending my mind to find creative solutions with a declarative language like CSS. Here I created a menu (hamburger) icon in pure CSS using :before and :after borders. I also displayed a menu when this icon is clicked using a <label> bound to a checkbox and selecting the menu with a clever + selector.

I really like not using images or Javascript for this kind of things. CSS is a powerful language, but a hard one to master.