My current job at the release & deploy mgmt team:

Basically this is the "theoretically sound flow":

* devs shit code and build stuff => if all tests in pipeline are green, it's eligible for promotion
* devs fill in desired version number build inside an excel sheet, we take this version number and deploy said version into a higher environment
* we deploy all the thingies and we just do ONE spec run for the entire environment
* we validate, and then go home

In the real world however:

* devs build shit and the tests are failed/unstable ===> disable test in the pipeline
* devs write down a version umber but since they disabled the tests they realize it's not working because they forgot thing XYZ, and want us to deploy another version of said application after code-freeze deadline
* deployments fail because said developers don't know jack shit about flyway database migrations, they always fail, we have to point them out where they'd go wrong, we even gave them the tooling to use to check such schema's, but they never use it
* a deploy fails, we send feedback, they request a NEW version, with the same bug still in it, because working with git is waaaaay too progressive
* We enable all the tests again (we basically regenerate all the pipeline jobs) And it turns out some devs have manually modified the pipelines, causing the build/deploy process to fail. We urged Mgmt to seal off the jenkins for devs since we're dealing with this fucking nonsense the whole time, but noooooo , devs are "smart persons that are supposed to have sense of responsibility"...yeah FUCK THAT
* Even after new versions received after deadline, the application still ain't green... What happens is basically doing it all over again the next day...

This is basically what happens when you:=
* have nos tandards and rules inr egards to conventions
* have very poor solution-ed work flow processes that have "grown organically"
* have management that is way too permissive in allowing breaking stuff and pleasing other "team leader" asscracks...
* have a very bad user/rights mgmt on LDAP side (which unfortunately we cannot do anything about it, because that is in the ownership of some dinosaur fossil that strangely enough is alive and walks around in here... If you ask/propose solutions that person goes into sulking mode. He (correctly) fears his only reason for existence (LDAP) will be gone if someone dares to touch it...

This is a government agency mind you!

More and more thinking daily that i really don't want to go to office and make a ton of money.
So the only motivation right now is..the money, which i find abhorrent.

And also more stuff, but now that i am writing this down makes me really really sad. I don't want to feel sad, so i stop being sad and feel awesome instead.

User: If we use Oauth2, can we audit exactly where this data is going and who sends it there, and in addition cam we audit who grabs that data from the Authenticating app and make sure it doesn't violate our requirements?

Me: No

User: Why not?

Me: Because thats like asking us to audit whether or not a user accessed files and then uploaded them to their personal drive instead of corporate. We don't mandate that application owners take responsibility for their data outside of their application, why would we require that in this case???

User: Uhhhhh

FFS the lack of understanding of application accounts here boggles my mind. I understand that the security concerns are real but throwing out all permissible contexts based on a mandate that we dont even apply to extremely permissive accounts (i.e. users compared to apps) is folly

Why can't GitHub allow you to use a
`/Licenses/` folder for multiple licenses.

Example:

Using a `LICENSE` (AGPLv3 for software) and
`LICENSE-HARDWARE` (OpenHardware Permissive)

That's 'only' two, however there could be
more and regardless they only clutter the root..

What things do people around you keep repeating related to programming?

For me it is surely "linux is soooo permissive", which is true but still funny when people start saying it unrelated and simply as a mean to jokingly explain why something doesn't work how is supposed to. Even if the problem is not even on a computer

Me and the lead developer of my team gave a long and detailed explanation to our manager entailing the current state of a budge program our workplace uses.

This app has been bugging him for a while, he did not write it and has not been given an opportunity to rewrite the damned thing. Its a really...really messy application, and whilst it is a functional one it most certainly is NOT an efficient one since adding or moving things only incites more spaghetti mess.

We were laughing while giving our report, but both of us were crying inside. The main thing is, we both love PHP and the things he has built are very well structured and efficient, he has good technique, but will admit at certain caveats regarding the way he structures his dbs stating that he always has to do changes, which hey, its the nature of the beast, dbs change all the time. But our issue with php is the same: it lets beginners write monstruosities that are harder to do in other environments.

It really is a permissive language. But I reckon thay such lax nature is better left at the hands of the more experieced developers that know what they are doing.

Either way, we will restructure this motherfucker taking advantage of the new standards (which both of us are well versed in) and applying a more structured approach with a nice frontend interface (we be looking at Vue.js and React although we are considering Angular as well)

Gon be some good times.

Depends on the definition "without break".

Does taking a walk count as a break if I'm thinking about work during it?
Does taking a shower?
Would it be considered continuously working if I'm sleeping for a few hours every few days, but otherwise work even while eating and pooping?

So I could say I range from ~48h hours on the strictest mode to multiple weeks on the permissive one. I wouldn't recommend any of these.

In most businesses, self-proclaimed full-stack teams are usually more back-end leaning as historically the need to use JS more extensively has imposed itself on back-end-only teams (that used to handle some basic HTML/CSS/JS/bootstrap on the side). This is something I witnessed over the years in 4 projects.

Back-end developers looking for a good JS framework will inevitably land on the triad of Vue, React and Angular, elegant solutions for SPA's. These frameworks are way more permissive than traditional back-end MVC frameworks (Dotnet core, Symfony, Spring boot), meaning it is easy to get something that looks like it's working even when it is not "right" (=idiomatic, unit-testable, maintainable).

They then use components as if they were simple HTML elements injecting the initial state via attributes (props), skip event handling and immediately add state store libraries (Vuex, Redux). They aren't aware that updating a single prop in an object with 1000 keys passed as prop will be nefarious for rendering performance. They also read something about SSR and immediately add Next.js or Nuxt.js, a custom Node express.js proxy and npm install a ton of "ecosystem" modules like webpack loaders that will become abandonware in a year.

After 6 months you get: 3 basic forms with a few fields, regressions, 2MB of JS, missing basic a11y, unmaintainable translation files & business logic scattered across components, an "outdated" stack that logs 20 deprecation notices on npm install, a component library that is hard to unit-test, validate and update, completely vendor-& version locked in and hundreds of thousands of wasted dollars.

I empathize with the back-end devs: JS frameworks should not brand themselves as "simple" or "one-size-fits-all" solutions. They should not treat their audience as if it were fully aware and able to use concepts of composition, immutability, and custom "hooks" paired with the quirks of JS, and especially WHEN they are a good fit.

I created a comprehensive, fundamental guide to privacy:
- it's eternal — new apps come and go, but while the internet and our computers are the way they are, the guide works and needs no adjustment;
- it's permissive — you don't need to live in the woods. Yes, some services should not be used as-is, but you may still enjoy their content;
- it's easy — yes, it requires your typical content consumption to be somewhat altered, yet there are no taboos.

Content and medium aren't the same. Instagram stories have fundamentally nothing in common with Instagram itself.

There is no inherently bad or harmful content.

My search for privacy is over. Not anymore is it an uphill battle. Yes, I can do a finite number of things to achieve privacy once and for all. No, this doesn't limit my content consumption.

I'm going to write a complete essay. Stay tuned.