 Thank you very much for that. I don't think I've ever been chanted on the stage before. That's a new one. Cool. So I'm here to talk about making a lot of things. I'm just going to get rid of my cursor for a sec. But before I start, I just wanted to say a bit of a thank you. So firstly, to everyone for being here. So I think I personally get a lot out of the tech community. And just having a kind of space where we're all together and being friendly and supportive of one another is a really kind of powerful thing. And so thank you, everyone, for being here. And a particularly massive thank you to Colgram for putting this together. It takes so much to get everyone here and having such a good time and so much behind the scenes. So I think I'd just like to give a round of applause to Colgram. So yeah. So yeah, I'm Ben. I'm a developer. I'm currently trying to rebrand as an adventurer. I'm based in Oxford in the United Kingdom. You might know me if you've been at this conference before, because in 2014, I was at FutureJS, where I got this pretty cool t-shirt. And this is a conference before full stack. And I was lucky enough to get invited back the next year. So I spoke at 2015 as well. In 2016, I wasn't invited back. But I came anyway. And I snuck on change and did a microtalk. And then in 2017, we're here right now, which is kind of cool. I've decided that I'm going to come again next year, but I'm going to definitely attend. It's really stressful putting together a talk when I should be enjoying other people's. So usually when I'm talking, I have in the past given quite a few live demos. But I was thinking today, I didn't want to do that. I wanted to give something useful that you might be able to take home with you and hopefully make a difference. However, if it was a live demo talk, this is what I would have talked about. This is a project that I've been working on recently, which is a set of fairy lights, which are connected together to a web browser. And you've got a 3JS thing that you can basically play with fairy lights. And it is the coolest thing ever. But we're not going to do that today. So I just thought I'd show you that. Today, I'm going to talk about two different things. I'm going to talk about exploratory coding, how we can change the way that we code to be more exploratory and discovery-like. And then I'm going to talk about micro hacks, which I'll explain what they are in a little bit. So let's get started. When we're exploring, it's really hard to do this without constraints. So when you're in a new place, it's really hard to know which direction to go without having a plan or a constraint. And I think the person who describes this most eloquently is someone called Igor Sravinsky, who's a Russian-born composer from the early 20th century. And he wrote this. My freedom thus consists in my moving about with a narrow frame that I have assigned myself for each one of my undertakings. I should go in further. My freedom will be so much the greater and more meaningful, the more narrowly I limit my field of action and the more I surround myself with obstacles. Whatever diminishes constraint, diminishes strength. The more constraints one imposes, the more one frees oneself of the claims that shackle the spirit. And I think this is a really beautiful piece of text. And even more beautiful is the idea behind this, this idea that if we constrain ourselves, then we can be more creative within that smaller space. And I think Sravinsky wrote this about writing music, but it's equally relevant to the way that we write code and the way that we develop projects. And I think, to me, this kind of collapses down into this idea that constraint breeds creativity. The more we can constrain ourselves, the more creative we can be within those. And when it comes to coding, we sometimes lack this constraint. So this is quite a small hack that I put together. And you can see that it's just a single page, but I've got HTML, I've got CSS, I've got a polyfill, and then I've got some boilerplate code. And only at this bottom part where I've highlighted it is where I've actually been creative, where I've actually kind of done something interesting. And yet I've got to have all this extra bump around my code. And with more complex projects, this can be even more of a problem because we've got so many more dependencies that we need to understand how they work and how they interact with our code before we can actually kind of get down to changing something. And I think something that has kind of evolved over time is this idea of having a live sandbox where we kind of hide the user from all that complexity and just give them a simple field that they can enter text into and it will be live evaluated. And this is a really kind of interesting way of getting around these problems. And each of these sandboxes have two properties which is one is constraint. So in that box, you're typing in a component. And the other thing is this idea of exploration. As you're typing text, the output is live updating. And this provides a really interesting feedback loop which allows you to explore rather than just to blindly code. And I've been really interested in these concepts recently and it's led me to create this kind of experimental coding environment called Code.js. And I'll go through it in a lot more detail in a bit, but you've got several cells of code and you can kind of like explore ideas through it and I've been playing around with it a bit. This is slightly based partly on a project called D3 Express which is in private beta at the moment and it looks fantastic. It's got some really great ideas and it's kind of geared towards visualization and exploring data and exploring how we represent it. Mike Bostock who wrote D3 and is working on D3 Express now has written this blog post describing what D3 Express will allow us to do and I highly recommend reading it if you've got a spare 20 minutes. It's this really kind of like different approaches to how we approach coding. And from a development point of view, I kind of think of this as a change of mindset to when we're writing code, rather than writing a module which represents functionality, we're writing a module that represents content. So we can, as we play around with that, we're playing with the content as it flows through an application rather than implementing a feature that will be reused again and again. Right, so we're going to look at Code.js and see a few features of that, partly because it's got this experimental aspect which is kind of interesting and secondly because from a technical viewpoint, it's got some really interesting challenges and I thought I would share them with you. So, the first idea behind Code.js is this idea of a unit of computation, like a bit of script. And I've embedded it here, but basically this is what it looks like. So you've got some code on the left and on the right it's live evaluated. So as I add more, I can't really see here, as I change this, then the output changes as well. And that can be text or it can be, this is working, that can be text or it can be numbers or anything we want. We can, these cells can contain more complex patterns. So this outputs a maze-like structure and we've still got this same thing that we can play around with these numbers, see how it looks, and just get a feel for the code in a kind of different way. As well as the outputting text, we can also output HTML divs or any kind of, yeah, any HTML element, and that will just be rendered to that iframe over there. And we still got that exploratory purpose to it. So essentially what this is, is a text area followed by an iframe on the right. And the challenge that we're having to overcome here is taking that text, bundling it up, processing it, shoving it in that iframe, which is actually quite an interesting challenge. So the first part of this is, does our text box even contain JavaScript? So we had to talk about this yesterday, which is great, and what it means for text to be JavaScript is that we can take out, we can split it into tokens, we can take those tokens and generate an abstract syntax tree, or AST out of it. So we can take a text area and we can do this exact thing. So if I do hello world, we can see that we can pull out those tokens, but we're unable to make that parse tree out of those tokens. So this isn't valid JavaScript. Whereas if we put a plus in the middle, then we're able to construct that tree and we know that that text area contains something that we might want to plunk in somewhere else. So we can kind of run that test at the very beginning. The second challenge is how do we capture the output? So when we're typing in something like this, we would expect the output to be 42, we'd expect to be X plus Y, but because we don't have like an implicit return in JavaScript, it makes us a bit challenging. So one way around doing this is again to generate a abstract syntax tree. Here it is as a graph. And we can highlight any nodes in this graph that are evaluatable, that might provide a value. And then we can modify our syntax tree to generate functions that wrap those up, which will allow us to pull out those values at runtime. So here's that. We can just, as we change this, we've got this wrapped function at the bottom. Although this is one in every line, it's actually pulling out, it's using the syntax rather than the lines. And something interesting is we're actually maintaining white space here as well. This is using a tool called recast, which maintains the white space when it's generating the code from the AST. Then, with just this code, we can just wrap that up in some HTML, generate a blob, make a URL for that, and shove the iframe at it. And that will just basically evaluate our code. And we're done. We're just kind of cool. So that process is taking input, processing it, evaluating it, and showing the evaluation back to the user. And what's really cool about this is it works for any language, right? Like so it doesn't just have to be JavaScript, it could be CSS, it could be shaders, it could be English, you know? Like you could be generating any information about that if you wanted. And by showing it back to the user, you've created this loop, which allows the user to explore what they're typing rather than statically analyzing it and being taken out of their flow. So if you're creating any kind of like plugin or any kind of tool at all, if you can allow your users to explore it, you can allow them to learn it in a very different and deeper way. Right, so we've talked about having a single unit of JavaScript, but something that cool.js can handle is multiple units. So you might have a first one that defines a constant name, and then the next one might use that constant to output some more text. And what we've got here is we've still got this exploratory thing happening. So we can change that text field at the bottom, but we can also change this top one. And the values propagate through the cells and our re-output. So we're able to explore within the context of what a single cell is doing and see that live propagating through the other cells. This is another really interesting problem. And the way we can get around that is this is to take our cells. We've got an abstract syntax tree for each one. We can use that to pull out all the variable declarations. Then we can analyze it more to pull out all the uses of variables throughout the cells. And then we can just connect those up, which kind of works pretty well. And then finally, we can simplify this graph to the cell level. And we've created this kind of dependency graph just by analyzing those ASTs. And we can use this to kind of like lazily evaluate our code. So I said no demos, but you know how it is. So for instance, these ones here, oh, this is probably the wrong one. You can see that as I'm changing this pattern, it's live randomly updating that maze in the bottom. Whereas if I change this maze, it doesn't update that pattern at all. So it's like it's maintaining the state and not reevaluating it the other way around, which is kind of useful and allows you to explore each cell independently. Right, and I think the thing that's interesting here is like code doesn't have to be text files. Like we're really used to opening up a text editor and kind of making like writing modules and importing them, but we can actually architect things in a different way. And I think this is gonna be particularly interesting as tools like VR and AR become more prevalent and we're gonna have to have new ways of interacting with our code. Right, so the final thing about Code.js that I wanna discover was the idea of bringing lots of people, like sharing, editing with other people as well. So when we're writing code collaboratively, there's basically two ways that we do this. So first one is this live collaborative Google Docs operational transform kind of way. And where you can invite people to edit the same code as you're writing, which is really interesting. But it has some issues with you don't want to open up that to everyone else. So the other alternative is to allow people to fork your code or remix it, which is another really powerful thing and allows your upstream code to be safer from downstream changes. With Code.js, there's something really interesting, which is we're able to, by restructuring the way that we think about code, we're able to restructure the way that we think about collaborating code. So Code.js can sit somewhere in the middle. And the way it does that is we can take our updates from ourselves individually and propagate them downstream. So on the right, we've got this fork and on the left, we've got a source. And as we change things, they'll flow this way. But on the fork, as that gets edited, we can block those changes so that that fork doesn't receive those updates anymore. And this has got some interesting properties. So here, we have got a source here. We can create a fork over here. And this fork will get updates. So hello, Ben. And that will update across to the downstream fork. But what's interesting is here, we can make local changes to that one cell. And now, any changes that come from the source won't update that cell, because it's overwritten. So when we change this, we're actually creating a new kind of data graph on the second fork of this, which is independent to that user, but using those same upstream changes from the source. And where this gets kind of even more interesting is that these forks can be hierarchical. So we can have a third fork, which receives the same updates. So it's got named Ben, and it's receiving those text changes down. But we can actually change this to being something else, which is split. So if we were to do that, make it trendy. So now, when we change our upstream fork, it's able to propagate to these two different users who have changed their forks in completely different ways, but they're still collaborating in this dynamic fork way. And this has been kind of interesting to play about with. And I think there's some really good potential stuff in there. And I think what this has made me think about is that I think there's gonna be, in the future, there's new ways of coding together. Like just now, stuff like Glitch is revolutionizing how people can take and remix code and share amongst each other. But I think down the line next few years, that's only gonna improve more and more, and we're gonna be seeing new ways of writing code with other people. Right, so that's me done on explorative coding. So that's what Code.js is, and that's how we can kind of change the way that we allow users to kind of interact with the code that we're writing, rather than it being a kind of static bit of text. What I wanted to talk about now is micro hacks. So micro hacks are something that I've been kind of getting quite a lot of use from recently. And it's like, I think, basically, why is this like a small hack, right? But it's not like regular work, because hacks are liberating in this way that we don't have to kind of adhere to code standards. We don't have to kind of be massively scalable or anything like that. We can just like play around. So it's not really like regular work. Also, micro hack isn't really like a big hack, like going to Hackday for a weekend. It's something a bit smaller. It's something we can kind of constrain and be creative within. And yeah, over the last couple of years, I've done quite a few of these small hacks. So up at the top, we've got this thing which I was exploring how dithering works, and took a couple of hours and it was like really, really fun. And then down the bottom, we've got these renders that I was working on. And they're all these kind of like, they're all kind of terrible code, but really worthwhile to do. On the top right here, we've got this one which me and a friend were doing Google Cardboard hacks and so we did this series of hacks over the month of October. And so as well as doing like single one-off hacks, I think there's something really interesting about doing a series of hacks and expanding on an idea. So down the bottom right here, I was teaching myself WebGL through a series of hacks every couple of days. And I went from having that simple hack on number one to like doing some WebVR that I'd hand coded from scratch, which felt really good. And I think the benefits of this is really fun, right? Like it's really kind of good fun to create something and to kind of see something that you've made be live. It's also really cool for how you understand libraries and APIs. Like I'm a very kind of practical coder, I think. And I understand something from reading docs, but I really understand something if I'm coding with it. You know, like if I'm kind of messing around and playing with it. And it's really good for exploring ideas. Like so with those cardboardtober hacks, every hack kind of took me a step forward to a bigger idea. And it seemed like a really powerful tool for doing that. And the other thing that's quite nice about concentrating on like as making hacks as small as possible is that they can lead on to bigger things, right? So you don't need to be making something huge. You can just make the start of something huge and keep it small as you want. So this is an example of one of those. This is a project that I worked on. It's got a video. Hi, this is me. But it's also got this line going across so it kind of feels like a flatbed scanner. And it's kind of weird, like so this is, yeah, doesn't make you look very pretty or anything like that. But it's like an interesting, like, so this took about like 20 minutes to kind of throw together, but it really allowed me to explore the idea of having a flatbed scanner video stream like this. And what's quite nice about this is it led on to other things. So this is some work that my brothers did. Where we had eight flatbed scanners and people could go and interact with those and we would capture the scans across the room and project it back to them. And it turned into this really nice way of kind of publishing images. And it kind of started off from these like tiny micro explorations and we did like three or four of them before we kind of got on with this. We did this other thing which I wasn't so much involved in where we attached lenses to scanners, to flatbed scanners and made this like really rudimentary camera which would take these really kind of creepy pictures in a really nice way. And it would take like about two minutes to take one of those pictures. And we ended up getting all these inputs from people visiting the gallery and it turned into something really interesting. So that's I think the power of making like small constraints as small as possible hacks there. And what I just wanted to kind of go across quickly was the idea how we can approach making things like this. So I think this is the timeline for a hack or kind of any project, if you're honest, I'm honest. So first of all, you got an idea and then once you kind of come up with that idea, you've got this kind of planning time where you like think about it and think about how you might approach it and then you actually kind of get down and start the coding process. And then after a while, you've finished it and you're done. It's like pretty obvious actually, now that I show it. I'm gonna go across each of these parts and kind of say how we can kind of constrain and improve them. So first of all, the initial idea, right? So how do we kind of come up with the concept of what we want to build and hack upon? I think the best way of approaching this is to chill out and talk to people about what interests you, like kind of, this is all driven by passion. And if you can kind of be passionate and be friendly, then that's when the ideas will come. I think, so James Victoria is a designer, teacher based in New York. And I think he says this really, really clearly, which is there's a reason why so many seminal works of art start off in the back of a beer napkin. It's because they're in a bar, you know, like so we don't have our ideas when we're like sat at a desk waiting for them. We have our ideas when we're chilling out with friends and in a bar having fun and receptive to creativity. So next up we've had our idea, we've got this idea in our head and we're trying to plan it out. So something that happens quite a lot is instead of planning the thing that we're wanting to build, we plan the approach, we go too far and we kind of constrain the wrong thing. So instead of saying I want this thing that does this, you think I want this thing that users react to do this and suddenly you've constrained how you're gonna do it. So I think basically we can, if we are planning off as soon as we've got that initial idea and just kind of keep it vague, then that's all right. That kind of saves us time. Starting is a massive problem and that's because scheduling things is hard. So if you've got like a job and you think it's gonna take a week, then it's really hard to kind of find time to do that. Whereas if you try and reduce that thing that you're trying to build, it becomes a lot easier to manage to fit it in around you. So just basically try and think small and keep it as micro as possible. So if we shrink down what we perceive the coding session to be, then that's gonna make it easier to kind of fit it around our lives. So the actual coding is like, so I think I've talked about this quite a bit about the idea of being able to explore our code and be able to get instant feedback to what we're doing and be able to step towards a goal. And I think this is a kind of key part of hacking and micro hacking is just working your way towards something rather than planning it all out beforehand. Though sometimes this has got a problem that you kind of miss, right? So you've got this plan of what you want, but along the way you've kind of diverged from that plan. And I think a really nice thing because this isn't a real project that you're having to deliver is you can just pretend that's what you were trying to do anyway, right? Like so you can, if you miss your goal, just pretend you've got a new one and that works. So we've kind of gone off on our coding, end up with a different goal and then finishing. So finishing a project is really where so many of our projects kind of get left behind. And I think part of that, I think that's down to two reasons. And firstly is like us not defining what a goal, what our project being done is. So for me it tends to be like pushing it up to GitHub or putting it in on Twitter or something like that. But if we define a way of being done then we're able to realize that and work towards it hopefully. The second problem that we have as well as not knowing when it is done is tinkering. So at the end of our coding phase, we go into this like this area where instead of actually working towards finishing it, we're instead trying to work towards making our code clean or making it kind of prettier. And this is really, really dangerous because we've already passed the point of being finished. So what I've started doing is just like publishing it as soon as I can. So if you kind of get to the point where it's like vaguely done and just send it out and tinker later, that works. So this is our kind of final timeline for what MicroHack is like. We have an idea because we've been chilling out. We haven't really planned that much because we don't need to. We've started and gone off in a different direction but that's totally cool. And then we've finished kind of early without fixing it up because yeah, we just don't really care, which is kind of nice. And so once you've completed that, the next step is just to do it all again, right? To start over. And what's really interesting is as you explore an idea again and again, a kind of process emerges, which is kind of interesting. And related to this, I think something that I've had challenges with is how you find inspiration and how you kind of judge yourself against others. So this is a series of hacks that I've taught myself, WebGL. So each one of these is a tiny little bit of code. And there's two interesting things about this. The first one is this first hack is just a single pink square, right? Which if I was looking at what other people are doing with WebGL isn't really that impressive. You know, like it's just two triangles. But I published it anyway. And that's because it was impressive to me. You know, like I'd never touched WebGL before. And so I kind of felt good releasing it into the world. And the other interesting thing is along each of these steps, I had no idea what the next hack would be. But as you start exploring ideas and putting small things together, you start to get more of a notion of where you can go next. And I found that process really interesting. And the absolute last thing that I kind of wanted to leave you with is that we should be proud of the things we make. I think it's like, it's really tempting to look around at what everyone else is doing and think that your own stuff isn't up to that scratch. But the other people don't matter, you know? Like, that you have created something that you've made something go from being an idea or a thought to something that is able to be shared is a huge, huge step and a thing that should be celebrated by you. And I think, so bearing that in mind, what I wanted to leave you with was that this thing here is like, it took me about like eight hours to draw this very static, small, pink rectangle. But I am like massively, massively proud to be sharing it with you today. So, yeah, that's all I've got. So thank you very much. Cheers. Thank you so much, Ben. What a fantastic way to end an amazing week. Cool. I have a question here from our audience. What other examples of Explorative Coding have you come across? Cool. Yeah, so yeah, we talked about this earlier. I think, so this is a project called Sonic Pi from Cambridge in the UK and this is a kind of audio generation program and it's really cool because you can basically like explore audio by programming and watching people using it is like a very different way of coding. So people will be like, press save and it'll kind of start a beat and it'll kind of like update and it's like, it's more coding as performance rather than coding for work. It's not like that. Very cool, very cool. Yeah, yeah, yeah, so I like that. Awesome, thank you, Ben. That's all the time we have. No worries. No, thank you very much. Amazing. Cheers.