Basic music theory. Almost no one I encountered bothered to actually explain anything. They simply regurgitated things and I guess expected me to somehow intuitively understand something or other.
Any good resources that do it the right way?
Ask HN: Concepts that clicked only years after you first encountered them?
251–260 of 946 posts
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#252Domain Driven Design. The book by Eric Evans lays out a bunch of concepts and as a developer that had not owned the architecture of a big domain, it was hard for me to see exactly where they fit. But after reading the book a couple times, and then encountering a few tricky domain modeling challenges, I started to see where these patterns add value. Also, as I started trying to describe the cohesive domain architectur…
- Aggregates are too heavy. You need to make the decision about what is or is not an aggregate way too early in the design process. Boundaries are fuzzy.
- Actual concepts don't exist in nicely packaged bounded contexts. Concepts overlap a lot. You need to make the decision about which concept fits into which bounded context too early in the design process. Boundaries are fuzzy. Things are kinda like other things. The definition of "Employee" is not the same in the Scheduling context as the HR context as the Payroll context, yet they do overlap a lot, and you can't just treat them as completely separate things. If you break everything down into tiny contexts to deal with this, you just make Contexts and Aggregates the same.
- Repositories are not original to DDD and I think are very likely to foster absolutely horrific SELECT N+1 or even SELECT N^2 or N^3 performance. You simply can't let one bounded context do all its expensive operations in a vacuum; not when you have lots of contexts and lots of operations. In a complex system, most parts need to be planning, not doing. The results of most operations should be a plan that you can compose with other plans, analyze, and possibly even have an "optimization pass" if you need one.
- Ubiquitous language is the right idea. If you take nothing else from DDD, take this.
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#253Basic music theory. Almost no one I encountered bothered to actually explain anything. They simply regurgitated things and I guess expected me to somehow intuitively understand something or other.
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#254It took me an embarrassing amount of time to fully grok what object oriented programming really means. It's one thing to have someone tell you what an object is, but it's another thing entirely to build a fully object oriented system. I remember what made it click: I was designing an animation system, which had a bunch of different interdependent moving parts. Once I started treating each part like an object and lett…
This one is the same for me. I'm not even sure I still totally get it. It feels like something used an awful lot in ways that don't really add any value. But again, it must just be my lack of understanding. Maybe one of these days it'll click in.
Moving the beam endpoint required an animation to bring the width to 0, change the endpoint, then ramp the beam width back up. The sprites each have their own animation in different conditions, and moving them along the beam is another animation.
The real key for me was the sprites. I built a class which takes in the start and end points of the beam and an update method. Once you start the sprite up, you just have to poke it every frame with the time delta and it manages all of its own animations.
Likewise, the laser itself was an object that managed its own animations and the sprites related to it.
This resulted in a bunch of objects with just a little code in them. But because the concerns are separated, it results in less code overall than it would take to manage everything all at once.
Is this the best, or even a good way to do this? Probably not, but it was a very beautiful solution in the moment
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#255Now i understand more about why 1+1=2.
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#256Earlier quoted context omitted.
Something in linear algebra clicked for me when I realized the infinite dimensional case is different from the finite dimensional case.
What are some applications / examples for the infinite-dimensional case?
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#257I've had many eureka moments when I suddenly realise what or why this thing from years ago is important.
I think teaching music theory with both what and why (with examples) is essential.
I still have haven't found a book that does a good job of it and keeps it interesting. Any recommendations?
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#258Steely Dan
(got a smile out of me, both because the band name and original meaning) Do you mean whole discography? Because I really like their earlier stuff but lost interest at one point. Asking since if there was enlightenment with whole discography then I have more interest to take new dives.
I thought they did more stuff on 80s..
Re: Ask HN: Concepts that clicked only years after you first encountered them?
#259Matrix multiplication. First encountered it in high school, where the textbooks presented matrices without any real motivation, and matrix multiplication just seemed like a weirdly-defined operation. Once I got to linear algebra in college and matrix multiplication was presented as the way to compose linear transformations, it made a lot more sense.
f(x) = 2x
g(x) = x + 5
It should hopefully be obvious that "nesting" the two isn't commutative: g(f(x)) = (2x) + 5 = 2x + 5
f(g(x)) = 2(x + 5) = 2x + 10
One miraculous fact here is that no matter how many functions we stack, we only ever have two terms: x and a constant term. Thus, we can represent this 'linear system' in terms of its coefficients, as long as we agree on an order: e.g. 2x+5 might become "2,5" in our system.You can do "multiplication" on these packs to compose them together, and even though the rules feel obtuse in abstract, they follow the logic of function composition. A matrix represents a similar function transform, only it's in 3 dimensions, and in order to handle rotation, it needs to swap around x/y/z. So an identity matrix is really saying:
f(x) = 1x + 0y + 0z + 0
f(y) = 0x + 1y + 0z + 0
f(z) = 0x + 0y + 1z + 0