Distributed Services with Go: Chapter 3 suggestions

Page 28: It implements io.ReaderAt on the store type.

  • Sorry if it’s a dumb question but was the io.ReaderAt supposed to be io.ReadAt?

Page 29:
func (s *store) Close() error {
s.mu.Lock()
defer s.mu.Unlock()
err := s.buf.Flush()
if err != nil {
return err
}

  • Possibly:
    if err := s.buf.Flush(); err != nil {
    return err
    }

Page 31: At the end of store_test.go

  • Could you please include instructions/Makefile to execute the tests?
  • I finally managed to run them by cd’ing into internal/log and running ‘go test -v’ but this was after a bunch of failed attempts at running them.

Page 30-50: I would suggest running the tests after each of the Store, Index, and Segment would help people stay more engaged? Otherwise it seems too much (25 pages) code reading without interactivity.

Page 34: an ungraceful shutdown

  • Does ‘forceful’ shutdown sound more appealing than ‘ungraceful’?

Page 37: type Config struct {

  • I was trying to execute index_test.go and index.go and was trying to figure out what the unresolved Config was. Would it help to move this definition ahead of usage?

Page 36: Then we verify that the index and scanner error when

  • that the index and scanner ‘throw an error’ when?

Page 37: We need the next and base offsets to know…

  • This isn’t clear. Could you please consider drawing a simple picture to clarify this better?

Page 39: func (s *segment) Append(record *api.Record) (offset uint64, err error) {

  • Please consider forward declaring the definition of Record to make compilation and execution possible.

Page 41: import (
“fmt”
“os”
“path”

"github.com/gogo/protobuf/proto"
api "github.com/travisjeffery/proglog/api/v1"

)

Page 43: api “github.com/travisjeffery/proglog/api/v1

Page 43: Next, add the this setup() method below NewLog()

  • Next, add ‘this’ setup() method below NewLog()

Page 48: api “github.com/travisjeffery/proglog/api/v1

Page 51: testReader(*testing.T, *log.Log) tests that we can read the full, raw log as it’s stored on disk so that on, when we can snapshot

  • so that on ‘startup’?, when we can snapshot - something is off here

Chapter 3, segment.go, code reads as “substract segment baseOffset from nextOffset”:

// index offsets are relative to base offset
uint32(s.nextOffset-uint64(s.baseOffset)),

but text reads as “we subtract the segment’s next offset from its base offset”.

Question on the Remove() , Reset() methods on Log struct. Why are these not protected by a Lock?

@travisjeffery

I don’t love the test layout used here.

  1. I’d rather not have so much indirection in test code. I want to see each test function testing a specific thing, not a main test function: TestStoreAppendRead. I want to see granular test results, and in test code I want the most direct code possible.
  2. The main test function TestStoreAppendRead depends on order. If you comment out the TestAppend function, then TestRead will fail because it depends on data mutated by the first test. This is bad testing practice. It can also easily lead to test interference.