A couple of useful little OS X bits that I learned while doing this; Fn+Left-Arrow and Fn+Right-Arrow are Home and End (of line) shortcuts when using the default keyboard. Very useful when using vim in iTerm2, where Cmd+[LR]-Arrow change tabs. Also was pointed to this which prompted me to map Caps Lock to Escape (also useful in vim) #

I think I need to look into a terraform vim plugin. #

Trying to get a CKEditor Markdown plugin working in Manuscript. Using this one which looks pretty good in the demo. I can reload the event editor’s CKEditor but can’t get the plugin to load via

var ed = CKEDITOR.instances.sEvent.config
CKEDITOR.instances.sEvent.destroy()
CKEDITOR.plugins.addExternal('markdown', 'https://rawgit.com/hectorguo/CKEditor-Markdown-Plugin/master/markdown/plugin.js')
ed.extraPlugins = "FBContextMenu,FBLink,FBFormSubmit,FBSnippets,FBInsertImage,FBCodeSnippets,markdown"
CKEDITOR.replace('sEvent', ed)

I can destroy and reload the Manuscript default CKEditor plugin to reload with that code, but the Markdown plugin isn’t available. Also tried CKEDITOR.plugins.add('markdown', 'https://rawgit.com/hectorguo/CKEditor-Markdown-Plugin/master/markdown/plugin.js') instead of addExternal() although I think the external version is the right API to use. #

I’m referencing this Stack Overflow question and answers and also pieces of this article. #

Azure SQL Managed Instances seem like an interesting alternative to Azure SQL Database. Lift-and-shift model with “local” control at the instance (instead of database) level. #

With respect to tuning, the DTU calculator tool looks useful. Also, wtf is parameter sniffing? Additionally, Jes talked about things at the logical SQL server level with respect to Azure SQL Database. I’d like to understand more abou tthat concept. #

Analysis Services session was probably good for analysis services developers; not that useful for me personally. #

Learned about WPS’s remote work push, which seems to have come a long way in just a few years. They’ve been moving to remote first for about 2 years and have a ton of their current workforce working remotely. #

1. While the config trigger is being handled in terraform with a VM Extension, it still relies on a Bash script running in the context of the VM being created to set itself up.
2. The config that’s executed by the VM Extension only approximates dynamic configuration by looping over some passed-in variables. Better than nothing, though.

Hopefully Consul will be able to address the service discovery concern, since right now the ES zen discovery addressing is dynamically hard-coded. It’s possible there’s a way to handle that “internally”, but so far I haven’t been able to find a way to access scaleset instance information during the startup process, and so am needing to gather that information in Bash when the VM starts up. #

TIL about Bash’s greedy variable parsing courtesy of krallja; this means that in the context of a Bash substitution varible like $host$prefix0000$counter, $prefix0000 is parsed as a whole variable instead of as a variable followed by a string. On the other hand in $host$prefix-0000$counter, $prefix is a variable since “-“ isn’t valid in a variable name. You can also resolve this like $host${prefix}0000$counter. #

So I switched, at least temporarily, back to the vm extension, but get the same result when running the script with sudo sh test.sh. Removing the sh from the extension’s commandToExecute causes an error:

azurerm_virtual_machine_scale_set.es_ss: Long running operation terminated with status 'Failed': Code="VMExtensionProvisioningError" Message="VM has reported a failure when processing extension 'test'. Error message: \"Enable failed: failed to execute command: command terminated with exit status=1\n[stdout]\n\n[stderr]\nsudo: es-shell-test.sh: command not found\n\"."

In the end I needed to go with bash without the sudo; the templating is a bash feature, and I suspect the commandToExecutew runs as root. #

Of course all of this is till running into startup problems, maybe at least partly to do with not correctly handling (or not properly ignoring) failure modes? And the challenge of running it @reboot is that if it fails the system, doesn’t boot. I’m not 100% sure why this is; most of what I’m doing in there shouldn’t be relevant to system startup (aside from whether or not Elasticesearch can start, which is a separate issue and shouldn’t mean that the OS boot would fail). #

Deallocating a scaleset instance seems to take a much longer time than I would have expected, as well, and oddly, for some script failures a deallocation and start cycle seems to fix the issue. #

I’ve been looking at using an alert filter in Azure connected to a webhook to publish notifications (perhaps to Slack). Might be useful not only for knowing when a long-running operation is finished but also for tracking other events. Interestingly enough the Administrative event fiolter also published activity from the Azure CLI (and presumably from Azure-PowerShell). It’ll be interesting to see if it also catches terraform activity. #

I’m also dithering about how to store more extensive info like dotstuff that’s stored in folders. Much of that probably belongs in submodules somehow as well. Also planning on decking out my vim a little more as previously noted, so that will have to come into it. I was planning on using vim-plug for that but I’ll need to make sureit supported installing from submodules if I’m going to go that route (as it seems to do). #

On the Elasticsearch scaleset front, since multicast isn’t an option I’ll have to do the cluster config some other way. It seems like using Azure Virtual Machine Custom Script Extensions (in terraform prompted by this quickstart) might be the route to go; that seems like it might be a useful replacement for the remote-exec work I was doing in the individual vm set up. #

TIL that GitHub gist raw urls change when a gist is revised. This makes sense from a git point of view (as I suspect that the gist is just a small git repo on the back end) but I’m not sure whether that seems reasonable from the front end. #

Another interesting TIL, it seems like when using terraform to apply a scaleset that relies on a virtual machine extension using a remote file (I’m currently testing with a gist), if there’s an error in the remote file, reapplying after fixing the problem in the remote file doesn’t seem to be sufficient. I’ve had to terraform destroy followed by a fresh terraform apply to get it to piuck up the changes. ~Not quite sure why yet.~ Apparently changes to the scaleset definition (including the fileUri for a vm extension script) don’t dirty the scaleset, so it doesn’t get picked up by the state refresh. Not sure exactly why this happens, but…. #

Today’s big discovery on the Elasticsearch in Azure front is that Azure virtual networks don’t support multicast, so ES discovery has to be unicast. that’s … unfortunate. #

Digging around online for ideas about how to organize them I quickly stumbled across the dotfile GitHub page, and specifically the tutorials section, and am reading through those. Lots to go through there, but so far Anish’s process looks pretty sensible, and DotBot in particular looks useful. #

• Zp Bappi
• minddust
• Long Qian

Of these right now the minddust approach seems the most straightforward and aside from having to generate the category and tag files manually seems pretty simple. To bbe fair both of the other models require some file creation, and that should be easily automated, bperhaps even hooking into the jekyll build process. #

This week I worked on a couple of internal Glitch projects (well, internal to Fog Creek but externally visible) to enhance our recruiting process. I won’t link to them here but anyone who applies for one of our open positions will see them. In any case I ran into a couple of slightly interesting bits that I want to capture, mostly having to do with “new” Javascript hotness since I last regularly used JS (in, um, 2012 maybe?).

• Template literals rawk.
• The FormData object is super nice for quickly capturing an entire form’s fields for POSTing to an endpoint for processing. Saves a lot of boilerplate.
  • If you’re using JQuery’s .ajax() function or the like, you must remember to set contentType and processData to false or things won’t work properly.
• When using the Google APIs (specifically the Sheets API, in this case), particularly when leveraging the Node.js client, using JWT Service Tokens is the best route forward. This took me entirely too long to figure out. It also took me a while to figure out that the service account created needed to be granted access explicitly. #