17 February 2014
Javascript is hard. Let’s not keep it that way.

Javascript is hard. I know, I’ve been programming in it since the GeoCities era.

Yeah, it was only a few lines of code back then, but today entire web apps are built around it ((frontend and backend). Thats’ pretty insane for a language that hides your errors until it meets the user’s browser.

Coding without a compiler is super hard so I do my best to keep the code as simple as possible. This becomes challenging as the codebase grows and more developers are added to the team.

I love Javascript and eager to change all that. The computer is so much better than us at detecting issues and keeping our code organized. I’m looking for the best tools to deliver a maintainable codebase.

Here are some libs and tools my team and I already use today:

Backbone

Backbone keeps everything in its place. It’s an MVC framework (sorta), but the important thing is it breaks your code into reusable modules.

I have much more to write about keeping backbone code ticking well, but I’ll keep that for a future post.

Requirejs

Requirejs breaks the code into modules and maps the dependencies between them.

I once hated requirejs. It just wasn’t working for real projects. Version 2 changed all that and now I have no idea how we maintained the project without it.

We use it to break the project into logical files. Each model, view, router, whatever gets its own file (Like a “real” programming language).

It also allows to easily port modules from one project to another without going insane.

r.js optimizer

Requirejs comes with the r.js optimizer that can concatenate your entire project into one file (and much more). This usually makes your code load faster.

A side effect of optimizing is the detection of typos and lowercase/uppercase issues while loading your files. Better now then on the user’s browser.

SourceMaps with UglifyJS

We use UglifyJS(2) to minify the code after the optimization with r.js. There’s a great feature that allows to generate source maps.

This maps the minified code to the original code. When faced with a bug in the real world, Chrome lets you debug it like it isn’t minified at all.

Errorception

"What you don’t know can’t hurt you" - Novice Javascript developer.

Think of all the bugs happening in the browsers of your users. You just have no idea about them. You’ll probably want to catch uncaught exception and report to your server.

We rolled out our own solution for that, but then decided errorception just does it better. Bugs will be collected with their stack traces and.

WebStorm

We love Sublime Text, but WebStorm is the winner for larger projects. Yes, it takes forever to load, but once it does, you get so much benefits out of it.

It understands your code, shows you warnings and errors and has great Git integration. History and blames are a click away and it has a wonderful merge tool.

Oh, we also use it to debug the node.js code and it’s surprisingly good.

JSHint

JSHint is an impressive tool. It protects us from common javascript gotchas and can make sure the entire team is using the same coding conventions.

It’s already baked into WebStorm, but for some reason it’s not on by default. Enable it from Preferences and you’re good to go.

Jasmine + Phantomjs

Unit testing isn’t always easy, but with Jasmine and phantomjs it becomes pretty simple.

We found out it’s more reasonable to test the models. It’s a good idea to keep the data-logic inside the models so it could be easily tested.

We have a lot more to learn about testing our code. The main thing I’d like to do is add it into the IDE and we’ll probably migrate over to  using Karma in the future.

Jenkins

We configured Jenkins to “build” the project after each commit. Yes, “build” is a weird concept for a dynamic language, but we do transform it with the r.js optimizer, minifying with UglifyJS(2) and add some extra pulp.

The build process also runs the tests on each commit and fails the build if the tests are broken.

Once you break the build, Jenkins will email you and ask you to fix it.

Are we missing anything obvious?

I’m probably only touching the tip of the iceberg with these libs and tools.

Let me know if I’m missing out on other great tools. I’d love to make Javascript easier.

13 February 2014
The simplest solution always wins

Having no UI is better than having an amazing UI.

The best interface is no interface.

An app with one screen is better than an app with two screens.

A solution where code is deleted is better than a solution where code is added.

A user flow with one fork is better than one with two.

An object with no members is better than one with 2 members.

An enum with 4 options is better than 2 booleans.

A great title is better than a good title plus a great paragraph to explain it.

A 20 seconds instruction video is better than a 60 seconds one.

A short email response is better than a long email response.

Simple isn’t always easy, but it always win.

17 January 2014
The impact of appearing on HN’s front page and the secret of getting there

My latest blog post (about developing apps for iOS 7 only) has been quite popular, probably my most read post ever. It is definitely not the best I’ve written.

I posted it to Hacker News and two hours laters it got 39 upvotes and 17 comments and went straight to the HN first page ranked at number 4.

image

Wow! That we awesome! I fired Google Analytics to see what the impact of it will be:

image

That was 339 people reading my blog post Right Now! That’s amazing! I usually open the real-time analytics to find 6-7 people at a time.

I waited to get the full statistics on the number of Unique Visitors to my blog post:

image

As you can see, most of the time my blog isn’t very popular, but this blog post on HN managed to bring more than 20,000 different people to read it (in both days it was popular).

Only 10 readers signed up for the site’s newsletter (Thanks guys!), which is pretty small, but I still enjoyed any reader who read and commented on it.

The Secret

If you made it this far, you probably are wondering what’s the secret of making it on HN and ranking on the first page.

The secret is… Unknown.

Yes. I have no idea what made this post popular and why other stuff I write didn’t attract the HN folks.

I did no gaming of HN, didn’t ask friends to upvote or anything special. Just posted it and the HN community liked it and upvoted it.

One thing I did do is edit the title of the post to sound more interesting than it initially was. The original name was “Porting iOS 3 app to iOS 7” - which probably sounds boring. The post was finally named “iOS 7 only is the only sane thing to do” which is one of the quotes I used in the blog post.

As always, the secret is to write great content, use a good title, mix in some luck and keep refreshing HN to see what happens.

3 January 2014
iOS 7 only is the only sane thing to do

I’m porting an app that was originally targeting iOS 3 to an iOS 7 support only. Almost three years later, so much have changed.

When I started programming it, iOS 4 was pretty new and not everyone upgraded to it. You know, there wasn’t over-the-air upgrades and you had to use iTunes for upgrades. No wonder only geeks were upgrading.

We decided to support iOS 3. Here are some stuff that weren’t available back then:

Blocks. Can you imagine programming without using blocks? I can’t, but that’s what we did back then.

GCD. There was no Grand Central Dispatch. Doing background work wasn’t easy as it is today.

ARC. No automatic reference counting meant worrying a lot about leaks, crashes and retain cycles. With ARC, you mainly have to consider retain-cycles and choosing between weak and strong references.

UIAppearance. There was no way to customize the basic UIKit controls. If you wanted a UISwitch with a different color, you had to build a complete custom switch control by yourself. It’s not just UIAppearance, it’s more that Apple understood that apps needs a unique look.

The list goes on and on. These are the things that I added to the app as time went by. When iOS 5 came around, we dropped iOS 3 support, introduced blocks, GCD and ARC into the app. When iOS 6 came out, iOS 4 support was abandoned and we could more easily customize the look and feel of the app.

Our current app is supporting iOS 6 and iOS 7 at the same time. This is horrible. We can’t leverage what iOS 7 has to offer and a lot of the UI is compromise. Going iOS 7 only is the only sane thing to do.

As we’re going for an iOS 7 only release here are some things I’m glad for:

Pull To Refresh. When we added pull to refresh to our app there weren’t many apps using this technique and it added a premium feel to our app. Our custom built pull to refresh control is no longer needed as Apple added UIRefreshControl a long time ago.

UIViewController Containment APIs. It’s so easy to keep sanity with UIViewControllers and the containment APIs allow creating a smart and scalable view hierarchy.

Custom Tab Bar. To customize it, we had to build our own UITabViewController subclass. Who needs it now. Deleted.

Custom Navigation bar. We wanted a background image for it, this wasn’t possible back then. Also gone.

HTML Strings. I remember that for adding an underline to some part of a UILabel, you had to split it into 3 parts. Not anymore, Attributes strings are so easy to create these days, you can even use HTML to create them.

@2x only. The era of retina only devices is here. Goodbye half of the images.

Flat out. A lot of retina images are also on their way out since most of the design gone flat. Almost no need for images

viewDidUnload. It’s not being called anymore by the OS. Wow, a lot of code is going to the trash!

AutoLayout. Not sure what I think of this yet. One thing I do know is if you’d like to achieve a html/css like rendering of UIViews then this is the way to go. Instead of calculating UILabel heights, let iOS do it for you.

UIDynamics. We’re surely not going to use this too much, but when physics are needed, we’ll surely use it.

Receding keyboard like the messages app. This was one feature we really wanted and implementing this was painful as hell. I can’t believe it’s now just a boolean value away.

There are so many options to make the app much better with iOS 7: Better handling of push notifications, background fetches, custom transitions, multipeer connectivity and so much more. iOS 7 also keeps us focused on the content and not the chrome, this is the ultimate key strength of iOS 7.

The iOS 3 app pushed what’s possible to the edge and beyond, I’m hoping to do the same for iOS 7.

27 December 2013
Detecting if a Backbone Model needs to be saved

I’ve answered a question on stackoverflow and I thought it might be useful for anyone using Backbone.

The question is how to detect if a Backbone Model has changes that requires it to be saved to the server. This is usually good for enabling/disabling the save button on forms.

The idea is that the model listens to its own changes and marks itself as changed. When it does sync with the server (read or write) it sets this flag to not-changed.

Here’s the code: