Getting caught up here and in my day job!

I just noticed that I haven't met my self imposed goal on updating this blog every week.  I've been locked down with so much day to day work this simply fell off the radar.  Instead of any insight (that's coming up :)  ) I'll share what I have been doing.

1. Filling holes in test coverage.  I had time to look at our code coverage numbers and found some holes in our coverage.  I have added some tests to validate the code continues to do exactly what it was designed to do.
2. Identifying holes in coverage.  As we get ready to send features out to our customers, we review the test plan we have in place to ensure we did not let any test cases slip through the cracks.  We find some very small gaps in our coverage when we did this exercise last time, so I added some tasks to our to do list and have been helping to get them done.
3. Had some good internal training on hiring practices and other activities like that.
4. Many (many!) discussions with partner teams about adding cross team features in the future.
5. Preparing for Tableau conference (I wrote about this last time).
6. And then simply doing my "regular" job has been very time consuming recently.

Looking ahead, I have been thinking about this situation.  If you give an artist a rake as the only implement to use to make some art, you had better expect to see some leaves.  I'll dive into that comment next up.

Questions, comments, concerns and criticisms always welcome,

John

I'll be speaking at Tableau Conference this year

Just got my confirmation that I will be co-speaking a Hands On Training for Basic Statistics in Tableau.  This should be a great experience - our team owns all the code that drives the features we will be teaching.  And since I am a tester, if there are any glitches, I guess I can only look in the mirror for who to contact about them (heh).

More about Tableau Conference here: https://tc18.tableau.com/

Now I need to go prepare the topics which we will present!

Questions, comments, concerns and criticisms always welcome,

John

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,
John

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.

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,

John

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,
John

Workaround for the Tabpy bug

I've spent the last couple of weeks heads down on the Tabpy bug reported over on our site: https://github.com/tableau/TabPy/issues/106

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,
John

Tableau is aquiring Empirical Systems

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

https://techcrunch.com/2018/06/13/tableau-gets-ai-shot-in-the-arm-with-empirical-systems-acquisition/

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,

John