If you have 2FA set up for many accounts like I do, it gets to be a pain scrolling through that list to find the one you want. Categories to the rescue! From the settings menu go to manage categories, from there you can create new categories and put authenticators in them. Categories in Authenticator Plus work more like tags than folders, you can put one authenticator in as many categories as you want. Sorry readers, that was a lie. The interface is kind of confusing, so I thought categories worked like tags, but they are actually folders. Either way they’re still really useful. Once you have your categories set up, you can switch between them from the hamburger menu. The categories list is at the top where it’s easy to find.
Now that I have my authenticators sorted into work and personal categories, it’s so much easier to find the one I want.
Many years ago when I was in college, a friend taught me something that’s been really useful for my whole career. That lesson was to let the computer do it for you. Unless there’s a compelling reason to do things the hard way, just let the computer make things easier for you.
Learning lisp? Get a plugin for your text editor or a simple IDE like Dr Racket that matches your parens for you.
Working with fixed width files? Get Record Editor, it’ll save you so much time!
If you have to do something tedious and fiddly, get the computer to help you. That’s what it’s good at. There is a tool out there that will make your life easier, you just have to go and look for it. The hard part is remembering to go look for it :)
It’s normal to think that if there was a tool you could use your teacher or your boss or someone on your team would have told you about it, but thinking to look for tools like that is surprisingly unusual. And to be fair, it can be a real timesink to try tool after tool just to find out none of them are better than what you’re already using.
If there isn’t already a tool, you might be able to build one. That’s exactly what bash or powershell scripting is for – fiddly things that humans are bad at and tedious but simple things that humans just don’t wanna do. If you’ve ever run a build script, you’ve used a custom tool that someone wrote to automate building your application so it gets done the exact same way every single time. No matter what OS you’re running, there will be other scripts out on the internet that you can take apart to build your own custom tools.
Whether you find tools or build your own, remember that boring stuff is the computer’s job!
First, a caveat: I learned this on EC2 instances and make no promises that it will work in any other setup. That said:
The recipe runlist is not anywhere in your custom cookbooks, it’s in the layer settings for each layer in your stack.
If you add a new cookbook, recipes absolutely have to go in the recipes folder under the [cookbookname] folder.
Data that your recipe expects, such as “node[‘datadog’][‘jmx’][‘instances’]” must exist in an attributes file or your stack settings or something, but doesn’t necessarily have to have a value. The structure just needs to exist with the expected names.
Cookbooks have metadata (metadata.md) where you define the version number of your cookbook and which other cookbooks it depends on. You can optionally list the recipes inside the cookbook but you don’t have to.
If you update your cookbook you can update that cookbook on your instances without redeploying them by running the Update Custom Cookbooks command from your stack (the run command button is beside the stack settings button on the “Stack” page for your stack).
Once you’ve updated your cookbook you can run your updated recipes almost the same way, just select “Execute Recipes” instead of “Update Custom Cookbooks” in the dropdown and put a list of recipes to execute in the field below the dropdown.
If you want to see when you ran a particular command on a linux, you just need to run
HISTTIMEFORMAT="%d/%m/%y %T "
at the command prompt, then the next time you run
you'll have handy timestamps! Thanks as usual to stackoverflow for that answer.
So that's cool and all, but why should you care? Because being systematic is extremely important when you're trying to solve a problem. If you don't know exactly when you changed something, you'll have a rough time figuring out which results were caused by which change. If you don't know which change caused which results, you're effectively stumbling around in a dark room at random, hoping you run into a light switch. Not only is that frustrating, but it's a huge waste of time. Systematically changing one thing, checking on the results, then changing one more thing and checking the results again can seem slow, but in the long run it's much faster than stumbling around and hoping.
Using myself as an example, knowing exactly when I ran a particular command let me compare what I had done with what was showing up in the logs and showed me that it was most likely a combination of two commands I had run rather than a weird delay after the first command that gave me the results I wanted. If I hadn't been able to figure out exactly when I ran each command I would still have no idea which one of them helped.
First of all, each problem in Exercism has a set of unit tests, so you don’t have to wonder if you’re doing it right, you can just run the tests and know for sure. The tests are also great for experimenting with your code and seeing if you can make it easier to read or easier to change without breaking it.
The problems are also carefully chosen to help you learn concepts that are important to each language. Just because you can solve a problem in a certain language on a coding challenge site like HackerRank doesn’t mean you’re learning anything interesting about that language in particular. I know that’s not really what challenge sites are meant for, but I’ve seen them recommended to a lot of people who are learning and think it’s important to be clear about what challenge sites are good for (general programming concepts) and what they aren’t necessarily good for (learning individual languages).
And finally, Exercism directly incorporates both giving and receiving feedback. Obviously getting feedback is helpful – to directly quote the Exercism site: “You can write FORTRAN in any language, as the saying famously goes, but with enough feedback, you’ll quickly find yourself writing the language the way it wants to be written.” – but giving feedback is seriously underrated. To tell someone what you think of their code, you have to read it carefully and then think seriously about what makes code good or bad. That’s enormously helpful when you’re new and don’t really understand what “good code” means yet, or when you’re new to a language and just don’t know the best way to do things in that particular language.
You know what sucks? Desperately trying to figure out how you broke your html layout, only to discover hours later that you had an invisible element or padding or a margin that was quietly ruining everything. Pesticide to the rescue! Pesticide is a very simple Chrome extension that does just one thing – it outlines all of your elements. That’s it.
I have a thing for simple tools that do one thing and do it well, and Pesticide is just that. No screwing around with settings, no trying to remember how to activate it, you just click the little bug icon beside your omnibox to turn it on and click it again to turn it off. Simple is just what you need when you’re fighting with your layout. Try it, you just might like it!
The reason I like this flowchart so much is that it’s really clearly broken down into steps and doesn’t drown you in information you don’t need. A lot of git guides start talking about branching and merging right away, and while those are important concepts they’re not necessary if you just want to put a simple project up on github so other people can see your code.
Fun fact about authenticators like Google Authenticator and Authenticator Plus: they have their own internal clocks that can get out of sync with the server you’re logging into. Most of the time they don’t drift far enough to cause problems, but AWS is very, very particular about your clock being in sync with theirs.
If you find that AWS rejects your one time codes but the rest of your accounts work just fine, it’s probably a clock sync issue. In Google Authenticator the sync function is easy to find under ‘Time correction for codes’ in the menu. In Authenticator Plus it’s hidden behind ‘Others’ -> Sync with Google. Try that before you waste a morning trying to figure out how one and only one of your accounts got corrupted ;)
Lately I’ve been updating some docs that we generate from YAML files and while I do like YAML as a format (beats the hell out of XML, but that’s the kind of bar you trip over), it can be really painful to figure out where exactly you messed up your indenting.
Fortunately, there’s an atom plugin for that! linter-js-yaml gives you incredibly fine-grained and helpful error messages. Isn’t that screenshot pretty? It’s got a nice obvious red dot and an underline and an error message that actually tells me what I got wrong! If you ever edit YAML, try linter-js-yaml, it’s awesome.
Since I switched to Linux, I’ve had to find a replacement for my beloved notepad++. I went with Atom because I like the project view in the sidebar and I’m too cheap to pay for Sublime.
Because I miss notepad++ so much, I’ve been slowly trying to make Atom behave as much like it as I can. One very simple plugin that helps me do that is selection-highlight, which highlights all occurrences of a word when you double-click it. For something so simple it’s really helpful, and something I missed a lot when I switched to Linux. Sometimes you just want to know whether the id you logged in a few different lines is actually the same, and it’s really nice to be able to do that with only two clicks.
If you use Atom, I recommend the selection-highlight plugin, and if you don’t use Atom, I recommend trying it out. It’s free and there are about a bajillion plugins :)