I’ve always had a love of tactile keyboards. For the past six or seven years I have loved using a WASD Code 87-key keyboard with Cherry MX Brown switches. Despite also having an example of the same keyboard with Cherry Clear switches, I clearly prefer the lighter spring weight of the Cherry Browns. This was enough for me, until two years ago when I was able to order an aluminum outer case for the same keyboard. I replaced the ABS plastic case with the much-heavier aluminum, and immediately preferred the added heft. Even though my beloved Model M keyboards were made of plastic, I always preferred their heft. They don’t move around on the desk, and they just feel solid.
Building and customizing keyboards has become quite a popular hobby in the past few years, and it seemed to me to be mostly focusing on unique key caps and lighting. This didn’t appeal to me, because half of my love of the Code is, while their keys are backlit, it is an extremely clean, utilitarian design.
Enter hot-swappable (no soldering required) switches. With the right keyboard, I can now tinker with how the switches themselves feel and sound, without the trouble of soldering.
This will be fun.
A good official tutorial exists
As prep for a learning presentation at work on the topic of KQL, I set out to turn a quick set of “primer” notes into a more thought-out blog post, and then hopefully a better presentation. Turns out, I quickly found a far better introduction to the language. This docs.microsoft.com tutorial is wonderful; it is simple and straightforward, and I used it for my talk.
Learn how to dig
So, rather than specifically a technical introduction, what is it that I am trying to share about KQL? Kusto is such an amazingly performant system, that using it can actually be fun.
What I want to convey in 15 minutes or less is how to discover what data you have, and how to conveniently dig. I have met a lot of engineers whose systems publish to a KQL system. They’ve had access to the data for years, and don’t know how to discover what’s there.
The noise of that sea of poorly conceived and messy telemetry can be intimidating. Don’t let it be.
So, my old KQL primer has become the following “things to learn”. When I share these, I always hope it sparks a little curiosity. That’s all.
Learn the following concepts, as quickly as possible.
Browse tables, looking at a few random records.
Perhaps union all your tables together:
union traces, exceptions, ... |
Filter on timestamps. Most KQL UIs will allow you to paste the text of a timestamp and it will wrap it in a
| where timestamp > ago(1d)
| where timestamp > [PASTE TIME] and timestamp < [PASTE TIME]```
| where timestamp between (datetime(2022-01-12 19:54:00) .. datetime(2022-01-12 20:10:54)))
Search for strings. Get hooked on Kusto’s amazing indexing.
// no substring matches
| where * has "caro"
// includes substring matches
| where * contains "caro"
Create your own columns, on the fly. Compute new values, or pull data from a column with a complex data object out to its own column.
| extend Duration = EndTime - StartTime
| where Id == "/US/North Carolina"
| extend ConfirmedValue = Confirmed.Value,
ActiveValue = Active.Value,
DeathsValue = Deaths.Value,
RecoveredValue = Recovered.Value
Remove columns you don’t need.
| project Id, ReportDate, ConfirmedValue, ActiveValue, DeathsValue, RecoveredValue
Group results and run functions over the set:
| where Id == "/US/North Carolina"
| extend ConfirmedValue = Confirmed.Value, ActiveValue = toint(Active.Value),
DeathsValue = Deaths.Value, RecoveredValue = Recovered.Value
| project Id, ReportDate, ConfirmedValue, ActiveValue,
| summarize count(), toint(avg(ActiveValue)) by bin(ReportDate, 31d)
Note, I’m assuming most queries will be using the sample data from the tutorial listed above, but my one criticism of the data from that tutorial is that it is not typical system telemetry. I’ll give examples for the following when I find a good sample dataset to use.
Get values out of JSON columns.
Join against other records.
So, with some free holiday hours, I’ve found playing with Jekyll to be more fun than expected. I guess I shouldn’t be surprised.
I wanted to do one of two things: Either start competely from scratch with a bare-bones GitHub Pages blog repo, or fork from Barry Clark’s jekyll-now repo. I tried both.
With the bare-bones repo, with no prior knowledge of Jekyll at all, it was very straightforward how to get a page to be served, but not how to create a blog of many files, all in a time series.
While the forked repo strategy was extremely simple to get started, I did not find it to be tinker-friendly without any knowledge of Jekyll. I can’t keep away from tinkering at least a little bit with a theme.
Eventually, it became apparent to me I should just learn what Jekyll is doing, and it turns out there is a wonderful Step by Step tutorial on the Jekyll site. There are ten steps, but they are pretty simple, and they each explain the logic of the components of Jekyll. I followed the tutorial on Windows, and pretty much ended up with a complete (albeit unstyled) site, running locally. Grab some existing CSS from a few blogs, and a tiny bit of tinkering later I have something a little closer to what I want.
In spare moments I’ve been looking for a quick blogging solution, and now I have one.
GitHub Pages is a wonderful free resource for all users of GitHub, both free and paid. Plus, it’s extremely easy to get started with it. You can start from scratch, or fork a repo to get a headstart.
- Get a GitHub account, if you don’t already have one.
- Fork Barry Clark’s jekyll-now repo.
- Rename your fork’s repository to
What you end up with is a static site. This basically means there is no database needed to run things. GitHub provides Jekyll (the code that generates the static pages) as a service. All of my content are Markdown text files, which are versioned with Git.
If you are interested in the same, please check out Barry Clark’s extremely helpful repo and explanations:
- Private repo: I don’t believe you can take a forked repo private, so may do a tiny amount of work to make this blog’s repo private. (Note, I believe GitHub Pages is only supported in private repos wih paid GitHub accounts.) I may prefer the repo to remain public.
- Style: I’d like to style things a little. I’ve already added an excerpt separator to the site’s
_config.yml, but I haven’t bothered to look at themes.
- Custom domain: I am using a custom domain for this site. Getting this to work was mostly simple, but I had more hiccups than I expected.
- Run Jekyll locally: I need to run the site locally.
- Drafts: I need a drafts strategy, which is probably this.