aidos

Exactly. Depending on where you live it’s hard to impossible to get permission to go above the existing ridgeline of the house, leaving people to poke flat roof dormers out the side.

Flat roofs don’t have to leak. I’m doing an EPDM roof on my garden office at the moment. It’s a single huge sheet of rubber.

As others have pointed out, the lack of eaves is the real killer. My dad was over from NZ in the summer and he was saying that fashion is there too. It’s causing all sorts of water issues for buildings.

Golly, QUALIFY, a new SQL operator I didn’t know existed. I tend not to do much with window functions and I would have reached for a CTE instead but it’s always nice to be humbled by finding something new in a language you thought you knew well.

Having flashbacks to the time where we had paid for a server and were paying for rack space for a customer and they were refusing to pay their bill. Our lawyers told us in no uncertain terms that turning off the server would be a terrible idea. “Obstruction of service” is the term that comes to mind.

Gotcha, thanks for the clarification. I’m not sure what that would buy me here.

I have a rule that I only async if it’s a requirement. In my case I can carry out all the steps in a single (simple) sync action. Our updates are optimistic so we update all the models immediately and mobx reflects that in the react components on the next frame.

The network request for the mutation is the only thing that’s running async. If that fails we crash the app immediately rather than trying to rollback bits in the frontend. I know that approach isn’t for everyone but it works well for us.

Exactly that. It’s tempting to try to combine them - we’ve all been there. They’re subtly but inherently different, in my experience.

I’m not quite seeing what you mean. What you mind redoing the example above for my benefit?

We have controllers that all the users actions are funnelled through. The top level functions in there are wrapped in transactions so in practice it’s not something you manually wrangle.

I didn’t clock the use of “triples” as the store on first read. That’s a non-starter for existing dbs and pretty much a dead end for anyone who eventually wants a db structure they can use outside of this model.

We have an internal lib for data management that’s philosophically similar to linear too. I opted for having required transactions for developer safety.

Imagine that you support the model discussed above where it’s possible to update the local store optimistically without syncing back to the db. Now you’re one missing .save() away from having everything look like it’s working in the frontend when really nothing is persisting. It’s the sort of foot gun that you might regret supporting.

Our model is slightly different in that we require the .save() on objects to create the mutation for the sync. The primary reason is that we’re syncing back to real tables in Postgres and require referential integrity etc to be maintained.

    tx((db) => {
      const author = new Author(db)
      author.save()
      article.name = “New name”
      article.author = author
      article.save()
    }

Mutating an object outside of a transaction is a hard error. Doing the mutation in a transaction but failing to call save within the same transaction is a hard error too.

This looks great. We use our own version of something much more naive which allows for the various benefits you have (but yours does more). Ours is also based on Linear but we go all in on mobx like they do too. It’s a great model where we have optimistic updates and a natural object graph to work with in typescript. I’ll have a play with this to see if it could eventually be used as a replacement.

Noticed in your docs you say that Hasura uses RLS for permissions but that’s not true. They have their own language for effectively specifying the filters to apply on a query. It’s a design decisions that allows them to execute the same query for all connected clients at the same time using different parameters for each one.

Fairly sure the linters would catch that (unless you referenced both of them in later code).

> The review comments should not be a stream of consciousness but properly written feedback.

My advice would be to not take it so personally and assume good intentions from your reviewers.

If someone gave me feedback that caused a big course correction then I’d slap my forehead for missing it, thank them, then move on with my life. The extra feedback of other issues is a bonus. Asking them to spend more time reviewing their review is wasted effort.

For me there’s only one thing that matters - you’re all working together to put good code into the system.

If you work in an environment where people lord code review over you in any way then you’re on a hiding to nowhere. That applies equally if you expect reviewers to not, you know, review your code.

I see this discussion of “nitpicks” constantly. If it’s a tiny thing that brings the code in line with the existing codebase then just do it rather than fighting it. If there’s some ambiguity then find a rule as a team and apply it.

I have no idea how people work in environments where you’re not all working together.

It’s effectively a subtle phishing attack (where a wrong click is game over).

It’s clever, and the probably the tip of the iceberg of the sort of issues we’re in for with these tools.

Ah! So that’s a spot where we’re talking past each other.

I’d anticipate you would be equally as able to ssh to VMs on dev laptops. That’s definitely a prerequisite for making this work in the same way as you’re currently doing.

The only difference between what you do and what I’m suggesting is the location of the VM. That itself creates some tradeoffs but I would expect absolutely everything inside the machine to be the same.

Sounds like you’re talking about something else (more like the Citrix / virtual desktop type model - I don’t know the name).

The idea here is that you use a VM (cloud or local) to run your compute. Most people can run it in the background without explicitly connecting to it.

So the devs don’t have the ability to ssh to your cloud instances and change config? Other than the size issue, I’m still not seeing the difference. Take your point on it needing to start before you have control, but other than that a VM on a dev machine is functionally the same as one in a cloud environment.

In terms of needing to reset, it’s just a matter of git branch, push, reset, merge. In your world that sync complexity happens all the time, in mine just on reset.

Just to be clear, I think it’s interesting to have a healthy discussion about this to see where the tradeoffs are. Feels like the sort of thing where people try to emulate you and buy themselves a bunch of complexity where other options are reasonable.

I have no doubt Stripe does what makes sense for Stripe. I’d also wager than on balance it’s not the best option for most other teams.

PS thanks for chiming in. I appreciate the extra insights and context.

I don’t know that’s safe to assume. Maybe it is an issue but it was not one of the issues they talk about in the article and not one of the design goals of the system. They have the proxy / lazy start system exactly so they can limit the services running. That suggests to me that they don’t end up needing them all the time to get things done.

For sure, but, a VM has that feature too. They have to run some services directly on the laptop to handle the code syncing. So if you accept a certain amount of “need to do some dev machine setup” as a cost, installing Parallels and running a script to download an iso is a pretty small surface area that allows for a full reset.

I don’t doubt that Stripe have a setup that works well for them them but I also bet they could have gone done a different path that also worked well and I suspect that other path (local VMs) is a better fit for most other smaller teams.

I want to double check we’re talking about the same thing here. I’m referring to running everything inside a single VM that you would have total access to. It could have telemetry, you’d know versions etc. I wonder if there’s some confusion around what I’m suggesting given your points above.

I’m sure there are a bunch of things that make it the right choice for Stripe. Obviously if you just have too many things to run at a time and a dev laptop can’t handle it then it’s a dealbreaker. What’s the size of the cloud instances you have to run on?

You could still run the proxy they have that lazy boots services - that’s a nice optimisation.

I don’t think that many places are in a position where the machines would struggle. They didn’t mention that in the article as a concern - just that they struggled to keep environments consistent (brew install implies some are running on osx etc).

Due to the work that this team put in though, right?

The choice to run dev environment far away from the files puts you in the position of needing to engineer your way past the inconsistency.

Maybe a silly question, but why all this engineering effort when you could host the dev environment locally?

By running a Linux VM on your local machine you get a consistent environment that you can ssh to, remove the latency issues but you remove all the complexity of syncing that they’ve created.

That’s a setup that’s worked well for me for 15 years but maybe I’m missing some other benefit?

Why would you feel obliged to accept a MR in which someone has accidentally changed large amounts of code?

> In practice, none of the day-long plans are actually a day. The gun isn't actually to your head. You can go home and sleep.

> hardware hasn’t been upgraded since 2017

What? They switched architecture to an amazing new chip series since then. I’d go even further and say that the era before then was the lost era of rubbish keyboards and strange gimmicks (looking at you, touchbar).

Do you have another link -that one’s not working for me

Unless something has changed, VSCode runs in a server / client model with the FE on your local machine and the code / language servers running remotely (I don't use it, I stick to neovim).

I find GitHub to broadly be ok.

One exception I have is for code reviews, arguably its most important usecase. Once there’s a little back and forth going on and a few rounds of things being fixed it becomes really hard to find a list of the comments. Maybe I’m just missing it somewhere but spread in the conversation tab it’s impossible to find things.

I’ve resorted to a couple of scripts that pull all the threads down into a file I can open in vim. Then I have a shortcut for jumping to the corresponding location in the code. Works well, but seems really unnecessary.

Countfire | Senior Fullstack and backend Developers| Remote (but must based in UK) | www.countfire.com

Countfire makes software for the construction industry. Our software is well loved because we try to design solutions that are a magnitude more efficient than existing tools. We use all sorts of tech, but mostly MobX, React, Typescript, Python, Hasura, Postgres, Terraform, and AWS.

We have a great loyal customer base and lots of exciting ideas that need bringing to life. Previously based in London, now seeking remote devs across the UK.

More info here https://www.countfire.com/careers/

Feel free to contact me directly aidan@countfire.com

Note, applicants must be resident in the UK. No recruiters.

That always felt like such a meaningless statement to me.