No Clocks

Examples @examples provides executable R code showing how to use the function in practice. This is a very important part of the documentation because many people look at the examples before reading anything. Example code must work without errors as it is run automatically as part of R CMD check. For the purpose of illustration, it’s often useful to include code that causes an error. You can do this by wrapping the code in try() or using \dontrun{} to exclude from the executed example code. For finer control, you can use @examplesIf: #' @examplesIf interactive() #' browseURL("https://roxygen2.r-lib.org")

Instead of including examples directly in the documentation, you can put them in separate files and use @example path/relative/to/package/root to insert them into the documentation. All functions must have examples for initial CRAN submission.

Impact of AI on Developer Productivity: Faster development cycles: Code suggestions and automation reduce time spent on repetitive tasks. Improved code quality: AI tools identify bugs or security risks that may go unnoticed by manual reviews. Enhanced learning: Engineers can receive real-time feedback or even ask AI for code explanations to learn new patterns or frameworks.

GitHub Copilot is a game-changer for writing code. Powered by OpenAI’s Codex model, Copilot suggests lines of code based on the context of what you’re writing. It’s especially useful when you’re working with repetitive tasks or writing boilerplate code.

ChatGPT, an AI chatbot developed by OpenAI, is not just a tool for casual conversations. It can be used to ask technical questions, explain difficult code, or even generate ideas for solving specific coding problems. Developers often use it for quick consultations — whether it’s about debugging or understanding the intricacies of a particular algorithm.

AI-Assisted System Architecture and Design As AI becomes more sophisticated, it may start to play a role in designing system architectures. Currently, system design is one of the more complex tasks that engineers handle, requiring a deep understanding of the trade-offs between different architectural patterns (monolithic vs. microservices, synchronous vs. asynchronous communication, etc.). Future AI tools could help design optimal architectures by analyzing the specific needs of a project, performance goals, and scalability requirements. AI could suggest which patterns, frameworks, or technologies are best suited for a given application. It could even generate architecture diagrams, API designs, or database schemas based on historical data from similar projects. This would revolutionize system design, making it faster and more accessible to engineers of all levels. While experienced architects would still be needed to make judgment calls, AI could drastically reduce the time spent on initial design phases, especially in large and complex systems.

It is recommended to use the same structure in your tests/testthat/ directory as your R/ directory, i.e., a test file for every .R file.

formattable Another nice table-making package is formattable. The cute heatmap-style colour formatting and the easy-to-use formatter functions make formattable very appealing. color_tile() fills the cells with a colour gradient corresponding to the values color_bar() adds a colour bar to each cell, where the length is proportional to the value The true_false_formatter() defined below demonstrates how to define your own formatting function, in this case formatting TRUE, FALSE and NA as green, red and black.

If you want the features of both DT and formattable, you can combine them by converting the formattable() output to as.datatable(), and much of the formattable features will be preserved.

However, one problem I had was that when using DT::datatable, missing values (NA) are left blank in the display (which I prefer), but in the converted from formattable() version, NA’s are printed. Also, color_bar columns seem to be converted to character, which can no longer be sorted numerically.

reactable Next I tried reactable, a package based on the React Table library.

Columns are customised via the columns argument, which takes a named list of column definitions defined using colDef(). These include format definitions created using colFormat.

In the end, I used DT::datatable() in my Shiny app, because I found it the easiest, fastest, and most comprehensive. I’ve been able to achieve most of the features I wanted using just DT.

Heatmap-like fill effect:

apply the formatStyle() function to the output of datatable() to set the backgroundColor for selected columns:

Abbreviate long cells

Sometimes some cells have a large amount of text that would mess up the table layout if I showed it all. In these cases, I like to abbreviate long values and show the full text in a tooltip. To do this, you can use JavaScript to format the column to show a substring with “…” and the full string in a tooltip (<span title="Long string">Substring...</span) when values are longer than N characters (in this case 10 characters). You can do this using columnDefs and pass JavaScript with the JS() function:

Really plain table Sometimes I don’t need any of the faff. Here’s how to get rid of it all:

headerCallbackRemoveHeaderFooter <- c( "function(thead, data, start, end, display){", " $('th', thead).css('display', 'none');", "}" )

datatable( my_pic_villagers, options = list( dom = "t", ordering = FALSE, paging = FALSE, searching = FALSE, headerCallback = JS(headerCallbackRemoveHeaderFooter) ), selection = 'none', callback = JS( "$('table.dataTable.no-footer').css('border-bottom', 'none');" ), class = 'row-border', escape = FALSE, rownames = FALSE, filter = "none", width = 500 )

Compared to event-based programming, reactivity allows Shiny to do the minimum amount of work when input(s) change, and allows humans to more easily reason about complex MVC logic.

An attractive default look based on Bootstrap which can also be easily customized with the bslib package or avoided entirely with more direct R bindings to HTML/CSS/JavaScript.

Tools for improving and monitoring performance, including native support for async programming, caching, load testing, and more.

observeEvent() is used to perform an action in response to an event eventReactive() is used to create a calculated value that only updates in response to an event

observe() and reactive() functions automatically trigger on whatever they access observeEvent() and eventReactive() functions need to be explicitly told what triggers them

And where does isolate fit in all this? isolate() is used to stop a reaction observeEvent() is used to perform an action in response to an event eventReactive() is used to create a calculated value that only updates in response to an event

Create .Renviron file Within the get_data.R script of my repository, I extract my EIA API key from my R environment so that I can connect to the EIA API and pull the data needed for my project. In order for this to occur during my workflow, I need to create an .Renviron file within my virtual environment and store the key within that environment. - name: Create and populate .Renviron file run: | echo EIA_API_KEY="$EIA_API_KEY" >> ~/.Renviron shell: bash