ncline-screenshots: New ncline Module For Managing Screenshot Files

When I'm observing a multi-step process during a debugging exercise, I often take screenshots at each breakpoint.  It gives me a record of the data values and behavior at particular points in the process, sometimes recording something I didn't realize I needed to pay attention to until after the fact.

On Windows computers, I use the freeware application Greenshot to take my screenshots.  One of the features of Greenshot is that it lets you use date and time parameters in the filename settngs, so I have it set to save each screenshot with a name and folder location based on date and time.  If I were to take a screenshot on June 16, 2016 at 3:30pm, I'd end up with a file named "screenshot-15-30-00.png" in a "2016-06-16" subdirectory of my root screenshot directory.

I recently started using a Mac laptop as my primary personal laptop, and I was disappointed to learn that there is no Greenshot version for Macintosh.  OS X's native screenshot implementation is less than ideal:  it saves the screenshot file on the desktop and provides no control over the naming of the screenshot (though it does include the timestamp in the name).  I looked at what Mac-compatible screenshot programs were out there and found many of them had a workflow geared towards manipulating the screenshot right after taking it.  I just wanted to take the screenshot, move on to the next one, and review all of them later.

So I decided to solve my Mac screenshot problem myself.  First, I followed the instructions for changing the location where OS X saves the screenshots (it's not a setting you can change in the OS X UI anywhere) so the files would be created somewhere other than the desktop.  Then I wrote ncline-screenshots, a new, separately-downloaded command module for my Node-powered ncline project.  It uses the chokidar npm module, an enhancement on the native Node file watcher library, to watch the directory where the screenshot files are created.  When a new file is found in that directory, it gets processed by a series of processing rules that rename and/or move the file.

The command module creates the watcher task, provides private functions that implement the processing rules, and includes a few commands for changing configuration settings and rule processing behavior.  Creating additional rules is simply a matter of writing additional functions that manipulate the file and pass on the results of the change to the next rule in the sequence.

Even though it was written to solve a Mac-specific gap in my workflow, ncline-screenshots works on Windows systems as well.

Announcing ncline: a Node Program/Platform for Executing JavaScript Functions from a Command Line

I'm pleased to announce the release of my new open-source project, ncline. ncline stands for "Node Command Line", and it's a platform for writing Node-powered JavaScript functions ("commands") that can be executed from a command line interface.

When you launch ncline, it loops through the collections of module folders within the master "cmdModules" folder and adds any functions exported under the "commands" property to a catalog of executable commands. The user can then execute any of those commands from the ncline command prompt by typing the command name followed by any required or optional arguments. Arguments can be provided in positional order or as a set of "name:value" pairs enclosed in brackets.



Ncline is designed to allow developers to customize it to their needs. Writing a command function that ncline can execute is no different from writing a regular JavaScript command, so experts and beginners alike can create basic commands fairly easily. The main ncline functions take care of registering the commands and managing the passage of arguments from the command line to the function. ncline provides generic Levitra online library functions for parsing arguments and for generating feedback to the ncline console (warnings, error messages, etc.) that can be leveraged within commands.



ncline also provides conventions for the creation and storage of user-generated command data that persists between sessions as private JSON data and for adding command documentation via a JSON file.

Out of the box, ncline provides commands for:

• Adding, changing, and deleting aliases for individual or multiple filepaths, and for setting the current target and source filepaths for filepath-related functions.

• Opening one or more file explorer windows based on the provided alias name.

• Opening one or more terminal windows based on the provided alias name.

• Executing a Grunt command in the filepath represented by the provided alias name.

• Creating or opening a .txt file in Notepad based on the provided alias name (Windows only).

• Adding, changing, and deleting aliases for Windows batch files (Windows only).

• Executing the Windows batch file associated with the specified batch alias name (Windows only).

• Adding, changing, and deleting aliases for opening websites from ncline in the specified browser (useful for opening multiples sites in one browser or the same site in different browsers quickly).

Further information can be found on the GitHub site for ncline at https://github.com/bcswartz/ncline.

Instructing Proxyquire To Ignore Nested Requires

When writing unit tests for Node.js applications, you can use the proxyquire npm module to override the modules pulled in by the file under test using require(), replacing them with your own.  So say your file containing the methods you want to test pulls in two other modules using require:

//underTest.js
var moduleA = require( './moduleA' );
var master = require( '../../core/master' );
...
module.exports = {
  runFoo: function() { return moduleA.outputResult() }
};

...in your unit test, you can use a stub library like Sinon in conjunction with proxyquire to instantiate the file under test but with the stubs used in place of the normal modules:

//underTest.spec.js
var sinon = require( 'sinon' );
var proxyquire = require( 'proxyquire' );

describe( 'underTest.js functions', function() {
  var stubModuleA, stubMaster;

  before( function() {

    var stubModuleA = sinon.stub();
    var stubMaster = sinon.stub();

    underTest = proxyquire( './underTest', {
      './moduleA': stubModuleA,
      '../../core/master': stubMaster
    });
  
  });
  
});

...and then you can spy on and define the function behavior of the stubbed objects for your tests.

When I first did this, I ran into problems because one of the modules I was replacing (say moduleA) itself pulled in a module of its own:

//moduleA.js
var main = require( '../../main' );

...and in that main module were functions that executed as soon as the file was loaded via require(), and the execution of those functions caused the before() block of my test file to bomb.

After some research, I discovered that one solution was to use proxyquire to override the require() call in moduleA, and instruct proxyquire to essentially ignore the require by not calling through to it.

//underTest.spec.js (revised)
var sinon = require( 'sinon' );
var proxyquire = require( 'proxyquire' );

describe( 'underTest.js functions', function() {
  var stubModuleA, stubMaster;

  before( function() {

    var stubModuleA = proxyquire( './moduleA', {
      '../../main': { '@noCallThru': true }
    });
    
    var stubMaster = sinon.stub();

    underTest = proxyquire( './underTest', {
      './moduleA': stubModuleA,
      '../../core/master': stubMaster
    });
  
  });
  
});