Is telnet still relevant? It turns out that the answer is yes. Recently a client commissioned me to develop a telnet client for Android. He's developing a wireless barcode scanner which connects to the server using telnet. To test my app, I needed to enable telnet server on my mac. Here's how I did it:

$ sudo launchctl load -w /System/Library/LaunchDaemons/telnet.plist

And to stop the server:

$ sudo launchctl unload -w /System/Library/LaunchDaemons/telnet.plist

1. Method one involves the use of a simple snippet of code in your browser's address bar.
2. Find the location for which you would like to obtain coordinates in Google Maps.
3. Right click on your chosen location, and select "center map here."
4. Open Firebug's console in Firefox then copy and paste the snippet of javascript code below into the address bar, and hit "enter."
javascript:void(prompt('',gApplication.getMap().getCenter()));

5. This will activate a small pop-up window that will show the coordinates for the centered location in decimal format.
    

From: http://gps.about.com/od/gpsproductoverview/ht/google-maps-coordinates.htm

So, finally I got the hang of NIB files. I can now develop simple app either without the interface builder (pure code) or with interface builder (with NIB files).

I had always thought that a NIB file was always associated to a UIViewController. This was because when you create UIViewController, there is an option whether you want to create a NIB file for it or not. If you choose to create the associated NIB file, then the file owner of the NIB file will be set to the UIViewController class.

That was until I found this sample code from Apple: http://developer.apple.com/library/ios/#samplecode/Scrolling/Introduction/Intro.html#//apple_ref/doc/uid/DTS40008023

In that sample code, the class of the file owner is UIApplication. It turns out that you can actually develop your app from scratch using the interface builder only (well, almost). You connect the NIB file (the main NIB file) to your application by setting the key "main NIB file base name" in your plist file to the value of your NIB file name (without the XIB extension). Contrast this with the practice of calling [UIViewController alloc] initWithNibFile] when you create a NIB file for a UIViewController.

Just remember to always set the file owner of your NIB file!

There are times when I watched some dirty movies on Quicktime Mac or clicked on file with embarrassing name to show on Preview. Then the names of those files will be recorded by quicktime and preview, and when I click and hold on the preview icon on the tray, those embarrasing names will show up. After wading thru the Mac file system I finally found what I should delete to remove those names:

Go to /Users//Library/Preferences

In that folder, delete the file com.apple.


NB: Mac OS X Lion.

I found two concise but complete references online:
http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/MemoryMgmt/Articles/MemoryMgmt.html
http://interfacelab.com/objective-c-memory-management-for-lazy-people/
http://www.raywenderlich.com/2657/memory-management-in-objective-c-tutorial

I will summarize them here to reinforce my understanding:

1. If you do alloc + init or new (which is basically just a shortcut for alloc + init), you must subsequently call release.
2. After you call release, you should set the var name to nil. So: [someVar release], and then someVar = nil; This is considered good practice (at least by Ray Wenderlich), because sending message to a nil var does nothing, while sending message to a deallocated var causes EXC_BAD_ACCESS.
3. If you get a var from framework methods, then there's this convention:
• If the method name begins with init or copy, the object returned will have a retain count of 1, and no autorelease pending. In other words, you own that object and have to release it when you’re done.
• If the method name begins with anything else, the object returned will have a retain count of 1, and an autorelease pending. In other words, you can use the object right now, but if you want to use it later you have to retain the object.
4. More about property, here's a snapshot of The Elements sample code:
   
   // Set up the portraitWindow and content view
   UIWindow *localPortraitWindow;
   localPortraitWindow = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
   self.portraitWindow = localPortraitWindow;
   
   // the localPortraitWindow data is now retained by the application delegate
   // so we can release the local variable
   [localPortraitWindow release];
   
   Lesson: when you retain a property, you increment its ref count. So you need to release accordingly.
   
5. Do this:
   -(NSImage *)getAnImage {
   
   return [[[NSImage alloc] initWithContentsOfFile:@"/tmp/youownthis.jpg"] autorelease];
   
   }
   Instead of this:
   -(NSImage *)getAnImage {
   
   return [[NSImage alloc] initWithContentsOfFile:@"/tmp/youownthis.jpg"];
   
   }
   The caller will then have to retain the returned object, and subsequently release it.

Now, on the topic of XCode profile -> leaks tool. I made a curious discovery. I build a skeleton table view app, just a navigation controller and a root view controller. Without any string occupying any table cell. And then I ran the profiler with leaks template. I randomly clicked on the table, and I pulled the table up and release it and pull it down and release it and I did it multiple times. And it red bold lines showed up! UIKit framework is leaking memory!

Even the official The Elements sample code from Apple website is leaking memory when tested this way.

Some nifty commands that I use often on other platforms but I miss on Mac. After googling around, I found the Mac equivalents.

Showing the desktop: Cmd+Option and then click on desktop.

Taking snapshot:

• Command-Shift-3: Take a screenshot of the screen, and save it as a file on the desktop
• Command-Shift-4, then select an area: Take a screenshot of an area and save it as a file on the desktop
• Command-Shift-4, then space, then click a window: Take a screenshot of a window and save it as a file on the desktop
• Command-Control-Shift-3: Take a screenshot of the screen, and save it to the clipboard
• Command-Control-Shift-4, then select an area: Take a screenshot of an area and save it to the clipboard
• Command-Control-Shift-4, then space, then click a window: Take a screenshot of a window and save it to the clipboard 

Pre compiled binary for the famous wget Linux util:

https://techtach.s3.amazonaws.com/files/wget

I will keep this list updated.