Monday, July 9, 2018

The Guin Constant

I was reading James Apnes Notes on Discrete Mathematics  this last week and came across this statement in section 2.1.5:
"The natural numbers N. These are defined using the Peano axioms,
and if all you want to do is count, add, and multiply, you don’t need
much else. (If you want to subtract, things get messy.)"

Since the book is aimed at Computer Science majors at Yale, I was bothered by this statement right off the bat.  Computers are pretty good at some aspects of mathematics, but not all.

In this case, I can't use a computer to count.  Eventually, my computer will run out of memory. When I try to add one more to the current number, my computer will crash.  I know what you are thinking: "I'll just add more memory!"  (It's turtles all the way down).  That won't work either since memory is made out of matter, and the universe in which we live has some finite amount of matter.

So suppose we used each bit of matter (atoms, leptons, whatever smaller building block we discover next) 100% efficiently to store the biggest number we possibly can store in this universe.

I call that the Guin Constant.   It is the biggest number this universe can hold precisely using all matter to store it.

And please don't add one to it.  I'd hate to crash this universe.

Questions, comments, concerns and criticisms always welcome,

PS: apologies to mathematicians if this constant already exists.  It's hard to find information like this with internet searches and/or the math books within arms reach of me right now.

Friday, July 6, 2018

Moving day for tests

One of the tasks on my plate is breaking up our old (old!) test suite.  We have a set of tests that live in this suite and without getting into the gory details, they need to be moved out of that project.  In short, that project is old and needs everything to be built to be used for testing.  Since unit tests are designed NOT to need everything built - just the bit of code I am trying to test - this is not a good paradigm to follow long term.

So we have started to break up these old tests and move them to the best location (module) into which they belong.  It's going well so far  but as some tests are really old they become troublesome and time consuming to move.

In the process, I have learned more about Cmake than I ever wanted to know!  As you can imagine, if a test is moved from its original location and into a new location, the file that directed it to be built in the old location needs to have that entry removed.  And the file that instructs the compiler for the new location needs to be updated to include the new file as well.

So in the best case, a single move has to update three files.  I haven't hit that best case yet - there are always more updates  needed - but I am getting better at it each day.  If you are interested, let me know and I can post more details.

Questions, comments, concerns and criticisms always welcome,

Friday, June 29, 2018

This week's extremely annoying and catastrophic bug

Somehow - and I have no idea how it happened - my Windows PATH environment variable got completely cleared.

The PATH variable is a list of folders on the hard drive that are accessed, in order, when I type a command at a command line (among other things).  So if I have a command window open and type "python" to start python, Windows will look for a program named python.exe (or .bat, or .cmd) in my current location.  If it finds one, it starts it.  If it does not find python there, it looks in the first folder of that PATH variable.  If Windows finds a python program there, it runs it.  If not, it looks in the next folder in that list, and so on.

I have probably a dozen commercial tools like python installed that use this.  I also have a couple of dozen batch and command files I have written to do repetitive tasks that I put in c:\windows\system32 (since that is always in the PATH) so they are always accessible.

But since that list got wiped, this all broke.  And the only way I have to restore it is to find broken applications, one at a time, that have dependencies on that PATH variable to work right.  When they fail, I have to either repair the application, reinstall it or manually figure out what went wrong and fix it myself.

Frankly, this has taken a tremendous amount of my time this week and I honestly think I might have been better just reinstalling everything on my C: drive from the ground up.  I keep all my data on a different drive so I wouldn't be that far behind the curve when done.  But at this point I have most of my key applications fixed so I think I will stay on my current path.

But this really messed up my week.  Sigh.

Questions, comments, concerns and criticisms always welcome,

Thursday, June 21, 2018

Workaround for the Tabpy bug

I've spent the last couple of weeks heads down on the Tabpy bug reported over on our site:

Essentially, we broke some customers when we rolled out 2018.1 servers.

It took awhile to narrow down the defect.  After a lot of hard debugging, we isolated the cause to servers that had never set a timeout value. The timeout controls how long Tableau will wait for a server response.  Anyway, if that value is not set at all then the server will default to a 0 time.  This causes it to wait no time at all for a response, and then give up when the server does not respond in zero time.

Embarrassing and annoying for sure.  But as we mention on the site, there is a workaround.  Run the tabadmin tool to set a value (directions are in the thread above).

Now that we know the cause of the error, we can start working on a fix.  Stay tuned for that.

Since this has taken almost all my time for the  past two weeks, I wanted to share an update on where we are.

Questions, comments, concerns and criticisms always welcome,

Wednesday, June 13, 2018

Tableau is aquiring Empirical Systems

Almost missed this big news today.  Tableau is purchasing/acquiring Empirical Systems:

Again, this is good news.  Check it out and feel encouraged to let me know what you think.

Questions, comments, concerns and criticisms always welcome,


Stepping back to look at a partner team here at Tableau

One of the teams at Tableau is called the Extensions team internally.  They are releasing a new feature to connect data to Tableau and are in the 2018.2 Beta 2 release of Tableau.

I listened to their online training on this and they admitted to a bug they had with their original beta release.

The original manifest XML we posted on github for our fiirst beta had a typo in it. 
Check out this one line:
<manifest xmlns="" manifest-version="0.1">

Do you see the typo?  There are 4 ws in the url.

It should have been
<manifest xmlns="" manifest-version="0.1">

When troubleshooting, this was pretty easy to find (but embarrassing).  It is also easy to fix - just delete that extra w.  And anyone writing code to use extensions could presumably make that fix as well for the beta releases.  Clearly, we are fixing this for final release.

I appreciate this bug, though, since it is a great example of the need to be meticulous with checking text.  That file is not that large, but reading XML can be tedious and typos can creep in.  It is also an example of NOT changing strings right before you release a piece of software. 

Anyway, I thought I would share this bug and fix.  Extensions are pretty terrific - check them out if you have a preview account at

Questions, comments, concerns and criticisms always welcome,

Tuesday, June 5, 2018

Another busy week in Tableau Test

As usual, there is plenty of activity on the test team this week here at Tableau.

A random sample of activities, all of which are typical:
  1. Test pass week!  We ship every quarter (from the test point of view, this happens MUCH more frequently -I wrote about this 2 weeks ago)
  2. Finding and filling holes in test coverage.  With a product as agile as Tableau, the current state is that we have some source code files without adequate automated test coverage.  One of the test teams' tasks is to find these files and add tests to validate the functionality of that file.  This is a fairly straightforward task to explain, but if (and when!) the code is complex, adding tests can be a time consuming event.
  3. One of our testers is adding a rolling log handler to tabpy.  Hop over to github to see her proposed changes.
  4. Oddly, we are updating our Windows machines to the latest version.  That takes a half day - I wish I would have known that BEFORE I clicked the button Monday morning.  I would have waited until the end of the day.
  5. Many server setups and configurations centered around R and Python external servers.  We're getting ready to test the secure capability we are adding to those services.  Again, see the tabpy site for details.
  6. Automation analysis results, find/file/regress bugs, etc…  The standard test workload is always ongoing.

So we are set for another full week of activity here.  Nothing too special about this week so I am just sharing a "day in the life" type of update.

Questions, comments, concerns and criticisms always welcome,