seveibar

13 ms·

121.
by seveibar 3y ago
In my original commit I wrote "BIGRELEASE.MAJOR.MINOR" but I realized in practice many packages start to bundle multiple changes into their MAJOR and sometimes even MINOR releases. To me this started to really confuse SemVer, ANNO
122.
by seveibar 3y ago
This is a great critique, and something important to address if "pragmatic versioning" actually becomes a thing. I think one solution is to have "LTS Pragmatic Versioning" as a subtype e.g. LTS.ANNOUNCE.INCREMENT could b
123.
by seveibar 3y ago
Yea I think more specificity is needed, SemVer is an actual spec with well-defined terms and this is more of an early concept. The tricky thing to maneuver is many package authors will not want to commit to an LTS, so what do you do? In pra
124.
by seveibar 3y ago
Yep, originally I wrote BIGRELEASE.MAJOR.MINOR but I didn't want to confuse the terms. (The first commit shows this: https://github.com/seveibar/pragmaticversioning/commit/70b76... ) Good read :)
125.
Pragmatic Versioning – An Alternative to Semver(github.com)
102 points by seveibar 3y ago|108 comments
126.
by seveibar 3y ago
An early draft of an alternate system to semantic versioning (semver) that I think is more useful in practice for both package maintainers (who don't want to evaluate every change for meaning, and want to be able to maintain large rele
127.
by seveibar 3y ago
This article advocates for a traditional REST API design. At Seam, we use an API design that is like a RESTful RPC API, inspired by the API at Slack. I think that HTTP RPC and Slack-like APIs are much better than traditional REST because mo
128.
by seveibar 3y ago
With generated database types (we use zapatos) this is the most type safe query builder, the typing is extensive and very correct
129.
ChatGPT Forgot My Startup(twitter.com)
20 points by seveibar 3y ago|24 comments
130.
by seveibar 3y ago
looks pretty cool :) nice work! Some things we find missing at Seam (we use both Clerk and Auth0 on different apps): 1. Inability to change email or reset password without using "privileged" API, would love to redirect users to a
131.
by seveibar 4y ago
Those libraries are helpful thanks! I didn't know icalendar had an RFC, very helpful!
132.
by seveibar 4y ago
The first link looks like a good translation of the iCalendar to JSON, I guess you can't really beat the iCalendar standard when it comes to representing events!
133.
Ask HN: Best API format for recurring schedules?
5 points by seveibar 4y ago|5 comments
134.
by seveibar 4y ago
Kysely[1] and zapatos[2] are excellent solutions for type-safe typescript query builders. It’s hard to go back to the days of spending 20-30% of your time in the object mapping layer. [1] https://github.com/koskimas/kys
135.
by seveibar 4y ago
It’s nice to have a structured review system. I find this is most difficult with Notion vs Github, there are a lot of conventions in Github around approval processes and sources of truth (eg CODEOWNERS, Github Flow)
136.
by seveibar 4y ago
I love outside-in testing, where tests are essentially any bug reported by a customer with fixturing of the db and api calls to an instance of the application and all dependencies are faked or doubled. At Seam, we use fakes for the 20+ IoT
137.
by seveibar 4y ago
thank you!
138.
by seveibar 4y ago
Base62 is a great alternative! The libraries/alphabet around base58 are fairly common thanks to cryptocurrencies, but base62 libraries are generally available and easy to produce if needed.
139.
by seveibar 4y ago
The signature approach is interesting because it couples the short token the api key, so they're a pair rather than totally independent. Introducing a signature changes the math to create the shortest possible API key with at least 128
140.
by seveibar 4y ago
Yep you've got it! The consumer gets the full api key containing the prefix, short token and long token, e.g. "mycompany_BRTRKFsL_51FwqftsmMDHHbJAMEXXHCgG". The database stores the short token, and a hash of the long token.
141.
by seveibar 4y ago
Thanks, yes I agree the ".split(_)[-1]" is ugly and there should be validation on the key prior to operations on it! Making an issue :)
142.
by seveibar 4y ago
I think this is an excellent idea! However, we didn't like the aesthetic of the version that included the domain- I'll admit it's not great reasoning.
143.
by seveibar 4y ago
my mistake! fixed :)
144.
by seveibar 4y ago
Appreciate the thoughts on the naming/exceptions and thanks for taking a look at the implementation! Definitely making some adjustments tonight. I think your thought on bcrypt/scrypt vs SHA256 is super interesting here. The long t
145.
by seveibar 4y ago
thanks for taking a look! I've created an issue on the repo and should be able to address these tonight :)
146.
by seveibar 4y ago
fixed thank you :) - and great suggestion! edit based on your edit: Added your recommendation to the README, thank you!
147.
by seveibar 4y ago
Author here: I was curious what HN would think of this token style, we're currently using it for getseam.com . I think it has a lot of advantages over other token styles (e.g. double-click to select, standard alphabet, compatible with
148.
Show HN: Prefixed, dual-token, base58 encoded API Keys(github.com)
100 points by seveibar 4y ago|54 comments
149.
by seveibar 5y ago
Surprised nobody has mentioned Row Level Security or RLS for postgres. It allows tight and domain-specific access control to each table through security policies you design. It's so effective at controlling access that Postgrest (postg
150.
by seveibar 5y ago
I would build out more of it and list it for free (I've dropped in a lot of TODO sections), I'm not sure if "progressive release" is possible, if it's not, we wouldn't want to release it as is. I have a lot of

More ›