DEV Community: kbartsch

NEWSARC.io: A New Way to See the World — Perspective on a Timeline

kbartsch — Tue, 17 Jun 2025 10:32:22 +0000

NEWSARC.io: A New Way to See the World — Perspective on a Timeline

Introduction: Have you ever felt like you’re only seeing part of the story?

Imagine standing in a room with just one tiny window. Every day, you look through it and see the same view. It becomes familiar — comforting, even — but deep down, you know there’s more out there.

That’s how reading the news often feels for me.

While trying to understand global events — wars, politics, markets, climate crises — I kept hitting the same wall: limited perspectives, missing context, and headlines that seemed to nudge me toward a conclusion rather than help me form one myself. I didn’t want pre-packaged opinions. I wanted the full picture and to be able to research myself.

👨‍💻 How NEWSARC Was Born

As a developer (and, let’s be honest, a bit of a news junkie recently), I began searching for better tools to navigate the chaos of modern news. That’s when I discovered various free tier news apis like finlight.me — one of many fascinating news API that opened some exciting possibilities for me.

I started experimenting, building a side project to bring different viewpoints together in one place. What began as a curiosity quickly became a mission with some friends. I got in touch with the developers at Finlight, shared my vision, and we started collaborating closely to shape a platform that might make a real change. Eventually, I joined forces with them — NEWSARC was born.

🧭 What is NEWSARC?

NEWSARC isn’t your typical news platform.

It’s a growing space designed to help people step outside their “news bubble” and see the bigger picture.

Our mission? To make it easier — and more enjoyable — to explore the full context behind global events. See timelines and make researching in the past easier and more comfortable.

We collect stories from a wide range of sources and connect them into one simple, powerful interface that helps you:

✅ View diverse perspectives side-by-side See how different media outlets cover the same event, and spot patterns, contradictions, or missing pieces.
📆 Trace events through time with historical context Understand how we got here by exploring the timeline of key events, decisions, and developments.
🧠 Build your own opinion — not inherit someone else’s No algorithms pushing one narrative. You get the facts, the context, and the tools to think for yourself.
🌍 Read articles from around the world — no language barrier NEWSARC automatically translates content into multiple languages, so you’re not limited by what’s written in your native tongue. The global conversation is open to everyone.
⚡ Get quick summaries and timelines with the help of AI Don’t have time to read it all? Let the AI generate concise summaries and timeline overviews so you can get up to speed in seconds — then dive deeper if you choose.

🚧 A Work in Progress — with Big Dreams

Let’s be clear: NEWSARC is still in its early days.

It’s raw, evolving, and far from perfect.

Right now, you might notice a limited number of sources or some rough edges — but that’s part of the journey. We’re actively working on:

Adding more diverse and independent news sources
Improving the user experience
Making research faster, smarter, and more enjoyable
Reducing bias through better curation and smart tooling
Building features that help curious people dig deeper
Build up the community to submit foreign news articels to be included in the timelines
Make more accessibility features

Think of this as an open beta. We’re building in public — and your feedback is part of the roadmap.

✨ Why It Matters

In today’s world, information is everywhere. But understanding? That’s harder to come by.

NEWSARC exists for people who don’t want to be told what to think. People who value curiosity, context, and critical thinking. People like you.

We believe that democracy starts with understanding — and that understanding grows when we have access to many voices, not just one.

🌍 Come Take a Look

This is your invitation.

Explore NEWSARC. Play around. See how it feels to read a story from more than one angle. If you like it, share it with someone who’s tired of seeing the world through a single window.

👉 Try it out at newsarc.io

We’re just getting started — and we’d love for you to be part of the journey.

Photo by AbsolutVision on Unsplash

Mastering External API Usage in Angular Interceptors with x-api-key

kbartsch — Tue, 03 Jun 2025 11:32:01 +0000

Image by T Hansen from Pixabay

Introduction : In Angular development, managing API calls to multiple endpoints is common. Some endpoints may require an x-api-key for authentication, while others don’t. Instead of hardcoding headers in each service, Angular’s HttpInterceptor allows us to centralize request handling and apply API keys conditionally. Let’s explore how to implement this and the pros and cons of conditional key management. (For only readers Step 4is the important one)

Level: For everyone

Note: In this tutorial, we’ll build a simple Angular 19 application to fetch news articles using the Finlight.me News API . While this guide uses Finlight.me to demonstrate managing an x-api-key, you can easily adapt the approach for any API requiring custom headers. Our focus will be on creating an interceptor to handle the x-api-key and applying it selectively to specific API requests.

Step 1: Set Up Your Angular Project

First, create a new Angular project and install required dependencies. (NodeJS installation required)

Create a new Angular project :

npx -p @angular/cli ng new angular-news-app 
cd angular-news-app

Generate the Environments files for your project:

npx -p @angular/cli ng generate environments

Open your project in your favorite editor (e.g., VS Code).

Step 2: Obtain the Finlight API Key

Go to Finlight.me and create an account or use alternativ APIs.
Navigate to the API Keys section in the menu after logging in.
Copy your free API key.

Step 3: Configure the Environment File

Store your API key in Angular’s environment configuration file for secure and environment-specific management.

Open src/environments/environment.development.ts and add your API key:

export const environment = {   
  production: false,   
  finlightApiKey: 'your-finlight-api-key-here' 
};

Open src/environments/environment.ts and update the finlightApiKey for production:

export const environment = {
  production: true,
  finlightApiKey: 'your-production-finlight-api-key-here'
};

Step 4: Create the Interceptor

We’ll create an interceptor to attach the x-api-key header only to Finlight’s API requests.

Generate the interceptor:

ng generate interceptor interceptors/api-key

Implement the interceptor in src/app/interceptors/api-key.interceptor.ts:

import { Injectable } from '@angular/core';
import { HttpInterceptor, HttpRequest, HttpHandler, HttpEvent } from '@angular/common/http';
import { Observable } from 'rxjs';
import { environment } from '../../environments/environment';

@Injectable()
export class ApiKeyInterceptor implements HttpInterceptor {
  private apiKey = environment.finlightApiKey;

  intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    const finlightUrlPattern = 'https://api.finlight.me'; // Match Finlight API endpoints

    if (req.url.includes(finlightUrlPattern)) {
      const secureReq = req.clone({
        headers: req.headers.set('x-api-key', this.apiKey)
      });
      return next.handle(secureReq);
    }

    // Forward requests to non-secure APIs without modifying
    return next.handle(req);
  }
}

import { HTTP_INTERCEPTORS } from '@angular/common/http';
import { ApiKeyInterceptor } from './interceptors/api-key.interceptor';

@NgModule({
  providers: [
    { provide: HTTP_INTERCEPTORS, useClass: ApiKeyInterceptor, multi: true }
  ]
})
export class AppModule {}

Step 5: Create the News Service

We’ll create a service to fetch data from the Finlight API.

Generate the service:

ng generate service services/news

Implement the service in src/app/services/news.service.ts:

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';

@Injectable({
  providedIn: 'root'
})
export class NewsService {
  private apiUrl = 'https://api.finlight.me/v1/articles';

  constructor(private http: HttpClient) {}

  // Fetch news from Finlight API
  getNews(): Observable<any> {
    return this.http.get(this.apiUrl);
  }
}

Step 6: Build the News Component

Create a component to display the news.

Generate the component:

ng generate component components/news

Update src/app/components/news/news.component.ts:

import { Component, OnInit } from '@angular/core';
import { NewsService } from '../../services/news.service';

@Component({
  selector: 'app-news',
  templateUrl: './news.component.html',
  styleUrls: ['./news.component.css']
})
export class NewsComponent implements OnInit {
  newsArticles: any[] = [];

  constructor(private newsService: NewsService) {}

  ngOnInit(): void {
    this.newsService.getNews().subscribe({
      next: (data) => (this.newsArticles = data.articles),
      error: (err) => console.error('Error fetching news:', err)
    });
  }
}

Update the component’s template in src/app/components/news/news.component.html:

<div class="news-container">
  <h1>Latest News</h1>
  <div *ngFor="let article of newsArticles" class="news-article">
    <h2>{{ article.title }}</h2>
    <p>{{ article.publishDate}}</p>
    <a [href]="article.link" target="_blank">Read More</a>
  </div>
</div>

Add some styles in src/app/components/news/news.component.css:

.news-container {
  padding: 20px;
  font-family: Arial, sans-serif;
}
.news-article {
  border-bottom: 1px solid #ccc;
  margin-bottom: 20px;
  padding-bottom: 10px;
}
a {
  color: #007bff;
  text-decoration: none;
}
a:hover {
  text-decoration: underline;
}

Step 7: Add the News Component to the App

Update src/app/app.component.html to include the NewsComponent:

<app-news></app-news>

Serve the app in the terminal:

npm start

Step 8: Test the Application

Open your browser and navigate to http://localhost:4200.
The app will fetch and display the latest news from the Finlight API.
Check the network requests in your browser’s developer tools to verify that the x-api-key is attached to requests to the secure API.

Final Thoughts

In this tutorial, you’ve built a simple Angular app that fetches news articles using the Finlight API. By leveraging an Angular interceptor, you managed the x-api-key authentication in a clean, reusable way, applying it only to secure requests.

This approach not only simplifies your code but also scales well for applications interacting with multiple APIs. Remember to keep your API keys secure and consider moving sensitive operations to the backend for production-grade security. There is also many things to learn and also to improve for example move the api url into an constant or use the new control flow from angular 17, but that is another story.

Happy coding! 🚀

Mastering package.json Versioning: Essential for Node.js Developers

kbartsch — Tue, 20 May 2025 11:51:52 +0000

Introduction: The package.json file is foundational for managing Node.js project dependencies. This configuration file, if managed properly, can be a powerful tool to ensure project stability and maintainability. One of its core features is version management, which hinges on a standard called Semantic Versioning (SemVer). Understanding this can significantly streamline your dependency management.

Level: Beginner

Understanding Semantic Versioning (SemVer)

Semantic Versioning is a versioning system that uses a three-part number: major.minor.patch. Each segment has a specific purpose:

major: Incremented for incompatible API changes,
minor: Incremented for new features that are backward compatible, and
patch: Incremented for backward-compatible bug fixes.

Here’s an example to illustrate:

"dependencies": {
  "express": "4.17.1"
}

This line specifies that the project depends explicitly on version 4.17.1 of Express. It’s a precise version with no room for automatic updates.

Version Modifiers: Carets and Tildes

The caret (^) and tilde (~) modifiers introduce flexibility in how updates are handled:

^: This allows the installation of all future minor and patch versions without changing the major version. For instance:

"dependencies": {
  "lodash": "^4.17.15"
}

This configuration permits updates to any 4.x.x version up to, but not including, 5.0.0.

~: This is more restrictive, allowing only patch updates within a minor version:

"dependencies": {
  "moment": "~2.24.0"
}

This limits updates to the 2.24.x range, offering a conservative approach to updates.

In short:

Caret (^): Updates allowed within the current major version.

Example: If you specify ^1.2.3, updates are permitted to any 1.x.x version up to but not including 2.0.0.

Tilde (~): Limits updates to the current minor version’s patch releases.

Example: Specifying ~1.2.3 allows updates within the 1.2.x range, but not to 1.3.0 or higher.

Advanced Versioning: Ranges and Wildcards

For more specific needs, developers might use greater than (>) or less than (<) symbols, or even wildcards (*):

> and <: Specify versions greater or less than a given version, as in:

"dependencies": {
  "react": ">16.13.1"
}

This setup demands any version of React newer than 16.13.1.

*: This wildcard allows any version:

"dependencies": {
  "vue": "*"
}

This signifies readiness to accept any released version, which is generally not recommended for production environments.

Best Practices for Dependency Management

Regular Reviews: Actively monitor and review the project’s dependencies.
Utilize Lockfiles: Make use of package-lock.json or yarn.lock to ensure consistency across installations.
Stay Updated: Use tools like npm outdated to keep informed about newer versions and assess their impact before upgrading.

By understanding package.json versioning, developers can better manage their project dependencies, avoiding potential conflicts and ensuring smoother operations. It’s essential to grasp each element of your dependency versioning to maintain a robust and stable architecture.

Thank you for reading! I hope this quick guide helps you get a better grip on using version modifiers in your package.json. Happy coding and feel free to share!

References: NPM documentation

Photo by Markus Winkler on Unsplash

Websockets vs. APIs: NewsAPI Features That Stands Out

kbartsch — Tue, 13 May 2025 11:32:21 +0000

Introduction: Many news platforms deliver articles via GET APIs , a standard method where you request data and get the latest articles back. But there’s a catch: this method often involves delays, and you might miss articles that are published just after your request or scraped later for past dates.

Level : Beginner (2 min readtime)

The Classic API — Good, but not Real-Time

Most platforms rely on GET APIs to deliver the latest content. You send a request, and the API returns the current articles. While this works, it comes with a delay, meaning you might miss a newly published article if it’s not included in the response.

This approach is fine for users who don’t mind waiting for the next refresh. However, the major drawback is that you’re not getting content in real-time.

Websockets — Real-Time, No Delays

On the other hand, Finlight.me ( I work with Finlight.me but there are also other apis that might have this — https://techdailyfeed.com/10-best-news-apis-for-devs) uses Websockets. With Websockets, you get immediate updates as soon as new articles are available — no need to keep making requests.

Even if articles are published later, the Websocket pushes them to you right away. No more waiting or missing out on the latest news.

Why Websockets Make a Difference

Real-Time Updates: Websockets deliver news instantly, while APIs require you to manually request updates.
No Missing Articles: With Websockets, you get all new content, even if it’s older but newly published.
Effortless: Websockets push content directly to you, so you don’t have to constantly refresh or check for updates.

Conclusion: The Edge of Real-Time

While APIs work for users who are okay with delays, Finlight.me ’s Websockets offer a clear advantage for those who want real-time news without the wait. It’s a simple but powerful improvement that ensures you never miss out on the latest articles.

Disclaimer: I am currently working on news APIs and testing features for my own app. This post reflects my approach to evaluating news platforms and my experience working with Finlight.me, where I provided feedback to help improve their service. I highly recommend testing their free tier to make up your own mind and see how it fits your needs, because there is no higher free tier on other platforms right now.

Photo by Christopher Robin Ebbinghaus on Unsplash

Comparing News API Services: Finlight.me vs. Newsapi.org

kbartsch — Wed, 07 May 2025 11:01:33 +0000

Photo by Fujiphilm on Unsplash

I am currently experimenting with scrapers and news APIs as part of my programming journey. While brainstorming options, I stumbled upon two notable services: Finlight.me and Newsapi.org. Both offer intriguing possibilities, but they cater to slightly different needs. Here’s what I’ve discovered while exploring these platforms.

Newsapi.org: The Veteran of News APIs

Newsapi.org is a well-known name in the world of news aggregation APIs. It’s been around for a while, and its established features make it appealing. However, it does have some limitations, especially for someone like me who’s testing and learning.

Features:

Article Search and Live Headlines : Great for searching articles and getting live top headlines.
Access to Historical Data : Articles up to a month old can be searched, though the free tier has delays.
CORS Support : Cross-Origin Resource Sharing (CORS) is enabled, which makes localhost development easier.

Limitations of the Free Tier:

Request Cap : The free tier only allows 100 requests per day — a bit restrictive when experimenting.
Article Delay : Articles are delayed by 24 hours, which isn’t ideal for real-time applications.
No SLA or Extra Requests : There’s no Service Level Agreement (SLA), and you can’t request more in the free plan.
Pricing : It becomes pricey if you need more extensive access.

Finlight.me: The New Challenger

On the other hand, I found Finlight.me, a newer platform that’s specifically focused on financial news. What caught my attention was how much they emphasize user feedback and their plans to keep improving based on it. This approach feels refreshing for someone like me who’s experimenting and might have specific needs.

Features:

Generous Free Tier : Their free plan includes 10,000 requests per month , which is incredibly useful for testing.
Sentiment Analysis : This built-in feature helps analyze the tone of financial news articles — something I find fascinating.
Rich Data Access : Offers real-time and historical data, plus article content.
CORS and Websockets : Makes integrating with web apps and receiving real-time updates easier.
Future-Forward : They’re planning advanced AI-driven sentiment analysis, which sounds exciting.

Why It Stands Out:

Unlike Newsapi.org, Finlight.me actively seeks feedback to refine its offerings. This focus on financial news and adaptability makes it a compelling option for developers like me who value experimentation and responsiveness.

One thing I particularly appreciate is how easy it is to contact the developers. Since it’s still a small platform, they’re very responsive. For instance, I suggested adding a news source that I was particularly interested in, and they quickly integrated it into their service for testing. It feels great to contribute to a platform with so much potential, especially when their free tier is already so fair and generous.

My Takeaways

If you’re also exploring APIs for a project or learning, here’s what I’ve found:

Newsapi.org is solid if you need a mature platform with broad news coverage, but its free tier is limited. No brain option.
Finlight.me shines for financial news and offers much more flexibility for free, making it great for testing and learning. Option for builders and community interessted people.

Why Feedback Matters

What I really like about Finlight.me is their openness to feedback. If you’re trying it out, you can share your thoughts to help them improve. It’s rare to find a service so willing to adapt based on user input that quick.

Conclusion

For me, Finlight.me’s generous free tier and focus on financial news make it the more exciting choice, especially as I’m still experimenting and learning. Newsapi.org, on the other hand, is a safe and trusted option if you’re ready to commit to higher usage costs. Whether you’re brainstorming or building, there’s something to appreciate about both platforms.

Understanding the SOLID Principles in Software Development

kbartsch — Tue, 07 May 2024 10:02:45 +0000

Introduction : In the realm of software development, adhering to best practices and design principles is paramount for creating robust, maintainable, and scalable codebases. One such set of principles that has gained widespread recognition is the SOLID principles. These principles serve as a guideline to facilitate the creation of software that is easy to understand, maintain, and extend. In this article, we will provide an overview of the SOLID principles, outlining each one’s significance and how they contribute to writing high-quality code.

Level: For everyone

Note: Keep in mind that this article is outlined as an overview, providing a brief introduction to each of the SOLID principles. If you’re interested in delving deeper into any specific principle, you can click on the corresponding links provided within the overview. Each link will redirect you to a detailed blog article dedicated to that particular SOLID principle.

SOLID Principles Overview:

Single Responsibility Principle (SRP): The Single Responsibility Principle advocates that a class should have only one reason to change, meaning it should have only one responsibility or job. By adhering to this principle, each class becomes focused and encapsulated, making it easier to understand, test, and maintain. — Link to detailed article on SRP.
Open/Closed Principle (OCP): The Open/Closed Principle emphasizes that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This principle encourages developers to design systems in a way that new functionalities can be added without altering existing code, thus minimizing the risk of introducing bugs. — Link to detailed article on OCP.
Liskov Substitution Principle (LSP): The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. This principle ensures that derived classes adhere to the contracts established by their base classes, promoting polymorphism and enhancing code reusability. — Link to detailed article on LSP .
Interface Segregation Principle (ISP): The Interface Segregation Principle suggests that clients should not be forced to depend on interfaces they don’t use. Instead of implementing large, monolithic interfaces, it’s better to segregate them into smaller, specific ones, tailored to the needs of individual clients. This promotes loose coupling and ensures that classes remain focused on their intended functionality. — Link to detailed article on ISP.
Dependency Inversion Principle (DIP): The Dependency Inversion Principle advocates that high-level modules should not depend on low-level modules; both should depend on abstractions. Furthermore, abstractions should not depend on details; details should depend on abstractions. By decoupling components and relying on abstractions, code becomes more flexible, reusable, and easier to test. — Link to detailed article on DIP.

Conclusion: The SOLID principles serve as foundational concepts in object-oriented design, guiding developers towards writing cleaner, more maintainable, and scalable code. By understanding and applying these principles, software engineers can build systems that are easier to extend, modify, and maintain, ultimately leading to higher-quality software products. Whether you’re a seasoned developer or just starting your journey, incorporating SOLID principles into your development practices will undoubtedly elevate your coding skills and contribute to the creation of better software solutions.

Outro: Thanks to you!

If you found this article and all other detail articles informative and helpful, feel free to share it with your fellow developers who might also benefit from learning about SOLID principles. Additionally, don’t forget to follow for more insightful content on software development best practices and stay updated on latest articles.

Your support and engagement mean the world to me as it shows that the articles are interesting and helpful to continue. Together, let’s strive for excellence in software craftsmanship, continue knowledge-sharing in the vast landscape of IT and build a community committed to creating elegant, maintainable, and scalable software solutions.

Thank you once again for your time. Happy coding!

Photo by Jason Goodman on Unsplash

SOLID Pattern — Liskov Substitution Principle

kbartsch — Tue, 16 Apr 2024 10:01:44 +0000

SOLID Pattern — Liskov Substitution Principle

Welcome back to the last article on my SOLID pattern research by myself. As software engineers, we strive to write code that is not only functional but also maintainable, scalable, and robust. In object-oriented programming, adhering to solid principles is crucial for achieving these goals. One such principle is the Liskov Substitution Principle (LSP), named after Barbara Liskov, which states that objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program.

Level: None

In TypeScript, a superset of JavaScript, we can leverage the static type system to enforce the Liskov Substitution Principle effectively. Let’s delve into some code examples to understand how this principle works and its implications.

Consider the classic example of shapes, where we have a superclass Shape and subclasses Circle and Square. According to LSP, we should be able to substitute Circle and Square objects wherever Shape objects are expected.

class Shape {
    area(): number {
        throw new Error("Method not implemented.");
    }
}

class Circle extends Shape {
    radius: number;

    constructor(radius: number) {
        super();
        this.radius = radius;
    }

    area(): number {
        return Math.PI * this.radius * this.radius;
    }
}

class Square extends Shape {
    sideLength: number;

    constructor(sideLength: number) {
        super();
        this.sideLength = sideLength;
    }

    area(): number {
        return this.sideLength * this.sideLength;
    }
}

Now, let’s say we have a function calculateArea that expects an array of shapes and computes the total area:

function calculateArea(shapes: Shape[]): number {
    let totalArea = 0;
    shapes.forEach(shape => {
        totalArea += shape.area();
    });
    return totalArea;
}

By following LSP, we can confidently pass an array of Circle and Square objects to calculateArea, knowing that it will work as expected:

const shapes: Shape[] = [new Circle(5), new Square(4)];
console.log(calculateArea(shapes)); // Output: 103.67 (approximately)

One advantage of adhering to LSP is the flexibility it provides. We can easily extend our system by adding new subclasses without modifying existing code. However, violating LSP can lead to unexpected behavior and bugs. For example, if we introduce a Triangle class that doesn't override the area method properly, it can break the behavior of calculateArea.

class Triangle extends Shape {
    base: number;
    height: number;

    constructor(base: number, height: number) {
        super();
        this.base = base;
        this.height = height;
    }
}

const shapes: Shape[] = [new Circle(5), new Square(4), new Triangle(3, 6)];
console.log(calculateArea(shapes)); // Output: NaN (Not a Number)

Conclusion: Liskov Substitution Principle plays a crucial role in designing robust and maintainable software systems. By adhering to this principle in TypeScript, we can write code that is not only type-safe but also flexible and easily extensible. Remember, honoring LSP leads to cleaner, more reliable code that stands the test of time.

Hope the article was helpful. For the next and last story on this topic a summarized version of all patterns will be writen shortly. If you like what I do feel free to share and follow me! Have a great day!

Photo by Christina @ wocintechchat.com on Unsplash

SOLID Pattern — Interface Segregation Principle

kbartsch — Tue, 09 Apr 2024 10:02:19 +0000

SOLID Pattern — Interface Segregation Principle

Greatings, today we are looking into a design pattern that will help us strive to create robust, maintainable, and scalable codebases. One such pattern in the realm of object-oriented design is the Interface Segregation Principle (ISP).

Level: Beginner

At its core, ISP advocates for breaking down bulky interfaces into smaller, more focused ones, tailored to specific client requirements. This approach not only promotes cohesion but also prevents unnecessary dependencies , paving the way for cleaner, more modular code.

Let’s delve into some code examples to illustrate the prowess of ISP in TypeScript.

The Problem:

Consider a scenario where we have a Printer interface that encompasses various functionalities:

interface Printer {
  printDocument(): void;
  scanDocument(): void;
  faxDocument(): void;
}

This Printer interface seems innocent at first glance, but it's a classic violation of ISP. What if we have a client who only needs printing capabilities? They would be forced to implement unnecessary methods like scanDocument and faxDocument, violating the principle of "Clients should not be forced to depend on methods they do not use."

The Solution:

By adhering to ISP, we can refactor our interfaces to be more granular:

interface Printer {
  printDocument(): void;
}

interface Scanner {
  scanDocument(): void;
}

interface FaxMachine {
  faxDocument(): void;
}

With this segregation, clients can now choose interfaces based on their specific needs. If a client only requires printing, they’ll depend solely on the Printer interface, reducing unnecessary coupling and potential headaches down the road.

Pros and Cons:

💡Pros:

Enhanced Modularity: Segregated interfaces promote a modular design, allowing for easier maintenance and extensibility.
Reduced Coupling: Clients depend only on what they need, mitigating the ripple effects of changes in unrelated functionalities.
Improved Testability: Smaller interfaces facilitate targeted testing, leading to more robust test suites.

🚨Cons:

Increased Interface Count: Segregating interfaces might result in a proliferation of smaller interfaces, potentially cluttering the codebase if not managed properly.
Initial Overhead: Refactoring existing code to adhere to ISP can be time-consuming initially, especially in larger projects.

Conclusion: In the ever-evolving landscape of software development, adherence to principles like ISP is paramount. In TypeScript, where strong typing is a boon, leveraging ISP can elevate your codebase to new heights of maintainability and flexibility. By embracing interface segregation, we pave the way for cleaner, more adaptable software systems that stand the test of time.

Happy coding! Feel free to share and follow!

Photo by True Agency on Unsplash

Why AI Alone Can’t Mentor Junior Devs

kbartsch — Wed, 03 Apr 2024 10:01:57 +0000

Hello fellow coders, let’s dive into a different but broad world of software development, where junior devs are like the lone wolves adventurers armed with a map, a compass, and, lately, a shiny new AI companion. While it’s tempting to let the bots take the reins, there’s a danger in relying solely on artificial intelligence to guide our coding prodigies. Please note that this article is my opinion and sight on that topic.

Level: None

Photo by Helena Lopes on Unsplash

Picture this: You hand over the responsibility of training junior devs to an AI, hoping for a seamless journey through the valleys of variables and the peaks of polymorphism. However, as any seasoned developer knows, the real coding expedition is more like a complex RPG than a stroll through a well-tailored tutorial and documentations.

if we are looking for example at the code review, a crucial rite of passage for any developer from junior to seniors. AI tools can swiftly identify syntax errors, point out style violations, and even suggest potential optimizations. But, my dear fellow devs, let’s not underestimate the importance of human experience in the realm of software craftsmanship. Now, don’t get me wrong, AI has come a long way now and can provide valuable insights but for now its still missing the human touch and knowledge of the surrounding elements.

Imagine you’re facing a tricky bug, a real head-scratcher that has you contemplating a career change to goat herding. Here’s where the seasoned senior devs swoop in, capes flapping in the debugging breeze, armed with their mighty stack traces and knowledge of legacy code. Can AI truly grasp the intricacies of your project’s unique architecture and business logic? Can it identify future problems, risks or bugs related to architectural decision. At least not when this article was written but in the future this might be the case.

Now, consider the training process. AI , with its vast knowledge base, can provide theoretical insights, but it lacks the personal touch of a mentorship forged through years of battles fought in the trenches of version control conflicts and merge hell. A real mentor in form of a senior developer can provide this personal touch by showing insights in problems, experienced mistakes and motivate juniors to reach thier business goals.

Conclusion: AI can be a powerful ally, but it should complement, not replace, the human touch. After all, the best code is crafted with a dash of humanity, a sprinkle of AI magic, and a generous helping of experience by colleagues. Also keep in mind that AI should not and cannot replace the unique work environment atmosphere of individuals and adds value to the company a junior is working in.

Hope you enjoyed my little articel! Feel free to like and share!

SOLID Pattern — Single-Responsibility Principle

kbartsch — Mon, 25 Mar 2024 11:02:24 +0000

SOLID Pattern — Single-Responsibility Principle

Greetings, today let’s dive into another SOLID pattern the Single-Responsibility Principle (SRP) with TypeScript. With this pattern we are able to improve issues like maintainability and scalability.

Level: Beginner

The SRP, championed by the venerable Robert C. Martin, admonishes us to imbue our classes with a singular purpose, ensuring that each class is responsible for just one aspect of functionality within our codebase. But how does this manifest in the TypeScript ecosystem? Let’s look at some code examples to see that it is not that big of a deal.

Consider a hypothetical scenario where we’re crafting a rudimentary ship management system:

// A class representing a ship
class Ship {
  private name: string;
  private crew: string[];

  constructor(name: string, crew: string[]) {
    this.name = name;
    this.crew = crew;
  }

  public sail(): void {
    console.log(`${this.name} sets sail with a crew of ${this.crew.join(', ')}.`);
    // Logic for setting sail
  }

  public loadCargo(cargo: string[]): void {
    console.log(`${this.name} loads cargo: ${cargo.join(', ')}.`);
    // Logic for loading cargo
  }
}

Here, our Ship class seems okay at first glance, handling both sailing and cargo-loading duties. However, the SRP recommends us to separate concerns more distinctly. Let's follow this:

// A class representing a ship
class Ship {
  private name: string;
  private crew: string[];

  constructor(name: string, crew: string[]) {
    this.name = name;
    this.crew = crew;
  }

  public sail(): void {
    console.log(`${this.name} sets sail with a crew of ${this.crew.join(', ')}.`);
    // Logic for setting sail
  }
}

// A separate class for managing cargo operations
class CargoManager {
  public loadCargo(ship: Ship, cargo: string[]): void {
    console.log(`${ship.name} loads cargo: ${cargo.join(', ')}.`);
    // Logic for loading cargo
  }
}

By untangling cargo-related operations into a distinct CargoManager class, we honor the SRP, ensuring that each class has a singular responsibility. This fosters code that's easier to comprehend, maintain, and extend—a improvement indeed!

Let’s have a look and delve into the pros and cons of the Single-Responsibility Principle (SRP).

💡 Pros:

Clarity and Maintainability: By adhering to the SRP, we create classes that are focused and concise, making our codebase easier to understand and maintain. Each class encapsulates a single responsibility, reducing cognitive load and facilitating future modifications.
Scalability: Separating concerns according to the SRP fosters modularization, enabling us to scale our codebase more efficiently. As our project grows, we can add new functionality without disturbing existing code, promoting code reuse and extensibility.
Testability: With well-defined responsibilities, our classes become more testable. Unit testing becomes simpler, as we can isolate individual components and verify their behavior independently, leading to more robust and reliable code.

🚨 Cons:

Increased Complexity: Adhering strictly to the SRP can sometimes lead to an explosion of classes, introducing additional complexity and overhead. Managing a multitude of small classes may become cumbersome, especially in smaller projects or when dealing with simple functionalities.
Indirection and Abstraction: Dividing responsibilities into separate classes may introduce indirection, making it harder to trace the flow of logic through our codebase. This abstraction layer can sometimes obscure the relationships between different components, requiring developers to invest extra effort in understanding the code.
Potential Over-Engineering: In our zeal to uphold the SRP, we must guard against over-engineering. Splitting responsibilities too finely can lead to unnecessary abstraction and code bloat, complicating the codebase without providing significant benefits in terms of clarity or maintainability.

Conclusion: Following the Single Responsibility Principle (SRP) makes our code easier to maintain, but it also means we might need more classes and extra steps, which can add some complexity. In short we must strike a balance between clarity and pragmatism.

Hope you enjoyed this little articel! Feel free to follow and sharing my library of knowledge, that’s been created here.

Photo by Sigmund on Unsplash