Friday, January 27, 2017

InspireNshare Thinglab

There has never been a more exciting time with learning
With the Internet, social media and mobile technology we have never been more connected - there has never been a more exciting time to learn.

There has never been a more exciting time with technology
With new technologies such as virtual reality, 3D printing, 360 imagery, 3D imagery, the Internet of Things, drones, robots and artificial intelligence becoming available to the general public - there has never been a more exciting time in technology.

Thinglab Foundations

InspireNshare Thinglabs are based on the open, informal, DIY and social ideas of Maker culture, the "The Web We Lost", "Web Squared", constructionism and connectivism

Maker culture emphasises a DIY, informal, social, peer and shared learning motivated by fun and self-fulfilment.

"The Web We Lost" emphasises open, connected social technologies and ways of doing things.

Web Squared emphasises the exponential potential when new technologies meet Web 2.0 ideas of open, social, and DIY participation in the real world ... "when web meets world".

Constructionism advocates student-centered, discovery learning where students use information they already know to acquire more knowledge. Students learn through participation in project-based learning where they make connections between different ideas and areas of knowledge facilitated by the teacher through coaching rather than using lectures or step-by-step guidance. Further, constructionism holds that learning can happen most effectively when people are active in making tangible objects in the real world.

Connectivism emphasises the role of social and cultural context - that people learn through contact, connection and experience. Connectivism embraces technology, diversity and continuous life-long learning - it is "a learning theory for the digital age"

Surf and Learn
Inspired by Maker culture, the "The Web We Lost", "Web Squared", constructionism and Connectivism inspireNshare Thinglabs explore new approaches with education and technology - emphasising open, social, informal, "freestyle" and experimental methods ...... "where web meets world" we surf and learn.

Heads On Hands On …. HOHO Learning :)
InspireNshare Thinglabs are not just about ideas - that would be "Thinklab". InspireNshare Thinglabs are about ideas and experiences .... doing things .... Heads On Hands On (HOHO) to enjoy and have some fun :)
Any Thing
InspireNshare Thinglabs are not just about digital - that would be "Digilab". While digital technology is important, InspireNshare Thinglabs are about 'things" .... artefacts, paper, hand-tools, analogue, art, craft ... even magic .... as well as digital.

To find out more about inspireNshare visit

To find out more about inspireNshare Thinglab visit

Thursday, January 26, 2017

AI In The Making

Circuit Board Robot

"...the street finds its own uses for things"  and soon it will be able to find its own use for artificial intelligence.

Dreams and nightmares about intelligent machines have been with us since we invented machines but our imagination was always ahead of reality. Significant progress was made with artificial intelligence during the 1960s and 1970s but the possibilities were impossibilities with the technology at the time and the field of AI sunk into a trough of disillusionment and a long AI Winter followed.

Decades of exponential development have given us the technology to thaw the AI Winter and make the potential of AI possible. If the information revolution is anything like the industrial revolution then what we have seen so far has been like the application of the steam engine ... AI is like the application electricity in the industrial revolution. The information age is yet to really begin but due to the speed of change these days the revolution will be an order of magnitude faster and sharper than the industrial revolution.

AI looks like the trigger of a new era of technology and every major tech company is in the race for AI and tech's future. But these systems are complex, big and expensive - table stakes are prohibitive and just getting on the starting grid is exclusive.

Today people can pocket more computer capability than the room sized computers used to help us get to the moon in 1969. Exponential developments are bound to lower the cost of entry to AI and open opportunity for anyone who wants to find their own use for it - potentially creating a "cambrian explosion" of new applications ... just like the application of electricity in the industrial revolution.

Already there are some very interesting and even useful entry level tools that people can use to dabble with AI using simple chatbots. "There's a bot for that" ... major tech companies are increasingly making simple bot development available on their platforms - Telegram was early into offering bot development on its platform and has its botfather. Facebook has made a big investment in AI - you can use Facebook's own messenger bot tools or third party apps like Chatfuel, Botsify, API,ai. There are more generic cross platform business type tools like, simple fun type systems like A.L.I.C.E and Personalityforge and for the more techy there is the open source Botkit available on Github and Google's Tensorflow which is also available on Github.

This is the most exciting time I can remember in tech - decades of exponential development have brought us to this point at the beginning of 2017 where we have so many technologies ready to burst forth into mainstream application - AI, virtual reality, augmented reality, IoT, robotics, 3D printing and wearable tech to name just a few. Any of these alone can create quite an impact but in combination can be revolutionary and be part of the trigger to a new era of technology and the information revolution proper.

It is into this "cambrian explosion" of new tech and AI that Google has announced its interest to get involved with the maker community to develop smart tools for Makers and users of nano board computers and launched a survey of the Maker community saying:

"We at Google are interested in creating smart tools for makers, and want to hear from you about what would be most helpful."

Tech areas that can be selected in the survey include home automation, drones, IoT, robotics, 3D printing, wearables and machine learning. The survey also mentions face-recognition, emotion-recognition, speech-to-text translation, natural language processing and sentiment analysis.

The Raspberry Pi Foundation is encouraging its community to help google develop tools for raspberry pi. Pi co-founder Eben Upton tells TechCrunchFor me, the big opportunities are around deep learning and AI. Google are very strong in this area, particularly after the DeepMind acquisition, and there are obvious benefits to being able to connect their services to the real world using Raspberry Pi".

Could Google Maker Tools do for AI what Cardboard did for Virtual Reality? 

Google's approach to the Maker community can be mutually beneficial. Obviously Google wants to build its platform and its influence with these "technologies of the future" but people and the Maker community can also benefit from accessible Maker tools. This reminds me of Google Cardboard and how this "Citizen Tech" helped access to what had been had been the complicated, expensive and exclusive technology of virtual reality.

Will Maker access help AI get over the peak of inflated expectations and get it out of trough of disillusionment onto the slope of enlightenment at the start of the information revolution proper?

Will maker access help the street find its own uses for things like AI, virtual reality, augmented reality, IoT, robotics, 3D printing and wearable tech and help balance corporate and state tech with Citizen Tech as we head into a new era and the information revolution proper?

Wednesday, January 18, 2017

Learning The Real Value Of Programming

The information age needs and will need a growing number of people with tech and programming skills - demand for IT skills is expected to grow at nearly five times the UK average over the next decade, digital tech skills have been added to Shortage Occupation Lists for UK and Scotland and a tech talent shortage is holding back business. The education sector has responded to business and economic needs with schemes and provisions to teach people how to program - its good for the business and the economy and for those learning how to program as there are good jobs available. Programming is a very useful skill to learn and to have but the real value of programming goes a lot deeper.

Programming is about problem solving, communication, creativity and invention. Teaching programming is an excellent way of teaching generic and transferable soft skills for jobs that don't even exist yet. Programs usually don't work first time and there is an iterative cycle of debugging them - trying out ideas, testing hypotheses, learning how to design things that are easier to support, maintain and develop. Teaching programming is an excellent way to teach people how to learn and how to adapt for an uncertain future - it need not be about working with computers at all.

The best way to learn is to teach and it was when I started teaching programming as a part of general IT courses to young people in 1981 that I fully appreciated the real value of teaching and learning programming.

The early 1980s was such a very exciting time in computing - microcomputers made computing accessible to people for the first time and there was an incredible "cambrian explosion" of diverse activity and a sense of optimism about what might be possible. In 1980 Seymour Papert published the inspirational and classic book "Mindstorms: Children, Computers and Powerful Ideas" and his ideas about learning in combination with accessible computing made for what seemed at the time like a revolution in education.

Mindstorms has two central themes: that children can learn to use computers in a masterful way and that learning to use computers can change the way they learn everything else ... even outside the classroom.

Program or be programmed

Papert understood that teaching is the best way to learn and that children should be programming the computer rather than being programmed by it. 

In Mindstorms Papert wrote:

"The child programs the computer. And in teaching the computer how to think, children embark on an exploration about how they themselves think. The experience can be heady: Thinking about thinking turns the child into an epistemologist, an experience not even shared by most adults."

"I began to see how children who had learned to program computers could use very concrete computer models to think about thinking and to learn about learning ad in doing so, enhance their powers as psychologists and as epistemologists. For example, many children are held back in their learning because they have a model of learning in which you have either :got it or :got it wrong." But when you learn to program a computer you almost never get it right the first time. Learning to be a master programmer is learning to become highly skilled at isolating and correcting "bugs," the parts that keep the program from working. The question to ask about the program is not whether it is right or wrong, but if it is fixable. If this way of looking at intellectual products were generalized to how the larger culture thinks about knowledge and its acquisition, we all might be less intimidated by our fears of "being wrong." This potential influence of the computer on changing our notion of a black and white version of our successes and failures is an example of using the computer as an "object-to-think-with." It is obviously not necessary to work with computers in order to acquire good strategies for learning. Surely "debugging" strategies were developed by successful learners long before computers existed. But thinking about learning by analogy with developing a program is a powerful and accessible way to get started on becoming more articulate about one's debugging strategies and more deliberate about improving them."

Papert’s research in the 1970s convinced him that children learned more efficiently if they could see a tangible result and for educational computing he developed the turtle - an "object to think with" - a robot that could be programmed by Logo commands to move around with a pen and draw shapes.

Programming in 1982 with BBC Micro, LOGO programming language and Turtle

Program and open your mind

I count myself as fortunate to have had access to a BBC Micro with Logo and a turtle robot to teach programming to young people in the early 1980s - its an experience that has stayed with me and inspires me to this day. Papert's ideas about having objects to think with and to program were spot on - I saw first hand how students turned from being programmed to programming. I saw how they became deeply engaged in thinking about what they were doing and about communication - that they couldn't program the computer to do something unless they could understand and do it themselves.

Most of all programming theTurtle robot was fun and seeing their programming actions in the real world was impactful. We often used to start out programming each other - writing programs for others to follow (a sort of dry run) before running the program on the computer. A common early exercise was to program ourselves and then the Turtle to draw things. We would start with a very basic vocabulary: 

fd x      forward x steps
bk x     backward x steps
rt x       right x degrees
lt x       left x degrees

We would start out creating the program and calling out to partners the instructions to walk  a square of a certain size. Already this introduced the idea of a variable (x steps) and debugging if their partner didn't walk a square and arrive back at the place they started. 

We could add a little more vocabulary to develop some powerful ideas - procedures and repetition. Seeing how the instructions to make one square could be repeated with variables to make a house shape with square windows and each window with square panes was a real "mind opener"  
LOGO program to draw a square
Where pd = pen down and pu = pen up

FD 100 RT 90

Using repetition
PD REPEAT 4 [FD 100 RT 90] 

The challenge then was to work out how to move the turtle to a new position within the square to make a window etc and then program it!

This physical or tangible programming was so incredibly powerful and mind opening it left a lasting impression with me
Building a ladder 

Programming teaches practical life skills

Programming is often misunderstood as a purely intellectual and academic type of activity but it's really quite practical, its about making and building things - no wonder in software we have terms like architect and engineer. However, programming doesn't have the deep rigour of engineering - programming is as much art and craft as it is science - to be a good programmer you need to balance both systems thinking and design thinking - you need to balance what wanted with what is feasible.

KISS"Keep It Simple Stupid"
"Simplicity is the ultimate sophistication" ~ Leonardo Da Vinci
"Less is more” ~ Ludwig Mies Van Der Rohe
This is like a version of Occam's razor and ‘cutting away’ of unnecessary material. Possibly the most important lesson you learn from programming (and you learn this early) is to reduce complication - to keep refining your program so that it is as simple as possible - this makes it easier to solve problems and develop a program, fix problems (bugs) and to change, update and develop a things later. KISS is useful in so many areas of life and at work KISS is a useful antidote to its antonym KICC (Keep It Complicated Creep) the form of ritualised creeping bureaucracy we often see in so many systems and organisations that seem to operate as Rude Goldberg machines.
Rude Goldberg toothpaste dispenser
While you may not be able to reduce complexity KISS can reduce complication can help you deal with it.  

Design and design thinking
Design permeates all stages in the programming cycle from initial design through programming to coding. Good design is like "pushing against an open door" and programming teaches you to spend time in the initial planning and design stages to save time later and make your work easier overall so that development can flow forward and progress relatively easily by making later problems easier to fix.
Design thinking process
Programmers recognise the rational of the Waterfall method (that initial design errors are more expensive to fix "downstream") and the necessity of Agile methods (that develop a solution adaptively through continuous improvement) because, as Seymour Papert said, "when you learn to program a computer you almost never get it right the first time".

Programmers recognise the importance of exploring the feasibility of alternative solutions at an early stage and then creating a design that can be flexible, adaptive and easy to change - using modules that can be more easily changed, re-used and re-purposed for example.

Science and scientific thinking
Programming teaches you to be like a scientist experimenting and testing ideas and hypotheses both to learn more about programming and to get your programs to work properly.  When a program isn't working and we have no idea what the problem is we set up observations to gain information to help us form ideas about why its not working and try to narrow down the problem. We learn to think about and explore problems using testable experiments.
Museum of Science Nano Days
Programmers make programs as if they were babies ... they want the best for them, they want them to succeed but this confirmation bias causes all sorts of problems. Programmers must be aware of this and just like science programming teaches us the dangers of experimenter bias and the importance of peer review and falsifiability. For programs tough love is best and like scientists programmers must use critical thinking and try to break their own programs if they are to succeed - often the best way to do this is to put a program into the hands of as many people as possible and ask them to use it and better ask them to try and break it - its a hard thing to do but its essential.

If you can’t explain it to a six year old, you don’t understand it well enough.” ~ Einstein

Programming teaches communication skills. In order to program a computer to do something you have to understand it yourself, be able to do it yourself and then be able to tell the computer how to do it in a language and way that it can follow. 

Programming as a communication skill applies in everyday life - communicating with people and machines means understanding the parameters involved - yourself, the other, the shared language and that which is being communicated. If the other cannot understand what you are communicating then its not communication - programming teaches us to package communication so that it can be received by the other in a way they can understand and with everything they need to understand it.
5 Ways to Encourage Communication with a Non Verbal Child Diagnosed with Autism
Programming teaches us the importance of good documentation both for ourselves and for others. Its easy to rush to code and then scratch your head later trying to work out the code when it doesn't work or you want to change it and in wondering why you made certain design decisions and did things in a particular way. Documenting a program is important for ourselves but essential when working with others - you might be able to read your mind and have an inclining as to what a bit of code does but others can't read your mind and code is not natural human language so for  so can be time consuming and difficult for other people to understand - good documentation helps others as well as yourself.  

Managing to get things done
KISS, communication, science and design these are the things that learning to program can teach us and these things can help us get things done in everyday life.

Looking for the essence of things to make them simpler helps understanding. Approaching big problems in a scientific way and breaking them down into smaller more manageable bits helps avoid decision paralysis and helps us organise, plan and get on and do things. Recognising the importance of understanding things ourselves and being aware of the other person helps us communicate better. But most of all .. being adaptive and continuously improving helps us keep learning through our lives.

KISS, communication, science and design - learning to programming helps us get things done in everyday life. 

Learning to program helps us learn.

Don't just learn to program .... program to learn
For more information and examples of LOGO programming visit the Logo Tutorial from Brown University 

Sunday, January 15, 2017

Coding a Design Error

I first programmed a computer in 1972 - the computer was an ICL 2900 mainframe, we used the language Algol 68 and manually punched cards to actually program it. Program entry was so laborious and results turnaround so long that we did our utmost to make sure our programs would run correctly first time. We were responsible for everything from design to build and had deep personal experience of the high costs of design error.

During the early 1980s I noticed design become increasingly separated and isolated - coinciding with the rise of system centric rationalist waterfall thinking like SSADM (Structured Systems Analysis And Design Methodology) where higher level and higher paid systems analysts and designers would specify systems and pass the actual build to lower level and lower paid programmers.

Since the 1990s I noticed programming and coding become increasingly separated and isolated - coinciding with the rise of managerialism and its promotion of division, hierarchy, performance measurement and management where higher level and higher paid programmers would specify program logic and pass the actual build on to lower level and lower paid coders. It was in the 1990s that I first came across terms like lines of code per hour ... turning computer professionals into commodified assembly line code monkeys following instructions to assemble things against productivity targets as if they were writing pulp fiction.

What I used to know as programming has been fragmented - its been deconstructed and divided into notionally hierarchical specialisms.

Thinking generically about this:

'Design is what links creativity and innovation. It shapes ideas to become practical and attractive propositions for users or customers. Design may be described as creativity deployed to a specific end.’ ~ George Cox 

Design is about semantics, its interdisciplinary, multifaceted, synthetic and collaborative - designers work with people, things and systems about accomplish a task, solving a problem or a thing to be made or achieved.

Programming is about creating the detailed logic and algorithms to solve a problem or make or achieve something ... its about creating a set of rules and sequences of actions that can be followed to accomplish a task, solve a problem or make or achieve something.

Coding (or scripting)
Coding is about writing instructions in a specific language to carry out a task. In terms of computers this means translating program logic into program code .... writing instructions for a computer in a language a computer can follow .. a computer programming language.

In a sense design is about the why, programming about the how and coding about the what.

Design, programming and coding - all of these are skilful and important. Good design blends in with what we do - a well designed product or program is "frictionless" - its not just easy to use but a pleasure to use. Good design is like "pushing against an open door - development can flow forward and progress relatively easily. Good programming is also well designed ... the algorithms of good programs can be described as elegant (if not beautiful) in the same way a mathematical formula might be described elegant as an efficient, effective and elegant solution. Good coding is also well designed and can be described as elegant (if not beautiful) in the same way that the language and structure used in a poem, story or song might be described as elegant and beautiful. I remember how Fortran programmers would struggle to express their code as efficiently and effectively as possible - showing great admiration for the elegance of other people's code just as if it were a formula. In the 1970s computer resources were very scarce and programmers had to take a lot of care to craft their code to fit into the limitations of computers at the time - remember that that Apollo missions to the moon used orders of magnitude less computer power than the average smartphone of today!

Today I see all sorts of job types in what I used to know as "programming" ... "software engineer", software architect", "software developer" etc. I can see the logic of separating these according to circumstance and how people would prefer and be better at specialising in certain aspects.  However, fragmentation in the role of programming is also driven by "politics" and can lead to significant problems. 

Managerialism seeks to entrench and centralise decision making and power by promoting hierarchy and division and centralising control through performance measurement and management. The result is fragmentation and polarisation - a small "elite" of high paid experts who manage and control a larger commodified pool of human resources - standardised replaceable parts in a "well oiled machine". This type of Fordist industrial mindset was problematic enough when applied to industrial processes and is equally problematic when applied to processes in the information age.

This type of fragmentation is designed to centralise decision making, ownership and power so its not surprising to hear how people working in such fragmented operations abdicate involvement responsibility beyond their patch. I hear how programmers complain about how poor design passed down to them affects their work and how coders complain about how poor logic handed down to them affects their work. I hear about how quality control and testing of programs is carried out by specialist software testers who pass changes back to others in the chain - the original coder or programmer already working on something else so may never have to deal with "downstream" problems. I have to wonder how much of this is responsible for the amount of unreliable and insecure software we have seen since the 1980s.

The information age needs and will need a growing number of people with tech skills and this includes programming. Demand for IT skills is expected to grow at nearly five times the UK average over the next decade, digital tech skills have been added to Shortage Occupation Lists for UK and Scotland and a tech talent shortage is holding back business

The response to the programmer skills shortage has been to think about it in the familiar industrial production efficiency framework of the last century that: 

Breaks every action, job, or task into small and simple segments which can be easily analyzed and taught

Aims to achieve maximum job fragmentation to minimize skill requirements and job learning time. 

Separates execution of work from work-planning

The response to the programmer skills shortage has been to separate out design and programming skills and focus on coding - considered a lower skill and therefore quicker and easier to teach to produce an army of coders able to follow instructions to assemble code on production lines in the information age. Businesses ask Can ‘Coding Bootcamps’ Fix The Shortage of Engineers and our politicians ask Will compulsory coding in schools solve the UK's IT skills shortage with the view that ‘ If children are taught to code from an earlier age then this will only have a beneficial effect on the UK".

Is the fragmentation of programming coding a design error?

The 21st century response to the software skills shortage sounds rather like the 20th century response to the skills shortage - educate the masses to be able to follow orders with enough maths and english to follow orders and work on factory assembly lines.

Is coding the production line job of the information age?

BBC Bitesize for children says "you use code to tell a computer what to do. Before you write code you need an algorithm."

When I learned to program the emphasis was on design rather than build. We spent a lot of time on logic and thinking through our programs and doing dry runs etc. Program entry and running took relatively little of our time. Today I notice a rush to code .. to almost make it up as you go along and spend so much more time with the code debugging it and running it over and over to get the bugs out. Is the rush to code producing pulp fiction - is it responsible for the rise in unreliable and insecure software we have all around these days that is never complete but always needs patching. We used to put reliability and security into the design - high modularisation and robust range and type checking on parameters at every stage. I often don't see robust parameter checking these days ... no wonder so many systems can be hacked using out of range values!

Much of the routine deskilled and standardised work on industry production lines has now been automated - managerialism treated people like robots and now robots do much that work. Automated coding is embedded in our computer languages - high level programming languages are "translated" with compliers or interpreters into lower level machine languages and machine codes and it is these which computers actually use. It has been the ambition for as long as I remember that coding disappear and computers use natural human languages. We must consider the possibility that routine production line coding will like routine production line manufacturing become automated. 

Much of coding education I see today is a sort of cut and paste recipe following activity - this not to be underestimated as it gives a real sense of satisfaction and achievement and can act as a great way into working with computers. Coding with tools designed for beginners like Scratch or App inventor is a playful introduction and first contact with programming but should be treated as just that ... a first contact with programming. Coding isn't all there is to programming - there is a whole lot more that is even better. Delving deeper into programming means getting creative, inventive and learning solve problems. Delving deeper into programming means learning how to design and to build - it means learning how to make and to craft.

Programming is about problem solving, communication, creativity and invention. Teaching programming is an excellent way of teaching generic and transferable soft skills for jobs that don't even exist yet. Programs usually don't work first time and there is an iterative cycle of debugging them - trying out ideas, testing hypotheses, learning how to design things that are easier to support, maintain and develop. Teaching programming is an excellent way to teach people how to learn and how to adapt for an uncertain future - it need not be about working with computers at all.

Coding is like baking something following a recipe - its a great introduction to cooking but do we want to stop there.

"The Artisan Baker" ..

Coding is about learning a language but programming is about what you say.

A programmer designs and crafts things, a coder follows instructions and assembles things. We must ask ourselves what type of skills and education should pass on to future generations.