npm@7 brings fundamental changes to npx, which may break your CI process.
npm_config_yes=true npx <package_name>Need to install the following packages:
Ok to proceed? (y)
npm@7 now uses
npm exec as an underline to npx. As a result, your terminal should wait for you to proceed with installation of uninstalled packages. (I’m “standard” as an example, but this applies for all).
Jump to the example below to create a rich HTML document enveloped in an SVG file.
With the new GitHub profile readme feature, rich readme files with personal banners and customised messaging have become real popular. But Markdown, especially GitHub markdown is limited, and us snowflakes want to display our uniqueness in code! We don’t want animated GIFs, what is this, GeoCities? We want a way to incorporate rich, styled HTML in your readme files.
A straightforward and performant way to detect mobile browsers.
The Client Hints proposal is already available in Google Chrome and makes for a very cost-effective way to detect (among other things) mobile devices.
If this feature is not widely supported, should we use it?
I am a performance and observability enthusiast. I am also extremely impatient. This combination of traits drives me to find ways to accelerate any process that takes even a tiny bit longer than absolute necessary.
I want my terminal to perform operations only when they are required. I already measure everything that my bashrc runs. So I picked the scripts from my bashrc who take the longest to run, and turned them into on-demand commands.
Front end application code, more than any other, runs on environments we have little to no control over.
Each browser has its unique set of attributes, feature support, connectivity levels, and more. In modern applications users configure half of the features, A/B tests alter the rest, and user installed browser extensions impact your data transit and code execution. All of this create a highly volatile environment for browser applications code to execute in.
Due to the combination of the execution being remote from our infrastructure and the runtime environment being especially noisy we are inclined to neglect the errors firing form the browser, and sink into a blissful lull of silence from our browser applications. …
I’ve always favoured static websites and recommended them as a first choice solution to others. For personal websites, blogs, and even catalogues — it’s perfect. You create a website with one of the many build systems available out there, throw your files on some CDN and voilà! You’ve got yourself a high performance, high availability website. Often for free.
This is how I pull it off for free, too: I host the source code at Github and create a build pipeline posting the result to Github Pages. After that I set up the domain name at Cloudflare DNS, and throw in their CDN abilities and a couple of cache headers. …
Our front end architecture at Fiverr dictates multiple gateway applications, serving “vertical” experiences. Each vertical creates web pages out of multiple components, from diverse sources, who share one runtime environment — the window, or global scope.
In our organisation, many of these components share extremely similar technology stacks (React, Redux, Lodash…) but we still want to keep them independent, and not reliant on resources outside of their control. Some components may remain as is with no maintenance for a long time, while others are changed frequently — new components and features are built all the time. …
Getter properties are a great way to mask logic and expose what appears as static values. I find it extremely elegant to differentiate functionality from attributes. This logic may hide lazy calculations to be performed only on-demand, or it may hide logic that’s based on object’s, or even application state.
For example, a
User object may have functionality like
user.goOnline(), it should have attributes like
user.isOnline. The check if a user is online should be performed on demand because this status may change from moment of instantiation to the moment of querying.
Automating code documentation tasks @ Fiverr
The popularisation of documentation automation tools like javadoc and jsdoc has re-introduced the standard of commenting guidelines. Keeping a uniform comment style is beneficial for the same reasons code style guides are; it contributes to conformity of code, ease of peer reviews and collaboration and minimises research efforts for unfamiliar parts of the code-base.
Readable code, Well commented code, Documentation.
When we select libraries to use in our own program, we require an accessible documentation. We check for one before (if at all) reviewing their code base. We consider it a necessity of external solutions. As our company grows, we begin to understand this feature is as important for internal projects and packages. Our developers will start using the tools we build without diving into the details. …
An illustrated guide to semantic versioning
A program’s version does not represent the state of the software, but makes a statement about its API for the consumer.
Semantic versioning does not reflect the size of the update, but the changes in the software’s public API.
As part of breaking up monolithic applications at Fiverr, we’re sharing a lot of functionality between programs using various strategies to create independent, interchangeable pieces of software; Ruby Gems, Node Packages, Godeps, and so on. We will address them all as “modules” from here on.
Loose dependencies of software, matching to highest patch (
~) or even highest minor (
^), is very common, and spawning new images in different times could result in different version of modules on different machines. This is desired behaviour. We want the ability to run latest versions of modules with the latest performance improvements and vulnerability fixes, without the need to manually update the code. …