Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What the hell have you built

wthhyb.sacha.house

Post reply on HN
Print view View original

141–150 of 239 posts

Re: What the hell have you built

#141

Post by 9dev »

pjc50 wrote: post #117
9dev wrote: post #81

It's sure a corny stance to hold if you're navigating an infrastructure nightmare daily, but in my opinion, much of the complexity addresses not technical, but organisational issues: You want straightforward, self-contained deployments for one, instead of uploading files onto your single server. If the process crashes or your harddisk dies, you want redundancy so even those twelve customers can still access the appli…

I think that's a slightly different set of things to what OP is complaining about though. They're much more reasonable, but also "outside" of the application. Having secret management or CI (pretty much mandatory!) does not dictate the architecture of the application at all. (except the caching layer. Remember the three hard problems of computer science, of which cache invalidation is one.) Still hoping for a good "s…

> Having secret management or CI (pretty much mandatory!) does not dictate the architecture of the application at all.

Oh, it absolutely does. You need some way to get your secrets into the application, at build- or at runtime, for one, without compromising security. There's a lot of subtle catches here that can be avoided by picking standard tooling instead of making it yourself, but doing so definitely shapes your architecture.

Re: What the hell have you built

#142

Post by chistev »

tnel77 wrote: post #138
macspoofing wrote: post #127

Earlier quoted context omitted.

>It's sure a corny stance to hold if you're navigating an infrastructure nightmare daily, but in my opinion, much of the complexity addresses not technical, but organisational issues: You want straightforward, self-contained deployments for one, instead of uploading files onto your single server ... You can get all that with a monolith server and a Postgres backend.

In this job market, how am I supposed to get hired without the latest buzzwords on my resume? I can’t just have monolithic server and Postgres! (Sarcasm)

Indicating sarcasm ruins the sarcasm

Re: What the hell have you built

#143

Post by 9dev »

BlindEyeHalo wrote: post #109
Freak_NL wrote: post #94

Earlier quoted context omitted.

> You want a CI pipeline, so the junior developer can't just break prod because they forgot to run the tests before pushing. Make them part of your build first. Tagging a release? Have a documented process (checklist) that says 'run this, do that'. Like how in a Java Maven build you would execute `mvn release:prepare` and `mvn release:perform`, which will execute all tests as well as do the git tagging and anything e…

Why not do a CI pipeline from the beginning instead of relying on trust that no one ever forgets to run a check, considering adding CI is trivial with gitlab or github.

Because it adds friction, and whoever introduces that CI pipeline will be the one getting messages from annoyed developers, saying "your pipeline isn't working again". It's definitely a source of complexity on its own, so something you want to consider first.

Re: What the hell have you built

#144

Post by reactordev »

chistev wrote: post #142
tnel77 wrote: post #138

Earlier quoted context omitted.

In this job market, how am I supposed to get hired without the latest buzzwords on my resume? I can’t just have monolithic server and Postgres! (Sarcasm)

Indicating sarcasm ruins the sarcasm

Squint or pretend it’s not there. This crowd is hit or miss on picking it up o’ naturál.

Re: What the hell have you built

#145

Post by 9dev »

macspoofing wrote: post #127
9dev wrote: post #81

It's sure a corny stance to hold if you're navigating an infrastructure nightmare daily, but in my opinion, much of the complexity addresses not technical, but organisational issues: You want straightforward, self-contained deployments for one, instead of uploading files onto your single server. If the process crashes or your harddisk dies, you want redundancy so even those twelve customers can still access the appli…

>It's sure a corny stance to hold if you're navigating an infrastructure nightmare daily, but in my opinion, much of the complexity addresses not technical, but organisational issues: You want straightforward, self-contained deployments for one, instead of uploading files onto your single server ... You can get all that with a monolith server and a Postgres backend.

You don't. When your server crashes, your availability is zero. It might crash because of a myriad of reasons; at some times, you might need to update the kernel to patch a security issue for example, and are forced to take your app down yourself.

If your business can afford irregular downtime, by all means, go for it. Otherwise, you'll need to take precautions, and that will invariably make the system more complex than that.

Re: What the hell have you built

#146

Post by cluckindan »

kragen wrote: post #137
hinkley wrote: post #126

Earlier quoted context omitted.

Cache invalidation is replacing one logical thing with a new version of the same logical thing. So technically that’s also naming things. Doubly so when you put them in a kv store.

That angle seems potentially insightful, and I'm going to have to think about it, but to me, cache invalidation seems more like replacing one logical thing with nothing. It may or may not get replaced with a new version of the same logical thing later if that's required.

To me, cache invalidation is not strictly about either replacing or removing cache entries.

Rather, cache invalidation is the process of determining which cache entries are stale and need to be replaced/removed.

It gets hairy when determining that depends on users, user group memberships AND per-user permissions, access TTL, multiple types of timestamps and/or revision numbering, and especially when the cache entries are composite as in contain data from multiple database entities, where some are e.g. representing a hierarchy and may not even have direct entity relationships with the cached data.

Re: What the hell have you built

#147

Post by spoiler »

tnel77 wrote: post #138
macspoofing wrote: post #127

Earlier quoted context omitted.

>It's sure a corny stance to hold if you're navigating an infrastructure nightmare daily, but in my opinion, much of the complexity addresses not technical, but organisational issues: You want straightforward, self-contained deployments for one, instead of uploading files onto your single server ... You can get all that with a monolith server and a Postgres backend.

In this job market, how am I supposed to get hired without the latest buzzwords on my resume? I can’t just have monolithic server and Postgres! (Sarcasm)

You're sarcastic, but heavens above, have I had some cringe interviews in my last round of interviews, and most of the absurdity came from smaller start-ups too

Re: What the hell have you built

#148

Post by kragen »

cluckindan wrote: post #146
kragen wrote: post #137

Earlier quoted context omitted.

That angle seems potentially insightful, and I'm going to have to think about it, but to me, cache invalidation seems more like replacing one logical thing with nothing. It may or may not get replaced with a new version of the same logical thing later if that's required.

To me, cache invalidation is not strictly about either replacing or removing cache entries. Rather, cache invalidation is the process of determining which cache entries are stale and need to be replaced/removed. It gets hairy when determining that depends on users, user group memberships AND per-user permissions, access TTL, multiple types of timestamps and/or revision numbering, and especially when the cache entries…

Yes—and, in many cases, ensuring that you don't use entries which become outdated during your computation.

Re: What the hell have you built

#149

Post by spoiler »

9dev wrote: post #143
BlindEyeHalo wrote: post #109

Earlier quoted context omitted.

Why not do a CI pipeline from the beginning instead of relying on trust that no one ever forgets to run a check, considering adding CI is trivial with gitlab or github.

Because it adds friction, and whoever introduces that CI pipeline will be the one getting messages from annoyed developers, saying "your pipeline isn't working again". It's definitely a source of complexity on its own, so something you want to consider first.

U agree it adds a bit of complexity, but all code adds complexity.

Maybe interacted with CIs too much and it's Stockholm syndrome, but they are there to help tame and offload complexity, not just complexity for complexity'a sake

Re: What the hell have you built

#150

Post by lifestyleguru »

zargath wrote: post #38

you guys are going to miss the days of over-engineered microservice solutions when you are debugging ai workflows :)

It's like debugging the code of that guy who wrote most of the project, was consuming entire coffee in the office, outtalked everyone at the meetings, and then relocated for a new job to Zurich or London.
Post reply on HN