Filed under Articles

LocomotiveCMS requires a fair ammount of preparation and this guide will help you install all prerequisites on OSX.

I presume you at least got Ruby, Rails and Rubygems running on your system.

If not, install RVM, Ruby and Rails before you continue.

Install git

Best way to install git on OSX is by downloading and installing Xcode.

• Install Xcode for free from the Mac App Store
• After installing Xcode, the Command Line Tools must be installed. This is done from the Downloads section of Xcode's preferences.

If you don't want to install Xcode, Github has a great guide to install git using the command line. Alternatively you can also download the Github client.

Install Homebrew

Homebrew is a nifty package manager for OSX. If you know Linux, Brew will look familiar.

Installing Brew is pretty easy. Open Terminal and run ruby -e "$(curl -fsSkL raw.github.com/mxcl/homebrew/go)"

Install X11

Get X11 by installing XQuartz. More information at Apple

Install Imagemagick

Open the Terminal app and run brew install imagemagick

If you get any errors you can run brew doctor to locate and fix any problems.

I personally got a lot of errors while installing Imagemagick.

The following error during 2 installations.

However, brew doctor is your friend. Following it's advice I was able to easily fix all problems.

Install mongodb

Open the Terminal and run brew install mongodb

You can test mongo by running it directly from the Terminal: mongod --config /usr/local/etc/mongod.conf

Install LocomotiveCMS

New rails app

rails new myapp --skip-active-record --skip-test-unit --skip-javascript --skip-bundle

Update the Gemfile

gem 'locomotive_cms', '~> 2.0.0.rc12', :require => 'locomotive/engine'
gem 'unicorn', :group => 'development'
gem 'compass-rails',  '~> 1.0.2', :group => 'assets'
gem 'sass-rails',     '~> 3.2.4', :group => 'assets'
gem 'coffee-rails',   '~> 3.2.2', :group => 'assets'
gem 'uglifier',       '~> 1.2.4', :group => 'assets'

And of course you need to run bundle install.

Configurate

Optionally you can tweak configuration settings. Checkout LocomotiveCMS official getting started page.

Run

If all went well you can now execute bundle exec unicorn_rails and open the browser to view a shinny new LocomotiveCMS install.

Ross Miller of The Verge had a hands-on experience with one of the new Samsung slates running the final version of Windows 8 RT.

Obviously you can see that it's not entirely optimized for a touch experience and a lot of what you can see in the desktop mode is better catered, better suited for a mouse and keyboard. But it is there!

Continuing:

The touch menus are.. really not suitable for touch.

But it is there!!

Steve Ballmer said it himself: Microsofts riskiest product bet is the next version of Windows.

I seriously doubt Windows 8 is going to pull it off and here is why.

A better experience

Metro, the UI paradigm from Windows Phone 7, is smart, recognizable and different. It's clearly designed with multitouch in mind, provides a consistent user experience and moves away from Windows classic desktop analogy.

Something we had not seen from Microsoft before.

Metro follows the trend Apple started in simplifying the use of computers by reducing legacy UI concepts like the desktop, file system, software- and window management.

With Windows 8 Microsoft decided to make Metro the default interface while including a classic Windows desktop in order to prevent breaking compatibility with a zillion existing legacy apps. Daring choice.

Microsoft actually calls this classic desktop interface: desktop and it's treated as a Metro app.

Seems like a smart thing to do… right?

Wrong. Very wrong. Failure.

It's not a Metro app

The plan sounds great:

Introduce a completely new OS, place all legacy functionality into a single Metro app. By doing this, current apps can still be used. In time more and more legacy apps will have Metro interfaces so in a couple of years we can toss the desktop app away…

The thing is, as it stands today, the desktop app doesn't behave like a Metro app.

The desktop app actually contains apps on it’s own and is started when a user clicks inside Metro on a tile of a legacy application…

In practice this sends a user from one UI straight into another one. Most likely the UI paradigm the user knows, and recognizes, as (the current) Windows.

Two of the pillars of user interface design are consistency and clear intent. Windows 8 neglects these rules, intentionally, by introducing two completely different UI paradigms that combine into one inconsistent and unclear experience.

Combining two completely different user interfaces introduces a huge amount of complexity and is a bag of hurt for the average user.

Let alone, an advanced Windows user might feel constrained since he's forced into a new, more limited, interface while the old one he knows, and has used for years, is still there.

The following videos 1, 2, 3 demonstrate part of the problem: confusion.

Everything goes fine until a user is send back and forth between two user interface concepts.

The desktop is a Metro app concept fails horribly.

Functionality divided

Beside two User Interfaces paradigms, apps on Windows 8 also add complexity by splitting and duplicating functionality. Some functionality is only provided in Metro, or vice versa in the classic desktop interface.

For example the Metro Mail client doesn't support POP3 or the ability to mark e-mail messages as flagged. The classic desktop Windows Live mail client does support POP3 and stuff like flagging.

Now imagine someone like your mother configuring her POP3 mail account… Or even something 'easy' as browsing the web. Windows 8 has two separate web browsers.

Users need clarity, not division. Stuff like that could be perceived as choice, but usually it only results in doubt.

Even long time Windows users will have a hard time finding out how to get things done and be productive.

On one hand they have a complete new UI with it's own set of mandatory multi-gestures you need to learn, on the other hand there is the old, now limited, interface.

The RT problem

Another factor to add into the complexity mixer: versions.

On the good side Windows 8 breaks away of the complex version strategy introduced with Vista. For consumers Windows 8, more or less, only has 2 versions: Windows 8 and Windows 8 RT.

RT has Metro and a dumbed down version of the Windows Desktop. This all has some technical reason that only allows Windows 8 to run legacy apps.

In general this makes it a lot easier for people to understand what Windows version to buy, but it also has a downside.

Having two, technically, different versions will surely lead to incompatibility issues.

Imagine a situation someone orders a Windows tablet online to find out some apps aren't working since it has a different Windows 8 version. Again: not meeting user expectations is a killer for the overall user experience.

It's all in the name

The above concerns might seem neglectible, but they have a major impact on the overall user experience. Remember Vista? Windows 7 wasn't that much different, but details make users perceive it as a superior functioning OS.

User experience is about expectations. Why call Windows 8, Windows? Metro is completely different from what Windows used to be.

The average Joe buying a laptop will expect Windows 8 to be Windows. But what does he get? A new Metro interface looking gorgeous at first… containing… the old Windows as he knows it!?

• Where is my start button?
• How do I get back?
• How do I turn it off?

Can you imagine Apple putting iOS on a Mac? The same questions would arise.

Confusing

Microsoft has chosen a path of no concessions and choice. In my profession, concessions are the only way forward, that's why I think Microsoft is making a serious step backwards.

Perhaps Daring Fireball's John Gruber describes it best.

With the iPad, Apple has eliminated large amounts of complexity. With Windows 8, it remains to be seen whether Microsoft has eliminated complexity, or merely hidden it behind a Metro veneer.

I think it's even worse then Gruber speculates.

By introducing Metro Microsoft will multiply the complexity of it's OS.

With it's aggressive pricing scheme Microsoft wants the Windows world too move to Windows 8. I’m not certain if the Windows world wants to shift to Windows 8.

Right now I actually see more problems with windows 8 then it's predecessors and I'm not the only one.

Need for a change

Yes, Microsoft needs to look forward and needs to act sooner rather then later.

If I was in charge of Microsoft?

Introduce Metro as a separate OS. Give it separate brand from Windows and only put it on phones and tablets.

Metro could be a great iOS and Android competitor, but it shouldn't be forced upon existing Windows customers. They'll demand a downgrade if you do so.

Next, create Metro versions of Office apps and slowly start putting back Metro functionality into classic Windows. Or even develop a Metro variant specific for netbooks and laptops.

This is more or less what Apple is doing.

Follow Apples example like you've done before, look where it brought you today…

A list of top notch Git client applications for OSX.

I'm a big fan of Github and Git in general. I'm not afraid to use a command prompt for Git, but I'm also a bit lazy and like the convenience a GUI provides.

That's why I used to run Github for Mac to view changes, read commits and sync my local repositories with Github.

Github for Mac looks great, but last night I lost my faith.

Somehow the application decided to create a branch without me explicitly doing so. Furthermore it actually managed to screw up my entire code base by "auto" commiting changes using a message: GitHub for Mac: Throw-away commit.

Next thing I did was revert everything using the command line and dropping the Github app inside my trash bin!

Now I'm on the lookout for a new Git app for the Mac so I decided to create this list.

Tower

I've beta tested Tower almost a year ago and was impressed. The app looks great, it's stable and has pretty much everything you'd expect from a professional Git client including a built in diff tool. I do think the price is a bit steep at $36,75 (and that's with a 25% discount). It's also not available in the Mac AppStore (I do believe this is a downside).

Sprout

Sprout is a Git client available on the AppStore. It's currently priced at $19.99 making it a lot cheaper then Tower. It's also a lot more limited in functionality though. Sprout looks(feature wise) a lot more like the Github for Mac app, except it isn't that tied with Github. A trial is available on the developers website.

SourceTree

SourceTree is a free Mac app available on the Mac AppStore. It's almost as feature rich as Tower and supports both Git and Mercurial. The app isn't by far as slick as it's paid alternatives, and be honest, it feels a bit bloated. Perhaps bloated is a bit overstated, but the UI isn't intuitive or self explanatory.

Gitbox

Gitbix is also priced at $19.99 and available on the Mac AppStore. It's also a great looking app and offers a feature set comparable to Sprout. It probably has the most minimal UI of all apps, and some really well thought-out shortcuts and features. For example, Gitbox keeps track of any submodules you add and makes it a breeze to update them. A trial is also available on the developers website.

Conclusion

Mac OSX has a ton of great Git client apps. There is no easy choice.

All the apps above are build around their own workflow and mindset. I didn't get a chance yet to check out all the Git clients out there. For example: Gitti also looks very promising.

For the mean time I've decided to go with SourceTree and will probably purchase Tower or Gitbox in the long run.

If you are in need of a Git client all I can recommend is to download trials/ demos of all apps and find out what app fits your own workflow best.

Update: I'm running the Gitbox trial as we speak and I must say this app impressed me with it's stability and ease of use. Besides it makes working with submodules a lot easier. Ditching SourceTree...

Yesterday I found out another bug involving my "favorite" browser...

Internet Explorer 8, perhaps also 7, behaves a lot differently when doing a for in loop on a array compared to the modern browsers.

Basically the thing I wanted to do was dynamiclly fill an array with elements using a predefined order.

The resulting array would look a lot like this:

var names = [];
names[0] = "0. John";
names[1] = "1. Mary";
names[3] = "3. Jack";
names[4] = "4. Jane";

The thing is I couldn't control the order in which elements would be added to the array.

So the order in which elements would be added could easily look a lot like this:

var names = [];
names[3] = "3. Jack";
names[1] = "1. Mary";
names[4] = "4. Jack";
names[0] = "0. John";

Now here is the thing. Since you have blank keys in the array you can't use a regular for loop.

In the example above names[2] isn't defined which prevents you from creating a basic:

for(var i=0;i<names.length;i++){}

The easiest way to iterate through such a incomplete array is by using a for in loop like so:

for (var key in names) {

    var name = names[key];

    if (typeof(name) === "function") continue;

    document.write(name + '\r\n');
}

This however produces unexpected resuls in IE8.

In Chrome, Safari, Firefox and IE9 it would output:

0. John
1. Mary
3. Jack
4. Jane

In IE8 this produces:

3. Jack
1. Mary
4. Jane
0. John

As you might notice IE iterates through the elements of the array by the order in which they were added.

How to fix this unexpected behavior?

The simplest solution is to simply copy the array before iterating like so:

// IE fix
names = names.slice();

for (var key in names) {

    var name = names[key];

    if (typeof(name) === "function") continue;

    document.write(name + '\r\n');
}

This will reorder all array elements accordingly.

I've created a small snippet to see the bug and fix in action on jsfiddle.

I think iOS5 is a massive update for iOS App developers, read my reasons why.

Customizing UI components

I've done this a lot myself using hacks, tricks and quirks. With version 5 of the iOS SDK they've added customization to UI controls.

For example, you can assign a custom background image to a UIToolbar or UINavigationBarusing a simple background property. Before you literally had to jump through hoops to make this work.

Automatic reference counting (ARC)

iOS does not have Garbage collection . You know - a background process constantly checking to see if it can reclaim memory occupied by objects that are no longer in use.

Obj-c has a autorelease pool and retain release strategy, but nothing as fancy like the way Java and C# runtimes manage memory. Although the garbage collector makes life much easier for a developer, it also decreases efficiency on mobile devices.

Apple says they found a middle ground. Instead of having a separate proces recollecting memory, they have created a compile time solution. Using the static code analyzer - previously built into LLVM - they dynamically add alloc and release statements during compiling.

This will literally spare you of writing hundreds of lines of dull code. As an extra, Apple says it will also prevent common bugs like memory leaks and make writing code a lot easier.

ARC does require some code concessions, but Xcode 4.2 supports a tool that helps you update your existing code.

Storyboards

A sweet addition to interface builder. Instead of numerous interface files you can start dragging and editing all your views in one place. You can specify transitions between screens and the actions that trigger them. Perhaps more importantly, they also added a design pattern that can be implemented to send and receive data between controllers. Currently you'd have to implement protocols, delegates, notifications or some other custom way to maintain state between screens.

Also new to interface builder is creating UITableViewCell instances within XCode's integrated interface builder.

JSON API

Finally Apple turned their private JSON methods in a public API. Sure, there are great alternatives like SBJson , but adding third party libraries are always a burden when you'd consider something fundamental, like JSON, should be in the core framework.

Cloud Storage

New API's allow to easily store documents and key-value pairs in the iCloud. This makes it far easier to share data between multiple devices. Right now the most common used alternative is Dropbox . Dropbox has it's benefits, but I think iCloud should provide a more consistent user experience as well as a more consistent way to implement cloud storage.

Twitter

I really see this as a bonus. They've made it super easy to add share functionality inside your app. Too bad they didn't add Flickr as an alternative to share graphics with.

In the end I really think Apple addressed a lot of holes in the SDK. The points above are just scratching the surface - there are a lot of other major improvements that will for instance benefit game developers.

I've got a hunch Apple might buy Twitter in the near future.

The reason why I think such a takeover is believable has to do with the naming conventions used in the latest iOS SDK.

The SDK is full of Twitter API's wrapped inside Twitter.framework.

Why Twitter? Why not something more generic like Social.framework, Socialmessaging.framework or Socialupdates.framework?

Twitter is popular, but so is Facebook and other sharing services like Flickr and Instagram . It's true that Facebook and Apple aren't exactly on the same page , but relationships can change rapidly.

Apple is very picky upon naming conventions and coding guidelines within their public API. There are, for example, seldom changes to method names with new SDK versions. If there are any, they are always kept to a minimum.

While designing the API they must have considered making the Twitter API methods somewhat more generic. How would they add a Facebook status update option in the near future? Add an extra API specific to Facebook that, pretty much, does the same thing?

I believe Apple has specifically chosen Twitter to become an integral part of iOS. They deliberately choose to name it's social messaging framework Twitter.framework.

Now that last point is something Apple has a track record of - Integrating another companies software or service making it dependant. They know they want to stay independent. They've got burnt way too many times . Imagine what would happen if Twitter got bought by Microsoft or Google? They would loose the initiative and destiny off the functionality.

It's one of the main reasons Apple created Safari and the iWork suite in the past. To make it independant from IE and Office.

On the other hand Twitter is worth billions , but it still can't seem to generate a solid income (and Apple tried to launch it's own social network , but that clearly flopped ).

Both Apple and Twitter could seriously benifit from a takeover or increased collaberation between the two companies.

All of the above is of course just my take on the matter. Pure speculation and heavily biased. Who knows.. Apple might eventually not buy Twitter at all. Maybe they thought naming the API Twitter.framework was the best thing to do. They might have thought "premature optimization is the root of all evil" and add additional API's for other social networks along the way. We'll just have to wait and see.

iOS has some naming conventions that make it easier to load device specific resources like .png and .xib files.

Imagine having to wrap if statements around every line of code when loading resources just to check if the current device is the iPhone 4. With some easy naming conventions there luckily is no need to.

First there is the well known @2x suffix you can use to load high resolution images for the retina display.

Simply create low resolution versions of your graphics and give them an appropriate name like 'button_save.png'. Then create a high resolution version for the retina display and append @2x to the filename. For example '[email protected]'.

Note that I usually work the other way around and downsize retina graphics to a lower resolution version.

// Whenever you load an image using 
[UIImage imageNamed: "button_save.png"]; 

// or (iOS 4+)
[UIImage imageNamed: "button_save"]; 

// the iOS framework will automatically load the 'button_save.png', 
// or the @2x.png, depending on the device resolution.
// This works the same inside Interface Builder.This works easy enough for iPhone only app development, but what if you are also creating graphics for the iPad? There is a convention for that as well.

Simply give all iPhone graphics an ~iphone suffix and all iPad resources a ~ipad suffix without changing any code.

For example:

// The iPad only version of a graphic
button_save~ipad.png

// iPhone only version 
button_save~iphone.png

// iPhone only version (retina)
button_save~iphone@2x.png

iOS will automatically determine what image to load on a specific device with a specific resolution.

Images aren't the only resources that are specific to a device. Usually you will also require alternative interface files for the iPhone and iPad when you are for instance creating a universal app.

Multiple strategies can be followed, but when you have an almost 100% code share between an iPad and iPhone version, you can use the same method for NIB files as for images.

// The iPad only version the NIB file
MainView~ipad.xib

// iPhone only version
MainView~iphone.xib

As a final note. Don't forget to import all the image files into Xcode!

Tonight I’ve created my first painting. I haven’t painted for a long time, so it was quite a surprise to see how it would go.

For my first painting I’ve had an image inside my head of my girlfriend. I’m not really satisfied about the end result, although I’m not too ashamed to put it online.

Friends and family gave me a lot of painting tools and materials for my birthday last Saturday. A special thanks for Dennis, the brushes he and his wife bought me were superb!

From now on every Monday evening will be my evening to paint. If it’s not too much of a disaster I’ll post the end result on my blog.

I know, it’s kind of stupid to post something about our first iPhone app three months after submitting it to the AppStore. During the development, and even afterwards, I didn’t have the time forgot to post about the app on my blog. The following days I’ll be catching up.

The Cooker is the first app Dennis and I created for the iPhone. Well, to be honest it’s not the first iPhone app we’ve built, but it’s the first one we published to the AppStore.

As it’s name implies the Cooker can be used during the preparation of food. It’s a handy tool to use when you’re for instance boiling potatoes. The timer is based upon seconds and easy to control using a special Time picker.

With this app we focussed on a few key features:

• Easy to use

• Fast and stable

• Great look & feel

• Different

• Perfect fit for the iPhone

The Cooker looks rather simplistic and I think thats one of the greatest things about it. It's a single purpose, 'less is more' utility. Besides keeping the UI clean and focussed on the primary functionality, we’ve put some extra thought in the behavior of the application. To give you a few examples:

• When pressing the Cooker during an alarm ring, the egg would instantly mute.

• When leaving the Cooker and returning to it the timer would how much time was left on the timer. So when you for instance receive an SMS message, and leave the app to read it, the timer wouldn't be reset to 0.

• When spinning the ‘advanced timer’ picker you’d notice that it would indicate 0 seconds and 1 second instead of ‘1 seconds’.

This simple ‘features’ might seem natural, but it’s the little things that set apart Apple and iPhone applications in regard to the competition.

Apart from it’s functionality the golden egg looks stunning if I say so myself :-)

Buy the Cooker for $1.99 at the AppStore