So you install Leopard and want to put that 2TB NAS of yours to good use but you can’t get Time Machine to see your file shares? Simply open a terminal, paste the following command into it:

defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

Then mount the share you want to use and open up Time Machine to set it up.

So last Friday, we decided to try something new at work — we decided to write a webapp in an afternoon. Well, we did and it’s just a simple web 2.0 wishlist appliction with a (small) bit of socialization built in. It’s called Wishalista and you should make one! Check it out — it’s not quite 100% perfect given the short amount of time, but we’ll probably work the tiny kinks out soon (for example, the wishlist isn’t updated after you “update” and you’re taken back to the main page upon adding an item — kind of odd but we’ll take care of them).

Best of all, Wishalista is open source you so can see how we did it. Just check out appcelerator_sdk source from the Appcelerator SVN and look in the examples/wishlist folder.

P.S. This is best viewed in Firefox for the time being.

The Tips Doc:
I thought it’d be nice to throw out some of the random but helpful
bits of information about the Appcelerator platform that I’ve come
across over the past year.  This text is just an informal mish-mash of
much of that information (as much as I can remember right now).
It happens that although the platform itself does a pretty good job of
being “cross browser,” engineers still need to keep each browser’s
quirks in mind.  Having said that, the issues lie mainly around CSS in
Internet Explorer 6/7 and minor javascript differences between them
(e.g. Firefox provides the convenience of indexing a String using
brackets to retrieve a single character while IE requires the use of
String.charAt()).
Some of these tips are more general than others.
Process:
The Appcelerator platform makes it simple to perform division of work;
more clearly, you can build the UI/client and the backend service
layer at the same time.
My approach, when working alone, has always been to build the client
first since it’s the more difficult of the two, using the Script
widget (app:script) to mock out services on the client (essentially
creating a contract for the service layer), then writing the service
layer using that contract.
I’ve also had the experience of concurrently building either the UI or
Service layer while another engineer wrote the other.  In this
situation, it’s best to work together as you go.  Depending on your
programming methodology, you can either write the service contracts on
the fly or create them ahead of time then fill in the code later.  An
example of a service contract one might use followings:
Request: hello.world.request
Payload: ‘name’: string
Response: hello.world.response
Payload: ’success’: boolean, ‘message’: ‘Hello World, John’ (where
John came from the payload of the request)
Mocking out the client initially can be helpful when proposing an
application.  The prototype can easily be reworked into the final
product.
XML Namespace Declarations:
The number one mistake I make is forgetting my XML namespace
declarations at the top of my HTML files.  At the top of every file
(including those files used only for content widget imports), one
should use this in place of the standard <html> tag:
<html xmlns=”http://www.w3.org/1999/xhtml” xmlns:app=”http://
www.appcelerator.org“>
What the heck does this do? Well, since Appcelerator uses custom tags
prefixed by the namespace “app,” we need to instruct the browser to
treat the tag as XML and not HTML.  Namely, this helps us in Internet
Explorer since most of the other browsers handle the lack of this
gracefully.  It’s one of those “just do it” things to keep yourself
from having a lot of headache.  Symptoms from not including this
declaration include strange or no rendering in Internet Explorer.  I
can’t think of any other browser (off hand, one may have an issue with
it) that doesn’t handle the lack of the namespace declarations
gracefully.
Javascript Syntax:
Browsers sometimes fail to “guess” what you wanted them to do so save
yourself the headache and double check your code.  IE, especially has
a hard time parsing malformed Javascript (and with good reason, trying
to be too predictive could lead to unexpected behavior that might make
debugging difficult).
First of all, don’t forget your semi-colons (”;”) at the end of every
line of Javascript you write (where needed).
It’s also important to make sure you do not include an extra comma
(”,”) after the last element in a predefined array.  Although Firefox
will let you get away with this, IE will throw an error.
Equally important is knowing tiny tricks hidden away in browsers that
help you overcome their short comings.  You will likely spend a lot of
time at Microsoft’s MSDN looking up things like IE’s “Dynamic
Properties” (really just javascript statements in CSS, can be pretty
cool stuff) and IE’s document.recalc() function.
Debugging:
This is a tough one.  Some  browsers are more difficult to debug than
others.  I’ll let you search on your own for the solutions to this but
they’re readily available and at worst you can resort to alert
debugging but beware that this has its drawbacks when debugging race-
condition scenarios.  If you run into one of these scenarios try
setting and clearing an interval (timer) to load whatever is failing.
IE: Use Visual Studio (MS has a free “express version”) and install
Microsoft’s IE Developer Toolbar
Firefox: Use Firebug
Opera: Toolbar buttons from Opera’s website
Safari: Turn on the debug menu
Keeping Code Tidy:
It’s impossible to memorize every intricate detail of a large
application so it’s important to keep your code “tidy.”
Start by naming important elements (divs or other containers) with
keyword-based unique ids.  For example “new_user_wizard” is a good
example.  The idea here is to use a project global search to find what
you’re looking for later.
One should also get in the habit of using the Appcelerator content
widget (app:content) regularly.  The content widget allows one to
extract portions of a document into smaller HTML files that are
essentially just dumped back into the main document at runtime.  There
is, of course, a small overhead when using many content files but it’s
minimal and can be partially alleviated by using lazy loading
(lazy=”true”).
Ensure Clean Rendering:
Sometimes, when loading applications, one may notice some text show up
and disappear.  This usually occurs when using script widgets
(app:script).  Although Appcelerator hides the elements that the
script widgets are transformed into, some browsers are too slow,
causing a flicker.  To solve this, simply put all of your app:scripts
right before your ending body (<body>) tag in a div element with style
set to display none (<div style=”display:none”>..scripts here..</
div>).