This is the written form of one of my presentations, which can be found here.
According to GitHub documentation, GitHub applications are the officially recommended way to integrate with GitHub, which essentially means that it is the way GitHub prefers you to write code around GitHub events.
Not sure what I mean?
Check out the GitHub docs for available endpoints. You can write code that responds to different GitHub events, like when a pull request opens or closes, someone comments on a pull request, or a status check passes or fails.
Why would I want to respond to GitHub events?
So what’s changed?
Well, I work for a different company now, Adobe/Magento, and have a different title,
This is the beginning of a series on automated testing and CICD (continuous integration continuous deployment) practices, both for UI and API testing. I have been writing automated test suites and setting up CICD pipelines for a few years now at the company that employs me, Rackspace. In this series I want to share some of the tools that I use to automate testing and build CICD pipelines and show you how to get set up with the basics so that you can easily add automated testing to your projects and achieve true CICD.
But first, let’s get into the…
It’s no secret that being a faster developer will increase your productivity, but it will also improve your daily workflow when you gain better control and mastery over your tools. It even has some added health benefits — just say NO to carpal tunnel!
Most of the time, being faster means decreasing the amount of keystrokes it takes for you to complete a task.
A simple example: Using aliases on the command line. Would you rather type:
git commit -m "Add cats to project" or
gcm "Add cats to project"?
13 keystrokes in the first base command turns into 3 in…