Early in my career, I really bought the stuff the Agile founding fathers promoted (Martin, Uncle Bob, Beck, etc). I tried bringing it into my code and pushing it on my teams, but it never went well. I tried finding great examples they've implemented to use as, well, examples - but never found anything. Turns out, these gurus of coding almost never release any open source code to be scrutinized outside of toy examples in their books.
I've realized the reality is that many of their suggestions are actually pretty reasonable, but they take time to implement. Most business software is written under a relative time crunch, and the time required to slow down and properly implement them is excessive and unaffordable.
More specifically, in the case of DDD, most businesses cannot afford to make every developer a domain expert so they can properly refactor to the DDD guidelines. The required think time and one-on-one time with an expert to learn the domain would be far too costly.
Further, it pushes a different type of complexity into the implementation that a non-expert cannot understand, which actually slows down future development when new hires fumble the domain. Thus, new hires end up having a longer ramp up time with less productivity and more handholding during it.
I studied a number of books in that field last year, and much of this entire thread is missing some key points.
The learning psychology field often differentiates practice from deliberate practice, where practice is just about anything and deliberate practice is focused learning.
In deliberate practice, you have to work at near your skill level, you need to apply proven learning methods, it should take maximal effort, you need a feedback mechanism to course correct, etc. A great deal of focus goes into creating effective mental models and intentionally removing ineffective mental models. It requires good coaching. As you progress in expertise, your practice should involve more risks and failures. (And there's still much more to be said here)
Gigging and noodling aren't going to make for efficient practice as it likely won't be full concentration, won't involve feedback, won't involve challenging material at your skill level, etc.
Also, you can spend 10,000 hours jamming alone in your bedroom on same set of guitar tabs and make shockingly progress compared to someone who spends just a few hundred hours intensely studying music books with a metronome and tape recorder.
You won't necessarily have to have ?client_type=xyz params on your endpoints if the BFF can do the filtering, so it saves having to build out all sorts of complexity in each backend service to write custom filtering logic. Of course, you'll pay the price in serialization time and data volume to transmit to the BFF, but that's negligible compared to the RTT of a mobile client.
I'd much rather issue 20 requests across a data center with sub-millisecond latency and pooled connections than try to make 20 requests from a spotty mobile network thats prone to all sorts of transmission loss and delays, even with multiplexing.
The article doesn't do a great job at explaining that this isn't always just filtering, sometimes it's aggregation too.
A mobile client may need data points to display a single page that require calling 20 different APIs. Even if every single backend offered options for filtering as efficiently as possible, you may still need an aggregation service to bundle those 20 calls up into a single (or small set) of service calls to save on round-trip time.
My company uses this pattern extensively, just as indicated in the post. Frontend teams deliver their own backend-for-frontend and the backend teams just worry about their own microservices. Generally, it works out pretty well most of the time.
The big issue I've been seeing is that occasionally frontend teams will decide to develop "features" by stringing together massive series of calls to the backend to implement logic that a singular backend could do much more efficiently. For example, they commonly will have their backend-for-frontend attempt to query large lists of data, even walking through multiple pages, in order to deliver a summary that a backend service could implement in a SQL query. Unnecessary load on the backend service and on the DB to transmit all that data needlessly to the BFF.
I know the easy answer is to blame the frontend devs, but this pattern seems to almost encourage this sort of thing. Frontends try to skip involving the backend teams due to time constraints or just plain naivety, and suddenly the backend team wakes up one morning to find a massive increase in load on their systems triggering alerts, and the frontend team believes its not their fault. This just feels like an innate risk to promoting a frontend team to owning an individual service living in the data center.
The optimist in me hopes this really is a quality of life improvement for the cattle. The pessimist in me fears this a way to begin patenting livestock.
> He most certainly did not. Of all the different takes out there, his is very weak.
I think Adam Neely did a good job explaining what infringement lawsuits mean in the context of popular music production. Whether or not you agree with the strength of his case on this particular lawsuit, well that's not quite the point I was trying to make here. Still, what do you consider to be a strong take on this case?
It's a fun concept, and maybe will be useful in some weird edge case of a lawsuit, but no. Most recent music infringement lawsuits seem to argue that some combination of the sound design, groove, rhythms, chord progressions, melody or reduced melody, structure, and lyrics wind up giving a song the same "feel" as a prior song, and that's the basis of the copyright infringement. Then pseudoscientific experts come in and pick and choose common musical elements that both the songs share to attempt to justify the claim, oftentimes wrongfully taking credit for inventing genre-wide defining musical elements. Adam Neely did a good job touching on this in his recent analysis of the Dua Lipa Levitating lawsuit [1].
An AI generated song machine would have to nail a lot more elements than just the melody notes to properly stop music copyright cases. In my view, a more interesting project that might be more effective in defusing lawsuits would be to try to catalog all of the musical tropes that define genres, then attempting to detect how common they are in that genre. In an ideal world, maybe this would be able to drive a metric of how similar specific two songs are vs. picking any two songs in that genre at random.
Most superstar pop singers have fantastic singing voices and great pitch control. Autotune shows up because of some mix of 1) the modern pop aesthetic demands superhuman tuning, 2) some degree of autotune artifacts are expected as part of the modern sound, and 3) it can intentionally be used as an effect (T-Pain).
To give some more detail about both 1 and 2 -
Pitch control is more than just hitting the note; its about how well you can onset at the right pitch, how well you can hold the pitch once hit, how well you can jump each pitch interval and land on the right pitch, how well you can pitch through different articulations, different vocal ranges, etc. The modern pop sound has accepted that superhuman levels of pitch control that lock the vocal into tune with the perfectly tuned synthesizers/samplers are more important than a natural sound.
Also, since we've been using autotune for so long, it has almost become natural. We expect to hear it to some degree on every track, especially in more difficult vocal areas. If it wasn't present, one might feel the song sounds "indie" or worse, dated.
Lastly, one thing that fascinates me about the autotune complaints are that it's just one stage of a very long vocal processing chain. To my ears, the tweaks provided by dynamics processors are much more dramatic than autotune when applied to a reasonably proficient singer. Autotune is just one step of a processing chain that can easily run through 10+ processors to end up at the right sound.
The best definition I've seen for the success of a piece of music is this: "What emotion is the artist trying to convey and how well does it convey it?"
Throughout the composing, arranging, recording, mixing, and mastering process, there are thousands of choices to be made, and the correctness of each choice is entirely linked back to that goal: Does the choice help to convey the emotion, or does it detract from it?
To that end, there is no correct choice, no correct or optimal harmony, no correct note, no correct rhythm, no correct timbre. It's all contextual in relation to conveying the desired emotion.
I'm really not sure how you could ever train a NN to make choices in that regard without first trying to teach them how to understand the impacts of their choices on the emotions conveyed.
At best, you may be able to train a NN to reproduce emotionally-void works in a particular style, and perhaps assign some emotion through the timbres selected (ambient music comes to mind here). Still, this isn't much of an achievement. You could easily codify the rules taught in Music 101 about harmonization and melody composition to a computer and have it spit out bland but pleasant excerpts, no deep learning required.
I misunderstood the point of this comment before, thinking you were arguing that MIDI fails because it is not, itself, a clear human-legible format like text-notation languages being discussed are.
I understand now that you likely meant that MIDI does not capture the score itself, so it does not work as a notation file format, whereas these text-notation languages do describe the score.
I think the truth of that statement very much depends on the genre, workflow, and age of the composer.
Yes, some older composers cut their teeth with pianos, staff-paper and pencils and established workflows based strictly on getting the whole song on paper before the orchestration/arrangement, and still work that way today.
However, I'd argue the vast majority of younger composers and people who write in more electronic-influenced genres definitely do not follow that workflow. It'd be very hard to write an entire pop/rap/dance track that relies heavily on the drum and bass interplay by first writing it all out on piano.
Yes that's a good point, something I was thinking about too after that post:
MIDI cannot work its way back to the original score itself, but it can capture a perfect performance of the score and allow that performance to be notated in another scoring program. That doesn't quite get you back to the original score however.
So now I suppose I can see some value in trying to develop more score representation formats with more compatibility - it'd be cool to be able to write a proper score then drag-and-drop it like MIDI into a DAW. Yes, that's usually possible through MIDI export, but it'd be neat if that was a first-class feature and we all passed around scores on the web instead of MIDI files.
EDIT: On further thinking, passing scores around wouldn't really be sufficient either, as oftentimes you do want a copy of an exact performance with humanized timings. I suppose you really would need to embrace both formats, or create some sort of hybrid that can capture elements of either/both freely.
I've played with ABC / ABC.js to render sheet music in the browser before and I like it for transporting notation; but I don't think it fulfills the same use-case that Alda is attempting to hit.
Alright, it was wrong of me to call MIDI a notation format, since it's not.
MIDI is a protocol meant to be able to capture the performance of music, and much of the performance isn't human-intelligible data, so MIDI doesn't work as notation.
However, the case I was making is that MIDI can capture all the data present in a score already and transport between applications. No, you would never read MIDI itself from a file and try to play it on a piano, but I also doubt you could easily read Alda straight from a text file without rendering it either.
Sorry to be a downer here, but can someone explain to me what the appeal of these projects are? In the past year or so I've seen a number of text-based music notation projects hit the front page of Hacker News and don't really understand the purpose they are trying to achieve.
If I want to transport music notation between software programs, I have MIDI for that, which does a good job of capturing all elements of a performance (keys, timing, velocity, pedals, aftertouch, etc.) These types of notation formats almost always fail to achieve MIDIs precision across all the aspects of a performance.
If I want to compose music, I need a format that makes it easy to visualize and manipulate notes in context of the other notes playing across all instruments. DAW piano rolls do a fantastic job of overlaying note information, and traditional combined scores do the same too. Again, text notation usually falls flat here - for example, if you had a large ensemble, and wanted to know which chord was being played on the 2nd beat of the 5th measure, how easily can do you do that? How do you determine if it's an open spacing or closed spacing? How do you determine the root without walking back through all the octave shifts?
If I'm old enough to buy a car, then I likely am having kids soon - so a 70 year time horizon means that my kids will be multi-millionaires when they are around 70, which doesn't do much for them. Maybe it'll do something for their children, who probably are in their 40's with kids of their own, but by then you are splitting things maybe three to six ways, so it's just a nice inheritance, not quick riches.
I was once in a position where I had nothing to do for around 5 months straight after starting a job. It was an open office plan, we were clocked in 9-5, and I had a supervisor from another team who sat across from me and meant to keep an eye on me. I was also young and naive enough that I didn't know how far I could push limits slacking, so I didn't really push them at all. I desperately pleaded with everyone for work, but was always told the equivalent of "next sprint we'll have some for you, go read some documentation for now!".
I had never been more depressed in my life than those 5 months.
The closest thing I could compare it to is imagine printing out a copy of your current project's documentation, locking yourself in a room with it for 8 hours, then doing that 100 more times. It's a special type of hell.
No matter how well you think you can divorce your work time from your personal time, it starts to cross over. Work becomes so boringly painful that you actively dread it even in your time off. You know that tomorrow you're going to have to wake up and pretend to stare at documentation. For hours. And hours. And hours. And then repeat that the next day. And the next. And the next - with no end in sight.
Oops, we lost your data - but don't worry, the team here all agrees that it was a mistake.