I’ve been holding off on posting for a few months as I’ve had a couple of pretty cool projects that I wanted to get released so I could write about them. Unfortunately they’re currently hitting a few snags so that’s going to have to wait. I do however have something else that I cooked up based on an idea for something at work that I would like to share. So without further ado, may I introduce guggenheim.js.

Guggenheim.js is a framework agnostic plugin for your website that will create an animatable gallery. It currently supports animated filtering and reordering of the galler items, as well as the pre-requisite pagination. It makes use of absolute positioning and hiding the overflow to position each item in the right row and column so that they remain in the correct order but still inside the same container. This enables me to animate the items to their new position when filtering or re-ordering, giving a really cool looking effect.

The animation is using the same code I used on tipBox, but with improvements and fixes that I will eventually port back across. It will use CSS3 animations where available but fallback to Javascript when necessary. The javascript animation is using a modified embedded version of emile with Kangax’s fixes to make it play nicely with opacity in IE8. This gives it a nice, lightweight engine for handling the animation.

I am intending to add functionality to auto generate pagination links, including numbered pagination, but for now you can easily add your own prev and next buttons and call the exposed methods of the guggenheim object.

Check out the Source Code and Examples over on GitHub for more information:

Source Code | Examples

So assuming anybody out there actually reads this blog more than once, you may have noticed a few things lately. Firstly that I’ve not posted in far too long, and secondly that there have been some changes around here. Well, it’s not just the blog, hence the extended break from posts. As the title of this post suggests 2012 is a year of new beginnings for me. I’ve started a new job, more on that later, and decided to move my blog away from wordpress and give it a bit of an overhaul.

Firstly, why the move? Well for one thing having done some work on setting up custom Wordpress sites for people recently I have massively fallen out of love with it. Don’t get me wrong, for the layperson who wants a basic blog it’s great. But for me it just wasn’t working out. There was also the fact that it was costing me for hosting and I wanted some cheap decent hosting. Enter Octopress, I’d seen some information on this a couple of times but never really properly looked at it, until now. For those that haven’t heard of it, Octopress is a blogging framework designed with hackers/coders in mind. It’s built on top of Jekyll the blog-aware static site generator that is used by GitHub pages. The way it works is that you create your posts in Markdown or HTML files, then run a Rake task which then builds static pages with your content on them. What this means is no database requirements, and technically no server side language required. This meant I had the choice of 2 (that I knew of) possible hosting options, GitHub Pages or Heroku. Both seemed like good options, both were free, had good levels of support and service, and would let me use custom domains. In the end I decided to go with Heroku as I’d been wanting to try them out for a while and it gives me a good scalability, so while it’s free for now, I can add more to it if I need to. So far this seems to be working out pretty well for me and I’ve since started hosting another project that I’m working on with them. As for Octopress, I’m really happy with that and would thoroughly recommend it to anyone needing a simple blogging solution.

As for the new job, well I’m now working at a games company called Eutechnyx in Gateshead. I’m one of the main Web Developers working on their new Online Racing MMO Auto Club Revolution. This has been a big change for me as it’s meant leaving behind PHP and MySQL and embracing Python and MongoDB. I’ve also had to get to grips with SVN which has been a considerably less enjoyable process. As for Python and Mongo I’m really enjoying them. Python is still a strange language to adapt to with it’s whitespace orientated style, thankfully the time I’ve spent using CoffeeScript lately has probably helped a great deal with that. I’ve also been using Mongo on a private project I’m working on with Ruby and Sinatra and finding that really snappy easy to work with once you understand the way embedding documents works.

So what does the future hold for me? Well I think that for now I’m leaving PHP and MySQL behind. I’m still going to be continuing in my Javascript development and looking to bring CoffeeScript into that as much as possible but my server side work is now going to be either Python or Ruby, both of which I’m having a lot of fun with at the moment. As for my choice of data storage? I think it’s safe to say MongoDB is here to stay on that front, although I will miss working out clever SQL queries.

So this month I’ve been playing with something new… again (I’m going through an experimental phase I guess). This month it was Ruby, or more specifically Ruby Gems. I’ve used Ruby a little in the Rakefiles I use for building my javascript projects but not really done any major work with it, until now.

I’ve been trying to find a nice simple solution for setting up my project skeletons quickly and easily. I’d thought of some sort of Git repository but then I’d end up with some faffy process involving multiple branches for different project types and having to clone a repository and then remove the git repository in the newly cloned folder and well, this didn’t sound quick or easy. Eventually I hit on the idea of a command line ruby gem that could use templates defining a directory structure to set up what I needed. A quick search turned up nothing that seemed to do the job, the closest thing was Mr Bones but that seemed to be entirely for Ruby projects and the template skeleton wasn’t easily customisable.  I was disappointed that it existed though as I wanted to name my gem bones but hey, how many things am I going to write that I can actually justify calling Skeletor?

So I started looking into what was involved in creating ruby gems. Initially I started of using Jeweler but this created a lot of stuff I didn’t really understand so I decided to strip everything back and just look at the structure of some gems I already used. My main source of reference was Sprockets but I also used Capistrano when trying to understand the command line aspect of the gem. These gave me a good source of reference for what was required in the various gem files.

For anyone who’s not created gemfiles before the basic folder structure is as follows:

• lib - contains 1 ruby file with the same name as the gem and a folder also named after the gem which contains all the code for the gem
• bin - optional folder that contains the command line executable files for the gem
• test - contains the unit test files
• a Gemfile that contains the dependencies for the gem
• a.gemspec file that contains the configuration details for building the gem
• the usual README and LICENSE files in your choice of format

I’m not going to go into the details of each of those files.  I’d say the best thing to do is to check out the source of some of the gems that you use and that will probably give you the best understanding of what’s required. I’m using Thor for the command line interface and Hike to locate the files in the 2 possible load paths.

Skeletor supports defining a directory structure with files and folders. You can also specify include files which will be copied into the directory, either from a local file or a remote url, and define build tasks to be run after the directory is set up.

The code for Skeletor is actually pretty simple. Ruby’s built in YAML.load function converts the template file into a Ruby Hash object which can then be looped through and there is a JSON gem that works in the same way. The most complicated part was the validation code as I needed to be able to specify custom data types that a node could match any one of.  The only gem I could find for YAML validation was Kwalify but that wasn’t flexible enough for what I needed so I had to write my own. I eventually managed to get a working validation class that worked for what I wanted and decided to extract it into it’s own gem so it could be used for other projects, and thus Grayskull was born.

Grayskull will validate JSON and YAML files against a given schema including matching against custom types. All the details for how to create the schema are at the GitHub page, as are the instructions on how to install and use it. The same goes for Skeletor. Grayskull is also using Thor for the command line as well as the aforementioned JSON gem for validation.

Check out the GitHub repositories for the source code and instructions.

Skeletor | Grayskull

Thanks to an issue raised on Uncharted by a fellow GitHub user pointing out that a lack of good examples was stopping people see if my work was any good and worth using I’ve started going through all my projects and making sure they all have proper example pages and decent instructions in their README files.

So far the following have been updated:

Obscura - Examples | Documentation
Uncharted - Examples | Documentation
Ermintrude - Examples | Documentation
tipBox - Examples | Documentation

I recently managed to get myself a Macbook, which besides finally giving me a home computer that can cope with what I’m throwing at it, has finally enabled me to start looking at iOS development. I’ve briefly played with Android development but what little Java skills I picked up at university and was able to remember after all this time weren’t quite up to the task. So you’d think that tackling developing in Objective-C, a language I’ve never used, would be an even bigger challenge right? Well thankfully I managed to find some help, primarily from iTunes U. If anyone hasn’t checked this out yet I’d highly recommend it, there are a load of free to download lectures from several of the big universities on there (primarily US from what I could see but there were some others). The course I’ve been following is Stanford’s cs193p course on iOS application development by Paul Hegarty. If you can get past Paul’s slightly eccentric seeming nature, anyone wanting to get into iOS development would do well to check this out. I’m only a few lectures in at the moment but the course has already succeeded in helping me finally get my head around MVC.

So what do I think of Objective-C? Well I’m still in my early stages of playing with the language so this is really just a first impression but I think I’m going to like developing in it, and I certainly think I’m going to find it easier and more enjoyable than I ever did Java. It’s very different from most of the languages I’ve ever learned and certainly a huge change from the languages I use on a daily basis (PHP and Javascript). One of the first things I’ve noticed is how verbose it is. There is very much a convention of the code reading like plain english, with things such as long variable names and methods. The way methods are defined is one of the primary examples I would give of this verbosity, and of the difference of Objective-C to languages I’m used to. The following examples show a comparison of how methods are defined in Actionscript 3 (I know, I know, but it’s the only langauge I know well enough to write comparison code in that defines the return and argument types) and Objective-C.

As you can see the single argument methods are pretty straight forward, return type at the start, followed by the method name, then the argument and it’s type listed after a semi colon (felt weird having no brackets). From what I’ve seen there doesn’t seem to be any indication of public or private with the method definitions. What seems to happen is that you just don’t define methods you want to be private in your header file, which defines the class’ public api. The - at the start of the definition indicates that this is an instance method, a + indicates a static method. The primary difference in the way methods are defined is when it comes to methods with multiple arguments, where you see this splitting of the method name. The only real purpose I can see of this is that if you write your method names and variables properly it helps the code read like plain english.

As for developing in XCode, so far I’m liking it. The built-in Interface Builder Gui tools are really helpful, especially when it comes to linking the controller to your views.  It’s taking me a little while to find everything in the property inspectors, possibly because what I’m looking for isn’t available for customisation but you never know. The in-line error and warning highlighting is really helpful as it makes it much easier to see where you’ve missed that semi-colon or curly brace. I think I’m really going to like the property synthesization (more on that once I’ve gone more in-depth with it) that allows the compiler to auto generate methods for you.

Developing for iOS is going to present me with some new challenges that I wouldn’t normally have to contend with such as Memory Management, which is going to take some getting used to, but that’s half the fun. So hopefully before too long I’ll be posting about my new app that you can all go and buy and make me millions, (although based on how many readers I probably have  I might be lucky to make a pound!).  I promise it won’t be a new fart app!