We are upgrading. The site software has been upgraded to the latest version of Drupal (version 6.2) and we are working on updating the theme. In the meantime we have reverted to using one of the core themes.

Ran into a problem when I was maintaining a customer's site today. They wanted to upload 10 - 20 MB movies as attachments to their Drupal blog posts. The standard limit set in Drupal is 2MB. I changed the setting to no avail. There was a note at the bottom stating that my PHP settings limited the upload to 4MB. So I did a search and come up with this post. So I changed my upload_max_filesize setting to "20M" this still did not work. The problem is that PHP also limits the post size and my default config limited post size to 8MB.

In a world where AJAX is becoming the norm instead of the exception we need technology platforms that allow us to scale these applications. I have been working on an application for a major hotel chain that is used by their call center agents to book reservations at their hotels. The application uses AJAX techniques to run several queries simultaneously and presents the data in a very dynamic interface that closely resembles a traditional desktop application.

I have started fooling around with the iPhone SDK. I am planning to release a product soon but the plans are quite preliminary so mums the word on exactly what is coming. However, I ran into a little problem right off the bat.

For the most part, Mac OS X programs do not use environment variables or the PATH. They behave in a very different way from other Unix environments on this score. However, as Java developer I use several tools that require that other command line programs be available on the system PATH. In Windows and Unix there are well known places to put this kind of information but in Mac OS X the location for these changes is obscure.

It seems there is a bug in WAS that was introduced with 6.1.0.3. I found this forum post on the subject.

Apparently, WAS looks for a resource in the WAR that matches the URL before allowing the servlet filters a chance to process the URL. Despite the fact that the design of the Servlet Filter mechanism is to allow web applications more control over their URLs and how they are accessed.

This affects all servlet filters not just Acegi's. IBM has had similar issues in the past like this one and this one. You'd think they could get it right after a few tries.

Well I figured out what was causing my IE Rendering problems. I was using a "code" tag and that seemed to throw off the floating of the right hand navigation elements. Weird but it looked great in Firefox. This is not new but, damn I wish IE would just implement the standards. Perhaps a meta tag could be created that tells IE to use a standards compliant interpretation of CSS and HTML. That way, a standards compliant web site can just add a meta tag and IE will render it correctly without all the weirdnesses that are left in for "backwards compatibility".

For a great site on the power of CSS check out the CSS Zen Garden.

I am aware of the IE rendering problems this site is experiencing and I am working on the issue. Thank you for your patience.

I am always looking for ways to limit the amount of typing I have to do. Hibernate helps me alot because I don't have to write all the SQL and I can concentrate on the less tedious aspects of designing my persistence model. Spring helps me alot because I don't have to write all those factories and other "glue" code.

In the interests of getting more done quickly, I started looking at how I can automate the generatin of the DAO pattern. Data Access Objects allow the service or session facade layer to be agnostic to the persistence layer used. As I have already said, I use hibernate but there might come a time when I need to use some other persistence layer and by keeping all the persistence layer specific code behind the DAO pattern, I can easily switch it out. I also love the fact that I can use jMock to test my service layer components without fooling around with actually changing database tables.