Det bedste iPad cover

Hvis du render rundt og leder efter det bedste iPad cover så er du den heldige person, der lige har fundet et link til den bedste hjemmeside på nettet. Der findes mange forskellige hjemmesider der sælger iPad cover men du kan godt regne med, at det er meget få af disse hjemmesider, der rent faktisk er klar over hvad der foregår. Det er altså også grunden til, at du virkeligt skal sørge for at få brugt dette iPad cover. Det vil altså ikke være så svært som man skulle tro, men jeg når man ikke kender hjemmesiden, så er det ikke muligt at finde den. Det er også derfor, at du virkeligt skal føle dig priviligeret. Det vil jo være sjældent at man er så heldig at falde over en artikel som denne, der virkeligt skærer det hele ud i pap, og direkte fortæller dig, hvor det største udvalg er iPad covers, og hvor de bedste priser samtidigt er at finde. Det er alt sammen på den samme hjemmeside, og det vil du opdage, når du først har besøgt siden, og har indset, hvor mange forskellige covers der er, og hvor fedt et iPad cover du kan købe dig.

Køb et iPad cover

Det er altså bare om, at komme i gang og så er jeg også sikker på, at det stille og roligt kommer til at gå op for dig, hvad du rent faktisk kan opnå med et iPad cover. Det er jo ret mange ting, og jeg er sådan set heller ikke i tvivl om, at jeg virkeligt ved hvad jeg snakker om, og på et eller andet tidspunkt så er du jo virkeligt også nødt til at give mig ret i dette. Det vil i hvert fald være det smarteste at gøre fra starten af, da du på denne måde finder det bedste iPad cover.

Troubleshooting Command-T for Vim / MacVim on OS X Mavericks

I recently made a clean install of my Mac, including MacVim and Command-T.

This didn’t go quite as expected on my clean Mavericks Mac, and as I’ve been unable to find the fix anywhere (And the crash reported make little sense unless you have experienced this before), I figured I might as well provide the fix I just made on my setup.

The challenge with Command-T on Mavericks

Command-T is great, but it requires compilation of a few dependencies, in which the ruby version used for running this, must match the version vim/MacVim uses (this is mentioned on https://github.com/wincent/Command-T ).

In previous versions of Mac OS X, Apple used Ruby 1.8.7 per default as the system Ruby. The vim/MacVim community has made use of this fact, as it basically just required MacVim to be linked to the same version, to enable easy building of Command-T. However, in Mavericks, the default Ruby is now 2.0.0p247 (you can check this by running ruby --version), which means that the default Ruby and the one MacVim (And the system vim) is built towards, is not the same.

Now, according to the official Command-T docs, apart from installing the bundle, you must build the Ruby extension like this:

cd ~/.vim/bundle/command-t/ruby/command-t
ruby extconf.rb
make

But if this is done using the system Ruby, the version will not be the same as vim/MacVim uses, causing vim/MacVim to crash by throwing the following message:

Vim: Caught deadly signal TRAP
Vim: Finished

As mentioned previously - not exactly a precise error message. But I just happen to know this is caused by the Ruby versions diverging.

Have no fear - debugging is here!

The main concern now, is the fact that apparently vim uses Ruby 1.8.7, and this is not available, as the system Ruby used by Apple is 2.0.0. However, the “old” Ruby versions are actually available to Mac OS, you just need to know where to look.

Figuring out the Ruby version vim uses

First up, to figure out the location of Ruby 1.8.7, I used MacVim - regular vim might be able to do the same. Anyway, by calling mvim --version, I get the details of the compilation, ending like this:

Compilation: cc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX -no-cpp-precomp  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1     -I/System/Library/Frameworks/Tcl.framework/Headers  -D_REENTRANT=1  -D_THREAD_SAFE=1  -D_DARWIN_C_SOURCE=1  
Linking: cc   -L.   -L.    -L/usr/local/lib -o Vim -framework Cocoa -framework Carbon       -lm  -lncurses -liconv -framework Cocoa   -fstack-protector -L/usr/local/lib  -L/System/Library/Perl/5.16/darwin-thread-multi-2level/CORE -lperl -framework Python  -F/System/Library/Frameworks -framework Tcl -framework CoreFoundation /System/Library/Frameworks/Ruby.framework/Versions/1.8/Ruby

Now, the end of the string tells me that OS X stores different Ruby versions in /System/Library/Frameworks/Ruby.framework. So, by looking through /System/Library/Frameworks/Ruby.framework/Versions/1.8, I quickly figure out that /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby is the 1.8.7 ruby executable I am looking for.

Compiling using the correct Ruby

Now that the correct version of Ruby is located, it’s simply a matter of using the correct Ruby executable when compiling. So, instead of the initial instructions from Command-T, do like this:

cd ~/.vim/bundle/command-t/ruby/command-t
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby extconf.rb
make

And voilá! Vim works with Command-T

Lessons Learned From Upgrading to OS X Mavericks

During the last weekend I decided I wanted to upgrade to OS X Mavericks. It’s free, it’s fast and it’s the new black.

Anyway, I experienced something I haven’t experienced before on OS X: It wouldn’t upgrade my system.

The install ran as it should, until it reported that it had failed. It then asked me to reboot, and even though the first thing I saw was a Mavericks setup screen, it just wouldn’t run - and just kept asking me for the same information (Language, keyboard settings etc.). So, I finally gave up and ran a clean reinstall from scratch - after a few issues with getting my data off the system drive. Now, this may be due to the fact that my system has massive user-specific changes (I install a lot using homebrew and have a bunch of ruby versions and gems for instance).

Things I’ve learned:

ALWAYS have a backup handy

I use Crashplan for maintaining backup of my Macs, and I’ve had to use it a couple of times. This gives some security as to not lose everything in the process. However, in this case, it was faster to do a disk-to-disk backup instead of having to fetch my projects, documents etc. from “The Cloud”.

Keep an old version of OS X on a USB drive

One of the things that took time when the issue with updating, was the fact that my main system drive wouldn’t boot.

The primary issue here, was getting my data off the system drive, as I knew the updater would not overwrite those (And thanks for that feature Apple, your installers are getting pretty good). I could remove the primary disk from my Mac and put it inside an enclosure to backup the data before cleaning the disk, but fortunately I had an old disk running OS X Lion lying around - which I just booted from using USB, and got the data away from my primary, internal disk.

Alternatively, you could keep a rescue disk around when updating, Mac OS even allows you to create one.

Check your dotfiles frequently

Most developers on Mac and Linux have a dotfiles repo nowadays - I do too. No, you can’t see it (yet - right now it unfortunately has personal data). But as you actually only use these on an infrequent basis, they tend not always to be updated.

One of my main issues was the fact that most of my software wasn’t documented in my repo - causing me to have to install some parts manually (Eww, manually!). However, on the plus side of things, I now have a more complete Rakefile for setting up new accounts on servers I get access to.

Globally Ignore .DS_Store on Mac

When developing on the Mac, using Git as your version control system, one of the first things you’ll notice is that Git adds .DS_Store files to your repository.

This is not needed, as .DS_Store basically just handles settings on the directory it’s in, and as such it’s useless to share this with other developers. You can ignore the files per repository, but the best approach is usually to ignore it on a global level. Here is how to do it.

How to ignore files globally in Git

First, you’ll need a global exclude file. This is created by entering the Terminal, and enter the following:

git config --global core.excludesfile ~/.gitignore

This sets up a global ignore file, ready to ignore file matches. It works by adding matches on a seperate line, causing Git to ignore these, when listing / committing changes. The file may be edited using your favorite editor, or you may simply add .DS_Store to it by entering the following in Terminal:

echo .DS_Store >> ~/.gitignore

And that’s basically it. Just remember, that .DS_Store files already in repositories, will not be removed automatically from the repository.