Forem: Michael Lobman

Workout Programmer

Michael Lobman — Fri, 13 May 2022 12:55:39 +0000

A few weeks ago, I began a new workout plan but spent the majority of my gym time on looking at my phone, referencing which percentages belong to which sets, which sets belong to which rep-schemes, etc...

When I returned home, I began building the Workout Programmer (deployed on Heroku) so I could spend less time scrolling and more time working out.

The application uses a PostgreSQL database with six relational tables:

Main Exercises (MainExes)
Accessory Exercises (AccessoryExes)
Weeks
Exercise Sets (ExSets)
Progressions
Users

As for the relationships between the tables, an instance of Main Exercise has many Progressions, has many Users through Progressions, and has many Accessory Exercises:

class MainEx < ApplicationRecord
    has_many :progressions
    has_many :users, through: :progressions
    has_many :accessory_exes
end

An instance of Accessory Exercise belongs to an instance of Main Exercise:

class AccessoryEx < ApplicationRecord
    belongs_to :main_ex
end

An instance of Week has many Exercise Sets and Users:

class Week < ApplicationRecord
    has_many :ex_sets
    has_many :users
end

An instance of Exercise Set belongs to a Week:

class ExSet < ApplicationRecord
    belongs_to :week
end

Progressions is a join table, with each instance belonging to one User and one Main Exercise:

class Progression < ApplicationRecord
    belongs_to :user
    belongs_to :main_ex

Finally, a User has many Progressions, has many Main Exercises through Progressions, belongs to an instance of Week, and has many Exercise Sets through Week:

class User < ApplicationRecord
    has_secure_password
    has_many :progressions
    has_many :main_exes, through: :progressions
    belongs_to :week
    has_many :ex_sets, through: :week
end

With the relationships established, let's walk through the application's user experience.

At signup, the user will have to elect which of the four main exercises to include in their workout, as well as their current fitness-level for the exercise.

Upon submitting, the endpoint maps to the create method in the users controller:

class UsersController < ApplicationController
    skip_before_action :authorize, only: :create

    def create
        user = User.create!(user_params)
        params[:exercises].each do |exercise|
            unless exercise[:include] == false
                ex_id = MainEx.find(exercise[:id]).id
                max = max(exercise[:weight], exercise[:reps])
                user.progressions.create!(main_ex_id: ex_id, baseline_max: max, current_max: max)
            end
        end
        session[:user_id] = user.id
        render json: user, status: :created
    end

    private

    def user_params
        params.permit(:email, :password, :full_name)
    end

First, a user is created with permitted params.

Next, for each exercise in params[:exercises], a progression associated with the new user will be created unless the user elected to not include the exercise on the front end.

Inside the ex_id variable, the corresponding instance of Main Exercise is stored.

As the user is asked to enter their highest weight and most reps performed for each exercise, a "max" is created using a method inherited from Application Controller:

class ApplicationController < ActionController::API
    include ActionController::Cookies

    private

    def max (weight, reps)
        nearest_five(weight * reps * 0.0333 + weight)
    end

end

The return value of that method is store in the max variable, which is used to create a progression for the user and this instance of main exercise.

Serializers organize the associated data so that it can be rendered to maximum effect on the front end.

Once their account is created, the user is automatically logged in and can begin exercising, with all of the week's sets and respective weight laid out before them in a clean interface built with React-Bootstrap.

Of course, a painless user experience involves some heavy-lifting under the hood.

One problem I encountered is, while the weights given to the user are all rounded to the nearest five (as the majority of weights are in reality at the gym), the user ends up doing a lot of calculation in their head to load up the bar properly.

Fine for some. Not for others.

Enter several custom methods in the progression serializer.

First, determine_plates:

class ProgressionSerializer < ActiveModel::Serializer

  @@plates = [45,35,25,10,5, 2.5]

  private

  def determine_plates(weight, plates, plate_hash = {})
    return nil if weight <= 45

    side = (weight.to_f - 45) / 2

    if side % plates.first == 0 
        plate_hash[plates.first] = side / plates.first
        return plate_hash
    elsif side > plates.first
        num = (side / plates.first).to_i
        plate_hash[plates.first] = num 
        weight = weight - plates.first * num * 2
    end

    determine_plates(weight, plates[1..-1], plate_hash)

  end

The method has three arguments:

weight
plates (an array stored in a class variable)
plate_hash (which defaults as an empty hash)

First, the method handles an edge case. If the weight argument is less than or equal to 45 (all weights are in pounds), the method returns nil. Simply, the standard bar at a gym is 45 pounds. If the weight is less than or equal to the bar, no plates will be needed.

As a bar has to have an equal number of plates on each side, it stores half of the weight argument in the variable "side".

If the side mod first plate in the plates array exactly equals 0, the if block executes. It divides the side by the first plate to determine the number of plates needed for the side. This value is stored in the plate_hash with a key of the first plate. The plate_hash is returned and the method terminates.

If the elsif conditional is true (side is greater than the first plate), that block of code fires. The side divided by the whole number of plates is stored in a variable 'num'. This value is stored in the plate_hash with a key of the first plate.

To determine how much weight still needs to be added to the bar after these plates, the overall weight of the plates is subtracted from the weight, completing the block of code and exiting the conditional statement.

Finally, the recursive call fires with the updated weight, the plates array beginning with the second element (in position '1'), and the plate_hash that has already been initialized.

Let's walkthrough the process with a weight of 200 pounds.

The first call:

def determine_plates(weight, plates, plate_hash = {})
    # weight = 205
    # plates = [45,35,25,10,5, 2.5]
    # plates_hash = {}

    return nil if weight <= 45

    # 200 <= 45 -false 
    # return not executed

    side = (weight.to_f - 45) / 2

    # subtract the weight of the bar, then divide by 2
    # side = 80

    if side % plates.first == 0 

        # 80 % 45 == 0 -false
        # 'if' block does not execute

        plate_hash[plates.first] = side / plates.first
        return plate_hash

    elsif side > plates.first

    # 80 > 45 -true
    # 'elsif' block fires

        num = (side / plates.first).to_i

        # num = (80 / 45).to_i
        # num = 1

        plate_hash[plates.first] = num 

        # plate_hash[45] = 1
        # plate_hash = { 45: 1 }

        weight = weight - plates.first * num * 2

        # weight = 205 - 45 * 1 * 2
        # weight = 115

    end

    determine_plates(weight, plates[1..-1], plate_hash)

    # determine_plates(115, [35,25,10,5,2.5], { 45: 1 })

end

The second call:

def determine_plates(weight, plates, plate_hash = {})
    # weight = 115
    # plates = [35,25,10,5, 2.5]
    # plates_hash = { 45: 1 }

    return nil if weight <= 45

    # 115 <= 45 -false 
    # return not executed

    side = (weight.to_f - 45) / 2

    # side = 35

    if side % plates.first == 0 

    # 35 % 35 == 0 -true
    # block executes

        plate_hash[plates.first] = side / plates.first

        # plates_hash[35] = 35 / 35
        # plates_hash[35] = 1
        # plate_hash = { 45: 1, 35: 1 }

        return plate_hash

        # method terminates and returns plate_hash { 45: 1, 35: 1 }

        # 'elsif' conditional never checked


    elsif side > plates.first
        num = (side / plates.first).to_i
        plate_hash[plates.first] = num 
        weight = weight - plates.first * num * 2
    end

    determine_plates(weight, plates[1..-1], plate_hash)    
  end

The second call reaches the return statement in the 'if' block and terminates the recursive process.

The determine_plates method is utilized by another instance method in the progressions serializer, weight_plates:

class ProgressionSerializer < ActiveModel::Serializer
    @@plates = [45,35,25,10,5, 2.5]

    def weights_plates
        base = self.object.w_max
        arr = []
        self.object.user.ex_sets.each do |set|
            weight = nearest_five(set.percentage * base)
            weight = 45 unless weight > 45
            arr << { weight: weight, plates: determine_plates(weight, @@plates) }
        end

        arr

    end

end

First, it stores the value of self.object.w_max in the 'base' variable and initializes an empty array, storing it in the 'arr' variable.

Next, for each of the user's exercise sets (recall a User has many Exercise Sets through the Week to which it belongs), a few actions will be taken.

The set's percentage times the value stored in the 'base' variable (rounded to the nearest five thanks to a private method) is saved in the 'weight' variable. However, 'weight' will be reassigned a value of 45 if the current value of 'weight' is less than 45 (the weight of the bar, in pounds).

Finally, a hash with two key/value pairs is being shoveled into the array stored in the 'arr' variable. The key of 'weight' points to the value stored in the conveniently named 'weight' variable, and the the key of 'plates' will point to the hash returned by the previously detailed determine_plates method.

Of course, these methods are just the tip of the iceberg. Explore the application yourself to gain a sense of all of the other processes going on under the hood to create a seamless user experience.

Thank you for reading, and I hope the Workout Programmer helps you achieve your fitness goals, whatever they may be.

In the meantime, happy coding.

Steak Whizard

Michael Lobman — Fri, 01 Apr 2022 14:52:39 +0000

The Philly Cheesesteak. Whether you love it or hate it, you likely have heard the never-ending debate about which is the best.

Enter Steak Whizard - a web application solely dedicated to finding the best steak in Philly. Review, rate, and let's settle the debate.

The application is built with a React frontend (and the much appreciated help of the Bootstrap library) and a Ruby on Rails back end with a PostgreSQL database. It is hosted on Heroku.

There are three distinct Rails models that are mapped to tables in the database - User, Steak, Review. The Review table is the join table, belonging to one instance of User and one instance of Steak:

class Review < ApplicationRecord
    validates :rating, presence: true, numericality: { greater_than_or_equal_to: 0, less_than_or_equal_to: 10 }
    validates :toppings, presence: true
    validates :title, presence: true

    belongs_to :user
    belongs_to :steak
end

A User has many Reviews and many Steaks through Reviews:

class User < ApplicationRecord
    validates :username, presence: true, uniqueness: true
    validates :fav_steak, presence: true

    has_many :reviews
    has_many :steaks, through: :reviews
end

A Steak has many Reviews and many Users through Reviews:

class Steak < ApplicationRecord
    validates :restaurant, presence: true, uniqueness: true

    has_many :reviews
    has_many :users, through: :reviews
end

The models also use Active Record Validations to ensure that valid data is being saved in the database.

The site will ask the user to create an account with a username and password. Passwords are salted and hashed with BCrypt and securely stored in the database.

When the user successfully creates an account with a unique username, a session is created with the user's specific id inside the Users Controller:

def create
    user = User.create!(user_params)
    session[:user_id] = user.id
    render json: user, status: :created
end

Inside the Application Controller, the private authorize method locates the current user by the :user_id held in session and assigns it to the instance variable @current_user, rendering an error response unless the variable is truthy - that is, the user exists:

before_action :authorize

private

def authorize
    @current_user = User.find_by(id: session[:user_id])
    render json: { error: ["Not authorized"] }, status: :unauthorized unless @current_user
end

Note the before_action filter which is a method that runs before a controller action. As the other controllers inherit from Application Controller, this will ensure that the user is authorized to view the content which they have requested.

The application has four pages served by client-side routing - Home, Best Steak, My Reviews, and Add Steak.

Home acts as the landing page, rendering each instance of the Steak class as a card component. The card contains "Favorite" and "Review" buttons, conditionally rendered dependent on the user's reviews and favorite steak:

On the back end, when a user reviews a steak, the POST request points to the create method in the Reviews Controller:

class ReviewsController < ApplicationController

    def create
        review = @current_user.reviews.create!(review_params)
        steak = Steak.find(params[:steak_id])
        steak.update(rating: steak.calc_avg_rating)
        render json: @current_user, status: :created
    end

    private

    def review_params
        params.permit(:steak_id, :title, :comment, :rating, :toppings)
    end
end

The method creates a new instance of the Review class that will be associated with the user stored in the @current_user variable.

The reviewed steak is found by accessing the [:steak_id] in the params hash. The steak's rating will be updated with the value returned by the instance method calc_avg_rating:

class Steak < ApplicationRecord
    def calc_avg_rating
        self.reviews.average(:rating)
    end
end

The method harnesses Active Record associations and methods to calculate the average rating from the steak's associated reviews.

The Best Steak page fetches from the API endpoint /steaks/highest-rated and renders the corresponding steak with its associated reviews. On the backend, the endpoint points to the highest_rated method in the Steaks Controller:

def highest_rated
    max = Steak.maximum(:rating)
    render json: Steak.where(rating: max)
end

On the page, the steak's associated reviews are rendered as well thanks to the has_many :reviews relationship established in the Steak Serializer:

class SteakSerializer < ActiveModel::Serializer
    attributes :id, :restaurant, :rating
    has_many :reviews
end

Similarly, the My Reviews page displays Reviews associated with the current user instance utilizing the same association but in the User Serializer:

class UserSerializer < ActiveModel::Serializer
  attributes :id, :username, :fav_steak

  has_many :reviews
  has_many :steaks
end

Finally, on the Add Steak page the user can create a new instance of the Steak class and leave a corresponding review:

And there you have it, the Steak Whizard. Give it a spin and let me know your thoughts - who knows, you may even find your favorite Philly Cheesesteak along the way.

Water of Life - A Scotch Whisky API

Michael Lobman — Thu, 03 Feb 2022 15:12:47 +0000

Hello! I'm back with my first full-stack web application: "Water of Life," a Scotch whisky API using a React JS frontend and Object-Oriented Ruby, Active Record, and Sinatra on the backend.

For those unfamiliar with Scotch, it is essentially just whisky distilled and bottled in Scotland. Scotland itself is divided into regions, each region has many distilleries, and each distillery has many bottles. Sounds like a perfect dynamic to take advantage of Active Record macros!

The API is comprised of three tables: regions, distilleries, and bottles, each with a corresponding model that inherits from ActiveRecord::Base.

As for the associations between the models, a region instance has many distilleries, and a distillery instance has many bottles. The distillery model acts as the join class so that a region instance has many bottles through distilleries, and a bottle instance has one region through the distillery to which it belongs:

class Region < ActiveRecord::Base
    has_many :distilleries
    has_many :bottles, through: :distilleries
end

class Bottle < ActiveRecord::Base
    belongs_to :distillery
    has_one :region, through: :distillery
end

With these associations established, "Water of Life" harnesses the power of Active Record to provide useful, organized data the client requests through the routes established with Sinatra.

Yes, I did it Sinatra's way.

Not "My Way."

But trust me, "The Best is Yet to Come..."

The first and most comprehensive endpoint in the application controller is the get "/all" route:

get "/all" do
    regions = Region.all
    regions.to_json(include: { distilleries: { include: :bottles } })
end

Simply, this returns all of the API's data, hierarchically structured by region, distillery, and bottle.

More dynamic routes, like get "/bottles/:id", take advantage of the params hash to locate and return the data for a specific bottle:

get "/bottles/:id" do
    bottle = Bottle.find(params[:id])
    bottle.to_json(include: { distillery: { include: :region } })
end

Or even delete it from the database entirely:

delete "/bottles/:id" do
    bottle = Bottle.find(params[:id])
    bottle.destroy
    bottle.to_json(include: { distillery: { include: :region } })
end

In both of these methods, the routes are not only returning information about the specific bottle instance but are "including" the data from its associated distillery and region as well:

bottle.to_json(include: { distillery: { include: :region }

Such functionality is possible because of the associations established earlier with Active Record.

Finally, for one of the post routes on the API...

As a quasi well-adapted perfectionist, I want my API to be efficiently created and properly maintained, which includes new bottles being added to the database in the correct format. Many scotches have a multiple-word name: "Lagavulin 16 Year Old," "macallan double cask 12 year old," etc. I prefer the former, not the latter.

Of course, I could have imposed a regex validator on the frontend form, but users shouldn't inherit my problems (after all, I'm not their parent class!). There are Ruby gems that provide a method to "titleize" a string, but I wanted to write my own method to better understand the process involved:

def titleize(string)
      title_cased = string.split.map do |word|
        letters = word.split("")
        letters[0] = letters[0].upcase
        letters.join
      end
      title_cased.join(" ")
end

And that, as they say, is that. My first API and full-stack web application. How far we've come...

Feeling thirsty? Check out "Water of Life" for details on your scotch of choice. And, if it's missing, please add it!

Intro to Regular Expressions in Ruby

Michael Lobman — Thu, 03 Feb 2022 15:11:28 +0000

Hello, friends! Wherever you may be in your coding journey, if you haven't yet encountered regular expressions (what the cool kids refer to as regex), you will soon.

You certainly have come across regex in your daily life- they are used to make sure the email address you entered is properly formatted and confirm that your password includes integers and special characters.

Let's start with a simple one. We will create a method that utilizes regex to see if a given word contains a vowel:

def vowel (word)
    word =~ /[aeiou]/
end

First, the =~ is an operator that checks a string against our regular expression. It returns the index of the string at which the first match occurs. If no match is found, the operator returns nil.

Second, since we want our method to determine if the given word contains any vowel, we place the vowels in question between brackets: [aeiou]. If we neglect the brackets, the regular expression would be looking to find a string with "aeiou" in that precise order. Hard to find one of those...

Finally, regular expressions in Ruby are written between two forward slashes to differentiate them from variables, strings, and arrays: /[aeiou]/.

Remember, the =~ operator will return the first index of the match and nil if no match is found. Let's wrap our expression in a ternary and print a message to highlight what is happening under the hood. Let's also add some test cases to ensure our method works as intended.

def vowel (word)
   puts word =~ /[aeiou]/ ? 
    "'#{word}' contains at least one vowel" : 
    "'#{word}' has no vowels"
end

vowel "hello"
vowel "world"
vowel "sky"
vowel "1"
vowel "I"

When we run this using ruby [file_name].rb in our terminal, we receive the following output:

'hello' contains at least one vowel
'world' contains at least one vowel
'sky' has no vowels
'1' has no vowels
'I' has no vowels

Whether "y" is or is not a value is beyond the scope of my grammatical expertise. But whether or not "I" is a vowel is certainly within the scope of our debugging expertise. Can you think of why "I" did not return a match for [aeiou]?

"I" did not return a match because our regex did not account for uppercase vowels. Let's first try "i" to test the validity of our hypothesis:

vowel("i")

Which prints...

'i' contains at least one vowel

Beautiful.

Time to update our method to account for uppercase vowels.

If we wanted to add that functionality to our regex, we could change the regular expression: word =~ /[aeiouAEIOU]/

We could also utilize the Ruby #downcase method to first convert the string to all lowercase letters, then check it against our regular expression:

def vowel (word)
    downcased_word = word.downcase
    puts downcased_word =~ /[aeiou]/ ? 
    "'#{word}' contains at least one vowel" : 
    "'#{word}' has no vowels"
end

Now, let's execute our file with the "I" test case again:

'I' contains at least one vowel

Excellent.

To be sure, this is hardly scraping the surface of the power of regular expressions in ruby (and other languages). But if you understand the processes behind these examples, you are well on your way.

I recommend checking out Rubular, an online Ruby regex editor where you create regular expressions and input strings against which to test them. It also includes a quick reference guide at the bottom of the page to explain common regex syntax.

Happy coding.

Recursion in JavaScript

Michael Lobman — Wed, 05 Jan 2022 19:29:48 +0000

The concept of recursion sounds intimidating, but it is deceptively straightforward.

Let's dive in. First, the terminology.

The MDN Web Docs define recursion as:

The act of a function calling itself, recursion is used to solve problems that contain smaller sub-problems. A recursive function can receive two inputs: a base case (ends recursion) or a recursive case (resumes recursion).

Let's create a function called "recursiveFunction" with a "num" parameter, taking in a number as an argument. If "num" is less than 10, the function will call itself on num + 1, checking to see if the new value is less than 10.

If the value of "num" is NOT less than 10, our "else" statement will execute and console.log "num".

To ensure our code runs as anticipated, I will add in a console.log in the "if" statement as well.

function recursiveFunction(num){
    if (num < 10) {
        console.log(`Number = ${num}. recursiveFunction will be called.`)
        recursiveFunction(num+1)
    } else {
        console.log(`Number = ${num}. Recursion terminated.`)
    }
}

In the abstract, recursion can seem needlessly verbose; however, when your code becomes more complex, recursion keeps your code clean.

For example, I created a recursive function for a React application that uses a window to display a random lyric from a hard-coded array:

function randomLyric(array) {
    let random = array[Math.floor(Math.random()*array.length)];
    if (lyric !== random) {
        setLyric(random);
    } else {
        randomLyric(array)
    }
}

The "if" statement checks if the randomly pulled lyric stored in the "random" variable is different from the lyric that is already stored in the state variable "lyric". If it is indeed different, it will use the setter function setLyric to updated the state variable "lyric" to the random lyric.

If, however, the two lyrics are exactly equal to each other - that is, our randomly pulled lyric is already being displayed - the recursion inside the "else" block executes and calls the randomLyric function on the same array, repeating the process until the randomly generated lyric is indeed random.

Try making a simple recursive function yourself. Once you see the utility of a function calling itself if certain conditions are met, you will never look back.

Well, you will, but only recursively.

Happy coding.

Direction Home

Michael Lobman — Wed, 05 Jan 2022 19:27:53 +0000

Lost? My React application "Direction Home" can help you find your way home... But only if you're lost in a metaphorical sense, kind of like a rolling stone...

Yes, my app is for Dylan fans. And yes, the lyric drops are just going to keep on keepin' on even as the times are a changin'.

The app is a single-page application and contains only one .html file. The parent "App" component utilizes Route and Switch hooks from React Router to create four distinct client-side routing pages - "Home", "Rank Songs", "Live", and "Moments":

function App() {

  return (
    <div>
      <NavBar />
      <Switch>
        <Route exact path = "/rank-songs">
          <RankSongs />
        </Route>
        <Route exact path ="/live">
          <Live />
        </Route>
        <Route exact path ="/moments">
          <Moments />
        </Route>
        <Route exact path="/">
          <Home />
        </Route>
      </Switch>
    </div>
  );
}

The "Home" component serves as the homepage of the application with two rows of Dylan album covers as decoration. It contains a "LyricWindow" component that displays a Dylan lyric from a curated array utilizing useState and useEffect React hooks.

The Film Finder

Michael Lobman — Thu, 02 Dec 2021 13:53:23 +0000

I love movies. Always have. Always will.

But I do not love the nightly ritual of endless scrolling until I finally find something to watch.

Enter The Film Finder, my first single-page application.

It asks you to enter five films that you have seen and enjoyed. From those five, it will recommend ten films for you to watch.

The application utilizes The Movie Database's API, which includes a recommendation method for every film in its wide collection. The Film Finder pulls the top two recommendations for each of the five films entered by the user.

While building the SPA, I wanted to make the experience of the site more personal than simply seeing titles on the page. For example, reading the title "Star Wars" doesn't evoke the same feeling as seeing the poster for "Star Wars". As an audience, we have a connection to the movies we watch, and The Film Finder taps into that by representing every film on the site by its respective poster.

One anticipated issue was navigating myriad similar titles to efficiently ensure the user's input renders the correct poster. As the user types, results appear in real time beneath the search bar in the form of posters. When the correct poster appears, the user clicks on it to add that film to their list of five.

Another anticipated issue was duplicate recommendations. If the user enters five films from the same franchise, for instance, they would receive duplicate recommendations, perhaps even be recommended a film they have already entered. To avoid this, every film input by the user is pushed into an array called "arrayAgainst", and each possible recommendation is checked against that array before it is rendered. If that specific film already exists in the array, the algorithm moves to the next result, checking for its individuality. If it is indeed original, then the result will be rendered as a recommendation.

function renderUnique (films, container) {
    let i = 0;
    let x = 0;

    while (x < 2) {

        if (arrayAgainst.includes(films[i]["id"])) {
            i++
        } else {
            renderPosters(films[i], container)
            arrayAgainst.push(films[i]["id"])
            x++
            i++
        }
    }
}

Now, for the fun.

Enter five films and see which ten await!

Learning to Code and Thought Processes in the Brain

Michael Lobman — Mon, 29 Nov 2021 19:39:31 +0000

A few months ago, I began my coding journey...

I hope you can remember the beginning of your personal coding journey. If it was anything like mine, it involved many late nights, online tutorials, the thrill of seeing no errors in the console, and the frustration of seeing many errors in the console.

I expected the highs and the lows.

I did not, however, expect to begin thinking in terms of JavaScript functions.

It first hit me when I woke up in the middle of the night, trying to remember if I had locked the door. In the past, my attempts to recall had been rooted in trying to retrieve specific memories: "Did I leave my keys in the door?" / "Did I even leave the house today?"

But that fateful night, my groggy mind used another procedure to ascertain the door's state...

A function.

Something like this:

Admittedly, the function is neither elegant nor useful, but it illustrated to me how quickly programming alters the pathways in our minds.

The next morning, I found this article by Jill Rosen detailing a Johns Hopkins study that used fMRI scans to monitor the activity in programmers' minds as they read code.

Though researchers have long suspected the brain mechanism for computer programming would be similar to that for math or even language, this study revealed that when seasoned coders work, most brain activity happens in the network responsible for logical reasoning, though in the left brain region, which is favored by language.

This is consistent with MIT scientists' findings as reported by Anne Trafton.

Programming brain activity does not conform to those consistent with math or language but rather activates the multiple-demand network, which is associated with complex problem-solving- not unlike figuring out if your door is locked at 3:00AM...

Happy coding.