Node has a built-in debugger.  It requires no extra tooling or purchased IDE.  Try it out.  It's easy.



## Commandline Debugging

Node's debug module is available in the terminal.  Normally you would start your app up with `node app.js`.  If you adjust it slightly, you'll be ready to debug:

```bash
node inspect app.js
```

Once you start the app this way, you'll see a debug prompt instead of your normal terminal prompt:

```bash
< Debugger listening on port 9229.
< ...
break in server.js:1
> 1 (function (exports, require, module, __filename, __dirname) { const http = require('http')
  2
  3 http.createServer((req, res) => {
debug>
```

You're debuggin'!

## Set Breakpoints

Previous to starting the debugger, you can set breakpoints inside your Node app by include `debugger` lines in your source code, like this:

```js
const http = require('http')

http.createServer((req, res) => {
  debugger

// ...
```

Now, if I execute this program using the `node inspect app.js` command, the first time the `debugger` line is hit, execution of the program will pause.  You can also set breakpoints and do other things from inside the debugger.

## Debug Control

To see what options you have inside debug mode, type: `help` in the debugger.

There are a few controls that any interactive debugger will have to help in navigation.  You can use the following:

- `sb` - set breakpoint - interactive equivalent of putting `debugger` in your source code
- `c` - continue - let the program execute until it encounters another breakpoint
- `n` - next - let the program advance to the next instruction
- `s` - step into - step into the next instruction (eg, inside a function call)
- `o` - step out - continue execution until the stack is popped

## Inspect Local Variables

One of the coolest things about interactive debugging is the ability to see what the values of variables are as the program runs.  To do this in the Node debugger, set a breakpoint at the place where you'd like to stop and look around, then let the program run.  Once you're paused at the right point, type `repl` into the debugger.  You've now entered a new repl mode.  Here, you can type the variable names of anything within scope and see the values printed to the screen.

For the source code above, we could pause and investigate:

```
break in server.js:4
  2
  3 http.createServer((req, res) => {
> 4   debugger
  5
debug> repl
Press Ctrl + C to leave debug repl
> req
{ _readableState: ReadableState,
  readable: true,
  domain: null,
  _events: EventHandlers,
  _eventsCount: 0,
  ... }
> req.url
'/'
```

To exit, press `Ctrl-c` once.

It's not a particularly beautiful UI, but it's keyboard accessible!  I like it because it's always available to use -- it's built-in tooling.  

What other ways do you do your debugging in Node?

Debug your Node.js app without having to buy or install other tools.

Debug Node with Built-in Tools

There aren't many functions in the standard lib for elm that create side effects.  Elm's `Debug.log` is one of those exceptions.  It logs to the console.  Here's how it's setup to make console logging whilst piping easier that patting your head whilst rubbing your tummy.



## The signature of Debug.log

The coolest thing about `Debug.log` is its type signature:

```
String -> a -> a
```

The first parameter is `String` and traditionally takes some label to identify what you're printing in the log.

The 2nd parameter is `a`, meaning it can be generically anything.   It's worth noticing that `a` as the 2nd parameter is required.  This means you'll have to print a value there whether you want to or not.  Otherwise, you won't be fully applying the `Debug.log` function.

The _coolest_ part is that `a` is also returned.  This helps with piping because you can just insert `Debug.log` in your pipe chain.

## Logging in Elm

Here's a little example.  In this `encode` function there are several pipes.  There are two helper functions, `keyIndex` and `keyValue` that return values that I'd like to investigate.  After each of those values are returned in the pipe chain, a `Debug.log` is inserted next in the chain with the associated "indexes" or "values" label for log clarity.

```haskell
encode : String -> String
encode phrase =
    phrase
        |> String.toLower
        |> String.split ""
        |> List.map (\l -> l |> keyIndex)
        |> Debug.log "indexes"
        |> List.map (\i -> -1 * i)
        |> List.map keyValue
        |> Debug.log "values"
        |> String.join ""
```

The resulting log for a test run of this code is:

```
indexes: [24,4,18]
values: ["b","v","h"]
```

This can be super nice when you're not in a live debug-ready environment.  What are some other ways to gain insight into your code for debugging that you use?

How to print to the console when piping data in Elm

Debug.log in Elm Pipes

One of the worst things to debug can be something that works just fine in your local development environment but does not work in a deployed environment.  If you deploy to Tomcat, you can debug it remotely.  If you use IntelliJ IDEA, you can do it with style.



IntelliJ makes it easy.  First, you want to click the runnable configurations dropdown and select "Edit Configurations":

![image](https://lh3.googleusercontent.com/_mA-9kCcx0bs/TaXdzFFhpxI/AAAAAAAAABM/6FoV9E3FpII/s800/ConfigDropdown.png)

Once in the "Edit Configurations" dialog, click the "+" Plus icon to create a new configuration.  Select "Remote":

![image](https://lh4.googleusercontent.com/_mA-9kCcx0bs/TaXdzLv6GAI/AAAAAAAAABQ/3giI8x9pZc0/s640/SelectRemote.png)

This dialog is the last, and you will need to configure your connection:

* Transport: Socket
* Debugger: Attach
* Host: Either IP or hostname of remote server
* Port: Must match debug port opened on remote Tomcat (address arg below)

![image](https://lh3.googleusercontent.com/_mA-9kCcx0bs/TaXdzPI1ovI/AAAAAAAAABU/EU-fflxWQ1g/s800/RemoteDebug.png)

As is explained to you on the window, you need to be able to add JVM arguments to the remote JVM.  By now, let us hope that we're all using a JDK more recent than JDK 1.3. :)  In that case, you'll need:

```java
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7007
```

To get those args on the server might require different mechanisms by default.  My environment's deploy is automated to put the args on the JAVA_OPTS variable in:

```bash
$CATALINA_HOME/conf/Catalina/localhost/tcat-env.conf
```

But if your deployment doesn't apply JVM properties for your app, you can put them in:

```bash
$CATALINA_HOME/bin/setenv.sh
```

Like so:

```bash
export JAVA_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7007"
```

Finally, restart the remote server, and your debugging port will be open.  Start your remote connection in IntelliJ and set a break point.  Exercise your deployed app so your code will be executed, and let the good times roll!

One of the worst things to debug can be something that works just fine in your local development environment but does not work in a deployed environment.  I