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.

Introducing Sparker: A Codebase Library Management Tool Showcasing AngularJS, Protractor, and Grunt Techniques

Sometimes projects take on a life of their own, and you end up with something unexpected.

I set out to create an template for CRUD-focused single page AngularJS web applications, something I and perhaps my colleagues could use as a foundation for writing new applications.  But under the momentum of self-applied scope creep, what I ended up creating was a Grunt-powered codebase library management tool, with my original template concept as the first codebase of potentially multiple foundational codebases.

After sitting back and looking at what I ended up with, I decided to name the project Sparker for two reasons:

• I didn't want to use terms like "templates", "scaffolds", or "foundations" for the codebases housed in the project (partly because the project encourages creating demo codebases to accompany the "clean slate" template codebases).  So the codebases are organized into "sparks" and Sparker is the tool for managing them.

• I wanted to focus on the inspirational aspect of the project:  that, at worst, the techniques in the sparks and in Sparker could "spark" ideas in other developers for how to approach certain problems.

At the end of the day, I see Sparker as a functional proof-of-concept, something individuals or particular teams can play around with or use in their shops to maintain and build off of their own spark libraries, but not something adopted for widespread use by the developer community.  It's not designed to compete with things like Yeoman or Express.js because, like I said, it didn't come out of a design.  But it was fun to develop, and I think there's value in sharing it.

Some of the things you'll find in Sparker today:

• An example of how to organize Grunt tasks and task options into separate files, and how to execute two different sets of tasks from the same directory/Gruntfile.

• A Grunt build task that determines which resource files to concatenate based on the <link> and <script> tags in your index.html file.

• A technique for executing the login process and running certain sets of Protractor tests based on the user role being tested.

• Convention-based Angular routes for restricting user access based on authentication state/user roles.

• Example of mocking REST calls within a demo Angular application using the ngMockE2E module.

• Examples of Angular unit tests and Protractor tests that utilize page objects.

Sparker is available on GitHub at https://github.com/bcswartz/Sparker.

Using Grunt to Concatenate Only the JavaScript/CSS Files Used in Index.html

One of the most common uses of the Grunt task runner is to build a deployment package out of your development code for your website or web application, and part of that build process is usually a task that concatenates the CSS and JavaScript files into singular (or at least fewer) files for optimal download.

The grunt-contrib-concat Grunt plugin allows you to configure a concatenation task to target individual files or entire directories, like so:

concat: {
            js: {
                src: [ 'dev/jquery/jquery.js', 'dev/angular/services/*.js', 'dev/angular/directives/*.js' ],
                dest: '../build/combined.js',
                options: {
                    separator: ';'
                }
            },
        }

The only drawback is that you have to update the task's "src" property as you add or remove CSS and JavaScript assets from your web application.

As I was playing around with Grunt on a personal project, I came to wonder: could I create a Grunt task or set of tasks that could figure out which files to concatenate based on the <link> and <script> tags in my code?  Here's what I came up with.

My project is a single page web application powered by AngularJS.  It has an index.html file that serves as the "single page" that displays the appropriate view fragment (HTML files stored in a "views" directory) for a given page/route in the application.  None of those view fragments require additional CSS or JavaScript resources, so my index.html page pulls down all of the necessary CSS and JavaScript files.

In my index.html file, I wrapped my blocks of <link> and <script> tags with special HTML "build" comments, a set for my CSS block and a set for my JavaScript block:

<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title>My HTML Page</title>

    <!--build-css-start-->
    <link rel="stylesheet" media="screen" href="assets/app.css" />
    <link rel="stylesheet" media="screen" href="packages/bootstrap/dist/css/bootstrap.css" />
    <!--build-css-end-->

</head>
<body ng-app="demoApp">

    <!--Div where my Angular views will be displayed-->
    <div ng-view></div>

    <!--build-js-start-->
    <script type="text/javascript" src="packages/angular/angular.js" ></script>
    <script type="text/javascript" src="common/app.js" ></script>
    <script type="text/javascript" src="controllers/loginController.js" ></script>
    <script type="text/javascript" src="controllers/logoutController.js" ></script>
    <script type="text/javascript" src="services/authService.js" ></script>
    <script type="text/javascript" src="services/session.js" ></script>
    <!--build-js-end-->

</body>
</html>

I then created a Grunt task powered by the grunt-replace plugin that finds and parses those blocks via regex, extracting and modifying the file path within each "src" and "href" attribute and appending them to arrays stored as Grunt configuration properities. Each block is replaced by a single <link> and <script> tag pointed at the combined CSS and JavaScript file. The overall build task then executes the concat task, which concatenates all of the files in the respective configuration arrays into the combined files.

So when I run the master build task against my original set of development files:

...I end up with a build directory containing the index.html file, the views folders with the view HTML files, and a single CSS and JavaScript file: 

...and the index.html file itself looks like this:

<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title>My HTML Page</title>

    <link rel="stylesheet" media="screen" href="combined.css"/>

</head>
<body ng-app="demoApp">

    <!--Div where my Angular views will be displayed-->
    <div ng-view></div>

    <script type="text/javascript" src="combined.js"></script>

</body>
</html>

Cool, right?

If you want to try it out for yourself, the entire Gruntfile used to power the build task is below, with comments:

Task-based web browsing: Grunt and the grunt-open plugin

Lately I've been playing around with Grunt, which is a JavaScript-based task runner similar to Ant and Gradle. Generally, these tools are used to automate software builds, but they can be utilized in other ways.

While browsing through the large collection of Grunt plugins, I came across one called grunt-open. The grunt-open plugin lets you create a task that opens a URL in your web browser. It looks like it was created with the idea of opening a web page at the end of a chain of Grunt tasks to check the result of a software build. But I thought it might be useful in automating everyday web browsing tasks.

I like to start off my work day with a bit of Internet humor and I have certains sites I visit for that. Dilbert has a new strip every day, while JoyOfTech and XKCD get published every Monday, Wednesday, and Friday, and the XKCD "What-If" article is published once a week, usually by Thursday. Rather than manually opening the appropriate bookmarks for the appropriate day of the week, I figured I'd program a task to take care of opening the appropriate sites.

I won't reinvent the wheel here trying to explain the basics of Grunt: the Grunt "Getting Started" guide does a good job of explaining how to install Grunt and generate the files needed (the package.json and the Gruntfile.js files). Here's what my Gruntfile looks like:

So in the directory where this Gruntfile.js lives, I just have to type "grunt webhumor' in the command, and Grunt will open the appropriate sites. Not a huge timesaver, but kinda cool.