Remembering ActiveX Controls, the Web’s Biggest Mistake:

Running JavaScript everywhere is looming as one of the biggest screwups in InfoSec. What do userscript extensions like Grease monkey teach us?

Ah, the Microsoft tradition of always having the wrong priorities.

I wouldn’t be too hard on Microsoft. The requirement to curate public package repositories only emerged somewhat recently, as demonstrated by the likes of npm, and putting in place a process to audit and pull out offending packages might not be straight-forward.

I think the main take on this is to learn the lesson that it is not safe to install random software you come across online. Is this lesson new, though?

Agile is not a system. It’s a set of principles, set by the Agile manifesto.

The Agile manifesto boils down to a set of priorities that aren’t even set as absolutes.

I strongly recommend you read upon Agile before blaming things you don’t like on things you don’t understand .

Also interesting, successful software projects don’t just finish and die. They keep on going and adapt changes and implement new features. If we have a successful project that goes on for a decade but we have a clusterfuck of a project which blows up each year for the same time period, by this metric you’ll have only a 10% success rate.

If you write it down it is documentation.

I think you’re not getting the point.

It matters nothing if you write down something. For a project, only the requirements specification matters. The system requirements specification document lists exactly what you need to deliver and under which conditions. It matters nothing if you write a README.md or post something in a random wiki.

Requirements are not the same thing as specifications either, but both are documentation!

https://en.wikipedia.org/wiki/System_requirements_specification

that managers want to stay in control of everything, and they decide whether they do it or not.

That’s fine, it’s a call from the manager.

That doesn’t make it Agile’s fault though. In fact, one of the key principles of Agile is providing developers with the support they need. Blaming Agile for the manager single-handledly pushing for something in spite of any feedback does not have any basis.

So you started with the need to authenticate, which should be documented in the requirements. You know, the things that are required to happen.

I think you’re confusing documentation with specification.

Requirements are specified. They are the goals and the conditions in which they are met. Documentation just means paper trails on how things were designed and are expected to work.

Requirements drive the project. Documentation always lag behind the project.

the whole point of agile is to be short term

Not really. The whole point of Agile is to iterate. This means short development cycles which include review and design rounds to adapt to changes that can and will surface throughout the project. The whole point of Agile is to eliminate problems caused by business, project, and technical goals not changing because planning is rigid and can’t accommodate any changes because the process does not have room for those.

This is why this whole “things need to be planned” crowd are simply talking out of ignorance. Agile requires global planning, but on top of this supports design reviews along the way to be able to face changing needs. This requires planning in short-medium-long terms.

Don’t blame Agile for your inability to plan. No one forces you not to plan ahead.

The primary problem is using agile all the time instead of when it is actually intended to be used: short term work that needs to be done quickly by a small team that are all on the same page already.

I think you got it entirely backwards.

The whole point of Agile is being able to avoid the “big design up front” approach that kills so many projects, and instead go through multiple design and implementation rounds to adapt your work to the end goal based on what lessons you’re picking up along the way.

The whole point is improving the ability to deliver within long term projects. Hence the need to iterate and to adapt. None of these issues pose a challenge in short term work.

Note that this is failure to deliver on time, not failure to deliver full stop.

It’s also important to note that the Hallmark of non-Agile teams is de-scoping and under-delivering. It’s easy to deliver something on time if you switch your delivery goals and remove/half-bake features to technically meet requirements while not meeting requirements.

On all the agile projects I’ve worked on, the teams have been very reluctant to make a specification in place before starting development.

I don’t think this is an Agile thing, at all. I mean, look at what Agile’s main trait: multiple iterations with acceptance testing and product&design reviews. At each iteration there is planning. At each planning session you review/create tickets tracking goals and tasks. This makes it abundantly clear that Agile is based in your ability to plan for the long term but break/adapt progress into multiple short-term plans.

I’ve been working with Agile for years and I worked with people who burned out, but there was not even a single case where Agile contributed to burning out, directly or indirectly. In fact, Agile contributed to unload pressure off developers and prevent people from overworking and burning out.

The main factors in burning out we’re always time ranges from the enforcement of unrealistic schedules and poor managerial/team culture. It’s not Agile’s fault that your manager wants a feature out in half the time while looming dismissals over your head.

It’s not Agile’s fault that stack ranking developers results in hostile team environments where team members don’t help out people and even go as far as putting roadblocks elsewhere so that they aren’t the ones in the critical path. Agile explicitly provides the tools to make each one of these burnout-inducing scenarios as non-issues.

it’s about deploying multiple versions of software to development and production environments.

What do you think a package is used for? I mean, what do you think “delivery” in “continuous delivery” means, and what’s it’s relationship with the deployment stage?

Again, a cursory search for the topic would stop you from wasting time trying to reinvent the wheel.

https://wiki.debian.org/DebianAlternatives

Deviam packages support pre and post install scripts. You can also bundle a systemd service with your Deb packages. You can install multiple alternatives of the same package and have Debian switch between them seemlessly. All this is already available by default for over a decade.

I feel this sort of endeavour is just a poorly researches attempt at reinventing the wheel. Packaging formats such as Debian’s .DEB format consist basically of the directory tree structure to be deployed archived with Zip along with a couple of metadata files. It’s not rocket science. In contrast, these tricks sound like overcomplicated hacks.

Logging in local time is fine as long as the offset is marked.

I get your point, but that’s just UTC with extra steps. I feel that there’s no valid justification for using two entries instead of just one.

Any style guide is better than no style guide. Until a better option is presented, something is better than nothing.

The Philosophy section has quite a few wonky arguments; I’d skip it altogether.

I agree. I wish they moved that to a standalone section so that it could be easily skipable. Reference docs can and should have a rationale, but a lengthy rant is not what leads people to the site.

Incidentally, this kind of passive-aggressive pressure is the kind of thing that might be considered a legitimate security threat, post xz.

Yes, OP’s attempt to bully a maintainer into accepting his PR is a very shitty thing to do.

Throwing veiled personal attacks, such as insinuating a developer is incompetent or dumb, is also very bad form.

This says more about OP than anything. I hope I never have to work with anyone like that. What a shit show of a person.

This shape certainly beats a triangle (…)

Nature loves triangles.

https://en.wikipedia.org/wiki/Michell_structures

It might be just me, but I think key bindings should definitely not be easily configurable or even changed across release. They should.be standard, pervasive, and set in stone.

For those who really want configurable key bindings in Firefox I think there are already a couple of extensions that do this for you.