#leedsjournal

Last Wednesday, I went to my first code dojo. Held in Callcredit's office, this dojo planned to build Skynet to occupy the city of Leeds with cyborgs. What would be the obvious thing that every war-machines have? Digit recognisers, of course! I can't imagine what cyborgs would do without able to read digits? So, instead of making a cyborg in its entirety, we ended up making a crude and simple implementation of digit recogniser as our first step.

Coding in pairs - Leeds Code Dojo (photos by Grant Crofton, taken from Meetup.com's dojo page)

The technique that was used is called k-nearest neighbour (KNN), which is to find k number of things with the most similar features (nearest in distance). I paired with Phil to implement the recogniser using Objective-C. Since both of us are Machine Learning newbies, we simply compared the number of whitespaces for each image. This simplistic approach yields the accuracy of 18.75% (which is better than expected!). Below is the snippet for calculating distance using whitespace comparison.

I went continuing to improve the distance calculator using different techniques and tweaks. Here are the results for each technique with its accuracy and performance (the machine: Macbook 2010, 2.3 GHz Core i5, running Xcode 6.1 GM on OSX 10.9.5):

Calculate Distance Accuracy (%) Time (s) Whitespace comparison 18.75 125.62 Sums of pixel differences 88.75 90.38 Euclidean distance (power=2, k=1) 90.25 106.87 Euclidean distance (power=2, k=3) 86.75 109.14 Euclidean distance (power=3, k=1) 90.25 111.04 Euclidean distance (power=3, k=3) 87.50 115.97

Adding neighbours seemed to be lowering the accuracy. Even after adding mechanism for putting weights for the neighbours (bigger weight for nearer neighbour), bigger value of k still lowers the final accuracy. The table shows us that using euclidean distance with power of two yields the best score in the shortest amount of time. Below is the snippet for calculating distance using euclidean distance (power=2, k=1).

I really enjoyed my first dojo experience. I met new people, got introduced to new languages, ate free pizzas, and learned new techniques. Code dojo made me realise that regardless of our ethnicity, race, text editors, indentation style and programming language, we know that deep down in heart we all developers have one similarity. We all want to make better cyborgs :)

Feel free to check the full code at Leeds Code Dojo's repo.

He's a very opinionated man with bold things to say. He has useful insights but sometimes his delivery might be a bit too straight or even harsh for some people.

Two main points that I took from this talk:

Don't structure your classes solely for testability

Strive for code clarity, read more code and write more code

Leading on from Chris' Intention post, I continued the journey to make my controllers slimmer.

If you haven't read the post, please do because the things that I'll share are based on that. It explains about how to make your controllers as light as possible. So how?

Code one and only one functionality as one Intention class

Drag an NSObject in the storyboard, make it as the custom Intention class

Wire up your controllers to the classes

The fun thing is that you can add features and functionalities in your controller by wiring things up in Storyboard. One can 'code' the controller's functionalities without writing actual codes.

However, I encoutered a problem when working with delegates. An object could only have one delegate object. Delegate objects have compulsory and optional methods that should be implemented in one class that conform to the protocol. Usually each methods has different functionality. If we implement all of them in one class, it will violate the concept of SRP.

I asked Chris himself about the issue, his answer pointed me about multicast delegate.

@ixnixnixn probably the best would be to have a multicast delegate =)

— Chris Eidhof (@chriseidhof) May 11, 2014

With a little bit of google research, I found an article and a sample code that explain the techniques involved.

But still, I'm not satisfied. I need a slightly different direction on the implementation. Since using Intention relies so much on storyboard already, I want to able to wire my object to its delegates using Interface Builder rather than using written code. Also, I need all of the delegates' methods to be called, even for the ones that returns a value.

Take textFieldShouldReturn: for example. The code should traverse all the delegates and check whether it will respond to the method. If it can, then it's safe to call the method. It should return NO if there's one delegate that returns NO. Otherwise, it should return YES.

'Proof of Concept' sample app

So here's how I went with the idea of extending the concept of Intention with delegates. The objective is to be able wire many functionalities as a delegate object.

I made an app to prove that it's feasible. The app's pretty trivial. It's an app with a text field that has three features;

dismisses when return key is pressed

limits the characters allowed

enable a button if the text is a valid email

Controller on a diet (ViewController.m)

The controller in this app is really light. It consists of a text field and an implementation of viewDidAppear:. I need both to make the text field the first responder after the controller appears.

Dismiss On Enter (DismissOnEnterIntention.m)

It's the same concept as the one in the original post. The only thing that's different from the original is instead of using textField:shouldChangeCharactersInRange:replacementString:, it uses textFieldShouldReturn:.

Limiting Maximum Character (MaximumCharacterOnEditIntention.m)

The cool thing is that we can set the maximum characters from storyboard with user defined runtime attributes. If not set, then we put a constant with a reasonable value (ex. 30 characters).

Email Validation (EmailValidationOnEditIntention.m)

First, we should have an NSString category for validating email. Next, we need to define how to communicate with external object such as UIButton. I copied the technique from the original post by making an IBOutlet for the target. Make an outlet from this class to the button and set the keypath in user defined runtime attributes.

Forwarding Delegate Calls (ITNTextField.m)

So how to forward all the delegate calls from a UITextField? The important thing that I learnt from the article is to have all the calls be forwarded to all delegates in the array.

I chose with subclassing instead of creating a separate MulticastDelegate object (like one in the article). I didn't use forwardInvocation: but I just implemented necessary methods and make sure that all of the delegates is called. One thing to note, we should check first if it responds to the selector before make the actual call.

We need Storyboard to recognize our array of property. We do this by adding IBOutletCollection to our property of delegates. And don't forget to switch the text field's class to your subclass (mine is ITNTextField).

Why not use category? In my opinion, subclassing is safer and more proper since we need to add a property1. With this approach, we're not changing anything with the original UITextField.

Wire Things Up

Check the animation to see how the wires are connected. So we're adding features only by wiring things. Simple. 👌

Caveat

One caveat is that IBOutletCollection can't handle id objects with protocols (ex. id<UITextFieldDelegate>). Since we already defend our code to only call methods from a delegate object that can respond to a selector, then everything should be fine.

Check out the Code

I've uploaded to Github for anyone who is interested; extending my intention.

To Sum Up

The concept of separating controller's code to pieces of intention class could still be improved even more. The class would turn into bits which we can use by wire them up. With this, not only our controller's code is light, but all of our class still conforms to SRP.

The Talempong Experience

This website describes the background, the motivation and the creation of Tlamp! project. Tlamp! is an interactive music software that helps its user to learn and play an Indonesian musical instrument, Talempong. This study will also review past related works and how music software can be brought into the musical tradition’s realm.

Numerous literatures argues about how effective software games teach its players to learn a musical instrument. The premise is that a software can teach basic skills that are transferable to the real instrument. Based on that premise, Tlamp! was built to conduct a simple experiment. It would explore how far could Tlamp! help to introduce traditional music to a broader audience.

This is my second assignment that went open-source. It's a music software for Mac, currently still in pre-alpha release. Tlamp! is heavily inspired by rhythm-based games such as Rock Band, Guitar Hero, DDR, etc. But what's unique is instead of playing popular music instruments such as guitar or drums, Tlamp! lets you learn and play Talempong, a Sumatran percussion.

I even went to 2 Indonesian families in Leeds to test Tlamp! out, and they seemed pretty engaged with it. It was a fun experience for me, seeing their responses from the software that I build. Hope that they had fun as much as I do.

A nice idea from Chris from the objc.io fame. The idea is to notch the concept of SRP up another level. A level until your controller's codes only consist of delegate methods implementation (viewDidLoad, viewWillAppear:, etc). With this idea, not only our controller will become super light, in fact it'll be almost weightless.

The way that he did it was to hammer the controllers' code into bit pieces. Each piece will be a class named "Intention", which has only one responsibility. You might ask, how do you access a property between classes? Simply, Separate the object into another class (an outlet to be exact). Delegation and data source also might be separated to a class. The things is everything revolves around your Storyboard.

"Yet it is no more necessary to have real or imitation instruments in order to reap the benefits of gamelan that it is for a composer to use actual Indonesian music to demonstrate an affinity with it" — Mantle Hood

Virtual Gamelan is a collection of sound explorations from Lydia Ayers. Spanning over 30 years of compositions and researches, the record gives various sound textures to its listener. The intricate combination of the composer’s background in technology, creative mind and broad knowledge of world music brings new kinds of music that few people can imagine. For an electronic composed music, elements in the album still sounded authentic rather than computed or artificial. The track 'Pendopos' combines bird chirps with synthesized gamelan, which brings an audio scenery of mountains in the morning time.