Traditional software is downloaded, installed, then run. With web applications it is different. These are built, then pushed to a remote server and then the interface of that application is presented to the screen of the users via web-technologies like HTML, CSS & JavaScript, in the past sometimes assisted by Flash, these days using WASM. Besides that web applications need databases, storage, cache-systems, maybe a search solution, and sometimes more dedicated tools. From the end-user's perspective, it became a lot easier (although more restrictive) to access these tools, but getting it up and running got harder.
In the old days web software was deployed by uploading software via FTP, in a folder that was then read by a web server, and then presented to the user of the web-application. I've also deployed compiled .war files manually via a tomcat web-interface. Databases, storage, these were all pretty much managed by hand, sometimes even requiring physically adding a new drive or…
When you're writing server to server communication locally, and these servers are running behind some proxy like puma-dev that enables SSL connections, you may face issues with OpenSSL (or variant) not trusting the connections. That is good, you want OpenSSL not to trust just any random certificate. But how to make it pass?
Your web browser probably allows you to visit a page on a server and even approve the certificate. You should then export the chain as .pem (Firefox makes this pretty easy: click on the lock, view security, view certificate, go to the "CA"-tab for that certificate and export the chain.
This PEM chain is just a plain text file, containing the public certificates of your local 'CA' (created by Puma-Dev)
Copy the text using an editor of choice.
And now open up: /opt/homebrew/etc/ca-certificates/cert.pem and add it.
Also make sure that everything uses this cert.pem by symlinking it to this file, so for example with ruby run
$ ruby -ropenssl -...
I was asked to make a list of my favourite beers…
For regular drinking, it is never a bad idea to go into a supermarket and to take a box of Gulpener Biologisch (organic). Gulpener harvests all their ingredients close to the brewery. They have three variants, a regular Pilsner, a Weizen and an IPA. Recently I drank their organic Pilsner again after choosing mostly their IPA variant, and realised that it is close to defining Pilsner. Their IPA is also never disappointing, and one that stands above many of these cooler smaller fancy (read more expensive) IPA’s.
Then what other beers? Amsterdam itself has lots of smaller breweries, biggest of the smallest is Brouwerij ’t IJ. Try Columbus for a heavier one (9%; IJ is the name of the river through amsterdam, which is in pronounciation not different from Dutch ‘ei’, which translates to egg, hence all kinds of twists around egg, egg of columbus etc. [Troost](https://bro…
When you maintain a few projects locally developing against localhost works good enough. npm start or rails s or python manage.py runserver or php -S 127.0.0.1:8000 will boot up a server that binds to a local port and allows you to see your work locally. The advantage of using localhost is that you don't have to bother with https-traffic as browsers don't require https for their latest features, but sometimes you need different domains to test and running multiple services distinguished by nothing more than their port numbers can become hard to manage.
To address this problem not only for websites served by the puma server, puma-dev exists. It is a spiritual successor to Sam Stephenson's Pow, which solved this problem for rack-apps. puma-dev, however, can proxy other servers as well, whether these are written in Javascript, PHP, ruby or other languages; as long as these exposes a port to 127.0.0.1, your local loopback/host you can use…
Dit artikel van murblog van Maarten Brouwers (murb) is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie .