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.
Here's the technical overview from the io.js Medium post:
Kris Reeves and Trevor Norris pinpointed a bug in V8 in the way it decodes UTF strings. This impacts Node at the Buffer to UTF8 String conversion and can cause a process to crash. The security concern comes from the fact that a lot of data from outside of an application is delivered to Node via this mechanism which means that users can potentially deliver specially crafted input data that can cause an application to crash when it goes through this path. We know that most networking and filesystem operations are impacted as would be many user-land uses of Buffer to UTF8 String conversion. We know that HTTP(S) header parsing is not vulnerable because Node does not convert this data as UTF8. This is a small consolation because it restricts the way HTTP(S) can be exploited but there is more to HTTP(S) than header parsing obviously. We also have no information yet on how the various TLS terminators and forward-proxies in use may potentially mitigate against the form of data required for this exploit.
Node 0.10 is not affected. Thanks to Rod Vagg for letting me know about this!
If you use npm private packages then there's a very serious data leak that you should be aware of. Metadata for private packages was accidentally made available from the public replication endpoint.
I've included the full announcement below:
We need to notify you of a serious security incident that was discovered today, July 2nd.
Starting on June 26th, scoped package metadata was available via the public replication endpoint from npm. This means that third parties were aware of metadata about scoped packages, including private packages. This metadata was limited to:
versions and version publication dates
It's important to make clear that this does not include the packages themselves: package contents and source code were never available. User information such as passwords and billing information was not part of the information that leaked.
If your package metadata contained sensitive information, please take mitigation steps immediately. Because this information replicated, we will be making a public disclosure of the leak. However, to give you time to react (we are aware that it is a holiday weekend in the US) we will be holding off on the public announcement until Monday, July 6th.
We apologize wholeheartedly for this mistake and have taken steps to prevent this error. We are conducting a thorough review of our processes to avoid both this specific problem and any similar errors in the future.
Thank you for your continued support of npm. If you have any further questions or concerns please reach out to firstname.lastname@example.org.
Check your readme files and package names to ensure nothing sensitive has been leaked. This is unfortunate, but npm is handling it promptly and professionally. With any service you rely on for commercial work, like GitHub, Bitbucket, npm, and CDNs, you should review what you publish before it's stored on remote systems.
Sindre Sorhus is the author of over 600 modules on npm. He recently wrote a long GitHub comment about why we should use small modules, and I asked for permission to reproduce the text on DailyJS. Read on to learn about why small modules make programming easier, and why it's not really about lines of code.
People get way too easily caught up in the LOC (Lines Of Code) argument. LOC is pretty much irrelevant. It doesn't matter if the module is one line or hundreds. It's all about containing complexity. Think of node modules as lego blocks. You don't necessarily care about the details of how it's made. All you need to know is how to use the lego blocks to build your lego castle.
By making small focused modules you can easily build large complex systems without having to know every single detail of how everything works. Our short term memory is finite. Other people can reuse these modules and when a module is improved or a bug is fixed, every consumer benefits.
Imagine if PC manufacturers all made their own CPUs. Most would do it badly. The computer would be more expensive and we would have slower innovation. Instead most use Intel, ARM, etc.
Small modules are made possible by how npm works. The beauty of being able to use nested dependencies means I don't have to care what dependencies a dependency I use have. That's powerful.
Some years ago -- before Node.js and npm -- I had a large database of code snippets. I used to copy-paste these snippets into projects when I needed them. They were small utilities that sometimes came in handy. npm is now my snippet database. Why copy-paste when you can require? Packaging and naming a module also has the benefit of having a clear intent. Furthermore, fixing a bug in a snippet means updating one module instead of manually fixing all the instances where the snippet is used.
As an example, I have a module called negative-zero. Its job is to tell me if a number is -0. Normally you wouldn't have to care about this, but I've found it useful. How do you figure out if a number is -0? Well, that's easy: x === 0 && 1 / x === -Infinity. Or is it? Do you really want to have to know how and why this works? I would rather require negative-zero and focus on other things.
Another example. Chalk is one of the most popular modules on npm. What you might not realize is that it's actually a collection of modules. It depends on a module for detecting if the terminal supports color, for getting the ansi escape codes, etc. All of this could have been just embedded in the main module, and it probably is in many cases. But that would mean anyone else wanting to create an alternative terminal string styling module would have to reinvent the wheel. By having supporting modules, people can easily benefit from Chalk and maybe even help improve Chalk by improving one of the dependencies.
Yet another example. I have a module called user-home which gets the user's home directory. You might think it would be simpler to just do process.platform === 'win32' ? process.env.USERPROFILE : process.env.HOME. And most people just that. But first, why force everyone to know how to get the home directory? Why not use a "lego block"? What you also might not realize is that this check is incomplete. On Windows you should also check process.env.HOMEDRIVE + process.env.HOMEPATH and you might also want to do additional checks. Lego blocks.
Do you make your own shoes? No, you buy them in a store. Most don't care how the shoe is made. Just how good it fits.
I want programming to be easier. Making it easier to build durable systems. And the way forward in my point of view is definitely not reinventing everything and everyone making the same stupid mistakes over and over.
Written by Sindre Sorhus, reproduced with permission and republished with edits by the DailyJS authors.