RSS feed for InstantSpot site EdomGroup Blog

Simple regex assist

Thu, 01 Nov 2007 18:55:51 GMT

If you're still writing some sql create and update statements by hand these may help you. Mainly, I wanted to post these so I wouldn't forget them.

Create a list of cfqueryparam's from a list of cfargumen's. If you don't do any column renaming in your code then this is straight forward:

Find: <cfargument name="(\w+)" type="(\w+)" [^>]+>
Replace With: <cfqueryparam value="Arguments.$1" cfslqtype="cf_sql_$2" />,

This next one will create all the values of an update statement from the list of cfqueryparam's, again if no column renaming has been done this is a one shot find/replace:

Find: (<cfqueryparam value="Arguments.([^"]+)" [^>]+>,?)

Replace With: $2 = $1

Mimicry is the Highest Form of Flattery

Thu, 09 Nov 2006 02:43:00 GMT

I'm a ColdFusion advocate as are the majority reading this post, I'd assume. Since being introduced to the CFML language I've begun seeing more CFML engine iplementations. Some of these are free, some are Open Source. The latest one Smith is a CFML engine written completely in Java that runs in a servlet container. The authors of Smith are waiting for feedback from the ColdFusion community before deciding to release the source code but they are giving away the engine for free. Three other CFML implementations I know of are: BlueDragon, Railo, and IgniteFusion. Each of these have their own specific strengths. Each also varies in the way they were implemented.

I believe it is imperative that there are free (and non-free) alternative CFML engines to spread the word about the language and compete with the currently dominate free web languages like PHP, Perl, and Python. If anyone reading this has heard of another CFML engine please post a link to it in the comments so the word gets spread. Also, don't forget to give these engines a try. Play with them, send complements and recommendations. May be the next time you need to setup a computer to host a small to medium sized CF site you can use one of these projects in conjunction with a MySQL or PostgreSQL database.

ColdFusion Wishlists And A General Understanding

Tue, 25 Jul 2006 01:43:13 GMT

I just thought I would chime in on some of the extreme beating around of wishlist features I've seen lately. I will explain how I feel and go into some arguments that I think have been taken a little to the extreme as to where CF programming and the products around it are headed.

We Are Headed In The Right Direction

The great amount of argument about all of the features in CF and the attentive attitudes we are getting from Adobe, Bluedragon, and anyone with a stake in CF is nothing but encouraging. It makes me very proud to be a CF developer. I am very confident in our community's ability to make CF continue to be the best language for web development out there, no matter who the largest vendor is, etc. With that said, here are my thoughts:

Why I Want Interfaces and Other "OO"-reminiscent Mechanisms in CF

The reason for this is simple. There are many common tasks that we get involved in when using objects in any language. These include API development, data abstraction, and utility methods. CF supports objects (CFCs), why not support that nice suite of tools that developers in almost every other language as well as some CF developers expect?

This has absolutely nothing to do with "OO" as the obsessive niche and often wrongly defined practice in our community as much as it does convenience, something ColdFusion is definitely good at. The fact is, I use interfaces so I don't have to remind developers what to do, I use static methods so I don't have to instantiate objects or store service objects in a global cache, not because I am a part of a small "OO" core of developers. These are very powerful and simple concepts that even beginning developers from their first CFC have the ability to understand. I think the flaw in OO is that many are over-educated to the point that they elevate it to an endless science rather than common sense.

Oh and you know what? Interfaces and static methods have absolutely nothing to do with Java. Their definition is way outside the realm of a Java-only feature. I am trying to make CF the most well-rounded, powerful, feature-rich language it can be, not like any other language. I am not going to define it as a presentation layer, because the reality as I have seen it is that most of us reach back into Java for little or none of our back-end. I know Java and use Java, but I work with the best tool for the job, given the tools available to me and for web development, that is CF (not just for the presentation layer). Because CF has a lot of presentation tools, doesn't mean we should focus all or even most of our attention on those things at any one time, ignoring performance, interactivity, and damn well-tested practices, but make them better.

I would be glad to elaborate more on this if anyone has any questions because I feel it is horribly under-discussed beyond an "I want or don't want interfaces" level.

What Makes ColdFusion?

Flash Forms, PDF Generation, etc. are features that are unmatched in any other web development tool out there, but they do not define ColdFusion. Anyone who uses ColdFusion for these features alone is not a loyal ColdFusion user or even remotely confident in the language because the moment a tool is better at one of those for a week, ColdFusion would theoretically lose all of its purpose.

ColdFusion is a combination of all of our wishlists.

It is the syntax: I love that tag-based syntax even at a programmatic level, much less a UI level for its ease of reading and self-documenting capability. This is saying a lot for someone with a C, C++, Java education in CSCI.

It is the simplicity: ColdFusion offers us easy file manipulation for many tasks, a relaxation of types (note I did not say dynamic typing) and much more. All of our code constructs say what they mean and do not require us to worry about the janitorial tasks of programming like loop indexes, etc. We expect these capabilities in all languages, but no language makes them as simple as CF

It is the integration: Those features mentioned at the beginning of this section fit here. How proud were you when you used your first cfchart tag? Sweet, wasn't it? These are the great features that are often mistaken as THE reason people use CF in my opinion, but they are indeed great. We have to remember that these are the features that "package" CF. They make it very attractive and incredibly useful, but without the core functionality that say, CFCs offer, my bet is that not a single developer I know would use it.

Lastly, it is the organization: By "organization" I don't mean Adobe, Macromedia, New Atlanta, or Allaire, but the community as a whole. The willingness we have to expand this language in all directions by leaving it open enough to create many different servers and projects, but tightly knitted enough to keep good naming conventions and a solid transition space between products. The willingness we have to compare it to all of the other tools out there without becoming alienated. Integrate their capabilities and learn from them to make an even better tool for ourselves.

Well, I intended to get through many of the arguments and mis-interpretations I have seen in the community lately, but I think it is better that this post is more unifying and encouraging to all of us, not just those who agree with interfaces, etc. To use the wise words of Gary Funk, "Google before you jump to your death" when you think you are decided on an issue that you may have thought plain and simple, no matter what your experience level.

Anyway, please understand that I speak from my point of view, but this pep-talk is as much for me as anyone else.

Java performance analysis - a real life example

Fri, 02 Jun 2006 03:43:25 GMT

For my thesis I'm writing a Java program that parses two text files (representing satellite images) and performs some analysis on them. The two files are 128 MB and each was taking ~33 seconds to parse. The analysis takes only a fraction of that time, then the results are written back to an output file.

Thinking this was very slow, since the files should be pretty much sequential access off the disk and the read-ahead-buffer would have cached the next block, I decided to dig a little. I rewrote the parsing algorithm in C since it's easier to manage the low-level IO. I used the file stream functions (fopen,fread,fclose) provided by stdio. When I ran the program it took ~10 seconds.

This was insane. Java does have more overhead due to its garbage collection, HotSpot optimizer, and object memory management but it should not be a magnitude of 3x slower. After a few minutes looking at the Java implementation I realized I had forgotten to instantiate a BufferedReader. I immediately jumped to the documentation and there it was, each call to the read method of the FileReader blocks until data is available. If no BufferedReader is supplied this means a context switch for each call. No wonder Java was taking so long. Adding the buffering I reran the algorithm and wow, 13 seconds. Not to bad for a “boated” language.

Figuring I had more places in my program which could be optimized I began looking. The first place I went was to one of the main methods, the one which did the analysis on each image. The logic was pretty simple, find the next pattern in the given image, see if it exists in a lookup table, if so update its statistics or create a new key and add it as a new entry. The data structure I was using for the lookup table was a simple HashMap object. When writing that section of the program I was still relatively new to the Java language and just went with what I'd used in other languages, an associative array.

I did a little analysis with some System.out.println statements and found that on average there was a 14,000 : 15 ratio between reads and writes on the lookup table. Knowing this ratio was pretty stable (I wasn't going to get anywhere near 50% writes) I decided a better data structure would be something with read time of O(n) or less, instead of O(h(k)) where h(k) was the hash function on the key. This meant an array would be best, but I didn't want the hassle of managing the size of the array as new patterns where found. Java had to have something for this. After a little searching I found java.util.concurrent.CopyOnWriteArrayList. This was exactly what I needed. After a little tweaking the new code ran in 1/3 the time.

After this I wrote some small timed programs to examine the running time of the HashMap data structure and the CopyOnWriteArrayList. What I found was as the mutations approached 25% the CopyOnWriteArrayList's performance slowed at an exponential rate. Finally, I couldn't evaluate the performance because the tests were taking too long. On the other hand, the HashMap data structure had a fairly constant performance time irrelevant on the read/write ratio.