Transforming the Future of NASA with CodeConf's Ariel Waldman

CodeConf 2015 will take place in Nashville on June 25 and 26. Ariel Waldman is one of many incredible speakers that will take the stage at the Bell Tower to share her expertise. We asked her some questions about her experiences at NASA, her vision for the future, and more. Check out her answers below!

ariel

Q: Why is collaboration important to you, and how do you think it can further scientific exploration and discovery?

A: To me, multidisciplinary collaboration is at the heart of furthering scientific exploration and discovery. In my work, I especially focus on unusual collaborations between people from different backgrounds. By having a fresh set of eyes from those who solve problems across a wide range of industries, new concepts emerge and go on to influence scientific processes, communication and discoveries in unexpected ways. Science doesn't require serendipity, but I'd argue it's significantly disadvantaged without it.

Q: You spoke at the very first CodeConf in 2011, and we’re excited to have you back since you’ve been doing so much exciting stuff in the meantime. What was your experience of CodeConf 2011, and what are you looking forward to seeing at CodeConf 2015?

A: CodeConf was fantastic. The community was so excited to have a wide range of topics at a "code" conference and I think it really helped open everyone up to new opportunities and aspirations. I think what made CodeConf 2011, and what will make CodeConf 2015, so special was the unexpected connections people end up drawing and a broadening of how big the universe to play in is.

Q: GitHub had the pleasure of hosting Science Hack Day in 2014, and we’ll do so again this year. What is the purpose of Science Hack Day, and what were some of the most exciting projects to come out of that event?

A: The mission of Science Hack Day is to get excited and make things with science! Science Hack Day is a 2-day-all-night event where anyone excited about making weird, silly or serious things with science comes together in the same physical space to see what they can prototype within 24 consecutive hours. Designers, developers, scientists and anyone who is excited about making things with science are welcome to attend – no experience in science or hacking is necessary, just an insatiable curiosity.

One of the projects I loved that came out of the Science Hack Day SF at GitHub last year was an interactive planetarium where you could explore the distance between stars, planets and constellations using your hands via a Kinect. I loved the idea of making a planetarium more physical. Because the code was made open source on GitHub, the project was then hacked on further and installed as a temporary exhibit at the American Museum of Natural History in NYC, where school kids, families and even an astronaut got to try it out!

Q: Tell us about NASA Innovative Advanced Concepts (NIAC). How can we participate in and contribute to the vision of this project?

A: NASA Innovative Advanced Concepts (NIAC) is arguably the coolest program at NASA - they fund and nurture all the radical, sci-fi-esque ideas that could one day transform future space missions. Submarines on Titan, human hibernation to Mars, comet hitchhiking space probes, you name it. Some utilize computer science and computer vision techniques – one project analyzes light versus dark areas on the Moon so that a lunar rover could navigate staying in continuous sunlight, thus able to be more efficient by having continuous solar power. The cool thing about NIAC is that they accept proposals from anyone every year around October, so if you have a credible idea you'd like to do further research and prototyping on that could transform a future space mission, you can apply!

Follow Ariel on Twitter for more updates on all of her projects, and grab your CodeConf ticket now! We can't wait to see you in Nashville next month.

Adding a billing manager to your organization

With the new billing manager role, you can invite individuals to manage the billing details of your organization without giving them access to code. The new role enables a user to:

  • Upgrade or downgrade the organization’s plan.
  • Update payment details like the credit card on file.
  • View history of past transactions and download receipts.
  • Receive receipts via email.

Billing managers won’t:

  • Be able to create or access repositories in your organization.
  • See private members of your organization.
  • Be seen in the list of organization members.

billing-managers-list

Leave the payment details to your wonderful finance team, and get back to your code!

For more information on adding a billing manager to your organization, check out the help article.

CodeConf 2015: Speakers, Workshops and Hotel Discount

We thought you'd like a preview of what we have in store for CodeConf 2015 in June before discounted ticket sales end on May 25th. We're beyond excited to be welcoming speakers from all over the globe and from companies and organizations of all sizes, who work on every facet of open source technology and represent many different parts of the community. Here's a sneak peak at some of the excellent speakers who will be presenting at CodeConf this year:

  • Eric Levine of Airbnb
  • Casey Rosenthal of Netflix
  • Christine Abernathy of Facebook
  • Corinne Warnshuis of Girl Develop It

This is just a sampling of the amazing line-up. Check out the full preview over at the CodeConf site.

But wait there's more!

  • Reserve a spot in one of our hands-on workshops led by expert trainers. Space is limited, so register early.
  • Join us the evening before the conference to enjoy the company of the Nashville open source community and grab your badge early. You won't want to miss the food from legendary Hattie B's.
  • Register for a discounted room at the Gaylord Opryland Hotel. Shuttles will depart at convenient intervals so you can easily get to and from the conference. By booking a room at the Opryland instead of a downtown hotel, you save about $100.
  • There are still a few sponsorship opportunities left, including our scholarship program. Check out the prospectus and drop us a line at events@github.com.
  • Find more details about everything we have in store for you on the new codeconf.com.

Lastly, we'd like to thank everyone who took the time to send us their ideas. We were overwhelmed by the quality and creativity of the 300+ proposals submitted. You are the heart of CodeConf.

Ticket prices go up to $399 on May 25th and we can't wait to see you in Nashville, so what are you waiting for?

Celebrate Pride with GitHub

Pride week is coming early to GitHub! We're throwing two LGBTQ-focused events on Tuesday June 2nd and Wednesday June 3rd, and will also be launching our 2015 Pridetocat shirt.

Patchwork

  • Tuesday June 2nd
  • 6:30pm-9:30pm
  • GitHub HQ, 88 Colin P. Kelly Jr. St, San Francisco

Join us for a special LGBTQ edition of Patchwork! No coding experience is needed to participate in this free hands-on workshop with support and talks from GitHubbers and Teagan Widmer from Refuge Restrooms. All LGBTQ folks welcome.

Register yourself here, or learn more about our Patchwork events.

Pride Celebration

  • Wednesday June 3rd
  • 6:00pm-9:00pm
  • GitHub HQ, 88 Colin P. Kelly Jr. St, San Francisco

We're hosting a celebration of the great things happening in the LGBTQ tech community! Celebrate Pride with old friends, make new ones, and learn about some amazing initiatives from organizations like Trans*H4CK, Lesbians Who Tech, Maven, GaymerX, and oSTEM!

We will also be launching our 2015 Pridetocat shirts, which will be available on site, with all proceeds going to Trans*H4CK, Lesbians Who Tech, and Maven.

Register now to attend! Open to all LGBTQ-identified folks and allies.

GitHub Enterprise, now on AWS GovCloud

GitHub is used by government agencies to collaborate on all sorts of interesting things, from software that aids first responders to White House policy, but sometimes agencies require a level of assurance that can only be afforded by a platform running on their own infrastructure.

Starting with version 2.2.2, released yesterday, AMIs for GitHub Enterprise, GitHub's self-hosted offering, are available in the AWS GovCloud (US) region, allowing US customers with specific regulatory requirements to run GitHub Enterprise in a federally compliant cloud environment.

What is GovCloud?

GovCloud is an isolated Amazon Web Services environment used by US government agencies at the federal, state, and local levels, along with contractors, researchers, educational institutions, and other US customers.

In terms of boxes checked, GovCloud has received a federal authority to operate (ATO), and conforms with U.S. International Traffic in Arms Regulations (ITAR) restrictions, Federal Risk and Authorization Management Program (FedRAMP) requirements, and Department of Defense (DoD) Cloud Security Model (CSM) Levels 3-5.

Getting started

You can begin using GitHub Enterprise in GovCloud today by requesting a free, 45-day trial, and customers that are already using GitHub Enterprise can migrate from other GitHub Enterprise deployment platforms to GovCloud by following these instructions.

If you have any questions about using GitHub in GovCloud, or GitHub + Government in general, please feel free to reach out to government@github.com at any time — we'd love to hear from you.

Happy (compliant) collaborating!

New Atom Shirt in the Shop

Prepare yourself for the future with the new Atom shirt and Atom Coasters.

Atom Shirt

Atom Coasters

Available in the GitHub Shop

The GitHub Engineering Blog

We are happy to introduce GitHub's Engineering Blog to the world. Starting today, you can read details about our infrastructure, learn about our development practices, and hear about the knowledge we've gained while running the world's largest code collaboration platform.

You can also get updates by following our Engineering Twitter account @GitHubEng.

Happy reading!

Git Merge 2015: Session Videos Now Available

gitmerge

On April 8-9, Git Merge returned to Europe, this time to La Gaite Lyrique in Paris. Over 200 people attended to celebrate ten years of Git, and with your help we raised over $15,000 in ticket sales, which was then donated entirely to the Software Freedom Conservancy.

Head over to git-merge.com to check out recorded sessions from expert speakers representing Google, Microsoft, SAP, Twitter, GitHub, Atlassian, and Amazon. These excellent talks focus on how teams use Git, as well as the implementation challenges of large Git deployments.

Thanks to everyone who attended! Make sure to follow @github on Twitter for announcements about Git Merge 2016.

New Octicons Shirt in the Shop

We love all the awesome little Octicons. Now you can wear Octicons...tons of Octicons!

Octicons Shirts

Available in the GitHub Shop

GitHub + Jupyter Notebooks = <3

Communicating ideas that combine code, data and visualizations can be hard, especially if you're trying to collaborate in realtime with your colleagues.

Whether you're a researcher studying Wikipedia, an astronomer investigating the movements of galaxies in our cosmic neighborhood or a data-scientist at fashion retailer Stitch Fix, producing insights from data and sharing is a common challenge.

Jupyter notebooks solve this problem by making it easy to capture data-driven workflows that combine code, equations, text and visualizations and share them with others. From today Jupyter notebooks render in all their glory right here on GitHub.

Jupyter Notebook toggle

With Git Large File Storage and Jupyter notebook support, GitHub has never been a better place to version and collaborate on data-intensive workflows. With more than 200,000 Jupyter notebooks already on GitHub we're excited to level-up the GitHub-Jupyter experience.

Looking to get started? Simply commit a .ipynb file to a new or existing repository to view the rendered notebook. Alternatively if you're looking for some inspiration then check out this incredible gallery of Jupyter notebooks.

Atom 1 Year Open Source Anniversary

One year ago today, Atom went from private alpha to open source software in hopes that the sunshine would help it reach its true potential.

Thanks to you, our users and contributors, Atom has had an incredible year. The number of contributors has skyrocketed, and with your support, the Atom team has hurdled significant technical challenges. Every day, the editor gets better, and its performance and stability improves. Take a look at how far Atom has come:

1-year-open-source

The future

With the help of many developers around the world, Atom 1.0 is in sight. We have been rapidly knocking items off of our 1.0 feature list, and plan on releasing 1.0 next month. It's been a very exciting year, and we look forward to many more as the Atom community grows.

1-year-open-source-milestone

Releases metadata for GitHub Pages

Last year, we exposed repository and organization metadata to help you showcase your open source efforts on GitHub Pages. We're adding releases metadata to that list, allowing you to more easily display information about your project's latest version (including release notes) and link directly to download the most recent releases.

Releases are exposed in the site.github.releases namespace within Jekyll, and contain all the information exposed through the releases API. For more information, see the Repository metadata on GitHub Pages help article.

Happy releasing!

Exporting Your Organization Audit Log

The Organization audit log allows you to quickly review actions performed by members of your organization on GitHub. You may need to look for specific activity or even through your organization's entire audit log to help aid in legal cases or keep record of suspicious activity.

To do just that, you now have the tools to export your organization's audit log in either JSON or CSV format.

Audit log export

Improving the GitHub workflow for the Microsoft Community

At Microsoft Build 2015, we announced deep GitHub integration in Visual Studio 2015, along with GitHub Enterprise 2.2.0. This release will help developers who work with the Microsoft stack make GitHub Enterprise a seamless part of their existing workflow. If you'd prefer to skip the summary, you can see a full list of new features in the release notes. If you're interested in the highlights, read on.

GitHub Enterprise now supported on Hyper-V and available on Microsoft Azure

It's important to be able to deploy and run GitHub Enterprise wherever you want. If your team works on the Microsoft stack, we have great news. With the 2.2.0 release, you can now host GitHub Enterprise in the Windows ecosystem using Hyper-V for local hosting or Azure for cloud hosting.

Powerful Collaboration - GitHub Enterprise

To request a 45-day trial of GitHub Enterprise on Azure just let us know.

GitHub Extension for Visual Studio

The new GitHub Extension for Visual Studio lets you work on GitHub repositories within Visual Studio 2015. Once you download the latest version of Visual Studio, you can log in to GitHub, clone and create repositories, and publish your local work without leaving your IDE. To see a walkthrough of the features, check out this video on Microsoft's Channel 9.

vs-clone

Microsoft Developer Assistant

In case you missed it, Microsoft also announced the availability of the Microsoft Developer Assistant for Visual Studio 2015—a way for developers to search for code on GitHub.com from Visual Studio. Just enter your query and you will see links to public code on GitHub.com, along with information about the project.

Wait, there’s more!

Beyond the Microsoft integration you’ll find lots more to like in Enterprise 2.2.0 including:

  • PDF rendering
  • Mobile web notifications
  • Quick pull requests
  • Xen hypervisor support

For a full list of what’s new, check out the release notes.

If you already use GitHub Enterprise, you can download the latest release from enterprise.github.com.

If you are attending Build 2015 and want to learn more, visit the GitHub booth on the third floor.

Eight lessons learned hacking on GitHub Pages for six months

Believe it or not, just over a year ago, GitHub Pages, the documentation hosting service that powers nearly three-quarters of a million sites, was little more than a 100-line shell script. Today, it's a fully independent, feature-rich OAuth application that effortlessly handles well over a quarter million requests per minute. We wanted to take a look back at what we learned from leveling up the service over a six month period.

What's GitHub Pages

GitHub Pages is GitHub's static-site hosting service. It’s used by government agencies like the White House to publish policy, by big companies like Microsoft, IBM, and Netflix to showcase their open source efforts, and by popular projects like Bootstrap, D3, and Leaflet to host their software documentation. Whenever you push to a specially named branch of your repository, the content is run through the Jekyll static site generator, and served via its own domain.

Eating our own ice cream

At GitHub, we're a big fan of eating our own ice cream (some call it dogfooding). Many of us have our own, personal sites hosted on GitHub Pages, and many GitHub-maintained projects like Hubot and Electron, along with sites like help.github.com, take advantage of the service as well. This means that when the product slips below our own heightened expectations, we're the first to notice.

We like to say that there's a Venn diagram of things that each of us are passionate about, and things that are important to GitHub. Whenever there's significant overlap, it's win-win, and GitHubbers are encouraged to find time to pursue their passions. The recent improvements to GitHub Pages, a six-month sprint by a handful of Hubbers, was one such project. Here's a quick look back at eight lessons we learned:

Lesson one: Test, test, and then test again

Before touching a single line of code, the first thing we did was create integration tests to mimic and validate the functionality experienced by users. This included things you might expect, like making sure a user's site built without throwing an error, but also specific features like supporting different flavors of Markdown rendering or syntax highlighting.

This meant that as we made radical changes to the code base, like replacing the shell script with a fully-fledged Ruby app, we could move quickly with confidence that everyday users wouldn't notice the change. And as we added new features, we continued to do the same thing, relying heavily on unit and integration tests, backed by real-world examples (fixtures) to validate each iteration. Like the rest of GitHub, nothing got deployed unless all tests were green.

Lesson two: Use public APIs, and when they don't exist, build them

One of our goals was to push the Pages infrastructure outside the GitHub firewall, such that it could function like any third-party service. Today, if you view your OAuth application settings you'll notice an entry for GitHub Pages. Internally, we use the same public-facing Git clone endpoints to grab your site's content that you use to push it, and the same public-facing repository API endpoints to grab repository metadata that you might use to build locally.

For us, that meant adding a few public APIs, like the inbound Pages API and outbound PageBuildEvent webhook. There's a few reasons why we chose to use exclusively public APIs and to deny ourselves access to "the secret sauce". For one, security and simplicity. Hitting public facing endpoints with untrusted user content meant all page build requests were routed through existing permission mechanisms. When you trigger a page build, we build the site as you, not as GitHub. Second, if we want to encourage a strong ecosystem of tools and services, we need to ensure the integration points are sufficient to do just that, and there's no better way to do that than to put your code where your mouth is.

Lesson three: Let the user make the breaking change

Developing a service is vastly different than developing an open source project. When you're developing a software project, you have the luxury of semantic versioning and can implement radical, breaking changes without regret, as users can upgrade to the next major version at their convenience (and thus ensure their own implementation doesn't break before doing so). With services, that's not the case. If we implement a change that's not backwards compatible, hundreds of thousands of sites will fail to build on their next push.

We made several breaking changes. For one, the Jekyll 2.x upgrade switched the default Markdown engine, meaning if users didn't specify a preference, we chose one for them, and that choice had to change. In order to minimize this burden, we decided it was best for the user, not GitHub, to make the breaking change. After all, there's nothing more frustrating than somebody else "messing with your stuff".

For months leading up to the Jekyll 2.x upgrade users who didn't specify a Markdown processor would get an email on each push, letting them know that Maruku was going the way of the dodo, and that they should upgrade to Kramdown, the new default, at their convenience. There were some pain points, to be sure, but it's preferable to set an hour aside to perform the switch and verify the output locally, rather than pushing a minor change, only to find your entire site won't publish and hours of frustration as you try to diagnose the issue.

Lesson four: In every communication, provide an out

We made a big push to improve the way we communicated with GitHub Pages users. First, we began pushing descriptive error messages when users' builds failed, rather than an unhelpful "page build failed" error, which would require the user to either build the site locally or email GitHub support for additional context. Each error message let you know exactly what happened, and exactly what you needed to do to fix it. Most importantly, each error included a link to a help article specific to the error you received.

Errors were a big step, but still weren't a great experience. We wanted to prevent errors before they occurred. We created the GitHub Pages Health Check and silently ran automated checks for common DNS misconfigurations on each build. If your site's DNS wasn't optimally configured, such as being pointed to a deprecated IP address, we'd let you know before it became a problem.

Finally, we wanted to level up our documentation to prevent the misconfiguration in the first place. In addition to overhauling all our GitHub Pages help documentation, we reimagined pages.github.com as a tutorial quick-start, lowering the barrier for getting started with GitHub Pages from hours to minutes, and published a list of dependencies, and what version was being used in production.

This meant that every time you got a communication from us, be it an error, a warning, or just a question, you'd immediately know what to do next.

Lesson five: Optimize for your ideal use case, not the most common

While GitHub Pages is used for all sorts of crazy things, the service is all about creating beautiful user, organization, and project pages to showcase your open source efforts on GitHub. Lots of users were doing just that, but ironically, it used to be really difficult to do so. For example, to list your open source projects on an organization site, you'd have to make dozens of client-side API calls, and hope your visitor didn't hit the API limit, or leave the site while they waited for it to load.

We exposed repository and organization metadata to the page build process, not because it was the most commonly used feature, but because it was at the core of the product's use case. We wanted to make it easier to do the right thing — to create great software, and to tell the world about it. And we've seen a steady increase in open source marketing and showcase sites as a result.

Lesson six: Successful efforts are cross-team efforts

If we did our job right, you didn't notice a thing, but the GitHub Pages backend has been completely replaced. Whereas before, each build would occur in the same environment as part of a worker queue, today, each build occurs in its own Docker-backed sandbox. This ensured greater consistency (and security) between builds.

Getting there required a cross-team effort between the GitHub Pages, Importer, and Security teams to create Hoosegow, a Ruby Gem for executing untrusted Ruby code in a disposable Docker sandbox. No one team could have created it alone, nor would the solution have been as robust without the vastly different use cases, but both products and the end user experience are better as a result.

Lesson seven: Match user expectations, then exceed them

Expectations are a powerful force. Everywhere on GitHub you can expect @mentions and emoji to "just work". For historical reasons, that wasn't the case with GitHub Pages, and we got many confused support requests as a result. Rather than embark on an education campaign or otherwise go against user expectations, we implemented emoji and @mention support within Jekyll, ensuring an expectation-consistent experience regardless of what part of GitHub you were on.

The only thing better than meeting expectations is exceeding them. Traditionally, users expected about a ten to fifteen minute lag between the time a change was pushed and when that change would be published. Through our improvements, we were able to significantly speed up page builds internally, and by sending a purge request to our third-party CDN on each build, users could see changes reflected in under ten seconds in most cases.

Lesson eight: It makes business sense to support open source

Jekyll may have been originally created to power GitHub Pages, but since then, it has become its own independent open source project with its own priorities. GitHubbers have always been part of the Jekyll community, but if you look at the most recent activity, you'll notice a sharp uptick in contributions, and many new contributors from GitHub.

If you use open source, whether it's the core of your product or a component that you didn't have to write yourself, it's in your best interest to play an active role in supporting the open source community, ensuring the project has the resources it needs, and shaping its future. We've started "open source Fridays" here at GitHub, where the entire company takes a break from the day-to-day to give back to the open source community that makes GitHub possible. Today, despite their beginnings, GitHub Pages needs Jekyll, not the other way around.

The numbers

Throughout all these improvements, the number of GitHub Pages sites has grown exponential, with just shy of a three-quarters of a million user, organization, and project sites being hosted by GitHub Pages today.

GitHub Pages sites over time

But the number of sites tells only half the story. Day-to-day use of GitHub Pages has also seen similar exponential growth over the past three years, with about 20,000 successful site builds completing each day as users continuously push updates to their site's content.

GitHub Pages builds per day

Last, you'll notice that when we introduced page build warnings in mid-2014, to proactively warn users about potential misconfigurations, users took the opportunity to improve their sites, with the percentage of failed builds (and number of builds generating warnings) decreasing as we enter 2015.

GitHub Pages is a small but powerful service tied to every repository on GitHub. Deceivingly simple, I encourage you to create your first GitHub Pages site today, or if you're already a GitHub Pages expert, tune in this Saturday to level up your GitHub Pages game.

Happy publishing!