Have you wanted a chance to rewrite your own history? With Git, you certainly can! We learn that and other amazing tips to supercharge your version control skills. Plus a promising new package to let your Shiny app users make the call on their preferred layouts, and how mocking is not something to dread when you build unit tests interacting with external services.
Episode Links
Episode Links
- This week's curator: Jon Calder - @[email protected] (Mastodon) & @jonmcalder (X/Twitter)
- Hack your way to a good Git history (SLC-RUG May) (slides)
- Introducing dockViewR 0.1.0: a layout manager for R and Shiny.
- Mock Them All: Simulate to Better Test with testthat
- Entire issue available at rweekly.org/2025-W21
- {saperpolette} Exercises (playgrounds) to go with oh (****) Git and beyond, for R users https://docs.ropensci.org/saperlipopette/
- No code data analysis with {blockr} (R/Pharma 2024 Workshop) https://www.youtube.com/watch?v=PQvTQqcmadY
- Prototype Shiny apps in Excalidraw with Shinydraw https://github.com/MikeJohnPage/shinydraw
- Multi-language pipelines with rixpress https://brodrigues.co/posts/2025-05-13-test_rixpress.html
- R/Medicine 2025 https://rconsortium.github.io/RMedicine_website/
- Fonts in R https://www.tidyverse.org/blog/2025/05/fonts-in-r/
- Use the contact page at https://serve.podhome.fm/custompage/r-weekly-highlights/contact to send us your feedback
- R-Weekly Highlights on the Podcastindex.org - You can send a boost into the show directly in the Podcast Index. First, top-up with Alby, and then head over to the R-Weekly Highlights podcast entry on the index.
- A new way to think about value: https://value4value.info
- Get in touch with us on social media
- Eric Nantz: @[email protected] (Mastodon), @rpodcast.bsky.social (BlueSky) and @theRcast (X/Twitter)
- Mike Thomas: @[email protected] (Mastodon), @mike-thomas.bsky.social (BlueSky), and @mike_ketchbrook (X/Twitter)
- Dovahkiin in Jamaica- The Elder Scrolls V: Skyrim - M Benson, Ben Cureton - https://ocremix.org/remix/OCR04390
- Crysis Crystal - Megaman 9: Back in Blue - k-wix - https://backinblue.ocremix.org/music.php
[00:00:03]
Eric Nantz:
Hello, friends. We are back of episode 205 of the Our Weekly Highlights podcast. We usually do this every week, but real life happened last week for both of us. But we're happy to be back this time around for another fun episode to share the latest highlights and additional resources that have been shared on this week's our weekly issue at ourweekly.0rg. My name is Eric Nance, and I'm delighted that you join us wherever you are around the world. And as always, I'm joined by my traveling cohost, but he's back home, so to speak, Mike Thomas. Mike, how are you doing today? Doing well, Eric. Yep. I had a a one day trip to to Kansas, the Midwest part of The US last week, which was a lot of fun, but a quick turnaround that ended up, taking place smack dab when we would typically do the highlights. So no travel here this week and happy to be back on the mic. Yep. Never never feels right without you, so I've decided I had my own, escapades, albeit internal escapades here that I had to take the week off of too. But, yeah, happy to be back here. And just a programming note, I don't know if we'll have an episode next week because then I will be traveling next week. So we'll try to squeeze one in, but if not, then we'll we'll be back the week after. But, we got a fun issue to talk about today. Some really interesting highlights here that have me, both, you know, thinking I need to learn a lot more, and I got some cool stuff to try out. Though it's not a believer at any longer, this week's issue is curated by John Calder, number one of our longtime curators on the RWBY project.
And as always, he had tremendous help from our fellow RWBY team members and contributors like all of you around the world. We've heard Paul request and other wonderful suggestions. And we will lead off with, a fundamental technique that if you're developing anything that's outside of that quick little exploratory data analysis script, Your future you will thank you later if you invest, some time in learning version control, in particular with the Git version control mechanism, which has become synopsis with, many of the development world, so to speak, and software development, but also data science as well.
Mike and I here use Git literally every day for our projects, and we could not live without it. And every time I think I've, you know, I I think I've got a pretty good grasp on some things. And then there are instances where I do feel very humbled based on how well some other people in the community have learned Git even when they didn't come from necessarily a software development background as well. So our first highlight is one of those showcases from a very renowned expert now in this intersection of Git and research software engineering and data science.
And in particular, it was a meetup that was recorded at the Salt Lake City, our user group meeting. And this is one of the top our user group meetings across the entire world, in my opinion. They always have fantastic speakers, fantastic talks. This is, run by, Pazit's own Julia Silgi as well as Andrew Redd. And in this particular instance in their May session, they had the esteemed, Ma'al Salman, who has been a long time both, curator for Art Weekly, and now a frequent contributor just of her daily work that spans our OpenSci as well as the synchro group, which we'll be hearing more about later as well.
And in her, presentation at this meetup, it was a both, presentation and interactive demonstration of be getting better with your history of git commits and a lot more than just that. So I both must confess I didn't watch the entire meetup yet that is on my list to do, but I have had a good, review of a few key sections as well as the slides, which we have linked to in the show notes. And Al always does a wonderful job of her presentation materials. So this is kind of a tour de force of, like, some really core Git concepts that, you know, you may use a little bit every day in in basic ways. But then if you take it up a few notches, you can really help future you immensely, especially when you get to reviewing when things maybe went wrong or reviewing what the heck you did last year in those various commits.
So as I was watching this, there are some practices that I've latched onto with a vice grip, so to speak. One of those is, one of her recommendations right off the top is instead of doing that massive commit of, like, fifteen, twenty files of a whole bunch of line changes and just putting this commit message, like, just get this in before the deadline or get this in before my break. You're not gonna be able to make heads or tails to that no matter what fancy get interface you use to examine that. And so her first piece of advice in this talk is make smaller commits with a focus set of files.
I wouldn't say really matters if it's one file or a set of files, but the changes should be related to each other in some way so that in your commit message, you're very specific about what exactly you're trying to fix. Maybe it's a bug in your code. Maybe it's, a refactor of a CI process. But if you lump that in with a whole bunch of other changes, oh goodness, that that that's gonna be rough to debug and rough to especially in the world of collaboration for your collaborators to see what the heck that commit was all about. So I have gotten better with that. Now again, we all sometimes fall in old habits from time to time, especially when things go haywire. But when I'm in the flow, so to speak, I am making these more nimble fit for purpose commit messages.
And the other part that she recommends highway and I wholeheartedly agree is branching. Branching is the methodology where instead of just being on that single stream of development, you can then separate another stream of development. Maybe you wanna experiment with a new feature. Maybe you have this really critical bug that you wanna fix and determine if you got the fix working before you push that back to your central or main branch. Git branching. Once you get in the flow of that, it is such a time saver and frankly, an effort saver as well.
When if something say doesn't work as expected, you just delete that branch and go back as if you never did anything wrong. And, also, when you wanna merge that into your main branch, having that separate branch as part of, say, a pull request in GitHub or a merge request in GitLab, it gives other collaborators an opportunity to review those changes, maybe even test it locally on their setup. But, again, you haven't touched that main branch just yet. You've got a way to have that separate stream of development, and it is very helpful for experimentation while avoiding making the infamous, say, copy of files that we often did, at least for me back in grad school when I didn't know Git yet. And I'd made tons of copies of my dissertation files when I was experimenting with something. And if I'd had Git, would have been much better.
That's where things and the rest of the presentation is where I start to feel a bit of humble, so to speak, and things I really need to level up on. So this is Eric being a little more vulnerable here in my get adventures, but I'm I'm always of the spirit of transparency here. When things do go haywire and you're not sure where it went haywire in your commit history or maybe you seem to have that file working before, and then you've done, like, five or six commits since then, and then suddenly without you knowing it, you've broken that file or you've broken that script or a Shiny app, and you don't know where the heck it went wrong.
That's where the git bisect command comes in, and this is where you can, in essence, enter a different mode of Git where then you can interactively step back in time to these different commits that you made and get the the you might say the environment of the files at that particular commit as you step back and then experiment with the code, see if things are still working or not. And you kinda go back and back until you found that place where it was working and then maybe go to that commit afterwards and then really start to isolate what you did in that script that might cause things to break. I have only used this sparingly. And boy, oh, boy, every time I enter that mode, I feel really nervous. It's almost like going into the black hole and wondering if you're ever gonna come out.
So one nugget that I saw in this presentation is that, yes, this is for all the maybe the VIM and VI haters out there and hate how you it's so hard to get out of VI. Right? Well, there is a way to get out and get bicep if you get too scared and you're like, just get me out of here. There is a way to exit it out, which I and then we didn't know about very well other than googling it the first time I did it. So that that is something I don't feel I probably shouldn't be so nervous about, but boy oh, boy. The first time I did it, I felt like I was in a a different world during it.
But one thing you'll see reinforced throughout this talk is that there are a lot of nice Git wrappers or, let's just say, gooeys out there that can help you with certain operations and Git, and they are really helpful. But sometimes there is just no substitute for being skilled in the terminal we get. There is some things that any GUI out there just is not gonna have an elegant interface for. Bisec might be one of those things where you just gotta get your hands wet or dirty, so to speak, and get in the terminal to do it. I'll be interested to see if that improves over time. But get bisect is definitely something I wanna practice. And one thing that you also see throughout the presentation, especially in the demo parts, is that Ma'am Elle realizes that it can be really scary to do this on a real project if you're trying to learn Git in these concepts.
So we've covered this before in our weekly highlights in the past, but she's made an R package that's been inspired by a very, fun, reference that she links to in the talk called, oh, beep, get. And it is called, I'm gonna try to say this right, suparlipopet. I probably didn't get that right at all. No nonetheless, not even close. This is a package that you can play with different exercises that that demonstrate these concepts. So I could get bisect, like some of the things we'll talk about later. And you can do this in a very low risk setting because you're gonna make temporary directories that have, like, a might call a borked git repo to let you practice in in your R session and throw this into your favorite IDE, like RStudio itself, like, more recently, Positron.
So you could try this in your preferred environment and get a feel for how things work. So we'll put a link to that in the show notes because it is a very fun package to play with. There are some other concepts here that I've seen used, especially by really talented developers out there that I have not done as much to my liking, such as when you get to a pull request merge, not just merging in all those commits from the the branch that you pushed up, but doing a squash and merge, where then you can consolidate all those, like, smaller commits into one commit that maybe now, again, maybe that doesn't work as well in certain situations.
But if a pull request only had, like, a few commits and they're all related to each other, it might be better for the history of the project to, in essence, squash those into one with a more detailed summary and bullets in the commit message of each of those individual changes. Your mileage may vary, but I have seen that in the past used with great success. Another thing is she makes heavy use of the git amend function, which again is a way to kind of change something you did in a previous commit. Maybe you had a typo in the commit message, so you can just simply amend what you typed in that message.
Other times, you could just add a file that you forgot about. And there are some GUIs that can help with this. So you might be able to use, like, even the RStudio GUI to do this or in positron with Versus code, you know, extension library. There's an extension called GitLens that does a great job with some of this as well as, you know, some of our, utilities like GitKraken, which I like, can help with this as well. So that's a great tip. As well as rebasing, which, again, that's one account I won't say scares me as much as BISEC, but I've always felt intimidated by trying that. But it is a way to kinda like in the squash thing, kind of consolidate certain commits and make the history a bit cleaner, especially if you're really iterating through things. And maybe in the long run, it doesn't have to be that verbose, but you just wanna, you know, make things a bit better, especially when you're merging things, so to speak.
So again, I haven't played with that as much. But again, you got demos in her package to try all this out. So definitely worth the watch. Definitely look at her slides, and she has links to her various blog posts that definitely most of them haven't featured in our weekly before. So it's not the first time we talk about version control, but boy oh boy, it's great to have a reminder from time to time just how powerful this can be in your development journey. So I ate some humble pie with this, Mike. How would you think about her her resources here? Always something to learn when there's a a Mael,
[00:14:27] Unknown:
presentation here. And I'm very jealous of the Salt Lake City, our users group. It seems to be going really strong for quite a few years. They get great speakers, cover great topics. So it's it's a great resource that we have out there for folks who are looking for, you know, live presentations and the community acts aspect to be a part of as opposed to maybe, you know, watching prerecorded things. But this is a fantastic walk through. Git is such a bigger language, I guess. It has such a big footprint of what it can do that maybe you don't realize. And I'm sure even maybe the males of the world still may not know every single little last thing that Git can do because it to me, it it just feels like there's always some new thing that Git can do, some new function it it has, command that it has that, I had never heard about before.
So there's some very, as you mentioned, Eric, I think there's some pretty low hanging fruit, in in terms of additional, you know, functionality that Git has that you may not have known about. The the amend the the Git amend is a fantastic, command in in my opinion. I often find myself making a commit and then realizing that, you know, I may have impacted a few files, but there was one last file that really, should have been changed as well that lines up with that that previous commit message. And instead of creating a whole separate commit for it, I can I can run git commit amend and actually overwrite, if you will, that last commit with the additional change that I want to bring in? So that's fantastic. You can also update the commit message with that command as well if you felt like the message, wasn't encapsulating everything that you wanted to say.
So that's fantastic. Git revert is is another one that Mel walks through, which I think is very useful. And those last two, as you mentioned in some of the GUI tools that we have, the GitHub desktops of the world, the GitKrakens of the world, may be able to do that. But git bisect, which I think is is what Mael may have spent sort of the majority of the time walking through, rightly so, is extremely powerful. Right? But it's it's certainly, detailed to get the hang of. And I think this sapphire le paupet, package, which apparently is French for my goodness or good heavens, something like that. It's like a French exclamation, which if you've ever worked with Git, you've probably exclaimed something like that at one point in time. But it's a really useful tool to be able to try some of this stuff out in a very safe setting. And I think probably as Mel mentions and as you mentioned, Eric, as well, some of this functionality may not be as important when you're working by yourself.
Right? I don't necessarily need to amend a commit message, you know, for myself if I forgot a file. I can just create a new commit, you know, on top of that that previous one. But when you start getting into team data science, this stuff becomes really important. And when you are reviewing codes, submitting pull requests, and other folks are going to be looking at the changes that you've made to the repository and the the Git history that is included in those changes that you've made, you want to provide them with a clear set of breadcrumbs that they can follow to understand the changes that you made and how you got from what existed in the repository to the repository to the fix or the enhancement that you created. And I can't tell you how much more efficient your workflow can be if you have a good grasp of these Git concepts, as opposed to to if you don't. It it can be a tremendous time savings for that code review process and for that collaborative process.
So if you do find yourself looking at some of these Git tools and thinking that, you know, maybe this isn't really that important to me in my current workflow because I'm sort of a solo data scientist on my team. That may be true. But if you do get into a situation in the future where you are collaborating with others, maybe even collaborating on open source outside of your your day job, I would highly recommend trying to pick up some of these additional Git tools that will really make that collaboration a lot easier.
[00:18:53] Eric Nantz:
Yeah. You wanna put yourself as well as, like you said, a team of, you know, data scientists and developers on the best path for success with this. Because one thing I've always learned is that, you know, not to to not to do a humble brag or anything, but when I get on a project of a team, usually, I'm the one that's doing the get kind of orientation first, just because just by by my work, you know, history, I have the most experience of it, other than a couple other people on a various projects, especially when you get to more of the clinical facing side of our data science area in our in our company.
So I'm trying to arm them with resources like what Mel has written here, but also just some cheat sheets and other, you know, tools like these interactive, you know, I mean, it's GUI based editors or frameworks around Git that can help along the way. And they may never need to be as proficient with certain parts of this, but that's where if there's just some attention to detail on at least the basics of this with those fit for purposes, commit messages, branching. And then as we grow into it, learning things like bisect, learning the amend functionality, I think that comes through experience as well.
But we we can expect to be experts right away. So getting them onboarded correctly or say efficiently, I will say that it's always been one of the most requested things I've ever had about, you know, like, say, education or training resources is resources around Git. So what I try to do is just assemble all these great resources from online. These online books that Mel mentions are also great reading as well, and I just try to distill the key points in various resources because there's no way I personally can duplicate what has already been done so well. It's just more of, I think, the practice of it, which, again, her package, I think, is a great way to practice it so that we all come with a foundation that we can contribute, you know, right away, but also not feel so intimidated by this whole get operation. So that first experience does matter.
And I don't know if you'll ever get in Git kind of like the experience we have on the r package development side with things like use this and other packages to just get you up and running really quickly. Get I'm not sure if we'll ever get to that point. No pun intended. But I think we we can definitely get some resources to share along the way, and this is certainly one of them. Absolutely. I do remember that
[00:21:28] Unknown:
Greg Wilson who was, sort of a famous software carpentries teacher, instructor, developer, once famously said on a podcast I was listening to that he has taught probably tens of different programming languages in, you know, these educational settings. And Git is by far the hardest language he has ever had to teach, like head and shoulders above.
[00:21:53] Eric Nantz:
Yeah. I, I can hardly agree with that from my limited experience in teaching this, but we should send some graduations to Git itself. I believe it just turned 25 years old recently this year. So, for those who don't know, Git was created by the author of the Linux kernel himself, Linus Torvalds, as a way to help manage all the kernel changes, and it's still being used to this very day. So talk about scratching your own itch, so to speak, for all of us to benefit. But, he he he had an entertaining interview a while back where he wished he didn't have to invent it, but he there was nothing else out there that met the needs of the kernel development. So we're all we're all beneficiaries of it even if we have some, less than stellar things to say when things go haywire, if you know what I mean.
Well, we're gonna transition now to, one of our favorite corners of the development world in the art community, and that's the space of Shiny and web applications. And in this next highlight, I will admit I got a preview of it, albeit not realizing where this was really gonna go. So a little step back in time with yours truly here. It was in last year during our r and pharma conference workshop series. I had the pleasure of hosting an a workshop by David Grange, Karma Tarip, and John Coon about this new blocker, framework that they used for a client project to help, application viewers, in essence, design a Shiny application of a no code like solution. It was kinda like a gooey editor for a for creating a Shiny app and then sending it to your users.
I was even put on the spot to do some exercise for it. It was a great way to learn on the fly. But throughout all of this, I realized they were doing some really slick things with how they were orienting these different parts of the app and being inserted in different places, be able to move it around. I had never seen anything like this before. Turns out that became a very important functionality and not just as blocker package, but in some other projects. So in this next highlight, we are pleased to talk about a new r package that has just been, released called doc viewer.
And it comes to us on this blog post author by David Grangen, Nelson Stevens, and Nicholas Bennett from Synchro, who we had just mentioned, and my Al was also supporting as well. And the doc viewer package under the, I guess, on the tin, so to speak, it is a way to give yourself these grid like elements, these panels. They can put any type of content inside and have some really neat capabilities to kinda mix and match, move them around wherever you see fit as well as some other nice customizations too. So in the blog post, you guess what? I know David's been a pioneer in WebAssembly.
There is a WebAssembly powered app right in the beginning of the post where you can actually see this in action with a set of about three panels here, one with a slider and a histogram, another with a VIS network graph, and then one with a data table that you can just move them around. I'm literally doing it right now as I speak. I'm just moving them within another panel with different tabs, or I'm blowing it out to a different side of the panel, with its own separate box. Very, very interesting here. And so you may be wondering, okay. Well, how does this actually work?
It is is using a doc view function where you put everything in, and then you put in a list of what they call panels. And in this panel, give it an ID. You can give it a title. And then the content, which, again, can be just a simple string or it can be a shiny type of content, like, say a slider input, like a plot output and whatnot. So again, we've seen they mentioned in the post, they've seen attempts at this in the past with, like, this kind of drag and drop functionality, such as the Dragua, framework, Dragua JS, also Shiny j q u I for wrapping jQuery extensions, and then also the sortable JS library where there's a sortable r package that I've used in the past.
They said each of them work pretty well for certain cases, but they needed something a little more customizable. And that's where they discovered the doc view JavaScript library that this one wraps. So there is a JavaScript library under the hood that if you're just doing any kind of web app, you could definitely tap into. But now we've as our users get to tap into the same functionality that that blocker package I mentioned was using under the hood. So you may be wondering why is this helpful for me as, say, a shiny developer listening here. I've always said you can't please everybody with your user interfaces.
There's always some client or some customer that just is tired of the sidebar layout. Maybe they just don't wanna have that plot be so big and in the in the frame. They just wanna kinda move it out of the way and move something else to get the key focus. Well, instead of creating, like, copies of apps that please, like, individual customers, maybe the doc viewer gives me a way to have one part of my app, maybe multiple parts, where I say, here's a predefined layout, what I think is, you know, a good way to present the data, present the controls. But you know what? If you have a preference, just drag and drop to your heart's content.
One interesting nugget that they mentioned here is that they do have functionality in this package to save the state of where these panels are and to restore it later. I wanna look into this a bit because some of you are aware I am working on a package called shiny state that's wrapping the shiny bookmark. We'll say, I think this is a little different, but I'm definitely intrigued to see how they pull this off. So they mentioned there's a vignette that talks about this, so I'm gonna definitely look at that after this recording. And there is some stuff they wanna work on in the future that the JavaScript library has, such as grid view without drag and drop or collapsible panels. They say they are working on that, but this is early days. They're looking for feedback, and I am definitely intrigued to try this out on one of my future projects, especially in those cases where I know I'm gonna have a few key elements on that on that interface, and I don't know exactly what is the best layout.
Maybe somebody prefers, like I said, that data table front and center. Maybe they prefer a plot front and center, and they want the controls in a more, you know you know, open way or or more larger view. So I'm gonna play it and see what happens, but I'm intrigued by what DocViewer could give us for customizing our shiny user interfaces. So, Mike, what do you what do you think about DocViewer here?
[00:29:26] Unknown:
Nope. This is super cool. It scares me in that it's could be one of those situations where you make an app that contains DocViewer functionality and then all of a sudden, your end users want all the other apps that you provide to them to also be doc viewer, functional if you will. Yep. But, it it's sort of like having a chat interface with your app. Right? Exactly. But I think it's it's really, really incredible. I think that there's a lot of potential here. I really thought that it was, you know, interesting how the the team arrived at at finding DocView after exploring a bunch of other sort of JavaScript tools that we may be more familiar with. They mentioned, you know, sortable. Js, which has an R package called sortable that I use a lot for filtering.
That's fantastic. There's Dragula, grid Stack, but but nothing really, fit exactly what they were looking for in terms of a a nice they call layout manager until they found dock view. And it's very smooth, sort of when you start to drag some of these different panels around, it's it's incredibly smooth. Yeah, I would have expected, you know, maybe one of the first packages that does something like this, at least that I've seen in Shiny, to be a little bit clunky, but it's it's pretty easy. And I think it plays into maybe another concept that we've probably all heard about, which is the idea of, like, self-service BI, alright, that end users potentially want, but is always tricky because I think a lot of times it's it's better to just put something in front of them that's a little more fixed, as opposed to doing the self-service thing where maybe they're not applying a filter that they don't know needs to be applied. But I'm gonna digress from that potential tangent. And one of the really interesting things to me in terms of the the code syntax is how you create these layouts is actually sort of starting with one panel, it's called.
And then the position of the other panels are all, defined with respect to a prior panel that's already been established. So, there's a within this this panel function, which is how you create a panel in the grid layout, there is an argument called position that you can serve a list to. And that list should contain, I think at least two objects. The first being reference panel, which is a different panel that you want to reference and then the section the second, argument there, the second list element would be direction. So if you're creating a second panel that you want to be to the right of the first panel, that list would say, you know, reference panel equals one to reference the first panel and direction equals right. So that my second panel is to the right of the first panel, which I think is really cool. You can obviously, decrease the width or decrease the height of any of these panels. But in situations where you want to set a minimum width, which is what they have in the example here, there's a minimum width argument so you can't decrease it, more than a particular number of pixels on screen, which I think is fantastic. So they've thought through, I believe, a lot of the functionality. I think that's sort of most important to creating these these layouts for end users. And I'm really impressed with what they've put together here with the doc viewer package.
I am most certainly gonna try this one out, in a future app here. And this is this link is going straight to our team's internal Slack channel because I think it's gonna be a hot topic.
[00:33:01] Eric Nantz:
Yeah. And one other area that I kinda glossed over until I reread again is a lot of times when we're starting these projects, we get into that wireframing stage, right, where we're just trying to figure out what are the just the basic components and from a UX standpoint that we want. And we've seen attempts at this a little bit in the past, from Posita, actually, that Shiny UI editor, framework that Nick Strayer had authored, and that can be a great tool as well. But with this, I could combine this with, actually getting to our friends, I think, are, Colin Fay had written a package called shiny ipsum, I believe, where you can have these random placeholders, like a data table, a plot, or or or another rendered output or input. And you could combine it with this doc viewer, and then you've got, like, okay. Here's my initial guess at the u at the UI layout.
Now in this meeting with maybe your stakeholders or other developers, let's just kinda drag some stuff around and see what really sticks, and then maybe we align on that fixed setting, or you might keep it flexible for the main app. So I think wireframe is another underserved area in application development that does get glossed over a bit, but yet is something that the last thing I wanna do is to bust out a PowerPoint slide for something like that. I want something that's more visual and interactive without paying for a proprietary service. So no shade to the Figma lovers out there or anything like that, but I'm I'm cheap. I like it free, and I think this doc the doc viewer, package might give me might scratch my itch on that on that side of it too. So as I mentioned, it is early days with it, but but as I'm as I mentioned earlier, the team has used this quite a bit with that block r package. So I know they've been putting it into a very realistic use case right off the bat, and I am intrigued to see what I can what I can do with this in a future project. And maybe there are cases where you have an app where maybe the majority of the app you wanna key fix, maybe that one module in there where you want to be more flexible.
I wanna see if I can, like, opt into using doc viewer in only one part of an app versus other parts that might still have that more
[00:35:22] Unknown:
fixed layout as a way to gently introduce it. So, again, things for me to try, but I'm intrigued to explore more. No. That wireframing case is a a great potential concept and there are certainly a lot of potential wireframing tools out there. I think this one would be a great one. I know we say no free ads, but I do wanna give a shout out. We do a lot of wireframing in Excalidraw, which is an open source tool that's just really fantastic for quick drawing sketches, things like that. And, there is a pull request out there to merge a new library in Excalidraw. So if you're familiar with Excalidraw, there are certain libraries that have like AWS icons for example that you can import and then you'll have access to using those in your wireframes.
And there is one called, Shiny Excalidraw and it has all Shiny components and there's open pull request into Excalidraw for it. It looks like, let me figure out. Mike John Page. I gotta figure out exactly what his name is on GitHub. It's Mike John Page, and, he's presenting this at the UseR conference
[00:36:32] Eric Nantz:
this year. So Oh. Give it a thumbs up if you see the poll request. I've I've definitely checked that out because I have used XCalDraw in the past as well. I wanna level up a bit more. I mean, having those shiny icons will just make it even easier. So yeah. Great. Great call out there. There's lots of interesting tools out there. And like I said, Doc Fear, I think, is gonna be in my, toolbox in the future. And I dare say the pedigree of the talent behind this package, I've always had a lot of a lot of appreciation for what David Grange and has has done for the shining community and his, previous efforts. So, certainly, it's in good hands as they say.
And lastly, in the highlights, episode today, we've got, another concept, from a development standpoint, especially when you get to, again, either application development, package development, another, maybe ETL pipeline development. You wanna make sure things are working as expected, not just by running code in your session, but you wanna repeat that, especially as you're making changes in an automated fashion. And that is where we have the test app package, which has been hugely instrumental in the automated testing of our packages when you build test functionality, test scripts, whatever you wanna call that.
But there are cases where maybe some of those functions you have in the package, you know, it either is an expensive operation to run or it's using a resource that would be really difficult to just manually keep configuring over and over again. And that's where the idea of mocking and testing comes to play. And no. I'm not talking about what the kids like to do when they think their daddy is talking about some old time concept. Not that kind of mocking. I'm talking about making things seem like they're real, but yet they kinda have a little maybe shim in front of it. So our highlight talking about mocking with Testac comes to us from Muriel Delmote, who is a data scientist at ThinkR. And our, ThinkR has always been a frequent contributor to the highlights as well. And her post is titled mock them all. Simulates a better test would test that.
So what is the motivation here on top of what I said? But let's say you also are building some business logic tests in an application like with Shiny. And maybe you have a piece in your app where the user uploads a CSV file or whatnot, and then your app's gonna do some processing on that. Well, imagine trying to build a test around that. Right? You can't offer using Shiny test two, perhaps. If you're not really interested in doing the interactive experience per se, but you just wanna test that what happens after that upload operation is working as expected.
You want a way to kinda capture that uploading feature without really uploading a file. Maybe you have a test file already in your package infrastructure. Well, that's where mocking comes in and tests that. They have functionality called with mocked bindings, where then you can kind of put in a shim to that function for, say, choosing a file or whatnot. And then you can just give it a hard code of path like she has in this first example here where she has mocked the choose dot files function in base r just to illustrate. So you can use your imagination. That could be used a lot of other ways as well.
And then the part that I've been more in the weeds of, so to speak, is that when your testing involves some kind of external resource outside of your package or app, let's think a system process. So let's think an API or maybe some other resource like that. So this can be also used with, with mocked bindings as well. And in the case of API, she does have an example where she's wrapped the idea of fetching the data from an API using the header package, h t t r. But you could also, again, have a mock binding where you simply give the result of that fetch operation as, like, a list or a JSON file or whatnot.
But I will put in a plug of a package I've had used great with great success, in a recent package I've built for wrapping an API, and that's called HTTP test two, which I'll link to in the show notes, which is a way to give you these mock bindings for for a hitter two or h t t r two, function calls where you kinda run it once, it'll capture the response. And then every time you run that test again, it's gonna use that cache response from that API request instead of hitting that API all the time. So that's a great accompaniment to, technique here. Now last but not least is that there are some situations that that with mock binding or even that a HTTP test two is not gonna help you because there are some functions that really depend on that. They're either very primitive in the language itself or they really depend on the environment at that specific time you run it, such as, say, sys dot time or getting an environment variable.
So you can't really put that in with mock bindings because it just doesn't know how to how to capture that effectively. The workaround, an understated workaround, is that for that function that you're trying to wrap, you put a wrapper function in front of, say, sys. Time. And then you can then do with mock bindings on your wrapper function instead of the base function itself. So in her example, she's got a wrapper function around sys dot time where it's, it it's simply that's all it calls under the hood. But then in her with mock binding, she then wraps her, get current time wrapper on it to just give a static timestamp instead.
So that might be really helpful if you're in a situation of testing in some kind of external environment or system environment where you can't just put in the with mock binding, that actual function itself. A wrapper function may be inconvenient at start, but in the end for testing, you'll you'll thank yourself later that you can put bindings for that. So very, straight to the point post, but I think, the mock bindings is an understated, underutilized utility so that you can, either save some cost by not calling that API so much or, please your IT admins. So don't want you hitting that that system resource all the time just because you're developing a new feature for a package. So really great advice here, and I'm definitely gonna take that to heart in my next project.
[00:43:51] Unknown:
Absolutely. And I didn't even realize, I guess, that, this with mock bindings function was in the test that package. It's fantastic. It's one that I admittedly haven't used yet, but but need to begin using. I think I've tried to do some things like this with the with r package. And I think the combination of test that and with r can be a really powerful one for doing things exactly like what's being discussed in the blog post, you know, simulating hitting an API, simulating a file being uploaded, simulating connecting to a database, things like that, and allowing you to build tests that, right, aren't going to be resource intensive and unnecessarily resource intensive, of the resources that you might be using in production, but still ensure that you're testing your business logic robustly.
So this is fantastic. I I think something that I often find myself doing, especially in my Shiny development, is having to make a change and rerun the app and, you know, upload a file, for example, and continue to do that to test the change. And it's not a huge deal, but it takes time to do that. And I think if I change my workflow, and this may be beneficial for some others out there as well, in that I try to make that change and instead run the the unit test first before I actually open up the app and, try to test that functionality, then I might be able to save myself some time by not having to to boot up the app, wait for it to to spin up, wait for the file to upload, and instead ensure that my unit test is running successfully and maybe that results in troubleshooting a few failures of the test first after I make my change.
And I will probably spend a whole lot less time doing that iterative process of continuing to boot up the app as I develop. So, this is definitely something that I want to bring into my workflow and I'm very grateful for, the the author here to be able to point out this with mock bindings that I definitely knew about in the back of my mind but have not been leveraging enough.
[00:45:58] Eric Nantz:
Yeah. I'm working on an app as I speak that does a lot of AWS processing under the hood, and I do have a dedicated package for that piece itself. But in that dedicated package, yeah, I absolutely wanna combine with mock bindings and this HTTP test too so that I can wrap these API requests, cache them after an initial run so that I can keep looking at these resources. I'm pulling things from, like, object buckets, DynamoDB databases, and whatnot, and I don't wanna keep hitting that Amazon API because, not that it's a huge cost. But if if you if you rack this up over time, it it can it can raise some eyebrows. So definitely caching that, I think, will be will be very helpful. And it does give you another on ramp to something that you and I agree with wholeheartedly when you search again, aspect of Shiny development.
Try to do the majority of your testing on the business logic side outside of Shiny first. And if you can use win mock bindings and to aid in that journey, I think it'll make testing a heck of a lot easier and save your usage of, say, Shiny test two or these other frameworks that are out there for when you absolutely have to do the UI stuff. But the business logic stuff, yeah, try try to use TestDaT for that if you can. And I think you and I are not alone in in thinking that. There are some other great people out there in the community that say the same thing. And what we also can agree on is this issue, we got a whole bunch of other additional resources, and we invite you to check it out as always. I won't give a specific one per se, although it is kind of a plug for an effort later on.
But in my, this three week window where I'm doing, conference presentation, but also I am gonna be part of the Our Medicine conference the week after. And, two guesses what I'm gonna talk about. My latest craze is the intersection of Nix and R, where I will be giving a hands on demo workshop of how I'm using Rix and Nix to do my Shiny app development. But then a couple days later, we have the man himself, Bruno Rodriguez, is giving a workshop on using Rix for Nix and reproducible analytical environments, and he does have a post in this our weekly issue and our additional finds here called multi language pipelines with Rickspress, which is his newer package that's augmenting the idea of targets, reproducible pipelines, but with Nix.
And the biggest, motivation for this is multilingual data science pipelines. The example he has is using R and Python. But imagine you could generalize this to say R and Julia, Julia and Python or whatnot. Anything Nix can do, we're express can do with you as well in the context of r as well. So definitely check that out, and we'll put a link to the r medicine, schedule in the show notes if you wanna check out Bruno's workshop and my, fun little adventures of my, Rick's journey. Kind of an encore for when I did a Shining Comp, but we get to really dive into the details quite a bit on how this actually works. So I'm excited to be a part of that.
[00:49:18] Unknown:
I'm always impressed by, what Thomas Lynn Peterson comes up with, and I think he's in a very unique niche within the R space in terms of graphics and fonts and things like that. And there's a great blog post that he recently authored called Fonts in R on the Tidyverse blog that walks through all sorts of different typefaces and and really a lot of interesting concepts that I don't spend a lot of time thinking about. But when I run into these issues, I am grateful for folks like him because there always seems to be an answer to the problem. So, really interesting one to check out if you're into that type of thing.
[00:49:54] Eric Nantz:
Yeah. Fonts have always been one of those things where I I use sparingly in customization, but they always kinda scare me when I have to go outside the confines of what's included in the system, especially wanna up my game with the g g pot visualization and fonts. So this is a very, very helpful resource to get started on the nuts and bolts of what's really happening. But with the recent advancements, as you said, with the system fonts package, as well as some other great resources, out there for both the visualization and the text representation, side of it, I think it's a great time to up your game, and it's not just for web apps. Right? This is for, again, those static visualizations, those static data summaries.
A new font can go a long way in that in that overall presentation for sure. So great find there. And, again, we invite you to check out the rest of the issue for your other, additional great resources of new packages, other events, and other top notch tutorials out there. So we love to hear from you as well. If you've been enjoying our weekly, one of the best ways to help the project itself is to get in touch with us via a pro request. If you find that new great resource, that new blog, that new package, we always have a link in the top right at rweekly.0rg for you to send that poll request with a template already prebuilt for you. Our curator of the week will be happy to get that merged in for you, to get your impact on our weekly itself. And, also, we love hearing from you in the audience. We have a contact page in the episode show notes so you can send us a fun little message with. You can also get in touch with us on these social medias out there. I am mostly on Blue Sky these days of at [email protected] as well as Mastodon with @rpodcastatpodcastindex.social.
And I'm on LinkedIn. You just search my name. You'll see my random exploits over there. And, Mike, where can the listeners find you?
[00:51:56] Unknown:
Yep. You can find me on blue sky at mike dash thomas dot b s k y dot social. Or on LinkedIn, if you search Ketchbrooke Analytics, k e t c h b r o o k, you can see what I'm up to.
[00:52:09] Eric Nantz:
Alright. And, looks like you got some great content coming our way soon. I'll be looking out for that. And, as always, I've like I said, I'm in the midst of this mini summer conference season, so I'll be sending some posts about what my adventures are there. But as always, we thank you so much for joining us on episode 205 of ROH highlights. And we may or may not be back next week, but rest assured there will be a new episode in the near future. So until then, enjoy your our journeys out there, and, we will see you next time.
Hello, friends. We are back of episode 205 of the Our Weekly Highlights podcast. We usually do this every week, but real life happened last week for both of us. But we're happy to be back this time around for another fun episode to share the latest highlights and additional resources that have been shared on this week's our weekly issue at ourweekly.0rg. My name is Eric Nance, and I'm delighted that you join us wherever you are around the world. And as always, I'm joined by my traveling cohost, but he's back home, so to speak, Mike Thomas. Mike, how are you doing today? Doing well, Eric. Yep. I had a a one day trip to to Kansas, the Midwest part of The US last week, which was a lot of fun, but a quick turnaround that ended up, taking place smack dab when we would typically do the highlights. So no travel here this week and happy to be back on the mic. Yep. Never never feels right without you, so I've decided I had my own, escapades, albeit internal escapades here that I had to take the week off of too. But, yeah, happy to be back here. And just a programming note, I don't know if we'll have an episode next week because then I will be traveling next week. So we'll try to squeeze one in, but if not, then we'll we'll be back the week after. But, we got a fun issue to talk about today. Some really interesting highlights here that have me, both, you know, thinking I need to learn a lot more, and I got some cool stuff to try out. Though it's not a believer at any longer, this week's issue is curated by John Calder, number one of our longtime curators on the RWBY project.
And as always, he had tremendous help from our fellow RWBY team members and contributors like all of you around the world. We've heard Paul request and other wonderful suggestions. And we will lead off with, a fundamental technique that if you're developing anything that's outside of that quick little exploratory data analysis script, Your future you will thank you later if you invest, some time in learning version control, in particular with the Git version control mechanism, which has become synopsis with, many of the development world, so to speak, and software development, but also data science as well.
Mike and I here use Git literally every day for our projects, and we could not live without it. And every time I think I've, you know, I I think I've got a pretty good grasp on some things. And then there are instances where I do feel very humbled based on how well some other people in the community have learned Git even when they didn't come from necessarily a software development background as well. So our first highlight is one of those showcases from a very renowned expert now in this intersection of Git and research software engineering and data science.
And in particular, it was a meetup that was recorded at the Salt Lake City, our user group meeting. And this is one of the top our user group meetings across the entire world, in my opinion. They always have fantastic speakers, fantastic talks. This is, run by, Pazit's own Julia Silgi as well as Andrew Redd. And in this particular instance in their May session, they had the esteemed, Ma'al Salman, who has been a long time both, curator for Art Weekly, and now a frequent contributor just of her daily work that spans our OpenSci as well as the synchro group, which we'll be hearing more about later as well.
And in her, presentation at this meetup, it was a both, presentation and interactive demonstration of be getting better with your history of git commits and a lot more than just that. So I both must confess I didn't watch the entire meetup yet that is on my list to do, but I have had a good, review of a few key sections as well as the slides, which we have linked to in the show notes. And Al always does a wonderful job of her presentation materials. So this is kind of a tour de force of, like, some really core Git concepts that, you know, you may use a little bit every day in in basic ways. But then if you take it up a few notches, you can really help future you immensely, especially when you get to reviewing when things maybe went wrong or reviewing what the heck you did last year in those various commits.
So as I was watching this, there are some practices that I've latched onto with a vice grip, so to speak. One of those is, one of her recommendations right off the top is instead of doing that massive commit of, like, fifteen, twenty files of a whole bunch of line changes and just putting this commit message, like, just get this in before the deadline or get this in before my break. You're not gonna be able to make heads or tails to that no matter what fancy get interface you use to examine that. And so her first piece of advice in this talk is make smaller commits with a focus set of files.
I wouldn't say really matters if it's one file or a set of files, but the changes should be related to each other in some way so that in your commit message, you're very specific about what exactly you're trying to fix. Maybe it's a bug in your code. Maybe it's, a refactor of a CI process. But if you lump that in with a whole bunch of other changes, oh goodness, that that that's gonna be rough to debug and rough to especially in the world of collaboration for your collaborators to see what the heck that commit was all about. So I have gotten better with that. Now again, we all sometimes fall in old habits from time to time, especially when things go haywire. But when I'm in the flow, so to speak, I am making these more nimble fit for purpose commit messages.
And the other part that she recommends highway and I wholeheartedly agree is branching. Branching is the methodology where instead of just being on that single stream of development, you can then separate another stream of development. Maybe you wanna experiment with a new feature. Maybe you have this really critical bug that you wanna fix and determine if you got the fix working before you push that back to your central or main branch. Git branching. Once you get in the flow of that, it is such a time saver and frankly, an effort saver as well.
When if something say doesn't work as expected, you just delete that branch and go back as if you never did anything wrong. And, also, when you wanna merge that into your main branch, having that separate branch as part of, say, a pull request in GitHub or a merge request in GitLab, it gives other collaborators an opportunity to review those changes, maybe even test it locally on their setup. But, again, you haven't touched that main branch just yet. You've got a way to have that separate stream of development, and it is very helpful for experimentation while avoiding making the infamous, say, copy of files that we often did, at least for me back in grad school when I didn't know Git yet. And I'd made tons of copies of my dissertation files when I was experimenting with something. And if I'd had Git, would have been much better.
That's where things and the rest of the presentation is where I start to feel a bit of humble, so to speak, and things I really need to level up on. So this is Eric being a little more vulnerable here in my get adventures, but I'm I'm always of the spirit of transparency here. When things do go haywire and you're not sure where it went haywire in your commit history or maybe you seem to have that file working before, and then you've done, like, five or six commits since then, and then suddenly without you knowing it, you've broken that file or you've broken that script or a Shiny app, and you don't know where the heck it went wrong.
That's where the git bisect command comes in, and this is where you can, in essence, enter a different mode of Git where then you can interactively step back in time to these different commits that you made and get the the you might say the environment of the files at that particular commit as you step back and then experiment with the code, see if things are still working or not. And you kinda go back and back until you found that place where it was working and then maybe go to that commit afterwards and then really start to isolate what you did in that script that might cause things to break. I have only used this sparingly. And boy, oh, boy, every time I enter that mode, I feel really nervous. It's almost like going into the black hole and wondering if you're ever gonna come out.
So one nugget that I saw in this presentation is that, yes, this is for all the maybe the VIM and VI haters out there and hate how you it's so hard to get out of VI. Right? Well, there is a way to get out and get bicep if you get too scared and you're like, just get me out of here. There is a way to exit it out, which I and then we didn't know about very well other than googling it the first time I did it. So that that is something I don't feel I probably shouldn't be so nervous about, but boy oh, boy. The first time I did it, I felt like I was in a a different world during it.
But one thing you'll see reinforced throughout this talk is that there are a lot of nice Git wrappers or, let's just say, gooeys out there that can help you with certain operations and Git, and they are really helpful. But sometimes there is just no substitute for being skilled in the terminal we get. There is some things that any GUI out there just is not gonna have an elegant interface for. Bisec might be one of those things where you just gotta get your hands wet or dirty, so to speak, and get in the terminal to do it. I'll be interested to see if that improves over time. But get bisect is definitely something I wanna practice. And one thing that you also see throughout the presentation, especially in the demo parts, is that Ma'am Elle realizes that it can be really scary to do this on a real project if you're trying to learn Git in these concepts.
So we've covered this before in our weekly highlights in the past, but she's made an R package that's been inspired by a very, fun, reference that she links to in the talk called, oh, beep, get. And it is called, I'm gonna try to say this right, suparlipopet. I probably didn't get that right at all. No nonetheless, not even close. This is a package that you can play with different exercises that that demonstrate these concepts. So I could get bisect, like some of the things we'll talk about later. And you can do this in a very low risk setting because you're gonna make temporary directories that have, like, a might call a borked git repo to let you practice in in your R session and throw this into your favorite IDE, like RStudio itself, like, more recently, Positron.
So you could try this in your preferred environment and get a feel for how things work. So we'll put a link to that in the show notes because it is a very fun package to play with. There are some other concepts here that I've seen used, especially by really talented developers out there that I have not done as much to my liking, such as when you get to a pull request merge, not just merging in all those commits from the the branch that you pushed up, but doing a squash and merge, where then you can consolidate all those, like, smaller commits into one commit that maybe now, again, maybe that doesn't work as well in certain situations.
But if a pull request only had, like, a few commits and they're all related to each other, it might be better for the history of the project to, in essence, squash those into one with a more detailed summary and bullets in the commit message of each of those individual changes. Your mileage may vary, but I have seen that in the past used with great success. Another thing is she makes heavy use of the git amend function, which again is a way to kind of change something you did in a previous commit. Maybe you had a typo in the commit message, so you can just simply amend what you typed in that message.
Other times, you could just add a file that you forgot about. And there are some GUIs that can help with this. So you might be able to use, like, even the RStudio GUI to do this or in positron with Versus code, you know, extension library. There's an extension called GitLens that does a great job with some of this as well as, you know, some of our, utilities like GitKraken, which I like, can help with this as well. So that's a great tip. As well as rebasing, which, again, that's one account I won't say scares me as much as BISEC, but I've always felt intimidated by trying that. But it is a way to kinda like in the squash thing, kind of consolidate certain commits and make the history a bit cleaner, especially if you're really iterating through things. And maybe in the long run, it doesn't have to be that verbose, but you just wanna, you know, make things a bit better, especially when you're merging things, so to speak.
So again, I haven't played with that as much. But again, you got demos in her package to try all this out. So definitely worth the watch. Definitely look at her slides, and she has links to her various blog posts that definitely most of them haven't featured in our weekly before. So it's not the first time we talk about version control, but boy oh boy, it's great to have a reminder from time to time just how powerful this can be in your development journey. So I ate some humble pie with this, Mike. How would you think about her her resources here? Always something to learn when there's a a Mael,
[00:14:27] Unknown:
presentation here. And I'm very jealous of the Salt Lake City, our users group. It seems to be going really strong for quite a few years. They get great speakers, cover great topics. So it's it's a great resource that we have out there for folks who are looking for, you know, live presentations and the community acts aspect to be a part of as opposed to maybe, you know, watching prerecorded things. But this is a fantastic walk through. Git is such a bigger language, I guess. It has such a big footprint of what it can do that maybe you don't realize. And I'm sure even maybe the males of the world still may not know every single little last thing that Git can do because it to me, it it just feels like there's always some new thing that Git can do, some new function it it has, command that it has that, I had never heard about before.
So there's some very, as you mentioned, Eric, I think there's some pretty low hanging fruit, in in terms of additional, you know, functionality that Git has that you may not have known about. The the amend the the Git amend is a fantastic, command in in my opinion. I often find myself making a commit and then realizing that, you know, I may have impacted a few files, but there was one last file that really, should have been changed as well that lines up with that that previous commit message. And instead of creating a whole separate commit for it, I can I can run git commit amend and actually overwrite, if you will, that last commit with the additional change that I want to bring in? So that's fantastic. You can also update the commit message with that command as well if you felt like the message, wasn't encapsulating everything that you wanted to say.
So that's fantastic. Git revert is is another one that Mel walks through, which I think is very useful. And those last two, as you mentioned in some of the GUI tools that we have, the GitHub desktops of the world, the GitKrakens of the world, may be able to do that. But git bisect, which I think is is what Mael may have spent sort of the majority of the time walking through, rightly so, is extremely powerful. Right? But it's it's certainly, detailed to get the hang of. And I think this sapphire le paupet, package, which apparently is French for my goodness or good heavens, something like that. It's like a French exclamation, which if you've ever worked with Git, you've probably exclaimed something like that at one point in time. But it's a really useful tool to be able to try some of this stuff out in a very safe setting. And I think probably as Mel mentions and as you mentioned, Eric, as well, some of this functionality may not be as important when you're working by yourself.
Right? I don't necessarily need to amend a commit message, you know, for myself if I forgot a file. I can just create a new commit, you know, on top of that that previous one. But when you start getting into team data science, this stuff becomes really important. And when you are reviewing codes, submitting pull requests, and other folks are going to be looking at the changes that you've made to the repository and the the Git history that is included in those changes that you've made, you want to provide them with a clear set of breadcrumbs that they can follow to understand the changes that you made and how you got from what existed in the repository to the repository to the fix or the enhancement that you created. And I can't tell you how much more efficient your workflow can be if you have a good grasp of these Git concepts, as opposed to to if you don't. It it can be a tremendous time savings for that code review process and for that collaborative process.
So if you do find yourself looking at some of these Git tools and thinking that, you know, maybe this isn't really that important to me in my current workflow because I'm sort of a solo data scientist on my team. That may be true. But if you do get into a situation in the future where you are collaborating with others, maybe even collaborating on open source outside of your your day job, I would highly recommend trying to pick up some of these additional Git tools that will really make that collaboration a lot easier.
[00:18:53] Eric Nantz:
Yeah. You wanna put yourself as well as, like you said, a team of, you know, data scientists and developers on the best path for success with this. Because one thing I've always learned is that, you know, not to to not to do a humble brag or anything, but when I get on a project of a team, usually, I'm the one that's doing the get kind of orientation first, just because just by by my work, you know, history, I have the most experience of it, other than a couple other people on a various projects, especially when you get to more of the clinical facing side of our data science area in our in our company.
So I'm trying to arm them with resources like what Mel has written here, but also just some cheat sheets and other, you know, tools like these interactive, you know, I mean, it's GUI based editors or frameworks around Git that can help along the way. And they may never need to be as proficient with certain parts of this, but that's where if there's just some attention to detail on at least the basics of this with those fit for purposes, commit messages, branching. And then as we grow into it, learning things like bisect, learning the amend functionality, I think that comes through experience as well.
But we we can expect to be experts right away. So getting them onboarded correctly or say efficiently, I will say that it's always been one of the most requested things I've ever had about, you know, like, say, education or training resources is resources around Git. So what I try to do is just assemble all these great resources from online. These online books that Mel mentions are also great reading as well, and I just try to distill the key points in various resources because there's no way I personally can duplicate what has already been done so well. It's just more of, I think, the practice of it, which, again, her package, I think, is a great way to practice it so that we all come with a foundation that we can contribute, you know, right away, but also not feel so intimidated by this whole get operation. So that first experience does matter.
And I don't know if you'll ever get in Git kind of like the experience we have on the r package development side with things like use this and other packages to just get you up and running really quickly. Get I'm not sure if we'll ever get to that point. No pun intended. But I think we we can definitely get some resources to share along the way, and this is certainly one of them. Absolutely. I do remember that
[00:21:28] Unknown:
Greg Wilson who was, sort of a famous software carpentries teacher, instructor, developer, once famously said on a podcast I was listening to that he has taught probably tens of different programming languages in, you know, these educational settings. And Git is by far the hardest language he has ever had to teach, like head and shoulders above.
[00:21:53] Eric Nantz:
Yeah. I, I can hardly agree with that from my limited experience in teaching this, but we should send some graduations to Git itself. I believe it just turned 25 years old recently this year. So, for those who don't know, Git was created by the author of the Linux kernel himself, Linus Torvalds, as a way to help manage all the kernel changes, and it's still being used to this very day. So talk about scratching your own itch, so to speak, for all of us to benefit. But, he he he had an entertaining interview a while back where he wished he didn't have to invent it, but he there was nothing else out there that met the needs of the kernel development. So we're all we're all beneficiaries of it even if we have some, less than stellar things to say when things go haywire, if you know what I mean.
Well, we're gonna transition now to, one of our favorite corners of the development world in the art community, and that's the space of Shiny and web applications. And in this next highlight, I will admit I got a preview of it, albeit not realizing where this was really gonna go. So a little step back in time with yours truly here. It was in last year during our r and pharma conference workshop series. I had the pleasure of hosting an a workshop by David Grange, Karma Tarip, and John Coon about this new blocker, framework that they used for a client project to help, application viewers, in essence, design a Shiny application of a no code like solution. It was kinda like a gooey editor for a for creating a Shiny app and then sending it to your users.
I was even put on the spot to do some exercise for it. It was a great way to learn on the fly. But throughout all of this, I realized they were doing some really slick things with how they were orienting these different parts of the app and being inserted in different places, be able to move it around. I had never seen anything like this before. Turns out that became a very important functionality and not just as blocker package, but in some other projects. So in this next highlight, we are pleased to talk about a new r package that has just been, released called doc viewer.
And it comes to us on this blog post author by David Grangen, Nelson Stevens, and Nicholas Bennett from Synchro, who we had just mentioned, and my Al was also supporting as well. And the doc viewer package under the, I guess, on the tin, so to speak, it is a way to give yourself these grid like elements, these panels. They can put any type of content inside and have some really neat capabilities to kinda mix and match, move them around wherever you see fit as well as some other nice customizations too. So in the blog post, you guess what? I know David's been a pioneer in WebAssembly.
There is a WebAssembly powered app right in the beginning of the post where you can actually see this in action with a set of about three panels here, one with a slider and a histogram, another with a VIS network graph, and then one with a data table that you can just move them around. I'm literally doing it right now as I speak. I'm just moving them within another panel with different tabs, or I'm blowing it out to a different side of the panel, with its own separate box. Very, very interesting here. And so you may be wondering, okay. Well, how does this actually work?
It is is using a doc view function where you put everything in, and then you put in a list of what they call panels. And in this panel, give it an ID. You can give it a title. And then the content, which, again, can be just a simple string or it can be a shiny type of content, like, say a slider input, like a plot output and whatnot. So again, we've seen they mentioned in the post, they've seen attempts at this in the past with, like, this kind of drag and drop functionality, such as the Dragua, framework, Dragua JS, also Shiny j q u I for wrapping jQuery extensions, and then also the sortable JS library where there's a sortable r package that I've used in the past.
They said each of them work pretty well for certain cases, but they needed something a little more customizable. And that's where they discovered the doc view JavaScript library that this one wraps. So there is a JavaScript library under the hood that if you're just doing any kind of web app, you could definitely tap into. But now we've as our users get to tap into the same functionality that that blocker package I mentioned was using under the hood. So you may be wondering why is this helpful for me as, say, a shiny developer listening here. I've always said you can't please everybody with your user interfaces.
There's always some client or some customer that just is tired of the sidebar layout. Maybe they just don't wanna have that plot be so big and in the in the frame. They just wanna kinda move it out of the way and move something else to get the key focus. Well, instead of creating, like, copies of apps that please, like, individual customers, maybe the doc viewer gives me a way to have one part of my app, maybe multiple parts, where I say, here's a predefined layout, what I think is, you know, a good way to present the data, present the controls. But you know what? If you have a preference, just drag and drop to your heart's content.
One interesting nugget that they mentioned here is that they do have functionality in this package to save the state of where these panels are and to restore it later. I wanna look into this a bit because some of you are aware I am working on a package called shiny state that's wrapping the shiny bookmark. We'll say, I think this is a little different, but I'm definitely intrigued to see how they pull this off. So they mentioned there's a vignette that talks about this, so I'm gonna definitely look at that after this recording. And there is some stuff they wanna work on in the future that the JavaScript library has, such as grid view without drag and drop or collapsible panels. They say they are working on that, but this is early days. They're looking for feedback, and I am definitely intrigued to try this out on one of my future projects, especially in those cases where I know I'm gonna have a few key elements on that on that interface, and I don't know exactly what is the best layout.
Maybe somebody prefers, like I said, that data table front and center. Maybe they prefer a plot front and center, and they want the controls in a more, you know you know, open way or or more larger view. So I'm gonna play it and see what happens, but I'm intrigued by what DocViewer could give us for customizing our shiny user interfaces. So, Mike, what do you what do you think about DocViewer here?
[00:29:26] Unknown:
Nope. This is super cool. It scares me in that it's could be one of those situations where you make an app that contains DocViewer functionality and then all of a sudden, your end users want all the other apps that you provide to them to also be doc viewer, functional if you will. Yep. But, it it's sort of like having a chat interface with your app. Right? Exactly. But I think it's it's really, really incredible. I think that there's a lot of potential here. I really thought that it was, you know, interesting how the the team arrived at at finding DocView after exploring a bunch of other sort of JavaScript tools that we may be more familiar with. They mentioned, you know, sortable. Js, which has an R package called sortable that I use a lot for filtering.
That's fantastic. There's Dragula, grid Stack, but but nothing really, fit exactly what they were looking for in terms of a a nice they call layout manager until they found dock view. And it's very smooth, sort of when you start to drag some of these different panels around, it's it's incredibly smooth. Yeah, I would have expected, you know, maybe one of the first packages that does something like this, at least that I've seen in Shiny, to be a little bit clunky, but it's it's pretty easy. And I think it plays into maybe another concept that we've probably all heard about, which is the idea of, like, self-service BI, alright, that end users potentially want, but is always tricky because I think a lot of times it's it's better to just put something in front of them that's a little more fixed, as opposed to doing the self-service thing where maybe they're not applying a filter that they don't know needs to be applied. But I'm gonna digress from that potential tangent. And one of the really interesting things to me in terms of the the code syntax is how you create these layouts is actually sort of starting with one panel, it's called.
And then the position of the other panels are all, defined with respect to a prior panel that's already been established. So, there's a within this this panel function, which is how you create a panel in the grid layout, there is an argument called position that you can serve a list to. And that list should contain, I think at least two objects. The first being reference panel, which is a different panel that you want to reference and then the section the second, argument there, the second list element would be direction. So if you're creating a second panel that you want to be to the right of the first panel, that list would say, you know, reference panel equals one to reference the first panel and direction equals right. So that my second panel is to the right of the first panel, which I think is really cool. You can obviously, decrease the width or decrease the height of any of these panels. But in situations where you want to set a minimum width, which is what they have in the example here, there's a minimum width argument so you can't decrease it, more than a particular number of pixels on screen, which I think is fantastic. So they've thought through, I believe, a lot of the functionality. I think that's sort of most important to creating these these layouts for end users. And I'm really impressed with what they've put together here with the doc viewer package.
I am most certainly gonna try this one out, in a future app here. And this is this link is going straight to our team's internal Slack channel because I think it's gonna be a hot topic.
[00:33:01] Eric Nantz:
Yeah. And one other area that I kinda glossed over until I reread again is a lot of times when we're starting these projects, we get into that wireframing stage, right, where we're just trying to figure out what are the just the basic components and from a UX standpoint that we want. And we've seen attempts at this a little bit in the past, from Posita, actually, that Shiny UI editor, framework that Nick Strayer had authored, and that can be a great tool as well. But with this, I could combine this with, actually getting to our friends, I think, are, Colin Fay had written a package called shiny ipsum, I believe, where you can have these random placeholders, like a data table, a plot, or or or another rendered output or input. And you could combine it with this doc viewer, and then you've got, like, okay. Here's my initial guess at the u at the UI layout.
Now in this meeting with maybe your stakeholders or other developers, let's just kinda drag some stuff around and see what really sticks, and then maybe we align on that fixed setting, or you might keep it flexible for the main app. So I think wireframe is another underserved area in application development that does get glossed over a bit, but yet is something that the last thing I wanna do is to bust out a PowerPoint slide for something like that. I want something that's more visual and interactive without paying for a proprietary service. So no shade to the Figma lovers out there or anything like that, but I'm I'm cheap. I like it free, and I think this doc the doc viewer, package might give me might scratch my itch on that on that side of it too. So as I mentioned, it is early days with it, but but as I'm as I mentioned earlier, the team has used this quite a bit with that block r package. So I know they've been putting it into a very realistic use case right off the bat, and I am intrigued to see what I can what I can do with this in a future project. And maybe there are cases where you have an app where maybe the majority of the app you wanna key fix, maybe that one module in there where you want to be more flexible.
I wanna see if I can, like, opt into using doc viewer in only one part of an app versus other parts that might still have that more
[00:35:22] Unknown:
fixed layout as a way to gently introduce it. So, again, things for me to try, but I'm intrigued to explore more. No. That wireframing case is a a great potential concept and there are certainly a lot of potential wireframing tools out there. I think this one would be a great one. I know we say no free ads, but I do wanna give a shout out. We do a lot of wireframing in Excalidraw, which is an open source tool that's just really fantastic for quick drawing sketches, things like that. And, there is a pull request out there to merge a new library in Excalidraw. So if you're familiar with Excalidraw, there are certain libraries that have like AWS icons for example that you can import and then you'll have access to using those in your wireframes.
And there is one called, Shiny Excalidraw and it has all Shiny components and there's open pull request into Excalidraw for it. It looks like, let me figure out. Mike John Page. I gotta figure out exactly what his name is on GitHub. It's Mike John Page, and, he's presenting this at the UseR conference
[00:36:32] Eric Nantz:
this year. So Oh. Give it a thumbs up if you see the poll request. I've I've definitely checked that out because I have used XCalDraw in the past as well. I wanna level up a bit more. I mean, having those shiny icons will just make it even easier. So yeah. Great. Great call out there. There's lots of interesting tools out there. And like I said, Doc Fear, I think, is gonna be in my, toolbox in the future. And I dare say the pedigree of the talent behind this package, I've always had a lot of a lot of appreciation for what David Grange and has has done for the shining community and his, previous efforts. So, certainly, it's in good hands as they say.
And lastly, in the highlights, episode today, we've got, another concept, from a development standpoint, especially when you get to, again, either application development, package development, another, maybe ETL pipeline development. You wanna make sure things are working as expected, not just by running code in your session, but you wanna repeat that, especially as you're making changes in an automated fashion. And that is where we have the test app package, which has been hugely instrumental in the automated testing of our packages when you build test functionality, test scripts, whatever you wanna call that.
But there are cases where maybe some of those functions you have in the package, you know, it either is an expensive operation to run or it's using a resource that would be really difficult to just manually keep configuring over and over again. And that's where the idea of mocking and testing comes to play. And no. I'm not talking about what the kids like to do when they think their daddy is talking about some old time concept. Not that kind of mocking. I'm talking about making things seem like they're real, but yet they kinda have a little maybe shim in front of it. So our highlight talking about mocking with Testac comes to us from Muriel Delmote, who is a data scientist at ThinkR. And our, ThinkR has always been a frequent contributor to the highlights as well. And her post is titled mock them all. Simulates a better test would test that.
So what is the motivation here on top of what I said? But let's say you also are building some business logic tests in an application like with Shiny. And maybe you have a piece in your app where the user uploads a CSV file or whatnot, and then your app's gonna do some processing on that. Well, imagine trying to build a test around that. Right? You can't offer using Shiny test two, perhaps. If you're not really interested in doing the interactive experience per se, but you just wanna test that what happens after that upload operation is working as expected.
You want a way to kinda capture that uploading feature without really uploading a file. Maybe you have a test file already in your package infrastructure. Well, that's where mocking comes in and tests that. They have functionality called with mocked bindings, where then you can kind of put in a shim to that function for, say, choosing a file or whatnot. And then you can just give it a hard code of path like she has in this first example here where she has mocked the choose dot files function in base r just to illustrate. So you can use your imagination. That could be used a lot of other ways as well.
And then the part that I've been more in the weeds of, so to speak, is that when your testing involves some kind of external resource outside of your package or app, let's think a system process. So let's think an API or maybe some other resource like that. So this can be also used with, with mocked bindings as well. And in the case of API, she does have an example where she's wrapped the idea of fetching the data from an API using the header package, h t t r. But you could also, again, have a mock binding where you simply give the result of that fetch operation as, like, a list or a JSON file or whatnot.
But I will put in a plug of a package I've had used great with great success, in a recent package I've built for wrapping an API, and that's called HTTP test two, which I'll link to in the show notes, which is a way to give you these mock bindings for for a hitter two or h t t r two, function calls where you kinda run it once, it'll capture the response. And then every time you run that test again, it's gonna use that cache response from that API request instead of hitting that API all the time. So that's a great accompaniment to, technique here. Now last but not least is that there are some situations that that with mock binding or even that a HTTP test two is not gonna help you because there are some functions that really depend on that. They're either very primitive in the language itself or they really depend on the environment at that specific time you run it, such as, say, sys dot time or getting an environment variable.
So you can't really put that in with mock bindings because it just doesn't know how to how to capture that effectively. The workaround, an understated workaround, is that for that function that you're trying to wrap, you put a wrapper function in front of, say, sys. Time. And then you can then do with mock bindings on your wrapper function instead of the base function itself. So in her example, she's got a wrapper function around sys dot time where it's, it it's simply that's all it calls under the hood. But then in her with mock binding, she then wraps her, get current time wrapper on it to just give a static timestamp instead.
So that might be really helpful if you're in a situation of testing in some kind of external environment or system environment where you can't just put in the with mock binding, that actual function itself. A wrapper function may be inconvenient at start, but in the end for testing, you'll you'll thank yourself later that you can put bindings for that. So very, straight to the point post, but I think, the mock bindings is an understated, underutilized utility so that you can, either save some cost by not calling that API so much or, please your IT admins. So don't want you hitting that that system resource all the time just because you're developing a new feature for a package. So really great advice here, and I'm definitely gonna take that to heart in my next project.
[00:43:51] Unknown:
Absolutely. And I didn't even realize, I guess, that, this with mock bindings function was in the test that package. It's fantastic. It's one that I admittedly haven't used yet, but but need to begin using. I think I've tried to do some things like this with the with r package. And I think the combination of test that and with r can be a really powerful one for doing things exactly like what's being discussed in the blog post, you know, simulating hitting an API, simulating a file being uploaded, simulating connecting to a database, things like that, and allowing you to build tests that, right, aren't going to be resource intensive and unnecessarily resource intensive, of the resources that you might be using in production, but still ensure that you're testing your business logic robustly.
So this is fantastic. I I think something that I often find myself doing, especially in my Shiny development, is having to make a change and rerun the app and, you know, upload a file, for example, and continue to do that to test the change. And it's not a huge deal, but it takes time to do that. And I think if I change my workflow, and this may be beneficial for some others out there as well, in that I try to make that change and instead run the the unit test first before I actually open up the app and, try to test that functionality, then I might be able to save myself some time by not having to to boot up the app, wait for it to to spin up, wait for the file to upload, and instead ensure that my unit test is running successfully and maybe that results in troubleshooting a few failures of the test first after I make my change.
And I will probably spend a whole lot less time doing that iterative process of continuing to boot up the app as I develop. So, this is definitely something that I want to bring into my workflow and I'm very grateful for, the the author here to be able to point out this with mock bindings that I definitely knew about in the back of my mind but have not been leveraging enough.
[00:45:58] Eric Nantz:
Yeah. I'm working on an app as I speak that does a lot of AWS processing under the hood, and I do have a dedicated package for that piece itself. But in that dedicated package, yeah, I absolutely wanna combine with mock bindings and this HTTP test too so that I can wrap these API requests, cache them after an initial run so that I can keep looking at these resources. I'm pulling things from, like, object buckets, DynamoDB databases, and whatnot, and I don't wanna keep hitting that Amazon API because, not that it's a huge cost. But if if you if you rack this up over time, it it can it can raise some eyebrows. So definitely caching that, I think, will be will be very helpful. And it does give you another on ramp to something that you and I agree with wholeheartedly when you search again, aspect of Shiny development.
Try to do the majority of your testing on the business logic side outside of Shiny first. And if you can use win mock bindings and to aid in that journey, I think it'll make testing a heck of a lot easier and save your usage of, say, Shiny test two or these other frameworks that are out there for when you absolutely have to do the UI stuff. But the business logic stuff, yeah, try try to use TestDaT for that if you can. And I think you and I are not alone in in thinking that. There are some other great people out there in the community that say the same thing. And what we also can agree on is this issue, we got a whole bunch of other additional resources, and we invite you to check it out as always. I won't give a specific one per se, although it is kind of a plug for an effort later on.
But in my, this three week window where I'm doing, conference presentation, but also I am gonna be part of the Our Medicine conference the week after. And, two guesses what I'm gonna talk about. My latest craze is the intersection of Nix and R, where I will be giving a hands on demo workshop of how I'm using Rix and Nix to do my Shiny app development. But then a couple days later, we have the man himself, Bruno Rodriguez, is giving a workshop on using Rix for Nix and reproducible analytical environments, and he does have a post in this our weekly issue and our additional finds here called multi language pipelines with Rickspress, which is his newer package that's augmenting the idea of targets, reproducible pipelines, but with Nix.
And the biggest, motivation for this is multilingual data science pipelines. The example he has is using R and Python. But imagine you could generalize this to say R and Julia, Julia and Python or whatnot. Anything Nix can do, we're express can do with you as well in the context of r as well. So definitely check that out, and we'll put a link to the r medicine, schedule in the show notes if you wanna check out Bruno's workshop and my, fun little adventures of my, Rick's journey. Kind of an encore for when I did a Shining Comp, but we get to really dive into the details quite a bit on how this actually works. So I'm excited to be a part of that.
[00:49:18] Unknown:
I'm always impressed by, what Thomas Lynn Peterson comes up with, and I think he's in a very unique niche within the R space in terms of graphics and fonts and things like that. And there's a great blog post that he recently authored called Fonts in R on the Tidyverse blog that walks through all sorts of different typefaces and and really a lot of interesting concepts that I don't spend a lot of time thinking about. But when I run into these issues, I am grateful for folks like him because there always seems to be an answer to the problem. So, really interesting one to check out if you're into that type of thing.
[00:49:54] Eric Nantz:
Yeah. Fonts have always been one of those things where I I use sparingly in customization, but they always kinda scare me when I have to go outside the confines of what's included in the system, especially wanna up my game with the g g pot visualization and fonts. So this is a very, very helpful resource to get started on the nuts and bolts of what's really happening. But with the recent advancements, as you said, with the system fonts package, as well as some other great resources, out there for both the visualization and the text representation, side of it, I think it's a great time to up your game, and it's not just for web apps. Right? This is for, again, those static visualizations, those static data summaries.
A new font can go a long way in that in that overall presentation for sure. So great find there. And, again, we invite you to check out the rest of the issue for your other, additional great resources of new packages, other events, and other top notch tutorials out there. So we love to hear from you as well. If you've been enjoying our weekly, one of the best ways to help the project itself is to get in touch with us via a pro request. If you find that new great resource, that new blog, that new package, we always have a link in the top right at rweekly.0rg for you to send that poll request with a template already prebuilt for you. Our curator of the week will be happy to get that merged in for you, to get your impact on our weekly itself. And, also, we love hearing from you in the audience. We have a contact page in the episode show notes so you can send us a fun little message with. You can also get in touch with us on these social medias out there. I am mostly on Blue Sky these days of at [email protected] as well as Mastodon with @rpodcastatpodcastindex.social.
And I'm on LinkedIn. You just search my name. You'll see my random exploits over there. And, Mike, where can the listeners find you?
[00:51:56] Unknown:
Yep. You can find me on blue sky at mike dash thomas dot b s k y dot social. Or on LinkedIn, if you search Ketchbrooke Analytics, k e t c h b r o o k, you can see what I'm up to.
[00:52:09] Eric Nantz:
Alright. And, looks like you got some great content coming our way soon. I'll be looking out for that. And, as always, I've like I said, I'm in the midst of this mini summer conference season, so I'll be sending some posts about what my adventures are there. But as always, we thank you so much for joining us on episode 205 of ROH highlights. And we may or may not be back next week, but rest assured there will be a new episode in the near future. So until then, enjoy your our journeys out there, and, we will see you next time.
