redbar0n

// The following is an example from the language Kitten, but generalizes to other languages.
// It should be useful for language design and choosing naming conventions for variables and functions.

// TL;DR: camelCase is most readable/discernable when used in context, as per this simple example extract:

`n bottles-of-beer on-the-wall` // kebab-case
`n bottles_of_beer on_the_wall` // snake_case
`n bottlesOfBeer onTheWall`     // camelCase

// To more fully see the effect yourself, in context, do the following:

redbar0n

// "Mutable borrows" is where the Rust ownership/borrowing model became too complex for it's own good...


// A function that mutates a value, but does not return the value. So it only performs an effect, often called a side-effect.
fn mutate_value(s: &mut String) {
    s.push_str(", world"); // we can mutate the borrowed value. In Rust, push_str returns the unit value, aka. void, so the function does not return the string.
}

fn main() {
    let mut hello = String::from("hello");

redbar0n

What if you could have vertically sliced MVC-widgets, that looked something like this?

Using React and XState.

//  A vertically sliced "MVC-widget"

//  VIEW:

export default function Users() {

redbar0n

a thread where we can discuss some crazy routing ideas a bit out in the open branching out from the previous discussion on filesystem routes over at: https://discord.com/channels/815937377888632913/1014946079965454366

so, first of all, it seems there is a close alignment between how vite-plugin-ssr and router5 handles routing:

• vps: (view === 'overview') @ https://vite-plugin-ssr.com/layouts#nested-layouts
• router5 (route === 'dashboard') @ https://youtu.be/hblXdstrAg0?t=197 maybe with the small exception that router5 has the explicit perspective of routes as app state whereas I didn't get the impression from vps that it's viewed as such (even though it technically is still state).

I recommend watching this router5 talk from 2:45 - 7:50 https://youtu.be/hblXdstrAg0?t=165 since it's really key to how I think about view / state separation, and I think of routing as a state separate from the view. (After all, and especially in a client-rendered app, what page it is showing is certainly a major part

redbar0n

;; The following example is: 
  "The program that prints the first 25 integers squared."

;; PS: The example was inspired by this article by C. Martin aka. "Uncle Bob": https://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure.html

;; Some necessary background documentation first:
;;
;; range - "Returns a lazy seq of nums from start (inclusive) to end
;;   (exclusive), by step, where start defaults to 0, step to 1, and end to
;;   infinity." https://clojuredocs.org/clojure.core/range

redbar0n

import { useStore } from "../store";
import ArticlePreview from "./ArticlePreview";

export default ArticleList = props => {
  const [{ token }, { unmakeFavorite, makeFavorite }] = useStore(),
    handleClickFavorite = (article, e) => {
      e.preventDefault();
      article.favorited ? unmakeFavorite(slug) : makeFavorite(slug);
    },
    handlePage = (v, e) => {

redbar0n

import { useStore } from "../store";
import ArticlePreview from "./ArticlePreview";

export default props => {
  const [{ token }, { unmakeFavorite, makeFavorite }] = useStore(),
    handleClickFavorite = (article, e) => {
      e.preventDefault();
      article.favorited ? unmakeFavorite(slug) : makeFavorite(slug);
    },
    handlePage = (v, e) => {

redbar0n

// --- 
// The following code is from: https://github.com/dwyl/learn-tdd/blob/master/change.js
// Note that:
// - The JsDoc mentioning the params to getChange became out of sync after it apparently was refactored. Therefore, avoid such comments.
// - There are quite a few comments merely detailing what can be self-evidently / obviously read from the code itself. They don't reveal anything more (like intent/purpose) than the code itself, and just add noise, and can become out of sync, so avoid those.

var coins = [200, 100, 50, 20, 10, 5, 2, 1];
/**
 * getChange accepts two parameters (totalPayable and cashPaid) and calculates
 * the change in "coins" that needs to be returned.

redbar0n

# Will take as input a time in seconds (which is typically a result after subtracting two Time objects),
# and return the result in HH:MM:SS, but instead of resetting HH to 00 when the time exceeds a 24 hour period,
# it will increase it indefinitely. For other variations, see discussion here: https://gist.github.com/shunchu/3175001
def formatted_duration(total_seconds)
  total_seconds = total_seconds.round # to avoid fractional seconds to potentially compound and mess up seconds, minutes and hours
  hours = total_seconds / (60*60)
  minutes = (total_seconds / 60) % 60  # the modulo operator (%) gives the remainder when leftside is divided by rightside
  seconds = total_seconds % 60
  [hours, minutes, seconds].map do |t|
    # Right justify and pad with 0 until length is 2. 

redbar0n

Here's a crazy idea. Take the following simple example (in javascript):

    var m = [[1], [2], [3]];
    // ... a lot of code in between, perhaps m was passed through
    // several functions without TypeScript type declarations, so you might mistakenly
    // think m is a simple array like [1, 2, 3] at this point...
    var m2 = [];
    m.forEach(x => {
 m2.push(x); //# [[number], [number], ...] will be the form of m2 here