Recently I embarked on a quest to design a framework which would help us keep track of large and complex javascript projects in easily identifiable and extendable patterns. After some thought and deliberation, we eventually settled on the observer pattern using Ext’s Ext.util.Observable object as the base object to use in responding to event broadcasts and the Ext.ux.BroadcastEvents plugin for managing global event broadcasts.

Here is the code I came up with for common component elements:

I wrote this method the other day that takes a simple PHP object, inspects it’s properties and “prunes” empty ones. I wrote this method in order to compress JSON objects by removing null properties before sending them down the wire, a big problem when using base objects or models.

If you find this useful or a have a suggestion, feel free to let me know!

private function getStripped($obj) {
		$objVars = get_object_vars($obj);

		if(count($objVars) > 0) {
			foreach($objVars as $propName => $propVal) {
				if(gettype($propVal) == "object") {
					$cObj = $this->getStripped($propVal);
					if($cObj == null) {
						unset($obj->$propName);
					} else {
						$obj->$propName = $cObj;
					}
				} else {
					if(empty($propVal)) {
						unset($obj->$propName);
					}
				}
			}
		} else {
			return null;
		}
		return $obj;
	}

I’ve been telecommuting for the past 4 years and since it appears to be a growing trend, (indeed, the future of knowledge working) I figured it would be helpful to put down some of the more helpful tips I’ve learned for anyone starting out.

1. Connectivity

This might seem obvious, but having a good, reliable, and fast internet connection is absolutely crucial if you want to do any real work. Look for the fastest service available with a trusted provider. Don’t be afraid to shop around every couple of years to make sure you continue using the best provider. You’ll want something that can handle video and audio streaming.

sfInternalAdapter is a Symfony plugin I wrote while working on a large AJAX portal which reused a lot of JSON. In order to optimize the application’s preformance we decided to combine many of the services into one AJAX request but didn’t want to combine all of the server side logic. This plugin was developed to handle “scraping” the results of other Symfony actions in order to combine their results into the final call while still allowing the other actions to be called independantly if needed.

XML was the data exchange format that was supposed to be the Holy Grail of information exchange mediums. SOAP was a protocol built around it that was supposed to make web-based communication robust, flexible, and…

slow.

While SOAP has been widely adopted and used in web-based applications, and while XML has become the predominant information exchange medium, we’re finding out that they just aren’t as efficient as they could be. The main problem stems mostly from bloat inherit in the XML specification. In a nutshell, XML requires a root node and well-formed tags in order to make it “valid”. So the way you would send a simple name/value pair in XML would be:

I recently worked on improving performance in a labor scheduling application. The app was originally designed to load all the employees at one time in one large chunk, processing and stuffing the data into various places as needed on startup. This all worked fairly well on average stores with 50-100 employee records until we discovered several stores with 100+ employee records which caused the browser to display an unresponsive script warning due to the rather heavy pre-processing algorithms.

I’ve been tasked with speeding up a web 2.0 application based on ExtJS 2.2.0 that contains several routines that take up quite a bit of time and, because IE6’s javascript processing engine is less than stellar (In other words, it sucks pretty bad.), I needed to find a way to “speed things up”.

Enter Ext.TaskMgr, a helpful ExtJS object that is essentially a glorified setTimeout implementation that allows us to run tasks that don’t block execution. This means we can set our more expensive blocks of code to run later but return control back to the user in the meantime. It’s not true multi-threading, but it does allow us to make the user interface a lot more responsive and in an age when users think 5 seconds is an eternity, perception is everything.

Recently I ran across an interesting problem involving dates and timezones while working on a rich web 2.0 application whose primary purpose was to allow the user to enter time values that were then saved, as true date objects, onto the server (Which, in this case is JBoss and Oracle).

Up until now I have not used time values on both a server and client level, I’d referred instead to use a UNIX timestamp that the server (Database or web application tier) did not touch or, if they did, they did so with the client being the authoritative source.

Debugging an application today before launch I noticed a problem where it seemed to be parsing a specific time value (0900) incorrectly as (12:00 AM or ‘0000’).  During my search I ran across this oddity with the parseInt function of Javascript.

Apparently parseInt can also work with different base notations so it’s a good idea to specify base 10 in the manner parseInt(val,10) just to be safe if you are passing it numbers (such as time values) that may start with a zero and you don’t want invalid octal numbers (like 09) parsing to zero.

Today I had an interesting task of figuring out why a piece of code I’d written a few weeks ago for autosaving user changes wasn’t being called as uniformly as we’d thought.

That is, on IE6 and FF, we were seeing a particular piece of code take almost twice as long to execute as it ought because (as we later found out) timings in javascript can’t be trusted.

So, if you need something to run on time, at regular intervals; use a polling pattern instead of relying on the usual javascript methods.