MacKuba

The beginning of 2013 was a really bad time for the Ruby community. In the first few weeks of the year a few separate security issues were found that made everyone run to their SSH consoles to update their Rails apps. Rails itself had to be updated 4 times so far because of this, and even the rubygems.org gem repository has been hacked.

And we aren’t talking about a minor “someone with enough luck and determination can use this for some malicious purpose one day” kind of issue; some of these were the nastiest security holes we’ve seen in years. Check out this article by Patrick McKenzie about what can happen (or rather: will happen) because of these vulnerabilities.

The worst part: it’s probably not the end. The general nature of these bugs – see another article by Aaron Paterson analyzing all the ways in which you can do harm to a Ruby app – means that it’s quite likely that there’s more where that came from.

Now, I don’t know about you, but for me it’s starting to get hard to keep track of all these issues. I know Rails should be updated, but which version was that, 3.2.10 or 3.2.11? Is 2.3.17 OK or was there something newer? And what else was there, json, rack, or was it rake?

If you’ve read the Rails 3.1 asset pipeline docs, you’re probably aware that you can add preprocessors to your asset files by appending extra file extensions. For example, to write your JS files in CoffeeScript you need to add the suffix .coffee, and if you also want to pass something from Rails to those files, like paths to image files, you also need to add the .erb suffix. All the extensions are added together, so you end up with e.g. profile.js.coffee.erb (it’s simpler with stylesheets, because by adding a Sass preprocessor you get a bunch of asset path helpers for free).

What the docs don’t tell you is that Sprockets can also be configured to include preprocessors implicitly based on a content type.

Last month I read a great book from the Pragmatic Bookshelf – “The Passionate Programmer”, another book in the not-directly-technical series of their books started with the original “Pragmatic Programmer”, which deal not as much with specific technologies and languages, but rather with programming and programmer’s life in general.

The book, written by Chad Fowler, a well-known Ruby expert, is a second edition of a book that was previously titled “My Job Went to India: 52 Ways To Save Your Job”. The first edition’s main idea was helping US developers find a new place for themselves in the globalized world where more and more projects are outsourced to some remote countries. The second edition is more of a redesign than an update, and instead of showing you how to be good enough not to be fired, its aim is to show you how to be awesome: how to become an expert in your field, a well-known, respected developer, and how to have fun on the way.

I’ve found a lot of great ideas and made tons of notes, but if I shared everything that would be definitely TLDR, so instead I’ll try to sum it up in a few points which were repeated in various forms throughout the book. (If some of these seem too obvious to you, I’m pretty sure you’ll find some other tips that will make more sense for you in the book.)

After I upgraded my Mac to Lion this month, I’ve noticed that my NTFS drives stopped working. I’m using NTFS on my Windows XP partition and on a WD external drive. I’ve previously used MacFUSE and NTFS-3G, which is probably the most commonly used solution for people who want full NTFS access on OSX (as you probably know, by default OSX only provides read only support). However, that doesn’t work anymore on Lion. The problem is that MacFUSE is not maintained anymore and doesn’t work with a 64-bit kernel which is used by default in Lion.

First Google results usually point you to commercial solutions, but I’m not willing to pay for something as basic as filesystem support, which, frankly, Apple should have provided themselves long time ago. If you want to avoid paying, the right way is to replace latest stable MacFUSE with something that works on Lion.

Based on a few blog posts and comments I managed to find a way that worked for me, so I thought I’d put it all here in one place for others. The fastest way IMHO is to install packages from the command line, because – at least in case of NTFS-3G – it’s hard to tell from the website which version is the right one. I’m going to assume you haven’t lived under a rock for the last couple of years and you’re using Homebrew, not MacPorts. It’s not completely automatic – you’ll need to do a few things in the terminal, but it shouldn’t take more than a few minutes in total.

I’ve recently updated my new blog’s layout to support mobile phones, iPhone in particular (since that’s what I’m using ;). Here’s how it looks now:

I decided to use the same HTML for both versions, and use CSS media queries to define how the mobile version differs from the main one – I thought this was the cleanest and simplest solution in this case. For more complex sites, it probably makes more sense to have the two versions completely separated.

Surprisingly, it was quite easy to do once I figured out what exactly I needed to do. Turns out, the hardest part is apparently knowing what to put in your header and what media queries to use. Here are some tips and suggestions if you want to make a mobile version of your site too:

I started this blog almost 3 years ago. It was a bit of an experiment, as I wasn’t sure if that actually made sense, if I would want to keep writing it a few months later – so I put it on Jogger (Polish Jabber-based blog service) and I used the classic Kubrick design.

Since I’m rather happy with how this experiment ended up, it was time for a change. The new version is hosted on Linode (definitely the best hosting I have used), and uses a custom-made engine based on Sinatra. Hopefully with this new design I’ll have a bit more motivation to write, because I just couldn’t look at the old one anymore…

If I find some more time, later this year I’m planning to learn some NodeJS and rewrite the engine using it (e.g. with Express).

There’s a few things that I’ve learned while working on the redesign:

There are many posts and articles that compare available open source licenses. A lot of them aren’t objective and are biased towards some kinds of licenses based on author’s own preferences.

Well, I have to disappoint you, this one isn’t going to be any different :)

After the VLC incident last week I got kind of fed up with GPL. I had licensed a few of my projects under GPL before, but I decided I don’t want to use a license that’s so restrictive that it makes it impossible to put an app on AppStore, even if it’s shared for free and the source code is available. So I did some research to find what other licenses made sense for me. As usual, I spent way more time on this that I should have, and the notes below are the result. (Note that I haven’t actually read the whole text of most of these – I’m not that crazy.)

Update (6.07.2017): I’ve added a section below about the “Very Simple Public License” (VSPL) that I started using in my projects as a simpler replacement for MIT.

A few months ago I wrote a post about JSON parsing libraries for Cocoa. I compared 4 libraries – BSJSONAdditions, JSON Framework, TouchJSON, and YAJL, I ran a benchmark on all of them, and the conclusion was that YAJL was the fastest and BSJSONAdditions was way slower than the rest.

Last week John Engelhart commented on that post, mentioning his own JSON library JSONKit, claiming that it’s really fast. Of course I had to check if that was true :)