Mark Richards has an excellent short presentation on developing and maintaining technical depth as an architect. His primary point is that nobody can be an expert on everything, but an architect should at least be aware of the existence of the most important tools for solving a wide range of problems - including new ones that are becoming popular.
He recommends starting each work day with 20 minutes of research, before reading emails. He also suggests some sources of info:
Many of the Youtube channels that I follow are promoting VPNs as their “sponsors”. That’s a shame.
VPNs were useful in the past, but in the last years just about every website and mobile app has integrated network encryption. Therefore VPNs these days are pretty pointless for normal people and are close to being a scam.
In any browser, try visiting a site using the non-encrypted protocol http:, eg http://www.google.com or http://www.youtube.com or http://www.nytimes.com. Notice that you immediately get redirected to the https: version, ie the encrypted one - at which point a VPN adds no benefit. Then try searching for “nytimes” in google - the recommended link will be the https one. Any website which requests data from you will certainly use https. And all serious mobile apps also already use encrypted communications.
Yes, DNS (Domain Name Service, ie hostname lookup) isn’t encrypted by default yet, so someone controlling the network you are on can see the “hostnames” (overall websites) which you visit (though not the individual pages). However that’s not so important - and many browsers optionally support dns-over-https (aka DOH) if you really want (search for details).
And of course the provider of a VPN gets a lot of detailed info about your network access…ie you’re moving your privacy vulnerability from the provider of the network you’re currently using to the VPN provider. What’s more, without a VPN you are exposing small amounts of data to a large number of networks (eg the various WIFI networks you might use) plus a large amount of data from your local ISP in your legal region, while with a VPN you are exposing all that information to a single centralized point which can potentially make better use of it (against your interests) and which is operating in a legal region which might not be accountable to you.
In summary, if you happen to live under a repressive regime, a VPN might bring some value. If you wish to access content which is blocked in your country, it might help. However otherwise the value of a VPN for most people is zero.
If you are thinking about building microservices (either greenfield or refactoring) then maybe my brief opinion on right-sizing microservices will be useful (though it’s pretty much what many other people are also saying).
If you are building a system in which different components have independent release cycles, but only have experience testing systems in which all components are released at once (including sytems where there is only one component) then the article on testing distributed systems may be helpful to you.
The Component Maturity Model article presents a list of capabilities that, in my opinion, microservice implementations should have. This list was developed for a previous employer (by the architecture team in collaboration with the company’s developers) as a checklist that each project/codebase implementing a standalone service should evaluate itself against. Perhaps you may find it useful for similar purposes. And BTW, this article is actually from march this year; I just hadn’t linked to it from the front page until now.
If you are interested in learning domain-driven design, then that article might be a reasonable starting-point. In it, the two best-known books on the topic are reviewed/summarized to give you an idea what to expect and maybe an overview of the main concepts. On the other hand, it might be best just to go direct to the original sources..this is just my personal view.
The articles on evolutionary architecture and scrum are very personal opinions of the named topics, based on books I’ve read recently.
And the monads article is yet another attempt by an amateur on this topic to explain them; it helped me to write it but I’m not sure if it will help anyone to read it…
There is a very interesting presentation by Ian Cooper titled TDD - Where Did It All Go Wrong. If you are interested in Test-Driven Development (TDD), whether for or against it, you should watch that. Regardless of your opinion, Ian makes some very thoughtful points. In summary: Ian is definitely in favour of TDD, but thinks many people (including himself originally) are not doing it right.
Actually the assertion he makes is not exclusively about Test Driven Development: the claim is that tests should verify the externally visible behaviour of modules, and not their implementation. In effect (my phrasing), any test should be checking behaviour that is specified in a requirements document, change ticket, etc. and NOT lower level details. Such tests are closer to integration-tests than unit-tests, with some practical compromises that ensure they run fast enough to give developers feedback without breaking their concentration. This seems to lead in the direction of Behaviour-Driven Development (BDD).
This is a quick note about a very cool tool for installing development tools for Java/Groovy/Kotlin/Scala, and more, on linux/unix systems. For those familiar with the nodejs management tool nvm, sdkman provides similar features for other languages.
