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!

img_1612-2

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!

img_1628

The InclusiveIO team

Advertisements

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 lib.rs I needed the following at the top of the file.  This would also go for main.rs if you have a main instead of a lib.

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

In my Cargo.toml I had the following dependencies:

[dependencies]
serde = "0.6.11"
serde_json = "0.6.0"
serde_macros = "0.6.11"

In my library module (not lib.rs, 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.

 

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.

Patterns

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
break;
case 2:
// do the same thing as case 1
break;
default:
// do the default
break;
}

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.

Traits

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.

Testing

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!