DEV Community: Charlotte Bush

Telling (User) Stories

Charlotte Bush — Sun, 28 Apr 2024 20:04:54 +0000

One of my favorite things to ask my community of more established devs in networking conversations is “what do you wish new devs knew?” Answers have led to great conversations around building relationships with a team, managing workflows and expectations, and many have been around writing and developing user stories. The first time a dev friend told me that they were putting their user stories in Jira, I was gobsmacked, since in boot camp, we were taught that user stories were just something you could toss off into a readme.

According to my teachers, user stories were useful, but not central to design, and they could just go into the docs of an MVP (minimum viable product.) I get why we were told this (the what of development is often seen as more important than the how or the why, especially for new devs, and while I don’t necessarily agree with this approach, it does make sense) but as I’ve learned different (arguably better) practices, I thought I’d start to codify some of them here, so anyone else in a bootcamp can see what’s up and be a more user-focused developer from the jump.

What (and why) is a user story?

Note: In my research, it looks like many PM frameworks and styles (Agile, Scrum, Kanban, etc) list different technical components of user stories, which I want to acknowledge, but am still researching and won’t go into much here until I know more.

At its most basic level, a good user story says what the feature will do for the user, but not necessarily how, since that’s more prescriptive. You’d want to say “a user can create an account” but not “a user will create an account by submitting to the form which will then POST to the API.” That way, if you, the developer, build the account creation flow in a different way, you’re not totally boxed into a corner by your own user story.

From my conversations, I’ve gathered that a mindful developer who’s focused on the user will have as many user stories as there are features on the application, so every part serves a purpose and can be iterated on with clarity and intention. (I also suspect designing with user stories in mind is helpful to maintain a healthy scope for a project, but what I’ve been learning about managing scope creep is going to be a different blog post!) This all ties back to something called user-centered design.

What is user-centered design?

In my research, it looks like user-centered design is exactly what it says on the tin: design that considers the user through each iterative step of the process.

This makes a ton of sense to me, a developer with a background in theater, writing, and education, fields whose success depend on the experience of a “user.” Playwrights write for an audience even if that audience is just a single reader (fun fact: this type of play is called a closet drama) and we think about not just the what but also the how and why of each beat of a user’s experience of a play, making user stories integral. Teachers write each lesson plan to be a useful tool, and considering each student’s personal user story of a lesson is a process of inclusive learning design called differentiation. Even this blog has what some writers call a speech act, or a user story to justify its existence. I’m writing this post so that hopefully some dev even newer than me will see it and put their user stories into Jira or Linear and not clog up a readme with them, even if bootcamp teachers say so. If the blog doesn’t convince a reader, then I’ve failed to provide this user story. This is all to say that user-centered design seems like a really reasonable and helpful framework, one that developers who’ve worked in a non-tech field should be able to apply pretty easily to development. That said, if there are better frameworks for app design, I’d be happy to hear about them.

Ok, cool, so where do user stories live?

All the experienced devs I’ve spoken to have mentioned putting user stories into productivity tracking software like Jira, rather than in the docs of the application, like we were taught in bootcamp. I understand this as being largely for modularity (so you can be working one user story/task and a member of your team can be working on a different one simultaneously) and scalability (if your app blows up in popularity, you’ll need a lot more space for user stories than a readme can reasonably provide.) I know I’ll be moving user stories for my application, RXGnosis, into Linear and using them more as a checklist for future development and less as a demo or narrative for the users themselves. This will also help me make my GitHub documentation easier to read- a perk!

What should the actual users see?

Actual users don’t need to see user stories. Just because it’s about them doesn’t mean that it’ll help them to see it, just like seeing a recipe for a cake doesn’t affect your experience of eating it. What you, the person eating the cake, benefit from is a totally different set of information than a recipe would give you. You'd want to know the flavor profile, the potential allergens, and the price, for example. That information for web developers is more like a User Guide, and can live in the app’s user-facing docs.

I really hope this helps other new devs think about User-Centered Design, what user stories can do, and where they can live, so our new-dev documentation can be cleaner and more intentional.

Telling (User) Stories

Charlotte Bush — Sun, 28 Apr 2024 20:04:54 +0000

What (and why) is a user story?

What is user-centered design?

In my research, it looks like user-centered design is exactly what it says on the tin: design that considers the user through each iterative step of the process.

Ok, cool, so where do user stories live?

What should the actual users see?

I really hope this helps other new devs think about User-Centered Design, what user stories can do, and where they can live, so our new-dev documentation can be cleaner and more intentional.

Snapshots through the Prisma

Charlotte Bush — Wed, 10 Jan 2024 22:26:23 +0000

Well, the cliche "new year, new me" may not apply to me personally, but it definitely applies to my Flatiron final project. I spent my last month in bootcamp making a patient advocacy tool for mental health prescriptions, and I'm really excited to deploy it and give it to its eager beta testers (and hopefully show it to some prospective employers!) That said, it's in dire need of some new years' TLC if I want to get it to that point. On the agenda:

~~1. Finding a good ORM library~~
~~2. Installing it, with node and express~~

Converting the ORM models, seed logic, relationships, auth, and backend routes from Python, Flask, and SQLite into something more easily compatible with Postgres
Setting up the Postgres docker image
Updating the readme to reflect all the changes (I love good docs!)

So far, I'm about halfway through my list, converting my backend from my beloved Python into my uneasy new frenemies Typescript and Express. I found a cool new ORM to help manage everything, which is adding another mean girl to the Plastics' cafeteria table: Prisma.

Things I've loved about Prisma: writing models and relationships is so much more concise. A models.py file that took a hundred or so lines in Python (it was the association proxy stuff, I'm sure of it!) became a 50-line schema.prisma file.

Things I've hated about Prisma: the syntax feels like a hybrid of Python's more intuitive grammar and Javascript's finicky logic, and it definitely has a learning curve.

Today's adventure was wrapping up the search routing for my capstone app, which once I got the hang of, Prisma had a variety of tools to help me use to make it a little easier to offer users even more functionality than I'd originally planned. Let's get into it!

The first thing I noticed was that all the concision of writing models in Prisma totally vanished while I was writing routes. In Python, the GET request for my search functionality was about ten lines:

class MedicationsByName(Resource):
    def get(self):
        query= request.args.get("q")
        medications = Medication.query.filter(
            Medication.name_brand.ilike(f"%{query}%")
            | Medication.name_generic.ilike(f"%{query}%")
        ).all()
        return make_response([medication.to_dict(rules=("-faves","-treatments", "-conditions")) for medication in medications], 200)  

api.add_resource(MedicationsByName, '/medications')

In Prisma, if I pasted the whole of my GET request in here, it'd make this blog unreadably long. It's something like 80 lines, mostly of opening and closing curly brackets, which makes it feel more verbose than it actually is.

Once I got over that initial annoyance, though, I found out something cool. Prisma's model queries and filter conditionslet you essentially wire up a search GET to look for more than one model property at once. While you can also do this in Python, Prisma made it surprisingly elegant today!

  where: {
        OR: [
          {
            nameBrand: {
              contains: query,
              mode: "insensitive",
            },

I used Prisma's "where" and "or" to essentially tell my search GET "hey, go back to the seed data, and look for the following fields in each object." Where in Python I was pretty much just letting users search for medications by name (brand or generic) I can now let users search for all types of attributes of their medications with a few quick keystrokes including side effects and other conditions that the medications can treat.

On top of that, adding:

mode: "insensitive"

to the search objects allows the GET request to query my yaml database accurately regardless of the casing of the search terms. I also added Full-Text Search to my "side effects" search routing so that my GET request can more easily go through the big wall of text that is side effects data in my database.

I know I have a long way to go learning this new framework, but I picked up something really cool today, and was able to use it to make my search functionality more useful for my app's eventual users! Thanks, Prisma!

How to Be Your Own PM, Make Friends (With Deadlines) and Influence People (Mostly Yourself)

Charlotte Bush — Thu, 09 Nov 2023 00:28:15 +0000

With bootcamp winding down, I found myself at a loss for what to write about here. Do I want to go into detail about my capstone project, and all the new technologies I learned to execute my vision? Do I want to take time to break down a key feature of Flask-SQLAlchemy that I had to learn on the fly to make my backend seamless? Or do I want to zoom out and get a little more reflective?

To answer my own (mostly rhetorical) questions, I think I'd prefer to zoom out a little for now, and think about the how of executing both my capstone project and that cool Flask-SQLAlchemy feature (both of which I'll probably go into greater detail about here soon.)

A part of my development process over the past month that I'm particularly proud of is the way I worked as my own Project Manager to create a full-stack, multi-page, cool-looking (if I do say so myself) and bug-free (mostly) application on time and with minimal stress.

I get the sense as a new dev that Project Management isn't a skillset that's seen as "technical" in the industry, an erroneous perception that I think is filled with all the inherent gender biases around "hard" and "soft" skills. As someone who's been on un-PM-ed projects with other new devs, software development without Project Management can sometimes be a clown show. With these things in mind, I'd love to talk you through some tools I used to manage my project successfully.

Scoping The Project

The first thing I did to set myself up for success was to outline a few different "ideal" versions of the project: one with all the stops pulled out that went above and beyond, a "scaled back" option with a handful fewer bells and whistles, and a utilitarian option that did the bare minimum. While the final product I demonstrated to the class had elements of all three plans, the process of outlining the options was very helpful for deciding what MVP (minimum viable product) should be. (I also included the "scaled back" option in my readme to show anyone who looks at it that I was mindful of scope and time constraints.)

Sprint Planning

We were given about two and a half weeks to pitch, plan, execute, and present our projects. I knew that without an outline of tasks and a clear sense of allotment of time, I would easily get distracted. And as cool as a Trello board would be, it might not be enough this time. After some research, I was recommended Linear.app, and I've never looked back. I love the clean and intuitive UI, and how easy it is to assign tasks different "cycles" (their word for sprints.) Using Linear and my own notes about scope, I was able to assign different tasks to their own weeklong "cycles" and stay mostly on top of my goals.

Another cool thing about Linear is that it can graph out your productivity by cycle and show you how many of your goals you've met in each sprint. This was really helpful for the next step.

Estimating Time (...and re-estimating)

I had frequent check-ins with myself (basically a one-woman retro meeting) using the graph feature on Linear and my list of still-open to-dos. In these checkins, I'd look at how long I'd spent on certain tasks and re-evaluate if my initial estimations of time were still accurate. I was proud to see as the project progressed how much more accurate my estimations of task length became.

Forgiving Yourself

While my estimation skills definitely improved over the course of the project, they weren't perfect. There were a handful of times I wanted to deliver on a task and found myself running out of time. While holding myself accountable, I became better equipped to forgive myself and (when possible) grant myself more elbow room. Additionally, by starting scaled-back but keeping my blue-sky vision in mind, I was able to pull many of my stretch goals in after completing my MVP.

Other Miscellaneous Helpful Things

Making sure all my commit messages were clear and descriptive and that new code sections had brief comments describing intent (aka the "Memento" school of software engineering) was really helpful for staying on top of goals and remembering what had already been done.

These are a few of my most helpful project management tips from this project; I'd love to hear more about yours in the comments! I'll probably blog here more about my project soon.

Serializing America’s Next Top Model (Class)

Charlotte Bush — Sun, 15 Oct 2023 20:27:01 +0000

Delving into backend dev has been fascinating. I love thinking about how data is organized and displayed, and how it “talks” to other data and servers, so this was a fun time for me. As I began to learn more, though, I realized I had a ton of questions about serialization, so I wanted to create an explainer based on some of my own questions.

What is serialization?

Serialization is just the process of converting a data object into a format suitable for transmission and storage. From a practical standpoint, this means it takes in an object and turns it into a giant string that you can send over the internet or store in a database or file. So far, so good. In Python, we serialize with functions like jsonify() whereas in JavaScript we use JSON.serialize.

So wait, if there’s a serialization, does this mean there’s a deserialization?

Deserializing is the opposite and equal reaction of serialization (that makes sense so far) done with things like JSON.parse(), and transforms data back into real objects. Any time you deal with data sent over the internet or stored in a database, you’re doing serialization AND deserialization.

What do we use serialization for in Flask?

When you integrate SerializerMixin into your Flask-SQLalchemy model classes, you can make your models serializable, which in turn makes the data within them (as a blog I found says) “compact, platform-independent, and easy for platforms and humans to read!”

Note: In the example below, SerializerMixin is the first argument in the model class, and has been imported “offscreen” at the top of the file like so:

from sqlalchemy_serializer import SerializerMixin

How do we do serialization?

If you have an instance of a model class, you can use a method like to_json() or add rules into a to_dict (by saying instance.to_dict(rules=(“-excluded_thing”,))) to serialize on a more individual basis, but you can also serialize on a broader level first inside the class itself. When you define a model class, you can use a property like serialize_rules to specify which fields to exclude from the default serialized representation of the model. In this example, we’re defining a class and showing its one-to-many relationship with another, while also indicating via serialize_rules that we don’t want to see certain things returned in API calls. In this case, we’ll see the orders affiliated with each deli but not the other delis’ orders affiliated with those orders (which would be, in technical terms, a recursion hellscape.)

class Deli(db.Model, SerializerMixin):
            __tablename__ = 'delis'

            id = db.Column(db.Integer, primary_key=True)
            name = db.Column(db.String)
            signature_sandwich = db.Column(db.String)

            # Add relationship (deli has many customers through orders)
            orders = db.relationship(
                "Order", backref="deli", cascade="all, delete-orphan")

            # Add serialization rules
            serialize_rules = ("-orders.deli",)

What’s that weird comma doing?

Serialization rules are tuples (aka a sequence of immutable objects separated by a comma and enclosed in parentheses) and tuples always have commas, even if there’s only one value in there. If you don’t include the comma, Flask-SQLAlchemy will raise a TypeError exception indicating that currently, serialize_rules isn’t a tuple, but it has to be.

Why write serializer rules?

If you want to see customized parts of a data set, or avoid seeing recursive or redundant (or just unhelpful) portions of a data set, you’re gonna want to change how the data gets serialized. Check out the following example of models:

from flask_sqlalchemy import SQLAlchemy
        from sqlalchemy_serializer import SerializerMixin


        db = SQLAlchemy()

        class User(db.Model, SerializerMixin):
            __tablename__ = 'users'

            id = db.Column(db.Integer, primary_key=True)
            name = db.Column(db.String)
            email = db.Column(db.String, unique=True)

            # Add relationship (has many posts)
            posts = db.relationship("Post", backref="author")

            # Add serialization rules (don't show people's passwords!)
            serialize_rules = ("-password",)

        class Post(db.Model, SerializerMixin):
            __tablename__ = 'posts'

            id = db.Column(db.Integer, primary_key=True)
            title = db.Column(db.String)
            content = db.Column(db.Text)

            # Add relationship (belongs to one user)
            author_id = db.Column(db.Integer, db.ForeignKey('users.id'))

            # Add serialization rules (don't show comments by default)
            serialize_rules = ("-comments",)

        class Comment(db.Model, SerializerMixin):
            __tablename__ = 'comments'

            id = db.Column(db.Integer, primary_key=True)
            content = db.Column(db.Text)

            # Add relationship (belongs to one post)
            post_id = db.Column(db.Integer, db.ForeignKey('posts.id'))

            # Add serialization rules (no rules)
            serialize_rules = ()

In this example, we’re serializing specifics that are integral to privacy, like not seeing a password or comments affiliated with a post. You can also get a little more interesting with serialization to prevent users from seeing a recursive data spiral, like so:

from flask_sqlalchemy import SQLAlchemy
    from sqlalchemy_serializer import SerializerMixin


       db = SQLAlchemy()

    class Deli(db.Model, SerializerMixin):
         __tablename__ = 'delis'

         id = db.Column(db.Integer, primary_key=True)
         name = db.Column(db.String)
         signature_sandwich = db.Column(db.String)

         # Add relationship (deli has many customers through orders)
         orders = db.relationship(
         "Order", backref="deli", cascade="all, delete-orphan")

         # Add serialization rules (-orders.deli,)
         serialize_rules = ("-orders.deli",)

         # Add validation for name
         @validates('name')
         def validate_name(self, key, name):
             if name and len(name) >= 1:
                 return name
             else:
                 raise ValueError("Must have valid name attribute")


    class Customer(db.Model, SerializerMixin):
        __tablename__ = 'customers'

        id = db.Column(db.Integer, primary_key=True)
        name = db.Column(db.String)
        allergies = db.Column(db.String)

        # Add relationship (visits many delis through orders)
        orders = db.relationship(
        "Order", backref="customer", cascade="all, delete-orphan")

        # Add serialization rules (-orders.customer,)
        serialize_rules = ("-orders.customer",)

    class Order(db.Model, SerializerMixin):
        __tablename__ = 'orders'

        id = db.Column(db.Integer, primary_key=True)
        name = db.Column(db.String)

        # Add relationships (foreign keys for customer and deli)
        customer_id = db.Column(db.Integer, db.ForeignKey("customers.id"))
        deli_id = db.Column(db.Integer, db.ForeignKey("delis.id"))

        # Add serialization rules (deli.orders, customer.orders)
        serialize_rules = ("-deli.orders", "-customer.orders")

How do we know what to put in the serialize_rules tuple?

So this is really cool and all, but how do we know what to put into the tuples? Is there a rule for the dot notation? What am I actually saying when I type ("-orders.customer",) or ("-deli.orders", "-customer.orders”)?

In the model class Customer that I defined above, the relationship is defined as being between Customer and Orders (the intermediate table.) So when you serialize to avoid the recursion spiral of doom, you only want to see the orders affiliated with a specific instance of a customer, and no other customers, even if they have the same order. That’s why the serializer rules for this class is ("-orders.customer”,). Without that dot notation, you could see that Customer A ordered a bacon-egg-and-cheese, but also a bunch of other customers who also ordered it, like Customer B, Customer C, and Customer D, which a) isn’t relevant to our data interests and b) makes Flask-SQLalchemy unhappy. So we code efficiently and throw a serialize rule in there to make sure we only see relevant information for that model.

On the intermediate table in the earlier example, Orders, the tuple has two excluded fields, ("-deli.orders", "-customer.orders”). This means that when we look for orders affiliated with a specific deli or customer, we won’t see the other orders that deli or customer has. This keeps our data specific, relevant, and non-recursive, and our code functional and free of the dreaded “Recursion Limit Exceeded” errors.

Will serializer rules affect how data is stored in the database?

Nope! These rules don’t affect the database, just how the data is presented in your APIs. You’ll still be able to retrieve and sort through it in all its big messy glory, even if you use serialization rules to make it more organized on the backend.

What happens if we don’t serialize data in a RESTful API?

The short answer is: nothing good. Here are some examples of what can happen:

The client might not be able to parse the raw data. (This can cause crashes.)
The client might be exposed to sensitive information that should be protected. (This can lead to users getting sensitive information leaked or exposed)
The data might be too big to be transferred efficiently and take a while to load in the client
If the raw data isn’t formatted in a way the client can “understand” it might not be displayable at all.

Don’t want to see these things happen? Serialize, serialize, serialize.

Works cited:

S. Stevens, “Flask+SQLAlchemy Serializer: A Comprehensive Guide to Serialization,” Medium, Aug. 08, 2023. https://medium.com/@seanstevens729/flask-sqlalchemy-serializer-a-comprehensive-guide-to-serialization-aec8eeb8b456#:~:text=Serialization%2C%20the%20process%20of%20converting (accessed Oct. 15, 2023).
“Python Recursion Errors & Serializer,” DEV Community, Jun. 05, 2023. https://dev.to/jvaughn619/python-recursion-errors-serializer-2kh8 (accessed Oct. 15, 2023).
S. radha krishnan, “Python Serialization and Deserialization in Flask SQLAlchemy,” Medium, Oct. 11, 2023. https://medium.com/@srimathiradhakrishna/python-serialization-and-deserialization-in-flask-sqlalchemy-c2ff09d69677 (accessed Oct. 15, 2023).
“API — Flask Documentation (3.0.x),” flask.palletsprojects.com. https://flask.palletsprojects.com/en/3.0.x/api/

Top Model Memes:

“Americas next top model,” Imgflip. https://imgflip.com/i/82ntne (accessed Oct. 15, 2023).
“Tyra Banks,” Imgflip. https://imgflip.com/i/82nu69 (accessed Oct. 15, 2023).
“Tyra Banks,” Imgflip. https://imgflip.com/i/82nuhn (accessed Oct. 15, 2023).
“Miss J Alexander,” Imgflip. https://imgflip.com/i/82nyz5 (accessed Oct. 15, 2023).

No One Expects the self._spanish_inquisition (Because it’s protected)

Charlotte Bush — Fri, 22 Sep 2023 20:58:23 +0000

Phase three of bootcamp has been an intro to Python. I’ve appreciated so much about it, from its relatively humane syntax to its modularity, to the way list comprehensions let me make this joke:

As I delved into learning about Object Oriented Programming, I started noticing a pattern in the error messages I was getting, and I got curious. Whenever I created a property with a setter, a getter, or attributes, it would throw an error and return an infinite loop.

(A sample photo of the errors I got on a mock code challenge last week)

In this sample, the code I was writing that threw the error was:

@property
  def price(self):
    return self.price

Eventually, after a very frustrated 20 minutes of trial and error, I added a protected attribute indicator, like so:

    @property
      def price(self):
       return self._price

and the recursion errors stopped, but I was left with the lingering question of why. Why did all attributes in setters and getters in Python OOP want to be private or protected? I’d heard that in languages like Java, the private keyword does what __ does in Python (private is two underscores, and protected is one) and if the folklore says that Python was created to solve Java’s problems, what problem does the __ and _ solve?

Well, __private and _protected attributes do a few things, some more obvious than others. Their chief weapons (other than fear and surprise, of course) are:

Preventing direct access to an attribute without additional logic being performed. This could be really useful if you need users to do additional validation or logic before setting a value, like a password.
Ensuring the attribute is always used in a consistent way, or returned in a specific format.
Making it easier to change the internal implementation of a class without breaking something external, like a database record or an API. (I suspect this wasn’t the problem I ran into in my mock code challenge, though.)

I also bumped into a principle of OOP called Encapsulation, which aside from sounding like a molecular gastronomy technique, boils down to the idea that keeping data and their methods in one place makes them harder to access (and therefore modify and otherwise futz with) unintentionally. It forces modularity and intention, both of which are hallmarks of OOP. It also reminded me of all my adventures with functional and local scope in JavaScript, which was a fun blast of nostalgia.

A Digression:

For the curious at home, I followed the rabbit hole to find the other principles of OOP in Python. Other than Encapsulation, we have:

Inheritance: the idea that an object can inherit methods and properties from another, as in the case of parent and child classes. An example of this:

   

    # parent class         
    class Person():
      def __init__(self, name, age):
        self.name = name
        self.age = age

      def display(self):
        print(self.name, self.age)

    # child class
    class Student(Person):
      def __init__(self, name, age):
        self.sName = name
        self.sAge = age

Polymorphism: the idea that a function or object can be used in multiple ways. A simple example of this is that you can use the + operator on both integers and strings in Python. When you see polymorphism in OOP, it’s generally paired with inheritance, allowing child class methods to override methods inherited from the parent when called with the child class object (aka method overriding.) In doing this, you can still access the methods of the parent, but you’ve effectively modified it to better meet the needs of the child. And finally:
Abstraction: the core of this principle is streamlining processes by only showing users details necessary to their experience. This usually gets achieved in OOP by having a base class and subclasses.

So I know now why Python wouldn’t want me to use a public attribute with a getter or a setter, and why it’d throw errors, but why was my code throwing those infinite recursion errors and not just regular syntax errors?

Turns out, the recursion happens when you try to access a public attribute from within the getter or setter method of a property. This is because Python will try to call the getter or setter method again, which will lead to infinite recursion. The reason for this? The names of both method and attribute are the same, so the infinite recursion is from Python thinking it needs to call itself over and over and over.

Check out this example:

           class MyClass:
            def __init__(self):
                self.name = "Charlotte"

            @property
            def name(self):
                return self.name
             @name.setter
                    def name(self, name):
                        self.name = name

        my_class = MyClass()
        print(my_class.name)

This throws the “recursion limit exceeded” error from earlier, because name is the name of the method AND the attribute. Python gets confused (much like me) when names are messy like this. So throwing in a private or protected marker differentiates the attribute from the method, and prevents the infinite, test-breaking recursion. You’d fix the code in the above example like so:

          class MyClass:
            def __init__(self):
                self.__name = "Charlotte"

            @property
            def name(self):
                return self.__name

            @name.setter
            def name(self, name):
                self.__name = name

        my_class = MyClass()
        print(my_class.name)

By making it private in this case, my_class.name becomes non-recursive!

And my final attribute privacy question: Is it better to use a private or a protected attribute?

This led me to exploring the difference between private and protected attributes. After the recursion error merry-go-round, I was expecting something weird as an answer, but it turns out the key difference is one of inheritability.

As Justin Ellis defines on his blog: “private (_)means that the attribute/method can only be used inside the class where it is defined. Protected () means that the attribute/method can only be used in the class where it is defined or its subclasses.” That subclass access makes all the difference, and I can see the appeal of protected attributes in the appropriate context.

Whew! If you’ve made it this far, thanks for reading this long, strange trip of a blog. Tldr;

What does making attributes and classes private (or protected) actually do?
What are the 4 principles of OOP in Python?
Why do public attributes in setters and getters throw recursion errors (and regular not syntax errors)?
Are private or protected attributes better to use?

I hope this helps!

Works Used:

“Image tagged in what is your name,” Imgflip. https://imgflip.com/i/7zztzs (accessed Sep. 22, 2023).
“Nobody Expects the Spanish Inquisition Monty Python,” Imgflip. https://imgflip.com/i/803cpn (accessed Sep. 22, 2023).
“Encapsulation in Python - GeeksforGeeks,” GeeksforGeeks, Oct. 15, 2019. https://www.geeksforgeeks.org/encapsulation-in-python /
“Python: The four pillars of Object-Oriented Programming,” www.linkedin.com. https://www.linkedin.com/pulse/python-four-pillars-object-oriented-programming-benjamin-b-phiri/ (accessed Sep. 22, 2023).
“Access Modifiers in Python,” Justin A. Ellis, Jan. 15, 2022. https://jellis18.github.io/post/2022-01-15-access-modifiers-python/#:~:text=Private%20vs%20Protected&text=It%20will%20actually%20raise%20an (accessed Sep. 22, 2023).
“Image tagged in and now for something completely different,” Imgflip. https://imgflip.com/i/803c57 (accessed Sep. 22, 2023).
“Help! Help! I’m being repressed!,” Imgflip. https://imgflip.com/i/803ci0 (accessed Sep. 22, 2023).
“Ministry of Silly Walks,” Imgflip. https://imgflip.com/i/803d5k (accessed Sep. 22, 2023).
“Image tagged in monty python viking,” Imgflip. https://imgflip.com/i/803gu1 (accessed Sep. 22, 2023).
“BBC Radio 4 - Front Row, Terry Gilliam and Edward Gardner, Joshua Ferris, Clean Bandit, Terry Gilliam Animations for Monty Python’s Flying Circus - Artwork by Terry Gilliam of a woman looking in a mirror.,” BBC. https://www.bbc.co.uk/programmes/p02067rh/p02067gc (accessed Sep. 22, 2023).

Side Effects: React, uh, Finds a Way

Charlotte Bush — Thu, 31 Aug 2023 21:48:12 +0000

Learning React after vanilla Javascript has been mind-bending. Working in React after weeks of trying to wrangle the DOM by hand is like realizing you can get a laugh with a clever movie reference, not having to do a whole long setup and punchline.

[1] “Welcome to Jurassic Park,” Imgflip, https://imgflip.com/i/7xmixa (accessed Aug. 31, 2023).

I was particularly fascinated during this phase of boot camp with the idea of functional components, or (to explain it to my two-weeks-younger self) what if functions, but on a scale that’s somehow smaller (one function per component makes things a ton more modular, and scope becomes easier to define) but also a whole lot more expansive.

[2] “That’s a big,” Imgflip, https://imgflip.com/i/7xm2h7 (accessed Aug. 31, 2023).

So, my adorable two-weeks-younger self wonders, what happens if you need to do something out of scope of the component? In vanilla JavaScript, you have a handy tool called a “closure” that lets you access an outer function’s scope from an inner function, like so:

function secretPassword() {
          const password = 'velociraptor93';
          return {
            guessPassword: function(guess) {
              if (guess === password) {
                return true;
              } else {
                return false;
              }
            }
          }
        }

        const passwordGame = secretPassword();
        passwordGame.guessPassword('clevergirl'); // false
        passwordGame.guessPassword('velociraptor93'); // true

Apart from terrible password design, what this example shows is the closure function guessPassword getting exclusive access to the secret password. So what happens if you need to do something like this, outside of function scope, in a react component?

The short answer? Side effects. Whether you know it or not, you’ve been using these bad boys in React to ensure that anything you want done outside of the scope of the functional component gets done, from making an API call, to setting up a subscription, to manually changing the DOM. The “side” part often gets omitted, making their reach in our code easier to notice (I see you there, useEffect.)

I started wondering why these actions, which in vanilla Javascript were something of the main event, are now relegated to being classified as side effects. To understand why this linguistic snub of naming happens, we have to start thinking more about functions.

In our earlier Jurassic Park meme, we did think about react components as big functions, taking in inputs (usually props) and returning JSX (that piquant mix of HTML and JavaScript we’ve come to savor.) These functions can be thought of as pure if, given the same inputs, they deterministically produce the same result. So far, so testable, right? Here’s where sideEffects come in.

Side effects are thought of as “unpredictable” because they interact with the outside world, like an API, the DOM, or really anything outside a specific render of the functional component. That said, because we don’t necessarily control what’s outside of the component, the results are regarded as potentially:

[3]Ytimg.com, 2023. https://i.ytimg.com/vi/TRQp5x1iQEk/maxresdefault.jpg (accessed Aug. 31, 2023).

Enter, useEffect, which handles side effects in what would otherwise be pure React components. Much like a pack of raptors, performing a side effect (like a fetch get request) by itself would get in the way of our component’s rendering. To horribly paraphrase the OG Jurassic Park, you can do it, but you shouldn’t.

[4] “Jurassic Park Raptor,” Imgflip, https://imgflip.com/i/7xmhzy (accessed Aug. 31, 2023).https://imgflip.com/i/7xmhzy

useEffect(() => {
                fetch(raptorURL)
                  .then((r) => r.json())
                  .then((data) => setRaptorData(data));
              }, []);

Using useEffect on a fetch request like this one allows us to get the benefits of the side effect (hello, API data!) while still preserving the purity of the component’s render. In this example, the component will render a second time once the data has returned. Both of these renders are still being mediated by the useEffect. Sounds like a clever girl to me!

Works Used:

“The React useEffect Hook for Absolute Beginners,” freeCodeCamp.org, Mar. 01, 2022. https://www.freecodecamp.org/news/react-useeffect-absolute-beginners/ (accessed Aug. 31, 2023).
“Using the Effect Hook – React,” legacy.reactjs.org. https://legacy.reactjs.org/docs/hooks-effect.html#:~:text=Data%20fetching%2C%20setting%20up%20a (accessed Aug. 31, 2023).

Cover Image:
‌
[1]People.com, 2023. https://people.com/thmb/ZaDCClsPoc1buDSzf6biAdXhLJo=/1500x0/filters:no_upscale():max_bytes(150000):strip_icc():focal(999x0:1001x2)/jurassic-park-watn-tout-2000-26d6d3b1e08f458889f9497772ab477c.jpg (accessed Aug. 31, 2023).

.then((playDominion)=>

Charlotte Bush — Fri, 11 Aug 2023 20:55:53 +0000

As a hatchling dev early in my bootcamp career, I’m constantly on the lookout for new metaphors to help rewire my brain and make it all make sense. One that’s been a helpful scaffold for me as I get deeper into JavaScript is thinking about it in terms of my favorite classic deckbuilder, Dominion.

A little about Dominion: it’s a very rad, much-expanded game from 2008. You play by building a deck and drafting a hand out of a bunch of different types of cards. On paper, at least, you win by getting the most victory points, but how you get there can be (much like a certain programming language) a little more…dynamic.

Starting to learn JavaScript, with its multiple ways of saying, doing, or making the same things, really reminded me of Dominion, initially from the parallels between chaining functions, and action cards, but once I started thinking about it, the similarities just kept coming. Let’s talk about a few in an internet-friendly numbered list:

Setup: On the most basic level, drawing and prepping your hand before play (especially if that round of play is a bunch of chained action cards) is the tabletop equivalent of declaring variables before outlining some functions with them.
Functions and Actions can both be chained, even with other (code/card) blocks: When I first started trying to write in JavaScript, the idea of calling a function as the logic of an event listener that is itself nested inside yet another function was a little brain breaking until I thought about it like Dominion, where as long as you have actions, you can “chain” action cards.

append() and the vassal If in this metaphor, the DOM is like the current field of play, any card like the vassal (which lets you draw the top card from your deck and play it if it’s an action) append to it outside of regular actions (functions) feel pretty similar to append().
Closures and Harbingers Is something out of scope? Maybe if you use a closure (in this case one of the cards that lets you go back into your discard pile, like the harbinger) you can get access to cards/variables that you otherwise wouldn’t!
Reactions and .thens reactions (like moat) often are immediate responses to other cards, like attacks, and can be chained with other actions, the same way a .then at the end of a fetch request can have a rendering function nested inside.

Sequence of Execution JavaScript, like Dominion cards, needs to get resolved in the order it’s written/played (unless you have sneaky workarounds, like the “defer” script attribute, moving your script tag to the bottom of or the harbinger or the spy, both of which “disrupt” the expected sequence of draw, play, and discard.

Function and Variable Delete The same way functions and variables are deleted on page close, dominion hands are lost after they’re played. (This one’s kind of an easy comparison, I suspect)

I hope these analogy explainers were as helpful for you as they are for me, and if there are any that I missed or could've explained better, leave them in the comments- I'm excited to keep learning!

Works Used:

“List of cards,” List of cards - DominionStrategy Wiki, https://wiki.dominionstrategy.com/index.php/List_of_cards (accessed Aug. 10, 2023).
D. X. Vaccarino, “Dominion.” 2008. Rio Grande Games, Placitas, NM. (Accessed August 10, 2023).
N. Knutsen, “Complete Rules for Dominion and All Its Expansions,” Shuffles Public Rulebooks- Dominion, https://www.shufflestulsa.com/public/rulebooks/Dominion.pdf (accessed Aug. 10, 2023).