This is a reading of one of the SAP Community posts in the Monday morning thoughts series from 2018. In it, I think about OData, in particular where it came from and why it looks and acts like it does. I also consider why I think it was a good protocol for an organisation like SAP to embrace.
Original post: Monday morning thoughts: OData.
This episode, recorded on Monday 12th October 2020, features a section from the paper "The UNIX Time-sharing System - A Retrospective", written by Dennis M Ritchie, at Bell Labs, Murray Hill, New Jersey. A version of this paper was presented at the 10th Hawaii International Conference on the System Sciences in January 1977. The section is "The User Interface", which gives us some great insights into the origins and design of the Unix and Linux command interpreter, also known as the shell.
I came across this recently and thought it was a decent summary of the 12-factor methodology, despite being already 5 years old. As the author mentions at the start, some tech is perhaps a little outdated but the fundamental ideas still hold.
Source: http://www.cs.columbia.edu/~aho/Talks/12-09-07_DMR.pdf (via HN)
A tribute to the late Dennis Ritchie delivered at Dennis Ritchie Day at Bell Labs, Murray Hill, NJ, September 7, 2012
Bell Labs, Murray Hill, NJ, September 7, 2012. I think it's important to remember some of the great thinkers and creators, whose work underpins so much of what we rely upon today. Dennis is one of those people. I remember that Dennis passed away only a few days after Steve Jobs, and his passing was...
This is a classic, and is worth remembering. I referred to it in one of my Monday Morning Thoughts posts (a cloud native smell) and, while some of what is referenced feels quite dated now, a lot of the thinking is still very valid, even in this age of a more centralised management of web resources (by cloud companies). In fact, I guess the web administrators of those cloud companies need to pay attention. Note that there's a difference between...
As some folks know, I am a big fan of the command line, I even have a t-shirt that has "> The future is terminal_" on the front. I thought the question in the title of this blog post is probably on many people's minds, even though they don't know it. And who knew there were so many Windows console choices?
This is a quick overview of the possible workflow solutions, with a decent focus on SAP Cloud Platform Workflow as a key player. Coming from the respected workflow expert Alan Rickayzen, the overview is a valuable piece of information.
I chose this Monday Morning Thoughts post because I've noticed some interest again in GraphQL, and wanted to revisit what I'd written about it around this time last year. I remember writing it, it was on a canal boat on the Bridgewater Canal, on my birthday.
Source: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ This post is 17 years old, but still totally relevant today in what it teaches us - that while we construct new software architectures on top of older ones, things are still hard - harder, even - when problems occur. And there's a great line in this article that is worth quoting here: "... abstractions save us time working, but they don’t save us time learning".
The SAP Cloud Application Programming Model (CAP) is an important set of tools for the new world of cloud-based application and extension constructions. In my opinion it's a well thought out framework with ideas and philosophies taken from many areas of computing, coalescing into something that just "feels right" to me. This "About CAP" section of the documentation gives a good indication of what those ideas and philosophies are, and a useful...
The Q&A with Bram is interesting in that for such a widely used editor, Bram and his approach to maintaining Vim seems very down to earth and philosophical. Some of his answers about working with contributors, and having a plan (regarding how features will appear) are simple but instructive. This is as much about maintaining a large open source project as it is about Vim specifics.