nuschk's comments

The code is very dense. Clear, concise, elegant. But dense. An LLM doesn't generate code like that.

I think it's perfectly doable to use an LLM to write into the Django codebase, but you'll have to supervise and feedback it very carefully (which is the article's point).

Would a company paying 600k per month not also be able to employ a couple of devs to improve the situation? Sure, effort is required, but with the right people they could save a ton and have a very good ROI.

I think it's just more complicated than that. No hostage situation, just good old incentives.

As long-time (and happy) DRF user of more than 7 years I've recently switched to django-ninja [1]. It's like FastAPI, but for django. Granted, I've only used it for a couple of months now, and also not in production yet. But I think it's pretty nice and a breath of fresh air for django. The thing you get from using it is full typing and IDE support (autocomplete!). It's using pydantic instead of DRF's serializers. Can definitely recommend so far.

[1] https://django-ninja.rest-framework.com

edit: typo

I'm pretty much looking for the same. AFAIK, autocomplete is provided by bing/azure, mapbox, tomtom, HERE and geocode.earth (I might also be missing a few). Also, mapfit (a pretty young participant, it seems) will have it "in a month", they say.

Edit: Added geocode.earth.

IMGIX (a image scaling service) used to use Mac Pros [1]. Dunno if they still do though.

[1] http://photos.imgix.com/racking-mac-pros

I'm relieved, thanks guys. I really don't see the complexity when deploying to a (managed) k8s cluster. Sure, we'll still have to configure a deployment pipeline, add some scripts to push and deploy the right images etc., but overall, k8s seems really well suited to the task.

Re 1: Why wouldn't you recommend going with kubernetes? From someone that hasn't deployed anything with it (yet), it seems rather straight-forward if run on a managed cluster (gke). I might be wrong and am thus genuinely interested in what you did for deployments.

flatfox.ch | Switzerland, on site | Full-time, all levels

flatfox is a proptech startup building a next generation SaaS for landlords. We are looking for devs with high ownership who like to move fast and have an impact with our customers. We're small, you're going to be one of the very early hires, so, lots of opportunity to make a dent.

We need:

* Full-Stack Engineer (django/kubernetes)

* Mobile Engineer (Android/iOS, react native)

Apply here if interested: https://flatfox.ch/en/jobs/ or questions to [email protected]

It's in beta currently [1].

Last time i checked (4 months ago, with a hobby project) it felt already pretty mature.

[1] https://cloud.google.com/appengine/docs/flexible/

Same here. Had a chat with the support team and they say they had to allocate a number of new IPs, since some of their existing IPs were blacklisted. Now they need to warm up the new ones first, which may take an undefined amount of time.

Support was very helpful and migrated our traffic to already warmed up IPs.

Well, finance takes also a large chunk of Switzerland's GDP and thus is scooping up many engineers as well. Maybe it's not as pronounced as in London, but it certainly isn't very easy to hire good engineers here because of all the banks and hedge funds.

I think google came to Zurich because of EPFL/ETH, the very high living standard and most of all the rather liberal labor law. It's very easy to fire someone in Switzerland, compared to the surrounding countries.

Doesn't seem like it. I too was hoping for this.

We're also using redux in production, after having switched from reflux. In redux, it's so much more clear where to put stuff.

In reflux, it was never clear to us whether certain async server operations should be handled in stores or in the actions. In general, you would always want them to be with your actions. Though every time you need a store variable to do the server call, you end up putting code in the store again (or passing the needed state through your react components, which is even uglier).

Not so in redux, where you have access to the stores in your actions. This way, stores get really dumb, which is the way they should be IMO.

And, btw, replacing reflux by redux is relatively easy and straightforward, as the same general concepts (flux) apply.

I also find the redux code easier to read, as the whole library is doing less (while achieving the same).

Well, economists often suggest a better way than just let the rich take over: directly subsidize people, not flats. So, if you want a neighborhood to not just attract bankers but also families with kids, pay the families for living there! The idea is to pay them only while they live there - independently of which accommodation they choose - and stop the payments when they move away. This way, the market isn't distorted, people don't get "sticky" in their ability to move to other apartments, and the whole setup is much more fair, as it's pretty easy to control who gets which benefits.

The downside, of course, is that the cost of such payments is far more transparent to the public. Many economists would argue that it's in fact much cheaper, as you it's more efficient. Still, today's subsidies are well hidden and almost never show up in household budgets. And thus it's hard to get to a system of direct payment.

Might I ask: If you're moving away from Marathon, where are you moving to? Kubernetes?