GitHub Universe: Conference Report

GitHub Universe 2016 container welcome attendees and doubling as a coat check stall.

Last week I attended GitHub Universe for the second year and once again it was time well spent. It continues to blow my mind the fascinating job they do of putting on the event, specifically the venue transformation (wow), high quality of food (yum), nicest Porta Potties I’ve ever seen or used (thanks), and high quality sessions (yay) all at a very reasonable price.

This year the sessions seemed a bit less technical but nonetheless still very interesting and relevant. The theme was mostly around community and driving culture change both topics which I could immediately relate as they areas I’m personally involved with at work. As to be expected at any conference there were a few product announcements and the ones that I found most notable were Projects and GraphQL access and the addition of SAML to github.com next year.

Projects

We use GitHub Enterprise at my job as a code repository and JIRA for project management. A couple of my projects use JIRA mostly for our daily standups and just for that 30–60 minute period per day, otherwise for the most part it’s not used. Most of the time the tasks in JIRA are a reflection of work needing to be done with code that’s in GitHub. I’m not hinting that Projects should replace JIRA per se but for small projects that don’t need the heavy reporting capabilities in JIRA or any of it’s deep project management functionality, Projects seems like a good fit. It’s 1 less tool for an engineer to have to learn and figure out. One stop shop for your code and status tracking; simple and functional. I also like that it enables the use of Issues for more than just code specific tasks but things like follow ups, planning, requirements gathering etc. That’s another thing that I found interesting about the conference is hearing all the ways that people are using GitHub, many of which have absolutely nothing to do with code. So even though Projects is not yet in GHE, I’m hoping that happens in the next couple months so I can start giving it more practical use.

GraphQL

Prior to the conference I had heard of GraphQL in passing but couldn’t really tell you exactly what it was. I attended GitHub’s session “Implementing and Using GraphQL at GitHub” co-presented by Dan Schafer @ Facebook, who not only explained what it is but highlighted the reasons why they’re using it now and I finally had my aha moment. It also made me realize just how graph-esque most of the data we work with really is and how thinking that way, in the sense of your data is a large graph, makes you realize just all the various permutations of relationships and connections that exist. The search versatility and granularity that GraphQL provides seems quite useful. I’m still trying to think of one or two real-use cases for it at work that I could immediately tackle in order to get more hands on with it because the one potential drawback that I could see is that it could lead to potentially bloated services. Bloated in the sense of having a lot more functionality built into a service which would have otherwise been a few disparate small microservices. Balance is likely the answer here but regardless this looks like quite an interesting piece of software.

SAML

In these modern times, “as a Service” is the new norm. The value proposition of running your own is diminishing daily. With the addition of SAML to github.com and additionally married with 2FA more businesses, especially medium to large sized ones would consider moving their code bases to .com where they can leverage their existing employee identities and make code sharing with the public identities as well open sourcing in general that much more seamless. There’s some expected controls I’d hope would be in place in order to prevent accidentally publicizing proprietary code or code that isn’t yet “ready” to be externalized but the path is being laid towards that happy place and I’m content to see that. This feature was announced to be coming in 2017.

Interesting Sessions and Content

The sessions are going to be posted online shortly so I’m only going to recap the ones I found most interesting:

  • Implementing and Using GraphQL at GitHub by Kyle Daigle @ GitHub and Dan Schafer @ Facebook. This was the GraphQL session I mentioned earlier.
  • Codifying Company Values by Hui Ding @ Instagram. I think the name of this one is a bit misleading but there’s a lot of good insight into the scaling challenges that Instagram has had to overcome and their decision making process that drove the tech stack they currently run. A couple takeaways for me…they use Postgres to manage all their user data with no DBAs on staff and only a dozen or so infrastructure engineers. Also clearly Python can scale, granted it does need to be tuned but so does every piece of software when exercised to that level.
  • Tips & Tricks: Gotta Git Them All by Jamie Strusz and Brent Beer @ GitHub. This entire session was worth noting down. I at first thought it was going to be a repeat of last year’s however it was everything but. Here’s a few goodies I pulled out… git config — global help.autocorrect 10 can be used to allow git to autocorrect your commands, no more git sttus. In GitHub, actually in Markdown, to enable syntax highlighting https://help.github.com/articles/creating-and-highlighting-code-blocks/#syntax-highlighting. In Atom check out the git-time-machine package :).
  • Building and Scaling a Distributed and Inclusive Team by Mathias Meyer @ Travis CI. I really liked this talk as he showed how the mostly remote and globally distributed employee base of Travis CI deal with communication and day to day interactions. They use the typical suite of tools as most any other company, no magic there but it was clear that it takes some thinking differently and there is no perfect answer. They have a mantra of “if it’s not written down, it doesn’t exist” which makes complete sense when everyone is dispersed all over the world in varying timezones. Another documentation mantra they have, “Less oral communication means more accidental documentation”. They use Google Docs and Pull Requests for documentation, Slack for real-time communication and Issues for discussions (in lieu of something like threaded conversations in Slack). They maintain a “Builders Manual” that sounds like it’s an employee playbook with links to other sources as a way to centralize where all the dispersed information can be found.
  • State of the Octoverse. Fascinating infographic showing just how awesome the opensource community really is. Check out the top starred repos and the ones with the most forks as well as most contributing users, a lot of gems in there.

Well it was a great 3 days and I’d be lying if I didn’t say I’m looking forward to next year.

Here are some pics of the impressive venue https://goo.gl/photos/VoS8jUjXNbJutGFN6

Show your support

Clapping shows how much you appreciated Alan Williams’s story.