ownagefool

Like cool, it's a great idea and would potentially produce positive results if done well, but the roles pay half the engineering roles, and the interviews are stacked towards compliance frameworks.

There's very little ability to fix a large public company when HR is involved

1. Users - your users table may not benefit by being ordered by created_at ( or uuid7 ) index because whether or not you need to query that data is tied to the users activity rather than when they first on-boarded.

2 Orders - The majority of your queries on recent orders or historical reporting type query which should benefit for a created_at ( or uuidv7 ) index.

Obviously the argument is then you're leaking data in the key, but my personal take is this is over stated. You might not want to tell people how old a User is, but you're pretty much always going to tell them how old an Order is.

Especially when folks are trying to push % based test metrics and have types ( and thus they tests assert types where the types can't really be wrong ).

I use AI to write tests. Many of them the e2e fell into the pointless niche, but I was able to scope my API tests well enough to get very high hit rate.

The value of said API tests aren't unlimited. If I had to hand roll them, I'm not sure I would have written as many, but they test a multitude of 400, 401, 402, 403, and 404s, and the tests themselves have absolutely caught issues such as validator not mounting correctly, or the wrong error status code due to check ordering.

A platform for digital asset management, review and workflow. Current features focus primarily on review of images aimed at automotive configurators.

The problem is generic, however, our USP is we have a couple of enterprise customers that upload packs of 60k+ assets for a round, and thus we aim to help discover what demonstrably changed.

A bit like Github, only working with images, videos, and other digital assets rather than text files.

If your average zoomer had the ability to get a job for life that paid comparably well by a company that would look after them, I don't think loyalty would be an issue.

The problem is today, sticking with a company typically means below market reward, which is particularly acute given the ongoing cost of living crises affecting the west.

I was engaged after one of the worlds biggest data leaks. The Security org was hyper worried about the cloud environment, which was in its infancy, despite the fact their data leak was from on-prem mainframe style system and they hadn't really improved their posture in any significant way despite spending £40m.

As an aside, I use NATs for some workloads where I've obviously spent low effort validating whether it's a great idea, and I'm pretty horrified with the report. (=

You have two poles here.

1. The VC route, strikes gold, and never really needs to live with the reality of asking what an ROI is, it's all talk about spotlight, impact and value, without any articulation about cash money.

2. The MBA route where you effectively can't brush your teeth without a cost/benefit analysis that itself often cost multiple times your initiative, resulting in nothing getting done until you're in some tech debt armageddon.

The reality is if you're still making bank on the abstract without being able to articulate revenue or costs, you're probably still in the good times.

1. Router

Tanstack Router: Supports runtime validation libraries such as z0d. So I have routes such as example.com/viewer/$uuid/$number, it should 400 if those aren't actually validate uuid and numbers.

React Router: Supports Types, but every type is a string because, well, they technically are, but this isn't useful in practice in my opinion. There are 3rd party libs such as: https://github.com/fenok/react-router-typesafe-routes

2. API

Lets say you're making your API public to clients you can't trust to send the correct data ( which probably also includes your own client ).

https://www.npmjs.com/package/express-openapi-validator

This library advertises validating both your input and your output

3. State

https://github.com/pmndrs/zustand/discussions/1722

4. Database

https://www.npmjs.com/package/prisma-zod-generator

5. Forms

https://medium.com/@toukir.ahamed.pigeon/react-hook-form-wit...

6. ENV

https://jfranciscosousa.com/blog/validating-environment-vari...

Obviously checks on the agent are primarily a DX/UX thing, whilst checks on the server step are also security controls.

Writing TypeScript is better than JavaScript, but the lack of runtime protection is fairly problematic.

However, there are libraries such as https://zod.dev, and you can adopt patterns for your interfaces and there's already a large community that does this.

It's one of the few CI tools where you can test your pipeline without committing it. You also have controls such as only pulling the pipeline from trunk, again, something that wasn't always available elsewhere.

However, it can also be a complete footgun if you're not fairly savvy. Pipeline security isn't something every developer groks.

I think it's still just 2 poles. However, I probably shouldn't have prescribed motivation to latter pole, as I purposely did not with the former.

Pole 2 is simply never adopt anything new ever, for whatever the motivation.

DevOps is a culture. It can also be the specific subset of highly skilled individuals who were part of or an outcome of said cultures cross pollination. Today DevOps most often means fairly unskilled person hitting pipelines with hammer.

In the end, the same old people with the same old commercial interests adopted the term in a way that benefited them but changed the meaning of the term because change was not actually something anyone wanted.

There's poles.

1. Is folks constantly adopting the new tech, whatever the motivation, and 2. I learned a thing and shall never learn anything else, ever.

Of course nobody exists actually on either pole, but the closer you are to either, the less pragmatic you are likely to be.

The consequence of running a database poorly is lost data.

At the end of the day they're all just processes on a machine somewhere, none of it is particularly difficult, but storing, protecting, and traversing state is pretty much _the_ job and I can't really see how you'd think ingress and DNS would be more work than the datastores done right.

Now with AWS, I have a SaaS that makes 6 figures and the AWS bill is <$1000 a month. I'm entirely capable of doing this on-prem, but the vast majority of the bill is s3 state, so what we're actually talking about is me being on-call for an object store and a database, and the potential consequences of doing so.

With all that said, there's definitely a price point and staffing point where I will consider doing that, and I'm pretty down for the whole on-prem movement generally.

Pretty much everything that's been layered on top though has either nothing to do with the manifesto, or actively breaks it. i.e. there's a burning issue, I'll get to that after my sprint commitment, which was sold to let me finish work, but now only exists to stress me out to squeeze more widgets per unit of time, where the widgets pretty much never actually map back to anything actually tangible.

For me, I usually try to avoid anything where the working practices are strongly defined. Agile has long been a bad word.

I'm glad you're doing well now.

Reporting on your Ordering System is an OLAP problem though. Generally an OLAP database stores data on disk in a way that it only needs to read the selected columns and the performance is better with wider columns, i.e. lots of duplicated data ( JOINs are slow ).

So like, you select * from Customer, Order, Items, Device, Staff, stick it in your OLAP database that's where customers should generate reports. This both makes reporting more performant, but it also removes the problem from the critical path of your POS device syncing and working.

This has the added benefit that updating your product name won't update the historical log of what was done at the time, because what was done at the time was done at the time ( but you can still map on like productId if you think the data is relevant. )

At scale you want to pop the writes on a queue and design those devices to be as async as possible.

This is what happens when you just build it pure OLTP.

https://www.linkedin.com/pulse/nobody-expects-thundering-her...

This was an ~£19m ARR POS company dying because of architecture, now doing £150m+ ARR. ( the GTV of the workloads are multiple times that, but I can't remember them ).

You wouldn't be publishing patient visits publically, the only folks that'd legitimatly see that record would be those which access to that visit, and they'd most likely need to know the time of said visit. This access should be controlled via AuthN, AuthZ and audited.

You'd also generally do a lot of time-based lookups on this data; what visits do I have today, this week, and so on. You might also want an additional DateTime field for timezones and offsets, but the v7 is probably better than v4 for this usecase.

You probably shouldn't / don't need to use v7 for your Users table because the age of your User probably has limted to no bearing on the look up patterns. For example, our Steam and Amazon accounts are pretty old, but we likely still use them.

However, your Orders table is significantly more likely to be looked up based on time, so a v7 makes a lot of sense here.

Now I'd argue the security implications are overblown, but in general tems you might also allow someone to look up a user, i.e. you can view my Steam profile, or maybe my Amazon wishlist. You probably don't need to be looking up another Users Order.

Alternativly, if your building an Enterprise Risk Solution, you could take a view that you don't want people knowing how old the risk is, but most solutions would show you some history and would believe that to be pertinent information.

There will be instances of getting it wrong, but it isn't actually _that_ complicated.

Manual long term keys are frowned upon due to potential keyleaks, such as heartbleed, or admin misuse, such as copy of keys on lots of devices when you were signing that 10 year key.

Automated and short lived keys are the solutions to these problems and they're pretty hard to argue against, especially as the key never leaves the server, so the security concerns are invalid.

That's not to say you can't levy valid criticism. I'm not sure if the author is entirely serious either though.

p.s. Certbot and Cert-manager are probably fine, but they're also fairly interesting attack vectors

"Vite+ will be source-available and offers a generous free tier."

I'm also a developer ( sometimes ) and we need to eat. However, for me these tools are too low of a level of he stack to monetize, so I'll probably stick with my collection of free tools.

Typically a strongly consistent (CP) system works by having a single elected master where writes are only ack'd when they're written to the majority of the cluster. The downside of this system is you need majority of the cluster working and up-to-date and the performance impact of doing this.

A multi-master system is generally ( AP ) allows writes to any master node, but has some consensus algorithm where it picks and chooses winners based on conflicting writes. It should be faster and more available at the cost of potentially lost data.

There are some systems that claim to beat CAP but they typically have caveats and assurances that are required. After-all, if you ack a write, and then that node blows up, how will it ever sync?

I'm cool with other reasonble approaches though, but I'm pretty over pointless hoops because someone says so.

Suddenly you're in a team with 2-3 people and one of them likes to git push broken code and walk-off.

Okay, lets make this less about working with a jack-ass, same setup, but each 5 minutes of downtime cost you millions of dollars. One of your pushes work locally but don't work on the server.

The point of a more structed / complex CI/CD process is to eliminate failures. As the stakes become higher, and the stack becomes more complex, the need for the automation grows.

Docker is just a single part of that automation that makes other things / possible / lowers specific class of failures.

I worked on FlexiScale, https://en.wikipedia.org/wiki/FlexiScale. The Architecture of IaaS provider doesn't need to look massively different from k8s.

- Node Agent that either listens or connects back to an API for instructions. - An API to request your workload. - Various decision daemons. IPAM, Block Storage, Etc.

What's missing in Europe is a Culture of Tech Leadership and Investment.

Case in point, I wrote or rewrote borderline 100% of an early European Cloud Provider, and I've never heard of nor been approached to work for another project like this. Even if one existed, they likely wouldn't come anywhere near offering a salary I'd be interested in, and leadership would almost certainly be full of people who haven't built a Cloud Provider before.

( This isn't so say I'm the most credible candidate in the market, but I have had salaried offers for IC in Meta and HFT in London. I'd have loved to build another cloud provider ( with more than a team of 3-5 ) but I've spent most of my career as a contractor interfacing with "cloud" teams offering things like vsphere, wondering where it all goes wrong. )