peter_l_downs

Yes, and I learned a lot there, including that I much prefer software engineering to computer science.

I ended up working for 2 years before I went to school, and it made a lot of things easier. When I graduated I was very certain that I wanted to go back to industry rather than go to academia. Definitely different jobs and skillsets.

Me! When I was in highschool I started emailing companies from the whoishiring thread, managed to find an apprenticeship in SF. My thinking was that before I went to college to study computer science I should check to see if I liked writing code.

Turns out I love writing code and don't care much for computer science. I've been a software engineer (NOT a computer scientist) ever since.

Thank you to Mek, Stephen, and Matt for taking a chance on me.

I appreciate the quick responses. Sincerely, best of luck.

By the way, you've left the notiz.dev LICENSE file in your server code, probably you want to remove that.

https://github.com/tegonhq/tegon/blob/158b54af8d6f7cf4195c61...

Separately, there seems to be a ton of unused or broken or dead code sprinkled throughout — for instance, in the auth code, I can't tell if you're doing basic email/password auth or using Supertokens and a third-party login via Google. You have code for both and some routes seem dead or missing.

https://github.com/tegonhq/tegon/blob/158b54af8d6f7cf4195c61...

Also, I mentioned the lack of documentation for how to run Tegon locally because your docs are entirely insufficient. The main docs page is just a README template. https://github.com/tegonhq/tegon/tree/main/docs

The quickstart guide has a broken link to instructions on how to self-host https://github.com/tegonhq/tegon/blob/main/docs/quickstart.m...

The oss/local-setup guide is entirely empty https://github.com/tegonhq/tegon/blob/main/docs/oss/local-se...

The oss/deploy-tegon guide does not explain anything and the script it references seems out of date https://github.com/tegonhq/tegon/blob/main/docs/oss/deploy-t...

I'm done looking at this project. I strongly recommend hiring the best engineer you can find as quickly as you can.

First, congratulations on launching. I think people are so used to seeing beautiful products these days that it can be hard to remember how hard it is to make anything. Nice work! With that out of the way, here is some critical feedback:

- What is the pitch that you made to YC that convinced them to back you? The market size just doesn't seem that large and I don't understand what will differentiate you from Linear (whose design language you seem to have ripped off, somewhat poorly.) This post and the current featureset is vague and does not seem like a significant improvement. What is the core problem you're solving and why is that valuable? Your launch post above describes a lot of "how" but not a lot of "why".

- Why are you bothering to pretend to be "open source"? You're backed by YC and you'll make money selling access to the product on your "Tegon Cloud". If you're really going to be open-source, you need to make some significant improvements before anyone would consider contributing. Some documentation on how to self-host would be a good start. Look at all the environment variables in this dockerfile — which ones are necessary to run this service myself? https://github.com/tegonhq/tegon/blob/main/docker-compose.ya...

- If you're going to be "open source", the quality of your codebase and engineering skills is going to be a deciding factor in whether or not you get outside contributors. Consider writing actual descriptions in your pull requests, describing what you've done and why. Here's a PR picked at random — this is bad engineering work and does not encourage others to contribute. https://github.com/tegonhq/tegon/pull/114

My advice is that you drop the facade of being "open source", hire a designer, and do some actual user research to figure out where people are actually struggling with their ticketing systems. The features you're building (automatic title suggestion, thread summarization, and "find similar tickets") do not solve the problems that I have had with ticketing systems. They're small, potentially nice-to-have features that absolutely do not help me understand the core question for all engineering teams: who is doing what, how will they do it, why, and when will it be done.

Extremely anodyne — given that the author has maintained FreeDOS for longer than I've been alive, I was hoping for slightly more interesting ideas than "have a website and be nice to people." Not that I disagree with his advice!

Looks totally fine at first glance. I'm happily using https://github.com/gorilla/sessions to handle cookies right now — OP, is there any reason I should want to switch to your library instead?

Makes sense, thanks for answering.

Aside — the architecture diagrams on https://xeiaso.net/blog/xesite-v4/ are not displaying in-browser for me, but do transfer correctly and are viewable on my computer. Maybe another mime issue, as the network inspector shows them being transferred with type "octet-stream"?

Repro by visiting the URL in latest Firefox, Safari, or Chrome.

Maybe I missed it, but why are you embedding a zipfile of gzip streams rather than just embedding the static site's files with an `embed.FS` and serving from that?

What are the downsides of enforcing squash-merge to main?

I think a lot of new entrants to previously-well-explored spaces tend to label themselves as "modern" in order to signify that there is something new about their approach.

For instance, I have a migrations library that I descibre as "modern" because it is designed for a continuous deployment environment where you're automatically running migrations on container startup — there are tons of existing popular migrations libraries, but none of them work this way because they were written in the era that you'd manually run sql commands in prod. I say "modern" so that if anyone finds my library, they realize that it was created recently based on more recent dev/ops trends.

Maybe I should drop the "modern"? I do see a lot of people describe their code as "minimal" or "clean", which is pretty meaningless to me, so I get that "modern" could come across that way as well.

Maybe. Frankly this is a very impressive outcome that is attributable both to the Father's business and management practices, as well as the Son's business and management practices. No matter how good you are at running a web business, if you inherit a totally fucked business with poor practices, very unlikely you could engineer this outcome.

My condolences to the OP and I was happy to read such a well-written article describing a fantastic outcome for his father's company.

Enforce squash merging to main and move on with your life. Linear history on main, individual contributors can rebase and merge or format-patch or do whatever they want on their PR branches and it doesn’t matter. There are zero downsides to this approach.

One more thing you could do is put the real name of any human being with any track record of professionalism, anywhere on the website. Currently you're:

- commenting under a pseudonymous profile

- asking for emails by saying "please email me. contact at cyberscarecrow.com"

- describing yourself in your FAQ entry for "Who are you?" by writing "We are cyber security researchers, living in the UK. We built cyber scarecrow to run on our own computers and decided to share it for others to use it too."

I frequently use pseudonymous profiles for various things but they are NOT a good way to establish trust.

Buttondown https://buttondown.email/

Shoot, this is a good reminder that I need to update my zine's mailing list. I'll be switching to Buttondown, definitely the spiritual successor!

Has anyone here used this, or anything similar? This sounds phenomenal if it really works. Looks like “contact us” is the only way to try it or buy it right now, and the purported benefit (memorize facts up to the model training size, basically trillions of tokens of facts) is wild. I’d love to try a system running this way to understand the failure modes, like for instance how does it reliably infer which “facts” to use?

I have immense respect for the OP for writing up the story, and even more so for giving this preface. It's really useful to know what mistakes other people make, but can be quite embarrassing to tell others about mistakes you've made. Thanks, OP.

Great writeup, bookmarked for any future case where I run into a similar problem.

Not sure I fully understand Pigweed — is it basically an open-source reimplimentation of Google's developer experience for doing firmware development?

https://pigweed.dev/docs/overview.html

(If you're reading this, hello Keir!)

I agree. Thankfully, you don’t have to take them and you don’t have to give them!

Yeah basically this!

Ha, I gave this exact speech at the 2021 Hasura Conference [0]. You hit the nail on the head.

Sometime in 2022 we switched back to REST endpoints for all of the reasons listed in the OP's article. Didn't hurt that we had hired for more fullstack engineers rather than "frontend only", so they saw exactly why we wanted to make the switch.

EDIT: to be fair, using Graphql and Hasura absolutely did help us iterate more quickly early on. But once we had a firmer idea of what we wanted to build, switching to REST was the right call. One of our most talented engineers wrote some helpers to make sure the frontend types were synced up with the backend types and that pretty much replaced the main benefit of using Graphql.

[0] https://hasura.io/events/hasura-con-2021/speakers/peter-down...

> JVector, the library that powers DataStax Astra vector search, now supports indexing larger-than-memory datasets by performing construction-related searches with compressed vectors. This means that the edge lists need to fit in memory, but the uncompressed vectors do not, which gives us enough headroom to index Wikipedia-en on a laptop.

It's interesting to note that JVector accomplishes this differently than how DiskANN described doing it. My understanding (based on the links below, but I didn't read the full diff in #244) is that JVector will incrementally compress the vectors it is using to construct the index; whereas DiskANN described partitioning the vectors into subsets small enough that indexes can be built in-memory using uncompressed vectors, building those indexes independently, and then merging the results into one larger index.

OP, have you done any quality comparisons between an index built with JVector using the PQ approach (small RAM machine) vs. an index built with JVector using the raw vectors during construction (big RAM machine)? I'd be curious to understand what this technique's impact is on the final search results.

I'd also be interested to know if any other vector stores support building indexes in limited memory using the partition-then-merge approach described by DiskANN.

Finally, it's been a while since I looked at this stuff, so if I mis-wrote or mis-understood please correct me!

- DiskANN: https://dl.acm.org/doi/10.5555/3454287.3455520

- Anisotropic Vector Quantization (PQ Compression): https://arxiv.org/abs/1908.10396

- JVector/#168: How to support building larger-than-memory indexes https://github.com/jbellis/jvector/issues/168

- JVector/#244: Build indexes using compressed vectors https://github.com/jbellis/jvector/pull/244

No — most constraint checks are by default deferred until the end of the transaction, but you'd still need to check them, and without an index you'll still have to do a large scan.

See https://www.postgresql.org/docs/17/sql-set-constraints.html for more information regarding constraint checking.

I agree with you. What I've done in the past (and continue to do with new projects) is write a database-backed test that:

- applies migrations

- parses the resulting schema

- finds all foreign key references: ref{tableA columnA -> tableB columnB}

- finds all the indexes: index{tableA columnA [columnB...]}

- checks that there is an explicit index for every reference column: index{tableA columnA} must exist

So basically, by default when you add a new foreign key, the tests fail until you either explicitly add an exception OR create the necessary index. Easy.

This strategy is also really nice for linting other relational properties in your database. For instance, for GDPR/CCPA/correctness purposes, you probably want to prevent deletion of certain rows unless it's done by specialized code with an audit log. These kinds of lints can check to make sure that there are no ON DELETE CASCADE foreign keys from those tables that would result in a surprise deletion. You can also check to make sure that foreign keys are either ON DELETE CASCADE, ON DELETE SET NULL, or explicitly covered by custom deletion code.

If you're using Go, sqlboiler can do this for you in most common cases (e.g., fetch all the Users matching this filter, and for each User, fetch the related Company)

https://github.com/volatiletech/sqlboiler

Fair enough, congratulations on your launch and I hope you see continued success!

This is a Show HN, so I replied with my feedback. The author explicitly invited this, too, by writing:

> Would love to hear what you think about it!