Tuesday, October 3, 2017

I so badly want to rewrite this little bit of test code, but won't

I saw something similar to this in a test script:

#fdef Capybara:
#include "A.h"
#include "B.h"
#include "B.h"

Fair enough.  I can imagine that this was NOT the way this conde snippet was checked in - it probably changed over time to what it is now.  I haven't yet dug into the history of it.

That seems a bit inefficient to me and I would prefer to change it to:

#fdef Capybara:
#include "A.h"
#include "B.h"

Fewer lines and should perform the exact same includes. 

But I won't make this change and here is why:
  1. It may break.  The odds are small, but why add risk where the system is currently working?
  2. It's a small benefit overall.  Maybe 1/1000 of a second faster build times.
  3. It takes some amount of time to make the change, build, test it, get a code review, check it in, etc…  I can't see any time savings for this change in the long run.
  4. A better fix than this one change would be a tool looking for this pattern in ALL our files.  Then use the tool to make the change everywhere, and make the tool part of the regular code checks we perform constantly.

But considering #2 overall, even a tool would not pay for itself.  So I am leaving this as is for now and moving on to my next task.

(But if I have the fortune of needing to edit that file, I will be sorely tempted to make this fix at the same time :) )

Questions, comments, concerns and criticisms always welcome,

Monday, September 25, 2017

Tableau Conference is 2 weeks away and I am getting ready

I got my schedule set for TC which is now just around the corner.  I will be working as a Schedule Scout, helping folks that attend get their schedules created.  Seems like a great way to get a conversation started face to face with our customers.

For TC last year, I had the same goal of talking directly with customers.  I looked around at all the jobs we can do - at TC, ALL the jobs are performed by Tableau employees - and figured that working at the logo store would be ideal.  My thought was that I would meet a large number of customers, and I did!  The only downside was that the store was very busy and I did not have much time to interact with everyone.

This year it looks like I will get a chance to work 1:1 with people and I am looking forward to it.  I hope to meet you in Vegas!

Questions, comments, concerns and criticisms always welcome,

Tuesday, September 19, 2017

Working with code coverage this week

I've been working on code coverage a bit this week.  Our team uses Bullseye for gathering information and while it has its good and bad points, overall it is fairly easy to use manually. 

More specifically, I have been trying to identify files that have no automated coverage at all.  This would mean that this file could, in theory, not even exist, and we would not know.  The reality is that Tableau would not be able to be built, but not having any automated coverage is a poor state to be in.

And this is where I hit my first snag.  We have several different types of automation we run each day.  Unit tests is an obvious starting point, and there are also end to end (integration) tests.  Code coverage numbers for those are easy enough to gather and to merge together.

We also run other types of tests like security tests and performance tests.  Getting numbers from something like a performance test is tricky.  Since we are trying to measure accurate performance, we don't want to also slow down the system by trying to monitor which lines of code are being hit or missed.  On the other hand, the code being hit should be the exact same code the other tests already cover - in other words, we should not have special code that only runs when we try to measure performance.  It's hard to validate that assumption when we specifically don't want to measure code coverage for half of the equation.

In any event, we do have a few files with low coverage, and we are working to ensure that code has adequate automated tests on it moving forward.  More on this - what adequate means in this context - coming up.

Questions, comments, concerns and criticisms always welcome,

Friday, September 8, 2017

How I learned Tableau

Way back when I came to Tableau, I needed to ramp up on how Tableau works.  While I like to think I understand much of the math behind the scenes, I still needed to figure out the UI, connecting to data sources and mapping and functionality like that which Tableau provides.

One of my buddies from way back was talking with me earlier this week and had the same dilemma I faced: how to learn Tableau relatively quickly.

When I started, I bought the Offical Tableau 9 book by George Peck.  Great book - it starts with the basics and builds from there.  It's about 2 years out of data at this point (there is a 10.0 book available now), but I still use it from time to time to refresh my memory.

But books only go so far, and I really learn best with hands on work.  I found a "20 days to learn Tableau" chart that I also used.  It really resonated with me - it had videos to watch, whitepapers to read (I actually found a typo in one of the papers, reported it to the author here at Tableau, and it got fixed) and activities to complete.  I recommended it to my friend and I hope he gets as much out of it as I have.

Questions, comments, concerns and criticisms always welcome,

Tuesday, August 29, 2017

Stochastic Processes

I'm a big believer in online classes to brush up old skills or develop new ones.  I've taken several over the past few years and while there are some classes that don't live up to the expectations, I found one that has been a pretty fun course so far.

It's called Stochastic Processes: Data Analysis and Computer Simulation from Kyoto University in Japan.  Here's a link to the class on Edx.  It is self paced and wraps up Aug 2, 2018.  It is divided into 6 weeks of classes and each week is expected to take 2-3 hours per week to complete.

I have spent MUCH more than that simply wiping the rust off of my physics classes from college.  Don't get me wrong - I love the experience of going back to Albert Einstein's PhD thesis on Brownian Motion to help with that chapter.  I understood just enough of his paper to make the simulation more understandable, and having an excuse to read anything by Einstein is just icing on the cake.

And there has been a lot of that.  I had to keep looking up mathematical concepts I haven't used in a long time (Dirac Delta equation, for instance).  Again, this was worthwhile.

If you get a chance and know Python and meet the other requirements, this may be an interesting class to take.  Plus, to audit the class is free, and you can't beat that price!

Comments, questions, concerns and criticisms always welcome,

Tuesday, August 15, 2017

I'm waiting for this book about using Tableau with Matlab

Last week I wrote a bit about the Matlab support with Tableau.  Our team also owns R support (it is all built on a REST API) and many people have been using R for years with Tableau.  Talks about R integration are a very popular topic at Tableau Conference each year as well, so there has been a tremendous amount of interest in this area.

So much interest, in fact, that Jen Stirrup has written a new book that is due out pretty soon, Advanced Analytics with R and Tableau. It will be available in paperback and ebook formats and is due out on September 6.  That is less than a month away as I write this and I am looking forward to getting my copy.

Good luck, Jen.  I hope you sell many copies of this book!

Questions, comments, concerns and criticisms always welcome,


Monday, August 7, 2017

Matlab and Tableau!

Kudos to the folks at Mathworks for their efforts to bring Matlab into the Tableau world!  Details about this are here.  Nice job, gang!

As for testing, this is one of my team's areas.  We also own R and Python integration, so we had test plans for this area well established.  Mathworks was so good at their implementation that there was frankly not much for us to do - a couple of string change requests and that was really about it.  We added some automated tests to validate the behavior is correct - to tell us if we change something that would break using Matlab server - and have that up and running now.  The side benefit to the automation is that we have no manual testing left from this effort.  This means that we are not slowed down at all in the long term even though we have added new functionality.  From a test point of view, this is the ideal case.

We never want to build up manual test cases over time.  That growth, if there is any, will always eventually add up to more time than the test team has to complete the tasking.  Obviously, this doesn't work in the long term so we have made a concerted effort to hit 100% of our test cases being automated.

So, yay us!

And thanks again to Mathworks. FWIW, I truly like Matlab.  It is every easy to look at some mathematical equation and simply type it into Matlab - it almost always works the very time I try it. 

Questions, comments, concerns and criticisms always welcome,