The Story - Hackathon

The Story - Hackathon

About three months ago, I decided it would be a good idea to run a hackathon. I suppose that I thought that it would be fun, and that I’d probably learn something, since I had never run one of these before. The truth is, I had not attended that many hackathons either. No matter, I was decided. This post discusses how the event planning got on its feet initially.

The story.

I reached out to a couple friends, who run the Smart Glass Innovators meetup with me. I had two things that I wanted to focus on, Google Glass, and the weekend before Google I/O. Then, I mentioned the idea to my friend Kevin Adler, who was instantly excited about it and started brainstorming ideas with me. The first thing that we decided was that education technology would fit as a theme, along with Glass. He thought that his company, Entangled Ventures might be a good fit as a sponsor, I agreed, and after running it by Lawrence Wong and Joseph Wei, we had our theme nailed down.

I had initially booked space at Hacker Dojo for June 20-22, but Kevin suggested moving it to the city. This was an idea that came up a lot with the meetup, plus, that’s where I/O happens, so I figured that it was probably a smart move. Kevin went to work finding an additional space, and convincing his partners at Entangled Ventures to sponsor us. Kevin found us a space, and from there we were off to the races.

People

The next step was to gather up organizers. Luckily, I know a lot of great people, who all organize events like this. I pinged everybody and created a list of organizers who were all excited about helping out. The primary organizers all provided lots of helpful input, and were instrumental in figuring out all of the details that end up making or breaking an event. Then we had some people who were more active at the event itself, giving up large chunks of time to be available for helping with either technical questions, doing food runs, and making sure that there was coffee.

We also had some good support from Galvanize, which made my life easier, by being there for almost all of the event, and helping out with logistics issues like an occasional WiFi issue, keeping the place relatively clean, and making sure there was music or AV help when we needed it.

I wrote a whole THANK YOU! post about all the people involved.

Planning

The planning was not taken lightly. I have a handful of email threads that total around 200 emails, as well as two conference calls with the organizers, and additional calls with individual organizers. We used Google Docs to organize our thoughts, flesh out a concrete plan for everything, and assign tasks. The budget was there, as was info about the space, sponsors, everything. One of my goals with the planning of this event was to be as transparent and up-front with everyone as possible. I wanted to do my best to avoid any politics, drama, or in-fighting that might have resulted from a lack of clear communication. I think the communication helped, along with the fact that, again, I was working with a great group of people.

The planning started about three months before the event. The major pieces were in place after about the first month, then over the next couple of weeks we grew the sponsorship to a place where I wasn’t constantly worrying about paying for food. Then the detailed planning took the final month and a half. The detailed planning was the most time consuming, because that’s really when all the little things needed to get done. I was unable to work on any other side-projects in that time, which was difficult for me.

The first thing to nail down was the venue. I had initially booked a space at Hacker Dojo, where we typically hold Smart Glass Innovators events. After talking it over with Kevin, Lawrence, and Joseph, we determined that San Francisco would be a better location than Mountain View. Kevin found us a space in SF, that he liked, and we jumped on it. I actually held the Hacker Dojo reservation until the Galvanize reservation was final.

I’m not entirely sure it made that the location much of a difference. While we had initially hoped to grab attention from I/O attendees, the GDG leaders summit was closer to our event, and several of our attendees were in town for that (as well as I/O). Maybe the next one will be the weekend before the GDE summit.

There were several reasons that it was so important to get this figured out first. First, obviously, we need to hold the event somewhere, and you need to be able to tell people where they’re going to go for the events. Second, we knew that people would be traveling to the area, and the sooner we could let them know about our event, the better. Finally, again, you can’t hold an event nowhere, well, you could, I guess, but it would be a different thing, and that’s not what we’re talking about here.

Once we had preliminarily held the space, I was able to make an initial announcement. This was timed to be right around the time when people were first finding out whether or not they had gotten I/O tickets, and would be making travel arrangements. It ended up really helping us gauge interest, and get people excited about the event early on.

Next up was finding sponsors. The first email that I sent to the organizers was asking them to reach out and connect with potential sponsors. They delivered, and we came up with a list of sponsors who were going to cover our food and prizes. From there, we were off to the races.

There were lots of details that we nailed down over the next few weeks. The planning continued over email, Hangouts, and Talkray group calls. I’ll share all of the details of what we decided in an upcoming post on ‘how to run a hackathon’.

THANK YOU!

THANK YOU!

After months of planning, the Pre-I/O Google Glass Hackathon is finally over, and I couldn’t have done it without the help of a bunch of people.

Sponsors

First, a huge thank you to our sponsors, who made this event both possible, and worthwhile for all of our participants.

Entangled Ventures was the first to step up, and basically underwrite the event. They secured a great venue, as well as contributing prize money. We wouldn’t have had much of an event without Entangled. Thank you, Entangled!

The Google Glass team paid for the food for the event. Having the food covered was a huge help, as it freed up ticket sales to go to other things like swag and prizes. It also gave me some assurance that no matter what the ticket sales ended up being, we would be able to feed people. Additionally, they provided some really cool Glass swag, that everybody loved! Thank you, Google!

Metaio also pitched in for food, taking care of dinner on Friday night and enough energy drinks to plow through the entire 24 hour event. They also offered an SDK as a prize, and gave out an SDK to a participant during the event. Thank you, Metaio!

HTC offered HTC One phones to each of the members of the winning team. In addition to prizes, Dario was on-site to help out during the event. Thank you, HTC!

Wearable Technologies Conference contributed prizes, in the form of two tickets to their conference, as well as a cash prize. Thank you, Wearable Technologies Conference!

GGDevCon offered a ticket to their conference as a prize. Thank you, GGDevCon!

NotionKit gave all of our participants access to their beta tools for prototyping and previewing Glassware. Thank you, NotionKit!

Judges

Next, I would like to thank all of our judges, for carving out the better part of their Saturday to come and watch presentations, deal with technical issues, and work out who the favorites were. Thank you, Kim Jacobson, Josh Salcman, Allen Firstenberg, and Kevin Adler!

Organizers and Helpers

Finally, there is one last group that was instrumental in making this event happen. Without these people, there would have been no hackathon.

Lawrence Wong and Joseph Wei, were the first people who I contacted about the event, and both contributed lots of insight, advice, and connections to sponsors.

Kevin Adler, who was instantly excited about it and started brainstorming ideas with me. He suggested that education technology would fit as a theme, along with Glass. Kevin thought that his company, Entangled Ventures might be a good fit as a sponsor. He also, through Entangled, secured the space, and helped on a lot of the major planning items.

Next, a few standout organizers, Libby Chang, ‘Katy’ Hsin-yi Berg, Trish Whetzel, and Dario Laverde all provided lots of helpful input, connections to sponsors, and were instrumental in figuring out all of the details that end up making or breaking an event. I also need to make special mention of Katy, since she was there for nearly the entire event, and anytime we needed someone to make a food run, or to help work the door, she volunteered. She did more work than I did for this event!

Then we had some people who were more active at the event itself, giving up large chunks of time to be available for helping with either technical questions, or making sure that there was coffee. Allen Firstenberg, GDE for Glass, made himself available to answer people’s questions (and helped as a judge), Shannon Fiume was both answering technical questions, and making sure that we had enough coffee for people, and (Ivan Yudhi)[https://plus.google.com/+IvanYudhi] was also helping out during the event making sure that people had what they needed to be productive for the long overnight stretch. This was in addition to the organizers who I’ve already mentioned, who were all doing lots of work, either staying overnight to help out, or doing food runs.

Both Bruna Maia and Kat Otto from Galvanize made my life easier, by being there for almost all of the event, and helping out with logistics issues like an occasional WiFi issue, keeping the place relatively clean, and making sure there was music or AV help when we needed it.

I also need to mention John Scott and Jeff Bond who were both attendees, but pitched in a lot during the event.

The rest of the participants were also all really great people. We asked them to help us out with a few things and they delivered. There was no drama, no complaints, no hassles, I almost felt a bit guilty that I had it so easy.

A huge thank you to everybody who was involved, and/or participated!

LowFreqLiveCard - Example of a low frequency LiveCard using GDK for Google Glass

LowFreqLiveCard - Example of a low frequency LiveCard using GDK for Google Glass

I wrote an example of a low frequency LiveCard using GDK for Google Glass. The master branch uses Gradle, the legacy branch is able to be imported into Eclipse.

This code is heavily based on the Live Card documentation on the GDK section of the Glass developer docs. The reason that I wanted to do this was that I wanted something that required as little code as possible to run.

Code

Here’s the entire source for the Service that creates and publishes the LiveCard. It’s very similar to what you see in the documentation.

Notes

A couple of notes, it uses a custom voice command, launch with:

'Ok Glass, start my awesome app'

This displays random data, it is not correct, and Glass does not have a built in HRM that I’m aware of. It will display a new value every 3 seconds, and will stop updating after 10 values have been generated.

Importing

Instructions for importing legacy version into Eclipse.

Instructions for importing into Android Studio.

Instructions for importing into IntelliJ. A note on this one, you’ll actually import this as a Gradle project, not ‘from existing sources’. Everything should be configured correctly to allow it to be imported as a Gradle project.

Source

Full source available on GitHub.

Witness, a simple Android and Java Event Emitter

Witness, a simple Android and Java Event Emitter

Source. I found this in an image search for ‘witness’. Had to use it. =)

I’ve been working on a project for Google Glass and Android that requires asynchronous messages to be passed around between threads. In the past, I’ve used Square’s Otto for this, but I wasn’t thrilled with the performance. Additionally, Otto makes some assumptions about which thread to run on, and how many threads to run with, that I wasn’t crazy about. Before continuing, I should point out that Otto is configurable, and some of these basic assumptions can be dealt with in the configs. Regardless, I felt like writing my own.

Code

Witness is a really simple event emitter for Java. The idea here is to build a really simple structure that can be used to implement observers easily. It’s sort of like JavaScript’s Event Emitter, and the code is short enough to read in its entirety.

I’ll start with Reporter because it’s so simple. Essentially, this is just an interface that you implement if you want your class to be able to receive events.

The Witness class maps class types to Reporter instances. This means that for a given data type, Witness will fan out the event to all registered Reporters. It uses an ExecutorService with a pool size of 10 threads to accomplish this as quickly as possible off of the main thread:

Usage

To receive events for a specific datatype, the receiving class needs to implement the Reporter interface, then register for whatever data types the following way:

Witness.register(EventTypeOne.class, this);
Witness.register(EventTypeTwo.class, this);

When you’re done listening, unregister with the following:

Witness.remove(EventTypeOne.class, this);
Witness.remove(EventTypeTwo.class, this);

To publish events to listeners:

Witness.notify(event);

Handling events in the Reporter:

@Override
public void notifyEvent(Object o) {
    if (o instanceof SomeObject) {
        objectHandlingMethod(((SomeObject) o));
    }
}

Android, it is a good idea to use a handler, to force the event handling to run on the thread you expect. E.g., if you need code run on the main thread, in an Activity or Service:

public class MyActivity extends Activity implements Reporter {
    private Handler handler = new Handler();

    // ...

    @Override
    public void notifyEvent(final Object o) {
        handler.post(new Runnable() {
            @Override
            public void run() {

                if (o instanceof SomeObject) {
                    objectHandlingMethod(((SomeObject) o));
                }

            }
        });
    }
}

Notes

Events are published on a background thread, using an ExecutorService, backed by a BlockingQueue. This has a few important implications:

• Thread safety
  • You need to be careful about making sure that whatever you’re using this for is thread safe
• UI/Main thread
  • All events will be posted to background threads
• Out of order
  • Events are handled in parallel, so it is possible for them to come in out of order

Please find this project on GitHub. If I get enough questions about it, I might be willing to take the time to package it and submit it to maven central.

Update

+Dietrich Schulten had the following comment:

It has the effect that events can be delivered on arbitrary threads. The event handler must be threadsafe, must synchronize access to shared or stateful resources, and be careful not to create deadlocks. Otoh if you use a single event queue, you avoid this kind of complexity in the first place. I’d opt for the latter, threadsafe programming is something you want to avoid if you can.

I should note that my usage is all on Android, where I’m explicitly specifying the thread that the events will run on using Handlers. I haven’t used this in a non-Android environment, and I’m not entirely sure how to implement the equivalent behavior for regular Java.

Pre-I/O Glass Hackathon Announcement!

Pre-I/O Glass Hackathon Announcement!

Finally, I have enough of the major pieces in place to be able to make a real announcement about this!

Come hack with us!

The weekend before Google I/O 2014, we are holding a 24 hour hackathon to build Glassware for Education.

Smart Glass and Wearables will be enabling innovation across many industries in the coming years, one such field is Education. Entangled Ventures has a special interest in seeing leaps forward in Education using technologies like Google Glass. Let’s see how we can enable teachers and students with Glass!

Keep an eye on the Eventbrite page for updates.

Are Wearables Doomed?

Are Wearables Doomed?

A number of articles have appeared in the last week, asking if wearables have already peaked. I think that the answer is a solid no. I’m going to break this down into a few parts, tracking devices, health and smart wearables (Glass, smart watches, etc.).

Tracking

While, I do think that the fitness tracking space is limited, I think that has to do with the appeal of these devices. No matter how many features fitness trackers offer, they will only appeal to a certain segment of the market. However, I think that there are three important aspects that have been unexplored so far.

First, is the feature set, most of the tracking devices are simply motion tracking, they do step counting and possibly sleep tracking. There are some people that primarily care about these two things. However, it misses out on other potential exercising, like cycling, or weight lifting. There are some tracking devices designed to do better activity tracking, like Basis, but we aren’t quite there yet, and those devices don’t seem to have penetrated the market in the same way that FitBit and its competitors have. Adding more sensors, and providing a more complete activity tracking picture will entice more people.

Second is health. I’ll discuss this more below, but there is an overlap with tracking devices.

Third, tracking devices may be used in conjunction with smart devices. This allows them to be possibly more discreet and less expensive, connecting through Bluetooth Smart (BLE). Perhaps I’ll have a step counter on my hip, a heart rate monitor chest strap, and a temperature sensor on my arm, all talking to Glass. What this does is allows those other devices to cut down on their BOMs, for example, they would not need a display at all if connected to a smart watch or to Glass, because they would already have access to a glance-able display.

Health

This isn’t as much a consumer space, but I think that there is a ton of potential here. We are just now starting to see devices that can start addressing health issues showing up. What’s more, there is some overlap with the tracking devices, for people with lifestyle conditions that would be improved by exercise.

I have started seeing reports of wearable patches being developed that could run on body heat and measure blood pressure. Imagine if there was an easier way to do blood glucose readings with a non-invasive wearable? Or, a potential application for Glass which might assist patients in taking their pills, using computer vision to verify the correct pill, and motion tracking to verify that it was taken, then reporting to the physician. There are lots of potential applications in this space.

Smart Wearables

This is what is going to tie everything together. I’m not sure that people will be still walking around with phones in a few years or not. Either way, smart wearables will enable other categories of wearables, as well as providing their own value. We are starting to see some useful Glassware show up, things like LynxFit and DriveSafe, that really couldn’t be done without Glass or at least not as well.

Conclusion

Wearables are not doomed, and they have not peaked, but we aren’t there yet either. If we still aren’t there in a couple of years, I’ll have to re-think some things, but for now, I’m optimistic.

IDE Imports Part 9 - GDK with Eclipse

IDE Imports Part 9 - GDK with Eclipse

This is the ninth of a series of posts discussing how to get Google Glass Mirror (Java) and GDK projects set up in various IDEs.

One of the most common questions that I get from people during workshops is how to get set up either the Mirror quick start, or the GDK project into Eclipse, Android Studio or IntelliJ.

This post will cover importing a GDK project into Eclipse.

0. Clone from GitHub

See previous post.

1. Import Project

File -> Import Project -> Android -> Existing Android Code Into Workspace

2. Select the directory with your project

Make sure that all your source is selected. Then ‘Finish’ and you’ll be done with that.

3. Edit Project Properties

Right click the project, select Properties.

4. Set the SDK as GDK 19

In Project Properties, go to Android, then select the correct SDK.

5. Finished!

You’re all done!

IDE Imports Part 8 - Java Mirror with Eclipse

IDE Imports Part 8 - Java Mirror with Eclipse

This is the eighth of a series of posts discussing how to get Google Glass Mirror (Java) and GDK projects set up in various IDEs.

One of the most common questions that I get from people during workshops is how to get set up either the Mirror quick start, or the GDK project into Eclipse, Android Studio or IntelliJ.

This post will cover importing the Java Mirror Quick Start project into Eclipse.

0. Clone from GitHub

See previous post.

1. Install m2e plugin in Eclipse

• Visit the m2e project site
• Go to the Downloads section
• Copy the latest m2e release URL
• In Eclipse, go to Help -> Install Software
• Paste the m2e link into the bar, hit ‘enter’ and give it a name, like m2e
• Select the packages that come up when it loads
• Install the m2e packages
• Accept the license
• Restart Eclipse

2. Import Project

File -> Import Project -> Maven -> Existing Maven Project

3. Hit 'Next’ a few times

Then 'Finish’ and you’ll be done with that.

4. Update the oauth.properties file

I previously made a video with instructions on this. Google has also posted instructions for getting OAuth set up.

5. Fire up a terminal

Run the following from the root of the project:

$ mvn install
$ mvn jetty:run

6. Finished!

You’re all done!

IDE Imports Part 7 - Legacy GDK with Android Studio

IDE Imports Part 7 - Legacy GDK with Android Studio

This is the seventh of a series of posts discussing how to get Google Glass Mirror (Java) and GDK projects set up in various IDEs.

One of the most common questions that I get from people during workshops is how to get set up either the Mirror quick start, or the GDK project into Eclipse, Android Studio or IntelliJ.

This post will cover importing a Legacy GDK project into Android Studio.

0. Clone from GitHub

See previous post.

1. Import Project

2. Hit ‘Next’ a few times

Until the project is imported.

The project will automatically be converted into a Gradle project.

3. Add compileSdkVersion to build.gradle

The correct value is:

compileSdkVersion "Google Inc.:Glass Development Kit Preview:19"

4. Fix the AndroidManifest.xml

Need to have one Activity that is considered the launch Activity, otherwise IntelliJ (Android Studio) won’t let you run.

5. Finished!

You’re all done!

IDE Imports Part 6 - Java Mirror with Android Studio

IDE Imports Part 6 - Java Mirror with Android Studio

This is the sixth of a series of posts discussing how to get Google Glass Mirror (Java) and GDK projects set up in various IDEs.

One of the most common questions that I get from people during workshops is how to get set up either the Mirror quick start, or the GDK project into Eclipse, Android Studio or IntelliJ.

This post will cover importing the Java Mirror Quick Start project into Android Studio.

0. Clone from GitHub

See previous post.

1. Import Project

In Android Studio, select Import Project.

2. Import project from existing model

Select Maven

3. Hit ‘Next’ a few times

Then 'Finish’ and you’ll be done with that.

4. Update the oauth.properties file

I previously made a video with instructions on this. Google has also posted instructions for getting OAuth set up.

5. Fire up a terminal

Run the following from the root of the project:

$ mvn install
$ mvn jetty:run

6. Finished!

You’re all done!