In the second of my blogs on Swift I will look at WatchKit for the newly released Apple Watch. This will involve adding Watch functionality to an existing project, the Hackaball prototype app. Hopefully some of the solutions to problems found on the way will be of use. Version 6.3.1 of Xcode is used.

For an excellent overview of technologies in the Watch, check out the blog by my colleague Alex Barlow.


Replacing Rails: Part 2 - Amazing Tooling

Medium gopher

I come from a compiled language background (C, Objective-C) and I've been thinking for some time now that Rails isn't always the best tool for the job. Memory usage, performance, deployment and too much "magic" are an example of some of Rails' weak points, points I find to be of great importance in the larger scale apps I've had to write or maintain.

I remember reading the initial release of Go and being excited! A statically typed language with garbage collection, a compiled language where concurrency is a first class citizen and a standard library which has everything you could ever need, 90% of what you need is already there.

Here's the workflow and tooling I've been using recently with Go.


Apple Watch: What can you do with it?

Medium img 9537

I’ve been lucky enough to get hold of an actual physical Apple Watch now since Friday. I’ve worn it over the weekend and of course, played around with building an application. One of the interesting things about the Apple Watch is that many of the apps built that were available on day 1 have never been run on real hardware, except perhaps, those built by friends of Apple like Twitter!

Whilst this isn’t a definitive guide to the Apple Watch from a developer’s perspective, it is a list of questions I had and I’m sure others have! I also found a great Ray Wenderlich post with WatchKit FAQs.

Its worth noting that these are things Ive found out so far, I could be wrong and it will probably change in the future!


Replacing Rails: Part 1 "Lets Go!"

Rails has been, whether I like it or not, a pretty big chunk of my life. When I first started charging for my work, Rails was new and it seemed like a community of really active developers. Github and RubyGems seem to have changed the way we all write and use code. (Remember when Github used to be the best RubyGem host?!)

Here at Made by Many, Ruby along with Rails is often our back end of choice for building applications that require a quick turnaround, particularly when there is lots of CRUD involved. It's often an easy option with a fairly good toolset (we’ll talk more about that later) and lots of RubyGems around it cover everything from pagination to authentication.

Simply “not using Rails” anymore however is, well, not that simple! Rails does certain things very well and that’s a part of why it’s still around. In particular, Forms, Database mapping (ORM), Convention, Emails, Rake Tasks and Migrations to name a few, so what’s around that has a chance of replacing Rails? Go!

I’m not going to try and teach you Go from scratch, but look at the getting start guide and Go by Example for some great help there. Also this video is a great talk about some ideas behind the concurrency in Go.

I’m hoping to make this into a series of posts, but I’m not going to make a step by step guide. If that’s something that could interest you, perhaps a screencast is in order.

In the last week I’ve been building an app that includes Dropbox authentication, a job queue and RESTful controllers — so let’s have a look at some of those parts extracted and compare them to Rails-land! In this example I’m using a simple router/toolkit called Martini.

Here’s my model for Reels (a Reel is a collection of Photos); not so different really! The JSON notation you see is called ‘tags’ in Go, it’s essentially metadata added to the field and here it specifies the field names Go will use to parse or encode JSON. “-” means don’t print anything and “omitempty” means only output the field if it isn’t null.


What is a Debian package?

For the past year or so we’ve made an effort here at Made by Many to start embracing more tried and tested approaches to releasing software. After having a long debate around what toolchain we’d like to use, Debian packaging was suggested as a possible unit of deployment. It’s a platform that’s been used for ages, is well tested, and Ubuntu, our operating system of choice, uses it by default.

When we took a deeper look into what a .deb file actually does when installed and found it had some properties that we really liked. It: