How To Install Sublime Text 3 on Fedora

Here’s a simple script to install the latest stable build of Sublime Text 3 in Fedora 22 Workstation.
Should work on other Linux distros too. See the full gist on GitHub.

It will install the Package Control as well!

Just run this command:

1
$ curl -L git.io/sublimetext | sh
  • Update (10 March 2014): I made some improvements to the script so I generated a new link.
  • Update (16 March 2014): The script stopped working because GitHub is now doing a redirect to another domain (see their post if you’re interested). Added the -L flag to fix the issue.
  • Update (1 September 2014): I’ve updated the script to install the latest build and made a new blog post, check it out.
  • Update (12 July 2015): Updated the script again to work with the latest version of Fedora.

How to set a default message in your exception

Today I was thinking about a way to define custom exceptions with a predefined error message. For example, instead of doing this:

1
raise MyError, "Something went wrong."

We want to simply do:

1
raise MyError

This could be useful because if we need to raise that same exception again and again, we don’t have to specify the error message every time.

Well, how can we do that?

I spent all day figuring out the best way, actually doing very bad things – I’ve even attempted to monkey-patch the Kernel module!
So – believe me – it’s not as simple as it appears to be. Or, at least, I thought this until I stumbled across this article (dead link).

In short, you just need to override Exception#message.

For example:

1
2
3
4
5
6
7
8
class MyError < Exception
  def message
    "a predefined message"
  end
end

raise MyError
# => MyError: a predefined message

Quick note: I’m inheriting from StandardError, not Exception, because extending the Exception class in Ruby is considered really bad. Please don’t inherit from it: see here and here for the reason (in few words it’s because you may catch errors that are not meant to be catched, such as SyntaxError).

Of course you could also create a module with your own exceptions in it:

1
2
3
4
5
6
7
8
9
10
11
12
13
module CustomError
  class AnError < StandardError
    def message
      "A more specific error"
    end
  end

  class AnotherError < StandardError
    def message
      "just another error"
    end
  end
end

Or even a subclass of your custom error class:

1
2
3
4
5
6
7
8
9
10
11
12
13
module CustomError
  class Error < StandardError
    def message
      "default error"
    end
  end

  class SpecificError < Error
    def message
      "a more specific error"
    end
  end
end

However, this is not very useful. What I find useful, though, is that you can bring shared pieces of information from the base class to the subclasses, which is IMO very desirable in error handling.

Since Exception#message is nothing but an alias of exception.to_s, we can call super to get the superclass' message. For example, this is what I ended up doing:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
module CustomError

  class Error < StandardError
    def initialize(msg=nil)
      @message = msg
    end

    def message
      "Message from main class: #{@message}."
    end
  end

  class SpecificError < Error
    def message
      super + " We also got a specific error."
    end
  end
end

And here's the result:

1
2
raise CustomError::SpecificError, "fubar"
# => CustomError::SpecificError: Message from main class: fubar. We also got a specific error.

This demonstrates that we can potentially carry whatever information (i.e. instances of objects involved in the error) in order to better handle errors in our applications.

That's it.
As always, please feel free to share your thoughts by commenting below.

View latest file changes in command line using Git

Let’s say you did some changes to several files, but you don’t remember which ones. How do you proceed?

A git status will be enough in most cases, but it just shows which files changed – what if you want to see the actual changes you made?

The answer is:

1
$ git diff

It shows every line of code you changed and that you haven’t committed yet. Useful, isn’t it?

If you have already committed some code, but not pushed yet, don’t be afraid: you’re still in time to check if everything is good, and a git log will come handy:

1
$ git log -p

You probably already know the power of git log, but -p makes it even more powerful, because it will also show a patch of what changed in each commit.

Loop through parameters in Bash

Iterating over the arguments in a Bash script is way simpler than you might expect.
See this gist:

In the snippet above, "[email protected]" represents all the parameters. The echo "$i" shall obviously print each argument on a separate line.

It’s always a good idea to wrap parameters within quotes, because you’d never know when a parameter might contain spaces or whatever.

How to load jQuery plugins with RequireJS

RequireJS is a useful script loader library. Even if your site/app isn’t super big, it’s usually a good idea to use RequireJS: it makes your code maintainable.

The problem

Often we need to include external plugins that depend on jQuery. Those plugins usually do expect to find a global jQuery ($) object, and then they just extend it.

Of course not all plugins behave like that, but most of them do, and we must deal with it.

By the way, loading jQuery as a global variable is not really a good idea. Okay, you have namespaces, $.noConflict() and IIFEs and whatever but – hey come on, do you really think you need all this stuff? We can do it better.

The solution

Use RequireJS with jQuery to manage dependencies. More specifically, you can use the shim config to specify dependencies for jQuery plugins that are not AMD modules.

Let’s suppose you need to include 2 jQuery plugins, foo.js and bar.js. Here’s a sample configuration:

1
2
3
4
5
6
7
8
9
10
11
requirejs.config({
  shim: {
      foo: {
          deps: ['jquery'],
          exports: 'Foo'
      },
      bar: {
          deps: ['jquery']
      }
  }
});

Then, later, when you need to use that Foo plugin, you can just define a module by doing:

1
2
3
4
5
6
7
8
9
// foo.js
// This defines a module named 'foo'
define(function() {

  var Foo = function() {
      this.bar = 'baz';
  }
  return Foo;
});

And require it when you actually want to execute it:

1
2
3
4
5
require(['foo'], function(Foo) {
  // this is a callback function, and it's optional.
  // the foo module has already been required and executed.
  // Foo and $ are now loaded.
});

Yeah, it’s that simple.

Want to see a working example? Check out the official one.