ty for the recommendation; for those interested in reading it here's a PDF version of it (via the author's website).
140 karma · joined November 2, 2014
The Roland TR-808 drum machine doesn't have a kickdrum.
Instead it has a BassDrum. It's not as warm as the TR-909 nor as infectious as the LinnDrum, and it can't be tuned and it has no MIDI or swing option. But when tweaked just right it can bellow out a teeth-rattling low register note that make da cars go BOOOOOOOM.
It was a happy feature of a device that Roland obviously conducted zero market research for, in that the first run of these units actually had a longer decay time which meant it was even more bass-heavy. Subsequent releases "fixed" the decay issue because Roland didn't think to ask anybody why they would need that much bass in their drum kicks.
Little did Roland realize that to residents of South Florida there is no such thing as too much bass. When producers wanted more out of the machine, they took to opening it up and fiddling around with the factory default settings (Richie Hawtin did this once and the result was Spastik [1]). Those who were more electronically inclined took a soldering gun to the circuit board to tune the kick circuit and increase the decay time to the point of self-oscillation (it's not hard to do that -- the instructions are right here [2]).
[0] https://music.ishkur.com/ [1] https://www.discogs.com/master/37372-Plastikman-Spastik [2] article link
Concerning this line: https://github.com/arkadiyt/zoom-redirector/blob/master/back... Why is it sometimes returning undefined? (or is that known)?
Cheers!
> But how do you know these things actually improves code maintainability? How do you quantify it's effect?
Trends. Trends in Client retention, trends in fewer user-submitted bugs. Trends in error rates garnered from logs. Trends in employee retention. Simply stated, Statistics. Imagine: you code a Minimum viable product (MVP) and get to market! Then you're inundated with user-submitted and computer monitor-submitted issues (i.e. AWS alarms) – you have a "shit show" of a product. So, how do you improve this MVP to reduce the Trends of failures? The solution is expressed in the ways I outlined above (but with vigor): CI, Tests, utilizing language linters such as TypeScript's tsserv, etc. (and so much more).
> Code reviews and linting is just applying some opinions to code. How do you prove these opinion are valid?
It's not an "opinions on code", it's a culture which is predetermined by the org (assuming the culture is healthy enough to understand its necessity and/or recognize its deficiency of the same). EVERY org needs to "scale". Orgs asked themselves: how do we effectively "scale" and what is "scale" org-wise? The tenets vary, but the history has painted a portrait of domains: SRE, DevOps, Data Analysts, Frontend, Backend, Product, Systems, Networking, SDET, etc. Each is not encumbered by the need for tests/CI/pre-deploy shtuff (arguable), but is released from "toil" because they recognized scale went beyond "opinions on code."
Validity of code is tests and there are many, many, expressions of tests: End-to-end, Integration, Regression, Smoke tests, Unit, etc.
> How do you prove empirically that immutability is not just a fad like so many others?
I look back on the time before I was cognizant of the concept of Immutability and every larger FE app I wrote feels now indistinguishable from disorder and turmoil. I hope the YC community can expand on the necessity of immutability from a maths perspective (as I cannot), but it's eminently scalable (read: understandable and practicable from an FE dev perspective).
(It's late and I gotta cut off here, hopefully someone can expand and/or redact everything I've said).
Cheers
I have to disagree with you on this point (and your third point)
I've seen so many examples where developers DID improve Code quality (CQ) from of the numerous automated/personal quality checks available. (Though what follows is from a Frontend dev perspective)
- CI is CQ
- Code Review is CQ
- IDE w/ Linters is a form of CQ
- `tsserver` is an real-time type CQ
- Immutability is a passive CQ
Idk, maybe Frontend-space is a world away from what you're working with every day, but CQ in my domain has both technological and cultural tools available before code ever reaches the end-user.
> So for non-technical leadership, it is hard to know if "extra time" spent on code quality actually improves anything or is a waste of time and money.
This is really interesting to me as a problem statement: how can devs unfold/make known the value of CQ as a critical function in this math? (I don't have an answer, but I think about it a lot). What are we not sharing – or, worse, what methods/language/etc. are we using that don't fully translate between teams?
I feel it's the job of the org to be able to identify this kind of bottleneck. What position within an org is responsible for explicating the properties of this kind of issue? (Again, I don't know)
I'd like to ask, though: looking back, what were (or have become) the best resources to you - read: books, articles, conference videos, etc. - which have unequivocally helped you in the years since?
Thank you
What's that? I haven't encountered that terminology before.
>... to address the CSAM issue lest governments come down on them hard.
And I think that is the springboard of why this is happening.
It's no secret that Apple has lobbyists which by turns have a "pulse" on the trajectory of Bills in the House and Senate.
What immediately came to mind to me was H.R.485 of 2021's House Session:
https://www.congress.gov/bill/117th-congress/house-bill/485/...
My (layperson) estimation is that Apple knows the rewording of it is liable pass both House/Senate in some way either in the 2022 or 2023 sessions and are attempting to get ahead of the issue. (most likely as a "rider" bill at this point)
That's my thought process on what may have precipitated Apple's move toward "CSAM"; and I welcome it in some ways (unequivocally, children should not be subjected to sexual abuse) and am wary of it in others (ML is in its infancy in too many respects, and if a false-positive arises who's to say what's liable to happen on the Law Enforcement level).
There are infinitely many concerns to be discussed on both sides of this argument, and I want both to succeed in their way. CSAM, however, feels like an attempt to throw a blanket over Apple's domains-of-future-interests while playing an Altruism Card.
One thing is certain, though: they've opened the floodgates to these discussions on an international level...
However, looking at Etymonline's definitions, I find myself in a difficult spot of having to rethink how Irony can be expressed:
eironeia "dissimulation, assumed ignorance,"...
https://www.etymonline.com/word/irony#etymonline_v_12234
So I thank you for sharing your thoughts because what you stated gave me pause: I agree with you in part, felt your conclusions are linked in a way, but it's clear that I have a long way to go to understand the topic.
That said, and from the article, "Coincidences involve juxtaposition and incongruity, but they aren’t counterfactual and don’t involve pretense." The syntax/logic statements in this sentence make my head spin :(
Beyond the book linked, if anyone has further suggestions on readings on Irony please share. Thank you.
What are the use-cases here? What's Notion being used for that this new API functionality will help in? How are you using it either personally or professionally?
Thanks
The National Interest Wikipedia article: https://en.wikipedia.org/wiki/The_National_Interest
What would a documentation or comment-chain ideally be constituted of? How would you change existing docs in a practical way which would reflect both deprecated and replacement functionality?
When you originally considered "RFC Culture" what system did you have in mind?