| /* | |
| Instagram API: view and backup direct messages from a web browser | |
| Since April 2020, Instagram has a web version to send and read direct messages so my Instagram scripts are not longer needed and I would not recommend using them unless you really need it, to avoid being banned | |
| (never happened to me with Instagram but WhatsApp is owned by Facebook also and they did it to users registering from an unofficial app like yowsup: https://github.com/tgalal/yowsup/commit/88b8ad9581fa22dac330ee3a05fec4e485dfa634#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5) | |
| 1) Log in on Instagram web version and go to your profile page | |
| (the home page will not work because it loads data when scrolling down and the direct messages will be displayed at the bottom of the page) | |
| 2) Modify HTTP headers with a browser addon like Header Editor (https://addons.mozilla.org/en-US/firefox/addon/header-editor/) |
| /*! NOTE: These are just recommended default global styles, edit as required */ | |
| @import ('Import reset stylesheet here, (I recommend modern-normalize) or even better, import the reset stylesheet in the HTML as the first imported stylesheet'); | |
| ::selection { /* Optional */ | |
| /* It can be really hard to read highlighted text with a text-shadow, it should be removed when selected */ | |
| text-shadow: none; | |
| /* NOTE: Using this means the color and background-color are set to transparent for selected text... */ | |
| /* So you can customise your styles below */ |
This document was created back in 2020 and might not be actual nowadays. It is not supported anymore, so use thise information at your own risk.
wsl --set-default-version 2 in windows command line, so that all future WSL machine will use WSL2.
Firstly, Create React App is good. But it's a very rigid CLI, primarily designed for projects that require very little to no configuration. This makes it great for beginners and simple projects but unfortunately, this means that it's pretty non-extensible. Despite the involvement from big names and a ton of great devs, it has left me wanting a much better developer experience with a lot more polish when it comes to hot reloading, babel configuration, webpack configuration, etc. It's definitely simple and good, but not amazing.
Now, compare that experience to Next.js which for starters has a much larger team behind it provided by a world-class company (Vercel) who are all financially dedicated to making it the best DX you could imagine to build any React application. Next.js is the 💣-diggity. It has amazing docs, great support, can grow with your requirements into SSR or static site generation, etc.
| import React, { useEffect, useRef } from "react"; | |
| import Plyr from "plyr"; | |
| import "plyr/dist/plyr.css"; | |
| import Hls from "hls.js"; | |
| import "./player.css"; | |
| export default function Player({ isLive = false, playbackURL }) { | |
| const videoRef = useRef(null); | |
| const playerRef = useRef(null); | |
| // const previewSrc = `https://image.mux.com/${playbackId}/storyboard.png`; |
Note: I have moved this list to a proper repository. I'll leave this gist up, but it won't be updated. To submit an idea, open a PR on the repo.
Note that I have not tried all of these personally, and cannot and do not vouch for all of the tools listed here. In most cases, the descriptions here are copied directly from their code repos. Some may have been abandoned. Investigate before installing/using.
The ones I use regularly include: bat, dust, fd, fend, hyperfine, miniserve, ripgrep, just, cargo-audit and cargo-wipe.
| /* Using a JavaScript proxy for a super low code REST client */ | |
| // via https://dev.to/dipsaus9/javascript-lets-create-aproxy-19hg | |
| // also see https://towardsdatascience.com/why-to-use-javascript-proxy-5cdc69d943e3 | |
| // also see https://github.com/fastify/manifetch | |
| // also see https://github.com/flash-oss/allserver | |
| // and https://gist.github.com/v1vendi/75d5e5dad7a2d1ef3fcb48234e4528cb | |
| const createApi = (url) => { | |
| return new Proxy({}, { | |
| get(target, key) { |
Personally I've never liked how tools like Remix or NextJS have mapped a nested file system to routes. Simple things like "I want to put this component in its own file" become annoying tasks.
I've always been a fan of "flatter" file systems, my files often look like this:
/App/
| /* Ultra lightweight Github REST Client */ | |
| // original inspiration via https://gist.github.com/v1vendi/75d5e5dad7a2d1ef3fcb48234e4528cb | |
| const token = 'github-token-here' | |
| const githubClient = generateAPI('https://api.github.com', { | |
| headers: { | |
| 'User-Agent': 'xyz', | |
| 'Authorization': `bearer ${token}` | |
| } | |
| }) |
In the olden days, HTML was prepared by the server, and JavaScript was little more than a garnish, considered by some to have a soapy taste.
After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun.
But all was not right in the world. Somewhere along the way, we had slipped. Our pages went uncrawled by Bing, time to first meaningful paint grew faster than npm, and it became clear: something must be done.
And so it was decided that the applications first forged for the browser would also run on the server. We would render our HTML using the same logic on the server and the browser, and reap the advantages of both worlds. In a confusing series of events a name for this approach was agreed upon: Server-side rendering. What could go wrong?
In dark rooms, in hushed tones, we speak of colours.