Using non-breakable spaces in test method names is a great example of how something can start as a joke and quickly turn into something very practical and useful.
if we decide to not follow PSR-2 naming for test methods because of readability, we might as well use non-breakable spaces since it’s even more readable…
Real Favicon Generator is a handy tool for setting up your website’s favicon properly. It takes care of both the images (formats, resolutions, etc) and the HTML that you’ll need to include. With just a few clicks your website will work properly with browsers, operating systems, and mobile applications.
With so many platforms and icons, it’s hard to know exactly what you should do. What are the dimensions of favicon.ico? How many Touch icons do I need? RealFaviconGenerator did the reseach and testing for you.
If you still prefer to do it yourself and know all there is to generating proper favicon images and markup, have a look at this resource for everything there is to it and more.
Open Stack wiki has an excellent guide on how to create good commits. In a few places it is too specific to Open Stack development practices, but overall it’s one of the best guides I’ve seen for any project using git.
It is basically split into two sections. One on how to decide which code goes into the git commit, and the other is what to include in the git commit message to make it useful.
The first part is simpler:
The cardinal rule for creating good commits is to ensure there is only one “logical change” per commit. There are many reasons why this is an important rule:
- The smaller the amount of code being changed, the quicker & easier it is to review & identify potential flaws.
- If a change is found to be flawed later, it may be necessary to revert the broken commit. This is much easier to do if there are not other unrelated code changes entangled with the original commit.
- When troubleshooting problems using Git’s bisect capability, small well defined changes will aid in isolating exactly where the code problem was introduced.
- When browsing history using Git annotate/blame, small well defined changes also aid in isolating exactly where & why a piece of code came from.
With these things to avoid:
- Mixing whitespace changes with functional code changes.
- Mixing two unrelated functional changes.
- Sending large new features in a single giant commit.
The second part is slightly more detailed. Here’s the information that should be included in the commit message, generally speaking (abbreviated quote):
As important as the content of the change, is the content of the commit message describing it. When writing a commit message there are some important things to remember
- Do not assume the reviewer understands what the original problem was.
- Do not assume the reviewer has access to external web services/site.
- Do not assume the code is self-evident/self-documenting.
- Describe why a change is being made.
- Read the commit message to see if it hints at improved code structure.
- Ensure sufficient information to decide whether to review.
- The first commit line is the most important.
- Describe any limitations of the current code.
- Do not include patch set-specific comments.
In other words, if you rebase your change please don’t add “Patch set 2: rebased” to your commit message. That isn’t going to be relevant once your change has merged. Please do make a note of that in Gerrit as a comment on your change, however. It helps reviewers know what changed between patch sets. This also applies to comments such as “Added unit tests”, “Fixed localization problems”, or any other such patch set to patch set changes that don’t affect the overall intent of your commit.
Read the whole thing for more details, examples of good and bad practices, and more specific instructions on the spacing, line length, and more.
And if you need more convincing or a different explanation, then Google “git commit best practices” or simply check out some of these resources:
GitHub blog is “Announcing Open Source Guides“:
we’re launching the Open Source Guides, a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to open source.
Open Source Guides are a series of short, approachable guides to help you participate more effectively in open source, whether it’s:
- Finding users for your project
- Making your first contribution
- Managing large open source communities
- Improving the workflow of your project
These guides aim to reflect the voice of the community and their years of wisdom and practice. We’ve focused on the topics we’ve heard about most, and curated stories from open source contributors across the web.
I think it’s a great idea and I really like the execution too. Most of what I know about Open Source comes from years of participation, and from reading old books, manuals and licenses – not something that is easy to share with people who are just getting their feet wet.
GitHub’s Open Source Guides are very simple, concise and specific. And they cover a variety of subjects, not just the legal or technical side of things, but also communications, support, marketing, etc.
Fergus Henderson, who has been a software engineer at Google for 10 years, published the PDF document entitled “Software Engineering at Google“, where he collects and describes key software engineering practices the company is using.
It covers the following:
- software development – version control, build system, code review, testing, bug tracking, programming languages, debugging and profiling tools, release engineering, launch approval, post-mortems, and frequent rewrites.
- project management – 20% time, objectives and key results (OKRs), project approval, and corporate reorganizations.
- people management – roles, facilities, training, transfers, performance appraisal and rewards.
Some of these practices are widely known, some not so much. There are not a lot of details, but the overall summaries should provide enough food for thought for anyone who works in the software development company or is involved in management.
PHP Package Development Standard, aka pds/skeleton, is now stable. I’ve linked to it before and I think it’s a great idea and I’m glad I’m not alone:
Roughly 78,000 packages already comply with the
pds/skeleton standard, although they may not know it. To formally show that your package has adopted the standard, “require-dev” it via Composer, or display a badge on your README.
I’d gladly follow this standard for my own work too, except that I mostly work with WordPress and CakePHP these days, both of which do things differently from the standard and from each other.
WordPress kind of assumes that the whole project is public, so you don’t really get public/ folder. It also organizes the code into wp-includes/, wp-admin/ and wp-content/ folders, instead of the src/ suggested by PDS. And, in terms of configuration, everything goes into wp-config.php file instead of something in the config/ folder.
CakePHP is much closer to PDS in terms of organization of files. The only difference that I can spot is the use of webroot/ folder instead of the suggested public/.
I’d really love to see larger libraries and frameworks adhere to the PDS, but until that happens, I’ll keep an eye on things.
P.S.: The standards comic strip is of course from xkcd.
If you write any Bash code that lasts more than a day, you should definitely read “Defensive BASH Programming” and follow the advice, if you haven’t already. It covers the following:
- Immutable global variables
- Everything is local
- Everything is a function
- Debugging functions
- Code clarity
- Each line does just one thing
- Printing usage
- Command line arguments
- Unit Testing
All that with code examples and explanation of importance.
PagerDuty shares their Incident Response Documentation:
This documentation covers parts of the PagerDuty Incident Response process. It is a cut-down version of our internal documentation, used at PagerDuty for any major incidents, and to prepare new employees for on-call responsibilities. It provides information not only on preparing for an incident, but also what to do during and after. It is intended to be used by on-call practitioners and those involved in an operational incident response process (or those wishing to enact a formal incident response process).
I think this is a goldmine for anybody involved with incident response teams, operations, monitoring, technical support, network centers, and other similar setups. Not only it covers the specific steps and expectations during different situations, but it also defines the culture, which the company is trying to built.
I wish I had this 15 years ago when I was involved in setting up the Network Operations Center (NOC). I will definitely use it in the near future, when we’ll be setting up the support department at work.