DEV Community: Manish

Inversion of Control and Frameworks v/s Libraries in Software Development

Manish — Wed, 10 Jan 2024 16:27:55 +0000

In the ever-evolving landscape of software development, the quest for efficient and maintainable code is a never ending journey. One of the concepts that has gained prominence in this landscape is the concept of Inversion of Control (IoC). IoC represents a paradigm shift from the traditional approach of writing code, where the developer has primary control over the execution flow, to a more modular and loosely coupled architecture.

Understanding Inversion of Control

In a typical software development workflow, developers write code and incorporate external libraries to handle specific functionalities. In this conventional model:

The control primarily rests in our code.
Libraries are integrated to provide reusable components and functionalities.
Our code delegates control to the library for executing specific tasks.
Control returns to our code for further execution.

However, Inversion of Control flips this model on its head:

An external package or framework takes charge of the general workflow.
It implements essential configurations and functionalities for fundamental aspects of the application.
Control is then passed to our code for customization.
Our code, once tailored to its requirements, hands back control to the external package for continued execution.

In a practical context, consider the example of NextJS, a popular React framework. NextJS handles tasks such as parsing file structures, building routes, and managing static resources. Developers then contribute their code within individual page components, and the control seamlessly oscillates between the framework and the developer's code.

Frameworks vs. Libraries

Understanding IoC facilitates a grasp of the broader concepts of frameworks and libraries. In the software development workflow, libraries are tools that we integrate into our code, providing additional and reusable functionalities or utilities. Frameworks, on the other hand, offer a pre-established, structured foundation for building applications. The relationship can be summarized as follows:

Libraries

Libraries serve as invaluable supplements to our code, providing additional reusable tools and functionalities. When utilizing libraries:

We plug these libraries into our code, extending its capabilities.
Developers craft the main logic and code, while libraries offer specific, reusable features.
For example, libraries, such as React Spinners or mathematical utility packages, expose a set of methods and resources to attain desired functionalities.
Typically, these entities are implemented by their authors and are intended to be non-modifiable or, at the very least, cautionary about modifications.

Consider a React Spinner library – it comprises a set of components accepting properties like size and color to render loader animations. The beauty lies in the simplicity of usage. Developers leverage the same component across multiple instances without delving into the intricacies of its internal workings.

Exported entities from libraries aren't limited to functions. They can include variables like Math.PI, functions like Math.round(), or even entire classes like Serializable.

Frameworks

Frameworks, in contrast, provide a comprehensive, pre-implemented codebase that forms the backbone of an application. Here's how frameworks fit into the development landscape:

Developers plug their code and additional libraries into a framework.
Frameworks handle the heavy lifting by offering a structured foundation with essential features.
NextJS, for instance, functions as a framework, providing routing, static resource serving, optimizations, server-side rendering, static site generation, and more out of the box. Let's dissect the components of NextJS to understand the intricate dance between frameworks and other elements:
- Routing: Navigation within the application is seamlessly handled.
- Static Resources Serving: Efficient delivery of static assets is a built-in feature.
- Optimizations: Performance optimizations are taken care of by the framework.
- Server-Side Rendering (SSR): Dynamic content generation on the server side is seamlessly integrated.
- Static Site Generation (SSG): Pre-rendering of pages at build time for enhanced performance.
- Incremental Static Regeneration (ISR): Periodic regeneration of static pages for dynamic data updates.
- Environment Files Handling: Management of environment files, including loading and security.
- Loading: Reading and incorporating environmental variables to be accessible throughout the application.
- Security: Ensuring secure handling of sensitive information, such as env variables being inaccessible by default in client side code, unless being prefixed by NEXT_PUBLIC_.
- Server-Side Code Generation: Dynamically generating server-side code for enhanced flexibility.

However, frameworks often rely on additional components, and NextJS is no exception:

Styling: Developers choose their preferred styling method – be it CSS Modules, Tailwind, or SASS.
UI Library: While tightly coupled in many frameworks like NextJS (using React), some frameworks like Astro offer flexibility by allowing the combination of multiple UI libraries (React, Preact, Svelte, Vue, etc.).
Linting and Formatting: Developers can plug in their preferred tools for code linting and formatting.

Conclusion

Embracing Inversion of Control, along with an understanding of frameworks and libraries, empowers developers to create scalable, maintainable, and adaptable software architectures. By relinquishing control to external packages for fundamental functionalities, developers can focus on crafting code that aligns with specific project requirements, fostering a more modular and collaborative approach to software development. As the landscape continues to evolve, embracing these concepts becomes integral to staying ahead in the dynamic world of software engineering.

Note/Credits: This article is based off my notes. I'm still learning these concepts and I keep noting down what I understand and think is pivotal. The content is then stitched together and filled into blog paragraphs using AI. It hasn't just been lousily copied from ChatGPT using my notes, it has undergone multiple readings and modifications and multiple prompts. But I've just kept it transparent for your judgement and knowledge. Thanks!

Day 2 | Xhopie - Starting up

Manish — Wed, 03 Jan 2024 00:40:53 +0000

Context

This is a blog series where I document my progress on Xhopie, a self project I'm starting to learn about general concepts regarding software development by implementing an e-commerce application with different tools and technologies to learn how to do important and common things in different languages.
Here's the main repo link: https://github.com/the-halfbloodprince/xhopie-main

Work Overview

So here is a brief overview of the work

on `xhopie-server-node`

Environment Variables

added env file support (used dotenv, considered also using the native --env-file flag of NodeJS, but fell back on dotenv to make it work asap with nodemon and ts-node)
- currently just added PORT, HOST and EXAMPLE_VARIABLE to the list
- EXAMPLE_VARIABLE is just a variable used to be available to confirm the proper loading of env variables. This can be done in other more robust ways probably, or just by checking any other variable, so it is safe to be removed in a future commit.
- added all of them in an .env.example file as well.
added env file type declaration support
- added a ENV_Variables interface in the config folder for declarations of the variables
- added a overwrite of ProcessEnv interface which declares the interface of process.env
- used inheritance to automatically extend from the ENV_Variables interface.
defined a separate APP_CONFIG variable in config folder to hold important app wide accessible variables in one place
- added the env variables present at the moment to APP_CONFIG
- also throwing an error if there was any error in loading env variables.
- TODO: This should be properly handled later instead of blatantly just throwing an error
- also this makes the purpose of EXAMPLE_HANDLING obsolete, so it's been removed

Refactoring The Project's Folder Structure

added the src folder.
- made corresponding updates in the package.json as well as tsconfig.json

It was a short day, mostly just configuring stuff up, recalling the good architectural/folder patterns etc, and just brushing up some of my old concepts and memories.

Hope you hadn't given up on your new year resolutions yet. Keep the work up.

See you on the next day.

Day 1 | Xhopie - Starting up

Manish — Mon, 01 Jan 2024 01:26:04 +0000

This will be a blog series where I document my progress on Xhopie, a self project I'm starting to learn about general concepts regarding software development by implementing an e-commerce application with different tools and technologies to learn how to do important and common things in different languages.

Here's the main repo link: https://github.com/the-halfbloodprince/xhopie-main

Starting this out today, on the 1st of Jan, 2024. (Please don't judge me)

I'll not be going into in-depth summarization today, as I don't have much to say at this point, and it's already 6:20am, I really need to go to sleep.

Work Overview

So here are a few basic overviews

Decided to use git submodules as I'll be creating various repositories in future to try the same things out in other technologies such as Angular and Spring Boot.
Decided to start using a set of flags on my commit messages which will make it easier to navigate and read. I believe this kind of organization technique must already be used elsewhere as well, but I haven't seen much of it from the projects I have encountered or the organizations I have worked for. So, yeah it's simple and obvious but I'm glad I came up with it myself and started using it from the start of the project. Here are the flags at the moment:
- DIARY just updating the diary.md
- SYNC just syncing/updating submodules
- CONFIG makes configurational changes like,
- adding dependencies
- making global file structure changes
- FEATURE adding features like:
- adding a new client component
- adding a new REST endpoint functionalities
- REFACTOR refactors like:
- refactoring a react component to multiple individual components
- OOPS made a mistake somewhere down the line, this commit is a part of an effort to fix it
Decided to keep a diary.md file explaining the work for that day. But now that I'm writing this blog, I'm starting to wonder if that's useless, but nonetheless, let's keep it for now.

Work (repo wise)

Here's an overview of the work in the respective repositories. The same can also be found in their corresponding diary.md files

xhopie (Main)

started the project structure
decided to use git submodules
learnt how to use and work with submodules
accidentally made blunders with submodules (happens everytime I try out a new git feature)
made respective changes in the next client and node server repositories
set up my VS-Code workspace config
added flags to be used in commit messages for better readability and navigation through commit history
regretted not recording this session (would have been fun to start documenting it on YouTube)

xhopie-client-next

decided the project structure
made 3 categories for the app
- marketing (all the landing pages / marketing pages)
- store (main store app)
- seller (seller interface)
- admin (admin dashboard)
gave each of these their own layout.tsx file as they can have drastically separate layouts later.
made all of them to by-default reference the globals.css in the app folder. As they would progressively need different styles, we may point to different globals.css in their respective folders/groups.

xhopie-server-node

just did a bare initialization of the app
added typescript, express and nodemon
nothing much for today in this app

Today's 1st of Jan 2024, and this is my first new year resolution. Starting out the project with hopes of atleast staying consistent and building something that can teach a lot.

Bye.

Stripes in Shaders

Manish — Fri, 11 Nov 2022 21:30:57 +0000

Arguments to the frag fn

the frag fn takes 4 arguments:

red value,
green value,
blue value, and
opacity value.

All these values lie in the range [0.0, 1.0].
Any value above 1.0 is treated the same as 1.0
and any value below 0.0 is treated the same as 0.0.

eg:

fragColor = vec4(1.0, 0.0, 0.0 ,1.0);
will produce the following result:

fragColor = vec4(0.0, 1.0, 0.0 , 1.0);
will produce the following result:

fragColor = vec4(0.0, 0.0, 1.0 , 1.0);
will produce the following result:

You can mix the 4 fields with different values to generate any other colour or effect.

Normalizing the coordinates to screen coordinates (uv)

// Normalized pixel coordinates (from 0 to 1)
vec2 uv = fragCoord/iResolution.xy;

now uv will store a vec2 with values from 0 to 1 with the leftmost coordinate value 0 and rightmost value with value 1.

Simple X-Gradient

// Normalized pixel coordinates (from 0 to 1)
vec2 uv = fragCoord/iResolution.xy;


// Output to screen
fragColor = vec4(uv.x, 0.0, 0.0 , 1.0);

this will give the following result

Simple Y-Gradient

doing the same but with uv.y:

// Normalized pixel coordinates (from 0 to 1)
vec2 uv = fragCoord/iResolution.xy;


// Output to screen
fragColor = vec4(uv.y, 0.0, 0.0 , 1.0);

output:

Combining colors

We can combine the 3 fields to get different colours such as:
fragColor = vec4(0.3, 0.0, 0.5 , 1.0);
output:

Stripes

to create stripes,
we start from a basic gradient:

fragColor = vec4(uv.x, 0.0, 0.5 , 1.0);

output:

right now the red value is varying linearly along the x-direction.

Lets start by choosing a function which oscillates unlike a linear function.

eg: sine function

fragColor = vec4(sin(uv.x), 0.0, 0.5 , 1.0);

output:

you may not be able to tell a lot of difference, but wait until we scale the input to the function:

for a linear func: fragColor = vec4(uv.x * 20.0, 0.0, 0.5 , 1.0);

output:

but for the sine func: fragColor = vec4(sin(uv.x * 20.0), 0.0, 0.5 , 1.0);

output:

as we see the red value for linear fn reaches 1 faster and then above 1 it behaves as 1, but for the oscillatory fn reaches 1 very fast and then again goes to -1, which is why we see the darker region more as values < 0 are treated as 0.

to get a more equal width strip pattern, we need to oscillate the values from 0 to 1 not -1 to 1.

for this lets try using the following trick
remove the -1 part by adding 1 to the func , ie, sin(uv.x) + 1.

but this will get us the answer from 0 to 2.

to manage this, we can halve this, ie, 0.5 * (sin(uv.x * 20.) + 1.)

output:

increasing the argument to sine func increases the frequency of the stripes and reduces the width:

eg: changing the scale from 20. to 40.
fragColor = vec4(0.5 * (sin(uv.x * 40.) + 1.), 0.0, 0.5 , 1.0)

output:

to make the strips sharp and not dissolving naturally, we can ceil the sine func which will give us values in sharp 0 and 1.

fragColor = vec4(ceil(sin(uv.x * 40.)), 0.0, 0.5 , 1.0);

Y-stripes

replacing uv.x in the above expression with uv.y gives us stripes along the y-direction

fragColor = vec4(0.5 * (sin(uv.y * 40.) + 1.), 0.0, 0.5 , 1.0);

output:

fragColor = vec4(ceil(sin(uv.x * 40.)), 0.0, 0.5 , 1.0);

combining the x and y expressions:
fragColor = vec4(0.5 * (sin(uv.y * 40.) + 1.) + 0.5 * (sin(uv.x * 40.) + 1.), 0.0, 0.5 , 1.0);

output:

sharpening the values:

fragColor = vec4(ceil(sin(uv.y * 40.)) + ceil(sin(uv.x * 40.)), 0.0, 0.5 , 1.0);

keeping the red stripes in x and blue stripes in y, we get:
fragColor = vec4(0.5 * (sin(uv.x * 40.) + 1.), 0.0, 0.5 * (sin(uv.y * 40.) + 1.) , 1.0);

fragColor = vec4(ceil(sin(uv.x * 40.)), 0.0, ceil(sin(uv.y * 40.)) , 1.0);

DEV Community: Manish

Inversion of Control and Frameworks v/s Libraries in Software Development

Understanding Inversion of Control

Frameworks vs. Libraries

Libraries

Frameworks

Conclusion

Day 2 | Xhopie - Starting up

Context

Work Overview

on xhopie-server-node

Environment Variables

Refactoring The Project's Folder Structure

Day 1 | Xhopie - Starting up

Work Overview

Work (repo wise)

xhopie (Main)

xhopie-client-next

xhopie-server-node

Stripes in Shaders

Arguments to the frag fn

Normalizing the coordinates to screen coordinates (uv)

Simple X-Gradient

Simple Y-Gradient

Combining colors

Stripes

Y-stripes

on `xhopie-server-node`