Abstraction: An abstraction is a representation of an object or concept. It could be something such as a door, a speedometer, or a data structure in computer science. Abstraction decouples the design from the implementation. The gauges in an automobile are an abstraction of the performance of a car. A map is an abstraction of the earth.
Data Hiding: Data hiding is the technique that does not allow certain aspects of an object to be observed or accessed. Data and information hiding keeps the programmer from having complete access to data structures. It allows access to only what is necessary.
Minimization: Minimization refers to having the least functionality necessary in a program or device. The goal of minimization is to simplify and decrease the number of ways that software can be exploited. This can include turning off ports that are not needed, reducing the amount of code running on a machine, and/or turning off unneeded features in an application.
Modularization: The concept of modularity is like building blocks. Each block (or module) can be put in or taken out from a bigger project. Each module has its own separate function that is interchangeable with other modules.
Resource Encapsulation: Encapsulation is an object oriented concept where all data and functions required to use the resource are packaged into a single self-contained component. The goal is to only allow access or manipulation of the resource in the way the designer intended. An example, assume a flag pole is the object. There are fixed methods on how the flag pole is to be used. Put the flag on, take the flag off, raise or lower the flag. Nothing else can be done to the flag pole.
In this lesson, we will explore a cool hands-on technology called Littlebits. Littlebits follows a component-based design paradigm using GPIO (or general purpose input/output) to let you easily make apps. We will learn how to plug and play bits together to make some simple inventions. Littlebits will be the central platform for the rest of camp and you will be using them in other lessons.
By the end of this tutorial, you will be able to:
web services
Mashup
web services with LittlebitsIntro to components using Littlebits Droids
Computational Thinking and Design Process using Littlebits Droids
In the last lesson, you saw how versatile, modular, and cool Littlebits was to work with. It was easy to plug and play different modules together following simple design patterns
to make simple designs and inventions. Now, imagine everything you saw before can be hooked up to the internet and controlled using a smartphone or online app. We are going to do THAT now!
To start we need to create an account:
register
Now that we have an account, we need to pair our cloudbit
(an orange module with cloud
written on it) with the Littlebits Cloud Platform
. To do that:
cloudbit
a name: I decided to call mine “Tim”.cloudbit
.usb power
module to a power source and then snap the blue module to the pink button
module.button
module to the orange cloudbit
module.led
module to the cloudbit
module.CloudBit
until the light blinks blue.litteBits_Cloud_somenumber
).cloudbit
will live on. (At UNO that will be: UNOGuest
).Note if you are trying to pair multiple cloudbits for the first time it can be difficult to make sure you are pairing to the right one, we will do them in sequence in the camp. Don’t worry though - once paired you shouldn’t need to pair them again unless you change the network.
The purple button on your screen is linked to your cloudbit
output
.
LED
output module to the cloudbit
(if you didnt already).button
on your screen.It works! With that, you just made your first IoT app
.
button
on the button
module.You should see your gauge go up! Now you have input and outputs routed through the cloud controller!
Unplug all of the modules on the CloudBit
usb power
module to a power source and then snap the blue module to the button
module.button
module to the cloudbit
cloudbit
to the wire
wire
to the droid control hub
wait for your cloudbit to reconnect (it will turn solid green)
littlebit inventor kit app
Web services
are, as the name implies, services that live on the web. You use these all the time - mostly without knowing it. The internet is built on top of them. Google, Dropbox, Youtube, Twitter, and Facebook are just a few juggernauts that provide and use many different web services. In this lesson, we are going to use a mashup service
called IFTTT (which stands for If This, Then That ). IFTTT is a great platform that talks to all kinds of other web services. One service it connects with is, conveniently, Littlebits
. This is an example of modularity because IFTTT
can swap out components for others easily.
cloudbit
to IFTTT
by pressing the automate
button in the Littlebits
cloud controller user interface.IFTTT
if you don’t already have one.recipes
that have already been made for you by the Littlebits team. A recipe
is a design pattern
that combines input and output behavior to do something cool. IFTTT
refers to recipes as applets
.Lets create a new applet
that sends an email when you press the button
module. For flair, lets assume R2 is talking to us.
IFTTT
and click the down caret next to your name.plus
icon to specify the if condition our applet will fire up on.Littlebits
by typing it in the search/filter bar.IFTTT
to access your Littlebits
API.cloudbit
from the dropdown and click create trigger to set this as the IF condition. Once selected you should see:If (littlebits) then that
plus
icon to specify the THAT condition.email
and then send me an email. You will be asked to link your email to your IFTTT
account (if you haven’t already). Go ahead and confirm your email.add ingredient
to see available input information. You should have, DeviceName
, TurnedOnAt
, and PowerPercent
options. You can customize the email message here if you want. I made mine an r2 button.button
module connected as input to your cloudbit
module.Check your email!
It worked!
This is a simple, but powerful tool. It also shows off resource encapsulation and abstraction. In terms of resource encapsulation, each of the services connected to IFTTT
have many functions. These functions are encapsulated in a service (e.g. email
in this example). The functions are also abstract because IFTTT
doesn’t need to know how they work, just that they achieve a certain purpose (e.g. send an email). This helps model or abstract the implementation away from the design.
Lets make an applet
that allows us to turn the cloudbit
output on with an email or text.
email
service.Send IFTTT an email tagged
option.nebraskagencyber
littlebits
serviceSetOutputLevel
of the three options available.cloudbit
from the dropdown.You should see: Before we test it, make sure your scratch program is still running
IFTTT applet
with the tag #nebraskagencyber
in the body.
Note it may take a minute to process
Lets make an app that lights up every time a new tweet on a certain topic happens. This requires a Twitter
account. If you don’t have and don’t want to create a Twitter account, feel free to skip this, but it’s fun!
Twitter
service. You will be asked to link your Twitter account first.New tweet from search
option.#nebraskagencyber
to only fulfill the IF condition if someone tweets the hashtag.littlebits
serviceActivate Output
this time. This will just turn on the output for 3 seconds.cloudbit
Try some different designs yourself. You can combine any services with any Littlebits sensors.
You could swap the sound maker output for move forward.
You could write a scratch app that listens for different voltage levels on the inputs and then uses if conditions to switch between them. Then you could send those different signal levels from either the littlebits cloud or from IFTTT.
E.g.
TBA
In this lesson, we saw web services, such as IFTTT
, can abstract away details about devices and instead focus on recipes or design patterns
to describe how things work. We also saw that by keeping functionality modular, IFTTT
can combine Littlebits
with many other services.
Web services use resource encapsulation to ensure that all functions related to the execution of an app or service are neatly within the scope of the service itself. IFTTT
relies on services to be encapsulated so that they can provide external services with the ability to use them without worrying about connecting to multiple other related services.
Data hiding is also important to prevent internal data in the service from being released outside of the service invocation
. Local data remains hidden, while interfaces
expose only what the service wants to release (for instance to IFTTT
). This also relates to minimization because services can turn ports and other access off except for the specific interfaces it wants to leave open for other services to use.
For more information, investigate the following.
Special thanks to Dr. Robin Gandhi for reviewing and editing this lesson.
Nebraska GenCyber
is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Overall content: Copyright (C) 2017-2018 Dr. Matthew L. Hale, Dr. Robin Gandhi, Dr. Briana B. Morrison, and Doug Rausch.
Lesson content: Copyright (C) Dr. Matthew L. Hale 2017-2018.
This lesson is licensed by the author under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.