Took a wrong turn today while jogging to work.But then found my way again…
Traffic was bad today so chose to walk…
I work in a wework, they have been in the news recently as they are going through tough times at the moment in terms of finances.
There is a coffee barista downstairs in ours though worth celebrating!
Not bad for a first effort. Was a little too much pastry and not enough custard.
We are fifteen minutes drive from Blackheath and so often go there at the weekend, then walk to Greenwich. Blackheath is a lovely village with a big ‘common’ at the top.
It is a nice spot to go for a coffee and is a little less busy and cheaper than Greenwich itself. There is a new spot opened called avocado something or other (forgotten the real name), they do seriously good avocados though, even if seriously expensive!
Otherwise, Montpelliers is nice during the summer to sit outside with coffee, read the news and watch the world go by. There are a few other nice places also, cafe rouge if would like a petit French experience for lunch and there is an argintinean restaurant which does good pizza and lots more.
Once done with coffee there is a lovely walk through the common, past a nice old church. The common is very open with very few trees, a lot of kids with kites and people playing football.
The walk leads you to Greenwich park which probably needs no introduction.
I grew up in the countryside but had to come to London to see a fox!
There is an observatory in the centre and walking to the end of the park brings the maritime museum. After that you can continue into Greenwhich village, some photos of that…
In an ideal world every abstraction is pure. We don’t live in an ideal world (yet) though. Abstractions can be hard. They can cause frustration and people to give up on them or wait for the perfect solution.
In my experience, often the right thing to do is wait for the perfect abstraction but I think in a lot of cases it is right to go ahead and do the abstraction. You can always replace it or refactor it if need be but I think the key is not over doing it if not sure – keep it simple.
You want a good return on your investment and you dont want to make a brittle abstraction which limits peoples options down the line or causes tears and frustration.
Also, as with everything you should talk to people and get advice before creating your monster.
My commute for the last four years has been split into 3 parts, walk, train the tube/bus or walk.
Was a nice evening so walked the last part this evening, photos…
There can be a lot of confusion at times about these terms. Part of the reason for this I believe is that there are a lot of different descriptions floating around – just google. Also all 3 are very much related and their names and functions overlap. I guess you are also getting deep into the belly of the beast so there is a little complexity there.
Here is what they mean to me.
Inversion of Control is a generic term, meaning rather than having the application call the framework, the framework calls into the application. To my mind that is all it means really, perhaps the difficulty is visualising this in your head. Part of this might be because there are so many different ways – this is why you can be forgiven for sticking to DI. None the less, IoC is a collection of different solutions to the same problem, including Dependency Injection (DI), Factory Pattern, Strategy Pattern, Service Locator and perhaps others.
Service locator is a little controversial and considered to be an anti pattern by some – I don't know about Strategy Pattern.
Dependency Injection simply means that a class has deferred and is a type of IoC. Responsibility of obtaining or providing its own dependencies; instead that responsibility resides with whatever wants to create an instance (there might be a better description out there than this). This can be constructor, interface or property injection. We tend to do a lot of constructor injection. Interface injection leads us to the DIP.
The Dependency Inversion Principle is about abstractions and has two parts (borrowed from elsewhere):
- High-level modules should not depend on low-level modules. Both should depend on abstractions.
- Abstractions should not depend upon details. Details should depend upon abstractions.
DIP is more of a natural fit with static languages but in my opinion is often desirable irregardless. DIP does add complexity in itself though and might not be worth it in smaller scale applications (micro-services) in organisations or legacy code / code that does not change a lot.
DIP seems to be considered less desirable and actually stirs strong, (I would say unnecessary) feeling and emotion in Node. This is because Node is dynamic (difficult to implement – is easier with Typecript) and projects tend to lean towards Microservices (not worth the complexity).
Can go deeper into the principle here: https://martinfowler.com/articles/dipInTheWild.html
A final point is that IoC Containers such as (DryIoc above) tend to facilitate all 3 and looser coupling of your code. As I said before, it can be a confusing topic of conversation but I think is a great thing for a few people to discuss together.