I released a new video on my YouTube channel where I walk through how to access the US Census Bureau's APIs using R. I explain the difference between the Decennial Census, the American Community Surveys (both five year and one year), and how to access them.

The Census Bureau has a lot of great data that could benefit researchers and data scientists alike. But they're not that great at making it easy to understand or navigate.

My video walks you through this process step-by-step using the American Community Survey 5-Year estimates as an example.

If you learn better by reading than watching a video, you can also download the same instructions I walk through with my new Census Bureau guide here.

I'm happy to announce my new YouTube channel! On this channel, I'll take subscriber questions about R programming and answer them for you. If you have a question, feel free to reach out using my contact form. I may not be able to get to every question, but will try my best to answer those that reflect common problems faced in R programming.

Up until recently, I almost exclusively used Tableau for data visualizations. I believed (and still believe) it's the best data viz tool out there. It works well because you get to see the visualizations as you build them. You hardly have to do any programming within the tool and it doesn't take long to learn how to use it. Once you get enough experience, you can build beautiful dashboards relatively quickly.

Because of this, I never really bothered to learn Shiny. I love R programming, but I didn't think Shiny apps were as practical. "Why do I have to hand-write code to build an interface with data visualizations?" I thought. It seemed like a waste of time when a tool like Tableau allowed you to build visualizations by dragging and dropping and clicking.

But I recently worked on a project that changed my mind. A few months ago, a client approached my employer and asked for a Shiny app. I was the only R programmer available and so I naturally stepped up to use it.

Normally, I would've pushed back on the client and suggested Tableau, but they provided a mock up of what they wanted. I knew right away that we couldn't deliver the requested functionality with Tableau.

And so, despite never using Shiny or knowing what "reactivity" meant, I quickly learned how to use the tool and managed to deliver the app on time.

And I got to say... there's a clear difference in what Tableau and Shiny can do.

Tableau is great at guessing what you want it to do. With Shiny, you have to tell it exactly what you want it to do. And that's the big difference!

This is both a strength and weakness for Tableau. It allows you to intuitively drag-and-drop pills to put together a bar graph. You can select a color menu and create a palette from a color wheel. There are tool tips already pre-programmed that only require a little editing. You can use containers to space visualizations appropriately and use borders to create clearly defined sections of the dashboard.

Shiny doesn't work like that. At least not in its base form. It's hard to change colors because you have to hand type the color codes. Same with fonts, spacing, etc.

However, Tableau's strength is also a weakness. And vice versa for Shiny.

Clients often ask for more advanced functionality than Tableau can deliver. This doesn't happen that often, but it does happen often enough. When Tableau can't deliver, you're forced to rely on "hacks" to circumvent these limitations. One or two "hacks" work okay, but the more you add, the more performance issues you'll encounter. And these hacks often put a burden on either the developer the stakeholder to maintain over the long run.

Shiny doesn't require "hacks." While I think its UI framing is limited, you can pretty much tell it what to do and when to do it. The only problem is that you have to research the coding required to support those functionalities. And, most importantly, you need a good understanding of R programming beforehand.

Shiny loses out to Tableau in ease-of-use and aesthetics, but you can get far more ambitious with functionality. Because Shiny operates on R programming and R programming has a wide-range of capabilities, Shiny can do specific things that Tableau can't.

For example, Tableau can only read data. Shiny can both read and write data. This is a limitation I often ran into with Tableau. Quite often, we had to build a separate interface or use Google Sheets to allow end-users to input data. With Shiny, you can build a form for end-user to input data. And more importantly, you can create rules within the form to ensure the end-user inputs the correct data.

You can also transform data more easily within Shiny. While Tableau has great data transformation techniques, it's a lot easier to create precise transformations on a smaller scale that's geared towards an app function or visualization.

And lastly, you can create more advanced interactions with Shiny. When you learn about how to use reactivity and event observations, Shiny allows you to create far more specific interactions than Tableau.

Since you build Shiny apps using R programming, it's easy to integrate machine learning models within the app. And if you're a good enough designer, you can use this app to make the model more accessible to a wider audience.

Tableau has some modeling capabilities, but far more limited. Last time I used it, it could only produce a simple linear regression, as well as some other basic models. It's primarily a data visualization tool.

Ultimately, I think the tool depends on the audience.

Tableau performs better than Shiny in aesthetics and ease-of-use. With Tableau, you can quickly automate a reporting process and tell great data stories. For that reason, business stakeholders love it and I imagine they'll continue to invest in Tableau (or a similar tool like PowerBI).

Shiny outperforms with its advanced functionality, machine learning integration, and precision programming. You can tell it exactly what to do, but it won't look as pretty.

Because of this, I think Shiny is the best tool for subject matter experts. You can work alongside an engineer or scientist or knowledge-based professional and give them the ability to use a machine learning model to guide their decisions. Because subject matter experts need more advanced functionality and predictive analytics, aesthetics and ease-of-use are less important.

R programming is overwhelming to new data scientists. It was for me. I came from a SQL background. In SQL, a simple SELECT statement with a WHERE clause works in most situations. I didn't have to change things up based on the object type. Not true for R.

That meant I spent a lot of time trying to figure out how to wrangle data in R that would've been better spent on analysis.

In hindsight, a lot of these mistakes I made could've been prevented had someone given me a "list." Something to tell me the useful key principles, such as object types, that would've made the R programming language easier to learn and understand.

Well, I can't change the past, but I can hopefully save you (the new R user) some of those headaches.

Here's the list of R programming concepts you should learn ahead of time to make your R programming journey easier.

I adapted this blog post from a chapter in my upcoming book, R Programming in Plain English. You may download a PDF of all completed material for this book here.

As I said in a post a few weeks ago, R programming runs on objects. Most object types relate to the way data is stored and how it's handled. There's one object type, though, that's unique compared to the others.

That would be the function object type.

R functions allow you to script out various commands to transform and analyze data. This can be as simple as taking data from a vector and outputting a data frame. Or it could be something as complicated as a machine learning algorithm!

It all depends on your own R programming goals.

I adapted this blog post from a chapter in my upcoming book, R Programming in Plain English. You may download a PDF of all completed material for this book here.

Packages are one of the most important concepts in R programming. It's almost hard to conceive R programming without them.

An R package stores various functions and data sets for other users to access. It allows R to move beyond its roots in statistical programming and achieve more complex goals.

For example, you might be writing a research paper. You want to clearly show the results of your regression analysis in this report, along with various tables and charts to illustrate key points. You can use a combination of Rmarkdown, ggplot2, xtable, and various other packages to accomplish this goal.

That way you don't have to copy and paste your work to a word document as you analyze the results. You merely write it and program it in R and then export it to Microsoft Word when you're done. This saves you a lot of time in the long run and makes your code far more re-producible.

I adapted this blog post from a chapter in my upcoming book, R Programming in Plain English. You may download a PDF of all completed material for this book here. The PDF also includes practice problems and solutions over these concepts.

In a previous post, I explained the various object types in R. Now we want to learn how to filter and transform those objects. Notice how I didn't say filter and transform the data? That's because filtering and transforming data in R heavily depend on the object type.

That's what we'll cover in this post.

Before I explain those methods though, we need to quickly cover operators.

I adapted this blog post from a chapter in my upcoming book, R Programming in Plain English. You may download a PDF of all completed material for this book here.

RStudio is an IDE (integrated development environment) that allows more interactivity and for you to visually keep track of what you’re doing.

In simpler words, it’s a handy user interface for programming in R.

It’s far easier to both get started and understand the R programming language by using RStudio. It makes importing data and packages easier. It also makes it easier to manage and visually review what data and packages you have already loaded. And finally, it’s just plain nicer looking.

This post was adapted from material in my current book project, R Programming in Plain English. You may download a PDF of all completed material for this book here.

Before you can download RStudio, which is the far better way to use the R programming language, you'll need to first download R base. I'll show you how to do that in this post.

I adapted this blog post from a chapter in my upcoming book, R Programming in Plain English. You may download a PDF of all completed material for this book here.

R uses objects to store and interact with data and there are various object types. That probably means little to you now, but understanding these differences will make R programming easier – whatever your R programming goals.

In fact, I say it’s better to understand how these objects interact with one another over memorizing every base function and package out there.

That’s different from the approach I took to learning R. When I learned R, I went straight to learning the base functions. You know, the cool stuff that does the regression analysis and confidence intervals and whatnot.

That didn’t work out well for me. I was coming from a SQL background and thought data worked in a similar way with R.

Had I started by learning the objects first, I would’ve saved a lot more time. I would’ve done less data manipulation in SQL or Excel ahead of time and made simpler, more scalable R code.