1596540180
How we launched docs.github.com
We recently completed a major overhaul of GitHub’s documentation websites. When you visit docs.github.com today, you’ll see content from the former help.github.com and developer.github.com sites in a unified experience.
Our engineering goals were two-fold: 1) improve the reading and navigation experience for GitHub’s users; 2) improve the suite of tools that GitHub’s writers use to create and publish documentation.
Combining the content was the last of several complex projects we completed to reach these goals. Here’s the story behind this years-long effort, undertaken in collaboration with GitHub’s Product Documentation team and many other contributors.
A brief history of the docs sites
Providing separate docs sites for different audiences was the right choice for us for many years. But our plans evolved along with GitHub’s products. Over time, we aspired to help an international audience use GitHub by:
- Offering multi-language support for all content
- Scaling docs for new products
- Autogenerating API reference docs
- Providing interactive experiences
- Allowing anyone to easily contribute documentation
We couldn’t do these things when we had two static sites, each with its own codebase, its own way of organizing content, and its own markup conventions. Efforts were made to streamline the tooling over the years, but they were limited by the nature of static builds.
To achieve our goals, we determined we needed to write a custom dynamic backend, and eventually, combine the content.
Only fixing what was broken
Our docs sites were previously hosted on GitHub Pages using Jekyll practices: a content directory full of Markdown files and a data directory full of YAML files. This is a great setup for simple sites, and it worked for us for a long time. Although we outgrew Jekyll tooling, the writing conventions based in Markdown and YAML worked well. So we kept them, and we built the dynamic site around them.
Keeping these conventions let us alleviate pain points in the tooling without introducing a new paradigm for technical writing and asking writers to learn it. It also meant that writers could continue publishing content that helps people use GitHub in the old system while we built the new one.
What was broken?
We outgrew static site tooling for a number of reasons. A big factor was the complexity of versioning content for our GitHub Enterprise Server product.
We release a new version of GitHub Enterprise Server every three months, and we support docs for each version for one year before we deprecate them. At any time, we provide docs for four versions of GitHub Enterprise Server.
We handle this complexity by single-sourcing our docs. This means we provide multiple versions of each article, and a dropdown on the site lets users switch between versions. Here’s how it looked in the old help.github.com:
Versioning can be hard. Some articles are available in all versions. Some are GitHub.com-only. Some are Enterprise Server-only. Some have lots of internal conditionals, where a single paragraph or even a word may be relevant in some versions but not others. We also have workflows and tools for releasing new versions and deprecating old versions.
What does single-sourcing look like under the hood? Writers use the Liquid templating language (another Jekyll holdover) to render version-specific content using if / else statements:
{% if page.version == 'dotcom' or page.version ver_gt '2.20' %}
Content relevant to new versions
{% else %}
Content relevant to old versions
{% endif %}
Statements like this are all over the content and data files.
Static site generators are designed to do one build. They don’t build multiple versions of pages. To support our single-source approach in the Jekyll days, we had to create a backport process, in which writers would build Enterprise Server versions separately from building GitHub.com docs. Backport pull requests had to be reviewed, deployed to staging, and published as a separate process. Over the years, as we released new Enterprise Server versions, the tooling started to fray around the edges. Backports took a long time to build, did weird things, or got forgotten entirely. Ultimately, backports became a liability.
Launching a dynamic help.github.com
When we set out to create a new dynamic site, we started with help.github.com. We built it over six months and carefully coordinated with the writers to swap out the backend, while mostly leaving the content alone. In February 2019, we launched the new Node.js site backed by Express. On the frontend, there is just vanilla JavaScript and CSS using Primer.
It was a big improvement:
- No more build
- The app loads metadata for all pages at server startup, but the contents are rendered dynamically at page load.
- Shaved ~10 minutes off deploy times.
- Dynamic version rendering
- No more backports! Enterprise Server content is loaded at the same time as everything else.
- Fastly CDN
- Serves as a global edge cache to keep things fast.
- Better search using Algolia
- Less chatops, more GitHub flow
- Staging and production deployments happen automatically.
Internationalized docs
Within a few months, the dynamic backend allowed us to reach our next major milestone: internationalization. We launched the Japanese and simplified Chinese versions of the site in June 2019 and added support for Spanish and Portuguese by the end of the year. (Look for a deep dive post into the internationalization process coming soon!)
This was progress. But developer.github.com was still running on the old static build, and parts of it were starting to break down. We needed to bring the developer content into the new codebase.
#engineering #github
What is GEEK
Buddha Community
1603861600
How to Compare Multiple GitHub Projects with Our GitHub Stats tool
If you have project code hosted on GitHub, chances are you might be interested in checking some numbers and stats such as stars, commits and pull requests.
You might also want to compare some similar projects in terms of the above mentioned stats, for whatever reasons that interest you.
We have the right tool for you: the simple and easy-to-use little tool called GitHub Stats.
Let’s dive right in to what we can get out of it.
Getting started
This interactive tool is really easy to use. Follow the three steps below and you’ll get what you want in real-time:
1. Head to the GitHub repo of the tool
2. Enter as many projects as you need to check on
3. Hit the Update button beside each metric
In this article we are going to compare three most popular machine learning projects for you.
#github #tools #github-statistics-react #github-stats-tool #compare-github-projects #github-projects #software-development #programming
1618254581
Activate a Device - Netflix.com/activate, roku.com/link, amazon.com/mytv
geeksquad.com/chat-with-an-agent
walmart.capitalone.com/activate
#netflix.com/activate #roku.com/link #amazon.com/mytv #primevideo.com/mytv #samsung.com/printersetup
1611609121
Quick Pay Portal | www.quickpayportal.com | www.quickpayportal.com
Pay Medical Bills your bills @https://sites.google.com/view/www-quickpayportal-com/
It is really very easy to pay your bills at [priviabillpay.com](https://sites.google.com/view/www-quickpayportal-com/ "priviabillpay.com"). First of all, patients will have to go to the official Privia Medical Community Online portal . Patients can use the quick pay code of priviabillpay.com to make a one-time payment. On the first page of your statement, the QuickPay code is found. Using Priviabillpay to follow a few steps to get paid.
First of all, you must visit the official portal at [www.priviabillpay.com](https://sites.google.com/view/www-quickpayportal-com/ "www.priviabillpay.com")
In the box, fill out the QuickPay Code and tap Make a Payment.
You will be redirected to a page showing all your current rates.
Now select the fees you want to pay and click the check box that you want to accept quickly.
Finally, click on the payment option button.
Your payment details will be asked on the screen.
Fill out the field required and submit your payment.
Our Official Website : https://sites.google.com/view/www-quickpayportal-com/#www.priviabillpay.com #www-quickpayportal-com #quickpayportal.com #www.quickpayportal.com. #quickpayportal.com.
1595581560
Stay Safe on GitHub: Security Practices to Follow
gthen Access Controls
Implementing proper access control is one of the best practices for enhancing security, not only on GitHub but in every other environment where code security is imperative.
GitHub offers several options that users can employ to reduce the risk of improper exposure. But to start with, it is important to employ the least privilege model where users are only granted necessary permissions.
Here are some basic access control guidelines that you should follow:
- Restrict the creation of repositories to prevent users from exposing organization information in public repositories.
- Enable branch protection and status checks to ensure users can merge commits or manipulate branches safely.
- Allow or disallow forking private repositories to ensure users do not expose or share organizational code with unauthorized parties.
- Revoke access for all inactive users who are no longer part of the contributors.
- Review access rights to your GitHub projects periodically.
- Ensure users do not share GitHub accounts or passwords.
- Ensure every contributor uses two-factor authentication on their account.
- Rotate personal access tokens and SSH keys
Never Store Credentials in Your GitHub Files
Leaking secrets to your GitHub repositories, either through code, configuration files, or commit messages, provides a gateway for attacks.
#tutorial #github #access control #software security #repository management #github issues #source code analysis #github apps #github enterprise #git best practices
1596161100
Stay Safe on GitHub: Security Practices to Follow
GitHub is undoubtedly the largest and most popular social development platform in the world. According to its 2019 State of the Octoverse Report, GitHub is home to over 40 million, and the community keeps expanding every day.
As developers in this deeply interconnected community use open source code to build software, Github security should be a top priority. This is because extensive code re-use increases the risk of distributing vulnerabilities from one dependency or repository to another. As such, every contributor should focus on creating a secure development environment.
Here are eight security practices that GitHub users can follow to stay safe and protect their code:
Strengthen Access Controls
Implementing proper access control is one of the best practices for enhancing security, not only on GitHub but in every other environment where code security is imperative.
GitHub offers several options that users can employ to reduce the risk of improper exposure. But to start with, it is important to employ the least privilege model where users are only granted necessary permissions.
Here are some basic access control guidelines that you should follow:
- Restrict the creation of repositories to prevent users from exposing organization information in public repositories.
- Enable branch protection and status checks to ensure users can merge commits or manipulate branches safely.
- Allow or disallow forking private repositories to ensure users do not expose or share organizational code with unauthorized parties.
- Revoke access for all inactive users who are no longer part of the contributors.
- Review access rights to your GitHub projects periodically.
- Ensure users do not share GitHub accounts or passwords.
- Ensure every contributor uses two-factor authentication on their account.
- Rotate personal access tokens and SSH keys
#tutorial #github #access control #software security #repository management #github issues #source code analysis #github apps #github enterprise #git best practices