Skip to content

Instantly share code, notes, and snippets.

View jordanorelli's full-sized avatar
👾

Jordan Orelli jordanorelli

👾
View GitHub Profile
package main
import (
"fmt"
"reflect"
)
type pair[T, Z any] struct {
left T
right Z
@jordanorelli
jordanorelli / fetch.go
Last active November 22, 2021 21:22
concurrent list evaluation with generics
package main
import (
"fmt"
"github.com/jordanorelli/generic/list"
"net/http"
"net/url"
)
func status(path string) int {
jorelli@Jordans-MacBook-Pro[0] ~: dig go.dev
; <<>> DiG 9.10.6 <<>> go.dev
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21884
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
@jordanorelli
jordanorelli / gist:385a6f5de1b914a4631e2899ea10d377
Created November 21, 2021 21:13
union elements in interfaces
jordan@wonkavator[1] ~: cat what.go
package main
import (
"fmt"
)
type Smallboi interface {
int8 | int16
}
@jordanorelli
jordanorelli / compose.go
Created November 21, 2021 12:52
generic channel composition in Go
package main
import (
"errors"
"fmt"
"math/rand"
"time"
)
type code int
@jordanorelli
jordanorelli / integration.md
Created April 27, 2021 17:07
on integration testing

when people say "integration testing", the feeling I get is that the definition that most people are using is "unit tests that happen to perform i/o". is this the definition that most people are using?

there's another definition, which is the definition I learned when I first learned about unit testing, which I have never seen anyone actually use: a unit test is an individual unit of testing, and "integration testing" is when you sequence the unit tests to create an integrated suite of tests. that is ... integration testing is when you integrate your unit tests, not when you test how your system integrates with another system. Those are distinct concepts! My suggestion here is not that the latter concept isn't valuable, it is valuable, it's just distinct, and rarely do I see the first concept being executed well.

For example, let's say you were testing some CRUD API and you wanted to test two things: the create and the update. The strategy that I most commonly witness is as follows:

  • create a unit t
select -cl;
select -add AZRI:CTL_L_BeltSide1;
select -add AZRI:CTL_L_BeltFront1;
select -add AZRI:CTL_R_BeltFront1;
select -add AZRI:CTL_L_BeltBack1;
select -add AZRI:CTL_R_BeltBack1;
select -add AZRI:CTL_R_PouchBack1;
select -add AZRI:CTL_R_PouchFront1;
select -add AZRI:CTL_R_BeltSide1;
send_request_one()
response_two = send_request_two()
response_three = send_request_three()
send_request_four()
await response_two
await response_three
send_request_five()
@jordanorelli
jordanorelli / box.zig
Last active December 24, 2020 22:27
undefined values
const std = @import("std");
const stdout = std.io.getStdOut().writer();
fn Box(comptime T: type) type {
return struct {
value: T,
};
}
const Point = struct {
vagrant@vagrant[0] ~: cat pwd.zig
const std = @import("std");
const os = std.os;
const print = std.debug.print;
pub fn main() !void {
// I think this is entirely on the stack?
var buf: [4096]u8 = undefined;
// use that fixed array we put on the stack as