What's it all about, Alfie?

Today was both a great joy and a major bummer. I thought I was done with the adding of new calculated values to this application I inherited, so in that moment, I was really happy. It had been a hard several days to get the values worked in at each level, but hard work pays off, right? I thought so too.

And after I sent out the email on what additions were now in the system, I was reminded of one I had forgotten.

Crud.

I had to go back to the code and work in another variable. Thankfully, I had the data in the system, so all I had to do was to work it through the reporting system. But even that was going to take time. Ugh.

While it's not core to my Mac work, it's nice to see that Google has moved Chrome 3.0.195.21 to the stable branch so that I can use it for production web sites at work. The stuff I run at work makes heavy use of JavaScript for large data sets and the Google Visualization. The move from 2.x to 3.x is certainly going to bring much needed speed improvements as well as stability improvements for those users really pushing their machines.

Glad to see them making these steps forward as opposed to the "perpetual beta" status.

One of my favorite web scripting languages is PHP. To me, it seems that it's right in the sweet spot of powerful yet fundamentally a scripting language. That means that it's much more lightweight for a developer than, say Java/JSP, and at the same time, more C-like than, say Perl. While there is a place for almost all of the web technologies in today's development environment, I have to say, PHP holds a really special place in my heart.

Because of that, I was thrilled over the years to see Marc Liyanage continue to produce a great PHP distribution with all the bells and whistles - including my favorite database - PostgreSQL. For the last several OS releases, Apple has delivered a PHP component to Apache, they leave out the PostgreSQL support that I need to do the few scripting-based web projects that I have.

Not Playing Well with Snow Leopard

But with the introduction of Snow Leopard - Mac OS X 10.6, Marc hasn't been able to build a PHP distribution that is compatible with the OS. So when I ran across this article about building the PostgreSQL support for PHP into the Snow Leopard Apache install, I had to jump at it for several reasons:

• It's low-impact. I don't have to get rid of all the suport that Apple has in it's PHP install.
• It's independent of Marc, so I don't have to wait on him to release compelte updates to PHP.

So it is with excitement that I venture off on my own to build the PostgreSQL support into Snow Leopard's Apache server and forever empower myself to keep PostgreSQL support in PHP as it ships from Apple.

Let's get to it!

According to the write-up, we need to set the bash variables:

  MACOSX_DEPLOYMENT_TARGET=10.6
  CFLAGS="-arch i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp"
  CCFLAGS="-arch i386 -arch x86_64 -g -Os -pipe"
  CXXFLAGS="-arch i386 -arch x86_64 -g -Os -pipe"
  LDFLAGS="-arch i386 -arch x86_64 -bind_at_load"
  export CFLAGS CXXFLAGS LDFLAGS CCFLAGS MACOSX_DEPLOYMENT_TARGET

but we can also use the tcsh variable scheme:

  setenv MACOSX_DEPLOYMENT_TARGET 10.6
  setenv CFLAGS "-arch i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp"
  setenv CCFLAGS "-arch i386 -arch x86_64 -g -Os -pipe"
  setenv CXXFLAGS "-arch i386 -arch x86_64 -g -Os -pipe"
  setenv LDFLAGS "-arch i386 -arch x86_64 -bind_at_load"

Then I get into the PHP 5.3.0 source code at: php-5.3.0/ext/pgsql/ and run the commands to build the module:

  phpize
  ./configure
  make

The end result being that in php-5.3.0/ext/pgsql/.libs/ there is now pgsql.so that's ready to be used with PHP. All we need to do is to copy into the right place: (assuming we're still in the php-5.3.0/ext/pgsql directory)

  sudo cp .libs/pgsql.so /usr/lib/php/extensions/no-debug-non-zts-20090626

and then edit the /etc/php.ini file to tell it about the addition. This is a two-step process, as we need to update the commented-out line:

  ;extension_dir=./

to:

  extension_dir=/usr/lib/php/extensions/no-debug-non-zts-20090626

and then add in the line:

  extension=pgsql.so

after all the Windows examples of loadable modules.

A quick restart with:

  sudo apachectl restart

and then the system is all ready to go!

Results

It's amazing to see the show up with the familiar 'pgsql' section:

And with this, I can dump Marc's PHP distribution and not have to worry about his updates any longer. The feeling of freedom and independence this gives me is really hard to express. It's fantastic!

UPDATE: this seems to be working, but when I look at /var/log/apache2/error_log I see a bunch of:

dyld: lazy symbol binding failed: Symbol not found: _PQconnectdb
  Referenced from: /usr/lib/php/extensions/no-debug-non-zts-20090626/pgsql.so
  Expected in: flat namespace

dyld: Symbol not found: _PQconnectdb
  Referenced from: /usr/lib/php/extensions/no-debug-non-zts-20090626/pgsql.so
  Expected in: flat namespace

when I try to run a simple PHP script to hit a PostgreSQL database and pull back a little data. I have a bad feeling that it's a 32-bit/64-bit issue as the libraries are most likely 32-bit and I'm guessing Apache2 is 64-bit from Apple.

Indeed... the file type of the libpq.5.dylib library in use is ppc and i386, but the pgsql.so is i386 and x86_64. But I'm betting that httpd is x86_64. This means I need to update to a 64-bit version of PostgreSQL for the Mac. Marc L doesn't have one. I wonder if that means I'm on my own, or if I can get something built for me?

[9/18] UPDATE: when I updated from PostgreSQL 8.3.0 by Marc L. to the 8.3.7-3 from William Kyngesburye, and repeated the build, the 64-bit (actually 32-bit and 64-bit) libraries were all I needed. The test page was perfect without any errors:

Well... I knew this wasn't a one-day job... in fact, it's liable to take a few more, but today was one of those days I didn't want to talk to anyone - I just wanted to get through these changes and get something out. It's maddening when someone wants to talk to you in this mode. I know they don't realize it, but this is like ripping off a band-aid - just do it and then it's done.

Yeah, today has been a day when I've been barely able to keep my head above water, and had to spend a ton of time working on the feature set expansion for this unruly app that I inherited. It should belong on the Daily WTF but if I sent it in, I'm afraid that I'd be giving myself away and that's no good. So I dove deep into the code and hammered on it as hard as I could for the day.

Today I started the laborious process of adding more than a dozen new calculated fields to this somewhat shaky web app that I've inherited. It's working, and that's the best and worst of it, really. If it weren't working, given all the improvements that I've made to the system, then there would be a greater push to replace it with something that's really much better. But it's running. Yet it's barely running, and that means that working on it is exceptionally uncomfortable.

But it's something I have to do, and so today I started the multi-day process of adding more calculated values to the system. It's going to take a few days to get it all done, but as long as I'm slow and methodical about the additions, I'll be able to do this pass nearly error-free, which is going to make it a lot easier.

Not fun, but no one asked me if it was going to be fun.

Today I spent the time getting all the new portfolio groupings into my web app prior to the second big push for the additional calculated values that will nearly complete the set of calculated risk values deliverable by the legacy risk engine. I wanted to get these groups in and stable and delivered to UAT before this so that it's one less "moving part" in the codebase.

It wasn't that bad, and I also added in a few alerts for Jeff so that the risk managers and portfolio managers can get these alerts as needed. The data is still a little rough, and it's possible to get a few false alarms due to the problems in the legacy risk engine, but it's the best we have at this point, and we need to get this in front of the users to force an increase in the quality of the data driving it.

So it's been a good day and I know I'm not going to look forward to the next few as it's the adding of the calculated values to the old app. Yeah... it's not a lot of fun. But I have to do it.

Today was the first day back from a nice, lovely, long four-day weekend, and it was tough. It was hard to get up, hard to get in to work, and a tough day of writing code that I personally think is a mess, but the time to re-write it is still in the future, so I have to fix this version.

I left the office beat down tired. I mean really beat-down-tired.

But it was a good day.

There's nothing quite like leaving it all, and I do mean all on the track. There's no doubt in my mind that there's nothing more I could have give to the cause today. Nothing. I can walk out of here, sleep on the train home, and know beyond a shadow of a doubt that there's nothing I could have done more today.

It was a really good feeling to have.

A good friend tweeted about this interesting collection of objects for Interface Builder 3. There seem to be a lot of very useful widgets in the collection, and I would love to spend a little time looking at these, as it could make development of a nice GUI quite a bit easier.

Until I get the chance, we'll just use this as a bookmark for the URL.

I was reading the lists this morning and noticed that Coda was updated to 1.6.5 to have Snow Leopard support and a few other fixes as well. Since this morning is my time to upgrade, it's a great thing they dropped this when they did.