npm@7 brings fundamental changes to npx, which may break your CI process.
npm_config_yes=true npx <package_name>
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).
npx standard -- --fix
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…
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…
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…