DEV Community: Michael Gokey

Common Naming Case Types

Michael Gokey — Tue, 21 Oct 2025 14:48:31 +0000

If you've worked across multiple languages or frameworks, you've probably noticed that naming conventions are everywhere, and they're not always consistent. Each project uses something different. camelCase, another prefers snake_case, and suddenly you're context-switching between PascalCase components and kebab-case CSS classes.

This is a quick reference I keep handy when I'm switching projects or reviewing code. It covers the most common naming conventions, where they're typically used, and why. It's nothing fancy; it's a cheat sheet that saves me from second-guessing myself when I'm deep in the work.

A quick reference guide to the naming conventions used across programming languages, documentation, and UI design.

Common Case Types

camelCase

The first word is lowercase, subsequent words are capitalized
Example: myVariableName
Commonly used in: JavaScript, Java, and for variables or function names

PascalCase

Every word is capitalized, including the first
Example: MyVariableName
Often used for: Class names, types, or components in many languages

kebab-case

Words are lowercase and separated by hyphens (-)
Example: my-variable-name
Often used in: URLs, file names, CSS class names

snake_case

Words are lowercase and separated by underscores (_)
Example: my_variable_name
Common in: Python, databases, and some configuration files

SCREAMING_SNAKE_CASE

Like snake_case but all uppercase
Example: MY_VARIABLE_NAME
Often used for: Constants

Train-Case

Like PascalCase but with hyphens
Example: My-Variable-Name
Usage: Less common, sometimes used in URLs or documentation

dot.case

Words separated by dots (.)
Example: my.variable.name
Sometimes used in: Config files or namespaces

Title Case

Capitalize the first letter of most words (like a book title)
Example: My Variable Name
Often used in: Headings, menu items, or UI text

Sentence case

Only the first word (and proper nouns) capitalized
Example: My variable name
Common in: Normal text, documentation, and UI instructions

lowercase

Everything in lowercase, no separators
Example: myvariablename
Usage: Rare, but sometimes used in URLs or legacy systems

Notes and Patterns

Many of these are interchangeable depending on context: programming language, framework, or documentation style.

You'll often see a mix in modern projects:

JavaScript:

camelCase for variables
PascalCase for classes
SCREAMING_SNAKE_CASE for constants

Python:

snake_case for functions and variables
PascalCase for classes
SCREAMING_SNAKE_CASE for constants

CSS / HTML:

kebab-case for class names and IDs

Closing

Naming conventions matter more than they should, but they do matter. Consistency makes code easier to read, review, and maintain. It also makes onboarding smoother when you're working with a team or picking up someone else's work.

If this helps you avoid one moment of "wait, should this be camelCase or snake_case?" then it's done its job. Bookmark it, share it, or keep it handy. Whatever makes your workflow a little smoother.

How Social Media Feed Algorithms Work

Michael Gokey — Thu, 02 Oct 2025 21:13:32 +0000

A social media feed algorithm acts like a personal content curator, choosing which posts you see and in what order. Imagine it as a music playlist generator. It collects all possible songs (or posts), removes ones you've already heard, scores how much you might enjoy each, ranks them, adds some variety, and then gives you a playlist tailored just for you.

Core Components

User Profiling System

The algorithm builds detailed profiles of each user by tracking:

Interaction History: What you like, share, comment on, and how long you view content
Social Connections: Who you follow, message, and interact with most
Content Preferences: Whether you prefer videos over text, news over memes
Usage Patterns: When you're most active, what device you use
Demographic Signals: Age, location, language preferences

Content Scoring Engine

Every potential post gets evaluated using machine learning models that consider hundreds of signals, but the main factors include:

Relevance to your interests and past behavior
Relationship strength with the content creator
Content quality and engagement from other users
Recency and trending status
Content type match to your preferences

The Algorithm Process (Step-by-Step)

1. Collect Candidate Posts

The system gathers potential content from multiple sources:

Your Network: Posts from friends, family, and accounts you follow
Trending Content: Popular posts in your region or globally
Interest-Based: Content matching your topics and hobbies
Recommended: Posts from accounts similar to ones you follow
Promoted: Advertisements and sponsored content

2. Filter Out Unwanted Content

Before scoring, the algorithm removes:

Duplicate posts you've already seen
Content flagged as spam or inappropriate
Posts from blocked or muted accounts
Content that violates platform policies
Posts outside your language/location preferences

3. Score Each Post

This is where the magic happens. For every remaining post, the algorithm calculates a "relevance score" using factors like:

User Engagement Signals: Did you like, share, or comment on similar posts before?
Relationship Strength: How close are you to the author (DMs, likes, tags)?
Content Type Preference: Do you watch more videos than read text posts?
Recency: Is this new or old?
Virality/Quality: Is the post popular with others?

The scoring formula looks something like:

score(post) = w1 × engagement_probability
            + w2 × relationship_strength  
            + w3 × content_type_match
            + w4 × recency_decay
            + w5 × global_quality

Where each "w" represents how much weight the platform gives to that factor.

4. Apply Machine Learning Prediction

The algorithm uses trained neural networks or other ML models to predict:

Probability you'll engage (like, comment, share)
Time you'll spend viewing the content
Likelihood you'll find it valuable based on similar users' behavior

5. Business Logic & Final Adjustments

The raw ML scores get modified by:

Promoting paid content (ads get score boosts)
Ensuring diversity (penalizing too much similar content)
Boosting close friends (recent posts from best friends get priority)
Balancing content types (mixing videos, photos, text posts)

6. Rank & Sort Posts

Sort all posts by their final scores, highest first
Apply diversity rules so you don't see 10 posts from the same person
Insert promoted content at strategic intervals
Mix content types for visual variety

7. Build Final Feed

Take the top N posts (usually 50-100 for initial load)
Add slight randomization to prevent identical feeds
Log what was shown for future learning
Display the personalized feed to you

SOCIAL MEDIA FEED ALGORITHM - PSEUDOCODE

FUNCTION generate_personalized_feed(user_id):

    // Step 1: Get user profile and preferences
    user_profile = get_user_profile(user_id)
    user_interests = extract_user_interests(user_profile)
    user_connections = get_user_connections(user_id)

    // Step 2: Gather candidate posts from multiple sources
    candidate_posts = empty_list()

    // Get posts from friends and followed accounts
    friend_posts = get_posts_from_connections(user_connections, time_limit=24_hours)
    candidate_posts.add(friend_posts)

    // Get trending/popular posts
    trending_posts = get_trending_posts(user_location, time_limit=6_hours)
    candidate_posts.add(trending_posts)

    // Get posts based on user interests
    interest_posts = get_posts_by_topics(user_interests, time_limit=12_hours)
    candidate_posts.add(interest_posts)

    // Step 3: Initial filtering
    filtered_posts = empty_list()
    FOR each post in candidate_posts:
        IF post is not spam AND 
           post is not inappropriate AND 
           user has not seen post AND
           post is not blocked content:
            filtered_posts.add(post)

    // Step 4: Feature engineering - calculate signals for each post
    scored_posts = empty_list()
    FOR each post in filtered_posts:
        post_features = calculate_post_features(post, user_profile)
        // Features include:
        // - recency_score = calculate_time_decay(post.timestamp)
        // - engagement_score = (likes + comments + shares) / followers
        // - relevance_score = match_user_interests(post.content, user_interests)
        // - relationship_score = connection_strength(post.author, user_id)
        // - content_type_score = user_preference_for_type(post.type, user_profile)

        scored_posts.add({post: post, features: post_features})

    // Step 5: Apply machine learning model to predict engagement
    FOR each scored_post in scored_posts:
        predicted_engagement = ml_model.predict(scored_post.features)
        scored_post.prediction_score = predicted_engagement

    // Step 6: Apply business logic and final adjustments
    FOR each scored_post in scored_posts:
        // Boost promoted content
        IF scored_post.post.is_promoted:
            scored_post.prediction_score *= 1.5

        // Ensure diversity - penalize similar content
        IF too_many_similar_posts_already_shown:
            scored_post.prediction_score *= 0.8

        // Boost recent posts from close friends
        IF scored_post.post.author in user.close_friends AND post_age < 2_hours:
            scored_post.prediction_score *= 1.3

    // Step 7: Sort and select final posts
    sorted_posts = sort_by_prediction_score(scored_posts, descending=True)
    final_feed = take_top_N_posts(sorted_posts, N=50)

    // Step 8: Add some randomization to prevent staleness
    final_feed = add_slight_randomization(final_feed, randomization_factor=0.1)

    // Step 9: Log interactions for future learning
    log_feed_generation(user_id, final_feed, timestamp=now())

    RETURN final_feed

// Helper functions would include:
// - get_user_profile(user_id)
// - calculate_time_decay(timestamp)
// - match_user_interests(content, interests)
// - connection_strength(author, user)
// - ml_model.predict(features)
// - etc.

Technical Architecture

Most platforms use a multi-stage pipeline:

Candidate Generation → Pulls thousands of potential posts
Initial Filtering → Reduces to hundreds of viable options
Feature Engineering → Calculates scoring signals
ML Ranking → Applies trained models for predictions
Business Rules → Applies platform-specific adjustments
Final Assembly → Creates the ordered feed

The system is always learning from what you do. Every like, scroll, and the time you spend viewing content helps improve the recommendations you see in the future.

Platform Differences

While the core approach is similar, different platforms emphasize different signals:

Instagram: Heavily weighs visual engagement and story interactions
TikTok: Prioritizes completion rates and rewatches for videos
Twitter/X: Focuses on recency, trending topics, and real-time engagement
Facebook: Emphasizes social connections and meaningful interactions
LinkedIn: Prioritizes professional relevance and network connections

The fundamental goal remains the same: show you content that keeps you engaged, satisfied, and coming back to the platform.

Understanding BEM as a CSS Methodology for Modern Web Development

Michael Gokey — Thu, 04 Sep 2025 12:49:22 +0000

Maintaining clean, scalable, and maintainable CSS has become increasingly challenging in this ever-evolving landscape of web development. As projects grow in complexity and teams expand, the need for a consistent CSS architecture becomes critical. Enter BEM (Block Element Modifier), a naming methodology that has transformed how developers approach CSS organization.

Whether you're working on a small personal project or a large-scale enterprise application, BEM provides a systematic approach to writing CSS that promotes code reusability, reduces conflicts, and improves collaboration among team members. This article will explore what BEM is, how it compares to other popular CSS approaches, and provide practical guidance for implementing it successfully in your projects.

What is BEM?

BEM (Block Element Modifier) is a CSS naming methodology that helps create reusable, maintainable, and scalable stylesheets. It's one of the most popular CSS architecture patterns used in modern web development.

The BEM Structure

BEM follows a specific naming convention with three main components:

Block: A standalone component that is meaningful on its own

Example: header, menu, button, card

Element: A part of a block that has no standalone meaning and is semantically tied to its block

Named using double underscores: block__element
Example: menu__item, card__title, button__icon

Modifier: A flag on a block or element that changes appearance, behavior, or state

Named using double hyphens: block--modifier or block__element--modifier
Example: button--large, menu__item--active, card--featured

BEM Naming Examples

/* Block */
.card { }

/* Elements */
.card__header { }
.card__title { }
.card__content { }
.card__footer { }

/* Modifiers */
.card--featured { }
.card--large { }
.card__title--centered { }

HTML Structure Example

<h2>Article Title</h2>


<p>Article content goes here...</p>


Read More

Key Benefits of BEM

Clarity: Class names are self-documenting and clearly show the relationship between components

Modularity: Each block is independent and can be reused anywhere

Maintainability: Easy to understand and modify without fear of breaking other components

Avoiding CSS Conflicts: Specific naming prevents accidental style overwrites

Team Collaboration: Consistent naming convention makes it easier for teams to work together

BEM vs Tailwind vs Sass/Less

Neither Tailwind CSS nor Sass/Less are examples of BEM. They're different types of tools entirely. Understanding these distinctions is crucial for modern CSS development.

BEM is a naming methodology/architecture pattern. It's about how you structure and name your CSS classes, regardless of what tool you use to write them.

Tailwind CSS is a utility-first CSS framework that takes a completely different approach from BEM. Instead of creating semantic component classes, Tailwind provides small, single-purpose utility classes.

Sass/Less are CSS preprocessors. They extend CSS with features like variables, nesting, mixins, and functions. You can use BEM naming with Sass/Less.

Comparing Approaches

BEM Approach:

.card { }
.card__title { }
.card__content { }
.card--featured { }

Tailwind Approach:

<div class="bg-white rounded-lg shadow-md p-6 border-l-4 border-blue-500">
  <h2 class="text-xl font-bold text-gray-800 mb-4">Article Title</h2>
  <p class="text-gray-600">Article content...</p>
</div>

BEM with Sass:

.card {
  background: white;
  border-radius: 8px;

  &__title {
    font-size: 1.25rem;
    font-weight: bold;
  }

  &__content {
    color: #666;
  }

  &--featured {
    border-left: 4px solid blue;
  }
}

Key Differences

BEM: Component-based, semantic naming, custom CSS for each component.
Tailwind: Utility-based, descriptive classes, pre-built styles.
Sass/Less: Tools that can work with either BEM or utility approaches

Tailwind is actually quite different from BEM philosophically. BEM encourages creating reusable component classes, while Tailwind encourages composing styles from atomic utility classes.

Best Practices and Common Pitfalls

Successfully implementing BEM requires understanding not just its syntax, but also when and how to apply it effectively. Here are some key best practices and common mistakes to avoid.

When to Use BEM

Ideal Scenarios:

Component-based user interfaces
Large-scale applications with multiple developers
Projects requiring long-term maintenance
Design systems and style guides
When CSS specificity conflicts are a concern

Consider Alternatives When:

Building simple, static websites
Working on prototypes or one-off projects
Team strongly prefers utility-first approaches
The existing codebase uses different methodologies extensively

Common Pitfalls and How to Avoid Them

1. Over-Nesting Elements

Wrong:

.card__header__title__text { }

Right:

.card__header { }
.card__title { }
.card__text { }

BEM discourages deep nesting. Elements should be direct children of blocks, not nested within other elements.

2. Creating Elements Without a Clear Purpose

Wrong:

.card__div { }
.card__container { }

Right:

.card__content { }
.card__actions { }

Elements should have semantic meaning and a clear purpose within the block.

3. Inconsistent Modifier Naming

Wrong:

.button--big { }
.button--small-size { }
.button--color-red { }

Right:

.button--large { }
.button--small { }
.button--danger { }

Use consistent, meaningful modifier names that describe state or variation, not implementation details.

4. Mixing BEM with Non-BEM Classes

Wrong:

<div class="card featured-item">
  <h2 class="card__title big-text">Title</h2>
</div>

Right:

<div class="card card--featured">
  <h2 class="card__title card__title--large">Title</h2>
</div>

Maintain consistency within components by sticking to BEM naming throughout.

File Organization Strategies

Component-Based Structure

styles/
  components/
    _card.scss
    _button.scss
    _navigation.scss
  base/
    _reset.scss
    _typography.scss
  utilities/
    _helpers.scss

Block-Centric Approach

styles/
  blocks/
    card/
      _card.scss
      _card--featured.scss
    button/
      _button.scss
      _button--large.scss

Managing Global Styles with BEM

While BEM excels at component-level styling, you still need global styles for base elements, typography, and utilities:

// Global base styles (not BEM)
body {
  font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif;
  line-height: 1.6;
}

h1, h2, h3, h4, h5, h6 {
  margin: 0 0 1rem 0;
  font-weight: 600;
}

// BEM components
.card {
  background: white;
  border-radius: 8px;
  box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);

  &__title {
    // Inherits from global h2 styles
    color: #333;
  }
}

Performance Considerations

CSS Size Management

BEM can lead to longer class names, which might increase the CSS file size. Mitigate this by:

Using CSS minification in production
Implementing purging of unused CSS
Considering critical CSS extraction

Specificity Benefits

BEM naturally creates consistent, low specificity selectors, improving CSS performance and reducing cascade conflicts:

/* Good: Low, consistent specificity */
.card { }                    /* 0,0,1,0 */
.card__title { }             /* 0,0,1,0 */
.card--featured { }          /* 0,0,1,0 */

/* Avoid: High specificity conflicts */
.sidebar .card .title { }    /* 0,0,3,0 */

Team Adoption Strategies

Documentation

Create clear guidelines for your team:

Block naming conventions
When to create new blocks vs. modifying existing ones
Approved modifier patterns
File organization standards

Code Review Checklist

Are class names following BEM syntax correctly?
Is the block/element relationship logical?
Are modifiers descriptive and consistent?
Could any elements be simplified or combined?

Gradual Implementation

Don't attempt to convert entire codebases overnight. Instead:

Start with new components using BEM
Refactor existing components during regular maintenance
Establish BEM as the standard for new development
Document the migration process and timeline

Conclusion

BEM represents more than just a naming convention. It's a systematic approach to writing maintainable, scalable CSS that stands the test of time. By providing clear structure and meaningful relationships between components, BEM helps development teams create more predictable and debuggable stylesheets.

While BEM may seem wordy initially, its benefits become apparent as projects grow in complexity. The methodology's emphasis on clarity over brevity pays dividends in reduced debugging time, easier onboarding of new team members, and more confident refactoring.

The key to successful BEM implementation lies in understanding its core principles rather than rigidly following its syntax. Focus on creating logical, semantic relationships between your CSS classes, maintain consistency across your codebase, and don't hesitate to adapt the methodology to fit your specific project needs.

As the web development landscape continues to evolve with new frameworks and tools, BEM's foundational principles of modularity, clarity, and maintainability remain as relevant as ever. Whether you choose to adopt BEM wholesale or incorporate its concepts into your existing workflow, understanding this methodology will make you a more thoughtful and effective CSS developer.

Remember: the best CSS architecture is the one your team can consistently implement and maintain. BEM provides an excellent foundation, but success ultimately depends on clear documentation, team buy-in, and consistent application of whatever standards you choose to adopt.

Top 3 Web Security Vulnerabilities Every Developer Should Understand

Michael Gokey — Fri, 29 Aug 2025 17:49:26 +0000

Think about web security; it’s tempting to assume that firewalls, antivirus software, and strong passwords are enough. Yet most successful attacks don’t start at the network edge; they slip through cracks in the way applications are built. The real battleground for security is often in the very forms, queries, and scripts developers write every day.

Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF)

Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) are two major web security threats. Both can cause serious damage to websites and users.

XSS happens when bad actors put harmful code into trusted websites. When users visit these sites, the bad code runs in their web browser. This can steal cookies, passwords, or personal information. Think of it like someone hiding a virus in a letter that activates when you open it.

CSRF is different. It tricks users who are already logged into a website into doing things they don't want to do. For example, an attacker might make you change your password or send money without knowing it. This happens because the website thinks the request came from you.

To stop XSS attacks, you should clean all user inputs before using them. Use content security policies to control what scripts can run. Pick web frameworks that have built-in XSS protection. Always encode data before showing it to users.

To prevent CSRF attacks, use special tokens that prove requests are real. Check where requests come from. Set your cookies to "SameSite" mode. Ask users to re-enter their password for important actions.

Good session management helps with both threats. Use secure cookies that can't be accessed by scripts. Change session IDs regularly. Set timeouts so users get logged out after being inactive. Keep sensitive data on your servers, not in users' browsers.

Finally, follow good coding practices. Test your security regularly. Keep your software updated. These simple steps will help protect your website and users.

SQL Injection Attacks and Form Protection

SQL injection is a serious web security threat. It happens when attackers put harmful database code into your website's input fields. They do this to steal, change, or destroy your data.

This attack works when websites don't properly check user input before adding it to database commands. For example, an attacker might type ' OR '1'='1' -- into a login box. This trick code can let them log in without knowing the real password.

How to Protect Your Forms

The best way to stop SQL injection is to use parameterized queries. These are also called prepared statements. Instead of mixing user input directly into your database commands, you use placeholders.

Here's the difference: Bad code looks like SELECT FROM users WHERE username = '" + userInput + "'. Good code looks like SELECT FROM users WHERE username = ? and sends the user input separately. This way, the database treats user input as data, not as commands.

Other Ways to Stay Safe

Check all user input carefully. Only allow letters, numbers, and symbols you expect. Use stored procedures when you can. Give database accounts only the permissions they actually need. Clean user input by escaping special characters. Add a web application firewall for extra protection.

Many modern web frameworks have built-in tools called ORMs. These automatically use safe database queries. This makes it much easier to avoid SQL injection problems.

Test your security often. Use both automated tools and manual checks. Find and fix problems before the bad guys do. Regular testing helps keep your website and data safe.

Insecure Direct Object References (IDOR)

Another common but often overlooked vulnerability is Insecure Direct Object References (IDOR). This occurs when an application exposes references to internal objects such as files, database records, or keys, without properly checking whether the user is authorized to access them. For example, imagine a URL like /profile?id=1234. If the application doesn’t verify ownership, a malicious user could change the value to 1235 and gain access to another user’s profile.

To fix this, always check user permissions on the server before sharing sensitive data. Don’t use easy-to-guess IDs. Use random values like UUIDs instead. Make sure each user role can only access what they’re supposed to.

Vulnerabilities like XSS, CSRF, SQL injection, and IDOR aren’t just theoretical. They are used by attackers all the time! The upside is that with secure coding, careful design, and regular testing, you can stop most of these problems before they reach production.

Which of these vulnerabilities do you think developers forget, or struggle with the most, and why?

🏷hashtags:
#WebSecurity
#CyberSecurity
#AppSec
#WebDevelopment
#InfoSec
#CodingBestPractices

A Beginner DBA's Guide to SSRS Reports

Michael Gokey — Mon, 23 Jun 2025 17:57:39 +0000

Remember the first time someone asked you to "put that data in a report"?

You probably stared at your perfectly good SQL query results and thought, "Isn't this already a report?" Then you realized they wanted something their boss could actually look at without squinting at raw data tables.

Here's the thing nobody tells new DBAs: Writing great queries is only half the job. The other half is making that data speak to people who don't think in SELECT statements.

That's where SSRS comes in. And no, it's not as scary as it sounds.

What Is SSRS Anyway?

SSRS (SQL Server Reporting Services) is Microsoft's tool for turning your SQL query results into professional, interactive reports. Think of it as a translator between your database and everyone else.

You know that query you wrote to check which products are selling best? SSRS can turn that into:

Clean, formatted tables
Visual charts that tell a story
Automated email reports
Interactive dashboards where users can drill down

It's powerful, and once you get the hang of it, surprisingly straightforward.

Let's Build Your First Report

Here's exactly how I walk junior DBAs through their first SSRS report. No fluff, just the steps that matter.

Step 1: Start With Good SQL

This is your foundation. What story are you trying to tell with the data?

SELECT ProductCategory, SUM(Revenue) AS TotalRevenue
FROM SalesData
GROUP BY ProductCategory
ORDER BY TotalRevenue DESC;

Before you touch SSRS, make sure your query answers a clear business question. Like: "Which product categories make us the most money?"

Step 2: Fire Up Report Builder

If you're new to this, use Report Builder instead of Visual Studio. It's free, and Microsoft built it specifically for people who aren't full-time report developers.

Create a new report
Connect to your SQL database
Add your query as a dataset

The wizard will walk you through it. Don't overthink this part.

Step 3: Pick Your Layout

SSRS will ask you what kind of report you want:

Table – when you need to show detailed rows
Matrix – think pivot table for grouping data
Chart – when patterns matter more than individual numbers

For our revenue example, a bar chart makes the story obvious at a glance.

Step 4: Design It

This is where you connect your data to the visual layout. You can:

Drag columns where you want them
Group related data together
Add totals and calculations
Make it look professional with formatting

Pro tip: Keep it simple. Your data should be the star, not fancy colors and fonts.

Step 5: Test Everything

Use the Preview tab religiously. Check your report with different data scenarios. Add parameters so users can filter by date range or region.

Watch for:

Missing or unexpected data
Charts that look weird with small datasets
Formatting that breaks with long text

Step 6: Share It With the World

Deploy your report to the SSRS Web Portal. Now your team can access it through any web browser.

You can also set up subscriptions to email reports automatically. Nothing makes you look more professional than having that monthly summary hit everyone's inbox right on schedule.

Why This Matters for Your Career

As a DBA, you usually work behind the scenes. You tune queries, manage backups, keep the lights on. Important work, but invisible work.

SSRS changes that dynamic. When you build reports that help people make better decisions, you become part of the conversation. You're not just maintaining data – you're translating it into insights.

That moment when someone says "Can you show me that in a chart?" becomes your chance to shine.

Your Next Steps

Ready to try this? Here's what I recommend:

Pick one SQL query you run regularly
Ask a colleague what data would make their job easier
Turn that into a simple SSRS report
Set it to email you every week

Start small. Get comfortable with the process. You'll improve with each report you build.

Level Up Challenge

Take your favorite SQL query and turn it into a parameterized SSRS report. Then schedule it to email you every Monday morning with fresh data.

That's not just a report – that's automation. That's you becoming the person everyone comes to when they need data that actually makes sense.

Want to see this in action? I'm working on some starter templates and examples. Drop a comment if you'd like me to share the SQL and RDL files when they're ready.

Beginner’s Guide to SQL Server Stored Procedures

Michael Gokey — Tue, 17 Jun 2025 01:39:04 +0000

Imagine you're new to a software team.
You notice the same chunk of database code (SQL) copied and pasted in five different places.
Your lead developer says, "Hey, we should make this a 'stored procedure' instead."" You nod confidently, but inside you're thinking, "What exactly is a stored procedure, and why does everyone keep talking about them?" If you're a new developer or DBA who's heard the term thrown around but never quite understood the hype, you're in the right place. Let's demystify stored procedures and show you why they're one of the most powerful tools in your database toolkit.

TL;DR - The Quick Facts

What: Reusable SQL code blocks stored in the database run faster than regular SQL
Why: Better performance, improved security, and cleaner application code
When: Use for complex business logic, frequently-used queries, and data validation operations

What are Stored Procedures?

A stored procedure is essentially a named group of SQL statements that you can execute as a single unit. Instead of your program sending many separate database commands, it can just ask the stored procedure to do all the work.
It's like creating a shortcut. Instead of giving someone detailed instructions for "Get the milk" every time, you just say "Get Milk" and they know all the steps involved. SQL Server saves and optimizes your procedure the first time it runs, so it executes faster with repeated calls.

Prerequisites

Before diving in, make sure you're comfortable with:
Basic SQL SELECT, INSERT, UPDATE, DELETE statements
Understanding of database tables and relationships
Basic knowledge of SQL Server Management Studio (SSMS) or similar database tools

Copy-Paste Starter Template

-- Template: Basic Stored Procedure with Error Handling
CREATE PROCEDURE [dbo].[YourProcedureName]
    @Parameter1 VARCHAR(50),        -- Input parameter
    @Parameter2 INT = 0,            -- Input parameter with default value
    @OutputParameter INT OUTPUT     -- Output parameter (optional)
AS
BEGIN
    -- Prevent extra result sets from interfering with SELECT statements
    SET NOCOUNT ON;

    BEGIN TRY
        -- Your main logic goes here
        SELECT 'Replace this with your actual SQL logic' AS Message

        -- Set output parameter if using one
        SET @OutputParameter = @@ROWCOUNT

    END TRY
    BEGIN CATCH
        -- Handle errors gracefully
        PRINT 'Error occurred: ' + ERROR_MESSAGE()
        RETURN -1  -- Return error code
    END CATCH
END

Practical Examples

Example 1: Basic Procedure (No Parameters)

CREATE PROCEDURE GetAllEmployees
AS
BEGIN
    SET NOCOUNT ON;

    SELECT EmployeeID, FirstName, LastName, Department
    FROM Employees
    ORDER BY LastName, FirstName
END

To execute it:

EXEC GetAllEmployees

Example 2: Procedure with Input Parameters

CREATE PROCEDURE GetEmployeesByDepartment
    @DepartmentName VARCHAR(50)
AS
BEGIN
    SET NOCOUNT ON;

    -- Validate input
    IF @DepartmentName IS NULL OR @DepartmentName = ''
    BEGIN
        PRINT 'Department name cannot be empty'
        RETURN -1
    END

    SELECT EmployeeID, FirstName, LastName, Salary
    FROM Employees
    WHERE Department = @DepartmentName
    ORDER BY LastName
END

To execute it:

EXEC GetEmployeesByDepartment @DepartmentName = 'Sales'

Example 3: Procedure with Input and Output Parameters

CREATE PROCEDURE GetEmployeeCount
    @DepartmentName VARCHAR(50),
    @EmployeeCount INT OUTPUT
AS
BEGIN
    SET NOCOUNT ON;

    SELECT @EmployeeCount = COUNT(*)
    FROM Employees
    WHERE Department = @DepartmentName OR @DepartmentName IS NULL
END

To execute it:

DECLARE @Count INT
EXEC GetEmployeeCount @DepartmentName = 'Marketing', @EmployeeCount = @Count OUTPUT
SELECT @Count AS TotalEmployees

Example 4: Complex Business Logic with Transaction

CREATE PROCEDURE ProcessEmployeeRaise
    @EmployeeID INT,
    @RaisePercentage DECIMAL(5,2)
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @CurrentSalary DECIMAL(10,2)
    DECLARE @NewSalary DECIMAL(10,2)

    BEGIN TRY
        BEGIN TRANSACTION

        -- Validate inputs
        IF @RaisePercentage <= 0 OR @RaisePercentage > 50
        BEGIN
            RAISERROR('Raise percentage must be between 0 and 50', 16, 1)
            RETURN -1
        END

        -- Get current salary
        SELECT @CurrentSalary = Salary
        FROM Employees
        WHERE EmployeeID = @EmployeeID

        IF @CurrentSalary IS NULL
        BEGIN
            RAISERROR('Employee not found', 16, 1)
            RETURN -1
        END

        -- Calculate new salary
        SET @NewSalary = @CurrentSalary * (1 + @RaisePercentage / 100)

        -- Update the salary
        UPDATE Employees
        SET Salary = @NewSalary,
            LastModified = GETDATE()
        WHERE EmployeeID = @EmployeeID

        -- Log the change
        INSERT INTO SalaryHistory (EmployeeID, OldSalary, NewSalary, ChangeDate)
        VALUES (@EmployeeID, @CurrentSalary, @NewSalary, GETDATE())

        COMMIT TRANSACTION

        -- Return success message
        SELECT 'Salary updated successfully' AS Result,
               @CurrentSalary AS OldSalary,
               @NewSalary AS NewSalary

    END TRY
    BEGIN CATCH
        ROLLBACK TRANSACTION
        PRINT 'Error processing raise: ' + ERROR_MESSAGE()
        RETURN -1
    END CATCH
END

Performance Comparison: Before and After

-- Without stored procedure (slower)
SELECT COUNT(*) FROM Orders WHERE CustomerID = 123 AND OrderDate > '2024-01-01'
SELECT AVG(TotalAmount) FROM Orders WHERE CustomerID = 123 AND OrderDate > '2024-01-01'

Create this stored procedure:

-- With stored procedure (faster)
CREATE PROCEDURE GetCustomerOrderStats
    @CustomerID INT,
    @StartDate DATE
AS
BEGIN
    SET NOCOUNT ON;

    SELECT 
        COUNT(*) AS OrderCount,
        AVG(TotalAmount) AS AverageAmount,
        SUM(TotalAmount) AS TotalAmount
    FROM Orders 
    WHERE CustomerID = @CustomerID AND OrderDate > @StartDate
END

The stored procedure version will be faster because SQL Server compiles and caches the execution plan, plus it reduces network traffic by sending one call instead of multiple queries.

Testing Your Stored Procedures

Always test your procedures step-by-step:

Test with valid data first

EXEC GetEmployeesByDepartment @DepartmentName = 'Sales'

Test edge cases

-- Test with NULL
EXEC GetEmployeesByDepartment @DepartmentName = NULL

-- Test with empty string
EXEC GetEmployeesByDepartment @DepartmentName = ''

-- Test with non-existent department
EXEC GetEmployeesByDepartment @DepartmentName = 'Unicorn Department'

Test error conditions

-- Test with invalid parameters
EXEC ProcessEmployeeRaise @EmployeeID = 999999, @RaisePercentage = 100

Debugging Stored Procedures

When your procedure isn't working:

Add PRINT statements to see what's happening:

PRINT 'Current salary: ' + CAST(@CurrentSalary AS VARCHAR(20))

Use SELECT statements to check variable values:

SELECT @CurrentSalary AS CurrentSalary, @NewSalary AS NewSalary

Run sections individually - comment out parts of your procedure and test smaller pieces

Key Benefits

Performance: SQL Server saves and optimizes your procedure, making repeat calls faster than sending the same SQL over and over.

Security: Procedures help prevent SQL injection attacks and let you grant execute permissions without giving direct table access.

Maintainability: Business logic lives in one place in the database, making updates easier without changing application code.

Network Efficiency: Send one procedure call instead of multiple SQL statements.

Real Talk: When NOT to Use Stored Procedures

Simple CRUD Operations: If you're just doing basic INSERT/UPDATE/DELETE on single tables, stored procedures might be overkill.

Microservices Architecture: When each service manages its own data, stored procedures can create tight coupling between services.

ORM-Heavy Applications: If your application uses Entity Framework or similar ORMs effectively, stored procedures might complicate your data layer.

Testing Complexity: Stored procedures can make unit testing more difficult since they're harder to mock.

Version Control Challenges: Database objects are trickier to version control than application code.

Version Control Tips for Teams

Always script your procedures: Use SSMS to generate CREATE scripts
Use ALTER instead of DROP/CREATE when modifying existing procedures
Include rollback scripts for procedure changes
Document parameter changes clearly in your commit messages

Common Error Messages and Solutions

"Procedure 'X' expects parameter 'Y', which was not supplied"

Solution: Check your parameter names and make sure you're passing all required parameters

"Invalid object name 'TableName'"

Solution: Verify the table exists and you have permissions to access it

"String or binary data would be truncated"

Solution: Check your parameter sizes match the data you're passing

Where Stored Procedures Run

Stored procedures are specific to Microsoft SQL Server. Other database systems have similar concepts:

MySQL: Also calls them stored procedures
PostgreSQL: Has stored procedures and functions
Oracle: Uses PL/SQL procedures and functions
SQLite: Doesn't support stored procedures

Try This Now

Pick a common query
Turn it into a stored procedure
Add validation
Test with various inputs
Compare execution time

Next Steps

As you get comfortable with basic stored procedures, explore the following:

Stored functions (return single values)
Table-valued functions (return result sets)
Triggers (procedures that run automatically)
Dynamic SQL within stored procedures (advanced topic)
Recursive procedures for hierarchical data

Remember: the best way to learn stored procedures is by writing them. Start simple, test thoroughly, and gradually add complexity as your confidence grows.

Happy coding, and welcome to the world of stored procedures!

Understanding T-SQL vs PL/SQL Database Curveballs

Michael Gokey — Fri, 13 Jun 2025 16:46:32 +0000

Picture this: You're troubleshooting an application that worked perfectly on SQL Server. Now it's being moved to Oracle, and everything suddenly seems out of order. The code looks familiar, but it's throwing errors left and right. Welcome to the world of database dialects.

Here's the thing most people don't tell you: SQL isn't just SQL. Microsoft and Oracle each built their own flavor, and they're different enough to make your head spin.

What Are We Even Talking About?

T-SQL is Microsoft's procedural extension to SQL. It's what SQL Server speaks. PL/SQL is Oracle's procedural language. The same basic idea, a totally different execution.

Think of it like American English vs British English. You'll understand most of it, but some words mean completely different things.

The Stuff That'll Trip You Up

Setting Up Variables

In SQL Server (T-SQL), you declare and go:


DECLARE @userName VARCHAR(50) = 'John'

SELECT @userName

Pretty straightforward, right?

Oracle (PL/SQL) requires structured blocks:


DECLARE

    userName VARCHAR2(50) := 'John';

BEGIN

    DBMS_OUTPUT.PUT_LINE(userName);

END;

See that? Oracle wants everything wrapped in a structured block with declaration and execution sections.

When Things Go Wrong

SQL Server keeps it simple with try-catch:


BEGIN TRY

    -- your risky code here

END TRY

BEGIN CATCH

    SELECT ERROR_MESSAGE()

END CATCH

Oracle does its own thing:


BEGIN

    -- your risky code here

EXCEPTION

    WHEN OTHERS THEN

        DBMS_OUTPUT.PUT_LINE(SQLERRM);

END;

Speed and Performance

Here's where things get interesting.

SQL Server compiles your code when you first run it. Then it remembers what it did. This works great for most situations.

Oracle pre-compiles everything and stores it in the database. It's like meal prep for your database. More work upfront, but it can be faster for complex stuff.

Where You'll Find Each One

You'll bump into T-SQL when:

Working with Microsoft shops
Dealing with .NET applications
Managing Azure databases
Companies want quick results

PL/SQL shows up in:

Big corporations
Banks and government systems
Places where the database does heavy lifting
Environments where performance is everything

The Migration Headaches

Moving between these systems? Here's what'll bite you:

Data types are different. Oracle uses VARCHAR2, and SQL Server uses VARCHAR. Oracle has NUMBER, SQL Server has INT, and DECIMAL.

String concatenation is different. Oracle uses || to join strings together. SQL Server uses +.

Dates are a nightmare. Oracle has SYSDATE. SQL Server has GETDATE(). They don't play nice together.

Stored procedures work differently. Oracle bundles them together in packages. SQL Server treats each one separately.

What This Means for You

Don't panic when you switch between systems. The core SQL stuff transfers over fine. It's the fancy programming bits that change.

The trick is knowing which system you're working with. Then you can speak its language instead of fighting it.

Most of your SQL knowledge still applies. You need to learn each database's personality quirks. Think of it like learning to drive different cars; the basics are the same, but every model has its own dashboard layout.

The Bottom Line

Both T-SQL and PL/SQL do the same job. They have different ways of getting there. Oracle is more formal and structured. SQL Server is more relaxed and flexible.

Know which one you're dealing with, and you'll save yourself hours of head-scratching.

Advanced NgRx Patterns for Enterprise Angular Applications

Michael Gokey — Tue, 20 May 2025 03:59:55 +0000

Welcome to the final installment of our NgRx deep-dive series! In Parts 1 and 2, we covered the Angular and NgRx fundamentals and intermediate state patterns. Now, we're tackling the juicy stuff; the advanced patterns that'll save your sanity when your enterprise Angular app starts growing. (⏱️ Est reading time: 9.5 min)

If you're dealing with complex state management challenges in large-scale applications, you've probably felt the pain of tangled observables, redundant calculations, and components that re-render for no good reason. Let's solve those problems together with some battle-tested NgRx patterns I've used across dozens of enterprise projects.

Performance Optimization with Selectors

The Power of Memoized Selectors

You'll use selectors to derive data without doing extra work and thanks to NgRx's memoization, your app stays fast even when the state grows. Think of selectors as your first line of defense against performance issues:

// Feature state interface
export interface DashboardState {
  metrics: Metric[];
  loading: boolean;
  error: string | null;
}

// Basic selectors
export const selectDashboardState = createFeatureSelector<DashboardState>('dashboard');
export const selectAllMetrics = createSelector(
  selectDashboardState,
  (state) => state.metrics
);

// Derived selectors with memoization benefits
export const selectActiveMetrics = createSelector(
  selectAllMetrics,
  (metrics) => metrics.filter(metric => metric.active)
);

// Complex calculations that won't recompute unnecessarily
export const selectMetricsSummary = createSelector(
  selectActiveMetrics,
  (activeMetrics) => {
    // This saves you from running expensive logic every time Angular blinks,
    // Especially important when rendering dashboards or charts
    return {
      total: activeMetrics.reduce((sum, metric) => sum + metric.value, 0),
      average: activeMetrics.length ? 
        activeMetrics.reduce((sum, metric) => sum + metric.value, 0) / activeMetrics.length : 0,
      count: activeMetrics.length
    };
  }
);

This prevents unnecessary component re-renders and keeps Angular's change detection lean. Your users will notice the difference when they're rapidly interacting with data-heavy interfaces.

Selector Composition for Complex Data Transformations

When your app's complexity increases, you'll want to create small, focused selectors that you can compose together:

// Combining data from multiple slices of state
export const selectUserPermissions = createSelector(
  authSelectors.selectCurrentUser,
  roleSelectors.selectAllRoles,
  (user, roles) => {
    const userRole = roles.find(role => role.id === user?.roleId);
    return userRole?.permissions || [];
  }
);

// Building on existing selectors for dashboard-specific permissions
export const selectUserDashboardPermissions = createSelector(
  selectUserPermissions,
  (permissions) => permissions.filter(p => p.resource === 'dashboard')
);

I've found this approach invaluable when different teams are working on different parts of the application. Each team can build on existing selectors without duplicating logic or stepping on each other's toes.

Handling Authentication and Security with NgRx

Let's be real; authentication is one of those things that's simple in concept but gets messy fast. NgRx gives you a clean way to manage all the moving parts.

Authentication State Design

Here's a practical auth state that covers all the bases:

export interface AuthState {
  user: User | null;
  token: string | null;
  loading: boolean;
  error: string | null;
  lastAuthAttempt: Date | null;
}

export const initialAuthState: AuthState = {
  user: null,
  token: null,
  loading: false,
  error: null,
  lastAuthAttempt: null
};

Authentication Actions

I like to be specific with my auth actions so debugging is easier down the road:

export const login = createAction(
  '[Auth] Login',
  props<{ username: string; password: string }>()
);

export const loginSuccess = createAction(
  '[Auth] Login Success',
  props<{ user: User; token: string }>()
);

export const loginFailure = createAction(
  '[Auth] Login Failure',
  props<{ error: string }>()
);

export const checkAuthStatus = createAction('[Auth] Check Status');
export const logout = createAction('[Auth] Logout');

Authentication Effects for Token Management

Here's where the real magic happens; effects that handle the token lifecycle:

@Injectable()
export class AuthEffects {
  login$ = createEffect(() => 
    this.actions$.pipe(
      ofType(AuthActions.login),
      exhaustMap(action => 
        // Note: exhaustMap is used here to avoid parallel login attempts
        this.authService.login(action.username, action.password).pipe(
          map(response => {
            // Store token in secure storage
            this.tokenService.storeToken(response.token);
            return AuthActions.loginSuccess({
              user: response.user,
              token: response.token
            });
          }),
          catchError(error => of(AuthActions.loginFailure({ 
            error: error.message || 'Authentication failed' 
          })))
        )
      )
    )
  );

  logout$ = createEffect(() => 
    this.actions$.pipe(
      ofType(AuthActions.logout),
      tap(() => {
        // Clear token on logout
        this.tokenService.removeToken();
        this.router.navigate(['/login']);
      })
    ),
    { dispatch: false }
  );

  // Effect to check auth status on app initialization
  checkAuth$ = createEffect(() => 
    this.actions$.pipe(
      ofType(AuthActions.checkAuthStatus),
      switchMap(() => {
        const token = this.tokenService.getToken();
        if (!token) {
          return of(AuthActions.logout());
        }

        return this.authService.validateToken(token).pipe(
          map(user => AuthActions.loginSuccess({ user, token })),
          catchError(() => of(AuthActions.logout()))
        );
      })
    )
  );

  constructor(
    private actions$: Actions,
    private authService: AuthService,
    private tokenService: TokenService,
    private router: Router
  ) {}
}

I've seen too many apps where tokens are handled inconsistently across components. This centralized approach gives you one source of truth for auth state.

Route Guards with NgRx State

Guards are where your auth state becomes a security boundary. Here's how to hook them up to NgRx:

@Injectable({
  providedIn: 'root'
})
export class AuthGuard implements CanActivate {
  constructor(
    private store: Store,
    private router: Router
  ) {}

  canActivate(): Observable<boolean> {
    return this.store.select(selectIsAuthenticated).pipe(
      tap(isAuthenticated => {
        if (!isAuthenticated) {
          this.router.navigate(['/login']);
        }
      }),
      take(1)
    );
  }
}

@Injectable({
  providedIn: 'root'
})
export class RoleGuard implements CanActivate {
  constructor(
    private store: Store,
    private router: Router
  ) {}

  canActivate(route: ActivatedRouteSnapshot): Observable<boolean> {
    const requiredRole = route.data.role;

    return this.store.select(selectUserRole).pipe(
      map(userRole => userRole === requiredRole),
      tap(hasAccess => {
        if (!hasAccess) {
          this.router.navigate(['/unauthorized']);
        }
      }),
      take(1)
    );
  }
}

These guards are easily testable via mock store observables, which helps catch auth regressions. I can't tell you how many security holes I've prevented by having solid tests around these guards.

Entity Management for Data Collections

If you're building an enterprise app, you're probably dealing with lots of collections, users, products, orders, you name it. The @ngrx/entity package is your best friend here.

Setting Up Entity Adapters

export interface User {
  id: string;
  name: string;
  email: string;
  roleId: string;
  active: boolean;
}

export interface UserState extends EntityState<User> {
  selectedUserId: string | null;
  loading: boolean;
  error: string | null;
}

export const adapter = createEntityAdapter<User>({
  selectId: (user) => user.id,
  sortComparer: (a, b) => a.name.localeCompare(b.name) // Optional sort by name
});

export const initialState: UserState = adapter.getInitialState({
  selectedUserId: null,
  loading: false,
  error: null
});

This setup allows O(1) lookups and makes UI list rendering super cheap. Your users will thank you when they can scroll through thousands of records without lag.

Entity Reducers for Common Operations

The adapter gives you helper methods that handle the heavy lifting:

export const userReducer = createReducer(
  initialState,

  // Load operations
  on(UserActions.loadUsers, (state) => ({
    ...state,
    loading: true,
    error: null
  })),
  on(UserActions.loadUsersSuccess, (state, { users }) => 
    adapter.setAll(users, { ...state, loading: false })
  ),

  // Add/update/remove operations
  on(UserActions.addUser, (state, { user }) => 
    adapter.addOne(user, state)
  ),
  on(UserActions.updateUser, (state, { update }) => 
    adapter.updateOne(update, state)
  ),
  on(UserActions.deleteUser, (state, { id }) => 
    adapter.removeOne(id, state)
  ),

  // Selection state
  on(UserActions.selectUser, (state, { id }) => ({
    ...state,
    selectedUserId: id
  }))
);

Entity Selectors for Efficient Data Access

Here's where it all comes together, the adapter gives you optimized selectors out of the box:

export const { selectIds, selectEntities, selectAll, selectTotal } = 
  adapter.getSelectors(createFeatureSelector<UserState>('users'));

// Extended selectors
export const selectSelectedUserId = createSelector(
  createFeatureSelector<UserState>('users'),
  (state) => state.selectedUserId
);

export const selectSelectedUser = createSelector(
  selectEntities,
  selectSelectedUserId,
  (entities, selectedId) => selectedId ? entities[selectedId] : null
);

export const selectActiveUsers = createSelector(
  selectAll,
  (users) => users.filter(user => user.active)
);

I've worked on apps where we tried to roll our own entity management before discovering this pattern. Trust me, it's not worth reinventing this wheel!

Debugging & Troubleshooting NgRx Applications

When things go wrong (and they will), you need visibility into your state.

Redux DevTools Integration

The Redux DevTools Extension is an absolute must-have:

@NgModule({
  imports: [
    StoreModule.forRoot(reducers),
    StoreDevtoolsModule.instrument({
      maxAge: 25, // Retains last 25 states
      logOnly: environment.production, 
      autoPause: true, // Pauses recording actions when the browser tab is not active
      trace: !environment.production, // Include stack trace for dispatched actions
      traceLimit: 75, // Maximum stack trace frames to be stored
      connectOutsideZone: true // Connect outside Angular's zone for better performance
    })
  ]
})
export class AppModule {}

This will save you countless hours of debugging. Being able to travel through state changes is like having a superpower when tracking down bugs.

Custom Meta-Reducers for Logging and Debugging

For those times when you need extra visibility, meta-reducers can be your secret weapon:

export function debug(reducer: ActionReducer<any>): ActionReducer<any> {
  return function(state, action) {
    const nextState = reducer(state, action);

    console.group(action.type);
    console.log(`%c prev state`, 'color: #9E9E9E; font-weight: bold', state);
    console.log(`%c action`, 'color: #03A9F4; font-weight: bold', action);
    console.log(`%c next state`, 'color: #4CAF50; font-weight: bold', nextState);
    console.groupEnd();

    return nextState;
  };
}

export const metaReducers: MetaReducer<State>[] = !environment.production ? [debug] : [];

@NgModule({
  imports: [
    StoreModule.forRoot(reducers, { metaReducers })
  ]
})
export class AppModule {}

I've solved many tricky bugs by seeing exactly what changed between states. Just remember to disable this in production!

Extending State Architecture as Apps Grow

Feature State Composition Pattern

As your team grows, you'll want to split your state into manageable chunks:

// Root state interface
export interface AppState {
  router: RouterReducerState<any>;
  auth: AuthState;
}

// Extended with lazy-loaded feature states
export interface State extends AppState {
  users?: UserState;
  dashboard?: DashboardState;
  reports?: ReportState;
}

Dynamic Module Federation with NgRx

For large applications, you'll leverage NgRx's forFeature method in lazy-loaded modules:

@NgModule({
  imports: [
    CommonModule,
    StoreModule.forFeature('users', userReducer),
    EffectsModule.forFeature([UserEffects]),
    // ...other module imports
  ],
  declarations: [
    UserListComponent,
    UserDetailComponent,
    // ...other components
  ]
})
export class UserModule {}

I've found this approach invaluable on large teams. Each feature team can own their slice of state while still playing nicely with the global store.

State Normalization for Complex Data Relationships

If your data has complex relationships, normalization will save you tons of headaches:

// Instead of nested data:
const badlyNestedState = {
  departments: [
    {
      id: 'dept1',
      name: 'Engineering',
      employees: [
        { id: 'emp1', name: 'Alice', projects: [...] },
        { id: 'emp2', name: 'Bob', projects: [...] }
      ]
    }
  ]
};

// Use normalized state with references:
const normalizedState = {
  departments: {
    ids: ['dept1', 'dept2'],
    entities: {
      'dept1': { id: 'dept1', name: 'Engineering', employeeIds: ['emp1', 'emp2'] },
      'dept2': { id: 'dept2', name: 'Marketing', employeeIds: ['emp3', 'emp4'] }
    }
  },
  employees: {
    ids: ['emp1', 'emp2', 'emp3', 'emp4'],
    entities: {
      'emp1': { id: 'emp1', name: 'Alice', projectIds: ['proj1', 'proj2'] },
      'emp2': { id: 'emp2', name: 'Bob', projectIds: ['proj1'] },
      // ...other employees
    }
  },
  projects: {
    ids: ['proj1', 'proj2', 'proj3'],
    entities: {
      'proj1': { id: 'proj1', name: 'Dashboard Redesign' },
      // ...other projects
    }
  }
};

I've seen teams get into a world of pain with this nested state. Normalization might feel like extra work at first, but it pays massive dividends as your app evolves.

Conclusion: Putting It All Together

Throughout this three-part series, we've gone from NgRx basics to these advanced patterns that will help your enterprise Angular applications scale gracefully. I've used these techniques on applications with hundreds of components and dozens of developers, and they've been crucial for keeping complexity under control.

The real power comes when you combine these patterns: memoized selectors feeding normalized entity data to performant components, all while maintaining security with NgRx-powered auth state and guards. It's a beautiful thing when it all comes together!

As your application grows, remember these key takeaways:

Use selectors strategically to prevent unnecessary re-renders
Centralize authentication logic in NgRx effects to ensure consistent security
Leverage @ngrx/entity for all your collection management needs
Keep debugging tools configured to catch issues early
Split your state into feature modules as your application grows

What patterns have you found most helpful in your NgRx journey? What anti-patterns have you seen pop up?
I'd love to hear about your experiences in the comments. And if you found this series valuable, share it with a fellow Angular developer wrestling with state management!

Happy coding!

NgRx State Management Across Angular Modules

Michael Gokey — Tue, 20 May 2025 03:58:41 +0000

Part 2: Structuring Shared State in Large Applications

In Part 1, we explored the basics of NgRx and why a centralized state can help tame complexity in modern Angular applications.

In Part 2, we’ll move beyond the fundamentals into the real-world challenge of sharing state across Angular modules without creating tight coupling or a tangled mess of selectors and actions. (⏱️ Estimated reading time: 4.5 minutes)

Understanding the Problem

Imagine you're building a house with several rooms. Each room serves a different purpose, but everyone in the house needs to know if it’s day or night, hot or cold, or if someone’s at the door.

In Angular, each feature module is like a room, self-contained, but part of the same living space.

Now imagine that instead of a shared thermostat or central lighting control, every room makes its own guess about the time of day or the temperature. That’s what happens in Angular apps when modules try to manage state locally, in isolation; you get duplicate logic, inconsistent behavior, and poor user experience.

This is where NgRx shines. It gives your Angular app a centralized information desk (aka the Store) that every module can subscribe to and contribute to, in a clean, consistent way.

But here’s the catch:
While NgRx makes centralized state management possible, you still need intentional structure to make it scalable across multiple modules.

Review: NgRx Core Concepts

Before we dive into cross-module concerns, let’s do a quick refresher on the building blocks:

Store – the single source of truth, holding your application’s state tree.
Actions – plain objects that describe state changes.
Reducers – pure functions that respond to actions and return new state.
Selectors – reusable queries for retrieving slices of state.
Effects – handling side effects like API calls or navigation.

These concepts stay the same, but how you organize them matters a lot as your app scales.

The Challenge: Sharing State Without Tangling Modules

A common mistake in large Angular apps is allowing feature modules to directly reach into other modules' states.
This creates coupling and a nasty tangle when teams need to refactor or isolate functionality.

The goal is shared understanding, not shared chaos.

Here’s what we want instead:

Encapsulated feature modules, each managing its feature logic.
A core shared state slice, defined in a neutral place (like app.state.ts or a shared library).
Well-named action contracts and selectors that modules can subscribe to without needing to know who triggered the change.

Strategies for Cross-Module State

Here are a few battle-tested approaches to organizing state across modules:

1. Use Feature States Wisely

Each Angular module should define its own NgRx feature slice via StoreModule.forFeature.
Avoid trying to cram everything into a global root reducer.

This keeps logic scoped, testable, and maintainable.

But what if two modules need to interact?

2. Create a Shared or Global Slice for Cross-Cutting Concerns

Sometimes, multiple modules care about the same data, like user authentication, settings, or permissions.

Put these into a shared state module (e.g., @app/state/core) and use StoreModule.forRoot() to initialize it.

Then expose clear selectors like:

export const selectCurrentUser = createSelector(
  selectAuthState,
  (state) => state.user
);

Other modules can import this shared selector without knowing how the data is stored or updated.

3. Use Facade Services to Hide Store Details

You don’t want every component wiring up selectors and dispatching actions.
Create a facade service per module or domain, something like UserFacade or SettingsFacade to act as the single entry point.

This service:

Wraps select() calls into clean, reactive streams (like currentUser$)
Dispatches actions behind readable method names (loadUser(), updatePreferences())
Decouples components from NgRx boilerplate

Now your UI is easier to test and reason about.

4. Minimize Cross-Domain Dispatches

Avoid letting one module dispatch actions that mutate another module’s state. Instead, use shared actions and let each reducer respond as needed; this keeps boundaries clear.

Case Study: AdminPortal State Structure

In our AdminPortal app, we split our store into three key areas:

Core state

Authentication
User profile
App-level settings

Feature state

Each module (e.g., users, dashboard, reports) owns its slice
Isolated selectors and reducers

Shared utility state

UI loading flags
Toaster notifications
API error logs

Each module imports only the pieces it needs and uses facade services to access or update them.

This keeps our modules independent, but still able to collaborate.

Wrapping Up: Shared State Without the Pain

Sharing state across Angular modules doesn’t have to feel like a plumbing nightmare.
With the right NgRx structure, and some thoughtful use of shared slices, facades, and selectors, you can build apps that scale without getting brittle.

NgRx isn’t just about centralizing data. It’s about creating clear boundaries, predictable flows, and confident teams who know where things live and how they change.

Coming in Part 3:

“Optimizing NgRx for Performance and Developer Experience”
We’ll explore:

Memoized selectors and why they matter
Lazy-loading state modules the right way
Developer tooling, best practices, and debugging tips that make life easier

Stay tuned.

Building a Multi-Module Angular Application with NgRx

Michael Gokey — Tue, 20 May 2025 03:56:19 +0000

Angular's modular design and NgRx state management allow for the maintainable, performant, and collaborative development of even intricate applications with varied user roles and features. (Part 1, ⏱️ Estimated reading time: 5 minutes)

Introduction to the AdminPortal

Meet AdminPortal, a web application that helps organizations manage users and resources. Like many real-world apps, AdminPortal supports different areas for different people:

Administrators need tools to manage users.
Managers need dashboards to see team activity.
Regular users need access to their profiles and basic functions.

Let's not cram all of this into one big chunk of code. That'd be chaos. Instead, we broke the application into smaller, focused pieces called modules. This improves maintainability, performance, and clarity.

In this article, you'll get the high-level tour; a look at how AdminPortal is structured, how its pieces work together, and how NgRx ties it all up without going too deep into technical weeds.

Application Architecture and Module Structure

Core Modules

AdminPortal is built with five main modules:

App Module: The main shell that wires everything together, routing, bootstrap logic, and core services.
Core Module: Hosts essential singleton services used app-wide:
- Authentication service
- HTTP interceptors (for auth tokens, error handling)
- Global error and session management
Shared Module: Reusable, stateless building blocks:
- UI components (buttons, cards, inputs)
- Pipes, directives
- TypeScript interfaces and helper models
Layout Module: Defines the global layout (header, footer, sidebar).
Feature Modules:
- Auth Module: Login, registration, password reset
- Dashboard Module: Role-based dashboards and user profiles
- Admin Module: Admin-only tools and user management

Module Interaction and Lazy Loading

The power of this structure lies in how the pieces fit:

By implementing lazy loading, feature modules are not loaded upfront but rather when they are navigated. This means that if a user never accesses the admin area, its code will not be loaded into the application.

A key aspect is the limited sharing; only Core and Shared modules are accessible throughout the application, ensuring that Feature modules remain isolated and do not directly depend on each other.

NgRx for Centralized and Shared State. NgRx centralizes application-wide data (e.g., user authentication, roles) in a single store, leading to a shared state with well-defined boundaries.

Simplified Module Map:

App Module
├── Core Module (services, guards)
├── Layout Module (header, footer, sidebar)
├── Shared Module (components, pipes, models)
└── Feature Modules
 ├── Auth Module (login, registration)
 ├── Dashboard Module (user dashboard)
 └── Admin Module (user management)

Key Features and Role-Based Flow

Authentication System

Auth is handled through NgRx effects and a shared authentication service:

Users log in via the Auth Module
Tokens are stored securely and used with API requests
Session expiration is monitored; expired tokens trigger logout

The authentication state is global:

The Layout Module updates the header with the user profile
Role-based routing and guards unlock or hide features

Role-Based Access Control (RBAC)

AdminPortal defines three main roles:

Administrators – Full system access
Managers – Read-only access to team metrics
Users – Personal profile and usage only

RBAC affects:

Navigation: Sidebar and header options change per role
Routing: Unauthorized attempts trigger redirection
UI Features: Certain buttons or views are hidden based on the role

Dashboards Tailored by Role

Each user gets a personalized dashboard:

Admin Dashboard – System-wide metrics, shortcuts to admin tools
Manager Dashboard – Team statistics and limited admin features
User Dashboard – Personal usage, profile, recent activity

These dashboards reuse many components but differ in data and access logic.

User Journeys

Emily (Administrator)

When Emily logs in:

She submits her credentials via the login form.
The Auth Module verifies and stores her profile (including the admin role) in NgRx.
She's redirected to the Admin Dashboard.
The Layout Module updates to show admin-specific navigation.
She clicks "User Management" to:

Edit user profiles
Change permissions
Disable accounts
1. Her changes are synced across the app via NgRx and backend API calls.

Siddarth (Regular User)

When Siddarth logs in:

He logs in through the same Auth Module.
His user role is stored in the NgRx store.
He’s routed to the User Dashboard.
The Layout Module hides admin links.
He updates his profile and uses basic features.
If he attempts to access /admin, he’s redirected to /dashboard.

Development Best Practices

Clear Module Boundaries

Each module focuses on one area:

Auth handles login and tokens
Admin handles system-level features
Dashboard manages user-specific views

This makes testing, maintenance, and team handoffs smoother.

Shared State with NgRx

NgRx handles cross-cutting concerns:

Auth state
Current user profile
Global settings (e.g., dark mode preference)

This avoids tightly coupling feature modules.

Route Guards & Smart Routing

Each module has a route config
Route guards enforce login and role-based access
Lazy loading keeps the app lean

Example: Visiting /admin/users

App checks login status
Verifies admin role
Grants or redirects accordingly

Shared Components & Design System

The Shared Module powers UI consistency:

Buttons, inputs, cards, alerts
Theming and accessibility
Form controls behave the same across features

Angular Modularity Principles in Action

AdminPortal follows key design principles:

Single Responsibility: One purpose per module/component/service
Encapsulation: Modules expose only what’s needed
Reusability: Components and services are flexible, not hardwired
Progressive Loading: Users load only what they need

Final Thoughts

AdminPortal shows how modular Angular apps with NgRx can scale smoothly:

Teams can work in parallel without stepping on each other
Apps perform better with lazy loading
Features are isolated, testable, and easier to maintain
Role-based logic is secure and user-friendly

The takeaway? Use Angular’s modular architecture intentionally. Pair it with NgRx to manage a shared state without tight coupling. The result is a maintainable, real-world-ready application that evolves with your users and developer team.

The Algorithm of Critical Thinking: Teaching Devs to Think Before They Code

Michael Gokey — Fri, 09 May 2025 01:06:28 +0000

Introduction

As junior developers begin their coding journeys, it's tempting to dive headfirst into the code, typing fast, googling snippets, and copying from Stack Overflow. While this kind of enthusiasm is great, the real secret to becoming a great developer isn’t just speed or syntax. It’s critical thinking.

This article explores how teaching developers to think before they code can lead to cleaner, smarter, and more maintainable solutions. And to bring this to life, we'll use the creation of a Flashcard Game, a simple card flipper built in HTML, CSS, and JavaScript as a working example. ⏱️ Estimated reading time: 2 minutes

Step 1: Think in Pseudocode

Before you crack open your editor, pause. Ask yourself:

What exactly am I building?
What are the parts?
How will users interact with it?

Let’s apply this to our Building a Flashcard Game with HTML, CSS & JavaScript and see the steps.
You can go see FunCards in Action on CodePen

Pseudocode Outline:

Create a container for flashcards
For each flashcard:
  - Show a question on the front
  - Show an answer on the back
  - Flip the card on click

This level of clarity early on helps keep you grounded. It removes ambiguity, and forces you to think through the interaction model.

Step 2: Sketch the Architecture

Every app, even a tiny one, has structure. Whether you’re working in a framework or plain vanilla HTML/JS/CSS, spend a minute mapping the architecture. Sketch the Architecture Mentally or Literally. Its a step in the right direction.

In our Flashcard Game:

HTML creates the structure.
CSS handles visual transitions, layout, and flipping animations.
JavaScript drives logic and user interaction.

Understanding where each concern lives helps reduce messy code later.

Step 3: Think Like a User

What’s the first thing a user will do? Click a card. What do they expect? A flip animation. Are they surprised by the content? Is it legible? Responsive?

By simulating the user experience in your mind first, you can anticipate hiccups. For example:

What if someone clicks rapidly?
What if they want to reset?
Can it be extended to more cards or categories?

These questions don’t need answers immediately, but asking them shows maturity in your thinking process.

Step 4: Comment Before You Code

Even before writing the actual logic, start with well-named // comments.

// Select container to hold all cards
// Loop through each flashcard item
// Create HTML structure for front and back
// Attach event listener for flip

This acts like scaffolding. It guides your build and makes the code more readable.

Step 5: Build in Layers

Start with a small slice of the functionality:

Get one card to flip.
Then expand to multiple cards.
Then style and polish.

Working this way teaches patience and reveals issues early, rather than snowballing complexity.

This is the developer’s version of TDD (Test-Driven Development): Think-Driven Development.

Step 6: Reflect and Refactor

Once your Flashcard Game is functional, step back.

Is your code reusable?
Could this become a component or be extracted into a module?
Are the HTML and CSS organized?

Reflection is part of critical thinking. It’s where good devs separate from great ones.

Final Thoughts: "Thinking Is the Real Skill"

The biggest value of this exercise isn’t the 10 flashcards or the flip animation. It’s learning how to:

Break a problem into parts.
Think about user interaction.
Build in small increments.
Write code with intention.

The Flashcard Game may look simple, but behind it is a layered thought process. And that’s the point.

If you're a junior dev, or even a mid-level dev who wants to sharpen your instincts, remember:

Coding is just the output. Thinking is the real skill.

🎮 Live Demo: See the Flashcard Game on CodePen

📦 Code Repo: View on GitHub

🧠 Challenge: Fork the CodePen and add a category filter, or track correct/incorrect answers.

Flip for Knowledge: Building a Flashcard Game with HTML, CSS & JavaScript

Michael Gokey — Fri, 09 May 2025 00:32:29 +0000

Audience: Junior developers, bootcamp grads, and anyone who loves interactive learning. ⏱️ Estimated reading time: 2 minutes

Goal: Build a 10-card flashcard game from scratch, moving from pseudocode to production-ready code—explaining the why behind each step.

💡 Why Flashcards?

Flashcards are a great way to reinforce learning. They keep users engaged and help us explore:

DOM manipulation
Event listeners
Component reuse
Separation of concerns

Let’s break this down into small wins.
You can go see FunCards in Action and see the steps here.

🧾 Step 1: The Pseudocode

1. Create a container for flashcards.
2. Each flashcard has a front (question) and a back (answer).
3. Clicking a flashcard flips it.
4. Load 10 flashcards into the DOM.
5. Style the flashcards to animate the flip.

🧱 Step 2: The HTML Skeleton

<div id="flashcard-container">
  <!-- Cards will be injected here -->
</div>

🧠 Step 3: Sample Flashcard Data (in JavaScript)

const flashcards = [
  { question: "What does HTML stand for?", answer: "HyperText Markup Language" },
  { question: "What is the purpose of CSS?", answer: "To style HTML content" },
  // ... add 8 more
];

🛠️ Step 4: JavaScript to Create and Inject Flashcards

const container = document.getElementById("flashcard-container");

flashcards.forEach((card, index) => {
  const cardDiv = document.createElement("div");
  cardDiv.classList.add("card");

  cardDiv.innerHTML = `
    <div class="card-inner">
      <div class="card-front">${card.question}</div>
      <div class="card-back">${card.answer}</div>
    </div>
  `;

  cardDiv.addEventListener("click", () => {
    cardDiv.classList.toggle("flipped");
  });

  container.appendChild(cardDiv);
});

🎨 Step 5: CSS for Styling and Flip Animation

#flashcard-container {
  display: flex;
  flex-wrap: wrap;
  gap: 20px;
  justify-content: center;
}

.card {
  width: 200px;
  height: 150px;
  perspective: 1000px;
  cursor: pointer;
}

.card-inner {
  position: relative;
  width: 100%;
  height: 100%;
  transition: transform 0.6s;
  transform-style: preserve-3d;
}

.card.flipped .card-inner {
  transform: rotateY(180deg);
}

.card-front,
.card-back {
  position: absolute;
  width: 100%;
  height: 100%;
  backface-visibility: hidden;
  padding: 20px;
  box-shadow: 0 4px 8px rgba(0,0,0,0.1);
  border-radius: 10px;
  background: #fefefe;
}

.card-back {
  background: #ffefd5;
  transform: rotateY(180deg);
}

🔍 Why We Built It This Way

Componentization Even though we’re using plain JS, each card is its own mini-component.
Event Binding Shows how to handle DOM events cleanly.
Animation with CSS Keeps it performant and easy to tweak.
Separation of Data & View The flashcard content is kept separate from the DOM logic.

✅ What’s Next?

Make the game track score (quiz style).
Pull flashcards from a backend API.
Let users add their own.

🎮 Live Demo: See the Flashcard Game on CodePen

📦 Code Repo: View on GitHub