17 results back to index
Version Control With Git: Powerful Tools and Techniques for Collaborative Software Development by Jon Loeliger, Matthew McCullough
.), 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?
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).
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?
Html5 Boilerplate Web Development by Divya Manian
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. 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.
Commit your changes in logical chunks; use Git's interactive rebase feature (more about this feature at help.github.com/articles/interactive-rebase) to tidy up your commits before making them public. 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.
ZeroMQ by Pieter Hintjens
anti-pattern, carbon footprint, cloud computing, Debian, distributed revision control, domain-specific language, 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. That simplifies things, but the maintainer may refuse the whole bundle based on one patch that doesn’t look valid.
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.
No special privileges to the original authors, because otherwise we’re not building a community, only boosting our egos. 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. I’m sure there are more complex ways to work. Complexity is easy; it’s simplicity that’s incredibly hard.
git internal by Scott Chacon
integration manager model This is where each developer has a public repository, but one is considered the ‘official’ repository – it is used to create the pack- 103 ages and binaries. 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. In the end, there is really no single right way to do it – being a decentralized system, you can have a model with all of these aspects to it, or any combination you can think of.
You can then delete your fork and revert to the original project head. 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. Services like GitHub and an increased adoption of distributed SCM systems will dramatically change open source development workflows on teams of all sizes, in addition to changing the way individual developers work. 110 Commands Overview chapter 4 This section is meant to be a really quick reference to the commands we have reviewed in Git and a quick description of what they do, where we have talked about them and where to find out more information on them.
Searching is built in and we can edit the wiki offline. 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. See the git-wiki (http://github.com/al3x/git-wiki/tree/master) project for an example of this.
Bandit Algorithms for Website Optimization by John Myles White
We’ve chosen to use Python for this book because it seems like a reasonable lingua franca for programmers. 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. In order to do that, we have to introduce quite a large number of jargon words.
My thanks go to them, as well as to the three technical reviewers—Matt Gershoff at Conductrics, Roberto Medri at Esty, and Tim Hopper at RTI—all of whom read through this book and found countless ways to improve it. 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. Deb Knull’s story will introduce the core concepts that come up when studying bandit algorithms, which are called exploration and exploitation.
Pro Git by Scott Chacon
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. Gitolite lets you define a “personal” or “scratch” namespace prefix for each developer (for example, refs/personal/<devname>/*); see the “personal branches” section in doc/3-faq-tips-etc.mkd for details.
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, load shedding, loose coupling, platform as a service, premature optimization, pull request, recommendation engine, social graph, software as a service, source of truth, the built environment, web application, WebSocket, x509 certificate
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. We want the code to be of decent quality, and the service itself to exhibit some sort of consistency in how it is put together.
Following a similar model for your own organizations makes sense. 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.
Bootstrap by Jake Spurlock
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
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.
Ansible Configuration Management - Second Edition by Daniel Hall
Note Do not remove any of the existing directories, as you will be removing plugins that provide core Ansible features such as the ones we have mentioned earlier in this book. 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.
Interlibrary Loan Practices Handbook by Cherie L. Weible, Karen L. Janke
This presents a challenge for administrators who should update job descriptions to reflect the changes, develop work priorities, and contribute to staff evaluations. 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. Many reference desks have slow times, so working on other projects is an efficient use of staff time.
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 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
If you are running a crowdfunding campaign (such as on Kickstarter), you are also required to link your bank account. 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.
The results of standard tests and community feedback will be added to the page when they are available. 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:220.127.116.11-4.el7 Dependency Installed: libgnome-keyring.x86_64 0:3.8.0-3.el7 perl-Error.noarch 1:0.17020-2.el7 Complete!
Developing Backbone.js Applications by Addy Osmani
Airbnb, anti-pattern, create, read, update, delete, database schema, don't repeat yourself, Firefox, full text search, Google Chrome, Khan Academy, loose coupling, MVC pattern, node package manager, pull request, Ruby on Rails, side project, single page application, web application
I regularly use it and hope that you find it as useful an addition to your toolbelt as I have. 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.
3D printing, barriers to entry, call centre, Clayton Christensen, clean water, cloud computing, commoditize, Computer Numeric Control, continuous integration, corporate governance, experimental subject, Frederick Winslow Taylor, Lean Startup, Marc Andreessen, Mark Zuckerberg, Metcalfe’s law, minimum viable product, 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.
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, pull request, side project, smart transportation, web application
The volumes_from parameter does not work with recent versions of Docker. 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. The sensitive data is in a separate file, shown in Example 13-11.
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 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, 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 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, 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, Thomas L Friedman, transaction costs, Transnistria, urban decay, urban planning, Watson beat the top human players on Jeopardy!, WikiLeaks, women in the workforce, Y2K, Yogi Berra, zero-sum game
I would view that online and say: ‘Hey, I have few points I would like to add.’ 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. But ultimately you have an expert—the person who wrote the original program—‘How to Write a Column’—who gets to decide what to accept and what to reject.