Programming with your voice? It’s not that far-fetched

I was recently in a discussion with a friend about the challenges that face folks like me that spend a LOT of time at a keyboard. I’ve had many friends in the industry that have been diagnosed with various levels of repetitive stress injuries (RSI) and I’ve seen first-hand how debilitating these conditions can be. Just trying to do everyday things, especially writing code, can range from slightly painful to downright impossible depending on the severity of the condition.

I made the statement that it would really be nice if modern software development tools were more “voice-aware”. My friend forwarded me a link to this video from a couple of years ago on YouTube of a presentation given by Tavis Rudd showing how he changed his daily workflow and toolset to be able to do ~60% of his daily tasks with his voice.

While he has a LOT of work invested in customizations and training himself to use his new workflow, the amount of things he can do just by speaking to his computer is pretty amazing. He mentions that after a few months his RSI symptoms were completely gone. That to me is the proof that his hours spent training and customizing his system to “work” for his situation were well spent.

With the recent rise in popularity of Amazon Alexa and Google’s recent release of Google Home, I can only hope that in the near future the process gets easier to adopt for a wider range of developers.

Generating a Local Copy of NativeScript Documentation

This will be a quick post to document how to generate a local copy of the API documentation for NativeScript. One of the things I’ve been disappointed in with the NativeScript ecosystem is the state of the documentation. There are several “How-To” articles and some API documentation on the docs.nativescript.org site but I’ve found a distinct lack of comprehensive documentation to be a stumbling block in learning how to build apps with NativeScript.

In talking with a couple of the Telerik folks in the NativeScript Community Slack team (get an invite if you’re not already on the team), it came out that the team has been working on a way to automatically generate the API documentation using from the source code using an open-source package called TypeDoc. The resulting files haven’t been made publicly available yet as the engineering team is still working on getting the theme and styling modified to suit them.

However, with a little command-line mojo, you can generate your very own, locally-hosted version of the docs. Since NativeScript is open source and hosted on GitHub, you can pull the source down and execute the documentation build yourself.

First, we need to make sure that the Grunt task runner is installed (I’m assuming you already have NodeJS and NPM installed here):

npm install -g grunt

Next we’ll clone the main NativeScript repo:

git clone https://github.com/NativeScript/NativeScript.git

You’ll want to switch to the latest stable tag (after all, you’ll want documentation for the version that gets installed with NPM):

cd nativescript
git checkout v1.7.1

*note: v1.7.1 is the lastest as of this writing. Run `git tag -l` to see what tags exist

One more setup step before we generate the docs. We need to install the dependencies:

npm install

Now that we have the source and all its dependencies, we’re ready to generate the docs:

grunt typedoc

You should see the grunt task kick off and hopefully at the end say “Done, without errors.”
grunt-typedoc-result

If that all went well, you now have a new folder inside your nativescript project folder named `bin`. Look in `/bin/dist/api-ref` and double click the `index.html` or `globals.html` file.

nativescript-folder-structure

Not only can you get your hands on this before the NativeScript team gets it prettified to their liking, but having a local copy is always nice in case you’re like me and sometimes working where there isn’t reliable internet access.

iTerm2 Features You Didn’t Know You Were Missing

For the last couple of years I have been developing with technologies that require spending a fair amount of time in a terminal session. I’m a Mac user (even an admitted Apple fanatic) so for years when I needed to SSH into a remote server, launch my local MongoDB server or start the Grunt or Gulp build process for a project, I reached for Terminal.app to get things done.

Then a few months ago I started using the free iTerm 2. At first I really didn’t see the advantage of using iTerm2 over Terminal.app. While iTerm2 had a few more visual customizations that Terminal.app, the difference didn’t seem that great. Then I found 2 features that, for me, made all the difference in the world.

Read More

Standing Desk Update

Almost 18 months ago I wrote about starting an experiment with my standing desk. Then last summer, I purchased two ERGO adjustable standing/sitting desks from Autonomous.ai for my wife and myself. I’ve now had the ERGO for a little over 7 months and wanted to share an update about it.

As I mentioned in the unboxing video that my son and I did, the desk is built very solidly. It’s very stable both during regular use and while moving from one position to another. The motors, while not completely silent, are quiet enough–and fast enough–that I can move between positions even when on conference calls without disturbing the conversation. I have gotten a few interesting comments however when I move from one position to another while on a video call and suddenly the other participants start to see the room moving in their video feed!

Read More

The Perfect (Network) Storm

For the last few months, we’ve had a really annoying and intermittent issue with our home networking setup. I’ve had my home network configured to use the 192.168.100.x IP range for several years. In February this year, my Time Warner issued cable modem failed and I purchased a Motorola SB6121. This summer, in preparation for Google Fiber coming to our area, I upgraded my router to a Cisco RV130 small business VPN router. Ever since then, at odd intervals, we’d notice issues with internet access and discover that the router had reconfigured itself to use 10.10.10.x range for the internal network.

After the first couple of times of manually resetting the IP range, I created a backup config file to quickly restore the correct settings and reboot the router. I contacted Cisco support and spoke with several different support technicians. One had me set up a syslog server on my network so we could get a durable copy of the log entries from the router since the internal logs are cleared on a restart. This week, the support tech I was working with and I were reviewing the logs and found something pretty startling.

Any time the cable modem would lose connection to the upstream network, it would assign the IP address 192.168.100.10 to the device connected to its ethernet port until it could reestablish a connection to the upstream DHCP server. That device just so happened to be the WAN interface of the RV130 router. Even though it only happened for a few seconds, the router would see an IP address on the WAN in the same range as the internal LAN. At that point, it made the decision to change the internal IP range to 10.10.10.x to avoid a conflict.

The fix was simply to pick a different IP range for my internal network. Once we figured out what was going on and reconfigured the internal IP range, I tested the theory by power cycling the cable modem while tailing the log file from the router. Sure enough the router configuration stayed consistent and we haven’t had issues since then.

Who would have guessed that a decision that I made 8+ years ago would conflict with a decision the Motorola engineers made for their equipment defaults?  I’m just glad we’re finally stable and I can get back to solving problems with the software that I write vs the stuff in my house that needs to “just work”