The 48 Hour Launch — Can you really launch a company in 48 hours?

This past weekend, I had the honor of being invited to the 48 Hour Launch Internet of Things (IoT) Edition in Chattanooga, TN as a mentor from Mozilla.  48Hour Launch is a competition event where inventors come with their ideas they want to turn into a company.  On Friday night they tell the local community what their idea is and what type of help they need (e.g. designers, engineers, business and marketing, etc.).  Prizes are awarded for 1st, 2nd places as well as Mozilla awarded two trips to MozFest in London.

Teams began to form organically after each entrepreneur had an opportunity to talk about what they were building. Mentors and members of the community were just milling around at different tables trying to dig deeper, understand the vision more and see if it was something they were interested in and whether they thought their skills could be used.  

Chattanooga has a thriving innovation community.  The Edney Innovation Center building downtown is where this event was hosted.  The Edney is home to The Company Lab, a local startup business accelerator that sponsored and ran the event.  Additionally, there were many professors from University of Tennessee, Chattanooga and other nearby schools that had come to offer their assistance for the weekend.  Chattanooga is very fortunate to have received a grant to be one of the Gigabit cities (along with Kansas City and Austin) funded by the National Science Foundation.  They also had a mentor in attendance. I admit I spent much of the weekend envying the lightning fast internet speeds and wishing we had that in our town.  US Ignite was also in attendance.  They are an organization that works to foster applications that leverage the power of the Gigabit network.  It was truly amazing to have so much cross-discipline support from so many organizations.

What initially drew me to this event when I was first asked was it’s education focus.  I’m very concerned about education becoming a closed one-vendor solution (I think we all know who I’m talking about here).  I connected with a Red Bank (TN) public elementary librarian, Cristol Kapp.  Her project was initially titled “Inclusive Makerspaces”.  I could tell she was extremely passionate about her project.  She was the first librarian in her county to fund and create a Makerspace in her library.  Libraries are in a transition today and are becoming places where patrons can build, learn, and create with different tools including 3d printers, electronics kits, and whatever grabs their interest.  The Chattanooga Public library is a prime example of this with an entire floor dedicated as a Makerspace.  Tools included a piano, zine-making station, 3d-printer, computers, electronics kits, and much more.

The first evening we had a group of about 10-15 that were interested in Cristol’s idea.  She explained to us that in her library she had children with different ranges of abilities that were unable to participate in the Makerspace as some of the maker tools were just not accessible to them.  She made it very clear that these children were not only being left out academically but also socially.  Her tagline was “Everyone is a Maker!”.  It was clear to us that our mission over the weekend was to help her craft a makerspace solution that was accessible and collaborative for all children.

Saturday morning we came in and really focused on a solution.  We defined different personas for one of our customers, the children.  We had teachers in the group work on this as this was their area of expertise.  Our solution was to create a platform that allowed different kinds of input and output.  Different modalities of input would be used for children with different abilities.  Essentially, the idea was that all children are able to create the same output.  A Heroku server (rocked out by my awesome colleague Sam Foster) was used to translate the commands from the different inputs to the outputs.  Inputs would include things like image recognition for children that are able to gesture, play dough buttons using MakeyMakey boards for children that have gross motor control, keyboards for children with fine motor control and speech recognition for children that have verbal abilities.  We had some ideas for collaborative output so that children can create an art project together and see the result displayed in the library.  Publishing the result of your work is an important part of the creative process and we wanted to make sure we included this.

For my part I worked on connecting the MakeyMakey boards to the Raspberry Pi and translating this to the server.  MakeyMakey was a new discovery for me over the weekend.  It’s really the simplest thing to use.  There are instructions where you can make a piano out of bananas.  I plan on getting one of these for my own kids to play with.  I think these are really good for the under 10 crowd. Sam created some output using some fractals that the kids could play with as an example of something they could create together.   We managed to successfully test end to end from the input devices to the visible output on the screen.  Then we turned to gesture recognition to see if we can create another input.  I used Python with OpenCV.  Many thanks to Dan Mailman of the Stage Genies project for helping us with the Pi/OpenCV image.  That would have taken hours without his image.  We were able to recognize hand gestures and translate that to the server using the websocket protocol.  One of the greatest parts of the weekend was to see the collaboration between the teams.  It was a competition because there were prizes, but everyone genuinely wanted everyone else to be successful!


The MakeyMakey and the Raspberry pi with play dough inputs!

Late Saturday night and Sunday, we continued to work on the prototype and help refine the pitch.  Others focused on a business plan on what the company would need and how it would grow and scale.  Others worked on a company logo.  The project was renamed to Inclusive I/O.  This gave rise to a brilliant logo with an O with an I inside of it.  The pitch was just hours away.  Cristol had created a company twitter account and things were falling into place.

Sunday evening all the teams gathered at the Church on Main and readied for pitches.  It was a festive event with food and drink before the pitches.  Judges from the event included a panel from Mozilla, US Ignite, and others.  There were many wonderful ideas pitched.  Here’s a list as well as the winners.  Cristol gave an amazing pitch and took second place in the event.  She won some startup cash as well as many business accelerator services including legal, marketing, and business development.

All in all, this was a wonderful weekend.  I can also confirm first hand that it’s true about Southern hospitality!  Those of us Mozilians that came from different locations (some as far as Berlin) were so warmly welcomed by the Chattanoogans.  Such a delightful city!  I came back from this weekend event very excited and hopeful about the future of education and open collaboration in this space.  To answer the question, Yes, I do feel it’s possible to launch a company in 48 hours when you have a passion for your idea along with the help and support of people in your community!


The InclusiveIO team


Rust – Working with JSON– Part 2.

I spent quite some time trying to figure out what Rust crate to use for serializing some from an object into JSON.  I debated quite a bit between rustc_serialize and serde.  I wound up choosing serde as it seems to be the direction things are going and it’s reported to be more efficient and have more features.  I did not independently verify this.

My problem was a little more difficult than the simple example of serializing a single level of JSON.  I had multiple nested levels complicated with the fact that I wanted to allow an already serialized string to be tacked on as an element so I can treat it like a chunk of anonymous JSON passed in by a caller.

This is on nightly rust vs. stable.  We like to live on the edge!

rustc 1.9.0-nightly (998a6720b 2016-03-07)

Essentially I wanted to serialize something like this:

{item1: "1234",
item2, "2345"
item3: {
item4: "3456"
item5: {
item6: "4567",
item7: '5678"

There were a lot of compiler errors being caused by not having this in the right place and with the right combination of extern crate.  In my I needed the following at the top of the file.  This would also go for if you have a main instead of a lib.

#![feature(custom_derive, plugin)]
extern crate serde;

In my Cargo.toml I had the following dependencies:

serde = "0.6.11"
serde_json = "0.6.0"
serde_macros = "0.6.11"

In my library module (not, but the implementation of my library module.) I included the following:

extern crate serde_json;
use self::serde_json::Value;

#[derive(Serialize, Deserialize, Debug)]
pub struct TopLevelItem {
item1: String,
item2: String,
item3: Option,

#[derive(Serialize, Deserialize, Debug)]
pub struct SecondLevelItem {
item4: String,
item5: Value, //This is needed to allow a JSON string to be added
// without the serializer escaping this as a string again.

Later on in my code, I create these objects…

let top = TopLevelItem {
item1: "1234".to_string(),
item2: "2345".to_string(),
item3: Some(SecondLevelItem {
item4: "3456".to_string(),
item5: data, //This is just another serialized structure which I needed to //anonymize and treat item5 as just a chunk of JSON.  I was unable to do //this with 
rustc_serialize.  This was a case that worked out nicely.


Then I serialize the data to a string…

let serialized = serde_json::to_string(&body).unwrap();
println!("serialized: {}", serialized);

If the serialized data needs to be converted to a static str and you can’t get
a static str from a String, thus you need to slice.  This was needed before I could use the data in the body of an HTTP POST request using hyper.
let body_slice: &str = &serialized[..];

Overall, this was obviously a lot more involved than serializing in JavaScript.  It’s not too bad after getting the macros and features setup correctly.  That took some time and experimentation.  That’s all for now.  I will continue to blog on my experiences with Rust.


Webelos “First Responder” Adventure

Our den started working on the “First Responder” adventure. I really wanted to make a concerted effort to make sure everything was very hands-on for the scouts. I’m a firm believer that you have to practice something in order to have it stick in your head.

We have a den of about 11 scouts. We decided to break them up into about 3-4 groups at each meeting. I drafted parents to handle one topic for each meeting. We had about 4-6 stations per meeting and had the boys rotate through them in SMALL groups (not more than 3 in a group). Having small groups was key so they each got a chance to practices.

For the hurry cases, we made sure to talk to them about identifying the symptoms of the issue how to treat and then we had parents act out certain cases and the boys each had to apply the proper treatment.  We also made sure to review everything at the end of the meeting. We kept pretty close to the content in the new handbook.

I do believe like the scouts learned a lot in this adventure. We were fortunate to have very willing parents. We were lucky to have a Dr. in our group as well as several parents in the medical profession. Having parents involved was really key to the success of this adventure.

Unfortunately, we did not have access to a CPR dummy. This would have been nice for the CPR portion.

Learning Rust for ex C++/Java developers (Part 1)

I’ve decided to start learning Rust.  It’s starting to be used across Mozilla and Mozilla has been heavily involved in defining it.

Additionally, I’ve been focused on JS  for a couple years now and this seems a nice language to get back to my C++/Java roots.  One of the main tutorials I’m reading is  here.

Rust is a strongly typed language and it’s main selling point is memory safety.  Rust will be a good language of choice for drivers or other systems programming.  Rust also has convenient ways to connect to other languages as a stack with many languages is quite commonplace these days.

Building and Running

Tools in Rust seem quite simple at first glance.  You can quickly build by running rustc.  Rust also has a sweet build and packaging system called cargo.  I found all this quite simple to get going with the basics.  I believe the “up and running” phase to be easier than Java and C++

First Impressions

Safety First!

I like how Rust makes safety a priority.  You’ll find TONS of safety checks built into Rust. For example, when you’re indexing into a vector you need to use a usize vs. an int; otherwise, you’ll get a compiler error which could save you from future grief.


Rust has pretty powerful pattern matching capabilities.  Here’s one really cool thing:

In C++/Java a standard switch/case example:

switch (x) {
case 1:
// do something
case 2:
// do the same thing as case 1
// do the default

becomes the following in Rust:

match x {
case 1:
1|2 => // do something
_ => // do the default

Sweet!  A lot more brief in Rust.  One of the big selling points of Rust is the safety.  IF you forget to add a catchall ‘_’ you will get a compile time error.  Rust is demanding exhaustiveness here.


Initially, traits are a little difficult to grasp.  I started thinking of them as something similar to an interface in Java.  Interfaces are specified and then implemented inside of a class in Java.  In Rust, they are specified and then implemented inside of the struct.  Rust does have a trait called “drop.”  This is similar to destructor capabilities in C++.  It allows you to run some code when a variable goes out of scope.  You could use this to clean up resources that were used.  Additionally, it could be used to implement a reference count.


I took a cursory look at how unit tests can be written and it seems like a clean design.  There is an option to include the tests in the same file as the implementation or include a separate tests module.  The infrastructure seems quite simple and is integrated right in with cargo.  I particularly liked this.

Overall, I’m very enthusiastic about Rust and there is still lots to learn!

Stronger, Faster, Higher Meetings

We are on our second meeting for the “Stronger, Faster, Higher” adventure.  The first meeting, we had the scouts work on the basic fitness items A-F (jumprope, pushups, 20-yd dash, etc.)  We recorded their results and asked them to keep it up for 30 days and record their results weekly at least.

The second meeting we had them design a fitness course.  We have a rather large den (13 kids).  We let them flounder around and chaos ensued for about 5 minutes until we broke them up into two groups.  We had one group that was passionate about football design a sort of NFL combine course.  They did a good job with this.  We had to have adults be the ones throwing the passes.  So, we had to set their expectations a bit, but it was nice to let them do something they enjoyed… football.  The other half of the group was less interested in football and designed a different course involving jumping, crab walking, frisbee toss, and plain running.  We wound up prepending the football course to the jumping course and it all worked out fine.

We had to drive home to the scouts that they are really competing against themselves to become “Stronger, Faster, and Higher”.  We will repeat the course in two weeks.

In this meeting we also had them practice a relay game to teach to the younger scouts at our next pack meeting.  Will report on this next time.

Next week we have our shopping trip for camping at Costco for “Cast Iron Chef”.  We are camping next week.  It’s a bit late for the cubbies to go camping, but it’s been warm so far this fall.. (famous last words!).

Cast Iron Chef and Camping Adventures – Meeting 2

Again… Joaquin… you REALLY SUCK!

This meeting was really good.  We had our AWESOME den chief to help us out tonight. We covered their logs for nutrition, the menu for camping, and practicing their bowline as a gathering activity (not everyone got it the first time).

We went over their nutrition logs.  They were supposed to record everything they ate and say whether it was Animal, mineral, or vegetable… wait, that’s 20 questions.. It was fruit, vegetable, dairy, protein, or grain :).  About 50% of my kids actually did it (yes, they had reminders).  I had the ones that did it pair up with the ones who didn’t and calculate a pie chart for how much of each they ate.  I used a free iPhone app that generates pie charts so they can get an idea.  Then we went around and everyone said what they needed to eat more/less of.  Of course, my child was overloaded on carbs!  But, it was a good, quick exercise for them to be conscious of what they intake and to try and balance it.

We then worked on planning meals for our campout.  We split them into two groups.  One dinner group and one breakfast group.  Den Chief was very helpful to make sure that not all the meals were carbs!  We have to make sure that adults can eat the meals too!  We had the groups make shopping lists as well.

We have another meeting setup to do the Campout shopping at Costco for the dinner and breakfast that our scouts are responsible for during the trip.

Alas… Joaquin came and made us reschedule our campout.  Stay tuned for how our campout actually goes…

Cast Iron Chef and Camping Adventures – Meeting 1

We have a group of Webelos 1.  We are following the new 2015 curriculum.  We thought the “Cast Iron Chef” and “Camper” Adventures fit nicely together.  Here is my experience with our den so far on these:

We centered everything around our big fall camping trip. Which has been canceled and rescheduled already (Joaquin, you suck!).  Our first meeting (our first of the year actually), we had the scouts work on tying bowlines and do the race they suggest in the leader guide.  This meeting was a bit rocky, but rocky because we have a large den and my co-leader and I just merged our dens together.  We had them set their personal nutrition goals (part of the Cast Iron Chef).  We also had them recite the outdoor code and the “Leave No Trace” principles.