
![❄️](https://padilla-media.s3.amazonaws.com/blog/art/sketches-2024-08-17.jpg)

Dreaming of colder weather. ⛄️


Winter Tunnel


I've been between projects in Python, Java, and JavaScript. Aside from the syntax differences, I've been pausing to wonder why the context switch takes time.

The answer has to do largely with the programming paradigm these languages tackle programming challenges. 

There's a spectrum here between Functional Programming and Object Oriented Programming. While all three can manage both paradigms in this day and age, their communities favor being on different poiints along the spectrum:

- JavaScript leaning heavily towards functional programming
- Java towards Object Oriented Programming
- Python sitting in the middle with great support for both paradigms

If you've started in web development, more than likely functional programming is very familiar. So here I'll explore how to make the switch in thinking in an OOP way coming from that perspective.

## Functional Programming

At the risk of stating the obvious: FP is built around functions. These individual functions are not tied to an object. They take inputs, process those inputs, and return a result. 

```JavaScript

const add_then_multiply = (a, b, c) => {
	let res = a;
	res += b;
	res *= c;
	return res;
}

```

What my silly example demonstrates is how a function takes in a handful of arguments, calculates through them, and returns the result. Side effects are possible, but not desirable. This paradigm fits nicely with unit testing and TDD because it's simple to test. If I put in 1, 2, 3, I expect to get 9.

JavaScript takes this a step further by treating functions as first class citizens. A function can be passed into another function (referred to as a callback) and then call that function within its own procedural process.

To oversimplify the pros — we are namely looking at a process that thrives on specific calculations and processes. This can lend short programs to be easy to read and unambiguous. When avoiding side effects, there's no confusion around what the program is doing. 


## Switching to Object Oriented Programming

Functions exist in OOP, but the major difference is that they are tied to data. I'll sum up my case right here: If you're looking to switch your thinking between the two, start thinking about how groups of data need to operate and can interact with each other. This is different from thinking of only the functionality that needs to occur.

In Python, say that I have a representation of a web page. I want to encapsulate the data and some functionality around it in a class:

```python

class WebPage():
	def __init__(url: str, name: str):
		self.url = url
		self.name = name
		self.visits = 0
		
	def visit_url(self):
		# Open url
		
	def print_webpage_details(self):
		print(f'{self.name} at {self.url}')
		
	def add_visit(self):
		self.visits += 1

```

This simple example demonstrates the shift. Not only have I defined some functionality, but that functionality is primarily centered around manipulating and using the data that's present on the instance.

Imagine it multiplied by dozens of classes then. All with their own state and functionality.

In fact, if you've been writing React, you've likely already been thinking in a moderately OOP way! The execution is largely functional. Hooks are primarily event driven. But it's the encapsulation with state and methods that also blends a bit of OOP into the way React is written.

There's more complexity that can naturally be held this way. And the power comes from having some flexibility to employ both. A procedural script employing functional programming that leans on Objects to encapsulate large amounts of data and complexity is what most apps realistically employ. So it's not a matter of one or the other, but understanding what problem you're trying to solve and picking the right paradigm for the job.



Functional vs. Object Oriented Programming

Lucy Knows We'll Be Together Again...

Strauss - Blue Danube Waltz


![The way it flops! 😂](https://padilla-media.s3.amazonaws.com/blog/art/bocoblin_hat.jpg)

I just think this Moblin hat in Tears of the Kingdom is swell.


Moblin Mask


I've updated my blog home page to show posts in full instead of just the titles. I'm doing too much art and music making to let all that fun stuff hide behind a click!

I also found out I've posted over 200 times to this blog!! A great milestone! _And_ a fun performance issue to navigate with pagination. :)

![Hey Diglett!](https://padilla-media.s3.amazonaws.com/blog/images/Screen_Shot_2023-08-10_at_3.25.49_PM.png)

## Pagination

In a big picture sense, you need these things:

- Loads of data to render, like blog posts
- A way to query it
- A maximum number per page (the interval at which to show data)
- A way to keep track of which page you're on.

That translates to:

- Content
- API/DB Calls
- Limit value
- Skip value

## Calculating Skip

Skip value is the most interesting value up there. If you have a limit of 5 posts per page, you'll know your starting place if you know what page you're on. Page 1 will shows items 0-4, so there's no skip.

Page 2, however, starts at 5. So we can get this for each page by multiplying the page number minus 1 by 5.

```
const skip = limit * (page - 1)
```

From there, passing that to the DB will get you just the data you need.

## Getting Page State

Plenty of ways to do it, though the most user friendly is likely to keep it in your query params. Your url will look something like `/blog?p=2`. It has the benefit of allowing users to use the back button on their browser.

Here's how you can get that value in `getServerSideProps` in Next:

```
export async function getServerSideProps(context) {
  const page = context.query.p || 1;
  const count = getPostsCount();

  const skip = (page - 1) * 5;
  const allPosts = getAllPosts(
    {
      skip,
      limit: 5,
    }
  );

  return {
    props: { allPosts },
  };
}
```

`context` is passed from next with the query params (including any that you set yourself through the `[id].js` naming convention.) Very handy!

## Setting Page State

It's as simple as linking to the new url! First I'll get the current page through the client side router:

```
import { useRouter } from 'next/router';

export default function Blog({ allPosts, count }) {
  const router = useRouter();
  const query = router.query;
  const currentPage = parseInt(query.p) || 1;
  const lastPage = Math.ceil(count / 5);
```

And then I can use it in my links below.

```
<div className="pagination-controller" style={{ display: 'flex' }}>
  <div className="left" style={{ flex: '1' }}>
    {currentPage !== 1 && (
      <Link href={`${router.pathname}?p=${currentPage - 1}`}>Back</Link>
    )}
  </div>
  <div className="right" style={{ flex: '1', textAlign: 'right' }}>
    {currentPage < lastPage && (
      <Link href={`${router.pathname}?p=${currentPage + 1}`}>Next</Link>
    )}
  </div>
</div>
```

You'll have to do the math to add or reduce a page while ensuring you're not going out of bounds. Above I'm hiding the links based on the calculated `lastPage`.


New Blog Layout and Pagination


You guys, I'm just really jazzed about a piece of software over here.

I think for anyone that codes, there's just a _little_ bit of the person who organizes their sock drawer in us all. Organization and systems are a big part of the job. And so, our project management has that element to them too.

In that arena, Notion has just been SO pleasant to use.

# Kanban Board

My primary use for it is the board view. This alone has been huge, and maybe actually, this is more of a blog about why kanban boards are _the best_.

Let me set the scene: Jenn and I start our big game development project together. We're excited, energy is high, and we have lots of brain-space mutually for where things are and what our individual tasks are.

Then the project gets **BIG**. The list of features are long, a log of bugs crop up, and we don't have a unified spot to keep notes on individual features.

![Notion Board with Cards under Analysis, Development, and Awaiting Input](https://padilla-media.s3.amazonaws.com/blog/imgs/notionboard.png)

The beautiful thing about a board is that we can keep track of multiple features, ideas, and bugs. From a glance, we can see what's on deck for developing, researching, and giving feedback.

What's _especially_ cool about Notion's boards is that you can open the card up into its own document!

Say that Jenn makes a card called "Add Pizza to Inventory."

We have a comment function on the card where we can have a conversation over what toppings should the pizza have, when to add the pizza to the inventory, and so on.

Under that is space for writing on the document. Anything goes here - adding screenshots, keeping a developer todo list, keeping notes from research. So _all_ the details around that feature is kept in one spot.

What happens often is that we'll talk about an idea, leave it for months, and then have to come back to it. With a comment thread and notes from development, it's that much easier to pick it up and work on when the time comes.

# Guides and Meeting Notes

Notion is mostly marketed as one of those "everything-buckets", similar to Evernote or Google Drive.

I'm personally a believer in [plain text](https://sive.rs/plaintext) and just using your file system for note keeping. But, collaboratively, having a hub for all things project related is unbeatable.

On top of our progress with the board, we used documents for writing meeting notes and keeping track of guides for using Sanity. We both always have the most up to date info, as Notion syncs automatically with any changes either of us makes.


Chris Padilla/Blog

On This Day