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.

GitHub Universe was hosted in an old warehouse this year. Industrial chic!

GitHub Universe was hosted in an old warehouse this year. Industrial chic!

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.

GitHub Universe crowd

The interior of the warehouse was quite nice.

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.

14 Comments

  1. naxhh on January 25, 2016 at 9:56 pm

    Not to be that guy that complains but since this is about small Images you should deleted the files apk update generates and concat all that in one line so you don’t generate extra layers

    Example in the alpine readme https://hub.docker.com/_/alpine/

    • treeder on January 26, 2016 at 6:48 am

      All our Iron images do delete the apk files, eg: https://github.com/iron-io/dockers/blob/master/ruby/Dockerfile#L10 .

      I’m curious to know what difference extra layers make in terms of size?

      • naxhh on January 26, 2016 at 8:59 am

        Sorry, I didn’t check the final images 🙂 I just was quickly reading with the mobile.

        Checking imagelayers it seems that the rm from cache does not remove anything but the update generates 700k every time you execute it. So I will check that a bit more.

        I don’t think less layers is about final size but more about download speed. The same applies to the good practice of executing only one apk add with packages sorted by name and the re-use of existing layers on your pc.

        Btw apk add –no-cache should do the trick

        • treeder on January 26, 2016 at 5:40 pm

          Ya, the layers don’t show the size decrease for some reason, but the total image size is much smaller. In iron/node, we uninstall npm and it cuts the image size down by something like 20MB. Even though the layer for npm uninstall shows 0.

  2. tom_m on January 25, 2016 at 10:46 pm

    This kinda stuff is really cool. It’s going to get even smaller and more secure in the future too. Iniatives like this are foreshadowing things a bit: https://github.com/deferpanic/gorump

  3. Harlow Ward on January 26, 2016 at 9:37 pm

    Great post @treeder:disqus . Can you expand on the advantage of building the Golang static binary inside the Docker container as opposed to building with `GOOS` and `GOARCH` ENV vars on command line?

    • treeder on January 27, 2016 at 6:31 pm

      I don’t think there’s an advantage to build it either way, you should end up with the same bin eight way. I just like building inside containers regardless so I don’t have to setup anything on my machine to do it (GOPATH, etc) and if it’s not static, you can build/test on whatever system you are going to be running on. For instance, a Go binary built on Ubuntu will not run on Alpine, so just build it inside an Alpine container and you’re good to go. And you can test it on the destination operating system too.

  4. Rémi Alvergnat on January 27, 2016 at 9:09 am

    Great post, thanks ! Micro containers are often better, people should keep in mind that if you have 10 container sharing the same big 650Mb image, it won’t eat 10x650Mb, but 1x650Mb.

    So if size matters for ease of distribution and public images, I’m not sure it’s that critical and it can even be counter-productive in some case.

    If host runs 10 containers based on 10 distinct micro image, it might eat up more space that it would by using a single bigger and more generalist base image …

    • Dave Newton on January 27, 2016 at 5:45 pm

      But the generalized base container would still be the same, and the specialized images would still have the same stuff. I think you’d need a pretty wide swath of micro images to add up to even a few macro images.

  5. Ralph Tice on February 3, 2016 at 11:58 pm

    Have fun troubleshooting really insane seg faults because of musl instead of glibc. I’ve had some fun ones with both python and Oracle JDK. Just getting the Oracle JDK running at all involves wget’ing some random glibc bits from circleci.

  6. James Mills on February 4, 2016 at 7:29 am

    I don’t mean to be a cynic; but this is all based around Alpine. Several or more of us in the community have already done all this (including myself for Python). What is so special about what iron.io have done or provide really?

  7. zoobab on February 4, 2016 at 10:05 am

    I made even smaller images with openwrt (basically the rootfs is mostly just busybox). 5MB.

  8. Michał Gryko on February 9, 2016 at 7:34 am

    Nice idea in overall, great that people finally see that containers should contain only app + its dependency. I’ve created very basic version of such build tool for my previous company: https://github.com/Playsoft/container_builder It saved us lot of disk space and time on container pull. I didn’t understood this “FROM ubuntu” Dockerfiles from very beginning. It feels so heavy.

  9. rudijs on February 12, 2016 at 6:54 am

    For Node.js web apps, shouldn’t there’s be a process manager to restart the server if it crashes? A process manger like PM2, forever or strongloop’s Arc.

Leave a Comment





This site uses Akismet to reduce spam. Learn how your comment data is processed.