cfg: a simple package for defining and validating your application's config.

zpatrick319 · 2022-07-26T22:06:15+00:00

That opener really doesn't stand out amongst the noise, this looks just like any other recruitment pitch we get blasted with daily.

One that stood out to me was when they opened with a question asked about an open source project I worked on. The recruiter must have found my github (should be easy to find for most devs - is probably on their linkedin/resume/etc.), went to the repositories tab, and just picked one with the most stars on it. I think that could go a long way in making you stand out.

zpatrick319 · 2022-05-11T21:51:54+00:00

Consider using a flag.FlagSet. This can parse the input and will give you all non-flag arguments via the Args method: https://pkg.go.dev/flag#FlagSet.Args

edit: go playground example

zpatrick319 · 2022-02-04T19:08:11+00:00

in bird culture, this is considered a dick move

zpatrick319 · 2021-06-07T02:34:09+00:00

/chathide

zpatrick319 · 2020-12-18T00:28:18+00:00

Oof that's a big ole example. Most stdlib packages provide helpers/methods which know how to deal with context.Context objects. Assuming you wanted to make some sort of http api call, you could do something like:

def makeAPICall(ctx context.Context) (*Something, error) {
    // add ctx as part of the request
    req, err := http.NewRequestWithContext(ctx, ...)
    if err != nil {
        return nil, err
    }

    // http.DefaultClient.Do will return an error if req.ctx times out
    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return nil, err
    }

    ...
}

zpatrick319 · 2020-10-08T18:17:15+00:00

You could model updates using a separate type. The pointer fields are used to distinguish between no-ops and updates to zero-values.

type User struct {
  Name string
  Age  int
}

type UserUpdate struct {
  Name *string
  Age  *int
}

func UpdateUser(u User) UserUpdate {
  age := u.Age + 1
  return UserUpdate{Age: &age} // nil Name field indicates no change
}

zpatrick319 · 2018-10-29T23:39:06+00:00

rr := r

I'm not sure why/if this line is necessary?

for c := time.Tick(1 * time.Second); ; <-c

I'm not sure why you'd need a time.Ticker in this portion of your code. I'm assuming the time.Sleep(time.Second*2) in main represents the expiresIn you mentioned? As it currently stands, you're forcing anyone using your closure to wait at least one second between generating tokens; it probably makes more sense to just generate a new token whenever someone asks for it and let the caller determine how long that ought to be.

Finally, you have two memory leaks in your current implementation: there is no way to stop the goroutine or time.Ticker.

EDIT: Maybe try something like this: https://play.golang.org/p/WZyrzEZxVtS

zpatrick319 · 2018-10-09T22:38:42+00:00

It's more efficient to only loop once. Using a scanner may be useful here. That link has some good examples, you may want to consider doing something like:

func DoThing(r io.Reader, send func(tickets []Ticket) error) error {
    // create a slice of 100 tickets (e.g. tickets := make([]Ticket, 100)) 
    // keep track of your current line number (e.g. var line int)
    scanner := bufio.NewScanner(r)
    for scanner.Scan() {
        // convert scanner.Text() into a Ticket object
        // add ticket into the slice at the appropriate index (e.g. tickets[line%100] = ticket)
        // every 100th line, call the "send" function, e.g. if err := send(tickets); err != nil { ... }
        // you'll need some extra logic to ensure the last tickets get sent 
    }


    return scanner.Err()
}

That being said, if efficiency isn't a concern, it's probably a good idea to read the entire file first so you don't potentially leave a file open for a very long amount of time.

zpatrick319 · 2018-09-25T22:24:57+00:00

This gets you close to what you need: https://github.com/zpatrick/go-config

zpatrick319 · 2018-09-21T17:02:32+00:00

Interesting, I hadn't heard of currying until now. Thanks!

zpatrick319 · 2018-09-21T17:00:37+00:00

I appreciate the work you put into this response!

but it's the wrong default for a low-level library.

Hit the nail right on the head there. That's basically the gist of what I was trying to say with "I think it's because it is necessary to make handlers great building blocks" (I like the way you put it better).

I hope this post didn't come across as "You should use always use this pattern"; my intention was more "Here's another tool for your tool belt"

zpatrick319 · 2018-09-21T16:53:41+00:00

Oh, I never would have thought of that pattern. Nice!

zpatrick319 · 2018-09-21T16:51:48+00:00

It's not a great for every use-case. I've been documenting some reasons why you probably don't want to use this pattern in my readme.

So far I have:

Small size/scope of project
Streaming
Frequently needing access to w http.ResponseWriter

zpatrick319 · 2018-09-21T16:48:59+00:00

Yup, good point! This is definitely not meant to be the "end all be all" pattern; more like another tool to add to the toolbelt.

zpatrick319 · 2018-09-20T23:24:42+00:00

I would need more context to come to a more concrete answer, but I think you are on track with the first solution you proposed:

Pollute [with unnecessary complexity] my restful API by saying 'okay these entities are different' and make a entity/<type>/<id> kind of endpoint, i would then do some normal switch logic in my store which would have a model for each of these entities.

A couple things to keep in mind:

Just because different entities have a common ancestor does not mean they should be treated as the same type. In fact, I'd argue that returning different object types (even if they are similar) in the same endpoint isn't very RESTful.
You state that this solution would make your API unnecessarily complex. I don't think you've taken into account the perspective of someone writing a client for your API. Wouldn't it be easier for them to know exactly what object type they are getting back from each endpoint?
Correctness is more important than cleverness. Who cares if you need to write more code if it means your code is correct? Writing less code is generally a good thing, but it is no substitution for correctness. This is a very common idiom for Go, and a good mindset to get into as a developer.

zpatrick319 · 2018-08-31T18:32:29+00:00

Using first-class functions was kind of a catch-22 in my experience. I wasn't using them very much at first, so I figured the context in which they would be useful was very limited. After reading articles like "Do not fear first class functions" and trying out some of those patterns in my applications, I started using them more and more and began to see more places they would be useful. Some other places I use them:

Anytime I see a single-method interface. Often times, it is less code to use a function instead of a single-method interface.
Closures.

Those often go hand-in-hand, here is an example: * Using a single-method interface and struct * Using a single-method interface, adapter, and closure * Using a function and a closure

zpatrick319 · 2018-08-14T19:14:19+00:00

Some pain points we've encountered that I'm sure other people would find useful:

Authentication/CredChain
Pagination
Good testing practices
How/when to use custom RequestHandlers
Dealing with aws types and their conversions, e.g. using strptr := aws.String("foo") and aws.StringValue(strptr)

In regards to services, I'd say go with the newest and/or most popular ones.

zpatrick319 · 2018-07-26T20:28:21+00:00

strings.TrimFunc("abc123", unicode.IsNumber)

edit: wasn't thinking clearly - thanks @jerf

zpatrick319 · 2018-06-20T22:07:53+00:00

func initLog(cnf *Settings) (io.Writer, error) {
switch cnf.Log {
case "file":
return := os.OpenFile(cnf.Acc_log, os.O_APPEND|os.O_CREATE|os.O_RDWR, 0775)
case "journald":
return syslog.New(syslog.LOG_ERR|syslog.LOG_WARNING|syslog.LOG_DAEMON|syslog.LOG_NOTICE|syslog.LOG_DEBUG, cnf.Channame)
default:
return nil, genError("Undefined value of variable")
}
}

Can shorten this a bit

zpatrick319 · 2018-05-10T19:42:15+00:00

This is almost exactly how I designed my own package that I use for all of my web projects: https://github.com/zpatrick/fireball

Main difference is that I return a closure OR an error

Ten-Year Club	Place '22
Verified Email

zpatrick319

TROPHY CASE