Good video. I was expecting you to mention some of the common pitfalls of DI. Namely, once the dependency tree gets complex. My two quick examples: 1. Trying to locate the "real implementation" can be a real pain if the dependency tree is 3+ layers deep. 2. Dealing with any dependencies that are somewhat "circular" in nature.
re 1: Language servers / IDEs tend to help the most here. Usually more complicated ones are created on program start or at the start of a request. That's usually pretty easy to find. The times I've had this problem (needing to dig into the instantiation that wasn't in an obvious place) and found something being instantiated mid-stack, it was always something that I decided should have been instantiated higher up. (YMMV) re 2: circular deps - in my experience this is always due to a flaw in the design. Usually something is doing too much and should be broken up. Sometimes it needs a bigger redesign. Either case, if not addressed the weird coupling will be a pain point later.
Great explanation. Well thought out and presentded.. I am just wondering at 6:46 the connect function of the RabbitMQConnector is never called? Am I missing something? Should the connect function rather be a constructor so new initialzation of the RabbitMQConnector creates a connection or should we call connect in the constructor of the VideoUploader?
This is great. Here you explain how it is better to use interface to do DI. I've just watched your facade video and find that they look very similar but can't quite wrap my mind around understanding their differences.. 🤔
Nice one Bran, again ;) I'd have thought you would emphasize a bit more on UT as DI is a gift of God on that matter. And to echo your video on naming ;), I'd rather go for enqueue/dequeue instead of push/pull with a queue :)
Yeah some unit testing examples could have worked indeed, thanks for the feedback! As for enqueue vs. push, I can see that argument, but I also feel 'push' is to a queue, as 'i' is to a for-loop: a very common convention. And it gives me the extra knowledge where you enqueue it: front or back of the list? There's the whole push/shift/pop/unshift thing which is more nuanced.
@@branvandermeer ;) For a queue, usually, it's the very nature of the queue which defines what you're doing with the enqueue/dequeue. And, no, it's not for the sake of argument :o) but I don't use "i" anymore. idx will be the name if nothing better comes to mind. ;)
@@tmbarral664 yeah I can see that: if you've got a `const stack = ...` somewhere, I guess the operation that `stack.enqueue()` does is clear from context indeed :)
Thanks for your good question! I just tried to answer it in my latest video. As for the second part: I recommend to code as much as possible together with more senior devs! So I recommend as much pair programming as possible, that's what I regret not starting sooner. Make sure you always have inspiring people around you, if not: switch jobs to find some :)
@@branvandermeer +100 I don't know that you should expect much from manager 1:1s - what you should get from your manger is help figuring out priorities, help pressuring another team, defense from requests from another team (or internally), and help finding out who to talk to about any blockers/challenges. Probably what slowed me the most is too often being the most senior dev - if you find yourself in that position, it's good for a little while, but you'll grow the most by going where you aren't the most senior. As a senior dev, I would love if people on my team took up offers to pair program. If the more junior people level up faster, that is well worth my hands-on time, so don't hesitate.
Good video. I was expecting you to mention some of the common pitfalls of DI. Namely, once the dependency tree gets complex. My two quick examples:
1. Trying to locate the "real implementation" can be a real pain if the dependency tree is 3+ layers deep.
2. Dealing with any dependencies that are somewhat "circular" in nature.
re 1: Language servers / IDEs tend to help the most here. Usually more complicated ones are created on program start or at the start of a request. That's usually pretty easy to find. The times I've had this problem (needing to dig into the instantiation that wasn't in an obvious place) and found something being instantiated mid-stack, it was always something that I decided should have been instantiated higher up. (YMMV)
re 2: circular deps - in my experience this is always due to a flaw in the design. Usually something is doing too much and should be broken up. Sometimes it needs a bigger redesign. Either case, if not addressed the weird coupling will be a pain point later.
Great explanation. Well thought out and presentded.. I am just wondering at 6:46 the connect function of the RabbitMQConnector is never called? Am I missing something? Should the connect function rather be a constructor so new initialzation of the RabbitMQConnector creates a connection or should we call connect in the constructor of the VideoUploader?
This channel is a gem and should have at least 100k subscribers. Keep up the great work!
Yes, you gave realistic examples, thanks
A brilliant concise explanation of DI, thank you! A follow up video on how DI containers work and their benefits would be awesome as well.
Good idea, thanks for the feedback!
this channel is so under-appreciated. Good job on explaining topics realistically and in simple words.
I'm impressed, that was super clear and well explained. Thank you. I shall check out more of your content and subscribe!
This is great. Here you explain how it is better to use interface to do DI. I've just watched your facade video and find that they look very similar but can't quite wrap my mind around understanding their differences.. 🤔
What a brilliant one 🚀
Very nice video man! keep it up! :)
this was really helpful, you made it sound so simple.
Great explanation ❤
Nice one Bran, again ;)
I'd have thought you would emphasize a bit more on UT as DI is a gift of God on that matter.
And to echo your video on naming ;), I'd rather go for enqueue/dequeue instead of push/pull with a queue :)
Yeah some unit testing examples could have worked indeed, thanks for the feedback!
As for enqueue vs. push, I can see that argument, but I also feel 'push' is to a queue, as 'i' is to a for-loop: a very common convention. And it gives me the extra knowledge where you enqueue it: front or back of the list? There's the whole push/shift/pop/unshift thing which is more nuanced.
@@branvandermeer ;) For a queue, usually, it's the very nature of the queue which defines what you're doing with the enqueue/dequeue.
And, no, it's not for the sake of argument :o) but I don't use "i" anymore. idx will be the name if nothing better comes to mind. ;)
@@tmbarral664 yeah I can see that: if you've got a `const stack = ...` somewhere, I guess the operation that `stack.enqueue()` does is clear from context indeed :)
You're amazing, that was such a great video, I learned a lot. thanks
Awesome insights.
Please create more of these videos. i really find it easy to understand your explanation
Great videos, keep up the good work!
Hi Bran! Been a fan of this channel since ur first couple of vids!
I'm entry level SWE (about
Thanks for your good question! I just tried to answer it in my latest video. As for the second part: I recommend to code as much as possible together with more senior devs! So I recommend as much pair programming as possible, that's what I regret not starting sooner. Make sure you always have inspiring people around you, if not: switch jobs to find some :)
@@branvandermeer +100
I don't know that you should expect much from manager 1:1s - what you should get from your manger is help figuring out priorities, help pressuring another team, defense from requests from another team (or internally), and help finding out who to talk to about any blockers/challenges.
Probably what slowed me the most is too often being the most senior dev - if you find yourself in that position, it's good for a little while, but you'll grow the most by going where you aren't the most senior.
As a senior dev, I would love if people on my team took up offers to pair program. If the more junior people level up faster, that is well worth my hands-on time, so don't hesitate.
Great
Would you please share the font used in the editor?
Menlo.
See my vscode config: github.com/branneman/dotfiles/blob/master/vscode-settings.json
so it is just calling foreign code referenced in your code - how it is an injection
why create so many mishmash definitions....
It's called injection because that foreign code gets passed in, instead of imported directly.