The circuit to get the room temperature using the LM35 (or TMP36) is pretty basic, as you can see from the picture (the position of the flat part of the sensor is important!)

You can now run the following code in Arduino to get the 1st results.

int tempPin = A0; //LM35 Vout

void setup()
{
  Serial.begin(9600);
  pinMode(tempPin,INPUT);
}

void loop()
{
  delay(1000);
  Serial.println(analogRead(tempPin));
}

This will start outputting values without a lot of meaning. For instance, right now its showing 44 at my desk using the LM35.

The trick is that we’re using an analog port — A0. This gives us a 10 bit analog to digital converter, which means we have 2¹⁰ (1024) different values. These values range from 0 to the operating voltage you’re using, 5V if you’re powering your Arduino using USB.

So if you want to know how many volts are in A0, you need to multiply the value you get in analogRead(A0) by the operating voltage (5) and divide by 1024. Just change that last line by these two:

// The .0 after the 1024 is required to convert to float
float A0volts = analogRead(tempPin)*5/1024.0;
Serial.println(A0volts);

The output that I get is 0.21 (44*5/1024), so my A0 input is currently receiving 0.21V.

The way you can turn this into a temperature depends on the sensor you’re using.

LM35

According to the spec, the LM35 output formula is 0mV + 10.0mV/C, which is equivalent to 0.01V per each centigrade. That’s very convenient, because all you have to do is multiply volts by 100 and you get the temperature.

Serial.println(A0volts*100);

So now I know that the temperature at my desk is at a nice 21.5º (44*5*100/1024).

TMP36

The sensor I have at home is the LM35, but while playing with tinkercad I found they only have the TMP36. The spec tells us that the formula for this sensor is 50mV + 10.0mV/C so you need to offset A0Volts by 0.5:

Serial.println((A0volts-0.5)*100);

Reading temperature with Arduino and an LM35 (or TMP36) was originally published in Arduino Playground on Medium, where people are continuing the conversation by highlighting and responding to this story.

For instance, if you have the following data:

data <- data.frame(x = 1:20, y = c(rnorm(19), 500))

If you plot this with no changes, this is what you get:

ggplot(data, aes(x,y)) + geom_line()

It’s kind of hard to understand what’s going on in other points other than the last, so some zooming comes in handy. If you use ylim, this is what happens:

ggplot(data, aes(x,y)) + geom_line() + ylim(-5, 5)

Granted, you get to understand what’s going on, but that last of the chart data is just gone! A better alternative is to use the ylim parameter of coord_cartesian:

ggplot(data, aes(x,y)) + 
   geom_line() + 
   coord_cartesian(ylim=c(-5, 5))

This makes it much clearer that something’s going on at the end of that chart.

Setting limits on ggplot was originally published in Data Trekking on Medium, where people are continuing the conversation by highlighting and responding to this story.

The end result of this article will be to create a Time Map that looks like this:

Sample Data

The type of data I usually want to put in this type of chart comes in the form <TimeStamp> | <Event>. Here’s an example data frame:

library(dplyr)
set.seed(123)
df <- data.frame(helper = c(rnorm(500, 120, 100), 
                            rnorm(500, 1, .8))) %>%
    mutate(elapsed = cumsum(helper), 
           date = as.POSIXct('2019-05-25 10:00:00') + elapsed, 
           event = 'Ping') %>%
    select(date, event)

This will create a data frame with events that happen about 2 minutes apart and then 1 second apart. The data frame looks like this (the event is useless, it’s there just to make the data frame more interesting):

> head(df)
                 date event
1 2019-05-25 10:01:03  Ping
2 2019-05-25 10:02:40  Ping
3 2019-05-25 10:07:16  Ping
4 2019-05-25 10:09:23  Ping
5 2019-05-25 10:11:36  Ping
6 2019-05-25 10:16:28  Ping

Transforming the data

Next step, we need to have a “time before” and “time after” value for our data frame. Here’s how to do it:

before_after <- df %>%
    arrange(date) %>% 
    mutate(before = as.numeric(date - lag(date)),
           after =  as.numeric(lead(date) - date)) %>%
    filter(!is.na(before) & !is.na(after))

This will create the following data frame:

>  head(before_after)
                 date event    before      after
1 2019-05-25 10:02:40  Ping  96.98225 275.870831
2 2019-05-25 10:07:16  Ping 275.87083 127.050839
3 2019-05-25 10:09:23  Ping 127.05084 132.928774
4 2019-05-25 10:11:36  Ping 132.92877 291.506499
5 2019-05-25 10:16:28  Ping 291.50650 159.585497
6 2019-05-25 10:19:07  Ping 159.58550   6.506124

Plotting the data

The simplest plot would be:

library(ggplot2)
ggplot(before_after, aes(x = before, y = after)) +
    geom_hex()

But this is not very informative. There’s a very high concentration near (0,0) that we can barely see. Let’s use a logarithmic scale, and also add a bit more color to the chart:

library(RColorBrewer)
ggplot(before_after, aes(x = before, y = after)) +
    geom_hex() +
    scale_fill_gradientn(colours = rev(brewer.pal(5, "Spectral"))) +
    scale_y_continuous(trans = "log10") +
    scale_x_continuous(trans = "log10")

Better, but the axis labels aren’t very informative… Using breaks and labels on the axis, the time intervals become much more clear:

axis_labels = list('1/100s' = 0.1, '1 sec' = 1, '1 min' = 60, 
             '2 min' = 120, '10 min' = 600)
ggplot(before_after, aes(x = before, y = after)) +
    geom_hex() +
    scale_fill_gradientn(colours = rev(brewer.pal(5, "Spectral"))) +
    scale_y_continuous(trans = "log10", minor_breaks = NULL,
                       breaks = unlist(axis_labels),
                       labels = names(axis_labels)) +
    scale_x_continuous(trans = "log10", minor_breaks = NULL,
                       breaks = unlist(axis_labels),
                       labels = names(axis_labels)) +
    theme(axis.text.x = element_text(angle = 45, hjust = 1))

Here’s the complete code for the chart:

Creating Time Maps in R was originally published in Data Trekking on Medium, where people are continuing the conversation by highlighting and responding to this story.

Testing “normal” Shiny applications can be achieved with check host, but Rmd files are trickier... they return a success page, and only then do they build the report, which later can lead to an undetected error.

Our solution was to use puppeteer to test these pages.

Installing puppeteer

This may differ from distribution to distribution. We are using CentOS, so the 1st thing was upgrading nodejs to a later version. This was done using nvm.

The commands look something like:

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.34.0/install.sh | bash
source ~/.nvm/nvm.sh
nvm install 7
nvm use 7

Next, you can install puppeteer:

npm i puppeteer

The following script tests an Rmd file based on a URL:

Save the code to a file and run it using node test-Rmd.js <url>. You'll probably get an error like error while loading shared libraries, which means you're missing some dependencies... you can check which dependencies by running

ldd ~/node_modules/puppeteer/.local-chromium/linux-624492/chrome-linux/chrome  | grep not

For me, it was enough to install the following dependencies:

sudo yum install gtk3
sudo yum install libXScrnSaver

Note: The “ — no-sandbox” option launching puppeteer is not recommended, but since we’re using it to access our site only, it should be ok.

Once you have the script running, it’s time to configure monit.

Configuring monit

We’ll be using check program from monit which, unfortunately, doesn't take any arguments. So before we configure monit, we need to make a wrapper to our nodejs call.

You can do so by creating a shell script called test-Rmd.shwith something like:

#!/bin/sh
URLS=(http://<yourserver>/report.Rmd 
http://<yourserver>/another_report.Rmd)

RES=0
for i in ${URLS[@]}
do
    node /srv/shiny-server/ETLs/monit-validations/test-Rmd.js $i
    if [ $? == 1 ]; then 
        RES=1 
    fi
done
exit $RES

Next, you just need to configure monit. Edit a file for the Rmd validation, e.g. sudo vi /etc/monit.d/rmdmonitor and call the script you just created.

check program RmdCheck with path /<path_to_script>/test-Rmd.sh
        every 2 cycles
        if status != 0 then alert

Reload monit (sudo monit reload) and you're good to go!

Testing Rmd files on Shiny with monit was originally published in Data Trekking on Medium, where people are continuing the conversation by highlighting and responding to this story.

My team uses a Shiny Server to share some data analysis and dashboards with other teams.

The server has automatic processes to get data from external sources, and any team member can publish new code to production at any time.

Most of the time things go right, but I want to make sure everything keeps working, regardless of the changes that happen. To monitor the server, we decided to use monit.

Installing Monit

The installation depends on the operating system you’re using. For CentOS, here are the steps to install:

sudo yum install monit
sudo systemctl enable monit
sudo systemctl start monit

You can check if everything is working by running curl http://localhost:2812, although the result is not very interesting... A 401 error.

We can configure monit to allow remote access to the web interface, so that we can see the results in a remote browser.

Edit /etc/monitrc, and search for the embedded HTTP interface configuration (just look for 2812). Replace what's there by:

set httpd port 2812
    allow admin:monit

And reload monit: sudo monit reload. If you now launch a browser a navigate to http://<yourhost>/:2812, you should see something like this:

Note: You should later get back to this configuration and make it more secure!

Monitoring the Shiny process

To monitor the shiny process, the 1st thing you need is to launch Shiny with a configuration that uses a PID file.

Run systemctl status shiny-server and this will give you the name of the service. In my machine it's /etc/systemd/system/shiny-server.service

You can edit this file and change the ExecLaunch section to add a PID file (--pidfile=/var/run/shiny-server.pid)

(...)
[Service]
Type=simple
ExecStart=/usr/bin/env bash -c 'exec /opt/shiny-server/bin/shiny-server --pidfile=/var/run/shiny-server.pid >> /var/log/shiny-server.log 2>&1'
(...)

Run sudo systemctl daemon-reload and sudo systemctl restart shiny-server. You should now have a PID file.

Next, we need to configure monit. Create a file called /etc/monit.d/shinymonitor and add the following content:

check process shiny-server with pidfile /var/run/shiny-server.pid
start program "/usr/bin/systemctl start shiny-server.service"
stop program "/usr/bin/systemctl stop shiny-server.service"
if failed port 80 protocol http then restart

You can check that everything is ok by running sudo monit -t, and then restart with monit reload.

You are now monitoring your Shiny Server! Go back to the web console and check it out. Click the link, and you can see additional information about the process.

Monitoring Applications

In addition to monitoring if the service is running, you can make sure specific applications are running. Just to be sure a move to production or a data fetch hasn’t caused any problems.

You can do this by creating a file called /etc/monit.d/shinyappsmonitor with the following content:

check host myhost-myimportantapp address myhost.com
        if failed port 80 protocol http request /myapp/ then alert

check host myhost-otherimportantapp address myhost.com
        if failed port 80 protocol http request /otherapp/ then alert

check host myhost-reports address myhost.com
        if failed port 80 protocol http request /report/ then alert
        if failed port 80 protocol http request /anotherreport/ then alert

The name after check host is what you'll see in the report. You could put all applications under the same host, but I find it easier to look at the report like this.

What’s next?

If you have Rmd files running on your Shiny Server, these take a bit more work to monitor. Take a look at this article to learn how to do it.

Other things I’d like to do with monit:

1. Send alerts via slack. You can only configure monit to send alerts through email
2. Monitor cron jobs. We have some data processing jobs running through cron, would like to know if everything succeeded.

I’ll write about these things as soon as I build them! :)

Monitoring a Shiny Server with Monit was originally published in Data Trekking on Medium, where people are continuing the conversation by highlighting and responding to this story.

The goal is simple. I have a mobile application built with OutSystems and I want to check whether a red button or a green button converts better.

The application has two screens and looks like this:

Step 1: Set Up Google Analytics

The first thing to do is configure Google Analytics so you can track your goals and test which o f the options has a higher conversion rate.

Create a new account and select “Website”. At the end of the process, you will have a tracking code.

Next, set up a goal. This will measure each variant’s rate of success, and you’ll be able to understand which option is better. For this particular situation, we want people to click the Buy button.

Step 2: Set Up Google Optimize

Next, go to Google Optimize. Create a new account if you don’t have one and add a container. At the end of the process, you’ll have a Container ID.

To collect experiment data, link your Optimize account to your Analytics account.

Step 3: Configure the Application

With the basic setup done on Google’s side, we need to set up the application. Start by installing the “Google Optimize” component from the OutSystems Forge.

Next, add “SetupGoogleOptimize” to OnApplicationReady, “SendPageView” on the OnReady of the Common/Layout block, and “SendEvent” on the button click event. Be sure to use the Category, Action and Label configured in the Analytics goal.

We can now publish and run the application and make sure the events are being properly tracked. Open the application in a browser and check the real-time reports in Google Analytics.

Step 4: Configure the A/B Test

It’s time to go back to Google Optimize and create the experiment. I called mine “Green Button” and configured the URL for the homepage.

Once that’s done, we can start configuring variants. We’ll just add one called “GreenButton” that will change the color of the button to green.

Next, we need to configure the objective and the targeting of our experiment. The objective will be the goal we set up earlier: clicking the button. On the Targeting tab, change the activation event to “Custom” with an “optimize.activate” value. This is the value the Google Optimize component uses.

And that’s it! You’re ready to go!

Step 5: Get Some Results

You can now start seeing your different variants running. The easiest way to do it is by launching an incognito window and access your app’s URL. One of the variants will show. Close all incognito windows, open another incognito window, and you might get the alternative variant (if you don’t, try a couple more times). If all is properly configured, you’ll be able to see both variants.

Google Optimize is now collecting data and managing your experiment. But it will be a while before you can see the results — up to 48 hours. If you’re in a rush, you can always take a peek at the results in Google Analytics while it’s still available!

When your results are finally processed, you get all the information you need about your experiment.

A/B Testing OutSystems Mobile Apps with Google Optimize was originally published in OutSystems Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

When looking for a new job, it’s easy to be impressed with the perks some companies offer. After all, working in a place that offers ping-pong tables, unlimited vacations, and free breakfast seems like fun!

But perks are just ingredients. You’re not tasting the full dish!

As discussed in this Rework podcast, pilling perks is the wrong way to go through the job seeking process. Perks alone will not make you happy.Since I’m lucky enough to work for OutSystems, a company with an extraordinarily high employee NPS (yes, even higher than Google), I wanted to know what people value in their job.

It was easy, I just had to ask our amazing People Ops team. They had already done this work. So here they are, the 4 characteristics that make people love their job:

• Purpose: This is the thing that gets us out of bed. A passion for doing something that’s bigger than ourselves. Our work matters, and we’re changing the world for better every single day;
• Growth: We’re always learning. Either because there’s a new challenge, or because we want to find a better way to do an old job. Our People Ops team created career tracks to help us grow, but in the end each person controls their path. We’re always working to be masters of our practice;
• Great Culture: We all share the same values (we even have a little book about them) and we invest a lot in relationships. We are a team, not a group of individuals or departments;
• Recognition: We believe in rewarding achievements. We do it through fair paychecks, by offering stock options to all employees, and by saying “thank you”. We say “thank you” a lot. Throughout the day, in meetings, and in #kudos, our appreciation slack channel.

OutSystems also has perks, of course. Ping-pong tables, fruit, fridges full of yogurts, a great office… But when we ask people what they value most about their job, that’s not the main ingredient.

So if you’re looking for a new job, look beyond the perks. Find people that have worked for the company you’re targeting, and ask them about the things you value in a job. It’s the best way to find a position compatible with what makes you happy. Oh, and be sure to take a peek at our careers page :-)

People will quickly forget that a project was delivered late… But a project delivered with poor quality will leave a long-lasting memory!

A few years ago I was platform release manager at OutSystems. My main responsibility was making sure we released versions of the platform on time. And that’s what I did. If we announced the platform would be released on a given date, we made it happen.

But whenever you rush delivery, there is a price to pay: Quality.

At OutSystems we’ve always been very focused on quality, so the impact of rushing deliveries wasn’t that big. There were a few issues, but problems were quickly solved once detected. Seemed like a small price to pay for early delivery.

But losing quality isn’t the major issue. The big trouble is losing your customers’ trust!

Even this tiny loss of quality made customers avoid early releases of our product. It was better to wait for more stable versions rather than risk an early upgrade. And if nobody installs your product when you release it, what’s the point of releasing early?

So we changed our approach. We improved the way we guarantee product quality and we no longer compromise. If there’s any warning sign, regardless if it‘s a minor hiccup or an issue with the tests, we don’t release.

We’ve been having a lot of success with this approach. Customers feel confident to upgrade as soon as we launch. And we’re confident enough to release new product features continuously!

Release dates are still important, for sure. But delaying a couple of weeks for quality’s sake has proven to be the right choice, every single time.

But there’s a catch! After all this work, we still have customers that are afraid to upgrade immediately. They installed a slightly glitched version, got a sub-par experience, and never changed their behavior. They’re still suspicious of new releases, and for the most part wait before upgrading to new versions.

Making our product and quality processes bulletproof is hard. But changing customers’ behavior proved even harder!

So now we’re working to win back the trust of these customers. One by one, we’re getting them back on board of our fast release train. And it is working, but only because we’re delivering with such high quality standards!

But… why? Well, mostly just for the fun of it. Typing on this mechanical complexity, where everything is configured using levers and springs and clicks and clacks is a blast. Just the sound of the keys makes you want to type more!

Then there’s the fact that this is the only thing I’m doing! May seem like an odd thing to say, but not having distractions, and the attention I need to put on each key of this strange keyboard, it’s almost meditation…

It’s been a while, since I wanted a typewriter. I think I was inspired by a documentary where Woody Allen showed how he wrote his scripts. Yeah, you guessed it. He still use one of these machines, and when he needs to cut and paste . . . he uses actual scissors and glue.

I’m not sure if these were his sayings, and right now I don’t feel like using my computer to check it out, but I believe his reasons for using a typewriter included the fact that it is slower. The fact that on any modern editor you get to go bqck and edit what you just did, means that you tend to edit the whole time you are writting. Not having this ability makes you focus more on what you wanto to say, makes you think harder about XXXXXXXX how you want to say It (because editing is so hard) and alledgely makes your writig better. (btw, those mistakes on this paragraph, just when I was making a point about how focused I was? Got distracted by my phone. … :)

So, is it tru? Do I feel like I can do great writing on this relic? Well, sadly no… At least, not yet. ironically; I need to focus so much to write on this machine, that sometimes I feel like I lose my train of thought… Maybe that’s just a matter of practise. But I still miss the spell checker, and I’m not sure my family and neighbours appreciat my new toy… It is a bit noisy…

Anyway; I’ll continue to play with my Royal Deluxe. The sound of the keys is just too good not to use it. Let’s see where this leads… But if I do use it for my next post(s), I’ll edit out all the terrible mistakes on the fina version!

Setting up a LED Matrix can quickly get you out of pins to do other things with your Arduino. One way to overcome this is to use a 74HC595 shift register.

This chip transforms bits that are inserted in series trough the data pin into 8 parallel bits. More on that later, but first, the circuit:

The connection between Arduino and the matrix columns is the same as without the 595. Just plug it to the right pins with a resistor in the middle (I used a 330Ω) and you’re done.

Pins QA-QH on the 595 are the outputs that we want, so they’re connected to the matrix rows. Don’t worry about QH*.

The other interesting pins are:

• SER (SERial) where the data gets in;
• SRCLK (SeRial CLocK) the pin you set to high to store what’s in SER;
• RCLK (Register CLocK) the pin you set to high once you’re done setting all the pins.

So here’s how it works. Let’s imagine you want to set the QA-QH to 10010010. You start with the least significant bit (0) so you set SER to LOW (D10 on the Arduino). Next, you set SCK (D11 on the Arduino) to HIGH and then to LOW, to “save” the value.

Time to go to the second bit, which has value 1. So you set SER to HIGH, and again you set SCK to HIGH and then to LOW.

You keep going, until you’ve sent the 8 bits. At this point, you set the RCLK to HIGH to sent your changes to pins QA through QH.

This may seem complex, but fortunately Arduino has a function that takes care of sending that bits out to the shift register:

shiftOut(dataPin, clockPin, bitOrder, value)

This means that, to set data on the 595, all you have to do is:

digitalWrite(RCK_PIN, LOW); 
// Write byte_to_write to SER, using SCK_PIN as the clock and 
// send the least significant byte first (LSBFIRST)
shiftOut(SER_PIN, SCK_PIN, LSBFIRST, byte_to_write); 
digitalWrite(RCK_PIN, HIGH); 

Cool, isn’t it?

So here’s the full code for the LED matrix, using a 595:

If you run this code you’ll get a nice smile! If you want to build a different character, head over to the character builder and create your own.

You can get the code and schematics for this project on github.

Using a 74HC595 to control a LED Matrix was originally published in Arduino Playground on Medium, where people are continuing the conversation by highlighting and responding to this story.