kornish

One danger of chargebacks: companies may ban your account or otherwise treat your activity as fraud. It can be extremely difficult to get through to a person to correct the situation.

I know a couple folks who still can't use Lyft, for instance, because they charged back an NYC Citibike subscription. You can allegedly cancel a Citibike subscription by contacting customer support — but after no response, they issued a chargeback and Lyft banned them a couple days later. Since the accounts are tied to the phone number, they simply can't use the service.

Support actually managed to reverse the ban for a few days, but then it was re-triggered (presumably by some automated system).

Ah - so that's why GitHub Actions are unreliable right now.

Gravity | Remote (US only - for now!) | Full-time | Senior engineers of all stripes (full-stack, frontend, backend). Also, BDRs and AEs.

Gravity (https://gravityclimate.com) is a carbon accounting and decarbonization software company. We help industrial companies track, report, and reduce their greenhouse gas emissions. Our business is buoyed by tailwinds of climate regulation and private market forces.

Buzzwords: the stack is a Go/Postgres modular monolith, serving a Next.js/React/Typescript client. We use an internal CLI, `gdev`, for all common developer actions. We will keep a low-dependency architecture for as long as possible.

Please contact jobs@gravityclimate.com if interested. (or reach out to me - cofounder & head of eng - for a 15min chat. Email is in my profile). At this time, we are hiring within the US only.

RIP Oden! https://oden-lang.github.io/

Gravity | Remote (US only - for now!) | Full-time | Senior engineers of all stripes (full-stack, frontend, backend). Also, BDRs and AEs.

Gravity (https://gravityclimate.com) is a carbon accounting and decarbonization software company. We help industrial companies track, report, and reduce their greenhouse gas emissions. Our business is buoyed by tailwinds of climate regulation and private market forces.

Buzzwords: the stack is a Go/Postgres modular monolith, serving a Next.js/React/Typescript client. We use an internal CLI, `gdev`, for all common developer actions. We will keep a low-dependency architecture for as long as possible.

Please contact jobs@gravityclimate.com if interested. (or reach out to me - cofounder & head of eng - for a 15min chat. Email is in my profile). At this time, we are hiring within the US only.

After most recently working in ads, I switched to working in climate - feels infinitely more meaningful on a daily basis.

We're working on carbon accounting and industrial decarbonization here at Gravity (https://gravityclimate.com). Your background could make for a strong fit.

Email in profile.

I think https://jam.dev/ should do it!

(not affiliated - just a fan)

Gravity | Remote (US only - for now!) | Full-time | Senior engineers of all stripes (full-stack, frontend, backend). Also, SDRs and AEs.

Gravity (https://gravityclimate.com) is a carbon accounting and decarbonization software company. We help industrial companies track, report, and reduce their greenhouse gas emissions. Our business is buoyed by tailwinds of climate regulation and private market forces.

Buzzwords: the stack is a Go/Postgres modular monolith, serving a Next.js/React/Typescript client. We use an internal CLI, `gdev`, for all common developer actions. We will keep a low-dependency architecture for as long as possible.

Please contact jobs@gravityclimate.com if interested. (or reach out to me - cofounder & head of eng - for a 15min chat. Email is in my profile). At this time, we are hiring within the US only.

Gravity | Remote | Full-time | Senior engineers of all stripes (full-stack, frontend, backend). Also, SDRs and AEs.

Gravity (https://gravityclimate.com) is a carbon accounting and decarbonization software company. We help industrial companies track, report, and reduce their greenhouse gas emissions. Our business is buoyed by tailwinds of climate regulation and private market forces.

Buzzwords: the stack is a Go/Postgres modular monolith, serving a Next.js/React/Typescript client. We use an internal CLI, `gdev`, for all common developer actions. We will keep a low-dependency architecture for as long as possible.

Please contact jobs@gravityclimate.com if interested. (or reach out to me - cofounder & head of eng - for a 15min chat. Email is in my profile). At this time, we are hiring within the US only.

Gravity | Remote | Full-time | Engineers of all stripes (full-stack, frontend, backend). Also, SDRs and AEs.

Gravity is a carbon accounting and decarbonization software company. We help industrial companies track, report, and reduce their greenhouse gas emissions. Our business is buoyed by tailwinds of climate regulation and private market forces.

Buzzwords: the stack is a Go/Postgres modular monolith, serving a Next.js/React/Typescript client. We use an internal CLI, `gdev`, for all common developer actions. We will keep a low-dependency architecture for as long as possible.

Please contact jobs@gravityclimate.com if interested. (or reach out to me - cofounder & head of eng - for a 15min chat. Email is in my profile). At this time, we are hiring within the US only.

Marketing site is launching this summer, though emails are functional. The lack of site hasn't halted shipping or generating revenue :)

We're hiring at Gravity, a carbon accounting firm. Shoot me an email if you're interested in helping us fight climate change and grow revenue fast: ted@gravityclimate.com.

Interested in chatting about an opportunity? I feel pretty good about all three of those criteria you mentioned. (email is in my profile)

Good op-ed in The Information about this exact topic: https://www.theinformation.com/articles/the-end-of-venture-c...

Is he...reasonably honest?

(asking because as a bit of trivia, there's an SF handyman named Reasonably Honest Mike who's both hilarious and effective. http://reasonablemike.com/about.html)

What do you mean? Ads show up as native content in Facebook, Instagram, etc.

Correct. Previously, advertisers bought segments of 3P cookies, then targeted those IDs wherever they appeared. Cookiepocalypse means that advertisers will be unable to buy segments of domain-agnostic IDs (3P cookies), and so it will be up to the publisher to segment up its viewers and sell access to those segments to advertisers.

There will be more layers of aggregation on top of that, such as SSPs (supply-side platforms, which aggregate access to publishers' inventory) or PMPs (private marketplaes, which are effectively funnels of select inventory per some critera for some client), but the general principle is that targeting capabilities are shifting from the demand side to the supply side, closer to the viewer. So instead of picking the right segment, effective advertising will be about picking the right publishers. That's good for Google and Facebook because their 1P data is so rich.

If you like grep, you'll probably really like Sourcegraph, which I believe has most of GitHub indexed and supports some useful operators: https://sourcegraph.com/search

Too proprietary.

Every major cloud provider has a blob store. Most are S3-interface compatible, or can be fronted by something which is, like Minio.

Can't be run locally, on robots, etc.

If the contents of your S3 keys are just line-delineated JSON files, you can easily download those files and run scripts or process them locally.

Can't be transferred to other cloud providers.

Again, not true — a tool like rclone handles this case in a single command. Depends on the amount of data, but if anything it's easier to move a bunch of flat files between providers than copying a database backup around. You have to pay for egress bandwidth, though, of course.

Also S3 is horribly slow to write or delete thousands of records at once.

If you're keeping one JSON record per S3 key, that is a blatant misuse of the tool and performance will be terrible. On the other hand, if you batch records into files of appropriate sizes, it's very cost-effective to store and query via Athena, Spark on EMR, etc.

If you need individual record-level access as identifiable by a key, then you'd probably be better off with Redis or Memcached. (though, those will not be as good for bulk offline processing) It's all about your access patterns.

The description makes it sound like this is lending to businesses, not consumers.

It's also worth noting that with Spark, you can perform arbitrary computation using the Dataset API and operating on case classes.

That's pattern-matching on a tuple, which is common in languages that support destructuring, like Clojure, Scala, OCaml, and other functional programming languages.

2019: Tableau (BI)

2020: Slack (messaging)

2021: Zendesk? (CS)

Emacs, I'd imagine. (the same statement goes for Emacs and most anything, though) :)

Very cool!

Have you heard of StoryCorp? [0] It's a nonprofit which sets up booths and recording equipment around the world, then records and transcribes intimate conversations between individuals and catalogues those stories in the Library of Congress so they can be found and remembered.

They have hundreds of thousands of conversations at this point. Pretty remarkable initiative, similar in philosophy to yours. Dave Isay, the founder, describes it as a "hope machine", kind of the opposite of reality TV.

StoryCorps also produces these 3-minute summaries of some of their more notable conversations, which cover the whole range of human emotion. Here's a funny personal favorite: https://storycorps.org/stories/betty-jenkins/

[0] https://storycorps.org/

You may be thinking of this comment: https://news.ycombinator.com/item?id=23423955

One of my favorite talks is by Rick Reed about scaling Erlang at WhatsApp. What an absolute savage. He flies through an articulate and in-depth curriculum on system performance and bottleneck mitigation.

The talk is called "That's 'Billion' with a 'B'" and makes for a great lunchtime watch: https://www.youtube.com/watch?v=c12cYAUTXXs

What made the offer simple compared to typical modern SV startup offers?

I worked for Cleargraph, a startup which built a natural language query layer on top of RDBMSes and which we sold to Tableau. We reached the same conclusions as you: that such a system must properly handle ambiguous queries, and users need to explicitly understand the results they're viewing.

The way our system worked, broadly, was with a computational linguistics approach rather than an NLP one. We used an augmented bottom-up parsing algorithm to assemble a user's query into an AST, then translated that AST into both SQL (though that changed post-acquisition) and back into a canonical English-like query.

For ambiguous inputs, the parser would produce multiple candidate ASTs which we could offer to the user in the form of search results, for them to select the expression they preferred (solving your point 1).

The parser was constructed to use semantic information about the database schema to infer fields in the case of underspecification (handling your point 2). For example, we might understand about the `Series` table that `name` was the "display column", and should be the default field by which record-level results were displayed. Semantic information could, to various degrees, be inferred - always with the option to be manually overridden.

It seemed clear to us that a schema-agnostic approach to SQL generation would be untenable for a real product. Annotation of the schema over time (starting with basic information like field names, synonyms, and types, then adding semantic information like currency or unit labels) is key to letting a query generator produce sensible results to underspecified queries. For this reason alone, I'm skeptical of the quality of results that something like Photon can produce. Every schema differs in syntax and semantics. Perhaps a big enough corpus of schemas can allow for a generalized model. The more you can constrain the domain in building such a system, the better the results. (look at Statmuse [0]: pretty impressive query capability over sports facts).

[0] https://www.statmuse.com/

The author of curl has a funny blog post about how random people will sometimes find the curl license in the software of their everyday things (like a Toyota Corolla) and reach out to him asking for help with their things.

https://daniel.haxx.se/blog/2016/11/14/i-have-toyota-corola/