To solve help their own team more easily write and share code, Temboo designed a new way to program called Twyla. It was originally just an internal experiment, but it wasn’t long before they figured out it was something special.
“It started from a bigger idea of how to get systems talking together, and rethinking at a really high level how to program,” says Vaughn Shinall, Temboo engineer and head of Product Outreach. Over a period of time that grew into a new visual programming language and an unexpected discovery: that Twyla is also a way to program connected hardware.
And right now, there is nothing else like it out there.
How Twyla Could Change Hardware Programming
How does Twyla work? It visually choreographs how everything will live on the cloud, connects the hardware via Temboo’s other product, and makes memory constrained devices like Arduino (the hardware they support now) capable of more than they would ever be otherwise. In simplest terms: They’ve created a shortcut for making dumb hardware seem smart. By moving the “brains” into the cloud.
“You can create really complex chains of processes in Twyla so that you can have a device that in itself seems rather dumb, but if it’s connected to the Internet it can call up a complex process,” says Shinall. “All of that intelligence and processing is actually being offloaded.”
For Shinall and his team, the discovery started with Spotify. “Shortly after we introduced support for the Arduino Yún, we started getting support questions from people working with Yúns who were still running out of RAM on their boards,” Temboo product engineer John Sigmier explains. “One of our product engineers decided to spend some time building an elaborate project from scratch to get a good sense of what issues our users might be experiencing.”
The engineer started playing. He programmed a Yún to interface with the Spotify app. When a song came up on Spotify that liked, he would push a button and his friends would be sent a playable URL for the song via Twitter. It’s nothing you can’t do with Spotify anyway, but running it through the hardware made it a good test project.
“Doing this involved several steps and multiple Choreos and hardware as well as software. It was an ideal test. And sure enough, many of the same RAM issues users were describing showed up,” says Sigmier.
“It was at that point that Twyla appeared to us not just as an ideal tool for building our library,” Sigmier continues, “but also as an elegant and effective way to maximize the capabilities of otherwise limited hardware devices.” And then the lightbulb went on.
That single realization marked an important shift in the company. It was the moment when the team seriously moved into hardware and started learning what it means to program it (hint: it’s a different mindset than software). What have they learned since? How different the hardware mindset is than software. And how Twyla can help to visually code and smooth those processes.
If you’d like to mess with it yourself, here are their three biggest pieces of advice for building hardware with Twyla.
The most common problem the Twyla team sees in hardware: memory constraints. How do you work within the parameters of a small, limited device? How do you manage when RAM is a barrier? Sigmier says the best solution is to change your mindset–and your order of operations.
“In hardware in general, it’s a different way of thinking about programming from what we’re used to,” Sigmier explains. “You’re trying to do something physical and you’re dealing with physical roadblocks–force, power.”
Shinall puts it this way, “It requires careful thought in terms of what can live on the device as well as what can be taken care of with a cloud service. A lot of what we think about is how to put the cloud inside devices.”
What are a few rules of thumb for how to decide? If you’re using Twyla, “only three tasks must run on the hardware itself,” says Sigmier, “and none of those three will necessarily appear in every program.”
“The first task is the acquisition of some sort of input”– the moment when a program is meant to be triggered by an external stimulus such as a button push or sensor value above or below a certain level. When that happens, says Sigmier, “the code to register that stimulus must be on the device.”
“The second task is the calling of the Choreo itself,” Sigmier explains. “If the program is triggered on the device, the command to run on the cloud must come from the device. “And the final task governs the behavior of the device’s outputs.” That is to say, if you you want to program your hardware to do something in response to your Choreo, such as turn on a light or a motor, the activation code has to run on the device as well.
“Otherwise,” Sigmier says, “everything else can happen on the cloud!”
Shinall’s biggest piece of advice for programming hardware: to remember that imagination is key. “Imagine anything you will. Because with the cloud and with all these web services, you can do quite a bit in the digital world. But think very hard about exactly how you want that packaged,” he says.
Imagination can go a long way in hardware–and it can be used in unexpected ways. One example: a Willy Wonka chocolate machine one hardware guy made his girlfriend for her birthday.
“This is actually a story from one of our users,” Shinall says. “He wanted to build a device that would dispense chocolate based on comments. It was in response to happy birthday wishes on his girlfriend’s Facebook wall.”
The issue their user was facing was that wanted to do a lot with a small, memory constrained device without having to build a major backend. “They’re easy and simple tasks,” says Shinall, “but if you were to start coding this [to identify appropriate comments then activate the hardware] it would probably be difficult and too much for the hardware in hand.” To solve the problem, the team used Twyla to help him build his own process–using the cloud to handle the memory-intensive bits. It’s not an earth-shaking example, but it does show that what you imagine you can build. And that geeks give sweet gifts.
“We’ve stayed in touch with him,” Shinall says. “As a side note, it was apparently very successful.”
What is their last big piece of advice? To think about how what happens once the hardware is deployed, and to make it so it can easily be changed in the future.
“If you want to change the device later on, a lot of what you can do with Twyla is go into it without ever having to go back and touch the device itself, re-upload the code to it, or reboot the device,” says Shinall. It is an important point, and a benefit of having cloud-connected hardware. Particularly if you’re working across multiple devices. “If you think about on an industrial level, if you deploy 1,000 devices across a municipality or a neighborhood, you’re not going to want to go to each device individually as it’s deployed and upgrade its firmware,” he says. “It’s really about thinking of ways to make devices be flexible and be able to be compatible with what’s coming up. Which we don’t always know.”
While it Twyla still experimental, it is pretty clear: It is a cool new tool for hardware builders. However, even if you don’t play in hardware, it is worth paying attention. There is something bigger about the system that you should note–because it represents a trend in how the programming world is evolving. Namely, that Twyla is built around a visual interface.
Part of a modern developer’s experience is interacting with other people’s code, and that means making it easy to understand. “If you’ve every done any introduction to computer science, there’s this law that you need to comment your code,” says Shinall. “You need to make it so that it’s readable by other people who might come along.” But with open source as a major force in technology and even big companies like Tesla starting to open up their IP and share what’s under the hood, the idea that what you build should be shareable is becoming even more important.
And that’s exactly why visual programming starting to take hold. “With a visual interface, if I build something and I want to share it with you, it’s going to be much easier for you to see, understand what I’ve done, and to modify it or use it in whatever way you come up with totally independent of my initial ideas,” he says. “A picture is worth a thousand words.”
More and more leading-edge developers are playing with visual programming interfaces. David Rutten built a tool called Grasshopper that is a visual interface for programming, like visual basic without the basic; he’s shared all iterations on YouTube. Dynamo is an open source visual programming language add-in for Autodesk software–an open source tool that allows graphical programming and design. (Or, in their language that “allows designers to customize computational design and automation processes through a node-based interface.”) And most recently IBM has been working on something called Node Red. Just previewed at O’Reilly’s Solid Conference, it is a visual tool for wiring together hardware devices.
All of these examples are not only highly visual, but they also have the same benefit: They are all steps toward making the developer’s experience as elegant as that of the end user. CX, Coder Experience–it’s rising.
“More people are realizing the value of UX,” says Sigmier. “We’ve reached the point where that’s a real point of differentiation between services. What we think about a lot is not UX but CX for the developer experience. Thinking about the experience of the people who are going to be creating new tools, new applications, be it for hardware or software. Giving them a whole, full, and useful experience.” In practical terms what that means is creating tools that can allow people of varying skill levels to create complex processes. Making sure website interaction is smooth on both the front and backend. And being sure that documentation and code are elegant.
“I think it’s really thinking about the 360 degrees of a developer’s experience,” Shinall says. “We think about it all holistically.”