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: 47d1d1d08a9ec5ce • 2018-11-21 08:34:51 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. 10, no. 8
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)

Jesper | Sun, 26 Aug 2012 02:12:20 UTC

A comment to the system() calling answer:

A point I miss is that you might at some point want to move the code to another system that does not have the same shell available. Or even a system where the shell is available, but with slightly different arguments available for the commands. Or the commands might do something slightly different on the other system.

If you write everything in a standard language, moving the program to another system (e.g. from Linux to Windows) should be easier. The internal library calls should be the same and have the same effect on the other system; that is the job of the writers of the standard libraries of the language.

So that is another argument for staying in the same language when programming and not making calls to the shell.

A slightly similar problem is that the system the program is supposed to run on might be updated at some time in the future, below the feet of the program. Thereby the effect of the shell commands might change in subtle ways; a bug might be introduced, or a bug you depend on might be exterminated. When you use a shell command, you don't state the version of the command you expect to be called. You just say "call the current version of this command". That will often go well, but then again, it might not. Often programs are seen to be still in operation 10 years later; it is not unlikely that the system the program is running on has changed in that time period.


Leave this field empty

Post a Comment:







© 2018 ACM, Inc. All Rights Reserved.