While continuing to work towards a release that's Snow Leopard compatible, the Cyberduck team has released 3.3b3 and it's getting closer. I haven't had a real need to check on Cyberduck, the upgrade to Snow Leopard made me take an active interest in the app's compatibility. It's nice to see the progress is still being made.
Gus at Flying Meat is really moving forward with fixing the bugs in Acorn with 2.0.2 released this weekend. The list of fixes is impressive, with a lot of crashes fixed and a few UI improvements as well.
It's great to see the Snow Leopard adoption going so well in the development community.
With the problems I had getting PostgreSQL support in PHP, and the desire to take control of my toolset, I went looking for a 64-bit version of PostgreSQL rather than resort to building it myself. What I found was that William Kyngesburye (a.k.a. KyngChaos) maintains a dual-build of PostgreSQL - i386 and x86_64 that's even Snow Leopard compatible! Marc seems to be out of it, and even the EnterpriseDB guys have no plans for building a 64-bit version.
While I don't need a 64-bit version per se, I do need the 64-bit libraries and this was an easy way to get them.
The upgrade was pretty easy - dump the database, move/remove the old install, and then follow the package installer. It should "just work", but it was missing the launchd file. I found something close to it on the net, and just fiddled the parameters to make it work:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>PostgreSQL</string> <key>UserName</key> <string>postgres</string> <key>RunAtLoad</key> <true/> <key>EnvironmentVariables</key> <dict> <key>PGDATA</key> <string>/usr/local/pgsql/data</string> </dict> <key>ProgramArguments</key> <array> <string>/usr/local/pgsql/bin/postgres</string> <string>-e</string> <string>-i</string> </array> <key>StandardOutPath</key> <string>/usr/local/pgsql/var/logfile</string> <key>StandardErrorPath</key> <string>/usr/local/pgsql/var/logfile</string> <key>ServiceDescription</key> <string>PostgreSQL Server</string> </dict> </plist>
Once I created that file as /Library/LaunchDaemons/org.postgresql.postgres.plist, I was ready to go. The instructions in the package work perfectly for starting it up, but now that I have the file there, the installer is supposed to restart PostgreSQL.
Once I had this installed, it was a simple matter of rebuilding the pgsql.so file using the provided libraries and it worked like a champ!
Now I feel I can move forward with this guy's PostgreSQL packages and making the PHP library each time I upgrade. Not a bad place to be.
[9/20] UPDATE: well, when trying to upgrade the PostgreSQL on my 20-inch iMac with 2GB RAM, I got a ton of errors about the SHMMAX value not being large enough to complete the operation. Basically, PostgreSQL wasn't able to get the shared memory to complete the operations. I did a bit of googling and found this post about setting the SHMMAX value.
When I set the SHMMAX sufficiently high, I was able to get the initdb command to work, and then I had to set these parameters in the startup by creating /etc/sysctl.conf which is read by the 10.4+ kernel on initialization. The file contains:
kern.sysv.shmmax=1073741824 kern.sysv.shmmin=1 kern.sysv.shmmni=32 kern.sysv.shmseg=8 kern.sysv.shmall=1073741824
and after a reboot, I was able to finish the migration by loading up the database and things were working perfectly. I then compiled the PHP PostgreSQL extension and added it to the config and all was working quite nicely.
Quite an adventure!
Well... everything costs. Pretty darn true. Not a lot in life is free, and that which is most of the time only seems free at the time. So it's not at all surprising what happened today.
I'm a Band-Aid Ripper. When I have a task that I know I'm not going to like, I try to steel myself to the pain, and then just rip. Get it done. Get over it. Move on. There's no reason to draw out a painful process to make it long and painful. It's enough that it's painful. Rip it off.
In all honesty, I didn't use to be this way. I was scared - plain and simple. I hoped, like all kids, I guess, that if you do it slowly, there won't be any pain. All the pain, you hope, is in the ripping. But that's not the case, is it? Nope. In most cases, that band-aid is stuck, and it's going to be painful to get it off. So it's just up to you to take it off on your terms.
So I've been working for the last several days on adding a few calculated values to this application that I have inherited at my new job. It's not what I'd have written. In fact, I look at it and I think there's just about nothing I think that was done right. It's a mess. Plain and simple. Even the original author has called it "crap", "a hack", and not once or twice.
But I'm able to make it work.
So there's no need to rewrite it. It works. So when I had to work on it, I knew I had to attack it... get into it, get it done. The longer I stayed working on it, the angrier I was going to be. But why?
To give you an idea, to add the 10 or so calculated values I had to add over 5,000 lines of code - totaling nearly 500,000 characters. Just to add a few fields. The problem is in the way it's structured - lots of interfaces and objects - but all functional in nature and none really encapsulating the reporting behavior. This means that when I have a report that looks at a certain variable trading during the day, there's going to be an opening value, a trading value and a net value. Rather than create a object for this, there are three values passed around the code.
Add to that, we might need to difference these, and we get nine values: open, trading, net, and then initial, final, difference. If I add 10 variables, then I'm really adding 90 arguments to many methods.
It's not good. It just wasn't designed properly for what it was doing. But I got it done.
After I got this all done, I had a meeting with my manager. Basically, he believed that there were two ways to go about doing this:
I wanted to say that Fantasy Island is a nice place to live, and I'd love to visit him there, but I didn't. What I said was that I'd try harder to keep my mouth shut, and not give off the wrong impression.
But is it really the wrong impression, or just an unpopular impression? I have no doubt that I'd love to be happy when working with all the code I have to work with. I don't enjoy getting upset at code, or developers, but when I have to extend code and the number of arguments to a method exceeds 255, then there's something terrribly wrong with the code and it needs to be fixed.
But if it's not outwardly broken, why fix it? There's no business motivation for it. It's working, after all, it's just a complete mess.
So I'm left with a manager thinking I'm making the active decision to be unhappy when I'm just responding to someone doing a horrible job and being held up as a paragon of development virtue.
I'm left thinking about the experience and wondering if Liza's not spot on when she says this happens with every place I work. That my expectations of others are far too high for mortals, and while it's less than I demand of myself, the vast majority of people simply fall far short of my standards, and these problems are bound to arise. I don't think I'm that demanding. But I can certainly see her points.
I'm in an industry where developers are paid a ton of money. I mean a ton. If you're making in the six-figures annually, then by golly, you had better be giving it your all every day - or at least more days than not. That's a ton of money, and you need to be worth it. There is no free ride.
So I do get a little miffed at these guys making this money and not feeling compelled to fix up their messes. Far too many developers write something and hand it off never to think about it again. Where's the pride in what you have created? Where the dedication to your craft that you'd hand off such crap and call it "done"? Clearly I come from a different time. Which leads me to the ultimate question: Where do I belong?
I'm coming back to the thought that I need to be on my own. Writing software that meets my standards. It's not easy, and consulting is the easiest way to make the transition, but that leads to a lot of consulting and not a lot of your own code getting written. No, I'm thinking it's time to start planning on getting out on my own. I've toyed with the idea for a long time, but never really had a motivation to make any real, concrete steps. Maybe this is showing me that I need to go out on my own.
There's the money. That's #1. I know what I need to do -- write code, push it, and get some sales going. After a few apps making $50k/yr, I'll be able to think about going it alone. I know what I need to do, I just need to do it.
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.
This morning I saw that Flip4Mac WMV - the free add-on to QuickTime to view Windows media files, had a new beta that was Snow Leopard ready. I tried to get it, but the disk image wasn't mountable, and submitted a 'ticket' to them. In a few hours, they had a new download file on the site and it worked just fine.
This guy had a 64-bit Pref Pane, which was nice as all the others I have are all 64-bit and I didn't want to fall back to the 32-bit System Preferences app. With this, I get what I need. Nice.
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.
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:
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.
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!
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:
While I'm a big fan of Google Chrome on Windows at work, I haven't really been that excited about it coming to the Mac. Face it, Safari is WebKit, so there's not a lot that is in Chrome that I don't already have in Safari, but it's nice to see the progress, anyway.
Today I noticed that they had dropped another release of the 'dev' branch at 4.0.207.0 and so I got it just to check it out. I have to say, it's a little behind Camino, which is behind Firefox and then Safari - to me. Buttons aren't rendered right, and this is on the Google home page - of all places. So I think they're still looking at the big issues and not yet interested in looking at the things like how something is rendered.
Thankfully, it's making progress, but I don't have to depend on it.
OK, it looks like NetNewsWire 3.2b25 is out, and simply postpones the adds for another week - no other new functionality or fixes - though they are reported to be in the works. And I'm not at all sure how I feel about this. Sure, it's nice to have a free, stellar, RSS reader on the Mac - a rising tide raises all boats... but I paid for NetNewsWire, and I hate adds. So what's the ultimate solution going to be?
Am I going to have to have a subscription? I'd rather go back to paying for the app. I'm not at all interested in seeing adds, and I don't mind paying for the app, but a subscription service for an app is something that rubs me the wrong way.
I guess we'll see in a few weeks. Hope it's something I can live with.