Custom Software Development

I was very excited to read Adobe’s beta release notes about AIR 2.  AIR gives developers a very easy way to develop good looking, cross-platform applications.  The problem is that, in order to ensure all applications are cross-platform, Adobe was very stingy about how much you can reach out and interact with the underlying OS.

Those of us investing time in developing AIR apps have been working with one hand tied behind our back, unable to do simple things like even launch a document in MS Word, let alone utilize the thousands of shell commands available inside the OS.  (Well, there are various alternatives and hacks to do similar things, but still…)  Simple functions like burning a CD or encoding an audio file were simply not possible because the underlying libraries that perform these functions are not accessible within the AIR sandbox – even if those libraries themselves are cross platform.  None of the other major cross-platform environments have this limitation.  AIR was designed to connect to a server via HTTP in order to do these types of things, which is great for a web-based solution but not so for a desktop solution.  So AIR sometimes gets a bad rap as a a “widget” development platform that is good for eye candy, but not able to have deep interaction with the OS.

With AIR 2 Adobe decided to lift even more of the constraints and allow developer to execute native commands.  What this means is that we might start seeing very handsome AIR apps that serve as SVN front-ends, MP3 encoders, network monitoring tools, disk utilities, etc.   AIR will be able to interact with other software on the machine such as legacy enterprise apps.  I know this was not Adobe’s original vision for AIR, but  I have always thought otherwise and I’m very glad Adobe decided to loosen the shackles.  There are several other interesting improvements in version 2, but I think the native call feature has the potential to open the floodgates for enterprise developers.

With the new functionality comes the inevitable risk that some AIR apps will only run on one platform, or they may require you to install an OS-specific component in addition to the AIR application.  It will also be possible to build an AIR app that requires a certain Windows-only or OSX-only command.  However, thoughtful developers will at least be able to make that choice for themselves.

AIR 2 is out in beta now and end users will start seeing new applications when the public release launches in the first half of 2010.

The timezone functionality in Flex (as of SDK 3.4.1) makes me wonder if this is the person who designed this behavior.  It’s clear that the functionality was designed to magically handle the difficult subject of timezone and I appreciate that.  The problem is that, athough Flex goes through the trouble of calculating the UTC time automatically, you have no clean way to obtain input or display date values in anything other than the local system time.  So in order to display dates in other timezones, you actually have to enter incorrect UTC values and “trick” flex into showing the value that you want.  Additionally the remote server communication is very confusing and inconsistent with local (AIR) db storage.  The server has no way of knowing what the real value of your Date is unless you also provide it with the local clients current timezone offset.  Meanwhile, dates saved to a local DB have no timezone info stored with them at all.  Saving dates locally (AIR) can be downright dangerous if the system timezone changes while the app is open, including daylight savings changes.

If this is something that has caused you grief, I encourage you to vote for the issue to be fixed in the Flex SDK.

Read more

I’m setting up a new machine and found a great tutorial written by Josh Lockhart on getting a PHP web development environment up and running on Snow Leopard.  This goes through almost everything to be up and running for a typical LAMP stack with unit testing using all of the default services.

Josh’s instructions include everything that I need except mcrypt.  Luckily Michael Gracie has provided a walk-through for installing mcrypt on Snow Leopard which involves re-compiling some things, but isn’t as tough as it first appears.

After getting PHP and mcrypt going, the last step for me is setting up MySQL which has some caveats on OSX.  The main problem is that the MySQL installer places the mysql.sock file in a non-standard place and so you have to either create a link or alter your php.ini file before PHP will be able to talk to MySQL.  (If you get “Can’t connect to local MySQL server through socket ‘/var/mysql/mysql.sock’” or  “No such file or directory” when calling mysql_connect, then this is the problem)

Read more

One of our sync servers started throwing a “Fatal error: Allowed memory size of 16777216 bytes exhausted” when dealing with some large data sets.  We easily fixed it by bumping up the php.ini memory_limit setting.

It seems that the default 16Mb was a pretty low setting and it was probably inevitable that it would need to be bumped up. But it made me wonder why one server call would need 16Mb of ram.  It wasn’t due to a file upload, which is a common cause, so it must be something in our code.  Just bumping up the ram solves the problem for now but it always irks me to not know what is going on with the code.

I found an interesting article by Alex Netkachov that goes into detail about circular references in the code which is a definite possibility in our code because we use an ORM framework and access our data through a graph.  Due to the combination of data relationships and generated code it’s very likely we have circular references like this.  Paul M. Jones also writes about the same issue and illustrates a way to deal with it in your classes.

It looks like we will have to do some investigating to see what’s going on with the code and where the bottlenecks are occurring.  If you have any tips or utilities that you use for this type of thing, please post a comment.

I really like using iChat for IM but one thing that is a minor annoyance is having to click the “Accept” button when you receive a text invitation from an AIM account.  My preferred solution is to use Chax which offers a lot of other functions including chat logging.  However if you don’t want any of that stuff, in Snow Leopard you can configure iChat to auto-accept text invitations in the preferences.  On the “Alerts” tab of the Preferences, select the Event “Text Invitation,” check the box to run an AppleScript and select “Auto Accept” like so: