This post is a response to a writing prompt from Underline Center: "Write about an album that got you through a hard time." It would be an injustice to pick just one album! Hard times have a tendency to move in and stay for a good chunk of
Part of the Building the Log Package series How I thought through the log package design before writing any code When I was working through the store object, the whole idea was clear enough when bytes are given, append and when a position is given, read. Pretty simple interface. But
Part of the Building the Log Package series How I thought through the log package design before writing any code The five layers of the log package are easiest to understand by tracing one record through all of them. The scenario Building a chat app. Messages come in: "hello&
📖Distributed Services with Go by Travis Jeffery; Chapter 3. Here's what clicked. Understanding the structure of a log is one aspect of learning curve. And sitting down to build it in Go is a whole different trajectory! Here's how the progression looked. Step 0: Co-relations; Why
Part of the Building the Log Package series How I thought through the log package design before writing any code Syscalls are not free they involve a context switch from user space to kernel space. Your Go program runs in user space think of it as a regular employee working
ℹ️in reference to what makes protobuf faster?. You write code in a language humans can read. The computer only understands binary (0s and 1s). A compiler bridges that gap. This is why protobuf needs a compiler you write the schema in .proto format, run protoc, and it generates Go
📖Distributed Services with Go by Travis Jeffery: swaps JSON for Protocol Buffers. Before writing a single .proto file, I wanted to understand why and what actually makes Protobuf faster? Understand serialization Example: curl -X GET localhost:8080/consume -d '{"offset":0}' {"record":{"value&
📖Chapter 1 summary of pragprog.com/titles/tjgo/distributed-services-with-go/ The correlation when building anything Every server you ever build has exactly three layers: LAYER 1 DATA "what do I store and how?" -> your Log, your Database, your Cache -> pure Go structs, no HTTP, no
uint = unsigned integer, no negative numbers. Range is 0 to a very large positive number. var x int // -9,223,372,036,854,775,808 to +9,223,372,036,854,775,807 var x uint64 // 0 to 18,446,744,073,709,551,615 In a commit log specifically:
Let's understand this with log structure example. A commit log is just an append-only slice // at its heart, this is all a log is type Log struct { records []string } func (l *Log) Append(record string) { l.records = append(l.records, record) } func (l *Log) Read(index int) string
Array: fixed, value type arr := [3]int{10, 20, 30} // size is part of the type * Fixed size, decided at compile time. [3]int and [4]int are different types. * Value semantics when you assign or pass to a function, the whole array is copied. * Rarely used directly in production
The 7 Layers of the OSI Model #LayerFunctionCommon Protocols / Tools7ApplicationWhere users and software interactHTTP, HTTPS, DNS, SSH, SMTP, FTP, SNMP, etc.6PresentationTranslates, encrypts, and formats dataSSL/TLS, MIME, JSON, ASCII, JPEG5SessionStarts, manages, and ends sessionsTCP session, NetBIOS, RPC4TransportEnsures data delivery (error checking, retransmission)TCP, UDP, SCTP3NetworkHandles routing and addressing between