This is where I put all the things I've created which I hope may somehow be useful to others.
I believe in modular, purpose-built software. The more freely a program or library can be adapted and joined to other software the better. This of course begs the question of interoperability, documentation and cooperation amongst developers, and is why I am a sharp proponent of free software. I cannot stress how important it is, not simply just for myself (in that regard I find it to be an unparalleled educational tool), but rather for humanity as a whole. It is the actualization of creating software without constraints of intellectual ownership/micromanagement.
I have a strong interest in distributed software systems, especially favoring self-healing networks and distributed data structures and associated techniques. Beyond that I prefer to create purpose-built, practical use applications in a variety of languages. Practical in that their sole use isn't to pad a resume, but rather be of some use to others now and in the future beyond direct use even, either for design ideas or coding practices. Being able to riddle off a list of intangibles for the sole purpose of creating a list reeks of convenience, if nothing else. Above all else, I would hope what I have created can be of some use to people, even if only pedagogical.
In retrospect, I have since come to understand that I am a very design-driven developer, perhaps even over designing at times. A vast majority of my effort is prepaid out beforehand designing multiple approaches and ideas. Generally this pays off since perfect information about the task at hand rarely exists (so much for SCRUM), and I'd rather fall back on a secondary design than have to re-design again on the fly. Over-designing also helps the implementation in terms of knowing what you'll expect out of certain parts of the program. Despite modern languages offering an over-abundance of higher-order constructs, I honestly don't believe in their liberal use, ie. Php's magic methods. Most of the highly extrapolated capabilities of modern languages are more reliably implemented by means of lower level controls. Illustratively, one could implement an alternative, and more highly-tailored form of reflection in any language that doesn't support it by means of status accessor methods. Judgment calls will inescapably need to be made about any design decision and in some cases these constructs can be indispensable, however a rush to be highly reflexive/dynamic isn't always the best approach, as readability can suffer.
I recently contributed to the FTC's RFC for opinions about the "Business Practices of Cloud Computing Providers", and have also attached it here:
The most important thing, i have noticed as a regularly transitioning developer, having worked at a few places who have used cloud computing (AWS) and traditional shops which go full self-hosted, and conducting countless interviews with companies on both sides of the fence, is that despite all the arguments which can be made about any given tool, ie. databases, storage, functions, containers, etc, the negative effects are not immediately easy to spot. This is because they involve not solely the technical elements, but rather the human element.
If all you do is look at any given specific offering, its negligibly arguable that it either is or isn't open. AWS elastic compute does use containerization, and it is portable enough to migrate elsewhere from that in general. Even software defined networking isn't different conceptually. The way in which thees services, notably AWS, create their moats is that they involve an inordinate amount of extra learning to master. This human cost is not inconsequential, as ultimately more and more generations of developers will opt to become cloud developers or AWS/Azure/GCP developers, in stead of generic developers. This has real costs. Just as general database developers are almost nonexistent due to the ubiquity of database software engine packages which can be harnessed via developing "in SQL". Having to create an entire bespoke engine, is a practice that is virtually nonexistent, which isn't necessarily good or bad.
It is, however, illustrative of what will come to pass as cloud compute platforms fully saturate the market over time. New companies, new ideas, and innovative, bespoke industries will be shoehorned into one of a few giant rent-seeking platforms. I have seen this first-hand in the form of startup shops with very green development teams who flat-out wouldn't have the first idea on implementing their setups outside of a major cloud provider, both from the perspective of scale but also network complexity. As time progresses things will just be "done this way", as taking time to architect an independent solution will unfortunately be a thing of the past. This puts huge advantages into the big 3's court, since they know that like Microsoft Windows in the 90s, cloud service computing will become ubiquitous with web development going forward, unless the companies really can assess why staying off it and self-architecting is advantageous. Most will not and the extra knowledge previously required to keep solutions independent will become much less widespread.
The implications for security, are also dire as well. Security, unlike most other areas of development is crucially linked with simplicity. One of the reasons why the web is especially fraught with perpetual insecurity lies in the incessant layering of technologies which ultimately create a security arbitrage, or traversal path which leads to a vulnerability. One need not look far to see how frustratingly over complicated cloud storage is perceived as, in the case of S3. The obvious retort is that once-learned, the automation and auto-deployable/salable capabilities are what outweighs working with simpler systems of yesteryear. This is exactly what providers are leveraging as well. They know that keeping N machines idle at traditional hosting sites is much more expensive than using an elastically deployable container system. However, it is not the case that all metrics end up being cheaper in the cloud, specifically raw storage/transit costs. The last of which is another subtle example of lock-in as traffic within the provider is greatly discounted vs outbound flows.
In the end, the extra vendor-specific knowledge learning costs will be borne by the next generation of developers, implicitly creating lock-in as less and less are able to work with pure deployments and teams become more wary of moving "off AWS", the real tragedy is that security will also suffer as it is the part of software with the least tolerance for complexity. Its not enough for software to "just work" for it to be considered secure.