I recently changed jobs, and I thought it would be a time-saver in the future if i’d write down some quick instructions to setup my mac.

first step: install a decent browser

I use firefox. At the same time i installed some of my favorite plugins: Vimperator, JSONView, HTTPS Everywhere, Privacy Badger, Ghostery, Disconnect, Adblock Plus

install a decent terminal

I use iTerm2 all the time, it’s epic. Don’t forget to set the fullscreen mode to classic.

With a decent terminal in place, let’s get some of the things we need:

Install Homebrew
Run these commands to install some basic tools:
brew update
brew install ack chicken cowsay ctags ffmpeg git gpg guile newsbeuter node pandoc pass screen sl stow the_silver_searcher tig trash tree vim wget z

install dot files

Clone dot files from dotfiles repo on bitbucket and install them using stow.

install virtualbox & vagrant

Install virtualbox & vagrant

configure some stuff

  • mails
  • git
  • dropbox?

That’s about it, set up in 1 hour!

As you all know, Scheme is epic, and guile is a really nice environment for scheme programming. What bothered me for some time was that the REPL (read-eval-print-loop) lacked readline support. After some digging around in the official guile documentation I found a really simpel way to activate it. Guile is actually compiled with readline support, you just have to enable it manually due to licencing problems.

just issue these commands at the REPL:
(use-modules (ice-9 readline))
(activate-readline)

I’ve gone one step further, and created a .guile config file in my home directory, containing those two lines. That enables readline automatically, every time i start the REPL. Nice!

Toon

If you’re on Mac OSX, you have a really nifty cli tool at your disposal: sips. It uses OSX core image processing capabilities, and makes them available for shell scripting or batch image manipulation. Rejoice!

This would be a basic example:
sips -Z 200x200 image.jpg
To resize image.jpg to be 200×200 pixels.

For more info, check
man sips

Have fun!

This is a problem that i encounter sometimes: I’ve committed on the master or dev branch when in fact i wanted to do those commits on a feature branch like feature-foobar. Let’s fix that.

Important: don’t do this when you’ve already pushed your commits to a remote.

  1. Checkout the branch in which you made the commits to be moved. e.g.: git checkout master
  2. Create and checkout the feature branch where you wanted the commits to be in te first place. e.g.: git checkout -b feature-foobar
  3. Checkout the main branch again. (See 1).
  4. Reset this branch a number of commits (use git log --decorate) to see how many commits you want gone from the main branch and moved to the new one. Use this number in the reset command. In my case, i want 5 commits moved: git reset HEAD~5

And that’s it really. Simple as that!

IMAP email debugging

November 21, 2013

Isn’t it a problem when you have to debug a problem with emails in an existing project? You never know if they are sent and to whom? I just found out that python has an awesome IMAP debugger built in! Just set your project to use these email settings:

IMAP host: localhost
IMAP port: 1025
IMAP user: {leave empty}
IMAP password: {leave empty}

Then you run this in your terminal:

python -m smtpd -n -c DebuggingServer localhost:1025

You’ll now see every mail that’s sent from your application displayed in your terminal!

That’s it… Have fun debugging

PSR coding standards

October 26, 2013

I think cross-project, language wide coding standards like PSR are great. It makes reading or writing code from other projects easy. And since PSR is so widely adopted in the PHP programming scene, it’s a really good coding standard to adopt. When studying it, though, I came across two things that I really dislike in their standard. They both apply to PSR-2.

The eternal Spaces vs. Tabs debate

Indents are a really personal thing. Some people find 4 spaces a good indentation width, others prefer 2 spaces, even others prefer 8. That’s why tabs are so awesome, every good editor allows you to set your own tab width, so that your indentation is perfect for you in your editor, and perfect for somebody else in his or her editor of choice. Now, i’m really talking about indentation, not alignment. Allignment SHOULD be done using spaces. Things will still align, even if the tab with is changed. This is perfect in every case.

An example. . are spaces, and thus fixed width spacing. - stands for one space width inside a tab in a certain editor.

One tab is 2 spaces wide

/**
.*.This.is.an.example.class
.*/
class.ClassName {
--/**
--.*.The.fooBar.method,.takes.two.arguments
--.*
--.*.@param.string..............$argument1.......The.first.argument
--.*.@param.string[optional]....$argument2.......The.second.argument
--.*/
--public.function.fooBar($argument1,.$argument2.=.null).{
----if.($argument1.===.$argument2).{
------//.Return.Foo
----}
----else.{
------//.Return.Bar
----}
--}
}

One tab is 4 spaces wide

/**
.*.This.is.an.example.class
.*/
class.ClassName.{
----/**
----.*.The.fooBar.method,.takes.two.arguments
----.*
----.*.@param.string..............$argument1.......The.first.argument
----.*.@param.string[optional]....$argument2.......The.second.argument
----.*/
----public.function.fooBar($argument1,.$argument2.=.null).{
--------if.($argument1.===.$argument2).{
------------//.Return.Foo
--------}
--------else.{
------------//.Return.Bar
--------}
----}
}

As you can see in these two examples, things keep aligning perfectly, everyone gets to use their own prefered indentation width, *and* your git history is as clean as using only spaces. When used consistently this method has all the upsides of the PSR-2 “only spaces” rule, and none of the downsides.

Curly brackets

PSR is not really consistent in this case. Control structures like if, elseif, switch, for and while must have their opening brackets on the same line, while functions, methods and classes must have their opening brackets on the next line.
I think it would be more consistent if control structures, functions, methods and classes would all have the same notation with brackets on the same line, like in this example:

<?php
namespace Vendor\Package;

class ClassName {
    public function fooBar($argument1, $argument2 = null) {
        if ($argument1 === $argument2) {
            // Return Foo
        }
        else {
            // Return Bar
        }
    }
}

Also notice in the above example that every closing bracket is on its own line, unlike the PSR-2 standard way of putting the if closing bracket on the same line as the else statement, like this:

if ($argument1 === $argument2) {
    // Return Foo
} else {
    // Return Bar
}

I think this is inconsistent, and doesn’t help for readability.

That’s all…

1. Check your screen name

Open a terminal and type this command:
xrandr

You’ll get a list of available screen sizes, along with the name of your screen. In my case, that’s default.

2. Run xrandr as an OpenBox startup command

Open the ~/.config/openbox/autostart file, and add this line:
xrandr --output {screen name} --mode {window size} &

e.g.:
xrandr --output default --mode 1280x800 &

That’s it! OpenBox will now use your desired screen resolution at startup.