Stateless CodeIn one of our videos in the NerdDice.com series, we fixed our CONTRIBUTING.md file to use relative links instead of absolute links and added this item to the NerdDice backlog because there was a similar issue here.
In most cases (with the exception we note below about the CHANGELOG), you want to use relative links in your repository's GitHub Markdown files. That way when you are on a branch working on something, the links will resolve to the file on that branch instead of always pointing back to the master branch.
In our case, there's only one bad link to be fixed. When our build runs on the push, it succeeds, but the benchmark fails on the pull request. Since none of the code related to that benchmark script or any application code changed, we demonstrate how to re-run the failed build to get it passing.
This video covers: 00:00:12 Introduction 00:01:50 Review a similar example commit in the NerdDice.com application with relative links 00:02:18 Demonstrate absolute link to be corrected 00:02:47 Explain reasoning for keeping changelog_uri in gemspec an absolute link to master and plans for CHANGELOG on legacy branches. 00:03:40 Check out a new branch and demonstrate use of GitHub markdown editor and preview 00:05:08 Make the edit to use a relative link 00:05:49 Commit and push the change 00:06:52 Open pull request 00:07:27 Benchmark build fails on pull request, but not push. Re-run failed build and it passes. 00:08:20 Merge and close issue
See other related StatelessCode videos: - Flesh Out the README for the Project youtu.be/EQioYZAWvGU
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.
Create a RubyGem 90: Fix README to Use Relative Links Instead of Absolute LinksStateless Code2023-02-14 | In one of our videos in the NerdDice.com series, we fixed our CONTRIBUTING.md file to use relative links instead of absolute links and added this item to the NerdDice backlog because there was a similar issue here.
In most cases (with the exception we note below about the CHANGELOG), you want to use relative links in your repository's GitHub Markdown files. That way when you are on a branch working on something, the links will resolve to the file on that branch instead of always pointing back to the master branch.
In our case, there's only one bad link to be fixed. When our build runs on the push, it succeeds, but the benchmark fails on the pull request. Since none of the code related to that benchmark script or any application code changed, we demonstrate how to re-run the failed build to get it passing.
This video covers: 00:00:12 Introduction 00:01:50 Review a similar example commit in the NerdDice.com application with relative links 00:02:18 Demonstrate absolute link to be corrected 00:02:47 Explain reasoning for keeping changelog_uri in gemspec an absolute link to master and plans for CHANGELOG on legacy branches. 00:03:40 Check out a new branch and demonstrate use of GitHub markdown editor and preview 00:05:08 Make the edit to use a relative link 00:05:49 Commit and push the change 00:06:52 Open pull request 00:07:27 Benchmark build fails on pull request, but not push. Re-run failed build and it passes. 00:08:20 Merge and close issue
See other related StatelessCode videos: - Flesh Out the README for the Project youtu.be/EQioYZAWvGU
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Install Ruby and Rails with Databases on Ubuntu 24.04Stateless Code2024-07-05 | In this video we take a fresh installation of Ubuntu 24.04 (see the link to the video where we installed it below) and set it up so we can develop applications using Ruby on Rails.
Before we can install Ruby, we first need to install some dependencies onto our system. There have been some slight changes to the set of dependencies since the last Ruby install video we made in 2021 using Ubuntu 20.04. In particular, libgconf-2-4 is no longer needed (and the install will error out if you try to include it in the list of packages).
We use Ruby Version Manager (RVM) to install Ruby. Pay attention to the post install configuration steps and do a full system reboot. In the aforementioned 2021 video, it didn't go smoothly.
We install the current versions of Ruby (3.3.3) and Ruby on Rails (7.1.3.4) at the time of the recording. There are 3 primary database adapters for Rails. SQLite3 comes built-in as the default and is what you get if you run `rails new` without specifying a database. Rails also comes with a MySQL adapter and a PostgreSQL adapter. We create initial applications for each. If you have a particular database in mind, you can skip to that section of the video.
Here are (most of) the commands we execute in the video: ``` # install dependencies sudo apt install -y autoconf bison build-essential curl g++ gcc git git-core libffi-dev libgdbm-dev libncurses-dev libreadline-dev libsqlite3-dev libssl-dev libxi6 libyaml-dev make sqlite3 xvfb zip zlib1g-dev libxml2-dev libxslt1-dev libcurl4-openssl-dev software-properties-common gnupg2
# optional dependencies if using ActionText and/or ActiveStorage sudo apt install -y libvips-tools libvips-dev libvips42
This video covers: 00:00:00 Introduction 00:02:38 Install dependencies for Ruby and Rails (see command above) 00:05:06 Install optional dependencies for ActionText and ActiveStorage 00:05:35 Install Ruby Version Manager (RVM) via Personal Package Archive (PPA) 00:07:45 RVM post-install configuration and reboot machine 00:10:34 Install current version of Ruby (3.3.3 at time of recording) 00:12:59 Install Ruby on Rails version 7.1.x 00:15:09 Create a Rails app and start the server (using SQLite3) 00:18:17 Optional: Install MariaDB and create a Rails app with the MySQL adapter and configure 00:26:20 Optional: Install PostgreSQL and create a Rails app with the PostgreSQL adapter
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Set up a Salesforce Development Environment on Ubuntu 24.04Stateless Code2024-06-01 | In this video, we guide you through setting up a Salesforce development environment on a new install of Ubuntu 24.04. The only things we have installed so far are Visual Studio Code, bzip2 and tar. We have other recent videos linked where we install Node.js (via NVM), VS Code, and Git, so we breeze through those steps quickly in this video.We start by installing Node. Then we install the Java 17 OpenJDK (and save the directory from the installation output so we can set it in the VS Code settings later.) After that we install Git.For the Salesforce CLI, I always use the "install via NPM" option, irrespective of which operating system I use. I find it to be easier to maintain and upgrade. After the CLI is installed, we install the Salesforce Extension Pack (including the expanded version). After the extension pack is installed we can set the Salesforcedx-vscode-apex Java: Home value in VS Code settings.We authorize our DevHub (a TrailHead developer edition) and create a scratch org and make it our default org with `sf config set`.When we try the `sf org open` command, it fails. Salesforce CLI assumes that the temporary directory being used is the system temporary directory. Ubuntu 24.04 has Firefox installed using snap. Snap sandboxing places the temp directory in the user's home directory instead. There are two ways to resolve this. You can execute `TMPDIR="$HOME/temp" sf org open [your-flags]` every time you run the sf org open command. This is tedious. The other option is that you can install a browser via apt instead of snap. Unfortunately Chromium will not work for this because the apt install uses snap. To resolve it, we install Chrome and make it the default browser. There's a privacy trade-off here. Make the decision that's best for you.After we have the ability to open our scratch org, we create a "Hello World! Taxation is theft!" Lightning Web Component with a simple Jest test. We run npm install on the SFDX project directory so that we can run our JavaScript tests and everything.Finally we deploy the component to our scratch org, create a Lightning page with a few different instances of it, and retrieve everything back to our project.This video covers:00:00:00 Introduction00:01:38 Install Node 20 (requires curl and NVM)00:03:19 Install Java 17 OpenJDK and copy the Java Home directory from the output00:05:21 Install Git and Salesforce CLI NPM package00:07:57 Install Salesforce Extension Pack (including Expanded) and configure Salesforce Java Home setting in VS Code00:11:47 Use Salesforce CLI to login to DevHub00:14:12 Create a scratch org00:18:20 Workaround issue to get `sf org open` to work, option 1 adding TMPDIR variable to beginning of command00:21:45 Alternative workaround, install Chrome via apt and set as default browser00:29:13 Create a "Hello World! Taxation is theft!" Lightning Web Component and ensure Jest test framework works00:36:35 Deploy the component to the scratch org, add to a Lightning Page, and retrieve the whole project back00:40:37 Conclusion and preview of other upcoming Salesforce material#setup #configuration #install #linux #ubuntu #debian #deb #terminal #ubuntu24 #lts #github #code #visualstudiocode #vscode #apt #git #node #nodejs #nvm #npm #java #jdk #openjdk #salesforce #sfdx #salesforcecli #workaround #scratchorg #helloworldtaxationistheft #jest #lightningwebcomponent #lwcSee other related StatelessCode videos:- Install Ubuntu 24.04 LTS Desktop youtu.be/yHxuNUovS20- Install Node.js (versions 18, 20, 22) with NVM on Ubuntu 24.04 youtu.be/YyEf1QWfg9Y- Install Visual Studio Code on Ubuntu 24.04 youtu.be/GdmHY1JhLI8- Install Git on Ubuntu 24.04 and Configure for Verified Commits in GitHub youtu.be/CagiEjuqKxU- Migrate from SFDX CLI version 7.x to Salesforce CLI version 2.x youtu.be/kyii2tPwcBI- Codecast: Install Salesforce DX on Ubuntu 20.04 (from 2021) youtu.be/JaVf4FYcYw0Resources that we relied upon for this solution:- Lightning Web Components Developer Guide: Develop with Salesforce DX Tools developer.salesforce.com/docs/platform/lwc/guide/get-started-sfdx.html- Salesforce CLI Setup Guide developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm- Node.js package manager instructions (you can choose your OS and preferred method) nodejs.org/en/download/package-manager - Salesforce CLI Command Reference developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_unified.htm- sf org open GitHub issue on forcedotcom/cli repo github.com/forcedotcom/cli/issues/2769- Command line workaround by setting TMPDIR variable github.com/salesforcecli/plugin-org/pull/992#issuecomment-2013234183
This video is CC0 - No rights reserved. All code is released under the UNLICENSE.Install Git on Ubuntu 24.04 and Configure for Verified Commits in GitHubStateless Code2024-05-25 | Git is an open source distributed version control system that is the most widely used by software developers today. Its decentralized nature makes it essentially censorship-proof and very robust against accidental deletion or permanent loss of work. Even if somebody accidentally deletes the remote repository entirely, each member of the team has a full version of the project and can just create another one.
In this video, we install Git on a mostly fresh copy of Ubuntu 24.04 (with Visual Studio Code installed). Because we want to use Git with GitHub and get that sweet-sweet Verified tag on our commits, we install git along with the dependencies needed for git-credential-libsecret:
`sudo apt install make gcc git libsecret-1-0 libsecret-1-dev libglib2.0-dev`
After installing Git, we do some basic global configuration, (including enabling rerere, you'll thank me later), create a GPG signing key, upload that signing key to GitHub, and create a GitHub access token with repo access.
We use git-credential-libsecret to improve security so we don't have the access token stored in plain text somewhere on the hard drive.
This video covers: 00:00:00 Introduction and overview of Git 00:03:41 Install Git along with libsecret dependencies 00:04:53 Post install verification and initial global config setup 00:07:50 Create a basic local repo to make sure local committing works 00:10:40 Set up GPG key so commits can be signed. 00:16:04 Add the GPG key to the GitHub account 00:18:11 Configure git-credential-libsecret as the credential helper 00:19:56 Generate a GitHub access token 00:22:33 Clone a remote repo and create a commit on a throwaway branch to test the token and signature 00:25:20 Copy the generated access token and use it to authenticate when pushing 00:26:11 Look in GitHub to ensure the commit shows as verified and then remove the throwaway branch from the remote. 00:27:43 Review the option to always sign commits `git config [--global] commit.gpgsign true` 00:29:14 Closing comments
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Install Visual Studio Code on Ubuntu 24.04Stateless Code2024-05-23 | Visual Studio Code is the most popular free text editor used for software development today. It is a freeware (not open source) offering from Microsoft available on all major operating systems.
In this video we install VS Code on the newly released Ubuntu 24.04. We use the Debian (.deb) package and aptitude to install it. You can also use snap on Ubuntu. We used that method in a 2021 video where we installed VS Code on Ubuntu 20.04.
We take a look at some of the documentation, including a series of introductory videos that help you get started. After installing we launch the editor, open a folder, install some extensions, and modify settings and preferences.
This video covers: 00:00:00 Introduction 00:01:19 Discuss 2021 video and note that we will use apt instead of snap for this video 00:01:40 Download the Debian package and kick off install in terminal using apt 00:02:37 Take a look at the repo we will open in VS Code after it installs 00:03:09 Launch Visual Studio Code, open a folder, review the Getting Started page 00:05:08 Install some extensions for a few languages 00:06:49 Make some changes to preferences and settings 00:09:01 Close and re-launch after installing extensions, show the integrated terminal 00:11:06 Other videos to look out for
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Install Node.js (versions 18, 20, 22) with NVM on Ubuntu 24.04Stateless Code2024-05-21 | Due to its integration with browsers since the advent of the World Wide Web, JavaScript has been used on the vast majority of websites created. Node.js is an asynchronous event-driven JavaScript runtime that can be used for creating executable scripts, building web servers, or doing just about anything else you would want to do with a programming language.
In this video, we use a tool called Node Version Manager (NVM) to install three different versions of Node.js on a freshly installed Ubuntu 24.04 Linux operating system. In order to install NVM, we first need to install curl, a command-line tool for making network requests across a variety of protocols, including HTTP(S).
This video covers: 00:00:00 Introduction 00:01:01 Why use NVM? 00:01:45 Take a quick tour of the NVM GitHub repo README 00:02:03 Try to execute NVM install command in terminal. Curl not installed. Install that first 00:02:52 Hit the up key twice in the terminal to retry the previous install command. It now succeeds. Close and reopen the terminal. Check install by running `nvm -v` 00:03:34 Review the support schedule of Node.js (as-of May 2024) 00:04:22 Install node 18. (As the first version installed, this becomes the default.) 00:04:43 Install node 20. 00:05:13 Install node 22 00:05:24 Demonstrate how 18 is the default version 00:06:06 How to use `nvm use` to switch between versions 00:06:25 Make node 20 the default version with `nvm alias default 20` 00:06:59 What's next?
See other related StatelessCode videos: - Codecast: Install NodeJS 14 Ubuntu 20.04 (2021) youtu.be/6IKHyNgS1x0 - Codecast: Install NVM and Yarn in Ubuntu 20.04 (2021) youtu.be/6IKHyNgS1x0
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Install Ubuntu 24.04 LTS DesktopStateless Code2024-05-17 | Ubuntu is a popular open source operating system derived from Debian built upon the Linux kernel. Ubuntu has Desktop, Server, and Core edtions. Every two years Ubuntu releases a Long Term Support (LTS) release. As of the publishing the video, the most recent release is from April 2024 (24.04).
In this video we guide you through choosing an Ubuntu "flavour", how to create a bootable USB, how to set up VirtualBox for installing, and then the installation itself from the booted ISO/USB.
The install process is essentially the same regardless of whether you are using a USB on hardware or a virtual machine.
After installing, we boot from the installed version, check for updates, and then install the VirtualBox guest additions (VirtualBox only).
This video covers: 00:00:00 Introduction 00:02:00 Quick overview of the Ubuntu flavours page 00:03:12 Download the "vanilla" version of Ubuntu desktop 00:03:53 Option 1: Use balenaEtcher to create a bootable USB 00:06:44 Option 2: Setup VirtualBox to install for a virtual machine 00:09:53 Boot from the ISO 00:10:56 Navigate through the install wizard and select various configuration options 00:18:42 Hit the Install button. (Fast-forward through the install process) 00:20:23 Post install, click the Restart now button to shut down the ISO booted session and ensure installation medium is removed 00:23:52 Boot the installed version of Ubuntu 24.04 from the hard drive and login to the created user 00:27:07 Search for and install new updates on the system 00:28:26 Optional: Install VirtualBox Guest Additions for virtual machine (along with prerequisites bzip2 and tar) 00:30:52 Reboot one last time. Now able to run full screen in VirtualBox
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Install balenaEtcher on Ubuntu 22.04Stateless Code2024-05-13 | balenaEtcher is a tool for flashing SD cards or USB drives to make them bootable. Canonical recommends balenaEtcher for creating a bootable USB in its tutorial for installing Ubuntu (which we will do in our next video) because it runs on Linux, Windows, and Mac OS. The installers for Windows and Mac OS are fairly self-explanatory, so we don't cover them in a video.
Linux is a bit more involved, as you either need to either download an AppImage or a Debian package. We go to balenaEtcher's GitHub page and get the .deb package for the latest stable release (1.18.11 at the time this video was recorded.)
After downloading we are able to install it with apt. (Command below from the directory containing the downloaded file):
To launch, we hit the Super Key and start typing balenaEtcher. It comes up as an installed program, and we are up and running.
This video covers: 00:00:00 Introduction 00:01:38 Click the Download Etcher button and review options 00:02:19 Visit the GitHub page for balenaEtcher and download the .deb file for the latest release 00:03:28 Install the .deb file from the terminal using apt 00:04:07 Launch and run the program 00:04:39 Conclusion 00:05:31 Blooper reel
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Install VirtualBox 7 on Ubuntu, Windows, and Intel MacStateless Code2024-05-05 | In this video, we install VirtualBox, a virtualization solution from Oracle that allows you to run a virtual machine (the guest) from your main operating system (the host). This can be useful for trying out other operating systems to evaluate them before you implement a more permanent solution like dual booting.
In the video, we take a bit of a Choose Your Own Adventure route where we install on three different platforms. You can click on the video chapter below to pick the OS relevant to you and then skip forward to 00:16:11 where we review the configuration options.
After installing, we import a (very) old VirtualBox hard drive and configure it. After we boot it up, we insert the VirtualBox Guest Additions image and install the newest version of the guest additions. After rebooting we can run our virtual machine full screen.
This video covers: 00:00:00 Introduction 00:02:11 Choose a scenario, kupo! 00:02:47 Install on Ubuntu 22.04 00:07:52 Install on Windows 10 00:11:55 Install on Intel Mac running MacOS Sonoma (14.x) 00:16:11 Review configuration options and basics of interface 00:18:48 Set up a new Virtual Machine and import an existing VirtualBox hard drive file 00:23:41 Boot the virtual machine and install VirtualBox Guest Additions 00:26:02 Restart the system for the new Guest Additions to take effect. Now machine can run full-screen
Resources that we relied upon for this solution: - VirtualBox site virtualbox.org
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Upgrade Sublime Text from Version 3 to 4 on UbuntuStateless Code2024-04-26 | Back in 2021, we had a video for installing Sublime Text 3 on Ubuntu. In that video, we inadvertently installed version 4 and had to back it out to install the right version. Now Mike has a license upgrade from 3 to 4 and we're going to do the upgrade on Ubuntu.
In order to do this, we install the Sublime GPG key and add the Linux Package Manager Repository to the list of sources, and then the normal commands apt update and apt full-upgrade get us upgraded.
In this case there is one Package Control package (TypeScript) that is not compatible with Sublime 4. It's not a deal-breaker for Mike and he finds and installs a replacement.
This video covers: 00:00:00 Introduction 00:02:00 Set update_check to true on Sublime User settings and relaunch to demonstrate behavior 00:03:02 Remove old license from Sublime 3 and enter Sublime 4 license 00:04:11 Follow instructions for Linux Package Manager Repository to Sublime 4 00:05:38 Run apt update to update package registry. Sublime shows as upgradable. 00:06:20 Run apt full-upgrade to update packages (including Sublime) 00:07:24 Launch Sublime and see what happens. Announces incompatible Package Control package (TypeScript) 00:08:26 Review changelog and confirm correct version and registration info 00:09:48 Find an install a replacement for outdated package in Package Control 00:10:35 Conclusion
See other related StatelessCode videos: - Codecast: Install Sublime Text 3 on Ubuntu
Resources that we relied upon for this solution: - Sublime Text Downloads page: sublimetext.com/download
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a RubyGem 103: Winter 2024 Maintenance Part 2 - Update Certs and Release Version 0.5.1Stateless Code2024-04-17 | In this video, we complete the periodic maintenance of our gem that we started in the previous episode. We generate a new gem certificate, as we've done most recently in Episode 98. Back when we did that, the process was noted in the commit message so we can refer back to it in this video.
We replace the gem certificate by copying the old one to an archive directory and using the `gem cert --build` command and do a dry run from the feature branch. (The feature branch, checked out off of master has a version of 0.6.0, which is different than the 0.5.1 that we will eventually release.) We uninstall the dry run version of the gem after building it.
When it comes time to build the gem off of version-0-5-x-stable, Mike makes a mistake in cherry-picking the commit from the previous video off of the feature branch. The version defined in your gemspec needs to match that of the Gemfile.lock or the `bundle install` command. After reverting a couple of commits, we fix the Gemfile.lock and the build succeeds. We build the gem version we intend to release and successfully push it to RubyGems.
After that, we take care of some documentation by updating the CHANGELOG and security policy on the feature branch. Then it's time to generate the checksums for 0.5.1, but uh-oh. Mike deleted the .gem file. Thankfully we can download the file back down from RubyGems. We get our changes into GitHub, tag the commit that was built for version 0.5.1, take care of our pull request to merge the feature branch into master, and close the issue.
This video covers: 00:00:00 Introduction, review of previous video, and plan for the video. 00:01:33 Review commit message from last certificate replacement with instructions 00:02:27 Move the old gem certs into the old_gem_certs directory 00:03:13 Generate the new cert 00:04:15 Copy the gem-public_cert.pem to the gem certs/ directory, rename it and trust it 00:05:36 Do a dry run gem build to ensure the gem can install with HighSecurity. Uninstall the test version. 00:08:05 Commit and push the changed certificate to the feature branch 00:10:34 Bump the version on version-0-5-x-stable and cherry-pick the commits from the feature branch, reconciling conflicts (incorrectly) 00:14:39 Fix the build failure: Reset the branch to the commit before the cherry-picks. Issue was un-buildable Gemfile.lock. Force-push to branch. 00:18:40 Build version 0.5.1 of the gem and release it to RubyGems. 00:20:55 Install the released version of the gem from RubyGems with high security 00:21:37 Bump the working version of the version-0-5-x-stable branch to 0.5.2 00:23:45 Switch back to the feature branch and update the CHANGELOG 00:27:37 Update the security policy to indicate that the old versions of the gem are no longer supported 00:29:04 Commit the changes to the CHANGELOG and security policy 00:30:16 Generate checksums and publish last commit to the feature branch. (Re-download the pushed version of the gem from RubyGems because I deleted it) 00:34:21 Checkout the commit of the 0.5.1 release, tag it, and push the tag 00:36:37 Open pull request from feature branch into master 00:39:20 Create GitHub release for 0.5.1 off of the tag 00:40:44 Merge pull request into master, close the issue, and delete the feature branch
See other related StatelessCode videos: - Create a RubyGem 06: Release the Gem! youtu.be/4ihGTcy9jtI - Create a RubyGem 09: Fix RuboCop issues and release a patch version youtu.be/2tw6ozMgTpQ - Create a RubyGem 23: Release version 0.2.0 of the gem youtu.be/uzI-xQin2-A - Create a RubyGem 61: Release 0.3.0! youtu.be/EZyDlHW4MvU - Create a RubyGem 85: Release Version 0.4.0! youtu.be/b4CMUgfycZs - Create a RubyGem 98: Replace the Expired Gem Certificate youtu.be/TP1cReJgSro - Create a RubyGem 99: Backport Changes to Other Stable Branches and Update the CHANGELOG youtu.be/rn5dOzQyMos - Create a RubyGem 100: Release Patch Versions and New Minor Version (0.5.0) of the Gem youtu.be/VLbGtZoDubg
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a RubyGem 102: Winter 2024 Maintenance Part 1 - Update Bundle and Fix Rubocop ViolationsStateless Code2024-04-04 | It's time for another round of periodic maintenance activities for the gem. In this video, we install Ruby 3.3 on the local machine and check its compatibility with the current state of the Gem.
The version of RuboCop we have installed errors out when we try to run it. Since we plan on updating all of the dependencies anyway, we do that next and see if that resolves the issue. RuboCop runs after the `bundle update`, but it introduces some new violations.
Most of them are auto-correctable and are related to replacing additional parameters like `*args, **kwargs, &block` with the more succinct `...` or using string interpolation for symbols when passing arguments to the :send method.
The first non-auto-correctable one is a new cop called Gemspec/DevelopmentDependencies. It has a default enforced style of wanting you to put your development dependencies in your Gemfile instead of your gemspec. For now, we decide to leave the development dependencies in the gemspec and make that the enforced style.
The second group of new violations we need to correct are RSpec/IndexedLet. This cop discourages you from using variables like :die1, :die2, :die3, :die4 in RSpec let declarations. This is a good practice and we set about providing more meaningful names for the violations.
Once the RuboCop violations are cleaned up and we double-check the specs are still passing, we add Ruby 3.3 to the GitHub Actions for the gem, commit, and push to GitHub.
With the new RuboCop violations the maintenance was too much to tackle in a single video. We'll finish up in the next one.
This video covers: 00:00:00 Introduction 00:02:05 Install Ruby 3.3.0 on the local machine 00:03:40 Install the bundle and try to run RuboCop and RSpec. RuboCop errors out in 3.3. 00:04:57 Look for newer versions of dependencies on RubyGems.org and update the versions in the Gemspec and update the bundle 00:09:17 Try to run RuboCop again. It executes with new violations. Autocorrect the auto-correctable ones and see if the changes are acceptable 00:12:32 Review the remaining RuboCop violations 00:13:13 Review the Gemspec/DevelopmentDependencies violations. Resolve by using EnforcedStyle: gemspec in .rubocop.yml 00:16:10 Resolve RSpec/IndexedLet by having more descriptive let variable names 00:21:38 Add Ruby 3.3 to GitHub Actions 00:22:51 Commit and push the changes. Review remaining items to do. Ensure the build succeeds.
See other related StatelessCode videos: - Create a RubyGem 09: Fix RuboCop issues and release a patch version youtu.be/2tw6ozMgTpQ - Create a RubyGem 89: Add Ruby 3.2 to GitHub Actions and Update RSpec to a compatible version youtu.be/kid7Cc2dzRk - Create a RubyGem 93: Refactor RuboCop to Enable New Cops by Default for the Gem youtu.be/wyZTKXMx8lg - Create a RubyGem 97: Update Bundle Before Performing Releases youtu.be/1hVpwRL3B98
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Install Windows Subsystem for Linux 2 (WSL2) and Set Up Remote Development for Visual Studio CodeStateless Code2024-01-20 | We have hundreds of coding videos here at Stateless Code, but almost all of them are recorded using the Ubuntu Linux distribution. We've invited you to code along, but maybe you're having trouble taking that first step because you're a Windows user and you don't know how to set up a development environment on Windows.
We've got good news! It has never been easier to set up a development environment on Windows. When I started learning Ruby, I would use VirtualBox to run a desktop version of Linux. In 2016, Windows released the first version of Windows Subsystem for Linux. It was a major improvement over needing to work on a desktop virtual machine guest, but it was still a bit clunky. Windows Subsystem for Linux 2 became generally available in 2020, and the experience for installing it has improved since then to the point where you can get it installed using one command on administrator PowerShell:
wsl --install
Once you run that command and reboot, you will be prompted to set your UNIX username and password for Ubuntu, and you're off and running!
But wait, there's more! If you have Visual Studio Code installed on Windows, you can install the Remote Development extension pack and interact with your Linux distribution from your Windows code editor.
After a few minutes, you can be up and running and code along with Stateless Code!
This video covers: 00:00:00 Introduction 00:02:34 Launch PowerShell as an administrator and execute `wsl --install` to begin the install process 00:04:20 Alternatives for manual installation if you don't want the default Ubuntu distribution 00:05:09 Reboot. Remaining portion of the Ubuntu install autolaunches when you log back in. 00:05:29 Increase the font size in the terminal and set the UNIX username and password 00:06:41 Update the software on Ubuntu with `sudo apt update && sudo apt full-upgrade -y` 00:07:22 Review the documentation on setting up a WSL development environment 00:08:46 Install Visual Studio Code on Windows (skip if already installed) 00:09:38 Launch VS Code and install the Remote Development extension pack 00:11:00 Re-launch VS Code and open the remote window to connect to WSL 00:12:05 Clone a Git repo in Linux and open it in the VS Code remote window 00:14:27 Quick overview of how preferences can be set at the Remote WSL level 00:15:24 Concluding thoughts
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Migrate from SFDX CLI version 7.x to Salesforce CLI version 2.xStateless Code2023-12-20 | Maybe you've seen the deprecation warnings about the need to move from the sfdx-cli to the sf commands in the new sf CLI, and have been reluctant to rip off the Band-Aid and make the switch.
In this video we uninstall the sfdx-cli (version 7.x) and install the new version (@salesforce/cli version 2.x).
In this new version of the CLI, all the commands and most of command line arguments are are different. Commands are no longer separated by colons, and comma-separated lists are gone in favor of repeating the same argument flag multiple times. If you were a heavy sfdx CLI user like me, it's a lot of adaptation. Because of this we walk through converting an old sfdx command into a new sf command.
This video covers: 00:00:00 Introduction and overview of options to upgrade from sfdx to sf 00:01:54 Uninstall sfdx version 7.x 00:02:49 Install @salesforce/cli version 2.x (switched to latest installed version of node using nvm before installing) 00:04:40 Convert an sfdx force:source:deploy command into an sf project deploy start command and change the syntax to match the new command style 00:09:44 Discussion of the --ignore-conflicts command line argument 00:11:18 Try executing the sf command and examine the results 00:12:15 Using the Salesforce CLI sf Command Reference
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Remove the Webdrivers Gem from a Rails 7 App and Update Selenium WebdriverStateless Code2023-09-09 | In the previous video, we encountered an error when trying to run our system tests because the version of Chrome installed on the system was newer than the latest version supported by the gem. After we updated the bundle, the system tests worked again, but the webdrivers gem had a post-install message noting that if you were using Ruby 3 that you should stop requiring the webdrivers gem and upgrade to version 4.11 or later of the Selenium Webdriver gem. New Rails 7 applications now omit the webdrivers gem from the Gemfile, but existing applications need to remove it manually.
In this video we drop webdrivers from the Gemfile for our application and update the bundle to a late enough version of selenium-webdriver. For once there aren't any surprises. Our test run fine after the update and the build succeeds when we push the code to GitHub.
This video covers: 00:00:00 Introduction 00:01:46 Clip from previous video where the error occurred 00:02:14 Review the GitHub issue and Rails GitHub repo change removing from generator templates 00:03:40 Remove webdrivers gem from Gemfile, run `bundle install`, and review changes to Gemfile.lock (gem is gone, but still has too low a version of selenium-webdriver) 00:05:08 Run `bundle update` to get selenium-webdriver to a proper version 00:05:46 Run tests and RuboCop (which was updated with the `bundle update`) 00:06:49 Review changes commit and push code 00:08:22 Pull request, ensure passing build, merge, and close issue
See other related StatelessCode videos: - Update to Rails 7.0.7.2 and Upgrade Other Dependencies to Clear Dependabot Alerts youtu.be/7vWRVgyUHVQ
Resources that we relied upon for this solution: - Selenium Manager documentation page https://www.selenium.dev/documentation/selenium_manager/
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Update to Rails 7.0.7.2 and Upgrade Other Dependencies to Clear Dependabot AlertsStateless Code2023-09-02 | As time has passed, new Dependabot Alerts have surfaced on our application's dependencies. In particular, Puma, Nokogiri, ActionPack, and ActiveSupport need to be updated to resolve security alerts. While we're at it, we'll update the entire bundle.
Before updating, we check the Rails releases since our last update, ensure that the patch version of Ruby we're running is the latest available, and ensure that the existing tests still pass before updating. It seems like there's always something when you upgrade dependencies, and this time it's the existing tests failing because the version of chromedriver running on the system is not recognized. This causes the test run to error out.
We attempt to update the local Aptitude packages and reboot the machine, but this doesn't resolve the issue. The error message mentions updating Browserlist: caniuse-lite, but that solution is not applicable because we don't have a package.json for our app.
Eventually we just try running `bundle update` and seeing if that resolves the issue. It does, and the tests now run and pass. The post install message notes that Selenium itself now manages drivers by default. We'll investigate that and deal with it in another video. We check for any new RuboCop violations, and there aren't any, so we can push the code to GitHub, ensure the build is passing, and merge the pull request.
This video covers: 00:00:00 Introduction and convert backlog item into issue 00:02:28 Review current version of Rails, Rails releases and latest patch version of Ruby 00:03:58 Check out a new branch and attempt to run existing test suite. Errors out due to unrecognized version of chromedriver 00:05:33 Update packages on local machine and reboot machine. (Does not solve problem) 00:07:38 Attempt to follow instructions about Browserlist: caniuse-lite. Not applicable because project is using import maps instead of a package.json 00:09:34 Just try running `bundle update` and it resolves the issue 00:12:20 Check for new RuboCop violations and discuss not adding rubocop-capybara 00:13:07 Review, commit, and push code to GitHub 00:14:34 Open pull request, ensure build passes, merge and close issue
See other related StatelessCode videos: - Update Rails to 7.0.4 and Update the Bundle youtu.be/gB2PtQfthI4 - Upgrade a Rails 7.0 App to Ruby 3.1.3 youtu.be/DFvzWcAx-Rc - Update a Rails 7 Application to use Ruby 3.2 youtu.be/C_UzpLST3us - Update Bundle to Clear Dependabot Alerts and Troubleshoot Build Dependency Failures youtu.be/rMlolATu73U - Upgrade a Rails 7 Application to Ruby 3.2.2 youtu.be/Ij1QRQE2hBA
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Populate the Project Backlog with Preliminary Features for the AppStateless Code2023-08-22 | We've got our user authentication with Devise working and took care of some housekeeping items and now our backlog has been depleted almost down to nothing. If this were writing a book, we would be staring at a blank page. Where do we begin?
In this video, we take a three phase approach to initial population of the backlog:
Step 1: Brainstorm a list of features and get them into the backlog. Order, priority, feasibility and value beyond it being a potential wish list item don't really matter.
Step 2: Rearrange the backlog by value, ignoring execution order and dependencies.
Step 3: Rearrange the backlog again, taking into account execution order and dependencies.
This is still early in the project's lifecycle. There are a lot of unknowns, but one thing you can take to the bank is that we won't just execute through the backlog in the order it is in by the end of this video without making modifications. As we work through the backlog, ideas for improvement and iteration will come up as we iterate on the application. We will learn things and flesh things out more. Thankfully the Ruby on Rails framework is among the best available for adapting to these changes when we do need to pivot.
This video covers: 00:00:00 Introduction, review recent videos and backlog 00:02:18 Overview of a project backlog and plan for the video 00:05:22 Review initial "brainstorm" version of the backlog 00:09:19 Rearrange and review the "abolute order" version of the backlog 00:14:27 Rearrange backlog to a more realistic "execution order" 00:16:09 Example of how a lower priority item might influence a design decision 00:19:26 Anticipating change and adaptability to backlog changes
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.NerdDice.com Retrospective 4 - It is a Long Way DownStateless Code2023-07-22 | At regular intervals, the team (even a team of one) reflects on how to become more effective, then tunes and adjusts its behavior accordingly...
I lost a bit of momentum since our last retro. There are a total of 14 videos covered by this retro, but they were published over a period of four months. The video that had the most views out of the bunch is probably the one I would rate the worst of them, so you never know what the response will be to something you publish. Time to get back into the game and start publishing content more frequently.
The featured art by @j.morp_art is of one of my D&D characters. Sammie Hermes is essentially a Freddie Mercury tiefling bard. All of his spell incantations are excerpts from Queen songs. You can hear me sing these excerpts poorly in the Art Review.
As always with our retros we try to have a little fun.
Theme: Inside Out Mediocre Karaoke: From the Pinnacle to the Pit by Ghost
This video covers: 00:00:00 Introduction and review of completed work 00:09:33 Review action items from last retro 00:10:37 What went well 00:13:38 What went poorly 00:16:59 Action items 00:18:11 Art Review: Sammie Hermes by @j.morp_art 00:22:34 Mediocre Karaoke: From the Pinnacle to the Pit by Ghost
Note: There is a copyright claim on a portion of this video because of the karaoke track. From the Pinnacle to the Pit was written by A Ghoul Writer (Tobias Forge), Indio Marcato (Martin Persner), and Klas Frans Åhlund, and performed by Ghost on their 2015 album Meliora. Copyright currently held by Loma Vista. This is well within the realm of Fair Use.
Copyright is stupid. Check out the Center for the Study of Innovative Freedom for more info.
Except for the note above, this video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Exploring My Table Top Role-Playing User PersonaStateless Code2023-06-01 | Every user is different. We each have our own preferences, needs, and idiosyncrasies. In this video, we explore my persona as a table top role-player.
I act as both a game master and a player, and play mostly in-person on an actual table top. I participate as a player in one online campaign, using a combination of D&D Beyond, Discord, and Shmeppy.
Generally I'm a "pencil and paper" gamer, but I do all of my preparation and encounter running using a laptop. In a way that only a coding nerd can, I use Sublime Text editor for my preparation, encounters, session notes, spell descriptions, magic items, and monster stat blocks. We have multiple game masters in the house, so we use a locally hosted Git repository (with branches for the different users) to synchronize preparation and notes across users and computers.
I then talk about some of the features that I would value as a user and practice going through the user questionnaire created on the project wiki.
This video covers: 00:00:00 Introduction: Code what you know 00:01:57 The importance of being able to "speak" both business and technology 00:03:08 My tabletop role-playing persona overview 00:08:02 How I use Git and Sublime Text for managing current tabletop campaigns 00:14:23 Some features that I would find valuable in a role-playing management application 00:20:51 Go through the interview script on the project wiki
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Adapt a Usability Interview Script for the Project and Fix Broken Wiki LinksStateless Code2023-05-29 | This episode piggy-backs off of a previous episode where we set up a Wiki page for the project with an overview of the project and a couple of pages for user experience interviews. The previous episode focused more on a questionnaire about the user persona that we are designing for. This episode will focus specifically on adapting a model usability interview script from Steve Krug and adapting it to our (mostly remote) interview use case.
We start by fixing some incorrect wiki page assignments and broken links. Unlike the Markdown files in our source control for the project, the link to the wiki pages will actually change if you rename the page, potentially breaking links on other wiki pages. We rename our intended home page to Home and after moving the content, delete the duplicate home page.
Then we take the usability test script from Rocket Surgery Made Easy by Steve Krug and adapt it into Markdown for our wiki page. We also adapt it for the fact that we won't have an observation room and we are intending to release (at least some) interviews as video episodes in this series.
We wrap up by closing the GitHub issue and looking ahead to future videos.
This video covers: 00:00:00 Introduction 00:02:41 Fix the Home page for our project's Wiki and delete duplicate 00:04:27 Fix broken links on the existing Wiki pages 00:07:40 Create and review adaptation of usability test script from Rocket Surgery Made Easy 00:10:34 Add link to main User Experience and Market Research page 00:12:16 Discuss plan for upcoming videos and close issue
See other related StatelessCode videos: - Why Do Your Own User Experience Research? youtu.be/OTUNVF8D1z8 (extracted into short in the video) - Create a GitHub Wiki For User Experience Interviews youtu.be/UzPHcckRYd0
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a README for Your GitHub ProfileStateless Code2023-05-16 | In one of our previous videos, we had a contribution request. The contributor, Atharva Salitri, had a profile README for his GitHub and we noted in our retrospective that it would be cool to have one for Stateless Code and my own profile.
In our last video, we set up a GitHub profile README for the Stateless Code org. It was not very straightforward or smooth experience, with a bunch of "gotchas" and mistakes along the way.
In this video, we make a GitHub README for Mike's personal profile (msducheminjr). We compose the file directly in GitHub's Markdown editor (using a draft issue for more editor tools) as needed.
You can even drag-and-drop an image into your README. Just be sure to have a line break before and after it so that it renders properly (or use HTML tags in your Markdown).
You can use your README to spice up your profile introduce yourself to the rest of GitHub.
This video covers: 00:00:00 Introduction and review of the differences between user profile README and organization profile README 00:02:44 Create the msducheminjr/msducheminjr.git repo 00:04:33 Draft the README using the GitHub markdown editor for an issue 00:05:33 Review draft of README 00:06:08 Drag and drop some images into the GitHub markdown editor 00:07:30 Add some line breaks to get pictures to render properly 00:09:42 Commit the file directly on GitHub 00:10:07 Test to see that it shows up on the profile and move the action item to Done
See other related StatelessCode videos: - Set up a GitHub Profile README for an Organization youtu.be/hqFq-2yqPZM - Create a RubyGem 101: Retro on Version 0.5.0 and Patch Releases youtu.be/FIA8wyaHmnk - Create a RubyGem 92: Add Contributing Guidelines to the Project youtu.be/IiUWiV2svIU
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Set up a GitHub Profile README for an OrganizationStateless Code2023-05-09 | In this video, we tackle the organization profile README for Stateless Code. We start by assuming (incorrectly) that the structure of an organization profile README is the same as a personal profile README and create a repository with the same name as our org. We create a README for that repository using GitHub's Markdown editor and...
...nothing.
In order for a profile README to show up in an org, you need to have a .github repo for the org (instead of one matching the org name) AND the profile README needs to be located at the path profile/README.md instead of the root README for the .github repo.
We clone the repo onto our machine and add some links to assets. In doing so, we learn that organization profile links can't be relative. We wind up using that statelesscode repo we created at first as the location for the Stateless Code assets, branding, and icons.
Eventually we work out the kinks and get a working README profile associated with our org.
This video covers: 00:00:00 Retrospective introduction after recording the video and noting the pitfalls 00:01:27 Original introduction and example of a GitHub profile README from Atharva Salitri 00:02:43 Create a repo matching the organization name (not the right choice for an organization profile, but we'll still make use of it) 00:04:46 Edit the README on GitHub (and use a draft issue for better markdown editor features) 00:05:59 Review the first draft of the README 00:08:14 Double check links and fix broken or erroneous links 00:13:19 Commit initial changes to the statelesscode.git README, review and discover that organizations need a .github repo 00:15:14 Create a .github.git respository for the organization 00:16:18 Clone both the statelesscode.git and .github.git repos using the command line. 00:18:08 Copy the profile README from the statelesscode repo to the .github repo 00:19:28 Get the Stateless Code branding and assets into the .github repo and replace the placeholder text for Website with a reference to the stateless code logo 00:23:36 Add an image to the top of the README and do a commit on the .github repo 00:25:06 Take a look at GitHub. Not working. The profile README is not in the correct location and the find and replace for the links was not done correctly 00:26:38 Fix malformed markup in README (find and replace error) and force push (twice) 00:30:00 Move the README to the profile directory of the .github repo and change relative links to assets and force push again 00:32:53 Profile README showing up on org profile but relative asset links not working. They need to be absolute links for an org profile 00:34:50 Move the assets to the statelesscode.git repo and push them 00:39:04 Refer to the abosolute links of the assets in the .github repo and remove the assets from the .github repo. Force push again 00:43:27 Validate that everything is working as expected. Reference to assets folder now broken. Fix that and force push one last time
See other related StatelessCode videos: - Create a RubyGem 101: Retro on Version 0.5.0 and Patch Releases youtu.be/FIA8wyaHmnk - Create a RubyGem 92: Add Contributing Guidelines to the Project youtu.be/IiUWiV2svIU
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Remix One of Your Existing Videos into a YouTube ShortStateless Code2023-04-21 | YouTube now allows you to take one of your existing videos and remix it into a YouTube short. If you are a creator you can do this with your own videos to potentially increase your reach. In this video we just get a basic clip of one of our own videos edited into a short with no bells and whistles.
Once you get the basics down, you can add text to the timeline after choosing your clip and remix it together with other video clips. We show an example from @WizNugs that uses more of these features at the end.
The current state (March/April 2022) of YouTube has some limitations that made it hard to record a video of this. You can currently only do this in the mobile app. To complicate matters attempting to record a mobile app from a desktop for a screencast is a frustrating endeavor. (See the "frustrated Mike outtakes" chapter for some of the problems.) If you look at 0:12:27 or 0:19:24 you will see our brief homage to Little Mac and the Game Over screen from Mike Tyson's Punch-Out.
You can probably skip to the part where we just record it on a physical iPhone if you don't want to see Mike muddling through bad user experiences.
This video covers: 00:00:00 Introduction, try to perform the task on Android emulator 00:01:24 Select a video to edit into a short 00:02:22 Version of YouTube app being emulated does not support Remix 00:08:21 Try on a later Android API version. Unable to get it working. 00:12:27 Get frustrated and switch to Mac with AirPlay 00:13:53 Try to remix into a short with AirPlay, but it keeps going to full screen and doesn't work 00:19:24 Get frustrated with Mac and AirPlay and switch to just taking a video of holding a phone 00:19:49 Open the video and hit the Remix and Edit into Short buttons 00:20:34 Select and adjust the length of clip for the short 00:22:29 Click next and review clip 00:23:12 Caption the short and hit Upload Short 00:23:49 Find the uploaded short 00:24:54 Show an example from the WizNugs channel of a short that uses captioning and remixes in another video clip 00:26:32 Frustrated Mike outtakes
See other related StatelessCode videos: - Install an Android Emulator on Ubuntu 22.04 youtu.be/riC8PJfAAhw - Getting Started with Rails 7 22: Broadcast Comment Changes to the Article with Turbo youtu.be/NykaB6QCmmw (extracted into short outside of video) - Broadcasting Comments from Conall and Donall youtube.com/shorts/5X1mbaRMeRs?feature=share (extracted from Broadcast Comments video) - Why Do Your Own User Experience Research? youtu.be/OTUNVF8D1z8 (extracted into short in the video) - I Will Show You a Liar youtube.com/shorts/DDuayRqTmWA?feature=share (short extracted from UXR video)
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Install an Android Emulator on Ubuntu 22.04Stateless Code2023-04-13 | This one was a doozie... It had a bunch of false starts and other problems that came up, but eventually we were able to get an Android emulator installed on Ubuntu 22.04. There were so many problems trying to get this installed that we went back and added a TL;DR summary at the beginning.
We started by installing Anbox, but after installing, it wouldn't launch because the Linux kernel removed the ashmem_linux module that it relies on.
After that we install Android Studio. This is an IDE for developing on Android, and is really overbuilt for what we wanted. There is so much overhead that we ran out of space on the OS drive and had to move it to the data drive and use symbolic links.
Eventually we were able to get it up and running. Hopefully this video won't age well and a better solution will emerge. (If there's already a better one available, hit us up in the comments.)
This video covers: 00:00:00 A TL;DR summary of the video 00:02:33 Original intro for the video and install Anbox using snap 00:05:36 After rebooting try to get it running. Failed to start binder or ashmem kernel drivers not loaded 00:07:18 Attempt to install ashmem_linux kernel module. Doesn't work. 00:08:02 Try to add a PPA to get anbox dependencies installed. Doesn't work. 00:10:58 Attempt to install linux-modules-extra. Doesn't help. 00:13:25 Try to clone the anbox-modules repo and build the modules. It fails. 00:16:21 Discover that the modules needed for Anbox were removed from the Linux kernel entirely and uninstall the Anbox snap 00:17:23 Find an alternative emulator Android Studio. Download and extract. 00:22:51 Install the required libraries for Android Studio 00:24:12 Execute the shell file to launch Android Studio and do initial setup. 00:31:39 Go to Device Manager and try to create a virtual device. Need to reboot and enable Virtualization Technology in BIOS. 00:34:03 Post reboot, retry creation of virtual device 00:37:43 Creation failed due to running out of disk space again. Try to change preferences and settings to write to the data drive instead of the OS drive. 00:38:58 Show all the disk space that the different Android Studio components take up 00:40:00 Move all the Android Studio stuff to the data drive and then create symbolic links (first attempt with arguments in the wrong order) 00:43:10 Re-launch Android Studio after moving and symlinking the directories and create a virtual device 00:44:33 Virual Device successfully created. Try to launch it. It fails. Look in command line for problems. Disk space again. 00:46:10 Move the final ~/.android directory and emulator is able to launch and run in a larger window 00:48:46 Concluding thoughts
Resources that we relied upon for this solution: - Android Mobile App Developer Tools developer.android.comMandatory is PoisonStateless Code2023-04-11 | A bold assertion. Can I back it up? It's also controversial, but I'm an ideological statue toppler.
Mandatory here is defined as a "comply or else" command. The poison of mandatory tends to erode culture and trust within organizations. Enforcement of mandatory takes away the choices people would have made for themselves in the absence of intervention.
Are mandates sometimes necessary? Chemotherapy is also poison. When facing something life-threatening like cancer, it's usually seen as a less bad alternative than leaving the cancer unchecked. But you don't give chemotherapy to healthy people. That's just poisoning them.
Good ideas do not require mandates. If it actually is a good idea, all you need to do as a leader is remove the roadblocks to adoption. The difference between "got to" (the stick) and "get to" (the carrot) has far-reaching cultural implications. If you take a command-and-control approach, you will drive everybody except for the compliant worker drones away from you.
If you treat the people you lead like children, you will always have an immature organization. Don't be a tyrant.
This doesn't just apply to politics and businesses. It also applies to families and churches, and looser associations like your group of friends.
Chapters: 00:00:00 Introduction and definitions 00:01:34 Chemotherapy analogy 00:02:37 Comply or else takes away choices from people and treats them like children 00:04:15 There is a relational and cultural cost of mandatory 00:06:00 Iatrogenics (harm done by the healer) and the "We have to do something" mentality 00:06:55 Oppression of the mandatory gets worse in larger scale organizations 00:07:45 Mandatory shows lack of trust from leadership and erodes trust in leadership 00:08:54 Decisions should be made the closest to the bottom you possibly can 00:10:03 Examples of when non-intervention has been shown to be better 00:10:24 Swedish non-intervention in COVID producing the lowest increase in deaths above expected 00:12:12 Economics: Top-Down Keynesian Econometrics vs Austrian Subjectivism and Marginal Utility 00:13:54 John James Cowperthwaite and proactive non-intervention in Hong Kong 00:16:05 Good ideas don't require mandates to be adopted 00:18:00 Won't there be chaos? 00:19:45 What about actual bad actors? 00:21:59 Won't logistics and operations take a hit? 00:23:42 An example of how leaders can inspire trust and build culture without relying on mandating things
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.I Will Show You a Liar #uxd #uxr #whystatelesscodeStateless Code2023-04-09 | ...Add an End Screen to a YouTube VideoStateless Code2023-04-05 | If you've been around YouTube for any amount of time and watched a video to completion, you've probably seen an end screen.
It's common practice for YouTubers to add end screens to videos in order to increase the number of subscribers or drive traffic to their other content.
It turns out though, that even though I have over 240 published YouTube videos on this channel, I had never used an end screen. This ends (get it?) today. This was an improvement idea in our latest Stateless Code retrospective, and it gave me an idea for a whole new video series titled "How the Sausage is Made" where I make videos about my video making experience.
In this video we add a new end screen to a published video and then import the newly added end screen into a second video.
Here are a couple of strategies for what to include in your end screens: - If you refer to other videos or playlists in your video, add them to the end screen of that video so the viewers can watch that one next - If you have a video that is getting high traffic, you can use that to provide exposure to one of your better, but unappreciated videos.
This video covers: 00:00:10 Introduction to the "How the Sausage is Made" series 00:01:28 Overview of end screens 00:02:14 Select a video for the end screen 00:03:02 Navigate to the end screen editor 00:04:05 Review the section of the video eligible for the end screen 00:04:43 Select the type of end screen and choose the video and playlist 00:06:05 Demonstrate ability to adjust timing of elements in the end screen 00:06:41 Save the end screen and test the video on YouTube 00:08:38 How to import an end screen from another video 00:11:10 Prioritizing the video backlog 00:11:40 One suggested approach: adding other videos you referenced in your current video
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Upgrade a Rails 7 Application to Ruby 3.2.2Stateless Code2023-04-04 | Ruby 3.2.2 was released on March 30, 2023. It has a couple of security fixes and hopefully will also fix the pesky dependency issue we've been encountering with the debug gem.
We upgraded to 3.2.1 a few videos ago, so we use that commit as our blueprint. We install Ruby 3.2.2 using RVM. Then we run bundle install to install our gems on 3.2.2. We probably could have gotten away with just doing a bundle update here since we were intending to do that anyway and we could always reset to the HEAD in Git if something went wrong.
We spend a little time trying to get the app to use the latest version of bundler, ultimately solving it by updating the BUNDLED WITH attribute in our Gemfile.lock. Probably not the most elegant way to solve the problem, but it works.
This video covers: 00:00:12 Introduction 00:01:57 Take a look at the commit of our previous Ruby upgrade 00:02:39 Update the Ruby version in the .ruby-version and Gemfile 00:02:54 Install Ruby 3.2.2 with RVM 00:03:53 Run `bundle install` 00:04:31 Run `bundle update` 00:05:23 Get the app to bundle with the latest version of bundler 00:08:10 Run RuboCop and test suite 00:08:44 Review and commit. Double check that debug dependencies are correct 00:10:28 Push, pull request, merge, close issue
See other related StatelessCode videos: - Upgrade to Ruby 3.2.1 and Rails 7.0.4.3 youtu.be/XvRzpoWfM9Q - Update a Rails 7 Application to use Ruby 3.2 youtu.be/C_UzpLST3usUpgrade to Devise 4.9 on Rails 7 and Decommission the 4.8 HacksStateless Code2023-04-01 | Some exciting developments have taken place while we were working on our RubyGem! Devise released a new minor version 4.9 that works with Rails 7 and Turbo without requiring a custom responder class or TurboDeviseController.
We intentionally held off on doing the upgrade in our video and commit where we upgraded to Ruby 3.2.1 and Rails 7.0.4.3 to isolate the Devise change. (We even needed to modify our Gemfile.lock to explicitly hold the Responders gem back at 3.0.1 because it was breaking our system tests.)
Situations like this illustrate why it's so important to have a robust automated test suite. In the devise epic, we created system integration tests for all of our Devise scenarios so that we could discover whether the upgrade attempts would cause a breaking change or not.
To upgrade our app, we refer to the How To: Upgrade to Devise 4.9.0 [Hotwire Turbo integration] guide on the Devise Wiki. We start by removing the hacks we introduced to get Devise 4.8 working with Turbo and Rails 7. We delete our custom TurboDeviseController file altogether and remove the custom failure app code from our initializer.
We already modified the views to work with Turbo, so we can skip that part of the upgrade guide. The actual code change to upgrade to Devise 4.9 once we roll back our hacks is fairly simple. We just need to add configuration options for config.responder.error_status (:unprocessable_entity) and config.responder.redirect_status (:see_other).
When we run our full test suite, there is one failure. We investigate the screenshot and development environment of our application. It looks like the flash message for a blank email when Devise is configured to paranoid mode has changed. We're okay with the change, and modify our LogInLogOutTest for blank email to expect the new behavior.
This video covers: 00:00:12 Introduction 00:01:59 Check out the Devise pull request that fixes the Rails issues and the commit to our project where we introduced the hacks to get it working with 4.8 00:04:17 Update the Gemfile to use Devise 4.9.0 and run `bundle update` 00:05:15 Debug gem dependencies were blown away by the general `bundle update`. Reset to Gemfile.lock to HEAD and just run `bundle update devise` 00:07:34 Git Remove on the TurboDeviseController (git rm app/controllers/turbo_devise_controller.rb) 00:07:55 Remove the hacks from the Devise initializer configuration file (config/initializers/devise.rb) 00:10:04 Add in the new configuration options needed for config.responder.error_status and config.responder.redirect_status 00:11:36 Run the full test suite and investigate the one failure 00:13:56 Pull up the scenario in localhost development environment and see what happens. Determine that the change in behavior is acceptable 00:15:26 Modify the test to use the new flash message and refactor out the flash error text into an instance variable 00:16:52 Re-run tests to ensure everything is passing consistently 00:17:55 Review the git diff, run RuboCop, and commit 00:20:25 Remove missed TECH DEBT comment and amend the commit 00:21:52 Push to the branch, pull request, close issue
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Fix a Documentation Bug Referring to the Wrong ProjectStateless Code2023-03-29 | In our other series for the NerdDice RubyGem, we were attempting to adapt the CONTRIBUTING.md file from this project and discovered that the file from NerdDice.com was already referring to the issues list for the RubyGem project instead of the Rails Project. We added an item to the backlog of this project in that video. In this video, we take care of it.
We use the project-level search and replace in Visual Studio Code to replace the instances of the other project name followed by a slash with the correct project name. (We do replace with a typo at first and then need to do a second replace to fix it.)
After pushing the code to the repo, we test it to make sure that the links in the CONTRIBUTING and README files are pointing to the issues log for the correct project.
This video covers: 00:00:12 Introduction 00:01:24 Demonstrate the problem 00:02:18 Use search and replace at the project level to find "nerd_dice/" (replaced with typo) 00:04:34 Detect and fix the typo with a second search and replace 00:05:31 Review the git diff to ensure the correct changes 00:06:21 Add, commit, and push the code. Open a pull request. 00:07:17 Test that the changed links navigate to the correct location 00:10:00 Merge the pull request and finish up
See other related StatelessCode videos: - Add a CONTRIBUTING.md File to the Project to Help with Collaboration youtu.be/BI7zcbbPREk - Create a RubyGem 92: Add Contributing Guidelines to the Project youtu.be/IiUWiV2svIU
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Upgrade to Ruby 3.2.1 and Rails 7.0.4.3Stateless Code2023-03-27 | While we were working on our NerdDice RubyGem, new versions of Ruby (upgrading from 3.2.0 to 3.2.1) and Rails (upgrading from 7.0.4.2 to 7.0.4.3) came out. There were also 3 new Dependabot alerts related to Rack and Active Support.
We were planning to do a full `bundle update` on the project. There was one problem the last time, where the debug gem wasn't properly registering its dependencies. Also we know that a new version of Devise is available, but we're going to deal with that upgrade in a separate story.
We start by modifying our .ruby-version file and Gemfile to indicate Ruby 3.2.1 instead of 3.2.0. In this case 3.2.1 is not currently installed on the system, so we install Ruby 3.2.1 using RVM and set it as the new default.
After that, we run `bundle update` to upgrade the bundle of Gems. This will update the version of Rails and Rack to clear our Dependabot alerts.
After that we run RuboCop and our test suite. And it's a good thing. The change in the Responders gem from 3.0.1 to 3.1.0 is breaking a bunch our our Devise tests. Since we already have a story and an issue in our backlog to upgrade Devise, we manually modify the Gemfile.lock to stick with Responders 3.0.1.
Come to think of it, this approach can also be used to solve our issue with the debug gem from the last time we tried to upgrade. We manually modify the Gemfile and Gemfile.lock with the new version and dependencies of debug. (This isn't a sustainable solution, but it will solve the problem for now.)
Now our tests are all passing and we are able to produce a passing build and merge a pull request with the fixes back into our main branch.
This video covers: 00:00:12 Introduction 00:03:37 Take a look at the previous commit where we upgraded a Ruby version 00:04:27 Update the .ruby-version and Gemfile to Ruby 3.2.1 00:05:15 Install Ruby 3.2.1 with RVM 00:06:10 Tell RVM to use 3.2.1 as the default Ruby 00:06:32 Run a general `bundle update` and see what happens with the debug gem and Dependabot-related gems 00:08:54 Run RuboCop and tests 00:09:35 A bunch of new test failures exist due to changes in the Responders gem. Manually set the responders version in the Gemfile.lock to 3.0.1 until we make the update to Devise 00:12:13 Re-run tests with the downgraded version of Responders 00:13:09 Manually modify Gemfile and Gemfile.lock to upgrade the debug gem. 00:15:32 Re-run RuboCop and tests 00:15:45 Check out a branch, review changes, commit, push 00:18:16 Open and merge pull request, resolve issue
See other related StatelessCode videos: - Upgrade a Rails 7.0 App to Ruby 3.1.3 youtu.be/DFvzWcAx-Rc - Update a Rails 7 Application to use Ruby 3.2 youtu.be/C_UzpLST3us - Update Bundle to Clear Dependabot Alerts and Troubleshoot Build Dependency Failures youtu.be/rMlolATu73U
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Why Do Your Own User Experience Research?Stateless Code2023-03-25 | Usability is for everybody. It's not some super arcane topic of human inquiry that must be left only to the anointed select few professionals who have "user experience" in their title.
More importantly, everything you design has usability problems that you can fix. Even a back-end system needs to be implemented in a way so that the humans who try to work with it or develop against it are able to do so without frustration or confusion.
A few years ago, a coworker at my day job purchased the book Don't Make Me Think by Steve Krug and sent it to me. (Thank you Gurudev!) It has been extremely beneficial for me and was important feedback. Software developers like solving complex problems. Web users want clarity and simplicity. Those two things don't naturally harmonize, so you need to invest the effort to see how you can reduce the cognitive load on your users.
Even if you're the perfect subject matter expert on the topic of your product, you will quickly become blind to the usability issues of it because you are constantly working with it and testing it. When you start actually watching other people use your product, it will be eye-opening and humbling to see them muddle through something that you have spent so much time designing and testing.
But, you'll be able to reflect on what you saw, find the three-ish most important usability issues you can fix with minimal effort and take action. Over time your product will be significantly more usable compared to the status quo. It won't be quite as usable as it would be if you could afford a dedicated professional user experience designer to extensively research every feature. (There aren't enough to go around anyway.) But this is realistic and achievable. Do it.
This video covers: 00:00:12 Introduction 00:01:28 How Don't Make Me Think by Steve Krug inspired me 00:01:56 The idea of T-Shaped skills 00:03:06 Don't be afraid to start off by doing something badly. Always be a noob at something 00:04:53 Why you should prioritize user experience research as a skill to develop 00:08:20 Everything has a usability component (even back-end) and there is no shortage of examples of bad usability 00:09:13 Even if you are a subject matter expert, you still want to test with other users because people are different 00:09:56 There is no shortage of low hanging fruit from a usability standpoint in your project
Note: I mispronounce Krug in the video. I looked it up afterwards and it is pronounced "kroog" (I haven't heard him say it, so I don't know whether it's "oo like food" or "oo like look".)
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a GitHub Wiki For User Experience InterviewsStateless Code2023-03-23 | Our initial backlog has dwindled down to almost nothing. So what do we do next? In this video we take a step back from active coding and talk about the approach. In our project we want to deliver value to our users, but how do you figure out what that value is.
The first step on that path is to understand our users. I personally know a lot about the subject matter (a good idea for a solo project), but I have biases, idiosyncrasies and blind spots. What we want to do is find out how other users do table-top role-playing. Do they use digital tools? If so, which ones and how do they use them? What are their pain points and gaps that might not be provided well?
Unless seed capital magically falls from the sky, we are not going to have the resources to outdo the established players in the role-playing management space. By interviewing users, perhaps we can discover a niche that other products aren't providing. Since this is first-and-foremost an educational endeavor, it's okay to overlap some of the features that the established products have, but the input of our users should weigh heavily when it comes to prioritizing features.
We decide to make a Wiki for the GitHub project and create a home page, a user experience page, and a user experience initial interview page.
This video covers: 00:00:12 Introduction 00:01:59 Doing your own usability and T-shaped skills 00:03:39 Code what you know, but get the perspectives of other potential users 00:05:00 Recommendation of Don't Make Me Think by Steve Krug 00:06:45 The initial research goal: discovery of current state and lay of the land 00:09:30 Overview of the questionnaire 00:11:08 Create our first Wiki page, a home page 00:18:33 Create a user experience Wiki page 00:20:46 Create user experience questionnaire 00:29:00 Close the GitHub issue
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Broadcasting Comments from Conall and Donall #stpatricksday #rails #modalismStateless Code2023-03-19 | This was extracted from Getting Started with Rails 7 22: Broadcast Comment Changes to the Article with Turbo youtu.be/NykaB6QCmmw
If you haven't seen St. Patrick's Bad Analogies from @TheLutheranSatire then you're probably committing a ton of Trinitarian heresies that you aren't even aware of. youtu.be/KQLfgaUoQCwMediocre Karaoke - Dust in the Wind by KansasStateless Code2023-03-15 | Song: Dust in the Wind Artist: Kansas Album: Point of Know Return Writer: Kerry Livgren Year: 1977
At the end of our retrospectives and other special episodes, we like to close things out by singing a song.
Dust in the Wind has long been one of my favorite songs. Recording this gave me a chance to experiment with harmony on a video and editing the separate tracks together.
The song was written by Livegren 1977 less than 2 years before his conversion to Christianity. In many ways it echoes the themes of Ecclesiastes with an emphasis on the vanity of life under the sun.
Be warned: I'm a professional programmer rather than a singer for a reason. Michael Duchemin and Stateless Code disclaim any and all liability for psychological trauma you may experience as a result of listening to me sing this song.
NOTE: In the pre-song banter I make a factual error approximating Solomon to 1000 A.D. when I meant 1000 B.C.
Chapters: 00:00:10 Mediocre Karaoke Introduction 00:00:40 Pre-song banter 00:02:49 Dust in the Wind performance 00:06:18 Post-song banter
Source of the Dust in the Wind instrumental track: Luis Manzo youtu.be/5ouhrdZ4faY
Original video this was extracted from: - Create a RubyGem 101: Retro on Version 0.5.0 and Patch Releases youtu.be/FIA8wyaHmnk
Note: There is a copyright claim on a this video because of the karaoke track. Dust in the Wind was written by Kerry Livgren and performed by Kansas on their 1977 album Point of Know Return. Copyright currently claimed by Sony Music Publishing on behalf of original label Kirshner. This is well within the realm of Fair Use.
Copyright is stupid. Check out the Center for the Study of Innovative Freedom for more info. c4sif.org
Except for the note above, this video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a RubyGem 101: Retro on Version 0.5.0 and Patch ReleasesStateless Code2023-03-13 | At regular intervals, the team (even a team of one) reflects on how to become more effective, then tunes and adjusts its behavior accordingly...
Our poor NerdDice RubyGem had set neglected, not even having a valid gem signing certificate for over a year. It was in need of a little tender loving care and finally got it.
In this retrospective we look back over the videos that contributed to the five .gem version releases we published in the previous video.
In terms of existing action items, we had a really productive interval since our last chronological retro with five getting moved into the done column.
As always with our retros we try to have a little fun.
Theme: Back to the Future Mediocre Karaoke: Dust in the Wind by Kansas
This video covers: 00:00:12 Introduction and review of completed work 00:10:51 Review action items from last retro 00:16:05 What went well 00:26:13 Things to improve 00:29:52 Action items 00:34:25 Art Review: A Special Place by @j.morp_art 00:37:21 Mediocre Karaoke: Dust in the Wind by Kansas
Note: There is a copyright claim on a this video because of the karaoke track. Dust in the Wind was written by Kerry Livgren and performed by Kansas on their 1977 album Point of Know Return. Copyright currently claimed by Sony Music Publishing on behalf of original label Kirshner. This is well within the realm of Fair Use.
Copyright is stupid. Check out the Center for the Study of Innovative Freedom for more info.
Source of the Dust in the Wind instrumental track: Luis Manzo youtu.be/5ouhrdZ4faY
Except for the note above, this video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a RubyGem 100: Release Patch Versions and New Minor Version (0.5.0) of the GemStateless Code2023-03-11 | In this video we release five versions of our NerdDice RubyGem. We add the four patch releases that have current signing certificates and our other minor changes we backported in the previous video.
Unlike the last video where we counted down from the highest to lowest minor version, we will release our gems from lowest to highest, so that our new minor version 0.5.0 is the most recent chronological release.
It's kind of tedious to iterate through each of the versions, which is why we're deprecating everything below 0.5.0. Overall the lift for tagging, building, and publishing each gem version isn't too bad, especially compared to backporting the changes.
After we release each version, we check rubygems.org to ensure that everything looks good.
Then we generate checksums for each of the released versions and commit them to the repo. That way somebody can verify that what is published on RubyGems matches what is committed to GitHub.
We check out a legacy tracking branch for version 0.5.x and modify the CHANGELOG with our Princess is in Another Castle version.
We close our issue and milestones in GitHub. Then we iterate through each of the tags that we pushed and create a release in GitHub with the contents of our CHANGELOG for each version as release notes.
Finally we increment the minor version of the gem on the master branch. Now that the NerdDice gem is officially "un-neglected" we can do a retrospective.
This video covers: 00:00:12 Introduction 00:01:49 Check the git tags for previous versions and explain process 00:02:33 Checkout, tag, build, publish version 0.1.2 00:05:48 Checkout, tag, build, publish version 0.2.1 00:07:04 Checkout, tag, build, publish version 0.3.1 00:08:09 Checkout, tag, build, publish version 0.4.1 00:09:10 Validate patch versions on rubygems.org 00:09:57 Checkout master then tag, build, publish version 0.5.0 00:11:06 Move the built packages into the pkg directory and generate checksums for the releases 00:12:57 Check out version-0-5-x-stable branch and push to remote 00:13:47 Switch back to master and commit the checksum files 00:14:45 Push the checksum commit directly to master and close the GitHub issue, and milestones 00:16:48 Create GitHub releases off of each new tag and validate 00:22:00 Install 0.5.0 from RubyGems using HighSecurity 00:22:20 Checkout the version 0.5 stable branch and modify the CHANGELOG to point to master. 00:24:55 Increment the minor version on master, run bundle install, and commit 00:27:00 Double-check backlog and finish up
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a RubyGem 99: Backport Changes to Other Stable Branches and Update the CHANGELOGStateless Code2023-03-09 | This one is a doozy!
So we have all of our changes in the master branch. Now we need to document those changes in the CHANGELOG and figure out which change goes in which patch release.
We start with the 0.4.x branch, which is closest to master and cherry-pick nearly all of the changes, leaving out only the ones related to dropping support for Ruby 2.7. Then we iterate through similar processes in the branches for the other versions.
In some cases, we can just cherry-pick a commit without modification. In the commits where we updated the bundle, we need to check out only the Gemfile.lock and gemspec from the master branch. Then we need to re-run `bundle update` so the gem version is correct and re-do the corrections for the RuboCop violations. The branches are all different and are targeting a different Ruby version in the RuboCop config than master.
We pasted our CHANGELOG into a GitHub Markdown editor on the issue to make our changes. This nearly leads to disaster, because we navigate away from the issue on that tab. You get to watch Mike panic for a minute before he realizes that the in-progress changes were still in a draft comment on the issue. (Thanks GitHub for an excellent user experience!) In the future, we should probably place our in-progress changes in another editor.
When we inspect our legacy branches, it turns out that we neglected to properly sign some of the commits while cherry-picking. We solve this by doing an interactive rebase, choosing edit, amending the commit to sign it, and force pushing to the branch.
Finally we commit our updated CHANGELOG and merge it into master. We are ready to release!
This video covers: 00:00:12 Introduction 00:01:22 Look at the CHANGELOG and create template sections for each release 00:05:15 Create the consolidated set of all the changes in the 0.5.0 section 00:11:13 Get the master CHANGELOG into the GitHub markdown editor so we can switch to the other branches to cherry-pick the changes 00:12:09 Use git stash save to save the master changes 00:12:35 Check out the 0.4.x branch, cherry pick changes, and update section of CHANGELOG 00:24:45 Check out the 0.3.x branch, cherry pick a smaller subset of changes, and update section of CHANGELOG 00:37:24 Fix intermediate commit on 0.3.x branch to include forgotten changes and amend commit 00:40:21 Check out the 0.2.x branch, cherry pick subset of changes, and update section of CHANGELOG 00:52:00 Check out the 0.1.x branch, cherry pick changes, and update section of CHANGELOG 01:00:38 Add in missing cert commit to version 0.4.x branch 01:02:00 Correct unsigned commits on each of the patch version branches with interactive rebase 01:10:00 Switch back to master, check out a new branch, and update with the finished CHANGELOG (Watch Mike panic thinking he lost the CHANGELOG edits) 01:13:31 Pull request into master, close issue, update backlog
See other related StatelessCode videos: - Create a RubyGem 05: Prepare for the Initial Release youtu.be/lDLj_96QHfY - Create a RubyGem 19: End of an Epic - Finish the configurable generator story youtu.be/SLMepoMVaTY - Create a RubyGem 34: Evaluate whether to release, backport changes youtu.be/NS_WnhPD0kM - Create a RubyGem 49: Open Pull Request and Update Documentation youtu.be/IG2nur2xKcQ - Create a RubyGem 60: Add Ability Scores Documentation and Merge youtu.be/vrcTV1UMwvU - Create a RubyGem 63: Create 0.3.x Stable Branch and Prune Old Branches youtu.be/xV8FanV7vBw - Create a RubyGem 84: Update Docs and Extend ConvenienceMethods into NerdDice, Merge youtu.be/b7hTPBaI28U
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a RubyGem 98: Replace the Expired Gem CertificateStateless Code2023-03-07 | Okay I messed up, big time. The signing certificate for our gem expired over a year ago. When you add a cert to your gem, you're making a contract with your consumers that you will have a current signed version of your gem available at all times.
With an expired cert, a HighSecurity or even MediumSecurity install will fail. We need to rectify this. The process we use to update the gem certificate
* Move the old cert to an archive directory * Un-trust the old cert with `gem cert --remove [path_to_cert]` * Generate the new cert from the ~/.ssh directory of the local machine using the command: `gem cert --build [email in gemspec]` * Change permission for the private key to 0600 * Copy the PUBLIC certificate to the new directory with the command `cp ~/.ssh/gem-public_cert.pem certs/[RubyGems user name].pem from the gem's root directory * Trust the new cert with `gem cert --add certs/[RubyGems user name].pem` from the root directory of the gem * Test a build version of the gem with `gem build nerd_dice.gemspec` * Install the built version of the gem with the command `gem install ./nerd_dice-0.5.0.gem -P HighSecurity` (replace with built version in the future) * Uninstall the test version of the gem with the command `gem uninstall nerd_dice -v 0.5.0` (replace as appropriate)
In this video, the need to explicitly remove the expired cert before adding the new one gives us some trouble, but we figure it out and now our users will be able to install with high security again once we release.
This video covers: 00:00:12 Introduction 00:01:14 Demonstrate the problem 00:03:08 Archive the expired certificate and key 00:04:48 Generate the new cert and private key 00:06:41 Copy the new cert to the certs directory of the gem 00:08:38 Build the gem and test that it can be installed with HighSecurity, fails 00:10:49 Troubleshoot install failure. Solution is to remove the old cert before adding the new one 00:15:06 Test install with high security successful; uninstall test version 00:15:49 Commit the new certificate 00:16:34 Update the SECURITY.md file with new end-of-life date for other versions and amend commit to include change 00:18:54 Push to the remote, open pull request, ensure process for updating the certificate is noted in a comment in the issue 00:21:01 Merge pull request and update backlog
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a RubyGem 97: Update Bundle Before Performing ReleasesStateless Code2023-03-04 | We are nearing the end of our development for the maintenance releases for our gem. One of the final things to get in the habit of doing before a release is to review our dependencies and look for opportunities to upgrade them.
It's possible that dependency upgrades could contain breaking changes, so it's important to start with a clean working directory in Git. If things go south, we can always do a `git reset --hard HEAD`. The more likely situation is that you would have a subset of gems that need to be reverted. You can downgrade the offending gems explicitly or add more pessimistic version constraints. Then you can re-run your bundle commands.
We look through all the dependencies in our Gemfile and gemspec and check RubyGems.org to see if there are newer versions available for them. Most of them do have newer versions available, so we make the updates to our gemspec so that the latest version is captured.
After that we run `bundle update` to update all of our dependencies to the latest version allowed by our constraints.
After updating our bundle we get a little confused about an issue that occurred with the debug gem the last time we updated a bundle. After a couple minutes chasing our tails, we realize that the issue came up in our NerdDice.com Rails 7 project and debug isn't a dependency at all for this project.
We run our RSpec specs and everything looks good.
Back in video number 93, we updated RuboCop to enable new cops by default. We updated RuboCop in our bundle update, so we expect that there might be new violations to resolve. There are a lot of new violations (95), but they're all about preferring be to eq when making an expectation about a Boolean. We agree with the new standard and can autocorrect all of them.
We push to the remote and our GitHub actions pass on the first try. (Yay!)
This video covers: 00:00:12 Introduction 00:01:05 Look at Gemfile and gemspec, see whether there are new versions of gems available, and make updates 00:05:00 Review the changes made to the gemspec 00:05:22 Check out new branch and run `bundle update` 00:05:51 Try to find out what happened with the debug gem. Eventually realize that the issue was in the Rails project and not this one 00:08:27 Re-run bundle update and run RSpec 00:09:20 Run rubocop and auto-correct the new violations, preferring be over eq for Boolean expectations 00:11:30 Review changes 00:12:43 Commit, push, watch builds. 00:15:32 Pull request, prune some old branches, close issue
See other related StatelessCode videos: - Update Bundle to Clear Dependabot Alerts and Troubleshoot Build Dependency Failures (the debug gem issue I got confused with) youtu.be/rMlolATu73U - Create a RubyGem 93: Refactor RuboCop to Enable New Cops by Default for the Gem youtu.be/wyZTKXMx8lg
Resources that we relied upon for this solution: - RubyGems rubygems.org
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a RubyGem 96: Drop Official Support for End-of-Life Ruby 2.7Stateless Code2023-03-04 | Sometimes the best way to solve a problem is to avoid it. Back in episode 89 when we ran into an issue where our build was failing on Ruby 2.7. Our fix at the time was to at least temporarily drop Ruby 2.7 from the GitHub actions build and add an item to the backlog to see if we could fix things.
In this video we tackle that backlog item. We start by taking a look at the Ruby Maintenance Branch Schedule to determine whether a fix is even worth the effort. As it turns out, Ruby 2.7 is in security maintenance only and is scheduled for End-of-Life on March 31, 2023. This video was filmed on February 22, 2023, so the Ruby version only has a little more than a month before it is unsupported.
Trying to figure out how to get the current version of RSpec to work with the 2.7 version of the gem could be time-consuming and not yield any value. We decide that the best solution, given the circumstances, is to drop support for 2.7 and bump the minimum version for future releases to 3.0. Sometimes dropping support for old versions of things is a necessary part of Technology Lifecycle Management.
Changing the minimum version requires us to upgrade the RuboCop target Ruby version, which surfaces some new violations. We had a hack in one of our shared examples that accounted for the difference in the Random class behavior between 2.7 and 3.0. With 2.7 no longer needing support, we can retire the hack and make our spec more concise.
We also no longer need to call .freeze on our regular expression literals because in Ruby 3.0 and up, they are frozen by default.
This video covers: 00:00:12 Introduction 00:01:28 Take a look at the Ruby Maintenance Branch Schedule 00:02:29 Decide to end support for Ruby 2.7 for new versions of the gem 00:03:40 Increase the required Ruby version to 3.0 in the gemspec, run `bundle install` and specs 00:04:54 Run RuboCop and fix the new violation by updating the target Ruby version 00:05:51 Remove the Ruby 2.7 specific code condition from an RSpec shared example 00:07:54 Autocorrect redundant freeze violations now that Ruby 2.7 is no longer supported 00:08:45 Review the changes in the git diff 00:09:15 Refactor the shared example we fixed earlier to be more concise 00:10:51 Commit, push, pull request 00:12:01 Create a new milestone for the 0.5 release of the gem 00:13:39 Merge pull request, close issue
See other related StatelessCode videos: - Create a RubyGem 89: Add Ruby 3.2 to GitHub Actions and Update RSpec to a compatible version youtu.be/kid7Cc2dzRk
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a RubyGem 95: Consolidate the CHANGELOG to the Master BranchStateless Code2023-02-28 | A few videos ago, we modified our README to use a relative link instead of an absolute link to another file in the repo.
In this case we go the other direction and double-down on using an absolute link. There is a time for every purpose under heaven, and in this case we want to gather stones together.
The gemspec for the project and the entry on RubyGems explicitly link to the master branch version of the CHANGELOG. Because the CHANGELOG could exist in various states on different branches, it can introduce ambiguity as to which is the source of truth and become a tedious administrative chore to maintain.
In order to have a clear authority as to which CHANGELOG is the authority, we update the CHANGELOG files on our legacy branches to explicitly point to the master branch. We even add in an image that pays homage to the iconic scenes in Super Mario Brothers where you complete a castle level and are greeted by a citizen of the Mushroom Kingdom who informs you that the princess is in another castle.
We use the GitHub Markdown editor to draft our new pointer to the master CHANGELOG, and then check out and paste in the contents to each legacy branch.
After pushing to the legacy branches and verifying that the intended changes are in place, I hem and haw about whether to update the master branch version now or not. Ultimately, we defer that CHANGELOG update for a couple more videos until we start determining which changes to to each branch.
This video covers: 00:00:12 Introduction 00:01:52 Demonstrate variance in CHANGELOG files across the various stable branches 00:02:26 Show how the gemspec and RubyGems refer explicitly to the master branch CHANGELOG 00:03:45 Draft a Markdown replacement for the CHANGELOG on legacy branches that points to the master CHANGELOG 00:05:51 Make change on 0-1-x branch 00:08:10 Make change on 0-2-x branch 00:10:02 Make change on 0-3-x branch 00:11:15 Make change on 0-4-x branch 00:12:25 Go to GitHub Actions and ensure all the builds passed. 00:12:50 Validate changes on all the legacy branches 00:13:35 Indecision about whether to update the master CHANGELOG now or not, ultimately decide to defer it to another video 00:15:09 Close issue and update backlog
See other related StatelessCode videos: - Create a RubyGem 90: Fix README to Use Relative Links Instead of Absolute Links youtu.be/fHirL25vP-8
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a RubyGem 94: Fix a Cognitive Complexity Code Smell from Code ClimateStateless Code2023-02-24 | Overall the metrics on our codebase are pretty favorable. We have a Code Climate Maintainability rating of A. We have 100% code coverage. Our test suite and builds run fast.
But, we do have one code smell identified in Code Climate. In the grand scheme of things, it's not that big of a deal, but my "inner Monica" wants perfection. Also, it can serve as a teaching opportunity for how to solve for issues like this.
If you're not familiar with the term "code smell," it refers to something that works but could be improved. The particular type of code smell identified by Code Climate is cognitive complexity. The amount of assignment/branch/condition activity that goes on in a method adds exponentially to the cognitive load of the person reading and trying to understand the code. The fact that we're using the Ruby ternary operator a couple of times in the method masks the level of complexity in the current method.
The solution for almost all cognitive complexity problems is to refactor larger methods into smaller methods that do less. Even though Ruby has the reputation of being an object-oriented language, you can still use the functional programming paradigm well with it. Have a method that does one thing well and returns a consistent output for a given input.
After we refactor out the methods, we run afoul of RuboCop's Metrics/ModuleLength cop. The refactoring pushed us up to 106 lines out of an allowable 100. In this case, the value of breaking the module down into smaller files isn't that great, so we just add a magic comment to disable that cop for this module.
After we push and merge the pull request to master, our code smell is cleared on Code Climate.
This video covers: 00:00:12 Introduction 00:01:12 What is a code smell, and why should we fix it? 00:03:01 Review the particular method 00:05:12 Plug for the metaprogramming epic 00:08:07 Applying principles of the functional programming paradigm to Ruby code 00:09:40 Refactor get_default_from_number_of_dice to its own method 00:11:51 The importance of having a robust test suite that covers everything you care about 00:15:58 Refactor get pattern_match_or_default into its own method 00:19:01 Ensure adequate commenting 00:20:06 Run RuboCop and add an exclusion about Metrics/ModuleLength 00:24:47 Commit, push, pull request 00:27:51 Verify code smell cleared in Code Climate and close issue
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a RubyGem 93: Refactor RuboCop to Enable New Cops by Default for the GemStateless Code2023-02-22 | In our other series, NerdDice.com where we build a Ruby on Rails application to manage table-top role playing, we recently modified our RuboCop configuration file to enable new cops by default. In that episode, we added a backlog item for this project to do the same thing.
If you don't enable new cops by default, each time you upgrade RuboCop in your bundle, you will see warnings about new cops that need to be enabled or disabled in your configuration. While this allows for explicit documentation about your configuration, it also causes your RuboCop configuration file to grow by quite a bit over time.
When you get the warnings, RuboCop presents another alternative: You can enable new cops by default. The trade-off here is that if your existing codebase has violations, you will start getting new failures when you upgrade your bundle. When that happens, you can either modify your code to conform, or add configuration to ignore the new cops. Either way, our configuration file will be more meaningful; it will only have non-default or explicit configuration instead of a bunch noise about new cops we have enabled over the course of the project.
When removing the redundant configuration, we also find a few places where we are excluding directories that don't exist in our project. (We copied and adapted this file from Rails back in 2020 and didn't remove the references to the Rails project directories.)
This video covers: 00:00:12 Introduction, overview of RuboCop 00:01:47 Demonstrate the warning when new cops are available but not configured 00:05:25 Overview of what we're going to remove 00:07:11 Remove the unnecessary config from the .rubocop.yml file 00:08:24 Review file after making changes 00:09:17 Remove exclude lines for directories that don't exist in this project 00:10:28 Save and re-run RuboCop. Observe the expected warnings. 00:11:20 Add the NewCops: enable line to the config and re-re-run RuboCop to demonstrate no warnings 00:13:03 Review diff and compare size before and after 00:15:29 Commit, push, pull request 00:17:10 Merge pull request and close issue as complete
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a RubyGem 92: Add Contributing Guidelines to the ProjectStateless Code2023-02-18 | In our NerdDice.com series, we received a spontaneous pull request to collaborate while we were working on our Devise epic. This prompted us to create a CONTRIBUTING.md file in the repository to encourage and set expectations for collaboration.
When we did our video creating the contribution guidelines for the NerdDice.com project, we also added an item to the backlog of the NerdDice gem to do the same.
For the most part we, adapt what we already had in the NerdDice.com version, making some small changes for the project being a RubyGem instead of a Rails project. We also discover that in the NerdDice.com CONTRIBUTING.md file we accidentally linked to the NerdDice gem's issue log. We place an item to take care of that later.
We also make some changes to the README to adjust to the existence of a separate contribution guidelines file and add more named anchor tags to allow for linking to sections of the README.
Interestingly enough, it turns out that while we were recording this video, we received an offer to help collaborate on it. The specific collaboration (creation of a Code of Conduct), isn't something we're interested in adopting, but we thank our collaborator and encourage future participation and input.
This video covers: 00:00:12 Introduction and review of NerdDice.com version of contributor guidelines 00:01:47 Paste existing content into GitHub markdown editor and demonstrate how linking within the same repository works 00:03:58 Discuss how we plan to modify the README 00:04:31 Start adapting and demonstrate the additions of the anchor tags to each section of the README 00:05:59 Discover that the NerdDice.com contributing guidelines mistakenly refers to the NerdDice gem and add an item to that project's backlog to fix it 00:07:37 Preview the adapted draft of the guidelines 00:09:14 Paste raw markdown into Visual Studio Code and review diff 00:10:24 Git rid of the old Development and Contributing sections from the README. 00:11:02 Check out branch, commit, push 00:12:24 Test the links and functionality on the new branch 00:15:32 Discover a mistake in the fork link referring to the Rails project repo instead of the RubyGem repo and continue testing 00:18:05 Correct the mistake of the fork referring to the wrong repo, amend the commit and force push 00:19:15 Re-test the fixed fork link 00:19:58 Open and merge pull request 00:21:43 Start to close issue and respond to an offer to collaborate on a Code of Conduct 00:23:09 Close issue and update backlog
See other related StatelessCode videos: - Add a CONTRIBUTING.md File to the Project to Help with Collaboration youtu.be/BI7zcbbPREk - Burn the Contributor Covenant with Fire! youtu.be/D9h572uwf8c - Review a Pull Request from Our Devise Tailwind Video: Rails Helpers or Tailwind Directives? youtu.be/NY6J4Hjjftg - Flesh Out the README for the Project youtu.be/EQioYZAWvGU
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a RubyGem 91: Add a Security Policy to the GemStateless Code2023-02-16 | In this video, we add a security policy to the NerdDice gem.
Why would you want to set up a security policy? On an open source project, the public can read all your code, normal bugs, and other issues. In the event that a suspected or actual security vulnerability is discovered, you want to be able to provide people with a way to confidentially report these things so that you can investigate and fix those vulnerabilities without having that potential vulnerability published to the public while it is being fixed.
You can also use a security policy to inform your users about which versions of your project are still being supported to receive security updates. In our case we also use it to set expectations of when our support for old minor versions of the gem will sunset.
You can either directly commit the security policy file on GitHub, or you can copy the raw markdown into a file in your code editor and commit it as you would any other code.
Once our security policy gets, merged into master, the security tab gets updated to show that a security policy has been enabled for the project.
This video covers: 00:00:12 Introduction 00:00:50 Look at an example security policy 00:02:14 Use the security tab and click on set up a security policy 00:03:16 Use the GitHub markdown editor to draft the security policy and review results 00:05:31 Paste the raw markdown into a code editor, commit and push 00:07:41 Open and merge pull request 00:08:35 Demonstrate that security policy shows as enabled and close issue
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Create a RubyGem 89: Add Ruby 3.2 to GitHub Actions and Update RSpec to a compatible versionStateless Code2023-02-08 | This is the 89th video in the NerdDice create a RubyGem series. In this video we ensure compatibility with Ruby 3.2 by adding it to the GitHub Actions for the gem.
This does not run as smoothly as our transition from 3.0 to 3.1, though. Many of our specs are failing, and it's hard to figure out why. All of our keyword arguments are using the double-splat and seem to meet the Ruby 3.0+ specifications.
We go into the console and the method is working fine. What gives?
Maybe the issue isn't in our application code, but in RSpec. The tests that are failing all have one thing in common: the expect().to receive() pattern. Our gem itself is using the Ruby 3 keyword arguments properly, but the current version of RSpec we have installed is not delegating them properly when evaluating the expect().to receive() syntax.
We didn't want to modify our Gemfile, gemspec, or Gemfile.lock as part of this video, but it looks like we have no alternative in order to make our test suite pass with Ruby 3.2. We upgrade RSpec from 3.10 to 3.12 and use `bundle update rspec` to update the related gems.
After doing this our test suite is back to passing with Ruby 3.2. We push again. This time the build fails on 2.7. For right now, we remove Ruby 2.7 from our GitHub actions build. We'll evaluate the gem's future as it relates to supporting Ruby 2.7 in a future video.
This video covers: 00:00:12 Introduction 00:02:57 Take a look at the issue and the previous commit when we updated to Ruby 3.1 00:06:03 Run RSpec. Fails. Troubleshoot 00:07:25 Switch to Ruby 3.1 in RVM. All tests passing. 00:08:43 Back to 3.2. Still failing. More troubleshooting. 00:16:25 Check to see if the problem is RSpec and not the gem itself by trying the convenience method in the console 00:19:06 Update RSpec in the Gemfile and run bundle update rspec. Tests now passing 00:21:53 Run RuboCop. Try to change target Ruby version. Not supported by currently installed version of RuboCop. Decide to defer that. 00:22:44 Update the GitHub action to add Ruby 3.2 00:23:49 Run the benchmark script a few times. Decide not to modify it and see if the GitHub Action build succeeds. 00:26:03 Review diff, commit and push to the branch 00:28:09 Build fails because 2.7 won't work with the new version of RSpec. Drop 2.7 from the build. 00:31:56 Build successful. Open and merge pull request. Close issue and update project.
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Mediocre A Capella Cover - Foil by Weird Al YankovicStateless Code2023-02-01 | Song: Foil Artist: "Weird Al" Yankovic Album: Mandatory Fun Parody of: Royals by Lorde Writer: "Weird Al" Yankovic (parody), Joel Little and Ella Yelich-O'Connor (Royals) Year: 2014
At the end of our retrospectives and other special episodes, we like to close things out by singing a song. This was an impromptu bonus song where I decided to do the a song a capella with no backing track. It is only the second verse of the song.
Cameo appearances by Loki the Bearded Dragon and j.morp_art's arm.
Be warned: I'm a professional programmer rather than a singer for a reason. Michael Duchemin and Stateless Code disclaim any and all liability for psychological trauma you may experience as a result of listening to me sing this song.
Original video this was extracted from: - NerdDice.com Retrospective 3 - The Retro that THEY Don't Want You to See youtu.be/J-twNrO5XV0
Foil (written by "Weird Al" Yankovic) is a parody of Royals (written by Joel Little and Ella Yelich-O'Connor). Foil was performed by Yankovic on his 2014 album Mandatory Fun. This is well within the realm of Fair Use.
Copyright is stupid. Check out the Center for the Study of Innovative Freedom for more info. c4sif.org
Except for the note above, this video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.NerdDice.com Retrospective 3 - The Retro that THEY Dont Want You to SeeStateless Code2023-01-31 | You want the truth? The world is controlled by shadowy elites and shapeshifting lizard people! Wake up sheeple! The evidence is right here!
At regular intervals, the team (even a team of one) reflects on how to become more effective, then tunes and adjusts its behavior accordingly...
This is our retrospective for the work we have completed since our last retrospective on the Devise epic. We had a couple more Devise stories mixed in with this set of videos. There wasn't a real unifying theme to this set of videos. It was more of a hodgepodge of different topics, ranging from reconfiguring RuboCop, to documentation to making Devise paranoid (hence the video title and the Inside Job reference).
As always with our retros we try to have a little fun. Okay, for this one we had more fun than usual.
Theme: The IT Crowd Mediocre Karaoke: He Is by Ghost Bonus Mediocre A Capella Cover: Foil by "Weird Al" Yankovic
Papa Emeritus III face painting done by @j.morp_art
This video covers: 00:00:12 Introduction and review of completed work 00:08:53 Review action items from last retro 00:12:11 What went well 00:18:17 Things to improve 00:22:50 Mediocre A Capella Cover: second verse of Foil by "Weird Al" Yankovic 00:24:06 Action items 00:27:44 Plan for upcoming videos 00:30:19 Art Review: Secrets and Treasures by @j.morp_art 00:32:14 Mediocre Karaoke: He Is by Ghost (featuring the Ugly Copia Plushie)
Note: There is a copyright claim on a portion of this video because of the karaoke track. He Is was written by A Ghoul Writer (Tobias Forge), Indio Marcato (Martin Persner), and Klas Frans Åhlund, and performed by Ghost on their 2015 album Meliora. Copyright currently held by Loma Vista. This is well within the realm of Fair Use.
Foil (written by "Weird Al" Yankovic) is a parody of Royals (written by Joel Little and Ella Yelich-O'Connor). Foil was performed by Yankovic on his 2014 album Mandatory Fun.
Copyright is stupid. Check out the Center for the Study of Innovative Freedom for more info.
Except for the notes above, this video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.Update Bundle to Clear Dependabot Alerts and Troubleshoot Build Dependency FailuresStateless Code2023-01-31 | We forgot to set up Dependabot alerts for the project when we first created the repository. (We set it up offline between videos.) Now that we have it set up, there are 20 Dependabot alerts for us to take care of.
Before trying to clear them, we provide a quick overview of how we set them up and look at some of the other items on the Security tab.
In a best-case scenario, just running a bundle update will solve the issues and clear the Dependabot alerts. Because we just set RuboCop to enable new cops in the previous video, we need to remediate any new violations that crop up when we update the versions of the various RuboCop gems in our Gemfile. There are new violations, but they're straightforward we dispatch them quickly. We run our full test suite, and it looks like it's going to be an easy and straightforward configuration update video. Right?
Wrong.
When we push to our branch, our GitHub action build fails, saying that the debug Gem revealed dependencies not in the API or the lockfile (irb , reline).
The first path we explore is seeing if we can account for it in the GitHub action configuration, but this doesn't seem like the right solution.
We try running the bundle commands with --full-index. No dice.
We try adding irb to the Gemfile. This puts both gems in the Gemfile.lock, but it still won't build.
Finally we decide to downgrade the debug gem and set a pessimistic constraint on it. The build passes, and we can re-evaluate the constraint in the future.
This video covers: 00:00:12 Introduction 00:02:07 Add a backlog item to create a security policy 00:03:58 Take a look at current Gemfile.lock, Rails post about upgrade to 7.0.4.2, and discuss plan of action 00:06:07 Check out a new branch and run `bundle update` 00:07:23 Run RuboCop, examine results, and fix new violations 00:11:11 Run the full test suite 00:11:40 Review the diff, commit, and push 00:15:13 Build fails. Retry. Also fails. Troubleshoot build failure in console. Problem is the debug gem is not writing its dependencies to the Gemfile.lock correctly 00:16:59 Explore trying to modify the GitHub action to solve the problem. Not the right solution. 00:18:10 Try running bundle commands with --full-index. No change 00:19:39 Take a look at the debug gem on rubygems.org 00:21:20 Try throwing in irb as a development and test dependency. 00:23:10 Amend commit and force push. 00:25:00 Build still fails. Downgrade the debug gem and set a pessimistic constraint on it 00:28:02 Amend commit and force push again. Take a look at issues on debug gem while the build is running 00:30:48 Build is passing. Open and merge pull request. 00:32:20 Verify that all the security alerts have been cleared and close issue 00:33:49 Conclusion
See other related StatelessCode videos: - Getting Started with Rails 7 27: Add a Stimulus Controller for Client-Side Interaction youtu.be/pwg-pD4GcNI - Change RuboCop Config to Enable New Cops By Default for a Rails Application youtu.be/J8QvGnn-wso
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.