Configuring CakePHP for an OSX local install

I am currently learning some of the technologies involved in building web based applications, following ideas from the Software as a Service course.

Currently I'm looking at PHP and the CakePHP frameworks.

Obtain the source

Download and unzip the package from the CakePHP website

Rename to a suitable folder, I have put mine in Sites/ScoutCamp.

Set up Apache

Edit your sites file sudo nano /etc/apache2/users/username.conf

   Options FollowSymlinks

   AllowOverride All

   Order allow,deny

   Allow from all

Restart apache sudo httpd -k restart and open a browser to your shared pages.

Lots of errors and messages

First time I fired up the browser I thought “Oh dear me” or at least something along those lines.
Unlike my trial of Ruby on Rails, there were loads of errors and configuration changes that were required.

I have solved most of the problems, but still have one left to suss out.

Timezone settings

In app/Config/core.php there is a line (it was 232 on my build)

   //date_default_timezone_set('UTC');

Uncomment and set to your timezone - Newcastle is in the same timezone as London.

   date_default_timezone_set('Europe/London');

Unable to write 'cake_dev_en-us' to File cache

The app/tmp folder needs to be writable by the web user.
To find out who this is, add the following bit of code to app/View/Pages/home.ctp


   

On my system, the web user is _www, so change the owner:

   sudo chown -R _www app/tmp/

This cleared up all the errors above the title.

Please change the value of “Security.salt” and “Security.cipherSeed”

In app/Config/core.php find the lines and change to a more suitable value. I used sha1sum to generate the salt, and pasted for the salt. The Seed I just typed a few numbers at random.


   df  | shasum

Setting the database connection

You need to create your database using mysql (there are other options, but that's the one I went with).

Copy database.php.default to database.php and add your user and database details. Note that for some reason, OSX will not work user localhost (and that took a day to track down).

   public $default = array(

      'datasource' => 'Database/Mysql',

      'persistent' => false,

      'host' => '127.0.0.1', // Note change from localhost

      'login' => 'ScoutCamp',

      'password' => 'yourPassword',

      'database' => 'ScoutCamp',

      'prefix' => '',

      'encoding' => 'utf8',

   );

URL Rewriting

This is the only bit I haven't worked out yet, but I want to make a start developing my site and will come back to this.

Administrating a mySQL database with phpMyAdmin

Just a quick gotcha for OSX, mySQL and phpMyAdmin.

I had successfully set up mySQL and secured the default accounts with passwords. Although shipping a product without passwords may be thought of as a security hole, it is just as bad as shipping with a default password.

Downloaded and installed phpMyAdmin onto the macbook and configured according to instructions. 

Did it work? Did it heck! 

After a while googling for answers, I read through another install guide (although for Lion not Snow Leopard) and found this gem: 

Edit config.inc.php using your favorite editor (I prefer vi) and change$cfg['Servers'][$i]['host'] = ‘localhost’; to $cfg['Servers'][$i]['host'] = ’127.0.0.1′;*Well it sounds stupid because localhost and 127.0.0.1 are same in networking world but phpMyAdmin won’t let you (At least me) log in without this change and keeps throwing error “#2002 Cannot log in to the MySQL server”

This is one of the classic IT gotcha's: two things that are supposed to give the same result don't. I'm almost tempted to see if it is the same on a linux machine, but don't want to get diverted.

Next steps will be to start reading up seriously on PHP MVC frameworks - I'm currently looking at cakePHP.

I really can't remember how we did this stuff before the internet was available, and many of the younger developers probably can't imagine the idea. Perhaps that is why I have a largish collection of computing books going back to VB5 and Access 2 in my bookshelves. Although that could just be because I hate to get rid of books.

Learning PHP the hard way

I have been given a challenge: to learn PHP well enough to demonstrate my programming prowess.
Most people will have no idea what PHP is, and probably care less. Not to worry, read on and you will possibly learn more than you are interested about.

Backups and upgrades

I am taking the (big) risk of doing an update on my main laptop in upgrading it to Ubuntu 11.10.

Out of paranoia (and because I had a problem with the filesystem recently), I decided to do  a full backup of my home directory first.

Two days later the backup was complete. Not surprisingly, I had done some work on the machine and needed to do a backup again, but this time I just backed up the files that have changed.

Today is the big day: starting the upgrade process. I found it amusing that it might take some time to download the updates. Only might?

Currently using my MacBook, and (as always) it is taking me a while to get used to the different key layout.

It takes a little while to reprogram my muscle memory into finding the ~, | and # keys again. I am never sure if Apple actually looked at a UK keyboard before setting up their keyboards, but it is most certainly not following the standard.

For those slightly less trusting than me, how do you know if a backup is successful? The only way I know is to do a restore. Comparing the backup to the original only says the files have the same contents, after all. It does not mean that the backup will be able to be restored to your machine.

My usual method for upgrades is to buy a new hard disk for the laptop, do a clean install then copy my files over onto the new install. This time I have bitten the bullet and went for a direct upgrade.

Further frustrations and a brief moment of joy

After getting the OSX code to compile and execute using OSX (and the codeblocks/gcc combination), my next plan was to get the code to compile under Linux.

I had set up my code in a dropbox folder so I could access the same codebase across all my machines, and booted my laptop running Ubuntu 11.04.

Codeblocks started, the targets for Linux added to the project and hit 'build and run'. I sat back to watch... Screens full of error messages, top of the list was

error: invalid use of incomplete type ‘struct wxFrame’

After going round in circles, checking that the include files were present (which they were) and a few other dead ends I ended up removing and re-installing the wxwidgets libraries. It felt like a desperation move, and oddly it worked.

My code now compiled and executed as expected under Linux. Feeling brave, I started investigating getting the code to work cross-compiling for a Windows target.

Mingw libraries and utilities installed, a test program put together (another version of the infamous "Hello, World!" application) and a Hello World message box running on my Windows VM.

Getting codeblocks to use the cross-compiler wasn't difficult, a new compiler setup copied from the gcc version and changing the toolchain executables did the trick (the only bit I'm not sure about is the debugger, but when the code is compiling cleanly I'll run through that set of options).

The only gotcha was that a set of libraries are needed to have the code execute on Windows XP (I don't have other options to test at the moment - at least not while Lynn is using her computer).

Back to making progress

Hopefully these won't be the famous last words type of progress...

In the OSX Debug and Release build options we need:

-arch i386 in the compiler and linker options

In the post compilation build add

mkdir -p $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/MacOS/

/Developer/Tools/SetFile -t APPL $(TARGET_OUTPUT_FILE)

/Developer/Tools/Rez -d __DARWIN__ -t APPL Carbon.r -o $(TARGET_OUTPUT_FILE)

cp $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/MacOS/$(TARGET_OUTPUT_BASENAME)

/usr/local/bin/dylibbundler -od -b -x $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/MacOS/$(TARGET_OUTPUT_BASENAME) -d ./$(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/libs/

The only thing that is (mildly) irritating is getting the cocoa application to execute when the ide is trying to run the code.

Next step: get the basic code to compile and execute on the Linux box, and following that cross-compiling for windows (not sure if there will be different variants for XP, Vista and 7 though). And after that? Creating a useful (or otherwise) application.

>About to switch machines. After tea (gammon with honey glaze mmmmm)>

Getting Closer

There are a number of logical steps required to build an application that will run under OSX.

The most obvious is that you need to compile the code. There are some hidden gotcha's if you're not using xcode or projectbuilder, however.

In my previous entry I commented on my discovery that you need to add a flag to the compile and link options "-arch i386".

This has allowed the code to happily compile and link, but when the application is executed it starts in the background and refuses to come to the front. No menus, and seemingly unable to accept focus.

Todays discovery has been getting the application to accept focus, this needed further changes to the way that my codeblocks ide is set up, as well as adding a new application to my system.

The dylibbundler is the new application. The main page says that dylibbundler is a small command-line programs that aims to make bundling .dylibs as easy as possible. It automatically determines which dylibs are needed by your program, copies these libraries inside the app bundle, and fixes both them and the executable to be ready for distribution.

But like everything, it wasn't quite as easy as running the command line utility.

Firstly the output directory was changed to myApp.app/Contents/MacOS/myApp

Then I added the following to the Pre/Post build steps:

/Developer/Tools/SetFile -t APPL $(TARGET_OUTPUT_FILE)

/Developer/Tools/Rez -d __DARWIN__ -t APPL Carbon.r -o $(TARGET_OUTPUT_FILE)

/usr/local/bin/dylibbundler -od -b -x ./SRA.app/Contents/MacOS/$(TARGET_OUTPUT_FILE) -d ./myAPP.app/Contents/libs/

This now gives me a running application that can be brought to the front. Note that the text is wrapping, a copy/paste into codeblocks will help.

Now all I need to do is to get the code to load the text file and display correctly. That might just be a little more difficult than getting codeblocks and OSX to play nicely.

Update: a step I missed out was to set the Output filename for the build targets to point to the modfied file name. For my app I had to set it to bin/osx/Debug/Sim65.app/Contents/MacOS/Sim65.

Frustrations with computers

In my free time (hollow laugh), I'm looking at creating a couple of simple applications using Codeblocks and wxWidgets.

My primary development environment is a laptop currently running Ubuntu 10.10, but I was wanting to use the same tools on my MacBook running Snow Leopard.

Over the past few visits to Starbucks, I've been trying to get a default application from Codeblocks for wxWidgets to compile, and got some wonderful compile and link errors.

The problem, apparently, is that the compiler will generate 64 bit code by default, which does not seem to be supported by many libraries.

After much frustration, I pasted an entire line from the build log into Google, finding this site http://forums.codeblocks.org/index.php?topic=12968.0.

The recommendation is to add -arch i386 to both the compile and link options. And it seems to work.

At least now I have a custom compiled set of wxWidgets libraries and Codeblocks itself. Sigh.

Time to start cutting code.