DEV Community: Liz Laffitte

WP2AT Part 4: Comparing Datasets

Liz Laffitte — Wed, 14 Apr 2021 01:38:22 +0000

I'm working on a Ruby CLI gem that will automate adding WordPress blog data to AirTable. It uses the WordPress API to collect a blog's title, date published, ID and URL, formats the data, and then uses the AirTable API to create new rows in a specified table.

Last time I discussed my new workflow. Instead of adding all the data received from the WordPress to AirTable every time the sync method was called, the gem will compare the AirTable's ID column to the ids of the WordPress posts, and only add new posts.

collect_row_data()

I shared my collect_row_data() method in my last post. This method calls call_at(), and collects the HTTP response data in a usable format for the rest of the gem.

I've revised it so that it isn't requesting data it doesn't need, speeding up the process. This is accomplished by passing in the fields I want (ID and Last Modified) as query parameters. The responses are also collected into a hash, instead of an array. I made this change so that later, when comparing our two datasets, I can easily get the ID column data by calling .keys on row_data.

    def collect_row_data
        row_data = {}
        offset = ""
        loop do
            at_response = call_at("fields%5B%5D=ID&fields%5B%5D=Last+Modified",offset)
            at_response.parsed_response["records"].collect{|post| row_data[post["fields"][@current_settings.headers[:id]]] = [post["id"], post["fields"]["Last Modified"]]}
            offset = at_response.parsed_response["offset"]
            break if !at_response.parsed_response["offset"]
        end
        row_data
    end

sync()

When a user wants to update the WordPress data in AirTable, they call the sync method.

In its latest form, sync pings WordPress to get the total number of result pages and ensure the user has entered the blog post URL correctly.

It then gathers the Wordpress data (collect_post_data) and AirTable data (collect_row_data) into two hashes. The datasets are compared by passing arrays of their ids into compare_datasets() and a hash is returned. The all_data hash will always have a key :current, and sometimes have a of :new. If the hash has a key of :new, we filter the WordPress data, keeping only the posts whose ids appear in all_data[:new]. That data is added to AirTable.

    def sync
        if ping_wp
            post_data = collect_post_data()
            rows = collect_row_data
            all_data = compare_datasets(rows.keys, post_data[:ids])
            if all_data[:new]
                data = prep_data(post_data[:posts].keep_if{|post| all_data[:new].include? post["id"]})
                add_to_at(data, @@at_api)  
            else
                puts "All data up-to-date"
            end
        else
            puts "There was an issue. Try correcting your blog's URL"
        end

    end

compare_datasets()

This method takes our two arrays of ids as arguments. We get all the new posts by subtracting the AirTable id array from the WordPress id array. We are left with any values that appear only on the WordPress array. These are the ids of our new posts to be added to AirTable!

    def compare_datasets(at_arr, wp_arr)
        new_posts = wp_arr - at_arr
        post_data = {:current => at_arr}
        if new_posts.count > 0 
            post_data[:new] = new_posts
        end
        post_data
    end

Next Steps

I now have all of the post data in data structures that make them easy to compare and change. The next step will be altering the WordPress API call so that we get the last modified date for each post. We'll compare these to the last modified date of each AirTable row. If WordPress has been modified later than AirTable, we'll update AirTable with the Wordpress info.

WP2AT Part 3: Retrieving All Table Rows from AirTable

Liz Laffitte — Wed, 07 Apr 2021 02:09:37 +0000

If you've been following along you know I've been working on a Ruby CLI gem that will automate adding WordPress blog data to AirTable. It uses the WordPress API to collect a blog's title, date published, ID and URL, formats the data, and then uses the AirTable API to create new rows in a specified table.

Last week, I talked about how the gem can only add all the blog post data wholesale to AirTable. It doesn't take into account the rows of data already in the table, meaning we could have duplicate content.

At first, I considered having the gem's sync() method accept flags, so that the user could specify how the data was synced: just adding new rows or deleting all the table data first before adding all the WordPress data wholesale. After some deliberation, I decided to scrap that idea.

New Plan

Instead of accepting flags for the sync method, the gem should get all the data from WordPress, all the data from AirTable and compare those two sets of data.

Why?

We could just check and see what the highest ID was in AirTable and retrieve any WordPress posts with an ID greater than that ID. Unfortunately, we wouldn't be able to tailor our request for conditional IDs (meaning, we can't ask the WordPress API for only posts with IDs great than 772). So we would have to request all of the posts anyway.

We could just request the WordPress API to only send us the posts published after a certain date. Unfortunately, WordPress authors can change their publish date, meaning we might end up with holes in our data.

Instead, I want to compare the WordPress post IDs from two whole sets of data. Any IDs that exist in both sets will be updated in AirTable (because maybe we changed a blog post's name to improve the SEO). Any IDs that exist only in the WordPress dataset will be added to AirTable as new rows. Any IDs that only exist in the AirTable dataset will have their rows removed from AirTable (maybe we decided to delete a post that didn't make sense anymore).

First Steps

The first step in accomplishing this new workflow is making sure all the data is retrieved from AirTable. AirTable (like WordPress) sends a max of 100 records per request. If there are more records available, the response will have a top level key of offset. To get the next set of data, you send the offset with the new request.

How I accomplished it

def collect_row_data
  row_data = []
  offset = ""
  loop do
    at_response = call_at("",offset)      
 row_data.push(at_response.parsed_response["records"].collect{|post| {post["id"] => post["fields"]["ID"]}})
            offset = at_response.parsed_response["offset"]
            break if !at_response.parsed_response["offset"]
        end
  row_data.flatten
end

I decided to use a do while loop to call the AirTable API as long as there is an offset value in the response. Every time we get a response back, we create a new hash, with the key being the AirTable row's id and the value being the WP post id. If we don't get a response with a key of offset, we break the loop. This way, we know we will always call the AirTable API at least once. Finally, we flatten our array of arrays and return it.

Next Steps

Next, I'll work on a method for comparing our two datasets. Then we'll send each array of IDs ([exist in both], [only in AT], [only in WP]) to methods that will handle updating, deleting and adding AirTable rows.

WP2AT Part 2: Working with WordPress & AirTable APIs

Liz Laffitte — Wed, 31 Mar 2021 02:13:25 +0000

Correction

In part 1 I implied that wp2at isn't a CLI. That is incorrect. Just because it doesn't continuously run via a while loop until the user exits the app (like my very entertaining Hogwarts CLI gem), doesn't mean it's not a CLI. Part of learning and growing in development is sharpening your industry vocab and I work on that every day.

Updating execute()

This week I worked on integrating the WordPress and AirTable APIs into wp2at (aka: the fun stuff).

This is where we left off:

    def execute(args)
        command = args[0]
        options = args[1]
        @current_settings = Settings.exists? ? Settings.load : Settings.new
        case command
        when "userconfig"
            puts options ? add_username(options) : @current_settings.username
        when "blog" 
            options ? @current_settings.add_blog(options) : @current_settings.list_blogs 
        when "sync"
            api = API.new(@current_settings)
            if options
                api.ping(options)
            else
                api.list_blogs
            end
        else
            puts "That's not an option"
        end

    end

The "sync" when condition is where we are telling the gem to get the WordPress blog data and add it to AirTable. This is what that section of the execute method looks like right now:

 def execute(args)
        command = args[0]
        options = args[1]
        flags = args[2]
        @current_settings = Settings.exists? ? Settings.load : Settings.new
        case command
       ...
        when "sync"
            if options
                if @current_settings.blog_count < 1
                    puts "Add a blog by running blog with an argument of the blog name you'd like to add."
                end
                if @current_settings.at_api != ""
                    blog = @current_settings.blogs.find{|blog| blog.name == options}
                    api = API.new(@current_settings, blog)
                    api.ping(flags)
                else
                    puts "Add an AirTable API Key by running the command api-key and passing an API key."
                end
            else
                puts "Add a blog to be synced"
            end
        else
            puts "That's not an option"
        end

    end

I'm doing a little error handling here with some if statements. First, the method checks to see if there is a blog to retrieve data for, then it checks to see if there is an AirTable API key available. Without those two pieces, the gem can't do the one thing I want it to do. If the gem has all the necessary pieces, it finds the blog object the user wants to grab post data from, instantiates a new API object and passes it that blog object and the current settings. It then calls the API instance method ping. (Normally I would advise against this, but ignore the flags for now...)

API Class

Let's take a look at the initialize method in the API class.

    @@wp_api = "/wp-json/wp/v2/posts?_fields=id,title,date,link&per_page=100&page="
    @@at_api = "https://api.airtable.com/v0/"

    def initialize(settings, blog, flags="")
        @current_settings = settings
        @blog = blog
        @@wp_api.prepend(blog.url)
        @@at_api += @blog.base_id + "/" + replace_space(@blog.table) 
    end

First, there are two class variable assignments. The base or domain of the AirTable API route will always be the same, while the subdirectories and query parameters will depend on the base and table values of the Blog object. On the other hand, the subdirectories and query params are constant for the WordPress API endpoint, while the domain will depend on the Blog object's url attribute.

When the class instantiates the new API object, it uses the Blog object it was passed to concatenate and prepend to the @@at_api and @@wp_api class variables, respectively.

Ping!

Let's look at the method our options class is calling: ping()

    def ping(flags)
        posts = collect_post_data()
        data =  prep_data(posts)
        add_to_at(data, @@at_api)
    end

This method calls collect_post_data, which gets the WordPress blog post data using the WordPress API. Then it calls prep_data to clean that data before passing it to add_to_at which adds it to AirTable.

def collect_post_data
        x = 1
        total = 2
        resp_array = []
        until x > total
            resp = HTTParty.get(@@wp_api + x.to_s)
            resp_array.push(resp.parsed_response)
            total = resp.headers["x-wp-totalpages"].to_i
            x += 1
        end
        resp_array.flatten
    end

This method sends a GET request to the WordPress API and adding that parsed response to resp_array. The WordPress API response will include ["x-wp-totalpages"] in the header. I'm using this to make sure I'm are getting all of the post data. Otherwise we would only get the first page of results, which WordPress limits to a max of 100 results.

def prep_data(results)
        records = []
        results.collect do |post|
            post["ID"] = post.delete("id")
            post["Title"] = post["title"].delete("rendered")
            post.delete("title")
            post["Date Published"] = post.delete("date")
            post["URL"] = post.delete("link")
            records.push({:fields => post})
        end
        records
    end

Prep_data iterates over the post data it was passed, changing key names to match the table header names in AirTable. It also adds a top-level key of :fields for each post, because that is what AirTable will expect in a post request.

def add_to_at(data, at_route)
        data.each_slice(10) do |slice| 
            at_response = HTTParty.post(at_route, 
            :body => {:records => slice}.to_json,
            :headers => {"Authorization" => "Bearer #{@current_settings.at_api}", "Content-Type" => "application/json"}
             )
            puts at_response
        end
    end

When creating new records, AirTable limits you to creating 10 records in each new request. That's why I use each_slice() here to send a post request with the cleaned post data in slices of 10.

Status

Right now, the gem can add blog data for any WordPress blog saved in the YAML file. However, multiple calls to sync the data don't account for the rows already in AirTable. Meaning that duplicate blog data is being added. The table header names are also very rigid at the moment. They must match what is hardcoded in the API class.

Next Steps

Remember the flags? The next step will be allowing users to indicate whether they want to delete all the current post data and add all the post data again as new rows, or just update the table with missing data. I'd also like to add an option for retitling the AirTable table headers, saving the values alongside the other data in the YAML file.

What I’m Working On: WP2AT – A Ruby Gem

Liz Laffitte — Wed, 24 Mar 2021 01:38:46 +0000

The Scenario: I work for a marketing company and our niche – the thing we’re really, really good at – is telling stories. One of the primary ways we tell our clients’ stories each month are blog posts.

For new clients, it’s easy to remember all of the topics we’ve written about. But some of our clients have been with us for more than 8 years, and others have changed hands from client manager to client manager as the company evolves.

To help keep track of what topics we’ve written about, we started tracking blogs in AirTable. We keep track of the blog title, date posted, category, URL and Yoast SEO data as well. This makes it really easy for our writers to ensure we haven’t written about a topic, and see what SEO keywords we’ve focused on in the past.

The Problem:

My coworkers and our interns have been inputting this data by hand. By hand. This is an issue for me because:

The potential for human error during the data entry process
The tables are never up to date because we always forget to update them
BY HAND?! This simple task takes up too much time, which is to say, it takes more than a minute. We’ve all got better things to do!

The Hard Way:

My initial solution was to export all the WordPress data monthly from phpMyAdmin and then paste it all into AirTable. This took less time, but it still require that I access one client’s DB at a time, export the data and then find the correct table in AirTable and import it. This was still taking too much time, and the blogs were never posted at the same time, so I ended up doing this task the hard way several times a month.

The Better Way:

I decided that I would build a program that uses the AirTable and WordPress APIs to gather the blog data and import it into AirTable, with a simple command in the terminal.

Done is Better than Perfect

Because I am on a React kick, initially I thought I would build this project as a Rails API backend with a React frontend. After some more planning, I realized that I didn’t need a GUI, I didn’t want to deal with creating users and storing passwords, and I wouldn’t want to worry about the security implications of storing AirTable API keys (which are required to make this work) or sending them in HTTP requests.

I decided that the program should store data on the user’s computer in a YAML file.

My next thought was to build a full-fledged CLI application. I very quickly got bogged down in all the puts statements and walking the user through the program loops.

I decided that I didn’t need a full app that continued to run until the user exited the program. This project needs to go from WIP to portfolio project, so I shifted gears.

I want the user (i.e. me) to be able to run specific commands in the terminal that accomplished different tasks. Think using Git in the command line. $ git config --global user.name "John Doe"

I want to run a command like wp2at sync and have all the AirTable tables be updated with the latest WordPress blog info. I want to run wp2at blogs and get a list of all the blogs I’ve configured. Ruby gem with executables it is!

I started with a simple command:

$ bundle gem wp2at

In my bin directory, that was created for me with the previous command, I created a file wp2at. In this file, I use the shebang line to tell the computer that this code is in Ruby, require a Ruby file that will serve as the entry point to all the other code in the gem, and include an executable.

#!/usr/bin/env ruby

require_relative '../lib/wp2at'
Wp2at::Option.new.execute(ARGV)

Now, when I run ./bin/wp2at in the terminal, Wp2at::Option.new.exevute(ARGV) is called.

In my Option class, I have an instance method execute that takes the command line arguments. In execute, I use a (case statement)[ https://www.rubyguides.com/2015/10/ruby-case/] to run different methods based on the arguments.

    def execute(args)
        command = args[0]
        options = args[1]
        @current_settings = Settings.exists? ? Settings.load : Settings.new
        case command
        when "userconfig"
            puts options ? add_username(options) : @current_settings.username
        when "blog" 
            options ? @current_settings.add_blog(options) : @current_settings.list_blogs 
        when "sync"
            api = API.new(@current_settings)
            if options
                api.ping(options)
            else
                api.list_blogs
            end
        else
            puts "That's not an option"
        end

    end

Status

Right now, the program loads or creates a Settings instance, based on the presence or absence of a YAML file. It can save a username and blogs to said YAML file. I’ve started to incorporate the WordPress API. The program can now GET blog data based on the blog info added to the Settings instance.

Next Steps

Next, I’ll concentrate on formatting the returned blog data so that it can be easily sent to AirTable.
I hope you’ll stick around and check back to see how this one progresses!

“It used to work!” Reviewing this Week's Web Dev Problem Solved

Liz Laffitte — Wed, 17 Mar 2021 02:03:30 +0000

One thing I hear often when working on web development projects is: “It used to work!” This past week I had the opportunity to tackle an “It used to work” project, and this is a review of that project.

Details

The Pretty Puppy Association (PPA)* has a website for their members and other puppy enthusiasts. It is built in Expression Engine and they are using the Low Reorder add-on (among others) and jQuery.

One of their channels is State Puppies. It has 51 entries, each one featuring an official state puppy for each state in the U.S. (and one for Puerto Rico). Each entry has a photo, a breed name, and basic information about the puppy’s breed.

*This is entirely made up, but ultimately the subject matter of the website doesn’t matter for this post.

It Used to Work Feature

On the PPA website homepage, there is a Spotlight on Spot section where the image and breed name of the featured puppy is displayed. Here users can select their state’s official puppy from a dropdown menu. When they make a selection, the photo and breed name in the spotlight section change to match their selection. When users visit the website in the future, their last-selected puppy should be seen in the spotlight feature.

The code

In the homepage template, we have the spotlight section itself, including a form with only a select element. You'll notice everywhere there would normally be puppy-specific info (breed, image URL) there is...nothing. That information is being retrieved and placed in the DOM via JavaScript.

The select element itself is being populated via Expression Engine, with the help of the Low Reorder add-on.

<div class="section-4 puppysection">
    <div class="row">
        <div class="container">
            <h2 class="col-md-12 spotlighthdr"><i class="fa fa-chevron-circle-right" aria-hidden="true"></i> Spotlight On Spot</span></h2>
            <div class="col-md-4">
                <div class="homefeatured">
                    <a class="puppylink" href="URL"><div id="divFeaturedPuppyBreed" class="featuredbreed">Breed</div></a>
                    <a id="aFeaturedPuppy" href="URL"><img id="imgFeaturedPuppy" src="IMG" class="img-responsive puppy-photo" alt="BREED" width="326" height="336" /></a>
                </div>
            </div>
            <div class="col-md-8">
                {exp:channel:entries channel="new_home_page" dynamic="off" limit="1"}
                    {spotlight_text}
                {/exp:channel:entries}
                <div class="col-md-8">
                    <form class="connectform">
                        <div class="col-md-8 nopadding">
                            <label title="Pick a state to see that state's official state puppy and get a link to read more." for="drpPuppies" class="hiddenLabel2">Pick a state to see that state's official state puppy and get a link to read more.</label>
                            <select id="drpPuppies" name="puppylist" form="puppyform">
                                {exp:low_reorder:entries  set="puppies" dynamic="no" disable="member_data|category_fields"}
                                    <option value="{entry_id}">{state}</option>
                                {/exp:low_reorder:entries}
                            </select>
                        </div>
                    </form>
                    <div style="clear:both;padding-top:20px;">
                        <a id="aFeaturedPuppyLink" href="URL">Read more about the <span class="sbreed"></span></a>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>

We also have some inline JavaScript in the homepage template. There is a change event listener set on the state select. When a change event is triggered, JSON data is retrieved from "/site/puppy-info/VALUE_OF_SELECTION". If we have a successful GET request, that information is used to populate our spotlight section with the selected puppy's info.

At the very bottom of the script, we see $('#drpPuppies').change();. This line of code is triggering the change event, without a user actually making a selection. This will become important later one.

function jqExt() {
    $('#drpPuppies').on('change', function () {

        $.getJSON("/site/puppy-info/" + this.value, function (result, status) {
            if (status == "success") {
                $('#divFeaturedPuppyName').text(result.name);
                $('.sname').text(result.name);
                $('.puppylink').attr("href", result.bio_url);
                $('#aFeaturedPuppy').attr("href", result.bio_url);
                $('#aFeaturedPuppyLink').attr("href", result.bio_url);
                $('#imgFeaturedPuppy').attr("alt", result.name);
                $('#imgFeaturedPuppy').attr("width", result.image_width);
                $('#imgFeaturedPuppy').attr("height", result.image_height);
                $('#imgFeaturedPuppy').attr("src", result.image_url);
            }
        });
    });
    $('#drpPuppies').change();
}

Let's look at '/site/puppy-info/'

            {exp:low_reorder:entries set="puppies" entry_id="{segment_3}" }
    {exp:ce_img:pair src="{puppy_picture}" width="300" height="340" crop="yes|center,top|0,0|yes" allow_scale_larger="yes"}
    <?php
        setcookie("exp_custom_default-puppy-id", {entry_id}, time() + (86400 * 365), "/", $_SERVER['SERVER_NAME']);
        header("Content-Type: application/json");
        $data = array( 'id' => '{entry_id}', 'breed' => '{breed}', 'image_url' => '{made}', 'image_width' => {width}, 'image_height' => {height}, 'puppy_url' => '{url_title_path="puppies/bio"}' );
        echo json_encode($data);
    ?>
    {/exp:ce_img:pair}
{/exp:low_reorder:entries}

If you blink, you might miss the setcookie() function. When users change that select dropdown, a GET request is sent to '/site/puppy-info/VALUE_SELECTED'. That value selected, or entry_id is set as a cookie.

Conceivably, when the user leaves the homepage and comes back, their last-selected puppy will be showing in the spotlight section, right? That wasn't happening.

The Problem

Instead of showing a user’s last-selected puppy, the Spotlight on Spot section is defaulting to the first state on the dropdown menu: Alabama – Blackhound. (I also made this up for example purposes. There is no official dog breed of Alabama.)

Why? First, the cookie was set, but that was it.

The cookie was never read and nothing was ever done with the value of that cookie.

Also, triggering the change event led to the featured pup always being Alabama, because of the way the select element works. The first option in the select element is always selected be default. So the page loads, the change event is triggered, this.value defaults to Alabama and the cookie value is set to Alabama. And over and over....

The Solution

Solving the problem involved four main parts: reading the cookie when the window loads; using that value in our GET request; and not triggering the change event automatically.

<script>
    function getCookie(key) {
        var keyValue = document.cookie.match('(^|;) ?' + key + '=([^;]*)(;|$)');
        return keyValue ? keyValue[2] : null;
    }
    function setPuppy(result) {
        $('#divFeaturedPuppyName').text(result.name);
        $('.sname').text(result.name);
        $('.puppylink').attr("href", result.bio_url);
        $('#aFeaturedPuppy').attr("href", result.bio_url);
        $('#aFeaturedPuppyLink').attr("href", result.bio_url);
        $('#imgFeaturedPuppy').attr("alt", result.name);                    $('#imgFeaturedPuppy').attr("width", result.image_width);
        $('#imgFeaturedPuppy').attr("height", result.image_height);
        $('#imgFeaturedPuppy').attr("src", result.image_url);
    }
    window.onload = (event) => {
        puppySelect = document.getElementById('drpPuppies');
        let myPuppy = getCookie("exp_custom_default-puppy-id");
        if(myPuppy == "" || myPuppy == null){
            myPuppy = "27";
        }
        puppySelect.value = myPuppy;
       $.getJSON("/site/puppy-info/" + myPuppy, function (result, status) {
            if (status == "success") {
                setPuppy(result)
            }
        });
    };
    function jqExt() {
        $('#drpPuppies').on('change', function () {
            $.getJSON("/site/puppy-info/" + this.value, function (result, status) {
                if (status == "success") {
                   setPuppy(result)
                }
            });
        });
    }
</script>

First we have getCookie(), a function that will retrieve any cookie, given its name.

Next I pulled all of the code around setting the puppy-specific info in the spotlight section into a new function setPuppy() so I can call it in two other functions without repeating myself. It takes the results of the GET request as an argument.

Up next is a window.onload event where we are checking for the "exp_custom_default-puppy-id" cookie and saving it into the variable myPuppy. If it is not set, we are returning a default value (27 - for Florida!).

The myPuppy value is used in our GET request. This way, we are sure that every user is greeted by an adorable puppy, whether or not they've visited before or their cookie has expired. We're also using setPuppy() to set the values of the elements we're referencing using the results of our GET request.

Last is our trusty jqExt() function, still with its change event listener intact. This takes care of rendering the correct pup when the user makes a selection. It also calls our setPuppy() function.

Thoughts

It turns out this “It used to work” never worked. It was requested when the website was updated, but this feature never worked in the way it was requested. On a former iteration of the website, the spotlight section would be randomly populated every time the homepage loaded.

Have you worked on any "it used to work" projects lately?

Converting CSS to SASS in Rails Project

Liz Laffitte — Wed, 10 Mar 2021 03:20:41 +0000

As an exercise to flex and practice my SASS skills, I recently converted the CSS in one of my projects to SASS. Did this project need the conversion? Ehh, probably not. I'm only using one stylesheet and it's less than 300 lines, but converting a smaller stylsheet is great practice for a larger project.

Getting Started

My YellowBitRoad application is running Rails 6, so the sass-rails gem was shipped with Rails.

I had dumped all of my CSS into application.css. To start the conversion to SASS, I created a new stylesheet /app/assets/stylesheets/style.scss. All stylesheets included in app/assets/stylesheets will be compiled and used in your application.

In your Rails application, you'll see comments at the top of application.css explaining how stylesheets are incorporated. You'll also see a suggestion to split up your CSS, and see .scss files created for each model generated with the rails g model command. For my purposes, it doesn't make sense to split up such a small file, so I'm going to put everything into one stylesheet.

Color Palette

One of the most convenient things about SASS, to me, is not having to remember, look up, copy and/or paste HEX codes. Also, do you know what color #01BAEF is? Maybe you do, but I have no clue. I love picking out a color palette for my application, I don't like having to remember HEX or RGB codes or what colors they represent.

My first step in the conversion was saving all my theme colors as variables, and them implementing those variables throughout my stylesheet.

CSS: Before

nav, footer{
  background: #04724D; 
  height: 70px;
  width: 100%;
}
a {
  color: #04724D; 
  font-weight:bold;
}

SASS: After

$dark_green: #04724D; 
$light_green:  #16DB65;
$yellow: #FFD23F;
$red: #B80c09;
$light_blue:  #01BAEF;

 body {margin: 0;}
 nav, footer{
   background: $dark_green; 
   height: 70px;
   width: 100%;
 }
 a {
  color: $dark_green; 
  font-weight:bold;
}

Hooray! That was exceedingly easy, and now I can decide to change my entire color palette if I would like. I can also remember color names a lot easier than HEX codes, so I don't have to keep referencing previous style rules when writing more CSS.

If there is a good chance you'll change your theme colors entirely, you may want to choose more generic variables names ($main_color, $secondary_color, etc.) so you can change the HEX values and still have variables that make sense for your fellow devs and your future self.

Nesting

Next I tackled nesting my separate style rules where I could. For my project, this made a lot of sense for my nav and footer elements.

Anywhere I had a rule for a child element of nav or footer (really apparent in my CSS as I referenced those parent elements), I converted the separate rules into my two new nested rules. I also used the opportunity to nest some rules where I didn't reference the parent element, but used an ID for their children.

Before: CSS


nav, footer{
  background: #04724D; 
  height: 70px;
  width: 100%;
}
nav { 
  position:fixed; 
  top: 0; }
nav ul {
  text-align:right; 
  margin: 0 auto; 
  width:85%;
}
nav ul li {
  display:inline-block; 
  margin-right:25px; 
  line-height:70px;
}
nav a, footer input {
  color:white; 
  text-decoration: none; 
  font-family: 'Roboto Slab', arial, sans-serif;  
  font-size:20px; margin-bottom: 10px;
}
nav a:hover{
  border-bottom: 1px solid white;
}
footer {
    padding-top: 20px;
    padding-left: 20px
  }
footer input {
    color: white;
    border: none;
    background: none;
}
#branding{
  color: #fff;
  display: inline-block;
  float:left;
  line-height: 70px;
}
#nav-items {
  width:85%;
  margin: 0 auto;;
}

After: SASS

nav { 
    position:fixed; 
    top: 0; 
    background: $dark_green; 
    height: 70px;
    width: 100%;
    ul {
        text-align:right; 
        margin: 0 auto; 
        width:85%;
        li {
            display:inline-block; 
            margin-right:25px; 
            line-height:70px;
        }

    }
    a {
        color:white; 
        text-decoration: none; 
        font-family: 'Roboto Slab', arial, sans-serif;  
        font-size:20px; 
        margin-bottom: 10px;
    }
    a:hover{
        border-bottom: 1px solid white;
    }
    #nav-items {
        width:85%;
        margin: 0 auto;
    }
    #branding{
        color: #fff;
        float:left;
        line-height: 70px;
    } 
}
 footer {
     padding-top: 20px;
     padding-left: 20px;
     background: $dark_green; 
     height: 70px;
     width: 100%;
     input {
        color: white;
        border: none;
        background: none;
        text-decoration: none; 
        font-family: 'Roboto Slab', arial, sans-serif;  
        font-size:20px; 
        margin-bottom: 10px;
    }
   }

Now, we've had to repeat some styles here, in the outer footer and nav nested rules, but I'm okay with that. It's minor, and now I can visually see all the style rules that affect these two parent elements and their children.

Converting the a smaller CSS file to SASS is great practice. Do you use SASS, CSS or both? Have you ever converted a large project from one CSS to SASS? Let me know!

Eggasaurus: JavaScript SPA Browser Game

Liz Laffitte — Wed, 03 Mar 2021 02:32:32 +0000

This post will review how I handled gameplay visualization in a JavaScript SPA browser game I built.

When working through the Software Engineering bootcamp at Flatiron, I built a JavaScript SPA as a portfolio project.

I decided to build a game that was simple enough for my (then) three-year-old to play. (Spoiler alert: he was not impressed. ) The resulting game, Eggasaurus, came from a combination of my love of browser games and my son’s fascination with dinosaurs. Users can create dinosaur pets and interact with them.

Over time, the dinosaurs get hungry, tired and bored. This is shown visually by what I call mood meters. Moods decrease constantly, over time. The player can click the care buttons to "fill" the corresponding mood meter back up.

I accomplished this with a combination of HTML (divs), CSS (background colors, width) and JavaScript (setInterval, event listeners, HTML DOM style property).

Mood Meter HTML & CSS

The mood meters are built with divs. Each mood meter (there are three total: hunger, happiness and tiredness) starts with a div with the class meters.

This parent div has a border-radius, border and height to form the actual meter. If this was an old-school thermometer, it would be the outer, glass piece of the thermometer.

<div class="meters">
...
</div>

div.meters {
  height: 20px;
  border: 4px solid gray;
  border-radius: 30px ;
  margin-bottom:5px !important;
}

Then there is a child div with a class green and and id according to what mood it represents. It also has a width value that we're retrieving via string interpolation. This div represents the value or level of the mood. Continuing our thermometer example, it is analogous to the mercury level in the thermometer (if that mercury was green).

<div class="meters">
  <div id="hunger-meter" class="green" style="width:${this.hungerP}">
    ...
  </div>
</div>

The CSS gives the mood level div the same height as its parent; a left float so it appears to grow and shrink from the left; a background color to visually display the level value; and a border-radius to match our illusion of the meter.

  div.meters div.green{
    height: 20px;
    float: left;
    border-radius: 30px; 
    background: green;
  }

Finally, there is a grandchild and a great-grandchid div. These hold the sprite that matched the mood the meter represents. So, chicken leg for hunger, in this case.

<div class="meters">
  <div id="hunger-meter" class="green" style="width:${this.hungerP}">
    <div class="sprite-holder">
     <div class="sprite"></div>
    </div>
  </div>
</div>

The CSS gives the sprite holder a background color, keeping the mood level from showing through. It also places it perfectly in our top-level mood meter div; and sets the background position depending on the meter, so the correct icon is displayed.

div.sprite{
    background: url('images/meter_icons.png');
    width: 20px;
    height: 20px;
    background-size: 58px auto;
}
div.sprite-holder{
    width: 25px;
    background-color: #fff;
    float: left;
    position: relative;
    left: -5px;
    top: -5px;
    padding: 5px;
    border-radius: 50%;
}
div#hunger-meter div.sprite{
    background-position: 0px 0px;
}

To handle the interactions with these mood meters, there are corresponding care buttons. Each button has a background image and id that corresponds with the mood meter it will affect.

<div id="care-btns">
  <button id="feed" data-id="${this.id}"></button> 
  <button id="play" data-id="${this.id}"></button> 
  <button id="nap" data-id="${this.id}"></button>
</div>

Mood Meter JS

The JavaScript takes care of changing the width of the mood levels with the use of setInterval, the HTML DOM style property and event listeners.

setInterval

First, when the game loads or a dinosaur is selected, moodTimer is called. This function accepts a Dino object id and uses setInterval to repeatedly call a function decreaseMoods on the Dino instance with the passed id.

function moodTimer(dinoId){
    newMoodAdjust = window.setInterval(() => {Dino.findDino(dinoId).decreaseMoods()}, 1000)
}

The setInterval() method calls a function or evaluates an expression at specified intervals (in milliseconds).

In newMoodAdjust, decreaseMoods will be called on the Dino instance, every 1000 milliseconds.

The setInterval() method will continue calling the function until clearInterval() is called, or the window is closed.
-- W3Schools

If a user logs out or selects a different dinosaur to play with, clearInterval is called.

clearInterval(newMoodAdjust)

If a user just selected a new dino, moodTimer() is called again, and it is passed the new dino id.

Decreasing Moods (HTML DOM style)

The newMoodAdjust calls the function decreaseMoods every second. This function is a Dino class method. It checks to see if a Dino instance's hunger, happiness and tiredness properties are above 0. If so, it calls the corresponding class methods hungry(); bored(); or tired(). These methods adjust the value of the Dino instance's properties and call another class method.

    decreaseMoods(){
        if(this.hunger > 0){
            this.hungry()
        }
        if(this.happiness > 0){
            this.bored()
        }
        if(this.tiredness > 0){
            this.tired()
        }
    }

    hungry(){
            this.hunger -= 0.5
            this.adjustHungerMeter()
    }

    bored() { 
            this.happiness -= 0.5
            this.adjustHappinessMeter()
    }

    tired() { 
            this.tiredness -= 0.5
            this.adjustTirednessMeter()
    }

Remember that we are displaying the Dino's hunger, happiness and tiredness property values to the player visually by adjusting the width of the green div. Zero is our floor. Once those properties and the width of the green div reaches zero, we don't need to make any more adjustments.

Our adjust class methods retrieve the appropriate green div and set its width equal to the Dino's hunger, happiness or tiredness property value, using the HTML DOM style property.

this.hungerP is a getter that translates the hunger property to a percent string. So if this.hunger // 50 then this.hungerP // "50%"


    adjustHungerMeter(){
        const hungerMeter = document.getElementById("hunger-meter")
        hungerMeter.style.width = this.hungerP
    }

    adjustHappinessMeter(){
        const happinessMeter = document.getElementById("happiness-meter")
        happinessMeter.style.width = this.happinessP
    }

    adjustTirednessMeter(){
        const napMeter = document.getElementById("tiredness-meter")
        napMeter.style.width = this.tiredP
    }

Increasing Moods (Event listeners & style)

When the game is loaded and a dino is selected, the SPA calls moodListeners().

This function adds click event listeners to each of our care buttons.

function moodListeners(){
    document.getElementById("care-btns").childNodes.forEach(btn => {
        btn.addEventListener("click", (e) => {
            const thisDino = Dino.findDino(e.target.dataset.id)
            if(e.target.id == "play"){
                thisDino.play()
            } else if(e.target.id == "feed"){
                thisDino.feed()
            } else if(e.target.id == "nap"){
                thisDino.nap()
            }
        })
    })

}

When the buttons are clicked, different Dino class methods are called: play(); feed(); and nap().

Unsurprisingly, these methods increase the Dino instance's mood property values (setting them to 100), and call the adjust class methods discussed above.

    feed(){
        this.hunger = 100
        this.adjustHungerMeter()
    }
    play(){
        this.happiness = 100
        this.adjustHappinessMeter()
    }
    nap(){    
        this.tiredness = 100
        this.adjustTirednessMeter()
    }

I decided to increase the moods to their max level, instead of increasing them by increments, because my son was getting frustrated with all the clicking.

Have you built any games just for fun? Are you a professional game developer or engineer? What are your favorite browser games? (Mine are CookieClicker and NGU Idle.)

Web Development Bad Habits to Kick

Liz Laffitte — Wed, 24 Feb 2021 02:11:34 +0000

Cover photo by mohamed abdelghaffar from Pexels

1. Not Designing for Mobile First

You know what’s difficult? Taking a complex, intricate design that looks pixel-perfect on a 24 inch monitor and trying to shove it on a 300-pixel-wide screen.

How do you decide what to cut? How do you ensure the most important info is still above the fold? You go back in time and design the mobile view first.

If you’re not optimizing your design for mobile, you’re likely serving a subpar experience for a majority of your users.

Start with a simple prototype that gives users easy access to the most important information on the page. Add design elements as you scale for bigger devices.

If you’re not a designer, take advantage of tools like Bootstrap.

2. Not Being Consistent

Consistency helps users know what to expect from your website and helps teach them how to use it. Being inconsistent can lead to frustration, despair and high bounce rates.

Inconsistent Links

You should treat links of the same type the same. If one of your external links opens in a new window, they should all open in a new window. (Don’t forget to think about users using screen readers. Check out these suggestions on making target=”_blank” more accessible)

This includes links to media! Don't indicate a link opens a PDF in one place and neglect to add that info everywhere.

Inconsistent Style / Design

While it's more than likely that you'll have multiple page templates and designs, users shouldn't think they've navigated to a new website or caught you in the middle of a theme update when the open a new page.

You should have your basic theme colors and include a header, navigation and footer where appropriate. (E.g. If you're building a JavaScript SPA browser game, you probably don't need a footer.)

It can be tempting to use an entire palette of colors and six different Google fonts, but less is...way less confusing. Define your CSS styles for font families, colors and sizes and use them.

3. Hardcoding Full Paths

Stop. It. Do you enjoy doing things multiple times? Does it bring you joy to install a plugin that literally only does one thing that you could’ve done yourself? Stop hardcoding full paths!

I cannot express to you how many times I’ve had someone ask me to troubleshoot a website issue that turned out to be a hardcoded full path for an image source attribute or external stylesheet.

Clients change their minds about domain names, production and development domains differ. Using partial paths gives you the freedom to make changes and push to production without having to go back and look for references to a previous domain.

4. Not Using Image Alt Tags

Seriously, it’s 2021. Adding alt tags to images is literally the most basic thing we can do to make a website or app more accessible. This is especially true for any images that contain text. The goal is to express the function, meaning or information portrayed by the image to all users.

Check out this alt decision tree for help deciding how to make images in specific contexts more accessible.

5. Being Div-Happy

Listen, we all love divs. They're fun little boxes that you can use for almost anything. But just because you can doesn't mean you should.

We should try to use divs only when there are no more appropriate - read semantic - elements for the job. You could use a div for your menu and everything would work fine. But using a <nav> element helps anyone using a screen-reader and the non-humans (i.e. search engines) understand the meaning behind your code. This isn't just a box with links in it, it's a navigation elements that holds a menu that will guide me through the rest of the site.

Instead of using a div to...
Place text under an image ... use <figure> and <figcaption>
Make a link that performs an action (e.g. uses JavaScript to open a modal or page through a multi-page form) look like a button ... use <button>
Group the main part of your page ... use <main>

What are your web development bad habits? Which ones do you come across most often?

Creating Accessible Accordions with HTML, CSS & JavaScript

Liz Laffitte — Wed, 17 Feb 2021 00:37:14 +0000

An accordion, in development and design, is a graphical control element that consists of vertically stacked headers and hidden internal content. When clicked, a header's previously collapsed/hidden content box will expand to show its content; often text, images, or other grouped information.

You've probably seen (or used) an accordion on a FAQ page, with the questions shown in the headers, and the answers to those questions hidden in the content boxes.

Accordions can help increase the user experience on web and application pages with lots of information. They allow developers to group all that information on one page, but only display the higher level headers/titles. Users can then glance over all the titles without being overwhelmed by the details. They can more easily find, and click on, the headers/titles that they are interested in, and access the greater detail of the content.

There are countless widgets, plugins and other code snippets that will auto-magically add an accordion to your website or app. But you can also build a simple accordion with only HTML, CSS and JavaScript.

Accordion HTML

<ul id="accordion">
  <li>
    <button aria-controls="content-1" aria-expanded="false" id="accordion-control-1">FAQ 1</button>
    <div class="acc-item-content" aria-hidden="true" id="content-1">
      <p>Answer 1!</p>
    </div>
  </li>
  <li>
    <button aria-controls="content-2" aria-expanded="false" id="accordion-control-2">FAQ 2</button>
    <div class="acc-item-content" aria-hidden="true" id="content-2">
      <p>Answer 2</p>
    </div>
  </li>
  <li>
    <button aria-controls="content-3" aria-expanded="false" id="accordion-control-3">FAQ 3</button>
    <div class="acc-item-content" aria-hidden="true" id="content-3">
      <p>Answer 3</p>
    </div>
  </li>
  <li>
    <button aria-controls="content-4" aria-expanded="false" id="accordion-control-4">FAQ 4 </button>
    <div class="acc-item-content" aria-hidden="true" id="content-4">
      <p>Answer 4</p>
    </div>
  </li>
  <li>
    <button aria-controls="content-5" aria-expanded="false" id="accordion-control-5">FAQ 5</button>
    <div class="acc-item-content" aria-hidden="true" id="content-5">
      <p>Answer 5</p>
    </div>
  </li>
</ul>

For the HTML, our entire accordion is housed in an unordered list. Each list item holds a div with the inner content and a button that will toggle the div's visibility. In an effort to make the accordion more accessible, we have aria-expanded and aria-hidden attributes, as well as aria-controls attributes on the buttons that correspond with the ids of the acc-item-content divs. These attributes will help users using screen readers understand our accordion, and what is and is not visible when the buttons are clicked on.

I've also got my text in paragraph tags, which will be helpful if you have more than a few sentences in the content divs.

Hopefully you're using a loop somewhere to dynamically create each list item and its child elements.

Accordion CSS

ul {
  list-style: none;
}

#accordion button:focus {
  border-radius: 0px;
  outline: none;
}
#accordion button {
  outline: none;
  background-color: DarkSeaGreen;
  padding: 10px;
  border: none;
  border-bottom: 1px solid darkslategrey;
  color: white;
  width: 100%;
  text-align: left;
  font-size: 16px;
  border-radius: 0px;
}
#accordion li {
  border: 1px solid DarkSlateGray;
  border-bottom: none;
}
.acc-item:last-child {
  border-bottom: 1px solid DarkSlateGray;
}
#accordion button::after {
  content: "\002B";
  font-weight: 900;
  font-size: 22px;
  float: right;
}

#accordion {
  width: 80%;
  max-width: 800px;
  min-width: 275px;
  margin: auto;
}

Most of the CSS is for...style. We add background colors, borders and pseudo content to visually indicate that this is an accordion, and that you should click if you want to see more.

Technically, the only rule set you need is this one:

.acc-item-content {
  padding: 0px 10px;
  max-height: 0;
  overflow: hidden;
  transition: max-height 0.3s ease-out;
}

It sets the height of the content divs to 0 (hiding them from view); and gives the max-height a transition style and speed. This will come in handy when we get to the JavaScript, where we'll change the max-height values for our divs when the buttons are clicked.

Accordion JavaScript

window.addEventListener("DOMContentLoaded", (event) => {
  let buttons = document.querySelectorAll("#accordion button");
  buttons.forEach((button) => {
    let content = button.nextElementSibling;
    button.addEventListener("click", (event) => {
      if (button.classList.contains("active")) {
        button.classList.remove("active");
        button.setAttribute("aria-expanded", false);
        content.style.maxHeight = null;
        content.setAttribute("aria-hidden", true);
      } else {
        button.classList.add("active");
        button.setAttribute("aria-expanded", true);
        content.style.maxHeight = content.scrollHeight + "px";
        content.setAttribute("aria-hidden", false);
      }
    });
  });
});

In pseudo code:

When all the DOM content is loaded...

  Collect all the buttons that are child elements of the element 
  with the id #accordion...

  Loop through each of these buttons...
     Grab the button's sibling element and save it in a variable 
     called content AND

     Add an event listener to each button, so that when the 
     button is clicked...

       If the button has the class active...
           Remove "active" from its class list AND

           Set its aria-expanded attribute to false AND

           Set the content variable's max-height value to null AND

           Set the content variable's aria-hidden attribute to true.

       Otherwise, if the button doesn't have the class active...
            Add "active" to its class list AND

           Set its aria-expanded attribute to true AND

           Set the content variable's max-height value even 
           to the value of the content variable's scroll height 
           (the height of an element's content) AND

           Set the content variable's aria-hidden attribute to false.

And that's it: an accessible, simple accordion made with only HTML, CSS and vanilla JavaScript!

Conquering Twitter OAuth Authorization in a Rails/React App

Liz Laffitte — Wed, 10 Feb 2021 00:49:13 +0000

Cover Photo by Brett Jordan from Pexels

This is a quick walkthrough of making Twitter API requests that require OAuth authorization, in a Rails/React app. You will need a Twitter developer account, an app with read and write permissions registered within your account, and your application’s API key and API key secret. You’ll also need to have added a callback URL for your application in your developer portal. I suggest app.com/auth/twitter/callback.

Please note that Twitter calls their client credentials several different things, but I’ll be using API key and API secret to keep it simple.

If you’ve ever built a React application with a separate Rails API backend, you’ve likely used the omniauth and omniauth-twitter gems to handle authorization for various social media platforms. However, if your application, like my social media assistant app, does not have separate front and backends (i.e. you’re not using views at all), you won’t be able to (easily) use the omniauth gem.

Instead, we’re going to use oauth and httparty.

The Twitter 3-legged OAuth flow is made up of three steps:

POST oauth/request_token
- Your application will send a POST request to https://api.twitter.com/oauth/request_token.
- The request will include your API key and API key secret
If successful, the request response will return a token and a token secret
GET oauth/authorize
Your application will send a GET request to https://api.twitter.com/oauth/authorize
The request will include the previously returned token as a param.
Your app’s user will be asked to authorize your app
If successful, your user will be redirected to the callback URL specified in your developer portal
The request response will include a oauth_token and a oauth_verifier
POST oauth/access_token
Your app will send a POST request to https://api.twitter.com/oauth/access_token
The request will include the previously returned oauth_token and oauth_verifier as params.

First, in our application’s Gemfile, we’ll add oauth and httparty as dependencies.

Gemfile

gem 'httparty'
gem 'oauth'

Make sure to run $bundle install.

Next, we’ll save our API key and API key secret as environmental variables in a untracked .env file.

Never, ever, save API keys or other sensitive information into a file that’s being tracked by a version control system; or upload it somewhere public where it can be accessed (e.g. GitHub).

.env

KEY=THISISOBVIOUSLYNOTMYAPIKEYREPLACEWITHYOURS
SECRET=AGAINTHISISJUSTANEXAMPLE

The next step is connecting your callback URL to the sessions controller create action.

/config/routes.rb

  get '/auth/:provider/callback', to: "sessions#create"

Now we’re set up and ready to start the 3-legged OAuth flow.

Step 1: POST oauth/request_token

We’re going to be making our API calls from a controller that exclusively handle any social media API calls.

app/controllers/social_controller.rb

require 'pry'
require 'oauth'
class SocialController < ApplicationController
    def create
        ckey = ENV['KEY']
        csecret = ENV['SECRET']
        consumer = OAuth::Consumer.new(ckey,csecret,
            :site => 'https://api.twitter.com',
            :authorize_path => '/oauth/authenticate',
            :debug_output => false)
        callback_url = "http://127.0.0.1:3000/auth/twitter/callback"
        request_token = consumer.get_request_token(:oauth_callback => callback_url)
        token = request_token.token
        token_secret = request_token.secret
        confirmed = request_token.params["oauth_callback_confirmed"]
        if confirmed === "true"
            redirect_to "https://api.twitter.com/oauth/authorize?oauth_token=#{token}"
        else
            redirect_to "/"
        end
    end
end

In the method, first we’re saving our API key and API key secret from our .env file to local variables.

def req_token
  ckey = ENV['KEY']
   csecret = ENV['SECRET']
…
end

Then we are creating a new consumer instance, passing it the API key and secret, the site we’re making the API request to, the authorize path and setting debug_output to false.

def req_token
…
        consumer = OAuth::Consumer.new(ckey,csecret,
            :site => 'https://api.twitter.com',
            :authorize_path => '/oauth/authenticate',
            :debug_output => false)
…

Next we save the callback URL into a local variable. We then make the POST request, by calling get_request_token on our consumer instance, passing in the callback variable and saving the response as request_token (step 1 a-b). We then use that response to save the returned token and token secret (step 1 c).

Step 2: GET oauth/authorize

def req_token
…
callback_url = "http://127.0.0.1:3000/auth/twitter/callback"
request_token = consumer.get_request_token(:oauth_callback => callback_url)
token = request_token.token
 token_secret = request_token.secret
…
end

To make sure our request was successful, we’re checking to see if request_token contains oauth_callback_confirmed. If so, we’re redirecting to https://api.twitter.com/oauth/authorize (step 2 a), adding the token we just saved to the URL as a param (step 2 b).

def req_token
…
confirmed = request_token.params["oauth_callback_confirmed"]
        if confirmed === "true"
            redirect_to "https://api.twitter.com/oauth/authorize?oauth_token=#{token}"
        else
            redirect_to "/"
        end
    end

This is the point in the OAuth flow when the users will be redirected and asked to authorize your application. If they do, they’ll be redirected to yourapp.com/auth/twitter/callback which we connected to sessions#create.

Step 3: POST oauth/access_token

For example purposes, I’ve dumped all the rest of the flow into sessions#create.


def create
        if params[:oauth_token] && params[:oauth_verifier]
            oauth_token = params["oauth_token"]
            oauth_verifier = params["oauth_verifier"]
            baseUrl = 'https://api.twitter.com/oauth/access_token'
            response = HTTParty.post(baseUrl + "?oauth_token=#{oauth_token}&oauth_verifier=#{oauth_verifier}" )
            @access_token = response.split("&")[0].split("=")[1]
            @access_secret = response.split("&")[1].split("=")[1]
            @user_id = response.split("&")[2].split("=")[1]
            @user_sn = response.split("&")[3].split("=")[1]
            user = User.find_by(username: @user_sn)
            if user
                session[:user_id] = user.id
                render json: UserSerializer.new(user)
            else
                new_user_info = get_user(@user_sn)
                 new_user = User.new(username: new_user_info[“name”], password: SecureRandom.hex, uid: @user_id )
                if @user.save
                   log_in(@user)
                  else
                  render :new
                end
                render json: new_user_info
…
            end
        end
    end

If the params promised in step 2e were returned, we’ll use HTTParty to make a post request, passing those params to the base URL.

That’s it! After you get the basics down, you’ll be able to connect the API calls to actions on your frontend.

CSS but with Bridgerton Characters

Liz Laffitte — Wed, 03 Feb 2021 02:58:23 +0000

A few CSS selectors explained, but with Bridgerton characters. Possible spoilers!

Everything Selector

Selects every element.
Syntax: *
Example:

* {
  color:white;
  font-size:48px;
   -webkit-text-stroke-width: 1px;
  -webkit-text-stroke-color: black;
}

Element Selector

Selects every one of the specified elements.
Syntax: div
Example:

div{
 border: 1px solid red;
  border-radius:5px;
}

Class Selector

Select every element with the specified class.
Syntax: .class
Example:

.the-ton {
  color:red;
}

Double Class Selector

Select every element with both specified classes
Syntax: .first-class.second-class
Example:

.the-ton.bridge-brothers {
  color: blue;
}

Multiple Class Selector

Selects every element with the second specified class, that is a child of an element with the first specified class.
Syntax: .first-class .second-class
Example:

.the-ton .secret {
  font-size:30px; color:green;
}

ID Selector

Selects the one element with the specified id. There should be only one.
Syntax: #id
Example:

#queen{
  color: purple;font-size:68px;
}

First Child

Selects the element that is the first child of its parent element.
Syntax: element:first-child
Example:

#characters div:first-child{
  color:green;
}

The more you use these, and other CSS selectors, the more they will become second-hand. Do try not to bungle it up.

PHP Cheatsheet for Rubyists

Liz Laffitte — Wed, 27 Jan 2021 03:11:40 +0000

This is a quick cheatsheet for every Rubyist struggling to remember PHP syntax.

Variables

Ruby
Variable names can begin with an alphanumeric character or an underscore, but not a number. Local variables don't require any keywords. Variables are case sensitive (name and Name are two different variables). Conventionally, variables begin with a lowercase letter, and snakecase is used for multi-word variable names. You must assign a value to a variable when it is initialized, even if that value is 0, an empty string, or nil.

Instance variables are initialized with the @ symbol, class variables with two @@, and global variables with a $.

name = "Ginny"
Name = "Jennifer" 
p name # "Ginny"
p Name # "Jennifer"
your_name = "Ted"
_energy = nil
@@name = "Liz"
$tater = "Tot"

PHP
PHP variables always start with a dollar sign ($) and all variable declarations (all lines in PHP actually) must end with a semicolon (;). Other than that, PHP and Ruby variables have very similar rules. Variables names can start only with an alphanumeric character or an underscore, never a number. Variables are case sensitive.

However, you can declare a PHP variable without assigning it a value. Also, multi-word variables names can be camel- or snakecase.

<?php
$tatertots;
$name = "Liz";
$hours_of_sleep = 0;
$tatertots = 3;

Comments

Ruby
Single line comments begin with a hash.

p "Pay attention to this." #ignore this

Multiline comments begin with =begin and end with =end.

p "Print this."
=begin
Don't print this.
Also, don't look at this.
It's not pretty enough to be part of Ruby.
=end

It's very common to see hashes across multiple lines.

p "This is common"
#Even though
#they are
#for single lines
#technically

PHP
Single line comments start with two forward slashes ( // ). Multi-line PHP comments start with a forward slash and a star (/) and end with a star and a forward slash (/), similar to multiline CSS comments.

<?php
echo "This will print to the screen." //But this will be ignored.
/*
This will also be ignored
*/

Arrays

Ruby
There are two ways to create an array in Ruby:

my_array = Array.new
your_array = [1, 2, 3]

PHP
There is a grand total of one way to create an array in PHP:

<?php
$this_array = array(1, 2, 3);