Skip to content

Building with learning #el30: Week 2

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,

but instead:

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.

image CC BY by Dale Cruse 

Featured image by clement127 CC BY-NC-ND

5 thoughts on “Building with learning #el30: Week 2”

  1. From a software design perspective, this is ideal: “if you swapped out the internals of a container and replaced them, nobody would/should know or need to care about the particular.”

    For example, if you have a comment box, you would replace it with a different comment box, and the people reading and writing the comments would never know the difference.

    One of my main points in this module was to say that we can make very complex containers. Not just comment boxes where you make comments, but image boxes where you make images, music boxes where you make music, or programming boxes where you make programs.

    These boxes are much more complex than more documents or video, because you can do things with them. These boxes are not things you remember, but thing you use to learn new things for yourself.

    So far, your friend and I are in complete agreement. The box is useful because you have “gathered the resources necessary for the students and packaged them up so the environment was ready for them to use.”

    But I would take learning a step further.

    Why should your students be satisfied with prepackaged boxes. I think they should be able to see how different boxes produce different results. Minimally, they should learn to gather the resources for themselves. Ideally, they should know how changing the way the box works changes the way the output is produced.

    I understand that you have no interest in computer programming and want only to make music. But at the same time, I would be very surprised if you didn’t know about the properties of sound waves, about the difference between square waves and sawtooth waves, etc.

    *My* point is that, in an important sense, you *cannot* separate the interface and the implementation. And that even if you don’t have any interest in programming, you should understand that the programming has a significant and irreducible effect on the interface.

    You said, “The roles of the user and creator were blurred in the video.”

    I’m *always* going to blur those roles. I will blur them for epistemological reasons, and for ethical reasons.

    – epistemological reasons – essentially, I think it’s impossible to separate those roles completely. (It’s like the analytic-synthetic distinction in philosophy; the distinction is a false distinction).

    – moral reasons – ethical decisions made by the creator have ethical implications for the user. The clearest case of this is in artificial intelligence, but there are other cases as well.

    I’m not sure I said all this as clearly as I would like. Let me summarize by saying:

    – containers are useful because they allow you to share complex pre-made environments with others, and these create complex learning experiences

    – so long as the container is the same, the experience ill be the same, but if the container changes, then so will the experience (and it is important to understand this)

    – but this means that containers are a new form of media, and their value won’t lie in the fact that they’re all the same, but in the ways they can be different

    1. Wow! What a comment! Hopefully I haven’t offended you! In the world of software design containers are a very specific thing and I can see that what you are suggesting is a pedagogical purpose which is slightly different to that defined role. The conflict of understanding/meaning comes when the same terms are used for things that in essence are (or become) different things or have different purposes in their different settings. e.g. your container is not ‘just’ a container.

      There are more things that I understood from watching your 2017 talk and I’m drafting those thoughts.
      ps I am of course interested in the programming side or I don’t think I would have waded in so deeply and installed gRSShopper! Understanding the workings of, thinking behind, and implications of, and abstracting those to wider learning theory and applications are precisely what make me tick. Thanks for taking the time to read and reply; I genuinely appreciate it.

    2. This explanation/clarification/extension is helpful, Stephen.

      “Why should your students be satisfied with prepackaged boxes. I think they should be able to see how different boxes produce different results. Minimally, they should learn to gather the resources for themselves. Ideally, they should know how changing the way the box works changes the way the output is produced.”

      Pulling back the veil and giving agency/ownership to users would make a huge difference in how we envision technology working for us in our lives, as opposed to us feeding our technology with our data (for some company’s financial gain). It’s all moving parts, but we don’t often see beyond the screen of those “containers.”

      In some ways, this same idea (with plenty of push-back from different communities) is behind the wave of teaching young people the basics of coding and programming. Understanding not just the outer container interface but also having a conceptual understanding of what makes that container work is an important literacy moment (or so I would argue). I’m not sure many teachers are equipped for that.

      Lots to ponder here … particularly for someone who is not a technical person but who wants his young students to better understand the world through the lens of being creators, not being mere consumers.

      Kevin

  2. Pingback: E-Learning 3.0 : Task 2 – Jenny Connected

  3. Thx
    Got me thinking … your reflections and understandings go deeper than mine, Laura, so I am learning from what you are learning. Call me a cheater if you want.
    🙂
    Kevin

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.