tartieret

having built two enterprise data platforms in python, I can't disagree more. for a startup, development velocity matters more than code performance especially for a CRUD app even at medium scale. Frameworks like Django simply enable you to do so much and so quickly. and you can reach world scale, that's what Instagram did!

I have definitely noticed this in our organization as people use more AI tools. At first educating by providing feedback to the developers, then after a few repeat directly requesting that a PR is broken down if there is an obvious way to do it.

But the thing that really made the differences: 1) having a small github action that checks the size of a PR and leave a warning comment if it's large. Obviously some PR have to be large but then the developer has to justify 2) much better: getting early access to Github Stacked PR. we all like the experience and it solves a number of problems. without it even if you are disciplined and break down your work on several PRs, you end up having to deal with rebasing them one by one when the base moves. We modified Claude.md so that it tries to use it when it makes sense and now even AI generated changes result in stack of small PRs

I think it's worth investing in this as there are studies showing that review time is exponential with the size of PRs (or worse you are more likely to let defect go through on a large PRs). And AI agents are also better are reviewing smaller chunks.

I had personally several experiences of asking someone to break down a super large PR into smaller ones and found a defect in PR#2 which wasn't caught in the original AI driven PR review

Over the last 6-9 months, I build an app to calculate the optimum jet lag management plan from a combination of flight. It tells you the optimum times for light exposure, sleeping, taking coffee...

It started with a naive "I know the tricks, let put them in an app" based on my own travel experience and quickly turned into a pretty nasty constrained optimization problem to optimize a cost function while keeping the schedule realist. So far I have been slowly releasing with friends and family, but I am pretty happy with the results as it can handle pretty complex combination of flights and layovers, compared to other similar apps.

If anyone wants to poke at it, I'd love to have some feedback! https://www.jetlagcoach.com

After ~20 years of long-haul travel, I spent the last 9 months building Jetlag Coach, in parallel with my busy life (full time job toddler and pregnant wife!). You give it your chronotype and your actual itinerary (multi-leg and layovers included) and an optimization engine generates a personalized schedule for light, sleep timing, caffeine and melatonin to shift your circadian clock toward the destination time zone.

At core it turned out to be a complex optimization problem and a real challenge to tackle. I also put a lot of care in the UI/UX, while I usually focus more on backend work. It's working well, I am just finalizing the handling of some of the nastier edge cases

https://www.jetlagcoach.com

have you considered Capacitor? it works pretty well for cross platform web development

There is definitely some confusion on the EU part. I am a European citizen, but some of my activity data on some of the sites I host is logged in US Posthog, which means Posthog is subject to the GDPR, even if the data is US hosted!

this is what triggered my post. The announcement pretends that it's not bug deal because of "anonymization" but that's easier said than done. You can send custom events and logs that contain confidential information even if it doesn't contain personal identifiers

I fixed the title, sorry for the typo!

I initially used Posthog as an alternative to Google Analytics with more privacy. Now they want to use the data for a business purpose. Working hard towards enshitification?

why not swarm? it's basically the same yml file except that you can do zero downtime deployment, simply with docker stack deploy -c stack.yml (swarm will outline the image, warm up the container and switch traffic automatically). roll backs are also included for free. it's part of docker so no additional dependency

It seems that the author thinks that AI use is limited to developers, I don't understand how short slighted is the debate between CLI and MCP. Sure, CLI are more convenient, but currently most AI users consume LLM through online tools like ChatGPT

A basic example: a company using ChatGPT or Claude, and wanting to connect their business tools (ex: marketing, sales, project management...). in that case MCP is perfect from an enterprise point of view, and the integration can be managed at the company level.

MCP includes a standard for some more advanced capabilities like: - tool discovery: for instance you can "push" an update from the server to the client, while with OpenAPI you have to wait for the client to refetch the schema - background tasks: you can have a job endpoint in your API to submit tasks and check their status, but standardization on the way to do that brings additional possibilities on the client side (imagine showing a standard progresss bar no matter which tool is being used) - streaming / incremental results / cancellation - ...

All of this is http based and could be implemented on a bespoke API but the challenge is cross-API standardization so that agents can be trained on representative data. The value of MCP is that it creates a common behavioral contract, not just a transport or schema.

I was a little puzzled as we got notified our apps were down, and then I tried to login in the Azure portal with no success. But the Azure status page reported no incident, so I posted here and quickly confirmed that others were impacted! They did a pretty bad job with their status page as the front door service was shown green all along

it took a good half hour after we detected the problem to see a notification on the Azure status page. Thanks to those who responded to my question as it validated the issue was global and we contacted our users t right away

Microsoft posted an update on X: https://x.com/AzureSupport/status/1983569891379835372?ref_sr...

"We’re investigating an issue impacting Azure Front Door services. Customers may experience intermittent request failures or latency. Updates will be provided shortly."

I agree with your analogy with pair programming. Except that now your co-developer types way faster!

The business cost with PRs isn't the first review but another developer, it's the number of iterations on a pull request due to defects and change requests. The way I am trying to promote the use of LLMs with more junior developers in my team (I am the CTO) is to use AI-assisted tools (we used Windsurf and recently switched to Github Copilot) for a first pass, e.g asking the agent for a review and catching potential defect before involving the human reviewer.

This doesn't mean the human reviewer will need to spend less time reviewing, but potentially this PR will be merged faster with on average a lower number of iterations and improved code quality.

I do have in my team some senior developers that are excellent, and it's very very rare I catch an issue in their PRs (maybe 1 out of 50). But I also have greener developers for who the ratio is way higher (like 8 or 9 out of 10) and this means repeated context switching for the reviewers.

As a CTO of a small company, spending a lot of time reviewing other developers' PRs, I completely agree. I recently enabled Github Copilot Agent and use it a lot for dealing with smaller and lower priority tasks in an async workflow (e.g. while I am doing other things). A lot of developers are not very good writers, and reviewing PRs from Copilot, with access to the full "thinking process" and being able to request changes in a few comments is sometimes more pleasant and effective

I absolutely love your summary

we have standardized on windsurf in my company. Cursor was part of the review but Windsurf has better support for dev containers and development on WSL, which most of our developers use. So beyond the actual AI part, there are some surprisingly rough edges with Cursor (using it with WSL is super hacky)

Developers tend to consider that picking a cloud provider is a technical decision, but it's actually a business one. If you aim for B2B, there is a massive incentive to use Azure, as your clients are typically Microsoft users. From there, you can benefit from coselling programs and the cost of your solution can look more attractive to your clients as they can include your license in their overall Azure/Microsoft spend.

Granted, the price of services is higher than on other platforms, but you would be mistaken to thing that's the price you are paying at scale, on a multi-year deals with reservations.

If I were to start a B2B startup I'll definitely go with Azure. For B2C or e-commerce, I'll probably look at others

>> Washington Post owner Jeff Bezos said Wednesday that the newspaper’s opinions section would now be focused on “personal liberties and free markets” and won’t publish anything that opposes those ideas.

I am French & Canadian, so I don't have a stake in this, but it's crazy to see what's happening in the US right now, in the name of "Freedom of Speech".

Great overview thanks

I just reviewed uv for my team and there is one more reason against it, which isn't negligible for production-grade projects: Github Dependabot doesn't handle (yet) uv lock file. Supply chain management and vulnerability detection is such an important thing that it prevents the use of uv until this is resolved (the open github issue mentions the first quarter of 2025!)

Managing static assets in Django applications deployed with Docker can be tricky, especially when dealing with deployment rollbacks and static file optimization.

I wrote an overview of the challenges of handling static assets with Docker, and how using versioned static files can help streamline deployments, improve rollback efficiency, and avoid overwriting critical assets.

If you're managing static files in a Dockerized Django setup, this post covers: - Common issues with running collectstatic during deployment. - The pros and cons of running collectstatic during Docker build. - A solution for versioning static assets using semantic versioning to ensure consistency and simplify rollbacks.

"Recently, a tricky concurrency bug in our distributed data platform was escalated to me—one that had stumped the entire team for months due to gaps in understanding transaction isolation and concurrency issues (despite having CS degrees!).

Inspired by this experience, I wrote a simple, practical tutorial using a Django app as an example.

This is a new exercise for me since I’m often too busy to write public-facing content (seriously, how do people find the time for blog posts??), but I hope it helps others avoid the same headaches!"

Yes, the goal is to generate business value. But Scrum requires to do this in small increments, and these increments have to be exposed to stakeholders. As per the Scrum guide (https://scrumguides.org/scrum-guide.html#increment):

"In order to provide value, the Increment must be usable."

So this conflicts with the fact that business value can be generated (or protected, in the case of maintenance/upgrade of a system) without generating immediately "usable" changes. Or said otherwise, a high value change may requires a succession of non-usable changes over many "sprints", and Scrum doesn't account for that.

I used Scrum with my teams for about 1.5 year, and tried hard to adjust the framework. Then we switched to Kanban, which matches much better the realities of an innovative and B2B product.

The main benefit of scrum is that it forces stakeholders to discuss goals and priorities.

But the framework itself has flaws in its philosophy. The Scrum book is adamant that the results of a sprint should be a user facing change, which doesn't always aligned with the "path of most value generated" that an organization should follow. For instance my team is working right now on transitioning our data storage system to a different offering in Azure as the type of PostgreSQL service we use is being retired. That's a non user facing but imperative change. Similarly, as our products are getting mature we work on both incremental improvements and longer term (6-12 months) ML/AI projects which are discussed with our clients. Our product manager has to be involved with those too and sometimes prioritize engineering work related to them. Scrum simply ignore this reality of operational tasks, and medium/long term value generation

"Engineer" is a regulated title in Canada, and non-registered professionals cannot call themselves "Software engineers". The government of Alberta just changed this rule for their province

Does anyone knows any alternative simple open source MDM solution that works with Windows, Linux and Mac?

I still use Docker Swarm in production, but the main issue is the lack of support from cloud provider and tooling. For instance, there is no good solution like ArgoCD for continuous deployment and updating your stacks. In addition, if you want to be able to automatically add a new node to the cluster, you basically have to write some infrastructure code by yourself. This makes infrastructure as code / configuration as code a pain, and these things are required to be compliant with stuff like SOCII