All right, thank you all for coming out here today. We had to do a bit of a switcheroo. So the normal person given this presentation every year is actually my boss, Michael Haggerty, who's the CEO of Trellen. I was actually the project manager on this project. And unfortunately, Michael had a bunch of other stuff to attend to. I don't know whether it was leaders of state or ice cream truck, but he couldn't be here. So you guys are stuck with me, unfortunately. What I will do, though, is do my best effort to guide you through the case study that we put together for a project that we did recently that I'm hoping you all find some nugget interesting or some valuable takeaway. Because as you can see from our description here, the main challenge that we had with this client was not that the work was incredibly difficult, although there were some challenging aspects to the project. It was that we had a very, very compressed time frame in which to do that work. So we had a client out in Massachusetts, a company called Brainshark, who was very cooperative. And a lot of the stuff that you're going to see on this presentation is actually supplied by them or even quotes from them. But they had really come to us, asking us to migrate their entire site to Drupal.  And after weighing a bunch of options, they had made the decision to switch or make a transition from Sitecore, that platform, to Drupal. And then as we got into it, we discovered this was not just a straight out migration. This was also going to be a complete redesign, as well as in tandem with the reposition of their entire company. And it was also going to be done within three months. So typically for a project of this size, I mean, to put it in context, this is about $100,000 project. We were asked to do, typically a project like that might take us four to six months. Here we were doing it in three. So just to give you a sense of the old site that they were coming from and some basic information about it, I think it was at least two or three years old. One of the main challenges they had was updating content. I'll get to this in a second, but they had some challenges with their actual Sitecore implementation, which I'll talk about shortly. What you can see here, though, and this is just a point I want to emphasize because I've come back to it in a few, well, probably about 20 or 30 minutes, is the basic layout of these pages. What you're seeing here is really a site that is a format that we, at least at Trellin, would call like a wedding cake format or a layered page. So it's stack content that is being applied. So what they're really doing is creating layers of content that might have different templates or different designs, and then stacking content repeatedly on top of this. And they're doing this in various formats with different kind of media all throughout the site, whether it's a straightforward page describing their product that happens to have some video playing in Modals or whatever it is to the way that their blog is arranged. It's all stack content throughout the site. So one of the things to keep in mind when we get into out the solution that we wound up implementing was we needed something to accommodate the way that they were comfortable entering and creating content for. Because even though they were going through a redesign, and even though they were going through a reposition, they still kind of were comfortable entering content. And the company that they outsourced the redesign to was using that approach as well. So we had to keep that in mind as we moved forward. So here are some of the challenges. I'm not going to go through every one of them, because we started a bit late. But one of the challenges was they had very limited support and maintenance. There were some security issues. They had a challenging install and not a lot of support. And I think one of the financial challenges they were running into was the way that site court structure, some of their arrangements, is that if you drop support, you've got to pay arrears if you want to get back on support, which was the circumstance they found themselves in. So that was going to be expensive as well as, obviously, some security challenges as well. You can tell from my last slide they had some poor template implementation. I'll show you a specific screenshot in a second about the interface that they were actually using to enter content. But ultimately, it wasn't intuitive. It wasn't user-friendly. There were only like, in a reasonably medium-sized company, there were maybe two or three people that could actually do the content entry, which was not an ideal solution for a company that had an entire media department and bloggers and all kinds of other things where they needed accessibility to the CMS system. And then there were also some challenges with the licensing model. And redirects and their CDN system was also a challenge as well, which I'll get into in a second. So some more contextual issues. They wanted to change their hosting situation. I just mentioned the arrear situation with support and maintenance. They had a BAS installation. They couldn't upgrade. They had burned a lot of money trying to upgrade. One of the challenges was finding good people to help them with that site, because SiteCore is a lot less widely adopted than Drupal is. And the way that the client characterized their solution at that time was that it was like a race car, which was something that was really powerful if they actually knew how to operate it, which really not a lot of people there did. And so it was actually this really dangerous vehicle instead of something that could really be very successful. So here's my screenshot. There's their CMS interface. And so every page that you saw, that's really what they were having to code in. And like I said, there was really like two guys in their entire organization that got saddled with that sort of development, which is, as you can imagine, not really what they had envisioned when they selected SiteCore in the first place and really guided a lot of their decision-making for selecting Drupal and ultimately Trellin as a choice. And I think I've got this slide if I could figure out how to activate it. Well, we'll skip it. But basically, it was a heated mess. It was about as far from ideal as you can imagine. And that's part of the reason that we had to do this so rapidly, why we only had three months in their plan. Because I think they were really exhausted with the situation they found themselves in. So from a business needs standpoint, it was a major priority changing the CMS. And then one of the things that we discovered in our three-month journey with them was there was going to be a major rebrand. So first, they came to us saying, well, we really just want to migrate and put this on Drupal. And that turned out to be, well, then we want to outsource to a third party and have them reskin some pages. And then we'll just adopt that reskin template for the rest of our pages. And you're just going to be doing that in Drupal. And then it became, well, let's just redesign the whole thing. So that was a wrinkle. And if we had known that at the beginning of the project, we probably would have pushed a lot harder to say, this can't be done in three months. Because one of the challenges that we had to experience was and overcome was we didn't have design work. So they wanted to do all this rebranding. And we're waiting for a third party to come and deliver design work for us. It would have obviously much faster for us to just take our own designers and have that do that, engage in that process. But they were committed to their choice. And what really happened as far as the timeline was, we were two months into the project before we started to get finalized approved design work. So we had a month at that point to do everything design related, theme, et cetera. And that was a wrinkle for us as well. And then they wanted a templatized approach to coding pages. So getting away from the screenshot you just saw. And then something else to consider was they, the way that Brainshark works, they've got their own proprietary app that they use. And that's something that they sell to clients. They've got a Brainshark app, they've got a SlideShark app. It's for marketing and sales enablement. And we had to be able to integrate with that app as well. So that was another item that we had to factor into our approach. So here's the actual Brainshark plan from their own words. It was migrating to CMS.  They put together like 40 slide presentation using a bunch of research. If some of you guys were at the AQUA's presentation on Monday, you probably saw some of that research selecting partners. You'll see like SiteCore is in a quadrant and Drupal is in a quadrant. That was, again, a fairly exhaustive process they went to to make that selection based on some of the challenges I just described. And their timeline. So this timeline was the original timeline. This was without any rebranding. This was a three month timeframe. Notice that the design development phase is two and a half months. And I just told you we had to compress that into a month. And that this that you're looking at really didn't account for much new branding and we had to account for an entire rebrand. So we still tried to accommodate their schedule but with a lot of new factors thrown in, a lot of monkey wrenches thrown in that we didn't really account for at the project outset. By the way, if anybody has any questions about any of the details, please raise a hand, jump up. I'm happy to jump in. So a little bit of information about us. We do about, we've been in business for about 12 years now. Trellin primarily focuses on the non-profit and education and NGO space. So the reality is we don't even do that much commercial work. But Aqua came to us with this project. They said we've got a client that really needs help. They've got to get this done in three months. We said, you know what, we're up to the challenge. So that's kind of the genesis for us even working on this project because it's outside of our usual market space. There's about 20 of us divided up into full-time folks. We're a completely remote firm that's something maybe you guys have some questions about how we did some of this as a distributed workforce as opposed to everybody in an office where it could collaborate easily. But we just use a lot of online tools that Slack and Hangouts and all kinds of other things to work around that with both ourselves internally as well as the client. And then some information about our process. So first we go through a discovery phase, defining goals, understanding what the deliverables are, a design phase. As I've been indicating, this phase kind of got bumped a bit. It changed drastically throughout the project because really what happened was, and I'll get to this in the later slide, but there was, during this, the section of time which we would ordinarily devote to a lot of design work, we were actually doing rapid prototyping. So we had, we went through the next phase actually, the core configuration phase, which gathered the requirements. We documented everything as exhaustively as we could in our Wiki and met with the client, understood what their need was, and then translated that need into technical terms that our developers could then take, we could use to write tasks and tickets for, figure out what modules we need, what content types, et cetera, and we used that to rapidly prototype during that timeframe that we would ordinarily be doing design. So a bit of an inversion there, design actually came right before, really right before deployment and after implementation. So moving on, we had then development and the implementation. We'd have our weekly sprints, usually those were a week to week and a half, followed by implementation, preparing for launch, importing the data, and even then, that's when we sort of plugged in the design phase, followed by deployment, implementing the CDN and Fastly solution, et cetera, and then post delivery, doing a lot of review QA and bug fixes to make sure that they could get a working viable product within their three month timeframe. So just some basic methodology information, we use an agile process. What that means in practice is, like I said, week to week and a half sprints. What that usually means is we've broken all of the requirements down into user stories first with the client and then we take those, we size those user stories internally with our team. You guys are probably familiar with this, we use a Fibonacci scale to evaluate the stories that we can't include that are epic. We go back to the client and we say, how can we make this happen in a different way? Or we say, this will happen in post launch at some point. Once we've done that, those stories become, they're broken down by tickets, by priority, and by project plan. And then they're tasked out to developers as needed from there as tickets. We use RedMind, and one of the things I wanna emphasize in RedMind is our client has complete access to RedMind as well. So they're working through, one of the challenges I'll get to in a minute was some contextual stuff. And one of the things I wanna emphasize is on this project, given the timeframe, it was incredibly important that we maintain as open and transparent mode of communication with the client as possible. So they knew exactly where we were because the folks that we were dealing with on there they've gotta have accountability to their chief marketing officer, their chief financial officer, the rest of the executive team to make sure that their business needs are gonna get met within those three months. So it was important for us to make sure that they were invited to sprint meetings, to sprint planning meetings, they could sit down and understand why is the story epic versus why is the story a three? And they could understand all of the documentation that we were doing in our wakey. So, and I'll show you some of that in a moment, but we wound up for some of the aspects of the project that we knew were gonna require more of, there were gonna be a communication hurdle, working through the Fastly and Proxy issue, working through the migration issues that they had. We knew that we were gonna have to document that and make sure everybody was in the same page as far as what the problem was and what our solution to us, gentlemen. That's a vote that, so usually we grab no less than three developers and so I'll lead a meeting where we'll sit down with them and they're the ones that are voting and I'm just administrating that vote and then we've got a system that averages out their score. We make sure everybody's comfortable with that. Obviously we've compressed timeframe, we had to hustle a little bit during these meetings that we normally wouldn't, that we'd normally be trying to talk about them a bit more, make sure, first we make sure everybody understands what the requirement is, we vote, we average, we make sure that makes sense and then we move on to the next one. And then the point that I talked about a few minutes ago, the wrapper prototyping, one we would ordinarily do that anyway once we gather the requirements and core configuration so that we can start to build out something that even though it doesn't look exactly like what the client is anticipating, it functions exactly like the client is anticipating so that we can start to tweak that or refine that as needed based on any new requirements and obviously throughout this project, just in the design standpoint, there were a bunch of new requirements that emerged throughout this small three month window and the prototyping then allowed us to hit the ground running the moment we did get that design work done. So not only just as a little bit of more context, not only was, do we go from just migrating to some reskin to redesign, but the third part that they outsourced the redesign to wound up dragging their feet a little bit on that. So that was an additional challenge for us to make sure that we had everything ironed away as much as we could so that we could hit the ground theming as soon as we got that approved design work. All right, and so here's just an example of how we document stuff in the Wiki. I know that there are probably better systems that other folks use, but each one of those, you probably can't read it, but each one of these corresponds to a major item. One of those is, for instance, we've got page configuration, block configuration, content type configuration, module configuration, and then there are some additional challenges that we also document at the bottom, everything from theme setting to the issue with Fastly and the CDN system because they had to serve pages both to their BrainShark app as well as to Drupal, which is another challenge we had to work with. But the other thing I'm just gonna emphasize with that is, again, client can see all of that. So they know exactly when that's getting updated. If there's a question they have, whether it's understanding how we're working content types or whether it's some of the stuff that I'll show you in a few minutes about how we approach the CDN issue, all of that's in that same repository where they can view it to their satisfaction. So just a word here about the migrations. Cycle or handles their data a lot differently than Drupal does. So one of the things that we had to account for was a migration strategy because they had a lot of blogs, they had a few other content types that we would also need to be in there. The blog was the main challenge because they had links and media going back over a thousand blog posts going back several years in the Cycor system and it's very proprietary, they have their own internal IDs. We had to make sure that we could develop a package first within Cycor that contained all of the requisite information we were gonna need and then create a custom script within Drupal to digest the package so that Drupal could understand it. And then finally put that up in the development environment to execute the migration and then I'm just gonna mention that, like I said, there were additional migrations we had to contend with too, not just the main one. So that was something that, again, is gonna be documented in the same wiki that you just saw so that we were on the same page as far as both how to execute in the timeframe. And let's see. So yeah, just to run down to some of the items that they wanted to migrate from Cycor, a lot of pages, a lot of blog posts. They also had a database of press releases and news articles that I'm not even sure is listed on here. So it was a fair amount to make sure we had under control and that we had a strategy. In fact, I'll admit that we had one person working on that for about three straight weeks to get that done and make sure it was, we were on top of it. So the issue with the CDN Fastly, I kind of touched on this, this is making sure that we could serve data to both the native Brainshark app as well as Awkwia Drupal and wound up configuring a bunch of rod of slash rules to make sure that content was gonna be served in the appropriate place. And this was also just collaborating with them, making sure we understood everything from directory structure and how they wanted pages to be built out, to understanding how the Brainshark app worked and making sure, again, all this was accounted for in our plan. And yeah, and there were some issues where we just had to accommodate some conflicts and work through them. And like everything else that I've touched on, as an example, so here's how it was documented in the Wiki. So we had, again, one or two people sit down, come up with a plan and figure out the best approach, share it with their engineering team, make sure that they were on board with our approach and recognize, you know, we're in agreement with both the problem and the solution so we can move forward with that particular solution as well. And finally, our challenge and with theming, again, we typically would take at least four weeks on most projects. Here we had really about two weeks because those last two weeks were for QA and testing and making sure that we could actually launch the product in a format that they were happy with. So one thing I really gonna emphasize was, and this is something I had never done at this stage, was we essentially, for a lot of this, grouped up to coordinate our theming efforts. So if we had, say, six people working on theming at a particular time, we'd get everybody in a hangout and it really became a four or five hour hangout, perhaps, as people would hop in, figure out where we are at that particular juncture, we'd hand out discrete tasks, we need to create a particular style sheet class for something that handles something and that developer would go handle that and come back to us in half an hour, an hour, or two hours, or whatever it took. And then we'd be able to, we'd be able to add that to whatever additional style sheet classes we already had. Maybe a developer that was working on a specific kind of page would take his work, take the other person's work, and incorporate that maybe, so there were, we tried to work on a series of dependencies basically, so somebody would create a number of classes and then somebody else who was then doing different theming work would take those classes and actually build out the specific layers in a page. Ordinarily, the process of trial in is that the client, once we've trained them, does a lot of content entry, but in this case, there really wasn't the time to do that, so it was on us to do that. And I want to show you, in a few minutes, the system that we actually created, we used a paragraphs module approach to the layers, so this is where I mentioned at the beginning of the presentation, a lot of their content is stack content in those layers, so those wedding cake pages. And what we did was we used paragraphs to make sure that each paragraph had a different template, so we looked at their site, we realized, okay, there's 10, 15 major templates that they use for the way that they're creating these layers. Maybe it's a 40, 60 distribution of content, maybe it's an inverted layer that has four columns, something like that, and then all the user does is go and select that layer in a dropdown menu and then plug in the respective content from there. And then with each respective layer or even each content section within a layer, they have the option to add style sheet classes to make sure that content is displaying, like with a particular background. Or in a particular font or the content is centered or whatever it is, that it was an easy way for somebody to be able to look at the mock up and say, okay, this is actually a page with five layers, we're using these different formats for these five layers and here's the style sheet classes we'll need. And if we didn't have one, that's why we're on that call with all of my developers, we can say, okay, we have this need for a particular class, can somebody go make this? And somebody would volunteer and they'd go come back to us an hour and it'd be made and we could then go use that on the work that we were doing for the other folks that were actually building the content out. That's a good question. Sorry, I think if I'm not by the mic, it doesn't record, it hates me. So we actually look strongly at panels and it may be a better question if I talk to you afterwards and I can show you the specific setup we use, but ultimately Paragraphs was gonna accommodate the sort of specific layers that they were looking for in the layer templates as well as the style sheet classes a lot better than we could do with panels as an out of the box solution. So it was partly again a timeframe issue that we made that choice. Okay, so I think I've talked enough about that unless anybody has any questions about that approach. I'll show you visually in a few slides what that's really gonna look like. So the other aspect I wanna touch on is how we handle review and QA because this was really like the last two weeks of the project that we had to make sure everything was actually in order in a way that they could flip the switch and launch the site on time. And what we wound up doing was coordinating very closely with the client so that what they would do is on their end, when we were at a place where content was ready to be reviewed, we'd have, first of all, and I wish I had a slide for this actually, but maybe I can show anybody it's interesting. We first had a page index, which we were turning over pages and periodically reviewing them with the client. But after all of that was done, we had a separate Google doc that we were sharing with the client to catalog all of their feedback, which was broken down by page and then broken down by issue in the page. And I think I've got a slide for it. So that's actually, this is like 460 issues long and probably wasn't the end of the project. And some of it's hidden, but what they were doing was they'd have review parties on their end. They probably had in total, I think over the course of those two weeks, probably at least four of them, where they'd pull in all people from all kinds of departments that they'd sort of requisition or pull into service and sit down on evenings and go through these very in-depth review sessions, pouring over each page that we turned over and figuring out this match, what we're looking for. Does each link work? Does each video pull up in the right sort of format, full-screen modal? Does it look like it's supposed to? Does it function like it's supposed to? Where are the issues? Is the page loading correctly? Are there small inconsistencies or errors? And these all get documented on a line item base in our feedback worksheet. And so every morning, the following morning after the review party, we would connect with the client and figure out, okay, let's triage this list, figure out what the most important is, so they rank it. One of those columns is for priority. We make sure that we target the highs first and the mediums and the lows. Off from the side, I'm not sure you can actually see is a column for us to also use it to take, so our developers can take issues, put their name in there, say we're working on this to make sure nobody's duplicating effort and make sure that we can just, in a span of two weeks, plow through every item on this list. So that the site's in a good working order by the time it is actually launched. And then obviously each time there's a review party, more issues get added to this list and we repeat the process. And this, we again went through this four or five times through the course of those two review weeks, basically the QA weeks. And then there's something intangible I also wanna mention, which is attitude. And that's actually a quote from the client. That's there, I think they're marketing director and he called us the calmness and the storm. And I think probably people in the audience have been in similar spots where their client is a little bit anxious about the state of the project. Maybe they're anxious about the fact that we've gotta deliver this entire thing with a lot more requirements that we originally envisioned within just three months. And maybe they thought we'd be farther along for some reason. You know, I think one of the particular challenges in the case of this client was, and you guys have probably experienced this yourselves, if design isn't in place, even if we've got a prototype that works exactly to the specs that they needed, if design is not in place, it doesn't look like what they're expecting. And that is a psychological hurdle that we had to overcome. And so part of our solution that was just knowing that, you know, our confidence, we've done this for 12 years, we've done, we've probably been in as tight positions before, and I think the client really picked up on that attitude and appreciated it. And it calmed their anxiety. So when they had their own meetings with their own executive team, they could say, you know what, we get that maybe all the design isn't quite in place. We get that there's 200 issues still in the backlog, but we'll be ready. And yeah, we did have to work some weekend hours, and I know that they were working nights to review it, but it was all, none of it was, I would say excessive. In fact, in my history at the company, I think this is probably the only project I've had to work some weekend hours on. So the point is, if we needed to ramp up even more, if I needed to pull in more developers to put in a few more hours in the weekends, we still had the bandwidth in which we could have done that. And I think that's probably the knowledge on our end that allowed us to have that sort of calm attitude to take to the client so that when we engage them, they could really, they had the confidence to realize we were gonna get this done on time. This, you know, there wasn't an imminent crisis. We weren't gonna have to push back to launch date. Things were gonna be okay. So here I wanted to show you the paragraphs system that we implemented. I'm happy to walk to the site with anybody after, because I think we'll probably have a few extra minutes. I'm not sure I can actually am smart enough to figure out how to put on the screen, although I'd love to do that if I could. But you can see that content is again sort of stacked and you can't really see the bottom of the page, but it's in a similar format where it's layers and layers may have all kinds of different setups. They might have video, they might have images, they might have infographics, they might have contact us layers with, you know, it could have all kinds of contents and backgrounds and so on. And here's what it actually looked on the back end for our users. So what you're seeing here is, unfortunately it's kind of hard to see, but we call them wedding cake pages internally, but they're really just layered pages. And what a user is selecting in that drop down menu at the bottom is the template for that particular layer. So like I said, it could be a 60 40 inverted layer and then they get a system in which they can then edit that layer depending on the particular constant layer. And then they've got a section below that in which they can add or adjust any stashy classes that we've already set up for that layer so they can get the look and feel that they're hoping for. And that from here on out also, that more than just two people in the organization can be comfortable using this system. That it's very different from the system than the screenshot that I showed you at the beginning of the presentation. And let's see, I think that's probably it. So that's pretty much it. I'm happy to pull up the side itself and walk through some of their choices that we made with the client and how, you know, this particular content management system worked for them. I mean, they were pretty ecstatic with the solution that we delivered and the timeframe that we delivered. And yeah, with that said, I'm happy to take any questions you guys might have. Right, so any one of these systems can be edited and the fact that that's the first button you're seeing on each of those layers and pulls out into that expanded window in which somebody can do all those edits and adjust the stashy classes and so on per layer. I don't have a great answer for you as far as an engineering perspective, but the guys that worked in it are downstairs. Or you can shoot us an email and we're happy to walk you through that process. That's a great question for our guys downstairs. So I'm gonna defer to them because I'm probably gonna botch the answer. But again, quite happy to walk anybody through exactly what that page looks like when it's actually on the site. Any other questions? I'm gonna actually ask, so my team just walked in, at least a couple of them. So I'm gonna ask, so Joe can probably help you with the paragraph question that you just asked in the back and David here can help you with your migration question. If you guys wanna talk to the mic. What was the migration question? I'm sorry. How did they do that? It was a while ago. So the way we do it is just have the migration set and tested over and over again on our dev environment.  So we just had them continuously making content and we would just pull the, right before the prod migration, we would pull the final data set and go from there basically. Do you wanna repeat your question about the paragraphs? We can do it more in a second. The paragraph is actually easy to rearrange all the number we can do in paragraphs. It's the big block of content and you maybe get one and a half on a page or they all disappear up and it's really hard to read it. I was just in a bot earlier and that would take me points if you almost had them trying to collapse them all. I was wondering what you used to collapse them all. Sure. I think it was an option actually within the paragraph type we were creating them. There was another module. It's paragraphs extra features or something like that because it adds some defaults and let's just add some default settings for the paragraph types. And that might have been the one we used so we could say we start out with one specific paragraph type by default. Everything starts with a single text block by default and it starts flashed or expanded. The module was called off. It's something like paragraphs extra features or something like that. Any other questions? Go for it. It was a challenge and so we'd have, we usually had, like I said, sprints from about a week to a week and a half. We tried to engage them as much as possible so that they were as included in every meeting that they wanted to be included. What they chose not to in this particular case, they chose to primarily be included in a post-sprint review meeting where we'd say here's what we accomplished this week. We met nine of our 10 goals in this particular sprint. These core configurations are ready. We were here on the migration strategy. We're here on the CDN strategy. And that's how we essentially coordinated with them over the period of the three months. Is that sort of the answer you're looking for or more detail? I don't think there's any magic secret. There is in a magic secret. But they were a wonderful client. Yeah, I mean, they, you know, that's where I went into that slide about the intangibles and the anxiety. And I think part of that was solved just by transparency and part of that was solved by the attitude that we had, which was, you know, we're on track, we're fine, we've been here before, we can do it again. We've launched 505, 550 websites over the course of 12 years, you know, while the requirements may be challenging, they're not by any means impossible. And I think that also rubbed off on their project manager and their, you know, their marketing people that were, and some of their technical people too. So, you know, I'd say it's a combination of that process plus the sort of psychological component. That's a great question because, I mean, it's great for the developers and it's great for me. Right. Yeah, there's no question in any of our minds and we've certainly explored alternative PM solutions that are different from Riem and perhaps more user-friendly from a client perspective but haven't made that transition yet. So, you know, I think it was probably more their technical people and their engineering team that were using RedMind more than their marketing people and their PM people. I do think it probably on the whole poses a bit of a hurdle, as you say, for less technical people or people that are looking for information displayed in a more convenient manner. I think one workaround that we do is we try and maintain very well-organized wikis, both in terms of up-to-date and in terms of navigation. So, if I were to show you a wiki or even a brain-sharp wiki, you know, it's very easy to navigate from the main section of the wiki to dive into a specific section of content types within our core configuration section. Not only that, but pretty much all of the documentation of the whole project is in there and it's all pretty easily to navigate to. So, we try and overcome that. Yeah, exactly. We try and sort of have our own approach within RedMind so that it is a bit easier to use and it does vary from client to client. So, some that are more comfortable or maybe have used a similar system in the past, they do jump in there and they even maybe write some of their own tickets if they see something and others, you know, they're much more reluctant to do so, you know, their technical knowledge is, it's more intimidating for whatever reason. Sure. Do you guys recall anything? I don't think there were a lot of features that we had trouble with. You know, I think that migration, sorry, go ahead. You know, I think the main challenge was the one I listed earlier, which was the migration just because of the very proprietary way that Cycor stores that data. But beyond that, in terms of the way that the actual pages are set up, there wasn't anything terribly troubling. The main thing was, how do we replicate or generate a system that's easy to use as far as CMS that is comparable to both their old design, which we were originally going to use prior to being told, hey, by the way, there's a reskin coming, hey, there's a redesign coming after that. So, we needed a system that was flexible enough to account for that, and that's where that paragraph's module was selected to help us through that process so that, regardless of whatever the design solution was, we had a system in place that could do what they needed to do. Anything else? I think they actually had a lot of that. So, they shared with me, but I've got a 40-slide presentation of how they were debating that choice internally. And I think they went through probably, it was probably a very accelerated research, but it was still pretty thorough. Like, I was surprised when I saw it, and I only saw it far after the fact, I only saw like a week or two ago. So, I think most of that was handled on their end, their decision-making process, but there's probably information in those slides I'd be happy to share with you. In fact, I'd probably pull up that presentation if we really wanted to take a look at it. Sure, we can do that. Anything else? Alrighty, well, thank you so much for your questions and your interest in this. We're gonna be downstairs and around. If you guys have anything else you'd like to investigate, I'm happy to walk to the site with anybody. I'm sure our team would also be happy to share their thoughts if you've got any more technical questions because I'm just a lowly project manager and, you know, when it comes to fancy stuff. I'm just gonna pass it off, so. Yeah. Okay, thank you so much, guys.


Hi everyone, I'm Lucy. So I'm really glad that there are actually two relativity talks in this session because relativity is all about space time, right? So that talk was about time and this one's going to be more about space. So here's a question that I asked myself a while ago. So if you took a photo of an object moving at some velocity near the speed of light. Would you mind taking the microphone? Yeah. Thank you. So here's a question that I asked myself not a year ago. So if you took a photo of an object moving at some velocity near the speed of light, what would that photo look like? So if you want, you can actually just do the math or you can get a computer to do it for you, which is what this is about. So before I get started on that and talk about what is relativity and so on, let's just talk about how computers render 2D images of three-dimensional objects. So before we even talk about computers, I'm just going to talk about pinhole cameras. So the way a pinhole camera works is that you have this box and it has this pinhole on the front and that's the aperture where light goes in and on the back you have some photographic film. And if the light rays coming from this object are at the right angle, they go into the aperture, they strike the photographic film and that's how you get this image. So it's sort of like a geometrical setup. By the way, if you're getting a sense of deja vu from looking at this tree, it's from the slides from yesterday. It's like a domain image. It's good. So ray casting is this algorithm in computer graphics that sort of simulates the same process. So what this is is that if you want to generate this 2D image, you can have the same geometrical setup. If you have this geometrical setup, what you can do is you can basically simulate the light rays that go from your simulated pinhole camera to the 3D object. And this is what you do if you have some tree or something in a video game and you want to render a particular two-dimensional view of it and that's how you get this pixel array of colors over there on the right. So let's take a slightly closer look at how this works. Okay, so for each image pixel you define a ray in three dimensions which starts at this pixel and passes through this pinhole. The way that you do that is you can just define these two points and two points to find a line. I put my aperture right at the origin. And the next step is that you can compute the point where this ray intersects the 3D object. This is basically a geometry problem. And this final step, so this is a really sort of simplified view of what ray tracing is, you know, I'm not going to talk about shadows or textures or shading. Basically what you do is you just set that pixel color equal to the color of the 3D object at that point and that's good enough. And from that we can like render this picture. Okay, so that's all fine if your tree isn't moving. What we want to talk about in general is like what happens if this object is moving. So specifically if your object is moving at some significant portion of the speed of light then it turns out that the finite speed of light actually really matters here. And to describe exactly what's going on we're going to need to do some physics. So this next section is going to be about special relativity. So special relativity is this physical theory that describes space time. And it's got these two postulates from which in principle you could derive like the rest of the content of relativity. I'm going to talk about these two postulates in the context of how they're going to be useful to us. So the first thing is that the laws of physics are the same in all non-accelerating reference frames. What this means for us is it's basically sort of a statement about symmetry. So let's say that you're on a train and it's moving and your friend is on the platform and it's not moving. So from your friend's point of view the train is moving forward and you and the train are moving forward but from your perspective and your reference frame you and the train are both actually still but your friend on the platform is moving backward. And what this says is that neither of you is more correct than the other physically speaking because both of your reference frames are equivalent and neither is privileged over the other. The second postulate says that the speed of light in a vacuum is always the same for all observers regardless of the motion of the light source. This seems pretty innocuous but this is the thing that's going to lead to some non-classical and possibly counterintuitive consequences for how different observers experience space and time. So I have a little thought experiment. I think for basically like historical reasons every thought experiment about special relativity has to involve at least one train so I hope you guys like trains. So you're on a train. In your reference frame the train isn't moving and let's say you like turn a flashlight on or something just for an instant at the exact midpoint of the train and so what's going to happen is that this spherical way front of light is going to expand outward symmetrically and then it's going to fill up the entire train and the light is going to reach the front and the end of the train at the same time. So now let's look at this from the perspective of your friend who's on the platform. From their reference frame the train is moving but it's the same physical setup so you turn the flashlight on again at the midpoint of the train but here's the thing that second postulate says that the motion of the train which is the light source doesn't actually matter from your friend's reference frame the light is still going to spread out in these concentric circles. Okay so the light now reaches the front of the train after it already reached the back. So what this means is that you and your friend actually disagree on whether the light reaches the train at an end point simultaneously. You think it does your friend says no like the light reaches the front after it's already reached the back but you're actually both right either of you is more right than the other. So more generally speaking different observers can actually disagree on various things about space and time. First of all as we've already seen they can disagree on whether two events are simultaneous and hopefully that will make the next two things seem more plausible even though you know we haven't fully gone into it. Different observers can also disagree on what the length of objects are. So the faster an object moving the shorter it gets. In your reference frame if the train is a certain length in your friend's reference frame from which the train is moving it's actually going to be shorter. The other thing is that time intervals can also be disagreed on so the faster a clock is moving it turns out more slowly it runs. One thing that's important to note here is that these are actually geometric properties of space time. This is nothing to do with cameras or human observers or anything like that. Let's make this a little more quantitative. So what it basically said amounts to the statement that for you and your friend on the train you basically have different coordinate systems and the way that you convert between these coordinate systems is that you do something called the Lorenz transformation. This is a linear transformation of the coordinates. If the train is moving in one spatial dimension which we'll call X and not this other time dimension which we'll call T and so this is like a 2 by 2 matrix that defines this coordinate transformation and it might be easier to see this if you plug in some numbers. So if the train is moving at 60% of the speed of light which means this parameter beta is 0.6 then this is what that matrix looks like essentially. And more generally we don't just live in one spatial coordinate we actually live in three. So a more fully general formula if you have three dimensions or something you know two observers moving co-moving in three spatial dimensions then you just have this bigger 4 by 4 matrix with T and XYZ. So now that we know about special relativity we can get back to this ray tracing problem. So this is just to review that same algorithm that we had before it just has these three steps. It turns out the modifications you need to make to make this relativistic are like not actually that difficult. So here I've just bolded all the parts that actually changed from the last slide. So for this first step it's basically the same except there's some points of clarification. One point is that when you're defining this ray to start out with that you're casting you define it in the cameras reference frame. And also these endpoints that define the ray you're going to have to make them into 4D because things are happening in time. But all of this is pretty straightforward so far. The second step here is the actually new thing. And what you have to do in this step is you have to transform it from the cameras reference frame to the moving objects reference frame. So all you have to do there is just apply this 4 by 4 matrix transformation. And that's basically it. The rest of the steps are the same. This third step which used to be the second step in our old algorithm is computing the point where the ray intersects the object. But since you already did the transformation both the ray and the 3D object are in the same reference frame. So you can just compute that intersection geometrically like you would before. And the fourth step is also the same. So let's actually see some pictures. So here's what you get if you just ray trace this cube. You're looking straight at one of the faces. The cube is not moving. And so let's say you know this cube is actually moving either to the left or to the right across this slide. Add some appreciable fraction of the speed of light. So we were just talking about length contraction. You know we expect this cube to get compressed in this direction. You're probably going to expect it to look something like this. And since this is an accurate physical representation of what the cube is doing when it's moving to the left or right but here's the actual like output of that ray tracer which I just took it a bunch of different time slices. This is a cube moving at 60% of the speed of light and it actually looks rotated. I haven't rotated it or anything but this is actually just what it looks like if you take these pictures at these time slices. So the question is why does it look rotated? It turns out that there's this visual phenomenon which is called Tarell rotation. And what's going on here is that because you have a camera that's it's actually taking all these light rays and light signals from the back of the object take longer to reach the camera compared to light signals from the front of the object. So objects appear to be rotated. If you look at this GIF then you can see that this bottom parameter here is what fraction of the speed of light you're moving at. And as you move faster the cube compresses more and more but also the apparent rotation angle becomes more and more extreme. And so the interesting thing here is that you can also do this with a sphere. And I've put in just a still shot of what you get if you do this ray tracer thing on a sphere. And it turns out that moving spheres always appear to have a circular outline. And this is because these two effects both the actual physical length contraction and this visual distortion of Tarell rotation actually cancel out always. And it turns out that there's actually some interesting math behind this. It's related to the theory of conformal mappings which are a type of mapping that always preserve angle and circles. And so the last thing I have for you is just some historical tidbits and why I find this interesting in the first place. Special relativity was discovered by Einstein in 1905 but Tarell rotation was not widely known for a while. It was only described by Tarell and Penrose in 1959. So that's a couple decades during which this effect wasn't widely known. And I think you can actually even find textbooks where this optical distortion wasn't talked about. Which is fine. This is not of extreme scientific importance but I think the interesting thing here is that now anybody with access to a computer can write a relativistic ray tracer and if you do that then this interesting physical effect just pops out at you. So basically in general you can actually use computers to visualize and understand and explore the physical world and that's what I find most interesting about this. And that's all I've got. You can look at the ray tracer code on GitHub and I've got some references if you want to look at that. Thanks.


Diolch yn y bwysig ac yn dechrau a'r Afrif. Dwi'n golygu ar drosio â gynnig o well yn y Cyfrifatwr Cymru yw Nidrwy. Gyda'r cyffredin Gweinwyr, yn y cyflawn ac yn niroddiad, ac yn gweithio y cyhoedd gwneud yn y pryd y Cyfrifatwr Cyfrifatwr. Bydd y cyfrifatwr tynnu dechrau. Ar fy enw yn cyrraedd yingodau ar y mynd, ac beth y peth yn gweld mynd i Edym Padg, Maen nhw'n wneud mewn cyfrannu. Mae gwybod ei ddechrau sydd wedi gweithio gyda'r Gwmeneithio Bancasol yn cyfrannu cyfrannu Llyfrgellau Llyfrgellol. Mae'r gwybod ei gweithio cyfrannu sydd wedi'i gweithio gyfrannu Cymryd yn gweithio mewn cyfrannu. Fe ydych chi'n gwybod, mae'r gwybod erbyn gweld, ac mae'r gwybod i'r gwahoddiadau o'r cyfrannu ac yn gofynol, felly o'r Lai Rwagau, yw'r MDE AQ technology management services. Wseny, rydw i ddweud yw'r gweithio? Thank you, it's my pleasure. No no no, so quickly, I'd like to show you thoughts on the consent of the Apex Bank asking that the E nair of Wallet or the payment system should be embraced by traders. That's on the one hand. Okay, thank you. So like usual, I can see, let me use the word policies should be sorted at this point in time. Mae'r ddweud y llyslywyr yn gwirio ar-doedd ar gael gwasanaeth hynny y bydd y cwestiynau y bydd ymgylch i'r llyslywyr yma, sylwyr mewn gwirio a'u ffordd. Yn y gweithio, yn dweud ychydig sydd y gallwn ni'n gweithio'n llyslywyr, ychydig y gallwn ni'n gweithio ychydig a'u ddweud. The bankers community here, they trained their best. However, the fastest moving way to ensure adaptability of policies like cashless policy that has been proven that I am seeing in the industry today is to agent network. But today, this same agent network are people that are not kind of just on paper considered as an important part of the financial ecosystem. But when it comes to implementation, they are not really carried along, they are not categorised, they are not really engaging, right? And again, it's not just about the bank. I think another way we can see the digitalisation of financial services in Nigeria is the adoption of all this kind of innovative way the ffintechs have gone about it. But today, I don't see any ffintech given talking about email. Particularly, the bankers committee sensitising market women and men were very explicit. So it's the ENAR platform, the ENAR. I'm sure that you are very in the know of this particular introduction and innovation as to the financial economy of our country. So I'd like you to speak to that one. Do you think that there's a lot of sensitisation? Do you think that there's a lot of capacity in that particular regard when you talk about the ENAR? Exactly. So what I'm saying is, yes, is about the approach of the sensitisation and the adoption of the solution. I'm trying to lay a basis where you see the adoption of other financial solutions, which is digitalised. If the same approach is used, I believe it's good. However, the bankers committee goes from a way, and when you look at agent networks, if agents are actually carried along for the ENAR sensitisation or ENAR adoption and music, they use their integrity, they use their influence to explain at their own languages at their local places, to explain and let people adopt the solution. But this set of people are people who are not duly carried along to encourage the adoption. And I keep saying for me, if we want to get things right, we need to understand the working channel and include this working channel to ensure we get good results in good time. Going forward, Nigerians are scared, and you have something to give them confidence to be able to say, this is what we want to go next. So, just still in the light of that conversation, as a country, do you think that we have what it takes, infrastructure, the awareness, favourable policies? The list is almost endless to enthrone an efficient, cashless society. Not limited to the ENAR now, but we're saying you are going to tell market women to embrace all the channels of payment, the POS machines, you also need to understand how favourable the prices are for them to accept it because it's not free. So, I'm saying, and comparsing, do you think that we have the capacity, the technology, the infrastructure, whatever it takes to run, I mean to say we're a cashless society? It's a good policy, but we are not yet there. When it comes to infrastructure, we still have a long way to go. We can see that within January to March, where this cashless policy was really hitting hard, even banks are filling. And another issue is how do we undo a centralized issue resolution system, where it makes it easy to address. We still have pending issues, as we speak, in terms of this cashless way. So we are not there, we are in terms of infrastructure, in terms of the orientation, in terms of the understanding, we are actually not there. There is still more to work to be done. So beyond the policy, we also need to look into other factors like technology, which is not well-grounded. Capacity, you know, technical know-how. You have people, you know, human capacity development, infrastructure capacity, and a lot of things needs to be looked into. We are not yet there. There are still a lot of ways, a lot of things to improve on to ensure this cashless policy or any other means, alternative means of payment is going as expected. So let's take it from that point on. What are the things that can be done to embrace this cashless policy? What exactly can we do? You have said that there are a lot of things that can be done. What are those things that can be done for us to say, hey, we're a cashless nation? So first of all, we need to work on capacity in terms of technology. The technology infrastructure we have in banks today are not readily welcoming for this kind of policy. Secondly, you have a women load of traffic on transactions and they can't handle it. They have to scale up and they have to do a scale up structure that if tomorrow they are going to extend, they should be able to accommodate that. Second, we need to also work on human capital development. We have a lot of people in the sector right now who have little to no knowledge of what they're doing. It is very, very necessary. We address that. Thirdly, issue resolution has to be prompt. You know, we have to centralize issue resolution where it is not like you send money from one entity to another and the other entity is claiming not to have received that money. However, the money is in that entity's position. You know, there are a lot of issues around there. So who do you trust? So is mistrust? Who do you trust? Who is telling the truth? Who is telling the lie? So that is knowledge gap. Then channel of orientation has to also be very, very defined, you know, and understand what works and what don't work. We have over 50 million engineers who are not, who do not have bank accounts, who are not banked. And these over 50 million people are the decider of the economy. You know, these people, there are ways you cannot just do formal, formal approach to them. You have to find a way to do informal to formal approach for them to, you know, be able to end the trust, have your understanding, and we have a better financial system in terms of cashless or cash economy. Well, Useni Olair Wajir, thank you so much. We have to let this go at this point in time because we need to join the newsroom at 9 o'clock for the news group. We appreciate your response this morning on the show. We have been speaking with Useni Olair Wajir, who is the MD of the HAQ Technology Management Services right here in Nigeria. Thank you once again. And that's the size of our conversation this morning on the show. That's the breakfast. We will return tomorrow. The lineup would be interesting. Now, and if you missed that on any part of it, we ask that you, you know, follow us on different social media platforms on Facebook, Twitter, Instagram, and subscribe to YouTube channel at Plus TV Africa, Plus TV Africa Lifestyle. You can also use that also on, you know, our YouTube channel as well. My name is Messi Boko. Have a fantastic morning. Thank you.