2011/02/18

Rather than query Google Maps to get driving distances between capitals, I found latitude and longitude and use these functions to determine the distance, then ran it against all thousand-some possible distances, so it is ultimately a hash check rather than a calculation to find a distance.

In the last Purdue Perl Mongers meeting, Mark suggested a challenge. Going from state capital to state capital of the "lower 48" (no Alaska, no Hawaii) , without skipping one and without repeating one, what are the longest and shortest distances. We guessed without knowledge, and then, after the meeting was over, we started working on it.

My immediate thought was to specify the most extreme unused distance for each capital, longest or shortest, depending. I also thought to start at Maine, seeing as it's the furthest out of all the state capitals.

You should be able to see some problems. For example, Arizona wasn't the shortest choice until it was the last choice. I'm not remotely happy with the Midwest and New England sections, either. So the fastest choice of algorithm wasn't the best choice. Running the naive longest-path against each state showed that Tennessee and Kentucky were the best starting point, which shocked the heck out of me.

I added some code to pick the closest n and recurse through those, and that cleared up the Arizona problem quickly, but it will take a lot of redoing to get it to back up to the Tennessee-to-Michigan jump, much less the New England jumble. Considering a quick read-through of threading modules, which could help me get through my too-many-possibilities, but also considering ways to rethink this as a breadth-first problem.

I'm also seriously considering just making a web interface and solving it myself. I can't be sure it's the best possible, but I can vgrep for issues and optimizations.

2011/02/12

I'm a programmer and IT helpdesk guy for a lab at a major university. I rarely touch office suites. I do, on occasion, prepare presentations for user groups I'm involved in, but as I've found I'm more comfortable diving into whatever applications I'm working with, that's a fairly rare thing. The office tool I most often use is a spreadsheet, which allows me to see CSV data (and we deal with a lot of CSV data) in the formatted way it's meant to be thought of.

For my personal purposes, I've Gone Google.

When your life is spread out among seven computers and a smartphone, connecting your stuff back to the cloud makes more than a little sense. I get the "you don't own your data" arguments, but for now, it fits my needs fairly well.

But it doesn't really fit my office's needs. Genomics data can be big. Big. Loading it up to Google isn't really where I want to go. Which leads to the real crux of this discussion.

I could go Microsoft Office. There was a technical reason that you might prefer Office, in that genomics data can be big, and Excel allowed for 65536 rows by 256 columns, which was more than double what I could get out of OpenOffice.org. However, it seems that this has been changed since I last tried it.

The problem there is that I prefer to go with a Linux desktop, both for the power of it and for the freedom of it, and Office is a Microsoft product that you can't run (without virtualization or something) on Linux machines. Ubuntu comes with OpenOffice.org, so that's my default go-to for those times I do need to play with an office suite product.

But....

I was listening to the FLOSS Weekly show about FOSDEM, and the mention of LibreOffice got me curious. Each time I've opened OpenOffice, I've thought that it was slow and cumbersome beyond what it does. If there's a noticeable improvement in it's speed, it's well worth considering.

2011/02/10

I first dealt with crontab in the late 1990s, and I still run many of those same crontabs. I mean, same program, same times. So, my understanding of that tool is very tied to that time.

Of course, very little changes in technology over 15 years. </sarcasm> So I recently looked through man 5 crontab and found that there are special strings for certain common times.

@reboot

Run once, at startup.

@yearly

Run once a year, "0 0 1 1 *".

@annually

(same as @yearly)

@monthly

Run once a month, "0 0 1 * *".

@weekly

Run once a week, "0 0 * * 0".

@daily

Run once a day, "0 0 * * *".

@midnight

(same as @daily)

@hourly

Run once an hour, "0 * * * *".

Some of these come with variable utility. What are you doing on a system that's @yearly? Sending "Happy New Year!" to everybody you know? There's much here that strikes me as better done connecting to a calendar. In fact, I'm hatching an idea of setting up a calendar in Google Calendar to do that sort of wide-ranging crontabby or batchy stuff. If something runs less common than weekly, it doesn't get into my crontabs.

Except...

I'm really drawn to the @reboot string. For my work setup, I have FUSE mounts to a great number of machines (which I really use) and a specific line to configure the line-in to go directly to line-out so I can route my Windows box and Android phone through my Linux box to my headphones. I've put those commands into my crontab at @reboot.

2011/02/08

A couple of issues here. First, Sara Underwood is pretty, but that voice! Almost like fingernails on a chalkboard.

Anyway, one of the issues she brings up is wide-open home networks. The warning wasn't folks coming into your WiFi, infecting your PCs and stealing private stuff. It's glomming onto your network and "stealing" your bits.

Honestly, before I moved, I never encrypted my WiFi. I never thought it was worth it. Different neighborhood, with more people closer, and the new access point came with it up by default. As long as they don't use enough to mess up your video streaming, why not?

I think I have to start with The New X here. I've gone on about The New Telephone and The New Television without really defining my conception, my mindset. I think it's obvious what I mean with those, but when I hit the next topic on my mind, you get a certain Bob Barker connotation.

I have a concept in my mind of life between 1955 and 1985 (only about half of which I lived through) where the Old Telephone and Television live. The Old Television, for example, consists of complete boxes, with the beginnings of plug-ins from VCRs and Atari game machines. The New Television, still being designed and tested, will involve multiple sources, time-shifting, and modularization such that the screen is but a monitor, one of many.

But TV is fundamentally information. As long as you can see it and hear it, who cares whether it comes from the air, a coax cable or a Cat5e jack? The New Car is different. It is first and foremost a mechanical thing, and thus the issues involved are different.

A person from 1970 stepping into today wouldn't understand cell phones and would be befuddled by the collection of remotes on the TV, but I am very certain she could get into a 2010 car, start it, and drive it around. "Three on the Tree" isn't nearly as popular as it used to be, but the gas pedal, brake pedal, speedometer, turn signals, AC, rear-view mirror would all be about where she'd expect them to be and would behave about how she'd expect them to behave. There would be a few hiccups possible — electric motors and hybrids, OBDII and continuously variable transmissions are three things that come to mind — but they don't particularly affect the driving experience too much. The mechanics of automobiles have been abstracted away from the act of driving, and that's a good thing.

What is changing is the information-related aspects of driving, as fast and as good as the car companies can do it. As the driver of a car that was the cheapest new car we could find, much of what I know is from driving rentals when my car is in the shop, and from watching Top Gear. I see in-dash navigation, but you don't really want to be looking down at the dash too much when driving, and an in-dash system won't have the quick update times of navigating with your phone. Car audio systems have connecting to your iPod and iPhone down just as Android is beginning to dominate the market.

For the car market, electronics is a trailing concern. You want it to be so, clearly, because making the car faster, safer and more economical are the leading concerns. But it makes the choices dated. I saw a video from CNet's Car Tech section where the reviewer talks about the Toyota Camry, mentioning the 6-disc CD player (in the last days of optical media?) and optional dual DVD players in the back seat for too much money, which he suggests you skip and get iPads instead.

I told a friend a few months ago that I wanted to put a computer in a car. He asked "What would you do with that?" The thing that I mentioned is combining OBDII data with GPS so I can connect what I was doing and where I was doing it to what the engine was doing. I'm not a mechanic, so I don't really know what I'd do with that information. That information becomes really usable when you breach the firewall and start connecting to engine, transmission and brake electronics. Currently, you can get aftermarket chips to change the behavior of your engine and such, but that's warranty-voiding stuff, and also, tight inner-loop microprocessor kind of work. It won't wait until the OS pages, queries a database and returns a proper response.

Plus, of course, the standard interface vectors for electronics elsewhere are attention-sucking accident-causing crap for autos.

So, I forsee the creation of The New Car, joining long-term reliable mechanics with high-turnover electronics, as a long-term process that will cause grumbling for a long long time.

2011/02/07

There's two main tasks on my desk right now. The first is adding a new instrument to one of our web workflows. It's my code, so I'm the one to do the diffs. The second is the Sikuli thing. To recap: We install VirtualBox, create a Ubuntu 10.10 64-bit virtual machine, upgrade libCV to 2.1, install Sikuli, ssh into a Linux compute server to run the Java GUI data modification server, then write Jython in order to script the thing. This will allow us to munge and generate PDFs and such for several things in order. Every time I deal with this program, I feel the nearly-but-not-quite-overwhelming urge to scrap that, decompile the Java bytecode and rewrite the thing in a way that's batchable. I haven't been overwhelmed, so I stick with the Sikuli solution.

I still think Sikuli is neat. I think I have to be clear. It's just that this is becoming a much more complex thing than I am comfortable with.

This is why, when the boss appeared over my right shoulder, I was working on the other one. It's web work. I like web work. It's mostly Perl. I like Perl. I wrote everything involved, from the SQL tables to the Javascript interface bits. I get all of the things I wrote. It is a comfortable place, which means it's a job I can get done and feel productive. I felt I could git 'r done, check the thing off, and then deal with the confusing time sink.

Nothing quite like the boss showing up behind you to tell you that, no, your priorities must change. There's a whole bunch of .DAT files to be munged, and what we have isn't cutting it. So, when will it be done?

No clue.

No clue on several sorts of issues. I started this as a programmer who never did much more than recursive and iterative Fibonacci in Python, so I am not familiar and comfortable enough with the language to really say I know how to do anything fast. I'm still on the learning curve there.

Plus, I don't really know what all the problems are. I don't know how to solve the problems I don't know that exist. We're combining two machines and two Java applications with ssh, X11 and other things. It is a complex thing.

But those things are relatively minor. The more fundamental thing is that I do not think of tasks in time terms. How long a task takes is how long it takes. I don't want to think about the time aspect. It distracts from thinking about how to actually do the task. If I come up with the clever solution, it's done. If I don't, it takes forever.

2011/02/05

I have my trusty netbook on my lap. In one of my USB ports, I have a thumbdrive with the Ubuntu Netbook Live CD on it. I'm installing Ubuntu Netbook 10.10 right now. But not on my netbook's SSD. I'm installing it on an 8GB SD card.

I remember getting hard drives smaller than that. Storage-wise, I mean. Physically, they were the size of today's DVD drives. I'm sure that the performance of an SD card will bed poor compared to an SSD card, but a second face for $20 is kinda cool. Dual-boot on the cheap. My friend Patrick put Ubuntu on a thumbdrive so he could have "GoodOS" on his work laptop. I wanted to have something that wouldn't hang out too much. I don't use my SD slot often, so keeping it there works for me.

It's still configuring, so I can't say much. But such powerful and modular hardware is neat.

We have a TiVo. Finally. Yeah, I know we're ... a decade past the curve here? Something like that. I have to add that the TiVo+satellite box sucks because that means only one tuner, which means you cannot record this and watch that. But I have to say, the folks who say that the user interface to TiVo is a cut above? They have something there.

What sucks outright is the IR blasters. Well, they're OK, except there's no feedback loop. It would be far better to have the TiVo be the satellite box. I understand the HDMI interconnections of the Google TV box (of which there's really only the Logitech Revue, last I checked) have bi-directional communication, and that's what you really want.

It's a bit funny, though. We have a PC running Boxee and a Wii that does good Netflix. So far, we're widely distributed. I want a newer, faster PC for Boxee (and other duties, like home file+print server), and with the TiVo we now have access to Amazon On Demand. (Not like we've used it yet. We're still a Red Box family, and spinning discs of optical media at DVD quality is definitely a trailing-edge technology, no matter the shiny red vending machine.)

For Christmas, my father gave me his old TomTom. I have always wanted a stand-alone GPS, but not really for car use. Well, yes and no. I want a list of discrete lat&long coordinates I can map. I'm sure I can have that with the Evo phone, but I haven't really dived into that. Anyway, the point at this juncture is that I have a phone with a navigation feature, my wife had a phone with a navigation feature, and 2 of 3 sons had phones with navigation features. I thought "Hey, I'll never use this".

There are two reasons I've started to. First is the mount. I can mount the TomTom to the window and keep it in a good position. I don't have a good cellphone mount for the Evo. I love having the rolling map and the speedometer even when I don't have a destination set.

The second is duplication. I can have my phone set to do phone things, or provide audio, or even just on my belt as it should, and not worry about it forgetting my destination. Don't know how I'll really integrate it into my driving, though.

2011/02/03

It's the GKM561R keyboard from IOGear, which I got through NewEgg. It's got a built in trackball, which makes it better for multimedia settings than the Logitech wireless desktop I got before. I have always used Logitech wireless keyboards before, and I'm sure I'll get one again, but the mouse stopped working and got lost, and for multimedia applications, it makes sense.

2011/02/02

I dream of a lamp. A lamp using LEDs. A lamp that changes color, depending on the ambient temperature outdoors. If the weather outside is frightful, the lamp indoors is blue-to-purple. If Summer's here and the time is right, the light is yellow, orange or even red.

This dream is in part inspired by my workplace in the subbasement of my building. I can very easily forget the season, even, when I'm head-down into my work, so any reminder of the conditions outisde would be good.

This is an example of what was called Ubiquitous Computing or Pervasive Computing, depending on who generated the buzzword. In essence, the data is everywhere around you, not just on your PC.

The thing that's really keeping me from realizing this dream is a lack of electronics skill.

But that's a smaller thing today.

There's a thing called an Arduino, which is an Open Source bit of hardware that begins to open up the world of programming small things. I'm fairly sure I could, given an Arduino and a breadboard, begin to dummy this up.

This kinda gets me to categorization issues. Does this concept, an internet-aware fixture that determines the shade by the weather report fall under the Semantic Web? Or is it more tightly connected to the Internet of Things concept? Or is it a bit of both, like a Reese's cup?