This post is intended to be a reference for myself and others I am trying to help get the most value out of Talon Voice (with community config) and Cursorless. I will try to cover things that other places do not mention or emphasize.
For instance, my experience is that the semiofficial community documentation does not properly emphasize that adding stuff to additional_words.csv and words_to_replace.csv in the "settings" folder is extremely useful and one of the first customizations you should do. There are nice commands like "customize additional words" and "customize words to replace" to launch a text editor on those files (currently does not work on Windows 11). It is also my experience that they do not even mention that you should change the gitignore file to source control all of the settings/*.csv files except for system_paths.csv. I wish I had known these things earlier, so I'm mentioning here to help others and also to record them for myself.
This post is intended for people who are computer savvy and I will probably not go into depth about git stuff unless it is specifically requested.
This will be a continual work in progress and a testament that I should have made this post over a decade ago.
Dedicated fast-forward merge post of mine.
Reminders: the “index” is what holds staged changes. Useful site for undoing/recovering stuff: https://dangitgit.com .
This post and a lot advice and help for git on the internet assumes the command line. That is because the git command line is same for everyone and easy to give precise instructions. But really you should try to do as much as possible inside a nice git gui, possibly your IDE or SourceTree. A nice git gui makes it easy to go from "I want to ..." to "I did it" by exploring menus and possibly right clicking items instead of looking up weird commands and syntax that you will soon forget. A nice git gui also makes it much easier to see and understand your current repo state and its history.
Fast-forward merges have properties that are tightly tied together (basically they are equivalent)...
A note on terminology. I have looked for the most official term for merges that are not fast-forward merges; these are the classical merges that create a merge commit. The closest I have found is "true merge" as a git-merge reference section header. Some people use the term "3-way merge" for all merges that create a merge commit, but 3-way merges are an algorithm for producing merge output where you also look at the most recent common ancestor of the two things you are merging, thus the name having "3" in it. True merges do not have to use the 3-way merge algorithm (see merge strategies). Thus, I will be using "true merge" or "non-fast-forward merge" to refer to merges that create a merge commit.
The 2021 edition of "Warhammer 40,000: Kill Team" (KT21 for short) is a skirmish-sized wargame played with miniatures and dice. In KT21, it's a bit complicated to calculate average/expected damage for a shooting attack. Also, it's a bit surprising that improving the accuracy of a weapon by some proportional amount increases the expected damage by an even higher proportion. This post explores the quirks and nonlinearities of expected damage from shooting attacks.
Perhaps the most important thing to realize: number of attack dice, ballistic skill, and save characteristic all nonlinearly impact average damage (even if we ignore crit stuff). Attacking stuff super-linearly affects damage (increasing returns). Save characteristic sub-linearly affects damage (decreasing returns). Damage is hard to reason about.
For instance, doubling the number of attack dice will more than double the post-save damage. How much the post-save damage increases depends on everything else (BS, SV, special rules, auto-successes from cover, etc).
Update: I made my own KT21 Calculator.
A lot of this post is applicable to games with any number of players, but there is special attention paid to two-player games with strangers. A lot of this post is applicable to any board, but we will also analyze particular boards in order to come up with general things to keep in mind when analyzing any board.
This post is a work in progress. I made a video of a lot of these concepts, and some sample games: game1, game2, game3. I made a deterministic Kill Doctor Lucky game where you can play and see what the AI thinks is a good move (sorry, it's command line).I'm making this demo repo and writeup because it was surprisingly and frustratingly difficult to get Xamarin.UITest tests for Android to run on a Microsoft-hosted agent in an Azure DevOps pipeline. NO App Center. NO self-hosted agents. I just wanted to do everything in Azure DevOps.
So, this demo shows how to accomplish that, and some other common goals for an Azure Devops continuous integration pipeline for the Android portion of a Xamarin app...
versionCode and versionName.This demo is not about getting started on unit testing or UI testing; the demo is about getting these things to work in an Azure DevOps pipeline.
You can see a successful run, a successful job overview, published artifacts, and unit+UI test results (also alernate view for unit test run and UI test run).
This repo is available as a visualstudio.com repo and a github repo. As of 2020-Dec-24, Azure DevOps offers a free tier with 30 build hours per month and 2 GiB of artifact storage. The free tier was more than enough for all the pipeline needs of this demo.
This writeup is available as a github readme, visualstudio.com readme, and blog post. The repo readmes will be kept up to date, but the blog post may not receive many updates after 2020-12-24. Readme section links are oriented for GitHub.
The password generator settings you use should depend on how you're going to use the password. Passphrases are great for passwords you need to remember, but maybe not for your work password that you manually type >20 times a day. My recommendations depend on the "password use case":
This blog post is focused on:
The cracking costs tables are towards the bottom, feel free to check those out first if you want to see results, not methodology and commentary.
When someone creates a password, sometimes they are concerned about how resistant the password is to being guessed by an attacker. For instance, a one-letter password for your bank account is probably unacceptably weak and a computer-generated 40-letter password is probably more than acceptably strong. These two example passwords are so extreme in weakness/strength, that we can make these judgments intuitively, but we will have to be more careful and systematic if we want to determine what sorts of passwords are acceptably strong and not excessively painful to type.
This blog post will focus on password strength in the context of offline
attacks, which is where an attacker has hacked some service, obtained hashes of passwords, and can very quickly check password guesses on their own machines. Offline attacks are a worst-case scenario for password strength, and it makes sense to have the worst-case decide what we consider acceptable password strength.
There are a few ways to think about how strong a password is: guesses-to-crack (GTC, basically entropy), time-to-crack (TTC), and money-to-crack (MTC). "Crack" simply means "correctly guess". Each way builds on the previous way. Discussions of password strength usually focus on GTC and TTC, and only rarely go into MTC. I think that MTC is far superior to TTC for most discussions about passwords, and I propose my own way of calculating MTC and plug in numbers for hardware available in 2020-Nov.
Interestingly, there's only a 15x-38x difference in costs between realistic upper bounds (AWS cloud computing) and unrealistic lower bounds (arbitrary number of GPUs with no overhead).
The Pareto Principle ("80/20 rule") is the observation "for many outcomes roughly 80% of consequences come from 20% of the causes", such as 20% of Italian landowners own 80% of Italian land, and has been extended to things like 20% of development time/effort can be use to write 80% of desired software functionality. This can be written as a {0.2, 0.8} scenario.
Sometimes the principle can be applied recursively at multiple scales. Perhaps 20% of 20% of landowners (4%) own 80% of 80% of land (64%). In other words: {0.2, 0.8} at all scales implies {0.04, 0.64}. Perhaps for some matters (land ownership, wealth), things can be that skewed at many scales. For stuff like time to develop software functionality, I suspect the Pareto Principle can only be applied at a few carefully chosen scales.
Let's look at the following table to appreciate how recursive application yields some extreme scenarios.
We see the famous {0.2, 0.8}, but we also see {0.007, 0.5} which would imply that you can get 50% of desired software functionality with less than 1% of the effort required to get 100% functionality. There's even more extreme results like {0.001, 0.4}; one-thousandth the effort to get 40% of the benefit. Putting these two scenarios together: you work some amount (0.001) to get to 40% functionality and you have to work an additional six times that amount to get to 50% functionality...and then you have to work and additional 9,000 times that amount to get to 100% functionality.
My thesis is that the Pareto Principle leads to proportions that are surprisingly extreme, and thus we should be very hesitant to apply the principle beyond a single well-chosen scale. There might be lots of naturally-sized tasks where ~20% of the effort gets you ~80% of the benefit, like how carefully you hang a curtain and how good it looks. But I doubt that {0.2, 0.8} and {0.007, 0.5} both apply to hanging a curtain.
Another question that arises is that if you can get 80% of desired software functionality with 20% of the effort required to get 100% functionality, do we really believe that multiplying the amount of desired software functionality by 1.25 multiplies the required effort by 5 (coming from 1/0.8 and 1/0.2)? Or imagine someone bloating the desired software functionality to 1.25x so that the actually desired 1x software functionality will supposedly only require 20% of the time of their original 2x-functionality schedule. I think these scenarios illustrate that the Pareto Principle is very unlikely to be applicable when you are considering different amounts of output to ask for. Usually when you ask for more output, those outputs will contain easy parts and hard parts. The only way for the Pareto Principle to hold as you increase desired functionality is whether you are always adding the easiest parts of the easiest features; but humans never do that; humans ask to add complete-enough-to-be-useful features, not the easiest 20% of a feature.
 |
| Visual metaphor for DCA's inconsistency |
Dollar cost averaging (DCA) is a strategy deliberately delaying investing money. I will argue that DCA is an ill-founded and logically inconsistent way to manage risk. The superior way to manage risk is a well-chosen asset allocation.
I'm going to take some time to define my terms, because people use the term DCA in different ways. I'm not arguing against all of the different flavors of DCA, just a particular flavor.
I'll point to some existing great work on how DCA has been disappointing historically, but the heart of the post is explaining on a conceptual basis why DCA is disappointing and not a coherent approach to investing. Proper asset allocation is the superior and coherent way to manage risk.
It also used to be that to take over an Amazon account, you only had to know was a person's name and their shipping address, and to make three calls to customer service. You could use the name and address to find out the registered email address, then use those three things to add a phony credit card number, then use those four things to change the associated email and then trigger a password reset using the new email address..At 4:33 p.m., according to Apple’s tech support records, someone called AppleCare claiming to be me. Apple says the caller reported that he couldn't get into his Me.com e-mail – which, of course was my Me.com e-mail.In response, Apple issued a temporary password. It did this despite the caller’s inability to answer security questions I had set up. And it did this after the hacker supplied only two pieces of information that anyone with an internet connection and a phone can discover....It turns out, a billing address and the last four digits of a credit card number are the only two pieces of information anyone needs to get into your iCloud account.
 |
| Vanilla: exotic spice but default flavor. |
I want to help answer the question, "How, exactly, do I buy an ETF? What buttons do I click? What options do I choose? What numbers do I enter, especially for things like quantity and limit price?". There seems to be lots of written material about how to choose an ETF and the different types of buy orders, but very little written material that tries to answer the questions in quotes above. The best I can find is stuff like the "ETF Best Trading Practices" section of this pdf from Vanguard, which still leaves things at the abstract level of "use a limit order that is likely to be executed instantly".
This post will go, click-by-click, through the process of transferring money into a Fidelity account and submitting a buy order for an ETF. Hopefully, this click-by-click will help make people's first time easier and less scary (especially due to clear statements of which clicks have real-world consequences). Also, this post will give the exact logic/calculations I use for coming up with the quantities and limit prices for my buy limit orders. The logic/calculations for quantity and limit price are applicable at all brokerages, not just Fidelity.
If you are wondering what ETF to buy, see this long post or this short post.
2022-Jan update: Fidelity now has a quantity calculator, which helps with a lot of the calculations mentioned below. Also, Fidelity now lets you buy fractional amounts of ETFs where you specify how many dollars you want to spend. The "Explanation Of How We Calculate Desired Quantity And Limit Price" could use some updating..
 | |
| Hubert Featherbottom |
