• Dominik Wind: Creating a Tangible Vision for a Sustainable, Open World

    Friday, March 13, 2015

    3/13/15– Kelsey Breseman

    I was introduced to Dominik Wind through a friend I made at MozFest, a several-floor consortium of chaotics working together to change the world through open source projects. When we think of open source, we tend to think of open source software, or some think of open source hardware in the embedded sense, but the movement is broader. Open source is about information flow– within companies, countries, and communities.

    Dominik is working on OpenState, which hopes to bring together several of these communities and create a tangible vision for an open and sustainable world. Right now, OpenState is putting together POC21, an ambitious five-week project that will take place leading up to the UN’s climate change conference, COP21 in Paris.

    Kelsey: What is OpenState?

    Dominik: OpenState is an organization that we founded in early 2012. Me and my friends, we were all working for NGOs, but we all had the feeling that it was not the most we could do. It was work that didn’t hurt, that paid the rent, but it didn’t feel satisfying anymore. We were looking for ways to create more impact within our lifetime.

    We really care about topics like resource depletion and climate change. We were working on that before, but we founded OpenState to fully focus on that. For us it’s all about developing sustainable ways of life, which includes production, manufacturing, and consumption habits.

    We think that social processes and group processes can be a very powerful tool for change. Most people only focus on technology, so we easily jump to technology as the one and only option for finding solutions. We wanted to focus more on the behavioral side of things– which still includes technology, but it’s also more than that.

    OpenState is a laboratory for exploring these processes: what do we need for a sustainable society besides the technology?

    Kelsey: What is an example of making changes through processes?

    Dominik: Everything that touches you emotionally opens you up to changing your opinions. What we do is bring together people who have diverse skillsets and also cultural backgrounds and try to create a world in our work. It’s an experimental space where you prototype whatever is the topic. So if it’s the future of work, for example, you simply behave like you would be in that different world.

    You behave like the future is already there: if I could make everything perfect, what would that perfect environment be?

    The same thing, we are trying now with OpenState in Paris regarding sustainability. What would a family, or a neighborhood, or a friendship group, how could we live more sustainably without giving up the standards of life that we have today?

    The interesting thing is that when you get people together in such an intense experience, they reinvent themselves. Nobody knows each other, so everybody tries to live up to his or her best version. You can restart in a way, and pretend to be whatever you want to be. And then the time is long enough to get into habits. You exercise of practice something as a habit for some weeks, and that really has an impact on you, that really changes your behavior.

    We often hear from participants in former camps that they changed their lives. It’s really a pretty powerful situation.

    Kelsey: So what’s the plan for for POC21?

    Dominik: This camp will be five weeks of living and working together in the beautiful Château de Millemont near Paris. It’s called POC (proof of concept) 21 because it will be around the climate negotiations of the UN in Paris in December, COP 21.

    Kelsey: What do you expect in terms of tangible results from POC21?

    Dominik: We are aiming to find solutions or technological approaches to satisfying basic needs: how to produce energy, food, water, communications, shelter, and mobility. Within those five areas, we will invite open source projects that are already working on that; we won’t start at zero.

    By the end, we hope to include all these parts into one holistic prototype of that potential sustainable future, so you really can have a festival in the end where people can come see what this “future living” could look like.

    You can step into that Wikihouse, for example, with that open energy monitoring system installed, where you understand, here I can see my energy consumption, here I can control my impact. Make it tangible for people.

    And then, they get the story of, it’s produced in a different way, it could be locally produced, it’s repairable, everything’s open source, the average craftsman wherever you live could open these things and get it fixed without you having to re-buy the next thing. Then the whole story comes in on why certain products might be more sustainable than others.

    But first it needs to be this experience: touch things and understand it’s real.

    Kelsey: What do you see as the primary tangible outcome?

    Dominik: Currently there are hundreds of potential solutions and different groups around the globe that are at different stages of their product development.

    We aim to offer an online platform and an on- and offline catalog where we showcase the solutions that are ready for broader audiences beyond the maker and hacker niches. We showcase the ones that are for average people– like if my parents want to buy a new washing machine, they should easily get access to the best open source washing machine.

    Most platforms online for this show all potential options, and normal people quickly lose orientation. They are simply overwhelmed with hundreds of projects, and all of the details.

    We also hope to kind of showcase things in a shop format. We will start in Berlin, and have an “open everything” shop. What you can get there works, but it’s fundamentally different. It’s still a lamp, or a desk, or whatever, but it’s produced differently, and it can be repaired, or you could rebuild it yourself if you have the skills.

    All of this, and then it will also be about the media outreach in the uprun to the COP21 conference, showing that it’s not all too late.

    We expect that the UN talks in Paris will be like always: you will have the politicians negotiating; outside, you have normal people, saying it needs to go faster, or differently, or whatever, in between police, you will have some demonstrations, maybe you will have some riots. At the end they will have the press conference, saying yeah, they have some very minimal improvement on something, and then everybody goes back to normal.

    We would like to have a new narration on that: there are people who have already started on creating a more sustainable way of doing things, it’s going around the globe, and it’s a movement you can join. Or at least you can start using different products that are designed and produced on a very different basis.

    OpenState

    Kelsey: What are some of the biggest blockers for people who want to use products from this movement?

    Dominik: Communication and IT stuff is probably the hardest, I think. The open source scene is really small, and the open source hardware scene is even smaller, and before that you have digital literacy, basically. Like my mom, if something doesn’t work automatically with her computer, she has no idea what it could be. It’s just not working.

    For all the other things, average people can rely on crafts and craftsmen. Open Desk, for example, offers an online platform where you can upload designs for chairs and desks and tables. People can buy designs and they get shipped, or you can download the designs for free, and produce it yourself. The entrance barrier is lower for most people, to pick up their drill and saw, it’s simply easier for most people than microcontrollers.

    Kelsey: What sort of labs and materials will you have at POC21?

    Dominik: We have partnered with all kinds of hacker and maker spaces in Paris, and with fablabs.io, the global network for FabLabs. We’ll have some machinery right onsite, at the castle, and we will also get maker spaces in Paris involved to produce certain things.

    I think the only thing that we are creating from scratch is the media outreach. We have to find the right stories, and the right timing regarding COP21.

    Everything regarding prototyping and tech development and coding and stuff like that, will be a blend of groups, tools, and spaces that are already there and are up and running.

    Kelsey: At POC21, you’re hoping to have a mix of people from a variety of different backgrounds, right?

    Dominik: Yes: engineers and coders, but also people from many other backgrounds. When we develop tech today, the mindset is strictly focused on coders, engineers, and maybe you have some business people involved. But I think our tools are forming our reality. The things we use create certain habits, and these habits become a part of us.

    Development of technology changes our behaviors and our perception of the world. This development of technology has had a huge cultural impact on everyone. It’s not just a market thing, as we mostly treat it at the moment. There are also spiritual questions, and social questions, and questions of how we actually want to live as a society. These all should be integrated into good product design. It’s really a powerful tool for cultural change.

    Ed. note: you can see a video about the vision of POC21 here

    #openstate #open source #oss #oshw #dominik wind #opencamp #POC21 #COP21 #sustainability

  • Tessel 2 Hardware Overview

    Tuesday, March 10, 2015

    3/10/15– Eric Kolker

    Hey Tesselators, Eric here. Since we announced Tessel 2 last week, we have gotten a lot of questions about the new hardware.

    Tessel 2 boards

    Shiny new boards back from the manufacturer!

    Tessel 2 at a glance

    We packed a whole lot of hardware in there:

    • A 580MHz WiFi router system on chip (Mediatek MT7620n) running linux (OpenWRT)
    • 64 MB of DDR2 RAM
    • 32 MB of flash storage
    • 2 High-speed USB 2.0 ports
    • a micro USB port
    • A 10/100 Ethernet port (RJ-45 jack)
    • A 48MHz ARM Cortex M0 microcontroller (Atmel SAMD21)
    • Two module ports that are much more capable than their predecessors
    • a button and a bunch of LEDs, because what’s a Tessel without blinky?

    The board’s bill of materials and physical characteristics are only part of the picture. We spent a long time thinking about how we wanted to architect Tessel to push it beyond “another dev board” and clear into “this platform is exactly what I needed!” territory.

    A few features under the hood (in addition to the ones current Tessel users know and love, including the expansive plug-and-play module ecosystem and high-level language support for low-level hardware features) include:

    • Router-grade 802.11b/g/n WiFi, including access point mode (Tessel can be a router)
    • 16 GPIO broken out as a pair of multi-purpose module ports
    • Individual control over and protection for all outward-facing power buses (USB and module ports)
    • A form factor designed for abstraction and flexibility in the hardware, software, and mechanical worlds as you scale from prototype to production

    Abstraction boundaries

    One of the things which makes software so powerful is a heavy emphasis on frameworks and abstraction. Although there is no shortage of “standards” (official or otherwise) in the hardware space, one thing nobody has done particularly well yet is cleanly and clearly share abstraction boundaries between the hardware and software layers. We’re looking to change that.

    The high-level system diagram for Tessel 2...and most other single-board computers, too.

    The high-level system diagram for Tessel 2…and most other single-board computers, too.

    The diagram above is a high-level system diagram for Tessel 2. Let’s dive into where we drew the lines internally.

    The board employs a processor/coprocessor architecture. The Mediatek runs your user code, hosts USB devices, handles the network connections (be they wired, wireless, or cellular over USB), and communicates with the SAMD21.

    The SAM acts as a coprocessor and handles real-time, low-level IO through the module ports, USB comms through the Micro USB port, and programming the device as a whole.

    The two chips are connected by a SPI bridge that also includes the onboard flash (the readme for Tessel 2’s firmware repo goes into more detail here).

    The whole system is powered from the single Micro USB (device) port, and its specific functional blocks look more like this: Functional blocks of Tessel 2

    Functional blocks of Tessel 2

    This arrangement, which also very closely mirrors where the related parts are located on the hardware itself, allows us to draw the boundaries at the both the mechanical and conceptual level as follows:

    Functional groups in Tessel 2’s architecture

    Functional groups in Tessel 2’s architecture

    Or, on the board itself: Functional groups on Tessel 2’s prototype hardware

    Functional groups on Tessel 2’s prototype hardware

    Consciously drawing these same boundaries when creating both the software and the hardware lets us make developing on the Tessel platform simple and consistent throughout an entire product cycle, which is a huge win. I’ll talk more about this in another post, but suffice it to say that most of the optimization and integration story relies on the fact that we kept these boundaries at the top of the list when making design decisions about how to build Tessel 2.

    New and improved module ports

    The two module ports on the new Tessel look and behave the same as the ones on the original board, but they’re actually a lot more versatile. In fact, don’t lock yourself into thinking that they’re “just module ports”; think of them as mini GPIO banks. Each pin on the two 10-pin headers is unique and can be reconfigured to do almost anything from speaking alternate comms protocols to clock generation. For example, if you decide you don’t want SPI, feel free to give yourself another I2C or UART with minimal changes to the SAMD21’s firmware. Touching only JS, you can forgo the fancy comms in favor of just plain GPIO, which gives you access to as many as 16 of them.

    Plus, a nifty new power architecture gives you individual control over the 3.3V rails on each port, so you can turn modules off when they’re not in use to save power. This essentially converts the 3.3V rails on the ports into two high-current (at least 250 mA) output pins that just so happen to power modules most of the time. …Or, put another way, this is our pass at solving hot-plugging for low-level hardware.

    Last but not least, all eight pins on Port B are also inputs to a 12-bit, 350ksps ADC, with adjustable gain that can operate in differential mode, if that floats your boat. Not too shabby.

    Close

    We’re pretty excited about the new hardware and what in enables, and hope you are too. It’s been in the works for a few months now, and at this point it’s time for us to start cranking out docs and answering questions, so don’t hesitate to reach out on the forums or over email.

    On the subject of docs, here is what we’ve released so far, including a preliminary schematic (full KiCAD project files are on their way soon). For now, head to our website to see more.

    Until next time,
    ~e


    This post has been translated:

    #Tessel #Tessel 2 #eric kolker #technical machine #hardware #features #electrical engineering

  • Moving Faster with io.js

    Friday, March 6, 2015

    3/6/15– Jon McKay

    After building a custom JavaScript engine for embedded devices, we’ve made the decision to transition to io.js for our newest hardware offering: Tessel 2.

    Tessel 1 & Tessel 2

    We had been developing Tessel, a JavaScript powered, Node.js compatible microcontroller, for almost two years. In order to run JavaScript on a Cortex-M3 device, we had built a custom minimal runtime that “transpiles” JavaScript code to Lua and runs that Lua code on a Lua VM. While we are proud of the progress we’ve made with the runtime and extremely grateful for all of the developers who have contributed code, a shift to running io.js on V8 better suits the immediate needs of the community.

    Overall, I strongly believe that this change will make for a much more consistent and robust development experience on the Tessel platform. This shift was motivated by a confluence of factors including power consumption, JS/Node compatibility, and budding story for npm modules with binary dependencies.

    Power Consumption

    When it comes to running JavaScript and Node, the implementation pathway is to either use an existing runtime like V8 (often on top of Linux) or build a custom runtime. Originally, we decided to build our own runtime so that we could put JavaScript on an ARM Cortex M3, thus opening up the opportunity for lower power consumption and “realtime” IO (as compared to using an OS scheduler).

    For a variety of reasons, but primarily the power consumption of the CC3k WiFi chip and the 32MB of SDRAM, optimizing power consumption on Tessel has proved to be futile. For comparison, the Raspberry Pi B+ (running a Linux distro) uses slightly more than 1 Watt of power and Tessel uses ~.85W at 5V. Certainly, taking proactive measures such as aggressive on/off management of the WiFi chip, batching network requests, and only running JavaScript on intervals can reduce this consumption, but not by enough to get weeks or months of battery life. In short, if you’re trying to build a truly low-power application, WiFi is not the right protocol to use and you don’t want to be using JavaScript on the device. If you are using WiFi with a high level language, you’re going to need more power, so you might as well have all of the extensibility and reliability of Linux + V8 instead of a fledgling RTOS.

    JavaScript and Node.js Compatibility

    Perhaps the most pressing reason for using V8 is the promise of JavaScript and Node.js/io.js compatibility. We believed that over time we could cover all of the corner cases of JavaScript with our own runtime, but perhaps we should have taken a cue from the “Wat talk” that it was going to be an uphill battle. While the semantics between JavaScript and Lua are very similar, they are also just slightly different in many ways (For example, the comparisons between null vs undefined vs falsy), and capturing all of those idiosyncrasies has proved frustrating for both the users and developers of the Runtime.

    In addition, the Node.js landscape has shifted. We’ve seen the io.js team fork the Node.js project and start developing new features. We have been fortunate to have an external contributor add relevant Node libraries as submodules, but others must be implemented by hand in Lua. The maintenance and overhead of making sure new Node.js/io.js libraries are consistent with our runtime is yet another uphill battle. For that reason, we’ll be running vanilla io.js on a lightweight distribution of Linux (openWRT). io.js allows us to remain backwards compatible for folks looking to use Node.js, but lets us stay on the leading edge of development.

    I still do believe it’s possible to make a nearly compatible runtime, but it’s going to take much more work than we expected and that resource investment would be an unwise business decision.

    Binary Dependencies

    One consequence of rolling our own runtime is that modules with binary dependencies (the most requested of which has been ws for faster websocket support) are not be able to run on Tessel 1. These modules depend on C/C++ libraries which get compiled on the platform that installed them prior to being able to run them. In order to get these modules to run on Tessel 1, we would need to be able to link them against V8 APIs cross-compiled for ARM Cortex-M3, which would take a ton of development effort. Moving forward, we have a pathway for using these highly requested modules in development. If we use V8, we can stash popular binaries pre-built for Tessel 2’s MIPS architecture and send those over when requested by a project’s package.json.

    The Plan For Colony

    Colony is the name of Tessel 1’s original runtime. Going forward, Technical Machine will continue making small bug fixes in Colony but will not adding any new features. That being said, some of the Technical Machine team, including myself and Tim, are interested in maintaining and improving Colony at a personal level. We’ve thrown around the idea of getting the runtime on standalone, barebone WiFi chip, using only the onboard flash. We’re not retiring the runtime completely, but rather, putting it on the backburner for now.

    So how is this different from Pi/BeagleBone/Insert Linux-based Dev Board Here?

    Several people have asked us how we expect to differentiate ourselves from other Linux-based development boards. The Tessel platform is unique in that we believe we can deliver the best developer experience by abstracting away the underlying OS technology and ensuring there is a clear path to production. We still believe that developers just want to push code, build their product, and deploy it - the underlying technology is only relevant if it gets in the way of functionality. In that vein, we continue to have a Heroku-like deployment process of tessel run on Tessel 2.

    In short, the Tessel platform is still the fastest way to prototype an idea and, with Tessel 2, the fastest way to bring it to market.

    Tessel 2

    #Tessel 2 #Node #Linux #OpenWRT #Tessel #Javascript #Microcontroller #Microprocessor #Jon McKay #Technical Machine #io.js

  • A Truly Open Hardware Development Platform

    Thursday, March 5, 2015

    3/5/15– Kelsey Breseman

    Technical Machine announced Tessel 2 today: an open source $35 development platform you can take into production.

    Why Tessel 2?

    Tessel 2 is an affordable, accessible, open, and robust platform to build connected hardware devices and funnel them into production.

    The Tessel platform was created to abstract away the initial hurdles of hardware development. Tessel opens up connected device development to people who want to build embedded devices, but don’t have the time to start with Ohm’s law and work their way up.

    Tessel 2 takes the promise of Tessel 1, adds features and a path to production, and cuts the cost in half.

    The original Tessel board fulfilled the goal of electrical accessibility. High-level languages, plug-and-play extensibility, and the use of a great package manager for installation all made Tessel the fastest way to build a prototype out of an idea. But it was also frustrating: fast as it is to get started on a Tessel 1, it’s hard to go beyond a single prototype. In the year since we shipped Tessel, we’ve been collecting feedback on user experiences and investigating solutions. Tessel 2 is based on that feedback.

    With Tessel 2, we are building for users who want to take an idea, prototype, and then produce in volumes of hundreds to thousands.

    For Tessel 2, we sought out the most reliable WiFi chips on the market, and found a solution in wireless router systems-on-chips (SoC’s, combined processor/wifi solutions). These chips are built into millions of routers and have very robust hardware and firmware. As an added bonus, they are produced in such high quantity that they cost less than $3 in quantity, compared to Tessel 1’s $13 for WiFi + microcontroller.

    We’re now able to offer a device that runs 20x as fast, offers full Node and io.js, has router-grade Wifi reliability, USB ports, and ethernet, and costs less than the original Tessel. That offering is Tessel 2.

    Tessel 2

    Putting Tessel in a Product

    At this much lower cost, Tessel 2 is cheap enough to just insert into a product (as people do with BeagleBone and Raspberry Pi). And it’s open source, so you’re free to do so. Unlike BeagleBone and Raspberry Pi, however, we’re going out of our way to make that easy for you.

    At the 100s-1000s scale, we are able to automate some simple optimization on the boards and components, thus reducing your end cost for embedded hardware.

    We’re also offering services to support you as you scale up to production. Manufacturing is opaque and intimidating. It doesn’t have to be– we’re aiming for a Heroku-like experience of physical product deployment.

    Please email us if you’re interested in discussing this with us.

    Will Tessel 2 act like Tessel 1?

    In a word, yes. For all intents and purposes, using the Tessel 2 should feel the same as using the original Tessel (but more reliable and a little faster). However, there will be a few changes to the underlying technology: original Tessel runs the Colony compiler to turn JS into Lua and is thus “Node compatible”; Tessel 2 just runs Node on V8– so you won’t run into the same incompatibility bugs. You can read more about this in the blog post Moving Faster with io.js.

    There will also be a couple of differences in modules: Tessel 2 supports USB modules, so a USB webcam, USB speakers, and a few other modules will move into this sphere. This will allow us to reduce the cost of these modules and get you a higher-quality experience. USB compatibility also lets us easily support new third-party plug-and-play hardware capabilities in a similar capacity to current Tessel modules.

    Is it still JavaScript?

    Tessel 2 will not only run JavaScript with io.js (a fork of Node), but also support Rust, Python, and potentially other languages.

    At the time of writing, we have already run Rust and Python code on a Tessel 2.

    Around the time of ship, we will release examples of running Rust and Python on Tessel 2, as well as documentation on library porting for interested members of the community. The same process of plugging in a hardware module and installing the driver from a package manager will apply for these languages. Both languages will eventually be fully supported on Tessel 2.

    Multiple language support is made possible by the change in underlying technology on Tessel. We’re excited to see where you take it.

    What about low-power applications?

    Based on feedback from the original Tessel, we’ve learned that people building connected device systems often need either a relatively high-power system to control and process various inputs and outputs, or they want simple, low-power sensor nodes.

    WiFi chips are now more reliable and also cheaper than they were a year ago, but Wifi as a protocol is not designed to be low power. Tessel 2’s power draw is slightly less than that of the original Tessel, but not much.

    For people seeking low-power solutions, we’re working on adding that capability to the Tessel ecosystem as well. Expect another big announcement next month.

    Open source

    Tessel is open source, software and hardware, and we owe a lot to our community. We have open sourced the software work we’ve done so far on Tessel 2, along with the schematics to tessel.io/opensource, and will continue developing in the open. As the hardware is finalized, we will release layouts.

    We will be adding more about the architecture of Tessel 2 to the open source page in the next few days.

    What will you build?

    Our vision at Technical Machine is to build an open and scalable platform for hardware development. We’re reimagining the hardware development process with a focus on creating the best possible developer experience. Tessel 2 is the next piece of that vision.

    With Tessel 2, we’re giving you the experience of Tessel, at the price of a Pi, with scaling opportunities that no other development board offers.

    For us, Tessel 2 lays out the next leg of the journey on your road to production. We’re waiting in anticipation for you to take your next steps.

    Kelsey Breseman
    Director of Community, Technical Machine

    Check out Tessel 2
    Discuss Tessel 2 on our forums.

    Tessel 2

    #Tessel #tessel 2 #new product #announcement #technical machine #javascript on hardware #javascript microcontroller #rust microcontroller #python microcontroller #kelsey breseman

  • An Interview with Jay Henderson: Product Prototyping on Tessel

    Monday, February 23, 2015

    2/23/15– Kelsey Breseman

    Jay Henderson spills over with excitement, ideas, and passion. He’s building a code school and a hardware startup both from the ground up right now, trying to improve drought conditions in north Texas, working to bring together his community, and working to teach himself ever more about technology and programming.

    Just home from his day job, Jay sat on the couch to Skype me, all smiles and enthusiasm. His girlfriend’s dog, Dylan, jumped up more than once to try to join the call.

    Kelsey: What are the main things you’re working on right now?

    Jay: The main thing that I’m working on right now is a water barrel app. It was part of the North Texas Apps Challenge. During the summer months, there’s water restrictions in Dallas County. We wanted to create a rain barrel app that tracked how much water you got from your roof, and then how much water you started to dispense on your yard.

    The other thing I’m working on is, I’m trying to start a learning lab that teaches people how to do software, and then eventually, blend that into hardware.

    Kelsey: Can you tell me more about your water barrel app?

    Jay: We met with an environmentalist at the University of North Texas, and he told us about how he made these products for people who wanted them in their home. He said, if there was a way to calculate how much water they’re using, and have an app that displaces the water out as they use it, that would be cool. So we made Barrl.

    I went on Adafruit and bought a liquid flow meter, a soil / moisture temperature sensor, and a brass solenoid valve, which we plan to use with to tell us how much water is going into the barrel.

    We’re trying to work on that as our first product as a startup, as Intelliflux Labs. We’re hoping to bootstrap it. That’s why we love Tessel, because I have a frontend development background, so the JavaScript makes it quite easy for me.

    Kelsey: You said you have a frontend development background?

    Jay: My background is in front-end: HTML, CSS, JavaScript, user interface; user experience is my forte. In the last year, I have really immersed myself in full-stack development. Experimenting with that has been fun.

    The reason why I want to learn as much as I can is so that I can teach other people who are unaware of what’s going on with JavaScript, and see what they can make it do with physical computing.

    Kelsey: Can you tell me more about your learning lab plans?

    Jay: About three years ago, I was going to school and working at the Apple store, but courses became really expensive. I couldn’t go to school anymore, and then I lost my job. But then I started to teach myself during my unemployment. I created a Personal Learning Environment, a PLE, started navigating content, learning things that I was personally interested in for programming, and started to get an understanding.

    I’d started to see different code schools pop up, and I decided to have a trial run of a code school here.

    Eight people paid for it, and then we got ten scholarships from a company. It was really exciting meeting the different personalities. I had a gentleman who was developing in C#, who wanted to learn more about HTML, CSS, and JavaScript. I had a school teacher who knew nothing about programming or anything like that.

    I started the course with an introduction to PLEs; I asked each person, what do you want to build? What is it you’re passionate about every day? Your learning is going to grow based on your personal learning environment. I’m teaching you how to go out and find these tools, but in the end it’s going to be up to you. When you’re faced with a problem, you’ll need to reach out to others in the community to get answers.

    One gentleman was doing graphic design, and he loved the job, but it was so demanding, and he wasn’t getting a lot of compensation for the work he was doing. During the course, I had a speaker series where I had professionals come up. They spent most of their time answering questions and engaging with the students. One speaker came in and talked about the Myo, different human interactions that are coming out, and that really engaged him [the graphic designer]. He started prototyping UI with some of his graphic UI knowledge, and he just landed a job at the Dallas Morning newspaper here just from interacting with the course.

    I helped teach a man who was homeless, in the course. He took it on quite well, and now he’s working in a coworking space, and developing clients with a unique support system.

    The testimonials and success stories are starting to come out, and we only did just a trial course.

    Kelsey: That’s amazing. What are you planning to do differently with your next course?

    Jay: I think I condensed too much into five weeks. We covered a lot of UI and frontend, but I didn’t go into detail with programming logic. I think that the concept of doing something physical for that will be easier to grasp, because you’re dealing with physical components. You can actually see physical objects come to life coding physical elements, such as, if this is true, then have a led blink.

    I’m hoping to do more– from surveying students from the course, participants were more on the marketing side, more graphic artists and designers, and I’m starting to brainstorm about how I can help bridge the visual with the programming.

    Kelsey: Are you planning to use the Tessel for that?

    Jay: One of the things that I want to do with Tessel is to take two or three projects from the projects board and teach that to the class in workshops. Once they get a foundation with JavaScript, introduce them to the things that they can do outside of JavaScript. In which we’ll open up the possibility of creating products.

    [Tessel] is actually making it a whole lot easier for software developers to create real products with only a little bit of knowledge of hardware. That’s one thing that I’m trying to do, is give frontend developers and software developers a chance to interface with hardware.

    After you teach the foundational tools and introduce the projects, you can expand your creativity and your imagination. I’m excited to teach people that you can start making your own products and start making a profit from just an idea.

    #jay henderson #kelsey breseman #interview #tessel #technical machine #code school #barrl #education

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