I have moved my blog to Wordpress at theunixgeek.wordpress.com. I will still be checking back periodically on this one as well, though. 19 April 2009


Merging Mkdir and Cd | 280 Slides Interview | I Switched to KDE 4

clickable portals

Friday, September 26, 2008

An Introduction to Key-Value Coding in Cocoa

Key-value coding is a powerful technology available in Cocoa, but it may be difficult for beginners to understand. But without key-value coding, you couldn't easily make applications scriptable or use bindings in your applications. Also, using key-value coding can significantly reduce how much code you write by eliminating accessor methods. Using it may even increase your code's security by not needing to access instance variables directly. I believe that's enough to be convinced to use this technology, but how should one go about doing so?

First off, we need to learn some vocabulary:

  • property - an object value (specifically attributes, to-one relationships, and to-many relationships) that can be accessed by KVC.
  • attribute - a property that is represented as a simple value. Examples include immutable (non-editable) objects, numbers, strings, booleans, etc.
  • to-one relationship - a property in which an object has properties of its own
  • to-many relationship - a property that consists of a collection of related objects, such as an NSArray
  • key - a string that identifies a specific property of an object. 
In case you don't know how to declare properties in an Objective-C class, here's a sample of a basic AppleFruit class:

@interface AppleFruit : NSObject
  NSNumber *price;
@property(copy, readwrite) NSNumber *price;

@implementation AppleFruit
@synthesize price;

Of course, you could get a lot fancier with properties, but there's the bare basics of it.

Now, let's get further acquainted with keys. Keys typically correspond to the name of an accessor method or an instance variable in an object. Quoting the documentation,
Keys must use ASCII encoding, begin with a lowercase letter, and may not contain whitespace.
If you wanted to get the value of a key, you would simply use the valueForKey: method. For example:
[appleFruit setValue:23 forKey:price];
[priceTextField setStringValue:[appleFruit valueForKey:price]];

could be used in another class to set and get the price value of the appleFruit object, respectively.

Here's what the class could look like if key-value coding weren't implemented in it:

@interface AppleFruit : NSObject
   NSNumber *price;
- (NSNumber *)returnPrice;
- (void)setPrice:(NSNumber *)newPrice;

@implementation AppleFruit

- (NSNumber *)returnPrice
   return price;

- (void)setPrice:(NSNumber *)newPrice
   price = newPrice;


See how much code was spared? Good luck with implementing KVC in your applications!

Note: this is a summarized beginner-friendly version of the first three sections of the Key-Value Coding Programming Guide available through Apple's documentation. Bits were also taken from the Design Guidelines and The Objective-C 2.0 Programming Language.

HTML: The Cross-Platform Solution

Trying to write a cross-platform application today can be done in either of two ways: write a separate implementation of the app on each platform using the platform's native API or write the app in a specialized cross-platform framework. Obviously, the latter is more preferable. While Qt is the API of choice for most cases today, but for those who want to write cross-platform proprietary applications without paying a fortune, there's another unexplored alternative: HTML.

Sure, HTML is, at its basic, the only choice for web development, but it can easily be applied to desktop development. Here, I'll show a Cocoa example, but the idea can also be applied in WPF and GTK+.

Note: you should be able to create some basic applications in Cocoa in order to understand what I'm talking about here.

Create a new project and add the WebKit framework to it. Add a file.html file with the desired HTML in the file. Add a Controller class (or, as some prefer it, AppController) and make an instance of WebView called view. Don't forget to import WebKit/WebKit.h into the class! Open up the MainMenu.xib and drag in a web view. Add an NSObject and, in the inspector, make its class be Controller (or AppController). Connect the Controller to the Web View as view and save it. Add the following code to the Controller in the awakeFromNib method and run your app.

NSString* file = [[NSBundle mainBundle] pathForResource:@"hello" ofType:@"html"];
NSURLRequest * request = [NSURLRequest requestWithURL:[NSURL fileURLWithPath:file]];
[[view mainFrame] loadRequest:request];

Update (8 March 2009): Use the setDrawsBackground:NO method to have the page's background be transparent (unless you specified it via HTML or CSS, that is).

Change the code as needed. Good luck!

Thanks to Pieter de Bie for the code.

Thursday, September 18, 2008

Google Chrome Micro-Review

I downloaded Google Chrome and installed it on Windows Vista Ultimate last night, and here I some things I really liked about the new browser:

  • The preferences window is super-clean, super-easy to follow. Overall, it's a very good implementation.

  • Gmail is sufficiently faster (for obvious reasons)

  • There is no status bar, but when you hover over a link it appears in a little unintrusive blue pop-up at the bottom.

  • It's really interesting how Chrome marks download progress - instead of using a horizontal bar, they use a sliced circle. It's really interesting. Oh, and there's no download window - the progress is kept at the bottom, but you can open a download tab if needed.

Thursday, September 11, 2008

Ubuntu 9.04 Jaunty Jackalope

It was recently announced by Mark Shuttleworth that Ubuntu 9.04 will be codenamed Jaunty Jackalope. I just wanted to summarize the main goals in the next version of Ubuntu:
  • Ubuntu on over a million devices
  • Faster boot time
  • Integrate web applications with the desktop
More is being planned and more ideas will be shared come the Developer Summit.
Just to note: the jackalope isn't a real animal....

Tuesday, September 9, 2008

Snow Leopard will be Darker: More Hints

I've previously published two posts with sources and reasons as to why it seems that OS X Snow Leopard will have a darker UI:

Now, with iTunes 8 being released a few hours ago, I have more hints supporting the idea that Snow Leopard will be dark:
  • As I've posted some times before, Apple keeps a consistent user interface among their applications, being web, desktop, or even iDevices.
  • iTunes has a few times back predicted the future of Apple interfaces (darker toolbar, non-Platinum look, etc).
  • In iTunes 8, (only) in the Grid View, the scroll bars are darker. Sure, the scroll bars in iTunes have been non-Aqua for a while now, but this time around it's even darker. Also, the Grid View sub-toolbar has the same look as the MobileMe toolbar, meaning Apple's beginning to merge the interfaces....
I'm going to continue supporting the idea and hunting down proof for it. In the meanwhile, here are some screenshots from the Grid View:

Sunday, September 7, 2008

USB as an Anti-Piracy Measure?

After a bit of pondering, I found out USB could easily be used by companies as an anti-piracy measure. Here's why I think it would work:

  1. Today the industry lives off of DVD. DVDs get scratched easily. USB drives... not so much
  2. Companies are already used to hiding information on USB products (anybody say iPod?)
  3. More than just a serial number for anti-piracy protection: have a hidden file on the drive that counts how many times a file was accessed (such as a setup program). This isn't possible with DVDs.
  4. It's not as easy to copy the plastic of the USB drive as it is to copy a DVD label
  5. More environmentally-friendly: smaller packages since USB drives are obviously not as big as DVDs. For example, take a look at Vista's box... now imagine that wrapped up in a USB drive... much smaller!
If anyone has any other ideas or opinions, feel free to leave a comment!

C vs Python: Speed

Python is a very popular interpreted scripting language. C is a very popular compiled language. Due to its compiled nature, C is generally faster than Python, but is lower-level, making Python programming quicker and easier than C programming.

The questions here are whether or not the extra time taken to run a Python program (without input) will be less cost-effective than its C equivalent and whether runtime time is more important than programming time.

Note: due to technical difficulties, I have placed parentheses around some symbols or removed some tabs from the Python examples

The Systems Program
I decided to make a simple program that resolves the following system of equations:

{ x + y = 14
{ x^2 + y^2 = 100

I quickly wrote the program in Python and found the answers. Then I translated the same program into C. I knew the same program in C would be relatively longer than the same written in Python, but that's not what I was looking for. But before we get there, here are my results:

x = 1
while x <= 14:
y = 14 - x
print str(x) + "|" + str(y)
if x**2 + y**2 == 100:
print "match"
x = x + 1

#include (<)stdio.h(>)

int main()
int x, y, t;

for (x = 1; x <= 14; x++) {
y = 14 - x;
printf("%d|%d\n", x, y);
if ((x*x) + (y*y) == 100)
return 0;

Now, I've always heard that C was always one of fastest languages out there. Running both programs from the terminal, I didn't recognize any difference between the Python program and the C program, so I fired up the terminal in Ubuntu and typed:

time ./a.out
(The time command, followed by the normal command that could be typed without the "time" prefix, runs the command and times it - here, it is obviously the C program that's being tested) I got 0.001 seconds real time, 0 for the user time, and 0 for the system time. Now, time to test the Python version!

time python system.py
The figures got a bit scary here: 0.017 seconds for the real time, 0.012 seconds for the user time, and 0.004 seconds for the system time.

Sure, the difference for the real time is only sixteen thousandths of a second, but it can be a significant difference for larger systems that need to perform multiple calculations for long periods of time.

The Million Program
I decided to take this idea into hand and wrote yet another program that prints all integers between 0 to 1,000,000 including 0, which, of course, is not exactly of the same scale as the aforementioned possibility, but gives the computer a bit more to print out.

i = 0
while i (<) 1000000 print i
i = i + 1

#include (<)stdio.h(>)

int main ()
int i;
for (i = 0; i <>
printf ("%d\n", i);
return 0;

now, time to test out the programs!

real 0m24.625s
user 0m0.652s
sys 0m2.240s

real 0m29.805s
user 0m1.984s
sys 0m1.812s

I have to admit each language has its strengths and weaknesesses, but from these results, I only want to use Python for quick things like the systems program shown or for prototyping C programs, and C for programs where the time taken to process information matters more.

Either way, goals may be different for different people or different projects - what's your opinion?

After testing and retesting various times, I have found that at times the programs can be faster or slower depending on what else the computer was doing (on my machine, the more processes were being handled, the faster the programs ran, oddly enough).