RX 24 - New to Rock "Development" - Daniel Hazelbaker

Transcribed Content

Welcome, everybody. We're gonna get started here with, new to code development. Daniel Hazelbaker will be presenting. If you can't see in the back there, you may wanna move up because there there will probably be some code on screen. So just keep that in mind. If we have enough time at the end, we'll do a q and a. If we do that, then just, raise your hand, and I'll come by with the microphone so we can capture your question. Thank you. Alright. Good morning. Can everybody hear me okay? Yep. Alright. So this is new to rock development. The subtitle is really the more important part. It's not just about writing code because we want to kinda we wanna give everybody this idea that there's more to development than just writing code or being a programmer. So I said, I am Daniel Hazelbaker. I'm a software developer. I've been working at Triumph Tech for about four or five years and before that worked at churches for twenty years. So I do have a lot of experience working with churches. So why are developers needed? And this is somewhat a personal opinion but I think it comes down to customization. Organizations, churches, they want to customize something whether it's a software process or a paper process. They need something more or something new or a different flow of how it works so they need to customize it. That might be something as simple as the way something looks or behaves. In your rock instance, you might have wanted just to change the color theme to match your branding. That's a customization that would be needed. Automation of common tasks. If you've done anything with workflows or seen workflows, you know, that's another customization. Even finance software, somebody didn't just come along and say, hey, we should build this thing called finance software just because. There's a whole history of paper based finance that the software is built to replicate and that's a customization that's to make it faster, easier, more productive, less error prone. And then finally, also better insights into the data. Rock, other systems, they have a lot of data many times that you don't even know is there. So, figuring out how to get it, how to display it in a way that's helpful. If you just give them an excel sheet of all the data, probably not as helpful as if you can present it in a way with a time chart or pie charts or things that let them quickly grasp what the data is actually showing in meaning. So, what are some of the ways we can customize Rock? There's quite a few. There's Lava, SQL if you're into more database access, HTML and CSS, Workflows will let you customize, plug ins, data views and reporting, the dynamic data block, the API access and obviously some c sharp will let you customize. I would say most of the customization happens in Lava, HTML and CSS which I translate to mean most of the development that organizations need to do can happen in Lava, HTML and CSS. There's a lot you can do with just those three things to customize your Rock instance and even add new features. A lot of customization can also happen in plug ins and workflows. Both of these kind of act as micro apps. They're a kind of a prepackaged flow of something that you just, once it's installed and set up, your staff just uses it over and over again. And obviously, can do Direct SQL and API. These are more low level along with C sharp, but they give you access to things that you wouldn't normally have in the user interface pages, blocks, etcetera. And then finally, of course, have C. This is what we commonly think of as development, but I would say all of the things you see on the screen really qualify as development. They all let you make rock better, give more information to your staff, even customize the experience, make things faster, better, cleaner. So, plug ins, if you're not familiar, you can install them from the Rock Shop. We're not going to really go into detail into a lot these because it's giving you an idea of what's out there, what's available for development type stuff. Plugins are essentially something that other developers have put together often with C Sharp code but not always. They often require some configuration but they're mostly ready to go out of the box. You might need to set up, you know, some default email templates or other things like that that go with them to make them work with your organization. But they generally work just out of the box, you know, maybe spend ten minutes getting them set up and then you're ready to go. Plugins can provide additional features as well as entirely new things. So, communication providers for SMS gateways, email systems, those can be installed by plug ins. Financial gateways for giving event registration payments that's done by plug ins as well. And then some plug ins add entirely new features to Rock like managing your facility and scheduling rooms and locations. Data views and reports is another common one. This is more the output side, like looking into the data. Data views provide a phenomenal way to get to that information so that your staff knows what's there. And reports let you display that information in a way that's probably a little more helpful than what they would otherwise see with just a plain data view. These are again two very important things to have in your developer toolkit essentially of, sure, you could figure out how to write SQL to get to all this data and query it, but data views is going to be much faster, much easier and not run the risk of breaking when you upgrade Rock and something changed in how the data is stored in the database. Workflows, as I said, is a very powerful customization tool. You can do, I mean a lot of stuff with workflows. I think somebody long ago wrote a game in workflows just to kind of play with it, experiment, figure out what it can do. There are workflows that people built for hiring new staff, for staff leaving the organization so they know all the checklists that need to be done. Position requests to request a new position be created for the organization. Sometimes even signing up for events might start as a workflow to gather initial information and then send them over to the registration or decide which registration they need to be sent to. And then SQL is an option. You don't need to worry too much about what the actual SQL is. That's just an example. But that is a more powerful way to, you know, do this development process of getting into rock without having to write C sharp code and build your own blocks. Related to that, while not really a development thing, is the model map. If you're doing any development type stuff in Rock, whether it be Lava, SQL or C, you want to get familiar with this block. It's in every Rock instance pre installed and it really tells you how everything is related to each other. So, all the people records, how they're related to groups, how they're related to campuses and so on and so forth. What data's available on them. So, it's a very helpful tool that you'll want to get familiar with. Lava, and specifically Lava entity commands, also let you do a lot of what we traditionally think of as a programming theme without being in C Sharp doing programming. You have all your if statements. You can access data from the database. You can filter the data from the database. Decide what to do with it. How you want it to display, what you want it to do. Very powerful functionality. So, how do you access the data in Rock? There's a couple layers to this that we'll go over. The first one is basically what we would call the data layer. So, that is the objects in the database, so the people, groups, campuses, financial transactions and other things. There are, I want to say, over 200 of these object types in Rock. So we can store lots of different kinds of data. Then next we have a set of objects that help in accessing this data that we call the service layer. This layer would be what lets you read and write the data and perform calculations. These calculations might be mathematical such as what is the total transaction amount for this financial batch or it might be more logical calculations like I want this person's full name. Well, we're going to take the nickname, the last name, the suffix and put it all together for you. The service layer provides a lot of these features so that you don't need to one, so that you don't need to know how, and two, so that it's all consistent. So that when, whether it's something that the core team has written or you're developing or you're getting from plug in, when it displays person's full name, it will be the same in every spot. So consistency is something that we strive for. A lot of the service layer stuff helps provide that. And then finally, we have what we call the Rock context. That is essentially the actual direct database access. Now, unless you're in C, you will probably never use the service layer or the RockContext directly. You will probably always work in the data layer. So even in Lava when you're using entity command, you're not directly talking to a service layer. You're just saying, I want all, you know, people objects that match this filter. Under the hood, it's going to do these bottom two layers for you, but you just have to worry about the top layer. So, again, unless you're doing deep programming, you kinda don't need to know about the other two, but it's helpful to recognize what they are when you hear another developer mention them and you're not instantly lost at, well, what is this rock context thing? So just kind of know it's there. Okay, but sometimes you really want to write code. I would say need, but you know, sometimes you want to write code. There are three, really two, but kind of three languages to do that in Rock. The primary one is C sharp, that's what all the server code is written in. Then we also have TypeScript, which is essentially JavaScript for those of you that aren't deep into programming. TypeScript lets you write it in kind of a standard language that will work on multiple browsers, and then it will kind of compile it down to something that's a little bit little bit more understood by all browsers rather than you having to nitpick and figure out how to do it. And it provides some additional things that are nice for the programmers. But this would be the stuff that you would get into if you're wanting to create create a plugin. So if you're you're trying to make something that's reusable, such as creating a plugin, you're going to probably want a, you know, code of some kind. Lava shortcodes are also a great way to do reusability because if you just need to use the same Lava shortcode but pass a different group ID, that's also a great way to do some reusability without having to get into deep code. Another reason you might do this is to create a feature reusable for other organizations, whether as a plug in or just something that you know, send them through email to share. You might need to do code to make that a little bit easier. Sometimes a block setting is a lot easier than saying here's this lava and SQL and go in and change line 37 to this. Sometimes you just say, oh just go to the block settings, hit the group picker and pick your group. And then another big reason you might need to do code is if you're adding new entities into the database. Again, entities like a person, group, financial batch. If you need to create some new thing to hold your data for whatever you're building, that would need to be done in C. So what makes up Rock? This is certainly not a comprehensive list. It would take a really long time and a really tiny font to list everything that makes up rock, but these are some of the big pieces. Blocks, obviously, is a big piece of rock. Pretty much everything visual in rock is powered by a block. The cache is a big piece of rock and this is again more of a low level c sharp kind of thing. You would not believe how many times rock needs to know the name of campus one or campus two or campus whatever. I think I looked once on my, just my local dev instance while I was doing some testing and it was tens of thousands of times in one day that it would have needed that value. So the cache lets it say, well I've read this once, I don't need to go back to the database because that's slow. I can get it instantly out of memory. And when you have one person using your Rock instance for development, it kind of doesn't matter. It feels fast. You deploy that to production and suddenly you've got 10,000 people hitting that page, that little slowdown adds up real quick. So the cache is a big piece of what makes Rock responsive, snappy, not feel like it's slow, and also not requiring you to bump up your server instance beefier than it needs to be. And then we have components. This is a bit of an umbrella term, but a component a basically a pluggable piece of rock. So we will write a basically an empty hole in rock and say a component can provide the functionality to fit that hole. So your financial gateways is a component. One of those things. We said, here's the contract that a financial gateway needs to follow to work with ROC. And you install a plug in that says, great, here's the financial gateway and you're up and running. A small list of some of these components, achievements, badges, communication transports, financial gateways, following events, following suggestions, media accounts, file storage providers, universal search. These are all components and things that can be built, which means if you have a email provider that has a custom API that can't be used currently by Rock and you want to use it, you can build a component that talks to that service, also talks to Rock to say, oh, here's the email data. Great. I know how to pass it on to the provider. That would be a component that you would build and install in Rock. Data filters. These are kind of like components, but a little bit different in that You can go to a data view or build a data view and select, you know, any type of person and then each filter that you add and you want to say, you know, where last name equals Decker, last name is a data filter. So all those things in that list box that you see are data filters that can be added to. You can say, we want a new data filter that behaves a slightly different way or adds a new feature or filters on something that can't be filtered on currently, you can build that and suddenly you can make use of it in Rockin DataViews. Very similarly, data selects. So data filters are on the data view side. Data selects are on the report side. So again, you build a report and you add a column and then you say what should go in that column, that dropdown can be added to by a plugin. New plugins can add new features of what goes into the report. Entities, as I said, if you need new entities, that would be a C sharp code and entities always make up a big piece of ROC. ROC wouldn't be anything without people, groups, financial transactions and so on. Rock jobs. I was pondering this over the weekend of how painful it would be to run Rock if I had to remember every day to run the the Rock cleanup task. If I had to remember four times a day to run the download financial transactions task. So all these things that are automated are for a good reason. They're things that really need to happen but you don't want to remember. You don't want to have a timer going off every few hours reminding you. And jobs again are things that can be added by plug ins. So whether it's a plug in from the shop that you share or just that you build in house for yourself, you can create new job types that new that do new things, provide new functionality to rock. There there's a lot of power in jobs, when you start combining a job with a workflow or something else to do things for you. You know, a job might look at a data view, say, oh, there's three people in this data view, well let's kick off three workflows with each person in that data view to do something, contact them, ask for a picture, whatever it needs to be. So you start taking these pieces and building this bigger puzzle that gives you better functionality in rock. Field types. For those that don't know because a field type is kind of a low level word in rock, when you look at a campus, basically all those UI pieces can be thought of as field types. Not all of them are, but they all provide the same functionality. When you add an attribute, it's like a custom person attribute or custom group attribute and it has that type drop down of boolean number, etcetera. Those are the field types. So there's already out of the box a lot of field types in Rock but you can add more if you need a new thing or new way to handle something. Especially if you're adding a new entity, you're probably going to want a new field type so that it can be selected and then you can do something with that. Workflow actions. Again, this is a huge piece of rock. All those workflow actions, there's just too many to list but there's a ton of functionality already there but sometimes you go, I really wish I could do something a little bit more specific or a little, maybe even a little broader than what's there. This existing action is a little too tightly controlled. I need more control over it. You can add new workflow actions that will do kind of anything you want. Know, sky's the limit really for that. Very powerful, honestly very easy to write. Many of the core workflow actions are probably under 30 or 40 lines of code, I think. So that makes up Rock. And like I said, this is not a complete list. There's lots more things. But these are some of the big things that are probably resonating. Oh yeah, I've used data views. I've used reports. I've used jobs. And how you can hopefully not just use them, but use them together to build something even bigger. I want to do a quick trip through time to help understand where Rock came from in terms of a development framework and then kind of where we're going. Rock is built on something called ASP net, specifically the web web forms variation of it. This was released in 02/2002. It's a little old. Mean, 02/2002 is a while ago. So what was around in 02/2002 when this was released? We had HTML four. That means a lot of things but the two big things it means that really matter to us is there was no concept of audio or video for a web page. So you think of all these sites that have, you know, videos that play or audio was not a thing. It was just there were ways to do it but they were not compatible across browsers. We had CSS two. Again, this is a technical term, but basically that means whereas now you can have one style sheet that kind of covers everything with just a few customizations on each page, You had this tiny little style sheet with lots of customizations on each page. We had GeoCities. Does anybody remember GeoCities? That, I am so glad is gone. Twitter did not exist. Things like Twitter did not exist. We didn't have this concept of constantly getting updates on the web page. Over half of Americans still use dial up at 33.6 kilobits per second. For those of you that don't know what that means, that is point zero three three megabits. That is very slow. So when I say we didn't have video on the web, it didn't matter. We couldn't have used it anyway. We had Netscape seven. Netscape doesn't exist anymore. We had Internet Explorer six, that doesn't exist anymore. Rest in peace. So what's new since then? What has been added to the web environment that affects us since 02/2002? IPhones, Android phones, new. We did not have a concept of, oh, let me pull out my phone and take a look at that web page. That's all new. HTML five, new. Again, that added a lot of things but the big things were added audio and video support. Google Chrome, I believe that's now used by 92% of people in the world. That didn't exist when our framework was first released. Web sockets. This is another technical term. This basically means real time communication between the browser and server. So if you've been on Asana or something similar where a colleague maybe in another state is typing into it and you see it filling in as they're typing, that is web sockets. That is a new technology that did not exist in 02/2002. Multi touch on web. We didn't have that either. Even when the iPhone was first released, it did multi touch because it would respond to you zooming into the page but it did not pass it along to the page. You couldn't respond to it and do something yourself. One case where this is useful is when you upload a picture in most sites now, you can now use your finger to zoom in, rotate, all these adjustments to the picture. That's what this multi touch lets you do. TypeScript didn't exist. All we had was JavaScript, which meant we would write some script, we would deploy it, we would test it, and we'd go, oops, that doesn't work because we passed the wrong type of value. It wanted a number, we gave it a string. That is one of the things that TypeScript does, is catch these things early so that we can can find these errors before we deploy. Xbox One. You might think this is an odd one to put on the list. Xbox One, as far as I know, is the first gaming console that gave you a web browser. And now we have web browsers in our TVs. So when you're building a website, you're not just dealing with a desktop computer, a mobile phone, you also now have to deal with, you know, potentially deal with gaming consoles, televisions and other set top box type things that have browsers built into them. Drag and drop. That's actually even newer than I thought. Before this, you couldn't drag a file into your browser to upload. You couldn't drag something from inside the browser to another part of the browser. That just didn't exist. WebRTC. This stands for web real time communication. This is different from WebSockets. If you've done a Teams call or something like that in your browser, that is WebRTC. It allows for video conferencing essentially inside a web browser. That is very new. Web push notifications. Did you know that you can go to a website and it might ask you if you will let it send you push notifications. If you say yes and close your browser completely, they can send you a push notification. It will show up in your, you know, Mac, Windows, whatever notification center and if you click on it, it'll take you back to the website automatically. That is a new technology, very new actually. So, why does this matter? Like, why does the fact that all these things came out after the framework, why is that important? When a framework is built, it's designed for the existing technologies. There is no concept of a web page having video, so that wasn't built into ASP.NET version one. Old frameworks get these new technologies, but usually they're packed in. And these packages never quite fit perfectly. It's an add on. It's, oh, well, found a way to do it, but it's not quite as smooth as it could be. I view it as similar to a church that has been around for twenty, thirty years as a single campus church that decides to go multi campus. Suddenly, the staff structure probably needs to change a bit. The policies probably need to change a bit. How how money is strategically spent probably needs to change a bit. That's not easy to do on the fly. It's not easy to make those changes while you're continuing to serve your current congregation. It would be a lot easier if you could just, oh, we're just gonna close down the church for a year, redo everything, and then open the doors again. But that just doesn't work for you and it doesn't work for these frameworks. They can't just say, oh, hey, great. We're going to just kill everything that is using this and move on. So they have to package in it, which is not as clean. So newer frameworks have come along that include all these technologies from the get go, which means they're smooth, they're clean, the integration works perfectly. Whereas doing it in web forms might have taken 40 lines of code. In this new technology, it takes two. So there's a reason for these technologies or these platforms to lag and there's a reason that the new ones get adopted because they're easier to work with. So, where are we going as rock? Well, we're still going to be using c sharp so that's not going anywhere. We're going to something called dot net Core. Microsoft has actually dropped the core from the name, but because we're still using what's referred to as dot net framework, we're still using the moniker of core just to clearly differentiate between the two when we're talking to staff or other developers outside the organization. We're going cross platform to an extent. Most of this is coming because dot net Core is itself cross platform natively. There's no it's not like we're going, oh, well, let's spend a lot of time and effort to make it cross platform. We're getting it for free. Does that mean we will officially support running Rock on other platforms? Not sure yet. Probably, but we're gonna have to get a little further along in the process to see how hard is it. Is it likely that you'd be able to run a Rock server on Linux? I would say probably. I think that would be our goal too is like if we can get rid of the Windows licensing for searches, that would be a plus. Are you going be able to run it on a Mac? Probably not, especially since they killed their server support, so there's kind of no point. Would you be able to develop on a Mac? I hope so. Like, I think that would be a cool ability to say, yeah, you can develop on a Mac. You'll have to run the server on Windows or something else, but you could develop on a Mac. So, I think that would be a goal of, yeah, we want to be able to get there. Are we promising it? No, not yet. We've got to get further along to see what other issues we might run into. UI agnostic blocks. Meaning, the blocks themselves in rock core, the part running on the server, they don't care how they're being displayed. They don't care if they're being displayed on a web page or the mobile shell app or something else, some future thing that we don't have yet. So, the direction we're going, the goal is to separate that functionality. Right now, all of our blocks because that's how web forms work are pretty tightly integrated with the UI. We're separating that out which is taking a lot of work but it's not going to be wasted work because in ten, fifteen years when the next framework comes along that we want to make use of, now we don't have to touch the server piece. It stays exactly the same and we're just consuming the data in a new UI to display it differently. In the case of mobile shell, that means you have a single block that can be used on a web page or a mobile page. So when you submit a feature request or a bug report for that block, it would be fixed in both. There would be no more, oh, oops, it didn't get reported here or requested here, so we didn't know to do that. Now, not all blocks will fit this pattern because some really just kind of don't fit. They're used too differently between mobile and web or some other platform. But that is our goal. We're trying to get more to that direction. JavaScript UI framework. Basically, this means we want to offload a ton of processing power from your servers to the browsers. So the new Obsidian Grid, if you've seen that at all, has this feature where you just click the search glass, you type something in and it instantly filters and updates the results. There is no communication to your server when that's happening. Today, you do that and it sends the request to the server and then repaints the entire page from the server all the new data, which means that data's coming down multiple times. And your server's doing a lot of work to figure out how to display that page, render it, and send it down. So we're offloading a lot of stuff which will make your servers feel a little snappier than they are now once everything is kind of converted over and moved. Standard field type UI. So if you remember earlier, I mentioned the field types are kind of those UI controls. So a campus picker, a person picker, and so on and so forth. We're building a standard field type UI that does the same thing as the UI agnostic blocks. The field type logic right now is again tightly integrated with web forms. We're working on separating that so that when a new UI thing comes along like Rock Mobile or in the future some new framework in ten, fifteen years, we again, we don't have to touch the server again, we just update the UI framework to make use of all that existing functionality and code. For the core team, that means, again, the next time we have to do anything like this, we're shaving off 70% of the time that we've had to do this time around, we don't have to do it again. For the plug in developers, what that's going to mean is a, your field types will actually work in Obsidian, but b, it means you won't have to do anything with a custom field type to make it work in whatever we decide to add support for. So when mobile shell gains support in the near future for these standardized field types, any plug in field types that adhere to that, you know, that protocol, that standard contract will instantly work. When a new UI framework comes along or a new platform, So we got, you know, a TV is even a platform. When something new comes along that we add support to it, it's a free game. You don't have to do anything as a plug in developer. It just magically works. So that is where we're going. Also, again, that's kind of a high level but that's the direction we're trying to get to. So we have a few minutes for questions.