A concise blog.

My latest project is a web application that tells you the asset allocation ofyour investment portfolio .   Happily, I just finished getting my Exam 70-761: Querying Data with Transact-SQL certification, so I thought that I’ll use a SQL database for the project.   One of the cooler features that I learned about while studying for my exam is a feature called temporal tables .   Temporal tables allow you to see what the data used to look like. It's a feature that is baked in to SQL Server 2016 and has been ANSI standard since 2011.  I thought that they would be really useful feature to show how the asset allocation changed over time.   Want to see what your portfolio looked like at the end of 2012?   Great Scott!! With temporal tables, you can!! Unfortunately, they aren’t standard in PostgreSQL.  PostgreSQL is my DB engine of economic necessity, and it doesn't support temporal tables out of the box (there are extensions that you can use to make it happen, but my

I’m always working to improve my code.    One of the ways that I do this is that I frequently work on Code Wars practice problems.   I was working on a   prime number generator   for a practice problem (if   you’re interested, the code is here: https://github.com/tmurphree/node-utilities/blob/master/primeNumberGenerator.js)   and I wondered, “Should I use a set or an array?” I solved the problem with both a set and an array, and I ran some tests* to see   how long the function took to run and how long the   searches on the results took.    The results were interesting: Operation Average time (ms) Array generation 18.2412 Set generation 44.3016 Array seek 0.021 Set seek 0.0099 The set took about 2.4x the time to generate as the array, but it is searchable in about 1/2 the time.  So the answer to the question  “Should I use a set or an array?” boils down to another question: "