Mike Schierberl's Blog

varScoper 1.30 release with CF Builder extension

Mon, 27 Jul 2009 22:29:00 -0700

varScoper 1.30 is now available to download on RIAForge. This release fixes over 17 reported issues and also works properly on both Railo and OpenBD. Additionally, Raymond Camden's ColdFusion builder extension code has been integrated. Hopefully the consolidation will make life easier for everyone. You can either install the zip, or import the extension if it's already unpacked. In case you haven't used it yet, this feature allows you to right click on a file or folder in CF Builder and run varScoper directly from the IDE. At the moment, this release will not correctly identify variables based on CF9 syntax (LOCAL scope and ability to identify var anywhere in a function). The test cases are in place and I'll be working on it soon. As a result you will notice the unit test will throw an error if you aren't running cf9. Thanks again to Ray, Pat Santora, and everyone else who has reported issues. If you have any problems, please report them at RIAForge and I will get to them eventually.

I'll be at webdu on Thurs/Fri

Mon, 18 May 2009 15:34:00 -0700

I'm excited to say that I'll be attending webdu here in Sydney on Thursday and Friday this week. Looking forward to an impressive lineup of speakers.

I'm new to Sydney, so please don't be a stranger and introduce yourself, here's a picture of what I look like.

Also, I just found out about code-wars as well, not sure what to make of it, but sounds like a blast, I'll see you there.

Moving to Sydney

Wed, 06 May 2009 14:20:00 -0700

At 10:30pm tonight I will be getting on a plane to relocate to Sydney, Australia. The bags are packed, and I'm looking forward to the next exciting chapter in my life. As of Monday, my company was acquired by Thomson Reuters, and I will be working as an independent consultant for them.

I'm looking forward to getting involve with all of you in the CF community when I arrive. Don't be a stranger, please introduce yourselves as I hardly know anyone there. I'm really hoping that I can win a pass to @webdu in their twitter competition, it would be a great opportunity to make some connections. If you're on twitter I wouldn't mind a shameless plug for a ticket :) (@mikeschierberl).

Additionally, if you are in Sydney, I'd love recommendations on things to do/see from a locals perspective. I've been there a few times, but I will be coming with a clean slate and an open mind.

Deploying cached CSS and JS with Ant

Mon, 09 Feb 2009 14:49:00 -0700

If you are using YSlow or an equivalent tool you're probably aware of some of the best practices to follow to optimize client-side load times. In this post I'm going to outline a quick and easy approach that we use at Planitax to deploy static content using Ant. The best practices that I hope to address with this build strategy are...
1) Add an Expires or a Cache-Control Header
2) Minify JavaScript and CSS Both of these are pretty straightforward, but it's easy to run into problems when deploying updates to content that might have an expire date in the future. You might run into this problem when you make changes to js, css, or images in your application. If a browser has cached content locally, the user might see stale images, or worse yet experience errors due to out of date javascript or css files. When we developed a deployment strategy we wanted an approach that was transparent to the end user, easy to build, and had minimal impact on developers checking in code. We needed to meet the following criteria.

Content should be able to have a Expire date at any point in the future
Content can be deployed to QA/Production at any time using a one step build
Webserver should automatically apply expires headers to static assets without additional deployment steps.
Developers should always be able to check into a single repository location. Branching/Deploying should not require a copy of a file to be checked in.
Developers should not be required to run a build target in order to see changes to static content.
js/css should be minified on production deployments, but not in the source code repository.

From these requirements we came up with a strategy that looked something like this.

Static assets that can be cached will always live in the /assets folder off the application root. Content will be organized into subfolders for /assets/js, /assets/css, and /assets/images.
Developers will work with expires headers turned off for these folders so changes will appear immediately.
Developers will check files in directly to this location. The repository location will always be /assets.
When deploying to QA/Production, a copy of the static assets will be created with a new version identifier. This copy will also be minified as part of the deploy step.
The application will be able to determine the correct copy of static content to use regardless of the deployment environment.
QA/Production web servers will automatically add an expires header to any content located in the /assets folder.

The first step was to build an ant target that would take care of creating a new folder, copying the assets and minifying content appropriately. We use JSMin to minify our JS. In order to execute this example you will need to download the JSMin Ant Task from Google Code. Note, when setting up your taskdef, the classpath attribute should point to the relative location that you have saved the .jar file. For this example it will be in the /lib subfolder off of root.

This code creates a folder with a name that looks something like this... ./assets/js200901141546 , it's named this way so we can do alpha sorts easily as you will see in the next step. We don't check this folder in to source control. Note: You can adapt this code for css or images by modifying the copy command, if you only need to copy/minify JS you might be able to get by without the copy command. The next step is to make your application aware of the correct folder to be used. This is easy to do with a cfdirectory based on the naming convention we used above. First we will create a variable that identifies the most recent/current folder created by the name that contains the timestamp. The nice thing about this is that it will identify the correct folder for prod servers as well as developers who only have a ./assets/js folders. It does not require developers to run the build target in order to see changes.

The only tricky part is to make sure that all your links to assets include the new variable that you have created. Your links will look something like this...

I'm sure there are countless ways to approach this, and your deployment strategy may differ significantly based on your environment, and or application. I'm interested to see how others have approached this and other deployment tasks.

Thread safety and the var scope - live example

Mon, 21 Jul 2008 17:18:00 -0700

Recently, I've talked to a few developers who knew about the var scope, but didn't quite grasp the concept of making a variable local to a function. Additionally, I've come across a few posts that indicated that setting a var statement was strictly to conserve memory (along with other reasons that missed the point). To help anyone struggling with understanding the impact of the var scope I've put together a quick example to demonstrate what can happen when you improperly scope a variable. The example here focuses on CFCs that are loaded into a shared scope (session, application, etc), and are accessed simultaneously by multiple users.Running the code will make 2 simultaneous requests to the same function in separate iframes. The example contains a loop that outputs the index of a loop from 1 to 100. If the loop executes correctly the numbers appear in green, if the numbers are out of sequence, they will be red. To make the results more dramatic I've included a 1-40ms pause in each loop iteration. run example with var statement
run example without var statement

Here's the cfc that is loaded in server scope (simplified for reading). Note the only difference in the functions is that the "count" variable has a var statement in one function and doesn't in the other function.



	
	
		
		
		
		
		
		executing "nonVarFunction()"

		
		
			
			
			
			
				
				   
				   #count#
				
				   
				   #count#
				
			
			
		
	
	
	
		
		
		
		
		
		executing "VarFunction()"

		
		
			
			
			
			
				
				   
				   #count#
				
				   
				   #count#

What happened? If the example executed correctly, you should have seen all green numbers in both windows for the var scope example, and a mix of green and red in the example that executed the function without the var statement. The presence of the "var" statement makes the variable local to the function. This means that when the function runs, it creates a new instance of the variable that is unique each time the function is executed. Without the var statement in place, the variable gets "shared" between everyone who is accessing this component. When a component lives in a shared scope (session, application) the variable will be shared for everyone accessing that scope. Think of the following scenario. User 1: set count = 1
User 2: set count = 1
User 1: set count = count + 1
User 2: set count = count + 1
User 1: count = 2
User 2: count = 3
In this case the developer most likely intended to have both users see count = 2, however the variable was shared and as a result a user's result was impacted by another user's request. Note: this may be the intended behavior of the code, and that's why there is no definite rule on why you should "always" or "never" var scope a variable. Unfortunately, recognizing issues that appear as a result of improper scope can be difficult. Many times they result in server errors that are intermittent and only appear under load. This can sometimes make it practically impossible to reproduce the error in a test environment. Also, many tags create variables that are easy to miss (cfquery, cfloop, etc). Luckily, there's a tool to help (shameless plug here). Take a look at varscoper. Hopefully this will become an integral tool in your development process.

New varScoper release candidate

Wed, 25 Jun 2008 18:12:00 -0700

A new release candidate is available for my varScoper tool.

varscoper_1_30_RC.zip

Please download and run against your code. If you find any issues please report them at RIAForge.

Thank you to everyone who provided feedback on 1.21. At least 16 bugs were identified and are now fixed in the RC. All reported issues and corner cases have been added to the unit test to ensure that it won't break the same way in the future. Additionally, thank you to Pat Santora, who was responsible for a majority of the fixes.

Finally, based on feedback, I've included a cfset statement generator to generate blocks of cfset var statements. However, I take no responsibility for the consequences of using this generated code.

quick varScoper update

Thu, 22 May 2008 09:37:00 -0700

Version 1.21 of varscoper is now available to download . This is a minor update that fixes some of the CF6, CF7, and *nix issues that were reported when I released 1.20. Additionally, there was a minor fix to cfscript parsing when using a function inside a struct set. Something similar to this...


mystruct[someFunction()] = "";

varScoper 1.20 - critical update

Tue, 20 May 2008 22:17:00 -0700

Version 1.20 of varscoper is now out on RIAForge. It's also available directly from the download link.

Many thanks to Pat Santora for this release. The majority of the content in this release is a direct result of his hard work.

Updates

Improvements to cfscript parsing engine
- RIAForge issues 6,7,8,9,10,11 are fixed
- Improved handling of script comments
Ability to exclude files/folders
- configured through properties.xml
- Ability to exclude individual files or directories from your search
Integrated Unit Testing
- testCaseCFC.cfc now includes positive/negative test cases for all reported issues
- Currently still reporting 2 known issues that will be addressed in a future release
Improvements to parsing engine
- Fix for Ray's cffeed bug (also fixes cfprocparam)
- More agressive var scope checking (re-run against all your code, we found 2 new unscoped vars at Planitax)

Minor update to varscoper

Thu, 06 Dec 2007 12:44:00 -0700

I just released a 1.12 update to my varscoper tool. I've added new tags to the parsing engine, added XML output support, and fixed some bugs related to directory parsing in CF6. Thanks to Kola Oyedegi for help with XML output and Dmitriy Goltseker for fixing directory processing. Thanks to everyone who helped to refine the list of tags that create variables. The additions are below. You can also download 1.12 here , or get it via SVN on riaforge.

cfhttp:result
cfquery:result
cfimage:name
cfmail:query
cffeed:name
cffeed:query
cfftp:name
cfwddx:output
cfobject:name
cfsearch:name
cfprocresult:name
cfpop:name
cfregistry:name
cfreport:name
cfdbinfo:name
cfdocument:name
cfexecute:variable
cfNtAuthenticate:result
cfcollection:name
cfpdf:name
cfxml:variable
cfzip:name
cfldap:name

Can you name all the tags that create variables?

Mon, 22 Oct 2007 16:44:00 -0700

As part of the development effort on my var-scoping tool I have been trying to identify all of the tags that can create variables. I have yet to find a comprehensive listing of tags, so I'm hoping that people can leave comments here to expand the list.

Here's my partial list to start with (yes I know it's small), along with the parameter that specifies the variable name. Please comment on my blog and add on any that I've missed.

cfloop:index
cfloop:item
cfquery:name
cfinvoke:returnvariable
cfdirectory:name
cffile:variable
cfparam:name
cfsavecontent:variable
cfform:name
cfstoredproc:name
cfprocparam:variable

varScoper 1.1 - now with cfscript parsing

Sun, 07 Oct 2007 19:43:00 -0700

That's right, my varScoper tool now supports cfml written within cfscript blocks. Please note that this is still somewhat experimental, but seems to handle quite a few scenarios.

Click here to download the 1.1 code.

Here's a link to the project page.

Many thanks to Zac Spitzer who is responsible for writing the code to identify var statements within cfscript. He completed the cfscript var statement support as a response to this post.

After looking at Zac's code, I decided to take it to the next level and complete the code required to identify variables created within cfscript blocks.

The code will even ignore variables created within comments, but unfortunately does not include the ability to identify the line number of the variable (which it does within tags). You can still jump directly to the method, but you're on your own to find the variable.

You can even identify variables created within for loops and if/else blocks. Here's an example...


for(correctLoop=1;correctLoop LTE 10; correctLoop=correctLoop+1) correctSimpleVar = correctLoop;

In this example correctLoop, and correctSimpleVar will both be identified with the tool.

For those of you who aren't aware of varscoper, it is a code analyzer that will look for variables without a var statement that exist within a cffunction. I released the tool last July and cfscript support has been the #1 request.

Additionally, I am now hosting the project at RIAforge at http://varscoper.riaforge.org/, you can look there for SVN access.

Please take a minute to test out the code and please let me know ASAP if you can find any cases that the cfscript code doesn't cover.

Sessions DO NOT expire on browser close

Mon, 01 Oct 2007 23:06:00 -0700

I have interviewed quite a few people lately for a few positions at my company. An interesting thing that I have noticed is that the majority of people I interview seem to think that session variables ALWAYS expire on browser close. However in a default CF install, session variables will persist even after a browser is closed and re-opened. This could mean that your users continue to be "logged in" to your application even after they close their browser.

The default behavior of a ColdFusion installation does not use per-session cookies in a browser, it uses persistent cookies instead. The difference being that per-session cookies are stored in client memory and are destroyed on browser close where persistent cookies are stored on disk and are available after a browser has been closed an opened.

There are reasons to use both per-session cookies as well as persistent cookies, but you should be aware of the difference. In a secure application, users generally expect that their session will end on browser close so you should be careful to enforce this behavior.

How do I change this???

There are a few ways to accomplish per-session cookie management in your application. One approach is to enable "Use J2EE session variables" in ColdFusion administrator, but you can also accomplish this in code. Take a look at this knowledgebase article for an extended explanation.

Hiring Engineers in the Bay Area

Wed, 29 Aug 2007 11:21:00 -0700

I have an immediate need for Senior ColdFusion developers in Emeryville, CA. I'm looking to fill 3 full time positions and 5 contract positions. Applicants should have a minimum of 3-5 years of development experience with CF, strong understanding of CFCs and Object Oriented concepts, and preferably experience on at least one large project with mach-ii or model-glue.

All positions will need to report on site at our offices in Emeryville. The name of the company is Planitax , and we have a hosted software solution targeted to tax departments in Fortune 1000 corporations. We have a robust client base (intel, at&t, sun for example) and we are growing rapidly. The application is very mature and it would be a great opportunity to work with some top notch developers, and explore advanced concepts. Pay is extremely competitive, and we have a great work environment.

Please contact our human resources department at human.resources@planitax.com if you are interested in applying. Please NO recruiters.

Memory Leaks: Part III - sessions and cfcs

Wed, 25 Oct 2006 16:15:00 -0700

    In part III of my memory leak posts, I will attempt to show an example of how variable references can increase within in the heap on every request. If you would like to know more about the tools I used to identify the problem, or would like to follow along with the example you should take a look at my previous posts,
"ColdFusion Memory Leaks: Part I - profiler introduction"
"ColdFusion Memory Leaks: Part II - variables scope"

    Note: The example that I will demonstrate is 90% complete. It is similar to the behavior that I experienced in my application, but not as severe. This only works in specific circumstances, where my problem appeared 100% of the time. Unfortunately, this is the closest I could come without including hundreds of thousands of lines of code.


For this example, we will expand the case that I demonstrated in the variables scope example. We will use the same test.cfc as the previous example.

Next we will need to expand the cfm page, we'll make the following modifications.

add session timeout of 10 seconds (to see results quickly)
only load test.cfc into application on the first request
create an array on the session
create a new instance of test.cfc locally, and append it to the array on the session





 
	
	





	
	creating a new session







completed request - session size = #arrayLen(session.sessionArray)#



reset application.test (this clears all memory references)

What should we expect in this example? (feel free to correct me if you think this should be different)

1 instance of test.cfc should be loaded into application
foo exists in variables scope and creates a reference to an array of 100 instances of test.cfc (this is the example from Part II and should be destroyed at the end of the request)
an instance of test.cfc will be added to the session on every request. (5 request in a session = 5 test.cfc)
when the session expires, the array should be cleaned from the heap.

Now for a flash movie that will show the results of what actually happens (my apologies if this is rushed, there's quite a bit going on in a short timeframe)

What happened??(also, how you can follow along if you execute the example)

On the first request, test.cfc is loaded into the application at the same time a new session is created
Every request loads an extra 100 references to test.cfc (which should only exist in variables scope)
The session that loads the cfc into application scope (and only this session) will persist all the references for the life of the application
All additional sessions will hold their references for the life of the session
Adding a structure to session instead of a cfc will create the proper behavior

Summary

Why does this happen? I can't tell you, I'm hoping the community, or adobe will be able to figure that out. Some other notes that I would like to add.... The behavior occurs if it is a struct OR an array on the session. The behavior also occurs if all the cfcs are different (I used test.cfc for all references to keep the example simple). If you reload application.test, the references will be cleaned up, but the behavior will occur for the session associated with the request that created application.test.

How do I fix this in my application???
I am not going to recommend a solution for this because I haven't found a "magic bullet" yet. I am also not going to recommend a solution because every application is unique, and every memory leak is different. I will however tell you that my problem was very similar to this. We were keeping a history stack on the session that consisted of an array of simple beans. Converting the beans to structures, solved a large part of the problem. This isn't always an option if you are storing complex objects on the session. I'm very interested to see if anyone else having a similar problem is storing cfcs on a session, as the root cause seems to be a wacky combination of instantiating cfcs on multiple scopes within a request.

Memory Leaks: Part II - variables scope leak

Mon, 16 Oct 2006 11:50:00 -0700

    In part II of my memory leak posts, I will attempt to demonstrate a simple example of how the CFML runtime engine can cause memory leaks. If you would like to know more about the tools I used to identify the problem, or would like to follow along with the example you should take a look at my previous post, "ColdFusion Memory Leaks: Part I - profiler introduction"

    For those of you that have ever experienced memory leaks, have there been cases where you have been convinced that the problem is not your code? Well, you may actually be right. This example will show a very simple case, then I will try to build on this to show a more problematic example in my next post.

    The first part of the example is to create a simple .cfc. This cfc will have 2 methods: init() which returns itself, and doSomething() which will return an array of 100 instances of itself.

The next part of the example will be a simple cfm file. This file will create 1 instance of the test.cfc and load it into application scope, then it will call the doSomething() function and set the result to a local variable that resides in variables scope.








foo is an array of #arrayLen(foo)# elements

What should we expect from this example? Well, we should have 1 instance of test.cfc persisted in the heap. We will create 100 references to test.cfc, but those should only exist in the heap until the end of the request. The garbage collector should pick them up immediately, as all references should only exist for the request.

Now, to show the results of the test, I created a flash movie that will show the behavior, watch it to see what actually happens.

Results:
What happened? As you can see, 101 instances were persisted in the heap, and not released. These instances will live for the life of the application and NOT for the life of the request as intended. In this case we should only see 1 instance of the cfc in the heap. Here are some of the behaviors I observed.

references to objects created in application scope will be kept alive if they are set to a reference in the variables scope.
Setting the variable in variables scope to empty string " " will destroy the reference.
Setting the reference in request scope will clean up the reference correctly.
Calling structClear(variables) in onRequestEnd.cfm will destroy unwanted references tied to variables scope
The reference retained in the variables scope only seems to apply to the last request to the.cfm file (will not grow)

Summary :
As you can see, this isn 't a horrible memory leak because it won't grow continually, but it could cause unwanted objects to be persisted in memory. This IS a simple example, and I'm working to create a similar, but more complex example to build on this that will show that cfc references can grow in memory on every request. Stay Tuned.