I work in technology sector. And I do round a clock, not only from 9 to 5. It is my bread and butter, it is my hobby, it is the fascination of my life. And with the current rate of change particular in information technology (IT), there is always something new to learn, to try, to talk about. I often post news, thoughts, and reviews. And when I do, this is the category I use.
The Science of the Job Search, Part VII: You Only Need 50% of Job “Requirements” – is a nice article in the series, with a few interesting numbers. The one that stands out the most is:
You’re as likely to get a job interview meeting 50% of job requirements as meeting 90% of them.
This sounds about right. And it also explains how the recruiting is still around, with all those ridiculous requirements in every other vacancy.
The evolution of technology always amazes me. Even more so, when it can so clearly be seen within the every day life, such as household items, day-to-day activities, or, like in this particular case, movies.
Well done, Pixar! Keep it up!
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.