by We wrapped up the 2015 Hack-A-Way this past Friday and after a few days to reflect I wanted to write about the event and on future events. Saying what the impact of a coding event will be can be difficult. Lines of code written can be a misleading metric and a given patch may not make it into production. However, a casual discussion could have major consequences years down the road. Indeed, it was at the first Hack-A-Way that Bill Erickson’s presentation on web sockets had no immediate impact but over the next year was a key component in the decision to go to a web based safe client. Still, I’m going to venture into saying that there are impacts both immediate and long term.
I won’t got into detail on each thing that was worked on, you can read the collaborative notes here for that: https://docs.google.com/document/d/1_wbIiU47kSElcg0hG2o-ZJ9hNmyM8v7rOWyi8jGvA38/edit?usp=sharing
But, some highlights, for me, included:
The Web Based staff client – Bill Erickson has done a lot of work on the Windows installer for Hatch and Galen will help with the OS X version. Both PINES and SCLENDS have libraries looking forward to getting the web based client into production to do real world tests. I’m very excited about this.
Galen Charlton was confirmed as the release manager for Evergreen 3.0 (or whatever version number is selected).
Syrup – A fair bit of bandwidth was spent on how Syrup could be more tightly integrated into Evergreen for course reserves. I’m always excited to see academics get more support with Evergreen even if it’s not my personal realm.
Sqitch – Bill Erickson presented on this, a tool for managing SQL scripts. Sqitch plans let you specify dependencies between SQL scripts; avoids need for numbering them so that they run in a particular order and encourages creation of create, revert, and verify scripts. This may be a good tool to use during development though production deployments are likely to still use the traditional upgrade scripts.
Twenty patches got merged during the Hack-A-Way with more following over the weekend that were tied to work done then.
Ken Cox, an Evergreen user joined us as a developer and showed us the great work he has done on an Android app for Evergreen.
We discussed the steps to becoming as a core committer and several ideas were thrown around about how to encourage the growth among potential developers via a mentoring program. No firm consensus came about in terms of what that program should look like but I’m glad to say that in an epilogue to the discussion Kathy Lussier has been made a core committer! Kathy has been a long time consistent contributor to Evergreen and bug reviewer so I’m excited to have seen this happen.
Search speed continues to be a contentious issue in the Evergreen community. Search relies on a lot of layers from hardware to Apache to Postgres to SQL queries to even the web site rendering and things beyond Evergreen like the speed between server and client. As a result comparisons need discipline and controls in place. Using external indexing and search products was discussed but it’s a hard discussion to have. Frankly, it’s very easy to end up comparing apples to oranges even between projects with similar tasks and goals. For example, Solr was referenced as a very successful product that is used commercially and with library products but research and exploration will be needed before we can have a more full discussion about it (or other products). MassLNC shared their search vision – http://masslnc.org/search_vision which was a good starting place for the dialogue. Many systems administrators shared their best practices. We also discussed creating a baseline of searching taking into account variables such as system setups and record sizes and then creating metric goals. Even possible changes to Postgres to accommodate our needs was thrown out for consideration.
Related to the core committer discussion we did an overview of the technical layout of Evergreen and common paths in and out of the system for data. https://docs.google.com/drawings/d/17aNEr8vLen5wBjCAP4NPnjL7fYT3VxK6_9wVArR9VII/edit?usp=sharing
Now, as all this wonderful work happened it’s still an incomplete picture. It doesn’t capture the conversations, the half patches, the bug testing, the personal growth of participants that happened as well. Nor does it capture the kind hosting we received from MassLNC and NOBLE who help ferry us about, sent staff to participate, arranged hotels, kept coffee flowing and in general were as kind a host as we could hope for. I feel like I should write far more about the hosts but I probably can’t thank each one individually as I’m sure I don’t know what each even did but the contribution of hosting the Hack-A-Way is always a big task and the folks at MassLNC and NOBLE did a wonderful job that we are all very thankful for.
Now, about the operational side of the Hack-A-Way. There were some discussions about the future of the event and managing remote participation. Remote participation in the Hack-A-Way has always been problematic. When the Hack-A-Way began remote participation largely amounted to people updating IRC with what was going on. Then we tried adding a camera and using Google Hangouts. Then, the limitations of Google Hangouts became apparent. We tried a FLOSS product the next year and that didn’t work well at all. Through all of this more people wanting to participate remotely has become a consistent issue. So, through the event this year I created a list of things I want to do next year. Tragically, this will put more bandwidth strain on the hosting site but we always seem to push the bandwidth to it’s limit (and sometimes beyond).
- Ensure that the main presentation computer for group events has a microphone that can be used, is setup as part of the group event and has it’s screen shared.
- Have the secondary station with the microphone / camera that can be mobile instead of on a stationary tripod. This will mean a dedicated laptop for this purpose. If I have time I may setup a Raspberry Pi with a script to watch IRC and allow IRC users to control the camera movement remotely, which might be fun.
- Move to a more robust commercial product that has presentation controls (the needs this year showed that was necessary). We also have needs to occasionally break into small groups with remote presence that this won’t solve so Google Hangouts will still probably have a use. We are going to try out a commercial product next year for this but look at our options that support our community as best we can, namely looking for Chrome native support via an HTML5 client.
Beyond that, we discussed the frequency of the Hack-A-Way and locations. Next year Evergreen Indiana is kind enough to host us and already has a submission in place for 2017. Several ideas that were floated were extending the conference by 1 – 3 days for a hacking event there or even having a second Hack-A-Way each year situated to break the year into even segments of Conference / Hack-A-Way / Hack-A-Way rather than the Hack-A-Way being mid year between conferences as it is now. No decision was made except to continue the conversation and try to come to some decisions by the time of the conference in Raleigh.
The only sure thing is that those months will pass very quickly between now and then. I felt the Hack-A-Way was very successful with a lot of work done and a lot of good conversations started, which is part of the function of gathering into one spot so many of us that are spread out and used to only communicating via IRC and email (with occasional Facebook postings thrown in).