Author Archives: J Simmons

Of Google+ Pages, Google Drive, and Hangouts

by .
Comment

As most of our readers have already guessed, Mach 30 is a big fan of Google’s services.  We hold our meetings over Google+ Hangouts.  We store our documents in Google Drive.  And of course, we have an official +Mach 30 Page on Google+.  Most of the time everything just works seamlessly.  But, such is not always the case, as was demonstrated last month when we tried to hold a Hangout On Air with guest panelists who had attended the Open Source Hardware Documentation Jam, during which our live stream was completely busted, and after which the video was deleted by YouTube for an unknown reason.

After licking our  wounds, owning our mistakes, and much research, I am happy to report we have a much better integration between the +Mach 30 page, our YouTube Channel, our Google Drive storage, and Google+ Hangouts.  Specifically, we can now run Hangouts from +Mach 30 and use Google Drive (instead of +Ezri Clarke, a fake account we set up to allow us to do this in the past).  As a bonus, the Mach 30 YouTube channel is now integrated into the +Mach 30 page, with its own tab at the top.

And how do I know all of this works?  Why, I tested it, of course (with a little help from our volunteer, Jaye Sudar).  And here’s the proof.

Warning, technical content

For those that want to know how we made all of this work, here are step by step instructions.  Of course, they are provided without warranty and with the usual disclaimer that YMMV.

  1. YouTube Integration with Google+ Pages (based on these instructions from Nonprofit Tech Blog)
    1. Login to YouTube with the account that manages the organization’s channel (we had a shared account for this purpose)
    2. Go to YouTube Settings
    3. Click the Advanced link
    4. Click the “Connect with a Google+ Page” button
    5. Select the Google+ Page you want to link to your YouTube channel
    6. Click the “OK” button to confirm the change
  2. Setup username and password for Google+ Pages (based on these instructions from Google)
    1. Open a browser, we will call Browser 1, and log out of all Google Accounts (this step is optional if you do not use multiple Google accounts, but is highly recommended if you do, it can save a lot of grief later on)
    2. In Browser 1, login to the owner account for the Google+ Page you are working with (note, the owner account cannot be a Google Apps/Custom Domain account, it must be a standard Google Account – if this is not the case, change the owner of the page to a standard account and start over with step 2.1)
    3. Now follow the steps in Google’s instructions for adding a username and password to the Page (click Pages, select the Page you are working with, click on Settings in the Google+ menu, click “Setup username & password”
  3. Integrate Google Drive
    1. In a second browser, we will call Browser 2, logout of all Google accounts
    2. In Browser 2, go to http://plus.google.com and login with the username and password for the Google+ Page you are working with
    3. In Browser 2, go to http://gmail.com, you will be prompted to choose an email address (this will be the login name for the Google+ page in all Google Services, like Google Drive); I recommend something like “plusmypagename@gmail.com” so the username is easy to remember (you will be asked to confirm the new email address using text message or phone call, follow all of these steps until you get to the Gmail Inbox)
    4. In Browser 2, go to http://drive.google.com
    5. If you have existing Google Drive files or folders that you need to use in Hangouts, go back to Browser 1, go to Google Drive and share the files/folders with your new user account for the Google+ Page (chosen in step 3.3)
  4. Test, Test, Test
    At this point, everything should be good to go, so now it is time to test

    1. In Browser 1, visit the Page you are working with, and verify there is a YouTube tab; click it and you should see a list of videos from your YouTube Channel like this one
    2. In Browser 2, start a normal hangout by clicking on the “Hangout” button in the “Share” box on the Page’s home page
    3. Invite one or more attendees to help with the test
    4. Be sure to add Google Drive files to your hangout and verify both you as the Page and the other attendees can edit the files and see each others’ edits
    5. Close the Hangout
    6. In Browser 2, start a Hangout On Air by selecting “Hangouts On Air” from the Google+ menu, then scroll down until you see the “Start Hangout On Air” button on the far right and click it
    7. Name the Hangout, and invite attendees
    8. Again, add Google Drive files to the Hangout
    9. When everyone is ready to start, click the “Start Broadcast” button and wait for the broadcast to go On-Air
    10. Again, verify both you as the Page and the other attendees can edit the files from Google Drive and that you can see each others’ edits
    11. Be sure to say a few words and make sure everything is recording and broadcasting correctly
    12. When you are done, click the “End Broadcast” button
    13. Verify the video shows up in your Page’s stream and on your YouTube channel

If you can get through all of that, you should be good to go.  Happy  Google+’ing!

ad astra per civitatem

Test Early, Test Often, Test Everytime

by .
5 Comments

Credit Rob Sayer

Not everyone knows this, but my first degree is in theatre, specifically theatre lighting design.  Before I ever learned about differential equations, stress analysis, or lift-to-drag ratios, I studied color theory, script analysis, and worked lights for dozens of shows ranging from “A Christmas Carol” to “Evita“.

One of the secrets to making sure a play comes off without a hitch every single night for weeks, months, or even years on end is something called a dimmer check.  Before each performance (even if there was one earlier in the day), the lighting crew chases everyone out of the theatre, and one by one turns on the 50-500 lights over the stage to make sure everything is still working.  The crew checks to make sure the lights come on, that the color filter in front of the light has not faded or burned through, that the light is still pointed at the correct location on the stage.  And, believe it or not, for medium to large shows, there is almost always something that needs to be fixed before each and every performance.  Yes, even when the last performance was just a couple of hours ago.

This attention to detail, and insistence that every time the equipment is turned back on it should be tested, is an essential element to getting live performances right every single time.  It’s even more important when you have just changed something, whether it is to make a repair or an improvement.

I pride myself on how my experience in theatre influences the way I approach live events at Mach 30 and elsewhere.  I always insist on rehearsals, especially when technology is involved (we had two separate technical rehearsals for this year’s Yuri’s Night Party), and I do my own version of the dimmer check for any gear I plan to use during an event.

hangout logo-g+_dk

Mach 30 Hangouts happen each Thursday

But this week, I got cocky, and I made a change (to improve our Google+ page) without running through any tests afterwards, and this change broke our ability to host On-Air Hangouts (on a week when we had an important one scheduled).  #Oops.  Apparently, linking one’s YouTube channel to a Google+ Page causes some squirrelly behavior with On-Air Hangouts.  Behavior we did not notice until during and after this week’s OSHW Documentation Jam Round Table Hangout, which not only led us to starting twenty minutes late, it also appears to have prevented the video from becoming sync’ed over to our YouTube Channel (which is too bad, I think our panelists and guests had some really great things to say, and I am sorry we won’t be able to share them with the Open Source Hardware Community).

So, that’s the bad news.  Of course, the good news is no one died or was injured from my failure to properly test things.  But, Mach 30’s work is building to a day when people’s lives will be on the line, so it is important to recognize small failures so we can learn from them.  In this case, the lessons are

  1. Remember to test everything associated with a system after making changes to the system (there is likely a balance of risk vs reward to be struck, but clearly the key features of a system should be checked when significant changes are made)
  2. Mach 30 needs to identify the core features we are using Google+ for (such as On-Air Hangouts) and create a test plan (or dimmer check) to be run when changes are made to our Google+ infrastructure, either because Google upgrades a feature or because we turn on an existing one we had not been using.

And, in the mean time, I will look into trying to recover our lost hangout video, and schedule the already discussed second round table hangout (after I have fixed our YouTube settings).

ad astra per civitatem

Growing Open Design Engine

by .
1 Comment

April is turning out to be quite a busy month for Open Design Engine.  So far we have found a new software development contractor to help us with the heavy lifting required for some of our new features, submitted a grant application to cover the next version of Open Design Engine, and prepared materials for the upcoming Open Source Hardware Documentation Jam.  By next week, we should have all sorts of feedback on what the Open Source Hardware community is looking for in project hosting.

Mach 30’s Ground Station Antenna

For those who don’t know, Open Design Engine is Mach 30’s free project hosting site for open source hardware projects.  We use it to host all of our publicly available projects (aka those not covered by export controls) such as the Shepard Test Stand and GS-001 (our new ground station project).  It is also home to a number of very cool projects from other users, including Andrew Starr’s Scanning Tunnelling Microscope.

Over the last couple of months, volunteers at Mach 30 have been planning the next major release of Open Design Engine as part of the work to apply for the SpaceGAMBIT Call for Projects.  As this plan came together, the volunteer team leading this effort realized Mach 30 would continue to need external software development support.  Unfortunately for us (but very fortunately for them), Littlelines, our developer for the current version of Open Design Engine, has plenty of work lined up at the moment and is unavailable for our next round of work.  All is not lost, however.  After reaching out through the volunteer team’s professional network, Mach 30 has been introduced to Mutually Human Software.  I am very happy to report Mutually Human will be a great addition to the Open Design Engine team.  Not only are they a skilled Ruby on Rails shop (Rails is the toolchain which Open Design Engine is built on), but they also “get” open source hardware and the maker community.  So much so that they are sponsoring a local startup makerspace, GR Makers.

April also saw the completion of Mach 30’s application for funding from SpaceGAMBIT’s Call for Projects to support Open Design Engine development.  Our application includes work to completely overhall the user interface, improve the infrastructure to support git repositories (among other things), implement one or more revenue generation streams so Open Design Engine can become self-sufficient, and marketing Open Design Engine to grow its user base.  I encourage you to take a look at the application.  The team did a great job in planning this new version, and in preparing the document.

Finally, I have been getting ready for the Open Source Hardware Documentation Jam.  This three day long conference/hack-a-thon is all about what the Open Source Hardware community needs to easily publish, share, and reuse documentation for open source hardware projects.  I am very excited to be included in this event for Mach 30’s work on Open Design Engine, and I am looking forward to sharing what we have learned and where we are headed, as well as finding out what the community needs from sites like Open Design Engine.  Stay tuned for updates from the Documentation Jam, and for a follow up On-Air Hangout covering the lessons learned and the community’s path forward after the event.

ad astra per civitatem

Fifty-two Years

by .
5 Comments

It’s been fifty-two years.  No, not of Mach 30 (well, not yet anyway)…  It’s been fifty-two years since the first human spaceflight.  And for the last twelve years people around the world have celebrated the anniversary of Yuri Gagarin’s first flight (and the first US Space Shuttle flight) with Yuri’s Night parties.

Starting last year, with a great deal of encouragement and support from our volunteers, Mach 30 celebrated Yuri’s Night with an online party.  Each year, we choose a theme and hold a space trivia contest, complete with prizes for our guests out in cyberspace.  As a distributed organization we find the online format gives our volunteers, partners, board members, and fans a chance to celebrate human spaceflight together without the need for a transporter.

We just held our 2013 party this weekend.  Check it out in the video above.  The theme was Rocket Science: Live!  During the party we demonstrated two of our open source spaceflight projects (the Shepard Test Stand and our first ground station prototype).  Both were a big hit with our guests including makers from Bucketworks and Club Cyberia, and students from John Mall High School.

From all of us at Mach 30, I want to thank our volunteers, guests, and partners who helped make this year’s party a huge success.  We had a blast!  And we can’t wait to celebrate fifty-three years!

ad astra per civitatem

Transparency Means Sharing Failures and Successes

by .
4 Comments

Maureen and I had lunch with Jerry from Maui Makers and the Hackerspace Space Program a couple of weeks ago.  We talked about a number of things including Open Design Engine, Makerspaces (which led to a brief tour of Dayton Diode), and Open Source Hardware.

It was our conversation around open source hardware which had me thinking back to our meeting days later.  We started off talking about the usual stuff:  licensing, the new Open Source Hardware Association, and of course we talked about open source spaceflight.

But then, sitting there in a Panera Bread over coffee and snacks, the conversation turned toward questions we don’t always address when talking about open source hardware.  Questions like:

  • “What should happen to abandoned projects on sites like Open Design Engine?” – Well, we should keep them up for others to learn from or fork into new projects, which is what Source Forge does.
  • “But won’t that eventually lead to lots of incomplete projects?” – Probably, which on the surface sounds like a “bad thing”, especially if there are many more abandoned projects than completed or active ones.
  • “And what if the reason the project was abandoned was it just didn’t work?  What if it was a failure???” – People really don’t like to share their failures…
  • “But, wouldn’t you want to know about the things that didn’t work so you don’t have to discover that for yourself?” – Well, yes. . . Of course. . .

And then it happened:  the light bulb flashed on, and we started talking very excitedly about science, engineering, publishing, and how hardly anyone writes about their failures.  They only share their successes.  In fact, if someone were to publish one of their failures, their peers would stare at them with bewildered expressions and ask “What are you thinking?”

It was Maureen who put it best, pointing out that we need to change the culture so people’s reaction becomes “What do you mean you didn’t share your failure?!?!”

In that spirit, allow me to present an update on Mach 30’s first open source hardware project, including the good with the bad, so we can all learn from the progress Mach 30 has made.

Shepard Test Stand Update

One concept for the Shepard Test Stand

Things have been very busy at the Shepard Test Stand.  Since announcing the project in May, we have completed the requirements analysis, the block diagram, and are working steadily through Shepard’s design.  That’s pretty good news.  We also submitted two Shepard related presentation proposals to the Open Hardware Summit.

The first submission was a plenary session presentation looking at the engineering process used to develop Shepard and the instrumental role Open Design Engine played in the process.  The second submission was a demo of the Shepard Test Stand.   We were disappointed when our plenary presentation was not accepted, but were pleased to be included as one of the demo projects.

So Shepard has had its share of successes, but what about the failures?  Where have things not gone as planned?  The most significant challenge for Shepard is our schedule.  We are more than a month behind, and we now have a confirmed deadline of September 27, 2012 to conduct a public demonstration of the test stand.  This gives us just short of two months to complete the design (which is mercifully nearing completion), assemble, test, and document Shepard.  That is a tight time frame, especially given our work to date.

So, how did we get so far behind schedule?

I see two driving factors.  First, we were probably a little aggressive in the scope of Shepard, and in the time we allotted ourselves to complete the project–especially when you consider this was our first open source hardware project.   Second, we split our focus between Shepard and our work on the Far Horizons Project High Altitude Balloon.  Our group of volunteers is still pretty small, and many ended up working on both projects.  With limited time, something had to give.  At the time, the deadlines associated with the High Altitude Balloon (HAB) launch meant that Shepard’s timeline that had to give.

Still, with the current round of development work on the HAB basically wrapped up, we will be turning our full attention to the Shepard Test Stand.  Hopefully, we can find a way to get caught back up and be ready for the Open Hardware Summit.

Only time will tell.