Sometimes when you set up an animation in a UIView that you want to run as soon as the view is displayed, you’ll encounter an issue where the animation doesn’t run and proceeds to its completed state without any delay.

For example, take the following code:

1
2
3
4
5

[UIView animateWithDuration:0.25 animations:^{
    _buttonView.layer.transform = CATransform3DMakeScale(0, 0, 1);
} completion:^(BOOL finished) {
    NSLog(@"animation complete");
}];

In this case what often happens is that the button will disappear instantly instead of showing the 0.25 second animation. Confusingly, it also displays the log message after 0 seconds. There is no delay happening at all. Why are our perfectly clear instructions being ignored?

Worse yet, this problem is often intermittent. Sometimes it will work fine, and other times it won’t. You may even be able to solve the issue by adding a delay with the animateWithDuration:delay:options:animations:completion: method. But how can you know how long to make the delay? On slower devices it may have to be longer.

So here’s what’s really going on: Core Animation is making a decision for you. If the view is not in the view hierarchy, it should not waste cycles animating. Furthermore, the animation should not ever start midway through (that would look bad, right?). So it forces any offscreen animations to immediate completion.

How do you solve this? It’s very simple: since your view is almost certainly being managed by a controller, just make sure that you do not try to run any animations before the UIViewController’s viewDidAppear: method is called (and make sure the view has been added to the hierarchy with [view addSubview:] or similar).

You could also check if the view has a superview, but it would be a lot tricker; the superview itself may not have a superview yet, and if there is no superview you will need to set a timer to check again. Too much work in my book.

I thought it might be nice to take a break from my regularly scheduled programming and share with you a great insight I’ve had recently about fried rice. Here in America, fried rice usually brings to mind Panda Express and a steam pan of dried-out white rice turned brown by the addition of soy sauce. In my younger days I would always opt for it because I thought white rice was boring, but it’s never been that appetizing.¹

Oddly, in the five months I spent in China, I never came across fried rice, so my conception of it never evolved beyond the Panda Express version. Then a few weeks ago at a restaurant² in the San Gabriel Valley, I was served this bowl of fried rice:

It was a revelation! No soy sauce whatsoever. It was moist and ten times as delicious as the slop I’d been eating at Panda. The secret, as it turned out, was that the rice was dotted with tiny cubes of salted pork. That mixed with sliced scallions and tossed with oil in a wok for a couple minutes was a big draw for this restaurant, eulogized on Yelp and ordered at every table.

Shortly thereafter I accidentally bought some 塩鮭 at a Japanese supermarket. That is, salted salmon. (It’s not my fault; in English it was only labeled “Salmon”. It’s usually latinized as some variation on shioyake, shiojake, or shiozake.) At any rate, it’s intensely salty. Unable to eat it as I had originally intended, I realized that it would be the perfect ingredient for a fried rice dish inspired by my earlier experience. Hence the following recipe was born:

If you find yourself stuck writing a complicated Flash Banner, you will run into a minor inconvenience: most of the ad networks package their api up into .mxp components. You load them into Flash via the Adobe Extension Manager.

That means that if you wish to use IntelliJ IDEA or Flash Builder to edit your code, you have to put up with them complaining about missing classes and a lack of code completion. Or does it?

Oftentimes, you want to include a lot of console.log() statements while you are developing your app. Most of these will be removed before deployment, but it isn’t always convenient to remove all of them. There are useful messages that illuminate what’s happening, like log statements in AJAX responses and module initializations. If you remove them all and a bug is discovered in your production code, you’ll have to go and put them back in – that’s not staying very DRY.

Of course, you could just leave the console.log statements in the code. There are two problems with that. The first problem is Internet Explorer. In IE 8, console is only defined when the Developer Tools panel is open. (That just seems like a cruel trick; you won’t see any errors caused by missing console objects when you open the dev tools to find out why your code doesn’t work.) You can get around that by including your own console shim. One is included in HTML5 Boilerplate.

That brings us to problem #2. There is a performance cost to having the browser catching log events. Usually this won’t really make any appreciable difference, unless you have a log message in a big loop somewhere, but it’s something to be aware of.

If you have a minification step, UglifyJS will afford you a better solution.

My first and most-popular article on this blog dealt with extending jQuery UI Draggable to make it work with Metafizzy’s Isotope Plugin in Firefox. You can read it here: http://jstarrdewar.com/blog/2011/10/28/extend-jquery-draggable-to-work-with-isotope/

This is actually no longer necessary – the bug in Firefox has been fixed – but I still have been getting a lot of requests for a working example.

I’ve written another article for The Code Builders’ website. This one is a quick non-technical introduction to Node.js: what makes it unique and why you might want to use it.

http://thecodebuilders.com/javascript-and-node-js/

One of the best pieces of advice for beginning programmers is “Don’t Repeat Yourself”. Whenever you find yourself performing drudgework, it’s best to take a step back and ask yourself if you have taken the right approach. By figuring out how to make the computer do the work for you, you will improve your skills and lower your maintenance burden.

People tend to avoid doing this because they it requires putting some energy into thinking critically about their work. It always feels like it would be easier to just paste that line of code in a bunch of different places. That’s a form of laziness that will come back to haunt you later. As a programmer you’re paid to think, not to type!

I’ve written an introductory article about this idea – often referred to as “staying DRY” – as a newsletter for The Code Builders. You can read it here: http://thecodebuilders.com/dont-repeat-yourself/

By the end of the decade, products like the Oculus Rift Head-Mounted Display could breathe new life into the PC business. I say this because I see great potential in the device for a whole new kind of computing experience. I think its utility could go far beyond games: it could replace our existing screens and monitors for day-to-day computing.

When beginners first embark on an HTML project, they generally test their work by simply double-clicking the index.html file and opening it in a browser directly. You can often get quite far into a project this way, and then comes the shock: you upload to a web server, and suddenly everything is broken. Your images don’t load and your links don’t work.

This happens because links on the file system are relative to the file that tries to open them; on a web server, they are typically relative to the base URL instead.

That’s not the only problem; typically callbacks from external services won’t work, and neither will iFrames. So your social media buttons will be broken too.

The solution to this is simple. Always develop locally with a web server. Macs have Apache installed by default and it’s easy to install WAMP/MAMP/LAMP/XAMP and use that for your server. Another major benefit to this is that you can connect to your computer from mobile device and test your changes with a simple save-and-reload. It’s far more efficient than pushing to FTP every time. There’s just one problem with the built-in Apache or LAMP-stack solution:

It’s inconvenient.

On Mac OS X, you are restricted to placing all your projects in the sites folder without reconfiguring Apache, and MAMP Pro places the same restriction on you. Moreover, as you move between projects, you have to point the webroot at different folders, which tends to be just time-consuming enough that it feels like a chore to be put off. That, or you have to navigate to your project root in the browser, annoying on mobile devices. Apache takes a long time to start up as well. As a result, I still see inexperienced developers using the filesystem to test their apps, and encountering the same unexpected difficulties.

Stop doing that! There’s a better way.

I think as web developers we’re all pretty familiar with this block of code, or something like it:

1
2
3
4

<link rel="stylesheet" type="text/css" media="screen" href="css/style.css" />
<!--[if IE 8]><link rel="stylesheet" type="text/css" media="screen" href="css/ie8.css"  />< ![endif]-->
<!--[if IE 7]><link rel="stylesheet" type="text/css" media="screen" href="css/ie7.css"  />< ![endif]-->
<!--[if IE 6]><link rel="stylesheet" type="text/css" media="screen" href="css/ie6.css"  />< ![endif]-->

When I see this I get depressed. It just feels like so much work to keep all the overridden classes straight, especially with the oldIE’s terrible dev tools. Paul Irish and HTML5 Boilerplate have since popularized a technique that I greatly prefer: rather than having the overridden styles in a separate stylesheet, you can place them right below the original declaration. It requires a lot less mental overhead to keep track of your overrides this way.

Here’s what the code block above looks like in HTML5 Boilerplate:

1
2
3
4

<!--[if lt IE 7]>      <html class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]>         <html class="no-js lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]>         <html class="no-js lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js"> <!--<![endif]-->

Here’s how it’s used on this site:

1
2
3
4
5
6
7
8
9
10
11
12

.lt-ie9 body > header h1 {
  font-family: "Open Sans";
}

.lt-ie9 aside.sidebar {
  padding-left: 40px;
  width: 240px;
}

.lt-ie9 body > nav {
  padding-right: 24px;
}

You can also use this technique with JavaScript to do a lot of useful things. I’ve found a few which I’ll share with you.