Summer vacations 2014


If you wanted to know why I've been absent, well, that's because I went on a couple of trips the past few weeks. Out of 23 days I spent 8 of them inside an airplane --- at least for a few hours. I won't write about all my vacations here, but the major highlight was going to Brazil for the Mexico vs Croatia group stage match.

Recife Antigo

The match was held at Recife which is in the Northeast of Brazil. There are quite a few things particular to this city, but I'll just focus on Recife Antigo. It's an island where old town Recife is located and held the main party attractions. You could easily go from the FIFA Fan Fest to Rua da Moeda and finally to the big dancing platform set up for the occasion. The FIFA Fan Fest had the large screen for watching games and all the official sponsors had booths there: my favorite, the one selling beer! A few blocks away was Rua da Moeda where many local bars were open at night and tons of people would go there. There was a relatively small stage set up too where one night they were playing Brazilian rock. After a few blocks packed with people and some food vendors you could get to a square where the local government had set up a large wooden platform and live musicians got you dancing.


Click on the picture to open the interactive map

Before match day

The pair of nights before the game were our most party-intense nights covering all three areas of Recife Antigo I describe earlier. As the match got closer, you could see tons of mexicans gathering at the FIFA Fan Fest. After all, you can say that at the FIFA Fan Fest it was around 60% tourists, then around 50% tourists at Rua da Moeda and finally like 10-20% at the dancing platform. I liked this since you could hang out with very different crowds.

As proof that mexicans were dominating the tourist portion, one of the popular chants was ¡Y ya lo ves, y ya lo ves, somos locales otra vez! as shown in the video below. Mexicans would find the few pockets of croatian tourists and sign next to them.

Mexico's national anthem

I took plenty of other short videos, but the main ones are from the match. Here is one where we sign the mexican national anthem before the start of the match. To feel it's power you really need to turn up the volume in your speakers/headphones.

Mexico scores

My video taking abilities are not top notch, and thankfully I don't do this for a living! Otherwise I would probably be without a job now haha. But I did get a live shot of Mexico's first goal in the match and the ensuing celebration =) Just ignore my finger's cameo appearance.


After getting 4 hours before the match, signing all day long (even on the subway -- sorry locals!) and jumping a lot, we were exhausted when we got back to the hotel. As proof, look at my brother defeated by a crêpe (and some caipirinhas ^^).

The trip was totally worth it and I would do it again if I could. Problem is that at the current rate, the next World Cup in Brazil will be 64 years from now in 2078. Hm..., I'm not sure I'll be alive then. Qatar 2022? Haha! Nope! Russia 2018? Hm... tempting.

All I know is that I need to keep saving some pennies for the next big trip!!

Want more?

Check other @jhubiostat student blogs at Bmore Biostats as well as topics on #rstats.

This post is part of the summer 2014 Bmore Biostats' iron blogger challenge.

Concerns that can deter potential orders for developing Shiny apps


A few weeks ago I was invited to a meeting where a group was interested in exploring options for replacing their contract with a propriety software. They invited me because they saw some resemblances between a Shiny application I made and the features they need. It is a relatively small project and it seemed feasible to implement, but well, some details could have been tricky to code. During the meeting I explained what Shiny is, showcased some of the Shiny apps I've made, and proposed some options including a simple site password.

A few days after the meeting, they raised three concerns.

  1. Privacy and security of their data. Specially with distribution of the site password.
  2. Technical support. They wanted something more than community support.
  3. Continuity of the project. Specially since their team might lack the technical expertise to support and modify the Shiny app after it is built.

These are all valid concerns and they are not something I have dealt with or been concerned with other Shiny apps I have deployed. Thus, I ended up finding more information and writing up a long reply which I am modifying into a post format here. If you identify other ways to approach these concerns that I missed, share the knowledge please!

Shiny overview


Shiny is an R package that allows creating web applications with R. A user opens the app on their browser, specifies a given set of inputs, these are transmitted to an R session, some code is evaluated with the input options, output is produced and transmitted back to the browser. Because it is so easy to use and useful, it has been very popular. That is the gist of it!

Deploying a Shiny app

Once you develop a Shiny app, you have to deploy it on a server so users can access it through their browsers. Here I describe several options to do so.

The application itself needs "Shiny Server" to run. An implementation of Shiny Server is free via ShinyApps (option 1) or if you have your own server you can install the open source version of Shiny Server (option 2). Alternatively, you can pay for Shiny Server Pro and also install it in your own server (option 3). Note that is previous version of ShinyApps and you can no longer get accounts on this server.

Option 1 has the advantage of being completely free and that there is no need to pay for your own server. It does rely on ShinyApps being online, which should not be a main problem since it is hosted on the cloud. Meaning that it is supposed to be robust.

Option 2 has the advantage of having technical support for the server (not the app) from whoever is providing the server (could be a company or the school). However, you need to have someone capable of installing Shiny Server and updating it whenever it's necessary to do so.

Option 3 allows you to have high level password security (via SSL) to any Shiny app you host. Plus RStudio provides technical support for Shiny. The server technical support would still have to come from whoever is providing the server. The main disadvantage is that this option is very expensive (even with the academic pricing discount).

Here is some information you might be interested on checking about Shiny:



Privacy issues in terms of password sharing can be limited by changing the password frequently. Privacy in terms of protection versus hacking is a different subject and I could implement something like this demo (username: withr, password: 12345678) as described in this blog post. However, if you want further protection vs hacking, you would need Shiny Server Pro. Here is a demo of the security provided by Shiny Server Pro (with multiple users too). I understand that hacking was not the main concern you had, but well, as I said password-sharing can be mitigated by frequent changes to the app site.

Technical support

I mostly answered the different options regarding technical support when I described the three options for deploying a Shiny app. As for getting support from IT, they would need to learn how to use Shiny.


Shiny is one of the most important projects for RStudio so they invest a lot in it, the community provides great answers very quickly, and a lot of people are learning how to use it. If you need an R programmer later on instead of a student, you could describe the job at R Users and employ someone that way. As far as the Biostats department is concerned, I know that several students are using Shiny and some have even published Shiny Apps in the academic literature. Here are some examples:

  • interAdapt is a Shiny app written by Aaron Fisher (Biostats student) and published here.
  • shinymethyl, a shiny application developed by Jean-Philippe Fortin described here with a demo here.
  • committees is a Shiny app made by Alyssa Frazee for verifying your school oral and/or defense committees. It's described in this post.
  • ENAR 2014 is a Shiny app made by John Muschelli for the ENAR2014 conference which allowed you to quickly identify talks you might be interested in. It's described in this post.


Regarding branding, a Shiny App can be embedded on a website. For illustrating this, I embedded two apps I made here.


In the end, this group decided to use something else instead of a Shiny app for now. I do not know exactly why they made that decision, but I can see that their concerns are probably shared with other potential Shiny users. These concerns are a challenge RStudio must be dealing with and I am curious to know how they would have approached them.

Want more?

Check other @jhubiostat student blogs at Bmore Biostats as well as topics on #rstats.

This post is part of the summer 2014 Bmore Biostats' iron blogger challenge.