one programmer's thoughts

Arya Bhimani


While solving problems for this year's Advent of Code, there were
just a few things I wanted to note down that I learned from
solving some of the challenges!

To preface, I haven't been able to fully keep up with solving all the
challenges, but I will try my best to get to them!

# Storage can be cheap - CPU is expensive

Sometimes, we need to store stuff to reserve the CPU to calculate
new stuff. That means we may sometimes need to take up memory temporarily
in order for the CPU to perform newer tasks. As long as the memory usage is
temporary (or in some cases, permanent), we can store it pretty cheaply.

For example, in a lot of the tasks, the solution for part 2 depends on constraints
from part 1. So if we need part 1's solutions, we can run both solutions together in
sequence. If a situation has been already calculated once in part 1, we don't need to
run it again in part 2.

In Day 7 this time, we could specifically run the entire sample set with day 1's constraints,
and reuse the results to figure out day 2.

This can be seen as follows:

```
solved = []
unsolved = []

# part 1
input_values.each do |input|
  matched = process_part1(input)
  solved << input if matched
  unsolved << input if !matched
end

# part 2
unsolved.each do |input|
  solved << input if process_part2(input)
end
```

We solve for part 1, and then we only solve the remaining ones for part 2.
There's no reason to run through the entire suite of inputs for part 2.

In real life, this might end up being a database or a cache where you store things
that you need later - but don't want to calculate them again.

# Memoization

During some challenges, there are a lot of calculations you're doing.
Some of these calculations involve solving the same thing again and again.
In this case, you can memoize the results once, so you don't need to calculate them again.

This is in line with the previous section about storage being cheaper,
though memoization is short-lived a lot of the time.

In Ruby, we can use some built-in features to memoize a variable that can take
a long time to process again, and the result would be the same.

Memoization works really well for pure functions, where given the inputs are the same,
we will always get the same output.

If we consider this function in Ruby to calculate Fibonacci numbers, we would greatly benefit from
memoizing the results we calculate because they would come up over and over.

```
def fibonacci(n, memo = {})
  return n if n <= 1
  memo[n] ||= fibonacci(n - 1, memo) + fibonacci(n - 2, memo)
end
```

The differences here are staggering with, and without memoization.
Calling the following function: `fibonacci(42)`

- with memoization: `0.06s`
- without memoization: `24.35s`

This of course is an extreme example, but we have basically an
infinite performance gain, with just memoizing some values temporarily.

Also, I tried to run `fibonacci(100)` but ultimately got tired of waiting!

With that said, if you'd like to follow my progress after this, or just
check out my solutions, feel free to look at my GitHub repository:
[aryascripts/advent-of-code](https://github.com/aryascripts/advent-of-code)!

Note: these are definitely not the best solutions out there, so I'm open to
feedback about anything you find!


Things I've learned from Advent of Code, 2024.

Learnings - Advent of Code 2024


While reading book, I wanted to remember and take some notes, since this book is a classic.

Note: this is currently not spell-checked and written on a train ride.

# Key Concepts

## Tips
1. Care about your work: We feel that there is no point in developing software unless you care about doing it well.
1. Think! About your work: Never run on auto pilot. This is a lifetime practice to do.
1. Good Enough Software: this does not mean you skip on requirements. 
  It means that your software is good enough for your users, future maintainers, and your own peace of mind.
    - Include your users and the company in your "good enough software". Ask them what is it that they need from you.
    What can the company afford to do? It would be unprofessional to ignore these constraints.
1. Building Your Knowledge Portfolio - analogous to a financial portfolio. 
    - Invest regularly: invest in your knowledge regularly, even if it's just a small amount.
    - Diversify: You should know more different things, the more valuable you become. Computing world changes rapidly, and it's good to know the new technologies and adjust to change.
    - Manage Risk: technology is on a spectrum of risky, low-reward, and high-reward. Don't put all your eggs in one basket. Don't be good at just one thing.
    - Buy low, sell high: Learning new technologies early on can be of great value. You can learn earlier, and then get the benefits later once you becomde an expert.
    - Review and Rebalance: revisit technologies that you have learned before, or skipped on learning when it was new.
1. Choose your moment to share ideas: don't bring up irrelavent asks when it's a a really bad time for someone else.

## Challenges to Try
- Choose two "broken windows" and discuss with the team on the priorities, and how we can solve them. What are the benefits?
- Consider modularization of software. Can you ship smaller pieces in several milestones, and is that easier to deal with, than 1 monolithic release?

## People and Culture

- Team trust: you have to trust in your team, and make sure that you can be trusted by your team.
  In a healthy environment, you can can safely speak your mind.
- Take responsibility: and when yu do, make sure that you can be held to it. when you make a mistake, admit it and try to offer solutions.
  You don't need to take responsiblity for everything, though. Imagine impossible situations and don't take
  responsibility for those, when possible.
- Be the soldiers with the stone soups: Ask the entire village what should be in the soup (software), and then try incorporarting it in your design.
  With everyone's ideas, you can probably make something great, and it benefits everyone.
- Communication: communication is super important. If you can be the best developer, most pragmatic, and hace the best ideas, it still won't be successful if you can't communicate your ideas to others.

# Specific Concepts

## DRY Code

DRY is more than just code. It's knowledge, documentaiton, workflows, and more.
We want to reduce duplication across: internal APIS, external APIs, Data Sources (key/value store, hash, or external data), and functional programming

Make code easy to reuse. Make sure that the code you write is easy to use again by someone else, otherwise no one is going to do it.

# Personal Thoughts and Criticisms
- Some of the ideas mentioned here are not relavent anymore, for existing developers that are trying to grow in their career. For example, one tip that is mentioned is
  to have Goals. They're definitely super important, but the examples mentioned are not. One example was to "learn a new language every year" and I think this is not one
  that belongs with my career path anymore. You can learn any new language as it's needed, but software design principles are should be learned as you go along.
- DRY Code: The book explains DRY as one of the core concepts, and that's amazing in an academic setting and "perfect code". However, companies don't work in a perfect environment
  , and often require trial and error to get the requirements correct.
    - I feel that we **should** have DRY code, but don't be afraid to repeat yourself sometimes, until it's required to keep it DRY.
    - For example, you can have 2 functions that are for similar concepts in different code bases, but maybe one only needs 10% of the code to run.
      Would you rather use the other 90% of the code as well, when you only need 10%? Or, just write the 10% of code in the codebase which is easier to understand, 
      and live with some repeated code?
    - I find that instead of making code easy to reuse from the get-go, it's a lot better to make sure that your code is refactorable so it can be reused.
      Having good programming practices and testing can make sure that someone else can update your code effectively and easily for their own use case, without
      breaking the existing use cases.





Go back [home](/).


Reading notes and summaries of classic programmer book.

The Pragmatic Programmer, Notes: Part 1


Have you ever wondered why `import` statements don't run your code twice?
This has to do with how node manages it's modules and how they are loaded into memory.
We'll see an example below on how that works in practice.

When we make statements like this in node.js:

```javascript
// x.js

export const X = () => {};
```

```javascript
// module-1.js

import { X } from './x';
```

We're actually telling node to "load in" the module at that file path. If we don't provide a relative path, it goes and fetches the module from node_modules if one exists.

We can add an console.log statement to see what is the "status" of our modules at any point. As an example, see below:

```javascript
// module-1.js

import { X } from './x.js'

console.log(module);

export const someFunction = () => X;
```

Which logs the following information.

```
{
  id: 'module-1',
  filename: '/some/file/name/module-1.js',
  loaded: false,
  children: [
    {
      id: 'x',
      path: '/some/file/name/x.js',
      exports: { x: () => {} }
      loaded: true,
    }
  ]
}
```

This means, that our current module (id `module-1`) has NOT loaded in fully yet, since `loaded: false`.
BUT, our imports have loaded in before, `loaded: true` for `id: x` .

## Synchronous Module Loading

Before the console.log in our code, we've loaded the imported modules fully, and we have not loaded the current module fully.
If the imported modules have already been loaded before, node will take them from the memory instead.

Looking at the [ECMAScript Abstract Module Records](https://262.ecma-international.org/6.0/#sec-abstract-module-records), we can see that in the spec, they define that if a module has already been loaded before,
we do nothing, and instead just provide the module in-memory.

> Do nothing if this module has already been evaluated. Otherwise, transitively evaluate all module dependences of this module and then evaluate this module.
> ModuleDeclarationInstantiation must be completed prior to invoking this method.

## Asynchronous Module Loading

If `X` was an asynchronous function that loads in something asynchronously, then we would need to make sure that we properly cache it somehow.
This could mean making a variable that we then set in an `async` function like so:

```javascript
let X;

export const getX = async () => {
  if (X) {
    return X;
  }

  X = await loadInX();
  return X;
};
```

This still means that we create the function `getX` synchronously, but what it does for us is asynchronous (like loading from a file, API, or buffers).

There are some utilities that you can use in node.js such as [top-level awaits](https://nodejs.org/api/esm.html#top-level-await), but these can be quite dangerous to use in production.
The main reason I say this is because of the statements that Node.js makes:

> If a top level await expression never resolves, the node process will exit with a 13 status code.

If your top-level await is crucial for the application to run at all, then that seemse like a good idea to implement.
However, if it's a side process or if your application can function without this top-level await, then it is better to have
good instrumentation and logging, along with a cached local variable, that can report any issues with loading the async value.

~ Arya

Go back [home](/).


Understanding how node modules are loaded in, and how they're cached.

A Path Down Node's Modules


JavaScript is a dynamically typed language, and that is fantastic. But, it does add some confusion when you work with many developers together as a team. Interfaces, types, and generics can be a helping hand in developing reusable, type-safe, and bug-free code.

TypeScript Generics can really help elevate your code readability and usability. If you've seen TypeScript code that becomes so complicated that you see "any" type everywhere, it can usually be solved with a generic.

A generic is sort of a term to identify the signature of a method, which supports many different types. The most common generic which all of you have probably used is: Array . For example, you can make your datatype an array of any: `Array<any>` or an array of numbers: `Array<number>` , you get the point. Note that this is equivalent to number[] .

So the "generic" portion of this is where the datatype goes. Array is defined as `Array<T>` where "T" (could be any character between the < > ) is defined by the consumer of the generic type, you.

## How Can I Incorporate This In My Code?

Let's say there's a method you create and you could pass in any of these types: a string, an array of numbers or strings, an array of a custom object like a User. Now, how wold you type this? You might go with something like:

```typescript
function myFunction(arg: string | number[] | string[] | User[]);
```

That looks really messy. At some point, your method signature will get so large, that you will just end up doing the following, and destroying any benefits you would receive from using TypeScript.

```typescript
function myFunction(arg: any[]);
```

Can we use a generic here? Absolutely! Let's give our method some meaning. The purpose of this method will be to return a random element from the list which is passed in. So instead of any array, we know that this is going to be a generic, and it will return one element from the array. We can define this as follows:

```typescript
function getRandomElement<T>(list: Array<T>): T;
```

And we can use this method for any of the types mentioned above. It is important to note that types can either be defined explicitly by the developer, or they can be inferred in TypeScript. In the second example, el is inferred to be a string type, since we passed in an array of strings.

```typescript
const n: number = getRandomElement<number>([4, 23, 42, 54]);
const el = getRandomElement(['hello', 'world', 'medium']);
```

## Default Values for Generics

Usually, the default value of generics ends up being "any" if none is provided. But, you can provide a default value if you like:

```typescript
function getRandomElement<T = number>(list: T[]): T;
```

## Extending for Generics

What if, instead of just returning a random element, you were to return a User's age in your function? You would want to protect yourself against the age being undefined , right? This is where your generic type needs to extend something. Let's see this in practice, what if you have a User, Admin, and Person types:

```typescript
interface User {
  name: string;
  age: number;
  data: WebData;
}
interface Person {
  name: string;
  age: number;
  data: PersonalData;
}
interface Admin {
  name: string;
  organization: string;
}
function getRandomAge(arr: User[] | Person[]): number;
```

We can see, that only User and Person have "age" property in them, and Admin does not. Instead of specifically typing your function to be "User" or "Person" in the example above, we can use a generic instead:

```typescript
function getRandomAge<T extends { age: number }>(arr: T[]): number;
```

We know that the function will still return a number, but we are guaranteeing that the object we pass into getRandomAge has at least an age property, which is of type number. If we pass in an "Admin" into the function, TypeScript will not allow it:


`Type 'Admin' is missing the following properties from type '{ age: number; }[]`

## Can We Still Improve?

In the previous section, we created a Person and User, both of these had the same three properties: name, age, and data. The only difference is that Person has a data of type "PersonalData" and User has a data of type "WebData". Can we reorganize this somehow?

Let's try and solve this using Generics. We know that all 3 property names are the same, so let's make an interface, with a Generic type.

```typescript
interface GenericPerson<T> {
  name: string;
  age: number;
  data: T;
}
```

What this means is that, GenericPerson must be created with another type which is reserved for the "data" property of the object. Now, we can create our Person and User types using this GenericPerson. We will define a "type" instead of an interface.

```typescript
type Person = GenericPerson<PersonalData>;
type User = GenericPerson<WebData>;
```

The above Person and User types will work the same way as our interfaces did in the previous section. The only difference is that we reduced the duplication of our code, and abstracted out some of the logic in our Generic interface.

## In Summary

You can clearly see the benefits of using Generics in this case, because it allows your code to be type-safe and reusable. Using "any" can create potential bugs which are introduced and can only be detected at runtime. TypeScript allows you to catch these bugs before it reaches any running environment, because they are caught before compiling the code to JavaScript. If you'd like to learn more, you can follow along with my "Build An App" series which uses TypeScript in practice.

Go back [home](/).


Discussing how generics work in TypeScript

one programmer's thoughts

Learnings - Advent of Code 2024

The Pragmatic Programmer, Notes: Part 1

A Path Down Node's Modules

Are generics a good enough reason to use TypeScript?