While watching the discussion between Tony Hirst and Stephen Downes as part of the cmooc #el30 (my other posts are here) there were moments of clarity on my part but also I found myself really not understanding. Things that I thought were the important points were not. My lack of understanding only came clear when I talked to a professional who designs and uses containers (although in a non-academic world). You could say I used the ‘phone a friend’ option for help. My friend said things like:
By maintaining a common interface and abstracting the internals you can make changes to the contents of the container by patching it or updating it without changing the interface, as in DevOps.
He went on to talk about CICD and although he said it was an elegant model, and suggested shifting in the direction of Kubernetes (which comes from the Greek word for helmsman) instead of Docker. He did suggest chapter 1 from the book Docker Deep Dive by Nigel Poulton. Thank you to the author who provided a sample of the book via his website! (yes, that’s what I linked to)
– at this point I looked like a tree (that is to say, standing there, and not communicating in an understandable way). With articulate patience he explained containers in terms I, your ordinary academic practitioner, could understand. 🙂 yay! Here’s the non-technical, common person, explanation:
When you get a wardrobe from IKEA, it comes in a box. It has all the parts you need in the box. It is generic, but it does make a ___ (insert word here: wardrobe, chest of drawers, bed) and then it has a certain usefulness. It is up to the user what clothes to hang in the wardrobe. The IKEA boxed wardrobe is the kit built by the creator (also called a White Box- because one is aware of the component parts). The completed wardrobe, in this case, provides a clothes hanging service for the user (also called a Black Box- because one is not generally aware of the component parts). The user should not know or need to care how the service is provided in order to functionally use it. e.g. as a user I do not need to know how to write code to create music writing software, nor do I need to care about that code for the sake of implementation. All I want to do is write music, not code – code is not music.
Correcting my misunderstanding…
This was the first thing I misunderstood from the video: In the video the demo was of a music thing that was very simplistic, and what (wrongly) seemed to be the point (to me) as it was shown, was that one could see the source code and modify it inside the container. I think I misunderstood this – I think what was supposed to come across was that you could use it. The roles of the user and creator were blurred in the video. I had misunderstood that the point of a container was to reinvent programmes, which seemed far too difficult and unnecessary to me. I can already direct my students to music writing software Trinket, which is open source and does all that already. (it is super-cool and you should check it out. It writes, plays, and you can send the output to anyone and they don’t have to have the programme to see/hear/use what you write. 🙂 )
However using a container might be useful if I gathered the resources necessary for the students and packaged them up so the environment was ready for them to use. If I build a purpose-built wardrobe they can use it. I did not understand the distinction between the builder and the user and the different goals and needs they had.
Containers are useful tools for building something bigger, and the ‘generic’ aspect of them is important. For example in a course there might be a container for resources which would gather resources just for that course, and a container for note taking services which might have visualisation tools, video and audio players, but the note taking container would not have specific content in it. I could put all the lectures/sessions in one container and that would be useful for that course. The note taking service container is not useful in isolation but would be useful and could be used alongside several different course material containers and could be used in different settings/configurations. The note taking container could be added to any course. It is a generic and useful thing. Just like many houses have wardrobes, and the way they are used is different in each setting.
A key takeaway from all this
is to remember to separate the interface from the implementation (meaning how the container operates internally- and that is only something the creator knows or cares about). Designing the thing is not designing the way someone uses it, and that is ok. In fact, that’s the point.
So if you swapped out the internals of a container and replaced them, nobody would/should know or need to care about the particulars of what happens inside the container because that is up to the user and the way they interface with it.
This fuzzy and increasingly complex image links nicely to my notes from Stephen’s video from earlier in the week on data.
The learning interface
He mentioned that specifically in an environment when data is linked, rather than being simple columns and figures, simple measuring ‘stuff’ makes less sense. Learning with data becomes different, (I’m working on that with this course, believe me!)
whereas documents are pre-packaged, pre-curated – for consuming. Take this post for example, you read it, but there are not in-built activities. It is a window into my mind. Stephen says documents are not designed for creating, but for passive participants. –He is right, but it doesn’t have to be that way.
Learning in a dynamic network involves curating, creating, making the network. You could respond. (please do!)
In the video Stephen says first students need to learn how to learn…[with data]. I’d like to add: AND WITH EVERYTHING. He says: You don’t walk into a classroom knowing how to learn. And I’ll add: neither do we walk into a classroom knowing how to teach. What if, (bear with me, I do go Yoda sometimes, but it’s only for 10 more words and I do mean it)
there is no teach,
Teaching is Public Learning.
Learn with me. Connect. and lets see where it takes us. Most importantly, keep going, and if and when you’re stuck – reach out. Phone a friend – there’s no shame in that! Learning isn’t something to do on your own.