Tweets as a unit of meaning

A “tweet” is a message on twitter.com, limited to 140 characters and referencing one idea, one piece of meaning. We can define the density of meaning in twitter messages by assuming that a tweet is always about 1 unique “thing”, and finding the average length of twitter messages. This will give us a new unit of measurement of the density of meaning in a body of text. Twitter messages can be a standard against which other texts are measured and compared for meaning density.  I propose that we name this unit of measurement the Tweet.

Shorter twitter messages will have a slightly higher Tweet value than longer twitter messages, but this variance might be fairly small. What might the Tweet value of a classical novel be? How about a scientific research paper? A political speech? 

This might be a fun project to work on. A bit of new software will be needed: first to find the average size of twitter messages and thus form a Tweet baseline, and then to analyze other publicly available texts in different genres to determine their Tweet value.

It would also be interesting to compare the Tweet density of public texts over time in similar genres so that we can see if, as a society, we are becoming more information-dense, or information-sparse. The difficulty here would be in finding a suitable basis for comparison. Certainly newspaper articles from 100 years ago and from today can be compared, but what about in other genres? What can we compare blog posts to? 

I hope to continue with this project in the future and come back with some numbers to present

Command line MSI parameters and spaces

I had to deal with an issue at work lately that was driving me nuts for a while, but I finally found a solution. If you’re having a similar problem, maybe this post can help you. My problem had to do with passing command line parameters to our installer when the parameters have spaces in them, such as when they’re paths to a location on disk. The short answer is that if you need to pass a double quote (“) in a parameter, escape it with another double-quote. However, I can’t stop here, or this would be a very short post.

 

I’ve been working on the installer for my company’s product and making certain improvements to it. Our installer is built using InstallAware. By default, InstallAware produces a .exe installer instead of a .msi installer because their technology provides certain enhancements over a basic msi such as stronger compression. Running this installer .exe from a command line is easy, and parameters can be passed like so:

setup.exe PARAM1="value 1" PARAM2="value 2"

So far, so good. The problem is that this installer can not be run through group policy on Windows Server, a technology that makes it easy for an admin to install the software on many computers remotely. Group policy can only run .msi installers in this manner. InstallAware includes a group policy wizard that will wrap your .exe in a .msi specifically for this purpose, which is great. The complication comes from passing those command line parameters. The msi generated by the group policy wizard can take a parameter CMDLINE which it will then pass along to the .exe inside, like so:

setup.msi CMDLINE="PARAM1=value1 PARAM2=value2"

We can see that double-quotes are needed to enclose the value of CMDLINE if there are multiple parameters. The .exe will then be extracted from the msi and executed:

setup.exe PARAM1=value1 PARAM2=value2

But what happens if value1 or value2 themselves contain a space? This is where we run into complications. 

 

The answer, as I’ve written at the top of this post is that we can escape a double-quote with another double-quote, like so:

setup.msi CMDLINE="PARAM1=""value 1"" PARAM2=""value 2"""

Notice the double-quotes around value 1 and value 2, with a third double-quote at the end. It’s awkward and unwieldy, but that’s the way it has to be done in this case. 

 

At the very least, clients need to be told about this and how to properly format the command line.