DEV Community: cristiano

How to install SDL2 on macOS

cristiano — Wed, 26 Jun 2024 14:20:50 +0000

Running SDL2 libraries on macOS is slightly different than running them on Linux and Windows systems.

You might want to run these libraries to work on a native application or a video game that requires graphics and access to other system controls.

Since there are a few pitfalls to avoid I have put this resource together that covers installing SDL2 and SDL2_image into the system.

Finally, I'll include a test program to open a window and a command to compile it.

It is written in C but SDL can be used with C++, Rust and a few other languages as well.

Installation

The first step is to get all files required into your system.

Download SDL2 by picking the .dmg one from the release list:

https://github.com/libsdl-org/SDL/releases

Additionally, download the SDL2_image library (also a .dmg from its release list:

https://github.com/libsdl-org/SDL_image/releases

Execute the SDL2 file (will be named something similar to SDL2-2.30.4.dmg) and a window will open with a few files and an SDL2.framework folder.

Open Finder, click Go then Go to folder... and type /Library/Frameworks which will open the contents of that folder.

Drag SDL2.framework to /Library/Frameworks and repeat the steps for the SDL2_image file.

There should be two additional folders in /Library/Frameworks, SDL2.framework and SDL2_image.framework.

Compile a program

One way to test the installation is to write a program, this one opens a window in the system.

Create a main.c file and add the contents below to it:



#include <stdio.h>
#include <stdbool.h>
#include <SDL.h>
#include <SDL_timer.h>

int main(void)
{
    // Attempt to initialize graphics and timer system.
    if (SDL_Init(SDL_INIT_VIDEO|SDL_INIT_TIMER) != 0)
    {
        printf("error initializing SDL: %s\n", SDL_GetError());
        return 1;
    }

    SDL_Window* window = SDL_CreateWindow("Hello, SDL2 on macOS 🍎",
                                       SDL_WINDOWPOS_CENTERED,
                                       SDL_WINDOWPOS_CENTERED,
                                       640, 480, 0);
    if (!window)
    {
        printf("error creating window: %s\n", SDL_GetError());
        SDL_Quit();
        return 1;
    }

    // Keep the window open, in this case SDL_Delay(5000); statement won't work.
    bool running = true;
    while (running)
    {
        SDL_Event e;
        while (SDL_PollEvent(&e) != 0)
        {
            if (e.type == SDL_QUIT)
            {
                running = false;
                break;
            }
        }
     }

    // clean up resources before exiting.
    SDL_DestroyWindow(window);
    SDL_Quit();
}

On a terminal window, navigate to the same directory of the main.c file and attempt to compile it:



gcc -o open_window main.o `sdl2-config --libs --cflags` -ggdb3 -O0 --std=c99 -Wall -F/Library/Frameworks -framework SDL2 -framework SDL2_image -lm

This could work first try but in my case I've hit quite a few issues a few are solved by the way the header files are included and the structure of the compile command which have already been addressed but there's a few more I found while trying to compile an SDL2 based program.

One of the issues might look like this:



dyld[94016]: Library not loaded: @rpath/SDL2.framework/Versions/A/SDL2
  Referenced from: <BAD3873A-39CC-4033-8C2A-85A0FC365404> /Users/user/Projects/open_window/open_window
  Reason: no LC_RPATH's found
[1]    94016 abort      ./open_window

The way I solved it was by running the following in the terminal before compiling the program:



export DYLD_FRAMEWORK_PATH=/Library/Frameworks

macOS displays a notice saying “SDL2.framework” cannot be opened because the developer cannot be verified

The issue can be addressed by running the executable, e.g. ./open_window then opening the Privacy & Security settings and scroll to Security.

You will see a button to allow the SDL2.framework, click "Allow Anyway".
Do the same for SDL2_image.framework if it shows up.

The notice should now show an "Open" option, there's more context in this Github issue:

https://github.com/libsdl-org/SDL/issues/4689#issuecomment-2189963510

Opening a window

Assuming the program compiled correctly we can now open a window by executing the program.

On a terminal run ./open_window and an empty should should now show!

Additional Notes

A lot of programs will use #include <SDL2/SDL.h> but in this case #include <SDL.h> needs to be used instead when including SDL related header files.
SDL2 can also be installed with Homebrew, if you prefer it there's a tutorial on dev.to that goes over the setup as well.

Managing JS and CSS Assets in Rails 7

cristiano — Sat, 08 Jan 2022 21:04:32 +0000

Image by Pawel Czerwinski

On Ruby on Rails 7 the asset management processes have changed from using Webpacker to use the asset pipeline with Import Maps by default as a way to streamline uses of JavaScript based tools and package managers such as Webpack (or other bundlers) Yarn or npm.

This article aims to explore Import Maps and custom bundling setups on a high level including a quick look over Webpacker so that it can be compared with other approaches, a short example of using Import Maps and a more convoluted example of custom bundling using esbuild with TypeScript and PostCSS.

Hopefully this article can be used as a starting point for someone who uses JavaScript tools to bundle assets but has little knowledge of how this currently works in the context of a Rails app.

Webpacker

This asset management approach was introduced in Rails 6 and is essentially an implementation of Webpack specifically configured to be used with Rails. This is a quick overview of Webpacker so that we can draw a comparison with more recent approaches to asset bundling.

With Webpacker a config/webpacker.yml is used as an interface to define the app’s Webpack configuration and a config/webpack folder was used store files to specify handling of assets in different environments (development, production) or to adapt it to use certain JavaScript libraries which might require additional configuration.

It would also include a package.json which has become common to use in any application that makes use of Node modules.

To install dependencies, yarn install needs to be run but when rails server is ran it would spin up the Rails application and run the Webpack watch task so that the assets are bundled correctly.

One disadvantage could be that the bundling tool is locked to Webpack behind an abstraction configuration layer as it was the default asset management approach picked for version 6.0.0 of Rails.

What I mean by abstraction layer here is that there wouldn’t be a need to configure Webpack and it would just work out of the box but configuration aspects are hidden behind the scenes and changing them required to change a webpacker.yml and not the Webpack config directly. Rails had logic in place to glue all of this together behind the scenes.

Stripping it out or ignoring it in favour of a custom implementation is possible but it’s an extra step and can be more time consuming.

Import Maps

Import Maps is the pattern being shipped with a default Rails 7 application. It makes use of a feature where JavaScript modules that would typically be installed with a package manager, such as Yarn or npm, and in most cases transpiled and bundled into a .js file can be imported directly into the browser and used in your application without an extra build step.

Key aspects on the Import Maps approach

It’s more tightly coupled with Rails as it is the way the creator encourages developers to go for and ships with a default Rails app.
Can simplify your toolchain since no npm or bundlers are required to make use of JavaScript libraries.
Requires less configuration, running a new rails new myapp is enough to get you started.
It does not include an option if you prefer an approach of bundling your own styles. For example using SASS or Postcss, although nothing stops you from making use of a hybrid approach and add a build step yourself.
Less control of your asset bundling so if you require more complex JavaScript and CSS handling such as using Postcss partials or using a custom way of transpiling JavaScript it might not be the best choice.

Using Import Maps in a website (including a Rails app) will result in the source code look something like this:

<script type="importmap" data-turbo-track="reload">{
  "imports": {
    "application": "/assets/application.js", // A local JS file.
        "another-js-library": "/assets/another-js-library.js, // Another local JS file.
        "local-time": "https://ga.jspm.io/npm:local-time@2.1.0/app/assets/javascripts/local-time.js" // A library being imported via a CDN.
  }
}</script>

The example above shows a description of which modules the page is using as importable files. Others could be added such as React, JQuery or pretty much any other JavaScript library.

Then the modules are imported after the importmap script tag by rendering a few additional module tags (can be one per module at times). In this case the libraries in the importmaps script tag are being used in application.js so only a single module tag is required and this should work for most cases:

<script type="module">import "application"</script>

Rails will generate these tags for you when the <%= javascript_importmap_tags %> is added to a layout, typically application.html.erb and will work out which modules need to be included.

For browsers that do not fully support this feature, the Rails team has created a shim to make it work for now.

What is a shim?

Essentially it’s a program that intercepts the default behaviour of another program or implementation and adds new logic to it, with the aim to make it work better with the application is being used in.

In this case it intercepts the Import Maps feature and adds logic to make sure it works correctly in all the modern browsers as well as making it compatible with the Rails pattern.

Using Import Maps in Rails

To import a package that is typically available in npm run the following command in the terminal. In this case it will install local-time:

./bin/importmap pin local-time

This will add a new line to config/importmap.rb to put the package to use. This file is essentially used for Rails to generate the Import Maps script tag that is placed in the final HTML output:

pin "local-time", to: "https://ga.jspm.io/npm:local-time@2.1.0/app/assets/javascripts/local-time.js"

If you would like to download the package to store it in your application, using the --download flag will pull the module file into vendor/javascript/local-time.js and it would also change the pin statement to reflect the change:

pin "local-time" # @2.1.0

The module can then be used in app/javascript/application.js like a regular import would be:

import LocalTime from "local-time"

In some cases you might want to use a module you’ve been working on and is not hosted with npm. To do this, add the file to assets/javascript in this case I’ve named it home.js:

console.log("Hello Home!")

Then it can be imported to application.js:

// Configure your import map in config/importmap.rb. Read more: https://github.com/rails/importmap-rails
import "@hotwired/turbo-rails"
import "controllers"
import "trix"
import "@rails/actiontext"
// Importing the home.js script here!
import "./home"
import LocalTime from "local-time"
LocalTime.start()

That should be it, the code inside home.js should run without the need to be pinned in importmap.rb.

The importmap.rb file is used to workout which modules will be in the following tag:

<script type="importmap" data-turbo-track="reload">{
  "imports": {
    "application": "/assets/application.js", // A local JS file.
        "another-js-library": "/assets/another-js-library.js, // Another local JS file.
        "local-time": "https://ga.jspm.io/npm:local-time@2.1.0/app/assets/javascripts/local-time.js" // A library being imported via a CDN.
  }
}</script>

It will also render any other necessary tags in order for Import Maps to work. Each tag points to a module used by this app in particular so your output might be different than this snippet:

<link rel="modulepreload" href="/assets/application-97114f95015a6fb5e0cb87c109b1397e96ba9a9d1e7422725a491c2034ce6580.js">
<link rel="modulepreload" href="/assets/turbo.min-305f0d205866ac9fc3667580728220ae0c3b499e5f15df7c4daaeee4d03b5ac1.js">
<link rel="modulepreload" href="/assets/stimulus.min-900648768bd96f3faeba359cf33c1bd01ca424ca4d2d05f36a5d8345112ae93c.js">
<link rel="modulepreload" href="/assets/stimulus-loading-685d40a0b68f785d3cdbab1c0f3575320497462e335c4a63b8de40a355d883c0.js">
<script src="/assets/es-module-shims.min-6982885c6ce151b17d1d2841985042ce58e1b94af5dc14ab8268b3d02e7de3d6.js" async="async" data-turbo-track="reload"></script>

This is currently the encouraged way to manage JavaScript in a Rails application but the Rails team has worked towards giving developers some freedom to implement their custom bundling as well.

Custom Bundling

Using your own bundling system such as Webpack, Rollup, esbuild or other is also possible in cases where you require a more robust setup. Perhaps you would like to use TypeScript or implement your own configuration of React, Svelte or Vue. You could want a setup with Sass or Postcss. You might simply want to have more control on how dependencies are installed and where they end up. If you require a more convoluted setup this could be the right approach to take.

Key aspects on the custom bundling approach

The bundler choice and configuration is left completely up to you. This can either be a positive change, because you get more control or could mean that it requires an extra step when setting up the pipeline and a number of additional configuration files.
The Rails team has made available the jsbundling-rails gem that streamlines configuring your application with esbuild, Webpack or Rollup along with [cssbundling-rails](https://github.com/rails/cssbundling-rails) which is the equivalent to manage CSS bundling. Yarn is used in this case.
This approach requires yarn build --watch to be run alongside the Rails server process but using ./bin/dev will run both processes in one go.

In new Rails 7 apps, a bundler and CSS pre processor can be specified using the following command:

rails new myapp -j esbuild -c postcss

The options for bundlers and CSS pre processors are limited to the options jsbundling-rails and cssbundling-rails offer. See each of the repositories README files for details since they might provide a starting point and save you some time when creating a setup with your preferred tools.

After using this command, a scripts object with build and build:css tasks still need to be defined and configured in package.json. An example of how these tasks may look like using the previously selected bundler and pre-processor:

// previous file contents...
"scripts": {
    "build": "esbuild ./app/javascript/*.* --outfile=./app/assets/builds/application.js --bundle",
    "build:css": "postcss ./app/assets/stylesheets/application.postcss.css -o ./app/assets/builds/application.css"
},
// file continues...

Using this approach still couples it with Rails configuration which expects a few things:

The JS and CSS final output needs to be copied to app/assets/builds. This means your final transpiled .js and processed .css files are expected to be served from here.
Rails makes use of <%= stylesheet_link_tag "application", "data-turbo-track": "reload" %> and <%= javascript_include_tag "application", "data-turbo-track": "reload", defer: true %> to look for a bundled application.js and a application.css in the builds directory and expect these to exist.

Other than that, it seems JavaScript files and CSS files can be put together in a flexible way. However, using the stylesheet_link_tag method to add link tags to the head of the document seems to still require bundled files to be in the builds folder:

<%= stylesheet_link_tag "application", "data-turbo-track": "reload" %>
<%= stylesheet_link_tag "style", "data-turbo-track": "reload" %>
<%= javascript_include_tag "application", "data-turbo-track": "reload", defer: true %>

In the example above a link tag pointing at app/assets/builds/style.css will also be included in the rendered HTML.

How does Rails determines that the builds folder should be where compiled assets are meant to be stored? This is decided by the jsbundling-rails and cssbundling-rails codebases, in their default internal configuration.

How about creating a JavaScript module?

The same way a bundled CSS file is expected to be in /builds when using stylesheet_link_tag, the same is expected for a bundle JS file when using javascript_include_tag.

By default, using this custom bundling approach, Rails uses app/javascript/application.js as an entry point to compile files and you could split your scripts within this folder and import them in, as well as any modules installed via Yarn, this is what the file looks like:

// Entry point for the build script in your package.json
import "@hotwired/turbo-rails"
import "./controllers"

Creating a new module in app/javascript/external.mjs shows how Rails picks up the change when the file is imported into application.js and that the .mjs extension can be used with no issues:

export const external_message = "External module loaded";

export function result() {
  return 3 + 3;
}

What about TypeScript?

Typescript can be added in a few steps, check out Noel Rappin’s post on how to get TypeScript up and running.

Here’s a breakdown of an example setup that builds on the previous steps, start by installing the typescript, tsc-watch and a configuration package. I’ve used @tsconfig/recommended:

yarn add --dev typescript tsc-watch @tsconfig/recommended

Then we want to run the TypeScript checker before esbuild transpiles the code so a watch:ts command was added along side of a failure:ts command to run on failure to the package.json scripts object:

"scripts": {
    "build": "esbuild ./app/javascript/application.ts --outfile=./app/assets/builds/application.js --bundle",
    "build:css": "postcss ./app/assets/stylesheets/application.postcss.css -o ./app/assets/builds/application.css",
    "failure:ts": "rm ./app/assets/builds/application.js && rm ./app/assets/builds/application.js.map",
    "watch:ts": "tsc-watch --noClear -p ./tsconfig.json --onSuccess \"yarn build\" --onFailure \"yarn failure:ts\""
},

This requires a tsconfig.json, this might be tricky to configure if you don’t do it often so here’s the configuration I’ve used:

{
  "extends": "@tsconfig/recommended/tsconfig.json",
  "compilerOptions": {
    "target": "ES2015",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "downlevelIteration": true
  },
  "$schema": "https://json.schemastore.org/tsconfig",
  "display": "Recommended",
  "include": [
    "./app/javascript/**/*.ts"
  ],
  "exclude": [
    "./node_modules"
  ]
}

Next, it’s required to rename the entry file at app/javascript/application.js to application.ts so that the TypeScript checker picks up on it.

Finally, the contents [Procfile.dev](http://Procfile.dev) need to be edited in order to run the TS watch command instead of the build one. We are running the esbuild command via ts-watch and that’s why it does not need to be in the Procfile:

web: bin/rails server -p 2077
js: yarn watch:ts
css: yarn build:css --watch

Running ./bin/dev in the terminal will start the tasks and the track changes as well as run TypeScript checks on any .ts files in the ./app/javascript directory.

Conclusion

With Rails 7, the framework now ships with an Import Maps approach by default but it does leave options for more complex setups with custom bundling which still have to be done “the Rails way” in some sense. This is noticeable, for example, when a there are assigned default entry points for scripts and pre processed styles. It does help developers that are looking to get slightly more control over their bundling and this seems to be a step in the right direction.

As the Rails getting started guide says:

If you learn "The Rails Way" you'll probably discover a tremendous increase in productivity. If you persist in bringing old habits from other languages to your Rails development, and trying to use patterns you learned elsewhere, you may have a less happy experience.

This does become true when, for instance, trying to place the files in custom directories since Rails still expects entry files to exist in certain folders and to be used or when trying to decouple asset bundling completely from the framework. For those wanting more complex setups it is completely possible to get them working but it can lead to a greater effort investment on the developer side and it might mean that some Rails helper methods might have to be set aside in those cases, creating a more decoupled solution.

As with everything, each approach shows advantages and disadvantages so it is very much dependant on the use case which one to go for.

Is going for Devise for user authentication a good choice for a first Rails app or should I write it from scratch?

cristiano — Mon, 25 Jan 2021 21:02:51 +0000

Question

I am writing a Ruby on Rails application and started looking into adding user accounts so I can scope access of different parts of the application.

The Devise documentation recommends that beginners start by setting up their own authentication before using the gem.

Setting up custom authentication logic seems to be okay but what would be the trade-offs? And if I would like to move to Devise after a while would that be challenging or even worth doing?

Would appreciate to hear from more experienced RoR devs. 🙏

Thanks a lot!

What I've learned

Either option is feasible, it seems that going with a custom implementation allows more control over the authentication and authorization aspects of the app. It can a good way of learning about how these features work in general. The cons can be that it can be a complex aspect of the app that needs to be maintained and monitored to make exploits are fixed over time if any.

This is a great guide to get started creating an auth system in Rails:

Authentication and Authorization à la Rails bcrypt

Levi ・ Dec 6 '19 ・ 10 min read

#ruby #rails #security #beginners

Additionally, Chris Oliver's Ruby on Rails for Beginners covers this topic: https://gorails.com/episodes/rails-for-beginners-part-11-creating-the-user-model

Using Devise is an out of the box solution, everything needed for auth is already available including e-mail confirmation and password recovery. Since it's used and maintained by a large number of developers improvements are constantly being made and the gem is kept up to date which can make it more secure to use. On the other hand it can be a black box and its source and features is something that is known over time by using it and reading the code (which is not a bad thing).

A guide for getting started with Devise can be found here: https://github.com/heartcombo/devise#getting-started

Scoping values in JavaScript

cristiano — Sat, 05 Dec 2020 19:23:34 +0000

Scoping is the concept behind how values of variables, functions and other expressions are made available in a program and where they can be accessed from. A good understanding of scope can avoid bugs or unexpected results in a script.

Scope Areas

Scoping can be thought of having three areas, the global scope, a function scope or a block scope.

Global Scope

The global scope is where values that can be accessed anywhere in the script exist and tend to be defined at the top level of your program. For example, if you had a script.js file, the variables and functions defined inside that file would belong to the global scope but anything within a function or a code block (more on this later) would not, for example:

// Available to global scope
const globalScopeVar = 'Can be accessed from anywhere (global scope)';

// Available to global scope
function parentScope() {

  // Not available in the global scope.
  function childScope() {
    return 'child';
  }

  return 'parent';
}

// This variable can be used here since its in the global scope.
globalScopeVar;

// This function may be used since its in the global scope.
parentScope();

// This function does not exist in this scope and would throw an error.
childScope();

In the example above it shows how JavaScript determines what is available to run on the global scope. globalScopeVar and parentScope() are available but childScope() is not because it is nested in a function which makes it bound to another scope.

Nice! Global scoped values may also be called from almost anywhere, even within function and code blocks.

Notice how globalScopeVar can be accessed within parentScope() and childScope():

// Available to global scope
const globalScopeVar = 'Can be accessed from anywhere (global scope)';

// Available to global scope
function parentScope() {

  // Not available in the global scope.
  function childScope() {
    return globalScopeVar;
  }

  return globalScopeVar;
}

// This variable can be used here since its in the global scope.
console.log(globalScopeVar);

// This function may be used since its in the global scope.
console.log(parentScope());

Additionally, can parentScope() be accessed from childScope() like globalScopeVar is? Yes! Because parentScope() if defined at the global scope level:

// Available to global scope
const globalScopeVar = 'Can be accessed from anywhere (global scope)';

// Available to global scope
function parentScope() {
  // Not available in the global scope.
  function childScope() {
    return parentScope();
  }

  console.log(childScope());
}

// This variable can be used here since its in the global scope.
console.log(globalScopeVar);

// This function may be used since its in the global scope.
console.log(parentScope());

This is probably a not so useful example of how functions are applied in practice as it turns parentScope() into a function that calls itself which most likely will lead to a call stack error that looks similar to the output below.

However, it is valid JavaScript and parentScope() can be used by childScope() because it was defined in the global scope.

script.js:8 Uncaught RangeError: Maximum call stack size exceeded
    at childScope (script.js:8)
    at parentScope (script.js:11)
    at childScope (script.js:8)
    at parentScope (script.js:11)
    at childScope (script.js:8)
    at parentScope (script.js:11)
    at childScope (script.js:8)
    at parentScope (script.js:11)
    at childScope (script.js:8)
    at parentScope (script.js:11)

The take away is that global scope values are available almost anywhere in your program. Global variables tend to be avoided as it could lead to bug they can end up changed unintentionally and cause unexpected behavior so the unspoken rule tends to be to avoid using them or using them carefully.

Function Scope

A function scope if determined by the curly brackets { } of its block. Any variables, functions or expressions defined within those blocks won’t be available outside of the block.

On the following example notice how the parentScopeVar is not available outside of the function it was defined in (parentScope()):

// This variable can be accessed from anywhere.
var globalScopeVar = 'Can be accessed from anywhere';

function parentScope() {
  // This variable can only be accessed within this function and its child function and code blocks.
  var parentScopeVar =
    'This variable can only be accessed within this function and its children';
}

parentScopeVar; // Error of undefined! Not defined in this scope

This example will throw an error. Values defined inside the scope of a function are not available outside of its block:

types.js:14 Uncaught ReferenceError: parentScopeVar is not defined
    at types.js:14

Like we have observed in a previous example, values from the global scope or higher scopes can be used inside the function, just not the other way around:

// This variable can be accessed from anywhere.
var globalScopeVar = 'Can be accessed from anywhere';

function parentScope() {
  // This variable can only be accessed within this function and its child function and code blocks.
  var parentScopeVar =
    'This variable can only be accessed within this function and its children';

  return globalScopeVar;
}

parentScope() // Returns 'Can be accessed from anywhere';

Notice how the globalScopeVar is available to be used inside the function block. This can be thought like the globalScopeVar can cross the “gates” (as in curly brackets) and get in parentScope(), becoming available. On the other hand, parentScopeVar can never leave the “gates” of parentScope(), hence why it won’t be able to be accessed anywhere else.

But what if parentScope() had another function nested inside its block? Would parentScopeVar still be available in the that function? Would the function be available in the global scope like parentScope() is?

You might have an idea of what the answer to these questions are, but if not it’s totally okay. Let’s consider the following example:

function parentScope() {
  // This variable can only be accessed within this function and its child function and code blocks.
  var parentScopeVar =
    'This variable can only be accessed within this function and its children';

  // This function is only available to the parentScope. 
  function childScope() {
    parentScopeVar;
  }

  childScope(); // Success! childScope is available within this block.
}

parentScope(); // Success! parentScope is available in the global scope.
childScope(); // Error! childScope is only available at the parentScope.

In the example above we can see how parentScopeVar is available to childScope() but childScope() is only available within the parentScope() block and it cannot be called in the global scope.

The key points are that variables and functions declared within a function are not available outside of its code block. However, they are available to be used inside and other nested function blocks if needed just like all the variables are available to every other code block when defined under the global scope.

Block Scope

The block scope is similar to the function scope in that global scoped values are available to it but it has a key difference. Variables, functions and other expressions defined within these blocks will be available to the scope they’re currently part of and not limited by the curly brackets.

Block scope is talked about when using if, switch, for and other types of code blocks for control flow or iteration. Take a look of an example of a couple of code blocks being used in the global scope and how values defined within the code block can be accessed outside their curly brackets ({ }):

// This variable can be accessed from anywhere.
var globalScopeVar = 'Can be accessed from anywhere';

// Code blocks won't affect the scope of a variable.
if (true) {
  var secondGlobalScopeVar = 'Can be accessed from anywhere';

  globalScopeVar; // Success! It's available in the global scope and can be accessed in the block.
}

// Variables in a loop will still be available and in scope after the loop is done.
for (var index = 0; index < [1,2,3,4,5].length; index++) {
  console.log('Global scoped loop:', index);

  globalScopeVar; // Success! It's available in the global scope and can be accessed in the block.
}

secondGlobalScopeVar; // Success! The if statement block will run and it's available in the global scope.
index; // Success! It's available in the global scope.

In the example above, index and secondGlobalVar can be accessed from outside their blocks. Variables declared with var are not bound to the limits of the blocks.

However, there is a way to scope index and secondGlobalScopeVar to their blocks and keep them from being available in outer scopes by using let and const. Here's the same example using those keywords but more on this topic later:

// This variable can be accessed from anywhere.
let globalScopeVar = 'Can be accessed from anywhere';

// Code blocks won't affect the scope of a variable.
if (true) {
  let secondGlobalScopeVar = 'Can be accessed from anywhere';

  globalScopeVar; // Success! It's available in the global scope and can be accessed in the block.
}

// Variables in a loop will still belong to the scope after the loop is done.
for (let index = 0; index < [1,2,3,4,5].length; index++) {
  console.log('Global scoped loop:', index);

  globalScopeVar; // Success! It's available in the global scope and can be accessed in the block.
}

secondGlobalScopeVar; // Error! This variable is not defined in this scope.
index; // Error! This variable is not defined in this scope.

Defining variables with let and const are a way of scoping them to their code blocks.

Example of scope using var

Now that there's been an introduction to scope, let's have a look at a larger example using var. Try to read it line by line and see how the rules we've described so far apply to this piece of code:

/*
 * How Javascript scope works using var
 */

// This variable can be accessed from anywhere.
var globalScopeVar = 'Can be accessed from anywhere';

function parentScope() {
  // This variable can only be accessed within this function and its child function and code blocks.
  var parentScopeVar =
    'This variable can only be accessed within this function and its children';

  // Global scope variables are available in this function scope.
  console.group('parentScope');
  console.log('parentScope can access globalScopeVar: ', globalScopeVar);
  console.log('parentScope can access parentScopeVar: ', parentScopeVar);
  console.log('parentScope can access secondParentScope (function): ', secondParentScope);
  console.groupEnd('parentScope');

  /* parentScope CANNOT access:
    childScopeVar // undefined in this scope
    secondParentScopeVar // undefined in this scope
  */

  // This function is only available to the parentScope. 
  function childScope() {
    // This variable can only be accessed within this function and its child function and code blocks.
    // Cannot be accessed by parentScope or the globalScope.
    var childScopeVar = 'Only available withing this function scope and its children';

    console.group('childScope');
    // Global scope variables are available in this function scope.
    console.log('childScope can access globalScopeVar: ', globalScopeVar);
    // Can access the variable defined by its parent.
    console.log('childScope can access parentScopeVar: ', parentScopeVar);
    console.log('childScope can access childScopeVar: ', childScopeVar);
    console.groupEnd('childScope');

    /* childScope CANNOT access:
      secondParentScopeVar // undefined in this scope
    */
  }

  // childScope() is only available to the parentScope
  childScope();
}

function secondParentScope() {
  var secondParentScopeVar =
    'This variable can only be accessed within this function and its children';

  console.group('secondParentScope');
  console.log('secondParentScope can access globalScopeVar: ', globalScopeVar);
  console.log('secondParentScope can access secondParentScopeVar: ', secondParentScopeVar);
  console.groupEnd('secondParentScope');

  /* The global scope CANNOT access within this block:
    parentScopeVar; // undefined in this scope
    childScopeVar // undefined in this scope
    childScope() // undefined in this scope
  */
}

// Code blocks won't affect the scope of a variable.
if (true) {
  var secondGlobalScopeVar = 'Can be accessed from anywhere';

  console.log('Global scope can access globalScopeVar (in if code block):', globalScopeVar);

  /* The global scope CANNOT access:
    parentScopeVar; // undefined in this scope
    childScopeVar // undefined in this scope
    childScope() // undefined in this scope
    secondParentScopeVar // undefined in this scope
  */
}

// Variables in a loop will still belong to the scope after the loop is done.
for (var index = 0; index < [1,2,3,4,5].length; index++) {
  console.count('Global scoped loop');
}

// globalScopeVar can be accessed in the global scope with no issues.
console.log('Global scope can access globalScopeVar:', globalScopeVar);
// secondGlobalScopeVar can be accessed in the global scope even though it was defined within a code block.
// If the statement didn't evaluate to true then this variable would be undefined.
console.log('Global scope can access secondGlobalScopeVar:', secondGlobalScopeVar);
// index can be accessed in the global scope even though 
// the loop is done andit was defined within a code block.
console.log('Global scope can access index:', index);

// Running parentScope.
parentScope();
// Running secondParentScope.
secondParentScope();

/* The global scope CANNOT access:
  parentScopeVar; // undefined in this scope
  childScopeVar // undefined in this scope
  childScope() // undefined in this scope
  secondParentScopeVar // undefined in this scope
*/

This example is also available as a Gist in case you would like to read it in your code editor or run it yourself.

How let and const affect scope

On an earlier example we've seen how let and const can scope a variable to its code block (e.g if and for) making it unavailable anywhere else.

The let and const declarations are block scoped. This brings the benefits of not being able to access a value that is part of a different scope which might prevent it from changing unexpectedly.

The use of let and const tends to be preferred to var, here's a breakdown of the differences between them:

var can be updated but not redeclared
let can be updated but not redeclared and is block scoped
const cannot be updated or redeclared and is block scoped

Example of scope using let and const

This is updated example of how this script would work using let and const. Take a minute to compare the two and try to see the difference and stop what variables are not longer available:

/*
 * How Javascript scope works using let and const
 * It is more restrictive as to where values can be accessed within functions and blocks
 */

// This variable can be accessed from anywhere.
const globalScopeVar = 'Can be accessed from anywhere (global scope)';

function parentScope() {
  // This variable can only be accessed within this function and its child function and code blocks.
  let parentScopeVar =
    'This variable can only be accessed within this function and its children';

  // Global scope variables are available in this function scope.
  console.group('parentScope');
  console.log('parentScope can access globalScopeVar: ', globalScopeVar);
  console.log('parentScope can access parentScopeVar: ', parentScopeVar);
  console.log('parentScope can access secondParentScope (function): ', secondParentScope);
  console.groupEnd('parentScope');

  /* parentScope CANNOT access:
    childScopeVar // undefined in this scope
    secondParentScopeVar // undefined in this scope
  */

  // This function is only available to the parentScope. 
  function childScope() {
    // This variable can only be accessed within this function and its child function and code blocks.
    // Cannot be accessed by parentScope or the globalScope.
    const childScopeVar = 'Only available withing this function scope and its children';

    console.group('childScope');
    // Global scope variables are available in this function scope.
    console.log('childScope can access globalScopeVar: ', globalScopeVar);

    // Can access the variable defined by its parent.
    parentScopeVar = 'parentScopeVar was modified within childScope()';
    console.log('childScope can access parentScopeVar: ', parentScopeVar);
    console.log('childScope can access childScopeVar: ', childScopeVar);
    console.groupEnd('childScope');

    /* childScope CANNOT access:
      secondParentScopeVar // undefined in this scope
    */
  }

  // childScope() is only available to the parentScope
  childScope();
}

function secondParentScope() {
  const secondParentScopeVar =
    'This variable can only be accessed within this function and its children';

  console.group('secondParentScope');
  console.log('secondParentScope can access globalScopeVar: ', globalScopeVar);
  console.log('secondParentScope can access secondParentScopeVar: ', secondParentScopeVar);
  console.groupEnd('secondParentScope');

  /* The global scope CANNOT access within this block:
    parentScopeVar; // undefined in this scope
    childScopeVar // undefined in this scope
    childScope() // undefined in this scope
    secondGlobalScopeVar // undefined in this scope
  */
}

// Code blocks won't affect the scope of a variable.
if (true) {
  let secondGlobalScopeVar = 'Can be accessed from this block only';

  console.log('Global scope can access globalScopeVar (in if code block):', globalScopeVar);
  console.log('Only this block can access secondGlobalScopeVar:', secondGlobalScopeVar);

  /* The global scope CANNOT access:
    parentScopeVar; // undefined in this scope
    childScopeVar // undefined in this scope
    childScope() // undefined in this scope
    secondParentScopeVar // undefined in this scope
  */
}

// Variables in a loop will still belong to the scope after the loop is done.
for (let index = 0; index < [1,2,3,4,5].length; index++) {
  console.count('Index may be accessed from this loop only');
}

// globalScopeVar can be accessed in the global scope with no issues.
console.log('Global scope can access globalScopeVar:', globalScopeVar);

// Running parentScope.
parentScope();
// Running secondParentScope.
secondParentScope();

/* The global scope CANNOT access:
  parentScopeVar; // undefined in this scope
  childScopeVar // undefined in this scope
  childScope() // undefined in this scope
  secondParentScopeVar // undefined in this scope
  secondGlobalScopeVar // undefined in this scope
  index // undefined in this scope
*/

This example is also available as a Gist in case you would like to read it in your code editor or run it yourself.

Resources

Introduction to the REST Architecture

cristiano — Tue, 29 Sep 2020 09:44:27 +0000

The Web’s most common interaction is retrieving HTML pages via requests that are identified with URLs so we can access pieces of information. When we enter a URL on our browser, a request is sent to a server which will work out what sort of response to send back, and most of the time it will be HTML that our browser can parse and display so we can read its contents.

However, web applications can do a lot more today than returning HTML to the browsers, they can allow for instance, products, users and other records to be created, we can update posts on our blogs, upload images and delete our tweets.

To account for this amount of complexity , these requests are not limited to retrieve HTML markup but other formats as well. Furthermore, the request can also trigger actions that make changes to the data stored in the server.

The Representational State Transfer (REST) architecture is widely applied in web application development to help in accessing and changing information related to it. The architecture is defined by a set of components and processes that are outlined by a set of constraints.

This article will cover the bare bones of REST, a few important terms and concepts required to understand it and a few examples of how it might be used in practice.

What is REST?

REST is an architecture style, a set of rules that can be applied when creating web services. Its purpose is to define a uniform way of accessing and modifying web resources.

Information that the browser can request is organised in entities (users, carts, posts, pages), each of these returns specific information which can be accessed via URLS.

Requesting information via a URL, or in other words access a resource, can return the information in multiple formats, or commonly referred to as representations.

With each request, the information includes all data required to make subsequent requests to the server without needing it to know about the whole picture of what is happening in the application (also referred to as state) on the browser side. It also tells us what other resources are available and which can be accessed next so we can keep using the application without having to resort to documentation.

Applying the concept of entities and resources as a way to organize, access and modify information has proven to be a useful approach to when developing applications and often seen as an alternative to other methods such as the Simple Object Access Protocol (SOAP).

This summarizes what REST is at a higher level but the architecture itself is composed of several components and constraints, each with a role to help define how a service designed with REST should work. We can now go into a bit more detail on these constraints and see how they relate with the concepts introduced in this section.

HTTP enables the exchange of information

The interactions with these resources occur through the use of the Internet’s Hypertext Transfer Protocol (HTTP). Since it’s an integral part of working with REST, it is important to understand a few parts of HTTP before moving on, let’s start by defining the request response cycle:

The client issues a request to a resource via an URL and the server returns a response. Further complexity is omitted in the diagram to focus on this interaction only.

The client (also known as user agent and could be a browser, a terminal or other software) initiates a request to the server using an URL.

The server then works out which type of request this is by reading it carefully. One of the details we should be aware of is the HTTP method used to make the request. Here’s the ones most commonly used in REST:

GET

Retrieves a representation of a resource. These requests should only retrieve data, without changing the resource at all (no side-effects). e.g Show a list of articles.

POST

This type of request submits information to the server which can cause changes to be made, effectively changing the state of the application. e.g Publish a new article or change the email of an existing user.

DELETE

It’s meant to indicate that the resource should be deleted. e.g Clear a shop cart, remove a user from the system.

These methods allow us and the server to understand what action is to be taken with a resource.

A resource is composed of an entity defined as a noun (e.g posts) and can be accessed as a collection or as an instance. Let’s say we would like to retrieve all posts, we could access a resource that could look like csalmeida.com/posts to request them and get an array posts (a collection) to display on a page for example. How about a specific post (an instance)? In that case the URL could look like csalmeida.com/posts/1. The difference here is that an ID is added to the URL to identify the post we would like to access, the server will make use of it to work out which post to get back to the client.

For example, presuming that we are accessing the URL csalmeida.com/users. The /users part of the URL would be the resource we are trying to get to and when a request gets to the server it will process this request, run any code needed to put a response together and retrieve an HTML page listing a set of users.

The reason we would know some information is being accessed instead of manipulated is by looking at the HTTP method used in the request which in this example is a GET request. The HTTP method used can give us some clues as to what a request intends to do but in reality we don’t know what sort of response we are going to get when the browser tries to access a resource.

Looking at the URL, we might assume it returns a page listing all users on the site, but the server could actually return a completely different kind of information depending on what code runs when this request is made. This means that we cannot assume that because a resource (an URL) is described a certain way that we will get what we expect.

There’s also another aspect that we don’t know about which is the kind of response. Although most of the time it is HTML, it could be other formats such as JSON, XML, plain text and more.

These aspects mentioned in the example are relevant because they help describing some characteristics of REST. Now let’s look at each of the major constraints of the architecture.

The REST Constraints

The set of constraints that define the REST architecture is worth knowing about to understand how to apply it when creating web services based on it.

Uniform Interface

It’s the idea that implementations are separate from the services they provide to promote independent system evolution. For example, the same API could be used by a website and a mobile application at the same time, but these elements could evolve independently. Fielding’s points out that the disadvantage of this approach is that information is accessible in a standardized format instead of it being designed for each context.

To achieve this REST takes a resource based approach to that are identified in requests. For example to access the articles of a site a resource could be /articles and to see the list of available the trains timetables another resource could be /timetables.

The manipulation of resources through representations should be possible. This means that a representation (for instance an HTML document should include all the the data and URLS necessary to perform subsequent actions if available. The actions could include, reading a related document or removing an article. For example, accessing csalmeida.com/articles returns an HTML representation of all the articles available on the site. There’s also a “remove article” link that points to csalmeida/articles/32. This link allows us to remove a specific article with all the information the server needs to perform the action.

This ties with the with the concept of having Hypermedia as the Engine of Application State (HATEOAS) which essentially means that each representation includes everything that is necessary for the user to perform subsequent actions in the application either to navigate to another resource or to makes changes to one. In fact, RESTful API expert Les Hazlewood argues that REST boils down to links and state transitions.

Finally there’s the concept of self-descriptive messages which means that each request itself should include enough information for the server to understand and process it.

Stateless

This concept essentially means that the server should not hold any application state for the current user session. The client holds all the state which means that each request made has the necessary information for the server to handle it.

This helps reducing complexity and resources used by the server since it doesn’t have to track the state of the application for each user, all of it is made available on the user side instead.

Cacheable

Essentially the idea of including metadata that specified whether the information returned but the request is cacheable or not and if so, for how long. If the client has already retrieved a representation of something it will cache it and used the next time its requested instead of asking the server for it again. However, this can lead to stale data or in other words, the cached representation the user is seeing might be out of date when compared with what’s available on the server.

Client-Server

The REST architecture bases itself on a client-server setup. The server holds the data and provides resources to the client. The client on the on the other hand requests theses resources once processed by the server. This creates a separation of concerns where the server handles the data storage and leaves business logic unknown to the client. The client hold the application state for that session and the server is unaware of what that looks like on each request it just provides information and executes actions as the client requests, depending on what actions are available and what the client is permitted to do.

Layered System

This concept defines that an applications might have multiple layers where each layer is only aware of it’s immediate layer, or in other words, the one it needs to interact with. Additionally the client should not be able to tell which one is connecting to along the way.

For example the API could be deployed on server A, and the data stored on server B and requests being authenticated in server C. A request is handled by server A, authenticated by server C and the data is then retrieved by server B, the client only gets it’s requested representation back without ever being aware that this has happened.

Code on demand

An optional aspect of REST, it means that in some cases servers might provide code for the client to execute instead of a representation. This could be for instance a CSS stylesheet of Javascript files.

This summarizes the six constrains that define REST, in summary each constrains encourages a separation of concerns when designing a web service.

A practical example of using a REST API

As most RESTful API’s return JSON we’ll make use of the jsonplaceholder API. This API returns example data out of the box without requiring further steps, let’s try the following URL in the browser:

https://jsonplaceholder.typicode.com/posts

The browser will show a JSON representation of the information we’ve requested, it should look similar to this:

[
  {
    "userId": 1,
    "id": 1,
    "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
    "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
  },
  {
    "userId": 1,
    "id": 2,
    "title": "qui est esse",
    "body": "est rerum tempore vitae\nsequi sint nihil reprehenderit dolor beatae ea dolores neque\nfugiat blanditiis voluptate porro vel nihil molestiae ut reiciendis\nqui aperiam non debitis possimus qui neque nisi nulla"
  },
  {
    "userId": 1,
    "id": 3,
    "title": "ea molestias quasi exercitationem repellat qui ipsa sit aut",
    "body": "et iusto sed quo iure\nvoluptatem occaecati omnis eligendi aut ad\nvoluptatem doloribus vel accusantium quis pariatur\nmolestiae porro eius odio et labore et velit aut"
  },
// ...
]

Each post includes a set of properties, an id, title, body and the author’s ID as userId. Next, let’s access the comments for a post:

https://jsonplaceholder.typicode.com/posts/1/comments

This resource retrieves all comments associated with the post with ID 1:

[
  {
    "postId": 1,
    "id": 1,
    "name": "id labore ex et quam laborum",
    "email": "Eliseo@gardner.biz",
    "body": "laudantium enim quasi est quidem magnam voluptate ipsam eos\ntempora quo necessitatibus\ndolor quam autem quasi\nreiciendis et nam sapiente accusantium"
  },
  {
    "postId": 1,
    "id": 2,
    "name": "quo vero reiciendis velit similique earum",
    "email": "Jayne_Kuhic@sydney.com",
    "body": "est natus enim nihil est dolore omnis voluptatem numquam\net omnis occaecati quod ullam at\nvoluptatem error expedita pariatur\nnihil sint nostrum voluptatem reiciendis et"
  },
//...
]

We can also observe that this API does not adhere to all the constraints, for example, when we retrieved all posts it didn’t provide further available resources to access the comments or the author’s information, which can leave the user or the developer to guess or rely on documentation to understand what other actions are available on that resource.

A way to make it clearer would be to add the paths or even the full URLs to the response as a way to facilitate access of those other resources if needed:

  {
    "userId": 1,
    "id": 1,
    "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
    "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto",
    "links": [
      "https://jsonplaceholder.typicode.com/posts/1/comments",
      "https://jsonplaceholder.typicode.com/posts?userId=1"
    ]
  }

When requesting each resource we are making an HTTP request which makes has a method specified. The method we’ve been using for out requests is GET. However, how do we know which request is being used?

For that we can inspect networks requests using the browser’s Dev Tools. Each browser is slightly different but it should have a Network tab where the request made and it’s properties can be inspected in a bit more detail:

Using the Browser’s available dev tools a request can be inspected further.

This concludes this example but there’s a lot more to explore, different HTTP methods and some API’s may only let a resource be accessed if they pass authentication, try to explore all of these on your own by interacting with the Twitter API for example.

Further observations and considerations

The resources can have dynamically generated responses

This means that the contents of a response can change with each request. For example, on an initial request to csalmeida.com/users, might show a page with three users, however a subsequent request can show two if one if them was removed since.

The format of a response can vary

It’s worth keeping in mind that responses can return information on an array of formats. It could be HTML for the browser to parse or a JSON data object to be consumed somewhere else. The same information can be represented in multiple ways.

A resource is a way to access some information and is identified by an URL used for the server to understand how to respond. The response can be any format, also called a representation such as HTML, JPEG image, JSON, XML and more.

Only the client knows what’s up

The state of the application is stored entirely by the user agent (typically a browser) and each request to the server is sent without the server being aware of what other requests occurred before.

This means that a request must include all the information it needs to perform an action in isolation, whether it’s creating, modifying or accessing a resource.

Understanding an already existing API

When accessing a RESTful API the interaction should be similar to other ones you have interacted with. There are collections and it’s individual instances.

This being said, one step that needs to be often taken is getting to know the database schema. What tables are there? Which columns each table includes and how do they relate to each other?

HTTP has its limitations

Martin Nally points out that HTTP is good for performing Create, Read, Update Delete (CRUD) operations but doesn’t take care of querying or versioning which poses a challenge in designing quality APIs. These topics are something worth exploring as well.

No agreement on format of JSON representations

JavaScript Object Notation is a format that’s commonly provided by a REST API. Despite its popularity, there’s no standardized specification on how this data should be structured which could lead to representations being dramatically different between APIs.

A few experts have developed their own solutions by defining specs that are in tune with their needs and respect the REST architecture, here’s a few:

Not all APIs that call themselves RESTful actually apply the REST architecture as intended

There are a lot of APIs that base themselves in the REST achitecture but violate one or more constraints. In this case, these are not considered truly restful and that’s completely fine but it’s worth mentioning since many APIs available for use that follow some of the rules of REST might not actually adhere to others.

Why is it worth knowing about REST?

The use of the REST architecture or modified versions of it (RESTful APIS) are widely used across many applications today. Frameworks such as Laravel, Ruby on Rails and Sails make use of it and abstract a lot of the complexity it has so developers can make use of it to streamline the development process and increase project maintainability.

One other emerging pattern that has seen increased use to design APIs is GraphQL which allows to get access to many resources in a single request. This approach tries to solve the limitations REST presents when it’s needed to quickly adapt to requirements on the client-side.

Can someone experienced in writing tests expand on the mental models of unit tests?

cristiano — Mon, 10 Aug 2020 11:45:31 +0000

Hey all, recently I've been trying to introduce tests to an app I'm working on in Rails 6 which uses MiniTest.

After going through a few guides I was still struggling and I think it's not because or the syntax of the methods available for testing but because I don't quite get the reasoning behind figuring out what to test and what is the best to way to do it.

Could someone give me an example of their thinking when they need to write tests for a method/something else? I would be very grateful! 🙇🏻‍♂️

How to setup a Ruby on Rails 7 project

cristiano — Sat, 08 Aug 2020 07:17:47 +0000

Cover image photo by Daniel Abadia

Ruby on Rails is a framework that includes a lot of tools to structure and develop dynamic web applications.

Rails is a good choice to create an application where a database is required to store information and provides functionality to display, change, remove data and add more as needed.

For example, it could be an app where users register and can write their thoughts for others to see as posts. Users can follow each other and like posts. This would require data to be stored and accessed as users need it, and relationships between data need to be built, Rails responds well to these requirements.

Although Rails can also be used to create static HTML pages, it is probably best to make use of a static generator for that purpose instead.

Hopefully this guide will give you an overview of how to setup a project with Rails 7.0 to the point of where you will be able to see this screen:

Before we begin

A couple of things are required to go through this guide. ails requires a few tools to be installed before a project can be created. This includes the Ruby programming language, Node, Yarn and a relational database management system. The RDBMS can be either MySQL, PosgreSQL or SQLite, this guide uses PostgreSQL but it shouldn’t make much difference to use one of your choice.

If you need to get these things setup, follow the official Rails guide on how to get started. The guide includes a lot of the things being covered here but it doesn’t include other important details that have tripped me up when setting up a project and might not be that obvious to someone new to Rails.

Finally some knowledge of how to access and run commands on the terminal is required.

Once everything is installed you can check if Rails is good to go by running this command in your terminal:

rails --version

Create a new Rails project

The first step to get started with Rails is to create a new project. This is done using a Rails command in the terminal. Navigate to a folder where you keep your projects and create a new Rails app:

cd ~/Projects
rails new rails-introduction-app -d postgresql

Let’s go through what each command does one by one.

The first command changes directory into a folder named Projects, this is where I would like this app to be created at.

The second command creates a new Rails app inside a folder called rails-introduction-app, the name can be named anything but it tends to be named lowercase separated with dashes. An optional -d flag is provided followed by a database management system name, this is how we can let Rails know which database adapter we are using, being postgresql in this case.

# other output above...
├─ y18n@4.0.0
├─ yargs-parser@13.1.2
└─ yargs@13.3.2
✨  Done in 9.49s.
Webpacker successfully installed 🎉 🍰

A lot of output will print in the terminal, eventually a new Rails app will be generated in the folder along with a lot of files, let’s have a look:

cd rails-introduction-app
ls

The first command enters the directory of the app, the second lists the files inside that folder, can you see them? There’s a lot of them, but don’t worry we are only editing one of them in this guide.

Configuring the database

In this step we will connect Rails with PostgreSQL, aside from how a database is created, everything else should be the same.

If you’re using a RDBMS other than PostgreSQL, the step of creating a database is still required.

Rails makes use of a database to store application data. In version 7.0, one is required from the start, in this case at least the development database needs to be in place but Rails makes use of three databases; development, production, and test.

Let’s setup all three of them by logging in to postgres, creating the three databases, each prefixed with the name of the project separated by underscores and creating and granting a user rights to access it. Remember this user’s password since it will be needed later:

# Log in to PostgreSQL, in my case the username is postgres
# but might be different in your case
sudo -u postgres psql

# Once signed in create three databases
create database rails_introduction_app_development;
create database rails_introduction_app_production;
create database rails_introduction_app_test;

# Creating a new user, this will be used for Rails to gain access to each database
create user yournewuser with encrypted password 'yoursecretpassword';

# Grant priviledges for the newly created user to manage these databases
grant all privileges on database rails_introduction_app_development to yournewuser;
grant all privileges on database rails_introduction_app_production to yournewuser;
grant all privileges on database rails_introduction_app_test to yournewuser;

To check if the databases and the user have been created, run the following commands whilst in postgres:

# Lists users
\du

# Lists all databases (it is a lowercase L)
\l

Everything good so far? I hope so but please feel free to get in touch if you get stuck! With the necessary databases created we can now let Rails know how to access them.

Open the app folder (/rails-introduction-app) in your favourite text editor and open /config/database.yml.

This file includes a lot of comments but here is what we are interested in:

default: &default
  adapter: postgresql
  encoding: unicode
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

development:
  <<: *default
  database: rails_introduction_app_development

test:
  <<: *default
  database: rails_introduction_app_test

production:
  <<: *default
  database: rails_introduction_app_production
  username: rails_introduction_app
  password: <%= ENV['RAILS_INTRODUCTION_APP_DATABASE_PASSWORD'] %>

In the first block, there are a few defaults setup, such as which database adapter Rails is going to use to interact with the databases. All other blocks inherit what is set on this block so we can add our username and password here for now:

default: &default
  adapter: postgresql
  encoding: unicode
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  username: yournewuser
  password: yoursecretpassword

Now notice how there’s three blocks, why is that? It is because Rails has three environments that it makes use of, development is the one running on our machine, production is the one everyone gets to use and test is used to run tests that make sure our code does what is supposed to do.

Also notice that the database for each environment matches the database names of the ones we created earlier and the adapter is already set to postgres but the Rails default is sqlite. How?

When creating the app we specified a database adapter with -d postgres. This was taken into account when creating the database.yml file so that value was pre-populated for us.

As for the database names, Rails assumes that’s how they're going to be named, first the name of the app followed by the environment, all lowercase and words separated by underscores.

Saving your file concludes all initial configuration steps of the app. Rails should now have everything it needs to run.

Running and viewing your app

To start the app run the following command in the terminal:

rails server

This will start the Puma web server, the one used by Rails during development. If ran successfully it should look something like this:

=> Booting Puma
=> Rails 7.0.0 application starting in development
=> Run `rails server --help` for more startup options
Puma starting in single mode...
* Version 4.3.5 (ruby 2.7.1-p83), codename: Mysterious Traveller
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://127.0.0.1:3000
* Listening on tcp://[::1]:3000
Use Ctrl-C to stop

To view the app initial screen open the browser and type http://localhost:3000, this is the address where the Rails app can be accessed during development stages.

Provided all went as planned, the Rails’ start page should render:

Conclusion

This is how to setup a new project running on Ruby on Rails version 7.0. From this point next steps could be adding views and controllers to add functionality to the app, I’ll try and cover this in a next post but in the meantime the Rails getting started guide is a good starting point. Thank you for reading this post! 🙏

.COM might be costing more from 2020

cristiano — Tue, 11 Feb 2020 10:24:41 +0000

Prices for acquiring and renewing .COM domains may rise from this year onwards so I thought I might put a short article together on what is happening and how you can minimise impact on your domains.

The measure is likely to be put in place after amendments were proposed to the .COM Registry Agreement and according to the document ICANN and VeriSign were the only two parties that took part of negotiations.

Something similar has happened before with the removal of price caps for .org domains last year. The price cap had been in place since 1999 for .COM and .NET domains too.

How does it impact .com domains?

These amendments could mean that, within 10 years, .COM domains could cost around 70% more than the current wholesale price.

VeriSign will be able to increase domain prices up to 7% each year for three years with a two year freeze in between every three year period.

It is unsure yet how clear these costs could impact domain owners but “it is likely that most of these increases will be paid by domain name registrants”, Namecheap states in an article on the subject.

What can we do to mitigate these changes?

You could extend your .COM domains to up to 10 years before prices increase as the amendments will have a six month notice period before changes can be made.

Finally, you could leave a comment with your thoughts on the proposed changes on ICANN until the 14th of Feb 2020 or discuss the subject on social media (@ICANN on Twitter).

Why do recruiters ask for current salary?

cristiano — Tue, 16 Apr 2019 17:06:32 +0000

I've recently had an interview where the recruiter kept pressuring me to tell her what my current salary was while at the same time being hesitant in saying what they were offering (which was on their advert anyway).

I thought this was irrelevant to the interview so I preferred not to share but I keep wondering what is the reason behind this question. Is it something harmless or is there a specific purpose to it? Would appreciate the thoughts of anyone who know about this. 🙇🏻‍♂️