It may not be the fastest programming language, nor is it the most popular language when it comes to the numbers game, but how can you not fall in love with:
10.times { print "Hello!" }
(instead of something like for(var i=0; i<10; i++){ console.log("Hello!"); })
Do things with sets like:
["a", "b", "c"] & ["b", "c", "d"] # gives you ["b", "c"]
[1,2,3] + [4,5] # gives you [1,2,3,4,5]
["a", "b", "c"] - ["b", "c", "d"] # gives you ["a"]
Or (with a little (opinions differ on this one ;)) help of Rails):
10.days.ago
That offers you exactly what you would think it would return: the date of 10 days ago.
And no ;’s, only brackets when absolutely needed, everything is an object…
Yes, it’s actually a language a human might understand, and still: it is pretty powerful, powering some of the most popular sites on the web, like AirBnB, Shopify, Basecamp (they’re the creators of Ruby on Rails), Github, Kickstarter, Twitch, Strava and many more (most of the full stack projects I did & do are using ruby).
Enjoyed this? Follow me on Mastodon or add the RSS, euh ATOM feed to your feed reader.
A simple OAuth provider. See below for more information, or check out the source of CentralLogin on GitLab. To integrate it with your ruby-apps, use the omniauth-central_login gem.
This app builds on the foundations of the Doorkeeper, Doorkeeper::OpenidConnect and Devise to provide a central login system.
While Doorkeeper supports other OAuth flows, CentralLogin focusses on OpenID Connect as it is a more complete, and hence useful standard, for most use cases where you want to support authentication & authorization.
This project builds on years of juggling with different authentication providers and implementations. It may cut corners to be a pragmatic and less flexible solution which you can host on your own. You don't have to tie your users to a closed authentication system such as Auth0, Azure Directory, Cognito (the horror, really, stay away from it) or something else. In the past I've been a happy user of Keycloak, which is definitely way more advanced than this project, but it in the end it is a Java application and hence harder for me to maintain and not focussed on what I think are the core requirements :)
So, are you in the market for:
Capistrano doesn't evolve as quickly anymore but it still delivers and is still being maintained. It dates from before docker & autoscaling kubernetes were in wide use. I still prefer the simplicity of the tool: Capistrano I can understand, it is just a nice layer on running scripts on a remote server. Below some posts I did on Capistrano.
While we're supposed to create docker(y) images and deploy these to the cloud, I'm still comfortable deploying and maintaining quite a range of applications using Capistrano (this builds on the battle tested server management process that I outlined more than 7 years ago). But Capistrano and its plugins are typically aimed at performing application level tasks, and not so much about configuring the environment.
I typically install ruby using rbenv. To deploy ruby apps using rbenv a Capistrano plugin exist (capistrano/rbenv) but it is missing the commands to install and/or update the ruby installation.
This snippet presented here adds a few commands:
cap rbenv:install ## installs rbenvcap rbenv:update ## updates rbenv & install…Ever had the problem that you reuse the same project for a managemable number of clients? Too few to store branding materials in a database, but more than one making it hard to keep separate branches in sync?
Introducing BrandingRepo (for Rails)
The idea is simple: create a configuration file with those files that are specific to different brands/customers and store their mods in a different repository. Repository is quite a big word here: we simply create a config/brands folder in your current branch where you can push and pull your brand specific adjustments from. All managed in the same git repository.
What it is not:
Add this …
I'm still a big fan of Ruby on Rails. No other framework has ever made me as productive. And it is no a secret that it makes quite some other product companies very successful. Think of Shopify, Github, Basecamp, Hey, and others.
But if you'd look at at the list of most popular languages, the top 10 doesn't feature ruby anymore.
In their 2020 survey on most popular technologies, StackOverflow writes:
> Additionally, Ruby, once in the top 10 of this list as recently as 2017, has declined, being surpassed by newer, trendier technologies such as Go and Kotlin.
Also if you look at Google trends, ruby has always been negligible when compared to Python or PHP or Javascript, [the trend is downward for the ruby package manager](https://trends.google.nl/trends/explor…
I am currently selecting a static site generator for an upcoming project. I value technical simplicity (exit React based solutions), like ruby and in the Static Site Generator category Jekyll is an established name. But doesn't the project that started in October 2008 show signs of age?
Inheritance is considered bad practice for quite some time now (Gamma, Helm, Johnson & Vlissides, 1994). Little did I know when I started the ‘workbook’-project in 2012 (note that I don’t have a computer science background).
The main reason I wrote this workbook-gem was that I wanted the most predictable API for working with spreadsheet data (acting as arrays of arrays), not having to use a different API when reading XLSX or CSV files, nor when writing it.
After learning that inheritance is not always a good thing, I still often thought of a workbook as an array of arrays and hence an exception to the rule. But then I came accross a helpful post by Avdi Grimm: [Why you shouldn’t inherit from Ruby’s core classes (an…
Om de zoveel tijd komt de term weer terug: 'TCO'. Total Cost of Ownership. Hoeveel het allemaal bij elkaar kost. Het werd in het verleden ondermeer uit de kast gehaald door Microsoft om te waarschuwen voor de kosten die de conversie van naar opensource software met zich mee zouden brengen. Onder TCO wordt dan ook gekeken naar o.a. opleiding, de kosten van licenties, wat de onderhoudsmedewerkers kosten (linux beheerders zouden duurder zijn dan mensen met een microsoft diploma). Wat willekeurige observaties.
Jaren terug genoteerd:
> Grappig om te zien hoe hij met het bijna niets kostende stukje software (van een grote speler) vele uren bezig is om via de complexe interface iets relatiefs simpels voor elkaar te krijgen: een factuur te printen. Straks gaat het zich terugbetalen, zo gaat het argument… maar ik heb er weinig vertrouwen in. Niet in dit geval. Wanneer je werkt met relatief grote bedragen worden er niet zoveel facturen verstuurd. Automatische koppelingen met de bank is …
I recently shared an overview article about Stubbing External Services in Rails. I found it when looking for the best way to stub a pletora of services in a microservices environment. Sure, docker (or whatever) everything and run it locally / in your test suite. But unless you've plenty of disk- and memory space, this isn't always a viable option. The alternative: simulate the service. Mock or stub the endpoint.
The go to gems are Webmock, which catches request and allows you to define the responses explicitly and VCR, which allows you to record responses, and play back.
VCR is quite cool, but as it is a recorder of earlier responses, there may be a lot of noise to dig trough when trying to make the responses a bit more generic (dealing with random token requests and what else)
For testing I pers…
A quick note, because I was using the wrong search terms. If you want to share e.g. the current user of an app with a model you can now (since Rails 5.2) use a model inheriting from ActiveSupport::CurrentAttributes. Before you were required to pass this current user explicitly or find another way to access state.
Note that this can either be a good thing or a bad thing (tl;dr: thread-local global state makes apps unpredictable)
And even the docs warn against abusing this feature. Powerful tools can come with dangerous consequences :) Global variables are immensely powerful. Use with care. I'm not even sure if I'm going down this path…
There are a lot of things that I don't understand. One of these things is how memory management really works. Memory management is hard, and even though I use languages that do garbage collecting by themselves, long running ruby apps seem to run out of memory after n number of days. Even the pro’s find it quite hard. While I previously resetted the failing app every now and then, I was triggered by Mike Perham’s (creator of Sidekiq) post: “Taming Rails memory bloat”.
When you start searching for the memory bloat problem, you'll find several directions. The easiest is changing a global variable which changes the number of “arena’s” where memory allocation takes place (note: I’m in no position to explain all this, please follow the references). The fanciest, however, seems to be changing the memory allocator from glibc's default 'malloc' to jemalloc. See for example [this](https://www.speedshop.co/2017/12/04/malloc…
Prometheus is a statistics collecting tool that originated from SoundCloud. Designed to be used in high performance environments, it is build to be blazingly fast. Hence, the client typically is expected to be blazingly fast as well, gathering and presenting data within nanoseconds. For Ruby on Rails applications however this has lead to an unresolved issue with the Prometheus ruby-client when the same application is forked (typical for Puma, Passenger and other popular ruby-servers). The Prometheus client collects data within its own fork before serving it to the exporter endpoint. This can or cannot be a problem. When you measuring response times, running averages from a random fork may be good enough. However, when you're also counting data over time you're having separate counters in …
Dit artikel van murblog van Maarten Brouwers (murb) is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie .