Jenkins has several "hidden" features that can be enabled with system properties. This page documents many of them and explain how to configure them on your instance.

Palisade works by reading two files in the root of your repository:

• A CHANGELOG.md file that describes the changes made to the program
• A VERSION file that contains the current version of the program (ideally following semantic versioning)

Every time Palisade is run, it will check the git repository for version tags based on the contents of the VERSION file. If it finds that the current version has already been tagged, Palisade will do nothing and exit with the exit code 0. If Palisade finds that there is a new release, the software will then read the changelog file, scrape it for release notes, then use those release notes when creating a new release on GitHub.

mkcert is a simple tool for making locally-trusted development certificates. It requires no configuration.

A set of common UI elements with a hand-drawn, sketchy look. These can be used for wireframes, mockups, or just the fun hand-drawn look.

If you're setting up a service where people can register their own usernames to be used as a hostname (username.example.com), email address (username@example.com), or URL path (example.com/username) within your domain, there are some common names you should avoid letting the general public register.

...

This is a list of all the names I know that should be restricted from registration in automated systems. If you know of others, please let me know and I'll update this page.

In this quick tutorial I want to show you how to generate a deb package from scratch that will install a binary executable in the target system. Let's start off with a bit of theoretical background.

You need two things to effectively move fast: a culture of psychological safety and smart investments in tooling. Employees need to feel empowered to speak up if things are moving too fast—if they are concerned about why a feature is being built and to identify gaps in the processes. They need to feel they won’t be blamed when something breaks. Building this requires empathy, open communication, and teamwork. This psychological safety is the foundation of being able to move quickly and quickly recover when things break.

Next up is selecting the right tooling and processes. Invest in tools that make things easier. Tools should be useful, usable, and change the underlying problems, not create more.

I’ve used the term *Feature Factory* at a couple conference talks over the past two years. I started using the term when a software developer friend complained that he was “just sitting in the factory, cranking out features, and sending them down the line.”

How do you know if you’re working in a feature factory?

Many developers have been voicing their concerns about Agile being broken lately. Among them are prominent figures like Robert C. Martin and Kent Beck – two of the people who charted the Agile Manifesto. Some of the most frequently-mentioned problems with Agile are: Agile ignores technical debt; frameworks like Scrum are just “red tape,” which they were never supposed to be; programmers are asked to commit to arbitrary estimates and deadlines and never get the time to think thoroughly about the features they’re creating. So if we can acknowledge and work on these problems, perhaps we can fix Agile.

Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.