Lewiscowles1986

import json
import base64
import os
import pathlib
from urllib.parse import urlparse

# list of supported image mime-types
# Special thanks to https://gist.github.com/FurloSK/0477e01024f701db42341fc3223a5d8c
# Special mention, and thanks to MDN
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types 

Lewiscowles1986

/**
  * Generic Container, which can contain a single item, and the next item as a function
  */
function cons(value, next) {
  return function wrap(wrapper) { return wrapper(value, next) };
};

/**
  * Get value of item by calling unwrap function, taking value
  */

Lewiscowles1986

Git Rename Script

This is a fork of https://gist.github.com/lttlrck/9628955 to make the renaming of branches simpler.

Usage

1. Ensure the script is executable.
2. git-rename.sh [oldbranchname] newbranchname [upstreamname]

conventions

Lewiscowles1986

var array = [];

function closest(array,num){
    var i=0;
    var minDiff=1000;
    var ans;
    for(i in array){
         var m=Math.abs(num-array[i]);
         if(m<minDiff){ 
                minDiff=m; 

Lewiscowles1986

Why do we change the cluster size when formatting USB drives for storing GameCube games?

For loading GC Games with USBLoaderGX via DiosMios/Nintendont, format your usb drive's primary partition as FAT32 with 32KB clusters (also known as blocks). This increases performance by reducing the NUMBER of transactions required to perform a read/write operation at the expense of the (very negligible) LENGTH of time to complete a transaction; since it's reading more data per transaction.

I'm not certain, since I can't find a GameCube disk specification, but I don't think the 32KB cluster size is an attempt to imitate the on-disk storage format of retail GameCube discs; which may or may not be 32KB. Retail Wii discs however, actually DO use 32KB clusters. As far as I can tell, 32KB is simply the highest density of bytes per cluster that is supported by FAT32 and of course, by extension, Wii homebrew storage libraries.

If you're concerned about storage efficiency

Lewiscowles1986

Problem #1

God algorithms, God solutions etc, God methods etc often add unnesecarry complexity with very little benefit. There is no God, get over that...

Shipow: Even if I don't support religions, I'm pretty ok with the idea of an omnipotent mind as it stay in the context of narration. And I guess that even someone very trustfull will never imagine God as web/app designer ;)

Problem #2

Lack of evidence for decisions... I could understand iteratively improving a design because nobody gets "sign up", "sign in"... if it EVER happened! Jeff even admits there is little evidence against "sign up" / "sign in", and the link seems to be to some stackoverflow o similar upvoting thread (thus promoting over-simplification, lack of engagement and pack mentality common on such services)... The truth is "sign up", "sign in" is not confusing, unless you do not speak english, then you have bigger problems than "sign up", "sign in"... You know like using any of the interface...