iovrthoughtthis

have fun installing and managing widevine!

i was so surprised by how hard it was to step outside of the walled garden

perhaps both! i'm currently exploring gabor maté's theory that it's a combination of genetically predisposed sensitivity and insecure modes of parental attachment

well, executive function issues are quiet heritable

i wouldn't be surprised if causation were reversed and children who have slower executive function development drink more ssb's

is caffeine controlled for?

you should be able to apply the same principals you picked up from developing in Java/Closure

node/js applications tend to be a bit more home grown than more traditional, convention driven ecosystems

for architecture: my "advice" would be to start with a single file, add things until you start to find friction (having multiple windows of the same file open is a good sign, constant searching too), break things into separate files based on your preference, folders and directories along the same lines, be consistent

your knowledge and opinions about errors/exceptions is valid here too

nodejs is fast but its not so much a performance focussed platform so ime, tuning options are lacking. there is an eco system of tools for managing stuff but it bleeds into the environment a lot more e.g. process management, ops and infra

i'd prefer it work like mario kart tbh, easier for the little co, harder for the big co

a lot of these are just ways to support the employee meet the needs of the business

i would love to see some ways a business can adapt to better meet the needs of employees with executive function disorders

i think for many, they are not easy

the pyramids of our time

i think we too easily fall for the heuristic of separate files == separate concerns

but your concerns arent really separate if, while in their separate files, they are concerned about the same things

and, so long as you want relative styling, they always will be. you can either (1) attach properties to your tree or (2) flatten your tree into a list of paths and attach properties to nodes that match the paths

in (1), changing the structure can only impact an individual node or it's children, only by the properties attached to the node and it's parents; changing the style can also only impact an individual node or its children

in (2), changing structure can impact the individual node, it's children, siblings or parents by any rules that now match any of the mentioned nodes; changing style will impact all matching nodes (not all of whom can be identified statically) and their children and may interact with other rules which apply properties to matching nodes.

either way, you cant escape the structure of the tree and one strategy lets you scope your changes easily, the other does not.

do you prefer the structure in the styling or the styling in the structure?

i prefer the later. with styling in structure if i make a change in one place, it effects the one thing i intended it to

with structure in styling, if i change one thing, it may impact many other things, some of which i might not intend to and are sometimes unknowable at the time of the change

but what does "user_profile" tell you, as a developer, when you need to style the element?

the classes you define become the new dsl though. so you keep the overhead of learning + the effort of writing and maintaing your own dsl

well, sometimes. yes.

the semantics of most html elements is useless to know for more devs (and classes don't help users)

in fact a class like .red conveys more useful information to a developer than .standout-link because when we go to change the colour of the button it's the colour we care about, not the "purpose" of the button

but now to understand what a single class might do to an elements style i have to check for ever possible combination .e.g

.btn.large {} .field.large {} .fieldgroup.large {} .title.large {} .link.large {} .large {}

to find all the elements that the .field.large declaration impacts we need to enumerate all the elements that have both .field and .large in any order.

we've coupled out html and css files

you know its good when so many people hate it

how are they separated though? if your css rules apply based on hierarchy they are incredibly tightly coupled to your html.

separate files != separate concerns

nice, now your aesthetic is coupled to your information hierarchy

style is orthogonal to semantics

well, if you hurt a persons feelings enough, they'll quit so like all things, it's a trade off to be played entirely to the context of the situation

i'm not a fan of this cultural backlash in management writing. we had a period of was was essentially "stop being a dick, your reports are humans" and now we have a push in the opposite direction.

i appreciate the pushback as reconciling it will cause innovation (probably) but i stand firmly on the side of dont be a dick.

there will be many opportunities to offer feedback. you only get one relationship with a person and people largely quit jobs because of managers

js frameworks wont go away until html or the dom makes mutating lists of elements easy

as is traditional in brief economic analysis, time is not accounted for here.

i don't like it.

largely because:

1. its focussed on "how" we hire, not "why" we hire which seems like a red flag for me.

2. it's a human - human interaction. all the humans involved should consent to it, requiring a human decision which must be done at human speeds.

3. people, their skills and interests change. we forgive and forget. success is chancy and sparse. the block chain is immutable.

4. the vision of the future reminds me a lot of the CCCP's social credit score system which does not fill me with hope.

5. it's entirely from the employers perspective with little to no consideration for the job seekers needs beyond "need a job". how do review, agree, negotiate the contract?

hiring isn't "broken", it's just a system being wrenched along with the wild pace of change

that said, maybe in a different system where things worked differently it wouldn't feel such a jarring idea

I use "more primitive" based on the assumption that less focused development has gone into the technology for organic farming than chemical farming but if the word provides a negative connotation then, well, that's not what I mean.

One of the things I wanted to chime in with, somewhere in the discussion, was that this is the sort of policy which pushes people to develop technologies and that perhaps if deployed more slowly it might have driven innovation in organic farming.

Something like a pilot scheme + opt in + subsidies.

I would assume they import fuel so this makes sense too.

True, the panic hoarding almost certainly wasn't restricted to foods only. See toilet paper hoarding early in the pandemic.

You're probably right there. That could be what is alluded to when they mention that the organic technologies "generates more air pollutants and environmental emissions". Basically they burn more stuff.

I wonder if they could become a net importer of organic waste?

I wonder what proportion of this is caused by the speed of change vs the changes them selves.

I assume everyone would expect lower yields from more primitive growing and processing technologies.

Why would "kerosene oil and cooking gas" prices rise are a result of organic only agriculture?

its not so clear cut. they both tackle the "plans are useless" but the "planning is indispensable" is implicit as anything you do in response to a challenging situation is a plan