I just gave a talk at iOSDevCampDC 2017 about building an Internet of Things bridge in Swift on a Raspberry Pi. Here’s the deck on SpeakerDeck, and I also exported the slides with my notes into a PDF:
Download Slides with Notes (PDF)
Also, here’s my demo video:
My Doorbell Runs Swift DEMO on Vimeo
I recently gave a talk on implementing an Internet of Things bridge in Swift using a Raspberry Pi. If you’re interested in following in my footsteps, here’s a quick abridged guide on how to set up your Pi. Many smart people have done the heavy lifting here, I’ve just put the building blocks together. Where appropriate, steps link out to these external tutorials with more information.
The best distribution of Linux for running Swift on Pi is Ubuntu Mate. Version 16.04 is recommended for compatibility with Swift. You can find instructions for installing it on your Pi here.
Swift is open-source and supports Linux as a platform for running the compiler. Getting the whole thing standing up on a Pi is a bit complicated, but luckily Umberto Raimondi has provided an amazing service by hosting precompiled Swift binaries for the Raspberry Pi 3. Instructions for installing those are available here.
I found that the easiest way to get a Vapor project started is to just clone a simple sample project and build off it. Here’s a good starting point, git clone this to a directory on your Pi.
My project used additional libraries, SwiftyGPIO and vapor-apns. To install these, add the following dependencies to the Package.swift file:
.Package(url: "https://github.com/uraimo/SwiftyGPIO.git", majorVersion: 0),
.Package(url: "https://github.com/matthijs2704/vapor-apns.git", majorVersion: 2)
Then, run a swift package install
If you want to access your Pi from outside your network, Dataplicity hosts a remote access service designed for Raspberry Pi, and it’s currently free for one device! I can’t recommend them enough, they even provide an externally resolvable hostname for your Pi to use, so you can connect to it from the internet. Here are instructions for setting up Dataplicity
That should be it! You should now have everything you need to do cool, Swifty IoT things with your Raspberry Pi!
If you have any questions or concerns, feel free to reach out on Twitter: @huebnerob
First up, a little background about me: I studied computer science at NYU for three years, then I transferred to Stevens to pursue mechanical engineering for another two. It’s all part of a dual-degree program between both schools that essentially allowed NYU to appeal to engineers while having no engineering department or school whatsoever (at least back when I entered). Suffice it to say Stevens filled the gear-shaped hole in NYU’s heart, until NYU went and bought a little place in Brooklyn *cough*NYUPoly*. Either way, I enjoyed the benefits of both schools, both the breadth of a city university and the closeness of a college campus in Hoboken. If for nothing else, it was often an interesting contrast.
At NYU, class sections tended to follow patterns in their scheduling. They would meet either Monday/Wednesday or Tuesday/Thursday, for the same 75 minute time period each day. Recitations and labs could meet later in the day, or on Friday, and there were plenty of choices for all. My transfer to Stevens was what taught me that I had been taking this sanity for granted; schedule chaos reigned supreme across the Hudson river in Hoboken, and for reasons still unclear…
My text editor doesn’t spoil many secrets, its title bar simply glows “stop_times.txt – nycsubway”. Below that, lines of gibberish seem to cascade downward endlessly, patterns coyly exposing themselves in streaks of data as I scroll down violently. In one file hides every single stop, made by every single train, running along every single route of the MTA New York City Subway. There are a few other files in the folder that can help describe some nuances, but stop_times.txt reigns supreme in its overwhelming size. One text file that *is* the entire Subway. At last count, it’s 522,670 lines long. I could spend my entire summer just scrolling that far, surely rubbing the pads of my fingers down to the bone in the process, but my plans are slightly more ambitious, slightly less crazy. Continue reading “It’s in the Data: TRANSient Beta.”
Aesthetic Design Algorithm for Public Transit Information Diagrams, ADAPTiD for short. As of yet, it’s just a dinky line simplifier that has been fed data from NYC’s PATH rail system, which connects Manhattan with points west across the Hudson. Yes, giving such a project an acronym already is perhaps akin to publishing my work on “Hello World”. This is true, but there’s no one out there to deny my request to acronym-ize myself so soon; perhaps I’ve abused this liberty.
So why does the world need a program that can automatically generate subway maps? Well if you’re anything like me and you live in a city, public transit is how you get around. You refuel not at a gas pump but at a MetroCard machine. You laugh as drivers kill each other over parking spots.
But then there are those times you’re left standing on a train platform — you’re waiting for a train that you must eventually admit will never come. Transit maps are designed to be accurate at one time: rush hour on a weekday. Every other second (which is a lot of seconds), you need to know what the exceptions are and what they mean. And when you start considering planned and unplanned service disruptions, that map might never be accurate. So keep on waiting, that train’s not coming, not today.
But what if you could design a subway map that’s always right? It would look at the day and time and show you only the service that’s running. If you’re lucky, it would even check for reroutes and suspensions, and adjust itself accordingly. I think we have the technology.
