In this video, I'm going to be telling you about the Elgato Wave Low Profile Mike Boom Arm and showing you how it's set up and all of the features of it. So if that sounds interesting, stick around. Hello, welcome to Take One Tech, my name's Alec, and you will notice that there are going to be a few more videos coming up over the next few days and weeks about new additions for my studio because I am in my new studio space. And one of the things that I invested in as well was a new Mike Boom Arm. I had been using up until now one of these typical sort of $10, $15, are they? I don't know, bog standard Mike Boom Arms, which it's actually served me very well, to be honest. It's just that the mounting of it is a little tricky with my new setup. And previously, when I was in my little basement studio, I had it sort of mounted to a cupboard over to the left of me. So it is still, in effect, a low profile just sort of coming down under the shop with the Mike sticking up, much as it's doing now. It's just that with my new setup, I needed something a little bit more versatile. And so this was the ideal one for me. The Elgato Wave LP, standing for low profile, Mike Boom Arm. And I did have to wait for quite a while because they weren't available in Thailand for so long. And then when they did become available, they were rapidly out of stock. In the end, I just bought it from Amazon on the UK and got it sent over here. So one thing that I do like about it, there's lots of great features, but one thing that I especially like is the minimalist packaging, because basically that is the box and they just slapped a label on it and sent it all the way from the UK to Thailand and very well it came to as well.  So very refreshing to see this. The actual box that the product comes in is the postal box as well. And then if I open it up, you'll see similarly minimalist inside as well. So we've got a little instruction booklet like that. And then we've got the arm itself and then just one extra little packet, which has got a few fixtures and fittings, namely an Allen wrench, which I'll explain shortly, and then also two little adapters so that you can fit different type of microphones onto the end of the boom arm. So first of all, we've got two components really, main components. The first one is the clamp to clamp it to the desk, which as you can see has just got a little winder here. It's really quite deep. So it will go up to nearly two and a half inches, so 60 centimeters. In fact, I think that might be slightly more than two and a half, but you can just sort of obviously unwind this round. One problem that you sometimes have with these fittings that clamp to desks is this bit getting in the way and not being able to actually wind it round. So some of the lower cost versions would have a sort of bar through it so that you can sort of turn it round and push the bar through. This has got a really neat little feature, which basically is on a little release catch here. So if you just sort of push this down, then this then becomes sort of free turning. And what that means is if you are up against the sort of side of a desk or something like that, you can just sort of tighten it, release it like that, tighten it a bit more, release it and tighten it. I thought that was just a really novel little way to get round that problem. And the whole thing, this is all metal. This part here is plastic and then the plate itself is metal as well, I think. But it just all feels really solid and certainly doesn't feel like it's going anywhere. It's got this sort of long piece here, which is essentially what the actual boom arm itself fits into. It's got a real heft to it when you lift it out. So it definitely feels sturdy and quality. You could probably drop it and it would certainly survive if not crack the tiles on the floor, but that piece just basically slots in there. So obviously you fit this to the table first to the desk and then that just slots in the top. Before I do that and actually show you what it all looks like, just want to mention a couple of other points. There's a hole here in the bottom and it actually comes all the way through to the top. So depending on where your cables are coming, you've got a way to get them into the into the boom arm. And then this is basically just a metal plate that just pops off really nice little solution that. And again, the metal feels nice and solid, nice and sturdy. And once it's in there, it certainly doesn't feel like it's going to come off anytime soon. And so you've got the hole at the front. The cable would go up say in the bottom in my case along inside and then out of here. And then it would pass down into the top and you've got the same sort of arrangement on the top here with a second plate and the cable would pass through there and then come out to the end. There is a couple of tensioning nuts. So there's one here to adjust the height. So the idea is this being a low profile arm that this sits on the desk and then this bit can move, this bit can move. But then also this one can move up and down to adjust the height of the microphone. And so you want to be able to adjust the tension or tighten it once you've got it right. That is actually plastic, but it still feels pretty sturdy. And then you've also got this one, which can adjust basically the friction on how free this is to move. And that is basically what this allen wrench is for here. So you can use that to tighten up this. If you feel like it needs to have a little bit more tension and you just tighten that up like that. You can obviously keep this somewhere nice and safe. Maybe attaching it inside close to the magnets might be a good idea so that you don't lose it and always have it with the arm. And then on this end, we've basically got the actual mic attachment. Again, you've got a little clump and this is plastic and this is plastic. In fact, actually the ball part is metal, but this clump on the outside is plastic. But again, it does feel like pretty quality. It certainly doesn't feel cheap or tacky or anything like that. So this basically gives you the different degrees of motion. So you can rotate it and then also move the ball joint in any direction almost.  So this is where the little adapters that come with it would come in. So often mics would have a larger screw thread. And so this one you can just add onto here. In fact, you would actually screw it into your mic first and then screw your mic on. But similarly, you can also use one of these adapters if you need to make it slightly bigger or smaller as well. So that is basically what it looks like. So let's just actually get it all set up on the desk and I'll show you what it looks like in situ. Well, as if by magic, I've now got it set all up on my, whoopsie daisy, on my desk. It's got a mind of its own at the moment though. Just making sure I have actually on paused it. So what I'll do is I'll just switch over to another camera. There we go. And now you can see, well, first of all, you can see my lovely Ecom Live mug. But then you've also got the monitor arm here. And if I come over, you can see how it's clamped to the desk. Excuse the cable management. It still needs a bit of work on that cable management at the moment. But as you can see, it is clipped to the front and the side. Obviously, you can have it coming from underneath the monitor if you wanted. But I've gone with this option. Just got to figure out which way to turn it so that you can see. And there you can see the mic attached to the end. So I am using the Shaw MV7. And I think the weight limit is something like two kilos. I'm just going to have to move this out of the way of it so that you can see. There we go. I'll come around this side. And so, yeah, I've used that little adapter on the end there, just in there, for the microphone to attach to it. And then, yeah, it's just really neat. The cables run up through the middle. So this is what I was talking about with the cable management. They just feed in there and then these just pop on, like I say, really nice little elegant solution. And then for me, this just folds out of the way when I don't need it. And apologies for the fan noise. I've got to get an air con up there, but it's not in. That's what the empty wire is for. So for the moment, I'm just cooling myself with a fan. So apologies if there's a little bit of extra blowing the normal. But yeah, that is basically the setup, how it all looks. And I'm really pleased with it. It certainly does exactly what I need it to do. One of the things that I do need it to do is for most of these videos, I am standing by do some stuff sitting down on Zoom calls and things like that. So I've got my camera setup now. I've found the sweet spot that I can either stand up and do these videos like this. But then I can also sit down and with a slight different cropping, I can do regular Zoom calls as well. So the thing about the mic, this mic arm is it does have that sort of up and down function as well. So I can move it down to a lower level rather than having it in my face like this. So I highly recommend it. It's a great boom arm. And the only thing to watch out is if you do have stuff on your desk. So if you were to have it mounted in front of the desk, then you'd have to bear in mind that it's basically sort of two inches off the desk for the sort of first section. So with that sort of sweeping across the desk, you just have to be careful of that. So if you're doing crafts and things like that, just bear that in mind that it might not come over the top of them all. However, if you do mount it over to the side, I don't see that there's much of a problem. If I just sort of flick back to this view once more, where was it that one? You can see that I've got the mic on there. It's still way out of the way and yet I can still sort of fold it back like that. So it's only really this small corner that down here that is getting affected. So I think it's a really, really good for a lot of use cases really. So I'll leave a link obviously as always in the description. And if you found this useful, then don't forget to like and subscribe as always and send it to all of your friends and family who are looking for boom arms and would maybe like to know a little bit more about this one. But don't go anywhere because there are still plenty more videos coming up right now. And I'll leave a link to some of those and some of my other gear reviews over on the right hand side. So until the next video, have an absolutely wonderful day.


Hi, Drupal Gov. I'm Brian Gilbert, the founder of Reality Loop, a Melbourne-based Drupal development shop. I've won many hats in my Drupal journey, larger developer, core contributor, community lead, event organizer, trainer, and more. Today I'll be playing the part of an interviewer. I have with me Stuart. Can you please introduce yourself and tell us what you'll be talking about? Hi, I'm Stuart Clark. I'm the lead developer at Reality Loop. I am a decoupled Drupal and Vue.js developer, and I'm the creator of Truxt.js. Today I'm going to show you how to decouple Drupal using Nuxt.js and the Truxt site module. But before we get into that, could you quickly cover off what decoupling is? Decoupling is the process of separating your presentation layer or your front-end from your content management system, your back-end, in this case, Drupal. Okay, so using Drupal more as a content repository? Yeah. And why would I want to do that? You might want to do it for multiple reasons. I think one of the most important reasons is that your content can power more than a single site. You can have your public website, but in addition to that, you may have an intranet and multiple campaign sites, native applications, voice assistants, the theming experience. PHP is a great language, but front-end development and developers tend to prefer a JavaScript-based language for the reactivity and component-based languages like Vue.js. So decoupling gives us more options and allows developers to work the way they prefer, making it easy to find developers. Why isn't everyone decoupling? There are valid reasons why not to do it, and I think one of those is the complexity. When we first started decoupling our websites, there was a lot that had to be reinvented, so that's also where DrugsJS comes in. How would we go about decoupling with Drupal? It's relatively simple. Both Drupal 8 and 9 come with the JSON API module, which does the majority of the work. We're also going to be using the JSON API views module and the DrugsJS module, which simplifies some of the setup process. The Drugs module also provides a read-only permission that allows you to control who has access to all of the required JSON API resources. What does the JSON API module give us? The JSON API module provides a way for a front-end or a JSON API client to consume the site's content as well as some configuration in a standardized format. What do we have to do to start on our front-end? For the front-end, we're going to use Nuxt.  Why are you installing DrugsSite here? Drugs is a modular framework. It allows us to build lots of things using Drupal's content and Drupal's configuration. DrugsSite is more focused. It's about providing that out-of-the-box front-end experience. So I'll jump into the configuration. If we open up the Nuxt config file, all I need to do is add the DrugsSite module and our Drugs configuration, which is just the base URL, the domain for our back-end. We'll also go ahead and set up the Nuxt proxy so that our images will work correctly. And lastly, I just need to set the components directory to global for Drugs's theming system. And that's it. I'll spin that up and we can take a look here at our Nuxt application and that's building the bundles required to serve up our front-end. And where's this page come from? If we just jump across, you can see here is the index page and that's being served via Nuxt, not via Drupal. So we could create files here if we wanted to have one-off campaigns or standalone applications that are alongside the site. Yeah, this demo here, we don't need that. So we'll just go ahead and delete that. Now we can see content from the Drupal back-end. Could you explain what's going on internally? I think the best way to do that is if I open up the view developer tool, we have a layout provided by Nuxt. It's layout system which allows us to wrap the entire application with the required markup. So it's kind of like page TPL in Drupal? Yeah, if we step through, we can then see our Drugs router component. It communicates with the decoupled router in the back-end to determine what this particular page should be rendering. So in this case, we're rendering the front-page view. As you can see here in Drupal's back-end, this is the view. We're actually now passing on to a Drugs view component which has got access to all of the results for that view. Do we also get the view header and attachments? Yeah, so that information is provided in the view resource. Okay, so how do we theme that? Theming in Drugs is relatively straightforward. It uses a slot-based theming system. So we can just take one of these available options and drop that into the components directory. And then we render out our slot, and that's the content provided by the Drugs view component. It also has name slots so we can render out the header and the results separately. The Drugs components also have a wrapper property which here allows us to set the component, props data, and the class that wrap our result entities. I see these items, our entities coming back from the view. What's defining the display here? Drugs leverages Drupal's own display system. If we have a look at the back-end here, you can see... It only shows the image. Yeah, exactly. You can make changes in your back-end and Drugs will respect that. That's great, but what if I just wanted to add it in the component? The parent component also provides props data. In this case, entity fields and schema. We simply need to register the required props in our component, and then we can reference it in our ViewJS expressions. You mentioned campaigns earlier. Could we see an example? Sure. This is a campaign I set up on our Umami demo site. To get started, you just need to create a file in the Nuxed pages directory. What are those B tags you're using here? They are layout components from the Nux Bootstrap View module, but you can build this any way you like. Any NPM library can be used, the View YouTube component for instance, which I could have used in this demo, but instead I used the embed code. So, does that mean it's possible to use Drugs components in a page? Yes, absolutely. All Drugs modules can be used via the Drugs component itself. It just needs the module name and the correct properties, which we can find in a few different ways. One way is to use the View developer tools, as I've done here. Alternatively, you can read the output of the JSON API directly. Earlier you mentioned using Drupal content in other applications. Do you have anything you can show? This is an example entity explorer app, which allows us to see all of our content in any chosen View mode. We designed it to help with the process of populating the campaign page. It also has a way to test and demonstrate our theming changes against live data. You can have a look at the source code for this in the Umami demo repository on GitHub. It looks like Drugs is pretty mature already. What's the status and current roadmap? There's still a lot to be done. Our target for a 1.0 release is a feature parity with the Drupal Umami demo. But to get there we need to engage with the communities, back-end and front-end alike, which is part of the reason for this presentation. What sort of contributions are you looking for? All contributions are welcome, of course. The more eyes on the project, the better it becomes for everyone. Documentation, testing, feature requests, support queries help a lot, as do pull requests. The project is open source, and while Reality Loop is currently funding my development time, there will be a point where the project will also be looking at options for funding. That leads on to how can someone actually get involved? You can find the code and issue queues on GitHub, and for support and general inquiries, you can find us on the Community Discord server. We're also available in the Drupal Slack. Thanks for your time, Stuart. Let's cut to questions now. You can put me live, I think. If we have any questions, please feel free to post them now. We've got one from Seagull, which is how SEO-friendly is Drupal JS? Sorry, DruxJS. That's a good question. Can we get my video full screen? It is, Stuart. It is? I'm in preview at the moment. It's as SEO-friendly as NuxJS is, so Drux is just a layer on top of Nux. There is already a range of modules available for SEO in Nux. Are you aware of any similar systems? How does Drux compare to other things? There are another few sets of tools similar to Drux. We saw some at Drupal Con Global earlier this year. We're not really the right people to make that comparison, but we would like to see people doing that, people who have tried each of the individual solutions. The main thing about Drux is it's not about replacing a solution. It's not about being the only one thing. It's written in such a way that the modules can be used with existing solutions. Drux is primarily of UJS, but the schema module, for instance, could be used with React quite easily just by including in the relevant classes and taking advantage of that logic. I've got a question from Lee. Does the markup come from Drupal when you use Drux Entity? When you use a Drux Entity, the markup doesn't necessarily come from Drupal, but this schema does. Drupal will tell the front-end, the Entity module, via the schema that, say, three fields are showing. The image field, the body field, and another field. It'll say what order that those fields should be shown. Then Drux will pass that through to the relevant field. Those fields are provided in the Drux Entity module. There's a bunch of... Let me see if I can jump across to a quick example. Give me a second. If you have a look at the Drux Entity module, you'll see that this comes with a bunch of fields, such as basic string, date time, entity reference. Each of these fields are being provided with the Drux Entity module. Additional could be added in the future, but these are your bare-bone base fields. They will take the data from the JSON API resource and the schema information that they've been passed, such as the settings for that particular field, the view mode for the reference field. They will pass that to the field, and it will then determine what to render. Tim asked, I'm going to paraphrase, because for what I think, which is how do relationships work, e.g. reference entities in Drupal? Yeah, so they work. It was built out of the box to work with paragraphs for our preferred setup. The way it works is probably best if I actually jump in. Is my screen viewable to everyone? Yes, too. Okay. If I jump into this here, and we open up a piece of content, so I'll jump into an entity. Let's see. What am I looking at? This one. All right. So that goes through to a themeable component here, DrugsEntityCardCommon, which passes through to a field. And in this case, that field is an entity reference field. So if we open that up, you can see that the entity reference field actually passes its information along to another DrugsEntity. So it's doing that entity reference exactly the same way that Drupal would. And then Drupal will then pass that along to its relevant field, and then you come to the last field in the RenderStack. Okay. Is there any PIP projects that you're using Drugs on? Yes. We, myself and my wife are currently building a game with it, using Drupal as the back-end, the database. And essentially, you have your Drugs front-ends where you'll present the game. You have web sockets to communicate with each player, and then it just stores that data as you play the game in Drupal and syncs it across and allows you to play another game. So it's a multiplayer game, basically similar to Cards Against Humanity style. You'd be in the same room. You'd be synced up with all the players that are in there. Marco asks, can you use Drugs.js in a progressively decoupled approach, like an on-page mini app slash widget? I don't see any reason why you wouldn't be able to. So each of the modules provide different exports as is. So if we were to look at... I'm still in here. One second. If you look at the component, the Drugs entity component, so as long as this entity component is registered in your progressively decoupled site, it will be available to your progressively decoupled view app. Drugs uses a Vuex store for the data that it has available to render into those components. But there's no reason that shouldn't work with progressively decoupled. I have not tried myself personally though. Letan asks, why did you choose Drupal as a database for the gaming site you're developing? I chose Drupal because I'm building Drugs. The main reason is as I started developing Drugs and I can see the connection, the ability to use data and crunch that data with things like views, I can simply turn Drupal into a database. It holds the information. It can crunch it. It can do whatever I need, but it's not necessarily for display. The front end, the Drugs side of things, it can just pull that data, the information I need and figure out what it wants to do with it instead of leaving that up to Drupal. Jack's asking, do you see any alternatives for paragraphs to model data for decoupled sites? It's an age old question. I don't want to make that decision. I don't want to use paragraphs in reality loop builds that we do. Any entity reference that you use, any entity referenceable system that you use will work with Drugs at the moment because the whole point is do what Drupal expects you to do. An entity reference says, this is my connection to other data and Drugs will go, I see your connection. I will acknowledge it. If you were using a WYSIWYG based approach, it will get the data that the Drupal has stored sent to you. So if you've got your references tokenized inside of that data, Drugs will see it and you will be able to use Drugs to reinterpret it as need be, but references and paragraphs seem to be the most logical for data structure. Are there any types of site that Drugs isn't currently suitable for? At the moment, the Auth module has not yet been solidified and published. So a site that is heavy on Auth is not the best choice right now, but it's essential. We're aiming at the moment to build Drugs around the UMami demo because it is a... On interrupt, we've only got 30 seconds left. How about integrating with something like Sol or other search engines? Yeah, absolutely. If you're headless, if you're decoupled, you can integrate with anything that you need to. If you've got endpoints, you can do it. The version of a front-end that we have with something similar to Drugs goes straight to the search engine instead of going to Drupal. In the case of the UMami demo, the search work that has been done to this point goes to Drupal via the JSON API search module and then to the search system. Okay, that was it. Thank you for being here and we'd love to hear feedback. Please jump into the Discord channel if you have any more follow-ups.


Hi everybody. I'm Ellen Ramsey from the University of Virginia, and I am fully aware that I am standing between you and the reception, so we will start on time. Thanks for coming. I'm the director for scholarly repository services at UVA. You can ask Chip what that means. We made it up. And we thought it would be interesting, and apparently CNI agreed, to talk a little bit about what it's like to live with an open source implementation. We've had one at UVA for a really long time, longer than I've been there, and so some of the things that I'll tell you today are outside of my personal experience, but I'm sure they're all absolutely true. I want to give you a little bit of background, a little history, about the platform and the things that we're working with, and sort of some things that happened before those of us who work on the project now have been working on it. I'm sure that you've heard the history of Fedora and that it was born in Cornell in 97, and 2001 is sort of when UVA started to get involved with this project in a really significant way. We had what we call an alpha test bed at UVA, and it was definitely a proof of concept, something like a half a million images in a Fedora repository. A few things happened over time. We got some grant money. There were some public rollouts, and by 2007, fast forward, we're starting to see some community movement, and so we've got Fedora Commons, and at UVA we did a little thing called Blacklight, and it was really interesting for me to go back and read the history on this. I don't think I was even a librarian yet at that point, no kidding, that there was a general dissatisfaction with what the vendors were bringing, and we wanted to build something that was better. Gosh, I think I've heard that before. So 2008, hey, institutional repositories, they're awesome, we should have one. So like all good research institutions, we wrote a report, and there are options at that time where you're not too dissimilar to what institutions right now are looking at in terms of we could adopt one, we could extend something that we already had, or we could go make something brand new. But there was something else going on at that time, really, for the first time, which was there was a lot of things going on in the open source community. And so the rest of the presentation I want to show you is what was going on at UVA, but what was also going on in the open source community at that time. You might notice though, my little icon there, given that is the holiday season, and given that this is a conversation about community source and what it means at the local level, I'll just say that every time a bell rings, a developer gets their wings, right? So I'll ring one bell, which is one of the original founders of the Fedora project at UVA, Leslie Johnston, left UVA to do much grander things elsewhere. 2009, hey, open access is good. Maybe we can use that to do some stuff. So there were things going on at the community level. We got our faculty senate to start discussing an open access policy, and best saddler left UVA to go, again, do really interesting things in the open source community at another institution. So there was also some community movement. We've got Duraspace coming together at this point. And so really a lot of things, a lot more resources that might be available to us. Fast forward to 2010. We finally get our open access resolution at UVA, and it provides the rationale for our continued development of our institutional repository. There's a link there. You can go read it. Judge for yourself whether you think it might be effective or not. We did get some resources, though, from the university based on that resolution to a higher media shelf, which is now DCE, to help us build what we call Libra. UVA has Libra, Virgo, Leo, you get the idea. The next one is cancer, so we're not building that. So we did do that work. Oh, wait. And so other institutions were building their own Hydra heads as well. And for the first time, we really see a community-sourced project to look at a particular implementation of a Hydra head, a Hydra implementation built on top of Fedora, which was called Hydrangea. It didn't really answer anybody's problems, but it was a nice start. 2011. Hold on. We had, fortunately, it was a good point in time that we had already begun taking deposits into the institutional repository head that we had built, but we did have a wholesale departure of our development team at that time. So things that were going on in the community, there was a lot of discussion about theses and dissertations being the low-hanging fruit, which I can't remember the article, I wish I had looked it up. Somebody said that's a horrible term, I agree. But we were taking that kind of scholarship, we were taking what I call small data, right? What do you get, 100 megabyte data sets? That's not even a data set, right? And we had availability for open scholarship in this tool. Moving into stuff I can actually remember now. At this point, between 2012 and 2014, I want you to notice no developers left. And we got some stuff done, right? So, and you start to see our repository down here, this is what this is, is really growing, okay? So we're up around 3,000 items, something like that. Also that, I would say, are theses and dissertations for sure. So we've got that going and we've got great linkages there. Not too much interest in the other things that the repository can take. And, oh, all of a sudden, man, that code base is getting old, right? So things that had been going on in the community is that Fedora had been, you know, coming out with new public releases. We had one, we had two, we had three, we're now getting to four. Our Fedora instance at this point was at two. So that's where we were, that we were interacting with the community but had some challenges to overcome. And, oh, there's another community-sourced institutional repository, collaborative project, this one was called Hydromeda. Yes, there's some lapses in the back of the room. Wait, you want to know who was in that team? It'll be a good list. So it was five institutions, Notre Dame, Northwestern, Indiana, University of Cincinnati, and University of Virginia. So there's some really familiar names to those of you who are still members of the now-Sanvera community, right? So lots of things did happen. They did not happen through Hydromeda. 2015. Yeah, that code base seriously old. But, oh, I don't know how to do a half a bell. You only had one developer leave, and we got two more. So I think that's a half. So we stopped our participation in Hydromeda at this point. But we were really clear that, man, we got to get off this whole thing, right? The usability for the students with the PCs and dissertations was dropping. And they had to use it anyway. So we had a captive audience, but that wasn't very nice of us. Nobody was using data or open, hardly at all, because it wasn't a pleasant experience. And all of those other reasons that institutional repositories also maybe hadn't been the answer to some of the things that we thought they would be. But in the community, we're getting some convergence on a couple of more successful institutions, institutional repository solutions. So ScholarSphere, Notre Dame's NDQ8, which NDQ8 was actually what came out of Hydromeda, mostly. And we're seeing more convergence on Fedorf. And we finally had the opportunity to go to Fedorf for. And what we took was a modular approach to what we needed to do with our repository. And a couple of things that we did a little bit differently. So we moved our ETD implementation onto Sophia, which is what ScholarSphere became. And that was where the community was converging. We did something really radical. And our library IT director is still mad at me about this, which is we said we're not really sure that small data is that useful. And so we're not going to build anything for that right now. But there's this awesome thing called Dataverse that we're going to use for a while, thus the modular. And that has been a reasonable solution for us for the last couple of years that we've had it. And the other thing that we did is we took away the discovery layer from the institutional repository itself. If you want to know what's in our institutional repository, that's awesome. You want to know what's in the library. And so it's in the library catalog. It's in Google Scholar. It has DOIs. It is in data site. So go find it there. We don't want to silo this content because if the objective is to make open scholarship in context with all the other kinds of scholarships that libraries provide, that's great. Let's put it in the same place. And we had it there. But by forcing people to, essentially, by forcing people to look for it in the library catalog, that really makes it clear that this is really in the library.  So we're watching the community. As I said, ScholarSphere became Sofia. And you curate became curation concerns. And while we were launching Dataverse, we're also watching what Michigan is doing with deep blue data. We're still watching. And they've got wonderful stuff. And that may be the direction that we go. But there's some other stuff that's happening in the broader community. Elsevier starts buying stuff, like SSRI. And we're seeing some more Mellon investment that we think is really relevant to us. So Hydra in a Box. And I'm sure that you have heard of the presentations that have been around the conference about that. And there's some really interesting things that Mellon is funding in terms of what might we do with open monographs. And initially, that research was about how much does it cost? But then that has, in the last year or two, moved into, OK, now that we know what it might cost, how do we do that in a community way? So here we are in 2017. We finished building the modules to our institutional repository this year. We launched the faculty piece, the open scholarship piece, of Libra in August of this year, Libra Open. It's got some stuff that we didn't have before. We were actually pushing people's deposits to Orchid. And that's pretty neat. We didn't give DOIs before for open content, but we did for ETDs. So we added that. And the other thing I didn't put on the slide, but we just had it on Friday, was we turned off the original Libra instance. We had a wake. That's fun. So other things that are happening in the community, we've now got high racks instead of two separate instances of Sophia and Curate. People are looking at Haiku. And we're seeing some interesting things going on with open publishing. More on the journal, sorry, on the open monograph side than on the journal side in the community. And so that's what we're watching. So what's next? We are really proud to announce that, can I announce this, Dave? He's looking at me. That we are piloting Ubiquity Press as an open journal service. And again, it's very similar to our decision about Dataverse in that we're really not sure how well this is going to take off. It might be fantastic. Dave thinks it's going to be. And if it is, that's great. And we may invest resources later into building something more custom. Or we may say, hey, this is awesome. And it is an overlay of an open system built on OJS. But it is also a vendor. So we have made these decisions about what we can do to be modular, to be agile, to be responsive, without making enormous investments in. So we will be migrating to Hierarchs this year, given no ringing of the bells. And other things that have been happening in the community, I think you've heard about those a lot during this conference as well. Hydra is not a thing, but same there it is. And I don't know if I've heard this today, but that Haiku and Hierarchs, the code bases are actually going to move. And so there should be some more alignment. And that will be really interesting for institutions that end up going with sort of the more out-of-the-box solution of Haiku and want to do more customization with Hierarchs. I don't know that I would go the other way, but you never know. And so we're watching. Now we have the great advantage of watching our partners already migrate to Hierarchs. And they said, oh, sweat. And our repository has continued to grow. So some of the culture shifts that have happened during this time, as we talked about moving from an all-in-one repository, Libre One was just everything in one bucket to some more replaceable components moving to that single search so that we can have lots of sort of invisible sources for the content coming to what feels like the same place to users. Internally, we moved from a more traditional, a little bit larger investment of time of an epic and story model of development to a more agile model. And I had to learn how to do that. And I think that it has been very successful for us. It's also something that the community was doing. And so we've been able to align better with the open-source community. I think we have to recognize that as a partner, we're really, as it says, just altruistic enough to participate with the community but make sure that we've got our eye on what's useful to us. And so there's a lot of pressure in the San Vera community, not a pressure, but there's encouragement to contribute to the community code base. And we've done that. We are doing that. And we're doing it in most cases where we see a real outcome for what our repository needs as well, what our institution needs. And that's a little bit more pragmatic, I think, than some institutions have been in the past and that some institutions are now. But, you know, just saying. There's some things that have happened in the community that have been really helpful and moved a little bit away from purely, from just a technical community to really how to manage these projects, how to transition to, okay, we built it and we still have to keep the thing going so that we don't have happened again, you know, an orphaned code base and aging software. And it really has been sort of what I would term agile production. We are still doing sprints for our Libra implementation, but we only do them once and once now. And we sort of gather up a little bit of stuff and roll it out. And one of the benefits of that has been that we had, our ETD deposit period is always like right after Thanksgiving. So we draw straws, who has to cover over Thanksgiving. We had no questions this year over Thanksgiving. And so, you know, we really have been able to respond to our community while still keeping current with standards. And I think I made the last point already. There's a recognition of things that you can get from the community, but it also, that it costs. And it's not always the solution in every case. Either right out of the box, or maybe something that we go to longer term when we feel that we need a more custom implementation. For your reading pleasure.  So the gray areas are what we are thinking about and the white areas are what we have already rolled out. I would be delighted to take your questions at the reception. Thank you. Thanks everybody.