September/October 2018 issue of acmqueue The September/October issue of acmqueue is out now

Subscribers and ACM Professional members login here



Kode Vicious

Development

  Download PDF version of this article PDF

Error 526 Ray ID: 47c87b71ef86c5fa • 2018-11-20 05:23:02 UTC

Invalid SSL certificate

You

Browser

Working
Newark

Cloudflare

Working
deliverybot.acm.org

Host

Error

What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.

acmqueue

Originally published in Queue vol. 8, no. 3
see this item in the ACM Digital Library


Tweet


Follow Kode Vicious on Twitter
and Facebook


Have a question for Kode Vicious? E-mail him at [email protected]. If your question appears in his column, we'll send you a rare piece of authentic Queue memorabilia. We edit e-mails for style, length, and clarity.


Related:

Alpha Lam - Using Remote Cache Service for Bazel
Save time by sharing and reusing build and test output


Jez Humble - Continuous Delivery Sounds Great, but Will It Work Here?
It's not magic, it just requires continuous, daily improvement at all levels.


Nicole Forsgren, Mik Kersten - DevOps Metrics
Your biggest mistake might be collecting the wrong data.


Alvaro Videla - Metaphors We Compute By
Code is a story that explains how to solve a particular problem.



Comments

(newest first)

Dan Cross | Sun, 26 Aug 2012 15:29:46 UTC

Peer pressure should not be confused with shaming, which is always essentially negative. Indeed, one of the first lessons of leadership is "praise in public, criticize in private."

Rather, creating an environment where it's okay for one to take public responsibility for an error is far more effective. Ensuring that peer pressure is constructive can be used towards this end, as can good-natured competition (I like Paul Murray's example of the toy duck). Everyone makes mistakes and it is the mark of a healthy environment and a strong leader when one can acknowledge those mistakes to others in the organization. Making someone feel ashamed of making a mistake is neither scalable nor conducive to the long-term health of the organization.


Paul Murray | Tue, 08 Mar 2011 05:27:23 UTC

I worked at one site where whoever had most recently broken the build had a duck (not a real duck, obviously) put in their cubicle. It was a triumphant occasion to pass the duck along to someone else.

Peer pressure, and a sense of professionalism and pride in your work. Each team member must internalise the value "I do not screw up everyone else's day by breaking the build".


Vijay Narayanan | Tue, 13 Apr 2010 00:55:41 UTC

Very useful article! I want to add that broken builds could also be due to too many manual steps in setting up development environments. There is always the temptation to "do the minor fix" but not go all the way- why go through the trouble of compiling the rest of the code, deploying, and verifying? When I hear a developer say "my dev environment is not setup" for days and weeks - that is a warning sign that the build might be too complex, manual, and error-prone. When you script the environment setup and the build process and start creating automated tests - it just makes the entire team more productive.


David Rogers | Tue, 30 Mar 2010 22:29:43 UTC

Great article! I would like to add that if the offender is unable to build the project with their changes before checking in those changes, you have an infrastructure problem. If they are technically able to build with their changes, and don't, you have a disciplinary problem.


Juan Manuel Trejo Sánchez | Thu, 18 Mar 2010 20:35:46 UTC

I think one important point here too is culture at work. When there's considerable time spent on discussions on how it is your fault and not mine, and not in actually solving the problem, there's more likely no will to agree something has to be improved, nor to propose how to improve it, volunteer to collaborate on the improvement or accept the changes derived from it.

What I mean is having a culture of feedback and openness where nothing is ever personal also need to be enforced. It may sound an ideal case yet it's possible: A culture where people know they are being evaluated always on their work and not on themselves, where feedback is intended for improvement and enforces constant improvement. Where people are not defensive, having to lie or argue to avoid feeling ashamed or being labeled, or even avoiding responsibilities.

That way people will feel safe and be open to improve, and will be motivated to help achieve the goals.

It is hard to push for any change in infrastructure, architecture or attitude when people are prone not to collaborate and are more worried about their own image and reputation.

These are my two cents, I love the way you explain things here, Kode.


Leave this field empty

Post a Comment:







© 2018 ACM, Inc. All Rights Reserved.