Monday, September 15, 2014

Reach the Beach Relay - 2014

Massakruliks - Mens Open

234/521 - 34/46

Back row from left: Paul (leg 12), Dave (leg 9), Randy (leg 2), Gavin (leg 8), Erin (leg 3), Jackie (leg 6), Jim "Wiggy" (leg 11)

Middle row from left: Steve (leg 1), Ali (leg 10), Jen (leg 4), Leon (leg 7)

Front row: Vince [aka: Me] (leg 5)

Vert
Distance Difficulty Gain Loss Net Flair Time Pace
Leg 5 5.5 Easy 73 388 -315 +11 37:25 6:48
Leg 17 9.1 Hard 773 739 34 +22 1:09:50 7:40
Leg 27 * 8.57 Hard 471 530 -60 +11 1:08:44 8:00
23.17 +44 2:55:59 7:36

* Due to an injury in our van, some switching happened and I volunteered for the longest of the last set of legs.

Monday, June 23, 2014

Perl and SQLite - Follow Through, On and Up

As follow through to my previous post, I did some investigation into SQLite and got that working in my little database proof of concept script.

As follow-on to my digression in that post, SQLite adds yet another wrinkle in the AUTO_INCREMENT saga I used as a primary key in each of my tables. These are the strings I found to work:

Microsoft Access
ID AUTOINCREMENT NOT NULL PRIMARY KEY
MySQL
ID INT AUTO_INCREMENT NOT NULL PRIMARY KEY
SQLite
ID INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL

As follow-up to my statement about not finding a way to programmatically instantiate a MySQL database, I did some searching and found the following in the 'perldoc' for DBD::mysql - I have yet to try it.

$rc = $drh->func('createdb', $database, $host, $user, $password, 'admin');

...

createdb
    Creates the database $dbname. Equivalent to "m(y)sqladmin create $dbname".

And finally, the topic of this post. I found this neat little Perl extension for SQLite and thought I might give it a try.

Learning from my last post, I checked my SQLite version and it was 32-bit, so I switched my Perl to Strawberry 5.18.1 32-bit on Windows 7 x64 and followed the steps outlined in that post. It worked a treat first time! So I ported the executable extension to my other machine and tried it and it failed.

Knowing my other machine was 64-bit for everything I switched Perl back to Strawberry 5.18.1 64-bit on my original machine and failure there too. It makes sense; I compiled a 32-bit Perl extension for a 32-bit version of SQLite - it stands to reason it would need a 32-bit version of Perl to run it. But I use 64-bit Perl normally.

Easy enough solution, I grabbed the sources for SQLite from their download page and compiled myself with the 64-bit gcc from Strawberry Perl 5.18.1 64-bit. This incidentally was the easiest build I've done - no warnings, no errors, built first time.

gcc shell.c sqlite3.c -o sqlite3.exe -lpthread

I redid the extension compile with 64-bit Perl and all worked again - this time all with 64-bit.

Since I did this a few times (due to my own mistake), I created a Perl package with a Makefile.PL to easily rebuild the SQLite Perl extension whenever / wherever needed.

Tuesday, June 17, 2014

64-bit Solution for "2-bit" Perl Problem

I'm not a Perl programming by trade, I just know enough to help me in my day to day activities. That said, database development / interaction with Perl is not a day to day activity, but it's something I feel I should know at a base level for the few times I've needed it in the past. To that end, I have a simple script that illustrates database instantiation, creation, population and some data manipulations with Perl.

I mainly use Windows, so the database for my little experiment was Microsoft Access as that's the most common database found on Windows; usually part of an enterprise Microsoft Office installation. I also have a view to cross platform capabilities, so I made my script check the operating system ($^O eq "MSWin32") and if not Windows, use MySQL as the database.

<digression>This presents some issues with database creation - creating tables has a different SQL syntax between Microsoft Access and MySQL so again an operating system check is required for some activites. For example, both have the concept of auto-increment, but MySQL is AUTO_INCREMENT, Access is AUTOINCREMENT. And while MySQL needs a type definition (INT AUTO_INCREMENT), Access believes AUTOINCREMENT is explicitly an integer type of its own, so will fail with INT AUTOINCREMENT.</digression>

My script:

  1. Instantiates - make a database (if it doesn't already exist)
  2. Creates - create the tables / schema in the database
  3. Populates - adds some data to the database
  4. Manipulates - does some SQL INSERT, UPDATE, DELETE, SELECT queries

I couldn't find a way to programmatically instantiate a database in MySQL - the database needs to exist for my script to use it. It's easy enough to do with some simple MySQL commands (with operations for a test example emphasized over secure best practices):

$ mysql -u root -p

mysql> create database PerlTest;
mysql> grant usage on PerlTest.* to perluser@localhost identified by 'password';
mysql> grant all privileges on PerlTest.* to perluser@localhost;

I did find a way to programmatically instantiate a Microsoft Access database in Perl. It relies on Win32::OLE, standard with Strawberry Perl - my Perl of choice for Windows.

use Cwd;
use Win32::OLE;
use Win32::OLE::Const;

my $dbname = getcwd . '/' . 'PerlTest.accdb';
my $props = Win32::OLE::Const->Load('Microsoft DAO')
my $dbLangGeneral = $props->{dbLangGeneral};

my $Access = Win32::OLE->new('Access.Application', 'Quit');
my $Workspace = $Access->DBEngine->CreateWorkspace('', 'Admin', '');
my $Database = $Workspace->CreateDatabase($dbname, $dbLangGeneral);

It's at this point I should mention I did this years ago on Windows XP (32-bit) with Strawberry Perl 5.10.1 (32-bit). I've since upgraded to Windows 7 (64-bit) and Strawberry Perl 5.18.1 (64-bit) and along the way, the script "broke".

I decided for no particular reason the other day to see what was wrong. I was sure it was a 32/64 bit issue with the instantiate code. On Windows 7 64-bit, I could instantiate the database with Strawberry 32-bit, but not connect to it for steps 2 through 4. With Strawberry 64-bit, I couldn't instantiate the database, but could do steps 2 through 4 on an existing database.

It turns out, there isn't a 64-bit version of "Microsoft DAO" and instead, you should rely on "Microsoft Office 14.0 Access Database Engine Object" for similar functionality. Changing the line to read:

my $props = Win32::OLE::Const->Load('Microsoft Office 14.0 Access Database Engine Object')

did the trick!

Next step - testing this all with SQLite.

Friday, May 30, 2014

The Adventures of Rich and Vince




Characters courtesy of SP Studio

Thursday, May 08, 2014

SDN - Outlook

The value proposition of Software Defined Networks (SDN) begs the question, what is the promise versus what is the reality? Most of the current literature states SDNs value proposition in list format without clear, well-defined use cases as to where it can directly benefit today's complex enterprise networks. To state it another way, SDN may be an panacea, but the path to get there from today's reality is obfuscated.

That leaves us with two main points:
  1. uptake will probably be phased, adopting pieces of SDN architecture that provide clear and immediate benefits with little disruptive change to existing infrastructure, and
  2. know what problem you are trying to solve and use SDN architecture concepts if they are the right fit.

Monday, November 11, 2013

Fifth Annual RI 6 Hour Ultramarathon

On Sunday, November 10, 2013, I ran in the fifth annual RI 6 Hour Ultramarathon. My goal - as in past years, was to do at least as well as I did the previous year.

The official results place me 11/93 with an official total mileage of 40.515 miles in 5:57:28.1.

The table below documents my miles and times (by my watch).

RI 6 Hour Ultramarathon: November 10, 2013
LapMileageCumm.
Mile.
Lap SplitCumm.
Time
Lap PaceAvg. Pace
12.72.722:22.320:22:22.308:17.208:17.2
22.75.422:06.630:44:29.008:11.308:14.2
32.78.122:09.401:06:38.308:12.408:13.6
42.710.822:12.881:28:51.208:13.708:13.6
52.713.522:31.301:51:22.508:20.508:15.0
62.716.222:34.312:13:56.808:21.608:16.1
72.718.922:43.452:36:40.308:25.008:17.4
82.721.622:57.882:59:38.208:30.308:19.0
92.724.323:43.083:23:12.208:47.108:22.1
Marathon26.2--3:40:20.0--08:24.6
102.72723:53.533:47:14.808:50.908:25.0
112.729.724:47.514:12:02.309:10.908:29.2
50K31.25--4:24:51.0--08:28.5
122.732.426:07.194:38:09.509:40.408:35.1
132.735.126:56.685:05:06.209:58.808:41.5
142.737.828:08.925:33:15.110:25.508:49.0
152.740.524:12.765:57:27.808:58.108:49.6
Totals:40.5155:57:28.108:49.6

Friday, November 01, 2013

Trick or Treat - KitKat Halloween Candy

I didn't get a new Nexus 5, nor do I have Android KitKat 4.4 on my Samsung Galaxy S3. However, others have managed to get the APK's for some new Google apps off the Nexus 5. I didn't venture to load the Google Experience Launcher - I use Nova Launcher Prime in favor of standard Samsung TouchWiz. But I did have to test drive the new Hangouts app - now with integrated SMS.

At this point, the Play store did not have the updated Hangouts v2 (only version 1.2 which I had loaded). I grabbed the APK, did the standard side-load procedure through ES File Explorer and tested it out.

At first startup, it notified me that it can handle SMS and asked if I wanted to enable it. Hell yes! And 'BAM', there it was - all my existing SMS threads showing up (including MMS messages) in the Hangouts interface. I tested with some texting to/from the phone and received messages in both the Hangouts app and the default messaging app - as I expected (they're pulling data from the same store).

I did not get the standard messaging app notifications when texts arrived - only the Hangouts notification in the notification bar - excellent! So no double notifications, but message counts is the only thing missing. As I mentioned, I use Nova Launcher - more specifically, TeslaUnread - to put the unread count overlay on things like GMail and messaging. It never worked for MMS messages, and now it doesn't work for SMS either. No unread count overlaying the Hangouts icon in my dock. Not to worry, with the notification bar working, I'm sure I won't miss any texts.

So even though no KitKat (bars or software) were received for Halloween, I still did get a treat! Now just waiting on Google Voice VoIP calling so I don't have to use Talkatone.

 

Copyright © VinsWorld. All Rights Reserved.