DEV Community: Brooks Patton

Use Transactions When Manually Accessing SQL Databases

Brooks Patton — Wed, 02 Oct 2024 22:02:11 +0000

Sometimes we find ourselves in a situation where we need to manually connect to the production database and change something. When we run into these situations we want to decrease the risk of causing problems as much as possible and this article will show you one way to do this: Transactions.

Normally SQL Transactions are a way to combine a bunch of related queries together into a single, transaction to the database. If any of them fail for any reason then nothing will be committed. We can use this same trick when manually working with a database, allowing us to make our changes, check our work, and only commit when we are sure that things are okay.

For this example let's set up a new Database. (I'll be using Postgres for this example, but I'll also be using the commands that are standard for SQL, they should work with other SQL based databases as long as they support Transactions). To begin with we'll create two tables as follows.

	Species
Primary Key	id INT
	name VARCHAR(10)

	Pets
Primary Key	id INT
	name VARCHAR(255)
Foreign Key	species_id INT

We'll create these tables using a Transaction in PSQL (The interactive shell for Postgres) this should work for your choice of interactive shell.

If you follow along, a couple of things to note. If you have an error with any of the commands in the Transaction, the entire Transaction will fail. You will need to run the ROLLBACK; command and then try again. We'll explore rolling back shortly.

postgres=# START TRANSACTION;
START TRANSACTION
postgres=*# CREATE TABLE species (
    id SERIAL PRIMARY KEY,
    name VARCHAR(10)
);
CREATE TABLE
postgres=*# CREATE TABLE pets (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255),
    species_id INT REFERENCES species (id)
);
CREATE TABLE
postgres=*# COMMIT;
COMMIT
postgres=# \dt
          List of relations
 Schema |  Name   | Type  |  Owner
--------+---------+-------+----------
 public | pets    | table | postgres
 public | species | table | postgres
(2 rows)

postgres=#

Note that in PSQL we are given a *= to show us that we aren't in normal mode, but inside a Transaction.

To finish the transaction and commit the changes to production we use the COMMIT; command. This immediately commits these changes to the database and are now available for use by other connections.

Let's try another transaction, but this time we'll make a mistake so that we have to rollback. We'll insert two pet's into our database, Xilbë the cat, and Ranger the dog.

postgres=# START TRANSACTION;
START TRANSACTION
postgres=*# INSERT INTO species (name) VALUES ('cat');
INSERT 0 1
postgres=*# INSERT INTO species (name) VALUES ('dog');
INSERT 0 1
postgres=*# table species;
 id | name
----+------
  1 | cat
  2 | dog
(2 rows)

postgres=*# INSERT INTO pets (name, species_id) VALUES ('Xilbë', 2);
INSERT 0 1
postgres=*# INSERT INTO pets (name, species_id) VALUES ('Ranger', 2);
INSERT 0 1
postgres=*# table pets;
 id |  name  | species_id
----+--------+------------
  1 | Xilbë  |          2
  2 | Ranger |          2
(2 rows)

postgres=*# SELECT species.name AS species_name, pets.name AS pet_name FROM pets JOIN species on species.id = pets.species_id;
 species_name | pet_name
--------------+----------
 dog          | Ranger
 dog          | Xilbë
(2 rows)

postgres=*# ROLLBACK;
ROLLBACK
postgres=# table species
postgres-# ;
 id | name
----+------
(0 rows)

postgres=# table pets;
 id | name | species_id
----+------+------------
(0 rows)

postgres=#

All of the commands were successful, but we made a data error that could only be caught by checking our work with a JOIN query. Running this allows us to catch that Xilbë has been entered as a Dog instead of a Cat. Xilbë would not be pleased so we rolled back the changes and therefore nothing happened in the database.

This shows the power of using Transactions in a manual setting, we can do our work, and then take time to check it all without having whatever we have done visible to any other connections to the database. Only when we are sure that we are ready do we commit it.

Learning Programming is Still a Good Idea

Brooks Patton — Mon, 12 Aug 2024 21:01:06 +0000

Recently, no matter where we go on the internet we'll see claims that it's a terrible idea to begin learning programming. And on the surface it's obvious why such advice is popular to give, AI tools like ChatGPT and CoPilot are gaining popularity and are getting better at writing code themselves. Why wouldn't we want to get ahead of the wave of automation and study something else? However I have my doubts on how good this advice is though.

A professional programmer in 2024 is expected to be able to do all of the following:

Write code
Create automated tests
Debug code that they wrote AND didn't write

In addition, programmers are also expected to do more than just programming. They will also be expected to:

Gather requirements from vague sources
Convert these into User Stories
Collaborate with technical AND non-technical team members
Manually test their own code
Estimate how long complex work will take
Learn new skills

These skills are crucial in todays world, where communication is a must when working in a team environment. Ironically, Large Language models like ChatGPT also require strong communication skills when working with them, making this skillset essential for the future as well.

And, as AI continues to become more present in our daily lives debugging skills will allow us to adapt to new AI model changes faster than our competition (be it other developers trying to get jobs or other companies leveraging AI as part of their products).

The ability to write code, or at least understand the code that AI writes gives us another edge. We'll be able to run the latest models, play with new technology and customize what is available to run better for us. If we revisit the tools already being used by programmers today I can see where both ChatGPT and Copilot can be customized to work with our coding styles and personalities. Meaning with some effort we can make them work with us a lot better than someone who is just using either tool straight out of the box.

These tools that we customize could help us by aiding in all of the steps I managed above. For example instead of writing the code the AI could be helping analyze the code that we write and suggest ways we could improve it. This brings the AI from replacement to partner.

I strongly believe that these are the reasons why learning programming is a great idea. However there is a caveat: if we stop learning, or we get complacent with our skills then we will wake up one day to discover our jobs automated away by tools we don't understand and can't use any better than everyone else.

Give tech layoffs, how long is it taking to hire devs?

Brooks Patton — Sun, 07 Jul 2024 03:41:39 +0000

Recently I became curious as to how the job market is for companies hiring developers. I wanted to look into this as I truly believe that it is more cost effective to train devs instead of hiring new ones. But I wanted to gather some data instead of just relying on my feelings (and of course I'm biased too).

My initial thought was the opposite of what I wanted to find though, that companies would be able to hire new developers quickly (within 3 months of starting the search) due to all the layoffs in the dev world that have been happening recently.

So I set up some polls asking my followers on LinkedIn, YouTube, and X how long it was taking their companies to hire a dev. I gave three options plus a fun opt-out option for anyone who wanted to answer the poll but not give a real answer. The options were.

< 3 months
3 - 6 months
> 6 months
companies are hiring?

I left the poll running for a week and we now have the results.

I got 117 responders to the poll, but 81 of them chose the companies are hiring? option, leaving 35 people across the other results.

Of these 35 people 20 reported that it was taking more than six months to hire a new dev. 10 were able to hire in less than 3 months, and 5 were in the middle.

I understand that this is a small sample size, and I didn't control to size, type, and/or region of the companies. I would love for someone with a larger audience to run the same poll and see if the numbers correlate.

That being said, the response is opposite of what I originally thought, which is that it's taking many companies more that 3 months to hire new devs. And we also know that just hiring is only the first step. Once hired devs are going to need to be onboarded into the company and the projects. This could take a long time as well.

Even with this smaller amount of data I'm more confident in my claim that a company that attempts to train their developers instead of laying them off to hire new developers with a different skillset is going to be cheaper in the short and long runs.

Observer Pattern in Rust

Brooks Patton — Mon, 15 Jun 2020 02:57:53 +0000

Recently I've been reading through the book Game Programming Patterns by Robert Nystrom while implementing the patterns into an infinite runner that I wrote in Rust using the GGEZ game engine.

Before starting the game patterns proper the first part of the book covers some of the classic design patterns in Object Oriented Programming. This includes the Observer pattern.

As a quick recap, the observer pattern is all about having an event happen in one area of the code, and that event triggering an action in another area of the code. In a traditional object oriented language this could be done by passing instances of objects around. These objects would have to be mutable since the actions that would be triggered almost always affect the objects internal state.

I have a working example of the code that I'm going to show, you can find it on my GitHub. I'm using a game of pong (well, more like work-in-progress part of a game that could be pong...eventually) written using GGEZ. This example is working, and while it isn't a playable game it does properly use the observer pattern.

With that, let's go through the code.

Sending an Event

Let's begin by examining how we are sending an event. In this case when the ball touches the left or right edge of the screen we'll want to send an event saying that the player or ai scored. I have an enum to cover this.

pub enum GameEvent {
    PlayerScored,
    AiScored,
}

The ball struct has a update function that is running every frame. It will check if the ball is touching an edge and will use the event system struct to send the event.

pub fn update(
    &mut self, 
    screen_width: f32, 
    screen_height: f32, 
    event_system: &EventSystem
) {
    // I have removed the code from this example to move the ball and 
    // bounce it off the top of the top and bottom of the screen. You
    // can view the code I removed at 
    // https://github.com/brooks-builds/observer_pattern_in_rust/blob/master/oop/src/ball.rs#L25

        if self.location.x + self.radius >= screen_width {
            self.velocity.x *= -1.0;
            event_system.notify(GameEvent::PlayerScored);
        } else if self.location.x - self.radius <= 0.0 {
            self.velocity.x *= -1.0;
            event_system.notify(GameEvent::AiScored);
        }
    }

This example shows that emitting an event doesn't require that the struct be aware that it is being observed. This will make it easy to add a lot of events throughout the code.

Let's move onto the observer of this event next, the score.

Observing an Event

I have the score as a struct that stores the ai and player scores respectively. It is also storing the Text drawables that will be displayed each frame to the screen.

pub struct Score {
    // I'm leaving out some of the non-essential information
    player: u8,
    ai: u8,
}

I'm also using a trait to mark that this structure is an observable.

pub trait Observer {
    fn on_notify(&mut self, event: &GameEvent);
}

It's a pretty simple trait, and while I could just add the on_notify function to the Score struct proper, I'm adding it through the trait to make it easier to add onto any structures that I want to turn into observers.

I've implemented the trait to watch for the events and increment the scores.

impl Observer for Score {
    fn on_notify(&mut self, event: &GameEvent) {
        match event {
            GameEvent::PlayerScored => {
                self.player += 1;
                self.player_text = Self::create_text(self.player);
            }
            GameEvent::AiScored => {
                self.ai += 1;
                self.ai_text = Self::create_text(self.ai);
            }
        }
    }
}

Now the score can do it's own thing and whenever it receives the player scored or ai scored events it will increment the appropriate properties and update the text that will be drawn to the screen.

We still have the problem of how we are going to have two mutable references to the same score available to the drawing system and the event system at the same time. The answer, of course, is to cheat and use a tool that is meant for something else entirely.

Enter Arc and Mutex

Arcs and Mutexes are often used together to allow multiple threads to have a mutable reference to the same instance of a struct. They do reference counting at run-time, so there is a slight performance hit but they guarantee that only one mutable instance will be mutable at a time. This is done using the lock method where the thread will be blocked until no other function is attempting to mutate the struct contained in the Mutex.

We're going to have to wrap our score struct in an Arc and Mutex and store it in the arena struct so that we can draw the score to the screen. Because any structs using the score need it to be wrapped, I'm wrapping it up inside the new static function on the Score struct.

pub fn new(screen_width: f32, context: &mut Context) -> GameResult<WrappedScore> {
        let player = 0;
        let ai = 0;
        let player_text = Score::create_text(player);
        let (player_text_width, _player_text_height) = player_text.dimensions(context);
        let ai_text = Score::create_text(ai);
        Ok(Arc::new(Mutex::new(Score {
            player_text,
            ai_text,
            player_location: Point2::new(screen_width / 2.0 - player_text_width as f32 - 5.0, 0.0),
            ai_location: Point2::new(screen_width / 2.0 + 3.0, 0.0),
            player,
            ai,
        })))
    }

The game arena simply stores the wrapped Score. It does have to unwrap it when it goes to call the draw method on Score though.

pub fn draw(&self, context: &mut Context) -> GameResult<()> {
        self.dividing_line.draw(context)?;

        {
            let score = self.wrapped_score.lock().unwrap();
            score.draw(context)
        }
    }

That lock method call is where the Mutex is blocking the thread to make sure that no other threads currently have mutable access to the instance of Score. Since this game is written in one thread we don't have to worry, we know that we will be the only ones that have access mutably or not, and it won't be for very long.

When we hand a wrapped score to the event system we aren't handing it a clone of Score, we are handing it a clone of the Arc that is holding the Mutex that is holding the Score. In memory, it is the same Score. This is how we can pass around instances of objects back and forth in Rust while maintaining the safety that the borrow checker gives us.

pub fn new(
        screen_width: f32,
        screen_height: f32,
        context: &mut Context,
        event_system: &mut EventSystem,
    ) -> GameResult<Arena> {
        let wrapped_score = Score::new(screen_width, context)?;

        event_system.add_observer(wrapped_score.clone());

        Ok(Arena {
            dividing_line: DividingLine::new(screen_width, screen_height, context)?,
            wrapped_score,
        })
    }

The proceeding code shows the arena creating the score, keeping a copy for itself and also registering a copy with the event system.

Handling the Events

Finally, let's take a look at the event system. It is storing the wrapped observers in a Vector, and looping through them to call the on_notify functions on them whenever an event is emitted.

However we don't want to have to be limited to just storing the Score, or any one struct that is acting as an observer. We want to be able to turn any struct into an observer in the future and have the event system just work. We can do this by using the trait that we added to the Score struct earlier. This will allow us to set the type stored as the trait instead of the struct.

pub struct EventSystem {
    wrapped_observers: Vec<Arc<Mutex<dyn Observer>>>,
}

The dyn keyword is using dynamic dispatch to get a pointer to the struct and then substitute that in at runtime. Of course this has a small runtime cost but it allows us to do what we want.

That was the last bit of magic to make this work, here is the full event system file in it's entire glory.

use std::sync::{Arc, Mutex};

pub struct EventSystem {
    wrapped_observers: Vec<Arc<Mutex<dyn Observer>>>,
}

impl EventSystem {
    pub fn new() -> EventSystem {
        EventSystem {
            wrapped_observers: vec![],
        }
    }

    pub fn notify(&self, event: GameEvent) {
        for wrapped_observer in self.wrapped_observers.clone() {
            let mut observer = wrapped_observer.lock().unwrap();
            observer.on_notify(&event);
        }
    }

    pub fn add_observer(&mut self, observer: Arc<Mutex<dyn Observer>>) {
        self.wrapped_observers.push(observer);
    }
}

pub trait Observer {
    fn on_notify(&mut self, event: &GameEvent);
}

pub enum GameEvent {
    PlayerScored,
    AiScored,
}

As I mentioned at the beginning, if you want to run the code, or look at it all at the same time then you can find it at [https://github.com/brooks-builds/observer_pattern_in_rust/tree/master/oop/src](https://github.com/brooks-builds/observer_pattern_in_rust/tree/master/oop/src)

I've been reading through the Game Programming Patterns book and implementing each pattern first in a JavaScript + P5.js infinite runner, and then a Rust + GGEZ infinite runner. If you liked what you read I'd love to hear from you. I'm streaming every weekday morning at 7:am Mountain Time for around an hour on Twitch.

I also have a YouTube Playlist of all the archived streams.

Thanks for reading and happy coding!

A Business is Like a Rope

Brooks Patton — Thu, 26 Sep 2019 01:23:46 +0000

When I first decided to go about the holistically learning the full-stack of businesses journey I reached out to one of my mentors that have made this journey before me. He gave me a metaphor for how products, and also businesses work that surprised me. Instead of the classic Business is like a house, it needs a good foundation he used Business is like a rope.

Let's take an aspect of business that many people focus on, the technical excellence of the product (in this case I'm focusing on software products). If the product or service isn't good, then snip, the rope is cut and it doesn't matter what comes after it. However because its a rope, a new rope can be tied on and we can try again. Maybe our product crashed constantly and corrupted data. We can tie on a new rope by fixing the bugs, creating a CI/CD pipeline to prevent them from occurring in the future, and of course, refusing to deploy when we know it will be a bad experience. The point is that when there is a problem and the rope is cut, we can't tie the next rope on until we fix the problem we are having.

This should make sense, it feels logical to me. However, my mentor continued to state that a common problem he sees, and I agree with, is that decision-makers in the company focus on areas of the rope that aren't their domain when there is a problem. The quality of the code-base doesn't matter if the rope was cut hight up the chain?

For example,

the product designers didn't interview potential clients and development created the wrong application? snip
the market shifted and now our customers want something similar, but not exactly what we provide? snip
There never was any market research and so the company built something that nobody was looking for? nothing to cut, the rope has been in freefall this entire time!

Why is this? My mentor's opinion is that many businesses culture is of my life is over if I'm wrong. Of course, if we cannot be wrong because we'll be fired then we cannot do anything other than defend our decisions...even if we know they are wrong.

To prevent this I am beginning my rope building adventure by practicing on myself. I'll be searching for the perfect place to put the eye bolt which the first section of rope will be tied to later. My mentor recommended the book The Lean Startup by Eric Ries to find where that eyebolt should be placed. From what I understand the plan will be to screw in the bolt to random metaphorical boards until one seems to hold.

This is the second article (you can find the introduction here about business here, are any of you interested in me continuing this series on Dev.to? Let me know with a comment. I plan to continue the adventure regardless but I also want to make sure I'm not adding noise where no-one is listening.

What Business Does a Dev Have in Business?

Brooks Patton — Sun, 22 Sep 2019 22:01:44 +0000

I've recently taken to thinking about leadership, businesses, and why many of them fail. And having finished the Phoenix Project novel about applying a more holistic approach to business towards an IT department I began wondering how to go about creating the utopia that the book seems to end with. If you haven't read The Phoenix Project, I highly recommend it, but if you want the TLDR version, here is a long sentence that doesn't give anything away.

The Phoenix Project is a fictional / how to hybrid novel describing how a company with a deeply flawed culture gap between IT, engineering, and the rest of the company can change how they work and in turn take a failing company to a wildly successful company in a very short time.

Of course, I want to work at a company that sees and treats the engineering department more than just a machine that produces the products that make money. Engineers are a clever bunch, we creatively solve difficult problems for a living. I believe that we could provide so much more value if we were invited to help solve some of the business problems rather than just a room full of MBA's.

Of course, that's crazy talk, right? Why would we want to step outside of engineering and into the political waters of the C-Suite?

For one, we might be able to fix the toxic culture that has developers and designers switching jobs every year or two. We might even be able to help more companies survive and thrive in an ever-changing marketplace. We might even build the right product for the customers and change people's lives.

I've seen far too many companies where danger is approaching, but the direction the company is looking is everywhere but that dark, stormy cloud. What is especially infuriating to me is that oftentimes (every time in my personal experience) the boots on the ground employees see the darkness coming, and even have really good suggestions that go unheard or worse, punished.

This is why I want to learn the full-stack of business so that I can have a holistic view, speak the language of every team, and hopefully, help some amazing companies succeed and do good to their clients and employees at the same time.