reCAPTCHA: Click here…You just translated a book

There is an neat article in today’s Sunday Boston Globe entitled Click here…You just captured a book (or Click to Translate in the online version).  It describes the way that the reCAPTCHA project takes advantage of the typing that we all do in those little windows that ask us the type the characters we see to prove that we are real humans.

Alan Turing did artificial intelligence work in the 1950’s and, among many other things, tried to devise a foolproof way to tell computers and humans apart.  The Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA, sort of) pays homage to him and was invented by Luis von Ahn.

The reCAPTCHA project takes things one step further.  Since we’re typing what we see in those little windows anyway, why not use the effort in a constructive way?  By having us type words that computers have had problems recognizing when they scan books, we can help to "translate" the text.

In the example window below from the reCAPTCHA Web site, you can see the two words "request" and "under".  One of the words is a test to see if we know what we are doing; the other is an indecipherable word from a book scan.  When we type what we see, we’re solving one tiny bit of a bigger problem.

image reCAPTCHA logo

If you manage a Web site that uses the CAPTCHA test to block ‘bots, reduce spam, and such, consider switching to the reCAPTCHA project as your source.  You’ll be helping a noble cause (digitizing the world’s books) and have an endless source of those tough to read little words.  Oh, and it’s free.  Click on the reCAPTCHA logo to the right to learn more.

Technorati tags: , ,

Lookup with Picker Data Type for a SharePoint List

While researching the issue I mentioned in my previous post, I ran across this neat thing at CodePlex: http://www.codeplex.com/lookupwithpicker/Wiki/View.aspx.  Here’s the brief description:

Microsoft Sharepoint Server 2007 lookup control with element picker for custom list.
This control is useful if you need to choose lookup data from large lists. This control supports single and multi select mode.

I haven’t downloaded it, so I can’t vouch for its specific implementation, but it’s something that I’ve been meaning to look into.  Most folks don’t realize that they can create custom Data Type controls for use in their SharePoint lists.  Now, I wouldn’t recommend going out and developing a custom control for every little thing, but if you have some Data Types that are very commonly used across your Web Application, this is an option that you should definitely look into.

This particular custom control looks like it would be useful in selecting from any long list with text values.  You might also consider a custom control if you need to look up images or something that feels clunky using one of the existing set of control options.

string;# Before Values in a SharePoint List’s Lookup Column Based on a Calculated Value

I’ve seen lots of posts discussing this, but no workarounds.  Here’s the situation:

  • One list (List 1) contains a list of values that are calculated (say ColumnC = ColumnA & ColumnB)
  • Another list (List 2) uses ColumnC above as a lookup for one of its columns
  • If you go into Datasheet view for List 2, you will get the following error every time you try to change an item (with your column name mentioned instead of mine):

image

  • If you click on the dropdown for the column in List 2 that contains the lookup, every value will be preceded by ‘string;#’.
  • If you select the entry that looks exactly like the current value (but with the ‘string;#’ preceding it), you can then save the item.

This seems to be an annoying “feature” of how a calculated lookup column is represented in the Datasheet view.  We’re running SP1 with all current patches at this point, so I don’t hold out hope of a fix anytime soon.

The best workaround that I’ve come up with is to not calculate the lookup column, but to have a simple workflow which does the calculation and updates the column whenever the item changes.  This should work just fine, but since my calculated column is already embedded as a source for many other lists (yes, I inherited a solution, yet again), it’s problematic to make the change.

Anyone seen a better workaround?  This really gets in the way if you need to do some wholesale changes on a long list that contains this problematic type of column.  I’ll certainly post anything I find that gets around this better.

 

Counting Subsets of Items in a Data View Web Part (DVWP)

I’ve posted about this application before. It helps my client manage their inventory of sports tickets which they can use with their clients and vendors.  They have a regulatory reporting requirement to maintain information about who uses the tickets and what their relationship is.

In this case, we wanted to be able to count the total number of tickets per event and the number that were available or reserved.  (This is not a highly sophisticated data model or application: we have one item in the Tickets list per ticket.)

When you want to count subset of records, you must provide the count function with a nodeset, which in this case is a collection of items. The code snippet below is part of the XSL from a DVWP which has an aggregate data source made up of the Events list and the Tickets list.  I’m passing the EventID into the XSL which deals with the Tickets list in line 2, and getting the rows in the tickets list which have that EventID in line 3.

In the Tickets.body template, I want to count the number of rows which meet each of the criteria.  The trick here is to take the full set of rows for the event and ‘skinny’ them down for each criteria.  I do this by specifying the filter for the criteria, creating the proper nodeset, as in line 18 for the available tickets and line 22 for the reserved tickets.

<xsl:template name="Tickets">
     <xsl:param name="EventID"/>
     <xsl:variable name="Rows" select="/dsQueryResponse/Tickets/Rows/Row[
  @EventID = $EventID]" />
    <xsl:call-template name="Tickets.body">
        <xsl:with-param name="Rows" select="$Rows" />
    </xsl:call-template>
</xsl:template>

<xsl:template name="Tickets.body">
    <xsl:param name="Rows" />
   
<td class="ms-vb">
        <xsl:value-of select="count($Rows)" />
   </td>
   
<td class="ms-vb">
        <xsl:value-of select="count($Rows[@TicketStatus = 'Available'])" />
   </td>
   
<td class="ms-vb">
        <xsl:value-of select="count($Rows[@TicketStatus = 'Reserved'])" />
   </td>
</xsl:template>

Technorati Tags: ,,

Reformatting Code in Visual Studio

This is one of those things that I can never find — I know it’s there somewhere, but it isn’t where I expect it.  Formatting your code ensures standardized usage of indentations and spaces. It also adds and removes lines near the brace characters that delimit code blocks.  This is especially useful if you find a great code snippet on the Web, paste it into your code, and then it looks all higgledy-piggledy.

To reformat your code, go to the Edit menu, Advanced, and choose either Format Document (Ctrl-E, D) or Format Selection (Ctrl-E, F).  The screen shot below is from Visual Studio 2008, but the functionality is basically the same in previous versions.  There are quite a few other useful text formatting options there as well.

New Picture 

Technorati Tags: ,