• Contributing to Open Source

    One of the questions I’m always asked is how to get experience in tech writing. It’s a chicken/egg problem: you need a job to get experience, but you need experience to get a job. You can attend a code camp or complete a certificate program to get some real-world experience to add to your resume, but what I always tell people is to get started with open-source software.

    There is a lot of open-source software out there these days. I got started in computing before this was the case, but was an early adopter of the Linux OS in the early 90s, which changed everything. Now, entire communities have sprung up around the development of operating systems, servers, programming languages, and desktop software. Tools like GitHub have centralized participation, putting source code in a centralized location, and providing tools for quick communication about projects, instead of crufty old mailing lists. It’s made it very easy to explore projects and contribute to them.

    Here’s a great article about how to get started on this:

    https://medium.freecodecamp.org/contributing-to-open-source-is-not-hard-here-is-my-journey-to-contributing-to-nodejs-d10760e31194

    This example is specifically about a developer contributing to the Node.js programming language. But there are a lot of opportunities for tech writers, because documentation for projects is not always that great. The only issue is that there aren’t always that many documentation bugs listed in projects. It requires hunting down a project you like (check out the “explore” section of GitHub to browse through things) and deciding what needs improvement.

    Overall, it’s a great way to gain experience, and also improve tools that everyone will use. And, maybe you’ll someday get a job out of it.


  • Gray/Grey

    I wish I had learned this forever ago:

    • If you are in America, it is gray
    • If you are in England, it is grey

    It’s that simple.

    (I partially blame this confusion on Fifty Shades of Grey.)


  • FrameMaker and the Kinesis Advantage Keyboard

    Because of RSI, I use a Kinesis Advantage keyboard. I used the Microsoft ergonomic keyboards for a while, but I’d burn one out every year, and the membrane keys are a bit mushy. I went whole-hog and spent the money on the Kinesis, which I don’t regret at all, except for one thing: the function keys. The F-keys and Esc are little rubber chicklet keys reminiscent – I’m dating myself here – of the Atari 400. And when you’re in FrameMaker and doing some heavy formatting, those keys are essential.

    You can remap keys in the Kinesis at the keyboard level, but I switch between Windows and Mac machines through a KVM switch, so I wanted to avoid that. Instead, I use AutoHotkey, a nifty little free Windows utility that enables you to easily remap keys at the OS level.

    Head over to https://autohotkey.com/ and grab a copy. My AutoHotkey.ahk has the following entries for FrameMaker:

    Home & 5::Send, {F8}
    Home & 6::Send, {F9}
    End::Send, {Esc}

    I don’t use the Home and End keys much, so I stole them for my own use. On the Kinesis, they are in my left thumb cluster, and great for frequently-used combo keystrokes. So I map:

    • Home-5 to F8. That opens the character designer.
    • Home-6 to F9. That opens the paragraph designer.
    • End to Esc. I use Esc constantly for Frame shortcuts, most notable Esc-j-j to repeat a paragraph assign, and Esc-c-c to repeat a character assign.

    AHK can do a lot more stuff, like assigning keys to modify and paste the clipboard, run macros from DLLs, and more. If you have a highly repetitive text massage job you can’t tackle in a script, check out the advanced options. But it’s easy to use for a few quick remaps.

     


  • Adjusting Mic volume from the command line in Windows

    I spend a lot of time in meetings on a USB headset. I have a Windows computer. So every day, multiple times a day, here’s the drill:

    1. Plug in headset.
    2. Mic volume is a random number.
    3. Right-click Sound.
    4. Wait for the right click to register, because half the time it doesn’t, and the lag is horrible.
    5. Select Recording Devices. See last step about lag.
    6. Click Microphone.
    7. Click Properties.
    8. One in ten times, this will cause the control panel to gray out and freeze, so wait five minutes and/or force quit it and start over.
    9. Click the Level Tab. (It’s not the first tab, so this takes ten seconds to scan.)
    10. Change the level back to 100.
    11. Click OK.
    12. Click OK.
    13. Feel the great joy in knowing you’ll have to do this three or four more times that day, which adds up to like 18 months of your life.

    The same process on a Mac:

    1. Plug in the headset. It remembers what you had the level set to the last time it was plugged in.

    There is a great way around this. It’s called NirCmd, and it’s a great little free Windows command-line executable that enables you to do all sorts of weird things from a command prompt or batch script.

    Go grab a copy of it at the above link. The first time you click on the exe, it will ask to copy itself to your Windows directory, and then it’s in your path, ready to go. Create a .bat file like this:

    nircmd setsysvolume 65535 Microphone

    Each time you put in your headset, run that, and you’re good to go.

    Nircmd also has some commands for shutdown/reboot/standby/logoff if you are sick of digging in the Windows menu for those commands.


  • REST API Doc article

    I think the big problem with API docs is what to document. And it usually ends up with a comment per method, where you have “createFoo = creates a foo; deleteFoo = deletes a foo” and no real content. The question always becomes “well, what else?” And the real value of API docs is everything in between, the things you can’t infer by just looking at method signatures.

    The following article is a good list of the other things you need to cover. It talks specifically about REST, but holds true for other API types, also. The TL;DR: what does a consumer need to know to actually use this API? How do you do auth? What are the business uses? What standards does it really follow? What are the other gotchas? What are the SLAs or other requirements for the service?

    https://dzone.com/articles/rest-api-documentation-part-1