Yes, google thought it would be just a great idea to make their website the only one of the frickin internet that takes over our arrow keys and makes them much less useful.

Anyway, this guy ZimZat hated it too, so he made a Chrome extension called Arrow Key Guard to fix the problem.

If you’re not using Chrome, I don’t care, you have bigger problems anyway and you probably don’t use your keyboard for anything but typing shit about your cat into MS Powerpoint rainbow colored word-art objects anyway.

Anyway, it got all the way 100% through Step 1: Gathering information about your iTunes library. and then stayed there for hours. Finally I noticed that a few songs in my library add a little cloud icon with a line through it. Closer inspection showed that those songs were DRM’d and were purchased on my ex-girlfriend’s iTunes account, which I am no longer authorized to use. Deleting, or removing them from the library (if you can foresee a need for DRM’d files you can’t open) will fix the problem.

The purpose of this class is to organize your Output window into something much more usable. I wrote it in out typical relaxed Primal Screen style— very human readable, very easy to figure out what function does what.

First, import the class:

import com.primalscreen.utils.Mic;

Then say something into the Mic:

Mic.say("This is a test", this);

And you should see this in your output window:

myClass says:  This is a test

The Mic class uses that reference to “this” to grab the name of the class that is “talking” to it, so you can see where the message is coming from, then it adds spaces where needed to line everything up. When you say things from a few different classes, you see the power in this:

       myClass says:  This is a test
  SoundManager says:  Playing sound "1.mp3"
       myModel says:  The button was pushed
  myController says:  Message recieved!
        myView says:  All your base are belong to us!

That’s a lot of “says: ” isn’t it? Well that’s because we’re being calm, and well mannered. We’re saying things that ought to be said. Important things should be yelled!

Mic.yell("This must be important!", this);

When the app starts to get big, with lots of traces, and you just want the big picture, turn off the normal speech, so you just hear the important stuff that you yelled (or screamed, we’ll get to that):

Mic.ignoreSpeech();

Some things we don’t care about much, but on the off chance that we’re tearing our hair out in über-debug mode, and want every last bit of data, we should still whisper it:

Mic.whisper("Nobody cares about what I'm saying right now", this);

Or if it’s super-duper important, we want to SCREAM it, and we can:

Mic.scream("Something crazy is happening!", this);

In the hierarchy it goes whisper, say, yell, scream, and when you ignore a level, you ignore the ones below it too. What about ignoring a class:

Mic.ignore(this);
Mic.ignore(SoundManager);
// this is a reference to the SoundManager class object
Mic.ignore("SoundManager");
// this works too, and we don't need an actual object reference
Mic.silence(this); // an alias for ignore

Mic.unignore(this);
Mic.unsilence(this); // an alias for unignore

What about the opposite, when we want to focus on the output of one particular class?

Mic.spotlight(this);
Mic.spotlight(SoundManager); // class ref
Mic.spotlight("SoundManager"); // class name as string
Mic.focus(this); // an alias for spotlight

Mic.unspotlight();
Mic.unfocus(this); // an alias for unspotlight

And I didn’t cover it above, but here are the other ignore functions:

Mic.ignoreWhispers();
Mic.ignoreSpeech();
Mic.ignoreSays(); // a grammatically incorrect alias
Mic.ignoreYells();
Mic.ignoreScreams();
Mic.ignoreAll(); // alias for ignore screams

Hope you like it!

Even better than just adding this code to all the elements you want sped up…

-webkit-transform: translateZ(0);

Use -webkit-transform: translate3d() to do all your animations, instead of left, right, top, bottom, margin, or padding properties.

-webkit-transform: translate3d(50%, 0, 0);

Note that the values in the translate3d parentheses are x, y, z coordinates. Since -webkit-transform uses (yet another*) coordinate system, leaving a value as 0 will leave it unchanged (unless you used -webkit-transform somewhere else already).

Basically, the first example tells the browser to use the GPU to animate the element, which helps a fair bit, but the second code snippet uses the new CSS3 transform algorithms, which are WAY more efficient. The beautiful thing about it is all the modern smart phones use webkit, and therefore support -webkit-transform. My iPhone app now scrolls “like butter“!

*“Yet another” meaning you can move things relative to their point of origin with left/top, margin-left/margin-top, and now -webkit-transform;

You’re using LiveView Screencaster to send your designs to you phone to see how they’ll look at actual size, in your hand.

You’re using these media queries to make stylesheets for portrait and landscape on iPhone/iPod and iPad.

@media screen and (orientation:landscape) {/*landscape mode*/}
@media screen and (device-width: 768px) {/*iPad*/}
@media screen and (device-width: 768px) and (orientation:landscape){
	/*iPad, in landscape mode*/}

But you start to notice that your pixel perfect design gets scaled up every time you rotate the device to landscape. It zooms about 1.25x! The fix is in your meta tags, specifically the viewport one:

Some people will say, “why not just use ‘user-scalable=false’,” and the answer is that the user isn’t the only thing scaling the viewport. The rotation event does it too. That’s what we’re trying to prevent.

Primal Screen website
(100% of code and 75% of design by yours truly).

Oh, and I’ll never write another website in that bloated carcass of a useable PHP framework: Zend Framework. My advice: CodeIgniter.

Unfortunately, CSS transitions can be a little slow, a little choppy, even on iPhone 4 and the faster Android based phones. The problem is that, by default, webkit doesn’t involve the GPU unless you’re doing 3D transforms. With desktop horsepower, thats fine. On a mobile device, that GPU could really help.

So how do you force webkit to share the processing load with the GPU?

Apply this style to the element you’re animating:

-webkit-transform: translateZ(0);

Simple, but effective.

I’m writing an iPhone app right now using PhoneGap and jQuery Mobile on the phone, and node.js and socket.io on an Amazon EC2 server, and I hit a wall when I started using Socket.io. The problem is that the documentation is sparse, disorganized, and hard to find. In addition to that, there are dozens of blog posts and community members who’ll teach you how to do things in older versions of socket, but the API has changed, so you just end up with undefined errors.

My exact problem was with sending messages to individual clients.

First, you need the client’s socket ID, so have the user “check in” when they connect, and have the server store their socket ID with whatever identifier we’ll be using to refer to users (in my case, phone number).

// on the server
var users = {};
io.sockets.on('connection', function (socket) {
	socket.emit('who are you');
	socket.on('check in', function (incoming) {
		users[incoming.phonenumber] = socket.id;
	});
});

// on the client
socket.on('who are you', function (incoming) {
	socket.emit('check in', {phonenumber: savedphonenumber});
});

To recap: The server is listening for connections. When a client connects, the server emits the custom message “who are you”. The client hears it and responds with it’s identifier (I’m using their phone number, which I verify and store earlier in the process). The server then stores the client’s socket ID in a users object, with their identifier as the key, and the socket ID as the value.

From then on, it’s a simple case of grabbing the user’s socket ID from the user’s table when you need to send them a message, and sending it like this:

var socketid = users[clientphonenumber];
io.sockets.socket(socketid).emit('for your eyes only');

One thing to consider is what happens to that users object if you have thousands of users. It’ll get pretty bloated, pretty quickly. You need to figure out a strategy for removing users from the users object if they disconnect AND if you don’t hear from them in a while (in case the disconnect event doesn’t fire).

img {
	z-index: 10000000; /* ignored */
}

img {
	position: relative;
	z-index: 10000000; /* works! */
}

$(".fadeThisGuy").fadeIn();

… type looks like crap all the way through the animation, and stays that way after.

The reason for this is a bad implementation of “filters” in IE. “What are filters” you ask? Well while the rest of the web was being standardized to make our lives easier, Microsoft was ignoring the new standards and making up their own, worse looking and harder to write versions. jQuery hides all that from us by turning your fadeIn() into the appropriate filter code in IE, or opacity code in everything else.

There are 3 fixes.
1) Avoid the problem. That means using a non-typekit font, or using an image of the type (which means it won’t be selectable, and google can’t see it).

2) Partial fix: At the end of your fadeIn() you can tell IE to drop all filters from the element. This isn’t great because it means that the type will still look like crap all the way through the animation, and then snap to normal looking (which is still not great in IE) at the end. Code for that below:

$(".fadeThisGuy").fadeIn(400, function() {
	$(this).css('filter', "");
});

3) “Graceful degradation”. The buzzword “graceful degradation,” refers to the act of checking the capabilities of your visitor’s browser, and scaling your awesomeness back to fit what their browser can do. They should still get the same website, just without the bells and whistles their browser can’t handle.

In this case, we’re checking for IE, and whether it’s version is < 9.

if ($.browser.msie && parseInt($.browser.version) < 9) {
	// dumb it down for old IE 6, 7, and 8
} else {
	// regular awesomeness for people who know how to use Windows Update
}

As an alternative to a fadeIn() and fadeOut() I’d suggest either a simple show() and hide(), or any of the other jQuery Effects that don’t have to do with opacity/filters. You can find a list of jQuery effects here in the effects section.