Apple

warning: Creating default object from empty value in /home/kourge/kourge.net/modules/taxonomy/taxonomy.pages.inc on line 34.

Why Mac?

I have again been asked recently by those around me: "Why a Mac?" Despite that it was not so much of a shocking revelation when I realized that the general argument that it makes web development easier is no longer convincing anymore, I was still quite perplexed. After thinking for a few days straight, I finally nailed down the subconscious reasons why I chose a Mac in the absurd age where Apple hardware, in terms of specs, is no different than any other PC.

  1. It just works.
    This seems to go without saying, but it really is true that when I plug in the devices I bought to a Mac, it almost always works immediately. This is sometimes true for Windows, but half of the time I have to install the drivers that are included. Linux. It's getting there, but not quite. Ubuntu is doing an alarmingly good job at supporting various devices and in certain scenarios, outdoing Windows by a margin.
  2. Eye candy software and pretty hardware.
    I will not lie to myself and claim that eye candy is useless. When used sparingly, eye candy increases productivity by providing useful, intuitive visual cues and just pleasing the users in general. Linux needs lots of manual configuration to get there. The furthest Windows can get is either Aero on Windows Vista (which, I admit, is the prettiest version of Windows yet) and GDI++ on Windows XP. Customization is cool, but it does bring awkwardness when certain apps that break because they weren't written with Windows theming in mind.
  3. Sweet blend of proprietary and free software.
    Linux has a huge repertoire of free software, but there is a lack of commercial software support. Wine can alleviate this a bit, but there is a limit for Wine as to how native a Windows app can behave on Linux. Windows has the hugest amount of software available, be it commercial software, freeware, or free software, but even Cygwin can't make up its unfriendliness to various open source tools. Mac OS X, on the other hand, has lots of commercial software offerings (e.g. Adobe) and, along with its Unix / BSD heritage, makes messing with open source tools way easier in general.
  4. Viruses are out of the picture.
    Because Mac OS X does not have a huge market share, it is not an attractive platform for malware authors. This means I don't have to deal with security software and other similar headaches on a daily basis.

The fact that I have less time to reinstall Windows every now and then, lower tolerance for ugly UIs, more chances to muck around with Photoshop, and more lines in my ~/.bash_profile than your average user shows that Mac OS X is currently my ideal platform.

Building and compiling V8 on Mac OS X

Now that Google Chrome is released, the project page and repository of the V8 JavaScript engine is revealed and available for public hacking. This guide shows how to get the source of V8 and build a V8 JavaScript shell on Mac OS X Leopard.

Mini-DVI, DVI-D, DVI-I, and frustration

It has been a while ever since I have been so pissed off. By Apple.

Apple sells these Mini-DVI to DVI adapters that work with MacBooks and whatever other kinds of Apple hardware that sport Mini-DVI ports, and, thinking that now I have a DVI to VGA adapter, I bought one of those Mini-DVI to DVI adapters at Fry's in hopes of finally being able to connect my MacBook to a VGA LCD monitor.

My dazzling happiness was abruptly halted when I realized that the Mini-DVI to DVI adapter does not work with my typical DVI to VGA adapter. It didn't fit. Then I realized that it's a Mini-DVI to DVI-D adapter, and my DVI to VGA adapter is a DVI-I to VGA adapter.

Even the packaging on the adapter showed a female DVI-I connector. Misleading enough, huh? Now I have to return the damn thing and buy an Apple Mini-DVI to VGA adapter, something Fry's doesn't have in stock.

A Better main.py for Python-Cocoa Apps

Although Apple describes both Python and Ruby as "first-class citizens" under a Leopard development environment, I feel that Apple meant it more programmatically than documentationally. Sure, both PyObjC and RubyCocoa are mature bridges, but both lack documentation from Apple (you have to rely on the community for gotchas) and RubyCocoa seems to receive more attention than PyObjC when it comes to tutorials for starters.

Moreover, the starting templates for Cocoa-Python apps and Cocoa-Ruby apps are not created equal. For example, while Apple encourages the scripts to be put into Resources, only a Cocoa-Ruby bootstrap file generated by Xcode (called main.rb) would automatically require them. A Cocoa-Python bootstrap file generated by Xcode (called main.py) would not import them, and this problem would manifest itself when you first attempt to do bindings in Interface Builder.

First, observe a generated main.rb:

iPod Video Prototype


This is a iPod video prototype by smash.
It's facinating, and I hope Apple can do this.

Syndicate content