Category: Technology - Slang's Anti-Singularity

VB6 migration... Now?

6/26/2012

VB6. Haven't heard that one in a while, have you? I seem to be about 8 years out of date. But if an application works, why change it, right?

One would think that embedding a spreadsheet into a Visual Studio 2010 (VS2010), VB-flavored form would be a fairly straightforward and simple process. One would even go as far as to say, "Gee, those Microsoft folks have Excel running around loose in the wild, maybe they'll even have a built-in component!"

One would be wrong on both counts.

Some background: years ago, I created a front-end application that would emulate the look of the timesheets we use for tallying the time we do for tasks. It linked up to the SQL back end, so the folks in Accounting could simply download the data into csv files for import into their magic buckets to spit out paychecks. For the most part, it all went swimmingly, with various levels of access to others' timesheets and two-level electronic approval, though the Accounting wonks never wanted to use the import function; apparently they preferred re-entering all the data from printed sheets. Whatever.

Fast forward 10 years. I've left and returned. The same VB6-based application is still in use, with nearly no changes. Now, for some inexplicable reason, that application is conflicting with the data access components we have in our extensive Word 2010 customization. Looking at the data access, I ensured all the Word stuff was using the latest ADO dlls (6.0) from the existing mishmash of 2.0, 2.5, 2.6, 2.7 and 2.8. Still, the timesheet app wouldn't work. Interestingly, re-installing the timesheet causes factory-access errors in our Word customization. Since the Word aspect of the division is much more important than the once-every-two-weeks timesheet, a fix for the timesheet was needed. I had two weeks until the pay period ended.

No problem. I would get the source code, poke around and find what needs updating. Anyone got a copy of VB6 running around? *crickets* As it turns out, there is not a functional copy of the combination of source code and VB6 application to make modification. Swell. Forced re-write time.

In trying to emulate the existing look and feel of the application (mustn't upset the users), I needed to embed a spreadsheet in a form. What a headache. To do so, one needs to download and INSTALL the office web components executable on every computer that will be running the app. Sorry, there will no simple dll and regsvr32.exe action for you! Manual process on every computer. I don't get it.

I tell you, if I need to do anything else on this timesheet, and/or if the replacement application (anyone hear of Tyler??) is delayed any longer or sucks more than anticipated, I'll scrap the VS2010 application altogether, and just customize the hell out of a spreadsheet and Excel instance. It'll likely be easier.

Moving Ahead With RunningAhead

6/8/2012

Run data, run data, run data. When will it EVER end? Probably with this post, is my guess. After this, well, I think I may stop harping about it, and simply enjoy the time outdoors and not worry about elevation profiles.

I recently started putting my run data on RunningAhead.com. I really like the site and the ability to graph multiple elements simultaneously on a single graph. I also like that it reads the data from my Garmin Forerunner 405CX wirelessly, too. That makes data upload easy. The only thing Garmin has on their site that I still occasionally look at is goal-progress. I imagine RA can implement that one pretty easily too, and eliminate any need for me to deal with Garmin.

When I uploaded some of my data, I noticed that, yet again, the elevation profile information was different from everyone else's. As part of a different conversation with Eric Yee from RunningAhead, I asked about why there were differences in elevation profiles for different sites. This is part of his response:

"It all depends on how the points are sampled. The elevation data are sampled differently depending on location. On RA, the entire country is sampled at every 30 meters. Some parts of the country also have 10 meter samples. The software will always choose the the highest resolution sample to use.

As you said in your blog, the points are expressed as a series of lat lng points. Since the elevation sampling is in a grid, most of the points do not fall directly on the sampling point so some interpolation is needed. This where where the difference between difference sites come from because each site will have a different interpolation algorithm. Sites such as RA and Garmin tend to have reproducible elevation profiles (within each site) because all the servers use the same algorithm.

Google is different. The reason you get a different profile depending on the computer you're using is that Google does a lot of things behind the scenes. Depending on a bunch of factors such as your computer's geographic location, OS, and who knows what else, your request will be load balanced differently. To make it more complicated, Google also do A/B test with their users so what you see will be different from what someone else is seeing. Depending on which server is handling your request, it may have a different algorithm because it takes time for the software to be deployed across Google's network. "

Wow. Google is different. I also think there is a fudge factor at play on some of my runs in the data itself. If, for example I am following a trail on the side of a fairly steep hill, the trail may be in fact "flat" as it is following the contour. However, the GPS is not ever spot on, and it may be tracking a point 20 feet to the right, then 5 feet to the left, and so on. On a steep hillside, that 20' right might be 15 feet higher than I am, and the 5' to the left may be 10 feet down. So in the course of my movement of 10 feet straight ahead, and level, the GPS just might have tracked a 30' loss of elevation. Or so it seems to me.

At any rate, have a great weekend. My loin-fruit are free of school as of this afternoon, so they'll be as happy as I am tomorrow: they get to sleep in, and I get to go for a run before the big 13th birthday party for my son. O_O

Run data slicing and dicing

5/22/2012

When I run, I usually tote along my Garmin Forerunner 405CX in order to keep track of the miles trod, and to capture the information into courses and routes for others to (potentially) follow if it turns out to be a good one. Since not everyone uses Garmin products and may not want to use the Garmin website's courses feature, I also convert the GPS data to Google Earth and post all the information into a .kmz file (scroll to the download link) for viewing in Google Earth on a local pc.

The data is the same: XML data containing latitude and longitude and that's about it. When it gets to either the Garmin website and/or Google Earth, that data is interpreted over maps to give the user a visual look of the data rather than lat/long coordinates, and gives distance, and elevation profile. This is where it gets all divergent.

I did a run last Friday that I converted to a course. The base run data as uploaded is shown below (Sorry, you don't get to see my imminent heart attack displayed in the heart rate info, nor the "trudge factor" in the timing chart.):

When I elected to save the run as a course, the data changed! Instead of being over 7 miles, the course data was 6.95, though the elevation data remained the same with a gain of 1066 feet. However, I do like that the elevation profile no longer starts at sea level, making the 1000+ elevation gain almost look like it hurt as much as it did.

In addition to saving the run as a course, I used the Garmin function to export the data to a Google Earth file. This conversion results in yet another divergent data set. In this case, the run distance shows as 7.05 miles, which isn't too terribly off (only 1 %) from the base run data, but a big delta shows up in the elevation gain: 1458 feet. Wow. That's a 37% difference! I must admit I much prefer the look of a Google Earth elevation profile over either Garmin:

Just looking at the elevation profiles, I get the feeling that Garmin is smoothing the data that erases the small changes in elevation despite using Google as the mapping base. However, over the course of a longer run, the tiny smoothing changes the overall run a lot. Those three and five foot elevation changes on the trail add up. Tell me. Toward the end of a run, any little hill up -- only to go back down -- gets a sound round of cursing from me.

VBA, ClickOnce Applications and Parameters - oh my!

5/18/2012

I'm a big fan of the KISS principle: "Keep It Simple Slang." I tried following the instructions for passing arguments to a clickonce application, and though I am not stupid, they seemed, I don't know, complex. I went for a much simpler route that works well in my environment.

Let me back up and give the situation. I have a simple clickonce application call AlphaWave that allows users to select from a couple of drop down lists, and enter some information into a text box and maybe add an image to provide feedback to me. Pretty simple stuff. What I wanted to do is to pre-populate one of the dropdowns based on the application that was calling the AlphaWave app so the user wouldn't have to. Again, pretty simple stuff. Or so I thought. Searching through the morass of blogs, MSDN articles, and other assorted goop, I found a couple of good articles that discuss it. The discussion was in-depth and complex. But I am lazy; I don't want to work that hard. So I bypassed all the passing parameter stuff in the usual way. What I did, is I create a text file with the parameters in it before calling AlphaWave through a Process.Start method in my Visual Studio 2010 VB application. In this particular case, the call was on a button click event. The WriteAllText line is what creates a text file and populates it with a string (the second parameter). In this particular case, the string "Sisyphus" indicating the application that is calling AlphaWave.

Const cAlphaFile As String = "C:\alphacall.txt"
Const cAlphaApp As String = "C:\ProgramData\Microsoft\Windows\Start Menu\LCB Applications\AlphaWave.appref-ms"
'What we are writing is the parameter string to be read later. In this case, it's a single line
My.Computer.FileSystem.WriteAllText(cAlphaFile, "Sisyphus", True)
Try

Process.Start(cAlphaApp)

Catch ex As Exception

MsgBox("Your application not found error message here.", MsgBoxStyle.Information)

End Try

The Process.Start line fires up the AlphaWave application itself, so from the perspective of the calling application, the job is done. A parameter has been "passed" by writing to the text file, and the AlphaWave application started.
In AlphaWave, I needed to set the startup object to be Sub Main and have that look for the text file with the parameters in it before displaying the form itself. If the parameter text file exists, I read its contents as the equivalent of a passed parameter, kill the file, then continue processing the AlphaWave form startup. If the text file doesn't exist, the code bypasses it all and I just don't have the parameters loaded into strParameters for launching AlphaWave. Simple and fast enough.

The additional code dealing with the cAppVersion is how I display the version number of the app. If it's deployed as a ClickOnce, it reads the data from the Deployment object. If it isn't, I am working in my own dev environment, and I display that.

Public strParamaters as string
Dim cAlphaCall as string = "C:\alphacall.txt"
Try

strParameters = My.Computer.FileSystem.ReadAllText( cAlphaCall )

Kill( cAlphaCall )

Catch ex As Exception
End Try
' Identify the version in the app
If Deployment.Application.ApplicationDeployment.IsNetworkDeployed Then

cAppVersion = "v. " & Deployment.Application.ApplicationDeployment.CurrentDeployment.CurrentVersion.ToString

Else

cAppVersion = "Development version"

End If
theForm.lblVersion.Text = cAppVersion
Application.Run(theForm)

Calling a ClickOnce Application from VBA

The second problem I had to solve was calling the app from inside VBA code. AlphaWave's raison d'être is to serve as a feedback process and – in addition to stand-alone applications – there is a lot of custom code in MS Word for which I need feedback.

The "Process.Start" method is not available in VBA, and the Shell command only works against .com, .bat or .exe files. A conundrum in that it appears there isn't a way to launch a clickOnce application from within a MS Office application. Why? A ClickOnce application is a completely different animal with an extension of appref.ms. Another search across the web pretty much resulted in nothing.

After thinking a bit, I cleverly (I think) came up with a clickOnce Application Launcher... application. It is a console app, taking as a passed argument the path to the clickOnce application I want to start. Since it can easily take in an argument, AND it can also launch appref.ms files, the problem was solved. Below is the ENTIRE contents of the clickLauncher application:

Module Module1
Sub Main()

Main(Environment.GetCommandLineArgs())

End Sub

Private Sub Main(ByVal args() As String)
If UBound(args) = 0 Then

MsgBox("This application is designed to be launched from VBA Code with an argument of a path to a clickonce application as follows:" & vbCrLf & vbCrLf & _
" RetVal = ShellExecute(0, ""open"", chr(34) & & chr(34), Chr(34) & & Chr(34), """", 0)" & vbCrLf & vbCrLf & _
"Double clicking it without passing an argument of the clickonce app path will do nothing other than get you this message box.")
Exit Sub

End If
Try

Process.Start(args(1))

Catch ex As Exception

MsgBox("The ClickOnce application that you are trying to launch (" & args(1).ToString & ") was not found in the expected location." & vbCrLf & _
"Please ensure it has been installed locally, and the shortcut properly located in the LCB Applications folder.", MsgBoxStyle.Information)

End Try
End Sub
End Module

Here is the VBA code that is used to call the app launcher to instantiate a ClickOnce app. You will need a reference to the ShellExecute function at the top of your module:

Private Declare Function ShellExecute Lib "Shell32.dll" Alias _
"ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation As String, _
ByVal lpFile As String, ByVal lpParameters As String, _
ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long

Sub VBACallToLaunchClickOnceApp()

Dim strLauncherPath as string
Dim strAppPath as string
Dim RetValue as Long
strLauncherPath = ""'this is the path to the clickOnceLauncher Application
strAppPath = ""'this is the path to the appref.ms shortcut you want to start up
RetVal = ShellExecute(0, ""open"", chr(34) & strLauncherPath & chr(34), Chr(34) & strAppPath & Chr(34), """", 0)

End Sub

That's it. I hope someone else can find the results of my investigations useful. Have a great weekend.

Security Theater - part 2

5/15/2012

Earlier this month, I had related the impression I had that security requirements for front end users is mostly theater, and that the vast majority of the hacking and unlawful access comes from the backdoors. Seems to be the case. I just read a very interesting article in Wired titled "Everyone Has Been Hacked. Now What?" that indicates the same thing.

Couple that with the information that Anonymous has claimed to have accessed all the confidential databases in the US government, and, well, I want to throw up my hands, get back my Macintosh SE (with dual floppy drives) and break out Mystery Box and let the Internet go by.

Unfortunately, I can't do that. The society in which I live nearly requires an online presence, despite the pitfalls of rampant hacktivism and the specter of my personal information in the hands of some smarmy, unwashed dung beetle wanting to sell it or rip me off.

Sigh.

Cyber-security Theater

5/8/2012

Recently, I had to update all the security questions for the AppStore for my Apple devices. This had closely followed a string of required changes to my passwords for a number of different websites. Seemingly, they all now require upper case, lower case, non-character and at least one number or some such stupidity in every password. Oh, and it needs to be at least 15 characters in length. (Some hyperbole there. Some.)

I don't get it. Has there been a rash of identity thefts of people stealing passwords and spoofing individuals on the Internet? I haven't heard much about that kind of activity since the 1990s. Admittedly, I am not privy to a lot of security discussions on the web, but still, all the tempest over users' passwords seems to me to be a bit of misdirection. You see, where are the big security breaches? Not with an individual password being hacked. No, it's with somebody hacking the backdoor of a company and stealing millions of users' information - including their passwords.

Seems to me that forcing the users to update their perfectly adequate password is an attempt to show "See? We are all about the security! We force you to change you password and make it impossible to remember!" when they need to be watching their own practices and back doors for the far, far more egregious thefts.

Perhaps somebody can tell me that I am wrong.

Rooting for the NFC

5/4/2012

For all the American football fans out there who thought I was going to discuss the Green Bay Packers, or the New York Giants, or even the lowly St. Louis Rams, sorry. I think the title has misled you a bit. Not to say I don't like football, but the only NFC team worth rooting for is the 49'ers, and they follow most of the AFC in my hierarchy. I guess I have a bit of a bias after growing up in Denver, with relatives in San Diego. But I digress.

The NFC I am rooting for is Near Field Communications. Using NFC is how I envision a scene that played out in my head when I was reading an Alan Dean Foster novel many years ago (I think the novel was Orphan Star, but it was a long time ago). In that book, two people have decided to perform a financial transaction. One person checked his balance on a card he was carrying, saw there was enough and made the transfer to the second person. All without need of a physical transfer of fungible items.

For the most part, we are there with the ability to transfer money between Paypal accounts from a smart phone. What will get us completely there, would be the addition of NFC (and biometrics, but I'll get to that). With NFC enabled on my (and my transaction partner's) phones, a financial transaction could simply be a process of tapping out the amount to transfer, putting the two phones in close (a few centimeters) proximity, and allowing the process to happen. Why NFC is integral is that it doesn't work for distances beyond a few centimeters (approximately an inch). This significantly reduces the potential for data theft that can occur via the Bluetooth technology (both using RFID signals). Android phones already are implementing NFC technology, but iPhones are not; they are thought to be doing so this fall with the phone following the 4S. At that point, all that's needed is the Paypal app that can implement it. I do realize that Google Wallet is already possibly implementing NFC, but who uses it in comparison to Paypal?

Now let's really take it to the next - and I believe attainable - level. Instead of a lame 4-digit code to unlock the phone, make it biometric and seamless. My hand grabs my phone, and it recognizes that it is me and completely unlocks it. Someone else? Well, there can be various levels of access. For example, my kids would get to play some games, maybe see some photos. Someone other than me that tries to access it multiple times without me unlocking it, the phone shuts down. Heck, add in an automatic call as stolen and reveal its location, and/or scrubs all contents. Secure and safe. Am I OK with my data scrubbed? Yes, because I back up my stuff... do you?

While I am at it, there needs to be increased durability. Exiting smart phones are still too fragile. Gorilla glass, for all its strength and scratch resistance, can't take a fall. I have high hopes for Liquidmetal that is rumored to be in consideration for the next generation of phones.

I want something as durable as a credit card, with biometric recognition, NFC data transfer, and self charging either through PV or kinetic recapture. I'm not asking for much. Oh, and I want it when my current iPhone 4S is in need of replacement. Sound good?

iAppliance updatable? Saweet!

5/2/2012

I am now able to update my blog (and perhaps more on the website) now with an iAppliance application. (iAppliance meaning iPhone/iPod/iPad).

Pretty sweet. I like that I can do it when I have down time waiting for a child at an event, or during lunch at work, like I did just now, with this quick post.

Flashback Mac Attack

4/19/2012

One of the selling points I have heard in the past regarding the Macintosh vs. Wintel configuration for a personal computer, was that a Mac was not susceptible to virus attacks like a Wintel machine. This is likely a big selling point for people who don't want the added complexity of having to buy, maintain and configure a software package designed to monitor and eliminate potential virus and/or spyware on your computer.

That was a disingenuous argument at its best, because it always was vulnerable - just less so. Now, as the Macintosh goes more mainstream and increases in popularity, people who get their jollies by writing malware are targeting Macintoshes more and more.

The current preferred method of attack seems to be through Java apps on websites that access the Mac OS through the installed Java application on the Mac that runs the webapp. Last week a large attack titled "Flashback" infected anywhere between 700K and 800K Macintoshes. Apple was slow with addressing this, but finally came out with a security update last week. Mac users need to take a cue from their Wintel cousins, and be a little more cautious about what and where they are clicking out there in the wild web world.

More information can be found here, and here. Tools have been released to address the potential vulnerability if you need to check. Security companies had tools out before Apple had the fix to the OS addressed, so if you are prone to Java play on the internet with your Mac, you may want to check this out.

To suffer a flashback of a different type and quote an old 1980's police TV serial, "Let's be careful out there."

Happy Paraskevidekatriaphobia Day

4/13/2012

Spooky day, Friday the 13th and all. Of course, it's as rare an event as a Tuesday the 4th, or a Saturday the 22nd, but superstition has no logic.

Even spookier this year is Saturday the 14th, when I will be timing for a local race. Of course, since I am working it, the weather gods have decided to bestow typically capricious northern Nevada weather on it. The forecast is for snow and rain overnight and stinkin' cold start. Sigh. Oh well. At least I get to simply stand in the potentially foul weather wearing appropriately thick and waterproof layers. More often, I am on the other end, wearing something appropriate for running. In that case, I am freezing at the start in order to not be overheated mid race. Then, at the end, I am warm for about 5 minutes until the sweat starts to freeze to my skin. For a 5K – as this race Saturday is – that makes me warm for somewhere around 30 to 35 minutes.

Yeah, I guess I'm happier this time working rather than running. I am going to escape at some point Sunday for a run for me. I haven't completely decided what route, but I'm leaning toward doing the Devil's Butterfly. If I'm feeling strong and social, it'll be posted on the CCRunners calendar by Saturday evening.

Unfortunately, since I'll be at the race until 11 or so on Saturday, and my office is within walking distance, and since I have some data consolidation to do, I'll likely work a good part of Saturday afternoon. For some inexplicable reason, the various databases I am now interacting with each have their own table of employees. The same people are identified in multiple databases and tables, essentially with the same information. My initial proximal task, since I chose to accept it (Jim Phelps reference anyone?), was to provide a meta-view of the information contained in the different databases, but in a cohesive, single view.

But since each user is identified in different databases, with different IDs (and not a primary key in sight), the former proximal task has become distal to merging common, employee data into a single source, and fixing all the stored procedures to do the lookups. Oh, yeah, and crawl the data and update all the existing reference IDs to the new ones. Sweet, eh? Maybe in a few weeks I'll get back to what I was initially tasked to be doing.