Tech Aloud

This is a special guest episode from my friend Sam Bail, the creator and maintainer of Tech Aloud's sister podcast, Blog Cast. Add Blog Cast to your subscriptions in your favourite podcast player for more interesting blog posts and articles in podcast format. In this episode, Sam reads aloud two short posts that she co-wrote with Zachary Drillings: Crisis Driven Development and Crisis Driven Development Part 2 — The Good Parts.

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.

Source: https://blogs.sap.com/2019/11/06/cap-is-important-because-its-not-important/

Source: https://will.koffel.org/post/2014/12-factor-apps-in-plain-english/ 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 somewhat eclipsed, which made me a little sad. But C and Unix, Dennis's legacy, strongly endures.

Source: https://www.w3.org/Provider/Style/URI 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 permanent resources (such as those referred to in this article) and ephemeral ones which are often used in cloud computing contexts.

Source: https://www.loxodrome.io/post/thinking-critically-about-code-quality/ A short but interesting meditation on code quality and de facto truths about good and bad code.

Source: https://www.hanselman.com/blog/WhatsTheDifferenceBetweenAConsoleATerminalAndAShell.aspx 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?

Source: https://blogs.sap.com/2019/09/30/which-workflow/ 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.

Source: https://blogs.sap.com/2018/09/03/monday-morning-thoughts-considering-graphql/ 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".

Source: https://cap.cloud.sap/docs/about/ 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 holistic view of CAP's makeup and intent.

Source: https://www.binpress.com/vim-creator-bram-moolenaar-interview/ 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.

Source: http://www.paulgraham.com/makersschedule.html

Source: https://google.github.io/eng-practices/review/reviewer/looking-for.html

Source: https://www.artima.com/intv/simplest.html

Source: https://www.martinfowler.com/bliki/DslQandA.html

Source: https://www.martinfowler.com/dsl.html

Source: https://google.github.io/eng-practices/review/reviewer/standard.html

Source: https://blogs.sap.com/2019/08/20/its-steampunk-now/

A welcome and introduction to what this podcast is about - tech articles and blog posts, read out loud, basically. A podcast I've wanted myself, so, while on the go, I can listen to articles that I might otherwise struggle to find time to read. That's about it, really! Thanks for listening.