The achilles heel of Node.js: Refactoring

Refactoring of Node.js code is awful, and I don't see it getting much better.

Working through a few smallish node projects it's become clear that there are lots of good solutions to many of the issues that people bring up about node, and more importantly, Javascript. My biggest issue early on was with the nesting of callbacks, but the excellent async library has make that a near non-issue. And other parts of Javascript I've come to know and love.

But when it comes to refactoring code, the problems inherent with dynamic languages come to the forefront. The IDE (in my case IntelliJ) can't rely on names and types to make refactoring easy. As a result, moving a function from one module to another is a scary experience. This is especially true if we're doing some JS magic where functions may be referenced by something other than their name.

The obvious response to this is that I should have better unit tests, and that's a given. But even still, running those unit tests would require me to manually make my own fixes based on the change. When I switched from C++ to Java, the refactoring support was one of the 'lightbulb' features that made me never want to go back. I get a little obsessive about my code; I want it to be beautiful; I want each of the pieces to be in the right place, making it readable, understandable, and just make sense. Without refactoring tools, that will be much more difficult. 

Kotlin Links

1. A comparison of a simple algorithm using Kotlin and Groovy. I agree with the conclusion; Kotlin is revolutionary perse, but takes ideas in more revoluationary languages and makes them more approachable to Java developers, and provides the tooling.

2. The Kotlin Journey Part II: A primer on classes. A nice walkthrough. For some reason, I still find the absence of 'new' uncomfortable, since it's pretty descriptive. I haven't seen a good reason for why it's not there, other than to reduce the number of keywords. Perhaps the implementation of primary constructors made the new keyword seem out of place.

3. Should Kotlin support 'Here Document' style string literals? Seems like a good idea to me. I've struggled often with escaping strings in Java, and these literals would seem to fall under the category of functionality that prevents errors (how often have you erred in your escaping?).

Use multiple GitHub accounts

I'm working on a project where I need to be able to connect to 2 different GitHub repositories with 2 different sets of github credentials. It took a tremendous amount of digging to figure out how to do this, but I've managed to get everything working. 

I'm starting with the assumption that you already have an account setup. You've got credentials stored at .ssh/id_rsa.

Now, create another set of keys and store them in the same location. You can name them whatever you want (ie. id2_rsa). You'll need to add them to the local ssh database by using ssh-add:

ssh-add ~/.ssh/id2_rsa

You're going to need to create (or edit) the ssh configuration file (.ssh/config). In the file, you set up a mapping between hosts and your local keys. Now, this confused me, because I figured that github.com would be the same host for both cases, but it turns out that you can use the config file to map hosts to the same host name:

Host acct1.github.com
    HostName github.com
    IdentityFile ~/.ssh/id_rsa
    User userid1

Host acct2.github.com
    HostName github.com
    IdentityFile ~/.ssh/id2_rsa
    User userid2

You're all setup, but if you use github normally, this still won't work. When you clone, you'll need to use the hosts that you've defined in the config file instead of github.com. So, instead of:

git clone git@github.com:somecompany/somerepo.git 

you'll use:

git clone git@acct1.github.com:somecompany/somerepo.git

SSH will use the config information to route to the proper host using the key file associated with the host you defined. 

Installing Node.js on Amazon Linux AMI

I was struggling to figure out how to get Node.js running on Amazon's default Linux AMI, and just wanted to give a shout out to this article that helped immensely. W00t!!

Assorted Links

1. Waterfall development doesn't work for the government either.

2. Node.js not ready?

3. Client-side throwdown. Small, individual templating effort bests the rest.