PostgreSQL Build Script

I’m currently working on a Cocoa project. It requires a server-client system. The current iteration of it uses a very complicated Distributed Objects system to send query objects across the network to a single instance of SQLite… and it’s rather flaky if I do say so myself. So I have decided to change it to a PostgreSQL system.

Obviously, however, PostgreSQL is not a standard component of Mac OS X–especially not a universal binary version. So, I had to devise a way to create a packaged version.

After fiddling with build settings for hours, I have come up with a shell script to build a universal version. It is meant to be run on a PPC platform to cross-compile for i386/Intel–not vice versa (though with a bit of modification you should be able to do it).

If you’re interested, you can download it here: build-pgsql-uni.sh (4KB)

And if you’re still interested, my application works like this: the server will broadcast over Bonjour a Distributed Object connection, as well as spawning this special distribution of PostgreSQL. The client will accept this and will receive a NSUrl with the database connection URL and then the rest will be handled by BaseTen. I think this will significantly improve the performance, and it will decrease code base size because I can use Cocoa Bindings.

New Type of Redesign

When I normally think of redesigning a site, new color schemes and layouts are usually the first things that come to my mind. However, when I decided to spruce up the Blue Static website about a week ago, I wanted to pose myself a design challenge: I did not want to use anything but existing design elements to create my refreshed design.

To accomplish this redesign, the first thing I did was I found and isolated the elements and colors that I liked the most. Some people say that a good design starts out in black and white and then colors are added so that it’s color-agnostic. However, I find that when I’m designing–both for print and the web–if I don’t have a vague idea of the final color scheme, the design just won’t work. So I picked a few elements (namely the striped background and the navbar) to reuse all over the place. I then went to work on a design on paper.

Any good designer will start out on paper just to get a rough idea of how things should look. I have paper designs for Bugdar, Kalens (the demoed calendar product), and this website and the paper looks almost identical to the web version. Designing on paper is important because it allows you to visualize your design without having to write any code. Can you imagine creating an entire website and then scrapping it because you don’t like the way it looks?

I feel that whenever you are _re_designing something, you’re doing it because you did something wrong with the current design. Therefore, before I finalized the paper design, I decided to go through the old website and pick out elements I didn’t like and I made sure I addressed them in the final design. What didn’t I like about the old design? The navigation bar was far too large, so the new design cuts out about 80px of it; many of the banner images had a greenish color which really jarred with the blue, so now the images have all been hued to a more bluish tint; the text was too low-contrast, and so I changed the background to be white.

And when you look at the final design, those are really the only major changes. Everything else has just been ever-so-slightly lightened to make the design more welcoming (darker designs are generally harsher too look at).

Here’s the before-and-after shot: bluwww-redesign-dec06.png (172 KB)

So what’s to learn from this redesign?

1. Keep your design goals clear.

2. Do your layouts on paper first.

3. Don’t change things that don’t need to be changed.

On a side note, Bugdar 1.2.0 is coming along steadily as is ISSO3. I hope to have both of those finished by late April or early June.

Bugdar 1.1.4 Released

While others may be taking the day off for Thanksgiving, I’m seizing the opportunity to get 1.1.4 out the door. I’m tremendously thankful for all the people who have sent bugs and feedback to me because it’s really helping Bugdar’s evolution and future development.

For those of you who use the SVN sources, I’d like to point out that the 1.1.x line has now been branched (branches/1.1.x) as the 1.2.0 release is now going to be developed on the trunk.

Happy Thanksgiving to those of you in the U.S.!

New Product Ahead!

If I’ve been quiet on the Bugdar front, it’s because Kalens has been under heavy development the last couple of weeks and we’re approaching Beta 1 after weeks of alphas.

Kalens comes from the Latin word for “calendar” which should make the function of this new application easy to discern ;). Kalens, however, is unique because besides having an amazing interface (which I’m still polishing up), it is very AJAX-y through a nifty JavaScript library called jQuery which provides very easy cross-broswer working animations and such.

So I figure the best way to show you parts of the interface is through a a movie (~2.7 MB).

Of course, this is released under the GNU GPL and the source code tree can be found here. Please feel free to check the code out, but at the moment it does not have any installer (though you can find the schema files in the docs/ folder).

Enjoy! Beta 1 should be released for public consumption within a week or two.

Updates Ho!

Hot on the heels of 1.1.0 is going to be 1.1.1. There have been a few bugs reported that need to be addressed sooner rather than later, so after I get a few more reports (I’m waiting on a couple) I’ll hopefully release 1.1.1 sometime later this week or early next week. So keep your eyes on the website or on the version checking feature in the Admin CP.