innomatics

This just a beautifully presented and informative article.

It's the kind of content I'd like to see so much more of on the web. A good news story using color and animation to teach science. Something to share with kids.

I agree that Scrum is fragile but not that it isn't agile.

It's agile up to the point that it is broken, which happens often due to it's fragility. That it is easily broken is an unfortunate but unavoidable consequence of its complexity, and common misunderstandings/misuses.

Scrum is complex because large software projects (large as in number of people, budget and expected velocity) are never simple to manage. Scrum is complex because correct usage can not be read from a book nor gained from a qualification - it requires experienced judgement to pick the optimal usage and apply it to a team and project.

Nothing can beat the effectiveness and efficiency of a single strong developer working on a stream of well considered backlog items. That is engineer nirvana! However many projects simply require more velocity than one person can manage. From here, there is a whole spectrum of processes that should be chosen depending on resources and needs. From my experience, full scrum kicks in once you have four or five engineers on the same system.

Product management is a key point of failure in Scrum, true also with other processes. But it's felt so much more when an entire team grinds to a halt and an iteration fails.

If Scrum doesn't feel agile then you are doing something wrong. This is exactly the question the team should be asking itself at retrospectives (doesn't need to be three questions!). What's changing in your process sprint to sprint? Scrum masters are there to facilitate incremental process changes driven by team members, not a system that doesn't result in agile software delivery.

I think it's fair to express rationale in comments, but the following works for me without comment:

  transactionsLeapDayAdjusted = transactions.map(t => t.date == '29-Feb' ? {date: '28-Feb', ...t} : t)

One thing I always push back on is references to ticket numbers or other external systems (except perhaps e.g. ISO standards). Repos should be self contained and perpetual. One might not have access to the ticket system now, or ten years from now.

It would be wonderful if car makers could position the interior door latches to make this the natural way to open the door. E.g. just under the window near the pillar.

I would staycation a lot more but bringing up a number of children, who fortunately have daily lives that closely resemble the description of activities in the article, generally requires some adventure to relieve them from the mundaneness of hanging at home or around the hood.

Going somewhere serene and quiet, and staying put there is my first choice. But finding and getting to and from these places, especially during school holidays, takes some effort and planning. Last summer we drove for 8 hours to a camp spot (not unusual for families to do here in Australia).

They'd certainly be a different class. I'd imagine a much more competitive selection process for entry into the profession, and the emergence of a generation who excelled at succeeding in that process, but might not be the type to commit to a life of advocating for children.

Especially if they possess the skills/drive to switch to other more lucrative occupations.

Don't get me wrong though I think that teachers should be well paid, more than enough to live comfortably and happily so they can enjoy what should be a very fulfilling job for them.

In ECS you can store them in the task definitions which is easy but might not be secure enough in certain situations. More robust is to read them in from the Parameter Store see https://aws.amazon.com/blogs/compute/managing-secrets-for-am...

Django, Docker and AWS ECS and ELB.

Absolutely worth the effort to learn how to build a Docker image and put together bash scripts to push the image and update an ECS service. We have a base project which includes nginx and uwsgi set up to simply serve the Django app and static files on port 80.

Having an ECS Docker cluster with spare capacity greatly assists getting new projects up and running quickly, especially if we can run the test site under an existing domain managed in AWS. Then we can just add new rules on an existing ELB and piggy back on the SSL certificate.

With this workflow we spend the time getting a good image running locally (with local environments vars/secrets) and we know the deployment side is taken care of, and can be scaled if and when is needed. This also has the benefit of forcing dependencies and environments to be fully documented from the start (in the Dockerfile).

The next step, if the project gains traction is to move the Docker build/push/service update into CI space. We've moved away from ansible now largely, there's a use case for more complex setups for sure but am interested in K8 capabilities to help there.