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, barriers to entry, Benevolent Dictator For Life (BDFL), bitcoin, Clayton Christensen, cloud computing, commoditize, continuous integration, crowdsourcing, cryptocurrency, David Heinemeier Hansson, death of newspapers, Debian, disruptive innovation, en.wikipedia.org, Ethereum, Firefox, Guido van Rossum, Hacker Ethic, Induced demand, informal economy, Jane Jacobs, Jean Tirole, Kevin Kelly, Kickstarter, Kubernetes, Mark Zuckerberg, Menlo Park, 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, The Death and Life of Great American Cities, The Nature of the Firm, 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, 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, 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, Debian, DevOps, don't repeat yourself, en.wikipedia.org, Firefox, Guido van Rossum, 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, corporate governance, Debian, Donald Knuth, en.wikipedia.org, experimental subject, Firefox, GnuPG, Hacker Ethic, Internet Archive, iterative process, Kickstarter, natural language processing, patent troll, peer-to-peer, pull request, revision control, Richard Stallman, selection bias, slashdot, software as a service, software patent, SpamAssassin, 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.

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

Amazon Web Services, cloud computing, continuous integration, crowdsourcing, DevOps, don't repeat yourself, en.wikipedia.org, index card, 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, carbon footprint, cloud computing, Debian, distributed revision control, domain-specific language, eat what you kill, factory automation, fault tolerance, fear of failure, finite state, Internet of things, iterative process, 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, David Heinemeier Hansson, Debian, DevOps, en.wikipedia.org, Firefox, GnuPG, Guido van Rossum, Khan Academy, Kickstarter, Marc Andreessen, market design, Network effects, platform as a service, pull request, Richard Stallman, Ruby on Rails, side project, Silicon Valley, Skype, software is eating the world, 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, Chris Wanstrath, create, read, update, delete, Debian, en.wikipedia.org, Firefox, Google Chrome, MITM: man-in-the-middle, MVC pattern, node package manager, p-value, pull request, Ruby on Rails, 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, blockchain, bounce rate, Cass Sunstein, Charles Lindbergh, Debian, Firefox, if you build it, they will come, IKEA effect, 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, sexual politics, Silicon Valley, Travis Kalanick, 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

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: 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.

pages: 355 words: 81,788

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

Airbnb, business process, continuous integration, database schema, DevOps, fault tolerance, ghettoisation, inventory management, Jeff Bezos, Kubernetes, loose coupling, microservices, MVC pattern, price anchoring, pull request, single page application, software as a service, source of truth, sunk-cost fallacy, telepresence

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 process, call centre, continuous integration, create, read, update, delete, defense in depth, don't repeat yourself, Edward Snowden, 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, social graph, software as a service, source of truth, sunk-cost fallacy, the built environment, 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, cloud computing, cognitive bias, computer age, continuous integration, create, read, update, delete, Daniel Kahneman / Amos Tversky, database schema, DevOps, fault tolerance, fear of failure, Google Chrome, iterative process, loose coupling, microservices, minimum viable product, platform as a service, pull request, QWERTY keyboard, Richard Stallman, risk tolerance, Schrödinger's Cat, side project, software as a service, Steven Levy, 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: 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

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

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, crowdsourcing, digital map, Google Glasses, 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, TaskRabbit, turn-by-turn navigation, 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 process, cloud computing, complexity theory, continuous integration, cyber-physical system, database schema, DevOps, fault tolerance, hindsight bias, Kubernetes, linear programming, loose coupling, microservices, MITM: man-in-the-middle, node package manager, pull request, ransomware, risk tolerance, Silicon Valley, six sigma, Skype, software as a service, statistical model, the scientific method, 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, 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: 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 process, centralized clearinghouse, Clayton Christensen, cloud computing, cryptocurrency, disintermediation, distributed ledger, Edward Snowden, en.wikipedia.org, Ethereum, ethereum blockchain, fault tolerance, fiat currency, fixed income, 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, 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: 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, blockchain, business process, continuous integration, create, read, update, delete, Google Hangouts, if you build it, they will come, Lyft, MITM: man-in-the-middle, premature optimization, pull request, 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, optical character recognition, pull request, QR code, transaction costs, 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, continuous integration, create, read, update, delete, en.wikipedia.org, Firefox, Google Chrome, MVC pattern, pull request, side project, single page application, 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, bioinformatics, business process, cryptocurrency, DevOps, Firefox, functional programming, Internet of things, iterative process, pull request, 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, 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, blockchain, Burning Man, call centre, charter city, cloud computing, cognitive bias, cognitive dissonance, commoditize, crowdsourcing, cryptocurrency, Extropian, functional programming, future of work, Golden Gate Park, housing crisis, Jane Jacobs, job automation, knowledge worker, Lean Startup, means of production, medical residency, microaggression, new economy, New Urbanism, passive income, pull request, rent control, ride hailing / ride sharing, San Francisco homelessness, Sand Hill Road, self-driving car, selling pickaxes during a gold rush, sharing economy, Shenzhen special economic zone , side project, Silicon Valley, Silicon Valley startup, social web, South of Market, San Francisco, special economic zone, technoutopianism, telepresence, telepresence robot, union organizing, universal basic income, unpaid internship, urban planning, urban renewal, women in the workforce, 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: 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, 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, call centre, Clayton Christensen, clean water, cloud computing, commoditize, Computer Numeric Control, continuous integration, corporate governance, disruptive innovation, experimental subject, Frederick Winslow Taylor, hockey-stick growth, 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, risk tolerance, selection bias, Silicon Valley, Silicon Valley startup, six sigma, skunkworks, 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 process, continuous integration, create, read, update, delete, en.wikipedia.org, fault tolerance, loose coupling, MITM: man-in-the-middle, MVC pattern, 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

23andMe, 4chan, Ada Lovelace, affirmative action, Airbnb, Apple II, augmented reality, autonomous vehicles, barriers to entry, Bernie Sanders, Burning Man, California gold rush, Chuck Templeton: OpenTable:, David Brooks, Donald Trump, Elon Musk, equal pay for equal work, Ferguson, Missouri, game design, gender pay gap, Google Glasses, Google X / Alphabet X, Grace Hopper, high net worth, Hyperloop, Jeff Bezos, job satisfaction, Khan Academy, Lyft, Marc Andreessen, Mark Zuckerberg, Maui Hawaii, Menlo Park, meta-analysis, microservices, paypal mafia, Peter Thiel, post-work, pull request, ride hailing / ride sharing, rolodex, Saturday Night Live, shareholder value, side project, Silicon Valley, Silicon Valley startup, Skype, Snapchat, Steve Jobs, Steve Wozniak, Steven Levy, subscription business, Tim Cook: Apple, Travis Kalanick, uber lyft, women in the workforce

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, 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, 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, bioinformatics, computer vision, correlation does not imply causation, crowdsourcing, distributed generation, 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, 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, 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.

Amazon Web Services, bitcoin, blockchain, continuous integration, cryptocurrency, Debian, 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, intangible asset, Internet of things, litecoin, move fast and break things, move fast and break things, node package manager, 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, 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

continuous integration, database schema, Debian, DevOps, don't repeat yourself, Firefox, loose coupling, MVC pattern, 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

Apple II, Apple's 1984 Super Bowl advert, augmented reality, barriers to entry, Bill Atkinson, commoditize, continuous integration, crowdsourcing, en.wikipedia.org, fault tolerance, Firefox, Google Chrome, Menlo Park, Parkinson's law, pull request, QWERTY keyboard, side project, Silicon Valley, skunkworks, speech recognition, stealth mode startup, Steve Ballmer, Steve Jobs, Steve Wozniak, 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.

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

Amazon Web Services, bash_history, cloud computing, correlation coefficient, crowdsourcing, data acquisition, database schema, Debian, en.wikipedia.org, Firefox, Google Chrome, job automation, 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

Amazon Mechanical Turk, Anton Chekhov, backpropagation, combinatorial explosion, computer vision, constrained optimization, correlation coefficient, crowdsourcing, don't repeat yourself, Elon Musk, en.wikipedia.org, friendly AI, ImageNet competition, information retrieval, iterative process, John von Neumann, Kickstarter, natural language processing, Netflix Prize, NP-complete, 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, autonomous vehicles, Ayatollah Khomeini, barriers to entry, Berlin Wall, Bernie Sanders, bitcoin, blockchain, Bob Noyce, business cycle, business process, call centre, centre right, Chris Wanstrath, Clayton Christensen, clean water, cloud computing, corporate social responsibility, creative destruction, crowdsourcing, David Brooks, demand response, demographic dividend, demographic transition, Deng Xiaoping, disinformation, Donald Trump, Erik Brynjolfsson, failed state, Fall of the Berlin Wall, Ferguson, Missouri, first square of the chessboard / second half of the chessboard, Flash crash, game design, gig economy, global pandemic, global supply chain, 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 skilled workers, Lyft, Marc Andreessen, Mark Zuckerberg, mass immigration, Maui Hawaii, Menlo Park, Mikhail Gorbachev, mutually assured destruction, Nelson Mandela, pattern recognition, planetary scale, pull request, Ralph Waldo Emerson, ransomware, Ray Kurzweil, Richard Florida, ride hailing / ride sharing, Robert Gordon, Ronald Reagan, Second Machine Age, self-driving car, shareholder value, sharing economy, Silicon Valley, Skype, smart cities, South China Sea, Steve Jobs, supercomputer in your pocket, TaskRabbit, The Rise and Fall of American Growth, Thomas L Friedman, 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

anti-pattern, barriers to entry, bash_history, business continuity plan, business process, Cass Sunstein, cloud computing, continuous integration, correlation does not imply causation, create, read, update, delete, cryptocurrency, cyber-physical system, database schema, Debian, defense in depth, DevOps, Edward Snowden, fault tolerance, fear of failure, general-purpose programming language, Google Chrome, Internet of things, Kubernetes, load shedding, margin call, microservices, MITM: man-in-the-middle, performance metric, pull request, ransomware, revision control, Richard Thaler, risk tolerance, self-driving car, Skype, slashdot, software as a service, source of truth, Stuxnet, 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, Amazon Web Services, backpropagation, bounce rate, business continuity plan, business process, cloud computing, cognitive bias, cognitive dissonance, commoditize, continuous integration, crowdsourcing, dark matter, database schema, Debian, defense in depth, DevOps, domain-specific language, en.wikipedia.org, fault tolerance, fear of failure, friendly fire, game design, Grace Hopper, information retrieval, Infrastructure as a Service, Internet of things, invisible hand, iterative process, Kubernetes, loose coupling, Lyft, Marc Andreessen, 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, 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, the scientific method, Toyota Production System, 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.