DEV Community: Gerardo Andrés Ruiz Castillo

Beyond Hardcoding: Ensuring Correct Payment Units in Reimpact's Platform

Gerardo Andrés Ruiz Castillo — Mon, 25 May 2026 06:00:05 +0000

On Reimpact's platform, we recently addressed a critical display inaccuracy related to service payment units. While seemingly minor, such details are crucial for user trust and clarity, especially in quoting and billing.

The Problem: Hardcoded Payment Units

Initially, our system for displaying service quotes relied on a hardcoded payment unit, specifically 'UF/h'. This unit, representing 'Unidad de Fomento per hour', was hardcoded directly into the frontend display logic. While 'UF/h' was applicable for many services, it created a significant inconsistency for other services that operated on different billing cycles or units, such as 'UF/día' (Unidad de Fomento per day). This discrepancy meant that regardless of a service's actual database-defined payment unit, the user interface would always show 'UF/h'. This led to confusion and potential misinterpretations of service costs, undermining the accuracy our users expect.

The Fix: Dynamic Unit Retrieval

To rectify this, the solution was straightforward yet impactful: instead of embedding the unit directly in the frontend, we opted to dynamically fetch the correct payment_unit from the database, associated with each specific service. This unit is now passed from the server-side controller to the view, ensuring that what the user sees precisely matches the service's actual billing structure.

Implementation Details

The core of the fix involved modifying the controller to retrieve the payment_unit alongside other service data and passing it to the view. The view then simply renders this dynamic value.

// In your PHP Controller (e.g., ServiceQuoteController.php)
class ServiceQuoteController
{
    public function showServiceQuote(int $serviceId)
    {
        // Simulate fetching service data from a database or service layer
        $serviceData = $this->serviceRepository->findById($serviceId);

        // Example dynamic service data
        if ($serviceId === 1) {
            $serviceData = ['name' => 'Consulting', 'base_rate' => 10, 'payment_unit' => 'UF/h'];
        } elseif ($serviceId === 2) {
            $serviceData = ['name' => 'Project Management', 'base_rate' => 80, 'payment_unit' => 'UF/día'];
        } else {
            $serviceData = ['name' => 'General Service', 'base_rate' => 50, 'payment_unit' => 'UF/unit'];
        }

        return view('service.quote', [
            'service' => $serviceData
        ]);
    }
}

// In your Blade/PHP View (e.g., resources/views/service/quote.blade.php)
<div>
    <h1>Quote for {{ $service['name'] }}</h1>
    <p>Rate: {{ $service['base_rate'] }} <strong>{{ $service['payment_unit'] }}</strong></p>
    <small>The payment unit is now dynamically displayed.</small>
</div>

This simple adjustment removes the hardcoded dependency, making the system more robust and adaptable to various service types and billing models. The view no longer assumes a unit but rather uses the precise information provided by the backend.

Outcome and Benefits

This change provides a significantly more accurate and flexible user experience. Each service's quoting now correctly reflects its unique payment unit, enhancing clarity and reducing potential misunderstandings for our users. It's a small but significant step towards greater precision and user trust in our platform's displayed information, ensuring that our interface accurately represents the underlying business logic and data.

Enhancing User Surveys: From Single Choice to Multi-Select and Reliable Notifications

Gerardo Andrés Ruiz Castillo — Fri, 22 May 2026 06:08:04 +0000

Delivering a seamless and informative user experience is paramount for any digital product. Recently, the Reimpact/platform project, specifically its landing component, underwent significant updates to its user survey system. These changes focused on improving data capture flexibility and ensuring users received promised follow-up communications.

Adapting Survey Input for Richer Data

Initially, key questions within our survey, such as the product_type inquiry, relied on a single-choice selection. While simple, this approach proved too restrictive when users needed to indicate multiple relevant options. For instance, if a product could fall into several categories, a single choice didn't accurately reflect their situation. This led to incomplete data and user frustration.

The solution involved transforming these single-choice fields into multi-select checkboxes. This change allowed users to choose all applicable options, providing a much richer and more accurate dataset. Alongside this, we introduced new options, such as "textiles," to broaden the scope of choices and updated question labels for clarity. Crucially, the backend logic for processing these responses also needed to evolve. Instead of direct equality checks, our outcome rules were updated to use contains or not_contains operators to properly evaluate array-based answers.

Here's a simplified example of how you might validate and process multi-choice input in a PHP application:

// In a Form Request or Controller validation logic
public function rules()
{
    return [
        'product_type' => ['required', 'array', 'min:1'],
        'product_type.*' => ['string', Rule::in(['electronics', 'textiles', 'packaging', 'other'])],
    ];
}

// In your processing logic, checking conditions based on multi-choice answers
if (in_array('textiles', $surveyResult->product_type)) {
    // Apply specific logic for textile products
    $this->handleTextileProductLogic();
}

if (!empty(array_intersect(['electronics', 'packaging'], $surveyResult->product_type))) {
    // Apply logic for products in specific categories
    $this->handleSpecificCategoryLogic();
}

Fulfilling the Promise: Emailing Survey Results

A critical element of user trust is following through on commitments. Our survey interface explicitly informed users that they would receive their results via email upon submission. However, this email notification was never actually implemented, creating a disconnect between expectation and reality.

To rectify this, a new SurveyResultMail Mailable class was introduced, complete with a dedicated email template for presenting the survey outcomes. The sending mechanism was then integrated into the BlogController::submitSurvey() method, responsible for handling survey submissions. A try/catch block was wrapped around the email sending operation to ensure robustness. This critical detail means that even if the email sending process encounters an unexpected error (e.g., mail server issues), the user's on-screen experience is unaffected, and they still see their results immediately, preventing a broken user flow.

This approach prioritizes user experience while providing a fallback for potential system failures:

use App\Mail\SurveyResultMail;
use Illuminate\Support\Facades\Mail;

// Inside your BlogController::submitSurvey method
public function submitSurvey(Request $request)
{
    // ... process survey data ...
    $surveyResult = $this->saveSurveyData($request->all());

    try {
        Mail::to($request->user())->send(new SurveyResultMail($surveyResult));
        // Log success or additional analytics
    } catch (Exception $e) {
        // Log the email sending error but do not block user flow
        Log::error('Failed to send survey result email: ' . $e->getMessage(), ['user_id' => $request->user()->id]);
    }

    // Redirect or return view to show on-screen results regardless of email status
    return view('survey.result', compact('surveyResult'));
}

Actionable Takeaways

When designing user interactions, always consider the flexibility of data capture methods and ensure all implied promises are met. Migrating from single-choice to multi-select can significantly enhance data quality and user satisfaction. Furthermore, when implementing external operations like email notifications, prioritize user flow with robust error handling (e.g., try/catch) to prevent failures in one system from breaking the entire user experience. Always test these paths thoroughly to confirm both success and failure scenarios are handled gracefully.

Streamlining User Engagement: Direct Booking Integration on Reimpact's Platform

Gerardo Andrés Ruiz Castillo — Thu, 21 May 2026 06:00:04 +0000

Introduction

In today's fast-paced digital landscape, minimizing friction in the user journey is paramount for converting interest into action. For platforms offering advisory or consultation services, enabling direct and immediate booking capabilities can significantly enhance user experience and operational efficiency.

The Challenge: Indirect Scheduling

Previously, users interested in scheduling an advisory session on Reimpact's platform, particularly through call-to-action (CTA) buttons in survey emails, were directed to a generic contact page. This multi-step process often introduced unnecessary friction, potentially leading to drop-offs before an appointment could be secured. The goal was to remove this intermediate step and provide a more direct path to engagement.

The Solution: Direct Google Calendar Booking

To address this, we implemented a direct integration with Google Calendar's appointment scheduling feature. The "Agendar asesoría" (Schedule an appointment) button, prominent in our survey email CTAs on the landing page, now links directly to a pre-configured Google Calendar booking URL. This change allows users to immediately view available slots and book an appointment without navigating away to a separate contact form.

Implementation Example

This change typically involves updating the target URL within a template or configuration file. For a PHP-based application, this might look like updating a variable or a direct link in a view:

<?php

// In a configuration file or a method handling CTA links
function getAppointmentBookingUrl(): string
{
    // This URL would come from a secure configuration or environment variable
    return 'https://calendar.google.com/calendar/appointments/s/YOUR_APPOINTMENT_ID';
}

// In a Blade/PHP template for the email CTA button
$bookingUrl = getAppointmentBookingUrl();
echo '<a href="' . htmlspecialchars($bookingUrl) . '" target="_blank" class="cta-button">Agendar asesoría</a>';

?>

This ensures that whenever the CTA button is rendered, it points directly to the active booking link, bypassing any intermediate pages.

Immediate Impact

This seemingly small adjustment has a significant impact on user engagement. By providing a direct link to the Google Calendar, we've achieved:

Reduced Friction: Users can book appointments in fewer clicks.
Improved Conversion Rates: A streamlined process increases the likelihood of users completing the booking.
Enhanced User Experience: A more intuitive and efficient scheduling process reflects positively on the overall platform experience.
Operational Efficiency: Reduces the need for manual follow-ups that might have been required for contact form submissions.

Key Takeaways

When designing user flows, especially for critical actions like scheduling or purchasing, always seek opportunities to simplify and shorten the path to completion. Leveraging direct integrations with third-party services like Google Calendar for scheduling can be a powerful way to achieve this.

Key Insight

Every click saved in a critical user journey contributes directly to better engagement and higher conversion rates. Optimize for directness wherever possible.

Streamlining SaaS Quoting: Enhanced User Experience and Granular Control

Gerardo Andrés Ruiz Castillo — Wed, 20 May 2026 06:09:04 +0000

Introduction

In the Reimpact platform project, our SaaS quote form is a critical component for potential clients to configure and estimate their service packages. A smooth, intuitive, and transparent quoting process is essential for user satisfaction and conversion. Recently, we focused on significant enhancements to this form to improve clarity, flexibility, and control over service selections and pricing.

Improving the User Experience

The previous iteration of our quote form, while functional, presented some areas for improvement in terms of user guidance and flexibility. Our recent updates addressed these directly:

Clearer Labels and Guidance

To enhance user understanding, we refined several key labels. For instance, "Servicios Extra (Horas)" was simplified to "Servicios Extra", making it less prescriptive and more inviting. Similarly, module selection received clearer guidance with a new subtitle: "(Seleccionar al menos 1)", ensuring users understand the minimum requirement.

Flexible Module Selection

A significant change involved the 'Packaging' module. Previously, it was designated as a mandatory base module, often creating friction for users who might not require it. We've now removed its 'required' status, making it, like all other modules, optional. This allows customers greater freedom to tailor their package precisely to their needs, without being forced into unnecessary selections.

Enhanced Quoting Logic with Service Limits

Beyond cosmetic and structural improvements, we introduced more robust logic for service quantity selection. To prevent over-selection or misconfiguration, we've implemented per-service maximum quantities on the slider inputs. This ensures that users select quantities within predefined business rules, providing both guardrails for the user and predictability for our operations.

For example, services like 'Baseline', 'Audit', 'Support', 'Training', and 'Consulting' now have specific upper limits (e.g., Baseline at 20, Audit at 12, Support at 24, Training at 1, Consulting at 24). This not only guides the user but also ensures the integrity of the generated quote.

<?php

class ServiceLimits
{
    public static function getLimits(): array
    {
        return [
            'baseline'   => ['min' => 1, 'max' => 20],
            'audit'      => ['min' => 0, 'max' => 12],
            'support'    => ['min' => 0, 'max' => 24],
            'training'   => ['min' => 0, 'max' => 1],
            'consulting' => ['min' => 0, 'max' => 24],
        ];
    }

    public static function validateQuantity(string $service, int $quantity): bool
    {
        $limits = self::getLimits();
        if (isset($limits[$service])) {
            return $quantity >= $limits[$service]['min'] && $quantity <= $limits[$service]['max'];
        }
        return false; // Service not found or no limits defined
    }
}

// Example usage in a form processing logic:
$serviceName = 'audit';
$userQuantity = 15; // User attempts to select 15

if (!ServiceLimits::validateQuantity($serviceName, $userQuantity)) {
    echo "Error: Invalid quantity for {$serviceName}."; // This would trigger an error
} else {
    echo "Quantity {$userQuantity} for {$serviceName} is valid.";
}

?>

This PHP example illustrates how these limits could be defined and validated within the application, ensuring that user inputs conform to the business rules.

Transparent Summary Details

One of the most impactful improvements for user confidence is the new itemized breakdown in the summary panel. Instead of a high-level total, users now see a clear, detailed list of each selected module and service, along with their respective quantities and costs. This transparency allows users to easily review their choices, understand how the total is calculated, and build trust in the quoting process.

Conclusion

These enhancements to the Reimpact platform's SaaS quote form collectively deliver a more intuitive, flexible, and transparent experience. By improving labels, offering greater module choice, implementing robust service limits, and providing a detailed summary, we empower users to configure their ideal service package with confidence, leading to a better overall user journey and more accurate quotes.

Enhancing UI Reactivity: Dynamic Editor Panels with Alpine.js and PHP

Gerardo Andrés Ruiz Castillo — Mon, 18 May 2026 22:01:03 +0000

Building highly interactive user interfaces often means juggling complex client-side state and ensuring seamless communication with the backend. For the Breniapp/brenia project, we recently tackled this by revamping the editor panel to offer a more fluid user experience, specifically focusing on dynamic layer expansion and real-time canvas preview updates. This overhaul leveraged Alpine.js for frontend reactivity, streamlining how users interact with generated content.

The Challenge: Static Panels vs. Dynamic Needs

Previously, parts of our editor panel might have relied on full page reloads or more cumbersome JavaScript to manage UI state. As features like iterative content generation and customizable layers became more central, the need for an instant, reactive UI grew. Users expect immediate visual feedback and the ability to expand and collapse detailed controls without disruption.

Alpine.js for Lightweight Reactivity

The core of this enhancement lies in Alpine.js, a lightweight JavaScript framework that brings the power of reactive data binding directly to your HTML markup. We introduced x-data to manage the state of the editor panel, specifically for expandedLayer (controlling the visibility of layer details) and canvasImageUrl (displaying the generated content preview). This declarative approach simplifies complex UI logic.

Event-Driven Updates: Seamless Canvas Previews

A critical aspect was updating the canvas preview in real-time as content is generated. Rather than polling or manual DOM manipulation, we implemented an event-driven mechanism. After a generation process completes, a generation-completed event is dispatched on the client-side. Alpine.js then listens for this event and updates the canvasImageUrl state, instantly refreshing the preview without user intervention.

This approach cleanly separates the backend generation logic from the frontend rendering, making the system more robust and easier to maintain. The PHP backend is responsible for processing the generation request and ultimately providing the new image URL, which is then picked up by the Alpine.js component.

Consider a simplified PHP endpoint that might handle the image generation request and provide the updated URL:

<?php

namespace App\Controllers;

use App\Services\ImageGenerator;
use Framework\Http\Response;

class EditorApiController
{
    private ImageGenerator $generator;

    public function __construct(ImageGenerator $generator)
    {
        $this->generator = $generator;
    }

    public function generateCanvasPreview(): Response
    {
        // Assume request body contains necessary generation parameters
        $params = json_decode(file_get_contents('php://input'), true);

        // Call a service to process and generate the image
        $newImageUrl = $this->generator->createImage($params);

        // Return the new URL to the client
        return new Response(json_encode([
            'imageUrl' => $newImageUrl,
            'message' => 'Generation complete!'
        ]), 200, ['Content-Type' => 'application/json']);
    }
}

This PHP code snippet illustrates a backend endpoint that would receive a request, trigger the image generation process (e.g., in a ImageGenerator service), and then return a JSON response containing the imageUrl. On the frontend, an Alpine.js component would make an AJAX call to this endpoint, and upon receiving the imageUrl, dispatch a custom generation-completed event (or directly update its state if the AJAX call is handled within the component).

Conclusion and Actionable Takeaway

The shift to a more reactive editor panel using Alpine.js significantly enhanced the user experience within Breniapp/brenia. By leveraging x-data for local component state and event listeners for inter-component communication, we achieved dynamic UI behavior with minimal JavaScript overhead. If you're looking to add interactive elements and real-time feedback to your web applications without the complexity of a full-blown framework, consider Alpine.js. Pair it with a robust PHP backend for data processing, and you can build highly responsive interfaces that delight users.

Actionable Takeaway: When faced with static UI elements that need to become dynamic, explore lightweight JavaScript frameworks like Alpine.js for managing frontend state and implementing event-driven updates. Design your backend APIs to provide the necessary data payloads for these frontend interactions.

Manejo de Errores y Prevención de Publicaciones Duplicadas en devlog-ist/landing

Gerardo Andrés Ruiz Castillo — Wed, 11 Mar 2026 07:04:04 +0000

Introducción

En el proyecto devlog-ist/landing, que permite a los usuarios publicar contenido en diversas plataformas, se ha trabajado en mejorar la robustez del sistema y prevenir problemas comunes relacionados con la publicación de contenido.

El Desafío

El sistema presentaba dos problemas principales:

Errores 500 al alcanzar el límite diario de publicaciones: Cuando un usuario intentaba publicar más contenido del permitido en un día, el sistema respondía con un error 500 genérico, lo cual no era informativo ni amigable.
Publicaciones duplicadas: En ciertas ocasiones, el sistema programaba publicaciones y, al mismo tiempo, el usuario intentaba publicar el mismo contenido de forma inmediata, resultando en una doble publicación.

La Solución

Para abordar estos problemas, se implementaron las siguientes soluciones:

Manejo de DailyPostLimitReachedException: Se capturó la excepción DailyPostLimitReachedException en todas las acciones de publicación (LinkedIn, Dev.to, individual y masiva). En lugar de mostrar un error 500, se muestra una notificación traducida al idioma del usuario, indicando que ha alcanzado su límite diario de publicaciones.
```
try {
    // Lógica de publicación
} catch (DailyPostLimitReachedException $e) {
    // Mostrar notificación traducida
    echo __('daily_publish_limit_reached');
}
```
Cancelación de publicaciones programadas pendientes: Al publicar contenido de forma inmediata, se cancelan los registros de ScheduledPost pendientes para evitar la doble publicación desde la cola de programación.
```
// Cancelar publicaciones programadas pendientes
ScheduledPost::where('post_id', $postId)->delete();
```

Decisiones Clave

Traducciones: Se agregaron traducciones para el mensaje daily_publish_limit_reached en los cuatro idiomas soportados (inglés, español, francés y alemán).
Robustez: Manejar la excepción específica mejora la experiencia del usuario al proporcionar información clara sobre el problema.
Prevención: Cancelar las publicaciones programadas evita la duplicación de contenido, manteniendo la integridad del sistema.

Resultados

Se eliminaron los errores 500 relacionados con el límite diario de publicaciones, mejorando la experiencia del usuario.
Se previnieron las publicaciones duplicadas, asegurando que el contenido se publique solo una vez.

Lecciones Aprendidas

Es crucial manejar las excepciones específicas en lugar de depender de errores genéricos. Además, la prevención de problemas a través de la cancelación de tareas redundantes puede mejorar significativamente la fiabilidad del sistema.

Optimizing Deployments for Low-Resource VPS Environments

Gerardo Andrés Ruiz Castillo — Sat, 07 Mar 2026 07:31:05 +0000

Deploying applications to low-resource Virtual Private Servers (VPS) can be challenging. This post explores strategies for optimizing deployments to minimize resource consumption and improve reliability, specifically for the devlog-ist/landing project.

The Challenge

Low-resource VPS environments often suffer from limited RAM and CPU. Standard deployment procedures can easily exhaust these resources, leading to slow deployments, failed builds, and application instability. The goal is to reduce the memory footprint and optimize build processes to fit within the constraints of the VPS.

Strategies for Optimization

Several techniques can be employed to optimize deployments for low-resource environments:

Reusing node_modules: Similar to the vendor/ directory in PHP projects, the node_modules/ directory can be reused from the previous release. This avoids re-downloading and re-installing dependencies on every deploy, saving significant time and bandwidth. The principle here is that dependencies change less frequently than the application code itself.
Limiting Node RAM Usage: Node.js can consume substantial RAM during builds. By setting the NODE_OPTIONS=--max-old-space-size=512 environment variable, we can limit the maximum memory Node.js can use. This prevents the build process from exhausting all available RAM and triggering out-of-memory errors.
Utilizing npm ci --prefer-offline: The npm ci command performs a clean install from the package-lock.json file, ensuring consistent dependency versions. The --prefer-offline flag instructs npm to use the local cache whenever possible, further reducing network activity and improving speed.
Splitting Deployments into Phases: Separating the deployment process into pre-activate and post-activate phases allows for more granular control and error handling. Pre-activate tasks can include copying necessary files and running database migrations, while post-activate tasks can involve clearing caches and restarting services.
Timing Deployment Phases: Adding timing information to each deployment phase (e.g., using time command) helps identify bottlenecks and areas for further optimization. This allows for data-driven decisions when making changes to the deployment process.

Implementation

The following example demonstrates how to limit Node RAM usage in a deployment script:

NODE_OPTIONS=--max-old-space-size=512 npm ci --prefer-offline

This command sets the NODE_OPTIONS environment variable to limit the maximum old space size to 512MB before running npm ci. This prevents the Node.js process from consuming excessive memory during installation.

Conclusion

Optimizing deployments for low-resource VPS environments requires careful consideration of resource consumption and build processes. By reusing node_modules, limiting Node RAM usage, utilizing npm ci --prefer-offline, splitting deployments into phases, and timing deployment steps, we can significantly improve the reliability and speed of deployments, even on constrained hardware.

Tenant-Specific Scheduling in devlog-ist/landing

Gerardo Andrés Ruiz Castillo — Sat, 07 Mar 2026 06:00:05 +0000

Introduction

In the devlog-ist/landing project, which likely involves a landing page generator with publishing capabilities, a key requirement is the ability to tailor content scheduling to individual tenants. This post explores how configurable publishing schedules were introduced to provide a more natural and less bot-like content delivery experience, enhancing the platform's flexibility and user experience.

The Challenge: Hardcoded Scheduling

Previously, the post scheduling mechanism relied on hardcoded values within the PostStaggeringService. This approach lacked the flexibility needed to accommodate the diverse needs of different tenants. All tenants were subject to the same rigid schedule, leading to potentially unnatural publishing patterns and a one-size-fits-all experience.

The Solution: Configurable Tenant Settings

The solution involved introducing configurable publishing schedule settings for each tenant. Specifically, tenants can now adjust the following parameters via the AutomationSettings page:

Publish Window Hours (Start/End): Define the time frame during which posts should be published.
Maximum Posts Per Hour: Control the density of posts published within the defined window.
Jitter Minutes: Introduce randomness to the exact publishing time, making the schedule less predictable and more organic.

Implementation Details

The hardcoded values in PostStaggeringService were replaced with these tenant-specific settings. This allows each tenant to customize their publishing schedule according to their preferences and audience behavior. For example, consider a hypothetical scenario where a tenant wants to publish content primarily during business hours, with a limited number of posts per hour and a slight variation in timing to avoid appearing robotic. The configuration might look like this:

$tenantSettings = [
    'publish_start_hour' => 9,
    'publish_end_hour' => 17,
    'max_posts_per_hour' => 3,
    'jitter_minutes' => 10,
];

// The PostStaggeringService would then use these settings to determine the
// appropriate time to publish each post.

Benefits of Configurable Scheduling

Improved User Experience: Tenants can tailor content delivery to their specific audience, leading to higher engagement.
More Natural Publishing Patterns: The introduction of jitter and customizable windows prevents the appearance of automated bot-like behavior.
Increased Flexibility: The platform becomes more adaptable to the diverse needs of different tenants.

Conclusion

By introducing configurable publishing schedules, the devlog-ist/landing project has significantly enhanced its content delivery capabilities. This change provides tenants with the flexibility they need to create a more engaging and natural user experience, moving away from rigid, hardcoded schedules towards a more dynamic and personalized approach.

Enhancing Security Audits: Avoiding False Positives in File Path Detection

Gerardo Andrés Ruiz Castillo — Fri, 06 Mar 2026 12:33:04 +0000

Introduction

In the devlog-ist/landing project, we're continually working to improve our security posture. A recent focus has been on refining our security auditing tools to reduce false positives, particularly around the detection of potentially sensitive file paths.

The Challenge

Our automated security audits sometimes flagged placeholder file paths as potential exposures of sensitive information. For example, paths like /path/to/certificate or /path/to/private/key were incorrectly identified as containing actual private keys or certificates. This was due to the LLM misinterpreting these paths, which were intended only as examples, as real file locations containing sensitive data.

The Solution

To address this, we've reinforced the rule that paths matching the /path/to/ pattern are always examples. This helps the LLM to correctly interpret these paths and avoid flagging them as potential security risks. Here's an example of how we might handle this in code:

<?php

class SecurityAudit
{
    public function isSensitivePath(string $path): bool
    {
        // Check if the path matches the /path/to/ pattern and exclude it from sensitive checks
        if (preg_match('/^\/path\/to\//', $path)) {
            return false; // It's an example path, not a real one
        }

        // Perform other checks for sensitive files (e.g., checking for known certificate extensions)
        if (strpos($path, '.pem') !== false || strpos($path, '.key') !== false) {
            return true; // Potentially sensitive file
        }

        return false;
    }
}

This code snippet demonstrates how we can use a regular expression to identify placeholder paths and exclude them from further security checks. By explicitly excluding paths that match the /path/to/ pattern, we prevent false positives and ensure that our security audits focus on real potential vulnerabilities.

Key Decisions

Regular Expression Matching: Using preg_match to identify example paths based on the /path/to/ pattern.
Exclusion Logic: Implementing logic to exclude identified example paths from sensitive file checks.

Results

By implementing this change, we've significantly reduced the number of false positives in our security audits. This allows our security team to focus on real potential vulnerabilities, improving our overall security posture.

Lessons Learned

This experience highlights the importance of context in security auditing. Automated tools must be able to distinguish between example paths and real file locations to avoid generating unnecessary alerts. By carefully crafting our audit rules and incorporating contextual awareness, we can improve the accuracy and effectiveness of our security audits.

Tenant Landing Page Optimization: Caching for Performance

Gerardo Andrés Ruiz Castillo — Fri, 06 Mar 2026 10:55:03 +0000

The devlog-ist/landing project delivers landing pages for tenants. A recent optimization focused on reducing database load by implementing a caching strategy for tenant-specific landing page data. This change significantly improves performance by minimizing redundant database queries.

The Problem

Previously, each request to a tenant's landing page triggered multiple database queries to fetch stats, badges, recommendations, and post languages. In particular, loading all posts to generate statistics resulted in a substantial performance bottleneck. This "load ALL posts for stats" query ran on every landing page hit, even if the data hadn't changed. This approach was clearly unsustainable as the number of tenants and posts grew.

The Solution: Caching Tenant Landing Page Data

To address this, a caching mechanism was introduced. Now, tenant-specific landing page data is cached with a Time-To-Live (TTL) of one hour. This means that the first request for a tenant's landing page will still incur the database queries, but subsequent requests within the hour will be served from the cache. The cache is automatically invalidated whenever a post is saved or deleted, ensuring data consistency.

Here's a simplified example of how the caching might be implemented in PHP:

<?php

use Symfony\Component\Cache\Adapter\FilesystemAdapter;

$cache = new FilesystemAdapter();
$cacheKey = 'tenant_' . $tenantId . '_landing_page_data';

$landingPageData = $cache->get($cacheKey, function () use ($tenantId) {
    // Fetch data from the database
    $stats = getTenantStatsFromDatabase($tenantId);
    $badges = getTenantBadgesFromDatabase($tenantId);
    $recommendations = getTenantRecommendationsFromDatabase($tenantId);
    $postLanguages = getTenantPostLanguagesFromDatabase($tenantId);

    $data = [
        'stats' => $stats,
        'badges' => $badges,
        'recommendations' => $recommendations,
        'postLanguages' => $postLanguages,
    ];

    return $data;
});

// Use $landingPageData to render the landing page

This code snippet demonstrates how the Symfony cache component can be used to store and retrieve tenant landing page data. The get method either returns the cached data or executes the provided closure to fetch fresh data from the database if the cache is empty or expired.

The Impact

This caching strategy significantly reduces the number of database queries per request, particularly on cache warm. More importantly, it eliminates the expensive "load ALL posts for stats" query that previously ran on every landing page hit. This leads to improved landing page load times and reduced database load, resulting in a better user experience and improved system scalability.

Geolocation Optimization: Caching and Local Database Lookup

Gerardo Andrés Ruiz Castillo — Fri, 06 Mar 2026 10:43:05 +0000

This post discusses optimizing geolocation lookups in the devlog-ist/landing project, which enhances user experience by personalizing content based on location.

The Challenge

Initially, the application relied on an external HTTP service (ip-api.com) to determine a visitor's country based on their IP address. This approach introduced significant latency, adding approximately 1 second to each page load. Furthermore, relying on an external service meant potential rate limits and service disruptions.

The Solution

To address these issues, we implemented two key optimizations:

Local Database Lookup: Replaced the external HTTP calls with lookups against a local MaxMind GeoLite2-City database. This eliminates network latency and reliance on an external service.
Caching: Introduced a caching layer to minimize repeat lookups. Resolved country codes are cached for 7 days, while unresolvable IPs are cached for 1 hour.

Implementation Details

The local database lookup is performed using the maxminddb package in Go. Here's an example:

package main

import (
    "fmt"
    "net"

    "github.com/oschwald/geoip2/maxminddb"
)

func main() {
    db, err := maxminddb.Open("GeoLite2-City.mmdb")
    if err != nil {
        panic(err)
    }
    defer db.Close()

    ip := net.ParseIP("8.8.8.8")

    var record struct {
        Country struct {
            IsoCode string `json:"iso_code"`
        } `json:"country"`
    }


    err = db.Lookup(ip, &record)
    if err != nil {
        panic(err)
    }
    fmt.Printf("Country code: %v\n", record.Country.IsoCode)
}

This code snippet demonstrates how to open the MaxMind database, perform a lookup for a given IP address, and extract the country code. A similar function integrates with a caching layer (e.g., Redis) to store the results. When an IP address needs to be geolocated, the cache is checked first; if the result is not in the cache, the local database lookup is performed, and the result is then stored in the cache with the appropriate expiration time.

To simplify the process of keeping the GeoLite2-City database up-to-date, an artisan command was added to download the latest version.

The Result

By switching to a local database and implementing caching, we significantly reduced the latency associated with geolocation lookups. This resulted in faster page load times and an improved user experience. The application is also more resilient to external service outages and rate limits.

The Takeaway

Optimizing geolocation lookups can have a significant impact on application performance and reliability. By leveraging local databases and caching, developers can minimize latency and improve the user experience. Regularly updating the local database is crucial to ensure accuracy.

Optimizing Tenant Schema Access in Go Applications

Gerardo Andrés Ruiz Castillo — Fri, 06 Mar 2026 06:01:04 +0000

Introduction

In multi-tenant applications, efficient management of database schemas is crucial for performance. This post explores how caching and schema tracking can significantly reduce database load in Go applications.

The Challenge

Accessing tenant-specific data often involves repetitive database queries to check for schema existence and set the appropriate search path. These redundant operations can lead to performance bottlenecks, especially when dealing with a large number of tenants. Specifically, the devlog-ist/landing project experienced a high volume of pg_class queries and redundant SET search_path statements, impacting overall application responsiveness.

The Solution

To address these performance issues, the following optimizations were implemented:

Caching Tenant Table Existence: The result of the tenantsTableExists() check is now cached using a persistent cache with a Time-To-Live (TTL) of one hour. This eliminates a significant number of pg_class queries.
Tracking Applied Schema: The application now tracks the currently applied schema. Before executing a SET search_path statement, it checks if the desired tenant schema is already set. If so, the redundant statement is skipped.
Skipping Redundant Schema Reset: Similarly, the resetTenantSchema() function is skipped when the schema is already null, avoiding unnecessary database interactions.

These optimizations are implemented in Go, leveraging caching mechanisms and state management to minimize database load. Here's an example illustrating the concept of caching the schema existence:

package main

import (
    "fmt"
    "time"
)

var schemaCache = make(map[string]bool)
var cacheTTL = time.Hour

func checkSchemaExists(schemaName string) bool {
    // Check if the schema exists in the cache
    if exists, ok := schemaCache[schemaName]; ok {
        fmt.Println("Schema existence retrieved from cache for:", schemaName)
        return exists
    }

    // Simulate a database call to check schema existence
    fmt.Println("Checking schema existence in database for:", schemaName)
    // In real implementation, this would be a database query
    exists := simulateDatabaseCheck(schemaName)

    // Store the result in the cache with a TTL
     schemaCache[schemaName] = exists

    // Invalidate cache after TTL
    go func() {
         time.Sleep(cacheTTL)
         delete(schemaCache, schemaName)
         fmt.Println("Cache invalidated for:", schemaName)
    }()

    return exists
}

func simulateDatabaseCheck(schemaName string) bool {
    // Replace with actual database query
    // For example:
    // err := db.QueryRow("SELECT 1 FROM pg_namespace WHERE nspname = $1", schemaName).Scan(nil)
    // return err == nil
    return true // Simulating schema exists
}

func main() {
     schemaName := "tenant_123"
     exists := checkSchemaExists(schemaName)
     fmt.Println("Schema exists:", exists)

    // Subsequent check will use the cache
     exists = checkSchemaExists(schemaName)
     fmt.Println("Schema exists:", exists)

     time.Sleep(2 * time.Second) // Give some time for goroutine to execute


}

Results

These optimizations resulted in a significant reduction in database queries:

Approximately 13,000 pg_class queries per day were eliminated.
Around 10,000 redundant SET search_path statements per day were skipped.

This leads to improved application performance and reduced load on the database server.

Lessons Learned

Caching and state management are powerful tools for optimizing database-intensive applications. By identifying and eliminating redundant database operations, developers can achieve significant performance gains. Regular monitoring and profiling of database queries can help identify areas for optimization.