15 March 2014
Move until you see it

Chess

Here’s a good advice for playing Chess:

"Don’t move until you see it"

There’s one best move to make and it’s your job to find it. It’s much easier to take the first move that seems good enough. It’s much harder to think each move through and follow the consequences. The ones who have the patience and stubbornness to do so - win.

I’m not a Chess player, I barely know the rules of the game.

Software Development

I’m a developer and I’d like to offer a different advice:

"Move until you see it"

The development process is also full of small moves.

- How should I name this method so my teammates understand it?

- Is it okay to use a global variable for this bug-fix?

- Should I encapsulate this in a new object?

- What framework should I use to solve this task?

Each task can be solved with many different moves. Some are very poor choices, others might be okay and some are pure genius. Yes, even in programming, some “moves” are better than others.

One of them is the best. It’s your job to find it.

In Chess, you only get one opportunity to take the correct move, but programming allows you to play around and find it.

So move a lot and start seeing it. It happens that the simpler moves to spot are the poor choices.

Yes, it’s easier to add a global variable to solve a bug, but what goes around comes around and that small hack will hunt you in the future. And yes, it’s easier to copy-paste code instead of making things DRY, but then each change multiplies work.

So go play and find the right move. And keep moving until you see it.

Let’s talk about this on Twitter, I’m @ketacode.

1 March 2014
5 Javascript debugging tips you’ll start using today

I’ve used printf debugging since forever and I always seem to solve my bugs faster that way.

Some cases calls for better tools so here are some gems that I’m sure you’ll find useful:

1. debugger;

As I’ve mentioned before, you can use the “debugger;” statement to force a breakpoint in your code.

Need a conditional breakpoint? Just wrap it with an IF clause:

if (somethingHappens) {

    debugger;

}

Just remember to remove these before going live.

2. Break on node changes

Sometimes the DOM just gets a mind of its own. Weird changes take place and it’s hard to get to the source of the problem.

The Chrome Developer Tools has one super useful trick for debugging this. It’s called "Break on…" and you can find it by right clicking a DOM node on the elements tab.

Breakpoints can be set when the node is removed, the node’s attributes change or one of its subtree nodes changes.

image

3. Ajax breakpoints

XHR Breakpoints, or Ajax breakpoints as I call them, allow to break when a desired Ajax call is made.

This is an amazing tool when debugging your web app’s networking.

image

4. Emulate different mobile devices

Chrome added interesting mobile emulation tools that will make your life much easier.

Find them by choosing any tab that isn’t the Console tab, press esc key on your keyboard and choose the device you wish to emulate.

You won’t get a real iPhone, but the dimensions, touch events and user agent will be emulated for you.

image

5. Improve your site with Audits

YSlow is a great tool. Chrome also includes a similar tool under the developer tools called Audits.

Take a quick audit of your site and get useful and practical tips for optimizing it.

image

What else?

I can’t imagine developing without these tools. I’ll post more tricks as I find them, so stay tuned.

Find me on twitter: @ketacode

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.