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".
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!"
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
I'd say Scrum is more about creating business value than user facing change. It is the business that consistently doesn't value long term value generation, not the process.
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.
"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
They can and do. There is risk of a fine. However there is the capability to disrespect the law and do what you like, an attractive option when the alternative is to prostrate oneself beneath non-Canadian jobseekers competing for the same positions internationally.
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
reply