The above code connects to Cosmos DB and retrieves the details for the base airfield that was specified, it then calculates the range of the aircraft in meters by multiplying the endurance (in hours) by the true airspeed in knots (nautical miles per hour) and then multiplying that my 1852 (number of meters in a nautical mile). A Linq query is then run against Cosmos DB using the built-in spatial functions to find airfields within the specified distance. The result is then converted into a JSON array that can be understood by the Google Maps API that is being used on the client side.
The client side uses the Google Maps API to plot the airfields on a map, giving us a view like the one below when given a base airfield of Blackbushe (EGLK), a true airspeed of 100kts and an endurance of 4.5 hours
Click through for .NET code to load and analyze the data.
Notice that we create a graph per continent by setting
facets = ~continent. The tilde there is important—it’s a one-sided formula. You could also write
c("continent")if that’s clearer to you.
I also set the number of columns, guaranteeing that we see no more than 3 columns of grids. I could alternatively set
nrow, which would guarantee we see no more than a certain number of rows.
There are a couple other interesting features in facet_wrap. First, we can set
scales = "free"if we want to draw each grid as if the others did not exist. By default, we use a scale of “fixed” to ensure that everything plots on the same scale. I prefer that for this exercise because it lets us more easily see those continental clusters.
Facets let you compare multiple graphs quickly. They’re great for fast comparison, but as I show in the post, you can distort the way the data looks by lining it up horizontally or vertically.
Okay, fine, who’s this really for?
Anyone, I suppose, but in reality? If you’re stuck on a remote system that only allows terminal logins, this is a super handy tool to use. If you’re used to text-based editors, like Emacs, Nano, or even vi or vim, you’ll feel right at home in here. You can type in commands and then run queries. There’s even multi-line support for more complex stuff. There’s another side to this too: if you’re the kind of DBA that gets really mad if someone installs management studio on a server, then this might be a solution: it’s got a very small installation footprint, and you don’t get a full UI experience so unless you know all the big T-SQL commands for heavy administration (like for, say, dealing with an availability group or adding permissions, or taking or restoring backups), you won’t get much use out of it. But in a pinch, on a server, in a crisis where you can’t tell if SQL is up and serving queries? It just might work out well for you.
Read the whole thing for an enlightening Q&A session, although the question-asker is kind of a jerk to the answerer.
There is a mechanism by which we can significantly influence memory latency in a multi-processor (socket) server system, that being memory locality. But few applications actually make use of the NUMA APIs in this regard. Some hypervisors like VMware allow VMs to be created with cores and memory from the same node. What may not be appreciated, however, is that even local node memory on a multi-processor system has significantly higher latency than memory access on a (physical) single-socket system.
That the single processor system has low memory latency was interesting but non-actionable bit of knowledge, until recently. The widespread practice in IT world was to have the 2-way system as the baseline standard. Single socket systems were relegated to small business and turnkey solutions. From long ago to a few years ago, there was a valid basis for this, though the reasons changed over the years. When multi-core processors began to appear, the 2-way became much more powerful than necessary for many secondary applications. But this was also the time virtualization became popular, which gave new reason to continue the 2-way as baseline practice.
Joe points out that for a highly-used transactional system, the lower memory latency might make a single-socket server perform better than a multi-socket server.
Even worse, Power BI is rapidly being iterated on. This is great for users, but a challenge for people trying to keep up with the technology. One year ago the following deployment options modes didn’t exist.
- Sharing individual reports (Jan 2018)
- “Apps” (May 2017)
- SharePoint Embedding (Feb 2017)
- Power BI Premium (May 2017)
- Power BI Report Server (June 2017)
- Power BI Embedded V2 (May 2017)
It can be a real challenge to keep up. I think that a lot of the dust has settled when it comes to deployment options. I don’t see them adding a lot of new methods. But I expect there to be many small tweaks as time goes on. In fact I had to make two changes to my slides this morning because they announced changes yesterday!
In contrast, I expect another six to be added to this list in the coming three months. Because it’s Power BI and the only rule behind Power BI is that there must be more.
Nearly two year ago, I first published my Shortcuts cheat sheet. Since then, thousands of people have downloaded it. I’ll be the first to admit that I didn’t expect it to be as much of a hit as it has been. When I give my one-hour talk in person, I bring card stock handouts of my cheat sheets, too. I also ask people for their favorite shortcuts, and I’ve learned some great new hidden gems.
I’ve been working on some updates, and the updated version is ready to go. I’ve added a bunch more shortcuts, and even added shortcuts for SQL Operations Studio. It’s two pages now, for double the fun!
That’s great stuff. Learning these keyboard shortcuts will provide a nice marginal benefit to your productivity.