Having seen how easy it was to convert a couple of hobby projects to use {pins}, I’m now daydreaming about putting it at the center of an S3 data lake operation.
I successfully made some small changes in a Shiny app to use the {pins} package to separate out a support file and data definitions from the app bundle itself. This lets me revise supporting information without needing to republish the app. It’s pretty cool! I’m excited to use the package lots more.
Sharing a quick tip that I’ve found useful while building with Shiny, recently: It’s handy to be able to save off the current state of a data set for bringing over to a scratch file. I made the download link appear only when running in my local environment. This way I can easily snapshot my in process data set for experimenting with visualization in my scratch file.
In ui.R:
if(interactive()) {
downloadLink("downloadData", "💾️ Download data set")
}
And in server.R:
output$downloadData <- downloadHandler(
filename = function() {
paste("shiny-export_", Sys.Date(), ".csv", sep="")
},
content = function(file) {
write.csv(globaldata$armor, file)
}
)
I had a good time this weekend coming up with a new way to visualize armor stat distribution in my Destiny 2 profiler tool. 🎮
Just learned of {httr2} (https://github.com/r-lib/httr2), a rewrite of R’s httr package, and am excited to try it out! The pipeable API looks like a nicely improved way to build complex requests.
I’ve had a nice afternoon working on my hobby R/Shiny project, a loadout finder for the game Destiny 2. These improvements make it a lot more flexible and informative: It can now optionally include armor that would otherwise be filtered out of configurations by the minimum stat threshold, and it will show current mods used in displayed loadouts.
I’m sure it poses some benefits for systematic parsing (and I’m certainly much more comfortable working in R and markdown, for what it’s worth) but Jupyter’s reliance on json for its file format seems like a big disadvantage for readability and portability.
I: Spend days carefully curating config files, reinstalling homebrew and trying variations of arm and x86 binaries
RStudio: Do you even ODBC, bro?
I: Just profanely put the path to the driver in the dbConnect call, disregarding all documentation and common sense.
RStudio: Yah here’s your SQL Server.
Dearest Ada, it has been two days since I began editing odbcinst.ini, and still SQL Server repels me. Tomorrow, we will sudo brew reinstall FreeTDS. With our persistence, someday, odbc::odbcListDrivers() shall yield results and I will be at peace.
/wistful violins
This revision of ArmoreR is really turning into something I’m happy with and proud of. I’ve learned so much since the very first iteration of this about a year ago. It’s really fun and rewarding to come back to it with a bunch of new expertise and make it much better in all ways, including a new approach to dealing with such a large amount of information.