Variables are immutable by default. This makes Rust safer and makes concurrency easier.
Immutable means once a value is bound to that variable, it cannot be changed.
For example:
fn main() {
let x = 5;
/** | |
* General-purpose NodeJS CLI/API wrapping the Stable-Diffusion python scripts. | |
* | |
* Note that this uses an older fork of stable-diffusion | |
* with the 'txt2img.py' script, and that script was modified to | |
* support the --outfile command. | |
*/ | |
var { spawn, exec } = require("child_process"); | |
var path = require("path"); |
import { parseArgs } from "node:util"; | |
const args = parseArgs({ | |
options: { | |
name: { | |
type: "string", | |
}, | |
verbose: { | |
type: "boolean", | |
short: "v", |
HackerNews discussed this with many alternative solutions: https://news.ycombinator.com/item?id=24893615
I already have my own domain name: mydomain.com
. I wanted to be able to run some webapps on my Raspberry Pi 4B running
perpetually at home in headless mode (just needs 5W power and wireless internet). I wanted to be able to access these apps from public Internet. Dynamic DNS wasn't an option because my ISP blocks all incoming traffic. ngrok
would work but the free plan is too restrictive.
I bought a cheap 2GB RAM, 20GB disk VM + a 25GB volume on Hetzner for about 4 EUR/month. Hetzner gave me a static IP for it. I haven't purchased a floating IP yet.
There are at least two valid, signed TLS certificates that are bundled with publicly available Netgear device firmware.
These certificates are trusted by browsers on all platforms, but will surely be added to revocation lists shortly.
The firmware images that contained these certificates along with their private keys were publicly available for download through Netgear's support website, without authentication; thus anyone in the world could have retrieved these keys.
Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I've since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I've written way better modules than this, the internet just hasn't fully caught up.
@broros
otherwise why would he hand over a popular package to a stranger?
If it's not fun anymore, you get literally nothing from maintaining a popular package.
One time, I was working as a dishwasher in a restu
All libraries have subtle rules that you have to follow for them to work well. Often these are implied and undocumented rules that you have to learn as you go. This is an attempt to document the rules of React renders. Ideally a type system could enforce it.
A number of methods in React are assumed to be "pure".
On classes that's the constructor, getDerivedStateFromProps, shouldComponentUpdate and render.
Scope | Description | User repo:read | User repo:write | User repo:admin |
---|---|---|---|---|
(no scope) | Access public information (read-only) | |||
user | Update all user data | |||
user:email | Access user email addresses (read-only) | |||
user:follow | Follow and unfollow users | |||
public_repo | Access public repositories | I | I | |
repo | Full control of private repositories | C | CI | CI |
repo_deployment | Access deployment status |