Limitations of technology and resources are not “inherently cruel”

In her commentary on speech recognition software (“Speech Recognition Tech Is Yet Another Example of Bias“, Scientific American, Oct 2020), author Claudia Lopez-Llorenda derides the limits of technology because of her need to alter her speech pattern to a non-accented version of her own voice in order to be recognized fluently. In her words, “[changing] such an integral part of an identity to be able to be recognized is inherently cruel.”

The technology community is a scientific one, subject to the same limitations of other sciences: those of resources, knowledge, and capabilities. It is also subject to the same limitations of economics: funding and supply and demand. To imply that technology (and technology companies) are ignoring smaller demographic groups or populations for reasons other than those limitations is short-sighted, and ignores the complexity of the problem and the allocation of available resources to solve it.

Speech recognition has become mainstream, and we have seen solutions delivered to market in the past ten years that were likely considered science fiction 20 years ago. It is still far from a complete solution, and that is shown by the continued rapid advances and developments in the field. Apple, Google, Amazon, and others have brought speech recognition to dozens of languages in just a few years, delivering an imperfect solution to a complex problem that consumers today expected to work without fail, much like we expect our cars to work when we turn the key.

The difference, of course, is that cars are all the same; people are all different, and even though many of us speak similarly, many of us do not, as we use dialects of the same root language — and that is where the economics of science come to play. When you want to implement language support, you will start with the baseline language, to capture the widest population of potential users. As technology improvements come, the availability to pick up smaller and smaller populations of users who speak in dialects will come with it. These are not limitations built into a solution; rather, they are limitations based on technological capabilities and available resources to implement them.

When companies decide to do this, it is not to be exclusive; rather, it is to be inclusive of as many people as possible. Turn on the television in the US and watch the news, and you will largely see newscasters speaking in a standard form of American English. This is by design; they are speaking in a way that people with nearly any dialect or understanding of spoken English can follow, thereby being inclusive of the most number of people by resorting to a common baseline. Technology companies do the same. This decision does not take away anyone’s cultural identity, nor should it be seen as “inherently cruel”.

Over the next ten years, Ms. Lopez-Llorenda will undoubtedly see incredible advances in speech recognition. As technological capabilities grow, and as company resources are freed up by completion of tasks for larger populations of users, she will see improvements in language support (including dialects) and eventually will see that speech recognition is able to recognize an individual’s speech (for example, picking up the l in salmon, for the one person I met in my life who pronounced it that way). The inherent cruelty will go away, not because anyone felt it was cruel, but simply because technology has caught up.

In the meantime, I will continue, at times, to mask my New York dialect in conversations — not because I am trying to hide my cultural identity. Rather, perhaps I am trying to be inclusive of the listener, who may be unfamiliar with such a dialect; or perhaps I don’t want to come across as a paisano — because, after all, if you heard me ordering a cup of cawfee (milk, no sugah), you probably would quickly make a certain opinion of who I am. And that opinion may be right or wrong, and you are entitled to make it, and I don’t take it as an insult. You’re merely taking in speech, and making a decision based on the limited amount of data and information you have to process it — which is, ironically, the same thing Siri is doing.

Create a Windows shortcut to map and open a network drive

After all these years, users still love their drive letters. And inevitably, I still hear the complaint, “My X: drive has disappeared!” Which makes me wonder a few things.

  1. What does the X: drive point to?
  2. Why are we still using drive letters?

It’s not my place to change the world, but we can make it easier on ourselves and our users. So when you have a user who uses network shares mapped to drive letters, create a shortcut on their desktop, and use the following command line in the shortcut — just specify your desired drive letter and your server and share information.

cmd /c "net use x: \\servername\sharename /persistent:yes | explorer x:"

This will both re-map the drive letter if it isn’t mapped, and open a Windows Explorer window to the drive letter. You now put the power in the hands of the user, and free up your time to write blog posts about how you put the power in the hands of the user.

Simple required field validation using jQuery

Sometimes, you work within the constraints of an existing application, trying to change as little as possible. So when a client had a very simple (two field) form, that showed up as a Bootstrap modal, and I needed to make sure the user didn’t click the submit button until they filled out all the fields, I simply dropped in the following JavaScript.

$(document).on('change keyup', '[required]', function() {
		var targetForm = $($('[required]')[0].form);
		var requiredOk = targetForm.find('[required]').filter(function () { return $(this).val().length == 0; }).length == 0;
		targetForm.find(':submit').prop('disabled', !requiredOk);
});

I then marked up my form fields by adding required property to each field that was required to be true. A simplified example follows.

<form id="form1">
  <input type="text" id="input1" required /><br />
  <textarea id="textarea1" required></textarea><br />
  <button type="submit" disabled>
  Submit
  </button>
</form>

Now, your submit buttons will automatically disable/enable. It doesn’t work in more complex forms with other field types, but I did start off by saying this was a “simple” solution, after all.

JSFiddle here: https://jsfiddle.net/05wyu3az/

Specifying time zone in SQL DATETIME DEFAULTs

You’ve had your existing application running for years, relying on DEFAULT constraints to set DATETIME fields to the current date using GETDATE(). Everything was great until you migrated to Azure SQL Database – and realized that your SQL Server is now set to UTC, and you can’t change it.

Fortunately, you can change your DEFAULT GETDATE() constraint to save date in your time zone. Just specify the default as shown below, specifying your time zone of choice:

default convert(datetimeoffset, getdate()) at time zone 'Eastern Standard Time'

To prove this, run the following, and note the output will show the time in Eastern Standard Time as opposed to UTC.

create table #test (
     val nvarchar(max),
     dt datetime not null default convert(datetimeoffset, getdate()) at time zone 'Eastern Standard Time'
 )
 insert into #test ( val ) values ('yo')
 select * from #test

Voila! No more time zone issue.

OneDrive sync fails because filename starts with a space

Windows (and, it seems, Microsoft in general) does not like filenames that start with a space. You can’t even create them in Windows Explorer — go ahead and try! If you start the name of a file or folder with a space, Windows will remove the space for you — automatically. Frustrating, eh?

Regardless, there’s sufficient ways to wind off with a file that starts with a space, and inevitably, if you use OneDrive, you’ll get sync errors, because OneDrive (being Microsoft) does not like filenames that start with a space.

The logical step would be to rename the file in Windows Explorer and remove the leading space — but that doesn’t work; Windows will tell you that the filename already exists. (Apparently, those spaces are ignored in more places than one.)

So how do you solve this? Two ways.

  1. Rename the file to something entirely new without a leading space.
    OR
  2. Open a command prompt and type this:
    ren ” myfile.txt” “myfile.txt”

The command prompt lets you use spaces (provided they are in double quotes), and will (accurately) know that a file name with a leading space is not the same as the same file name without the leading space.

Best solution? Avoid the darn spaces altogether.

Force a direct download from a shared DropBox file

While working with DropBox today, I created shared links to a file, and the links looked like this:

https://www.dropbox.com/s/abcxyz123/filename.zip?dl=0

This link goes to a nice DropBox web page that provides a lot of information — information that would confuse a less-sophisticated user. Why can’t we just get them right to the download?

You can. In the DropBox shared file link, change the “dl=0” at the end of the URL to “dl-1”.

So the same URL above as a direct download would be:

https://www.dropbox.com/s/abcxyz123/filename.zip?dl=1

It’s always fun hacking URLs!