Despite declaring his support for Black Lives Matter and stating GitHub would look at ways to support law enforcement reform, CEO Nat Friedman will not reconsider the company's contracts with Immigration and Customs Enforcement [ICE]. The news comes after a staff meeting wherein Friedman condemned police brutality, adding GitHub would look at ways to help back law enforcement reform. Asked by an employee if Friedman would thus reevaluate the company's contracts with ICE and other law enforcement agencies, Friedman said no. 

More:

• "Picking and choosing customers is not the approach that we take to these types of questions when it comes to influencing government policy," said Friedman. 
• Friedman added that he believes investing in policy changes is a better way to enact change.
• His response sparked outrage amongst many GitHub employees: "The company’s response is confidential, but mine isn’t: continued anger and disappointment,” GitHub senior application engineer Josh Nichols tweeted. @github's words and (hopeful, eventual) actions in support of #BlackLivesMatter are just performative. #NoTechForICE."
• Since September 2019, GitHub workers have been urging the company to cancel its contract with the ICE over the Trump administration immigration policies it enforces. 
• Over 160 software developers signed an open letter calling on GitHub to cancel its $200,000 contract with ICE, including the founder of Ruby on Rails and the Co-Chair of the W3C Technical Architecture Group. Some employees have even resigned in protest.

The Golang team announced the codebase for pkg.go.dev, a site developers use to find and evaluate Go packages and modules, is now open source. The repository resides here, and is also mirrored to GitHub.

More:

• The team says it will continue using the Go issue tracker to track feedback related to the site, however.
• Now that pkg.go.dev is open source, Golang will work on creating a more cohesive search and navigation experience, making it easier for users to find dependencies. The team will also be working on adding new features asked for by the community.
• Check out Pkg.go.dev's overall roadmap detailing its short-term and long-term goals here.

Coding Dojo and MIT Bootcamps are launching the Coding and Innovation Bootcamp, which teaches both entrepreneurial problem-solving skills and web and software development fundamentals. At the beginning of the 10-week program, students will learn core innovation principles in a three-week bootcamp led by an MIT instructor. Upon completion, students will learn HTML, CSS, and basic JavaScript, and the full Python programming stack during a six-week online Coding Dojo bootcamp.

More:

• The course aims to teach students "how to think like an entrepreneur," covering topics ranging from ideation to customer discovery so students can bring their ideas to life with the technical skills they will also learn. It starts on September 14, 2020.
• After it is safe to do so in light of Covid-19, both aim to launch an onsite version of the bootcamp where students will attend the MIT Bootcamp in Cambridge, MA, and Coding Dojo in Seattle, WA.
• Click here to enroll.

Universe is offering Black Lives Movement organizers free access to all of its Pro features, which include a free website, domain, donation support, and an email list. The company says it is doing so to help organizers "coordinate and connect with fellow protestors and activists effectively." 

More: 

• The small company launched a site where interested organizers can sign up. The site also features resources and a list of places to donate.
• For a list of ways developers can help with the BLM movement using their money, time, and skills, check out this list I curated.

Quick Hits:

• One company tested 1000 of the most popular Chrome extensions to see how they impact browser performance. Of the developer tools that most impacted performance...
• Yoast acquired the...

Over the past few weeks, many of our masterclasses have centered around a 38-page essay by Martin Fowler about how to dramatically reduce the time teams spend merging dozens of branches together through workflow patterns. In today's issue, we condensed that article (and the masterclasses) by 70% into a roughly 5-10 minute, ten-page outline of the full piece, so you can get all the highlights without spending an hour or so reading and taking notes on Fowler's article.

Introduction:

• First, to make it easier for multiple people to work on a codebase at the same time, each developer in the team should create a copy of it. In order to merge the copies together once they're finished, Fowler recommends relying on a source code control system to record changes made to individual branches as a commit.
• However, Fowler notes that source control systems cannot always tackle all issues, such as textual conflicts. To help avoid textual or semantic conflicts, one in which, for example, two developers on a team give different names to the same variable or function. Fowler suggests using a single, shared codeline, or what he terms the "mainline," that is the current state of the code. 
• Whenever you start on a new piece of work, pull the mainline code into your local repo to work on, and update the mainline when you wish to share the code with the rest of the team. Make sure, he says, to pull changes from the mainline into your personal branch at intervals to make sure the product is up-to-date. 
• Yet Fowler notes this in itself is not enough; make sure to also keep the mainline branch and others healthy by using Self Testing Code, performing automated checks on each commit to make sure there are no issues with the branch. While it's debated how long you should do this for, Fowler notes how some team successfully separate tests into multiple stages on a Deployment Pipeline, with the first stage -- the commit suite --  lasting for about 10 minutes, to save time on other stages.
• While this process is important for personal branches, Fowler particularly recommends that you use Self Testing Code on the mainline, and build a commit suite for it. Although he notes this may take a lot of time and energy, this is critical to ensure a single commit won't break the whole development process.

Mainline Integration:

The mainline offers the team a view of the software's current state and makes it easier for everybody to integrate by allowing each developer to do so individually.

An example:

• Let's say you start working, cloning the mainline into your repository. 
• While you work, your co-worker pushes changes into the mainline. When you're ready to integrate, you fetch the current state of mainline into your local master branch to pull in the co-worker's change, and merge those changes.
• If there is no textual conflict, it will be a clean merge; Fowler again encourages the Self Testing Code approach to better manage such conflicts if there is one.
• To complete integration, you push your changes into the mainline, a very important yet overlooked step, Fowler says.

When to use it: Use it if your team is using mainline on the product.

Alternatives to using mainline integration:

• Pull from mainline and merge changes into the personal development branch, but be aware that unless the other team member pushes, others on the team won't be able to see if there are conflicts between your changes and your co-worker's.
• Another alternative: open a Collaboration Branch when you're not done but want to share work with a colleague that you think may overlap.

Feature Branching:

Create a specific branch for a feature, place all your work on there, and then integrate into mainline when you're done working on the feature.

An example:

• Let's say you're working on a feature to add to your site. You will start with the current stable version, pull the mainline into your local repo, and then make a new branch starting at the tip of the current mainline.
• As you work, you'll make a number of commits. You may also push the feature branch to the project's repo so others can see it, while you may also pull from the mainline to see if any of your other team member's changes will affect your feature. You will only be looking at each other's work, at this point, not integrating. Depending on whether or not your team likes to keep all code in a shared repo, you may push your feature branch into it to let other team members see what you're working on.
• When you're done working on the feature, you'll then perform Mainline Integration to add the feature to the product.

Integration Frequency: 

According to the State Of Dev Ops Report, top development teams integrate more than poorer performing ones, something Fowler says he's seen personally.

Avoid Low-Frequency Integration, Embrace High-Frequency Integration

• Low-Frequency integration can make it harder as you'll have to make larger, more complicated merges. Smaller merges save time in the long run and are less risky, saving you hours from having to fix an integration down the line. 
• It also helps you root out potential conflicts earlier, saving you, again, more time. For example, let's say you and a co-worker are working together. You clone the mainline into your branches, make some local commits but don't push yet. If you two develop conflicts in the initial commits, you won't be able to find it until a merge made much later if you adopt a low-frequency approach while you can opting for the high-frequency one.
• "Increasing the frequency of integration is an important reason to reduce the size of features," Fowler adds, noting doing so also makes it faster to build, deploy it into production, and reduces feedback time.

Continuous Integration:

An alternative to feature branching, those who adopt Continuous Integration integrate each time they've made a solid amount of progress on a feature every day, often many times. 

Using this approach, Fowler says you must become comfortable with the idea of reaching frequent integration points with a feature that hasn't yet been built without exposing it in the running system. For instance...

Click here to upgrade to premium to read the rest of the outline.

Deals on Tools: Laptops, Web Hosting Plans, Earbuds, and More:

• Bluehost is taking 50% off of its plans.
• Microsoft Surface Go 2 Essentials Bundle: was $668 now $539
• Anker...

Free Courses/Certifications:

• The creator of the JavaScript...

Free Books:

• David Beazley's Python...

Dev Calendar: June 2020's Virtual Events:

JUNE 18-19: A free remote JavaScript conference...