NewSprint (GitHub: rodati/newsprint, License: MIT, npm: newsprint) from Rodati is a command-line Node tool for generating a mobile-friendly email based on Trello cards.
I use Trello for project management, and for a while I archived each week (or sprint) into a list so it was easy for management to see what we've completed recently. This process could be automated with NewSprint, by sending an email with card summaries. The emails look very nice, and I like the fact it uses a command-line tool with JSON files for configuration.
With Spectacle you can write slides with JSX. It supports tags like <Deck>, <Slide>, and there are even layout tags for making text appear in the right place without too much fiddling about with CSS. Here's a very basic example of a slide:
It even supports a presenter view, so you can see the next side and the current time. If you're currently addicted to React then this will probably be preferable to messing around in Keynote/PowerPoint/etc.
Mesh (GitHub: mojo-js/mesh.js, License: MIT, npm: mesh) by Craig Condon is a data synchronisation library that caters for server-side and client-side requirements. The author has pitched it as the "underscore of data", meaning it's a highly focused library that you can drop in to existing applications.
It covers both storage and transit. For example, in the browser you could use localStorage, and Socket.IO to broadcast data to other clients. The supported databases are in-memory, localStorage, and MongoDB. If you want to use Mesh with a database that isn't supported, then you can write a new database adapter based on a CRUD API.
The API is based on CRUD operations and Node-like streams. Let's say you want to store data to local storage:
var mesh = require('mesh');
var storage = require('mesh-local-storage');
var bus = storage();
You can now insert data (persisted to local storage) like this:
The main motivation behind this library is to make data sources interoperable with one another, so I'd like to see what this looks like with a React application in the client, and a MongoDB-based REST API on the server.
io.js 2.3.1 was also released this week. One of the big changes in this release is performance improvements for require:
module: The number of syscalls made during a require() have been significantly reduced again (see #1801 from v2.2.0 for previous work), which should lead to a performance improvement (Pierre Inglebert) #1920.
This sounds very nice for large projects.
NodeDay is a conference being held in London on 26th June (this Friday), for free! Speakers include Lin Clark, who writes npm's excellent blog posts, and programmers from the BBC, Red Hat, and other companies that are using Node for interesting things.
nodeday is a Node.js conference by the enterprise, for the enterprise. Now in its second year, this one-day industry conference brings together people from companies that have adopted or are planning to adopt Node.js, and focuses on the issues that these companies face. It gives participants a forum to discuss and share their experiences with Node.js, share advice, tips and tricks, and drive forward both the technology and the community.
I apologise for not writing about this sooner, but I only just found out about it! If you have conferences you want me to cover on DailyJS, you can use the contact forms or message me on Twitter (@alex_young).
I really wanted to go to NodeDay but I can't make it this time.
This is a framework for building data layers that map directly to REST APIs. It's a bit like ORM for HTTP. It comes with base classes for routing, REST resources, models, and validation, and the models can serialise data to RethinkDB. To talk to other databases a new base model class would have to be written.
To me this looks like C# without the extra syntax for strong typing. The validation API looks similar to what you might have seen before with modules like Mongoose.
I like the idea of object-resource mapping at the HTTP level. In Node web apps we seem to spend a lot of time thinking about HTTP servers and APIs, so this feels like it could reduce the amount of boilerplate required to interface from that step to the database layer.
Are you a fan of Node's crypto API? Like the other core modules, it tries to strike a balance between providing the bare minimum and just enough abstraction. You shouldn't need to be a cryptography expert to use it, but at the same time it doesn't want to be too limiting. However, whenever I need to quickly md5 or sha1 something, it feels like too much work. I also find it a little difficult to explain to beginners.
Sindre Sorhus has written a module called hasha (GitHub: sindresorhus/hasha, License: MIT, npm: hasha). It provides a more friendly wrapper around crypto that uses sensible defaults. To get a hex encoding of a string, you can just use hasha(new Buffer('unicorn')). If you want to hash a file, then use hasha.fromFile with a callback. You can supply the desired hashing algorithm as well:
Rozu (GitHub: avoidwork/rozu, License: BSD-3-Clause, npm: rozu) by Jason Mulligan is a webhook API server that uses io.js or Node, MongoDB, and Redis. MongoDB is used for persistence, and the Redis pub/sub API is used for inbound events.
It's built with tenso for the REST API, and keigai for data storage with MongoDB. It can both send and receive webhook events. To send events, you make a POST to /send with a logged in user, and to make it receive a JSON payload you use /receive. Receiving events uses a token, so it's pretty easy to use it with sites like GitHub.
Once you've installed it you can create an account by making a GET request to /register. If you visit / (whether signed in or not) you'll get a list of API methods.
The problem is that we use several different packages to build our application, taking full advantage of the awesome NPM private modules that were recently released. The problem was that it has become increasingly hard to keep track of what environmental variables were required to make the project function, or were just generally available, because they were all being accessed at different levels of the applications dependency tree.
With environmentalist, you define a JSON file that specifies each environmental variable:
"description": "Used to compute the password hash of users",
Because you can include a description it's already useful because in my experience most people export (or heroku config:set) and forget about it later. I also like the fact you can set a default value and the required state. The name is the only required field, so if the values are obvious and self-documenting then you can keep things simple.
When you run environmentalist in the command-line, you'll see a table that shows all of the environmental variables in the current package and its dependencies, which means you can construct projects from submodules with environmentalist JSON files and it'll dig them all out.
If you've created a Node application but you want to support plugins, what to do you? package.js (GitHub: s-a/package.js, License: MIT and GPL, npm: package.js) by Stephan Ahlf is designed to allow you to open up your project to plugin developers through npm or other package managers.
It allows you to load modules from a set of paths, and then ensure each module has a property (expectedPackageIdentifier) in its package.json. It's a small module with unit tests and an example in the readme.