TiddlyWiki

I'm Jeremy Rustin and you're listening to the Changelog. Welcome back everyone. This is the Changelog now you're host Adams Dakoviak. This is episode 196 and on today's show dare not talk to Jeremy Rustin, the creator of TiddlyWiki, a unique non linear notebook for capturing, organizing and sharing complex information.

It's written in JavaScript and sports a custom fake Dom. We talk to Jeremy about his nearly 40 year career in programming, hackability as a human, right Tiddlers, the atomic unit of data, intidly wiki and so much more. We have three sponsors for the show. Toptal, Linode and BMC True site Pulse.

Our first sponsor of the show is our Friends at Toptal, an exclusive network of top freelance software developers and designers. Top copies rely upon top top freelancers every single day for their most mission critical projects. And I'd love for you to get in touch with me if you'd like. A personal introduction to our friends at Toptal.

If you're an engineer or designer, you'll be a part of a worldwide community that loves to work on awesome projects with flexibility to travel and see the world and blog on the Toptal blog or apply for open source grants or even have access to scholarship options. Head to toptao.com to learn more or email me adamslow.com if you prefer. A more personal introduction to our friends at Toptop. And now onto the show.

All right, we're back. We got an awesome show today. This one. Jared, like many shows of ours, begins as an issue issue 248 on our ping repo.

Go to GitHub.com the changelog ping, you'll see a bunch of issues there. Contribute back. Recommend show if you want to, but share it with FND who commented back in July this is kind of crazy. It goes back to when we were go for cunt.

Remember that time? I do and this is a great suggestion. Definitely a project that had never hit either of our radars. I may never have if it wasn't for fnd.

I wish FND would leave his name somewhere on the Internet so we'd actually thank him by name. We don't know if it's a he either because it's a fighter pilot. This is an avatar. I guess we assume it.

That's true. I'm pretty sure it's a genderless faceless person. It is. So thank you genderless faceless person fnd.

I do like to read off specifically what was said because it was intriguing and he or she said that tiddlywik, which is what we're talking about, was one of the earliest single page applications and is in many ways both unusual and thought provoking. Its latest incarnation was rewritten from scratch, taking advantage of the JavaScript community's modern tooling. So that was Evan D's take on why TiddlyWiki is interesting. And also he she said, Jeremy Rustin will be a great guest.

So, Jeremy, you're here. We really appreciate you joining us. Thank you guys. Thank you very much.

Fnd as well. Yeah. So Jeremy, we actually getting to know our guest a little bit at the top. And so I did a little bit of looking up and on Twitter I found an interesting bio which says that you're been learning the code since 1978.

That's a long time. Yes. I wonder the average age of your guests. I was thinking I'm probably hugely older, but hopefully I can pull out some interesting perspectives that come from that.

I mean, I got a first computer in 1978, as it says there. It was long before the web and long before object oriented programming, long before databases, if you can imagine that. So what you cut your teeth on then? Was it a C or what?

No. So my first computer was a crazy thing called the MK14 and it's just a circuit board that you soldered yourself. It had a processor called the 8060, also called the SCAMP SC MP and it was in fact it was a bit of a precursor to the RISC chips in that one of the things that was regarded as freakish about it was intended for embedded applications was that it didn't have a stack pointer and instead there were some conventions for using one of the general purpose registers as a stack pointer. And obviously because it was the first processor I touched, I had no idea that that was such an unusual thing.

But then, however many years it was later, 15, 10, 15 years later, when I was working using the armchair, of course, again across the same thing where register 15 is the program counter. But anyway, it was a tiny 8 bit processor with 128 bytes of RAM. I'm pretty sure the first program I wrote for it was a brute force multiplication program that added numbers together and you programmed it with a hex keypad and a seven segment display. So there was no basic interpreter or anything like that.

But yeah, nowadays, obviously anybody who wants that experience simply picks up an Arduino or a Raspberry PI or any of these fun little embedded processor cards. But there is something incredibly invigorating about working so close to the hardw. Being able to relate what you're doing as a programmer with what you can see in the circuit diagrams and with what you can connect to the exposed ports is really fun. And programmers with my background are apt to feel almost a little sorry for people who only had the chance to work in very high level environments.

Well, you must be excited about some of the Arduinos and the. You still have high level languages, but at least being able to feel like you're a little bit closer to the machine than we normally operate on the web. Oh well, I mean, also having had the experience of working closer to the machine, I also really enjoy the experience of working as far away from the machine as possible. In a way that's kind of the goal.

We're trying to make computers tractable for humans and in a way that means making them less like computers. It's interesting to hear your take too on like, I don't really thought about it Jared, but you know how they, how the MK14 is declared. MK14 was a thing back in those days. And you know, Jim, your history and where you came from, like you're a, you know, you're an older guest than we normally have on the show.

So you have this history that goes back, I guess to the early days of things taking place in the early surge of technology. And now you see more and more like Arduino and you know, these kits, so to speak, that had this resurgence over the last, you know, say five years, how it was a thing and then how it's a thing again, you know, not 1977. Now it's, you know, 2014, 2015. And you certainly see those patterns endlessly repeating.

And there's mobile phones get 64 bit processors, there's something else even smaller, who gets the 8 bit processors that use to drive mobile phones. And yes, it's a great process. I think as a enthusiast for computers, one sense in which I feel extraordinarily privileged is that obviously right back since the 1970s, I've been keenly acquiring all the computers. And one remarkable thing is every computer I've got, right up to the MacBook Pro that I'm speaking to you on now has been better than the previous one.

And that's amazing if you think if we were horse riders, it wouldn't necessarily true by the time you got to my age that every horse you acquired was better than the previous, but indeed a tiny fraction of the price. But it's also slow, you know, in the 1970s, much of what we take for granted today was envisaged by people who weren't that specialist. I remember my math when I was playing with tape recorders in the early 70s, my maths teacher, math teacher, I should say, telling me that in the future there would be take recorders with no moving parts. Which thought was a fascinating insight.

And it took me ages to kind of understand exactly what he meant. And of course he was kind of talking about MP3 players, which we then waited 30 years for. And it wasn't useful I can bet on based on his prediction. But it just reminds us that technology while it's happening can seem like this tremendous rush, but actually it can be terribly slow and there's all of us on the sidelines saying, come on, give us a 300dpi full color display.

Which I've been saying since the early 1980s and it kind of didn't come true until a year or two ago. Here's a question I've been thinking about lately and I think, Jeremy, I'm going to use you as my test subject to ask and see how it goes. So one thing I've been thinking about with software, you know, we cover open source software and we all know how fast it moves. I think we'll talk to you later about JavaScript specifically and how fast that ecosystem moves.

And something that I've come to think about more and really appreciate is longevity. Because especially in tech where you have very startup, you know, disruption, fast moving, you know, companies are here today, gone tomorrow, type of a worldview, longevity is something that's really valuable. And so one thing I've been thinking back is like for myself, what's the oldest piece of code that I've written that I wrote back in the day, which is still running, still working, still doing its job to the present, or maybe it just quit working. I just realized, oh man, that was running for seven years or whatever it happens to be.

So I'd like to cast that at you. Since you have such a long history of writing software, can you think back and think what's the oldest bit of code that you wrote that's still providing some value today? Gosh, that's an interesting question. I'm pretty confident that the software I wrote in Visual Basic in the early 90s that is still being used, including icon designs that I made pretty incompetently now that I've seen more icons.

I worked for an investment bank in the 90s and so is anyone's guess what's still running there, because they do very odd combination of Tearing things out at the first opportunity, but also keeping the most inappropriate things running for 28 years, so they could easily stuff that too. But Visual Basic has been in the programming landscape, has been one of the big survivors left in busy and all the time in my day job life outside of open source, I encounter surprisingly big business empires that are basically based on the back of a big fat Visual Basic application that's very typically kind of molded around the needs of a specific vertical market. But still, you and I would look at and go see that icon in the top left, Visual Basic. Very cool.

So you recently gave a talk called Hackability as a Human Right. And we're going to get into the wiki. I think maybe this your perspective at this plays into the software that we're talking about today. Before we get to all that, I'd like to ask if you're willing to give a synopsis of this talk and your ideas behind this Hackability as a human.

Right, yeah. So that talk was to a really fun conference called Wuthering Bytes in the wilds of Yorkshire, Hepton Bridge, and a lot of people that are hardware hackers. So I was trying to think of something to say that was focusing on what unites software and hardware hackers, because although I had to solder together my early computers, I learned in the process that I'm not a hardware hacker. And having since then worked more closely with people who can wheel the soldering iron.

I know that it's not my mess here. And one of the words that software and hardware hackers use is of course, hacking. And what I was trying to do is to play with the idea that hacking, what is hacking? And hacking, obviously, I mean, in the white hat sense one has to specify.

And to me, hacking is changing your environment. It's tweaking and improving your environment, typically through engineering, but often just through cunning. And to me, an environment that you can't change, an environment that you're prevented from changing, is essentially prison. That's how prison works, is everything happens to you and you can't change anything in that environment.

And so I like those two extremes. The idea that hacking is a sort of an engineering expression of a human urge that if we didn't have, not that we would all be in prison if we didn't have, but that our lives would be indistinguishable from prisoners if we didn't have that freedom. And so we regard not being in prison as a basic human right for people who aren't criminals. And I think it's reasonable to say to the extent that it doesn't hurt other people, people should have the right to change their environment around them, to seek them.

And obviously, particularly in the realm of writing software and creating digital devices, changing the world around you, it's not the James Bond villain thing of turning the oceans into a ground algae factory or something, we're just talking about improving the light switches, that kind of thing. So, and I think I probably went on a bit about the aspects of all of that that I find matter to me. And one of them that maybe is a good theme for us to explore a tiny bit is that tidy Wiki is unusual amongst open source projects. Not that unusual, but fairly unusual in this.

Its primary target, people, user base, people who are not software developers, they're end users. And of course there are, there's things like Firefox for instance, a notable piece of open source software that's directly used by. But if you think about it, and if you look at the charts on GitHub, the vast majority of open source products are things made by bunches of developers and consumed by a bunch of developers. And so open source is a lot of.

It is a conversation between developers. Now, the aspect of tiddlywiki being. Gosh, what was your original question? Oh, talk about the hackability as a human.

Right. And how that plays into tiddlywiki itself. I was going to bring that hackability point together with the observation that one of the unusual things about tiddlywiki is that it's designed for end users. One of its properties is that it's generative, it lets end users make things.

And so I like to think that it brings some of the magical powers that developers have, because when we think of hacking, the digital realm that is accessible to developers pervades so much of our lives that if you have that capability as a software developer, you, you do have these mini godlike powers. You understand the technology around you and you're able to shape it to your needs. And that's a remarkable capability. It's a multiplication of the power of technology.

Technology in the hands of a programmer, you can do anything. With a computer in the hands of somebody who can't program, you can only do those things that the programmers equipped it to do for you. So I'm very interested in tools like typically wiki. I think there's many others that provide a palette of tools and capabilities for end users or people who aren't conventional software developers to achieve some of the goals that software developers take for granted all the time.

And so does that make sense? I'm kind of thinking that our duty as developers, we have this sort of natural ability to hack the digital world around us. And rather than jealously guarding those skill and those techniques, we should be trying to bring as much of that experience to ordinary people as we can. And the reason I think that's necessary is through tiddlywiki, I've seen that if you provide a tool that can do that, people will build technology to serve extraordinary tiny niches that would never get filled in the commercial way.

So one of my favorite applications of tiddlywiki is a volleyball teacher who has used tiddlywiki to create this extraordinarily detailed extensible lesson planning system. And in fact, it's not. It produces bits of paper, things that I think are printed out and given to pupils and teachers and so on, but it's also got a whole user interface for defining exercises, goals, goodness knows what stuff. And when you look at it, because I know nothing about volleyball, the thing that's really obvious is that it's riddled through.

The creation of it was riddled through with the knowledge and understanding of volleyball. And so the person who built it as a volleyball expert was able to build something very closely matched their needs because of their tool, because of being able to use a tool like wwe, but without it, there was no way that any of us software developers were going to say, oh, yucky, let's go and write the perfect software app for the volleyball industry. So that's where I was coming from with the hacking ability as a human right thing, this idea that kind of trying to frame it as an obligation for us, for developers. I think it's important to consider what you do in a thoughtful way.

And one aspect of being a software developer is sort of ethical, philosophical considerations. It's worth giving them a little bit. Yeah, I love that idea of bringing hackability to the masses. And as the ones who are, you know, the niched, the people with the current superpowers, right, the hackers of today, like, we can bring that to them or we can just hoard it for ourselves.

And so by building tools for end users that are extendable, are hackable, we're allowing a whole new class of things and ideas that we never would come up on our own. Awesome. If I got time to mention a specific one that I like, it's a good example, is that I think git, although source code control in general, but today that means git is one of our superpowers as developers but imagine that capability in the rest of our lives. It's the ability to make arbitrary changes to things completely safe in the knowledge that you can wind them back.

That ability to experimentally change things is actually completely denied most people. If I think about my LinkedIn profile, so I try and think of something as the opposite of the concern of a software developer. I might want to change my LinkedIn profile to present myself differently. But there's no, you know, there's no rewind on GitHub.

I can't go back to an earlier commit. There's just a whole bundle of apparently independent things that I can go in and change. And so that discourages experimentation. And we see that all the time with end user behavior.

There's an old adage that a significant goal of users of software is to not mess up, to not be seen to make a mistake. So, yes, there you go. I agree. I think it's a great example of the ability to rewind and start over.

Yes, I'm suspended. And complete the thought by connecting it to DDIwiki. I think after the break we'll be talking about the way that tiddiddiwiki exists as a single file and perhaps we'll touch on how that can give end users exactly this capability that we as developers get with git. Yeah, absolutely.

I think you do that. Well. Let's take our first break. When we get back, we will dive into the wiki and how all these ideas of yours play into that software and some of the success stories you've had with it.

So we'll be right back. If you're looking for one of the most fastest efficient SSD cloud servers on the market, look no further than our friends at Linode. You can get a Linode cloud server up and running in seconds with your choice of Linux distro resources and node location. And they've got eight data centers spread across the entire world, North America, Europe, Asia Pacific.

And plans start at just 10 bucks a month with hourly billing. Get forward access for more control. Run VMs, run containers, run your own private git server. Enjoy native SSD Cloud storage, 40 gigabit network, Intel E5 processors.

Again, use the code changelog10 with unlimited uses. Tell your friends it expires later this year, so you have plenty of time to use it. Head to linode.com changelog all right, we're back with Jeremy Rustin talking about Tillywiki and Jeremy, we're getting all the details. I love the idea of a tiddler.

We're going to explain that, the single file, the extendability, the hackability. But before we get into all that, I want to hear about the conception of tiddlywiki. You know, there's lots of wiki solutions out there, and wikis are, in my view, kind of a quintessential part of the web and the open web. And so all these wiki systems, most of them are open source systems, because wikis kind of have that open idea ingrained in them from the beginning.

And so can you take us back to the. To the origin of tiddlywiki and why you thought that this had to exist in a world where there were other wiki systems out there? To the wiki's direct origin, as in why I started writing the code. And once I started writing the code, I learned other things that made me think other things.

But the original motivation was based on a really simple observation that I've been using wikis for maybe five years, years in various different work contexts by then and found pretty much what everybody finds. They work really well in a technical community. They work less well as the community gets less technical. But more interestingly, I learned, as I guess everybody does, that you need to, that the ability to refactor content in a wiki is incredibly important and that a useful wiki that's shared within a group needs kind of constant tending.

Everybody needs to be looking out for opportunities to improve it. And I'll call those improvements refactorings. And what you observe with people using, say, MediaWiki is if they're approaching. There's two, perhaps archetypal refactorings with wiki.

One is to split a page into two. One existing page, you realize that there's a subtopic there that deserves its own page. You shift it off into a separate page, or conversely, you've got two pages you realize are about almost the same thing and merge them together. And when you watch people doing that with media wiki particularly, you will see them open those various pages in different tabs so that they can more easily jump between them.

And if you've got the keyboard shortcuts to hand for dealing with tabs, it can make that kind of refactoring actually pretty efficient. And when you switch between tabs, most browsers will retain the current selection within a text area. So it's quite easy to kind of line things up and get quite efficient that way. Well, I'm sure the Emacs and Vim users will argue that there's more efficient ways to operate anyway.

So it made Me wonder whether there was a more direct way that the software could support the interactions necessary for users to perform those kinds of refactorings. And then I saw Gmail at the beginning of 2004, signed up at the 1st of April 2004 I believe was when they launched it. And it seems extraordinary, modern audience. But the innovation in Gmail was the way that it showed multiple email messages at once.

Until that time, pretty much all email clients. You'd seen a list of individual emails in the thread, you selected one of them and then the text of that email was displayed. And this idea of having the same user interface gadget that was used to display an individual message repeated down the page, to me, I thought that was really attractive. It made brilliant use.

It's one of the things that is kind of second nature when you think about the web as a web page, but rather alien, with a sort of more old fashioned Visual Basic laying things out on a corkboard sort of view, which is rather was the prevailing view at the time. So all I did was to combine those two existing ideas that I saw to create a wiki where the pages were shown as individual chunks on a page. I've explained it badly because I was already interested in the kind of philosophy of recording and reusing information. And one of the ideas that I think I evolved, but that probably means that I read it, was the idea, well, two linked ideas really, that the purpose of recording information is so that we can reuse it and that the way to optimize information for reuse is to chop it up into little bits.

And those are kind of assertions that I have no formal proof of. But that's based on my experience of watching myself and other people working on stuff. And the small chunks of information thing is also it was part of. At the time I had.

I wanted to write as to be part of the blogosphere, but I knew that my tendency was to write very long pieces. I've been trained in essay writing and with lots of. I have to kind of kick myself to remove the rhetorical flourishes. So I rather liked the whole idea of building a tool that encouraged brevity, that encouraged concisely expressed ideas, so that by optimizing the tool for small chunks of text, you would avoid the problem that somebody faced with a massive blank text area will feel compelled to fill the text area with unnecessary embellishment and detail.

Not really blank either. If you see a blank page, designers out there that are familiar with Photoshop and a brand new document, this document, you open up and it's just white. And it doesn't encourage any sort of creation. Yes, whereas in siddilywiki, when you add something to an existing wiki, your new item will appear alongside the existing entries.

It feels explicitly like you're accreting onto an existing thing. Whereas presented. Yes, presented with a white box. Although sometimes it's what you want isn't necessarily conducive to thinking.

So that was kind of the idea. And I thought what needed to be what. I had a number of other sort of ideas floating around that seemed to connect with it. And at the time, Flickr had just launched, and so I thought that the obvious thing to do was to create a service like Flickr that would be based on what I was calling micro content, small fragments of text that people would share and tag and arrange into albums and sequences and so on.

So pretty much Flickr for text, for small fragments of text. And the very first thing I did to explore that was to create a prototype in JavaScript. And at the time, I'd only had the loosest experience with JavaScript. I looked at it from a distance and thought it looked like C and not really got much beyond that, but right this time, prototype.

And at the time I didn't have access to a server, and so a friend of mine had a static server. So the easiest way for me to kind of publish this demo so that I could talk to people about it was to create it as a standalone HTML page with embedded JavaScript that ran the demo, so to speak. So I put out what I thought was what people do all the time, a simple JavaScript demo that I thought would maybe start a conversation and help me to explore the ideas that I was expressing within or help me to explore them with other people. And what actually happened was that it got a certain amount of attention from a couple of.

At the time, it was blogs that used to be how people obtained links to interesting stuff on the web. And a blog called Kotki covered it and everybody. Yeah, I still read Pacquiao every day. Well, back then it seemed like being governed by Entertainment Weekly.

That's not the best example, I think it felt like very big splash. And so then there's a flood of people who don't know anything about wikis coming to this demo. And they go. When I say they, I mean the feedback that I then read, particularly on there was this bookmarking service called Delicious at the time.

And so one of the sort of ways that I got feedback then that would be kind of on Twitter now was the comments that people left as they bookmarked to do wikipedic.com, and the graph of people increasing. And the reaction to it was hey, that's really great once they fix it and make it work properly. And I was like what do you mean? And people's experts, despite the fact that I built it as a demo, was that it was a product.

And so it got to be rather a. So the way that I'd written todo wiki you could this initial demo of it was that you could make changes to so you could interact with this JavaScript application. And then when you tried to save your changes it popped up a pop up window that then JavaScript printed out your data in basically in HTML and you could copy and paste it elsewhere. And so what people were saying was that when you press save, it should actually save your changes so that the HTML file is modified.

And I got incredibly frustrated saying to myself and others, well that's ridiculous because you can't do that. An HTML file loaded in the browser can't save changes. That's absurd. But then saw that somebody else had worked on a Firefox extension that laptoply wiki save changes.

So it used the privileged APIs and there were available Firefox extensions to access the file system and save the HTML file. And then I discovered that these same APIs were actually not that privileged and you could use them from an ordinary HTML file. So then suddenly it was, well, I thought that was a rather nice example of something I found before that there are certain situations that the best response to them is just to write code. And when people are giving you a hard time about shortcomings of a product, then just write code and it's often the most useful response.

And in this case I'd unexpectedly uncovered what I now think is a potentially important but still much overlooked way of running software. And it's basically the idea is to treat the browser as a virtual machine and you can is quite explicitly a virtual machine virtual machine running JavaScript. But start to think about the browser as being a virtual machine container in the same way as virtual machine containers hypervisors and you realize that it's not so very far away. You can provision on your virtual machine by pressing command T.

The computing power available within a browser tab of course exceeds that slice of computing power that Facebook.com or Google.com is going to grant to your unique needs. It's good. I mean you're describing a little bit of the history of tiddlywik. You Start off with this demo of an idea around these small chunks of text, and then you provokes information.

Yeah. People got mad at you. And so you decided, I'm just going to code instead of reacting, just to going to keep coding. At which point now you've decided that you're going to start storing all of the information in the browser and you're going to start using it as a virtual machine.

So a little bit you're giving us the background of how tidywiki came to be. Maybe let's talk about this idea a little bit more of the unique, or excuse me, of the small, small chunks of text. It seems like that's the idea that has continued forward as you develop the software. One thing that we pulled off, I'm not sure if your website or a blog post, is that you said that tiddlywiki is based on the idea that information is more reusable if it's sliced up into the smallest semantically meaningful chunks and then woven back together to make narratives and stories.

And you call these tillers. But I think I referenced earlier. That seems like the unique bit. That seems like it's a unique take on the world.

Yes. And so again, it's a bit accidental and a bit deliberate. The word tiddler came from writing the code that. In the code, I was at first thinking, I'm dealing with objects, nodes, items, you know, all those words, records that we use for generic things that you deal with.

And lots of apps generalize everything. Like, I don't think WordPress does generalize everything to the point where basically everything's a post. And so I needed a word to describe that thing and had beforehand come across the advantages of neologizing an unusual word. And tiddler comes from an English.

English word. Tiddler just means small tiddly. It also means drunk. So it's kind of a joke where Italy winks comes from a game with a little tiddly wings.

That's different. Again, it might be the young person. So again, for tiddlers, these are my tidbits that you could say about my young children or something. But it turned out that it was the right place to neologize, that the idea of a tiddler, although closely related to lots of similar ideas in other applications, is so important and central to tiddlywiki that it's worth neologizing and choosing a word that we get to define.

And that is pretty much the definition that you gave the idea of the smallest semantic unit. So often when one uses tiddlywiki you might write a stream of consciousness. You write for 10 minutes to capture what you just did for the previous hour. And then as I mentioned before, an archetypal tiddiddwiki refactoring would be to slice out chunks of separate siddlers.

And then it's kind of the idea of active learning that when you learn something, you write it down and that improves your chances of remembering it. If you write it down and then do something with it, use it, that improves your chances even further. So the idea that you'll record information, refactoring it, changing the title so that it makes more sense when you refer back to it in the future, giving it some tags so it gets tied together into different categories, weaving it together into. Weaving it into different stories along with other items, those kinds of ways of exploring your data and kind of, sorry, exploring your information and crucially presenting snapshots of it to other people.

So, you know, common, you think about people who do stuff in Excel, a common thing is they've got some unholy mess of spreadsheets and macros in the background. But what comes popping out at the far side, it is a fairly simple spreadsheet that everybody can understand, showing the disposition of sand in the sandhills a little bit. One thing that FND said is first of all, the way it's built is unusual and thought provoking. It's probably this idea because I think that is the uniqueness and I think the way you think of the small, it's a bunch of pages.

You know, you edit a page and link pages and you know, with WordPress like they had posts and everything was a post and then they had some pages and then they started to like, you know, it started to expand beyond that idea and so the software and the nomenclature had to change and they started to, you know, started get that square pen and round hole. And it seems like the same problem happened with a page where like you said, you're refactoring. I think like trimming the hedges like you're, you're maintaining that the wiki, you start to realize that pages is not small enough for things to actually fit together in the way that you think about them in your mind. And so I think that the reason why it is unusual and thought provoking is because you're really focusing down on really small units of.

Is it just text or is a tiddler be an image or a link? A tiddler can be an image. There are situations where it makes sense to use a Tiddler to represent a link, but equals to links embedded within a tiddler. And you can have mp3 tiddlers wav tiddlers.

I mean anything in the mind type. You can do something within a browser it deals with. Very interesting. It also works with SVG.

But to pick up your points about TiddlyWiki not seemingly a wiki. There's the most common characteristic of a wiki is this idea of a wiki that anybody can edit. It's the kind of a page that anybody can edit is the highest expression, purest expression of the idea of a shared space. It's a shared space with no rules and no admins often.

But I always felt what was interesting about wikis wasn't that at all, although that is interesting. It was the way that wikis turned linking into part of the punctuation of writing. So I've always found hypertext and the previous developments in hypertext very interesting. And one of my observations is I think hypertext is an expression of a fairly common set of beliefs about how our brains work.

And our brains work to many of us feel without being too presumptuous, but some of the time it's useful to think of our brains as lumps of things connected by lines, as would be depicted in a mind map would be very direct expression of that vision that people have. Until he doesn't seek to express those relationships graphically like a mind map, although it can. There's a plugin to do mind mapping, but it seeks to give you a data structure that's rich enough to represent those kinds of structures. So the tiddler within tiddlywiki, once you get to the level of detail beyond its smallness, it's a kind of universal data structure for thinking about items of data.

And it's. In computer science terms, it's just a hashmap by title. And the tiddler is essentially a hashmap of field values named field values. So it's a similar data model to a lot of the NoSQL databases at the moment, for instance.

And yeah, that's turned out to be kind of easy to do because it's hypertext. As I say, we're 50 years into the history of hypertext and we've got some. There's some strong evidence that people like linking as a metaphor for, well as a way of expressing relationships between items. As software developers, we certainly like to define and have this nomenclature to things and understanding the depth and also your path to understand what a tiller is and what it means to you and how it's an atomic unit and it's the smallest unit is going to give us a lot of clarity, especially as we get into the more technical pieces.

Let's take a break and we come back. We'll dive a little deeper into tiddlywiki, how tillers plan to this larger and real peaceable. We'll cover them outside. So we'll be right back.

We're excited to work with BMC to spread the word about True Site Pulse, their infrastructure monitoring service with one second resolution atop the mic. More on the cross architect about the importance of alarming, but more importantly the importance of more accurate alarming. We also talked about integrations and how that plays into communicating internally across your teams as well as outside organization. Take a listen.

So alarming comes in really handy when you have one second data because we actually collected different resolutions and we aggregate that data into 1 second, 15 seconds, 60 seconds, 5 minutes. And what that allows us to do is we can actually pull out some of the noise and give you more accurate alarms. Now the question is, what do you do for me? Send me an email.

Well, that's not gonna be very helpful. Really what I want is I want to find a way to push that towards my team. So we're all knowing what's happening with the services, what's up, what's down, what's fixed, what's not. And that's where the integrations come in.

So integrating in with things like your chat, how do I integrate into my other tools like PagerDuty, your oxygen. So how do I take advantage of hooking up who's on call and who's not and then potentially how to do automation. So fire off a webhook or if you have another setup, you can set up an email and maybe that triggers something for you. But essentially you end up with that full round trip with everybody involved in that process and that's your developers and your operations team, because both of them have to be involved and know what's happening.

So kind of with that end to end level, we can pull the different stats from everywhere. We can share those dashboards between anybody in your team at a certain point in time and we can embed those dashboards into any of your existing dashboards or monitoring tools or things you may have. And that gives you the ability to share that information outside your organization. So that way you kind of have that one single piece that you can talk about, share about and see those metrics everywhere.

I have the ability to have that communication with my team and I b have the ability to have that same visualization across my team and external core team. That was Mike Morin, the senior architect of BMC's True Sightballs. Head to bmc.com true sightballs all in word to learn more and tell them Adam from the chainsaw sent you. All right, we're back for the break.

Tiddlywiki Jeremy's here. We're talking, you know, we talked about breaking down each of the pieces. Tiddlers, as you called it. I love the backstory there, especially tying back to the UK where you're from.

If you're listening to the show, you couldn't tell us where Jamie's from then check your ears or something like that. But TiddlyWiki is 98.5% according to GitHub JavaScript. How do you, you know, we cover that a lot around here. We have weekly email, we're always seeing the ups and downs and we even cover the, you know, the madness of frameworks in JavaScript and the fatigue that comes from it.

So having such a JavaScript depth to TiddlyWiki, how do you personally deal with this ever changing JavaScript landscape? That's a good question. So TiddlyWiki started in 2004 before any of those things existed. So I had to write my own bits of code to smooth over the differences between different browsers.

For instance, there was no jquery. So over the years what I've discovered is that for reasons that are Fairly specific to TiddlyWiki, it's quite useful to keep it as clean as possible. So it's pretty much self contained. It doesn't use any external libraries, but you can use external libraries with it.

So there's a sense in which some of the considerations that you'd apply to a library actually apply to tiddlywiki, even though it's an application. So I've been in a happy position of being able to watch and experiment with lots of JavaScript libraries. So D3, for instance, which I guess now is probably five or six years old, was one of the things that helped me to understand the potential of SVG in browser. So svg at that point, embarrassingly, we hadn't realized that a technology that had been broken in 2002 had quietly got fixed over the following five or six years.

A more recent things like Angular and Reactive, the kind of second wave of frameworks, I don't use those frameworks because, say tiddlywiki is kind of is its own framework tiddlywiki has a consciousness. Might be going a little bit too deep. Before I jump in, how is it? Describe how TiddlyWiki has its own framework.

So, I mean, you mentioned, I think you mentioned React and I couldn't remember what else you said, but. Because I was trying to follow along. But how's its own framework? From a distance, this will seem like a security answer, but hopefully we'll get there in the end.

From a distance, what? A wiki is a piece of code that converts Wiki text into HTML. In the case of TiddlyWiki, particularly the new version, my goal was to make the WikiText powerful enough that the user interface of TiddlyWiki itself could be written in its own wiki text, thus making it highly extensible, etc. And it's just like writing Chrome developer tools being written in JavaScript.

It's kind of a logical approach. And so you can imagine then that the pipeline that goes from WikiText to the DOM needs to be interactive in that case. So what tiddiddlywiki does is it parses the raw text of the tiddler into a pretty straightforward syntax tree, and then it executes that syntax tree into what tiddlywiki calls the widget tree, which is pretty much the virtual DOM tree that you see in things like React and Angular and the virtual DOM tree. Then there's a process that does well, close to the minimum or a fairly good subset of the maximum updates, the selective updates to the DOM.

So if we've got a WikiText construction like a Transclude, which will be familiar to JavaScript programmers from ordinary web development templates. So double moustache in double moustache, I'm sorry, in WikiText typically means transclude this other page, make it appear as if this page is here. And so in an interactive wiki like tiddlywiki, you want to make sure that if the text of that target page that is being transcluded changes, then we get minimal DOM updates to update the transclusion, but not the text around it. And that's what diddlywiki does.

And that enables all the paraphernalia that you see in the user interface, things like tabs and dropdowns and everything else, is modeled as the state of tiddlers. So the state of the user interface is modeled as tiddlers. To update the DOM with the state of the user interface, we render one single WikiText template that expands out to be the entire Domtree of the user interface. So what I described there was kind of talking about the internals of other libraries, and many of the people who use those libraries wouldn't necessarily think about them working in that way.

And I find that when I read about these libraries I have to kind of do some picking apart to relate my understanding of what they do to what I know about how Todiwiki works. But it's good to see that we're all on the same page. You do stuff in JavaScript as much as you can. You don't touch the DOM unless you have to.

Back in 2004, a very common idiom was that you kept maintain state in the DOM and it's still an incredibly useful trick on the web and appropriate in a lot of circumstances. But all of these products, including Dillywiki, gain enormously from moving all of the state into JavaScript variables and treating the treating the entire DOM is essentially transient to something that you can recreate at will. So that stuff those characteristics of Diddlywiki interestingly aren't they're not appreciated in the terms I just described them by the users. It's a kind of it's a very developer ish quality that they're describing, which we're happy to hear as developers ourselves and develop our audience.

So feel free to share the details are absolutely interesting to us. So one thing that FND mentioned is that the and maybe I missed this, forgive me if I did that this latest incarnation of witteddicky was rewritten from scratch. Was there like a big rewrite somewhere in the history and what was the reason for that? There were a whole multitude of reasons, but the main one was that some of the quality of the code in the original Tilbury Wiki was pretty cool.

I didn't know JavaScript when I wrote the first version. I thought it resembled C and I treated it like C for a few weeks and then gradually learned more and more about JavaScript. But it meant that there were decisions that were there were decisions that were impossible to reverse because other people had written code, plugins and so on. That was based on my code.

So I really felt that to fix the internal architecture we needed a complete rewrite. But there was also an opportunity in the change in the environment that JavaScript had shifted from being regarded as a niche embarrassment to become somewhat mainstream. So somewhere in 2011 no JS launched and I'd been waiting for that. When I was working for BT in about 10 years ago, I looked at Rhino so that it was possible to run JavaScript on the server.

I use Rhino back to yeah, in the late 90s the Netscape had some software that involved running JavaScript on server and looking at Rhino. The making tiddlywiki as I had written it, working Rhino would have been almost impossible because TiddlyWiki was heavily based on the DOM. There was no DOM in Rhino, and there was no decent support for writing web applications, for writing web servers. So when no JS came out, that seemed like a wonderful opportunity to fix one of the biggest frustrations for me about tiddlywiki, which was the limitations that stemmed from it running as a single HTML file in the browser.

So it's the quality of DailyWiki that leads to its most unique and unexpected future features. But it also, as everybody listening to the podcast, has profound limitations. There are pretty severe limitations to what you can do in the browser and I was confident that the ideas that we the community had explored with dillywiki were actually equally applicable to the server. So the opportunity window JS came out, the idea of writing DailyWiki as an isomorphic application became overwhelming and I left a job that I was in in order to do more flexible freelance consultancy work so that I could spend a bit more time on this rewrite.

So how is the wiki content persisted nowadays? It depends where you're running it. In a way this is the easiest audience to explain it to. Imagine that we've got a function just like I described that takes a chunk of wiki text and converts it to the to run that on the server we have an implementation of a very simple, I call it the fake DOM, but JavaScript, pure JavaScript implementation of the DOM APIs, so that on the server we manipulate that fake DOM and then we do an inner text on it to extract the HTML.

So given that engine and its capability running in both of those places, we can run in a bewildering number of configurations. So if we can run entirely in the browser and we save changes using HTML5's download attribute, which is a standard attribute, a standard feature of HTML5 that allows JavaScript executing the browser to prompt for a download. So in that case the experience is that each time you press save, you get a fresh copy of your up to date copy of your document. And that's not bad, it means that you get cumulative backups or you can configure your browser to prompt you when you save.

And then saving is a two click operation, but you update the original HTML file or there's a extension for Firefox that allows TiddlyWiki to save directly to its own file. Or there's a nwjs based desktop application that accesses to a custom browser that lets the single file configuration of tiddidwik again persist changes directly. Or you can run it under Node JS, where individual tiddlers are served over HTTP to another instance of TiddlyWiki running in the browser, and then your changes are persisted as individual files. So each tiddler is an individual file.

Or you can run siddiwiki Amazon Lambda, where it starts up, reads a whole load of tiddlers from DynamoDB, mashes them together, and then squirts the files out to Amazon S3. So really, although it's packaged and presented as a product, and I highlighted how important to me it is that it serves the needs of end users, what it is, in fact functionally, is a reusable JavaScript library for handling Wiki tag. And within TiddlyWiki we reuse it endlessly. So I described how we convert wiki text like headings and listen so onto HTML.

But we use the same engine to convert style sheets. So inside tiddlywiki's style sheets, we transclude what would in something like SAS via Variable. So we've got magic tiddlers that contain, say, the background color of the page, and then in a style sheet, wherever you want to reference the background color of the page, you just transclude that tiddler. And that's a characteristic angle developers love, is the idea that you only introduce new mechanisms reluctantly.

And when you do introduce a new mechanism, you make it pay its keep by using it orthogonally on lots of different problems that have the same shape. And you see that in lots of software. And JDWiki uses the same pipeline, the same processing pipeline to do interactive rendering in the browser, to produce static renderings on the server that then get served on a static web server. Plus all this internal stuff like the way it handles style sheets, the way that it handles color palettes, all that kind of thing is all wiki text mechanisms reused.

And there's something very pleasing about it as the creator. But the idea is, as a user, it's tools that behave like that have this pleasing property that you learn how these components work. And ideally in a sequence where you learn about the gradually more components, complicated ones, and then kind of like a bicycle they become the internal structure is sufficiently apparent that you can have a strong mental model of how to use the tool. You can anticipate how it's going to behave in a situation we haven't used it before.

It turns into something that feels like an augmentation of your brain. And that takes us back to Vannevar Bush and the early hypertext pioneers. They were obsessed with the heretical idea that people would use computers interactively. So in their work, one of the challenges they faced was just persuading people that that was practical and that the purpose of doing that was to extend their capabilities.

You sent us a nice write up in Network World about tidywiki. We'll put that in the show notes. One thing they said in that, that was very interesting, I think plays in this idea of single pilot pipeline, is that tiddlywiki is a quine. Some of them know that, some of us don't.

I've actually seen these before. I think I've had. But they're quine Q U I N E. It's the idea of a program that doesn't have any inputs, but as it's the process of it running, it outputs its own source or it outputs itself as the program.

And I've only seen those as like mental gymnastics type of things, like one liner. How do you do that? Can you do this in this language? They're very short snippets in there.

You know, it's a. It's kind of a. Not a toy, but it's a way of people to challenge themselves. And I've never seen an actual full on useful program that's also a coin.

Can you speak to that? Yes, there's. Well, you'll see some spectacularly useless coins. I've seen coins now that run in more than one language, quines that are also ASCII art at the same time.

So yes, there's no limit to how much effort people will put into these apparently pointless pursuits, but it's because it speaks to some sort of inner satisfaction. It's like an automaton that can reproduce itself is a fascinating thing, especially if you throw it in the lake of raw ingredients. So yes, it's a kind of timeless vision. Love that.

Absolutely love that. Well, let's take our final break and we'll talk about a few other things on the other side. Specifically, we talk about deployment and all these different ways you can persist it. I want to talk to you about what that looks like for your end users, whether they're going to one click install on a shared hosting or how the end users come to the wiki and set their own end user use them.

And then also talk about getting Started helping out, getting involved if you're looking for helpers or not. So we'll discuss those things as well as our closing questions on the other side of this break. Here at the Change Vlog, we have two emails we'd love you to subscribe to. The first is Changelog Weekly.

Now we've been shipping this email for several years now. We ship it every single Saturday morning. It's everything that hits our open source radar. It's our editorialized take on what happened this week in open source and software development.

Go to changelog.com weekly to subscribe. And our second email is changelogmile. Every single night we should just email out covering all the top new and top repos on GitHub at 10pm central time. It's all the latest stuff on GitHub before blows up.

It's often our own radar. We're often creating shows and finding new people, finding new projects, putting them on our own radar based on what we find in there. So we'd love for you to subscribe that head to chainsaw.comnetly and now back to the show. So Gary, before the break, you tried all these different ways that you could, you know, persist your tillers into different backends, even AWS Lambda, which is pretty interesting.

And I started thinking this sounds like a really awesome hacker tool, like you can do it this way, you can do it that way. So hackers love like giving the flexibility, gave me the freedom. I want to run it on a Raspberry PI, I want to put it on the digitalocean. But you also want this to be a general purpose, usable tool for anybody, not for just hackers.

So what's the use case of somebody who's coming to it and they're just looking for a wiki here, they're just looking for this web based notebook. How do they use. Great question. My approach to it has actually evolved over the time of the rewrite.

When I started the rewrite, I thought that it was important to present tiddlywiki in all of its multifariousness. I'm not sure if that's the right word, but all these different things that you could do with it. So I presented them or tried to present them on the site as if they were kind of peers. And what I found was that that was confusing for quite an important constituency, which is the people who were going to use the single file version of tiddlywiki were terrified of GitHub, didn't have any understanding of the command line.

So the Non developer types. So what I've ended up doing is making two pathways if you like. Gosh, that's a ridiculous word. But one is people going to tidywiki.com, we try to help them as quickly as possible possible to start using the standalone edition on their machines and the GitHub and it's GitHub.com Germaline Tiddlywiki 5, which is the rewrite version, is information for a developer audience and that does try to give a taste of all of these possibilities.

But I think as other open source projects have found, when all of these interesting developments in the project, a lot of them aren't from me, they're scattered throughout the community and they're at very different stages of development and some people have different publish at different times. So the community can seem very fractured. We, we've done a great job in open source of adopting tools that help to minimize that effect. And GitHub itself, of course the word hub is right in there to remind us of its main purpose is that it's the.

What do you call it? The village green for open source development. Right. Speaking of GitHub, I was on the TiddlyWiki GitHub page there and I know something that was a little bit concerning and just want to talk to you about the state of it because actually one of our closing questions is sometimes how can the open source community help support tiddlywiki or the project that is important to you?

And one thing I noticed you got a whole bunch of open issues out there. You got a lot of pull requests, you got 67 open pull requests, you got 520 open issues. And so I'm just curious that maybe the demand and the people the interest in tiddlywicky is overwhelming or you got it under control. What's the.

Interestingly, you're raising something that we in the community are trying to tackle at the moment. It's partly the result of a poor decision that we made last year, maybe the year before. So we use Google Groups as the mailing list for the project and we've got a mailing list called tiddlywiki and mailing list called tiddiddidwikdev. The first for users and the second for developers and I think pretty much we all hate it, but it happens to be where we tied a horse that's a bad metal but right at the beginning and some of the non developers anyway, for various reasons we decided to experiment with using GitHub issues for discussion and so Quite explicitly, we had the policy that it was okay to have basically anything that you wanted to discuss as an issue without a clear policy on closing the issues.

We're moving now to a much more conventional. And I'm so familiar for me, yeah, that's a lot of issues I was worried. And you'll see the worth of those. I mean a fifth of them are one person and that's.

And you should be extremely careful that I think that in open source we are incredibly lucky whenever anybody opens their mouth, even if they're saying something the same thing as somebody else, any kind of feedback is like oxygen for an open source project and it's obviously any other people's interest that keeps any project like this alive. So yeah, bit of a misstep on how we handled issues. We're moving to issues being more explicitly needing explicitly being the to do list for the core developers and there being basic requirements about actionability in order for them to remain open. And we will continue to host, I'm sure lively discussions on closed issues, but we'll try and keep the open issues above the waterline issues reflecting what we think is actually doable, actionable work that makes sense for issues.

But what about pull requests? Oh well, I mean I'm behind so. But you'll see if you look back that some of those issues have been around for an embarrassingly long time. So again, I've not had a clear policy on closing pull requests where they've gone off into a discussion.

I've tended to just leave them open. And the reason is because I haven't been using call requests or issues as my to do list. I've been tending to fall back to using essentially using email as my to do list. You know, you respond to the tickets that thanks to the noise on them, those risen to the top of your inbox.

I think it kind of reflects our peculiar heritage as having a substantial audience that are not developers. So a lot more of my tickets I think are open by non developers than would be typical for a library or a framework or something. In terms of pull requests, I wonder. I think tiddlywiki is also quite hard for new developers to get into because of some of the things we touched on.

It is its own framework. It's not like working in jQuery. Not keeping state in the DOM is profoundly difficult for people who've only ever worked that way. So we do.

And plus sure other people have experienced the same thing. You have to have quite a high bar for what you accept. Well, how well do you document those things like that, the DOM piece specifically, because it sounds pretty unique, it sounds pretty awesome. But how well is that documented that invites people into.

Because I think docs might lend a hand there. Again, a very good question. And I think I personally am not always the best documenter, so I can think that something is fully documented because I precisely described it unambiguously. And yet there's an enormous gulf between, in some cases between that and what's needed for people to have a clear understanding if they lack the context of being inside my brain.

So yes, it's a challenge and I guess what saved me so this rewrite's been going for five years, or nearly five years now, with pretty uniformly all the way through. People can come along and say documentation could be improved, and yet we've survived. And I think it's the universality of code that actually saves us that for a small but significant part of my audience, they can verify how the software operates by looking at the code and not that much of it. It's fairly neatly sliced up.

And so from a. If you've got enough of an incentive, it's reasonably attractable to find your way around and just see what the thing does. Well, there's different kinds of open source projects out there. Every maintainer or author runs their projects a little bit differently.

And you've got 87 contributors over the years. And this is probably just since the 2011 rewrites. All we have history in git, but if we go look at the contributions list, you have over 5,000 commits personally and the next closest is 158. So an order of magnitude difference there.

And as a fair, you're the primary developer onto the wiki and people who pitch in here and there, but it's not like a robust team that's working on it day in, day out. That's absolutely true, yes. Do you like it that way? Are you looking for more help or you like to keep on keeping on?

And people can help in other ways. The people who are missed out on that analysis are the people who work on kind of other things within the ecosystem. So for instance, Tiddly Spot is hosting a service that's been running for my system as diddidwiki, and it's completely independent and it's supported by people other than me. So yes, in terms of the code, that does tend to be 98% Jeremy or 95% Jeremy, I'm not sure.

But in terms of the ecosystem as a whole, it feels crucially like I'm less than 50%, because again, projects like Tiddlywiki, like All Open source projects, it deals with the conflicting requirements of its user base by adopting plugin architecture so that we can encapsulate conflicting requirements in plugins. And in any project with plugins and a community, you'll see most of the innovation happens out in the plugin space. And that's definitely how I like it, because that way there's a multiplicity of different things going on at once. Things aren't serialized on Jeremy's singular brain.

So if you want a project, if you want a system like that to survive and be healthy, oddly, the Core needs to be unbelievably conservative. You basically want to hardly change anything apart from minute bugs or reproduce that well, actually, you want to hardly change anything, but once you've got to where you need to get to. But what you do change, you need to pay incredible attention to backwards compatibility, because plugin architectures typically allow very tight coupling between the plugins and the host architecture. And so you never really quite know what you might change that might inversely affect the plugin.

So a lot of my job in the Core is for sure there's an agenda of features and mechanisms that need to be added and improved, but a big part of, of dealing with the kind of daily development is that it's kind of making sure that it works well as a platform for the ecosystem, trying to encourage contributors, in many cases to focus their efforts on working on plugins rather than the core. Because once you put something in the core of a project like tiddlywiki, there's no going back. You can't then retract it, you can deprecate it, but if you want plugin compatibility to carry on, you've got to keep the thing there. So there's a kind of.

It ends up. I make it sound like a horror movie that you can never go back into, but honestly, it's joyful. Because what one sees in exchange for I can't treat the Core as my plaything, that I do what I like with, I have to be extremely respectful. And what I'm respectful of is this, the ecosystem, the sense of artifacts that people have created, but also the thousands of hours that people have invested in understanding the product, figuring out how to get the best out of it.

And in the end, the software consists. Often it means to an end, in the end is a well informed, purposeful community that can solve a bunch of problems together all alone that they couldn't do before. And I feel that again because of this sense of tiddlywiki being used not just by developers, therefore it's used in an incredibly wide array of situations and contexts. And yes, that feels, feels like the most fun I can have as a developer writing code for other people.

Awesome. I think it leads us right into our closing questions. You just mentioned all different ways that people have been involved. Plugins, you know, obviously you had robust discussions in the issues.

Maybe not the best place for them, but live and learn. So our first closing question for you, kind of relates back to what we talked about just a moment ago, is you have a clear call to action, you know, or a call for help to the open source community, how they can help you take tiddlywiki even further or, you know, to new heights. What would you say to them? What's the best way people can hop in and help you out?

It's interesting. I think what open source needs is people paying attention to it. As we touched on before, one of the wiki shortcomings is documentation. One of the things that I've learned about documentation is that we can try to have a single body of reference documentation that completely accurately describes the behavior of the system.

That'd be a great thing to have, but it's actually not really what's needed. What's needed is introductory documentation that helps people up the on ramp of using TiddlyWiki because of all the different directions that that can take. So for instance, we've got reasonable coverage for people who want to use tiddlywiki in that standalone single file configuration. But the material for getting up and running on Node JS is still not as.

Not as straightforward and easy as it should be. So helping with the documentation in tiddlywiki is quite a good way to start because the documentation is written in tiddlywiki, so making a contribution to the documentation is itself working with TiddlyWiki. And then for a long time, at the beginning of TiddlyWiki was actually WR. Beginning of the rewrite, it was writing the documentation that drove the development.

I was busy writing the tech docs and then trying to write the features I needed wiki in order to present those documents. So given the fact that you began Sinclair MK14, you've been hacking since. And the positive, the white hat version of hacking, not the negative. Given your expansive history with programming and languages and all the ups and downs of tech and how it's gone slow to you or gone fast to others, you got to have a programming hero.

I can't even imagine if it's just one, but if you could just give us one single programming hero, who might that be for you? Yeah, and I thought about this and as somebody who I became aware of in 1996, so I guess I'll have other programming heroes from when I was younger. But it's Ward Cunningham, he's the developer of the original wiki. And for me, the thing that actually first attracted my interest was a colleague showing me the thing first and then telling me that it was 700 lines of pearl.

And I still think that's an incredibly impressive achievement that such a powerful piece of software with profound implications that we've gradually learned as we've used it and built communities around it. Should be 700 lines of pearl. Pretty amazing stuff. So for that and for his work on programming patterns, no difficulty in nominating woodcilling.

So it makes some sense to choose someone who's actually read the Wicked. Right. It just seems like it's perfect interview. So, yeah.

Well, Jeremy's definitely been fun having a show. Definitely been fun diving deep into the witchy and your depth as a programmer, your history program, certainly appreciated coming on show like this and share, you know, from the 70s to now, this rich history and to see you, I think the most important thing is that you haven't stopped, you know, is that 30 years later, how many years later, whatever actual number is, you still go on. So there's something encouraging, open source. There's something encouraging in this community and I think what if you didn't say it directly?

I think a lot of your thoughts and a lot of your passion shares that this is a rich, vibrant thing to do and that it's encouraging to those who might listen to the show. The second is open source for me now, I'm not getting paid, I'm not getting retribution for it, but it's inspiring to see that we've kept it going for all these years. But anything else you want to say in closing before we tell the show? Yeah, please.

If you like what we heard, please give Wikip a try. It's the easiest thing in the world. Just go to wi.com in your browser and give it a go. Fantastic.

And as I said, it was often head on the show today. Thank you so much for spending this time with us after. We thank you for sharing the time as well to hear Jeremy's past and his history he shared here today. And those who just want to show love, we thank you and our members.

You guys rock. Up next, we do have some big shows We've been mentioning these shows and we're excited about the next few weeks of the genesel. We've got the feature WordPress and Calypso with Matt Holmig. We also have a big show we're working on with Matt, 20 years of Ruby.

So if you're rubiest, if you've ever thought about Ruby, if you've ever envied Ruby, you want to listen to the show and you want to tell every single person, you know that we're doing the show with Matt. It's going to be awesome. 20 year history. We've also got recovers, Rockbot, npm in the pipeline, so stay tuned for that.

And that's it, guys. So let's chill out. Let's say goodbye. Right?

Thanks, J. For coming on. Thanks, Jared. Thanks, Adam.

Thanks very much. Bye. It.