Favorites from GitHub Universe

Remember when enterprise shied away from Open Source software? I sure do. The times they aren’t a changin’.  Led to by the desire to cut costs and create better products, companies are embracing open source. Business today runs on a mix of open and closed solutions.

Nowhere was this more apparent than at the inaugural GitHub Universe conference last week.

Keynote

GitHub CEO Chris Wanstrath opened the warehouse event with a talk (video) to fire everyone up.

“The last century was about hardware. This century is about humans.”

This was clearly the take home message of the event. SaaS means you no longer need to buy hardware to start your own company. All you need is an idea and access to a computer. For all of your services you can pay as you go.

After the keynote, the talks split into three different categories: build, collaborate and deploy. Let’s take a look at my favorites from each of these tracks.

Build

From the Build track, my favorite talk was titled Every Company is a Software Company. You can catch a video of the talk here. This talk was given by a panel comprised of representatives from General Electric, Ford, Target and John Deere. None of these are software companies in the traditional sense, but all of them are doing some really groundbreaking things in the software world.

It was amazing hearing about a company like John Deere, which manufactures equipment for agricultural, construction and forestry, finding a use for embedded Linux on their 7 inch displays. These displays also expose an Open API. In short, it was interesting hearing the ways non-tech companies are taking advantage of technology.

Digital challenges

Another key takeaway was the chasm between manufacturing and software development. One of the biggest is maintenance. When you build a truck, it’s done. The end user may break it, but that falls onto them to correct. One of the challenges of bringing cutting edge software into these same markets is explaining that even the best software needs maintenance.

Another factor I rarely consider is safety. As software developers, we sometimes rely on end users to find bugs. Sometimes these bugs are small, but not always. With software this is annoying, but rarely puts lives at risk. Now, imagine you are writing software to slow down a car if it approaches a hazard. This simply cannot break.

In the world of IoT, there is near zero leeway for minimum viable products or trial and error. In addition to safety, cost of potential poor performance is also a real issue. If GE has sensors on all of their windmills letting the blades know in which direction to turn to get the most return, if that does not work perfectly, millions, if not billions of dollars will be lost.

Collaboration

Later in the day, I attended some talks in the Collaboration track. This was a fitting theme for the conference, as easier collaboration was one of the main reasons Linus Torvald created Git back in 2005. Unsurprisingly, this was a big set of talks. My favorite of the bunch by far was Git and GitHub Secrets. This talk was less about secret, esoteric Git uses, and more about underused GitHub tools. You can catch the talk in its entirety here.

Here’s a quick showcase of some of my favorite learnings:

Adjust the tab space
Adding ?ts=4 to the end of diff or file URL will display tab characters as 4 spaces wide instead of the default 8. The number can be set to whatever you like.

Commit History by Author
To view all commits on a repo by author add ?author={user} to the URL.

Cloning a Repository
Yes, everyone already knows how to do this. What you may not know is you can omit the .git at the end. For example, https://github.com/iron-io/iron_worker_php.git is exactly the same as https://github.com/iron-io/iron_worker_php.

Keyboard Shortcuts on Repository Pages

• Pressing “t” will bring up a file explorer.
• Pressing “w” will bring up the branch selector.
• Pressing “s” will focus the search field for the current repository.
• Pressing Backspace to delete the “This repository” pill changes the field to search all of GitHub.
• Pressing “l” will edit labels on existing Issues.
• Pressing “y” when looking at a file (e.g. https://github.com/tiimgreen/github-cheat-sheet/blob/master/README.md) will change your URL to one which, freezes the page you are looking at. If the code changes at a later time, you will still be able to see your frozen snapshot.

A full written list of secrets can be found at https://github.com/tiimgreen/github-cheat-sheet.

Deploy

For the final stretch of the day, I headed to the Deploy track. This is where the rubber meets the road. We take what we’ve been working on and present it to the public. Ben Balter’s talk 10 ways people are (mis)using GitHub Pages for fun and profit was one of the most interesting in this segment.

I’ll be honest, I’ve never used GitHub pages before and was only aware of them in name. For those who are not aware, GitHub pages are free static websites. They come gratis with any GitHub account. But, this is not just Geocities for a new generation.

The talk spanned 10 major use cases, of which I’ll focus on three. The first is collaborative content. It’s easy as a software developer to treat the code we slave over with respect. Content is no different, in fact, you could argue that’s it’s even more important. Using GitHub pages, allows you to take an Open Source mindset to the content and copy side of things. It’s nice being able to think of content changes as pull requests.

The next awesome use for GitHub pages is collaborating on policy. At any company, policy is always in a constant state of change. You might see this in a change to the terms of service, an update to the HR policy after that incident at the company Christmas party, or in response to a governmental edict. Out of date policies are hard to trust. So, why not crowdsource the maintenance?

Take a look at https://github.com/showcases/policies, the government policy on Open Data. See something on there you don’t think should be there? Submit a pull request. That will spur a conversation with the maintainers, which ultimately leads to better policy.

The final use case was Documentation. Most developers know the pain of integrating a solution with poor or non-existent documentation. Poor documentation can make a short job a very long one. As software developers, most of us have also been tasked at some point to produce documentation. That’s not a fun job either.

Using GitHub Pages for docs is an ideal solution. It allows you to leverage the power of community. You aren’t stuck writing everything yourself. Additionally, if there’s a gap somewhere, the community can help both find and fix the issue.

To see all 10 of the GitHub Pages use cases, you can catch the video here.

Conclusion

I had a blast at GitHub Universe! If you’re eager for more, head over to their uStream page for videos.