Tag: software engineering

DevDose: Understanding Angular’s ngOnInit in the Component Lifecycle
Introduction

Angular’s component lifecycle is a cornerstone of building robust applications, and understanding hooks like ngOnInit is critical for predictable behavior. This post dives into ngOnInit’s role, inspired by a recent project where lifecycle misuse led to subtle bugs.

Real-World Example

In a dashboard application, I encountered a component fetching data in its constructor, causing inconsistent UI updates. The constructor, meant for dependency injection, isn’t ideal for initialization logic. Moving the logic to ngOnInit resolved the issue, ensuring the component was fully instantiated before executing setup code.
```
import { Component, OnInit } from '@angular/core';
import { DataService } from './data.service';

@Component({
  selector: 'app-dashboard',
  templateUrl: './dashboard.component.html'
})
export class DashboardComponent implements OnInit {
  constructor(private dataService: DataService) {}

  ngOnInit(): void {
    this.displayData         toSignal(this.dataService.fetchData());
  }
}
```
Insight and Reasoning

ngOnInit is a lifecycle hook called by Angular after the constructor and initial property bindings are set, but before the component’s view is fully rendered. It’s the right place for initialization tasks like fetching data or setting up subscriptions because it ensures the component’s dependencies and inputs are ready.

Using the constructor for such logic risks premature execution, especially in complex components with asynchronous dependencies. In the dashboard case, ngOnInit ensured data fetching happened at a predictable point, avoiding race conditions and improving testability.

Conclusion

Mastering ngOnInit means knowing when and why to use it: post-construction, pre-rendering, for safe initialization. This small shift in approach can prevent subtle bugs and make your Angular components more reliable.
July 15, 2025
DevDose: Understanding JavaScript Equality Operators in Practice
Day Eight of Devdose

Introduction
A recent debugging session reminded me how JavaScript’s equality operators can trip up even experienced developers. The confusion between == and === often leads to subtle bugs, so I wanted to share a practical perspective on their differences.

Real-World Example

In a Node.js application, I encountered a bug where a user authentication check was failing unexpectedly. The code compared a user input string with a database value using ==. The input “123” was being compared to the database value 123, and the loose equality operator coerced the types, allowing the comparison to pass when it shouldn’t have. This exposed a security flaw, as invalid inputs slipped through.

Code Snippet

Consider this example:
```
const userInput = "123";
const dbValue = 123;

console.log(userInput == dbValue);  // true (loose equality, type coercion)
console.log(userInput === dbValue); // false (strict equality, no coercion)
```
The == operator converts operands to the same type before comparison, which can lead to unexpected results, like 0 == false evaluating to true. The === operator checks both value and type, ensuring precision.

Insight and Reasoning

The key difference lies in type coercion. Loose equality (==) tries to be forgiving by converting types, which can obscure bugs in dynamic systems like JavaScript applications. Strict equality (===) enforces type safety, making code behavior predictable and explicit. In the authentication bug, switching to === ensured inputs matched both value and type, closing the vulnerability. While == might save a few keystrokes in rare cases, its unpredictability outweighs the convenience in most production scenarios. My rule: always use === unless there’s a specific, well-documented reason to allow coercion.

Conclusion

Choosing between == and === isn’t just a style preference; it’s about reliability and clarity. Defaulting to strict equality reduces debugging time and strengthens code integrity.
July 10, 2025
DevDose: Practical Git Habits That Make Daily Dev Work Smoother
Day Seven of Devdose

Most developers know what Git is, but not everyone uses it in a way that truly supports clean, thoughtful engineering. This post isn’t a Git primer. It’s a look at a few habits I’ve adopted to avoid chaos in day-to-day coding.

A Few Practices That Have Stuck

One habit I’ve grown to rely on is merging frequently, ideally every hour or two. This keeps changes small, encourages working in safe, testable increments, and reduces the chance of painful merge conflicts. It also forces me to think about how to integrate unfinished work without breaking anything. That might mean wrapping logic in feature flags or using conditional rendering to isolate updates until they’re ready.

I also try to keep atomic commits. A commit should do one thing, whether that’s renaming a method or adding a new function. This habit makes code reviews cleaner and makes it easier to understand history later.

My Personal Merge Workflow

I avoid rebasing in most cases. Instead, I use a simple pattern that’s worked well in team settings:
```
# Rename old working branch
git branch -m feature-a-old

# Checkout fresh master and pull latest
git checkout master
git pull

# Recreate working branch and merge old changes
git checkout -b feature-a
git merge feature-a-old
```
This keeps my branch history simple, avoids rebase conflicts, and makes my changes easier to review. Some might argue that rebasing is cleaner. I find this approach more predictable and easier to manage, especially under pressure.

The Bigger Picture

None of this is about mastering every Git command. It’s about building small, repeatable habits that protect your focus and your team’s sanity. You don’t need to know every edge case, but you do need to commit intentionally and communicate clearly through your commits and merges.

Takeaway

Git isn’t just a tool to back up your work. It’s an opportunity to improve how you think about change. Small merges, clean commits, and a calm workflow go a long way in making codebases and teams more resilient.
July 6, 2025
DevDose: Reflect and Iterate: Two Habits That Sharpen the Craft

Day Six of Dailydose

I’ve wanted to keep a developer log for years. I always felt it would add a level of professionalism that’s often missing in day-to-day coding. Recently, using GPT to help prompt reflection points finally gave that idea some structure. Just a small bit of research and prompting unlocked something bigger: a habit of daily thinking, not just daily doing.

I call myself a software engineer rather than a developer or coder, because I hold myself to a professional standard. That includes clean code, testability, proper patterns, and yes, reflection. Whether or not you write a formal log, taking time to think about the decisions you made can uncover gaps and improve your work.

This isn’t about rewriting everything. It’s iteration. Maybe you used a dumb component where it made sense, wired up DTOs and facades, and just moved on. But when you revisit it, some names no longer make sense, or a pattern you used has evolved. It happens. That doesn’t mean the original code was wrong, but it might mean there’s a cleaner way now.

What worries me is when developers just get something working and throw it in without a second look. Sadly, I’ve seen that happen more often than I’d like. That lack of reflection leads to brittle systems and technical debt that builds quietly over time.

Takeaway: Reflecting doesn’t slow you down. It sharpens your decisions. Iterating on your own code, even slightly, is a sign of engineering discipline, not indecision.

The list Chat GPT provided to assist in daily logging (they were bonus content, nothing I asked for)

Using AI with Intention

July 6, 2025