Cappuccino and Titanium for Building Desktop Apps
By David Golding
| 
Print This Post
Just discovered how easy it is to get a desktop app off the ground with Cappuccino and Titanium frameworks. 280North, the developers behind Cappuccino, have already created a beta of Atlas that enables you to distribute a Cappuccino application for the desktop. Atlas is fabulous, but it renders the interface using its own skin and not the native Cocoa window. Windows, therefore, aren’t bounded to the screen’s edges and resize fairly clumsily.
Titanium provides a useful platform for not only building desktop apps that are more consistent with the operating system’s UI, but also allows for cross-platform distribution to Mac, Windows, Linux, and even the major mobile platforms like iOS and Android. Because Titanium caters to web developers, it makes sense to combine the powers of Cappuccino and Titanium to leverage the strengths of both frameworks. Cappuccino ports sleek Cocoa concepts to its own JavaScript superclasses (Objective-J), making it possible to develop powerful web applications with the same feel and consistency as desktop applications. It has already succeeded well at bringing the powers of the desktop to the web browser; for one example, check out 280North’s 280 Slides application. (It’s essentially Keynote in the web browser.)
Combining the two frameworks was a simple two-step process. First, I got a Titanium desktop application project started. Second, I placed the contents of the main Cappuccino project into the Resources directory in the Titanium project directory, replacing the index.html file that comes with Titanium with the one used by Cappuccino. That was it. Now I can proceed to apply Titanium goodness where I like and base most of the application in Cappuccino. At this point, I’ll have to test for conflicts between the Titanium SDK and Objective-J, but so far, it’s been smooth as butter.
Installing MongoDB on MAMP 1.9.5
By David Golding
| Print This Post
Appsolute launched MAMP version 1.9.5 today, so I thought it’d be a great time to add MongoDB to it and improve my NoSQL skills.
1. Prepare MAMP for MongoDB files
Create a new folder at Applications/MAMP/db/mongo with three additional subfolders named bin, data, and tmp. Provide these folders with chmod 0755 access permissions. These folders will be the main runtime location for Mongo once MAMP gets it running.
2. Download MongoDB
Grab the latest Mac OS install package of MongoDB. My server setup called for OS X 64-bit, version 1.6.5. It’ll have a directory named bin. Drop the files from this folder into the /Applications/MAMP/db/mongo/bin folder you already created.
3. Download Mongo Driver for PHP
I’m running PHP 5.3 (why use MongoDB with any earlier version of PHP?), so I’ll need the mongo.so extension to get PHP and Mongo working together. This is available at the MongoDB GitHub repository, under the PHP 5.3 for Mac binary. After unpacking the downloaded file, place the mongo.so extension file in the /Applications/MAMP/bin/php5.3/lib/php/extensions folder.
4. Create Startup Routines for MAMP
Lastly, you’ll need to create the startup routines so that MAMP will launch Mongo along with MySQL and Apache. Create a new file at /Applications/MAMP/bin/startMongo.sh and place in it the following code:
2
/Applications/MAMP/db/mongo/bin/mongod --dbpath /Applications/MAMP/db/mongo/data --logpath /Applications/MAMP/db/mongo/mongodb.log --pidfilepath /Applications/MAMP/db/mongo/tmp/mongo.pid --fork --logappend
When called, this script will launch Mongo using the MAMP-relative paths rather than Mongo’s system defaults.
Create another file at /Applications/MAMP/bin/stopMongo.sh and place the shutdown method:
2
/bin/kill `cat /Applications/MAMP/db/mongo/tmp/mongo.pid`
This works like the previous script, except it kills the mongo.pid process, effectively shutting down Mongo.
To have MAMP automatically call these Mongo startup scripts, open the /Applications/MAMP/bin/start.sh and /Applications/MAMP/bin/stop.sh files, and insert the following lines above the startMysql.sh lines, respectively:
Now MAMP will automatically launch Mongo upon startup.
The only thing left to do is tell PHP to run the mongo.so extension. If you’re running MAMP Pro, edit the php.ini file by selecting File > Edit Template > PHP 5.3 php.ini, otherwise you’ll need to lookup the path the php.ini file from the MAMP startup screen, under “phpInfo” and “Loaded Configuration File.”
Insert the following line in the php.ini file/template, save the file, then restart MAMP.
Mongo should now run in the background on MAMP, which you can connect with from PHP using the main connection routines listed on the PHP site. Welcome to NoSQL on MAMP!
A Quick Unit Test in Lithium 0.5
By David Golding
| Print This Post
Unit testing has always proven a chore in past projects. But a necessary one. The more specific the testing, the more effectively one isolates problems in the code. Well, and the more aesthetic, provided one knows how to use unit testing right. I have found Lithium’s built-in unit testing environment amazingly simple, and since a couple of folks have asked me recently about this feature, I thought I’d post a very quick unit test just to demonstrate how even a beginner can take up unit testing in Lithium in minutes. (This example already assumes you have Lithium 0.5 working in your localhost environment; if you don’t, take a look at Union of Rad’s installation tutorial or the project lead Garrett Woodworth’s screencast.)
Create the Test Class
To launch Lithium’s unit test dashboard, simply add test after your application’s root path. Assuming our new app is named “basic,” you’d type something like http://localhost/basic/test as your URL. By default, the dashboard only displays Lithium’s core tests. Let’s add one for our own app to evaluate a model.
Create a model test file in app/tests/cases/models and name it after the model class you intend to simulate. In my case, I’m testing a table holding data on composers for a sheet music application, so I’ll name my file ComposerTest.php. Now, place some standard code in this file so that the test classes will execute the unit tests appropriately:
1 2 3 4 5 6 7 8 9 10 11 | <?php namespace app\tests\cases\models; use \app\models\Composer; class ComposerTest extends \lithium\test\Unit { } ?> |
On line 3, we specify the namespace for this class, which corresponds to the path in the application where this test class appears. Lines 5 and 6 call two classes that will allow the ComposerTest class to connect to the database and/or run methods in the Composer model, which, of course, is my runtime model for all of my Composer methods in the live app. Line 8 names the class following a convention: we add “Test” to the end of the model name we’re testing and we extend from the core unit testing class available as lithium/test/Unit.php.
Go back to the unit test dashboard and your new test class should appear on the left under app > cases > models > ComposerTest. Click the link to run tests on ComposerTest, and the results should light up green with zero passes, fails, or exceptions.
Perform a Unit Test
A very basic unit test performs a query to see whether the model connects to the database and can fetch records. I’m going to write a test function that allows me to see whether my model can perform a basic find query. In the ComposerTest class, I’ve written a function called testWhetherDbQueryWorks() that asserts whether a result set is null or populated with table data. It looks like this:
1 2 3 4 | public function testWhetherDbQueryWorks() { $id = Composer::find('first')->id; $this->assertTrue(!empty($id), 'Query did not pull data'); } |
Simple enough. Lithium provides several other assertion methods, which are all described at the Unit class entry in the Lithium API.
Now, when I run the test in the dashboard, it ought to pass, provided I’ve set up my Composer class correctly.
Hope this helps for those beginners out there looking to try out Lithium. I’ll try adding more detailed information, or using screencasts, when I’ve got a little more time for documenting my experiences in Lithium.
