Life as a GitHub Intern: What laser cutting taught me about contribution graphs

Anisha Gupta is a recent graduate from Arizona State University, a Campus Expert, and developer workshop leader at events around the world. She joined the GitHub Developer Marketing team in January as a Developer Relations Intern and will be working through Summer 2018. In this post, Anisha shares how she was able to connect with diverse communities and find inspiration, while working remotely from ASU, by laser cutting contribution graphs.

Students don’t realize how much stuff they get for free—I didn’t until I was three months away from graduation. I’d just started an internship on GitHub’s Developer Relations team when I also discovered my university’s laser cutting lab. I passed by the lab daily but never entered because I didn’t even know what laser cutting was. It didn’t occur to me to try it out until I found the perfect design idea: contribution graphs. My contribution graph tells me what I’ve contributed to, how I contributed, and how often I worked on projects.

After talking to a mentor from the GitHub Team, Katrina Owen, I learned that she works daily on her open source project, exercism.io, and it takes 100 commits to turn a gray square green on her contribution graph. This was humbling and inspiring to hear as a recent graduate just about to enter the developer industry. That’s when I decided to laser cut @kytrinyx’s contribution graphs from 2013 and 2014 to remind myself of the effort one has to take to reach their goals. What started as something cool to have on my desk is now my source of inspiration as I look ahead to building my skills as a developer.

Getting started with laser cutting

I worked with my school’s lab manager to outline the steps for the laser-cut contribution graph I wanted to create. These are the steps I followed:

  • Take a screenshot of the contribution graph you want to laser cut
  • Use software that’s connected with your laser cutter (in this case, CorelDraw)
  • Import the screenshot and convert it to a grayscale image
  • Adjust the laser cutter’s settings to fit the wood density and thickness
  • Click print

ContributionGraphs

ContributionCards1

Once I started laser cutting more contribution graphs, including one I gave to Katrina, I set out to work on a project which allowed all GitHub users to create laser-cut contribution graphs. I consulted Ladies Storm Hackathons (LSH), a Facebook group that empowers women to collaborate and go to hackathons together. I got an overwhelming response from members who were excited to be part of the project.

But now I had to screenshot 20 different contribution graphs, adjust their sizes, and put them into one SVG file. My team suggested that I create an application to automate the process, so I set out to build an app that would let me create laser-cut contribution graphs and then place an order for business cards.

Building the application

A first attempt

I started out by reaching out to the GitHub Ecosystem team, and Katrina suggested I look at Puppeteer, a headless Chrome tool that renders and screenshots pages without having to pull up the browser itself. I found a Puppeteer sample on Glitch, which I used as the basis of my application. I dove into testing different methods within Puppeteer and was able to grab screenshots of contribution graphs from GitHub usernames. The few lines of code below show the two core methods that powered the application. It navigated to my profile page and took a screenshot based on the clip parameters I specified:

await page.goto('https://github.com/ani6gup');
await page.screenshot({path: __dirname+'/public/puppeteer.png', clip: {x: 320, y:630, width:660, height:100}});

However, the clip parameters were too specific. Each user’s contribution graph is placed at a different pixel based on a user’s descriptions and pinned repositories. In short, the application only worked perfectly with my profile.

Try out the application

Refining the app

I pair programmed with John Crepezzi, who introduced me to Ruby and various gems and packages such as Nokogiri, a parser of many file types, and Octokit.rb, a simple way to connect with the GitHub API. Nokogiri parsed the profile page into one HTML file that’s used to grab and filter the GitHub contribution graph into its own variable (and later converts it to an SVG file):

doc = Nokogiri::HTML.parse(contents)
doc.css('.js-calendar-graph-svg > g').first['transform'] = nil
graph = doc.css(".js-calendar-graph-svg").first

For the front and back side of the business cards, the app provides SVG templates and information from the GitHub profile page are used to fill in the name and handle. Octokit collects the profile information based on the username, and it only requires one line to connect to the API: user = Octokit.user(login). The end product is an application which requires only a username to create three SVG files and place them into a folder.

By automating this process, I was able to print out 28 business cards at one time. The 28 in the photo below are a combination of people who have helped me, community members from LSH, and my GitHub Team.

28ContributionCards

How I feel about contribution graphs now

This project showed me how communities can come together to expand on an individual’s idea to create something larger. Working with contribution graphs helped me find common ground with other GitHub community members. I learned about the projects they worked on and how they came to release, maintain, and make their projects thrive on GitHub. In the past, I was intimidated by profiles with green-filled graphs, but I realized that each person has their own story to tell, no matter what their graph looks like. And there are always opportunities to contribute more.

If you’re interested in expanding the projects you contribute to on GitHub and seeing more of those green squares, here are some resources that have helped me:

If you would like laser cut your own business card or any design you had in mind, find a local makerspace to build things and become a part of a maker community.

Project board automation and template updates

We’ve made some changes to project automation that will provide you with more control when managing issues and pull requests in a project. Previously, issue and pull request cards behaved the same when they were added and moved across the board. Now you can specify different actions for them, like creating separate columns for in progress or reopened issues and pull requests.

Automation settings in a column

Template updates

Simplify the process of managing bugs with the new “Bug triage” project board template. It features “To do”, “High priority”, “Low priority,” and “Closed” columns for better bug tracking.

The “Automated kanban” template has also been updated for automated workflows and now places newly-added pull requests to the “In progress” column. New issues will still appear in the “To do” column.

Changing your settings

With the feature flag enabled, anyone with write access can manually configure new issue and pull request automation options on existing projects.

To configure these settings in existing projects, click Manage Automation on the columns you wish to update. For new projects, access the changes by setting up a project with the “Automated kanban” template, or by clicking Manage Automation on any columns you manually create.

Read the documentation to learn more.

Your Pride Month uniform is here: Get the shirt that gives back

pride-2018-blog

For the fourth year running, we’re kicking off Pride Month with limited-edition GitHub Pride and Trans Pride Shirts that help you show some pride and support the work of LGBTQ organizations while you do it.

Get your new favorite tee while you can. They’ll only be in the GitHub Shop until September 30.

Shop the shirts

pride-shirts-photo

pride-shirts-sleeve

Our new shirt design adds a little extra :heart: to your sleeve with retro ‘80s-inspired artwork in colors representing the pride and trans pride flags. The best part: For every shirt you buy, we’ll donate proceeds to some inspiring groups who are helping the LGBTQ community—find more information about their work below.

LGBTQ organizations you’ll be supporting

Jewish Family & Community Services (East Bay)

Rooted in Jewish values and historical experiences, and inspired by the strengths of the diverse communities they serve, Jewish Family & Community Services (East Bay) promotes the well-being of individuals and families by providing essential mental health and social services through every stage of life. Funds will be specifically marked for LGBTQ refugee services.

Trans Lifeline

Trans Lifeline works to end transgender suicide and improve overall mental health of transgender people through education, advocacy, and direct service. They empower transgender people to help one another and to shape our collective efforts by drawing upon our wealth of individual experiences.

Oakland LGBTQ Community Center

The Oakland LGBTQ Community Center is committed to supporting and enhancing the well-being of LGBTQ individuals, their families, and their allies.

Billy DeFrank LGBTQ Community Center

The Billy DeFrank LGBTQ Community Center provides community, leadership, advocacy, services, and support to the Silicon Valley’s LGBTQ people and their allies.

UCSF Alliance Health Project

The mission of the UCSF Alliance Health Project is to support the mental health and wellness of the lesbian, gay, bisexual, transgender, queer, and HIV-affected communities in constructing healthy and meaningful lives.

A bright future for GitHub

GitHub and Microsoft

I am very excited to announce that Microsoft is acquiring GitHub and expect the agreement to close by the end of the year. While it will still take a few months to finalize, we wanted to share the news as soon as we were able.

When GitHub first launched ten years ago, I could have never imagined this headline. Git was a powerful but niche tool, clouds were just things in the sky, and Microsoft was a very different company. Open source and business, people said at the time, mixed as well as oil and water.

We disagreed. As developers, we knew this was a false dichotomy—we had been using open source software successfully in a business setting for a long time. What we really needed was an easier way to work with others regardless of whether the code was public, private, or something in-between. We wanted to do it using Git, we wanted anyone in the world to be able to join in, and we didn’t want it to cost a dime if it was open source. So we created GitHub.

Now, of course, things are different. Git is far and away the most popular version control system, clouds are mostly computers, and Microsoft is the most active organization on GitHub in the world. Their VS Code project alone is beloved by millions of developers, entirely open source, and built using GitHub’s Electron platform. Beyond that, today major enterprises regularly embrace open source. The world has realized how important happy, productive developers really are. And also, people have smartphones now.

What hasn’t changed, however, is our focus on the developer. From the beginning, we have been obsessed with building a product for the people using it. We want to make developers more productive and we want more people to become developers. From “Code to Cloud and Code to Edge”, GitHub’s mission is to help every developer—regardless of experience level—learn, code, and ship software effectively.

So as we look to the next decade of software development and beyond, we know it’s all about the developer. And as we’ve gotten to know the team at Microsoft over the past few years through collaborating on projects from Git LFS to Electron, we’ve learned that they agree. Their work on open source has inspired us, the success of the Minecraft and LinkedIn acquisitions has shown us they are serious about growing new businesses well, and the growth of Azure has proven they are an innovative development platform.

But more than that, their vision for the future closely matches our own. We both believe GitHub needs to remain an open platform for all developers. No matter your language, stack, platform, cloud, or license, GitHub will continue to be your home—the best place for software creation, collaboration, and discovery.

We both believe that software development needs to become easier, more accessible, more intelligent, and more open, so more people can become developers and existing developers can spend more time focusing on the unique problems they’re trying to solve.

We both see the growing need for developers and the growing importance of software in all facets of our lives.

And, most importantly, we both believe we can do greater things together than alone. Collaboration, after all, is at the heart of everything we do.

As part of this change, Nat Friedman will be taking on the role of GitHub’s CEO. We have been searching for a new CEO for some time and found in both Microsoft and Nat a partner we believe will strengthen and grow the GitHub community and company over the next few years. Nat has a ton of experience with software and the open source software community, having co-founded Xamarin and worked on numerous open source projects over the years, and is the perfect person to help GitHub grow and continue to make life better for developers.

As for me, I’ll be taking on a new role at Microsoft working closely with Nat and the team, and will share more details on that in the future.

I’m extremely proud of what GitHub and our community have accomplished over the past decade, and I can’t wait to see what lies ahead. The future of software development is bright and I’m thrilled to be joining forces with Microsoft to help make it a reality.

@defunkt
CEO & Co-Founder, GitHub

Changelog

Subscribe

Discover new ways to build better

Try Marketplace apps free for 14 days

Learn more