Marcin Bunsch

One of the reasons I built Dotz was to see how it would survive change. The first release was simple exactly for this reason - I planned to return to add more features and see how simple or difficult it would be. I managed to add a new feature to Dotz recently - when you connect the dots so that the lines form a shape (like a rectangle or square), all dots of the same color will disappear, adding to your score. As I introduced this feature, I reflected on this refactoring exercise and SOLID principles.

Step 1: Make it work

My initial approach was to take the easy road by modifying the Move class directly. I realized that it was missing some core functionality, such as getUniqueDotCount or getGroupedDots methods. I've also fixed an issue in destroyDots which appeared only after it was forced to remove a lot of dots from the screen.

At the end, I've expanded it to check if a square was present and schedule more dots of the same color for removal.

I coded, tested and released it. And that's when it hit me. I did two things: I fixed issues within the Move class and I've modified its behavior. Now, fixing issues is fine. Modifying existing behavior in the same class has short legs - what if I want to add more functionality? What if I wanted to give a choice between game modes?

Service Object is a pattern of extracting business logic into a separate "service". It has gotten considerable traction in the Ruby ecosystem and is worth exploring. Steve Lorek described Service Objects in the following way:

A 'service' describes system interactions. Usually, these will involve more than one business model in our application.

As an example; we have a User model and this encapsulates a password. If a user has forgotten their password, the business rules dictate that we have to send them an e-mail with a link to reset it. This functionality is a service.

The CodeClimate blog post on refactoring fat models has a good rulebook on when to use this pattern:

• The action is complex (e.g. closing the books at the end of an accounting period)
• The action reaches across multiple models (e.g. an e-commerce purchase using Order, CreditCard and Customer objects)
• The action interacts with an external service (e.g. posting to social networks)
• The action is not a core concern of the underlying model (e.g. sweeping up outdated data after a certain time period).
• There are multiple ways of performing the action (e.g. authenticating with an access token or password). This is the Gang of Four Strategy pattern.

I see Service Objects as a mutation of the Command pattern. They allow separation of business logic from models and controllers, but have further benefits in testing and composition.

Hello method_struct

At Base Lab, we're implementing Service Objects using the method_struct gem. Let's go through an example which illustrates the benefits of this approach.

Ever since Twitter opened up their Analytics, I've probably been spending more time on it that I should admit to. It is a gold mine of information about how your tweets perform. As I was looking at the stats, I thought it would be fun to run an experiment on whether the Analytics data can tell me when to tweet.

Step 1: Gather Data

I was very interested in when was the best time to publish to be sure that most people see the tweet. What hours are best? What days of the week?

Unfortunately, Twitter Analytics gives a lot of information about particular tweets, but aggregate reports are missing. As Twitter exposes the ability to export your data into CSV, I decided to move in and hack it.

As I wanted to have everything in one place, I prepared a Chrome extension which introduces a new tab to Twitter where I could do all the hacking I need.

After loading and parsing the CSV via Papaparse and storing it in IndexedDB via PouchDB, I was ready to crunch the numbers.

Here's how the Week Analysis report ended up looking:

The design is lacking, but it visualizes data well. By looking at it, I concluded that I'm getting best results in the morning (9:00 AM), before lunch (11:00-12:00) and then around 4 PM.

Of course, this was error-prone:

• The hours are when I posted the Tweet. What this means is that I have an average of 150.5 on tweets I post on Mondays at 9 AM. Although not exact, it is still very useful.
• I have no historical data - Twitter starts tracking impressions when you sign up for Analytics.

I did end up with some pointers though, so it was worth to test this hypothesis.

Recently, at the Base Lab Hackathon, I've been playing around with building a mobile app in HTML5 with offline support. There's a lot of material on the subject scattered all over the web. I wanted a single place where I could find all this information, to I wrote everyting down with links, and here it is.

I also built a demo which supports everything I write about in this post. You can see it working at http://marcinbunsch.github.io/offline-mobile-html5-demo/ and the source code is available here. Make sure you view it on a mobile and use "Add to home screen" feature for best experience.

Pack light

An ideal mobile app is fast and snappy. Lowering the number of resources will dramatically improve the first load experience. Afterwards, it will use cache, but you only make a first impression once.

As much as I love jQuery, zepto.js is a much better alternative for mobile HTML5 apps. It's 9kb gzipped and has a largely jQuery-compatible API.

Don't bring in Bootstrap. It's huge and you most likely won't use most of it (see Addy Osmani's presentation on CSS Performance Tooling). Either use something smaller, like Pure and Picnic, or roll your own. You're on a much smaller screen, with less clutter - you need less boilerplate.

tl;dr You can check out the game here.

Recently, to learn new programming techniques, I've been reading up on game development.

I thought it would be a fun experiment to try to clone an existing game, so I would be able to focus on the game engine and code, with the hard part of game design already done. During vacation, I've been playing Dots by Betaworks, which is why I chose it as a source of inspiration.

I've decided to build it in CraftyJS and Brunch as a build tool. I've also added jQuery for some basic DOM manipulation.

Here's the result, which I've named Dotz: http://marcinbunsch.github.io/dotz. It is a simplified clone, so it only consists of one level in which you have to connect as many dots as possible in 20 moves.

As I found the whole experiment mighty interesting, I also thought it would be fun to highlight a few interesting problems I bumped into and how I solved them.