On The Mark Technology

So I've got an application that requires some reporting. There are several different reports, and each report can be run with any number of input filters. Some of those filters are required, some are not. So the requirement is to select a report, and based on that selection, display the available filters - some of those filters even require some dynamic selections.

So here's what I did.

I built a reports table, and a report_filters table - a report may have 1 to many filters associated with it. When the user hits the reports page they see a drop down box of the reports available. Also on this page is a couple of hidden regions; "Filters" and "Results".

The drop down box has an "onChange" action that passes the selected report ID to a server procedure via Ajax that provides the HTML required for all the filters available for that report in the "Filters" section of the page. This is where the Native Dynamic Sql (NDS) comes in.

In my table of report filters I have a column (filter_input_procedure) where I put in an anonymus PL/SQL block. This block gets executed in a loop of all filters for for selected report with an EXECUTE IMMEDIATE command. When this fires, the pl/sql block interacts with the database and outputs the required HTML for the input filter.

procedure build_rpt_filters(p_rpt_id in number) is
cursor available_filters is
	   select * 
           from report_filters_table 
           where rpt_id=p_rpt_id 
           order by sort_seq;
begin
for xx in available_filters loop
	execute immediate xx.filter_input_procedure;
end loop;
end build_rpt_filters;

To build the start date input procedure show in "Report With Two Filters", here are the contents of the "filter_input_procedure" field.

declare
begin
htp.p('Provide the Start Date (mm/dd/yy): ');
htp.p('<input type="text" name="p_start_date" size="10" value="">');
end;

The next thing I had to do was accomodate the user entering a value for a filter, but show them some information that allows them to confirm they have entered the right value.

In the "Report That must do a lookup", the input filter is displaed as before - this time with an input box and a "Submit" button. However, the "submit" button has it's own AJAX call that executes another procedure on the server fires to get another batch of HTML, which is displayed in the "Results" section of the page.

EXAMPLE:

One of the last reasons for doing report filters in this way was a support requirement. The application I wrote this for is supported remotely and often without access to the server. So as much configuration as possible is defined in tables and a user interface built for it. Using Dynamic Sql allows me to control some coding aspects on the fly, and using AJAX allows me to craft a user interface that quick and intuitive.

Recently, this site has been hit with "Comment Spam". This is a phenomenon where commercial messages are pasted into comments on blogs. These comments are not related to the topic in the blog post, are typically for pharmaceutical products, are are done by programs, not people.

One approach to this spam is to turn off comments altogether. This is the nuculear option that is pretty unattractive. This site doesn't get to many comments, but if somebody has a question on a technical topic I post, then email becomes the method, and only the parties in question benefit from the results of the discussion.

Another approach is to moderate the comments. Hide the comments until a human (me) can review the comment and either approve or discard the comment. This is a hassle, especially since the spammers are typically code based and can throttle up the volume pretty easily. I was getting 30-40 per day.

Another approach is to put in a "CAPTCHA" ("completely automated public Turing test to tell computers and humans apart") test that puts an image on the screen that can't be read by a computer and ask the commenter to key in the value in the image. Accessibility is the issue here as those using screen readers can't participate in the commenting.

To prevent the message from providing value (most search engines like outbound links and boost site rankings when people link to the site) you could remove all the HTML or add the "ref=nofollow" attribute to anchor tags (this tells participating search engines to not index the link). But once again, this can limit functionality to real users.

Another approach is to change the comment form in a subtle way that prevents the spammers program from working properly. But much like security techniques, the smart spammer will eventually figure this out.

I've implemented a combination of the above methods, and so far I've been able to thwart their attempts. I think their programs are still hitting the site as my page views are abnormally high, but the spam actually be posted to the server has been eliminated.

What I'd really like to know though is 1) how did they find this site? 2) what makes them think that this site gets enough page views that spamming would have any success at reaching an audience (search engines or human eyeballs? 3) does it really work?

I wonder if there is some sort of blog "confessions of a blog spammer" that could provide those insights.

I ran into another web application today - LookLater. This app appears to be a place where I can store a URL that I want to remember, but don't have the time at this moment to read. It comes with a little "bookmarklet" (a little functional bookmark) that sits on my Firefox toolbar. When I find something that I want to remember, I click the bookmarklet, highlight portions of the page, and then it sends it to the LookLater site.

I think there are great uses - for me - for this tool.

1. For blogging - I often see something and say "hey I should blog about that", but later forget what I saw or where I saw it.
2. Coding practices - I often see a coding technique or design angle that I might be able to use for something later on, but need to study it further - but forget.
3. It's web based - so I can get to these things at home, rather than risking valuable work time to read it.
4. It's private - not that I don't like to share, but I might read it a find that the item is not as applicable as I thought, and would remove it. This is probably why I don't bookmark as much as others. This way, when I do get around to reading the item, I can then figure out if it should be bookmarked, or blogged, or saved altogether.

I signed up pretty quickly. If you suffer from any of the bullet items above - you should too!

Two things are really getting me excited these days.

1. Free Delivery from Iconbuffet. They make very cool icons, and are now giving some of their collection away. I have 4 of the collections so far, and will be happy to deliver them to you - just leave me a comment here.
2. I found Blingo at Airbag when he announced he just won an iPod. Just today, he announced that he won a Sony Playstation - FREE - simply by using Blingo as his search engine. It's viral, so clicking the blingo icon will take you to their registration screen where you will be registered with my referral key. That way, if you win, I win. I've found the search results are the same as Google, and the spam index is zero - three weeks and not a single spam from them. I haven't won anything yet, but I'm sure I will soon!

I also plan to follow 24 Ways to impress my friends during the month.

I peruse the Delicious linkfest page periodically when I need something new to read - usually when I need a break from coding. What I found today is an old article, but really sums up good coding techniques..

Free Programming Tips are Worth Every Penny

Here's a summary - "* The Way of the Code Samurai *"

• Think first. Think some more. Don't write code until you know what you're doing. This goes to design. A good basic design will accomodate lots of modifications in the future. You must understand business processes, both what is for the Now, and what will be in the future. Understanding both will get you headed in a good design direction, and the application will have the ability to grow and change easily as business processes evolve over time.
• Write all your code "clean," the first time you write it. It's hard to say how many times I've looked at old code and said "what was I thinking?" Some of that is because I've learned over time new ways of doing things that are more effecient, but sometimes, I took the easy route, and did the QnD (quick and dirty), only to have to go back and fix it - the right way.
• If you're in code anyways to extend it or fix a bug, CLEAN IT. This is refactoring, always trying to make the code better, more flexible, more extensible. Sometimes doing this takes a little longer, but In my mind is mostly worth it.
• Less source code is better. Less for your successors to learn, figure out, and, inevitably, to fix.
• Optimize methods ONLY after they work - Don't optimize as you write. I do this all the time. I write a piece of code, sometimes several that do similar things and get it all to work. The trick is to recognize the fact that some modules can be combined, and go back and combine them, passing the parameters to make a single module do many things. The advantages cover much of the earlier points. But, get it to work first, then combine.