Dumindu Madunuwan dumindu

PostgreSQL Type	PostgreSQL Size	Description	Range	Diesel Type	Rust Type
Nullable Types		nullable		`Nullable```

Looking into the `Future`

futures-rs is the library which will hopefully become a shared foundation for everything async in Rust. However it's already become renowned for having a steep learning curve, even for experienced Rustaceans.

I think one of the best ways to get comfortable with using a library is to look at how it works internally: often API design can seem bizarre or impenetrable and it's only when you put yourself in the shoes of the library author that you can really understand why it was designed that way.

In this post I'll try to put down on "paper" my understanding of how futures work and I'll aim to do it in a visual way. I'm going to assume you're already somewhat familiar with Rust and why futures are a useful tool to have at one's disposal.

For most of this post I'll be talking about how things work today (as of September 2017). At the end I'll touch on what's being proposed next and also make a case for some of the changes I'd like to see.

If you're interested in learning more ab

Go (Golang) Standard Library Interfaces (Selected)

This is not an exhaustive list of all interfaces in Go's standard library. I only list those I think are important. Interfaces defined in frequently used packages (like io, fmt) are included. Interfaces that have significant importance are also included.

All of the following information is based on go version go1.8.3 darwin/amd64.

System Design Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

Basic Steps

Clarify and agree on the scope of the system

User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?

Default

Powerlevel10k

Frontend Development

Attention: the list was moved to

https://github.com/dypsilon/frontend-dev-bookmarks

This page is not maintained anymore, please update your bookmarks.

I'm having trouble understanding the benefit of require.js. Can you help me out? I imagine other developers have a similar interest.

From Require.js - Why AMD:

The AMD format comes from wanting a module format that was better than today's "write a bunch of script tags with implicit dependencies that you have to manually order"

I don't quite understand why this methodology is so bad. The difficult part is that you have to manually order dependencies. But the benefit is that you don't have an additional layer of abstraction.

	.tab-background {
	border-radius: 6px 6px 0 0 !important;
	margin-block: 0 !important;
	outline: none !important;
	}

	.tab-background:is([selected], [multiselected]) {
	box-shadow: none !important;
	}

	package main

	import (
	"context"
	"flag"
	"fmt"
	"log"
	"net/http"
	"os"
	"os/signal"

	/* x is the <input/> element
	type is the type you want to change it to.
	jQuery is required and assumed to be the "$" variable */
	function changeType(x, type) {
	if(x.prop('type') == type)
	return x; //That was easy.
	try {
	return x.prop('type', type); //Stupid IE security will not allow this
	} catch(e) {
	//Try re-creating the element (yep... this sucks)