How a recent pivot in one of the most popular testing frameworks in R unlocks mocking once again, bringing robust grammar checks to your R development environment with rspell, and flex your Shiny and HTML design muscles with flexbox.
Episode Links
- This week's curator: Batool Almarzouq - @batool664 (X/Twitter)
- Update on mocking for testing R packages
- {rspell} Are you writing in a foreign language? The RStudio spelling dictionary setting is not sufficient to correct grammar errors. Try the {rspell} package to grammar-proof your notebooks and documentation straight on RStudio without copying-pasting.
- 3MW (Aligning content with flexboxes)
- Entire issue available at rweekly.org/2024-W13
Supplement Resources
- testthat 3.2.0 re-introduced mocking after it was removed in 2019. The PR with Hadley's commentary https://github.com/r-lib/testthat/pull/1739#issuecomment-1428027869
Supporting the show
- Use the contact page at https://rweekly.fireside.fm/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) and @theRcast (X/Twitter)
- Mike Thomas: @[email protected] (Mastodon) and @mike_ketchbrook (X/Twitter)
Music credits powered by OCRemix
- Kannonball - Donkey Kong Country 2: Diddy Kong's Quest - The Good Ice - https://ocremix.org/remix/OCR04571
- The Art of Zoning Out - Pokemon Scarlet - timaeus222 - https://ocremix.org/remix/OCR04570
[00:00:03]
Eric Nantz:
Hello, friends. We're back up to a 158 of the R Weekly Highlights podcast. If you're new to the show, this is the show where every single week, we talk about the latest awesome highlights that are featured in this week's our weekly issue available at ourweekly.org. My name is Eric Nantz, and I'm delighted you joined us from wherever you are around the world. It's been a, you can tell spring is definitely more in the air, and I woke up to, a big old windstorm over here blowing over trash cans and everything around our house. Hopefully, you're safe wherever you are, but not in any event. I never do this alone. I'm joined at the hip here. Hopefully, he doesn't blow away with the winds either by my co host, Mike Thomas. Mike, how are you doing today?
[00:00:44] Mike Thomas:
Eric, I'm doing great because I finally got my devcontainer and Versus Code set up for quarto rendering to PDFs.
[00:00:53] Eric Nantz:
Flawless victory. Oh, listeners, if you only knew the struggles Mike has had on this effort, even I tried to take a look at it and I was scratching my head. So I'm really happy you solved that. But, man, what a game changer that is. Installing Windows fonts and everything. Oh, the pain. You don't wanna know. Yep. Yeah. I I really don't. Yep.
[00:01:15] Mike Thomas:
Blog post, I I guess I owe the the world a blog post on this. I would love to see it. Yeah. We can never have enough content about using
[00:01:23] Eric Nantz:
struggling through the container setup because it is never easy the first time around. Awesome stuff. Well, congrats on that. And, hopefully, you don't have too much debugging as we record this issue. But, nonetheless, we have a fantastic issue today, and it was curated by Batool Almarsakh, now a long time member of the r Wiki curation team. And as always, she had tremendous help from our fellow r Wiki team members and contributors like all of you around the world with your awesome poll requests and suggestions. And, yeah, we're gonna lead off here with a concept that actually was touched on, you know, a bit earlier episodes of this podcast, but there's been some great, I would say, revisions in kinda how we go about this. And we're talking about the use of the mocking principle for testing your R packages.
And in particular, this post is coming from, well, you guessed this. She returns once again to the highlights, Myel Salman, and this time from her post on the rhub blog on some of the latest developments that have happened in this space of automated testing within the R ecosystem and how mocking has just become a bit easier to do, you might say. And first, a little history lesson. So it was back in 2019 or so that the test that package, which at the time had been experimenting with implementing mocking with a with underscore mock function, decided to pull the plug on that a little bit.
They noticed that they weren't too happy with the implementation of it, and they weren't quite sure of the best use cases for it. And as a result, there were some packages that sprung up in the our ecosystem to help fill this now gap, such as mocker and mockery. And the approaches that they took apparently caught the eye of Hadley Wickham himself because in the latest release of Testat 3.2 that we covered in a previous episode, the mocking system has returned with now new functions that replicate that existing functionality. But in Hadley's words, in a much better implementation that they can scale up and make sure that it's robust in the future.
So Ma'al now has written this post as a revision to an example that they did back in 2019 that is now taking advantage of TestDAT's new functionality. And in my crack research, if you will, before the show, I did dig up the very poll request that ended up bringing the mocking support back in the test net. We'll have that linked in the show notes if you want to hear the dialogue or see the dialogue between Hadley and other developers on this great development. So how do you end up doing this in your test suite? So in the post that or an example that they draw up here, Mahal first leverages to use this package to actually create a very simple prototype package that illustrates this point.
And then the, the base example of this is a little callback to what you just said earlier, Mike, about your adventures with Windows fonts. They have a little fun function here called is encoding a pane. Guess where it's a pane, folks. It's a pane on the Windows system. I hey. I didn't write it. The Mal wrote this one, but it's a simple function that runs the base sys.info function to determine what operating system the r session is running on. And, of course, if it comes back as Windows, yeah, encoding is a pain. We all have been there. It's a very simple function. But here's the thing, though. Let's say this package is going to CRAN or another, you know, other system and you want to run your automated test, but you're probably going to run this either on a GitHub action, you know, container or whatnot.
And most of those are not running Windows with the exception of, say, the CRAN wind builder service. So what do you do when you want to test this function but don't want it to actually do the check itself? And that's where this new enhancement to test that comes in. In particular, they, leverages the function local mocked bindings inside the test that she crafted here where she basically makes a fake version of the sys.info function but gives it a simple return value, you know, hard coded, if you will, so that when these tests are run, it's not going to call the actual base r installation sys.info.
It's gonna call this what you might call the mocked version of sys.info. So this technique, yes, this is a bit of a contrived example, I'll be it. You know, there can be panes of windows on various things. We won't get into that here. But it does illustrate the point that if you want to temporarily, for your test purposes, inject your own return value or circumvent what the function actually would do and put in your own return value instead for the sake of the test. The mocking principle with local mock bindings is going to be a very helpful way to make this happen without a bunch of refactoring of your basic code in your package.
And she does have link to the manual page for local mock bindings if you want to see where this fits in terms of test stats, you know, you know, baseline functionality. But that's not all you can do with with the mock bindings functions. And, Mike, why don't you take us through another revision that Mau does here with what she calls revisiting their escape hatch example.
[00:07:17] Mike Thomas:
I remember this example fondly, I think, from in our weekly post, from from Elle on this very same topic. You know, it's probably a year or so ago. Now, at this point and and I thought it was really fascinating. And sort of the example is that there's a function in the r directory of your your package, so it's gonna be one of your package functions. And, you know, it it has this check sort of at the top of the function to see if, the user has an Internet connection. There's a function from the curl package called has_internet, which, I guess, detects whether or not, you're connected to the Internet. So, you know, imagine that you want to write a test to ensure that, that function is is firing correctly. You know, for example, say that, in your r function, you're returning a message letting the user know that there's there's no Internet, so they should make sure that they connect to the Internet in order to run this function. Right? And you wanna make sure that that message is is firing correctly.
When you go to run these automated tests in something like GitHub actions, you're probably not gonna be able to shut the Internet off, right, during that action. So this is where this local mock bindings can really come in handy, where you are essentially forcing the result of of this function, that that is called is InternetDown, this example function that they have, to be true. So you're you're essentially setting that and then your function is going to return that message that you would expect, and you can match that up in in an expect underscore message call from TestThat, and then life is good, essentially. But, you know, sort of before we had this local mocked bindings, ability in the TestThat package, it was very difficult to do this, sort of very hacky. Maybe you don't even maybe you don't even write the test because it's it's difficult to actually test.
Maybe you're using the with our package too to to try to control some of this stuff, but I think, these these new local mock functions actually make it make our lives even a little bit more streamlined than having to use with our to to handle our environment to do something like that. So I'm really excited. That was a great example. It sort of brings me back to when I was, writing unit tests for a recent package that was unzipping files in a different order than I was expecting them to be unzipped in in my GitHub actions call. And I it was my first attempt at trying to to be a good, software developer using the with r package in my tests and, shot me in the foot. But that's the story, for for a previous time and maybe another time if anybody wants to hear it again. But at the end of this blog post, Mel, provides some some great additional examples where and this is another one that resonates with me.
You know, mocking might allow you to simulate having an older version of a package installed. So, you know, what if somebody has, you know, a version of r that's like 3.5? Or or I guess in the example of a package, what if they have a version of dplyr, as my an example with here? That's that's version 1.0.0. Maybe you have some code that is dependent on, a a particular version, a particular package being installed, so you can pretend that, in another example here, provides, you know, pretend that Arlang isn't installed. You can use local mock bindings to do exactly that. You know, you can create OAuth tokens or simulated OAuth tokens. You can create a fake GitHub URL for a project. The the sort of the possibilities here are endless. I really appreciate all the different real life examples and links that Mael has provided here.
And it's it's a fantastic blog post showcasing this new, you know, albeit fairly straightforward,
[00:10:56] Eric Nantz:
function, local mock bindings, I think really powerful. So I'm excited to, leverage this new functionality and test that. Me as well. I was telling you in the preshow, I'm working on an internal package that's wrapping an API for scoring some health outcome measures. And this will be, you know, a great example of leverage a lot of the principles here with other, you know, best practices of API, package wrapping development. And, you know, this is yeah. These principles are really cool. And, yeah, that real life example about the package version, literally as you were talking about that, I just thought about a situation that I get confronted with for teams that are wary of building internal frameworks that are depending on what we call our central R library of packages, the ones that our IT group freezes until R is upgraded itself.
Well, of course, let's say we upgrade R. We upgrade to this new version, say, 3.2 or whatever. And then those same tools that we're working on, say, you know, 3.0 or whatever have you, they wanna make sure that with that upgraded base library that's coming in a new version, will their internal tools still work as expected? Boy, oh, boy. If they wanna put some automated tests here, it seems like the mock bind the mock bindings with package versions would be a huge way to go. So thank you, Myelle, for putting that in front of me and seeing this great example from the pool package because that comes up time and time again when people are wary of, quote, unquote, the fast pace of our package versioning.
You know, it's not really that fast paced, but I digress. But either way, there are lots of there's lots of, great principles here that I think you can take wherever you're building wrappers to APIs or wrappers to system processes or other the the possibilities are endless as you see here.
[00:12:45] Mike Thomas:
Absolutely. I agree. And, yeah. I mean, a lot of, a lot of throwbacks for me here not only to old blog post but the old situations that I've I've dealt with sort of this this overarching idea of how to really set, you know, minimum versions of R and minimum versions of packages as well for the R package that you're developing is that I think a really sort of complicated process as well. So maybe maybe some of these functions can help us, help us in that
[00:13:18] Eric Nantz:
journey. Yeah. You know, Mike, it's always good to have a helping hand now and again. And another area where I definitely need some help is if I'm drafting that very comprehensive report and I get it ready to send out, but, you know, I need that double check. Right? Misspelled check because, yeah, the fat fingers here often do misspellings in my documents. And also, it's not just a spell check. Right? Sometimes we need a little help with our grammar because as much as we learn about ours in our school education, we sometimes forget some of those rules. But that's where the magic of technology can help us. Right? And our next highlight here, we we highlight, if you will, this great capability where maybe what we see built in to an IDE isn't quite enough, but we want to tap in some more power or recite the grammar checking. And in particular, we're gonna be talking about this, I believe, a new package in the R ecosystem called Rspell.
Rspell has been authored by Rafael Saldanha who is a postdoc at INRIA, a French National Research Institute. And what is rspell for here? Well, rspell, the main objective here is to help plug in potential gaps that might happen in IDEs such as Rstudio for being able to do not just spell checking but grammar checking as well. Because some in the community and, like, the tech world at large will rely on services such as Grammarly or others that help with their document writing or even email proofreading and whatnot. Well, some of those are not really, you know, at this point integrated into, say, deposit or Rstudio IDE.
So where Rspell comes in is that it is, wait for it, a wrapper package to an API called the language tool API, which apparently does have a free tier. I did some digging on this. So it looks like this is leveraging the free tier of that API where then the user can simply select some text in the document they're authoring. It could be a markdown file, a markdown file, or a quartile markdown file, what have you, even just the documentation in their R script or whatnot. And then it will have a command or a function called check selection. And then the console will display any potential grammar errors after sending that, to the API for checking.
And, of course, who wants to do that always in the click and drag approach? There are some nice keyboard shortcuts that you can add in your Rstudio preferences as an add in as well that you could key bind all that. And this is another major selling point. It will have support for multiple languages, and it will be smart enough to detect if your default language in POSIT or Rstudio has been set, it's going to automatically leverage that particular language when it sends these grammar checks to the language tools API. It'll also respect any definitions that have been made for, you might say, exceptions in the user's dictionary set in Rstudio as well.
And then also it may be able to just say, I want to see the errors. Don't worry. Modify them. Yeah. Let me be the judge of that. You can do that with an argument ask modify equal false in the check selection function. Where I see this is honestly not just with the RStudio ID. I think this can be a great help for any development environment that you're leveraging with R. Why not put this in something like Versus Code or or Emax or N VIM, whatever have you? Like, this is giving you the power to do those grammar checks in a in a custom fit for purpose package that can be independent of, say, the ID.
So really great niche that's being filled here by by Rafael's Rspell package. And certainly, I think it's going to be a huge win for those of us that are not exactly using, you know, the Office type document, you know, software for our our document writing. It's always like a pain in the rear end for me to write something in Microsoft Word anymore. I love to do quartal and R Markdown all the way, and now I can have my nice grammar checks in there too just like anything else.
[00:17:43] Mike Thomas:
Yes, Erica. I couldn't agree with you more. I have a very hard time, like, authoring anything or putting any sort of text on screen in Microsoft Word as opposed to if I'm in in quarto, in in IDE, like Rstudio or Versus Code, I can I can write away? I don't know what's wrong with my brain that that's the case, but that's just, I guess where I'm at these days. And and this language tool API is is really really interesting and really useful. We author, you know, some pretty long, quarto documents that are either, you know, model validation reports or, you know, RFP responses, things like that. So so we do, you know, have a need for grammar checking, you know, on these these large pieces of text. And, I think that this package is actually going to be be useful sort of immediately for us. You know, one thing that I think is fascinating is the ability to select some text with your cursor, it sounds like, and run this check selection command at the console. That that to me is fascinating.
You know, I was taking a look at some of the, limitations that that you have. And and even on the the free plan, it's, I don't know, it seems, you know, pretty friendly, in in terms of how many requests you're able to make. 20 per minute. Number of characters you're able to, make in a request per minute, 75,000 free. You know, maximum number of characters per request, 20,000 free. It's pretty incredible. And even if you go to the the premium version, which which scales that up, you know, about fourfold across all those different metrics, I think it's like, you know, $39 a month for a 100 API calls per day. It seems seems pretty reasonable. It seems like a really fascinating tool. I know Grammarly has been, you know, one of the the larger name, larger brand resources out there for grammar checking. But, you know, something that has a beautiful API that we can really easily bring into our software development workflows, like this language tool.
I don't know. It seems pretty powerful to me. I don't know if there's I'd be curious to see if in Versus Code there's any extensions that, you know, are sort of higher level, more powerful grammar checkers than just sort of, you know, the spell check that you get out of the box, you know, that look something more like this language tool API or like Grammarly. Not a 100% sure there, but but it might be interesting to check out. But regardless, I think this is a a phenomenal solution. In the meantime, it looks like there's about 80 different languages that are supported in this Rspell package, and, I I really don't see how this can't be a benefit for everyone out there who's authoring any sort of scientific, report documentation.
[00:20:24] Eric Nantz:
Yeah. I I wholeheartedly agree. And I was looking under the hood a little bit at this, at this package, and, this is another one of the newer ones that is leveraging the h t t r 2 under the hood that recently had its 1 dot 0 production release. So if you're wanting to see another example in the community that's leveraging, you know, Hadley's new HTTR 2 package, this will be a great one to take a look at for inspiration. And I think, again, my my biggest win here is the democratization, if you will, of being able to leverage this wherever your development is happening. I think that's gonna be a huge help for everybody. And, yeah, I'd imagine in the world of Versus Code, there's basically an Accenture or just about anything these days.
But this means that you get this power of powerful, grammar checks wherever you are. And I'd imagine that as over time this package is more widely used, perhaps there will even be more features under the hood. So congrats again, Rafael, for this excellent release. You know, whenever you get Mike and I together on any show or podcast, event of where Shiny will enter the picture here in respect to our application development, our interfaces that we're trying to make a little more robust with some nice aesthetic stylings in HTML and CSS and whatnot. And one of the areas that in my day to day life is shiny in the early days that I definitely have one of those kind of love hate relationship with was the grid system.
How many times did I try to get the column width right between these rows and columns that are just scattered across my dashboard? Now things are looking better in the Shiny space, of course, with the advent of Versus Lib and whatnot. And sometimes you might need to still get a little lower level with some of your CSS styling. But our last highlight today is coming from the esteemed Albert Rapp on how you can take advantage of now a very popular technique in the world of web development and styling, in particular, the Flexbox, capability within CSS.
So, Mike, is Flexbox gonna gonna take me away from my column with woes, you think?
[00:22:47] Mike Thomas:
I think it will, Eric. And I think it's already probably being leveraged pretty heavily in packages like bslib that are are trying to alleviate some of the alignment issues or hurdles that we had to overcome in the past. You know, I I remember fondly with that that grid system, especially in Shiny, you know, doing things with columns and a fluid row to try to align things that probably should have been aligned, like in a div with some CSS manually because it wasn't perfect. And I think I think Albert is walking us through sort of best practices around alignment, you know, using this this new sort of Flexbox framework. And he has this weather app, which looks like a, you know, phenomenal mobile application. It looks like something straight out of my iPhone, that he has been developing. I think just mostly sort of a UI for, and and showcasing, you know, different aspects of of UI development and HTML and CSS to to bring sort of best practices to the design of this weather app. So, you know, we're walking through a use case here where he's trying to accomplish a few things. The first one is at the top of the app, UI, there are sort of 4 icon elements. One is a time stamp for for what the current time is that you you might can imagine see on your on your iPhone.
Then he has a, icon that represents sort of your your service, your your vertical bars, you know, can you hear me now? And then there is a WiFi logo, and then finally followed by a battery logo. And when the way that he puts these together is actually in a nested div, where at the top level of the div is the time, and then there's a a a div, you know, the nested portion that contains those 3 other icons, your your signal, your WiFi, and your battery status. And when he initially tries to do this this nested div without the flexbox, what happens is the time stamp is above the other 3 icons below it. And he really wants to align those, really nicely horizontally.
So the way that he's able to do that is in that the style argument of this main div, he has two arguments to the CSS function. The first is is a margin function, which, you know, doesn't have any impact, essentially, here. But the the second argument here is display equals flex. And that is how you implement Flexbox, you know, instead of grid, and that is all that was necessary here to align these necessary here to align these four elements, horizontally instead of, you know, part of the div being stacked on top of the rest of the div. So that was a really clever, sort of simple implementation and and really powerful to see how that plays out.
The second thing that he wants to do is he actually wants to, have the timestamp be on the left side of the screen, and then the other three icons be on the right side of the screen, be pulled to the right side of the screen, instead of them all aligned, you know, one right after the other. He wants this large space in the middle of the screen, between these icons. And the way that he's able to do that is is, again, you know, just essentially adding, this argument to the CSS function that that ends up, you know, being supplied to the style argument of the main div. And this additional argument is called justify_content and that equals, in quotes, space hyphen between.
So that's how he creates space between the top level of that div, which is just the time space, and then the the nested portion, the sub div, which are those 3 different icons. And it's it's beautiful the way that it plays out. It it creates the perfect amount of space, such that the timestamp is pulled to the left side of the screen and the other three icons are pulled to the right side of the screen, but they are all, again, on the same horizontal plane, which is fantastic. And the last, thing that that Albert does here, Eric, is centering this big icon that's that's below, these these top of your screen icons. This big cloud icon that's right in the middle of the screen, which I I believe, you know, sorta tells you what the weather is today. So I don't know if you wanna take a stab, Eric, at at, Albert's approach to centering that icon with some margin elements.
[00:27:01] Eric Nantz:
Yeah. And, first, it it gets wonky in the beginning here. Right? Because when you start just doing your your grouping with the div, which again is a I cannot undersell the technique of if you just think of these divs as, like, these virtual boxes of stuff and then be able to do whatever the heck you want with that and then have it only affect that particular, you know, grouping versus the rest of your app, that's just such a a game changing technique if you're new to this world of web styling. It took me a long time to grasp, but now in my apps, I'm dipping all sorts of things so that I get that flexibility.
But, yes, going back to this example when he first implements this grouping, and then you see that everything is all jumbled on this canvas. And it's not even fitting in this very nice styled cell phone like, you know, rec you know, vertical rectangle background. Been there. How the heck how the heck do we get this so that instead of spreading it out, like, on the column like fashion, it's spread into a row like fashion? And that's where in the Flexbox nomenclature, there is yet another argument or parameter called flex direction where now you can say, you know what? I want this text, all of or all these elements representing both the text and the image to be stacked on each other in this column wise fashion and not splat across this entire row by default.
So wave forty decides to use the flex direction, set it to the value of column. And now look at that. It's looking much better. Now you see the text and the symbol embedded into the cell phone background. And now, yeah, maybe it's still a little not quite there yet because you want to do some additional moving around. And that's where the margin arguments come in where you can define, you know, if it's intelligent enough to space it on, like, the margin left and margin right being auto. So it kinda, based on your screen resolution, will fit it appropriately into that container. And sure enough, once you do that, now you're really seeing a very fantastic looking layout already.
The city name at the and the quote unquote the top row. You got the degrees and, and the weather status on the next row. And then the actual icon indicating the weather. Front and center, literally center with a good size. And then there's placeholders from additional metadata, but they're nicely justified in the lower left. So really, really top notch styling here. Again, the key nuggets here are just taking advantage of Flexbox and the various parameters that you have at your play here. And one quick tip, it's been mentioned in his previous blog post, and other people have mentioned this as well. It's one thing to run this, you know, like recompile your app, if you will, see the layout on your, you know, browser window and kind of rinse and repeat, right, like we typically do with programming.
Remember, with web development and that fancy schmancy browser you're running in, you've got those developer tools. Right? And then you can do the inspect capability and drill down to that very CSS that's outlining that but to your element that you select with your cursor. And then in real time, you could change like the margin was. You could change the flex directions, and you'll see that happen in real time. And that can be a nice time saver if you know you're gonna need to experiment a lot with this and you just wanna quickly see the impact of about rerunning your Shiny app, it's another technique that took me years to master between what Albert mentioned in his previous post and what, our good friend, David Grandgen, has taught me with his various web development. In fact, Mike, you and I were TA ing his posit workshop last year, learning about the ins and outs of Shiny UI design.
Those nuggets, they add up to really minimizing your iteration time or really getting you to the point you need to be at. So looks like there's more to come in this space for his next, installment when he wants to, you know, make things even more polished here. It looks like that's coming soon. But in any event, if he had told me this was a professional weather based app that was in its early stages, I would say, yep. It sure is. How much is it? Nope. It's all free of charge, folks. It's all part of learning here. So congrats, Albert. A fantastic post as always, and we look forward to the next stage of this.
[00:31:41] Mike Thomas:
Absolutely. No. I remember my first, foray into looking, popping open that developer tools pain and wondering what the heck have I gotten myself into. Why would I ever want to even, you know, attempt to mess with what's going on in here because it all looked so foreign to me but now I am grateful for whoever created that developer tools, you know, concept and technology because it allows us to iterate so much faster across the styling of our apps.
[00:32:10] Eric Nantz:
Yeah. And it's easy to get overwhelmed when you look at that at the first glance because there are so many different tabs of functionality or respect to even just seeing what are the actual requests that the page is generating and that almost like a like a Systrace log on Linux. It looks very, you know, overwhelming. But then when you get to the meat of what you want, which typically for me is either, like I said, the CSS tweaking or the JavaScript console, and I wanna look at inspecting some variable values and whatnot. Those are the 2 I'm in right now, but I know there's so much more in that in that council space. I would be remiss to not offer up my little conflict and my inner geek, if you will.
You know, I I ragged on the grid system as kind of being a bit painful over the years. But when I think of grid, I think of my favorite movie Tron. They were in the grid, man. They were in the grid. Flexbox just doesn't quite have that same ring to it. So I I'm gonna have to reconcile that in my head sometime.
[00:33:07] Mike Thomas:
Favorite movie?
[00:33:08] Eric Nantz:
Tron. It's my favorite. Memorized it. Good to know. Yeah. Yeah. That's a that's a way to get Greek cred with me. Anybody that likes Tron as much as me is as a friend already. So but, maybe Flexbox will grow on me in that sense, but we're not quite there yet. But in you know what's there, Mike. We got a fantastic rest of this issue of our week that Patul has curated for us, and we'll take a couple of minutes to talk about our additional finds here. And, yeah, I kind of alluded to my, you know, my, tech and gaming roots here. And so this post really caught my eye from Rasmus Bath. He has a post on modeling his pinball scores.
Those of you that rep the arcades back in the old days, remember those awesome pinball machines that you would sink your quarters into. Highly addictive and the bling you would get by hitting all those sensors and seeing the score rack up. There's nothing like that that rush, you would say. And, apparently, what Rad Rasmuth has done here is he had downloaded a virtual version of a pinball game called fishtails, I believe. And he tabulated all of his scores that he got from that virtual game and has made a nice little jiggy pot out of it. And, yeah, it definitely looks like a somewhat random distribution, but the fact that you could do a data driven analysis on that, yeah, huge win in my book. Took me back to the days when, myself and a few of my winter skis friends were doing a virtual racing league, and we had to do screenshots of the race times to collect our data. But 2 of us did it, and we had tons of fun doing it. So awesome post from Rasmus, and, yeah, now I got the use to play pinball again.
[00:34:50] Mike Thomas:
That's really cool. I found a, incredible set of slides, authored by Michael Friendly for his PSYCH 6135 course on visualizing uncertainty. And just fantastic resource for doing exactly that in your statistical, analysis and journey. You know, I think it's really important to to not just communicate point estimates, but to communicate, the uncertainty that you do have around those point estimates, so people can make, you know, better risk based decisions. It's a great walk through of the functionality of packages like ggdist and tidybayes.
And, it's just a phenomenal resource, one that I am definitely going to to save, in my notes for the future because it's spelled out really nicely for us. So definitely wanna highlight that as well.
[00:35:42] Eric Nantz:
Yeah. I love seeing these these awesome visualizations in this space because in my line of work, Uncertainty is not just a buzzword. We really have to account for and then be very clear to our stakeholders, our leadership, when we're looking at these different, say, study designs, just the uncertainty we might have with that particular outcome, that particular time point. You know, we've got to make sure we're transparent about it. So anything we do to communicate that uncertainty in a more concise way is a huge win in our book. So really great great post by Michael Friendly there, set of slides. I'll be definitely checking that out. And we want you to check out the rest of the rweekly issue. Like I said, a ton of amazing content here. So much to choose from, from the world of package development, you know, data science and the industry, academic research, calls to action.
It's all right there. And everything is available at rweekly.org. Everything is there. All the back issues are there. And as well as hearing from you because one of the easiest way to help with our weekly is to send us a poll request of your favorite resource, new package, new blog post. We love to see it. We'll have it featured in the next issue. So it's just a poll request away. If you can write markdown, you can contribute to our weekly. It's that simple. Very easy to get set up with. And, also, we love hearing from you in the audience as well. Got a little contact page directly linked in this episode show notes on your favorite podcast player of choice. Speaking of those podcast players, if you have one of those modern ones out there like Podverse, Fountain, Cast O Matic, CurioCaster, I could go on and on. There's a Honeywell boost functionality you could have to send your hosts, yours yours truly, and Mike here. A fun little boost to read along in the show if you wanna send us a message. So all right there. And, also, we're on the social media sporadically.
I am on Mastodon mostly these days. So that our podcast at podcast index dot social. I'm also on the weapon x thing, that the r cast, and I'm on LinkedIn from time to time as well. And, ironically, you this will have happened since I've recorded this. But literally in a couple hours after finishing this recording, I'll be taking a part in the, latest Epsilon Shiny gatherings to help do little,
[00:37:56] Mike Thomas:
fun little, teasers for the upcoming shiny comps. So I'm really looking forward to that. And, Mike, where can they find you? I will be there too as well, Eric. I'm excited for, that gathering. Yeah. And folks can find me on LinkedIn. If you search Catchbrook Analytics, you can see what I'm up to. Ketchb r o o k. You can also find me on mastodon@[email protected]. And one last, callback to Michael Friendly. His GitHub handle is just Friendly. Github.com/ friendly. That's awesome.
[00:38:29] Eric Nantz:
Sure is. You got it at the right time. That's easy. Yeah. I wish I'd been more, well, at least I got our podcast eventually. I just had a fight for it. So one of those things. One of those things. First of all, the problem is the social handles. But, you know, it's never a problem to listen to our weekly. We hope you enjoyed it. Again, we love hearing from you, so don't hesitate to give us your feedback. And also we hope to see you for episode 159 of this very podcast next week.
Hello, friends. We're back up to a 158 of the R Weekly Highlights podcast. If you're new to the show, this is the show where every single week, we talk about the latest awesome highlights that are featured in this week's our weekly issue available at ourweekly.org. My name is Eric Nantz, and I'm delighted you joined us from wherever you are around the world. It's been a, you can tell spring is definitely more in the air, and I woke up to, a big old windstorm over here blowing over trash cans and everything around our house. Hopefully, you're safe wherever you are, but not in any event. I never do this alone. I'm joined at the hip here. Hopefully, he doesn't blow away with the winds either by my co host, Mike Thomas. Mike, how are you doing today?
[00:00:44] Mike Thomas:
Eric, I'm doing great because I finally got my devcontainer and Versus Code set up for quarto rendering to PDFs.
[00:00:53] Eric Nantz:
Flawless victory. Oh, listeners, if you only knew the struggles Mike has had on this effort, even I tried to take a look at it and I was scratching my head. So I'm really happy you solved that. But, man, what a game changer that is. Installing Windows fonts and everything. Oh, the pain. You don't wanna know. Yep. Yeah. I I really don't. Yep.
[00:01:15] Mike Thomas:
Blog post, I I guess I owe the the world a blog post on this. I would love to see it. Yeah. We can never have enough content about using
[00:01:23] Eric Nantz:
struggling through the container setup because it is never easy the first time around. Awesome stuff. Well, congrats on that. And, hopefully, you don't have too much debugging as we record this issue. But, nonetheless, we have a fantastic issue today, and it was curated by Batool Almarsakh, now a long time member of the r Wiki curation team. And as always, she had tremendous help from our fellow r Wiki team members and contributors like all of you around the world with your awesome poll requests and suggestions. And, yeah, we're gonna lead off here with a concept that actually was touched on, you know, a bit earlier episodes of this podcast, but there's been some great, I would say, revisions in kinda how we go about this. And we're talking about the use of the mocking principle for testing your R packages.
And in particular, this post is coming from, well, you guessed this. She returns once again to the highlights, Myel Salman, and this time from her post on the rhub blog on some of the latest developments that have happened in this space of automated testing within the R ecosystem and how mocking has just become a bit easier to do, you might say. And first, a little history lesson. So it was back in 2019 or so that the test that package, which at the time had been experimenting with implementing mocking with a with underscore mock function, decided to pull the plug on that a little bit.
They noticed that they weren't too happy with the implementation of it, and they weren't quite sure of the best use cases for it. And as a result, there were some packages that sprung up in the our ecosystem to help fill this now gap, such as mocker and mockery. And the approaches that they took apparently caught the eye of Hadley Wickham himself because in the latest release of Testat 3.2 that we covered in a previous episode, the mocking system has returned with now new functions that replicate that existing functionality. But in Hadley's words, in a much better implementation that they can scale up and make sure that it's robust in the future.
So Ma'al now has written this post as a revision to an example that they did back in 2019 that is now taking advantage of TestDAT's new functionality. And in my crack research, if you will, before the show, I did dig up the very poll request that ended up bringing the mocking support back in the test net. We'll have that linked in the show notes if you want to hear the dialogue or see the dialogue between Hadley and other developers on this great development. So how do you end up doing this in your test suite? So in the post that or an example that they draw up here, Mahal first leverages to use this package to actually create a very simple prototype package that illustrates this point.
And then the, the base example of this is a little callback to what you just said earlier, Mike, about your adventures with Windows fonts. They have a little fun function here called is encoding a pane. Guess where it's a pane, folks. It's a pane on the Windows system. I hey. I didn't write it. The Mal wrote this one, but it's a simple function that runs the base sys.info function to determine what operating system the r session is running on. And, of course, if it comes back as Windows, yeah, encoding is a pain. We all have been there. It's a very simple function. But here's the thing, though. Let's say this package is going to CRAN or another, you know, other system and you want to run your automated test, but you're probably going to run this either on a GitHub action, you know, container or whatnot.
And most of those are not running Windows with the exception of, say, the CRAN wind builder service. So what do you do when you want to test this function but don't want it to actually do the check itself? And that's where this new enhancement to test that comes in. In particular, they, leverages the function local mocked bindings inside the test that she crafted here where she basically makes a fake version of the sys.info function but gives it a simple return value, you know, hard coded, if you will, so that when these tests are run, it's not going to call the actual base r installation sys.info.
It's gonna call this what you might call the mocked version of sys.info. So this technique, yes, this is a bit of a contrived example, I'll be it. You know, there can be panes of windows on various things. We won't get into that here. But it does illustrate the point that if you want to temporarily, for your test purposes, inject your own return value or circumvent what the function actually would do and put in your own return value instead for the sake of the test. The mocking principle with local mock bindings is going to be a very helpful way to make this happen without a bunch of refactoring of your basic code in your package.
And she does have link to the manual page for local mock bindings if you want to see where this fits in terms of test stats, you know, you know, baseline functionality. But that's not all you can do with with the mock bindings functions. And, Mike, why don't you take us through another revision that Mau does here with what she calls revisiting their escape hatch example.
[00:07:17] Mike Thomas:
I remember this example fondly, I think, from in our weekly post, from from Elle on this very same topic. You know, it's probably a year or so ago. Now, at this point and and I thought it was really fascinating. And sort of the example is that there's a function in the r directory of your your package, so it's gonna be one of your package functions. And, you know, it it has this check sort of at the top of the function to see if, the user has an Internet connection. There's a function from the curl package called has_internet, which, I guess, detects whether or not, you're connected to the Internet. So, you know, imagine that you want to write a test to ensure that, that function is is firing correctly. You know, for example, say that, in your r function, you're returning a message letting the user know that there's there's no Internet, so they should make sure that they connect to the Internet in order to run this function. Right? And you wanna make sure that that message is is firing correctly.
When you go to run these automated tests in something like GitHub actions, you're probably not gonna be able to shut the Internet off, right, during that action. So this is where this local mock bindings can really come in handy, where you are essentially forcing the result of of this function, that that is called is InternetDown, this example function that they have, to be true. So you're you're essentially setting that and then your function is going to return that message that you would expect, and you can match that up in in an expect underscore message call from TestThat, and then life is good, essentially. But, you know, sort of before we had this local mocked bindings, ability in the TestThat package, it was very difficult to do this, sort of very hacky. Maybe you don't even maybe you don't even write the test because it's it's difficult to actually test.
Maybe you're using the with our package too to to try to control some of this stuff, but I think, these these new local mock functions actually make it make our lives even a little bit more streamlined than having to use with our to to handle our environment to do something like that. So I'm really excited. That was a great example. It sort of brings me back to when I was, writing unit tests for a recent package that was unzipping files in a different order than I was expecting them to be unzipped in in my GitHub actions call. And I it was my first attempt at trying to to be a good, software developer using the with r package in my tests and, shot me in the foot. But that's the story, for for a previous time and maybe another time if anybody wants to hear it again. But at the end of this blog post, Mel, provides some some great additional examples where and this is another one that resonates with me.
You know, mocking might allow you to simulate having an older version of a package installed. So, you know, what if somebody has, you know, a version of r that's like 3.5? Or or I guess in the example of a package, what if they have a version of dplyr, as my an example with here? That's that's version 1.0.0. Maybe you have some code that is dependent on, a a particular version, a particular package being installed, so you can pretend that, in another example here, provides, you know, pretend that Arlang isn't installed. You can use local mock bindings to do exactly that. You know, you can create OAuth tokens or simulated OAuth tokens. You can create a fake GitHub URL for a project. The the sort of the possibilities here are endless. I really appreciate all the different real life examples and links that Mael has provided here.
And it's it's a fantastic blog post showcasing this new, you know, albeit fairly straightforward,
[00:10:56] Eric Nantz:
function, local mock bindings, I think really powerful. So I'm excited to, leverage this new functionality and test that. Me as well. I was telling you in the preshow, I'm working on an internal package that's wrapping an API for scoring some health outcome measures. And this will be, you know, a great example of leverage a lot of the principles here with other, you know, best practices of API, package wrapping development. And, you know, this is yeah. These principles are really cool. And, yeah, that real life example about the package version, literally as you were talking about that, I just thought about a situation that I get confronted with for teams that are wary of building internal frameworks that are depending on what we call our central R library of packages, the ones that our IT group freezes until R is upgraded itself.
Well, of course, let's say we upgrade R. We upgrade to this new version, say, 3.2 or whatever. And then those same tools that we're working on, say, you know, 3.0 or whatever have you, they wanna make sure that with that upgraded base library that's coming in a new version, will their internal tools still work as expected? Boy, oh, boy. If they wanna put some automated tests here, it seems like the mock bind the mock bindings with package versions would be a huge way to go. So thank you, Myelle, for putting that in front of me and seeing this great example from the pool package because that comes up time and time again when people are wary of, quote, unquote, the fast pace of our package versioning.
You know, it's not really that fast paced, but I digress. But either way, there are lots of there's lots of, great principles here that I think you can take wherever you're building wrappers to APIs or wrappers to system processes or other the the possibilities are endless as you see here.
[00:12:45] Mike Thomas:
Absolutely. I agree. And, yeah. I mean, a lot of, a lot of throwbacks for me here not only to old blog post but the old situations that I've I've dealt with sort of this this overarching idea of how to really set, you know, minimum versions of R and minimum versions of packages as well for the R package that you're developing is that I think a really sort of complicated process as well. So maybe maybe some of these functions can help us, help us in that
[00:13:18] Eric Nantz:
journey. Yeah. You know, Mike, it's always good to have a helping hand now and again. And another area where I definitely need some help is if I'm drafting that very comprehensive report and I get it ready to send out, but, you know, I need that double check. Right? Misspelled check because, yeah, the fat fingers here often do misspellings in my documents. And also, it's not just a spell check. Right? Sometimes we need a little help with our grammar because as much as we learn about ours in our school education, we sometimes forget some of those rules. But that's where the magic of technology can help us. Right? And our next highlight here, we we highlight, if you will, this great capability where maybe what we see built in to an IDE isn't quite enough, but we want to tap in some more power or recite the grammar checking. And in particular, we're gonna be talking about this, I believe, a new package in the R ecosystem called Rspell.
Rspell has been authored by Rafael Saldanha who is a postdoc at INRIA, a French National Research Institute. And what is rspell for here? Well, rspell, the main objective here is to help plug in potential gaps that might happen in IDEs such as Rstudio for being able to do not just spell checking but grammar checking as well. Because some in the community and, like, the tech world at large will rely on services such as Grammarly or others that help with their document writing or even email proofreading and whatnot. Well, some of those are not really, you know, at this point integrated into, say, deposit or Rstudio IDE.
So where Rspell comes in is that it is, wait for it, a wrapper package to an API called the language tool API, which apparently does have a free tier. I did some digging on this. So it looks like this is leveraging the free tier of that API where then the user can simply select some text in the document they're authoring. It could be a markdown file, a markdown file, or a quartile markdown file, what have you, even just the documentation in their R script or whatnot. And then it will have a command or a function called check selection. And then the console will display any potential grammar errors after sending that, to the API for checking.
And, of course, who wants to do that always in the click and drag approach? There are some nice keyboard shortcuts that you can add in your Rstudio preferences as an add in as well that you could key bind all that. And this is another major selling point. It will have support for multiple languages, and it will be smart enough to detect if your default language in POSIT or Rstudio has been set, it's going to automatically leverage that particular language when it sends these grammar checks to the language tools API. It'll also respect any definitions that have been made for, you might say, exceptions in the user's dictionary set in Rstudio as well.
And then also it may be able to just say, I want to see the errors. Don't worry. Modify them. Yeah. Let me be the judge of that. You can do that with an argument ask modify equal false in the check selection function. Where I see this is honestly not just with the RStudio ID. I think this can be a great help for any development environment that you're leveraging with R. Why not put this in something like Versus Code or or Emax or N VIM, whatever have you? Like, this is giving you the power to do those grammar checks in a in a custom fit for purpose package that can be independent of, say, the ID.
So really great niche that's being filled here by by Rafael's Rspell package. And certainly, I think it's going to be a huge win for those of us that are not exactly using, you know, the Office type document, you know, software for our our document writing. It's always like a pain in the rear end for me to write something in Microsoft Word anymore. I love to do quartal and R Markdown all the way, and now I can have my nice grammar checks in there too just like anything else.
[00:17:43] Mike Thomas:
Yes, Erica. I couldn't agree with you more. I have a very hard time, like, authoring anything or putting any sort of text on screen in Microsoft Word as opposed to if I'm in in quarto, in in IDE, like Rstudio or Versus Code, I can I can write away? I don't know what's wrong with my brain that that's the case, but that's just, I guess where I'm at these days. And and this language tool API is is really really interesting and really useful. We author, you know, some pretty long, quarto documents that are either, you know, model validation reports or, you know, RFP responses, things like that. So so we do, you know, have a need for grammar checking, you know, on these these large pieces of text. And, I think that this package is actually going to be be useful sort of immediately for us. You know, one thing that I think is fascinating is the ability to select some text with your cursor, it sounds like, and run this check selection command at the console. That that to me is fascinating.
You know, I was taking a look at some of the, limitations that that you have. And and even on the the free plan, it's, I don't know, it seems, you know, pretty friendly, in in terms of how many requests you're able to make. 20 per minute. Number of characters you're able to, make in a request per minute, 75,000 free. You know, maximum number of characters per request, 20,000 free. It's pretty incredible. And even if you go to the the premium version, which which scales that up, you know, about fourfold across all those different metrics, I think it's like, you know, $39 a month for a 100 API calls per day. It seems seems pretty reasonable. It seems like a really fascinating tool. I know Grammarly has been, you know, one of the the larger name, larger brand resources out there for grammar checking. But, you know, something that has a beautiful API that we can really easily bring into our software development workflows, like this language tool.
I don't know. It seems pretty powerful to me. I don't know if there's I'd be curious to see if in Versus Code there's any extensions that, you know, are sort of higher level, more powerful grammar checkers than just sort of, you know, the spell check that you get out of the box, you know, that look something more like this language tool API or like Grammarly. Not a 100% sure there, but but it might be interesting to check out. But regardless, I think this is a a phenomenal solution. In the meantime, it looks like there's about 80 different languages that are supported in this Rspell package, and, I I really don't see how this can't be a benefit for everyone out there who's authoring any sort of scientific, report documentation.
[00:20:24] Eric Nantz:
Yeah. I I wholeheartedly agree. And I was looking under the hood a little bit at this, at this package, and, this is another one of the newer ones that is leveraging the h t t r 2 under the hood that recently had its 1 dot 0 production release. So if you're wanting to see another example in the community that's leveraging, you know, Hadley's new HTTR 2 package, this will be a great one to take a look at for inspiration. And I think, again, my my biggest win here is the democratization, if you will, of being able to leverage this wherever your development is happening. I think that's gonna be a huge help for everybody. And, yeah, I'd imagine in the world of Versus Code, there's basically an Accenture or just about anything these days.
But this means that you get this power of powerful, grammar checks wherever you are. And I'd imagine that as over time this package is more widely used, perhaps there will even be more features under the hood. So congrats again, Rafael, for this excellent release. You know, whenever you get Mike and I together on any show or podcast, event of where Shiny will enter the picture here in respect to our application development, our interfaces that we're trying to make a little more robust with some nice aesthetic stylings in HTML and CSS and whatnot. And one of the areas that in my day to day life is shiny in the early days that I definitely have one of those kind of love hate relationship with was the grid system.
How many times did I try to get the column width right between these rows and columns that are just scattered across my dashboard? Now things are looking better in the Shiny space, of course, with the advent of Versus Lib and whatnot. And sometimes you might need to still get a little lower level with some of your CSS styling. But our last highlight today is coming from the esteemed Albert Rapp on how you can take advantage of now a very popular technique in the world of web development and styling, in particular, the Flexbox, capability within CSS.
So, Mike, is Flexbox gonna gonna take me away from my column with woes, you think?
[00:22:47] Mike Thomas:
I think it will, Eric. And I think it's already probably being leveraged pretty heavily in packages like bslib that are are trying to alleviate some of the alignment issues or hurdles that we had to overcome in the past. You know, I I remember fondly with that that grid system, especially in Shiny, you know, doing things with columns and a fluid row to try to align things that probably should have been aligned, like in a div with some CSS manually because it wasn't perfect. And I think I think Albert is walking us through sort of best practices around alignment, you know, using this this new sort of Flexbox framework. And he has this weather app, which looks like a, you know, phenomenal mobile application. It looks like something straight out of my iPhone, that he has been developing. I think just mostly sort of a UI for, and and showcasing, you know, different aspects of of UI development and HTML and CSS to to bring sort of best practices to the design of this weather app. So, you know, we're walking through a use case here where he's trying to accomplish a few things. The first one is at the top of the app, UI, there are sort of 4 icon elements. One is a time stamp for for what the current time is that you you might can imagine see on your on your iPhone.
Then he has a, icon that represents sort of your your service, your your vertical bars, you know, can you hear me now? And then there is a WiFi logo, and then finally followed by a battery logo. And when the way that he puts these together is actually in a nested div, where at the top level of the div is the time, and then there's a a a div, you know, the nested portion that contains those 3 other icons, your your signal, your WiFi, and your battery status. And when he initially tries to do this this nested div without the flexbox, what happens is the time stamp is above the other 3 icons below it. And he really wants to align those, really nicely horizontally.
So the way that he's able to do that is in that the style argument of this main div, he has two arguments to the CSS function. The first is is a margin function, which, you know, doesn't have any impact, essentially, here. But the the second argument here is display equals flex. And that is how you implement Flexbox, you know, instead of grid, and that is all that was necessary here to align these necessary here to align these four elements, horizontally instead of, you know, part of the div being stacked on top of the rest of the div. So that was a really clever, sort of simple implementation and and really powerful to see how that plays out.
The second thing that he wants to do is he actually wants to, have the timestamp be on the left side of the screen, and then the other three icons be on the right side of the screen, be pulled to the right side of the screen, instead of them all aligned, you know, one right after the other. He wants this large space in the middle of the screen, between these icons. And the way that he's able to do that is is, again, you know, just essentially adding, this argument to the CSS function that that ends up, you know, being supplied to the style argument of the main div. And this additional argument is called justify_content and that equals, in quotes, space hyphen between.
So that's how he creates space between the top level of that div, which is just the time space, and then the the nested portion, the sub div, which are those 3 different icons. And it's it's beautiful the way that it plays out. It it creates the perfect amount of space, such that the timestamp is pulled to the left side of the screen and the other three icons are pulled to the right side of the screen, but they are all, again, on the same horizontal plane, which is fantastic. And the last, thing that that Albert does here, Eric, is centering this big icon that's that's below, these these top of your screen icons. This big cloud icon that's right in the middle of the screen, which I I believe, you know, sorta tells you what the weather is today. So I don't know if you wanna take a stab, Eric, at at, Albert's approach to centering that icon with some margin elements.
[00:27:01] Eric Nantz:
Yeah. And, first, it it gets wonky in the beginning here. Right? Because when you start just doing your your grouping with the div, which again is a I cannot undersell the technique of if you just think of these divs as, like, these virtual boxes of stuff and then be able to do whatever the heck you want with that and then have it only affect that particular, you know, grouping versus the rest of your app, that's just such a a game changing technique if you're new to this world of web styling. It took me a long time to grasp, but now in my apps, I'm dipping all sorts of things so that I get that flexibility.
But, yes, going back to this example when he first implements this grouping, and then you see that everything is all jumbled on this canvas. And it's not even fitting in this very nice styled cell phone like, you know, rec you know, vertical rectangle background. Been there. How the heck how the heck do we get this so that instead of spreading it out, like, on the column like fashion, it's spread into a row like fashion? And that's where in the Flexbox nomenclature, there is yet another argument or parameter called flex direction where now you can say, you know what? I want this text, all of or all these elements representing both the text and the image to be stacked on each other in this column wise fashion and not splat across this entire row by default.
So wave forty decides to use the flex direction, set it to the value of column. And now look at that. It's looking much better. Now you see the text and the symbol embedded into the cell phone background. And now, yeah, maybe it's still a little not quite there yet because you want to do some additional moving around. And that's where the margin arguments come in where you can define, you know, if it's intelligent enough to space it on, like, the margin left and margin right being auto. So it kinda, based on your screen resolution, will fit it appropriately into that container. And sure enough, once you do that, now you're really seeing a very fantastic looking layout already.
The city name at the and the quote unquote the top row. You got the degrees and, and the weather status on the next row. And then the actual icon indicating the weather. Front and center, literally center with a good size. And then there's placeholders from additional metadata, but they're nicely justified in the lower left. So really, really top notch styling here. Again, the key nuggets here are just taking advantage of Flexbox and the various parameters that you have at your play here. And one quick tip, it's been mentioned in his previous blog post, and other people have mentioned this as well. It's one thing to run this, you know, like recompile your app, if you will, see the layout on your, you know, browser window and kind of rinse and repeat, right, like we typically do with programming.
Remember, with web development and that fancy schmancy browser you're running in, you've got those developer tools. Right? And then you can do the inspect capability and drill down to that very CSS that's outlining that but to your element that you select with your cursor. And then in real time, you could change like the margin was. You could change the flex directions, and you'll see that happen in real time. And that can be a nice time saver if you know you're gonna need to experiment a lot with this and you just wanna quickly see the impact of about rerunning your Shiny app, it's another technique that took me years to master between what Albert mentioned in his previous post and what, our good friend, David Grandgen, has taught me with his various web development. In fact, Mike, you and I were TA ing his posit workshop last year, learning about the ins and outs of Shiny UI design.
Those nuggets, they add up to really minimizing your iteration time or really getting you to the point you need to be at. So looks like there's more to come in this space for his next, installment when he wants to, you know, make things even more polished here. It looks like that's coming soon. But in any event, if he had told me this was a professional weather based app that was in its early stages, I would say, yep. It sure is. How much is it? Nope. It's all free of charge, folks. It's all part of learning here. So congrats, Albert. A fantastic post as always, and we look forward to the next stage of this.
[00:31:41] Mike Thomas:
Absolutely. No. I remember my first, foray into looking, popping open that developer tools pain and wondering what the heck have I gotten myself into. Why would I ever want to even, you know, attempt to mess with what's going on in here because it all looked so foreign to me but now I am grateful for whoever created that developer tools, you know, concept and technology because it allows us to iterate so much faster across the styling of our apps.
[00:32:10] Eric Nantz:
Yeah. And it's easy to get overwhelmed when you look at that at the first glance because there are so many different tabs of functionality or respect to even just seeing what are the actual requests that the page is generating and that almost like a like a Systrace log on Linux. It looks very, you know, overwhelming. But then when you get to the meat of what you want, which typically for me is either, like I said, the CSS tweaking or the JavaScript console, and I wanna look at inspecting some variable values and whatnot. Those are the 2 I'm in right now, but I know there's so much more in that in that council space. I would be remiss to not offer up my little conflict and my inner geek, if you will.
You know, I I ragged on the grid system as kind of being a bit painful over the years. But when I think of grid, I think of my favorite movie Tron. They were in the grid, man. They were in the grid. Flexbox just doesn't quite have that same ring to it. So I I'm gonna have to reconcile that in my head sometime.
[00:33:07] Mike Thomas:
Favorite movie?
[00:33:08] Eric Nantz:
Tron. It's my favorite. Memorized it. Good to know. Yeah. Yeah. That's a that's a way to get Greek cred with me. Anybody that likes Tron as much as me is as a friend already. So but, maybe Flexbox will grow on me in that sense, but we're not quite there yet. But in you know what's there, Mike. We got a fantastic rest of this issue of our week that Patul has curated for us, and we'll take a couple of minutes to talk about our additional finds here. And, yeah, I kind of alluded to my, you know, my, tech and gaming roots here. And so this post really caught my eye from Rasmus Bath. He has a post on modeling his pinball scores.
Those of you that rep the arcades back in the old days, remember those awesome pinball machines that you would sink your quarters into. Highly addictive and the bling you would get by hitting all those sensors and seeing the score rack up. There's nothing like that that rush, you would say. And, apparently, what Rad Rasmuth has done here is he had downloaded a virtual version of a pinball game called fishtails, I believe. And he tabulated all of his scores that he got from that virtual game and has made a nice little jiggy pot out of it. And, yeah, it definitely looks like a somewhat random distribution, but the fact that you could do a data driven analysis on that, yeah, huge win in my book. Took me back to the days when, myself and a few of my winter skis friends were doing a virtual racing league, and we had to do screenshots of the race times to collect our data. But 2 of us did it, and we had tons of fun doing it. So awesome post from Rasmus, and, yeah, now I got the use to play pinball again.
[00:34:50] Mike Thomas:
That's really cool. I found a, incredible set of slides, authored by Michael Friendly for his PSYCH 6135 course on visualizing uncertainty. And just fantastic resource for doing exactly that in your statistical, analysis and journey. You know, I think it's really important to to not just communicate point estimates, but to communicate, the uncertainty that you do have around those point estimates, so people can make, you know, better risk based decisions. It's a great walk through of the functionality of packages like ggdist and tidybayes.
And, it's just a phenomenal resource, one that I am definitely going to to save, in my notes for the future because it's spelled out really nicely for us. So definitely wanna highlight that as well.
[00:35:42] Eric Nantz:
Yeah. I love seeing these these awesome visualizations in this space because in my line of work, Uncertainty is not just a buzzword. We really have to account for and then be very clear to our stakeholders, our leadership, when we're looking at these different, say, study designs, just the uncertainty we might have with that particular outcome, that particular time point. You know, we've got to make sure we're transparent about it. So anything we do to communicate that uncertainty in a more concise way is a huge win in our book. So really great great post by Michael Friendly there, set of slides. I'll be definitely checking that out. And we want you to check out the rest of the rweekly issue. Like I said, a ton of amazing content here. So much to choose from, from the world of package development, you know, data science and the industry, academic research, calls to action.
It's all right there. And everything is available at rweekly.org. Everything is there. All the back issues are there. And as well as hearing from you because one of the easiest way to help with our weekly is to send us a poll request of your favorite resource, new package, new blog post. We love to see it. We'll have it featured in the next issue. So it's just a poll request away. If you can write markdown, you can contribute to our weekly. It's that simple. Very easy to get set up with. And, also, we love hearing from you in the audience as well. Got a little contact page directly linked in this episode show notes on your favorite podcast player of choice. Speaking of those podcast players, if you have one of those modern ones out there like Podverse, Fountain, Cast O Matic, CurioCaster, I could go on and on. There's a Honeywell boost functionality you could have to send your hosts, yours yours truly, and Mike here. A fun little boost to read along in the show if you wanna send us a message. So all right there. And, also, we're on the social media sporadically.
I am on Mastodon mostly these days. So that our podcast at podcast index dot social. I'm also on the weapon x thing, that the r cast, and I'm on LinkedIn from time to time as well. And, ironically, you this will have happened since I've recorded this. But literally in a couple hours after finishing this recording, I'll be taking a part in the, latest Epsilon Shiny gatherings to help do little,
[00:37:56] Mike Thomas:
fun little, teasers for the upcoming shiny comps. So I'm really looking forward to that. And, Mike, where can they find you? I will be there too as well, Eric. I'm excited for, that gathering. Yeah. And folks can find me on LinkedIn. If you search Catchbrook Analytics, you can see what I'm up to. Ketchb r o o k. You can also find me on mastodon@[email protected]. And one last, callback to Michael Friendly. His GitHub handle is just Friendly. Github.com/ friendly. That's awesome.
[00:38:29] Eric Nantz:
Sure is. You got it at the right time. That's easy. Yeah. I wish I'd been more, well, at least I got our podcast eventually. I just had a fight for it. So one of those things. One of those things. First of all, the problem is the social handles. But, you know, it's never a problem to listen to our weekly. We hope you enjoyed it. Again, we love hearing from you, so don't hesitate to give us your feedback. And also we hope to see you for episode 159 of this very podcast next week.
