• The Tessel Crash Reporter service

    Friday, September 9, 2016

    TL;DR

    Do you want to know how the Tessel team identifies and fixes problems in the Tessel command line interface (CLI) without requiring users to reach out to the Tessel team? Say hello to the Tessel 2 crash reporter.

    Introduction

    The Tessel 2 crash reporter is a web service which automatically collects anonymized crash reports when a crash is detected in the Tessel 2’s CLI. Given that the CLI is one of the primary ways of interacting with your Tessel, it is important that the CLI be extremely stable and a joy to use.

    This project started during the early days of the CLI. We wanted to make sure that the team was proactively looking at and fixing issues as users encountered them. We wanted to make sure that the onboarding experience was as smooth as possible for new users.

    How it works

    Every time you use the Tessel 2 CLI, a central controller dispatches your command to an appropriate task handler. The crash reporter automatically checks for uncaught Errors and unresolved Promises in the node process that’s executing the task.

    Once the crash reporter detects a crash, it removes all personally identifiable information from the stack trace, and uploads it to the Crash reporter web service with the user’s permission. After the user opts-in the first time, subsequent crashes are automatically reported. Below is an example of what that interaction looks like:

    ERR! Detected CLI crash [Error: Testing the crash reporter] Error: Testing the crash reporter at  CrashReporter.off.CrashReporter.on.CrashReporter.sanitize.CrashReporter.sanitize.redactions.CrashReporter.prompt.CrashReporter.submit.CrashReporter.prompt.then.CrashReporter.post.CrashReporter.status.CrashReporter.test (/Users/rahulrav/Workspaces/Tessel2/CLI/lib/crash-reporter.js:177:25)
    
    at process._tickCallback (node.js:406:9)
    at Function.Module.runMain (module.js:449:11)
    at startup (node.js:141:18)
    at node.js:933:3
    
    INFO Detected a crash in the CLI. Submit crash (y/n) ?
      If yes(y), subsequent crashes will be submitted automatically.
    

    We put a great deal of thought into potential privacy issues, and decided to make this feature opt-in. The user can also turn off crash reporting simply by using one of the below options.

    Usage: t2 crash-reporter [options]
    
    Options:
      --off    Disable the Crash Reporter.
      --on     Enable the Crash Reporter.
      --test   Test the Crash Reporter.
    
    Configure the Crash Reporter.
    

    The service

    The Crash reporter web service collects the crash report, and de-duplicates it using the Sim Hash algorithm. Sim Hash looks at the contents of the crash report and computes a unique signature (called the fingerprint) and also keeps track of the frequency of the occurence of the report. The service also provides a way to look at Trending crashes and also provides a full text Search API. The service itself is built using Google App Engine and the Python Runtime. The full source code for the service is here.

    Hi from tessel-crashbot

    Recently, we landed a really cool feature in the Crash reporter service. In an effort to simplify the worflow of the Tessel team, which manages all feature requests and bug-fixes using GitHub issues; the Crash reporter service uses GitHub’s API to automatically create and manage issues for every crash report. Anytime there is a new crash in the wild, the ever friendly tessel-crashbot is ready to help proactively keep track of the problem. The tessel-crashbot also updates the GitHub issue via comments when it sees an uptick in the frequency of a crash. This helps the team identify the severity of a crash report.

    Image of crashbot submission.

    #update #this week in tessel #twit #updates

  • This Week in Tessel: the busy summer issue!

    Thursday, August 25, 2016

    Hello, Tesselators!

    TL;DR:

    Tessel Community Survey

    We’re researching the next direction for Tessel Project hardware, and we have six questions for you.

    Help us out by telling us what the future of connected things should look like on this survey!

    Tesselcamp

    The Tessel Team (the Steering Committee and some of the Team Members) are meeting in person the first time at Tesselcamp next week.

    The event will be a low-key three-day session in New York City for core community members to discuss vision, focus on key issues, and spend time together as a team.

    The final day of Tesselcamp (Saturday, September 3) is a community day, in which members of the public are welcomed to use the hardware and expertise of the core Project members and get up to speed contributing to the Project. If you’re in the area, please come!

    For those not in the area, we encourage you to spin your own “welcome to open source” themed events. Want to host one in your local community? Get in touch; we would be happy to help.

    Nodebots Day Recap

    We mentioned International Nodebots Day in the last newsletter, with a special mention of the Johnny-Five Inventor’s Kit as the kit of choice for a few of the event locations, like NYC and Miami. The Tessel 2 was also used to power Sumobots at Houston’s event, with a great recap by Justin Gosses.

    Check out @nodebots on Twitter to see pictures and video from other events around the world!

    More Tessel: Links Roundup

    Things to try

    Things to watch and read

    That’s all for this week! Feel free to submit to the next newsletter. In the meantime, see you online.

    With love,
    Everyone at the Tessel Project

    This Week in Tessel is where we highlight the latest news, projects, and events, from code, to community, to hardware manufacturing.

    #update #twit #this week in tessel #updates

  • Meet a Tesselator - Kelsey Breseman

    Tuesday, August 16, 2016

    (@selkeymoonbeam)

    A somewhat tired Kelsey Breseman backpacking in Iceland

    A somewhat tired Kelsey backpacking in Iceland

    How did you get involved with the Tessel Project?

    I wasn’t involved much in microcontrollers, or even programming, before Tessel. I’d worked with both a bit in college, but it wasn’t a guiding passion for me.

    The summer after I graduated, I was living with several friends, including the team of three that was founding Technical Machine to build Tessel.

    I had a work-from-home contracting job at the time. Our apartment had no air conditioning, and Boston was really, really hot that summer. So I started showing up at Technical Machine’s office space, and grew interested in the proposition: how do you get people who have no idea what they are doing to try hardware – and not fail? How do you take the world of the Internet – obviously useful, but traditionally accessed via screens (pretty limiting and draining, in my opinion) – and better hook it up to the real world and to physical space?

    Within about a month of the company’s founding, I was showing up to work every day, writing about the project, getting more into programming, and getting involved.

    I can’t claim credit for the idea of JavaScript on a microcontroller, or the implementation (novel at the time) of Wifi on a microcontroller. But I am really proud of the influence I was able to have over the user experience. As a relative beginner in both JavaScript and hardware, I was always asking: how do we make this or that clear to people? How will this feature be understood by someone who has never picked up a wire before?

    As the project developed, I adopted an “I fight for the user” mindset and guided product development as Director of Community.

    Kelsey Breseman speaking at OSCON 2016: “How to build a product when nobody’s getting paid

    When we transitioned to open governance as the Tessel Project, I put together a lot of our new structure and rules and became one of the four founding Steering Committee members. Together, we (now five of us) run the project.

    What do you like best about being involved with Tessel?

    It has been exciting to watch this project and community grow.

    I travel around the world giving workshops on Tessel, and I love that moment, every time, when a person’s face lights up.

    “Oh my gosh!” they say. “It did something! I made it do something!”

    Most of the people I teach Tessel to are people who have never had a success with hardware before. Sometimes, I’m also teaching them to code– that’s a lot of fun.

    Kelsey Breseman live coding on Tessel 2 at NodeConf Oslo 2016

    The other piece that I love is building connections between people– inspiring them to work on things together.

    Community is powerful. If I were to take on the whole of the Tessel project by myself, it would die pretty quickly. But if I can inspire a few people to work with me on it, we can get a lot done.

    One of the biggest challenges is figuring out how to keep a distributed team inspired and engaged. Our team members mostly haven’t met each other!

    It’s an ongoing social experiment for me to create tools and practices that make people want to keep coming back.

    Kelsey Breseman and Flaki (István Szmozsánszky) discussing Tessel at RuhrJS

    I absolutely love when I go off in the woods for a few days, come back to the internet, and discover that someone I’ve never met or heard of has started working on one of our repos. Or, when community members ask support questions, and other community members respond without anyone from the official Team being involved. That feels like community success.

    Outside of Tessel, what are you working on right now?

    I’ve been thinking a lot about climate change recently: reading books and articles on the subject, trying to wrap my head around all the issues at play and the opportunities they create. I’m blogging about my thoughts and taking copious notes, both as a way to help me think.

    The plan is to start a company in this space, though I’m not sure yet of the exact proposition. Climate change is going to require a lot of people to work hard on interesting new problems. I would like to be involved in connecting smart people to interesting, meaningful problems.

    Do you have any advice for people who want to get involved with the Tessel Project?

    Jump in with both feet. We’ll catch you.

    People are sometimes nervous to start contributing to the Tessel Project. By its very nature, it gets people from one field interested in another field they don’t know much about (web, hardware, and vice versa).

    My advice: contribute even if you feel completely unqualified. We have a number of open starter issues.

    This is how you learn. It’s hard. You feel stupid. You put yourself out there on the internet. But we’re here, and we want to help you.

    Sometimes, what you need is a good project to learn on. Tessel was that project for me, and I hope it can be for you, too.

    Love,

    Kelsey Breseman

    #kelsey breseman #meet a tesselator #tessel project

  • Interfacing with the Language Plugin API for Tessel 2

    Tuesday, August 9, 2016

    This month we merged one of the most significant pull requests for the Tessel project: adding Rust deployment support. For the past three years we’ve focused exclusively on deploying JavaScript on microcontrollers. This is our first step investing in a new language, a new ecosystem, and a new community. However, the purpose of this post is not to dive into the benefits of Rust, but rather to showcase the ease of adding new language support to the Tessel CLI.

    Despite the significance of this addition to the CLI codebase, the amount of code we modified was relatively small. We simply added two main files (along with minor modifications to a handful of other tests): one with the implementation and one with unit tests. The simplicity of the feature addition is a testament @rwaldron’s hard work building the CLI’s language plugin system. In this post, I want to demonstrate how straightforward it is to add support for a new language to the CLI using this plugin system.

    You can deploy an arbitrary code bundle to Tessel 2 (in any language) with the same six general functions:

    1. Determine project location in the file system
    2. Run any compilation/pre-processing steps (optional)
    3. Bundle the executable code into a tarball
    4. Run any pre-execution steps (optional)
    5. Execute the code/binary
    6. Run any post-execution steps (optional)

    These functions are more concisely named checkConfiguration, preBundle, tarBundle, preRun, shell/binary, and postRun (respectively). Here is an explanation of each of those interfaces.

    1. checkConfiguration

    checkConfiguration accepts the directory that was deployed with t2 run ... and returns the path to the entry point of the project. With Rust, we do this by parsing the Cargo.toml and with JavaScript we parse the project’s package.json. It is expected to return an object with a basename and optional program property (for the name of the project).

    // checkConfiguration to confirm project deployment files
    exportables.checkConfiguration = (pushdir, basename, program) => {
      // Should return the file information for the program
      return {
        basename,
        program
      };
    };
    

    2. preBundle

    preBundle is an optional step for any processes that need to be run prior to packaging the directory that will be sent to the Tessel 2. For example, when deploying JavaScript, this function is integral to the binary compilation stage (where we inject our pre-compiled binaries in place of existing project binary dependencies). For Rust deployment, this step is less critital but we use it to set some optional parameters (which we could do in the next function as well).

    // Optional function to process options prior to bundling project
    exportables.preBundle = function(options) {
      // Should return a Promise which gets resolved when the code is ready to be tarred
      return Promise.resolve();
    };
    

    3. tarBundle

    tarBundle is a required step which should resolve a Promise with a Buffer that represents the tarballed code or binary. The CLI will automatically untar the bundle after it is deployed on the Tessel 2.

    In the case of Rust, this was the biggest addition. In order to compile Rust code for Tessel, we needed to set up a special cross-compiler that could compile a binary that runs on Tessel’s MIPS architecture. The easiest solution was to have the CLI send out the project to a preconfigured remote cross-compilation server. The server then compiles and returns the binary to the CLI.

    // This must implement a Promise that resolves with a Buffer
    // that represents a DIRECTORY containing the desired bundle.
    exportables.tarBundle = function(options) {
      // Should return a Promise which eventually gets resolved with the bundle
      return Promise.resolve(bundle);
    };
    

    4. preRun

    preRun is an optional step that’s useful if you need to call any shell functions on Tessel itself before the project is initialized. For example, with Rust, we set the permissions of the binary to ensure it’s executable. It’s unused for JavaScript.

    // Optionally make changes within Tessel's Linux environment before starting the program
    exportables.preRun = function(tessel, options) {
      // Should return a Promise which eventually gets resolved
      return Promise.resolve();
    };
    

    5. shell/binary

    t2 run

    binary is a string that represents the engine that runs the program. It is used as the first argument in a shell command to start the program when a project is run. For JavaScript, this string is node and for Rust it’s ..

    t2 push

    shell is a function that could have been named begin because it’s responsible for actually getting the program going when you push the project. The reason it’s called shell instead is because the function needs to return a string representing the contents of a shell script that starts the program.

    exportables.binary = 'YOUR_EXECUTION_METHOD';
    exportables.shell = (options) => {
      return tags.stripIndent `
        #!/bin/sh
        exec YOUR_EXECUTION_METHOD /app/remote-script/${opts.resolvedEntryPoint}
      `;
    };
    

    6. postRun

    postRun is another optional step that’s useful if there is code you need to run on Tessel after the program has started (but not necessarily before the program has ended). It’s largely unused thus far so far but was added for future-proofness.

    // Optionally make changes on Tessel after starting the program
    exportables.postRun = function(tessel, options) {
      // Should return a Promise which eventually gets resolved
      return Promise.resolve();
    };
    

    Conclusion

    That’s just about all there is to adding language support to the CLI. There are several more steps that need to be taken to build full hardware support for a language on Tessel. You can follow Rust’s progress in that process here.

    If you have questions about the unit tests or the implementation of new languages in general, feel free to reach out in the #engineering channel of Tessel Slack. Let us know if there are any extra plugin functions you think the CLI needs to accomodate or if you need help building a plugin for the language you’d like to build hardware with.

    • Jon

    #tessel rust programming language plugins deployment compilation

  • This Week in Tessel: the awesome community issue!

    Friday, July 29, 2016

    Hello, Tesselators!

    TL;DR:

    Vision and Forward Motion: Development Updates

    Kelsey Breseman of the Tessel Project Steering Committee has just published a post with the Project’s long-term vision: Where are we going with Tessel? Rust, Reach, and Fractal

    International Nodebots Day

    NodeBots Day is world wide event where people learn how to control the physical world with JavaScript. Each event has experts on hand to help attendees build their projects and start them on the path to building awesome devices. Overall, it’s about getting together, collaborating and hacking. And lots of JavaScript. This year some events will using the new Johnny-Five Inventor’s Kit (J5IK), which includes the Tessel 2!

    International Nodebots Day: July 30

    More Tessel: Links Roundup

    Things to try

    Things to watch and read

    That’s all for this week! Feel free to submit to the next newsletter. In the meantime, see you online.

    With love,
    Everyone at the Tessel Project

    This Week in Tessel is where we highlight the latest news, projects, and events, from code, to community, to hardware manufacturing.

    #update #updates #this week in tessel #twit

July 2017

February 2017

November 2016

October 2016

September 2016

August 2016

July 2016

June 2016

April 2016

March 2016

February 2016

November 2015

September 2015

August 2015

July 2015

June 2015

May 2015

March 2015

February 2015

January 2015

December 2014

November 2014

October 2014

September 2014

August 2014

July 2014

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013