HN user

mustardo

282 karma
Posts0
Comments137
View on HN
No posts found.

Anecdotal but we certainly run flyway migrations with a high privelage user not the regular low privelage "app" user who can only SELECT UPDATE and sometimes DELETE. The fact that nobody does this doesn't mean it's a bad idea just a reflection on poor industry practice (add it to the list)

This! I've worked with a few developers I would consider net negative to their team and product, in that their removal would have increased 3-4 other team members productivity by say 20% each. Coincidently these developers were almost exclusively Indian immigrants. In organisation with poor corporate culture and the ZIRP (Zero Interest Rate Policy) days of hiring to signal growth and managers hiring to increase the number of reports (to signal importance) compounded the problem

I thought copy.fail is a privelage escalation exploit, become root from a regular user? Am I missing something?

How would "node architecture" make people vulnerable to this?

You have to have shell access to a victim first right? Or am I missing something?

In an interview with Zelinsky Trump asks "why haven't you had an election? " Zelensky : "because we are at war" you can see the idea percolating then. People think I'm a nutter for suggesting there just won't be another election but that's where my money is. I'm waiting for his version of the Gestapo, ICE seems to be a proving ground

Not even particularly elegant code, for example, opacity is clamped between 0 and 1 in in the very next line a bounds check is made anyway.

  opacity = (opacity < 0) ? 0 : opacity;
  opacity = (opacity > 1) ? 1 : opacity;
  if(opacity >= 0 && opacity <= 1) {
      document.getElementsByTagName("BODY")[0].style.opacity = opacity;
  }

Banks don't give out access to this API easily. Unfortunately it's not some OAuth thing that a new upstart accounting software could easily hook into, therefore the banks gate keep feeds to major accounting providers and no doubt charge excessively for the privelage. We need regulation to open feeds to anyone willing to consume them, or a bank to add it as a feature but why would they when they can charge Xero and MYOB to access proprietary feeds

100% this! One of the worst projects to reason about I have ever worked on (and I have worked on a lot of trash) was when a colleague insisted on implementing a state machine in a system that tracked voucher (offer) redemptions. State machines do have their place but coordinating business logic with one is a bad idea IMHO

This same colleague had implemented a similar FSM (flying spaghetti monster as known by the team) in an FX (foreign exchange) platform at a previous company. Which after a job change I got the pleasure of experiencing, nobody in the team knew how it worked and everyone was petrified of making changes

Never ending warnings you can't turn off and many other small things lead me to skipping small expenses and just eating them, because I can't be bothered to fight Concur.

Sometimes I wonder if this is a "feature not a bug" the company wins and saves money (in the short term)

It probably costs them via reduced employee happiness turnover etc etc indirectly but there is no KPI for that

You might want two or more routers (or network cards) on the same layer 2 (physical) network, if you buy two devices with the same MAC ARP (address resolution protocol) for example can't work. Typically the chip manufacturer "buys" MAC address ranges from IEEE, some cheap chip manufacturers won't. You can sometimes work around this in software by allocating a new random address to the interface

Using separate databases or schemas per tenant comes with the following problems

* Managing schema migrations across every DB

* You cant query across the DB, want to know some cross tenant thing for ops? That's now a lot harder

* Connection pooling and resource usage can be harder to manage

Most systems I've worked on use a single DB with a `tenant_id` col on every relevant table, it's easy to have your query builder slap in the auth'd tenant I'd. This approach does come with issues like saving and restoring an individual tenants data

Like a lot of things in life, it's a trade off

For your "maybe slightly better is" what happens when the db commit fails? FK constraint or some such, now you have sent an email (called the API) and have no record in your DB

Without two phase commits I would

1) Write to the DB in the original POST request a record indicating that an email should be sent 2) Process that record outside of the original request and mark it as sent