HTML5 Spectrum Loading Screen

I was searching around to see if someone had written a Javascript library to simulate the old ZX Spectrum loading screen. I didn’t find a library but I did find this great little HTML5 screen loader on robeesworld.

For those of you too young to remember, this is what Spectrum owners would see for large portions of their time with the machine:

Spectrum Loading Screen
Spectrum Loading Screen

 

This inspired me to hack a quick one for our GameCity visit with MicroTowns and here’s what take 1 looks like. Need to pixelate it next and add the yellow/blue borders 🙂

Learning To Program Does Not Mean You’ll Be A Programmer

Learning to program does not mean you’ll be a programmer just as learning to read and write does not mean you will become a writer or a professional speaker. But they are a fundamental part of the skills you now need to develop as a person and find meaningful employment. Which I think is pretty important right?

So why do we learn to read and write?

For me, it’s all about survival and communication.

We learn to read and write because we have to survive and to survive we have to communicate. “Run, here comes a tiger!” etc Being able to read a sign warning you not to cross the motorway/freeway can save your life. Being able to write a CV/resume will help find you work so you can feed yourself and your family.

These are skills that are vital to everyday activities in the modern.

Likewise understanding technology is now a fundamental part of that skill set because you now need to communicate to/with technology.

Learning and understanding how computing influences your world and how you can influence those technologies is now part of our everyday activities: from sending email, sharing photographs, buying groceries to making sure your details are safe online and making sure your children are safe online.

So learning to program does not mean you’ll be a programmer anymore than learning to write means you’ll be a writer. But what it does do is provide you with some very powerful ways to think and interact with our, now largely digital world, which will make it much easier for you to communicate with and using technology.

The basis of this post came after I was asked a great question when talking to a parent about their children going to a local computing club which went along the lines of “what’s the point of learning to program if they don’t want to be programmers?”.

I usually respond with anecdotal evidence that it “helps with problem solving” but I find that a bit wooly so I gave it a bit more thought and replied that “it helps them to communicate and I think communication is at the heart of everything we do and today that’s largely reliant technology”.

 

 

 

Finally: A playable demo of The Vault – our html5 browser game development

Very excited to be able to post up this playable demo of our html5 browser game development I’m working on. It’s called The Vault 

You can play Farringdon Lane and the Vault of Alien Mind Terrors here (Chrome/Firefox only at the moment, mobile browsers to follow 🙂


The Vault HTML5 game
The Vault HTML5 game

Once we’ve finished the game, I’ll write up the technical side of using JavaScript and HTML5 to make a game. In the main I’m very positive about it, particularly the applications it has as a tool for teaching children basic programming. As a language for large projects it has some severe limitations, mainly around objects, typing and debugging. But in the main, these are outweighed by brevity and speed of development.

The other part I want to write up is the 2D platform genre which HTML5 can rejuvenate. Some of my favourite games were of this genre (e.g. Turrican, Metal Slug, Ghost n Goblins, etc) and this project really also explores whether they can provide depth but more on that later…

Ira Glass on Storytelling

Ira Glass on Storytelling

Ever had that feeling that “for the first couple of years of making stuff, what you’re making… isn’t so good?”, let Ira talk you through why that is and why you need to keep going!

(Yes, on the face not really computing or games or education but the more you think about it, it is. To keep someone’s attention, in the end, is often down to storytelling. Read any Richard Dawkins and you’ll find what is the head of a scientist told through the heart of a storyteller)

Ira Glass on Storytelling from David Shiyang Liu on Vimeo.

Successful Software Development is Understanding the Problem Domain: If you don’t fully understand the problem domain, you won’t fully solve it.

I know, it sounds obvious but often we never really spend the amount of time necessary to do it…

Successful Software Development is Understanding the Problem Domain

Over a coffee with Anton and Dave from RantMedia (they recently released Vectrex Regeneration) we got to discussing the complexity of developing software so we reach a point where everyone can build software. The general opinion was that building an app is a non-trivial problem programmatically.

But I started to think it’s not. I think the real challenge is fully understanding the problem domain. Yes, the task of converting that to code is a challenge but as software development tools improve, especially as we move to visual drag and drop style environments, the real challenge is understanding the problem domain.

To understand the problem domain you need three things:

  • The access to those that can detail the problem to you in a complete, end to end manner
  • The time to reflect on it, properly
  • The mental tools to decompose it and then design a solution you can validate with the problem domain owner

As we talked over these things, what struck me was how little quality time the average software engineer gets to understand the problem domain. Moreover, the percentage of the problem domain we don’t know becomes a void that the developer fills with assumptions and half-baked theories which inevitably become bugs. This will be the maintenance nightmare you then inherit which will probably account for the large part of stress in your role as a developer.

Sadly, the amount of time the developer is ‘allowed’ to understand the problem is usually curbed by the organisation they’re part of. For the most part, project management and the drive to achieve sales KPIs can unfortunately mean that most client-work focused organisations are fully loaded toward courting and winning new development work. As soon as new work is won, the sales resource has to move onto the next prospect. The ‘job spec’ is then passed into the development pipeline where the time starved developer has no time to really understand it and it will slowly become a maintenance headache.

So, take the time to understand the problem, the more you do, the better the solution will be and the less time you’ll spend fixing it.

Or to put it another way, you will retain more of your revenue as profit.

Writing and programming: the act of turning an idea into reality

A curious thing happend recently. Primo* (the eldest child, 4.5 years, going on 45) handed me an iPad and asked where her favourite game had gone, Peppa Pig Party Time

I knew immediately “where” it had gone. Secondo (the youngest child, 2.8 years, going on 1) likes holding the home button, making icons jiggle and then randomly deleting them while laughing hysterically.

No matter though. It’s easy enough to re-install them on the iPad – or you can just “write it”

Writing and programming: making things real

Primo has connected that the verb ‘write’ can be used to mean ‘create’ or ‘make’. She will spot it’s missing and say, “that’s ok Dad, just write it” or “please, can you write it.” or “can we write this game”.

She knows that my job is primarily “making computers do things” and she’s been watching what that is, which externally is seen as the act of writing/typing – after a lots of serious thinking of course 😉

The gap between typing something and having it appear is unknown to her right now, and to some degree irrelevant, but what is particularly interesting is the association that writing can yield the creation of something digital, tangible and that hopefully plays Happy Mrs Chicken (It’s a Peppa Pig mini game for those of you lucky enough not to be sleep deprived from young kids demanding ipad apps during the night!)

Tying this back to one of the central underpinnings of Papert’s Mindstorms book, it’s becoming clear that the language we choose to convey metaphor is crucial to the novice programmer if we are to help excite and encourage people to become creators with technology.

If we check the language we currently use we find many examples which aren’t clear or just anachronistic as we’ve been too lazy to think of a better replacement. For example I have an ongoing issue with the word “Loading” especially when I see it in the middle of a video game screen on a PS3, pad, etc.

What on earth does “Loading” mean to someone who didn’t grow up with 8-bit micros and BASIC?

Papert describes the connection of Logo’s Turtle to the creation of words to encourage programming abstraction

The idea of programming is introduced through the metaphor of teaching the Turtle a new word

The idea of programming is introduced through the metaphor of teaching the Turtle a new word. This is simply done,
and children often begin their programming experience by programming the Turtle to respond to new commands
invented by the child such as SQUARE or TRIANGLE or SQ or TRI or whatever the child wishes, by drawing the
appropriate shapes. New commands once defined can be used to define others.

The key factor here is that Papert’s Logo puts the creative power of abstraction, through the creative use of language which comes naturally, into the hands of the child, they can use whatever word they like.

Primo* -I know the gender is wrong but I’m a big fan of Stanley Tucci and Big Night.

Powerful Ideas in Mind Sized Bites

Reading Papert’s Mindstorms book the phrase ‘Powerful Ideas in Mind Sized Bites’ is repeated several times throughout and gradually you begin to see why learning programming is potentially so useful a ‘tool’ for children (and adults). That is, because learning to program provides skills and tools that are useful beyond the discipline of programming. It is not that we want to create a nation of developers, though some have that agenda, it’s that learning it can help you with other non related subjects.

It helps us to break problems down into ‘mind sized bites’ and learn how to ‘debug’ our solutions. That is, when we’re confronted with a large problem, if we’ve been exposed to learning via programming, we are not over awed by the problem’s size. We know that we can break it up, divide and conquer it using decomposition. This technique can then be used in the “real world”

What’s interesting is that he gives ample examples of children as young as 6 demonstrating this learned skill, something I only remember learning when I was 18 at University. Papert highlights that Computer Science is really now the science of software but in essence Computer Science is doing a great job at classifying these approaches, giving them words which allow them to be assimilated into our culture. e.g. input, output, debugging, looping, feedback, etc

The second interesting skill that stems from breaking things into these mind sized bites is the skill of being able to debug your own solution – even one that’s perhaps a mental solution in your mind. The idea being that now you have small morsels of solutions strung together to solve a much larger problem, a ‘bug’ in one of your small pieces is easy to spot and fix.

Powerful Ideas in Mind Sized Bites

If you’re a programmer you’ll be familiar with that horror of horrors, ‘monolithic code’. Monolithic code is a large, seemingly never ending slab of programming instructions. It is not in ‘mind sized bites’ and doesn’t make use of abstraction to make it ‘readable’. Papert argues that we display similar organisational traits in our minds and those who can decompose and abstract their solutions are also better at coping with revising their solution if they don’t get it right first time.

Here’s a nice picture of monolithic versus modular:

mind sized bites - monolithic versus modular

Abstraction is a technique that is positively encouraged in Papert’s LOGO and gives the child insight into the rewards of debugging. By spotting patterns in the solution, e.g. a few lines that draw a Square, the child can create new ‘word’ e.g. Square and then abstract their mind size bite away into that word.

Powerful stuff!

Does the fact that we need Developers tell us that our interfaces for programming are not good enough

I’ve been thinking a lot about the root of the problem that I’m trying to solve. That is, making it easier for children to understand how to program computers and I’m coming to the conclusion that it doesn’t have to stop with children.

One of the most important reasons why I think “programming” a computer is useful is that you can use it to create solutions to problems: e.g. make an animation for someone’s birthday, create reports to find out why some of your customers are leaving, modelling a bridge and seeing it under the stress of high winds, seeing what a new colour paint would look like on your bathroom walls, etc. The length of that list is only limited by our imaginations and our ability to articulate it to a computer.

Being able to write or modify programs gives you the power to solve your own problem. That’s an incredibly empowering and liberating thing, particularly if you do not have the resources to ‘buy’ a solution.

To help me understand how we can approach teaching this, I wrote a list of (rough) axioms about programming and learning (bourne out of some recent readings by the leading people in this field, such as: Seymour Papert, Alan Kay, Ralph Knoster and Bret Victor.)

Axioms for learning programming

What was interesting was the final rhetorical point it ended on:

“Does the fact that Developers exist tell us that our interfaces for programming are not good enough”

By this I mean has the formal role of the developer only arisen because computers are not easy enough to use, as tools.

I keep thinking of my good friend Evan Rudowski (@evanrud) who I worked with at subhub.com. Evan is the CEO of Subhub – they sell a paywall/membership publishing platform that allows the publisher to restrict access to their premium content. Evan’s a pretty remarkable guy with a impressive career in journalism and Internet Publishing (he came from America to run Excite Europe in the late ’90s and ended up staying!) but I think he’s a product developer at heart, only he’s never learned to ‘develop’ aka write code. So in order to run Subhub and develop products he has to hire developers, which is logical, and therein lies the principal problem I’d like to solve.

I want anyone with a creative idea to be able to implement it themselves on a digital device.

Perhaps not to production level (well, not yet anyway), but enough to test out new ideas, play with them, prototype them, make toys to play with, show them to clients, get feedback, etc. That is, at a level good enough to for the person with the idea to get immediate feedback which they can be use to develop further (or not).

Going back to Bret Victor and the previous post on Inventing on principle, that’s the principle behind this project and one I think worth striving for: that is, to provide anyone with a creative idea the resources to learn how to implement them on a computer

Aren’t Developers Anti-Social, Wouldn’t They Make Terrible Teachers?

The quick stereo-typical answer to that seems yes. We prefer spending most of our day communicating with a machine using a strange cryptic language and Boolean logic.

Yes, that sounds a bit on the anti social side. A side effect of doing that for long periods of time without a break can sometimes mean a socially awkward moment or two. It’s a bit like sailing a boat on your own all day. When you get back to land it’s initially a bit jarring and you’ve not seen people for a while so they seem a bit odd at first.

But the more I think about the question and the developers I’ve worked with, the more I can find an overwhelming no to that answer. Developers are the really opposite. We’re much more sociable than you think.

The classic developer stereotype is as follows:

socially awkward, slightly anxious, practically mute/mono-syllabic, over caffeinated, likes sweets/candies/biscuits/crisps, probably a bit ADHD/shiny_new_things_all_the_time_oh_look_whats_that_I_need_that, gets irritable when asked “obvious” questions, questionable personal hygiene…

I could go on and having been in this industry for almost two decades it’s hard to disagree with some of those. But there’s a part missing from the stereotype and it’s a part that needs to be added to list. It’s this:

Developers love to share knowledge and they love to teach

I actually think that in the main developers love sharing knowledge sharing and most that I’ve seen are pretty good teachers too. In fact, if you really want to see a developer reveal this side of their character just go and ask one to show off what they’re working on.

If you’ve worked with developers at all you’ve probably already seen ‘developer excitus’ in the wild but if not you might be pleasantly surprised by your encounter.

Developer Excitus is the natural state of the person who often sits mutely/muttering at the screen all day. Ironically, we’re naturally enthusiastic about new things and just love to tell people about it. Problem is we’re in front of machines all day and machines don’t like hearing about new stuff.

When asked to demonstrate a new product feature, an obscure operating system rune or some code, what you’ll see is a wonderful transformation from developer to teacher. Usually full of energy, passion and desire to help.

How good we are at teaching is another topic altogether and one I’ll find out this month as I start trying to teach children to code. But one thing I’m certain about is the passion that’s there to help others learn about technology. I genuinely struggle to think of a developer that didn’t like doing it. Actually, I can think of one but he also preferred lying underneath his desk without any shoes on.

The upshot of this is great for the plans to help re-structure the way we teach our children how to use technology because if we can get the children connected to the developers I believe we can do incredible things in a very scalable way!