A big part of my work has to do with code. I’ve worked as system administrator – installing, patching, and configuring someone else’s code. I’ve worked as independent programmer, writing code on my own. I also programmed as part of the team. And on top of that, I worked as Team Leader and Project Manager, where I had to interact a lot with programmers. Programming world on its own is as huge as the universe. There is always something to learn. When I find something worthy or something that I understand enough to write about, I share it in this category.
Erica Sadun blog post goes into details of the difference between ‘YYYY’ and ‘yyyy’ when formatting dates. Remember to add a few unit tests to your application to make sure you are using the correct format.
We’ve recently seen this issue at work and it was a pain in the butt to troubleshoot.
Here’s a good collection of cheatsheets for anyone involved with Big Data and machine learning. Whether you are already well versed in the subject, or just starting, I’m sure you’ll find something useful.
And while we are on the subject of machine learning, check out this repository for examples in Python, theory and math explanations behind many algorithms involved.
There are not many people who I trust on the subject of API design like I do Phil Sturgeon. He has been a prominent speaker both online and at numerous conferences, covering a variety of problems, solutions, and approaches in the API design domain.
In one of his recent blog posts, he shared a diagram (see above) which provides a clear illustration on which API paradigm – REST, GraphQL, or RPC – one should pick for a web application, based on a variety of criteria.
I think this is probably the simplest of all the explanations I’ve seen around.
Paul Hammant has a quick and simple blog post illustrating the request-response sequence in the web application on a serverless infrastructure. I find it quite useful as a reference, when explaining serverless to people who are considering it for the first time.
This stuff and the abandonment of names:ports in the config is a key advance for our industry. It is like a limiting Unix problem has been overcome. While it is still is impossible for two processes on one server to listen on the same port (say port 443), it is now not important as we have a mechanism for efficiently stitching together components (functions) of an application together via the simplest thing – a name. A name that is totally open for my naming creativity (ports were restricted if they were numbered below 1024 and also tied to specific purposes) . We’re also relieved of the problem of having to think of processes now, and whether they’ve crashed and won’t be receiving requests any more. Here’s a really great, but rambling, rant on a bunch of related topics by Smash Company that you should read too as it touches on some of the same things but goes much broader.
“Stop Learning Frameworks” is exactly what I’ve been saying and doing for years.
Technology come and go, but it has a lot in common. Set priorities right. Invest 80% of your learning time in fundamentals. Leave 20% for frameworks, libraries and tools.
After 20 or so years working with technology, it always amazes me how most of the new and cool tech is actually another iteration on something that existed and has been used since forever.
Cloud computing, and even the newest hype of serverless architectures, are just another iteration on the ever-going problem of large and centralized versus small and decentralized (mainframes, PC, terminal servers and thin clients, and on, and on, and on). NoSQL databases have a very familiar feeling to anyone who have worked with LDAP. All the modern instant messengers iterate over the same problems (and often solutions) from the ancient protocols – NNTP, email (POP, IMAP, SMTP), IRC, and tools that implemented them for different purposes. And on, and on it goes.
There isn’t enough time in the world to learn even a fraction of all that technology. But focusing on the fundamentals helps a lot. If there was one thing to add, I’d also prioritize open technologies and formats versus proprietary. Open technologies survive the longest and tend to be reused a lot more.