Tod1d's Thought Process

A project that I am working on required the dynamic creation of a fax document, populated with data from a database and then sent to a fax server at runtime. I tried two methods for creating the fax document.

The first method was dynamically creating a Word document using Gios WORD .NET Library, which worked as long as you had MS Word installed on the machine that executed my code. Very annoying.

Creating a PDF file on the fly using iTextSharp was the second method I tried and settled on. Here is a description of iTextSharp as given on their website:

iText# (iTextSharp) is a port of the iText open source java library written
entirely in C# for the .NET platform. iText# is a library that allows you to
generate PDF files on the fly. It is implemented as an assembly.

iTextSharp works great, plus it is FREE (as in beer). I would deffinately recommend it.

iTextSharp Home Page

iTextSharp Documentation

I am using Microsoft SQL Server 2000 Replication for one of my company's projects. I had never used replication, but it seemed like a good solution to the problem we were facing. The application has been running for about a month now and I am happy to say that I am pleased with Replication so far.

I released version 1.1 of the application this weekend and it included some minor database changes. I needed to add columns to existing tables, create two new tables, update existing stored procedures, and create new stored procedures to support the new tables. This would normally not be a big deal. Unfortunately replication makes adding columns to a replicated table a bit more complex.

Thankfully I found the following article to assist me with adding columns to existing tables that are being published via replication:

Altering Replicated Tables (SQL 2000)

Another oddity is that when I altered replicated stored procedures and updated the Snapshot, the changes to the stored procedure did not propagate to the subscribing database. After monitoring the subscriber for changes for over an hour, I manually updated the subscriber with the proc changes.

It has been awhile since I have manipulated data in a Gridview. I am binding a collection to a Gridview and one of the values contains non-html line breaks (\n). I would like to convert these to html line breaks (<br />). The code below works fine:


I was wondering if there is an "easier"/"better" way of doing this, so I posted the question at the ASP.NET forums. Feel free to post your comments to that thread, rather than this blog entry.

Update

Aaron at ASP.NET provided me with a more aesthitic solution. See the code below:

<ItemTemplate>
     <%# ((string)Eval("Message")).Replace("\n", "<br/>") %>
</ItemTemplate>

My Google Mail box is overflowing with submissions from the contact form on this site. The form has been useful for people to contact me directly without having to leave a comment on my blog.

A few months ago spam began trickling in, three to five emails at a time. Now I average about thirty a day. Possibly worse than the amount of spam, is the lack of quality spam. Are these guys even trying anymore? Here is an example:

Insurance
Insurance
Insurance

Imagine that the above are all hyperlinks to sites somewhere in Russia and you get the picture.

To combat this onslaught of unwanted solicitation from Russian insurance salesmen, I have decided to add a low-tech version of CAPTCHA to the contact form on this site. It is a blatant rip-off of Jeff Attwood's, but I figure if it is good enough for him...

Update

Apparantely my solution was overly low-tech. The validation I was using was via client-side Javascript only. The bots that the Russians are using ignore Javascript, so they were still hassling me.

Last night I added server side validation to the ASP script that processes the form. I am happy to report that I have not received a single form submission that contained SPAM. Yeah baby!

In Joel Spolsky's latest post, he discusses practical ways of choosing a programming language to develop in. Not much new here, but I did enjoy this paragraph about FogCreek's in-house programming language/compiler written in C#.

"Finally -- as to what we use -- Copilot is C# and ASP.Net, as I mentioned, although the Windows client is written in C++. Our older in-house code is VBScript and our newer in-house code is C#. FogBugz is written in Wasabi, a very advanced, functional-programming dialect of Basic with closures and lambdas and Rails-like active records that can be compiled down to VBScript, JavaScript, PHP4 or PHP5. Wasabi is a private, in-house language written by one of our best developers that is optimized specifically for developing FogBugz; the Wasabi compiler itself is written in C#."

That sounds nifty.