tools

Where to start with Node.js as a Java developer in 2017

Recently a friend of mine who is a veteran Java developer was asking me about Node.js development. He tried to do some Node development 3 or 4 years ago, and got frustrated with the lack of tools and Javascript callback hell. I tried to tell him that things have changed greatly since then, but found myself not able to formulate a good response in the moment. He had also read “How It Feels To Learn Javascript in 2016”, which is really funny, but isn’t exactly a vote of confidence to try Node again!

Shortly after, I came across “Why I Struggle With Node” by Graham Cox. It’s a great post about why he loves Node.js, but gets frustrated with its ecosystem and prefers that of Java.

Having been a Java developer for 7 years before switching to do mostly Javascript development, I can say that I agree with many of Graham’s sentiments. The Java ecosystem is much more mature and the tools are great. There are many things I miss. But I don’t get frustrated with Javascript’s tooling as much. I actually find the Javascript ecosystem and its tools invigorating, as long as you know where to start…

The post made me think of my conversation with my friend. I linked to Graham’s post as a starting point, added some additional thoughts and sent them to my friend to give him a place to start with Node again. After I wrote it up, I thought it might be useful to other Java developers who haven’t taken the dive into Node.js and would like to, but might be intimidated or not know where to start.

If you’re in that boat, I suggest you first read Graham’s post. It has a great list of tools to start with that translate well into front end code too.

After you read that post, here are my notes and addons that I think might be helpful if you are coming into Node development from Java in the beginning of 2017:

Learning Javascript

If you don’t already have a good grasp on the Javascript language, or consider yourself just good enough to be dangerous, I found “Basic Javascript for the Impatient Programmer” to be particularly useful in improving my understanding of the language. There’s tons of great books as well out there that you can easily find.

Also, before you dive into creating a full app or start setting up tools, learn the Promise API and use it from the start in your code. It will make your code easier to reason about, and will make your life much more pleasant once you get past the initial learning curve. If you can, use the Bluebird library for Promises. It has lots of great extras on top of the native implementation, and rumor has it that it’s even faster.

Builds

Like Graham, I use Grunt for building, too. I haven’t tried Gulp, I’m sure it’s great, but I’ve used Grunt for a while and have found it effective. Though, like Graham, I do miss the fact that Maven takes care of a lot of the gruntwork (ha ha!) for you. For my team’s apps, we have separate Grunt tasks and configurations for building front end and back end code since folder structures are different.

Transpilers

I don’t use Babel. If I’m being honest, the whole transpiler thing is a mystery to me. I kinda get it: You want to use new features in the language, especially in a browser environment that adapts rather slowly. But if you’re writing production code that needs to be supported by a team with varying levels of Javascript knowledge, it seems to add unnecessary complexity. It’s hard enough keeping up with Javascript, let alone when you do source to source compiling. It will also make your toolchain a lot easier to configure, and your debugging a lot more straightforward.

Code Coverage

This is mentioned in the post but I thought I’d provide what I’ve used: Istanbul through Grunt. It’s nice and simple and does the job well.

Logging

Graham mentions that Node logging isn’t as nice as what he’s used to in Java. That’s true, but I’ve used Winston quite effectively in production apps.

Debugging

Graham is right, debugging in Node is hard. I attribute some of that to it’s asynchronous nature, though.

I’ve used node-debug effectively as a debugger. It’s quite nice, but a real pain to setup. But, if I’m being honest again, usually I try to use Winston (mentioned above) to put some nice low-level logging statements in place so I can debug with those, then turn logging levels up and down as needed. Sometimes those low level statements help when you’d least expect it.

Application Wiring

When I first started with Node, we were using a dependency injection framework in Node since my team was used to using Spring in Java. After a while, we just got frustrated with it and abandoned it.

Javascript is a dynamic language, so it’s really easy to stub and mock things out. Use something like Proxyquire to trivially inject mocks in tests.

Integration Testing

Graham’s comments about integration testing being much easier in Java are spot on. I haven’t come across nearly as many drop in, in-memory replacements for connected systems like databases or message queues. This makes it tough to integration test. What I’ve done in the past is to create throwaway Continuous Integration database instances at the beginning of the tests and then clear them out at the end of the tests. It’s not that bad once you set it up once, but I yearn for the ease of using something like HSQL in Java.

Team Development Environments and Docker

My team has half Windows users and half Mac users. It makes for a challenging environment for everyone to setup their development environment in Node.

If you’re on a team with developers using multiple platforms, and deploy to Linux, what I recommend is to create a Dockerfile which defines your development environment. Then, use a Docker volume mount to put your source code inside the container. (Side note: Use an official Node.js Docker image as your base image). This lets you use normal Docker build/run commands to bootstrap your dev environment. The volume mount lets you dynamically update your code so you can still iterate fast, as if you were working on your local machine. It works well across platforms (no worrying about exceptions in Windows), and as a bonus, if you ever want to run your app in a Docker container, you’ve already got it more than halfway there. I’m hoping to post more about this in the future.

Go enjoy!

I’ve been developing in Node for about 3 years now, and I still really love the developer experience. Sure, I’m probably not using the latest and greatest tools that just came out, but this workflow has gotten me to a good place where I can be very productive and crank out some good quality code.

I hope some of these notes help you do the same.

What tools/techniques/libraries did I miss that were important for you when you came to Node from Java?

On Learning Vim: False Starts, Pain, and Overcoming the Hump

I’m not going to try convince you to use Vim.

If you’re reading post and haven’t already closed it, you’re probably already convinced that it’s useful.

The purpose of this post is to help if you want to learn Vim because you see its promise, but just can’t seem to get past the hump of learning it and making it your primary editor. Or, perhaps you don’t know where to start.

In my opinion, and probably many others’, it is worth getting past the Vim hump, so hang in there! I’ll tell you how I went from IDE lover to Vim lover and hopefully provide some useful tips to get you there as well, if you want to.

The Beginning

I got my start developing in Java. So, what was my code editor of choice? An IDE, of course! First Eclipse, then IntelliJ IDEA.

As I moved along in my career, I saw presenters at meetups and conferences who used Vim. I watched in awe as they performed text gymnastics during their presentations. It was like they were playing an instrument, rather than coding.

Occasionally, in a fit of inspiration, I would give Vim a try. But I could never could get into the swing of things. It just seemed too hard to learn and I couldn’t get past how difficult it was to navigate around a project with a large set of files.

Because of this, I never committed. I always ended up going back to my IDE (or some other modeless text editor), even for scripting languages like Javascript. I spent a little time looking for the best of both worlds and found some plugins for my IDE which provided Vim keybindings. But you still had to use IDE features and shortcuts to navigate around. It never felt quite right.

So, I puttered on, half-effectively using Vim on remote Linux servers where I quickly needed to view or edit a file without downloading it.

The moment of inspiration

A few months ago, I had the fortune of working alongside a JavaScript developer who just so happened to be a Vim ninja. I could watch him code in real time, and more importantly: ask questions.

Usually it went something like this:

Vim Ninja: (( tap tap tap )) – ((50 lines show up on screen in the exact spot he wanted))
Me: Wait! How the hell did you do that!? Show me!
Vim Ninja: Oh, that’s a macro, you just type ‘q’ then…

You get the idea.

I didn’t get any detailed training from him, per se, but I was able to find out about some useful plugins and configuration options that got me really excited to use it again.

At that point, I decided that the way I was writing my code was not as effective as it could be, and I needed to fix that. Since I was writing lots of Javascript code for a Node.js application, it was a good fit. My usual IDE features of navigating around types didn’t really matter that much in a dynamic language.

So, I spent a handful of hours learning how to configure Vim and installed those plugins that the Vim Ninja recommended. After I finished, I told myself I was going to force myself to use Vim and only Vim for at least two weeks.

The Commitment

Then, shortly after I started, this happened:

I love this slide from SparkBox, because it is so true with lots of developer tools, but especially with Vim (and Git – perhaps the topic of another post).

If you’re comfortable where you’re at coding, when you decide to try a new tool like Vim, there is an immediate, sharp hurt you will feel. The hurt is usually accompanied by questioning the usefulness of the tool and the strong desire to give up.

You have to be determined to get through that hump, but when you do, you reach places you never thought possible.

How to learn to stop worrying and love the Vim

To appreciate Vim and take full advantage of it, you have to want to learn it, and need discipline. Force yourself to use it as your primary text editor for at least a few days or a week. Longer if you can. If you don’t, you will simply hit the “Ouch!” stage, get frustrated and never go back.

Where to begin?

For people in the same boat I was, or people who are brand spankin’ new to Vim, here are a few suggestions to get started on your Vim journey.

Install the right version

As of this writing, the latest version is 7.4 and that’s the one you should install to get all the latest good stuff.

On OS X

On OS X, Vim is installed by default, but chances are it’s an older version and you’ll want to get a newer one, and update it frequently.

To do this, I would recommend using Homebrew and installing Vim using that: brew install macvim --override-system-vim

You’ll also want to make sure that your fresh new Homebrew install of Vim is the default version you use when you type vim or macvim. The --override-system-vim flag should do most of this.

If you type which vim you should see /usr/local/bin/vim. If you hit issues, the default version of vim may be first in your $PATH and may need to be adjusted. This StackOverflow post is really helpful to get that configured correctly.

On Windows

For Windows, the Vim installer will give you options to install a gui and console version of Vim to use.

Learn the basics

This post isn’t about how to do this, but there are tons of resources out there:

Go whole hog

Don’t learn a bit of Vim, dip your toe in, then shift back to Sublime Text (without vintage mode on).

Make Vim your default editor, and open up all your text files in it. Resist any urge to open up anything else to type into, unless there is no other option! Do this for at least two or three weeks.

This is a bit like trying to get into an exercise regimen. It’s painful at first, but then gets easier and easier. Finally, you get to a point where you feel great about it and it starts to become more effortless.

Find a time when you’re not under tight deadlines

Under the gun to get features or fixes in at the end of a project? Not the time to be learning a new editor. Learning Vim will cause you to frequently pause, remember a key combination, and interrupt your flow temporarily.

Find a stretch of time at the beginning of a project, or second to that, in the middle of a project, where you have a bit of leeway to let your brain and your finger muscles get used to the shift in how your new editor works.

If you’re not under a lot of pressure, you’ll power through the “Ouch!” stage in a much easier fashion.

Focus on how to properly use Visual Mode

Learning how to really use visual mode effectively was my “a-ha” moment. This is why using a modal editor is great.

Learn the basics of shift+V, shift+v and about yanks and puts. Once you get the hang of these basics, you will be flying and the (text) world is your oyster.

Learn about the basics of a .vimrc file

A .vimrc file in your home directory is how you will configure Vim. And you’ll probably want to set some custom configurations right off the bat.

A great start is showing line numbers. (Why doesn’t Vim show them by default!?)

Just create a file called .vimrc in your home directory which contains this:

And start vim up. Viola, you’ll have line numbers all the time.

Then, go from there. There are tons of great resources out there on how to configure Vim. I would recommend finding some examples of .vimrc files and learning about the configurations you see in them. Everyone and their brother are starting to post their .vimrc and other dotfiles on Github.

You can find my .vimrc, too, it’s right here.

My favorite resource is to look at ThoughtBot’s .vimrc file. They have a good default set of options and the comments do a pretty good job of explaining what certain things are.

Install Some Good Plugins

There are some Vim purists who think you should learn Vim without using plugins. I disagree. It is useful to know “pure” Vim in case you’re out on servers and don’t have any plugins. But doing any significant development in Vim without a few decent plugins is like using a rotary phone – it’ll get the job done, and it’s kinda hipster-retro-cool, but it ain’t fun.

First off, go get Vundle. Vundle is a Vim plugin manager that will make installing new Plugins and updating them a breeze.

Once you get it setup, you can just add lines like this to your .vimrc to add new plugins:

In this config, the text you put inside the quotes is a git repo for a Vim plugin. Then you can run :PluginInstall to install. You’re done.

A list of plugins that will come in handy regardless of your language

CtrlP

This allows you to type ctrl+p and a filename. It’ll do some fuzzy searching on your filesystem to find files that match. You can then navigate up and down the search results list and open a file in your buffer.

This is really similar to Eclipse’s ctrl+shift+r or IntelliJ’s ctrl+shift+n functionality.

NerdTree

This gives you a sidebar with a tree version of your filesystem (think the tree view in Sublime Text).

It’s awesome to be able to navigate up and down your file structure and open folders freely with just the keyboard. This is really great when you can’t even start to remember the name of a file.

I also find it really useful to use Vim’s / search functionality find a folder name in the tree to quickly navigate to it.

I would recommend mapping the toggle on/off for nerd tree to a key binding like map <C-n> :NERDTreeToggle<CR>. This maps ctrl+n to turn on the tree.

DelimitMate

Auto completion of parens, brackets, etc. Ya need it.

NerdTree Git Plugin

If you use git, this one is great to see visual indicators of what git status your files are in right in a file tree.

GitGutter

Again, for you git users, this one is great to visually see added/deleted/changed lines in the left hand side of your buffer.

Javascript coders, you’ll be in plugin heaven

Javascript has an amazing community of developers making great plugins for Vim. You’ll have a blast trying them all out.

I’ll leave the configuration and plugin recommendations to this excellent post to help you get setup for Javascript in Vim: Equipping Vim for Javascript

Java coders, things are lacking…

Even thought I’ve been coding a lot recently in Javascript, I still code in Java a decent amount. I wish I didn’t have to say this, but I still find myself going back to IntelliJ IDEA when I need to work in it.

Simply put: I could not find anything that could really compare with the tight integration and IDE provides for a static language like Java.

There is real power of being able to navigate to static types and methods with a simple keyboard command or ctrl+mouse click. It’s also crucial for me to be able to do type-safe refactorings. Both of these things are built right into these IDE’s and are bound to keyboard shortcuts right out of the gate.

That’s not to say there aren’t options for Vim: I tried out Eclim which requires a headless version of Eclipse, but it was wonky to setup, and didn’t run very smoothly. It just didn’t feel worth it.

So, if you have to code in Java and only Java, you might have a tougher time really committing to Vim using the suggestions in this post.

However: You can install Vrapper for Eclipse or IdeaVim for IDEA which provide nice Vim-like keybindings for those IDE’s.

If you learn a combination IDE shortcuts for navigating around files and combine those with Vim’s keybindings along with Visual Mode, you’re more than halfway there. That’s what I do, and I find it really effective.

If you’re new to Vim and this is your only option, just really force yourself to not turn the plugin off if you get frustrated! :)

Some other thoughts

If I had unlimited time, I would really love to create an open source project which packages up these essential Vim plugins and installs them with some default configurations. I spent a pretty good amount of time getting configurations together so Vim felt usable enough for me. It would help others get over the hump a lot quicker if there were pre-configured “packages” that could be installed. Maybe something like this already exists and I don’t know about it?

Finally, while writing this post, I found this really great post from Antonin Januska which shares some very similar opinions of mine and is a really good read.

Update 2/26/2015: I Just came across a fantastic, step by step tutorial to setting up vim with plugins by jez on github. He uses a great approach of using git commits to walk through the process.