cfors

They were profitable for a while, and then got a round of funding from Andreessen-Horowitz. [0] I don't know if they are still profitable, but I recently for some reason was on the founder's (Alan Schaaf) wikipedia page.

[0] https://en.wikipedia.org/wiki/Alan_Schaaf#cite_note-3

The repository and structure is free here, but I highly recommend the actual course for API development, which is not free but very valuable.

https://github.com/ardanlabs/service

This is neat, and a testament to the simplicity of Go.

I normally point people to this tutorial if they want to learn Go quickly, it is interactive (able to navigate straight to go playground) and very well done in my opinion.

https://gobyexample.com/

Hinge | Staff Software Engineer (Backend) | New York (NYC), Remote until Spring 2021 | Full-Time

Hinge is the dating app for people who want to get off dating apps. In today’s digital world, singles are so busy matching that they’re not actually connecting, in person, where it counts. Hinge is on a mission to change that. So we built an app that’s designed to be deleted. On Hinge, there are no rules, timers, or games. Instead, you’ll meet your most compatible matches and you’ll have unique conversations over what you’ve shared on your detailed profile. It’s a natural way to find a great first date. Currently, 3 out of 4 first dates lead to second dates, we’re the #1 mobile-first dating app mentioned in the New York Times wedding section, and we’re the fastest growing dating app in the US, UK, Canada, and Australia.

The recommender system powers Hinge’s matchmaking capabilities and we’re looking for a staff engineer who is interested in owning the backend portion of this system. You will be the first dedicated backend IC on a new cross disciplinary team that includes data scientists, ML engineers, data engineers, and product managers.

https://jobs.lever.co/matchgroup/48cec48a-b16b-4592-92e7-e8c...

There is tooling built to easily do grpc requests from the command line[0] or even a GUI if that's your thing[1].

The tooling isn't quite as ubiquitous as cURL, but if anything I would think that its even easier because you have introspection into the contract with a .proto file.

[0] https://github.com/fullstorydev/grpcurl [1] https://github.com/uw-labs/bloomrpc

Presumably Developer Experience

Hinge | Engineering Lead (Backend), Associate Engineer (Backend) | New York (NYC), Remote until 2021 | Full-Time

Hinge is the dating app for people who want to get off dating apps. In today’s digital world, singles are so busy matching that they’re not actually connecting, in person, where it counts. Hinge is on a mission to change that. So we built an app that’s designed to be deleted. On Hinge, there are no rules, timers, or games. Instead, you’ll meet your most compatible matches and you’ll have unique conversations over what you’ve shared on your detailed profile. It’s a natural way to find a great first date. Currently, 3 out of 4 first dates lead to second dates, we’re the #1 mobile-first dating app mentioned in the New York Times wedding section, and we’re the fastest growing dating app in the US, UK, Canada, and Australia.

The backend team is hiring for two positions:

- Engineering Lead (https://jobs.lever.co/matchgroup/5fa5ad5b-8e6f-49d1-be81-414...)

- Associate Engineer (https://jobs.lever.co/matchgroup/249bbd9a-f629-4d8e-ab4a-c9a...)

It's not a replacement for git, its to interact with the GitHub UI over the command line.

There are 3 main commands from the CLI you can issue:

  gh

  CORE COMMANDS

   issue:      Create and view issues
   pr:         Create, view, and checkout pull requests
   repo:       Create, clone, fork, and view repositories

I still use the git cli and the github UI, but sometimes just view open PR's from the my terminal if I'm already in there.

Go's context package is great, but also hard to reason about. As developers, we often times like to think that just piping a context through a function chain will take care of all of your timeouts concerns for you.

Some fun context gotchas:

- Using `req, err := http.NewRequest(...)` to create an http request, and then calling `client.Do(req)` does not do anything with context, you need to use `http.NewRequestWithContext(...)`. [0]

- Creating a function that accepts a `ctx context.Context` and then making a blocking call that doesn't respect your context will still block for the entirety unless you instrument it yourself.

- If a parent context is canceled, all children (derived) contexts will also be canceled. However, only if they are explicitly checking `context.Done()`.

- And the worst of all is passing things that decide business logic in your context variables! First, you lose all benefits of go's static typing. Second, you will not realize all of the crazy places that a context scoped variable is coming from, have fun debugging that!

[0] https://golang.org/pkg/net/http/#NewRequest

> due to the transaction fees.

This is actually a misconception.

Amex has been competitive with Visa/Master for the past couple years, but haven't been able to shake off the stigma that the processing fees are more expensive, since it is up to the actual business to accept Amex.

> But in 2018, Mastercard and Visa credit had a swipe fee weighted average of 2.26%, while AmEx had 2.3%, additional data from The Nilson Report found. [0]

[0] https://www.retaildive.com/news/american-express-catches-up-...

In the past Amex has been prohibitively expensive to accept, and relied on their status as a luxury brand to get people to accept them. I think the playing field is starting to reach an equilibrium across payment network providers.

The big differentiator between these isn't per se the way that content is shared/created, but the network itself. So, as long as the network is intact, then in my opinion yes the big players can just copy/buy every competitor and remain on top.

I wonder what revealing how the algorithm works will impact content creators? We have entire industries built on poking at Google Search and Instagram to build exposure.

My prediction is that this levels the playing field, but doesn't solve the problem of people gaming algorithms to do what they want. The less shrouded the algorithm, the less snake oil that can be sold which is probably for the best.

Sounds like another win for languages with an LLVM backend. Definitely excited to see this language grow, especially as it has generics already.

Does anybody use Crystal professionally here? Any thoughts so far if so?

So the way I believe that it works is that the vulnerability was that a valid email is used to generate an Apple signed JWT. The server side validation would be unable to tell that the token wasn’t issued in behalf of the user since Apple actually signed it.

Wow. That's almost inexcusable, especially due to the requirement of forcing iOS apps to implement this. If they didn't extend the window (from originally April 2020 -> July 2020) so many more apps would have been totally exploitable from this.

After this, they should remove the requirement of Apple Sign in. How do you require an app to implement this with such a ridiculous zero day?

Because Bing does what Google does, which is uses your search history to show you targeted ads. DuckDuckGo only shows keyword based ads, which aren't as effective but do not require building a persona of personal information to target.

It's totally a problem and disingenuous of the article to talk about the "Business Model" of DDG and not mention this.

So this provides an http router written on top of fasthttp?

Why would this be better to use than something like Gin, which has way more features? I would update the docs to be clear about that. What is the advantage of your custom router implementation over others?

Neat project, but it’s hard (at the moment) to see why this would be useful over some of the more mature go web frameworks.

Edit: obviously performance is important, but how much faster is it than gin for example if I am going to be giving up features for speed.

For platform stuff that has speed and correctness as the highest priority? Absolutely. Things like http proxies, message queues, shared infrastructure makes sense to be done in Rust.

For writing a normal networked http/rpc/event stream service Go is probably more than good enough. It’s not a winner-take-all market.

A great example imo is Buoyant’s Linkerd. Rust dataplane proxy as well as a control plane written in Go. Two different requirements for each of those services drove the language requirements

Rather than take the information from the Docker website and package it in up a new format, why not just use the official Docker documentation?

Literally this is almost verbatim what is present in the Getting Started page from the official Docker docs:

https://docs.docker.com/get-started/part2/

Sure, you're right. They are quite good. But just from my perspective, I've been a backend engineer for most of my professional career and wanted to pick up front end dev. With little javascript/html/css knowledge, I used a couple different resources. I'm still learning, but I've found that just the official documentation doesn't quite get you there if you want to get the full picture.

I've been working through the following resources with a decent amount of success I think:

1. Fullstack React: The Complete Guide [0] - a wonderful book with a bunch of practical applications to build

2. Learn CSS Layout [1] - A nice write up for understanding what CSS actually is doing

3. Mozilla HTML Reference [2] - Can't get any better than this documentation

4. Eloquent Javascript 3rd Edition - Book being discussed, really enjoying working through it.

Obviously, the React and Redux documentation have been great as well. I don't think that just those really give you the full picture that you need though if you actually want to build professional web applications.

Just another side of the coin, I suppose.

[0] https://www.newline.co/fullstack-react/

[1] http://book.mixu.net/css/

[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference

From my understanding it's a managed Istio service.

Maybe I’m a cynic of all big corp companies but if you’ve ever worked with a big corp open source department that’s almost the entire point is to build PR for the engineering department. Same goes for tech blogs. These things will be PR pieces first, and valid production tools/frameworks second (mostly).

Yes, with the added bonus of tax money going into advertiser’s pockets!

Nope, to be clear I am talking about Prometheus' own TSDB.

Before anybody thinks that they need something like this at work, I have seen single node HA Prometheus set ups work at one of the largest CDN's in the country for metrics.

Reddit's own Kubernetes infrastructure team uses single node (pod) Promethei as well. [0]

If you look all of the components that are required to run Thanos [1], the operational complexity is incredibly high. I know its a shiny tool, that is super cool but please make sure you have an actual need for some of these before devoting resources to them.

[0] https://www.reddit.com/r/kubernetes/comments/ebxrkp/we_are_t...

[1] https://improbable.io/blog/thanos-prometheus-at-scale

For all the grief Kenneth Reitz gets... gotta give him credit for his emphasis on usability and professional presentation.

Brendan Gregg talks about it in the talk in the link at 17:50.

Here is a short transcription (not verbatim):

> People have asked if BPF is Turing Complete. Is is possible to have a BPF program that can run BPF programs? We have had some serious discussions, as are we there yet. And the answer is no. The answer is no because the verifier rejects unbounded loops and so that there is some things that are not possible. There are bounded loops in BPF now.

Ah sorry, forgot to link the post! Thank you.

Here is a relevant quote from Jess' blog:

> Hyperscalers like Facebook, Google, and Microsoft have what I like to call “infrastructure privilege” since they long ago decided they could build their own hardware and software to fulfill their needs better than commodity vendors. We are working to bring that same infrastructure privilege to everyone else. [0]

Is this same infrastructure privilege an effective, internal cloud? From my experience with large internal cloud platforms, the problems are almost always organizational ones.

Regardless, I am definitely hoping that Oxide can provide a better experience. Maybe with centralizing all hardware into a single group, rather than have network folks do switches, another team do servers, and a totally separate group to do ACL's, etc. you could improve the experience of managing an entire datacenter.

Edit: Forgot the link: [0] https://blog.jessfraz.com/post/born-in-a-garage/

With respect to the fact that 99% of my use of awk is done like this:

  > | awk '{print $<word>}'

The solution to the first exercise looks surprisingly clean. It will be interesting to see how they continue as the challenges get harder. Bookmarked!