Focus Follow Mouse and other *nix wonders

Back in the days at the UCSD Center for fMRI, I had the opportunity to get my hands dirty with a few types of *nix systems that most people have never heard of, much less use. My boss was also pretty keen on very specific configurations that he insisted his employees put on their computers for those infrequent times he’d be on our workstations. For the record, they were:

  • Always use Emacs
  • Make sure that key to the left of the “A” key was your control key, map it to control if it wasn’t already
  • Make sure focus follows mouse set to enabled.
These are no big deal on various *nix systems, but to most Mac people, completely novel ideas

Caps Lock to Ctrl

Briefly, that control key thing. I hated it at first. Then I started using Emacs quite a bit and it made sense. It much better on your poor little pinky finger to press down without having to contort your hand. Old Solaris systems actually made that the hardware control key. Any other keyboard has to be remapped via software so “caps lock” wasn’t really caps lock. I highly recommend it, but people are soooo confused when they’re using my machine and the caps lock doesn’t work. Or control doesn’t work and makes all their text in capitals.

Focus Follows Mouse

I don’t know why I forget to do this one. The idea is that window focus (the act of becoming active) can be controlled by simply moving your mouse over the window rather than having to physically click on it and bring the window to the foreground. FFM is particularly handy because the window isn’t brought to the foreground, but is still takes input from the keyboard. I use this most often when working with the terminal – where often I only care most about the last several lines of output, and not all the clutter of text and OS UI above it. It leaves the main window that might be referencing right where it is.

On your Mac, open Terminal, and do this:

Quit terminal. Re-open, and open a second terminal window (not tab). Hover your mouse over one of them and start typing. Now, hover your mouse over the other one and type. See what happens? If everything worked properly, the typing occurs in the window your mouse is hovered over. The only caveat is that it acts a little funny if the terminal is in the background to another app, but it still works. I found that sometimes you have to hover out & over another app then back to the other term window. Not a huge deal, I guess. Try it out. If you don’t like it, change the above command from … YES to … NO

It’s a time saver and convenience – especially useful on constrained displays. You might just fall in love. Now if only the whole OS would let me do that.


Quiet NSLog() in Release Builds

On the heels of the previous post, here’s a little snippit I picked up from Marek Bell to quiet NSLog() output in release builds.

Add this to your {MyApp}-prefix.pch file

#ifndef __OPTIMIZE__
#    define NSLog(…) NSLog(__VA_ARGS__)
#    define NSLog(…) {}

The reasoning behind using __OPTIMIZE__ is that it’s set only on release builds of your app, not in debug versions. It’s very simple and allows you to use NSLog() instead of having to come up with your own version.

Quiet the Console – PhoneGap / iOS

I have a confession – I’m a console logging junkie. I just like to see what’s going on. While that may be great for development, at some point you’ll have to quiet the logging down for production. Really – doing enough logging will slow everything down each time you’ve inserted a console.log() into your code.

Silencing the output to XCode’s debugging console wasn’t immediately obvious. Overriding console.log() in JS by setting it to an empty function worked in the browser for development, but as soon as I loaded the app onto the actual simulator, we were back to square one. Enter the PhoneGap DebugConsole prototype. Override it.

Insert this anywhere after your phonegap.js file loads. It’ll keep things quiet as long as DEBUG = true…

There you have it

If your site goes down, does it make a noise?

I don’t go to my brochure site very often. It’s there for the curious client who needs the reassurance that I know what I’m doing. Considering I haven’t made any significant changes in quite some time, I had no reason to go back, but apparently I should have. At some point my .htaccess file went missing, which was pretty good to foil even the best attempts to view pages other than the home page. I have two questions: 1) How long were all these links broken – that I didn’t even notice it, and 2) Nobody said anything – why?

Regardless, everything is fixed now. Typing my name into Google or Bing will fetch either this blog or the brochure site in the top 2-3 positions. If you haven’t been yet, check out mistercameron.com .

Cue deriding comments.

Cocoa Zombies – NSZombie

Found this great little debugging tip over at MarkJ.net. The short of it: You can use NSZombie tracking to debug memory crashes in your code. Great find – this whole time I was kinda under the impression that there was a lot of educated guessing involved based on where your fingers last touched code. I’m so naïve.

Compiling PHP5.3.x on Snow Leopard

I like to wait quite a while before upgrading Mac OS X to the newest release because, for me, it often requires quite a bit of work. I had hopes that Snow Leopard would be different because Apple finally installed current versions of the whole LAMP stack, but I wanted to wait regardless… just in case.

Why the wait?

I do dev work that require custom libraries in my PHP installation – vanilla PHP from Apple doesn’t have what I need. To do that I’ve relied pretty heavily on the Fink package manager. Too many times I’ve upgraded to the new OS and some of the libraries haven’t yet been updated to work properly on the new system. Usually after a couple months either the libraries get fixed or Google will give me enough results and clues that I can fix the issue myself.

First things first

I went ahead and compiled  Apache from scratch. It’s easy enough and you’ll need the 64bit support for PHP. MySQL was much easier – download the intel x86_64 installer for Mac OS X 10.5 (yes, even for Snow Leopard). Side note – MySQL finally got around to recompiling the System Prefs Pane to 64bit.

Installing Fink

I’ll save you some time. First, compile fink from source. When you set up the app, do the 64bit-only packages (you’ll know – it’ll prompt you to pick 32bit or 64bit). I tried the 64bit and PHP wouldn’t install. You can always do a separate mixed architecture install later (see here for details on mixed fink arch installs).

Compiling PHP (with GD)

I need GD. This tutorial did the trick – once I had figured out the 64bit fink issue(s). Follow it and the companion standard PHP / Snow Leopard compile tutorial, linked in that article. Take a look at my compile flags, if you’re interested:
CFLAGS="-arch x86_64"
CXXFLAGS="-arch x86_64"

./configure --prefix=/Library/PHP5

Two things: First, my PHP is installed into /Library/PHP5/. Second, my Apache is located at /Library/Apache2/. Nothin to it. Too bad it took me all day to figure this out. At least now I can move on with my life!

Installing PEAR Libraries Locally

[I started this post quite a while ago and forgot about it. Here it is finished. Hopefully you find something useful here]

I’ve had a few projects already where I could really use some PEAR libraries but not sufficient enough access to the server so I could install them in the system-wide PEAR include directory. I went searching for an easy to manage way to package specific PEAR libs along with apps I was building and installing for clients – something that would work without access to system-wide PHP/PEAR setup, and even in rare cases where I couldn’t write outside the document root.

First place to at least read through is the documentation. I’m going to assume you already know the basics of PEAR.

This summary will discuss the FTP method, as it seems applicable to more situations. For me – I keep my sites under version control so I need to be able to perform a local install that I can commit to the repository and either export or update on my various server environments.

* Terminal or command-line (CLI)
* CLI version of PHP
* CLI version of PEAR

Steps (code follows)

  1. Create a directory where you want the PEAR libs installed. Note: PEAR will create a directory named pear in the location you specify.
  2. CD into that directory.
  3. Create your config file for your local environment (probably won’t be needed on external servers unless you plan on installing from there, in which case you should create a separate config file for each site).
  4. Install and update packages.
  5. Update your app’s include paths.

The Code:

  1. Create your config file in the PEAR directory from step 1, above. Absolute paths, absolutely!

    The first path is the location where you want the files. The second path is the location where the pearrc file is located. I usually put the PEAR files in an includes directory within the site’s document root, just in case a host or client I’m dealing with doesn’t have write access in higher-level directories. It’s best to keep the pearrc file outside of the webroot, or deny access to the file via Apache’s Allow/Deny directives.
  2. To run PEAR commands on your local install, you will need to use the following format

    (otherwise you’re likely working on system-wide changes – doesn’t help you when it’s time to deploy to the server). An example,
    %> pear -c /path/to/setup/pearrc install File_CSV_DataSource
  3. Set your app’s includes path to search in the PEAR directory:

    Change as needed.

That should do it. It’s a basic introduction, but if you already know how to use PEAR, you’re already 95% of the way there.


Using Pinch Media Analytics in PhoneGap

Getting close to finishing up an app for a client in the coming weeks, my business partner and I decided it would be a good idea to include some analytics code so we could track how people are using our application. We ended up using Pinch Media’s Analytics to do our tracking. It came down to this: their code is REALLY easy to implement, and they provide us with just enough information to satisfy our curiosity. I think one of the biggest draws is that it records information regardless of the user’s online status – meaning offline app usage information is stored to a small database and then uploaded once the user reconnects. Had we used a web-based solution, which would have been natural given the nature of PhoneGap (the underpinning of our application) being UIWebView, we would have missed out on some details without considerable work-arounds to cache data as Pinch Analytics does.

Because PhoneGap is essentially a single view application that displays web pages, you are a bit limited with the extent that you can integrate Pinch Analytics out of the box… unless you use javascript callbacks to Objective-C within PhoneGap. That’s not the point of this post. The point is that you just need to follow Pinch’s instructions and you will have analytics data reported back to you within a few hours.

Moving forward, I’m likely to investigate some of the finer points of creating my own PhoneGap callback functions so I can embed Pinch Analytics Beacon methods, which are nice little ways to record information about discreet actions taken within your app – recording leader board views, for example.

PhoneGap Up To Speed

I recently ran across some major performance problems with a jQTouch app running in PhoneGap. Some of the symptoms included long pauses on touch events, non-responsiveness, and laggy transitions.

Brian LeRoux (Nitobi/PhoneGap), Jesse McFayden (Nitobi/PhoneGap), and David Kaneda (jQTouch) were the stars looking into this issue. Ends up Jesse found where the Accelerometer was taking a 40Hz sample rate and sending the data to a callback. The solution is to just disable Accelerometer use – either in the plist or, as I did, comment-out all the accelerometer bits. Likewise, I removed location functionality, as this app in particular doesn’t need it.

You can read Jesse McFayden’s post here. And if you’ll excuse me, I have an app to finish…

ReadOnly Form Elements

Here’s a quick note for the frustrated:
When setting the readonly parameter on a form element via javascript, make sure you use a capital “O” as follows:
elem = document.getElementById('myInputElement');
elem.readOnly = true;

Why it took me so long to find that out, I have no idea why. Most forums threads by others seem to think the disabled parameter is the best way to go. Actually, the sheer number of people suggesting that makes me think it’s a bad idea – just following the crowd. This is why readOnly might be the right option: You’re still allowed to post the form value, but the user isn’t able to change what’s inside the box. When using disabled *nothing* gets posted from that element. So if all you want to do is prevent a user from editing the value of a form element, use readOnly. If you don’t want that value posted, then go ahead and use disabled.