Your explanation is true of every prime. I’m pretty sure GP just meant that “2 is the only prime with the additional characteristic of being an even number”. So it’s odd (read “interesting”) in that sense, like if it would be if (for example) any number were to be the sole prime composed of exactly X digits.
Runtime validate at the database boundary? Isn't it better to just do runtime validation at the api boundary instead? Then any of the types that make it into the database should be mostly guaranteed by TS (and of course, whatever types are enforced by the database schema itself).
Well in most statically typed languages with a VM (Java/C#), there's some sort of runtime validation
In Java
Object something = new Map();
String badCast = (Object) something; // This line would throw a ClassCastException because something is not a String
This has the advantage of throwing an exception in the correct place, instead of somewhere down the line.
Other statically-typed languages do have to deal with the problem of parsing external objects. In my experience, none of them have parsers as good as Zod in terms of ergonomics.
> Other statically-typed languages do have to deal with the problem of parsing external objects.
Well that's just blatantly not true. Which languages are you thinking of? I'm sure I'm misunderstanding what you said.
I can't think of a single server side language that doesn't have to parse external untyped objects. That's where these serialization libraries come into play.
For example, in Kotlin, you declare a data class and mark it as @Serializable and it generateds `toJSON/fromJSON` for you. IMO it's a much better experience than Zod.
> I can't think of a single server side language that doesn't have to parse external untyped objects.
That's what I said too.
> For example, in Kotlin, you declare a data class and mark it as @Serializable and it generateds `toJSON/fromJSON` for you. IMO it's a much better experience than Zod.
If the JSON object matches the data class exactly, the Zod parser and the Kotlin Serialization parser and Jackson and all those other JSON parsers are similar in complexity.
However, where Zod shines is if the JSON object doesn't match your domain class exactly, e.g. you want to parse a JSON number into a Date, or you want to parse a string field into some custom domain object. In those cases, in zod this is a one-liner with `.transform(...)`. Other libraries will require all kinds of weird workarounds to support this.
The other thing Zod does really well is composition, i.e. making new schemas out of existing schemas. Something like this is difficult to express in most language's parser frameworks:
const User = z.object({id: z.string(), username: z.string(), ...})
const CreateUserPayload = User.omit({id: true}) // Same as user, but without the id field
const UpdateUserPayload = CreateUserPayload.partial() // Same as CreateUserPayload, but now all the fields are optional
I was poking around to understand how this was not caught in a test - any ordinary fetch call could have triggered the error, and besides how poor coverage it has for all the ways `fetch` can be used, it seems excessive mocking may have played a part: https://github.com/PostHog/posthog-js/blob/main/src/__tests_...
The whole fetch and XHR functions are mocked and become no-ops, so obviously this won't catch any issues when interacting with the underlying (native or otherwise) libraries. They have Cypress set up so I don't see why you'd want to mock the browser APIs.
I have seen so many mocked tests where you end up asserting the logic in the mock works; effectively testing 1=1.
The number of issues that can be prevented with an acceptance level test that has a user log in and do one simple interaction is amazing. Where I can convince the powers that be, PRs to main are gated by a build that runs, among others, that simple kind of AC test. If it was merged to main, you _know_ it will not totally break production.
We had regular outages with our internal emailing system at a small e-commerce shop. I stepped in and added one test that actually sent an email to a known sink that we could verify and had that test run pre-deploy. We went to zero email outages. Tests had the occasional flake that auto-retried. Also, if your acceptance tests are flaky, how do you know your software isn't? Bad excuse to avoid acceptance level testing
Thank you for pointing this out. I did not read the post in detail but I was wondering how could a monitoring library cause the entire application to go down. At worst, I thought, it should have failed to process the monitoring events, assuming that it was integrated in a reasonable way.
PostHog patching a very important global function is a feature that should be well-documented so that the people who are using it are aware of it and can be reasonably expected to have it in mind when debugging these seemingly unexplainable issues.
it's common with all these analytics toolkits. When you're monkeying with such a core api, I have no idea how you can actually test everything.
eg heap analytics still (as of this month) bad touches something inside hotwire and randomly entirely breaks hotwire causing every click to do a full page load. ime, it affects 30-60% of page loads. You can fix it (but thanks for 50+ hours of debugging) but making heap load after all hotwire js.
Would absolutely love to know how other engineers on HN approach interviews and assessing technical competence. I didn't _think_ I had any mis-steps here but would love to know if anyone thinks there's something I could have fixed about this whole interviewing process.
Probably the guy was just having a bad week, but all the same. Really bemused (and more than a little confused)
I think your process is enlightened and productive. In this case it worked like a charm, you got the vibe check pretty quickly! Just an outlier in the interaction.
In your history, is the "I'm the best!" bravado like that a sign of anything? Over-cocky is what it seems to have been here.
The funny thing is, it was pretty clear to me he meant that as a bit of a joke.
The question on our application is "are you a fit for the JD"
For the most part, the answer is "obviously yes, that's why I'm applying", but we do get some really insightful answers here where people talk about their weaknesses too and we learn something.
But even in the call he seemed to acknowledge that was a bit of a joke, and I legit don't mind jokey bravado for the most part.
i'm with you quantified. I'm just a guy, but for me personally when someone says "i'm the best" (especially as a programmer) that's a pretty decent red flag. Programming since the beginning of time is just one curve of lifelong learning with evolutions in languages, methodologies, etc. It's one field where it's basically impossible to be "the best", as there's always an area you can do better in. There's also always that one guy that's gonna be more cracked than you.
TLDR: IMHO bravado of any kind is pretty overrated. Just say that you are a fit and show where you can be better, that's what this game is all about. And feigning that bravado for interview clout is especially corny cause any programmer worth their salt can sniff that out immediately.
Complaining that you have to tune it for performance is like complaining that your runtime code isn't automatically maximally performant without a little tuning.
OneText | https://onetext.com | Bay Area, CA | Engineering | US (In person or remote) | Full time
We're OneText (Y Combinator W23), and we've built a product anyone pay and make purchases with a single text message. We need you to help us keep up with massive demand and scale up to the next level!
Very cool! Will you also add support for secret based 2FA codes, similar to Authy / Google Authenticator? It would be incredible to have those autofill.
1Password already has support for this. Some would argue that you're defeating the purpose of 2FA if it's stored in the same way as your password, but it is pleasant.
Personally, I use KeePass and a self-managed password database. I look at it as the "something I have" factor being the database file itself, and the "something I know" being the master password that decrypts it. Then it doesn't bother me quite so much that the password and 2FA seed are right next to each other.
Does 1Password do SMS based 2FA code filling? I use it for sites where they let me use any compliant auth app, but I've not seen a way to get it to work for SMS codes.
But this isn't an `any -> any` case. They passed in a default value, as a string, which is the correct type for a default value for this column. Even with very strong typing they wouldn't have got a type error here right?
"Even" just means "divisible by 2"
"2 is the only prime that is divisible by 2" "3 is the only prime that is divisible by 3" "5 is the only prime that is divisible by 5"
...
"N is the only prime that is divisible by N"