What are we doing today? We're talking about open source, because this is the open source conference, as applied to services. Services where oftentimes we end up building them or operating them in a non-open source way. And so we're going to talk about how to change that. I'm going to talk about some of the theory. So what principles we need to apply and how we might go about it. Michele is going to talk about the actual use cases. How it is happening in certain services and how open source is being used, where the gaps are, and so on. Kind of a scorecard analysis. So we have two back-to-back slots. And that's what we're going to cover in this session. So first I want to talk about what the hell our service is. I mean, we are all very familiar with this idea that some software is a service, but what does it actually mean? And someone asked this good question. It was Eric Helms like, wait a second. Tell me specifically why is this software a service? So we figured out, and I think it's obvious once you think about it, that services are software that you run for someone else, rather than asking that person to run or operate the software themselves. So when you run software for yourself on your own laptop, that's not a service, but when you run it for someone else, when you're operating for someone else, that's what we consider a service. And why is this interesting? Well, it turns out that operating the software is hard, especially as it gets more and more complicated, and many people don't want to do it. And they would like to have someone else, like this guy here, run the software for them. In fact, people who I think that's a fundamental principle that we have to remember is that if we force people to run the software themselves, even if it's a service, we've lost the fundamental reason that they came and are using the service in the first place. If they wanted to operate it, they would have chosen software that they can run themselves. And secondly, one of the big advantages of services is that you can bring a lot more benefits, a lot more value to the user of the service than just what is in the source code or what is in the actual application, the actual binary. The fact that it can be connected really easily with other services, or the fact that you can do the operations for it, the fact that in the background, you can scale it, depending on its workload, the fact that you can have multiple users interact with each other in that service really easily. There's so many different advantages. Of course, some of the value of a service is in the source code, absolutely. But it's far less than in software that you run yourself, like the percentage. Let's imagine, on your laptop, when you're running software, the percentage of the interesting parts, the value that's in the source code, written there, that are providing you with some benefit, is very high. On a service, it's much less of a percentile. There's many other things that provide the value as well. And fundamentally, this means that it is harder to take a service and make a second copy of it, because you not only have to make a second copy of the service. I'm sorry, of the software. But you would have to make a second copy of all of these things the way it authenticates with other services, the way it's operated, which users are using it, the network effect, and so on. And for any interesting service, that becomes very prohibitive to pull off. So those are the fundamental concepts around services that I wanted to share. So let's go into open source. So we're all familiar with this about open source, is that we have people who come. We share the source code. And the ideal is that someone comes by and gives a patch, or checks it out, makes a change. We have a community, a community build. There's interest around the software that we run. And this is a fundamental function that open source converts users into contributors. A small fraction of the users, depending, of course, on the project, some convert most of the users, some convert a very small amount. But it does what we do that. The problem is that open source stars when you inhibit that function of converting users to contributors. So here's an example of an amazing community, Postgres, where, I don't know if any of you actually, I haven't contributed in a while, but when I did contribute, I was super impressed with how they accepted me as a contributor, looked at my patch, actually worked on it, reviewed it, brought it through their cycle. I felt like suddenly I was part of the team. I was blown away by how that community works. We also have Amazon running Postgres for different users. And of course, there's tons of benefits there. There's high availability, there's backups. You don't have to operate it yourself. There's a lot of less complexity and so on. But it is not possible, if you're using Postgres in that way, as Amazon RDS, to figure out what is it doing, introspect the code, actually change something, make a contribution, and become part of the community. And so over time, if all the software is run in that way, we start to starve for contributors in open source. And this is a problem that I'd like to contribute to solving. You can see this diagram here. Open source software, we slowly whittle down the amount of participants. Each time we take a step here from the top down. So first time you might notice, okay, if the software is broken, I should look at it. Maybe it needs a change. And then the user figures out, oh, I can contribute. Then, okay, let's figure out what code I can change. What's going on here? Maybe I'll put a printf line. Like, how do I run this thing that I just changed? Oh, my change broke. How do I fix it? How can other people use my change? How can I contribute it to the project and so on? And each time, there's less and less people that stay with it. And that's why we have a small fraction of the users become contributors. But with software as a service, it's way harder and we lose everyone pretty much right away today. So how do we change this? And if we regress from this open source development model that we depend on, we take for granted, we take for granted that we can go and look at the code that's running and see what happens when we pass a different flag to an API, for example, or whatever. And when we lose that, we lose our basic practices that we use to our advantage. So because services don't have a distribution where you copy the service to everyone's computer, licenses, that is to say copyright licenses, are insufficient to power open source in this concept. They're necessary but insufficient because a service is not necessarily copied multiple times, like we talked about earlier. There's oftentimes just one viable place for the service to run or a couple. It's very difficult to copy all of those capabilities because it's not all in the source code. It's in the interconnections, it's in the users, it's in their data, it's in how the service is used. And so we can't rely completely on open source licenses to be the thing that powers open source and services. So we were talking about this with some of you and in the operate first community, this is a community that has a goal of operating services together with, not just in one company, but together with different companies, different communities, different participants. And we came up with two self-evident minimum open source requirements for services. And I'd like to share these with you. And it took a lot of discussion back around on how this would work and what would come about. And I'd be interested in your contributions, your participation, or your feedback on these. But it's pretty basic and simple, yeah? Okay, so I'll definitely explain that once we show the, oh, okay, so the question is why is this self-evident? What does that mean? And I'll get back to that. So the two, there's two principles, two requirements. The first one is that all of the services, code, assets necessary to operate the service are shared under an open source license and publicly accessible. It's pretty obvious. It's not just the source code, it's what is necessary to operate it, everything that's part of the service. And the second one is that a public contributor can use the same workflow as a typical team member to make a change to the service. These are really simple things. So the question is why are they self-evident? We discovered this ourselves. We didn't start with the idea of we're gonna make some things self-evident. The reason that they, I believe that they're self-evident is because by doing these two things on a service, you enable someone outside of the team working on the service, a public contributor, to take the open source aspect further, to fork, to build a community, to implement the ability to run it somewhere else on a different infrastructure if necessary, to operate in a different way. You enable, this is the core capabilities that when a service has them, these two requirements, you enable others to progress it to more full open source capabilities, more full open source methodology. So this is just the minimum bar that is necessary to enable that. Yeah, the minimum bar, this is not about the best practices in open source. We can all think about how we've experienced open source in really much better ways than these minimum requirements. But these are the minimum requirements that enable others to take the project or service and pursue those better open source practices. So again, all of the services, code and assets necessary to operate the service are shared under an open source license and publicly accessible. And a public contributor can use the same workflow as a typical team member to make a change to the service. There's of course a link down there to the full non-slide version of this with a lot more details in it. And I'll share that link at the end of the talk. So this leaves a lot of questions, of course. Like wait, these are very, very broad requirements. Like they could be applied in different ways. Like what about X, Y, Z? So in that link, if you follow it, you'll notice that there is a FAQ with some basic questions and answers of wait a second, what does this actually mean for this aspect or the other? I'm gonna go through some simple slide versions of those answers. Of course, they're much more fully described in the document and as with all of this, it is open for contributions for pull requests directly and the link to do pull requests we shared at the end of this talk. So the first question, what is the service? We already talked about this. A service is software operated for the user. Software the user is operating for themselves is not considered a service. Pretty obvious. Moving on. What assets, we talk about assets here should be open source. And the answer is make everything open by default except for law, security, privacy or common sense as otherwise. It's not required that dependencies of the service, whether it's deployment dependencies or other services that are connected to are themselves open source for the service to be open source. Could you speak up? No. So the question is when we talk about assets, do we mean the hardware or other things that the software is running on? And no, we're using assets here in the term that many developers use for different pieces not just code, but the operational scripts, the images, the API definitions and other such assets. Right. Right. So the word is confusing because there's initiative for open hardware. So one can think of assets in those terms. That's a good point. Then the question, should tests be shared with the code? Well, tests that are used during the operation of the service, maybe monitoring metrics, availability tests and so on, absolutely are part of the service. And according to requirement one should be open. And secondly, tests run when making changes to the service during the contribution workflow, the CI tests, all of that in order to meet these requirements must be open source. It's of course recommended that further tests are open source, that's always a good practice, but further testing, whether it's performance or intrusion testing or all sorts of other things that are not the two requirements don't apply to, it's up to the service whether to apply open source there. So the minimum requirements just require that those tests that are used in those two requirements are open. Should anyone, this is a common question that comes up, should anyone be able to trigger CI or test suites? Well, no, this is not required. Most of the projects that you run, if they have CI, have a small set of core contributors who perhaps are able to trigger the CI or let CI run on someone else's pull request. The same principle applies here. Must a contribution workflow be documented? Well, documentation is typically necessary in order for a team member or someone to come up to speed and make changes to the service. So if that's required, then yes, we should share that documentation about how to contribute. Must it be possible for anyone to operate the service themselves to make another instance of it? Well, if a typical team member takes the source code or the service and runs it themselves in order to make a change to it, well, then yes. You should share that ability with folks in the public. But if that's not necessary, there's many services where the team members are not launching a whole instance of the service in order to change it. Well, then it's not necessary to make sure that everyone can operate it. These requirements serve to make it sure that someone else can add that ability if necessary to run it somewhere else on a different infrastructure or to run multiple copies of it or to change it in some way. These are the minimum requirements that enable such a thing, but it's not necessary to meet that up front. So must all the dependencies for a service be open source too? Well, no, this is not required. A service can be open source without all of its infrastructure, its dependency, the hardware that it runs on or the APIs that it uses or other services that it interacts with to be open source as well. But these requirements again enable a public contributor to abstract out things that are proprietary, to change them, to replace them with open source alternatives and that is the goal here. So by meeting this minimum bar, you enable others to take this aspect further. And so must there be community for the service? And this is amazing when a community forms around a project, but the reality is most of our open source projects do not have a community around them and many of my projects, your projects, have no more than a single contributor. So it is great when that happens and we want to enable that for a service, but it's not necessary in order to apply open source minimum requirements. And so here are two links that go into the requirements and of course opening a pull request to these to change things, to have discussion about, wait a second, here's an aspect that's not covered or here's something that makes this not be that self-evident minimum set of requirements that we should meet in order to have open source applied to our services. And I would encourage anyone who wants to participate, to participate in all sorts of ways on this. But I'm hoping and Michele's gonna talk about services that are applying this or how different services meet these requirements or don't meet them where the gaps are and specific applications of this. So how much time do we have? Six minutes. So we'll have questions now and then questions after Michele talks about more of the concrete stuff. Yep, that's a very good question and one that we should have discussion around. The place I would start is with the current licenses. The choice of license for the code already makes a prescriptive choice for the service about the libraries that are included. The question is, I'm sorry for not repeating it, that what if we include libraries in the service? Where do we draw the line between what we require to be open source and what we don't? And so I think we start with the licenses first. That is the first requirement. We choose a license that reflects the behavior that the service would like on whether it's it, everything that is launched with the service, for example, with the GPL is required also to be open source or not. But the second thing is that things that are outside of this, I believe are things that are deploying the service, things that are monitoring the service, things that are obviously outside of the service itself. Those things should be available to contributors so that they can contribute. But the line, I believe, the minimum requirements don't require that those things are open source upfront. If we can replace them with open source alternatives, I think we have a real win there. And over time, we build more open source services. But to meet these minimum requirements, I don't think we have to be that contagious with everything that the service touches. Next question? Yeah? Right. Right, yeah. So the question is, are we required to take contributions that we don't like from a business perspective or for any other reason into the service itself? And the answer is no, the same principle applies as your other open source projects. These minimum requirements serve to enable a contributor who you don't agree with to fork your service. It's difficult, like we said, to make a second copy of the service or to duplicate that. But these enable that behavior just like forking an open source project. So that same open source dynamic applies here. We either use whatever mechanisms to come to an agreement, or we have branches or some other mechanism to involve other people in the project and the service itself, or it enables forking so that we can have that drastic escape hatch for people who literally don't agree and they can kind of do an evolutionary move of survival of the fittest and see who wins, right? Next question, yep. So we've spoken about this in previous dev cons. I mean, it was a remote DevCon 2021, I think it was. I would love to see a world where we enable contributors to contribute to a service without having to operate it themselves where they see their change running against their data and can do this. I believe that would be an amazing place to do. And I'm very excited by that kind of outcome. But that is far beyond these minimum requirements. So I did, I shared this to kind of share a bit of the why. Why am I concerned about services with regards to open source? Why are they currently seem to be diverging and not reconciled? And I believe we have a lot of cool things we can do with this. And we need to go far beyond these minimum requirements, but I think they just get us started and enable the rest to be discovered. Cool, so I'm gonna hand over to Michael. So, welcome to the second part. Now Steph, basically the motivational management make it happen part of it. I'm going to be the engineering complement of actually making those things happen and how to make those things happen. I said like, I think it's actually, I mean the reasoning behind why we would want those things is very sound, it's the same reasoning basically behind open source software by itself. But it's not as evident for an engineering type of person of how this now actually can be implemented. And so I think the discussion about minimum requirements kind of like might obscure that this is actually more of a journey than an end goal. A service can be partially open source. So it is an incremental happening and that's what engineers do, right? Like we don't mind too much to work on the same project for a couple of years and I mean we know that it's not ideal that's why we continue to improve it and the same goes for the open sourcing of something like this. And then we're going to talk about the engineering side but there's another aspect that needs to be taken account and that's the social aspect. So if we are talking about incremental improvements for an engineer that's kind of like changing code, changing deployments, changing whatever. But there are also attitudes involved of people, there are fears of people involved and they might actually need changing as well to get to this place of open source services and that's not included in the talk. So that's maybe another talk for another DEF CONF to do. So we thought about like how would you actually strategically go about this whole thing? Getting this marching order of open source your service. And we thought that it would be interesting for taking this general idea and decomposing it into something that's actually actionable. So we tried to come up with this scorecard of like how open source is your service. Kind of like this card game, right? Like you can say like my service is more open source than yours. And it should allow us to actually identify gaps like the ones where we would lose, like which pieces are not where they should be. And actually applying this scorecard to different services might allow us to pick ideas from other projects because they're all open source, right? Like so if somebody solves one of those aspects in a better way then it actually might be something that we should adopt in one way or the other. So I will put down the scope again. So this is about services but a lot of this is actually also applicable to other open source projects. But just here it's now limited to services where software is run for users. Now those users might actually be not just these strangers on the internet. If you are a public service, yes that's true but if you are in a company environment you might have those internal customers that are really angry if your service is down and that might be something where you would invite contributions as well to get stuff fixed. So if you could pick their brains or if they could file a merge request to fix the issues that they see you would already gain quite a bit. So thinking about community and what this might mean for whatever project you have might make sense. And this is a list of stuff. So this is like me at night brainstorming after we had the talk settled. Coming out of the questions and answers that in the previous talk. So it was about assets like the code. Everything that is in the Git repository basically. The workflow that people can actually contribute in an open way. How do you deploy this service and that's like the secret source of most services like how Amazon deploys Postgres into their infrastructure? I don't know, nobody knows I suppose but would be kind of cool. And it would be required to kind of hack on RDS. But it's also related to the communication style. Like is this actually a transparent process? Like how hard is it actually to talk to people? Is there documentation available? Do they have procedures for running it if something fails? What do they do? I mean if you want to run the service that's something you would also need. And if you have to develop this from scratch that's basically not possible to do. Are issues tracked in a transparent way or is it like this secret stuff where you see issues and then 95% of the comments are private and you don't even see them. So you don't see that there's stuff happening on them. Or you don't see those issues at all. And then can you actually see people operating the service? Is this something where you can observe and learn how it's done so that you can improve on it? But yeah, so I could go into the details but maybe that's not the best. So we just directly skip to some examples. So we are going to take two services and then try to figure out like how they are doing. So luckily it's not Santa doing the evaluation. So we're going to look at two projects. One is the one that Veronica talked about in the previous talk, which is the continuous integration as a service project for kernel developers, which is the CKI project. It's an internal project. It's aimed at internal developers. That's the business reason for it but there's an extended business reason that it tries to prevent bugs from getting into the upstream kernel first because that is actually going, I mean we are a redhead team. We want to prevent those bugs to actually hit the redhead kernel. And we would like to get stuff fixed before it actually happens. And the other project we are going to look at is GitLab itself. So GitLab is like this other Git forge. I don't know whether people have experienced with it but it's not GitHub. They have a different business model. They are selling you local instances that you can install as a community edition. It's an open core business but they also have a managed instance which is managed in a really interesting way in a very transparent way and they consider themselves as the open company. And the bottom line contains how we score this, right? Like this is now beyond the, we nowadays use emojis for scoring, right? Like we don't do plus one and minus one. So you use emojis for this one. So I don't just ask, just look at Veronica all the time and I talk about CKI whether she agrees or not. But so CKI is regarding open assets, pretty okay. So they have all their source code in GitLab.com but it took them 18 months to get there. So this was like mixed models, stuff in the open, stuff internal and especially moving stuff from the internal space and consolidating it into the public space is harder than it sounds most of the times because people tend to kind of like get messy if nobody is looking, right? Like you mix internal information into it makes it really hard to actually open it up. But so this happened. Dependencies are open source as well but then we get test on well. So well is private. So this is something that external people have problems maybe reproducing bugs for example on well. And they are, it would be kind of nice to have external tests available but then this doesn't really apply for CKI because there are no penetration tests or something running against it. But for other services it might be applicable. So okay, that's a check mark. This is hosted on GitLab.com and GitLab.com is actually pretty good in enabling a workflow for internal and external contributors. So it's the same workflow for everybody obviously because it's a small project. There's no documentation available how to do this properly but it's merge requests so it's not hard to basically fork it and open a pull request. And there are bots coming into it and they can talk to them and if you say please they will be in color or something but there's something to trigger for example integration tests that is mostly self-evident hopefully. Most of those features are mitigated by permissions and I think it's very similar to what people would do on GitHub. So you try to kind of like limit the exposure of your internal infrastructure but still try to make it possible for people to post it. A pretty important aspect is actually that people will feel welcome so you need to be nice to them but that also means that you're actually going to look at their contributions if those contributions come in. And for CKI that's pretty okay. Just looking at the statistics most merge requests are merged within a couple of hours but this is the same for external or internal ones. So let's go to some uglier aspects of the whole thing. So how do you deploy kernel testing as a service externally? Yeah you just don't. So there's I think one lap where people do this but it's because it was never required really hard to do. It's really annoying to set up. I don't think most team members would be able to do it. It's this thing that exists. It's GitObsified but it's still not, it was never necessary. It's a huge barrier to entry to actually get this thing running. There's no way to run it on your laptop while there might not actually be a good reason that this is that hard. Like you can run a GitLab instance on your laptop we will see it. And yet the infrastructure repository is also not available. And why? Because it mixes secrets and internal information. It's kind of like this mess that somebody would need to detangle and nobody can be bothered. It's just like thankless work because you will just break something. We have good documentation not how to set up the service but actually how to operate the service because that's what we are doing. There's some company internal guidelines that can't be opened up but other than that everything is visible. And also the operating procedures are actually accessible. It's possible to do this even if there's internal stuff in there you can actually tease those things apart as something that is done. But as a company internal project we don't have a code of conduct. Now if you talk about communicating it becomes interesting to discuss like who you want to communicate with. So if you're talking about communication with upstream like this is one of the goals of the CKI project and it's actually pretty hard to do it as a mailing list and that's basically it. You can't look at the source as it's made or the source address it's made. It's very transparent process. But if you're talking about internal kernel developers which is a really important audience also for contributions we have a channel you can jump in the CKI project pretty friendly folks. So that's a pretty okay experience but then there are easy gains like having a meeting where people can just jump in and ask questions like in-person video meetings. We are a remote team so. And then an interesting aspect is that next to official issues and the team channel a lot of discussions happens in those documents that people just create. I mean Google document, the markdown and something. And that's also something that can be actually solved and it would lower the barrier of entry but it's not something that's done properly. All the issue tracking is on GitLab so that's fine. Even though it's an internal team and most external contributors will never look at it but it still shows how it works. And then yeah we just skip it because it's the very entrance parameter. I'm not going over the list but how CKI is run is not visible on the outside. So this is a huge gap that would prevent people from actually running it because they can't see how it's done. They can't observe.  So let's look at something else which is the GitLab project. So they consider themselves as the open source company or the open company. They have everything on GitLab itself that's their main product. They are their first user. They are the heaviest user most likely. Everything that they need to run is open source as well because you can just spin it up on your laptop. Whether there's anything missing from the public view you can't figure out from the public view. So we don't know whether there's anything secret for testing for example but let's say open assets it's there. We have people contributing from Reddit to GitLab. So it's this contributor workflow like Reddit people are annoyed. It doesn't work and they come in and fix it and Lukas is actually kernel developer basically contributing to Ruby code working on those issues that annoy us as the users that they don't, like GitLab doesn't care enough but we care and we have a developer basically fixing those issues and they accept them. They have a really good workflow. They have coaches to move those things along. So they spend a huge effort and it works. It's something that is open for contribution in the best. You can just go through their documentation on how they do deployment. You can go through various possibilities of how they do deployment. There's some things that are missing but it's an engineer's paradise if you want to go in and figure out how they do it. You can just spend weeks and weeks reading code and documentation. And so it's just, yeah, it's available and there's nothing happening. Like there's internal information in those operating procedures for example and they just accept it. It's something that they accept as the price for the openness. They have something interesting from the engineering, from the management perspective. They have their management handbook online. So you can look at how they actually want people to work and it's a very interesting one. It tells how people should communicate that they should be open, that it should happen in a public venue. And this shows there might be internal, internal aspects to it but it's not something that seems to be missing. And yeah, obviously issues are also tricked. And you can read about their strategy. So if you're wondering like where is GitLab going as a customer? Is this moving in the direction you care about? You can actually look at those documents. So there's no management secret source as well. Right, this is not something that you would normally require from an open source service but it's very interesting for a customer to know where the company's going and whether this actually matches your use case. And you can look at them, why they run it, especially if it fails, it's beautiful.  I mean, these are like people that don't freak out. And you can watch how they triage issues in real time. And it's highly interesting for learning if you want to do it yourself, for example. So they are doing some really, really beautiful things. And some of those things, there's mostly behind some of those points. So sometimes even they have a limit where they say like, okay, we are not going to share this, this is not something. But so let's recap that because I'm an engineer. I'm trying to run a service as an open source service. And having this scorecard actually was quite eye-opening, pointing it at one of our services to find out where gaps are and what kind of things we would need to fix to actually move it to minimal requirements or to move it further. And it shows that it's more of a journey than really like getting this bar and then basically being done with it. It's never done. And I think stuff has this tendency to regress in places that people keep stuff in terminal. Don't share certain information. It's actually not that, it's never finished. We heard this sentence before about Linux and running an open source service is also something that needs to be reinforced once in a while. And would be interesting to continue this because just having a scorecard is one part, but most likely you could actually make something like a playbook out of it where you could, if somebody comes and says like, I would want to open my service, actually tell them different steps that they would need to follow to get somewhere. So yeah, the earlier you start, the better it is. So that's basically the thing. And so if somebody has a service that they want to evaluate in the following couple of minutes, I have empty slides with all those points so if somebody is up for it, we can evaluate the openness of the service within a couple of minutes. Otherwise, that's it. I don't dare to admit it, but this was like me at night coming up with slides. But I think it is quite, yeah, you could actually, but then it would need to do it properly. This was like a wrong person. Let's let people review it, scorecard. But then Steph didn't really look funny while I presented it, so most likely it's not too bad. But I think it would need to be done properly to be actually something to move into policy. Oh yeah, and the question was like, is this public? This is basically what there is. So there's not more than this.


Everybody forced here ripping the sports card almanac multi-sport personal box edition of volume 4 One box for Alec V which is box 31 31 for Alec. Thank you and good luck. Oh, do we have to ship Skittles with it? I mean that was the hint right? Everybody's ready on their keyboards. No Locked in love it. Oh That's really nice. This is a 2020 tops finest moments autograph Vladimir Guerrero, Jr. PSA 10 I Freakin love that insert this one is non numbered. I believe us on the front. Nope not numbered Vladdie, Jr. Box number 31 there you go Alec Nice card there for 2020 finest. So a second-year Vlad PSA Jim minton And that's gonna do it. We'll get it right out to you


Hi everybody. Thanks for coming to this session and thanks to Frank, even though he's talking for sponsoring NDF. It was greatly appreciated, Frank. We'll look forward to your party afterwards. Not least of all me, who's been sweating it all day about this presentation. I'm going to kick straight into it, but a word of caution, there's probably too much content, which is a problem that we face in the world at large. Okay, clearly I'm not an editor because there's a really disgusting full stop at the end of museums and digital publishing, but never mind that either. I am a publisher.  Because, oh, and I also run obviously Tupapa's multi-media publishing team and I think that's a name that very clearly locates us in the second decade of the 21st century. I can't remember who it was who said of participatory culture, we are all media producers now, and that's true. But there are three of them by trade in my team and a bunch of editors too. This also means that I run Tupapa Press, which is New Zealand's unique museum publishing imprint, and that I have straddled many a raft of public good commercial, institutional audience focused, and open access copyright protective for some time now. And these are of course all relevant to us at NDF and in life in general. So in this role there's a few questions that non museum people always ask me and just for amusement's sake I'm going to show you them too, particularly because we've never really appeared at NDF either. Do you only sell things through to Tupapa Store? No. Do you only publish to Tupapa authors? No. Do your books have to make money? Yes and no. And then there's this rogue one, this fourth question that I got asked one time. And that scared the bejesus out of me. Not just because of who asked it, although I will reveal that it was a prominent minister with a direct responsibility for Tupapa.  And at a time when it's no secret to anybody they are having to quite literally explain what it is that they do and to justify their value or demonstrate at least their value to the wider community. Now and that includes things like Random House putting up you know sort of quite instructive and corny videos about what happens at Random House with the kind of a do-do-do-do-do-do-do-do soundtrack in the background. Anyway, now we probably all think that this whole nobody gets it thing is because of that. And I very nearly didn't include that quote because people at NDF have been seeing it for years and years now.  Publishing is not a job, it's a button. And we probably all think that that's the whole reason and I'll recite the litany of disruptions later. But it probably actually has rather a lot more to do with this. This is a conversation that Max Porter, Eleanor Catton's publisher, had with Kim Hill when he was here in New Zealand a little while ago. No, no, Kim he said. We wear dark cloaks and we move in gloomy corridors.  The editor should be invisible, the publisher should be invisible. To the extent that in New Zealand institutional publishing, the fact that we are more often than not the content creators ourselves is often obscured. Now Max was joking, of course he was joking, but like all good jokes it was about quite a true thing. So here's what we actually do, just a few things. You can browse through them at your leisure. But note that none of them is related exclusively to print culture. And note also, and it may not be eminently obvious to you, that it's a very rare and talented self-published author who happens to be able to do all of them. Many people can, but on mass it's quite a rare set of skills. Now just for the record, I'm not proposing for a second that every last one of these functions could not in theory be disrupted or automated or sourced elsewhere or managed in some kind of other hitherto unexplained business model. Although I do share the opinion of the recent New Yorker writer, sorry I haven't had time to Google the article, although I gobbled it up, that disruption is becoming a slightly absurd and over-extracted concept. And I was joking with me a ridge over, didn't it the other night, that you could disrupt the olive oil or somebody could disrupt it. It really has become not quite what it was all about. But because it's NDF, and because we're feeling a little bit bold this year, thank you very much, Andy. And because later on I might even challenge us all to be a bit bold enough to give up some of our favourite firm positions, myself included. I will even go so far to say that Clay Scherke was totally right. And the Publishers Association, of which I am a council member, isn't going to like it if anyone tweets that. It's just that he was only partially right. And it's really easy to be right when you only tell half of the story. Because the value that publishers add to cultural outputs and products, including but not limited to books, was never, ever, ever, ever, ever limited to starting the rusty old clanky old keys to the machine down in the basement. And it wasn't even limited to what Brewster called on Tuesday, maintaining the economy of scarcity. That's a later, later byproduct, I think, of our current environment. So in his excellent talk on Monday night, Monday night's panel at the National Library, Tom Renne talked about how weird it is to be called that IT guy after years of effectively working in books. And I want to say that it's equally weird to be called some of the following. When your workflow has been, except for the final spasm, digital for my entire career, when I am obsessively author and, sorry, user focused. And when some of the practitioners who've made these comments are people that I passionately agree with. Dinosaur, just about everyone, but my husband included. It's bizarre to be called a dinosaur when you don't particularly feel like a dinosaur. Many evil soldier, gatekeeper, megafauna, that's somebody I admire very much and have had many a good conversation with Michael Edson and in conversation with me in 2012 and his perfectly pleasant office in the Smithsonian, Michael said, publishes, they just throw things over the wall of the castle and they hope that they'll land on someone. And I was forced to put him right about that because it's not entirely true at all.   And many of you will have caught it web stock back in whatever it was 2012. I mean, here's a nice charming image from the movie The Last Days of Disco, a personal favorite of mine, in which Chloe Savanie and Kate Beckinsale boogie at Studio 54 by night, no doubt, inhaling the contents of the cocaine trolley. But by day by day, they discover and publish amazing manuscripts and forge awesome careers as you know, publishes. So I'll tell you what, it's enough to give you what Serena Chen called the other day, another life crisis. Remember that? And her very stimulating talk about her comparatively short life. So suffice to say that throwing things over the wall and hoping they hit people is not the kind of operation that we're running here. But I hope to show you a bit about that in a second. But yes, the change is huge, the change is huge. And then there's this, the Peacont local variant. And I started thinking about moas and chickens and which ones die and which ones carry on and it wasn't particularly flattering to be compared to either a moa or a chicken. And so I just abandoned that. But I'm suffice to say that the tide is sucking out on New Zealand international owned publishing right now. And I have some very bold and tangentious and tendentious sorry and kind of exciting thoughts on what this all means for museums and cultural institutions and independence and funding models and the digital and everyone who's a content person and just plain making cool shit that I will share with you of time permits. And if it doesn't ask me later about the farmers market and paste up and punk. I'm not mounting a defence here of traditional publishing models. And I'll be bored to sob if that's what you think's going on. I'm also not charting the state of a beleaguered nation. And I'm certainly not going to enter into a discussion about the future of publishing, because Tom Rene did a pretty good job of it on Monday night. But I can only endorse this timely quotation of Leah Price at that time and it's worth recycling that today. All I'm doing is calling out a corny old cliche when I see it. And I'm published with hate cliches. And we all know how it goes. And here I'm quoting Lincoln, Michelle of BuzzFeed. We all know how it goes. We don't see the paradigm shifting sea change. We're not creating proactive new business models in the wake of this disruptive revolution. Anyone who reads print is a luddite propping up a dying industry. If they don't get on board soon, they're doomed.  And here's just a few of them. And are we not kind of at peak, peak ridiculousness, at least in this regard alone, purely in that regard? Can someone make a good picture of the death of publishing, please? If we're talking cliches, this is a good one. It's by Mark Twain, who's a writer. The report of my death was an exaggeration. And I think that's kind of where we are, because technological development like success, we've all seen the picture. Almost never travels in a straight line, but in a wiggly line. And in any case, it only looks like a straight line when we look backwards at it. Because for the indefinite future, we are very definitely straddling print and digital models. And because, as Lincoln, Michelle put it, dinosaurs don't always die, enter again the chicken. But anyway, what does any of all this have to do with NDF? With cultural institutions, with the digital and with museums? I will give you a clue. It has to do with the functional sense of publisher that I used earlier, the idea that you perform a bunch of functions, rather than the vertically integrated industry sense of publishers controlling the technology. And it has to do with the total cultural importance of literary culture, red culture, textual culture, and cultural value. And with what has always been motivated in museums, galleries, archives and libraries, by forces other than strict commerce. You can call it access or philanthropy or the public good, but you know what I'm driving at. So I will now turn to some specifics related to our publishing program, because I realized the other day when somebody didn't give a show and tell that it was utterly depressing to me, and I really wanted a show and tell. So I'm going to try and cram this in real fast. This is some of the stuff that to purpose publishing program has been tasked with on a policy strategy or otherwise KPI-ish level over the past 10 years, but they could apply to any institution. It's the last one I'm the most interested in today. Generate valuable and reusable content data and IP. And thank you for Victoria Leachman for helping me with my emphasis, because I could go deep on any of these ones. So what have we got? In a given year, we sell about 50,000 and sometimes give away about 50,000 individual units in print. I'll get to the digital in a second. That's off the base of about 12 new products of which there are additional print, sorry, digital products, which I'll get to in a second, reprints. It does generate revenue, generates revenue, and this isn't a secret, of between $600,000 and $1 million a year. Those aren't net revenues, but they are the revenues that Tapa receives before the costs are taken off. And they go on to win lots of awards, which makes the museum look good. And they do this. They make people say good stuff about your institution. And sometimes they very explicitly correct the impression of your institution if it's causing you trouble. What else am I going to say? And then really lovely things happen like this, which I cannot resist including.  Literary cat fight ensues. Not really. Museums can be the source of stories of vast national significance. And the act of professionally publishing them can get them places that they wouldn't otherwise grow. This is about icons now. I talked about the use of content in IP. This is an example from a classic print publication, icons now. Usually when I meet people from museums, all they want to know is how can I make a collections book. And I tell them please don't. Please make a book that's about something other than your collections. Because by and large they don't perform well. But icons is a very, very nice example of a well-performing collections book. So it was produced in 2002. And some of the places that it has ended up are as follows. There it is in the content from icons now, including the photography and all the indexing information that ended up in collections online. It resulted in derivative print products for very, very different audiences. So there it is in treasures, which was from the tourist market. There it is appearing as five little books that we call little icons that were aimed at a more family-friendly audience. We have a product in development, slow, slow, slow development, which is essentially a, I guess, a, I'm going to say app, but we're agnostic about that right now, for exploring collection items using the content from those books as well. It ended up in the Google Art Project. The content from Icons on a Tower ended up in the Google Art Project. Went to Papa, joined that. And it ended up forming the scripts for a TV series with TVNZ called Tales from Topapa. So the content from Icons formed the scripts for Tales of Topapa that was then recorded, videoed, appeared on TVNZ back when there was a Channel Six. And then the content from that was packaged into a DVD and a print publication that was aimed at small children and their parents. And that has gone on to do really, really well. So I feel as though sometimes the content that we create has at its front end a financial model that shows the entire costs being worn by the book. But that at the other end it's like grey water of London that's gone through everybody's body. And there's washed every, you know the London water story. Anyway, there you go. So that's a nice print example of the same thing. And I don't even know where the hell it's gone. Like what I want to do is a kind of a little track of a couple of pieces of content and really truly draw a map of the really many insane places that it's gone. But time didn't permit. So instead I'll tell you about some other stuff that we do. We are delighted that when Topapa restructured recently, we were able to be merged into a group that included our rights officer, our digital collections team, our photography team, and Topapa's records people. Am I forgetting anyone, Phil? Not really. Knowledge and content. Because at last we were able to focus on maximal reuse of Topapa's knowledge, content, and assets in the publishing sense. And that was really exciting. And as part of that we formed this multimedia publishing team. And its flagship product was Arts Topapa online. Now Arts Topapa was a response to the new approach to hanging art at Topapa. I'm called Ngatoi Arts Topapa. And at the very, very beginning we determined that we would not produce print catalogs for that exhibition. Instead we determined that we would create an online property that was as iterative and modular and intended to grow and reflective of the multiple voices who are interested in art at Topapa as the exhibition itself. We were forced to make it as a mini site due to the functionality that we wanted and the limitations at the time of Topapa's CMS. But it has been really successful. One of the main things that I think your publishing people can bring you in a museum or that publishers can bring in a museum context or people with those skills can bring in a museum context is maintenance of content across time. So prior to that Topapa had been, parts of Topapa had been prone to the exhibition mini site which is made and then abandoned, made and then abandoned, made and then abandoned. And they just build up like so many, you know, what tumbleweeds, I don't know, usual metaphor. But there are no more better, you know, they're no more pure or good than a unwanted print catalogue gathering dust in the hallway, you know, down beside your shop. So we were very keen to get rid of that model. And so we did. So what can I tell you about Arts Topapa online? It is, lost my notes, yeah. So it features online art exhibitions, digital media, events and a free quarterly online magazine called Off the Wall. This is the On the Wall component which reflects all the components of every single exhibition and every single refresh that goes up at Topapa. And it is, the way that it's developed is that all the content lives in Topapa's collections management system, KEMU. So you can always relate the exhibition to the content that was in it. So we do drive it out of EMU as a CMS. The installation views, Off the Wall. So Off the Wall is the online quarterly magazine and it combines our arts newsletter with the abilities that our team can bring to magazine publishing. So online, multimedia magazine publishing. So interviews with artists in video, art multimedia, curator talks, print interviews, studio visits by prominent writers and all the rest of it. Since it launched, we have released six, seven coming up this December for eight issues of Off the Wall including those accompanying Natoy seasonal hangs. We have a growing subscriber database of around about 5,000 users. The site has been well-reviewed in popular media which is a lovely thing to see and it won a prominent web design award at the 2014 Museums Australia Publication Design Awards which was very nice. There have been about 15,000 individual visits and we noticed that they profoundly coincide with links from other sites or that they coincide with really significant marketing from TAPAPA which we can't always throw a resource at obviously but the Warhol exhibition did really well for us in that regard. Right now there are about 23 clips of artists and curator interviews produced by our talented multimedia team and these are growing. Then this other cool thing happened and I certainly don't intend to take full credit for this but this is TAPAPA's channel. So working really closely with Ruth Hendry and Curtin Criminaka and our software development team, my colleague Jean-Marie produced and developed at almost no cost at all. We're certainly talking where are you, Jean-Marie? Are you in here somewhere? No. Yes, less than $500? $150. The TAPAPA channel and the TAPAPA channel perfectly embodies the idea of the reuse of our media assets which up till this point tended to be linked to the exhibitions that had birthed them. So this is the TAPAPA channel. It released in late 1314 with 84 videos, 52 audio clips, nine galleries and before marketing had attracted 1500 visits. It has very very strong engagement statistics so while the numbers are low we have as I say yet to advertise it or promote it really people are enjoying it and using it and this is the kind of stuff you can see and we're excited to say that we are now able to begin to digitise deliberately for it. We have a very modest budget for digitising for it but that's one of the things that I think can come from closer relationships between strictly speaking web people and strictly speaking publishing or media people. What else can I say about this? Some of the cool stuff that you can see. Slide shows. This was another nice flip-flop and this, I meant to say about Arts to Papa so this crazy thing happened right? So obviously it was all released completely free online all the content is freely available and they're released under Creative Commons non-commercial licenses but no sooner were they out there than we realised and they were also produced as floor brochures for in the exhibition some of them the ones that relate to on-the-floor content. We found that booksellers were selling them they were retailing them and so you might know some of you might know Helen and Roger Parsons or their art subscribe their sort of database that they send out catalogs to and we found all of our brochures on their catalog and they were selling them for like four bucks a pop or two bucks pop or something like that and we had to it was a brilliant ironic moment we had to bring them up and say that you can't be doing that we don't want you to sell our stuff these have been you know the artists have agreed to be included for non-commercial reasons and this whole thing is pretty publicly available would you just give us a link and a shout out so it was a very nice inversion of our traditional relationship with Helen and Roger which were something like sell, sell, sell um cool what else can I say this was a really cool flip-flop and obviously it builds once again on credit where credit is due on years of work by to Papa's curators and digital collections team on building information around the berry archive so you probably know who the berries are I'm not going to bang on about it soldier portraits found in Wellington but our team working again closely with the software development team developed an interactive interface so that members of the public could come and try and identify berry boys and they did this in really really good numbers and there were some really significant identifications found so many so that we were able to produce a book out of it and the book occasioned more happiness and more communications from people in in the cargo the real lever for this was of course the role of production shed and the TV show Sunday which drove awareness of the berry boys and dramatized the search for their identities and that was really great for us am I running out of time shit okay we do some other stuff science lies we do them with the rest of the team audio audio obviously behind the scenes things okay a few conclusions I'm going to try and cut to the chase some of these come from my recent Winston Churchill Fellowship trip to America where I met some of these people I believe that they would know what they were doing but they don't know anything more than us that's one of my conclusions the other one of my conclusions goes a little something like this and I want to talk to all of us as colleagues rather than give you predictions and discussions about the state of the nation except that I'm going to say you should totally check out both the online catalog online scholarly catalog initiative and the museum publishing Blicky if you don't already so what do I got to say we need good content strategies and good content management systems and we need to work very tightly together to achieve them we need to collaborate and I feel very strongly about this I would like to see a tighter relationship as we're beginning to see in places like SF MoMA MoMA itself and the Art Institute of Chicago between research digital programming and editorial slash publishing we are living in ideologically heightened times my friends and people freak out about their jobs it's not just me at some of you as well and in these times hypocrisy and contradiction conditions of everything that we do this conference included I have seen publishers share between themselves portable hard drives groaning with pirated material I've seen zealous open access champions make an exception to lockdown just their scientific research article because somehow it's special I have seen passionate advocates of audience engagement and accessibility hit the print button on runs of 1000 copies of heavily funded exhibition catalogues that just happened to have their own names on the spine full of utterly inaccessible text with no discernible distribution strategy and a dark unsustainable dusty future ahead of at least 950 of them before the final indignity of the skip bin my point is not that we're a bunch of frauds or liars or imposters although some of us might feel sometimes like imposters my point is that we ourselves as a culture as institutions as professionals and as consumers are flip-flopping in-betweening and straddling rafts canoes if you will as they drift apart just like what happened to that poor girl at camp in episode one sees a one of girls remember when Shoshana told that guy about that horrible accident that happened to that girl who was standing on two canoes all I can say is that they say you can die doing that certainly it's not without risk or at the very least it's mighty uncomfortable so I have a couple of honestly only a couple of things to say babies in bathwater Alex's talk yesterday was salutary to us to us hell yeah copyright has to change nobody doesn't think that the entire publishers association thinks that but babies and bathwater there is a livelihood at stake when it comes to literature and authors are terrified they do want some degree of protection and I think that's clear printers absolutely not dead we've had our best year ever with products in which the value is bound up in the physical product that ain't going anywhere it's only getting more crazy punk planet I've said this before publicly so I'm just going to be brief about it we're frightened Selena Chen was right the punks are right get your hands dirty DIY teach yourself the skills that you need to do the job that you want to do don't be afraid get out there and make cool stuff and make it for other people cool aid oh yeah drink the cool aid but maybe don't drink at all and hang on I've got another one really briefly it's gone somewhere yeah don't be a dick so when I originally did this piece of work I was in America and it was 2012 and that whole Will Wheaton thing was quite fashionable as a meme you may recall it we'd be dicks when we are frightened let us not be dicks let us remember the lesson of collaboration but it's probably enough pronouncing any questions yes yes sir that's such a good question I want to talk about how not digitising can be a legitimate business model so we absolutely and emphatically want to digitise we have to be really aware of what we prioritise and Phil would agree with me about this there are things that we can digitise that have a far vast audience than our highly illustrated print publications there's every piece of evidence in the world that highly illustrated print publications work like dogs and the technology is not there to make them pretty and enjoyable I'm not talking about fancy apps like the Wasteland or the gemstones I'm talking about what happens to print books when you turn them into basically PDFs so neither the business model is there nor is the technology that is supported in the form of EPUB 3 as yet as an adopted standard there are illustrated books yeah like Blitzfah Blitzfah yeah yeah look it's absolutely part of our plans it's just that we're part of a big institution with a lot of digitisation priorities I believe that Auckland's work was the result of a rather substantial grant yeah all right hopefully that conversation can continue over break which we're just about to head to before we do that if we could all just quickly thank Claire for her work on sponsorship for this conference because sure that's contributed greatly to our experience


This should be obvious right now. I lost my voice. So if you want to see this talk with proper audio, leave the room from Contrax, because I've given this talk ever once. Otherwise, please be nice. And please be quiet. Keep for wrestling and everything else to a minimum, so that I don't have to use any more wrestling I need to. And like, this is going to be an adventure for both of us. So, Goga Ruko 20 times my first compliments. Jim Weirich gave the keynote and he covered a wide variety of topics, including physical chemistry and vision spectra, and this book. He had this book recommended to him by many of the nerds and he talked about a study group he set out to go through. He demonstrated that Contrax flew the first two chapters and then at the very end he pointed out that everything in the 90 minute talk he had given hadn't used assignment. And that talk by Jim Weirich is the inspiration for this talk. This book is the structure and interpretation of computer programs. It was the program in 101 book at MIT for a very long time. It was wonderful. So a little bit about me. I'm Audre Emery. I'd like to be able to be able to read any of the talks. My phone is down there, so you can't be able to be able to read any of these. I'd like to be able to read any of the talks. I'd like to be able to read any of the talks. I'd like to be able to read any of the future that I can master. I'm not an expert on this stuff in any means but I have been part of three political study groups. I'm part of Seattle R.B. And I'm interested in the esoteric and academic parts of programming. I'm truthfully seeing functional programming all over the place that I'm more of this talk. I was reading Twitter and Zahra put it out that all of the not-rivy talks at RubyConf this year are about functional programming and that might be a hint. So, functional programming. What's that? Here's the Wikipedia definition. Computer science functional programming is a programming paradigm. A style of building, structure and elements of computer programs that treats computer computation as the evolution of mathematical functions and avoids state and variable data. This is a comment from one of my co-workers who I respect a lot. The idea of mutable state is suspicious and easy to discover. So, these are two wire definitions from the talk I was mentioning. So, this talk, I'm going to focus on one aspect of functional programming and that is not using mutable data structures. So, there will be no assignment in any of the code in this talk. There will be not a single single input in Ruby. There's a lot of scheme in this talk and in the scheme you set bang. So, there will be no set bang and if modifying object seems important we'll clone and create a new one instead. Setting expectations there are uncontrolled slides lots of parentheses and no monies. Sorry, Terry. Why should I care? So, functional programming is powerful. First of all, it's easier to test. There's less setup, less stopping and walking and you always start from a new state. Previous tests can't pollute this state for the next test. Functional programming supports concurrency very well. I think it's a modified state it doesn't matter how many threads you have because you don't have to deal with lots of shared resources. Reduce systems, create new functional programming techniques. When your code it doesn't want a full state it's always safe to reuse it for other parts of the same program. Functional programs tend to be very brief and very concise. Some people think this is awesome. I am one of them. You already used it. Ruby lends itself very well to functional techniques and you're probably using these techniques without knowing it. If you do any job is correct to guarantee you're running some functional issues and doing it badly. So you might as well do it right. And learning it in Ruby is easy. It's easy with the latest techniques to Ruby and I find that I'm learning a new program a lot. So I'm going to do this talk half in Scheme, half in Ruby. I believe everyone should be able to program in languages of Polygon to make it easier. I've got my slides laid outside my slide. Ruby is on the right and in red because they all start with R. Scheme is on the left and in blue. First thing you need to know about Scheme is that unlike Ruby it uses pre-expectation. That means the operator is first. So instead of 5 plus 3 you have plus 5 3 and you're like well that's kind of lame except for the next line you see that you can do 1 times 2 times 3 with only a single times using this kind of technique. You're powerful. Group B is pretty obvious you know what happened to group things with parentheses. And you can call name function is not just about the operator it's the same way that everyone has a successor function for numbers. So you can define functions define function name in the argument so we're finding a function called square n and then after that is the party times n of n and then like we have a definite end in Ruby we use parentheses in Scheme 2 to denote could blocks grouped. So the class of parentheses is equal to the end and then again we call that with functioning of the argument in parentheses. Conditional Scheme has several conditionals and I'm going to use con for this talk it's like case in Ruby so this is the definition of absolute value if our argument is greater than 0 we return a argument and it's equal to 0 we return 0 and if it is less than 0 we return the opposite of it. This is another case for prefix notation it's awesome because I can do a unary notation exactly the same way we do a subtraction because the last time I gave this talk there's blue people's minds yes you can do this sooner or maybe you don't have to put something after the case if you do this it just evaluates each of the causes and the whens and it falls through to the first one that's truthy since everything is truthy or falsely under Ruby this works great. I use it all the time when I'm learning this from the university I'll have this to your arsenal if you take nothing also put in this talk so back to our conditionals this is a slightly modified version on the scheme side this is not the real schemer we'll write it. It's much more condensed I think it's pretty you might think it has too many parentheses but you'll get over it because people asked you also have an F in the scheme this is defining a predicate function boing predicate function is of course a function that returns temperature of false if the temperature is greater than 0.5 pound T in Ruby and scheme is true pound F in the scheme is false and you can see the Ruby on the other side these are exactly the same code laid out the same in two different languages so most functional languages heavily use lists in scheme we represent lists with a quote an open parentheses the elements of the list with no commas it always messes me up when I'm switching back and forth between languages and then a closed parentheses to close the list I'm going to represent lists in scheme by Ray's and Ruby they are not the same at all if you know scheme I'm sorry but this was the easiest way to make the parallels for our purposes of this talk so most functional languages make heavy use of firsts and rests car is first in most lists dialects if you want to know why ask Wikipedia I don't have the space and voice to explain that right now car is just first it's prefix notation again the function goes before the list cdr is rest in Ruby to get rest I have to do 1 dot dot negative 1 that's gross so I'm just going to assume that rest exists and when I was actually building these slides I re-opened array and added the rest method and set it equal to the equivalent of self 1 dot dot negative 1 and when you're doing things with lists I often have to know if your list is empty we have mta in Ruby we have null a in scheme I am using the Canadian pronunciation of the question mark there if you've not heard that before and knowing if your list is empty is really important for recursion so let's do the canonical recursion example that you see all the time factorial here's the standard recursive definition of factorial if our argument is 1 the factorial of 1 is 1 so we return that otherwise we return the number times the factorial of the number minus 1 scheme in Ruby side by side here's the other canonical of recursion example fibonacci if our number is 0 we return 0 if our number is 1 we return 1 otherwise we return the sum of the number minus the fibonacci of the number minus 1 and the fibonacci of the number minus 2 and the fib number so now I'm going to go into something slightly more complicated called tail call optimization so this is exponentiation and specifically this is taking the number b the base if you remember your 7th and 8th grade math and raising it to the nth power anything raised to the 0th power is 1 so that's our base case if n is equal to 0 we return 1 otherwise we multiply our base times b to the n minus 1th power so this has a small problem though is that the stack ends up looking like this it gets more and more because we're saving off these from doing 2 to the 4th we're saving off these 2 times 2 to the 3rd, 2 times 2 to the 2nd 2 times 2 to the 1st, 2 times 2 to the 0th and we can reduce this stack size with an idea called tail call optimization so what we're going to do is we're going to add a helper function I'm calling this xxt dash t and this has an accumulator so we now have b the base same as before c is the number of times we need to raise that to a power it's a counter which is why it's c and p is the partial product the multiplication we've done thus far and so what we're going to do is we're going to say that if we've done all the multiplications we intend to do we're going to return p otherwise we're going to take a recursive call to our helper of b we're going to subtract one from the counter and multiply b times our product thus far if you've used inject you've probably dealt with these accumulators as you go before and if our language supports tail call optimization this will help our stack you'll note that our original function is still there we're hiding the helper function with the same b and n and we're going to use one that's anything raised to the zero is one that's our base case as the initial partial product so when we run this in a language this tail call optimized this is what our stack ends up looking like we don't end up accumulating those two times that need to keep going so we don't have as much stack to unwind and it uses less space so this is a semi contrived example that I'm going to go into now this is my favorite thing to test a new functional language on and part of a study group was Seattle RB that we just finished on a book called Build Your Own Lisp in C and we were building a language that if you squinted really hard it might have been a lisp it's a really good book I recommend working through it but it's not going to teach you a lisp but one of the last assignments was write a functional program using this lisp-ish language so this was the one I chose it's a little more complicated than some of the stuff I've shown you which is why I like it and I think it's kind of cool and the problem is making change it comes from the structure and interpretation of computer programs that Pochai referenced earlier chapter one and the book phrases it this way how many different ways can you make change for a dollar given half dollars, quarters, dimes, nickels and pennies and this is too complicated to dive straight into so the first thing you do is you want to simplify that and I end up with some coins and this phrasing is way more simple and way more general and from this I get a basic function outline I'm going to define a function count change and it's going to have two arguments amount and coins I'm going to say that amount is the number of cents if you've done any work in programming using money you know that you almost always want to represent it as a integer number of pennies because dealing with floats when you can only have two digits of precision is a pain and I'm going to say that coins is the list of coin denominations I'm going to assume that I'm living in Fort Knox and I have an infinite number of any given denomination but I have a set of denominations I'm also going to assume that my denominations are in descending order by value so back to my phrasing before how many ways can you make some amount with some coins well that's still hard enough that I can't figure out what the first line of code to write is so I'm going to simplify again how many ways can you make one cent and using no coins this is the audience participation part of the talk how many ways can you make one cent using no coins so that makes it easy I'm going to have a case statement and if I have no coins I can't make change so let's try running it again one cent because our amount that first argument is an integer number of cents and my coins is a collection of denominations that's an empty list so you're awesome because I am limited to slides and I wanted to keep these in the realm of readable for humans I'm going to alias count change to cc just to make it easier to see from that one so rerun it to make sure that that worked awesome next problem how many ways can you make one cent using pennies like that if you feel like you're doing your third graders homework right now you should so we're going to add another case when the amount we're looking for is equal to the first element of our denominations list we can make it we can make change one way awesome run it still works slightly more tricky five cents using pennies how many ways yep looks like that so now things get a little more complicated I'm going to need to add a case for that so I'm going to walk you through what this line means in English if you've taken discrete mathematics or done any combinatorics this is a pretty standard way of doing it we're going to assume we're going to use one of the first coin and then we're going to try to count the number of ways that we can make change the remaining amount so amount minus coins first is saying we're going to use one penny we're going to end up with four coins and we're going to say we're going to figure out how many ways you can make four cents using the same coins so we run it five cents one penny one one way we're doing this good so far how many ways can you make five cents using nickels and pennies yep one nickel five pennies so let's try it see if our code works that's not right so something went wrong for most of you I'm guessing it's not obvious right now exactly what's going wrong and it wasn't to me so what I did is I substituted the args in for the variables in the code and let's look at it one case at a time although list five one is not empty the array five one is not empty so we're going to skip that case we have this case here we're trying to make five cents we have a nickel so we return one well that's not right because that misses the case where we don't use nickels at all so we need to add a recursive call here what we need to do we need to say okay it's great that you can use nickel but you should also try to make that same amount using everything but nickels which is coins.rest so let's see if this works that worked great even more complicated how many ways can you make ten cents using nickels and pennies three two nickels a nickel and five pennies and ten pennies let's see if we got all the gazes down that's not right again so again let's substitute in the arguments and figure out where we're going wrong well we skip the first case again we skip the second case now because ten does not equal five so there's something wrong in our recursive case our fallback case and again we're missing a case where we don't use nickels at all and so we need to add that case in we're going to add the number of ways to make our ten cents using everything but our first coin denomination to the number of ways to make ten cents using our first coin denomination when I was taking combinatorics a professor called this weirdo analysis you claim that the first element of your collection is the weirdo and you count all the ways to do something with the weirdo and all the ways to do something without the weirdo and you add them together so if that helps you remember this technique awesome I'm sure that I'm sure that Professor Levin would be very happy so we now run a rerun our code we get three just the right result so now I put my QA hat on from when I was doing QA and I asked awesome questions such as how many ways can you make seven cents using only nickels all the answer is zero and when you run the code you get this so that's not right also it's not good so what's going on substitute the args in again so I've grayed out everything that we skip and what we end up with is this case where we're going seven minus five is two and we're trying to make two cents using nickels and we just keep ending up in this case so the next time we go through we're trying to make negative three cents using nickels and then we're trying to make negative eight cents using nickels and eventually we run out of stack and that's bad so we think we're missing a case we're missing a base case we're missing an infinite recursion and that's this case if the amount we're trying to make is less than the first coin in our denominations array we should try to make that amount using whatever is left in the denominations array this is where I am absolutely 100% assuming that the coins in the coins array are sorted in descending order since I get to decide who calls this and how they call it I'm going to say that's a fair assumption to make if I'm really worried about it I can sort that array in a helper function before calling into this recursive code and if I do that it works so at this point we're ready to tackle the original problem how many different ways can you make change of a dollar given half dollars, quarters, dimes, nickels, and pennies the answer is 292 so here's the same code in the scheme it's exactly the same cases as the ruby we have a cond instead of a case we're using no question mark instead of empty, returning zero in that case we have a less than again with prefix notation car instead of first we have the case where our amount is equal to the first coin in our set we're doing one plus figuring out the number of ways to make the amount with the rest of the coins and so it's exactly the same code more parentheses but the logic that we just applied to ruby is to visualize directly to scheme and vice versa you can really tell when you're looking at some of the stuff that ruby was heavily influenced by lisps because scheme is a lisp left that part out, sorry so a little bit more on functions this is a function called member in ruby we call it include question mark but every other language I have ever used calls it member basically we're saying given a list L and something, some item N is N in the list L at first we check and see if we have an empty list L if we do then clearly N can't be in it so we return false remember pound F is false otherwise we take the car the first element of L and see if that's equal to the thing we're looking for well if it is then the thing we're looking for is clearly in the list so pound T for true otherwise we see if the thing we're looking for is in the rest of the list, the tail of the list so pretty straightforward here's the exact same thing in a smaller font because I want to show something very clever here this is me defining the predicate any which exists in ruby basically like this and I've grayed out the stuff that I didn't have to change the only thing I had to change was the stuff in bold and this is pointing this points out to me that all of these recursive functions these operations on list end up looking a lot the same so any all it does is it takes instead of a thing to look for it takes a function that's a predicate that returns true or false and it tells you if any of the members of that list are true for that predicate here's the full implementation again we check to see if our list is empty and return false if it is otherwise we see if our predicate is true for the first element or if our predicate is true for the first element was equal to the thing we're looking for and return true in that case and if neither of those cases passes we then go to the case where we try to find out if our predicate is true for the rest of the list so if I'm going to do this I'm going to use anonymous functions on the left you see how you define an anonymous function in scheme on the right you see how you define an anonymous function in ruby I look a lot alike don't I I'm using the lambda syntax not the stabby proc syntax but the proc.new syntax on purpose and this function all it does is squares the argument in ruby you have to do dot call with the argument in scheme you throw an extra set of parentheses around your lambda and put the argument at the end of the right before the closing per run so here's me calling any function in the first line a lambda that returns true if any of the elements are greater than 5 less than 5 that returns true and the second case it's turning true if any of the elements are equal to 5 and that's false and so at this point I'm running out of voice I'm running out of time but I intended this talk to be kind of a functional programming 101 in the end it's actually just the first half hour of functional programming 101 and I have to encourage you to learn more so have some resources this is the little schema this book is awesome Seattle R.B. is starting a study group tonight for this book I highly recommend that you start a study group for this book at your workplace with your friends and your local Ruby meetup it's easy it's short you can read it in a weekend but I and the book do not recommend that it has space in it for jelly stains and it is also written entirely questions on the left answers on the right a number of people who are not at all technical but not consider themselves programmers I've seen pick this book up and just follow along because it's not intimidating and it's really awesome I didn't bring my copy with me but you should go buy one Ryan has a copy of the Little M.Eller this book has two sequels the season schema and the reason schema there's also the Little Lisper and the Little M.Eller and they're all written in this style and they're all delightful this is destruction interpretation of computer programs it is also known as the wizard book in the way that computer scientists like to give their very heavy technical manuals very unintimidating names so I was part of a study group with Ryan Davis and Aaron Patterson about what three years ago now Ryan took us nine months to get through this book it only has five chapters that should tell you something it's a dense I also know that I became a significantly better programmer in Ruby and in any other language I've ever used by finishing this book if you're the kind of person who likes lectures they're open course board lectures from the late 80s to go along with this the sweaters are awesome it really are I really highly recommend it if you're more like me and you're an auditory learner there's a bunch of talks on Khan Freaks that kind of give you an introduction to functional programming functional programming in Ruby by Pat Shaughnessy at Go Ruko 2013 is great parenthetically speaking by Jim Wyrick at Go Go Ruko 2010 is the talk that I referenced sadly only the first 45 minutes were captured and put online and that's most of the physical chemistry and less of the nerding you should still watch though because physical chemistry is awesome functional principles for OO development by Jessica Care Ruby mid-west 2013 this talk is on turbo and I am intimidated and delighted by Jessica on a regular basis if you want someone who's a little more animated than me watch this talk also really really well done mathematically I hand waved a lot of the math and then why not Adventures in Functional Programming was a RubyConf keynote at RubyConf Denver and I was in the room and I've watched the talk twice because I could barely follow along and I had finished SICP at that point but Jim just did an amazing job you know little baby steps from this is a stabby proc to oh my god I don't understand what's going on anymore and you should totally watch it it's amazing talk photo credit for the pony thank you guys for being nice and I like dinosaurs I am giving out dinosaurs to folks who teach me something or ask interesting questions I think I've got about 60 left so you should come find me at some point I saw folks taking pictures these slides are already online on my website because I gave this talk at Mountain West RubyConf I will also post this version of the slides within the next hour Fagomizer.com you can see them I am on speaker 8 if you want to rate this presentation thank you guys very much I can probably take a couple questions because my voice is holding out


significant fines have really done very little to change the behavior of companies and their kind of monopoly power. And so my question to you is, is it clear from this sort of history that these big fines are these monetary penalties, even if they're in the hundreds of millions or billions of dollars, are really insufficient to stop these companies from engaging in the kind of conduct that harms competition and consumers and workers? And if so, what should we be thinking about and how does this inform how we should be developing new legislative enforcement mechanisms sort of in light of this history and the size of these platforms and what seems to be sort of no financial penalty large enough to actually make a difference? Yes, that's absolutely right, Mr. Chairman. I was disappointed to see that the focus of that result from the Cambridge Analytica investigation of Facebook was monetary. We really needed to see big changes to how Facebook was treating user data and I didn't think we saw enough of that. So I think that's something to keep in mind going forward. You're absolutely right that monetary damages will usually be insufficient with these platforms and we really need to be making changes to how they are operating the business and really changes to the structure of these markets as I think what interoperability can do. If I may, Mr. Chairman, I'd like to add something to Mr. Singer's point in response to the last question about non-discrimination. I think there is an additional harm to the harm that he mentioned about competition on the platform. Platforms that are gatekeepers can actually also use discrimination as a tool to protect their gatekeeper power. It's not just about competition on the platforms but competition against the platform. One of the very few ways that smaller companies might try to compete against a gatekeeper platform is to start out selling a product on the platform or providing a service through the platform and to expand or to disintermediate building a direct relationship with consumers so that they no longer rely on that platform. If the platform has the power to intervene and discriminate against that potential competitor so early on in the process, they can prevent anyone from being able to compete against them at that gatekeeper platform level as well. So I think that's another important harm we should keep in mind with a non-discrimination rule. Thank you. Thank you, Ms. Lemon. I see that my time has expired. I now recognize the gentleman from California, Mr. Issa for five minutes.


What's up everyone? It's your girl Kenzie here from Leighton Sports Cards and I am ripping a personal here or a couple of personal for Eric W We've got two twenty twenty one panini select football hobbies. All right. Good luck Eric. Thanks so much for all your support Let's even get you a good luck in all those prism Prison basketball such a hopton too. Hope you hit some big magic cars man and okay see Snag them up in a bunch of breaks very nice Big Palmer We've got blue on the club level Aaron Jones. That's gonna be 22 of 49 And we've got Ravens to 50 on the white signatures Jamal Lewis The beautiful color match there at the white jersey and a Jonathan Taylor Jacob Harris Peterson. We've got to 25 on the tie-dye patch Thurman Thomas Bill's all two colors stuck a little red on the top corner there player worn use material on that one Silver Ricky concourse Bateman Kenan Allen Kylan Granson, Kaderis Tony rookie lamb Jack Phenoms. We've got Des Fitzpatrick silver field level Titans and Bobby Wagner Chubba-hubba Mowry we've got red Jacob Harris concourse for the Rams that is 48 of 99 Silver jeal and camp Texans and Shannon shark Justin Jefferson AJ Brown.  Um Mike M is up next and then you're after him Davis Mills rookie base. Calvin Cook Redemption and AJJ Wilds who your redemption is good luck rookie signatures memorabilia prism. So an RPA here card 37 of Chewbacca little chubba-hubba Nice Kaderis Tony rookie selections Justin field rookie Got silver Quinn and Williams and Amon Ra Zalas Davis. We got tricolor Saquon Barclay on the premier level 195 of 199 Silver Kenny Gallade club level and Russell Wilson. Now sure Zeke we've got sensations Aaron Jones Silver rookie of Anthony Schwartz concourse and Amon Ross St. Brown rookie On the field level. Yeah sure thing. Good luck on your prism football Tony of Gibson chubba-hubber. We've got tricolor Jevon Holland on the club level for the Dolphins 42 of 149 Silver field level Chase Claypool. Jayman Davis rookie Aja Laurie Devontae Smith on the rookie base. We've got silver sensations Tom Brady It's a beautiful looking card Jared golf silver concourse and a Tralance premier level rookie base Last pack of box one Tanon Hill Richie Grant. We've got a Tory Holtz on the snapshots for the ramps Club level silver Jarvis Landry and a Trey Nixon solid first box there Lux to Genio Andres is currently live over on the Lane gaming channel. You want to check him out? I did drop the link in the chat in book rookie We've got blue of Tyson Williams for the Ravens 168 or 199 on the concourse Silver club level Tom Brady Nice Brady's cards coming to you Desmond's Patrick Stripping some TCG's doing personals over there on the late in gaming from the new shop Sensations TJ Y got Charles Woodson silver and a Greg Newsom the second club level From Andre Stevenson Grankowski. We've got phenom phenomenon silver of Jamar Chase Daniel Jones silver concourse and a um, Elijah Vera Tucker These are a thousand dollars box 9 99 99 Try and shrink uh Jamar Chase on the concourse rookie We've got D hop To 199 a Kenneth Gainwell silver RPA equals Kenneth Gainwell Zach Wilson rookie Premier level If they'll be reduction like they were the year before I'm not sure lamb jack killin mom We've got red a mere smith marcette on the red mojo 260 49 club level Nice Trevor Lawrence on the club level silver rookie You go Eric nice teal on Mahomes Still looking for another auto waddle rookie Allen we've got white ed read premier level for the Ravens 29 of 35 Ed Reed And we've got to 99 silver rookie auto anthony Schwartz for the Browns Pulled a few Schwartz today already Schwartz And a givante Williams premier level rookie base I hope they're alive like they were this past year victor Kellan mon rookie we've got waddle on the club level rookie Rookie selections Ellinger Silver concourse rookies semi fahoko and Brandon cooks Kyle Trask rookie Derek Carr. We've got to 49 for the Bears David Montgomery on the bronze patch Claire Warren used material Trace sermons silver rookie concourse and Scridge rookie Tyler Wallace paint manning. We've got phenomenon Trevor Lawrence rookie Silver brand and cooks field level and a trailance field level rookie Yeah, those are sharp victor You got pat joseki blue Khalil Herbert on the club level for the Bears 38 out of 99 silver Baker concourse Derek Gore Henry kill Tredavious white. We've got maroon charles woodson concourse for the Raiders 81 of 149 Uh sake one Barclay silver and ben rossford last pack here player DJ chart to do to do to do we've got rookie selections silver kyle pits Silver ps2 on the club level and a gym kelly Alrighty eric that will do it for your box. I'm gonna show you that jamar chase that we got magged up for you real quick Beautiful hit here. Thanks again. Congrats and we'll get these right out to you