Fusioncube

The online journey of a technophile, by Steve Brownlee

Archive for October, 2007

Management by Humiliation

  • Filed under: errata
Wednesday
Oct 31,2007

I’ve been buried by work lately, as the current project is in a serious time crunch. During this time, however, I’ve been reflecting on what a huge difference the workplace can be depending on what type of people are managing the process.

In my last job, my manager, the CTO, managed people by asserting the following traits:

  • Availability – He always made time to talk about your work
  • Humiliation – He made examples of people by picking apart their code and mildly ridiculing them in front of others
  • Completeness – All issues were rigorously examined and adequately planned, and plentiful tools /processes were in place to ensure efficiency
  • Defensiveness – Any display of superior ability or ambition was squashed in effort to assert his authority
  • Fairness – Everyone was treated equally, whether the treatment was positive or negative
  • Detached – An unattainable level of robotic performance was expected – whether speaking about issues, or delivering work

Some good traits, some bad traits.

In my current job, things are handled differently. Again there are good and bad issues.

  • Support – As long as people work hard, any slip in the deadline of a project is handled professionally and clinically without blame being placed
  • Chaos – A huge void in tools and processes makes efficient use of time virtually impossible
  • Accountability – People are held accountable for their work and any failure is handled justly and appropriately
  • Micro Managing – Constant interruptions and focusing on minor issues disrupts a steady flow of work being produced
  • Fairness – Everyone is treated equally well (a core value of the company is Fun – that’s right, a core value)
  • Infrastructure – The availability and performance of the network , servers, and monitoring staff is, in my opinion, unacceptably poor

Weighing the pros and cons of each company, I’d much rather work for my current employer even though there are days I’d easily strangle people with a smile on my face, and then go have a great night’s sleep. However, the number of days that I leave content and even happy are far greater. Different strokes for different folks. There are people who have been working at my previous employer for over 7 years and have no plans on leaving.

As to the title of the post, I’ve often wondered what leads a person to believe that humiliation of the staff is a truly effective way to motivate them.

Powered by ScribeFire.

Enhancing ajaxCFC for Custom Error Handlers

Thursday
Oct 4,2007

Straight “out of the box” error handling functionality in the jQuery version of ajaxCFC is solid, but basic. The attribute useDefaultErrorHandler defaults to false, and when an error is thrown up to ajaxCFC, two things are done.

The error is caught and handled in the __initialize_AjaxCFC() function which, in turn fires the alertError() method. If the debug setting is enabled, then the error is logged by ajaxCFC, otherwise a Javascript alert is produced.

if (jQuery.AjaxCFCHelper.getDebug() == true) {
	log.error('Type: #jsStringFormat(arguments.objError.type)#, Message: #jsStringFormat(arguments.objError.message)#, File: #jsStringFormat(arguments.objError.TagContext[1].TEMPLATE)#:#jsStringFormat(arguments.objError.TagContext[1].LINE)#');
} else {
	alert('An error has occurred:\nMessage: #jsStringFormat(arguments.objError.message)#\nFile: #jsStringFormat(arguments.objError.TagContext[1].TEMPLATE)#:#jsStringFormat(arguments.objError.TagContext[1].LINE)#');
}

However, in my applications, I prefer the user not see generic, unintelligible error message in Javascript alerts, so I set useDefaultErrorHandler to false when making ajaxCFC calls. Then I can use the built-in success() and error() methods provided by the library. Here’s an example.

$.AjaxCFC({
	url: "model/ajax/custom/package/Component.cfc",
	useDefaultErrorHandler: false,
	method: "method",
	data: { 'argument':value, 'argument':value },
	timeout:15000,
	success: function(results) {
		successfulMethodCall();
	},
	error: function(results) {
		failedMethodCall();
	}
});

However, I was still seeing the Javascript alert produced by ajaxCFC, so I added another condition to the alertError() method code. It checks to see if the useDefaultErrorHandler property was enabled, and if so, bypasses throwing up the alert or logging the message.

if (jQuery.AjaxCFCHelper.useDefaultErrorHandler == true) {
	if (jQuery.AjaxCFCHelper.getDebug() == true) {
		log.error('Type: #jsStringFormat(arguments.objError.type)#, Message: #jsStringFormat(arguments.objError.message)#, File: #jsStringFormat(arguments.objError.TagContext[1].TEMPLATE)#:#jsStringFormat(arguments.objError.TagContext[1].LINE)#');
	} else {
		alert('An error has occurred:\nMessage: #jsStringFormat(arguments.objError.message)#\nFile: #jsStringFormat(arguments.objError.TagContext[1].TEMPLATE)#:#jsStringFormat(arguments.objError.TagContext[1].LINE)#');
	}
}

Now I can handle any error with custom Javascript code inside the $.AjaxCFC() call, but what about keeping a history of errors? I always maintain a log of errors produced by my application, but I never use Javascript to do so, I use the tag.

I needed a way to have built-in error handling accessible to any of my components that extended model.ajax.ajax. My solution was to add a method to the Ajax component that would accept two parameters – the name of the log file in which to log errors, and the cfcatch object. I could then log all of the attributes of the error with one simple call.

<cffunction name="logError" access="package" output="no" returntype="void">
	<cfargument name="logFile" required="true" type="string">
	<cfargument name="caughtError" required="true">

	<cfloop collection="#arguments.caughtError#" item="errorKey">
		<cfif isSimpleValue(arguments.caughtError[errorKey])>
			<cflog file="#arguments.logFile#" type="error" text="#errorKey#: #arguments.caughtError[errorKey]#">
		</cfif>
	</cfloop>

	<cfset throw(arguments.caughtError.type, arguments.caughtError.message, arguments.caughtError.detail, arguments.caughtError.errorCode, arguments.caughtError.extendedInfo)>
</cffunction>

Adobe Thermo and Devnet

Wednesday
Oct 3,2007

I really wanted to go to MAX this year.  There’s a lot of new tools that have either been released or are in development that I find exciting as an RIA developer.  In lieu of going, I’ve been scouring the blogosphere for update from the attendees.

Thermo

For those who haven’t heard about it yet, Thermo in currently in Adobe Labs, and is a design tool that will also create a workable application from that design.  Definitely something I’m going to play around with.

Labs Page
Demo from MAX

Adobe Devnet

Adobe also recently unveiled the Adobe Developer Connection. A central portal for resources for all their development tools.

Ext 2.0 Alpha Announced

  • Filed under: ajax, tools
Monday
Oct 1,2007

This is going to be an amazing release, and this preview should be enough to convince you. I’m currently using the 1.1 release for an application, and I can’t wait to use some of the 2.0 feature in the future. For me, the Web Desktop is the most impressive.

http://extjs.com/blog/2007/09/06/ext-20-a-preview/

Latest Tweets

  • Watch video on this page to see a quick shot my family's biz and a heapin' helpin' of Pittsburghese - http://bit.ly/aMxuLN
  • Ever wonder how insignifcant the Earth is on a cosmic scale? http://bit.ly/PV4o
  • How did I miss this highlight??? Hasek takes out Gaborik http://su.pr/1KZtN2
  • Rooted & upgraded my HTC Hero w/#Froyo. Holy shit is it faster and have improved features. Painless, too. http://bit.ly/cBjvuH #fusprint
  • @Antipimp You will do what Father Jobs tell you to do, peon.