The most recent one was as to why the shorter urls ie: “/index/pants” would not work.  It would always complain and blow up that the controller ‘pants’ doesn’t exist.  Even though I know for a fact that I want the index controller in the default module and the action ‘pants’…

The problem with naming your default, or any module ‘index’ is the way ZF matches and routes the request.  If you have a module called ‘index’ then any request that begins with ‘/index’ will get routed to it.  Even if this isn’t what you want.  Typically  when I have actions like ‘about’ or ‘contact’, they reside in my default module and are easily accessed by ‘/index/about’ or ‘/index/contact’ – when a module exists called ‘index’ these shorter links don’t work and I’d need ‘/index/index/about’ or ‘/index/index/contact’ – these suck and thus you should never have ‘index’ as a module name.

The point: If your default module has to be in the URL to access these default actions, you’re not using the ‘default’ module properly.

Social Gamer:  A small site that allows you to rate and review games that you play online.  Right now it’s focusing on Facebook Games but will expand to include Wii, DS, Xbox360, PSP, and PS3 games.  But for now, It’s still getting the infrastructure put behind it.  You can play around with it right now if you want and feel free to share it with your friends. This project is getting most of my attention right now.

Refill Revolution:  A start up in sunny California dedicated to promoting the use of refillable bottles. The site is in the first phase and running in a closed on-campus beta test at Berkely.  That’s all I can really say for now on this one.

Moments Like Today:  A collaborative effort between myself and Margaret.  There’s a facebook group, vimeo group and flickr group.  So far there are about a hundred contributors to the project and once it’s up and running on the main website there’ll be a nice little interface for you to browse peoples ‘moments.’

Triviosity!: A simple, quick online game of trivia.  It’s in the early stages still so I won’t link to it.  But it’s going to start on as a facebook app, but also be functional outside of facebook.

And now you know why my summer project got delayed. And now you know what the frack I’ve been doing.

At some point I’ll probably put it on a public SVN repository, but for now you can have the tarball.  There’s a README in the file with a simple sample. And the source is pretty self explanatory so you should be able to figure it out if you want to.

The remainder of the work will be done in the order I see fit.  Likely read-only methods (most of the getters) Authentication and write methods will be much much later.

I’ll also add more RESTful interfaces as I need them.  Probably Facebook soon, Twitter later.  Who knows.

Drop your comments here if you’ve got any questions.

Interesting:

• Data Models
  You define them in code and then the framework takes care of the rest.  This leaves it to be truly independent of which database you should choose to use; it keeps it portable between databases and helps you make sure all your database structures are up to date after rolling out a new version.
• Admin Tools
  Right out of the box Django has an easy to use and easy to configure admin section.  One of the greatest annoyances I’ve always had to deal with is “We need to be able to edit that.”  With Django’s magical admin section, all you have to do is enable your data models to be usable by it – and then anybody you give permission to can edit your database.  It’ll even track changes that users make. Handy.
• Lots of Tools
  With a handy, full featured django-admin tool, you can get a lot done and a whole app project up and running in no time.
• Everything is an Object (not Django specific)
  There’s not much more to say on that. Just that every piece of code will behave in the same object-like manner.
• Standalone Dev Server (not Django specific)
  Having a quick and easy dev server is handy.

Not so Interesting:

• Template System. it’s ‘meh’.  Nothing really jumped out at me as to why it’s exciting or great.
• Django’s PHP bashing in their documentation. Why the hate, guys?
• Having to Configure URLs. I kinda like the fact that I can disable a certain section of an application at the drop of a hat.  But I can see it being an annoyance to have to actually configure every URL after I create new modules apps.
• Projects vs. Modules vs. Apps.  I don’t like how they call what I would refer to as a ‘module’ an ‘app’.  This is just semantics.  In Djangoland what I would call an application they call a “project” and what I would call a module they call an “app”.

With a bit of an understanding on how things work now, at least I can dive on into the APIs and perhaps get something done.

Does anybody have any suggestions for a light weight GUI IDE?

Over the last year I had been using a Java Bridge from a Zend Framework application to access a Java only API.  And really, between the two bridges there are no differences.  They both work identical, they both work great.  Would I pay Zend for Zend Platform’s Enterprise license? No.  Why? Because both bridges perform the same.  The only differences are:

1. Zend’s Java bridge already has a function called java_require and the open source PHP/Java Bridge needs you to include a file.
2. PHP/Java Bridge has a java_cast function, and you need it.  Zend’s Java Bridge does not have, or need this.

With these two differences all you need is a little code in your bootstrap (or somewhere else useful) to cover them and all is golden. Your app should work with both Java Bridges without any issue.

/* no java_require() include the java.inc for PHP/Java Bridge */
if ( ! function_exists('java_require') ) {
    include "java/Java.inc";
}

/* declare this, it doesn't exist with Zend Java, but is needed for PHP/Java Bridge */
if ( ! function_exists('java_cast')) {
    function java_cast($whatever) {
        return $whatever;
    }
}

There’s probably a more graceful way of checking and doing this but that’s it, and it’s worked on a multi tiered build environment for over a year now.

So, for the basics of what I have decided to do: Yep, it’s an image gallery.  It’s not too exciting and definitely nothing original.  There’ll be a basic authentication system (login/logout) with web based uploading and tagging.  That’s pretty much it.  The images that get uploaded will be stored in the database itself as a nice central location for all my different variants to get the data from.

As far as the initial setup goes, I’ve managed to get PostgreSQL installed, running, and I’ve even created the necessary tables for all that I need.  Yeah, that part was pretty simple.  But I can’t say it happened without learning something.  I’ve noticed that something I took for granted with MySQL wasn’t available right away for my installation of PostgreSQL.

Yep, lots of functions.  As I previously explained about how expandable PostgreSQL is, well, it also starts out very simplistic.  I needed some encryption functions to be able to store users passwords in my database – and these functions weren’t available.  As PostgreSQL requires you to define functions on a per-database basis, I had to import a few little things (pgcrypto.sql from the distribution files) and voila, it all worked.  Part of this is an annoyance, but part of it makes sense.  I mean, there’s no point in declaring 500 functions if you’re only going to use 3. Right? Right.

Any way, I’m almost ready to jump on the first path. Python, Django here I come.

Note: this is not a tutorial.

The installation was simple, as are most installations with Ubuntu. The initial “get going” was a bit odd for PostgreSQL though. The one thing you have to remember when initially trying to get things going is this…

sudo -u postgres [command]

In order to set things up I had to use the postgres user account.  Using this I was able to create a password for postgres, create my own user account with super user privileges and a new database.  Once I had created my own account and secured the postgres user for remote network connections I was ready to move on and do whatever I want.  For administration purposes I’m going to stick with phpPgAdmin (php application) and pgAdmin3 (gui application), both available from the Ubuntu repositories.

After sifting around the admin interfaces a bit and creating a few test tables I started noticing a lot of differences between MySQL and PostgreSQL.  I’m really not going to get into the battle of who’s better.  It’s far too complicated for one post – and quite frankly I can’t tell you, yet.

What I can say though is that PostgreSQL seems to be a lot more versatile with respects to data types. It also seems to be a lot more configurable when it comes down to security and permissions of databases, schemas, tables.

A MySQL database contains: tables, views, stored procedures, functions and triggers.

A PostgreSQL database contains: schemas and full text search configurations. Sounds a bit off, right? but the schemas contains: tables, views, sequences, functions, domains.  This split allows for multiple schemas within a database, and essentially a much cleaner name space than what you can do with MySQL.  You can also use these schemas in the database to allocate different permissions to different groups of tables.  So far, not bad.

But, what are all these other things?

If you don’t know what tables and views are, you probably shouldn’t be reading this.  You should probably be reading a primer on what a database is.

One of the first “HDIDT?” was ‘Where’s the auto increment for my column?”  PostgreSQL doesn’t support an automagic counter like MySQL does.  So, for my standard table structure with an automatically numbered ID column, I had to figure it out.  This quickly introduced me to sequences and how PostgreSQL does things.  Using the data type ‘SERIAL‘ when I create the table, PostgreSQL automatically created a sequence for me which acts the same as an auto_increment setting for MySQL.  The difference? Well, with PostgreSQL’s sequences I can configure how it counts.  I can set the start, limit, increment, and whether or not it can cycle (loop, not useful for unique keys). The default SERIAL behaviour is to start at 0, increment by 1 with a maximum of 9223372036854775807 and not cycle.  That’s pretty good for a unique primary key if you ask me. I can also have multiple sequences on a single table, whereas MySQL only allows for a single auto_increment column.

Functions, much like MySQL’s stored procedures and functions only there’s something special about PostgreSQL’s functions.  That special feature is that you can do them in a few different ways.  Internal functions – built in when you compile PostgreSQL – not something that I can see a lot of use for in every day use, but if you’re a C programmer and want to make your own – you can!  The real kick here is the support for Procedure Language (PL) with multiple interfaces.  PostgreSQL supports pgSQL (their own), Python, TCL and Perl for creation of functions.  I don’t know about you, but those are some pretty powerful languages.  I’m not going to go into these in any depth, but I’m sold already.

Domains are a special little thing.  Slightly confused by the name, a domain is a user defined data type.  This is best described by the PostgreSQL manual:

Domains are useful for abstracting common constraints on fields into a single location for maintenance. For example, several tables might contain email address columns, all requiring the same CHECK constraint to verify the address syntax. Define a domain rather than setting up each table’s constraint individually.

With domains there is an ability to control data formatting as well as types at the server level.  I can see this being useful for BOFH DBA’s.

Another major difference that I’ll have to wrap my head around is the number of different data types that PostgreSQL supports.  Unlike MySQL’s fairly standard set, PostgreSQL supports a pile more.  A pile of native, specialized data types.  Nerdy things like ipv4 and ipv6, geometrical shapes, and money.  That’s pretty hot.

So far, I guess I have to say I’m pretty pleased with the shape things are taking with my adventure into PostgreSQL land. Only more time will tell as to whether it’s really good.

What do I mean by, “it’s just a language?”  Well, let me tell you. On a regular basis I get asked “do you now [language]?” And my answer is usually something along the lines of “Well, I know of it, I’ve touched it a bit, but never done anything real with it.”  But, since I’m a programmer I usually follow it with “It’s just a language.”  So now I’m going to prove to myself that it is in fact “just a language.”

In order to do this I’m going to do one project a few different times.  This project will be a simple web application that doesn’t do anything much – possibly something simple like a gallery or basic forums.

I’ll break down the project into components and then follow the following paths to complete it.

Path 1: Python, Django, Apache, PostgreSQL

Path 2: Ruby, Ruby on Rails, Apache, PostgreSQL

Path 3: Java, JSP, Apache (tomcat), PostgreSQL

Path 4: PHP, Zend Framework, Apache, PostgreSQL

Bonus: Perl, Apache (cgi), PostgreSQL

They will all use a common source of data, all stored in a single PostgreSQL database. After those are completed I will then venture on into the mobile platforms mentioned.  Since the mobile platforms are a bit different as to what I can do the end result may vary.  Hopefully the mobile interfaces will interact directly as if they were the same as the web site interfaces.

I plan on starting after my trip to Vancouver – early June.

Here’s lookin’ at my insanity.

All of my projects reside in an SVN repository and now they’re starting to get accessed by multiple users.  Typically with eclipse, I would just have a project that contained externally required libraries – such as the Zend Framework – but now the location of this is required to be more flexible.

That’s where a trusty environment variable comes in to play.  Now, Zend Studio for Eclipse already implements this but – unless you keep up to date – you’ll probably notice that it only has variables set for ZF 1.5 and ZF 1.6.

I want to add ZF 1.7 to this, and well, it’s fairly simple. Just click ‘New…’ and enter the path to where you’re freshly downloaded ZF 1.7 is.

After that, it’s all set and you can add that newly created environment variable to your project properties as an include path.  This is far more flexible and useful in the long run when multiple people and multiple platforms.

Now, you can commit your .project file and have it used for everybody without conflicting hard coded paths to included projects or libraries.

Cool, huh?

I’m guilty of using this style of inclusion in some cases.  Sometimes it’s just easier. I guess it’s time to re-think how I do what I do in these very few and rare cases.  No more ‘../’ in my render statements!

Thanks to Zend Framework In Action for the quick update.