CodeKit

CodeKit automatically compiles Less, Sass, Stylus & CoffeeScript files. It effortlessly combines, minifies and error-checks Javascript. It even optimizes images, auto-reloads your browser and lets you use the same files across many projects. And that's just the first paragraph.

http://incident57.com/codekit

Mac OSX Lion and RMagick

Error after update:
...
/Users/xxx/.rvm/gems/ruby-1.9.2-p290/gems/rmagick-2.13.1/lib/rmagick.rb:11:in `require': dlopen(/Users/xxx/.rvm/gems/ruby-1.9.2-p290/gems/rmagick-2.13.1/lib/RMagick2.bundle, 9): Library not loaded: /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib (LoadError)
...
Solution:
Recompile all your gems: gem pristine --all
dydl errors are commonly associated with database drivers/bindings

CUPS on Mac OSX

CUPS is the standards-based, open source printing system developed by Apple Inc. for Mac OS^® X and other UNIX^®-like operating systems.

http://localhost:631/

Insecure Startup Item disabled

“/Library/StartupItems/MySQLCOM” has not been started because it does not have the proper security settings.

Solution:
sudo chown -R root:wheel /Library/StartupItems/MySQLCOM

http://discussions.apple.com/thread.jspa?threadID=2644088&tstart=0&messageID=12781385

Uninstalling MySQL on Mac OS X Leopard

To uninstall MySQL and completely remove it (including all databases) from your Mac do the following:

• Use mysqldump to backup your databases to text files!
• Stop the database server
• sudo rm /usr/local/mysql
• sudo rm -rf /usr/local/mysql*
• sudo rm -rf /Library/StartupItems/MySQLCOM
• sudo rm -rf /Library/PreferencePanes/My*
• edit /etc/hostconfig and remove the line MYSQLCOM=-YES-
• rm -rf ~/Library/PreferencePanes/My*
• sudo rm -rf /Library/Receipts/mysql*
• sudo rm -rf /Library/Receipts/MySQL*

The last two lines are particularly important as otherwise, you can't install an older version of MySQL even though you think that you've completely deleted the newer version!

http://akrabat.com/computing/uninstalling-mysql-on-mac-os-x-leopard/

Save Precious Debugging Time and Boost Application Performance

gDEBugger is an advanced OpenGL, OpenGL ES and OpenCL Debugger, Profiler and Memory Analyzer. gDEBugger does what no other tool can - lets you trace application activity on top of the OpenGL, OpenGL ES and OpenCL APIs and see what is happening within the system implementation.
OpenGL debugger Helps you optimize OpenGL, OpenGL ES and OpenCL applications performance.

Saves you the time required for locating "hard to find" OpenGL, OpenGL ES and OpenCL related bugs.
Helps you improve application quality and robustness.

gDEBugger helps you improve application performance and quality, reduce debugging and profiling time, shorten "time to market", deploy on multiple platforms, conform with future OpenGL versions, optimize memory consumption and much more.

http://www.gremedy.com/

Reset a user's password in single user mode

We needed to reset the password on a Leopard system, but we didn't have the OS X install DVD available. 

1. Boot into single user mode (press Command-S at power on)
2. Type fsck -fy
3. Type mount -uw /
4. Type launchctl load /System/Library/LaunchDaemons/com.apple.DirectoryServices.plist
5. Type dscl . -passwd /Users/username password, replacing username with the targeted user and password with the desired password.
6. Reboot

This allows you to reset the password in single user mode without booting from the install media. 

Completely disable single user mode

A very simply way to disable single-user mode is to edit /etc/rc.boot (as root or with sudo) and in the section that prints "file system mounted read-only", simply add a line that says reboot Now, anytime the computer is booted in single-user mode, it simply reboots itself. 
This is totally non-bypassable because Apple disables any usable keys in the begining of the rc files. 

Change Mac admin password without the disk

Creating a new Admin on Mac Os X: 
Here's how to reset your OS X password without an OS X CD. 
the Working solution for me was to create a new admin 
you can create new admin like this by deleting a specific file. 

You need to enter terminal and create a new admin account: 

1. Reboot 
2. Hold apple key + s key down after you hear the chime. (command + s on newer Macs) 
3. When you get text prompt enter in these terminal commands to create a brand new admin account (hitting return after each line): 

mount -uw / 
rm /var/db/.AppleSetupDone 
shutdown -h now 

4. After rebooting you should have a brand new admin account. When you login as the new admin you can simply delete the old one and your good to go again! 

Apple stores wont reset it for you. Computer shops may charge you $50 to $200 trying to reinstall the Mac and failing at end.


http://en.kioskea.net/forum/affich-73393-change-mac-admin-password-without-the-disk

The future of notebooks: Ars reviews the 11" MacBook Air

We did find (quite by accident) that Apple may have more reasons behind not installing Flash by default other than the stated reason of ensuring that users always have the most up-to-date version. Having Flash installed can cut battery runtime considerably—as much as 33 percent in our testing. With a handful of websites loaded in Safari, Flash-based ads kept the CPU running far more than seemed necessary, and the best time I recorded with Flash installed was just 4 hours. After deleting Flash, however, the MacBook Air ran for 6:02—with the exact same set of websites reloaded in Safari, and with static ads replacing the CPU-sucking Flash versions.

Apple was able to achieve 5+ hours of runtime on just 4500mAh (previous MacBook Air models had roughly 5100mAh batteries, yet were only rated for the same 5 hours) in a few ways. The Air's logic board is tiny, minimized as much as possible to make room for the six Li-ion cells stowed underneath the keyboard and trackpad. The combination of a ULV Core 2 Duo processor with a TDP of 10 watts and an efficient NVIDIA 320M also sips juice from the battery at a slower rate than previous generation MacBook Airs.

The constituent parts of the 11" MacBook Air consist mostly of battery.

iFixit

Your use may differ from our own, but if you stick to mainly light Web surfing, e-mail, and word processing, you can get nearly a full workday from a fully charged 11" MacBook Air. If you play lots of video, games, or run CPU-intensive tasks like video encoding, expect to have to find a power outlet well within four hours.

For those trying to decide if an 11" model will cut it for mobile needs, we feel like battery life will likely be the deciding factor. If you're hoping for something that can run a full day without charging, the 13" model will likely be the better choice. The larger size is mostly taken up by a larger capacity battery, which Apple says is good for two hours more runtime. We haven't yet had a chance to evaluate a 13" MacBook Air (you can be sure we'll post the results if we do), but in our experience with the 11" version we feel confident that it should offer most Mac users a full day of use in the most minimal package.

(For comparison, the 13" MacBook Air uses four larger Li-ion cells totaling 6500mAh, though it also has a higher resolution, larger screen, and its CPU is rated at 17W TDP.)

In addition to raw runtime, though, the new MacBook Airs boast an added benefit of "up to 30 days of standby time." "Standby" is more or less equivalent to sleep, but because of the MacBook Air's architecture it works more like hitting the standby button on an iPad.

We obviously couldn't test Apple's claim in just over a week, but we did make an attempt to characterize the power drain while in standby. We charged the battery up to full, closed the lid, disconnected the power, and left it sitting for 14 hours overnight. That ran down the battery 108mAh, a little more than two percent of the max 4640mAh capacity reported by System Profiler. By our calculations, and assuming the power drain is linear, that is equivalent to about 25 days of standby time—certainly within reach of Apple's stated 30 days.

Finally, we have to note that we experienced two kernel panics during our battery testing. In both cases, it appears as if the kernel panic was triggered by putting the machine into standby mode when the battery was close to running out. Both times the machine appeared unresponsive after opening, and the display wouldn't come on. Pressing the power button to boot the machine didn't work; instead, we had to hold down the power button to power the machine off first, and then power it back on (this is a case where some sort of independent battery indicator would have helped figure out what was happening).

We discussed the issue with Apple, and provided them with crash logs, though at press time the company was unable to determine the exact cause of the problem. To our knowledge, no other reviewers have noted similar issues, and Apple said that our report was the first to detail such a problem. However, Cult of Mac noted over the weekend that at least one staffer has experienced kernel panics with a new MacBook Air. Some users have also been reporting issues with video, though we did not encounter this in our testing.

Performance

Ultraportable notebooks aren't about raw performance, and the MacBook Air—especially the 11" version—is no exception. That said, the infamous return rate on early netbooks showed that users don't like to be unpleasantly surprised by sluggishness, even in a very cheap portable, so this will be doubly true in for users who spring for a $1,000 laptop. 

With the new MacBook Air, Apple made important tradeoffs designed to minimize size and weight and maximize runtime, and one of these tradeoffs was to stick with low-clock speed, ultra low-voltage Core 2 Duo processors. From a raw CPU performance standpoint, the 1.4GHz U9400 in our review unit is no match for the Arrandale-based Core i-series processors used in some ultraportables or Apple's current 15" and 17" MacBook Pros. In fact, it's not even really a match for the 2.13GHz Core 2 Duo processors in the previous-generation MacBook Air.

Apple did manage to mitigate the CPU downgrade a bit by boosting the speed of the GPU and the SSD—these changes definitely helped, but is it enough? Let's find out.

We used three different benchmarks to look at the raw performance of the 11" MacBook Air. Geekbench strictly examines CPU and memory performance. Xbench, while targeting a range of hardware all the way back to PPC-based Macs, covers a lot more ground, looking at disk performance, graphics performance, and other OS operations. And Cinebench looks at both raw CPU rendering as well as GPU-based OpenGL rendering. For comparison purposes, we also included a previous-generation 13" 2.13GHz MacBook Air and a recent vintage 2.53GHz Core i5-base 15" MacBook Pro.

Looking at the Geekbench scores, the 11" MacBook Air clearly isn't winning any speed contests. The 1.4GHz ULV CPU is further limited by an 800MHz front-side bus, so memory access is also slower compared to the 13" MacBook Air's 1066MHz FSB. With a faster bus and a 50 percent faster CPU, the previous-gen Air manages a 28 percent better score. It's not even a fair fight with the Core i5 MacBook Pro, though—with the capability of running four threads simultaneously and direct connection between CPU and RAM, it easily stomps the 11" MacBook Air.

http://arstechnica.com/apple/reviews/2010/11/the-future-of-notebooks-ars-reviews-the-11-macbook-air.ars/3

Platypus

Platypus is a developer tool for the Mac OS X operating system. It can be used to create native, flawlessly integrated Mac OS X applications from interpreted scripts such as shell scripts or Perl and Python programs. This is done by wrapping the script in an application bundle directory structure along with an executable binary that runs the script.

http://www.sveinbjorn.org/platypus

Creating our very first Mac application with Ruby, how exciting!

After setting up MacRuby as described in our previous blog post and having set up Xcode, it is now time to create our very first Mac application in Ruby. In this series of articles, we assume that you have the latest version of OS X installed on your Mac. By the time of this writing, that is Snow Leopard and it is important to emphasize this seeing as some Cocoa API methods have been deprecated or added since its last iteration. Without further ado, allons-y!

Creating a new project

After starting up Xcode:

1. Select File
2. Select New Project

A dialog window as shown below should appear.

From this window

1. Select MacRuby application
2. Click on Choose…

A file save dialog should now appear as displayed below.

In this window:

1. Type in BornToBeAlive as our project name.
2. Click on Save.

A new window should now appear representing the newly created project in the Xcode environment.

By the time of this writing our environment is setup to target OS X 10.5 (Leopard). As mentioned before, we’re going to target OS X 10.6 (Snow Leopard) seeing as we want to utilize the most mature Cocoa API and platform. As such we need to set this target environment to OS X 10.6 in the overview popup menu.

Now that that’s been dealt with, we can finally really start working on our application.

Designing our Interface

Before we’re going to write even a single line of code, let’s first start off by designing the user interface to our application. To do this, we first need to discuss how our programming environment deals with this kind of information.

Certain information about our interfaces, in particular the one’s we’ve created using Interface Builder (the UI design application of Xcode) are usually stored in bundles called NIB files.

As of Xcode 3, these are actually stored in files with the xib file extension as opposed to the nib file extension. Worry not however, as they are just different formats for storing the same information: where xib files appear to be represented as XML text files, a nib file is an archive. More importantly however, the difference between xib and nib files are that the former will be compiled within the executable and will not appear in the final .app bundle.

In general, Xcode will ultimately know what to do with these files and how to treat them. It is for this reason that we’ll refer to both formats as nib files and basically assume no distinction between them.

In the Groups & Files panel, expand the NIB Files group.

In this panel

1. Double click on MainMenu.xib

This action should result in Interface Builder firing up for this MainMenu.xib file. Various windows of Interface Builder should now be visible to you.

In the MainMenu.xib window:

You see a collection of objects and proxy objects that are necessary for describing our user interface. The objects displayed in this window are objects that describe our application’s user interface and are stored in a freeze dried manner, i.e. serialized. Upon loading the NIB file, they get thawed and instantiated again.

In light of this, it is considered good practice to store only one window object per nib file. This way, we only load in the windows when we really need them (thus conserving memory) and will keep our design more maintainable too as each window and its components will be contained by its own NIB file. The latter will allow us to possibly recycle NIB files too in other projects.

Strictly speaking, we also shouldn’t store a window in our MainMenu.xib as is now the case, but in order to load this in, we require a notion of delegates. The latter is something we’ll discuss in a later article so for now, we’ll keep the window object in MainMenu.xib.

For now:

1. Double click on Window

This should put the focus on our initial window and via the inspector, we can edit some of its properties, such as the title of the window instance.

While having selected the Window in the MainMenu.xib window, in the inspector window:

1. Select the first tab, so that the inspector window is displaying the Window Attributes.

   

2. Edit the Title field to Born to be Alive

   

3. Hit the enter key

Your window should now bare the title Born to be Alive. How exciting!

Let’s add a Label to this window proclaim this message of life even bigger. To add cocoa components to our window, we need to drag and drop them from our Library panel to the window we want to add them to.

In the Library panel:

1. Set the focus on the search field at the bottom of the Library panel.
2. Type in Label. Notice that as we type character per character, the components get filtered based on our query.

Your Library panel should now display a few options for labels and should look something like the following:

Note that my Library panel will most likely display more options here in terms of labels as I’ve also installed the BWToolkit palette too. We won’t be using any of those components for our MacRuby applications though, so it’s safe for you to ignore them for now.

Now it’s time to actually add the Label component to our window. As mentioned earlier on, we do this by simply dragging and dropping the Label icon from our Library panel to the window we want to add it to. Doing so should result in something similar to the following:

Great! Let’s rename the newly added Label to something more fitting. In the window displayed above:

1. Double click on the newly added Label. This should now open up the ability to edit value of this Label.

   

2. Type in Born

   

3. Hit the enter key.

Your window should now look something like this:

Wouldn’t it be fun if we would have a button that we could press to unveil the full message of life? Let’s do just that by adding a button to the window we’re designing.

In the Library panel:

1. Type Button in the search box at the bottom of the Library panel. In a similar fashion as the label, it should filter away the components that do not match the Button search description.

   

   Whoah, so many buttons! Let’s just stick with the first shiny one for now.

2. Drag and drop the first button that appears in the filtered selection to our window. Depending on where you dragged and dropped the button to, your window should now look something like this:

   

3. Double click on the newly added button to be able to edit its title.

   

4. Type in Unveil full message

   

5. Hit the enter key.

Your window should now be shaping up pretty nicely and look something like:

We can actually build this project at this stage and see what we’ve just designed in the form of a real application! Indeed, the standard MacRuby cocoa template has set up most of the boilerplate to get us started. At a later stage, we’ll dive into the details of the bootstrapping process, but for now let’s just assume that it set it up all correctly and save our changes by selecting File->Save from the Interface Builder main menu.

Compiling is not the task of Interface Builder, but the task of Xcode so let’s switch back to Xcode. In the project window, click on the Build and Run button in its toolbar.

After compiling for a few seconds and linking all the dependencies, your new application should launch in your OS X dock, and in particular, the window you just designed should show up.

Clicking on the Unveil full message button doesn’t do a lot though, but that should come as no surprise seeing as we’ve only been designing the interface up to this point. We haven’t yet specified what should happen if one presses the Unveil full message button button.

In terms of Model-View-Controller (MVC) (a separation of concerns design pattern Cocoa relies heavily on), we need a controller to handle this kind of user input.

Writing our very first controller in MacRuby

As mentioned in the previous section, Cocoa was designed with the MVC paradigm in mind. Within this paradigm, we need some kind of controller layer to process the input provided by the user. This input ranges from keyboard events to mouse events. For our intents and purposes, we’re interested in handling mouse events on our Unveil full message button. In order to be able to do that, we need to create a controller that will be able to deal with that.

Also, we may want to process events employed by the user onto the window itself. This would normally require a NSWindowController instance. Taking in mind we want to process events from components within the window as well, we could choose to create a separate controller for these components as well, but that would likely make things overly granular, especially for the simple scenario we’re currently dealing with.

So in place of the latter, we can also just choose to consolidate the ability to process the events of a window and its components all together into a subclass of NSWindowController. This allows us to handle the general case of controlling an NSWindow as well as specify our own actions for handling the components contained by our NSWindow.

To do this, in the Groups & Files panel, expand the BornToBeAlive project as displayed below by clicking on the triangle next to it.

In this expanded project outline view:

1. Right click (or ctrl+click) on Classes
2. Select Add->New File

A new window should now appear giving you the options of what kind of new file you would like to add.

1. From the Ruby user templates, select Ruby File.
2. Click on Next

This will open up a Save File dialog.

1. Type in MyWindowController.rb as the name for the new Ruby file.
2. Click on Finish.

Your window should now look something like this:

As decided upon earlier, we now need to implement our MyWindowController class in a consolidated way such that it can control both the window and the elements contained by that window. We will achieve this by implementing MyWindowController as being a subclass of NSWindowController, and in doing so, specialize the NSWindowController class for our window.

In the code editor, type in:

class MyWindowController < NSWindowController
end

Tres bien! But how do we access the label to modify its value after a user has clicked on the Unveil full message button?

Well, according to the Apple cocoa documentation on NSWindowController, it is capable hold a reference to the window it controls/manages. Instinctively, we assume that through this reference, we could access the elements of the window.

Even though this is kind of true, the NSWindow class was designed for general cases as well and not just our specific window. This means that its design is well composed and that it will be rather tedious to acquire a reference to the element of the window we’re interested in manipulating. Most likely, it will involve a lot of chaining query calls which violates the principle of least knowledge.

To drive the point home, accessing an element in such a fashion in general will look something like: window.view.subviews[0]

A non-food solution to this would be to subclass our NSWindow to hold a direct reference to the elements we’re interested in manipulating, but that would require an assumption in terms of type seeing as our NSWindowController only deals with NSWindow and not OurSpecificWindow.

Taking all this into account, it’s probably just better to give our MyWindowController a direct reference to the element of the window we’re interested in manipulating.

In our particular case, we’d like to change the label’s string value after the user has clicked on the Unveil full message button to show the true message of life. This means we need a reference to the label within our MyWindowController and as such our code listing of MyWindowController now is:

class MyWindowController < NSWindowController
   attr_accessor :my_label
end

In Cocoa, such a reference is usually referred to as an outlet, in our case, representing the metaphor of “being able to plug a label object into the outlet”. C’est bon indeed!

We now need to define the action to be taken when a user has clicked on our Unveil full message button. You might be wondering right now whether or not we also need a reference to the button from within MyWindowController as was the case for the label. This however, is not necessarily the case for us seeing as the button — an instance of NSButton — is an action emitter. More specifically, an NSButton inherits from NSControl and NSResponder allowing it to receive user input (e.g. mouse events) and convert these to action events and dispatch the latter to our code. We may touch base on this subject in more detail in a later article, but for now, suffice it to say that we don’t need such a property reference.

When the button receives a mouse event from the user that is of our interest, i.e. a click event, it will convert this event into a click action and try to dispatch the action message to our code. To that end, the button expects us to provide an object with an action handler method to handle the action on delivery. In Cocoa terminology, this object containing the action handler method is referred to as the target of the button.

An action handler method in MacRuby has a distinct method signature: it is a method with one parameter named sender. It is important to adhere to this rule for action handler methods as Xcode and Interface Builder will only then recognize them as being actions.

Let’s open up our code editor in Xcode for MyWindowController.rb and change the listing to:

class MyWindowController < NSWindowController
   attr_accessor :my_label

   def unveil_full_message_clicked(sender)
       @my_label.stringValue = "42"
   end
end

Here, we’ve added the unveil_full_message_clicked action, which will change the stringValue property of our label to the true message of life. Excellent! We’ve now set up all our code, and what remains now is to tell our button to who it should dispatch its action to.

We can setup this target-action for our button programmatic, but Interface Builder provides us with a visual solution for setting these up as well. For the sake of clarity and convenience, the visual solution that we’ll go over with in a few moments enjoys our preference for now.

Hooking our MyWindowController up to our window

In the previous sections we’ve gone from designing our window to providing an implementation for our MyWindowController class. They still need to be hooked up to one another however as they are now still disjoint entities that don’t know of eachothers existence. In this section, we’ll describe how we’ll be able to hook these things up visually using Interface Builder.

In Xcode:

1. Double click on MainMenu.xib to open up Interface Builder for this nib file.

As we’ve discussed earlier, objects are stored in a freeze dried manner in our NIB file that get “thawed for use” when the NIB file is loaded again. In this case, we need an instance of MyWindowController to hook it up to our freeze dried window instance.

In Interface Builder in the Library Panel:

1. Type in NSObject in the search field.

   

2. Drag and drop the Object from the panel to the MainMenu.xib window of Interface Builder. This will create a new freeze dried object in the NIB file that will be instantiated when the NIB file gets loaded in.

   

3. Select the object.

In the Inspector panel:

1. Click on the Object Identity tab.

   

   As we can see, the object is of class type NSObject. We need to change this to be MyWindowController to let this object be an instance of that type.

2. In the class identity field, type in MyWindowController.

   

   Our object is now of type MyWindowController. Tres bien!

Now that we’ve created a freeze dried MyWindowController object, it’s time to hook it up to our window instance.

Recall from the code listing on MyWindowController that we have defined an accessor — i.e. outlet — for our label, but have not yet set this property. In particular, we need to set the my_label property of our MyWindowController instance to point to the label of our window. In Cocoa jargon, we need to “plug our window’s label into our MyWindowController’s my_label outlet”.

In the MainMenu.xib window of Interface Builder:

1. Hold down the right button (or hold ctrl+click) on the MyWindowController object and drag your mouse to the label in the designer.

   

2. Release the right mouse button above the label. A popup menu as displayed below should now appear showing you the outlets to which you can hook the label up to.

   

3. Click on my_label in the Outlet popup menu to hook the label in the window up to our MyWindowController’s my_label property.

Our MyWindowController now knows what object it should refer to when we use @my_label in MyWindowController. What remains is to set up the target-action for our button to our controller’s action handler method. We’re almost there indeed!

To set the target-action for our button:

1. Hold down the right mouse button (or ctrl+click) on the button in our window and drag to our My Window Controller object in the MainMenu.xib window as illustrated below.

   

2. Release the right mouse button. A popup menu should now appear displaying the controller’s action handler methods we can dispatch the button’s (click) action to.

   

3. Click on unveil_full_message_clicked: to allow the button to dispatch the click action event to this method of our MyWindowController instance.
4. Hit cmd+s to save our changes in Interface Builder.
5. Return to Xcode. Make sure we’ve saved all the changes we’ve made to the files here too via cmd+s.
6. Hit the Build & Run button in the toolbar as we’ve done before.

Congratulations, your very first MacRuby application should now be in working order! Go ahead, click on the button to unveil the full message of life!

Download code

BornToBeAlive MacRuby App Example

Epilogue

For the sake of brevity — something I know is hard to believe looking at the volume of this first tutorial — we’ve omitted a few steps you’d normally like to take into consideration.

For instance, we’ve not connected the window outlet of MyWindowController (an outlet it inherited from NSWindowController) to our window instance to allow it to manage the window. Connecting this outlet occurs in a similar fashion as was the case with connecting the label outlet by holding down the right mouse button on the MyWindowController instance and dragging it to the window instance.

Releasing the right mouse button will display a popup menu outlining the outlets we can connect the window to. Clearly we should select the window outlet here.

http://www.rubyinside.com/how-to-build-a-mac-os-x-app-with-xcode-and-macruby-3132.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+RubyInside+(Ruby+Inside)

http://www.macruby.org/downloads.html

http://blog.phusion.nl/2010/03/12/creating-our-very-first-mac-application-with-ruby-how-exciting/

Fluidium

Fluidium is an open-source platform for developing Rich Internet Applications that run as native Mac OS X desktop apps. Fluidium is much like Adobe Air, except open source (liberal Apache license), and exclusive to the Mac.

Increasingly, new applications are being written as web apps, but native Cocoa applications still provide the best user experience on Mac OS X. Using Fluidium, you can wrap your existing web app in a pure, native Mac application shell and provide the best of both worlds to your demanding user base.

Fluidium is unabashedly Mac-only, and makes no cross-platform compromises. With the high quality of native Mac apps, cross-platform, least-common denominator approaches don't cut it on OS X. Your Fluidium-based app will fit right in on OS X as a first-class Cocoa citizen.

Fluidium is based on the same open source technology that powers the popular Mac OS X Site Specific Browser, Fluid.
http://fluidium.org/

Mac Central

• Keyboard Shortcuts
• Multi-Touch Gestures
• Tips & Tricks
• Recommended programs

http://www.danrodney.com/mac/index.html

Snow Leopard Upgrade

• Fixing Ruby Gems, MySQL and Passenger Phusion on Snow Leopard 10.6
• Epic Snow Leopard Upgrade Guide
• Snow Leopard Ruby/Rails Developer Setup
• 23 Snow Leopard Tweaks You Didn’t Know About
• Snow Leopard: Upgrading for Rails Developers