How to Remote Debug Node.js

Finding and fixing bugs is not always easy, especially if someone else wrote the code!

I know that engineers in general have NIH syndrome, but I am one that doesn’t share that view. Technology is an enabler, meaning it’s not an end goal, it is there to provide a service (or at least that is how it is most of the time).

As such, we must sometimes make fixes to our code, or to other people’s code, and that requires debugging. I’ve seen many people use console.log/logger/printf – heck, sometimes they even suggested that I do it that way. But as much as I enjoy waterboarding myself, I’d much rather use a debugger whenever I can. Debugging a node.js project isn’t complex, it just requires a little bit of setup, after which you can debug a local app or even a remote production/staging/test environment.

The first step is to run node.js with the special debug flag and the optional port:


node --debug <-- run node with debugging on port 5858

node --debug=4455 <-- runs node with debugging on port 4455 (you change the port)

node --debug-brk <-- run node with debugging and will break on first statement

If you’re using gulp/nodemon etc, be sure to include those flags in a separate task and/or pass the relevant params to your node app.

// Nodemon task
gulp.task('remote_debug', function () {
return plugins.nodemon({
script: 'server.js',
nodeArgs: ['--harmony', '--debug=5577'],
ext: 'js,html',
});
});

Then you can launch your app, or do it via the task, and your node.js app is running and allowing any debugger to connect to it.

You can use any node.js you choose. I personally use phpstorm/webstorm. While it’s not a perfect product and has some issues, I’ve had very successful debugging sessions with it, and I’ll try and outline how to set that up.

First install webstorm/phpstorm. Both IDEs are great and very similar, except Phpstorm also allows you to edit and work on PHP files, whereas Webstorm mainly concentrates on JS files and web files.

After the install, launch the app and go into the plugin:

Go to File->Settings and in that screen click on the plugins menu item.

plugins_screen

The click on the “Install JetBrains plugin…” button and in the new window either scroll down or search in the top search box for NodeJS plugin.

Once the install is finished, you should have NodeJS installed and you can go ahead and open your projects directory in the IDE. (File->Open Directory, obvious I know, but still… 😉 )

In the last step we need to configure the remote config for our node project.

Click on Run -> Edit Configurations… Menu.

And Click on the + button and select Node.js Remote Debug.

node_remote_debug_new_config

Then in the main window just setup the server address and port (this can be used to debug a remote machine or a local machine)
And you’re all setup to start debugging your server!

node_debug_local

Then click ok, select the configuration from the top right-hand side menu and click on the little bug icon button:

remote_debug_launch

At this stage you’re up and running. If you look at the bottom debug tab you should see you’re connected and then you can put a breakpoint anywhere in your code and solve any bug you come across like a hero (at least in theory! 🙂 ).

***** Important note *****

While Phpstorm/Webstorm is wonderful, I’ve had some issues with debugging performance. This issue relates to some settings in the software so to ensure you do not get frustrated waiting for the first breakpoint to hit, I would suggest you configure Phpstorm/Webstorm as follows:

1) Click on help -> “Find Action” (ctrl + shift + a)
2) In the searchbox type: Registry.
3) Then start typing (or scroll down) and find
js.debugger.v8.use.any.breakpoint – turn off

Happy Hunting!

Authenticating with Ember-Simple-Auth

Recently I’ve setup an ember project and I needed authentication. There is an excellent library / cli plug-in called ember-simple-auth. While the guides are great, the most recent version of Ember(1.13 / 2) doesn’t play nicely with the latest ember-simple-auth.

Ember-Simple-Auth, provides a special branch called jjAbrams (PR 602). While it is an awesome library, getting it to work can be somewhat tricky as not everything is as documented and requires some tweaks here and there. I’m trying to outline what I did, in the hopes it will save time for many others. And help prevent other devs from banging their heads against their keyboards, posting issues on git repositories or irc channels, or reading simple-auth source code to understand why things don’t work they way they are suppose to (as I did) in the hopes of understanding why things don’t work. Especially if you’re running against a custom server, like I did.

Here are the steps to get it working.

<

ul class=”regular”>

  • First create an ember app using ember-cli

  • Then follow the instructions on ember-simple-auth, how to get this specials build. It’s rather simple but still you need to make sure you don’t have any of the ember-simple-auth / simple-auth packages in your package.json / bower.json and also delete them from your node_modules / bower_components directories. Here is the pull request for it (make sure to read it as it explain how to get setup). https://github.com/simplabs/ember-simple-auth/pull/602
  • Next add a Login page and login controller and a protected page (notice I’m not using the LoginMixin as in many of Ember-Auth examples as it states it’s deprecated and I’ve also chosen not to use the Unauthenticated mixin (just because I’d rather leave that always accessible).

  • edit the login controller file:

    and the protected page route

    then edit the login template (I have some bootstrap styling here)

  • Next create an authenticators directory and an custom.js (authenticates login requests and restores session on refresh)
    Notice I use the same name everywhere (access_token) as once you resolve when authenticating it stores all the info in the session.

  • Then add an initializer for the authenticator

    and the file itself:

  • And now create an authorizers directory and a custom authorizer
    Notice that the info is is accessible via that.get(‘session.authentication’) (not session.secure as in other documentation!)..

  • Then an an initializer for the custom authorizer:

  • Here is a Git Repo with a working example https://github.com/DoryZi/SimpleAuth

    This hopefully will get you up and running! enjoy 🙂

    Choosing an MVC framework: Why I picked Ember & why it was an awesome decision

    When I started working with Originate on a new project, I was given the freedom to choose my own stack. The CEO’s requirements were simple: create an MVP to replace the current process of resource planning that we use today. This meant creating a replacement for their Excel based process using a web app. I told the CEO: Don’t worry, I’ll get something out to you in two-three weeks.
    So there I was, staring at my computer, having absolute freedom to choose my tools. I should’ve been happy.

    I wasn’t. I was stressed. I really wanted to impress them, to use the latest technologies.

    I knew JavaScript very well, and I’d done a few node projects, so I picked that. I didn’t have too much relational data, so I picked Mongo.

    But which front-end frame to use to make a snappy single page app?

    The Decision process:

    I really wanted to pick the best one, but as getting hands-on with a framework can take anywhere from a few days to weeks, I just didn’t have that time to spare.

    So which one should I pick? Angular? Knockout? Backbone? Ember? Meteor? I was in a bit of pickle.

    I’ve used many technologies over the years but I hadn’t really experimented with Angular, Knockout, or Ember. I’ve used Backbone, but it’s just too messy for my taste and not really structured.

    So I started reading about all the technologies.

    The instant ‘No’s:

    • Meteor seemed amazing – really smart people building such a great concept. The idea of front-end and back-end in the same system seems incredible. I actually wrote similar code in one of my past projects to move models from the back-end to the front-end, so I instantly connected with the concept. However, it was still very early days for Meteor and no big production environment was running it at the time, so it was out. After checking on them recently I notice they seem to have made great strides and are doing very well. That’s one tech that I’d keep my eyes on personally.
    • Backbone – I never liked Backbone that much and I’m not a huge Marionette fan either. I just felt it’s too messy for my taste.

    Now there was the tossup between the ones that were left:

    • Angular– the most popular one at the time, with lots of support due to it being a Google product. However, I’d read complaints about it using its own idioms and engineering concepts that one must learn in order to use it. Still, it was the most popular and most commonly used MVC, so I was not going to dismiss it easily.
    • Ember – As I was reading about Ember and doing my background investigation, I leant that out of all the frameworks Ember is the most opinionated and that using it requires following a very particular structure, whereas Angular is more configuration based. I also learnt that Ember is stable and used by quite a few serious companies.

    My decision wasn’t simple, but ultimately I picked Ember for two main reasons:

    • Ember and Angular seemed to me the most stable, and the ones that have some serious customers using them in production.
    • Ember’s convention over configuration. Ember forces you to follow a particular structure, which can be a very good thing as it solves many of the engineering decisions for you. Plus, no one has to be the “code police” that makes sure you put files in particular directories, or call classes with certain names. I liked that, and since I’m not only the engineer but also the project manager and team lead, and needed to put more developers from various time-zones on the project, I thought that would be awesome. Boy, was I right.

    Getting Started With Ember:

    Now, once I’d chosen my tools it was time to start getting some hands on experience in building my MVP.

    Naturally I started on the Ember official tutorial. However their tutorial was based on used Ember-Data. Ember-Data is an ORM like layer that is separate to Ember. It provides the front-end with models, and all related operations and uses dependency injection to inject an object called the “store” into all parts of an Ember app. While the concept is wonderful, at the time I was starting out Ember-Data was separate to Ember, and they had mentioned it would soon make it’s way into the main branch. As such I decided it was too big of a risk to rely on it and developed my own data layer, using my own store. At the time of writing this post it has not made it’s way in, and went through many breaking changes. As such this decision was spot on.

    The first week with Ember was painful. The concept of convention over configuration means there is the Ember way, and the Ember way. Trying to do things in a none-Ember manner just creates frustrations and will get you no where, so the best way is to understand what Ember expects and to do it that way. For example, let’s say you’d like to update certain elements, hide or show etc. While in traditional jQuery you’d just bind to an event, the Ember way would mean you should add an action to some element.

    Ember a couple of months in:

    Once you do understand how Ember works, and what to do, you become super productive and you can crank out code in a fraction of the time it would otherwise take you.

    Ember has a very particular way for all objects in the system to interact. Ember gives you an excellent router, with each route having a very particular point in which it loads the model (Either stand-alone model object, POJO, or the ember data models), a controller object that wraps around your model, and can provide various computed fields, or connect various models together, handle actions and more, and the view that wraps the templates, which uses HTMLBars (ex. Handlebars) templates. Here is an anatomy diagram:

    Ember_Anatomy

    Ember really gives you a framework to do great stuff in a very easy to use manner (once you understand the manner as it’s perceived by Ember); I found myself completing whole pages, and complex UI components, in lighting fast speeds, with it being re-usable in other places later on. Once you’re up to speed with Ember, you’re going to love it (or at least I hope so).

    Ember Decision Epilogue:

    My Ember journey has been very exciting. It started with Ember 1.3 and now I’m Migrating to Ember 1.10 with Ember-cli. I have written a complete data layer for my Ember app, and the application today is 150,000 lines of code and used by a significant company in production. I have gone through performance optimization and made a few interesting observations about Ember:

    • Us geeks tend to love technologies for technological reasons. But the reason I love Ember is from a business perspective – convention over configuration. This means that you can move new engineers on and off a project, and as long as they understand Ember they can start to be productive very quickly.
    • During my work on this project, I assisted the company with implementing a new consulting agreement. Having the customer use Ember made it very easy for me to detect design flaws, and to do isolated re-factoring, rather than a complete throw away!
    • The company had another codebase that everyone suggested was a throw away. The code was indeed poor in many ways, but since it was Ember it was easy to salvage, to re-factor and shift snippets around, to make it usable and re-factorable, saving the company months of work.
    • I have hired a few engineers to work on this project, from multiple places around the world. I was amazed at how fast they have picked up Ember, and even though they are junior, Ember has allowed them to be highly productive from day one.
    • The Ember-Cli build system is an awesome addition that takes care of so many things, there is no other MVC framework that provides it.

    I’m finding more and more companies are using Ember, and I’m the big advocate of convention over configuration along with Ember. True, there is the downside that Ember has forced its users into making constant re-factors to it’s code-base, but I suspect this is still better than Angular 2.0’s throw everything away! Also when using the latest and greatest you should expect things to change, and overall Ember provides developers and product owners with lots of bang for their buck. I think it’s more complete and my #1 choice for CRUD like application, front-end MVC.

    <

    p class=”page-break”>Thanks for reading and I hope you’ve found my experience helpful.
    Cheers
    Dory 🙂