pull request

39 results back to index


pages: 1,136 words: 73,489

Working in Public: The Making and Maintenance of Open Source Software by Nadia Eghbal

Amazon Web Services, Apollo 11, barriers to entry, Benevolent Dictator For Life (BDFL), Big Tech, bitcoin, Clayton Christensen, cloud computing, commoditize, commons-based peer production, context collapse, continuous integration, crowdsourcing, cryptocurrency, David Heinemeier Hansson, death of newspapers, Debian, disruptive innovation, Dunbar number, en.wikipedia.org, eternal september, Ethereum, Firefox, Free Software Foundation, Guido van Rossum, Hacker Ethic, Hacker News, Induced demand, informal economy, information security, Jane Jacobs, Jean Tirole, Kevin Kelly, Kickstarter, Kubernetes, leftpad, Mark Zuckerberg, Menlo Park, Neal Stephenson, Network effects, node package manager, Norbert Wiener, pirate software, pull request, RFC: Request For Comment, Richard Stallman, Ronald Coase, Ruby on Rails, side project, Silicon Valley, Snapchat, social graph, software as a service, Steve Jobs, Steve Wozniak, Steven Levy, Stewart Brand, tacit knowledge, the Cathedral and the Bazaar, The Death and Life of Great American Cities, The Nature of the Firm, TikTok, Tragedy of the Commons, transaction costs, two-sided market, urban planning, web application, wikimedia commons, Yochai Benkler, Zimmermann PGP

By contrast, “issue zero” and “pull request zero,” with a steady rate of issues and pull requests opened and closed, would suggest that a project is in comparatively better shape. No metrics are perfect, however. Data can give us insights, but we still need to write the story. A few important caveats to keep in mind when developing project health metrics: LACK OF GRANULARITY: A project could have one massive pull request that takes months to get merged, versus a pull request containing a few typo fixes—yet each of these would count as one pull request. Commits are more granular than pull requests, but they aren’t uniform in size either.

GitHub repository for CPython.79 At minimum, open source projects hosted on GitHub can be broken into three parts: code (the final output of a project), an issue tracker (a way to discuss changes), and pull requests (a way to make changes). Code is typically managed using a version control system, of which Git is the most popular. This system is bundled directly with the code, using a .git file directory, which means that changes will be tracked irrespective of where those files are actually hosted, whether on GitHub or elsewhere. Issues and pull requests, on the other hand, live on GitHub. Although the concepts of an issue (also called a ticket) and a pull request (also called a patch) are much older than GitHub, issues and pull requests are GitHub’s branding of these features, and therefore aren’t quite so easy to migrate between platforms.

Ideally, new interactions (such as opened issues and pull requests) are addressed quickly, which often depends upon maintainer responsiveness. A few metrics related to responsiveness include: NUMBER OF OPEN ISSUES AND PULL REQUESTS: A high number of open issues or pull requests suggests the project is not well maintained, although projects have different philosophies as to whether they prefer to keep issues open or closed. AVERAGE TIME TO FIRST RESPONSE, from a maintainer, on a new issue or pull request. (Sometimes, maintainers use bots as first responders.) AVERAGE TIME TO CLOSE AN ISSUE OR PULL REQUEST.181 Activity that directly feeds back into “work done” (meaning, changes to the code) should weigh more heavily than issues and questions.


pages: 549 words: 134,988

Pro Git by Scott Chacon, Ben Straub

Chris Wanstrath, continuous integration, creative destruction, Debian, distributed revision control, GnuPG, pull request, remote working, revision control, systems thinking, web application

This can allow you to test the merge before even hitting the button. Pull Requests on Pull Requests Not only can you open Pull Requests that target the main or master branch, you can actually open a Pull Request targeting any branch in the network. In fact, you can even target another Pull Request. If you see a Pull Request that is moving in the right direction and you have an idea for a change that depends on it or you’re not sure is a good idea, or you just don’t have push access to the target branch, you can open a Pull Request directly to it. When you go to open a Pull Request, there is a box at the top of the page that specifies which branch you’re requesting to pull to and which you’re requesting to pull from.

If you wish, you can create and switch to a topic branch and then run this command to merge in the Pull Request changes. The other interesting URLs are the .diff and .patch URLs, which as you may guess, provide unified diff and patch versions of the Pull Request. You could technically merge in the Pull Request work with something like this: $ curl http://github.com/tonychacon/fade/pull/1.patch | git am Collaborating on the Pull Request As we covered in “The GitHub Flow”, you can now have a conversation with the person who opened the Pull Request. You can comment on specific lines of code, comment on whole commits or comment on the entire Pull Request itself, using GitHub Flavored Markdown everywhere.

If you’re working on a feature with someone and you both have write access to the project, you can push a topic branch to the repository and open a Pull Request on it to the master branch of that same project to initiate the code review and discussion process. No forking necessary. Advanced Pull Requests Now that we’ve covered the basics of contributing to a project on GitHub, let’s cover a few interesting tips and tricks about Pull Requests so you can be more effective in using them. Pull Requests as Patches It’s important to understand that many projects don’t really think of Pull Requests as queues of perfect patches that should apply cleanly in order, as most mailing list-based projects think of patch series contributions. Most GitHub projects think about Pull Request branches as iterative conversations around a proposed change, culminating in a unified diff that is applied by merging.


Version Control With Git: Powerful Tools and Techniques for Collaborative Software Development by Jon Loeliger, Matthew McCullough

continuous integration, Debian, distributed revision control, GnuPG, Larry Wall, peer-to-peer, peer-to-peer model, pull request, revision control, Snow Crash, web application, web of trust

.), symmetric difference, Commit Ranges, git diff and Commit Ranges, Ahead and Behind personal account in GitHub, Repo for Public Code PHP: Hypertext Preprocessor (PHP), GitHub Pages (Git for Websites) physical data layout, in Git, Pathname Versus Content pickaxe, Using Pickaxe–Using Pickaxe plug-ins, submodules for, Use Cases plus sign (+), Viewing Commit Differences, Viewing Branches, Diffs, git diff with conflicts, The refspec, Interactive Hunk Staging in diff, Diffs, git diff with conflicts in git show-branch output, Viewing Branches in refspec, The refspec and location for split operation, Interactive Hunk Staging when viewing commit differences, Viewing Commit Differences plus signs (+++), in diff, Diffs ports, default, Referring to Remote Repositories, Publishing repositories using git-daemon for Git, Referring to Remote Repositories for inetd service, Publishing repositories using git-daemon post hook, Hooks post-applypatch hook, Patch-Related Hooks post-checkout hook, Hooks, Other Local Repository Hooks post-commit hook, Commit-Related Hooks post-merge hook, Other Local Repository Hooks post-receive hook, Push-Related Hooks post-update hook, Hooks, Push-Related Hooks post-update script, Publishing repositories using an HTTP daemon pound sign (#), The .gitignore File, A Merge with a Conflict for comments, A Merge with a Conflict in .gitmore file, The .gitignore File PowerPC architecture, Converting to a Different Upstream Repository pre hook, Hooks pre-applypatch hook, Patch-Related Hooks pre-auto-gc hook, Other Local Repository Hooks pre-commit hook, Hooks, Creating Your First Hook, Commit-Related Hooks creating, Creating Your First Hook pre-rebase command, Other Local Repository Hooks pre-receive hook, Push-Related Hooks prepare-commit-msg hook, Commit-Related Hooks --preserve-merges option, for git rebase command, rebase Versus merge --pretty=oneline option, for git log command, Merging Two Branches, The Stash, Example: A Shallow Clone of a Single Branch --pretty=short option, for git log command, Viewing Old Commits printing, Using git add, Viewing Old Commits, Creating Your First Hook changes from commit, Viewing Old Commits error messages from “pre” script, Creating Your First Hook SHA1 hash, Using git add projects, Forking Projects–Forking projects at GitHub, Combining Projects–The git submodule Command, The Obvious Solution: Import the Code into Your Project–The Automated Solution: Checking out Subprojects Using Custom Scripts, Interactive Hunk Staging, Tags Automatically Becoming Archives archive on GitHub, Tags Automatically Becoming Archives combining, Combining Projects–The git submodule Command forking, Forking Projects–Forking projects at GitHub guidelines for, Interactive Hunk Staging importing code into, The Obvious Solution: Import the Code into Your Project–The Automated Solution: Checking out Subprojects Using Custom Scripts public code, repositories for, Repo for Public Code–Repo for Public Code public history, changing, Changing Public History–Changing Public History publishing branches, Using Branches publishing repositories, Remote Repositories, Publishing Repositories–Publishing Your Repository to GitHub, Repositories with Controlled Access–Publishing Your Repository to GitHub, Repositories with Anonymous Read Access–Publishing via Git and HTTP daemons, Publishing a repository using Smart HTTP–Publishing a repository using Smart HTTP, Publishing via Git and HTTP daemons, Publishing Your Repository to GitHub–Publishing Your Repository to GitHub, Repository Publishing Advice–Repository Publishing Advice, Separate Commit and Publish Steps–Separate Commit and Publish Steps advice, Repository Publishing Advice–Repository Publishing Advice with anonymous read access, Repositories with Anonymous Read Access–Publishing via Git and HTTP daemons with controlled access, Repositories with Controlled Access–Publishing Your Repository to GitHub with Git and HTTP daemons, Publishing via Git and HTTP daemons with GitHub, Publishing Your Repository to GitHub–Publishing Your Repository to GitHub separation of commit and, Separate Commit and Publish Steps–Separate Commit and Publish Steps with Smart HTTP, Publishing a repository using Smart HTTP–Publishing a repository using Smart HTTP "pull into a dirty tree" scenario, The Stash, GitHub in Sum (see git pull command) pull requests, Forking projects at GitHub, Creating Pull Requests–Creating Pull Requests, Managing Pull Requests–Managing Pull Requests GitHub, Creating Pull Requests–Creating Pull Requests, Managing Pull Requests–Managing Pull Requests creating, Creating Pull Requests–Creating Pull Requests managing, Managing Pull Requests–Managing Pull Requests push operation, Non–Fast-Forward Pushes–Non–Fast-Forward Pushes, Creating a GitHub Repository for local contents to GitHub, Creating a GitHub Repository non-fast-forward, Non–Fast-Forward Pushes–Non–Fast-Forward Pushes push-related hooks, Push-Related Hooks–Push-Related Hooks Q querying state of index, It’s All About the Index quotes ('), for ref as single word, The Reflog R -r option, for Unix diff, Diffs RCS (Revision Control System), Precedents Reachability, Commit Ranges, Garbage Collection in garbage collection, Garbage Collection in graphs, Commit Ranges read-only address, cloned submodules with, Why Read Only?

git reset command, Aborting or Restarting a Merge, Aborting or Restarting a Merge, Using git reset–Using git reset, Using git reset, Using git reset, Using git reset, Using git reset–Using git reset, Using git reset, Using git reset, Using git reset, Using git reset, Using git reset, Using git reset, reset, revert, and checkout, The Stash, Merge Conflicts, Recovering a Lost Commit to eliminate topmost commit, Using git reset–Using git reset --hard, Aborting or Restarting a Merge, Aborting or Restarting a Merge, Using git reset, Using git reset, Using git reset, Using git reset, The Stash --hard ORIG_HEAD, Merge Conflicts and lost commit, Recovering a Lost Commit --mixed, Using git reset --soft, Using git reset, Using git reset, Using git reset, Using git reset git rev-list command, Generating Patches, Generating Patches, Date-Based Checkout, Retrieve Old Version of a File --no-merges, Generating Patches -v, Generating Patches git rev-parse command, Relative Commit Names, The Reflog, Examining the Hashes of Submodule Commits git revert command, Using git revert, reset, revert, and checkout git rm command, Removing and Renaming Files in Your Repository, File Management and the Index, Using git rm–Using git mv, Using git rm --cached, Using git rm git send-email command, Patches, Mailing Patches git show command, Viewing Your Commits, Commits, Finishing Up a Conflict Resolution --pretty=fuller, Commits git show-branch command, Viewing Your Commits, Relative Commit Names, Viewing Branches–Viewing Branches, Viewing Branches, Deleting Branches, The Stash, Pushing Your Changes, Applying Patches --more option, Viewing Branches git show-ref command, The refspec git stash branch command, The Stash git stash command, The Stash–The Stash, The Stash, The Stash, Interactive Rebase with a Dirty Working Directory --all option, The Stash for dirty working directory, Interactive Rebase with a Dirty Working Directory --include-untracked option, The Stash git stash drop command, The Stash git stash list command, The Stash–The Stash git stash pop command, The Stash, The Stash git stash save command, The Stash git stash show command, The Stash git status command, Adding a File to Your Repository, It’s All About the Index, File Classifications in Git, Using git add, Using git commit --all, Locating Conflicted Files, Using git reset, Ahead and Behind .git subdirectory, Inside the .git Directory–Inside the .git Directory git submodule add command, The git submodule Command, Submodule Commands git submodule add URL command, Credential Reuse git submodule command, The Native Solution: gitlinks and git submodule–The git submodule Command git submodule foreach command, Submodule Commands git submodule init command, The git submodule Command, Submodule Commands git submodule status command, Submodule Commands git submodule summary command, Submodule Commands git submodule update command, Detached HEAD Branches, The git submodule Command, Submodule Commands git svn clone command, Example: A Shallow Clone of a Single Branch–Example: A Shallow Clone of a Single Branch, Cloning All the Branches, Cloning All the Branches --prefix=svn/, Cloning All the Branches --stdlayout, Cloning All the Branches git svn command, Example: A Shallow Clone of a Single Branch, Example: A Shallow Clone of a Single Branch, Pushing, Pulling, Branching, and Merging with git svn, Pushing, Pulling, Branching, and Merging with git svn, Keeping Your Commit IDs Straight, How dcommit handles merges, Reconstructing the git-svn Cache–Reconstructing the git-svn Cache --authors-file, Keeping Your Commit IDs Straight pushing, pulling, branching and merging, Pushing, Pulling, Branching, and Merging with git svn reconstructing cache, Reconstructing the git-svn Cache–Reconstructing the git-svn Cache vs. git svn rebase command, Pushing, Pulling, Branching, and Merging with git svn working directory, Example: A Shallow Clone of a Single Branch git svn create-ignore command, svn:ignore Versus .gitignore git svn dcommit command, Keeping Your Commit IDs Straight, Merging Back into Subversion, Reconstructing the git-svn Cache git svn rebase command, Committing Through git svn rebase, Pushing, Pulling, Branching, and Merging with git svn committing through, Committing Through git svn rebase vs. git svn command, Pushing, Pulling, Branching, and Merging with git svn git svn repository, cloning all branches, Cloning All the Branches–Cloning All the Branches git symbolic-ref command, refs and symrefs git tag command, Tags Git tags, Tags Automatically Becoming Archives Git Tower, Submodules on the Horizon Git transfer protocol, Patches git update-index command, --assume-unchanged Makefile, Keep, But Don’t Track, This File git update-ref command, Updating and Deleting refs Git URLs, Referring to Remote Repositories git whatchanged command, Quick Overview of Changes, Quick Overview of Changes–Quick Overview of Changes --since= option, Quick Overview of Changes git write-tree command, Files and Trees, Commits git-core package, Debian/Ubuntu git-daemon command, Referring to Remote Repositories, Publishing repositories using git-daemon–Publishing repositories using git-daemon, Publishing repositories using git-daemon --export-all, Publishing repositories using git-daemon git-daemon-run, Debian/Ubuntu git-email command, Debian/Ubuntu git-grep command, Using git-grep to Search a Repository–Using git-grep to Search a Repository, Using git-grep to Search a Repository command line options, Using git-grep to Search a Repository for searching repository, Using git-grep to Search a Repository–Using git-grep to Search a Repository git-gui, Debian/Ubuntu git-http-backend command, Publishing a repository using Smart HTTP Git-over-SSH protocol, Repository Publishing Advice git-submodule.sh shell script, The git submodule Command–The git submodule Command git-svn-id command, How dcommit handles merges git-svn-id, in commit message, Example: A Shallow Clone of a Single Branch git/.git directory, gitlink to, Gitlinks .git/config file, Remotes, Referring to Remote Repositories, Remote Configuration, Using git config, Using git config, Creating Tracking Branches, The git submodule Command–The git submodule Command adding branch entry, Creating Tracking Branches adding to, Using git config, Using git config copying .gitmodules file settings to, The git submodule Command–The git submodule Command .git/hooks directory, Hooks, Installing Hooks .git/logs directory, reflogs stored under, The Reflog .git/logs/HEAD file, The Reflog .git/MERGE_HEAD file, How Git Keeps Track of Conflicts .git/MERGE_MSG file, How Git Keeps Track of Conflicts .git/objects directory, Inside the .git Directory .git/rebase-apply directory, Applying Patches .git/refs/ directory, refs and symrefs ~/.gitconfig file, Configuration Files GitHub, Publishing Your Repository to GitHub, Forking projects at GitHub–Forking projects at GitHub, Submodules on the Horizon, Submodules on the Horizon, Repo for Public Code, Creating a GitHub Repository–Creating a GitHub Repository, Creating a GitHub Repository, Creating a GitHub Repository, Watchers, News Feed, Forks–Forks, Forks, Creating Pull Requests–Creating Pull Requests, Managing Pull Requests–Managing Pull Requests, Managing Pull Requests, Notifications, Finding Users, Projects, and Code, Finding Users, Projects, and Code, Wikis, GitHub Pages (Git for Websites), In-Page Code Editor, Tags Automatically Becoming Archives, Organizations Advanced Search page, Finding Users, Projects, and Code automatic merge button for Git commit, Managing Pull Requests creating account, Repo for Public Code creating repository, Publishing Your Repository to GitHub, Creating a GitHub Repository–Creating a GitHub Repository Explore page, Finding Users, Projects, and Code forking projects at, Forking projects at GitHub–Forking projects at GitHub hyperlinking of submodules, Submodules on the Horizon Mozilla’s Act control, In-Page Code Editor network graph, Forks New Repository page, Creating a GitHub Repository news feed, News Feed notifications, Notifications organizations, Organizations pages (Git for websites), GitHub Pages (Git for Websites) personal forks of projects, Forks–Forks project archive creation, Tags Automatically Becoming Archives pull requests, Creating Pull Requests–Creating Pull Requests, Managing Pull Requests–Managing Pull Requests creating, Creating Pull Requests–Creating Pull Requests managing, Managing Pull Requests–Managing Pull Requests pushing local contents to repository, Creating a GitHub Repository submodule hyperlinks on repositories, Submodules on the Horizon watchers, Watchers wikis, Wikis GitHub Enterprise, GitHub Enterprise GitHub.com, Forking Projects .gitignore file, File Classifications in Git, File Classifications in Git, The .gitignore File–The .gitignore File, svn:ignore Versus .gitignore svn:ignore vs., svn:ignore Versus .gitignore gitk (Git browser), Debian/Ubuntu, Using gitk to View the Commit Graph–Using gitk to View the Commit Graph, Using git bisect to view commit graph, Using gitk to View the Commit Graph–Using gitk to View the Commit Graph gitlinks, Gitlinks–Gitlinks, The git submodule Command git add to update, The git submodule Command .gitmodules file, The git submodule Command, The git submodule Command–The git submodule Command, Credential Reuse copying settings to .git/config file, The git submodule Command–The git submodule Command username as part of recorded address, Credential Reuse Gitolite project, Repositories with Controlled Access gitweb, Debian/Ubuntu GIT_AUTHOR_EMAIL environment variable, Configuring the Commit Author GIT_AUTHOR_NAME environment variable, Configuring the Commit Author $GIT_DIR variable, refs and symrefs GIT_EDITOR environment variable, Adding a File to Your Repository --global option, Configuration Files, Have You Been Here Before?

It also automates the most burdensome step of incorporating new code, merging it in, which can in most cases be done from the GitHub site on a Pull Request page via a mere button click. Managing Pull Requests A successful project on GitHub has a queue of Pull Requests (Figure 21-15) to manage. Anyone that is a collaborator on this core instance of the project can manage and process pull requests. It is useful to note that pull requests do not necessarily have to come from forks. Disciplined contributors that have the collaborator privilege on the core project may still decide to use pull requests as a means of soliciting code feedback before merging it in. Figure 21-15. Project pull request queue Pull requests are such an important part of the GitHub ecosystem that each user has his own custom dashboard to display pull requests across all the projects he is associated with as a contributor (Figure 21-16).


pages: 266 words: 79,297

Forge Your Future with Open Source by VM (Vicky) Brasseur

AGPL, anti-pattern, Benevolent Dictator For Life (BDFL), call centre, continuous integration, Contributor License Agreement, Debian, DevOps, don't repeat yourself, en.wikipedia.org, Firefox, FOSDEM, Free Software Foundation, Guido van Rossum, information security, Internet Archive, Larry Wall, microservices, Perl 6, premature optimization, pull request, Richard Stallman, risk tolerance, Turing machine

Isn’t it nice to read that something is somewhat standardized, after all these pages of “every project does it differently”? Introducing the Pull Request The primary mechanism for submitting a contribution to these services is called a pull request. Some services call it a merge request, but this refers to more or less the same process. We’ll use “pull request” or “PR” here, since these are what you’ll hear people use most often. The term “pull request” comes from the git commmand request-pull and was popularized in its current form by GitHub. In git, as a distributed version control system, each person can have their own copy of a repository, and each copy could be the source of other copies.

As you’re working on your contribution, other people are continuing to submit and merge other changes into origin and evolving the project. Once you submit your pull request, you enter a feedback loop with community members, working with them to refine your contribution. After you’ve collaborated with them to put the final shine on it, a community member will pull (merge) your contribution into the project. Make the Pull Request Now you’re ready to open that pull request to the origin repository. The actual steps for this vary by tool and by repository provider, so make sure to read their instructions before going forward.

At least one is in use today, so while I won’t go into detail (abundant documentation is available on the internet), it’s helpful for you to know about the other option that exists. The predominant form of contributions prior to the invention of pull requests was patch files. A patch is a specialized diff that is dumped to a file and can then be shared to others and applied to a project. The process for creating and applying a patch file varies by version control system and by project. Because patch files were used extensively for so many years, you’ll often hear people refer to all contributions as “patches,” even if the contribution is submitted as a pull request. While pull requests are the most common form of submission used today, some projects still rely on patch files for receiving contributions, including the Linux kernel.


pages: 193 words: 36,189

Html5 Boilerplate Web Development by Divya Manian

en.wikipedia.org, Firefox, Google Chrome, node package manager, pull request, Ruby on Rails, search engine result page

Ideally your bug report should contain the following: A short and descriptive title A summary of the issue and the browser/Operating Systems where this bug occurs If it is possible, steps to reproduce the bug A URL to the reduced test case (you can host one on jsfiddle.net or codepen.io) Any other information that would be relevant to the bug, including lines of code that might be the cause of the bug, and potential solutions Ideally, a bug report should be self-contained, so contributors do not have to follow up with you again to find out more about the bug and can instead focus on resolving it. Following this process to file a bug report is a learning experience in itself in how to find out what is wrong with the markup, style, or script that you wrote. Pull requests If you have ideas on how to improve HTML5 Boilerplate, patches to fix some existing issues, improvements or new features, you would submit what is known as a pull request. A pull request is a set of changes you can submit for review to the HTML5 Boilerplate GitHub repository, so it can be reviewed by the core contributors and merged into HTML5 Boilerplate if found to be useful. A good way to start contributing would be to find a small issue that you think you can fix, fork the GitHub project (learn more on what this means at help.github.com/articles/fork-a-repo), work on your changes and submit a pull request.

Please adhere to these Git commit message guidelines at tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html or your pull request is unlikely be merged into the main project. Locally merge (or rebase) the upstream branch into your topic branch. Push your topic branch up to your fork (git push origin <topic-branch-name>). Open a pull request with a clear title and description. Please mention which browsers you tested in. This may seem like a lot of work, but it makes your pull requests significantly easier to understand and faster to merge. Moreover, your code becomes the documentation of the work you have done and anyone who wants to know why that section looks the way it does can go back to your commits and understand exactly why it is the case.

A good way to start contributing would be to find a small issue that you think you can fix, fork the GitHub project (learn more on what this means at help.github.com/articles/fork-a-repo), work on your changes and submit a pull request. If your contribution changes a lot of lines of code and alters the nature of the project drastically, consider opening an issue on the GitHub project first. The following are the steps to get started with creating a pull request: Fork the project. Clone your fork (in your terminal, enter git clone https://github.com/<your-username>/html5-boilerplate.git and press Enter). Add an upstream remote (in your terminal enter git remote add upstream https://github.com/h5bp/html5-boilerplate.git and press Enter).


Producing Open Source Software: How to Run a Successful Free Software Project by Karl Fogel

active measures, AGPL, barriers to entry, Benjamin Mako Hill, collaborative editing, continuous integration, Contributor License Agreement, corporate governance, Debian, Donald Knuth, en.wikipedia.org, experimental subject, Firefox, Free Software Foundation, GnuPG, Hacker Ethic, Hacker News, intentional community, Internet Archive, iterative process, Kickstarter, natural language processing, off-by-one error, patent troll, peer-to-peer, pull request, revision control, Richard Stallman, selection bias, slashdot, software as a service, software patent, SpamAssassin, the Cathedral and the Bazaar, Wayback Machine, web application, zero-sum game

The project may also have moved on since the clone was made and contain new changes that the contributor does not have, but these can be ignored for the purposes of discussion here. A pull request is directional: it is for sending changes the contributor has that the receiver does not, and is not about changes flowing in the reverse direction. In practice, the two copies are usually stored on the same hosting site, and the contributor can initiate the pull request by simply clicking a button. On GitHub, and perhaps on other hosting sites, creating a pull request automatically creates a corresponding ticket in the project's bug tracker, so that a pending pull request can be conveniently tracked using the same workflow as any other issue.

The moment when a code change is merged to the project's master branch is when it becomes officially part of the project. It is no longer the sole responsibility of whoever submitted it; it is the collective responsibility of the project as a whole. Pull requests A pull request is a request from a contributor to the project that a certain change be "pulled" into the project (usually into the project's master branch, though sometimes pull requests are targeted at some other branch). The change is offered in the form of the difference between the contributor's copy (or "clone") of the project and the project's own copy. The two copies share most of their change history, of course, but at a certain point the contributor's diverges — it contains the change the contributor has implemented and that the project does not have yet.

Some projects have also contributions enter through a collaborative code review tool, such as Gerrit or Review Board, although GitHub has started building some of the features of code-review tools into its pull request management interface. Pull requests are so frequent a topic of discussion that you will often see people abbreviate them as "PR", as in "Yeah, your proposed fix sounds good. Would you send me a PR please?" For newcomers, however, the term "pull request" is sometimes confusing, however, because it sounds like it is request by the contributor to pull a change from someone else, when actually it is a request the contributor makes to to someone else (the project) to pull the change from the contributor.


pages: 265 words: 60,880

The Docker Book by James Turnbull

Airbnb, continuous integration, Debian, DevOps, domain-specific language, false flag, fault tolerance, job automation, Kickstarter, Kubernetes, microservices, MVC pattern, platform as a service, pull request, Ruby on Rails, software as a service, standardized shipping container, web application

You should also always run the full test suite on your branch before submitting a pull request. Any pull request with a feature in it should include updates to the documentation. You should use the process above to test your documentation changes before you submit your pull request. There are also specific guidelines (as we mentioned above) for documentation that you should follow. We have some other simple rules that will help get your pull request reviewed and merged quickly: Always run gofmt -s -w file.go on each changed file before committing your changes. This produces consistent, clean code. Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.

[PASSED]: save - save a repo using stdout [PASSED]: load - load a repo using stdout [PASSED]: save - save a repo using -o [PASSED]: load - load a repo using -i [PASSED]: tag - busybox -> testfoobarbaz [PASSED]: tag - busybox's image ID -> testfoobarbaz [PASSED]: tag - busybox fooo/bar [PASSED]: tag - busybox fooaa/test [PASSED]: top - sleep process should be listed in non privileged mode [PASSED]: top - sleep process should be listed in privileged mode [PASSED]: version - verify that it works and that the output is properly formatted PASS PASS github.com/docker/docker/integration-cli 178.685s Tip You can use the $TESTFLAGS environment variable to pass in arguments to the test run. Use Docker inside our development environment You can also launch an interactive session inside the newly built development container: $ sudo make shell To exit the container, type exit or Ctrl-D. Submitting a pull request If you're happy with your documentation update, bug fix, or new feature, you can submit a pull request for it on GitHub. To do so, you should fork the Docker repository and make changes on your fork in a feature branch: If it is a bug fix branch, name it XXXX-something, where XXXX is the number of the issue. If it is a feature branch, create a feature issue to announce your intentions, and name it XXXX-something, where XXXX is the number of the issue.

Dockerfiles and the build cache Using the build cache for templating Viewing our new image Launching a container from our new image Dockerfile instructions Pushing images to the Docker Hub Automated Builds Deleting an image Running your own Docker registry Running a registry from a container Testing the new registry Alternative Indexes Quay Summary Testing with Docker Using Docker to test a static website An initial Dockerfile for the Sample website Building our Sample website and Nginx image Building containers from our Sample website and Nginx image Editing our website Using Docker to build and test a web application Building our Sinatra application Creating our Sinatra container Extending our Sinatra application to use Redis Connecting our Sinatra application to the Redis container Docker internal networking Docker networking Connecting Docker containers via links Connecting containers summary Using Docker for continuous integration Build a Jenkins and Docker server Create a new Jenkins job Running our Jenkins job Next steps with our Jenkins job Summary of our Jenkins setup Multi-configuration Jenkins Create a multi-configuration job Testing our multi-configuration job Summary of our multi-configuration Jenkins Other alternatives Drone Shippable Summary Building services with Docker Building our first application The Jekyll base image Building the Jekyll base image The Apache image Building the Jekyll Apache image Launching our Jekyll site Updating our Jekyll site Backing up our Jekyll volume Extending our Jekyll website example Building a Java application server with Docker A WAR file fetcher Fetching a WAR file Our Tomcat 7 application server Running our WAR file Building on top of our Tomcat application server A multi-container application stack The Node.js image The Redis base image The Redis primary image The Redis replica image Creating our Redis back-end cluster Creating our Node container Capturing our application logs Summary of our Node stack Managing Docker containers without SSH Summary Docker Orchestration and Service Discovery Docker Compose Installing Docker Compose Getting our sample application The docker-compose.yml file Running Compose Using Compose Compose in summary Consul, Service Discovery and Docker Building a Consul image Testing a Consul container locally Running a Consul cluster in Docker Starting the Consul bootstrap node Starting the remaining nodes Running a distributed service with Consul in Docker Docker Swarm Installing Swarm Setting up a Swarm Creating some containers Filters Strategies Summary Orchestration alternatives and components Fleet and etcd Kubernetes Apache Mesos Helios Centurion Summary Using the Docker API The Docker APIs First steps with the Remote API Testing the Docker Remote API Managing images with the API Managing containers with the API Improving TProv Authenticating the Docker Remote API Create a Certificate Authority Create a server certificate signing request and key Configuring the Docker daemon Creating a client certificate and key Configuring our Docker client for authentication Summary Getting help and extending Docker Getting help The Docker user, dev mailing lists and forums Docker on IRC Docker on GitHub Reporting issues for Docker Setting up a build environment Install Docker Install source and build tools Check out the source Contributing to the documentation Build the environment Running the tests Use Docker inside our development environment Submitting a pull request Merge approval and maintainers Summary The Docker Book Who is this book for? The Docker Book is for developers, sysadmins, and DevOps-minded folks who want to implement Docker™ and container-based virtualization. There is an expectation that the reader has basic Linux/Unix skills and is familiar with the command line, editing files, installing packages, managing services, and basic networking.


Agile Project Management with Kanban (Developer Best Practices) by Eric Brechner

Amazon Web Services, cloud computing, continuous integration, crowdsourcing, data science, DevOps, don't repeat yourself, en.wikipedia.org, index card, Kaizen: continuous improvement, Kanban, loose coupling, minimum viable product, pull request, software as a service

Push your merged changes back into the upstream repo (or submit a pull request). A timing issue is involved, just like with centralized version control. Conflict mitigation fails if another repo pushes its changes while you are still validating yours. Fortunately, distributed version control allows the owners of the upstream repo to control the flow of changes. Owners can choose the order of the pull requests they take and can validate each one in separate branches within personal repositories or the upstream repo. Thus, the team submitting the pull request may want to track when its request is accepted and complete. You can track your pull requests by dividing the rightmost Done column of your signboard into sections for each repo.

The owners of the upstream repo accept pull requests from the downstream repos used by contributing individuals and teams, validate the changes, and accept none, some, or all of the changes, depending on the validation results. For large projects, multiple repos may be stored on the hosting service, with one or more related components in each repo. As with continuous integration, Kanban is a natural fit for continuous push because the tasks you complete daily are production-ready—they certainly pass the criteria that makes them prime for pushing to the upstream repo (or for submitting through a pull request). And as in continuous integration, large projects need to mitigate against merge and interface conflicts when new code is pushed to the upstream repo.

When a work item is completed, move its note card to the section associated with the repo where the work was done. The note card stays there until the pull request is accepted and complete. Add a special section for FastTrack items. These are work items that are needed immediately in the upstream repo. They get pulled individually into the upstream repo as soon as they are ready. FastTrack items are requested in advance by the owners of the upstream repo. Finally, include a large section where all the note cards go after they have successfully been pulled into the upstream repo. A little extra work is needed to track pull requests, but using simple sections on the right end of your signboard enables you to answer the question that all your partners and customers have: “When will our requests be available?”


pages: 1,025 words: 150,187

ZeroMQ by Pieter Hintjens

AGPL, anti-pattern, behavioural economics, carbon footprint, cloud computing, Debian, distributed revision control, domain-specific language, eat what you kill, Eben Moglen, exponential backoff, factory automation, fail fast, fault tolerance, fear of failure, finite state, Internet of things, iterative process, no silver bullet, power law, premature optimization, profit motive, pull request, revision control, RFC: Request For Comment, Richard Stallman, Skype, smart transportation, software patent, Steve Jobs, Valgrind, WebSocket

Committing the code, I pushed the patch to my forked repository (the “origin”): Git commit -a -m "Fixed issue #443" Git push origin master Switching to the GitHub web interface, I went to my libzmq fork and pressed the big “Pull Request” button at the top. GitHub asked me for a title, so I entered “Added ZMQ_XPUB_VERBOSE option.” I’m not sure why it asks this as I made a neat commit message, but hey, let’s go with the flow here. This made a nice little pull request with two commits: the one I’d made a month ago on the release notes, to prepare for the 3.2.1 release (a month passes so quickly when you spend most of it in airports), and my fix for issue #443 (37 new lines of code). GitHub lets you continue to make commits after you’ve kicked off a pull request. They get queued up and merged in one go.

If one puts the issue number in each commit, and if one uses the GitHub issue tracker—which we sadly don’t yet do for ØMQ—this release history is easier to produce mechanically. To work on an issue, a Contributor SHALL fork the project repository and then work on their forked repository. Here we explain the GitHub fork + pull request model so that newcomers only have to learn one process (C4) in order to contribute. To submit a patch, a Contributor SHALL create a Platform pull request back to the project. GitHub has made this so simple that we don’t need to learn Git commands to do it, for which I’m deeply grateful. Sometimes, I’ll tell people whom I don’t particularly like that command-line Git is awesome and all they need to do is learn Git’s internal model in detail before trying to use it on real work.

To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere. Randomly distributed discussions may be confusing if you’re walking up for the first time, but GitHub solves this for all current participants by sending emails to those who need to follow what’s going on. We had the same experience and the same solution in Wikidot, and it works. There’s no evidence that discussing in different places has any negative effect. To accept or reject a patch, a Maintainer SHALL use the Platform interface. Working via the GitHub web user interface means pull requests are logged as issues, with workflow and discussion.


pages: 139 words: 35,022

Roads and Bridges by Nadia Eghbal

AGPL, Airbnb, Amazon Web Services, barriers to entry, Benevolent Dictator For Life (BDFL), corporate social responsibility, crowdsourcing, cryptocurrency, data science, David Heinemeier Hansson, Debian, DevOps, en.wikipedia.org, Firefox, Free Software Foundation, GnuPG, Guido van Rossum, Ken Thompson, Khan Academy, Kickstarter, leftpad, Marc Andreessen, market design, Network effects, platform as a service, pull request, Richard Stallman, Ruby on Rails, Salesforce, side project, Silicon Valley, Skype, software is eating the world, the Cathedral and the Bazaar, Tragedy of the Commons, Y Combinator

Libraries.io, a website created by Andrew Nesbitt, is one effort to aggregate data open source projects and provide more data around their usage; it tracks over 1.3M open source libraries across 32 package managers. [194] Working with projects to modernize workflows Many projects struggle not just due to lack of funding, but because the projects are difficult to contribute to, or suffer a bottleneck from maintainers, who meticulously review and accept pull requests from the community. This is particularly true for older projects which may have been built using developer tools, languages, or workflows that are no longer popular (for example, using an older version control system instead of Git, whose popularity is growing among developers). There is plenty of work that can be done to make projects easier to contribute to, including migrating them to newer workflows, cleaning up code, closing unattended pull requests, and setting clear policies for contribution. Some projects have experimented with making it easier to contribute.

A developer would have to figure out who the maintainer was, find a way to contact them, and propose changes using whichever format that project maintainer preferred (for example, a mailing list or message board). GitHub standardized these methods of communication: maintainers are transparently listed on a project’s page, and discussion of proposed changes takes place on the GitHub platform. GitHub created vocabulary that is now standard among open source contributors, such as the “pull request” (where a developer submits changes to a project for review) and repurposing the term “fork” (historically, creating a copy of a project and modifying it into a new project). Prior to GitHub, forking a project meant there were irreconcilable differences over the direction a project should take.

Daniel Roy Greenfeld, a Python and Django developer, wrote: I personally get regular demands for unpaid work (Discussions about payment for work always stall) by healthy high profit companies large and small for [my projects]. If I don't respond in a timely fashion, if I'm not willing to accept a crappy pull request, I/we get labeled a jerk. There is nothing like having core Python/PyPA maintainers working for Redhat [sic] demanding unpaid work while criticizing what they consider your project's shortcomings to ruin your day and diminish your belief in open source.[105] (Red Hat is a multinational software company with annual revenue exceeding $2B which sells open source software solutions to enterprise customers. [106] Because of the nature of their business, Red Hat employees use and contribute to many open source projects; in some ways, Red Hat has become the business poster child of open source.


pages: 120 words: 19,624

git internal by Scott Chacon

Debian, en.wikipedia.org, loose coupling, pull request, Ruby on Rails

A person or core team has commit rights to it, but many other developers have public forks of that repository. When they have changes, they issue a pull request to an integration manager, who adds them as a remote if they haven’t already – then merges, tests, accepts and pushes. blessed repository developer public developer public developer public integration manager developer private developer private developer private Fig. M Private and public repositories driven by read-only pull requests This is largely how community-based git repositories like GitHub were built to work and how many smaller open source projects operate.

This will also really change patch submission for large projects. Instead of emailing patches around, you can fork the project, add your patch and submit a pull request for your branch with the fix to one of the core members or through the ticketing system. A member of the core team can add you as a remote easily, create a new testing branch, merge in or rebase your branch, test and accept or reject. If your patch is ignored or the team doesn’t have time to deal with it yet, it’s easy to keep up to date by continually rebasing and re-sending the pull requests until it’s either rejected or accepted. It doesn’t just go stale until it’s difficult to apply the patch anymore.

The other cool feature we could use is the distributed nature of Git. We could add other people on the project as remote repositories and push to and fetch from them, merging changes to write a book or documentation collaboratively. We could branch to try out a re-write and then either merge it in or throw it away if we don’t like it. We could send a pull request to our colleagues for them to try out the branch to preview it before we decide whether to merge it in or not. It’s possible the entire wiki project could even live in a bare branch (that is, a branch with no common ancestors with any existing branch) in the same repository as our project, so clones can get the 51 documentation as well, without it muddying up our code tree.


pages: 628 words: 107,927

Node.js in Action by Mike Cantelon, Marc Harter, Tj Holowaychuk, Nathan Rajlich

Amazon Web Services, business logic, Chris Wanstrath, create, read, update, delete, Debian, en.wikipedia.org, Firefox, Google Chrome, machine readable, MITM: man-in-the-middle, MVC pattern, node package manager, p-value, pull request, Ruby on Rails, SQL injection, web application, WebSocket

The following commands will do this for the node-elf repository: mkdir -p ~/tmp/forktest cd ~/tmp/forktest git clone git@github.com:chickentown/node-elf.git cd node-elf echo "exports.version = '0.0.2';" >> index.js git add index.js git commit -m "Added specification of module version." git push origin master Once you’ve pushed your changes, click Pull Request on your fork’s repository page, and enter the subject and body of a message describing your changes. Click Send Pull Request. Figure 14.7 shows a screenshot containing typical content. Figure 14.7. The details of a GitHub pull request The pull request is then added to the issue queue of the original repository. The owner of the original repository can then, after reviewing your changes, incorporate them by clicking Merge Pull Request, entering a commit message, and clicking Confirm Merge. This automatically closes the issue.

The process of collaborating on GitHub via forking Forking starts the collaboration process by duplicating the repository on GitHub to your own account (known as forking) (A). You then clone the forked repository to your workstation (B), make changes to it, commit the changes (C), push your work back to GitHub (D), and send a pull request to the owner of the original repository asking them to consider your changes (E). If they want to include your changes in their repository, they’ll approve your pull request. Let’s say you want to fork the node-elf repository you created earlier in this chapter and add code that exports the module’s version. This would allow anyone using the module to ensure that they’re using the right version.

The original author may not approve your contribution, but even then you still have your own fixed version, which you can continue to maintain and enhance independently. If your fork were to grow in popularity, others might well fork your fork, and offer contributions of their own. Once you’ve made changes to a fork, you can submit these changes to the original author with a pull request, which is a message asking a repository author to pull changes. Pulling, in Git parlance, means importing work from a fork and combining the work with your own. Figure 14.5 illustrates a GitHub collaboration scenario. Figure 14.5. A typical GitHub development scenario Now, let’s walk through an example of forking a GitHub repository for the purpose of collaboration.


pages: 302 words: 73,946

People Powered: How Communities Can Supercharge Your Business, Brand, and Teams by Jono Bacon

Airbnb, barriers to entry, behavioural economics, Black Lives Matter, blockchain, bounce rate, Cass Sunstein, Charles Lindbergh, content marketing, Debian, Firefox, gamification, if you build it, they will come, IKEA effect, imposter syndrome, Internet Archive, Jono Bacon, Kickstarter, Kubernetes, lateral thinking, Mark Shuttleworth, Minecraft, minimum viable product, more computing power than Apollo, planetary scale, pull request, Richard Stallman, Richard Thaler, Salesforce, Scaled Composites, sexual politics, Silicon Valley, SpaceShipOne, TED Talk, the long tail, Travis Kalanick, Virgin Galactic, Y Combinator

Without delving too deep into nerd land, engineering communities typically collaborate around code when a community member submits a pull request to a project. This is a chunk of code that can be applied to an existing set of code in different places. It is like a Band-Aid that adds additional functionality. In open-source communities such as Kubernetes, Drupal, and jQuery, pull requests are typically submitted publicly. Then other developers go in and review that pull request and provide feedback, also out in the open. They may request it to be modified or improved, or they may say that it looks great! When the pull request is considered approved, one or more developers will mark it as approved and then it will be merged into the main codebase.

When the pull request is considered approved, one or more developers will mark it as approved and then it will be merged into the main codebase. This is powerful for a number of reasons. First, anyone and everyone is welcome to submit a pull request. This provides a great opportunity for new developers, students, teenagers, and others to cut their teeth getting involved in a community. Second, this feedback is an essential part of the learning process for community members and always improves the overall quality of the code. Third, because this happens out in the open, everyone can benefit from seeing the feedback, even if they are simply an observer, thus building a history of how the project was built.

_OS, 264 positivity, 185 postponed (status), 147 pragmatism, 184 prioritization of audience personas, 112–13 of community leadership staff requirements, 257 of community within organization, 262–63 of goals for incentives, 214 prizes, incentive, xvii–xviii problem solving, in Community On-Ramp Model, 134, 136, 137 Procter & Gamble, 9, 10 product development, 25–27 product enhancement, 86 productive participation, success as, 162–67 Product Success Model, 50–52 product team, community leadership staff reporting to, 261 promotion of in-person events, 239 of job openings, 258 promotions, 193 publication, of reputation scores, 229 public communities, 13, 179–80 pull requests, 204 Pulp Fiction (film), 127 Quarterly Community Strategy, 162, 167–70 Quarterly Delivery Plan, 145–51, 182, 189, 192 in Bacon Method, 34 and Big Rocks, 89, 90 in cadence-based cycles, 168–70 components of, 146–47 for departmental alignment, 263 examples of, 147–48 and Organizational Capabilities Maturity Model, 176 principles of building, 149–51 Quarterly Reviews, 268 questions answering community members’, 134 asking, 51, 85, 134, 273 quiet community members, engaging, 122 Random House, 10 React Native, 134 realistic objectives, 89–90, 95–96, 149–50 real-time chat channel, 250 recordings, of digital training sessions, 244 recruitment, 86, 258–59 Reddit, 24, 228 Reddit Science community, 45 Reddit Sneakers community, 45 Red Hat, 25–26, 56, 261 referral halo, 60–61, 188 referrals, hiring through, 258 Regular members, 129, 140–43 advancement of, 196–97 at community summits, 242 engagement with, 199–201 incentivizing, 214, 215, 219, 221–22, 227 maturity model for, 165, 166 mentoring for, 203, 205 relatedness, in SCARF model, 106–7 relationship building at conferences, 242 in Engagement Strategy, 199 relationships with community, 72 value generation in, 79 representativeness, 217 reputation score, 48, 228–29 respect, for Core members, 144 responsiveness, 198 retention, 157 reviewing community strategy, 268 Organizational Capabilities Maturity Model, 175 Quarterly Delivery Plan, 150 rewards for audience persona, 115, 117, 118 in Community Participation Framework, 145 for Core members, 201 in Growth Strategy, 196 in incentives, 212, 214–16 on Incentives Map, 230, 232 risks with community building, 154–55 with community strategy, 29–32 Rock, David, 104 role models, 186 round-table discussions, 246 Saint-Exupéry, Antoine de, 137 Salesforce, 9, 21–22 Salesforce Success Community, 21–22 Salesforce Trailblazer Community, 21–22 sales leads, community members as, 120–21 sales team, interactions of community and, 29, 87, 120–21 Samsung, 128 SAP, 10 SAP Community Network, 10 satisfaction, 215 scaling up, 202–6 SCARF model of behavior, 104–8, 121, 141 SCORECast, 239 Scott, Bon, 62 Seasoned Advice community, 63–64 SecondLife, 26, 27 self-direction, 139 self-respect, 17 sessions attending conference, 241 community summit, 248–49 Setup Tools stage, 132, 136, 137 shared interests, 45–47 shared projects, in communities, 52–54 Shinoda, Mike, 183–84 Shuttleworth, Mark, 1 Sierra Club, 18 siloing, 171–72, 186 simplicity, of on-ramp steps, 137 skills development, 233 in Community On-Ramp Model, 133, 136, 137 organizational, 162, 171–76 as source of value, 82 training for, 206, 243–45 skills gap, 192 small events, co-organizing, 239 Smallwood, Rod, 39 social capital, 19 social media, 193, 276 societies, behavior in, 211–12 Software Development Kit (SDK), 65 Solve Problems stage, 132–33, 136, 137 Space X, 40 speaking, at conferences, 238–39, 241 specialization, 45–47 specific goals, 160 Spirit of St.


pages: 282 words: 79,176

Pro Git by Scott Chacon

Chris Wanstrath, continuous integration, creative destruction, Debian, distributed revision control, GnuPG, pull request, revision control, systems thinking

If the maintainers merge, rebase, or cherry-pick your work, you’ll eventually get it back via pulling from their repository anyhow: $ git push myfork featureA When your work has been pushed up to your fork, you need to notify the maintainer. This is often called a pull request, and you can either generate it via the website — GitHub has a “pull request” button that automatically messages the maintainer — or run the git request-pull command and e-mail the output to the project maintainer manually. The request-pull command takes the base branch into which you want your topic branch pulled and the Git repository URL you want them to pull from, and outputs a summary of all the changes you’re asking to be pulled in. For instance, if Jessica wants to send John a pull request, and she’s done two commits on the topic branch she just pushed up, she can run this: $ git request-pull origin/master myfork The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40: John Smith (1): added a new function are available in the git repository at: git://githost/simplegit.git featureA Jessica Smith (2): add limit to log function change log output to 30 from 25 lib/simplegit.rb | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) The output can be sent to the maintainer—it tells them where the work was branched from, summarizes the commits, and tells where to pull this work from.

You can tell gitolite: repo foo RW = @junior_devs @senior_devs RW NAME/ = @senior_devs - NAME/Makefile = @junior_devs RW NAME/ = @junior_devs This powerful feature is documented in conf/example.conf. Personal Branches Gitolite also has a feature called “personal branches” (or rather, “personal branch namespace”) that can be very useful in a corporate environment. A lot of code exchange in the git world happens by “please pull” requests. In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there. This would normally cause the same branch name clutter as in a centralised VCS, plus setting up permissions for this becomes a chore for the admin.


pages: 629 words: 83,362

Programming TypeScript by Boris Cherny

billion-dollar mistake, bitcoin, business logic, database schema, don't repeat yourself, duck typing, Firefox, functional programming, Internet of things, pull request, source of truth, SQL injection, type inference, web application

Always use an ORM when working with databases—it’s more convenient, and it will save you from getting woken up at four in the morning because the saleAmount field is null because you updated it to orderAmount the night before and your coworker decided to run your database migration for you in anticipation of your pull request landing while you were out, but then around midnight your pull request failed even though the migration succeeded, and your sales team in New York woke up to realize that all your clients’ orders were for exactly null dollars (this happened to… a friend). Summary In this chapter we’ve covered a lot: directly manipulating the DOM; using React and Angular; adding type safety to your APIs with tools like Swagger, gRPC, and GraphQL; and using TypeORM to safely interact with your database.

They come in a lot of flavors, each with libraries available in a bunch of languages (including TypeScript)—for example: Swagger for RESTful APIs Apollo and Relay for GraphQL gRPC and Apache Thrift for RPC These tools rely on a common source of truth for both server and clients—data models for Swagger, GraphQL schemas for Apollo, Protocol Buffers for gRPC—which are then compiled into language-specific bindings for whatever language you might be using (in our case, that’s TypeScript). This code generation is what prevents your client and server (or multiple clients) from getting out of sync with each other; since every platform shares a common schema, you won’t run into the case where you updated your iOS app to support a field, but forgot to press Merge on your pull request to add server support for it. Diving into the details of each framework is out of scope for this book. Pick one for your project, and head over to its documentation to learn more. Backend Frameworks When you build an application that interacts with a database, you might start with raw SQL or API calls, which are inherently untyped: // PostgreSQL, using node-postgres let client = new Client let res = await client.query( 'SELECT name FROM users where id = $1', [739311] ) // any // MongoDB, using node-mongodb-native db.collection('users') .find({id: 739311}) .toArray((err, user) => // user is any ) With a bit of manual typing you can make these APIs safer and get rid of most of your anys: db.collection('users') .find({id: 739311}) .toArray((err, user: User) => // user is any ) However, raw SQL APIs are still fairly low-level, and it’s still easy to use the wrong type, or forget a type and accidentally end up with anys.

Create a type declaration and contribute it back to NPM. If you got as far as the third option and now have a local type declaration for your module, consider contributing it back to NPM so the next person that needs type declarations for the awesome nearby-ferret-alerter package can use it too. To do this you can either submit a pull request to the nearby-ferret-alerter Git repository and contribute the type declarations directly, or, if the maintainers of that repository don’t want to be on the hook for maintaining TypeScript type declarations, contribute your declarations to DefinitelyTyped instead. Writing type declarations for third-party JavaScript is straightforward, but how it’s done depends on the type of module you’re typing.


pages: 94 words: 22,435

Bandit Algorithms for Website Optimization by John Myles White

profit maximization, pull request

If Python isn’t your style, you should be able to translate our Python code into your favorite programming language fairly easily. Assuming you are happy using Python or Julia, you can find the code for the book on GitHub at https://github.com/johnmyleswhite/BanditsBook. If you find mistakes or would like to submit an implementation in another language, please make a pull request. Dealing with Jargon: A Glossary While this book isn’t meant to introduce you to the theoretical study of the Multiarmed Bandit Problem or to prepare you to develop novel algorithms for solving the problem, we want you to leave this book with enough understanding of existing work to be able to follow the literature on the Multiarmed Bandit Problem.

Their comments were invaluable and I’m deeply appreciative for all of the little errors that they kept from creeping into the final release of this book. Finally, I’d like to thank the various people who’ve contributed to the codebase on bandit algorithms that complements this book. Receiving pull requests contributing supplemental code for a book that wasn’t even released has been among my favorite experiences ever as an author. Chapter 1. Two Characters: Exploration and Exploitation To set the stage for this book, I’m going to tell you a short story about a web developer, Deborah Knull, who ran a small web business that provided most of her income.


Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton, Manuel Pais

anti-pattern, business logic, business process, call centre, cognitive load, continuous integration, Conway's law, database schema, DevOps, different worldview, Dunbar number, holacracy, information security, Infrastructure as a Service, Internet of things, Jeff Bezos, Kanban, Kickstarter, knowledge worker, Kubernetes, Lean Startup, loose coupling, meta-analysis, microservices, Norbert Wiener, operational security, platform as a service, pull request, remote working, systems thinking, two-pizza team, web application

Every part of the software system needs to be owned by exactly one team. This means there should be no shared ownership of components, libraries, or code. Teams may use shared services at runtime, but every running service, application, or subsystem is owned by only one team. Outside teams may submit pull requests or suggestions for change to the owning team, but they cannot make changes themselves. The owning team may even trust another team so much that they grant them access to the code for a period of time, but only the original team retains ownership. Note that team ownership of code should not be a territorial thing.

., using semantic versioning [SemVer] as a “team promise” not to break things) Wiki and documentation: especially how-to guides for the software owned by the team Practices and principles: the team’s preferred ways of working Communication: the team’s approach to remote communication tools, such as chat tools and video conferencing Work information: what the team is working on now, what’s coming next, and overall priorities in the short to medium term Other: anything else that other teams need to use to interact with the team The team API should explicitly consider usability by other teams: Will other teams find it easy and straightforward to interact with us, or will it be difficult and confusing? How easy will it be for a new team to get on board with our code and working practices? How do we respond to pull requests and other suggestions from other teams? Is our team backlog and product roadmap easily visible and understandable by other teams? For effective team-first ownership of software, teams need to continuously define, advertise, test, and evolve their team API to ensure that it is fit for purpose for the consumers of that API: other teams.

In Dynamic Reteaming (by Heidi Helfand), Evan Wiley, Director of Program Management at Pivotal Cloud Foundry (PCF), a major enterprise Platform-as-a-Service (PaaS) provider, describes how more than fifty teams are seen at PCF: We really try to maintain as much contract based, API-based separation of concerns between teams [emphasis added] as we can. We try not to share code bases between teams. All the git repos for a particular team’s feature are wholly owned by that team and if another team is going to make an addition or change to that code base, they’ll either do it with a pull request or through cross-team pairing, where we would kind of send one half of a pair over to the dependency holding team and one half of that team’s pair back to the upstream team to work on that feature.28 An even more stringent team API approach is taken at cloud vendor AWS, where CEO Jeff Bezos insisted on almost paranoid levels of separation between teams.


pages: 355 words: 81,788

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith by Sam Newman

Airbnb, business logic, business process, continuous integration, Conway's law, database schema, DevOps, fail fast, fault tolerance, ghettoisation, inventory management, Jeff Bezos, Kubernetes, loose coupling, microservices, MVC pattern, price anchoring, pull request, single page application, single source of truth, software as a service, source of truth, sunk-cost fallacy, systems thinking, telepresence, two-pizza team, work culture

Before we talk about the sorts of problems that crop up, let’s first take a look at the concepts Martin outlines, and put them in the context of microservice architecture: Strong code ownership All services have owners. If someone outside that ownership group wants to make a change, they have to submit that change to the owners, who decide whether it is allowed. The use of a pull request for people outside the ownership group is one example of how this could be handled. Weak code ownership Most, if not all, services are owned by someone, but anyone can still directly change their modules without resorting to the need for things like pull requests. Effectively, source control is set up to still allow anyone to change anything, but there is the expectation that if you change someone else’s service, you’ll speak to them first.

But that functionality is currently managed by a different team, in a different part of the organization. So now we have to coordinate with them to make the required changes to support our features. This may mean we have to ask them to do the work for us, or perhaps we have to make the changes ourselves and submit a pull request (assuming our company works like that). Either way, we have to coordinate with another part of the organization to make the change. We could spend the time to coordinate with other people and get the changes made, all so we could roll out our change. But we work out that we could actually just write our own implementation much faster and ship the feature to the customer more quickly than if we spend the time to adapt the existing code.


pages: 540 words: 103,101

Building Microservices by Sam Newman

airport security, Amazon Web Services, anti-pattern, business logic, business process, call centre, continuous integration, Conway's law, create, read, update, delete, defense in depth, don't repeat yourself, Edward Snowden, fail fast, fallacies of distributed computing, fault tolerance, index card, information retrieval, Infrastructure as a Service, inventory management, job automation, Kubernetes, load shedding, loose coupling, microservices, MITM: man-in-the-middle, platform as a service, premature optimization, pull request, recommendation engine, Salesforce, SimCity, social graph, software as a service, source of truth, sunk-cost fallacy, systems thinking, the built environment, the long tail, two-pizza team, web application, WebSocket

If you want a change to an open source project, you either ask one of the committers to make the change for you, or else you make the change yourself and send them a pull request. The core committers are still in charge of the codebase; they are the owners. Inside the organization, this pattern can work well too. Perhaps the people who worked on the service originally are no longer on a team together; perhaps they are now scattered across the organization. Well, if they still have commit rights, you can find them and ask for their help, perhaps pairing up with them, or if you have the right tooling you can send them a pull request. Role of the Custodians We still want our services to be sensible.

If a service is pretty mature, and is rarely changed — for example, our cart service — then perhaps that is the time to open it up for other contributions. Tooling To best support an internal open source model, you’ll need some tooling in place. The use of a distributed version control tool with the ability for people to submit pull requests (or something similar) is important. Depending on the size of the organization, you may also need tooling to allow for a discussion and evolution of patch requests; this may or may not mean a full-blown code review system, but the ability to comment inline on patches is very useful. Finally, you’ll need to make it very easy for a committer to build and deploy your software, and make it available for others.


pages: 232 words: 71,237

Kill It With Fire: Manage Aging Computer Systems by Marianne Bellotti

anti-pattern, barriers to entry, business logic, cloud computing, cognitive bias, computer age, continuous integration, create, read, update, delete, Daniel Kahneman / Amos Tversky, data science, database schema, Dennis Ritchie, DevOps, fault tolerance, fear of failure, Google Chrome, Hans Moravec, iterative process, Ken Thompson, loose coupling, microservices, minimum viable product, Multics, no silver bullet, off-by-one error, platform as a service, pull request, QWERTY keyboard, Richard Stallman, risk tolerance, Schrödinger's Cat, side project, software as a service, Steven Levy, systems thinking, web application, Y Combinator, Y2K

It spread like wildfire across a wide variety of different institutions, including universities, museums, governmental organizations, and at least one all-girls private school in the early days. Users began putting their modified versions of Unix on magnetic tape and making copies to distribute among each other. These essentially were forks and pull requests long before the infrastructure for such things existed. The principal motivation for sharing was to distribute bug fixes and patches. Meanwhile, AT&T’s lawyers were trying to figure out what to do with Unix, and they were waffling between their original determination and a more traditional restrictive approach to intellectual property.

See cellphones momentum, 75–90, 117, 122, 130 monoliths, 50–51, 56, 85–87, 101–108, 148 Moravec, Hans, 63 morse code, 20 Mozilla, 204 MTTR (mean time to recovery), 113, 220 Multics, 21 murder boards, 125–127 MVP (minimum viable product), 32, 39, 76, 79 Mythical Man-Month, The, 140, 213 N NASA, 198 NASA’s Ames Research Center, 125 National Science Foundation Network, 10 Netflix, 204 networks, 13 nationalization, 11 nines of availability, 113 normal accidents, 46 O Obama administration, the, 79 objectives and key results (OKRs), 182 object-oriented, 70 object relational mapping (ORM), 105 observability, 52 on-call rotations, 109, 208 Operation Aurora, 119 opportunity costs, 90–94 optimizing, 83, 105 ORM (object relational mapping), 105 overgrowth, 64 P performance, 42–44, 52, 92, 113, 144 Perrow, Charles, 46 personal computer (PC), 10 Pew Research, 5 physical view, 173 Pinterest, 204 platform as a service (PaaS), 69 POSIX, 27 postmortem, 100, 167–168, 187–190 probabilistic outcome-based decision-making, 138 problem setting, 129–130, 159 processing power, 13 process view, 173 programming languages, 36 ALGOL60, 28–31 Assembly, 29, 40, 66 bash, 65 BASIC, 30 BCPL, 28 C, 28, 31 COBOL, 28–31, 39–41, 61, 70 CoffeeScript, 70 CPL, 31 CSS, 150 FORTRAN, 30 HTML, 150 Java, 30, 68, 70 JavaScript, 36, 67, 70, 150 JCL, 65 Lisps, 31 Python, 30, 69 SQL, 65, 105 Typescript, 70 protocols, 67 FTP, 67 HTTP, 209 NTP, 197 SMTP, 67 TCP/IP, 67 TLS/SSL, 206 pull requests, 23 Q Qantas Airways, 204 QWERTY, 27 R railroad tickets, 18 Reddit, 204 refactoring, 51–52, 71, 103 reorgs, 141, 151–152, 156 research institutions, 11 resilience, 112, 169 resilience engineering, 172 responsibility gaps, 99, 207 resulting, 60 retrospectives, 188 reverse engineering, 71 rewrites, 34, 54–55, 145–147 risk, 34, 88, 146, 162–171 Ritchie, Dennis, 23 Robert’s Rules of Order, 193 Rumelt, Richard, 184 S SaaS (software as a service), 95 Salus, Peter, 23 sandbox, 174–175 scaling, 62–63, 78, 110, 149, 195 Schrödinger’s cat, 124 SDK (software development kits), 67 second system syndrome, 33 security, 89 Selectric, 27 Service Dominate Logic (S-D Logic), 8 service level agreements (SLAs), 94 service level objectives (SLOs), 94, 106, 113, 144, 149, 169, 220 service-oriented architecture (SOA), 101, 148 service recovery paradox, 170 shell scripts, 65 Sholes, Christopher Latham, 19 site reliability engineering (SRE), 99, 113, 150, 157, 218 Slack, 102 SLAs (service level agreements), 94 SLOs (service level objectives), 94, 106, 113, 144, 149, 169, 220 SOA (service-oriented architecture), 101, 148 software as a service (SaaS), 95 software development kits (SDK), 67 software renovation, 71 Soule, Samuel W., 19 source code, 23 split in place, 56 Spolsky, Joel, 33, 145 SRE (site reliability engineering), 218 Stack Overflow, 33 Stallman, Richard, 25–26 standards, 11, 66, 77, 103, 107 static analysis, 69, 71–72 stocks, 210 storage capacity, 13 stored procedures, 65 Stricker, Gabriel, 119 success criteria, 83, 182–185 supercomputers, 10 Surprising Power of Liberating Structures, 135 system stability, 89, 169 T tabulating machines, 18–20 technical debt, 38–40, 55, 79, 106, 210–215 telegraphs, 19–21 testing, 51, 55, 57, 70, 85, 109, 124 Texas Instruments, 198 Thompson, Ken, 23 TOPS-10, 197 Torvalds, Linus, 25 trade-offs, 42, 83 transpilers, 69–71 true but irrelevant, 82 trust, 54, 100, 108, 123, 168–170, 219 Twitter, 62, 204 typewriters, 19 U United Nations (UN), 181 United Parcel Service (UPS), 203 University of Cambridge, 31 University of North Carolina at Chapel Hill, 140 Unix, 21–27, 197 UNIX-HATERS Handbook, The, 26 US Army/Marine Corps Counterinsurgency Field Manual, The, 129 US Digital Service (USDS), 68, 144, 164–165 V virtual machines (VM), 49–50, 85–87, 111, 176 W Working Effectively with Legacy Code, 55 working groups, 191–193 World Computer Corporation, 197 Y Y2K, 196, 200 yak shaving, 153 YouTube, 102 Z Zajonc, Robert, 22, 34


pages: 227 words: 63,186

An Elegant Puzzle: Systems of Engineering Management by Will Larson

Ben Horowitz, Cass Sunstein, Clayton Christensen, data science, DevOps, en.wikipedia.org, fault tolerance, functional programming, Google Earth, hive mind, Innovator's Dilemma, iterative process, Kanban, Kickstarter, Kubernetes, loose coupling, microservices, MITM: man-in-the-middle, no silver bullet, pull request, Richard Thaler, seminal paper, Sheryl Sandberg, Silicon Valley, statistical model, systems thinking, the long tail, web application

These dimensions kind of intuitively make sense as measures of productivity, but let’s see if we can model them into a system that we can use to reason about developer productivity: Pull requests are converted into ready commits based on our code review rate. Ready commits convert into deployed commits at deploy rate. Deployed commits convert into incidents at defect rate. Incidents are remediated into reverted commits at recovery rate. Reverted commits are debugged into new pull requests at debug rate. Linking these pieces together, we see a feedback loop, in which the system’s downstream behavior impacts its upstream behavior.


pages: 198 words: 20,852

Bootstrap by Jake Spurlock

commoditize, Kickstarter, pull request

The authors, Jacob Thornton and Mark Otto, have been meticulous in providing examples of the codebase, HTML code samples, and more to kickstart your project. It is top notch, and I’ve used it to gather the structure for this book. If you want to contribute to the work of the open source project, you can submit pull requests or use the issue tracker on the GitHub project for updates, downloads, documentation, and more. Are You Sure You Want Bootstrap? If you are looking for JavaScript plugins, or a CSS reset, Bootstrap may be overkill. If you aren’t in love with some of the default interface elements, they can be overwritten easily or you can just strip out the associated tags.


The Manager’s Path by Camille Fournier

Big Tech, emotional labour, failed state, fear of failure, hiring and firing, hive mind, interchangeable parts, job automation, Kanban, Larry Wall, microservices, pull request, risk tolerance, Schrödinger's Cat, side project, Steve Jobs, WebSocket, work culture

First, get someone to walk you through the systems and architecture, as well as the process for testing and releasing the software. If there is a normal developer onboarding process where you learn how to check 96 | THE MANAGER’S PATH out code and deploy the systems, go through that process. Spend some time getting comfortable in the code bases, and start watching the code reviews or pull requests, if they exist. Plan to work on at least a couple of features in your first 60 days. Take a specced-out feature and add it. Pair with one of the engineers on a feature he’s working on, and have him pair with you as you start working on a feature of your own. Get your code reviewed by a member of the team.

Given your level of technical responsibility, how should you invest your time in order to stay technically relevant? • Read the code. Occasionally taking the time to read some of the code in your systems can help remind you what it looks like. Sometimes, it also shows you places where things have gotten ugly and need attention. Looking over code reviews and pull requests can give you insight into changes that are happening. • Pick an unknown area, and ask an engineer to explain it to you. Spend a couple of hours with one of the engineers who is working on something you don’t understand, and ask him to teach you about that area. Go to a whiteboard or share a screen and have him pair with you on a small change. 156 | THE MANAGER’S PATH • Attend postmortems.


pages: 125 words: 28,222

Growth Hacking Techniques, Disruptive Technology - How 40 Companies Made It BIG – Online Growth Hacker Marketing Strategy by Robert Peters

Airbnb, bounce rate, business climate, citizen journalism, content marketing, crowdsourcing, digital map, fake it until you make it, Google Glasses, growth hacking, Hacker News, Jeff Bezos, Lean Startup, Menlo Park, Network effects, new economy, pull request, revision control, ride hailing / ride sharing, search engine result page, sharing economy, Skype, social bookmarking, TaskRabbit, turn-by-turn navigation, Twitter Arab Spring, ubercab

Prior to GitHub, developers who wanted to contribute code to an open source project were forced to download the source code, create their changes locally, and compile a list of those changes called a patch. This would then be emailed to the project’s maintainer for approval or rejection. On GitHub, developers can “fork” or copy any code repository that has been made public and modify it within their own account. They then share the changes with the repository’s owner with a “pull request.” If the owner likes the changes, they’re merged into the original repository. All of the friction that was once standard to software collaboration is removed with a solution that is manageable, seamless, and completely scalable. GitHub customers can have free access, but if they subscribe to a private account, they have more freedom to leverage GitHub’s resources within their development teams.


pages: 132 words: 28,815

Ansible Configuration Management - Second Edition by Daniel Hall

cloud computing, Debian, pull request, web application

When writing plugins to Ansible, you should focus on making them flexible and reusable where possible. This way you end up removing some complexity from your playbooks and templates into a few complex Python files. Focusing on re-usability of your plugins also means it is possible to submit them back to the Ansible project using a GitHub pull request. If you submit your plugins back to Ansible, then everybody will be able to take advantage of your plugin, and you would have played a part in the development of Ansible itself. More information on contributing to Ansible can be found in the CONTRIBUTORS.md file in the Ansible source code. Connection plugins Connection plugins are responsible for relaying files to and from the remote machine, and executing modules.


pages: 419 words: 102,488

Chaos Engineering: System Resiliency in Practice by Casey Rosenthal, Nora Jones

Amazon Web Services, Asilomar, autonomous vehicles, barriers to entry, blockchain, business continuity plan, business intelligence, business logic, business process, cloud computing, cognitive load, complexity theory, continuous integration, cyber-physical system, database schema, DevOps, fail fast, fault tolerance, hindsight bias, human-factors engineering, information security, Kanban, Kubernetes, leftpad, linear programming, loose coupling, microservices, MITM: man-in-the-middle, no silver bullet, node package manager, operational security, OSI model, pull request, ransomware, risk tolerance, scientific management, Silicon Valley, six sigma, Skype, software as a service, statistical model, systems thinking, the scientific method, value engineering, WebSocket

The CI pipeline runs a thorough set of unit and integration tests before baking an image for the virtual machine. Automated canaries test any new code change on a small amount of traffic before proceeding to a blue/green deployment model that runs a good chunk of the cluster in parallel before completely cutting over to a new version. All pull requests to change the code to F undergo a two-reviewer policy and the reviewer can’t be someone working on the feature being changed, requiring the entire team to be well informed about all aspects of development in motion. Finally, the entire organization goes into a code freeze at the beginning of November until January.

Once the experiments are scheduled, the dedicated team members observe and analyze the system for anomalies and document their takeaways. If any tool support is needed, then the core tooling team is contacted. If there are any capabilities specific to their architecture that they need from tooling, they would develop that feature and create a pull request for the tooling team to merge. This way, the application teams are not stuck waiting for the tool to be updated, and at the same time, they can innovate and make their contributions available for enterprise use. This also prevents another major pitfall: tool duplication. In large enterprises, however well connected the teams are, due to the innovative nature of today’s software engineering skill sets, the same problem is bound to be solved by multiple teams simultaneously, resulting in tool proliferation, which incurs further cost and management issues.


Real-World Kanban by Mattias Skarin

call centre, continuous integration, Great Leap Forward, Kanban, loose coupling, pull request

At this meeting, the team also solved problems and clarified who was responsible for following up on blocking issues. Finally, the team reviewed the Prioritized queue (which was kept to the left of the Kanban board) so that the team had an idea of what was coming up and what was important. The management team prioritized and pulled requests from the ticket system and added them to the Prioritized queue. This helped the team keep track of work in progress even if there was an increase in the workload. Smaller requests coming directly to the team members were reviewed during the twiceweekly standups. It’s worth noting that when prioritizing, the teams reserved the right not to take on a task.


pages: 241 words: 43,252

Modern Vim: Craft Your Development Environment With Vim 8 and Neovim by Drew Neil

bash_history, Bram Moolenaar, data science, Debian, DevOps, en.wikipedia.org, functional programming, microservices, pull request, remote working, text mining

You’ll find advice on how to install this plugin on GitHub.[65] vim-lsp,[66] by Prabir Shrestha, is another promising LSP plugin. This one is designed to work in Vim 8 and Neovim. There’s also vim-lsc[67] by Nate Bosch. Finally, TJ DeVries is working on adding built-in LSP support to Neovim. You can view the work-in-progress pull request on GitHub.[68] As you can see, there’s lots of excitement around LSP in the Vim and (especially) Neovim communities. Having so many options is overwhelming at the moment, but with competition, some of these projects may thrive. What’s Next for Vim 8 Vim’s pace of development has really picked up since the Neovim fork was created.


pages: 161 words: 44,488

The Business Blockchain: Promise, Practice, and Application of the Next Internet Technology by William Mougayar

Airbnb, airport security, Albert Einstein, altcoin, Amazon Web Services, bitcoin, Black Swan, blockchain, business logic, business process, centralized clearinghouse, Clayton Christensen, cloud computing, cryptocurrency, decentralized internet, disintermediation, distributed ledger, Edward Snowden, en.wikipedia.org, Ethereum, ethereum blockchain, fault tolerance, fiat currency, fixed income, Ford Model T, global value chain, Innovator's Dilemma, Internet of things, Kevin Kelly, Kickstarter, market clearing, Network effects, new economy, peer-to-peer, peer-to-peer lending, prediction markets, pull request, QR code, ride hailing / ride sharing, Satoshi Nakamoto, sharing economy, smart contracts, social web, software as a service, too big to fail, Turing complete, Vitalik Buterin, web application, Yochai Benkler

At the completion of a successful campaign, your earnings are automatically deposited into that account. When you link your ApplePay account to checkout and pay for items in seconds, the money is actually coming directly from one of your bank or credit card accounts. When you take an Uber ride, Uber makes a pull request to charge your credit card, automatically. A Venmo account that lets you receive money instantly from a friend, also lets you push that balance back to your bank account (or vice-versa). These examples are few but significant. The point and reality of all these situations is that we, as consumers, are doing more interesting things with these new ancillary services than we can directly from our bank accounts.


Learning Puppet 4: A Guide to Configuration Management and Automation by Jo Rhett

Amazon Web Services, Debian, DevOps, Golden Gate Park, pull request

If this process has changed since this book was published, the revised process should be documented at Publishing Modules on the Puppet Forge. 206 | Chapter 16: Publishing Modules www.it-ebooks.info Publishing a Module on GitHub It is common and expected for you to have a place to accept bug reports and pull requests for your module. GitHub is by far the most common location to do this. The following steps will create a GitHub repository for your module. If you haven’t installed git already, you should do that now. [vagrant@client ~]$ sudo yum install -y git ...snip... Installed: git.x86_64 0:1.8.3.1-4.el7 Dependency Installed: libgnome-keyring.x86_64 0:3.8.0-3.el7 perl-Error.noarch 1:0.17020-2.el7 Complete!


Designing Web APIs: Building APIs That Developers Love by Brenda Jin, Saurabh Sahni, Amir Shevat

active measures, Amazon Web Services, augmented reality, Big Tech, blockchain, business logic, business process, cognitive load, continuous integration, create, read, update, delete, exponential backoff, Google Hangouts, if you build it, they will come, Lyft, machine readable, MITM: man-in-the-middle, premature optimization, pull request, Salesforce, Silicon Valley, Snapchat, software as a service, the market place, uber lyft, web application, WebSocket

If you’re building a consumer product, you need to think hard about how you’re communicating the capabilities of your plat‐ form to your end users. WebHooks Security As discussed in Chapter 2, a WebHook is simply a URL where API providers send a POST request when something happens. For instance, Stripe sends notifications about new payments to Web‐ Hook URLs. Similarly, whenever you open a Pull Request in Git‐ Hub, GitHub sends a POST request to the developer’s configured WebHook URL(s). Securing WebHooks is slightly different from securing web APIs. Because the WebHook URLs are generally publicly accessible on the internet, it’s important for the developers to be able to ensure the POST request actually came from the stated sender.


pages: 144 words: 55,142

Interlibrary Loan Practices Handbook by Cherie L. Weible, Karen L. Janke

Firefox, information retrieval, Internet Archive, late fees, machine readable, Multics, optical character recognition, pull request, QR code, transaction costs, Wayback Machine, Works Progress Administration

This type of shared responsibility can also happen within the same physical location, but with different departments participating in the process. In some libraries, circulation desk workers may engage in scanning or searching for management of interlibrary loan interlibrary services, or shelving staff may be responsible for pulling requests for interlibrary loan. In some libraries, people who do interlibrary services may hold joint positions in other units like circulation, reference, or cataloging. Because much of the interlibrary loan workflow is location-independent, it’s not surprising to see someone working on ILL requests at another service desk.


pages: 292 words: 66,588

Learning Vue.js 2: Learn How to Build Amazing and Complex Reactive Web Applications Easily With Vue.js by Olga Filipova

Amazon Web Services, business logic, continuous integration, create, read, update, delete, en.wikipedia.org, Firefox, Google Chrome, leftpad, MVC pattern, pull request, side project, single page application, single source of truth, Skype, source of truth, web application

Now go to the index.html file and replace our curly brackets delimiters with double percentage, as follows: <div id="app"> <h1>%% message %%</h1> </div> Rebuild our application and refresh the browser! What about now? You see how easy it is to change the framework's code and to try out your changes. I'm sure you have plenty of ideas about how to improve or add some functionality to Vue.js. So change it, rebuild, test, deploy! Happy pull requests! Debugging your Vue application You can debug your Vue application the same way you debug any other web application. Use your developer tools (firebug), breakpoints, debugger statements, and so on. If you want to dive deep inside the Chrome debugging tools, check Chrome's documentation at https://developer.chrome.com/devtools .


pages: 821 words: 178,631

The Rust Programming Language by Steve Klabnik, Carol Nichols

anti-pattern, billion-dollar mistake, bioinformatics, business logic, business process, cryptocurrency, data science, DevOps, duck typing, Firefox, functional programming, Internet of things, iterative process, pull request, reproducible builds, Ruby on Rails, type inference

Nicholas Matsakis and Aaron Turon ACKNOWLEDGMENTS We would like to thank everyone who has worked on the Rust language for creating an amazing language worth writing a book about. We’re grateful to everyone in the Rust community for being welcoming and creating an environment worth welcoming more folks into. We’re especially thankful for everyone who read early versions of this book online and provided feedback, bug reports, and pull requests. Special thanks to Eduard-Mihai Burtescu and Alex Crichton for providing technical review and Karen Rustad Tölva for the cover art. Thank you to our team at No Starch, including Bill Pollock, Liz Chadwick, and Janelle Ludowise, for improving this book and bringing it to print. Steve would like to thank Carol for being an amazing co-author.

Make sure you read the surrounding text to see whether the example you’re trying to run is meant to error. In most situations, we’ll lead you to the correct version of any code that doesn’t compile. Resources and How to Contribute to This Book This book is open source. If you find an error, please don’t hesitate to file an issue or send a pull request on GitHub at https://github.com/rust-lang/book/. Please see CONTRIBUTING.md at https://github.com/rust-lang/book/blob/master/CONTRIBUTING.md for more details. The source code for the examples in this book, errata, and other information are available at https://www.nostarch.com/Rust/. 1 GETTING STARTED Let’s start your Rust journey!


pages: 420 words: 79,867

Developing Backbone.js Applications by Addy Osmani

Airbnb, anti-pattern, business logic, create, read, update, delete, don't repeat yourself, Firefox, full text search, Google Chrome, Khan Academy, Kickstarter, loose coupling, MVC pattern, node package manager, pull request, Ruby on Rails, side project, single page application, web application

Setting Expectations The goal of this book is to create an authoritative and centralized repository of information that can help those developing real-world apps with Backbone. If you come across a section or topic which you think could be improved or expanded on, please feel free to submit an issue (or better yet, a pull-request) on the book’s GitHub site. It won’t take long and you’ll be helping other developers avoid the problems you ran into. Topics will include MVC theory and how to build applications using Backbone’s Models, Views, Collections, and Routers. I’ll also be taking you through advanced topics like modular development with Backbone.js and AMD (via RequireJS), solutions to common problems like nested views, how to solve routing problems with Backbone and jQuery Mobile, and much more.


pages: 237 words: 74,109

Uncanny Valley: A Memoir by Anna Wiener

autonomous vehicles, back-to-the-land, basic income, behavioural economics, Blitzscaling, blockchain, blood diamond, Burning Man, call centre, charter city, cloud computing, cognitive bias, cognitive dissonance, commoditize, crowdsourcing, cryptocurrency, dark triade / dark tetrad, data science, digital divide, digital nomad, digital rights, end-to-end encryption, Extropian, functional programming, future of work, gentrification, Golden Gate Park, growth hacking, guns versus butter model, housing crisis, Jane Jacobs, job automation, knowledge worker, Lean Startup, means of production, medical residency, microaggression, microapartment, microdosing, new economy, New Urbanism, Overton Window, passive income, Plato's cave, pull request, rent control, ride hailing / ride sharing, San Francisco homelessness, Sand Hill Road, self-driving car, sharing economy, Shenzhen special economic zone , side project, Silicon Valley, Silicon Valley startup, Social Justice Warrior, social web, South of Market, San Francisco, special economic zone, subprime mortgage crisis, systems thinking, tech bro, tech worker, technoutopianism, telepresence, telepresence robot, union organizing, universal basic income, unpaid internship, urban planning, urban renewal, warehouse robotics, women in the workforce, work culture , Y2K, young professional

In the absence of vibrant cultural institutions, the pleasure center of the industry might have just been exercise: people courted the sublime on trail runs and day hikes, glamped in Marin and rented chalets in Tahoe. They dressed for work as if embarking on an alpine expedition: high-performance down jackets and foul-weather shells, backpacks with decorative carabiners. They looked ready to gather kindling and build a lean-to, not make sales calls and open pull-requests from climate-controlled open-plan offices. They looked in costume to LARP their weekend selves. The culture these inhabitants sought and fostered was lifestyle. They engaged with their new home by rating it. Crowdsourced reviewing apps provided opportunities to assign anything a grade: dim sum, playgrounds, hiking trails.


pages: 328 words: 77,877

API Marketplace Engineering: Design, Build, and Run a Platform for External Developers by Rennay Dorasamy

Airbnb, Amazon Web Services, barriers to entry, business logic, business process, butterfly effect, continuous integration, DevOps, digital divide, disintermediation, fault tolerance, if you build it, they will come, information security, Infrastructure as a Service, Internet of things, Jeff Bezos, Kanban, Kubernetes, Lyft, market fragmentation, microservices, minimum viable product, MITM: man-in-the-middle, mobile money, optical character recognition, platform as a service, pull request, ride hailing / ride sharing, speech recognition, the payments system, transaction costs, two-pizza team, Uber and Lyft, uber lyft, underbanked, web application

The process evolved, almost overnight, as the on-premises Container platform was rebuilt. As part of the rebuild, the deployment process also changed dramatically. Suddenly, pipelines were triggered on code commits which automatically built and deployed to the next test environment. Once functionality was confirmed in lower test environments, the developer would initiate a pull request which had to be reviewed and approved before the code change could be merged into the main branch. This action would also trigger a higher-function process which would deploy the component to a staging environment. The deployment process would not set it as the active version. An Instant Message (IM) had to be sent to a middle-earth wizard, Gandalf, a chatbot, who would then magically update configuration in the Kubernetes cluster to route requests to the new version.


pages: 761 words: 80,914

Ansible: Up and Running: Automating Configuration Management and Deployment the Easy Way by Lorin Hochstein

Amazon Web Services, cloud computing, continuous integration, Debian, DevOps, domain-specific language, don't repeat yourself, general-purpose programming language, Infrastructure as a Service, job automation, machine readable, MITM: man-in-the-middle, pull request, side project, smart transportation, web application

It does not support Boot2Docker, a commonly used tool for running Docker on OS X. It does not support the wait parameter that I use in some examples in this section. There are proposed fixes for all of these issues awaiting review in the Ansible project. Hopefully by the time you read this, these issues all will have been fixed. There is also a pending pull request to support detach=no, which has the same behavior as wait=yes in the examples here. In the meantime, I have included a custom version of the docker module in the code sample repository that has fixes for these issues. The file is ch13/playbooks/library/docker.py. Example 13-10 shows the entire playbook that orchestrates the Docker containers in our Mezzanine deployment.


pages: 278 words: 83,468

The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses by Eric Ries

3D printing, barriers to entry, Benchmark Capital, call centre, Clayton Christensen, clean tech, clean water, cloud computing, commoditize, Computer Numeric Control, continuous integration, corporate governance, disruptive innovation, experimental subject, Ford Model T, Frederick Winslow Taylor, hockey-stick growth, Kanban, Lean Startup, Marc Andreessen, Mark Zuckerberg, Metcalfe’s law, minimum viable product, Mitch Kapor, Network effects, payday loans, Peter Thiel, pets.com, Ponzi scheme, pull request, reality distortion field, risk tolerance, scientific management, selection bias, Silicon Valley, Silicon Valley startup, six sigma, skunkworks, social bookmarking, stealth mode startup, Steve Jobs, the scientific method, Toyota Production System, transaction costs

This assumes that customers could tell us what products to build and that this would act as the pull signal to product development to make them.9 As was mentioned earlier, this is not the way the Lean Startup model works, because customers often don’t know what they want. Our goal in building products is to be able to run experiments that will help us learn how to build a sustainable business. Thus, the right way to think about the product development process in a Lean Startup is that it is responding to pull requests in the form of experiments that need to be run. As soon as we formulate a hypothesis that we want to test, the product development team should be engineered to design and run this experiment as quickly as possible, using the smallest batch size that will get the job done. Remember that although we write the feedback loop as Build-Measure-Learn because the activities happen in that order, our planning really works in the reverse order: we figure out what we need to learn and then work backwards to see what product will work as an experiment to get that learning.


Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services by Robert Daigneau

Amazon Web Services, business intelligence, business logic, business process, continuous integration, create, read, update, delete, en.wikipedia.org, fault tolerance, loose coupling, machine readable, MITM: man-in-the-middle, MVC pattern, OSI model, pull request, RFC: Request For Comment, Ruby on Rails, software as a service, web application

., an Atom Syndication feed) that queries the data persisted by the first web service. 65 Request/ Acknowledge 66 C HAPTER 3 C LIENT -S ERVICE I NTERACTIONS Example: A Service That Implements Request/Acknowledge The following listing shows how a Java service can use JMS to forward requests. These are picked up by asynchronous background processes designed to pull requests from a queue and process them. Request/ Acknowledge @WebService(name="BargainAirService") public class BargainAirService { @WebMethod() public TripReservationAck ReserveTrip( @WebParam(name = "request") TripReservation request)) { String requestId = System.currentTimeMillis().toString() + java.util.UUID.randomUUI().toString(); request.setIdentifier(requestId); FlightReservationsGateway.SendMessage( request ); TripReservationAck response = new TripReservationAck(); response.setRequestId(requestId); return response; } } public class FlightReservationsGateway { public static void SendMessage(TripReservation request){ Context context = new InitialContext(); ConnectionFactory factory = (ConnectionFactory)context.lookup("queueConnFactory"); Queue queue = (Queue) context.lookup("flightReservations"); Connection conn = factory.createConnection(); Session session = conn.createSession(true, Session.AUTO_ACKNOWLEDGE); MessageProducer sender = session.createProducer(queue); TextMessage msg = session.createTextMessage( request.toString() ); sender.send( msg); } } R EQUEST /A CKNOWLEDGE 67 Example: A Resource API That Implements Request/Acknowledge/Poll This example shows how a Resource API (38) implemented in Java could support polling.


pages: 334 words: 104,382

Brotopia: Breaking Up the Boys' Club of Silicon Valley by Emily Chang

"Margaret Hamilton" Apollo, "Susan Fowler" uber, "World Economic Forum" Davos, 23andMe, 4chan, Ada Lovelace, affirmative action, Airbnb, Alan Greenspan, Andy Rubin, Apollo 11, Apple II, augmented reality, autism spectrum disorder, autonomous vehicles, barriers to entry, Benchmark Capital, Bernie Sanders, Big Tech, Burning Man, California gold rush, Chuck Templeton: OpenTable:, clean tech, company town, data science, David Brooks, deal flow, Donald Trump, Dr. Strangelove, driverless car, Elon Musk, emotional labour, equal pay for equal work, fail fast, Fairchild Semiconductor, fake news, Ferguson, Missouri, game design, gender pay gap, Google Glasses, Google X / Alphabet X, Grace Hopper, Hacker News, high net worth, Hyperloop, imposter syndrome, Jeff Bezos, job satisfaction, Khan Academy, Lyft, Marc Andreessen, Mark Zuckerberg, Mary Meeker, Maui Hawaii, Max Levchin, Menlo Park, meritocracy, meta-analysis, microservices, Parker Conrad, paypal mafia, Peter Thiel, post-work, pull request, reality distortion field, Richard Hendricks, ride hailing / ride sharing, rolodex, Salesforce, Saturday Night Live, shareholder value, Sheryl Sandberg, side project, Silicon Valley, Silicon Valley startup, Skype, Snapchat, Steve Jobs, Steve Jurvetson, Steve Wozniak, Steven Levy, subscription business, Susan Wojcicki, tech billionaire, tech bro, tech worker, TED Talk, Tim Cook: Apple, Travis Kalanick, uber lyft, women in the workforce, Zenefits

According to the stories: Ibid. Lydia Fernandez has seen the tech industry: Fernandez, interview by Helena Price, www.techiesproject.com, Feb. 11, 2016, http://www.techiesproject.com/lydia-fernandez. software community GitHub: Josh Terrell et al., “Gender Differences and Bias in Open Source: Pull Request Acceptance of Women Versus Men,” Peer J, July 26, 2016, https://doi.org/10.7717/peerj-cs.111. One former engineer at Facebook: Deepa Seetharaman, “Facebook’s Female Engineers Claim Gender Bias,” Wall Street Journal, May 2, 2017, https://www.wsj.com/articles/facebooks-female-engineers-claim-gender-bias-1493737116.


pages: 514 words: 111,012

The Art of Monitoring by James Turnbull

Amazon Web Services, anti-pattern, business logic, cloud computing, continuous integration, correlation does not imply causation, Debian, DevOps, domain-specific language, failed state, functional programming, Kickstarter, Kubernetes, microservices, performance metric, pull request, Ruby on Rails, single source of truth, software as a service, source of truth, web application, WebSocket

The collectd Docker plugin does this by creating a formatted dictionary of comma-separated key/value pairs. def _d(d): """Formats a dictionary of key/value pairs as a comma-delimited list of key=value tokens.""" return ','.join(['='.join(p) for p in d.items()]) Note I've added this capability in a fork of the Docker collectd plugin. It's in a pull request on the upstream plugin. These events are then sent to Riemann. We'll need to update our Docker event processing to extract this data. To do this, we're going to create new functions in the top of our existing: /etc/riemann/examplecom/etc/collect.clj file. Let's start with two functions to extract any labels from the :plugin_instance field and convert them into a map.


pages: 523 words: 112,185

Doing Data Science: Straight Talk From the Frontline by Cathy O'Neil, Rachel Schutt

Amazon Mechanical Turk, augmented reality, Augustin-Louis Cauchy, barriers to entry, Bayesian statistics, bike sharing, bioinformatics, computer vision, confounding variable, correlation does not imply causation, crowdsourcing, data science, distributed generation, Dunning–Kruger effect, Edward Snowden, Emanuel Derman, fault tolerance, Filter Bubble, finite state, Firefox, game design, Google Glasses, index card, information retrieval, iterative process, John Harrison: Longitude, Khan Academy, Kickstarter, machine translation, Mars Rover, Nate Silver, natural language processing, Netflix Prize, p-value, pattern recognition, performance metric, personalized medicine, pull request, recommendation engine, rent-seeking, selection bias, Silicon Valley, speech recognition, statistical model, stochastic process, tacit knowledge, text mining, the scientific method, The Wisdom of Crowds, Watson beat the top human players on Jeopardy!, X Prize

The driver and observer roles should switch periodically throughout the day. If done right, you’ll feel exhausted after several hours. Practice to improve pairing endurance. And when you don’t get to pair program, develop the habit to check in code using git. Learn about git workflows, and give each other constructive critiques on pull requests. Think of it as peer review in academia. Productionizing machine learning models Here are some of the toughest problems in doing real-world machine learning: How is a model “productionized”? How are features computed in real time to support these models? How do we make sure that “what we see is what we get”?


pages: 960 words: 125,049

Mastering Ethereum: Building Smart Contracts and DApps by Andreas M. Antonopoulos, Gavin Wood Ph. D.

air gap, Amazon Web Services, bitcoin, blockchain, business logic, continuous integration, cryptocurrency, Debian, digital divide, Dogecoin, domain-specific language, don't repeat yourself, Edward Snowden, en.wikipedia.org, Ethereum, ethereum blockchain, fault tolerance, fiat currency, Firefox, functional programming, Google Chrome, information security, initial coin offering, intangible asset, Internet of things, litecoin, machine readable, move fast and break things, node package manager, non-fungible token, peer-to-peer, Ponzi scheme, prediction markets, pull request, QR code, Ruby on Rails, Satoshi Nakamoto, sealed-bid auction, sharing economy, side project, smart contracts, transaction costs, Turing complete, Turing machine, Vickrey auction, Vitalik Buterin, web application, WebSocket

Finally, a huge dollop of thanks must go to Aeron Buchanan, without whom the last five years of my life could never possibly have unfolded in the way they did and without whose time, support, and guidance this book would not be in as good shape as it is. Contributions Many contributors offered comments, corrections, and additions to the early-release draft on GitHub. Contributions on GitHub were facilitated by two GitHub editors who volunteered to project manage, review, edit, merge, and approve pull requests and issues: Lead GitHub editor: Francisco Javier Rojas Garcia (fjrojasgarcia) Assisting GitHub editor: William Binns (wbnns) Major contributions were provided on the topics of DApps, ENS, the EVM, fork history, gas, oracles, smart contract security, and Vyper. Additional contributions, which were not included in this first edition due to time and space constraints, can be found in the contrib folder of the GitHub repository.


pages: 779 words: 116,439

Test-Driven Development With Python by Harry J. W. Percival

business logic, continuous integration, database schema, Debian, DevOps, don't repeat yourself, duck typing, Firefox, loose coupling, MVC pattern, off-by-one error, platform as a service, pull request, web application, WebSocket

Come on, Django, it’s only got one field, you should be able to figure out the answers to these questions for yourself. Here you go: class User(models.Model): email = models.EmailField() REQUIRED_FIELDS = () accounts/models.py. Next silly question?4 AttributeError: type object 'User' has no attribute 'USERNAME_FIELD' So: 4. You might ask, if I think Django is so silly, why don’t I submit a pull request to fix it? Should be quite a simple fix. Well, I promise I will, as soon as I’ve finished writing the book. For now, snarky comments will have to suffice. 294 | Chapter 16: Server-Side Authentication and Mocking in Python www.it-ebooks.info accounts/models.py. class User(models.Model): email = models.EmailField() REQUIRED_FIELDS = () USERNAME_FIELD = 'email' The next error is a database error: django.db.utils.OperationalError: no such table: accounts_user That prompts us, as usual, to do a migration: $ python3 manage.py makemigrations System check identified some issues: WARNINGS: accounts.User: (auth.W004) 'User.email' is named as the 'USERNAME_FIELD', but it is not unique.


pages: 580 words: 125,129

Androids: The Team That Built the Android Operating System by Chet Haase

Andy Rubin, Apple II, Apple's 1984 Super Bowl advert, augmented reality, barriers to entry, Beos Apple "Steve Jobs" next macos , Big Tech, Bill Atkinson, commoditize, continuous integration, crowdsourcing, en.wikipedia.org, fault tolerance, Firefox, General Magic , Google Chrome, Ken Thompson, lock screen, machine readable, Menlo Park, PalmPilot, Parkinson's law, pull request, QWERTY keyboard, side project, Silicon Valley, skunkworks, speech recognition, stealth mode startup, Steve Ballmer, Steve Jobs, Steve Wozniak, Tony Fadell, turn-by-turn navigation, web application

Peer developers far prefer the former, because one-liners are easy to review and approve. Woe be unto the developer that leans on their team to review a 10,000 line CL when everyone is under the gun already to deliver their own fixes and features. Changelist is apparently a term used primarily by Google engineering. Other software systems use terms like patch or PR (pull request) to mean the same thing. Emulator An emulator is a software program that mimics a hardware device. Developers use emulators (in particular, they use the Android emulator) to make it easier to run and test their programs on the host computer they are using to write their applications. Instead of requiring a physical device to test an app (and perhaps to suffer delays downloading the program to the device every time it is recompiled), they can simply run a virtual device on their powerful desktop computer instead.


pages: 424 words: 123,180

Democracy's Data: The Hidden Stories in the U.S. Census and How to Read Them by Dan Bouk

Black Lives Matter, card file, COVID-19, dark matter, data science, desegregation, digital map, Donald Trump, George Floyd, germ theory of disease, government statistician, hiring and firing, illegal immigration, index card, invisible hand, Jeff Bezos, linked data, Mahatma Gandhi, mass incarceration, public intellectual, pull request, Ralph Waldo Emerson, Scientific racism, Shoshana Zuboff, Silicon Valley, social distancing, surveillance capitalism, transcontinental railway, union organizing, W. E. B. Du Bois, Works Progress Administration, zero-sum game

While looking for Foudray, however, I discovered the census. The staff of the National Archives made that discovery possible, and I offer them my deepest thanks: first, the archivists who taught me how to navigate the paper finding aids in the binder and folder for Record Group 29, who corrected my flawed “pull requests” (which are used to order materials), and who organized and oversaw the efficient and elegant reading room. My thanks are also owed to the security staff who daily checked my credentials with good cheer and patiently reminded me in which direction to swipe my admission card. Every day that I entered the National Archives, I passed two stone sentries: Robert I.


Data Wrangling With Python: Tips and Tools to Make Your Life Easier by Jacqueline Kazil

Amazon Web Services, bash_history, business logic, cloud computing, correlation coefficient, crowdsourcing, data acquisition, data science, database schema, Debian, en.wikipedia.org, Fairphone, Firefox, Global Witness, Google Chrome, Hacker News, job automation, machine readable, Nate Silver, natural language processing, pull request, Ronald Reagan, Ruby on Rails, selection bias, social web, statistical model, web application, WikiLeaks

Get used to fetching remote changes with git fetch or using the git pull --rebase command to update your local repository with new commits. Then, work on your code, commit your work, and push your commits to your active branch. When it’s time to merge your branch with the master, you can send a pull request, have oth‐ ers review the merge, and then merge it directly into master branch. Don’t forget to delete stale or old branches when they are no longer useful. It’s also essential you set up a .gitignore file, where you list all of the file patterns you want Git to ignore when you push/pull changes, as discussed in the sidebar “Git and .gitignore” on page 211.


pages: 1,331 words: 163,200

Hands-On Machine Learning With Scikit-Learn and TensorFlow: Concepts, Tools, and Techniques to Build Intelligent Systems by Aurélien Géron

AlphaGo, Amazon Mechanical Turk, Anton Chekhov, backpropagation, combinatorial explosion, computer vision, constrained optimization, correlation coefficient, crowdsourcing, data science, deep learning, DeepMind, don't repeat yourself, duck typing, Elon Musk, en.wikipedia.org, friendly AI, Geoffrey Hinton, ImageNet competition, information retrieval, iterative process, John von Neumann, Kickstarter, machine translation, natural language processing, Netflix Prize, NP-complete, OpenAI, optical character recognition, P = NP, p-value, pattern recognition, pull request, recommendation engine, self-driving car, sentiment analysis, SpamAssassin, speech recognition, stochastic process

Müller, et al. (2013). 17 Some predictors also provide methods to measure the confidence of their predictions. 18 NumPy’s reshape() function allows one dimension to be –1, which means “unspecified”: the value is inferred from the length of the array and the remaining dimensions. 19 See SciPy’s documentation for more details. 20 But check out Pull Request #3886, which may introduce a ColumnTransformer class making attribute-specific transformations easy. You could also run pip3 install sklearn-pandas to get a DataFrameMapper class with a similar objective. Chapter 3. Classification In Chapter 1 we mentioned that the most common supervised learning tasks are regression (predicting values) and classification (predicting classes).


pages: 602 words: 177,874

Thank You for Being Late: An Optimist's Guide to Thriving in the Age of Accelerations by Thomas L. Friedman

3D printing, additive manufacturing, affirmative action, Airbnb, AltaVista, Amazon Web Services, Anthropocene, Apple Newton, autonomous vehicles, Ayatollah Khomeini, barriers to entry, Berlin Wall, Bernie Sanders, Big Tech, biodiversity loss, bitcoin, blockchain, Bob Noyce, business cycle, business process, call centre, carbon tax, centre right, Chris Wanstrath, Clayton Christensen, clean tech, clean water, cloud computing, cognitive load, corporate social responsibility, creative destruction, CRISPR, crowdsourcing, data science, David Brooks, deep learning, demand response, demographic dividend, demographic transition, Deng Xiaoping, digital divide, disinformation, Donald Trump, dual-use technology, end-to-end encryption, Erik Brynjolfsson, fail fast, failed state, Fairchild Semiconductor, Fall of the Berlin Wall, Ferguson, Missouri, first square of the chessboard / second half of the chessboard, Flash crash, fulfillment center, game design, gig economy, global pandemic, global supply chain, Great Leap Forward, illegal immigration, immigration reform, income inequality, indoor plumbing, intangible asset, Intergovernmental Panel on Climate Change (IPCC), Internet of things, invention of the steam engine, inventory management, Irwin Jacobs: Qualcomm, Jeff Bezos, job automation, John Markoff, John von Neumann, Khan Academy, Kickstarter, knowledge economy, knowledge worker, land tenure, linear programming, Live Aid, low interest rates, low skilled workers, Lyft, Marc Andreessen, Mark Zuckerberg, mass immigration, Maui Hawaii, Menlo Park, Mikhail Gorbachev, mutually assured destruction, Neil Armstrong, Nelson Mandela, ocean acidification, PalmPilot, pattern recognition, planetary scale, power law, pull request, Ralph Waldo Emerson, ransomware, Ray Kurzweil, Richard Florida, ride hailing / ride sharing, Robert Gordon, Ronald Reagan, Salesforce, Second Machine Age, self-driving car, shareholder value, sharing economy, Silicon Valley, Skype, smart cities, Solyndra, South China Sea, Steve Jobs, subscription business, supercomputer in your pocket, synthetic biology, systems thinking, TaskRabbit, tech worker, TED Talk, The Rise and Fall of American Growth, Thomas L Friedman, Tony Fadell, transaction costs, Transnistria, uber lyft, undersea cable, urban decay, urban planning, Watson beat the top human players on Jeopardy!, WikiLeaks, women in the workforce, Y2K, Yogi Berra, zero-sum game

In the old days, I would probably write up the changes I wanted to make and pitch them in the abstract to the community. Now I actually take your code into my sandbox. That is called a ‘fork.’ I work on it and now my changes are totally in the open—it’s my version. If I want to submit the changes back to you, the original author, I make a pull request. You look at the new way I have laid out ‘How to Write a Column’; you can see all the changes. And if you like it, you press the ‘merge’ button. And then the next viewer sees the aggregate version. If you don’t like all of it, we have a way to discuss, comment, and review each line of code. It is curated crowdsourcing.


pages: 1,380 words: 190,710

Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems by Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski, Adam Stubblefield

air gap, anti-pattern, barriers to entry, bash_history, behavioural economics, business continuity plan, business logic, business process, Cass Sunstein, cloud computing, cognitive load, continuous integration, correlation does not imply causation, create, read, update, delete, cryptocurrency, cyber-physical system, database schema, Debian, defense in depth, DevOps, Edward Snowden, end-to-end encryption, exponential backoff, fault tolerance, fear of failure, general-purpose programming language, Google Chrome, if you see hoof prints, think horses—not zebras, information security, Internet of things, Kubernetes, load shedding, margin call, microservices, MITM: man-in-the-middle, NSO Group, nudge theory, operational security, performance metric, pull request, ransomware, reproducible builds, revision control, Richard Thaler, risk tolerance, self-driving car, single source of truth, Skype, slashdot, software as a service, source of truth, SQL injection, Stuxnet, the long tail, Turing test, undersea cable, uranium enrichment, Valgrind, web application, Y2K, zero day

Then, by introducing Git hooks that analyze every commit, you can prevent new code from using the string-based overload. Alternatively, you can restrict the visibility of the unsafe API—for example, Bazel visibility whitelists would allow a user to call the API only if a security team member approves the pull request (PR). If your codebase is under active development, it will organically move toward the safe API. After you reach the point at which only a small fraction of callers use the deprecated string-based API, you can manually clean up the remainder. At that point, your code will be immune to SQL injection by design.


Seeking SRE: Conversations About Running Production Systems at Scale by David N. Blank-Edelman

Affordable Care Act / Obamacare, algorithmic trading, AlphaGo, Amazon Web Services, backpropagation, Black Lives Matter, Bletchley Park, bounce rate, business continuity plan, business logic, business process, cloud computing, cognitive bias, cognitive dissonance, cognitive load, commoditize, continuous integration, Conway's law, crowdsourcing, dark matter, data science, database schema, Debian, deep learning, DeepMind, defense in depth, DevOps, digital rights, domain-specific language, emotional labour, en.wikipedia.org, exponential backoff, fail fast, fallacies of distributed computing, fault tolerance, fear of failure, friendly fire, game design, Grace Hopper, imposter syndrome, information retrieval, Infrastructure as a Service, Internet of things, invisible hand, iterative process, Kaizen: continuous improvement, Kanban, Kubernetes, loose coupling, Lyft, machine readable, Marc Andreessen, Maslow's hierarchy, microaggression, microservices, minimum viable product, MVC pattern, performance metric, platform as a service, pull request, RAND corporation, remote working, Richard Feynman, risk tolerance, Ruby on Rails, Salesforce, scientific management, search engine result page, self-driving car, sentiment analysis, Silicon Valley, single page application, Snapchat, software as a service, software is eating the world, source of truth, systems thinking, the long tail, the scientific method, Toyota Production System, traumatic brain injury, value engineering, vertical integration, web application, WebSocket, zero day

(Source: https://en.wikipedia.org/wiki/Bus_factor.) 11 Thanks to Marianne Bellotti for the phrasing. 12 As a former employee of Harvard University, I want to call that institution out as doing this very well. Each job listing contains enough information to look up salary ranges, available insurance plans, union membership, tuition coverage, and any other benefits before you even apply. 13 Joblint is available online, or runnable locally from this GitHub page. The GitHub project also accepts pull requests if you want to add further rules. 14 This might even be illegal, depending on your state, as many are moving to ban the question outright. 15 Privacy engineering principles apply here, too, of course. 16 Unlimited vacation policies have seen rapid adoption because they avoid the accounting liability from accrued vacation days.