Ozz's Dev Blog

When a Good Abstraction Starts to Rot (and How HOCs Saved It)

Ozz Shafriri — Fri, 10 Apr 2026 15:04:02 GMT

Recently at work, I found myself fighting an abstraction that used to feel perfectly fine.

We're working on a visually complex feature built with React Flow - a graph of nodes and edges that represents workflows.

The same nodes are rendered in two different places:

Builder view (where users can edit the workflow)
Run view (where users just observe execution)

At some point, I needed to add a small feature to the builder: a toolbar on each node (delete, test, etc.).

Sounds harmless.

It wasn’t.

The Problem: A “Shared” Component That Isn’t Really Shared

We had a component that acted as a base UI for all nodes:

export function WorkflowNode({ title, icon, status, children }) {
  return (
    
      
        {icon}
        {title}
      
      {children}
    
  );
}

Clean. Simple. Reusable.

But then came the toolbar.

The builder view is wrapped with a React context (for things like executing nodes, deleting them, etc.). The run view isn't.

Normally, calling the builder hook outside that context would throw - so I introduced a “safe” version:

// returns null if not in builder
const builderContext = useOptionalBuilder();

And then:

{builderContext && (
  
    
    
  
)}

And just like that, I invented a hook just to make the abstraction pretend it still works.

Why This Felt Wrong

This component was supposed to be:

“A visual shell for a node”

But now it also:

Knows about a builder context
Handles business logic (delete, test)
Renders builder-only UI

And in the run view? All of this becomes dead code. It technically works, but it's misleading.

This is how abstractions start to rot:

You add one condition
Then another
Then a hook to support the condition
And suddenly your “shared” component isn't really shared anymore

The Key Insight

The problem wasn't what I added - it was where I added it.

I didn't actually want to change the node, I wanted to change how the node behaves in a specific context.

Enter: Higher-Order Components (HOC)

A Higher-Order Component (HOC) is just:

A function that takes a component and returns a new component with additional behavior.

function withSomething(WrappedComponent) {
  return function EnhancedComponent(props) {
    return ;
  };
}

That's it. No magic - just composition.

Applying It to Our Case

Instead of modifying WorkflowNode, I created a wrapper:

export function withBuilderNode(WrappedNode) {
  return function BuilderNode(props) {
    const { id } = props;

    return (
      <>
        
          
          
        

        
      
    );
  };
}

Now the node itself stays clean.

Where This Becomes Really Nice

In React Flow, nodes are registered via a nodeTypes map:

const nodeTypes = {
  action: ActionNode,
  condition: ConditionNode,
};

So instead of changing the components, I changed how they're registered:

const builderNodeTypes = Object.fromEntries(
  Object.entries(nodeTypes).map(([key, Component]) => [
    key,
    withBuilderNode(Component),
  ])
);

And then:

// Builder view


// Run view

Same nodes. Different behavior. No conditionals inside.

What We Gained

This small shift gave a much cleaner separation:

Concern	Where it lives
Visual node structure	`WorkflowNode`
Node-specific logic	`ActionNode`, `ConditionNode` etc.
Builder-only UI (toolbar)	`withBuilderNode`
Run view	untouched

No more:

useOptionalBuilder
Hidden conditionals
Leaky abstractions

Why I Like This Pattern

What I like about this solution is that it doesn't try to be clever.

It just respects boundaries:

Components describe what they are
Wrappers describe how they behave in a context

And since React Flow already uses nodeTypes as an extension point, this fits naturally into the architecture.

Final Thought

This wasn’t really about toolbars or even React Flow.

It was about catching the moment when:

“This abstraction still works… but it's starting to lie.”

And instead of patching it with another condition, stepping back and asking:

“Am I solving this in the right layer?”

Another unrelated (but amusing) note - here's what Gemini came up with when I asked it to generate a visual for this post:

How JavaScript Really Works Under the Abstractions We Rely On

Ozz Shafriri — Sun, 11 Jan 2026 16:46:07 GMT

As developers, we spend most of our time in the “Top Layer” of the frontend, relying on built-in methods like map, filter, and forEach. Usually, these abstractions are perfect. They let us write clean, readable code without worrying about what’s happening in the engine.

But as applications scale, abstractions eventually leak.

You might notice it when a simple forEach fails to handle a high-concurrency async task, or when you find yourself wondering why a primitive string, which technically isn't an object, somehow has access to a library of methods like .split().

To build resilient systems, we have to occasionally dive below the surface. Today, we’re tracing the thread from the fundamental mechanics of the Prototype Chain to the complex world of Async Concurrency Managers.

The "Everything is an Object" Paradox

Let’s start with a foundational paradox: the "Everything is an Object" claim. In JavaScript, strings are primitives. If you check typeof "Ozz", it’s a "string". By definition, primitives are just values; they don’t have properties or methods. Yet, we call .toUpperCase() on them every day.

To understand any of this, we first have to answer: what actually is a Prototype? In JavaScript, every object has a hidden property that points to another object. This "other object" is the Prototype. Think of it as a fallback system. If you ask an object for a property or method it doesn't have, it doesn't give up; it looks at its Prototype to see if it’s there.

A Practical Scenario: The Wasted Memory Trap

To see why this "fallback" is so important in the real world, let’s look at a classic problem. Imagine you are building a game with 1,000 "Soldier" objects. Each soldier needs a move() function. If you define the function inside the constructor, like this:

function Soldier() {
  this.move = function() { 
    console.log("Moving..."); 
  };
}
const s1 = new Soldier();
const s2 = new Soldier(); // ... 1,000 times

If you do this, the computer creates 1,000 different copies of the move function in memory. That is incredibly wasteful because every soldier moves the exact same way.

The Solution: The "Master Object" (Prototype)

Instead of giving every soldier their own copy of the function, JavaScript says: "Let’s put the function in a single 'Master Object' and let all soldiers look at it when they need it." This "Master Object" is the Prototype. It acts as a shared library that every instance can access without owning its own copy.

How it Works: The Mechanics of Delegation

Every object in JavaScript has a hidden "link" (internal property) called [[Prototype]] (commonly accessed via __proto__). When you ask an object for a property (like s1.move), the JavaScript engine follows these steps:

Look at the object itself: "Do you have a move property?"
Look at its Prototype: If not found, it follows the hidden link to the parent. "Do you have it?"
The Chain: If the parent doesn't have it, it looks at the parent's parent.
The End: This continues until it hits null (the end of the Prototype Chain).

`prototype` vs `proto`: Two Sides of the Same Coin

This is where most people get confused. They are related but serve different roles:

prototype: This is a property on Constructor Functions (like Array or Soldier). It is a "Blueprint" for what future children should look like.
__proto__: This is a property on the Instances (the children). It is the actual "Link" pointing back to the blueprint.

function Soldier() {}
// We add the function to the BLUEPRINT once
Soldier.prototype.move = function() { 
  console.log("Walking..."); 
};

const s1 = new Soldier();
s1.move(); // It works!
console.log(s1.__proto__ === Soldier.prototype); // true

The Primitive Paradox: Values Without Links

Now we hit the mystery. If a Prototype link is created by a Constructor function (like our Soldier), what happens to a simple string? When you write const name = "Ozz";, you aren't using a constructor. You're creating a primitive. Primitives are raw data; they don't have a __proto__ link. Technically, they should be "methodless."

The "Auto-Boxing" Mechanism

The moment you try to access a property or method on a primitive (like .toUpperCase()), JavaScript performs a magic trick called Boxing:

It creates a temporary Wrapper Object (e.g., new String("gemini")).
This wrapper object has access to String.prototype.
It runs the method you asked for.
It returns the result and immediately throws the wrapper object away.

The Prototype Chain "End"

When people say "Everything is an object," they mean that if you follow the prototype chain far enough, almost everything eventually points back to Object.prototype.

A String points to String.prototype.
String.prototype points to Object.prototype.
Object.prototype points to null.

This is why a String can use .toUpperCase() (from its own prototype) and .hasOwnProperty() (from the Object prototype).

Mastering the Blueprint: The Prototype in Action

Building Our Own `forEach`

Understanding that these methods aren't hardcoded into the data but live on a shared blueprint allows us to stop being passive users of the language and start being creators. To demystify this, let’s try to implement our own version of forEach directly on the Array.prototype. This exercise forces us to confront the this keyword - the bridge that connects the shared blueprint back to the specific data instance we are looping over.

Extending the Array Prototype

By adding a method to the prototype, we are effectively teaching every array in our codebase a new trick. Notice how this inside the function refers to the specific array instance that called the method.

Array.prototype.myForEach = function(callback) {
  // 'this' refers to the actual array instance
  for (let i = 0; i < this.length; i++) {
    callback(this[i], i, this);
  }
};

[10, 20, 30].myForEach((item) => console.log(item));

The Abstraction Leak: When Synchronous Loops Fail

While extending prototypes is a great way to learn how the engine works, it also reveals a significant limitation: the built-in "blueprints" were largely designed for synchronous operations. In a modern environment, we rarely deal with simple lists of numbers; we deal with streams of data and network requests.

Beyond the Prototype: Scaling for Concurrency

The Async Problem: `forEach` and the Event Loop

This is where the "Abstraction Leak" I mentioned earlier becomes a real pain point. If you use a standard forEach with an async callback, you quickly realize it doesn't actually "await" anything. It's designed to fire all callbacks as fast as possible in a single synchronous sweep. It doesn't care about the Promises you return, which means if you're trying to fetch 100 resources, you're firing 100 requests at the exact same time.

What Actually Works: The `for...of` Loop

The simplest way to fix the forEach issue is to switch to a for...of loop. Unlike forEach, the for...of loop respects the await keyword inside its body. It will pause the execution of the loop until the current Promise resolves before moving to the next iteration. This ensures your tasks run sequentially—one after the other.

const processTasks = async (tasks) => {
  for (const task of tasks) {
    // The loop stops here until this promise resolves
    await task(); 
  }
};

The Speed Alternative: `Promise.all`

But what if you don't want to wait for one task to finish before starting the next? If you have 10 independent API calls, running them sequentially with for...of is a waste of time. This is where Promise.all comes in. It takes an array of promises and executes them in parallel, returning a single promise that resolves when all of them are done.

Choosing the Right Tool

While Promise.all is incredibly fast, it’s a "heavy lifter." It fires everything at once. If you are dealing with 1,000 tasks, Promise.all might overwhelm the browser or the server. Understanding the difference between the sequential for...of and the parallel Promise.all is the key to choosing the right strategy for the right scale.

Conclusion

We started this journey by asking why a simple string can use methods, and we ended by discussing the nuances of async execution. This is the power of understanding the "under the hood" mechanics of JavaScript. When you understand the Prototype, the Constructor, and Boxing, you stop seeing the language as a collection of magical keywords and start seeing it as a system of blueprints and links.

Understanding Premature vs. Unnecessary Abstraction: Lessons from the Codebase

Ozz Shafriri — Sat, 26 Oct 2024 10:06:29 GMT

As developers, we’re often taught to write reusable, maintainable code. However, in our enthusiasm to “do the right thing,” we sometimes over-engineer solutions, introducing abstractions too early or where they’re not needed at all. This can lead to code that’s harder to maintain, not easier.

In this post, I want to explore the difference between premature abstraction—where we anticipate future needs before they arise—and unnecessary abstraction—where the abstraction itself offers no tangible benefit, even in the long run. I’ll illustrate these concepts with real-world examples from my own work.

Premature abstraction

Let me know if this sounds familiar…

You’re working on a large feature and notice repeated code across smaller sub-problems. To avoid duplication, you create an abstraction. But as you continue, each new variation requires tweaking the abstraction. Repeat this a few times, and before long, the abstraction becomes complex, hard to follow, and brittle—trying to handle too many scenarios.

This is premature abstraction—introducing abstractions too early, before there’s a clear need. Instead of simplifying, it leads to overly complex, hard-to-maintain code. It’s often better to wait for clear patterns to emerge before abstracting.

Let me share an example of premature abstraction from my own experience.

At work, we had a React component called InputWithButtons, designed to render an input field alongside a list of buttons passed as props. The idea was to create a reusable component for inputs with buttons, but this component was only used in one place—making it a premature abstraction right from the start.

Here’s a simplified version of the InputWithButtons component:

type ButtonInfo = {
    id: string;
    icon: IconTypes;
    onClick: () => void | Promise<void>;
    tooltipInfo?: string;
}

type InputWithButtonsProps = {
    value: string;
    disabled: boolean;
    buttons: ButtonInfo[];
}

export default function InputWithButtons(props: InputWithButtonsProps) {
    return (
        "flex-start flex w-full gap-1">
            
            {props.buttons.map((currButton) => {
                const Icon = SvgPickerNode({ icon: currButton.icon });
                return (
                    
                        
                    
                );
            })}
        
    );
}

Later, I added a CopyButton, which was always passed in the buttons array. To simplify things, I directly rendered the CopyButton inside InputWithButtons, removing it from the dynamic list of buttons. This effectively reduced the abstraction, but in doing so, the component lost its original generality and purpose.

export default function InputWithButtons(props: InputWithButtonsProps) {
    return (
        "flex-start flex w-full gap-1">
            
            {/* Always render CopyButton instead of passing it dynamically */}
            () => console.log('Copy action')}
            />
            {props.buttons.map((currButton) => {
                const Icon = SvgPickerNode({ icon: currButton.icon });
                return (
                    
                        
                    
                );
            })}
        
    );
}

While this made the component simpler, it also rendered the abstraction pointless. By hardcoding the CopyButton, the component no longer served its original purpose of dynamically rendering buttons—it had become specialized to one particular use case.

This is a good example of how premature abstractions can lead to unintended complexity or become irrelevant as the code evolves. It’s often better to wait until patterns emerge before introducing abstractions.

Unnecessary Abstraction

Unnecessary abstraction occurs when an abstraction never provides meaningful value to the code. It introduces complexity without offering any real benefits, regardless of when it was added. Even as the code evolves, this abstraction fails to improve the design or maintainability. It often leads to more convoluted code, making it harder to understand and work with, without any tangible gains in flexibility or reuse.

During a code review, I noticed a colleague had created a component to abstract a div with a className, used in two places in our codebase. His reasoning was that since it was used in more than one place, creating a reusable component seemed logical.

const Wrapper = ({ children }) => {
  return "custom-wrapper">{children};
};

// Used in two places
const ComponentA = () => (
  
    Content A
  
);

const ComponentB = () => (
  
    Content B
  
);

While the intent was to promote reusability, the component itself only renders a div with a className, without any additional logic or behavior. This is where the abstraction becomes unnecessary. In its current state, it doesn’t simplify the code or offer meaningful reuse—it just centralizes the className into one place.

In cases like this, abstraction doesn’t add value because:

• No logic or complexity is being abstracted—it’s just a div with a static className.

• Low likelihood of change: Since this is such a simple structure, there’s little chance that this wrapper will need to be modified or extended in the future.

• Readability: Instead of making the code clearer, the abstraction adds an extra layer of indirection, which can make understanding the code more difficult without providing any clear benefit.

Premature Abstraction vs. Unnecessary Abstraction

The difference between premature and unnecessary abstraction comes down to timing and need:

• Premature abstraction happens when you introduce an abstraction too early, before the codebase’s patterns or needs are clear. While it might not be useful at the time, it could eventually serve a purpose if those patterns emerge.

• Unnecessary abstraction, on the other hand, never provides meaningful value. It complicates the code without improving design or maintainability, regardless of timing.

In short, premature abstraction may have potential utility, but it’s introduced before a clear need arises. Unnecessary abstraction, however, has no utility even in the long run, adding complexity without benefit.

How to build a customizable dashboard with tremor, recharts and react-grid-layout

Ozz Shafriri — Tue, 03 Oct 2023 15:39:42 GMT

Looking to craft a personalized dashboard that perfectly suits your data needs? You're in the right place! In this blog post, I'll guide you through the process of building a customizable dashboard using tremor and react-grid-layout.

To initiate our project, let's scaffold it using Vite with the command:

npm create vite@latest my-project

When prompted to select a framework, opt for 'React'.

Next, you'll be prompted to choose a variant. I opted for 'TypeScript'

Afterward, execute the following commands:

cd my-project
npm install
npm run dev

Congratulations! You now have an initial working project. Pretty straightforward, isn't it?

For further instructions follow this guide: https://www.tremor.so/docs/getting-started/installation

Now let's install react-grid-layout by running the following command:

npm install react-grid-layout

And... we're all set! Let's dive right into working on our project!

For each chart component, I'll utilize the Card and Title components to contain the chart itself. Depending on the desired chart type (all sourced from tremor), I'll integrate either a BarChart or a PieChart. Additionally, I'm gonna use the ResponsiveContainer component from the recharts library (which tremor relies on as a dependency) to ensure the chart fits neatly with the respective card.

export enum ChartVisualization {
  BarChart = "bar",
  PieChart = "pie",
  // Add other visualization types as needed
}

export interface Chart {
  title: string;
  eventSchemaId: string;
  visualization: ChartVisualization;
  property: string;
  x: number;
  y: number;
}

type ChartProps = ComponentProps<"div"> & {
  chart: Chart,
  data: { name: string; value: number; }[],
};

Let's craft a chart widget tailored to each specific type of chart we aim to showcase:

function BarDashboardChart({ data }: ChartProps) {
  return (
    "h-[90%]"
      data={data}
      index="name"
      categories={["value"]}
      colors={["blue"]}
      showLegend={false}
    />
  )
}

function PieDashboardChart({ data }: ChartProps) {
  return (
    "h-[90%]"
      variant="pie"
      data={data}
      category="value"
      index="name"
      colors={[
        "slate",
        "violet",
        "indigo",
        "rose",
        "cyan",
        "amber",
      ]}
      showLabel={true}
    />
  )
}

In our chart component, we can map each visualization type to its corresponding component:

const visualizationComponents: Record> = {
  [ChartVisualization.BarChart]: BarDashboardChart,
  [ChartVisualization.PieChart]: PieDashboardChart,
  // Map other visualization types to their components
};

function DashboardChart(props: ChartProps) {
  const SpecificChart = visualizationComponents[props.chart.visualization];
  return (
    
      "mb-6"</span>>{props.chart.title}
      
        
      
    
  )
}

Notice that visualizationComponents corresponds not to the recharts components directly, but rather to our custom components that encapsulate and interact with recharts elements.

Once I have the list of charts, I'll iterate over it and render each chart as described:

{charts.map(({ chart, data }) => (
    
))}

To add a touch of responsiveness and style to our charts, let's make them customizable using the GridLayout component.

I enclose the entire preceding block, which I attached earlier, with a GridLayout tag:

"items-center w-[1200px]"
  layout={charts.map((chart) => ({
    i: chart.chart.id.toString(),
    x: chart.chart.x,
    y: chart.chart.y,
    w: 1,
    h: 1,
  }))}
  cols={2}
  rowHeight={400}
  width={1200}
  isResizable={false}
  onLayoutChange={(layout) =>
    mutate(layout.map((l) => ({ id: parseInt(l.i), x: l.x, y: l.y })))
  }
>
  {charts.map(({ chart, data }) => (
      
  ))}

And... Voilà! Once you have enough data to display everything, it should look something like this:

To make things a bit more interesting, how about we throw in an "Add Chart" button so we can dynamically pop in a chart based on the data we have?

I'll be using a new library called Floating UI for the dialog.

In the dialog, I'll allow the user to select the chart title, visualization type (bar/pie chart), the event type from the database, and one of the properties associated with this event.

In a new component that I've named AddChartDialog, I'll incorporate this code:


  {isOpen && (
    "Dialog-overlay" lockScroll>
      
        "bg-white p-6 rounded w-[35rem] flex flex-col"
          ref={refs.setFloating}
          {...getFloatingProps()}
        >
          "text-2xl"</span>>Add Chart
          Visualize your events
        
      
    
  )}

We can now integrate Select components (also sourced from tremor) inside your dialog. For instance, we could include a Select component for choosing an event schema:

"mt-4">
  "mb-2 text-sm">Event Type

Note: I could have implemented a more robust form validation system using the react-hook-form library, for the dialog of the "Add Chart" button.

For the complete context of what I've discussed here, and to get a glimpse of the entire project (including the backend), take a look at the repository of MagicInsight.

Tech Trailblazing: Your Ultimate Guide to Landing Your First Job

Ozz Shafriri — Tue, 11 Jul 2023 18:56:28 GMT

Welcome to the demanding but rewarding, tense yet fascinating world of high-tech. Whether you're a recent graduate, a career changer ready to embrace a new challenge, or someone with an unwavering passion for the tech field, this guide is crafted just for you.

For those wishing to take their initial step into the high-tech industry, the hassle of looking for a job can be extremely draining and tiresome. If you're involved in this world in any way, you've probably encountered the chicken-and-egg paradox: every job requires at least five years of experience (even if the programming language the applicant must be familiar with has only been around for three years), but no one is willing to hire juniors for entry-level positions so they can gain this experience.

You've probably also come across an annoying amount of the same message in various forms. It goes something like this:

Thank you for your interest in the position at [Random Company], and thank you for taking the time to apply.

While your skills and background are impressive, we have decided not to move forward at this time.

I know, right? Ugh...

I also ran into the same walls. The worst part is that there is no way to figure out what went wrong with the CV you submitted. Are there not enough impressive projects on my GitHub? Is my LinkedIn profile too bland? What am I doing wrong?

Nevertheless, I would like to provide you with several tools and perspectives of my own, which I learned throughout the process I went through, to avoid such messages (or at least reduce them significantly) and to give you a bit more insight into what they mean.

My Tech Journey Today 👋🏼

So hey folks, my name is Ozz Shafriri and I live in Tel Aviv, Israel.

As of the date of writing this article, I am in my final year of study for a degree in computer science and I have been working as a Backend Developer for the past six months.

I began looking for a development role with no experience or knowledge of the industry as early as my second year of education. I've been stuck in this loop for almost a year, during which time I also worked at a nearby neighborhood cafe, went to school, and worked on personal projects. The pressure to find a job rose as I neared graduation until eventually I struck it lucky and was hired for the position I had been looking for in the middle of my third and final year.

Needless to say, I quit my job at the cafe as soon as they told me they were interested in hiring me for the position I had applied for. After that, it was quite difficult to balance work and school, especially when exam periods came around once in a while, and also because I was an inexperienced junior at a small startup where I had to do and learn many things myself.

However, it all paid off because, at the end of the road, I'd end up with a prestigious degree and professional experience in the industry. Two birds, one stone.

But (!) I can't deny that there were challenges and hiccups along the way up until then; after all, as I already mentioned, it took me almost a year to find a job.

Let's start from the beginning, then...

Learning from Mistakes: The Cost of Inadequate Research

I think the main issue I had in the beginning, which is also one of the main reasons it took me so long to get a job, is that I wasted my time on idle pursuits. I made the wrong assumptions about the industry, focused on the wrong things and as a result - completely wasted my time when it came to job hunting.

I was confident that I would get employed immediately after graduation because there was such a high demand for computer science students. Who would turn down someone who has devoted three years of his life to earning a degree?

So I signed up for LinkedIn, created a GitHub account, got a CV template that I thought was appropriate, and started sending. and sending. and sending.

At the time, I didn't know what I was doing wrong. After many conversations with friends who have been in the industry for a long time, in-depth research I did on the internet and some additional consultations, I understood the flaws in my approach and started making changes.

Full disclosure - when I first started sending out my CV, I kept a table of all the companies I applied to, and when the table grew to a size of more than 3 pages and the only entries for the Response column in it were either Pending or Rejected, I realized that the table served no use other than to stifle me.

Someone once told me:

"You can, and you will get many "no's" in life, but you only need one "yes"

So as you would have guessed, I stopped keeping track of the places I sent my CV.

Crafting a Standout Tech Profile

I chose to divide this section into three parts.

I'm sure there are other ways to accomplish your goals, but I decided to focus on the strategies that were most helpful to me and the things that recruiters value the most and give more weight to in applications.

Crafting a Stellar CV: Presenting Your Best Self

Much has been said and much will be said about how to construct a good CV, so I can give you another viewpoint and some food for thought.

Always remember that the first thing recruiters see, even before they've even met you or had the chance to speak with you, is your CV. This is how their first impression of you is determined. Having said that, invest in your resume! The initial screening stage is the most inconvenient one; wouldn't you like to know that your resume looks good and gets the attention of the hiring manager?

Pay attention to subtleties - even before anyone starts reading the resume, the general form of the document creates a crucial impression of you. Something I've noticed people doing is opening a Word document and simply writing down all kinds of information they believe is important to know about themselves. It just looks bad.

When creating my resume, I drew inspiration from various templates I found on the internet that resonated with me. Although I designed the entire resume using PowerPoint, I ultimately submitted it as a PDF when applying for jobs.

I would recommend dividing your document into sections, following a format similar to this (which, by the way, is one of the examples I took inspiration from):

Try to be accurate to the right degree - not to multiply words where there is no need, but to condense what is relevant. As someone without experience, this task can be somewhat challenging. My suggestion is to include significant projects you have worked on independently, which can be showcased in a sentence or two. Moreover, if you are interested in becoming an Embedded Software Engineer, the fact that you were a shift manager at McDonald's is probably a minor detail that will just take up space in a document that should be mostly concise anyway.

Include links to GitHub, your LinkedIn profile, contact details, and so on. Additionally, it is customary to provide a brief description of yourself and what you are seeking (although it may not hold significant weight, it is a common convention followed by many).

And one last piece of advice - ask to see and read other people's CVs and take inspiration from them as well. If you come across something that you like and can fit with your qualifications, the people who will receive your resume may very well like it too!

Networking for Success: Maximizing Your LinkedIn Profile

Ah yes, the tricky part. What should you write on a work and business-oriented social network if you lack industry experience or personal insights?

So first of all, keep in mind that everyone has to start somewhere, and anyone who has a bit of experience has most likely been in your shoes at some point; this is a hurdle that needs to be overcome and is an essential part of the journey.

Begin by completing your profile with relevant details so that visitors have something to explore when they come across your profile. Opt for a professional-looking profile picture; one suggestion is a white background with you in a dark polo shirt, folding your hands, and wearing a subtle half-smile. Nevertheless, feel free to experiment and choose an image that aligns with your desired professional image. I would also propose paying a professional photo shop a few bucks to do it. Then, select an eye-catching background picture to complement your profile picture. Avoid leaving this section blank.

Looking for a job? Utilize the #OpenToWork feature to let recruiters know your current status without requiring them to log into your profile.

Add sections that can best reflect your abilities, such as a projects section where you can provide details about the projects you have worked on, including the duration of your involvement in them and relevant links. Furthermore, consider linking specific skills, such as programming languages, to each project to highlight your proficiency in those areas.

How many languages do you speak? Make a note of this as well; many organizations collaborate with clients from different countries. Being proficient in multiple languages can give you a significant advantage in such scenarios.

Just as mentioned earlier regarding your resume, avoid including irrelevant information under the Experience section simply to fill the space. However, as an Israeli citizen myself, I am aware that it is customary to mention my military service, even if it is not directly related to the high-tech industry. Take some time to reflect on your experiences and determine what is worth including in this section. Focus on highlighting relevant skills, responsibilities, and achievements that can showcase your abilities and transferable qualities.

Lastly, and perhaps most importantly, begin actively engaging on the platform! Here are some key actions to take:

Follow companies and individuals who align with your interests.
Like, repost, and comment on other people's posts to demonstrate your engagement and contribute to discussions.
Very important - expand your network by connecting with as many people as possible, even those you may not know personally. Through random connections on this platform, I have received about three job interviews. A recruiter took notice of my profile and promptly reached out.

Even after securing a job, I highly recommend keeping your LinkedIn page updated and maintained. The high-tech industry can experience unforeseen crises, and having a well-maintained profile with an impressive background can be valuable during such times.

Showcasing Skills: Powering Up Your GitHub Profile

Before you begin posting and showing off your projects, there are a few important considerations that I believe you should be aware of and take into account.

I'd like to start with a common mistake that I've seen a lot of people do - if you're a student, it's best to refrain from sharing your homework. GitHub is a platform intended for uploading and sharing projects, whether it's a small project like a 'to-do list' that you've completed within a week or a compiler you've developed over several months. In my opinion, and as echoed by people who research candidates for different positions, filling your GitHub with all the assignments you received during your studies does not present you in the best light and provides no significant advantage. I would even go further and say that it can give off an impression of amateurism.

Disclaimer - if during your degree, you have worked on a substantial and impressive graduation project or participated in a seminar where you built something that can be considered a project, you can market it as your own personal project, which is quite true when you think about it. Just make sure the repository's name isn't something like "Homework2_FinalVersion".

Another important thing to note - always consider how potential recruiters perceive you. While not everyone will make their way to your GitHub page, for those who do, it's essential to make a strong impression. How can you achieve this? The solution is simple - by creating a compelling README file.

A well-crafted README file can serve as a powerful tool to showcase your project, providing an overview, instructions, and any relevant details. It allows recruiters to quickly understand the purpose, features, and value of your project, which can help capture their attention and generate interest.

As an additional piece of advice, don't hesitate to introduce yourself and share your hobbies on your profile's README. This is the perfect opportunity to provide a glimpse into your personality and interests.

Feel free to check out my GitHub profile as an example. I've put effort into designing an engaging profile by incorporating captivating animations and emphasizing my interests in a nerdy and geeky manner 🤓

However, the work on READMEs does not stop with the profile. While you may have successfully captured the recruiter's attention, now you have to prove your worth. Then again, keep in mind that the person who's visiting your GitHub likely has a tight schedule and numerous applications to review for the same position you're being considered for. Your aim should be to encourage them to explore the code you have written and make a positive impression. To achieve this, you need to create a README for each of your projects, adhering to similar principles as the README for your profile.

Here are some key points on how I present my projects:

When building projects, I'm trying to choose catchy names for them, that give a product-like feel (see one of my projects - MonoBox).
Once I settle on a name, I enjoy using brandmark.io to create a logo that adds a visual element to the project.
By GitHub's unwritten convention, I ensure that repository names are written in lowercase letters and words are separated by hyphens.
I highly recommend adding descriptive text and relevant tags to projects, as it adds valuable context and helps with discoverability.
I prefer making the README within the repository more focused on the technical aspects and professionalism compared to the README on my profile. However, this approach is entirely flexible and can be tailored to your preferences. It's your project - go wild with it!

You can find a wealth of inspiration for special profiles and designed repositories in these links, which compile a wide range of examples that you can leverage:

awesome-readme: https://github.com/matiassingers/awesome-readme
awesome-github-profile-readme: https://github.com/abhisheknaiidu/awesome-github-profile-readme

Taking Action After Self-Promotion

Once you feel ready to dive back into the water, just do it!

After implementing and applying the strategies we previously discussed by myself, I experienced a noticeable increase in referrals from recruiters.

So I would like to present some ideas to help you take what you've done a step further (It's important to note that these suggestions are meant to complement the steps you have already taken. Moreover, implementing these suggestions can provide a significant advantage over your competitors for the job).

From Code to Spotlight: Leveraging GitHub for Projects and Articles

Who doesn't appreciate some positive feedback for their hard work, right?

Therefore, I strongly recommend that you start publishing your projects. After all, you have already put in the effort to create dedicated README files, so why not share your work with others and receive recognition for your achievements?

When publishing your projects (and as a personal example I take MonoBox, which I mentioned before), I recommend writing blog articles (just like this one) that capture the entire journey you experienced while building and working on the project. You may be pleasantly surprised to discover that people will take the time to read your articles and show genuine interest by asking questions. Engaging writing can create a captivating experience for readers and foster meaningful interactions around your projects.

In order to gain exposure for your project, I suggest sharing it on various platforms such as Reddit (while adhering to subreddit rules), relevant Facebook groups, Hacker News, LinkedIn, and any other platforms that come to mind. This multi-channel approach will help you reach a wider audience and increase the visibility of your project.

If you do it right, you will start to see a surge of activity in your repository. People may offer code optimization suggestions, open Pull Requests, leave stars (which, once the project accumulates a significant number of stars, can be highlighted on your resume), reach out to you, and engage in various forms of interaction.

The Power of Persistence: Casting a Wide CV Net

For both myself and friends from home and school, the strategy of sending resumes to multiple places proved to be fruitful.

A critical note - many job requirements advertised may not accurately reflect the actual requirements for the position. As an example, I personally began working in a role that supposedly required 2+ years of experience. The key takeaway is to filter opportunities wisely and not rely solely on automated processes.

Since I noticed that many companies were not interested in hiring people for student positions (at least during the time that I was looking for a job), I made the decision to omit any mention of my ongoing degree pursuit in my resume. However, it's crucial to note that I did not conceal any information. Instead, I listed the anticipated graduation year on my resume, allowing attentive readers to deduce my student status. Additionally, I refrained from explicitly stating that I am a student on LinkedIn and GitHub. Only in the late stages of the job interviews did I bring this up and clarified that the fact that I am a student would not interfere with my ability to perform the job effectively.

And one more thing under the same topic - don't get your hopes up. Keep sending out resumes until you secure an interview, and even after you've had an interview, continue sending out more resumes. The goal is to create momentum and keep multiple opportunities in progress. It's only when you find yourself in the later stages of the employment process with several different companies or on the verge of signing an employment contract that you can be confident you are on the right path and one step away from securing your first job.

Navigating Tech Job Interviews with Confidence

This is the part where I have limited insights to share since I haven't been to enough job interviews yet.

Nevertheless, what I can say, regarding this topic, is that I consistently made a point to inquire during each job interview (with humility, of course) whether the interviewers or recruiters had reviewed my LinkedIn profile or GitHub.

In one of the interviews, I had the opportunity to go over some of my projects on GitHub with the interviewer. Since I had included GIFs that demonstrated the functionality of the projects, there was no need to run the code live in front of him. The interviewer's reaction clearly showed their impression and positive response to my work.

In another interview, I was told that not only did the interviewers themselves check out my resume and GitHub, but it turned out that four different people in their company had to go through them before they decided to call me back. This showed that they took a thorough and careful approach in evaluating my profile, and it made me realize the importance they placed on the information I had presented in my resume and GitHub.

Lastly, in my current job, I was told that my GitHub profile played a significant role in helping the hiring team quickly recognize my suitability for the position they were seeking to fill. While it wasn't the sole reason for their decision to hire me, it did capture their attention and generate interest, leading to an invitation for an interview and subsequent progression in the hiring process.

Reflecting on the Journey: Key Takeaways

And... that's it, I think.

I believe I've covered most of what I wanted to share.

I would like to thank you and extend my sincere gratitude if you took the time to read everything. I know it was quite a lot, so I just wanted to express my appreciation.

Remember that everything described in this post should be taken with a grain of salt, as everything you read is true to the process I went through and experienced personally. However, as you can tell, the information is backed by people who have been in the industry for a long time, as well as a lot of research and validations I've done on my part.

So maybe not so little salt... 😉

Build your own Spotify: Killer Programming Project Idea in React Native and FastAPI

Ozz Shafriri — Wed, 16 Nov 2022 08:25:15 GMT

This article will walk you through a programming project idea - a mobile music player based on React Native, with a FastAPI / SQLModel backend.

As a reference, I will use one of my own project, a music player that I built using the guidelines that will be detailed below: MonoBox.

Also, check out my other article, where I share the process of building such an application from scratch, my thoughts, struggles and how I solved the issues that arose along the way: Introducing MonoBox

Make sure to check out the MonoBox's GitHub repo above, and don't forget to drop a star 🌟

Overview

The purpose of this task is to create a self-hosted music player similar to Spotify - users will be able to run their own servers with their own songs. You will implement the server itself in Python, and then a mobile application using React Native.

Before we continue, big shoutout to Om Arya, for a beautiful design.

What do I need to learn?

There are a lot of long videos here, it’s really okay to just watch some of them, get the general idea, and dive deeper when you need it. Don’t get stuck in this phase!

Server Side

Basics

SQLite with Python
- This tutorial (1h) will teach you how to work with databases (SQLite specifically) in Python.
- If you need another tutorial on SQL and how to work with databases from scratch, check out this tutorial (~4h).
Learn JSON in 10 Minutes + JSON in Python
- This tutorial will teach what is JSON and how to work with it in Python.
What is REST API?

Main Course

FastAPI - Full Course
- This is a 4 hour video that will teach you FastAPI, SQLAlchemy, Pydantic.

Deep Dives

Deep dive: SQLAlchemy - If you feel you need it
Deep dive: Pydantic - If you feel you need it
SQLModel - Cool library that makes things much easier

Perfect Python (or, how to write good Python code)

Client Side

TypeScript Course (3h) - You will write the client side code in TypeScript and not in traditional JavaScript. Also check out ESLint.
React Native
Figma to React Native

Let’s get started!

If you’re not sure about library / tech in one of the milestones - come back to this section any time 😉

Milestone 1: Create an empty React Native app with TypeScript

Create an empty React Native application with TypeScript + ESLint + Prettier.

See this tutorial to get started: ESLint + Prettier + Typescript and React in 2022

NOTE: We are going to have both backend and app in the same repo. So the react native app should be in a mobile/ directory for example.

Next steps:

Make sure you can run the application and see it.
Add a button that shows “Hello world” when you click it (see Alert API)

Milestone 2: “Liked Songs” View

Design the following screen in React Native:

Notes:

Here is the Figma - Music Player UI KIT
The screen shouldn’t use any real backend in this milestone - use mock JSON data (see example below).
Make sure to be as pixel-perfect as possible. Don’t forget small details like Fonts.
In this milestone, you should design the play / pause component but it shouldn’t actually work.

Mock JSON data:

{
  "songs": [
    {
      "name": "Believer",
      "author": "Imagine Dragons",
      "image": "https://upload.wikimedia.org/wikipedia/he/5/5c/Imagine-Dragons-Believer-art.jpg"
    },
    {
      "name": "Shortwave",
      "author": "Ryan Grigdry",
      "image": "https://m.media-amazon.com/images/M/MV5BZWUxOWIzOTYtMjBhYy00MWFiLWEzYTgtMzRiOTExOTA1ZWQ4XkEyXkFqcGdeQXVyNjI2ODA4MDU@._V1_.jpg"
    },
    ...
  ]
}

Milestone 3: Components Plan

Now that you have a good sense of how to build React Native screens, let's create a plan of all your React components (both full pages and small components).

Don’t forget:

Dark vs Light mode - how do you implement that?
Sidebar (see last screenshot) - how do you implement that?
How do you build the sliding images? Is there an existing component in the internet you can maybe use? Try Google & awesome-react-native
The “current song” component can appear in all screens, how do you do that?

You can easily plan & draw your design with excalidraw

Milestone 4: All screens, mock data

After deciding on the components plan, build all screens from Figma in React Native. All screens should use mock data.

In this milestone, add a URL to an audio file in the JSON above, and make sure the “Play” button works. Also make sure to run the app in your phone to verify it’s smooth and looks good.

Milestone 5: Create empty backend project

In the same GitHub repository, create the backend inside the backend/ directory, using the following tools:

FastAPI
SQLModel (includes Pydantic & SQLAlchemy)
Use SQLite as the database
Integrate pre-commit, black, mypy, isort to make sure your code looks good.

Create a single resource called Song (with name, author, image, url) and make sure you can access http://localhost:1234/docs and create / read / update / list / delete songs.

Milestone 6: Design the API Server

The API Server should be a RESTful API (e.g GET /songs to get all songs).

Design all the API endpoints your app needs, for each one make sure you have:

HTTP Method (e.g GET)
URL (/songs)
Request body example
Response body example

Milestone 7: Implement API Server & Integrate it with the mobile app

Implement all the API endpoints and use them in the React Native app.

The server should have a songs/ directory that contains all the songs of the user. See the eye3d library (+ example) on how to get the song name, artist, image etc from a audio file.

The server should also expose a /songs//download endpoint that will actually stream the audio file - this can be used in the React Native app to play this audio. See StreamingResponse in FastAPI docs.

Milestone 8: Make it usable

The entire application should be very easy to use. It should be very easy to spin up your own music server and it should be clear how to do this from the readme. For example:

pip install mymusicserver

mymusicserver run my-songs/

This should run the FastAPI server and then the app in the browser, using something like react-native-web.

Milestone 9: PUBLISH!

That's all, you guys! All that's left for you is to publish your project wherever you'd like!

Here's a little advice from me: give your project a catchy name and use it for publication.

I would love to know what you think and what you have to say, so don't hesitate to leave a comment (and of course star MonoBox on GitHub).

Introducing MonoBox: How & Why I Built My Very Own Music Player

Ozz Shafriri — Wed, 16 Nov 2022 08:14:19 GMT

If you've ever wondered where to start after deciding you want to work on a programming project, then this guide is perfect for you. That's because before I decided to write down this piece, I was in your shoes.

Creating MonoBox was one of the best and most enriching learning experiences I've had. I dealt with new technologies, encountered difficult problems and found creative solutions for them. My goal with this blog is to share the knowledge I've gained with you, as well as to tell you about the process and share, so that I can help and possibly inspire others (and maybe also earn some stars on GitHub ⭐).

If you're eager from the very first moment to see the final result and what I'm going to talk about here, here's the GitHub repo of MonoBox.

Also, check out my other article, which outlines my process and provides guidelines for creating MonoBox: Build Your Own Spotify

Why

I know what you must be thinking - "Wow, another Spotify clone, why the hell would you spend so much time and effort creating something that already exists?". Well, the way I see it, everything is a learning experience. I just really wanted to create a fullstack app, learn some new things, play with ORM and dig into React hooks. I also wanted a project which is complex enough, yet user-friendly and simple to utilize. MonoBox is exactly what I needed.

First Steps

So after deciding on a project idea—to create a self-hosted music player—I believed the abundance of information on the Internet would help me to focus on the technologies and libraries I would need. But in fact, the exact opposite happened. The amount of information I picked up in such a short time of searching, left me feeling disorganized and overwhelmed.

Therefore, I decided to put things in order and categorized the information according to the type of app I want to build, its complexity, company culture and market-relevance.

After careful consideration, I came up with the following results:

Frontend
1. React Native - an open-source UI software framework, used to develop applications for multiple different platforms. Having "my hands dirty" with React before, React Native got me hooked (pun intended) from the start.
2. JavaScript & TypeScript - TypeScript is basically an extension of JavaScript, as it enables developers to add type enforcement to their code. Moreover, TypeScript provides various other features, like interfaces, type aliases, abstract classes, function overloading, etc.
Back-end & Database
1. Python, with FastAPI + SQLModel - FastAPI is a Python web framework for building web APIs, created by the same author of SQLModel (hence the decision to work with both).
2. SQLite Database - "Simplicity is the ultimate sophistication" ~Leonardo Da Vinci

Good. Now that we have everything we need to get started, all that remains is to... well, get started!

Getting Started

The first stage, in my opinion, before starting to develop anything is to plan everything as thoroughly as possible. Of course, I expected to encounter bumps, difficulties, and error messages thrown at me along the way, but hey - you have to start somewhere. So, in order to learn all I needed to know to begin coding, I mostly watched live code tutorials or videos that taught the fundamentals of what I needed to know. I saved all of the videos and organized them by what I needed for the Server Side and the Client Side, making notes on what each video contained, so that if I forget something, I can easily find it later. Also, I found a Figma design that I liked and decided to implement in my app.

Oh and don't worry guys, all the information I gathered is ordered and organized in my other article, which you all have access to, so if I'm referring to any GitHub library or repo, you can find it in the link I included at the beginning. 🔝

Baby steps - create a new project

Finally, the time has come to create our initial application, and of course we'll start with the Frontend.

First, I created a React Native application using TypeScript + ESLinter + Prettier (for formatting and clean, readable code) and tested its interactivity by adding a button that displays "Hello World" when clicked.

So far so good. Everything is working. 👍

2 quick but important side notes:

For a short time, I used my computer's Android Emulator to simulate a mobile device and test my application - which was a nightmare. The emulator was heavy and super laggy; my computer moved slower with the emulator running in the background, and I immediately switched to using my own phone instead, once I discovered I could. So guys, use USB debugging. Trust me. 💪
I intended to have both the back-end and the app in the same repository. So all of the React Native code was in a directory called mobile/.

Firsthand experience with designing my screens

Now things are really heating up! It's time to design the app's screens!

Luckily, I found a video series that really explains in great detail how to turn a design in Figma into a React Native app. I found a design I liked and started working with it.

Before moving on to the next stage, I only built one screen at this time for my initial experience.

Some critical points:

Credit should be given when it's due, so thank you Om Arya, for a fantastic design!
In this milestone I haven't used any real data from the back-end (because it doesn't exist yet), but mock JSON data (as can be seen in the example below):
I tried to be as pixel-perfect as possible and didn't overlook small details like fonts.

{
  "songs": [
    {
      "name": "Believer",
      "author": "Imagine Dragons",
      "image": "https://upload.wikimedia.org/wikipedia/he/5/5c/Imagine-Dragons-Believer-art.jpg"
    },
    {
      "name": "Shortwave",
      "author": "Ryan Grigdry",
      "image": "https://m.media-amazon.com/images/M/MV5BZWUxOWIzOTYtMjBhYy00MWFiLWEzYTgtMzRiOTExOTA1ZWQ4XkEyXkFqcGdeQXVyNjI2ODA4MDU@._V1_.jpg"
    },
    ...
  ]
}

"Crafting with care" - Proper build and design of the UI

Now that I had a good sense of how to build React Native screens, I planned out all of my React components, from entire screens to small, reusable components (Yes, I literally grabbed a paper and a pen and started scribbling).

One of the most challenging decisions I had to make in this milestone was whether to implement parts of the components myself or look for a library that would do it for me. I'll admit that I was tempted to experiment with learning and brainstorming a bit, but then I thought to myself: "Why reinvent the wheel?"

I found a repo on GitHub that gathers a large amount of useful components, which helped me choose exactly what I needed.

Make it work

From this point on, I started going a little deeper into the app. I wanted to make it work!

So I tried playing music through the app before moving on to dealing with the back-end; here is where the React Native Track Player library comes into play.

The task of learning how to use the library and understanding it moved from being difficult to, well, less difficult, thanks to thorough documentation and a discord forum full of people who were willing to assist me with any questions.

All screens, mock data

Is everything planned? Is everything thought-through? Great! Let's build all the other screens from the Figma!

I made sure to follow the guidelines I discussed earlier regarding screen design, so building all the other screens went off without a hitch.

Face the music

The moment of truth - it's time to play some songs.

To do this, I found a random audio file link on the Internet and tried to make my app play it from the JSON file, by pressing the ⏯ button.

Up until now, all I've done was build visual screens and components. Getting the app to do even a fraction of what it was designed to do after so many stages of planning would be a significant step for the whole project.

A few drops of sweat and misplaced right brackets later, I was able to get the app to play its first sounds! Someone pinch me so I know I'm not dreaming!

Setting up the back-end

Okay, fine, I can have my player play music statically, but that's not what why we're here.

Do you remember how I mentioned my working rule of thumb at the beginning? no? well then let me remind you: "plan everything as thoroughly as possible". Before jumping into writing the code, I planned out all the REST API endpoints I thought I would need, and for each one I made sure that I have:

HTTP Method (e.g. GET)
URL (/songs)
Request body example
Response body example

After writing my own queries for my earlier projects, using FastAPI and SQLModel was a welcome change. The libraries operate well together, and their documentation was extremely detailed for me.

"It's not a bug, it's a feature"

Writing the endpoints had certain challenges, one of which was handling the relationship between the tables in the back-end. Don't get me wrong; I followed along with both the documentation and the YouTube tutorials. However, I was unable to figure out why a particular relation between two tables did not happen automatically as it should.

I spent the entire day attempting to identify the issue when, just as I was about to give up and retire crying to bed, I found someone else on GitHub Issues complaining about the very same problem I was working to resolve. It turns out that the most recent version just has a bug, and all I had to do was downgrade to a slightly older version.

I mean, seriously?!

My point is that no matter how hard I tried, I wouldn't be able to find a solution to my issue, so I started thinking of a detour in order for me to implement what I wanted. The thing is, sometimes, the solution is right under your nose, and the problem is not you. People make mistakes; you simply need to know where to look for them 😉

Final server tweaks

My ability to test all of my endpoints using FastAPI ensured that the requests were successful.

At this point all I have left to do in the server, is to write the main function that scans my songs folder, and uploads, updates and deletes according to the music files that are in it. I used eyeD3 to extract the information I needed from the music files' song info (aka ID3 metadata), including the song's title, the artwork, the artist, etc.

Come together

And now for the really tricky part - getting the whole chain to work properly. A true full-stack application. From the database, through the server to the user, and all the way back.

I started by writing down all the different fetch functions where I needed them. Then, After noticing that I had written the same functions several times (or at least in a similar way), I turned them into a custom hook to suit the needs of the application, and consolidated them all into one file of useful functions.

I made sure that everything works and that the app really gets all the information it needs from the database, and of course that everything is displayed as it should be. I then moved on to check that all the other methods are working (i.e. POST, DELETE, etc.). And that's where I ran into a "tech debt".

Integrating React Query into the code

I've found that while I initially receive all of my information when the app loads, when I attempt to update it in any way, the change only affects the database and not the app itself. This occurs because I never receive the most recent data from the database. I don't have any refetch requests in my app after the initial loading 🤔

A quick Google search gave me a very clear result: React Query. And more precisely, the invalidation method of React Query, which essentially, according to the documentation:

"Lets you intelligently mark queries as stale and potentially refetch them too!"

And that's exactly what I did. The choice I had to make was whether to utilize React Query for all front-end requests or to change the code selectively where I was required to use invalidation.

Fortunately, since I had previously consolidated all my code in one place, it was easy for me to replace all of it. The result was a shorter, clearer, and more readable code. And of course I also solved the problem 😎

Conclusion

That's all, folks!

I hope I have helped you and given you enough direction for your project, whether it be a music player or any other idea that comes to your mind.

I tried to summarize as much as I could and yet expand on the parts that seemed more relevant, because although reading this article takes a few minutes, the process of learning the various tools, languages and the best practices for work, took me close to 4 months.

Even so I didn't detail every moment when I felt dejected and that this project was bigger than me, you can be sure there were many such moments. I apologize for not being able to recall them all; after all, learning takes time, and I made a lot of mistakes along the way. And precisely because of this, I think your takeaway from this article should be to never give up. you will get there in the end - and this feeling of success will be amazing. Take your time, hone your skills.

Now all that's left for you to do is push the project to GitHub, make a killer readme for it, and be proud of what you've created.

Oh, and one last thing!

Did you notice how I hardly used the name "MonoBox" at all? That's because in this whole long process, I didn't think to give my app a name. I constantly referred to it as "The music player I'm building" or "My React Native app". In the end, you want your project to stand out above the others, and you want it to be unique and special. Market it and think of it as a product. Who wouldn't want to take a look at it?

Let your creativity run wild.

Thank you for taking the time to read what I had to say. You can follow me on LinkedIn, GitHub and you are more than welcome to star my projects there 🌟

I would love to hear from you, so let me know what you think in the comments, I'll be more than happy to help you out. 😃

Ozz's Dev Blog

When a Good Abstraction Starts to Rot (and How HOCs Saved It)

The Problem: A “Shared” Component That Isn’t Really Shared

Why This Felt Wrong

The Key Insight

Enter: Higher-Order Components (HOC)

Applying It to Our Case

Where This Becomes Really Nice

What We Gained

Why I Like This Pattern

Final Thought

How JavaScript Really Works Under the Abstractions We Rely On

The "Everything is an Object" Paradox

A Practical Scenario: The Wasted Memory Trap

The Solution: The "Master Object" (Prototype)

How it Works: The Mechanics of Delegation

prototype vs __proto__: Two Sides of the Same Coin

The Primitive Paradox: Values Without Links

The "Auto-Boxing" Mechanism

The Prototype Chain "End"

Mastering the Blueprint: The Prototype in Action

Building Our Own forEach

Extending the Array Prototype

The Abstraction Leak: When Synchronous Loops Fail

Beyond the Prototype: Scaling for Concurrency

The Async Problem: forEach and the Event Loop

What Actually Works: The for...of Loop

The Speed Alternative: Promise.all

Choosing the Right Tool

Conclusion

Understanding Premature vs. Unnecessary Abstraction: Lessons from the Codebase

Premature abstraction

Unnecessary Abstraction

Premature Abstraction vs. Unnecessary Abstraction

How to build a customizable dashboard with tremor, recharts and react-grid-layout

Tech Trailblazing: Your Ultimate Guide to Landing Your First Job

My Tech Journey Today 👋🏼

Learning from Mistakes: The Cost of Inadequate Research

Crafting a Standout Tech Profile

Crafting a Stellar CV: Presenting Your Best Self

Networking for Success: Maximizing Your LinkedIn Profile

Showcasing Skills: Powering Up Your GitHub Profile

Taking Action After Self-Promotion

From Code to Spotlight: Leveraging GitHub for Projects and Articles

The Power of Persistence: Casting a Wide CV Net

Navigating Tech Job Interviews with Confidence

Reflecting on the Journey: Key Takeaways

Build your own Spotify: Killer Programming Project Idea in React Native and FastAPI

Overview

What do I need to learn?

Server Side

Basics

Main Course

Deep Dives

Perfect Python (or, how to write good Python code)

Client Side

Milestone 1: Create an empty React Native app with TypeScript

Milestone 2: “Liked Songs” View

Milestone 3: Components Plan

Milestone 4: All screens, mock data

Milestone 5: Create empty backend project

Milestone 6: Design the API Server

Milestone 7: Implement API Server & Integrate it with the mobile app

Milestone 8: Make it usable

Milestone 9: PUBLISH!

Introducing MonoBox: How & Why I Built My Very Own Music Player

Why

First Steps

Getting Started

Baby steps - create a new project

Firsthand experience with designing my screens

"Crafting with care" - Proper build and design of the UI

Make it work

All screens, mock data

Face the music

Setting up the back-end

"It's not a bug, it's a feature"

Final server tweaks

Come together

Integrating React Query into the code

`prototype` vs `proto`: Two Sides of the Same Coin

Building Our Own `forEach`

The Async Problem: `forEach` and the Event Loop

What Actually Works: The `for...of` Loop

The Speed Alternative: `Promise.all`