Small == Big

Have you ever tried to over architect something so that it fits all cases and solves world hunger?

I think we have all ran into this problem before and I think it's due to fear. We are afraid that the wierd, the one-off case comes along and we have to re-work our code that we spent so much time and thought into. Let's be honest no-one likes to go back and repeat something all over again, just because of one little feature/request. Sadly, no matter what you do, it will quickly become out-dated and need to be looked at again. On the flip side, the cool part is that you get solve the issue in a new way.

One thing that helps remind me not to over architect something is to start small. Solve your issue for one record. Example: "Add one user to the system". Solving for one record helps you identify the core pieces that make up the record.

Next, go back and tweak your code to do a group of records. Example: "Add a group of users to the system." Processing records in a group helps save the end user time.

And finally package your code, if you it's generic enough, to be used by other systems. Packaging helps the next developer who needs to solve a similar issue jump start there development efforts and gives them a feeling of "safety net" that someone else can help them if they get stuck.

Going back and touching your code sucks but it can be made more fun if you try to solve for the group of records and packaging. It will help you discover a new solution to your issue and keep you interested in your re-work.

Remeber:
1. One record
2. A group of records
3. Package it for the next developer

Indexed views, not using your indexes

I was working on an export where we were building a query in a string to be passed to a CLR through a stored proc to a small .NET assembly on the db server and ran into some issues with performance. Now, of course CF is slow at running queries...that's why we passed to it .NET to handle the execution, but I didn't think .NET would be slow. I couldn't figure out why my query was slow for the life of me. All the indexes were place, no extra joins were added and the query still took 20 minutes to run. After talking to a DB developer he told me that even though we indexed the sql "views" the indexes were not being used. I quickly freaked out wondering why SQL didn't use the indexes on the views like it uses the indexes on the tables. It should be assumed. Turns out the reason was that, "It is just one of those things". To fix the issue we added "with noexpand" to the joins to the indexed view and then query time went down to about 8 seconds. Ridiculous.

StructSort() does not sort your keys

Ran into an issue on Friday where I was trying to sort a struct numerically by it's keys. My struct looked something like this {"1"= query,"11"=query,"2"=query}. I first tried StructSort(struct) but it didn't work for me, it kept erroring on me. I wanted my keys to be sorted like this 1,2,11 but we all know CF automatically sorts your structs alphabetically.

So I tested structSort() with a different struct like this {"1"= "1","11"="11","2"="2"}. Bam! It worked. Hmm...something is fishy here. StructSort() works with simply values, but not complex values...but it should be just looking at the struct's keys. Anyways got around it by doing this listSort(structKeyList(struct))

Tell the join how to join.

I have been having a lot issues…with query execution plans lately (using CF and SQL). SQL has been choosing shitty plans thus making my query slow. If you have ever looked at execution plans, they are difficult read...unless you are a DB developer. I have had no idea wtf was going on with these plans…until now. Another developer sent this great link explaining what the joins are doing in the execution plan. You can then tell your joins in your query how to join.

Example:
select * from [user]
inner hash join enterprise_user on enterprise_user.user_id = [user].id

An execution plan does more than just join identification, such as indexes, but the join thingy is all I really cared about at the moment.

P.S. Only specify the “how to join” if you have to; if your query blows at running, let SQL try to calculate the best plan.

Use Case: Had a query in cfquery tags and it was choosing an execution plan with nested loop joins instead of the fast hash joins.

Developer's Inspiration

I have read a lot of blogs of web designers who have a post about "Sources of Inspiration" and I just wanted to through one out there for the developers.

Outdoors

The outdoors is a great way to relief stress and concentrate on a single problem. In other words, "It gives you a chance to clear away all the daily bull shit and focus on the problem at hand." When I am talking about "The Outdoors" I am not talking about having your window open while you play video games. I am referring to remote areas usually where vehicles can't go. Examples of outdoor places would be the woods, a cliff, or a lake/river. I personally find the woods to be the most beneficial because of the silence and random things that can keep your eyes busy and your mind relaxed, yet turning.

We as developers don't care that much about the looks of that app or naming things in it...even though we should. I have had many walks in the woods where I have came up with a solution for a navigation issue by just looking at how the trees where aligned, just as an example of how the outdoors have inspired me.

A few things that can create inspiration:
• Hiking/walking in the woods
• Mountain biking
• Hunting/Archery
• Golfing for pleasure.
• Lawn mowing...because you get in the zone, at least I do, and nothing else matters. Until you mow over the flowers.

Constructing Things

One word...Lego’s. Lego’s, in case you don't know, are small little bricks that fit together and you can build things out of them. Kind of like pieces of code that form an app in nerd speak. While the outdoors in the section above focus more on freedom, constructing things focuses on constraints. When you construct something you are usually limited by the resources you have available. Example you are building a bed and you only have steel, well how do you make the most out your steel to maximize the outcome of the bed. The constraints force you to be creative to solve a solution and often require you think in a different way. My uncle told me a quote once that helps describe this better than I am right now. He said, "Poverty is the fuel of innovation". Poverty is the problem and the constraint and it requires you to maximize the outcome. We as developers can relate to this easily by having very little time or resources as our constraint and a business requirement as our problem.

A few of things that can create inspiration:
• Lego’s
• Carpentry
• Chingling a roof
• Arts and crafts...if you are in to that stuff.

Kids

Kids are great for inspiration because they see things in a simple way and don't care about the complexities. Often times we only see things in a overly complex way because we are trying to account for all the bullshit one-off requirements that we are trying to satisfy. Sometimes if we break these complexities into simple pieces it helps you see the hidden path through the labyrinth of craziness. A thing that web designers do that I am going to steal because developers don't do it enough is "The drawing board." This is the concept of writing all your complexities on a white board and moving them around and fine tuning them until you can see the path. Granted sometimes you need a really big white board but it does help to break things down.

Another thing that kids do well is trying hard at something they suck at. An example of this would include watching 4th graders play basketball. The hoop is clearly too high but they don't care because they are focused at getting a basket. I was able to figure out how I could refactor an old spaghetti code app by watching some kids play basketball. Watching them help me separate the old code into modules with which I could slowing fix while keeping the old code working. How does this apply to the kids playing basketball you might ask?

The kids all crowded around the bottom of the hoop = the spaghetti code.

Pulling one kid aside and explaining to him that if you stand by the free throw line you will be open for a pass by teammate = separating the spaghetti code into modules.

Video games and movies

...nothing really to say here, we all know.

Other blogs

There is a ton of developers and designers blogging inspiration. Read them and take what you need

value-of-select inside an xslt tag's attribute

I've been work with xslt lately and ran into an issue the other day while trying to put the value of a node inside a tag's attribute while in xslt. If you know a little about xslt...this will error out because you can't have a < or > inside the attribute. So what do you do? Well in the past I have been escaping the quotes in xslt and writing a ton of code to something so little...until now. Check it out:

Here is my xml that I want to loop over.

<cfsavecontent variable="xml">

 <boarders>
  <boarder>
   <id>1</id>
   <name>Joe</name>
   <board>Forum</board>
  </boarder>
 </boarders>

</cfsavecontent>

<!---Here I am putting the value of the id node in the href attribute of an a tag by escaping quotes. Pretty gross huh?--->
<cfsavecontent variable="xslt">
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fn="http://www.w3.org/2005/xpath-functions" xmlns:xdt="http://www.w3.org/2005/xpath-datatypes" xmlns:xs="http://www.w3.org/2001/XMLSchema" >
   <xsl:variable name="XML" select="/"/>
   <xsl:template match="/">
    <html>
      <head></head>
      <body>
      <xsl:for-each select="$XML"> 
       <xsl:text disable-output-escaping="yes"><</xsl:text>a
       href='test.cfm?id=
       <xsl:value-of select="boarders/boarder/id"/>
       '<xsl:text disable-output-escaping="yes">></xsl:text>
       <xsl:value-of select="boarders/boarder/name"/>
       <xsl:text disable-output-escaping="yes"></a</xsl:text>
      </xsl:for-each>
    </body>
   </html>
  </xsl:template>
 </xsl:stylesheet>
</cfsavecontent>

<cfoutput>
#xmltransform(xml,xslt)#
</cfoutput>

Now check this out. The same xslt with {} to access the node. Alot cleaner.

<cfsavecontent variable="xslt">
 <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fn="http://www.w3.org/2005/xpath-functions" xmlns:xdt="http://www.w3.org/2005/xpath-datatypes" xmlns:xs="http://www.w3.org/2001/XMLSchema" >
   <xsl:variable name="XML" select="/"/>
   <xsl:template match="/">
    <html>
     <head></head>
     <body>
     <xsl:for-each select="$XML"> 
      
     <a href="test.cfm?id={boarders/boarder/id}"><xsl:value-of select="boarders/boarder/name"/></a>
 
     </xsl:for-each>
    </body>
   </html>
  </xsl:template>
 </xsl:stylesheet>
</cfsavecontent>
<a href="http://www.w3.org/TR/xslt#dt-attribute-value-template">http://www.w3.org/TR/xslt#dt-attribute-value-template</a><br/>
<cfoutput>
#xmltransform(xml,xslt)#
</cfoutput>

It, the {}, also supports xslt variables as well.

<cfsavecontent variable="xslt">
 <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fn="http://www.w3.org/2005/xpath-functions" xmlns:xdt="http://www.w3.org/2005/xpath-datatypes" xmlns:xs="http://www.w3.org/2001/XMLSchema" >
   <xsl:variable name="XML" select="/"/>
   <xsl:template match="/">
    <html>
      <head></head>
      <body>
      <xsl:for-each select="$XML"> 
      
       <xsl:variable name="boarder_Var">
        <xsl:value-of select="boarders/boarder/id"/>
       </xsl:variable>
       a href="test.cfm?id={$boarder_Var}"><xsl:value-of select="boarders/boarder/name"/></a>
   
      </xsl:for-each>
    </body>
   </html>
  </xsl:template>
 </xsl:stylesheet>
</cfsavecontent>

<cfoutput>
#xmltransform(xml,xslt)#
</cfoutput>

Use Case:
I wanted to merge some data into a set of links that the user clicks on that returns the value to an FCKeditor.

Playing with cfloop's file attribute

I was playing around with cfloop's file attribute and how it only grabs the rows you want to loop over...not the entire file. So cool. I am amazed at how well and easy it is to use. Here's what I got:

<!---data.csv--->
ID,Name,Board,Gender
1,Joe,Forum,M
2,Jamie,Nitro,F
3,Jake,Forum,M
4,Ben,Burton,M
5,Ken,Elan,M

<cfset columns = "ID,Name,Board,Gender"/>

<cfset boarders = arrayNew(1)/>

<cfloop from="2" to="6" file="C:/workspace/examples/file_looping/data.csv" index="row">

 <cfset boarder = structNew()/>
 
 <!---loop through the columns and create a struct of the row's data--->
 <cfloop from="1" to="#listLen(columns)#" index="column">
  <cfset boarder[listGetAt(columns,column)] = listGetAt(row,column)/>
 </cfloop>
 
 <!---append the boarder struct to the boarders array--->
 <cfset arrayAppend(boarders,boarder)/>

</cfloop>

<cfdump var="#boarders#">

I put the rows in an array of structs to work with it more easily.

Use case:
It works great for imports where you want to throttle the amount of data you process at a time. Example you only want to pull records 1-99 process them, then 100-199 and so on.