Expanding unit tests for Tabpy - the Python connector for Tableau

Now that Tabpy has a unit test framework (thanks Bora!)  I decided to add a few unit tests to check for error handling in the event of malformed URLs and such.  This was a relatively straightforward task and, like many test tasks, uncovered a defect in the code.

In this case, we allow for a timeout setting - a set number of seconds to wait before "giving up" (I'm simplifying here).  The documentation for that command said that the number of seconds you tell it to wait cannot be None.  When I was looking at the unit tests here, I saw there was no check for None so I added it.  Then I thought about it a little more and realized that I could pass in a negative amount of seconds to wait.  That makes no sense at all, so I also added a check for that condition.  So at about line 90 (in current versions) of \tabpy-client\client.py, you can see the code I added:

        if query_timeout is not None and query_timeout > 0:

            self.query_timeout = query_timeout

        else:

            self.query_timeout = 0.0

The unit test for that change is also pretty simple:

        client = Client(

            endpoint="endpoint",

            query_timeout=-10.0,

            verify_certificate=False)

        self.assertEqual(client.query_timeout,0.0)

If you haven't installed Tabpy feel free to hop over there and give it a shot.  It's also now available on Pipy so you can pip install tabpy if you want.

And please add some more testing if you like!

Questions, comments, concerns and criticisms always welcome,

John

New team name!

For a while now, we have been contemplating renaming our team here at Tableau.  We have (had) been the Statistics team since I started.  While that is a great name, it really did not reflect our day to day work.  We use statistics for all that we do, but we don't create new algorithms or anything like that.  It would be roughly akin to calling a team that works on cars the Algebra team if you use algebra to compute mileage or whatever.

So after thinking about it for almost a year (!) we finally settled on the Advanced Analytics team as our name.  We're still getting used to it and I hope it starts to roll of the tongue easily as time goes by.  Our mission is the same - to help you see and understand your data - so the day to day work doesn't change.  But it does help define our role a little better for both internal teams and even when we partner with outside folks.

So here's to Advanced Analytics!

Questions, comments, concerns (and a cool nickname) always welcome,

John

Some comments about comments in code

I was looking at a code review recently and was reminded of the old piece of advice I once received:  "God comments in code do not explain what the code does, they explain why the code does what it does."

I agree completely.  I was looking at some code to validate we use the correct font.  The code would change from normal, to Light, to Bold, etc… and preceding each of those commands was a comment that said "Changing to Light", "Changing to Bold, " etc..  For a simple task like this it is not too hard to figure out why the font is being changed.  In this case, we want to validate the Bold font, the Light font and so on.  But when code gets trickier, the why the code exists becomes much more important.

Oh, one other thing that drives me up a wall.  Typos in comments.  Seriously - if I am looking for the word "Bold" then I want to find that word.  If someone had spelled it "Blod" then search would fail and life can become quite difficult if I need to change the Bold font behavior everywhere it is used.  Fortunately, this doesn't happen very often, but when I see it, I generally try to make a code change to spell the word correctly. 

Questions, comments, concerns and criticisms always welcome,

John

Snow days mean working from home

While I am a big fan of snow days in general, this week in Seattle has been tough.  It snowed surprisingly hard for a while and I was unable to make it to our offices on Monday.

While this is not a terrible situation, it meant I had to work from home for the day.  I'm not personally a big fan of working from home.  There are several reasons for this and the biggest is probably that "home is where I go when I am done working."  Mentally, it is tough for me to stay focused when I am home.

Another reason is the limited hardware I have at home, specifically multiple monitors.  I'm lucky enough to have 2 monitors at my desk (three if you count my laptop) at work.  That makes debugging and testing in general much easier - run Tableau on one monitor, debug on the other.  I've written a few articles about this in the past and  I do not have this at home.  Typing on one monitor is simply frustrating for the work I do.

I also miss the interaction with my team.  Sometimes I just need a simple question answered which is pretty fast if folks are around me.  At home, I have to rely on instant messaging, email or whatever and the delay can leave me blocked for a while.

Finally, my home network is not as fast as our work building.  Frustrating.

The task I CAN do at home is paperwork.  Updating documentation, reading designs, giving feedback, etc… are the types of work I can complete at home and not feel distracted.  As luck would have it, I had about a day's worth of reading and online training to complete while snowed in, so the day went pretty well.

Now, back to the office and (real) work!

Questions, comments, concerns and criticisms always welcome,

John