https://dorothykabarozi.wordpress.com/feed

---

Laravel Mix “Unable to Locate Mix File” Error: Causes and Fixes

If you’re working with Laravel and using Laravel Mix to manage your CSS and JavaScript assets, you may have come across an error like this:

Spatie\LaravelIgnition\Exceptions\ViewException  
Message: Unable to locate Mix file: /assets/vendor/css/rtl/core.css

Or in some cases:

Illuminate\Foundation\MixFileNotFoundException
Unable to locate Mix file: /assets/vendor/fonts/boxicons.css

This error can be frustrating, especially when your project works perfectly on one machine but fails on another. Let’s break down what’s happening and how to solve it.

---

What Causes This Error?

Laravel Mix is a wrapper around Webpack, designed to compile your resources/ assets (CSS, JS, images) into the public/ directory. The mix() helper in Blade templates references these compiled assets using a special file: mix-manifest.json.

This error occurs when Laravel cannot find the compiled asset. Common reasons include:

1. Assets are not compiled yet
   If you’ve just cloned a project, the public/assets folder might be empty. Laravel is looking for files that do not exist yet.
2. mix-manifest.json is missing or outdated
   This file maps original asset paths to compiled paths. If it’s missing, Laravel Mix won’t know where to find your assets.
3. Incorrect paths in Blade templates
   If your code is like: <link rel="stylesheet" href="{{ asset(mix('assets/vendor/css/rtl/core.css')) }}" /> but the RTL folder or the file doesn’t exist, Mix will throw an exception.
4. Wrong configuration
   Some themes use variables like $configData['rtlSupport'] to toggle right-to-left CSS. If it’s set incorrectly, Laravel will try to load files that don’t exist.

---

How to Fix It

Here’s a step-by-step solution:

1. Install NPM dependencies

Make sure you have Node.js installed, then run:

npm install

2. Compile your assets

• Development mode (fast, unminified):

npm run dev

• Production mode (optimized, minified):

npm run build

This will generate your CSS and JS files in the public folder and update mix-manifest.json.

3. Check mix-manifest.json

Ensure the manifest contains the file Laravel is looking for:

"/assets/vendor/css/rtl/core.css": "/assets/vendor/css/rtl/core.css"

4. Adjust Blade template paths

If you don’t use RTL, you can set:

$configData['rtlSupport'] = '';

so the code doesn’t try to load /rtl/core.css unnecessarily.

5. Clear caches

Laravel may cache old views and configs. Clear them:

php artisan view:clear
php artisan config:clear
php artisan cache:clear

---

Pro Tips

• Always check if the file exists in public/assets/... after compiling.
• If you move your project to another machine or server, you must run npm install and npm run dev again.
• For production, make sure your server has Node.js and NPM installed, otherwise Laravel Mix cannot build the assets.

---

Conclusion

The “Unable to locate Mix file” error is not a bug in Laravel, but a result of missing compiled assets or misconfigured paths. Once you:

1. Install dependencies.
2. Compile assets,
3. Correct Blade paths, and
4. Clear caches; your Laravel project should load CSS and JS files without issues.

---

---

Deploying a Simple HTML Project on Linode Using Nginx: My Journey and Lessons Learned

Deploying web projects can seem intimidating at first, especially when working with a remote server like Linode. Recently, I decided to deploy a simple HTML project (index.html) on a Linode server using Nginx. Here’s a detailed account of the steps I took, the challenges I faced, and the solutions I applied.

---

Step 1: Accessing the Linode Server

The first step was to connect to my Linode server via SSH:

ssh root@<your-linode-ip>

Initially, I encountered a timeout issue, which reminded me to check network settings and ensure SSH access was enabled for my Linode instance. Once connected, I had access to the server terminal and could manage files and services.

---

Step 2: Preparing the Project

My project was simple—it only contained an index.html file. I uploaded it to the server under:

/var/www/hng13-stage0-devops

I verified the project folder structure with:

ls -l /var/www/hng13-stage0-devops

Since there was no public folder or PHP files, I knew I needed to adjust the Nginx configuration to serve directly from this folder.

---

Step 3: Setting Up Nginx

I opened the Nginx configuration for my site:

sudo nano /etc/nginx/sites-available/hng13

Initially, I mistakenly pointed root to a non-existent folder (public), which caused a 404 Not Found error. The correct configuration looked like this:

server {
    listen 80;
    server_name <your_linode-ip>;

    root /var/www/hng13-stage0-devops;  # points to folder containing index.html
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }
}

---

Step 4: Enabling the Site and Testing

After creating the configuration file, I enabled the site:

sudo ln -s /etc/nginx/sites-available/hng13 /etc/nginx/sites-enabled/

I also removed the default site to avoid conflicts:

sudo rm /etc/nginx/sites-enabled/default

Then I tested the configuration:

sudo nginx -t

If the syntax was OK, I reloaded Nginx:

sudo systemctl reload nginx

---

Step 5: Checking Permissions

Nginx must have access to the project files. I ensured the correct permissions:

sudo chown -R www-data:www-data /var/www/hng13-stage0-devops
sudo chmod -R 755 /var/www/hng13-stage0-devops

---

Step 6: Viewing the Site

Finally, I opened my browser and navigated to

http://<your-linode-ip>

And there it was—my index.html page served perfectly via Nginx.

---

Challenges and Lessons Learned

1. Nginx server_name Error
   • Error: "server_name" directive is not allowed here
   • Lesson: Always place server_name inside a server { ... } block.
2. 404 Not Found
   • Cause: Nginx was pointing to a public folder that didn’t exist.
   • Solution: Update root to the folder containing index.html.
3. Permissions Issues
   • Nginx could not read files initially.
   • Solution: Ensure ownership by www-data and proper read/execute permissions.
4. SSH Timeout / Connection Issues
   • Double-check firewall rules and Linode network settings.

---

Key Takeaways

• For static HTML projects, Nginx is simple and effective.
• Always check the root folder matches your project structure.
• Testing the Nginx config (nginx -t) before reload saves headaches.
• Proper permissions are crucial for serving files correctly.

---

Deploying my project was a learning experience. Even small mistakes like pointing to the wrong folder or placing directives in the wrong context can break the site—but step-by-step debugging and understanding the errors helped me fix everything quickly.This has kick started my devOps journey and I truly loved the challenge

Embarking on an Outreachy internship is a great start into the heart of open-source , a journey I’ve longed to undertake. December 2023 to March 2024 marked this exhilarating chapter of my life, where I had the honor of diving deep into the GNOME world as an Outreachy intern. In this blog, I’m happy to share my experiences, painting a vivid picture of the growth, challenges, and invaluable experiences that have shaped my journey.

Discovering GNOME: A Gateway to Open-Source Excellence

At its core, GNOME (GNU Network Object Model Environment) is a graphical user interface (GUI) and set of computer desktop applications for users of the Linux operating system.GNOME brings companies, volunteers, professionals, and non-profits together from around the world.

We make GNOME, a completely free software solution for everyone.

Why GNOME Captured My Heart

The Outreachy internship presented a couple of projects to choose from, but my fascination with operating system functionalities—booting, scheduling, memory management, user interface and beyond—drew me irresistibly to GNOME. My mission? To work on the implementation of end-to-end tests, a challenge I embraced head on as i dived into the project documentation to understand the project better.

From the moment I introduced myself on the GNOME community channel in the first days of contribution phase, the warmth and promptness of their welcome were unmatched, shattering the myth of the “busy, distant mentor.” This immediate sense of belonging fueled my determination, despite the initial difficulties of setup procedures and technical trials.

My advice to future Outreachy aspirants

From my experience is to start early, Zero down on a project, try to set up early as this took me almost 2 weeks to finally make a merge request to the project.

Secondly ask questions publicly as this helps you easily get unblocked faster in cases when your mentor is busy.

Milestones and Mastery: The GNOME Journey

Our collective goal for the internship was to implement tests for accessibility features for GNOME desktop and also test some core apps on mobile. The creation of the gnome_accessibility test suite marked our first victory, followed by the genesis of gnome-locales and gnome_mobile test suites. Daily stand ups and weekly mentor meetings became our compass, guiding our efforts and honing our focus on the different tasks.Check out for more details here and share any feedback with us on discourse.

Technically ,I learned a lot about version control and Git workflows, how to actually contribute to a project with a large code base, writing clean, readable and efficient code and ensuring code is thoroughly tested for bugs and errors before pushing it. Some of the soft skills I learned were collaboration, communication skills and the continuous desire to learn new things and being teachable.

Overcoming Obstacles: Hardware Hurdles and Beyond

The revelation that my iOS-based machine was ill-equipped for the task at hand was a stark challenge. The lesson was clear: understanding project specifications is crucial, and adaptability is key. This obstacle, while daunting, taught me the value of preparation and the importance of choosing the right tools for the task.

Beyond Coding: Community, Engagement, and Impact

I have not only interacted with my mentors for the project but also participated in sharing about the work we have done on TWIG where I highlighted the work we had done writing tests for accessibility features ie, High contrast,Large text,Overlay scrollbars, Screen reader, Zoom, Over amplification,Visual alerts and On Screen Keyboard features and added more details on the discourse channel too.

I have had public engagements on contributing to Outreachy over twitter spaces in my community where I shared about how to apply to Outreachy and how to prepare for in the contribution phase and shared more about my internship with GNOME during the GNOME AFRICA Preparatory Boot camp for GSoC & Outreachy, check out my presentation here where I shared more about how to stand out as an Outreachy applicant and my experience working with GNOME .These experiences have not only boosted my technical skills but have also embedded in me a sense of community and courage to tackle the unknown.

A Heartfelt Thank You

As this chapter of my journey with GNOME and Outreachy draws to a close, I am overwhelmed with gratitude.To my selfless mentors , Sam Thursfield and Sonny Piers for the guidance and mentorship . I appreciate you all for what you have planted in us. To Tanjuate you have been an amazing co- intern I could ever ask for. To Kristi Progri and Felipe Borges for coordinating this internship with Outreachy and the GNOME Community.

To Outreachy, thank you for this opportunity. And to every soul who has walked this path with me: your support has been amazing. As I look forward to converging paths at GUADEC in July and beyond, I carry with me not just skills and knowledge, but a heart full of memories, ready to embark on new adventures in the open-source world.

Here’s to infinite learning, enduring friendships, and the unwavering spirit of contribution. May the journey continue to unfold, with success, learning, and boundless possibilities.

Here are some of the accessibility tests for gnome_accessibility testsuite, we added during the internship with GNOME .

Click here to take a more detailed look.

Introduction

Open source embodies collaboration, innovation, and accessibility within the technological realm. Seeking personal insights behind the collaborative efforts, I engaged in conversations with individuals integral to the open source community, revealing the diversity, challenges, and impacts of their work.

Conversations Summary

Venturing beyond my comfort zone, I connected with seasoned open source contributors, each offering unique perspectives and experiences. Their roles varied from project maintainers to mentors, working on everything from essential libraries to innovative technologies.

• Das: Shared valuable insights on securing roles in open source, including resources for applications and tips for academic writing and conference speaking. The best part with Das was that she also reviewed my resume and shared many ways i could make it outstanding and shared templates to use for this.We had a really great chat.
• Samuel: A seasoned C/C++ programmer working mainly on open-source user-space driver development.He was kind enough to share his 20 years long journey on how he started working with open source and how he loves working with low level Hardware.He also commended Outreachy as a great opportunity and my contributions with GNOME in QA testing.He encouraged me to apply for roles in the company he’s working with,and highlighted “Even if they say NO now, next time they will say YES”. Samuel also encouraged me to find my passion and this will guide me to learn faster,create my personal brand and encouraged me to submit some conference talks.
• Dustin: Shared his 20 year journey and we mostly talked about Programming and software engineering in general . Highlighted the significance of networking and adaptability to learn quickly in open source.He shared a story how he “printed out code on one of his first jobs and learnt a skill of figuring out early what you don’t need to understand when faced with a big code base”. This is one skill I needed at the start instead of drowning in documentation trying to understand the project and where to start.
• Stefan: Discussed his transition from a GSOC participant to a mentor,shared opensource job links , commended Outreachy as a big plus. He highlighted not to set yourself up by mental blocking that you can’t do anything, because you can.He encouraged to submit talks at conferences, network and publishing my work.

These interactions showcased the wide-ranging backgrounds and motivations within the open source community and have deepened my respect for the open source community and its contributors. I have some homework to do with my resume and the links to opportunities that were shared with me.Open source welcomes contributors at all levels, offering a platform for innovation and collective achievement.

Feel free to be an Outreachy intern on the upcoming cohorts to start your journey.

Best of luck.

Hello there ! Welcome back!.

As I reach the midpoint of my internship, I’m thrilled to share my journey into the intricate world of end-to-end testing for GNOME OS using the powerful tool, openQA. From initial bafflement to mastering complex tests, it’s been a roller coaster of learning and discovery. Here are a few things i have learned so far along this journey as it unfolds as an Outreachy Intern!

Key Takeaways

• End-to-End Testing Mastery: I’ve gained an in-depth understanding of end-to-end testing, a critical component in ensuring a smooth user experience in software development.
• Problem-Solving Skills: Tackling complex technical issues head-on has honed my problem-solving skills, a vital asset in any tech career.
• Continuous Learning: The tech field is ever-evolving, and this experience has instilled in me the importance of continual learning and adaptation.
• Learning to to collaborate and effectively communicate: I can not stress this enough! Do not be shy on this as silence eats you up more or even worse the uncomfortable feeling of not finishing the task and being stuck for long.
• Learning Git: There are some Git commands that i had seen but not used but while working on this project i had to master,still cant believe I can git rebase faster and excitingly without breaking things! Don’t forget i can git rebase -i HEAD~3 and squash multiple commits into 1 and even when nano editor played me a bit i did crack it in the end. Lastly I learned how to cherry pick commits and put them on on another branch and am till learning more. My mentors shared some resources that helped me along the way thanks to Sonny Piers and Sam Thursfield who were very quick to help. Checkout one of the resources that i looked at here :Handbook , some others are PDF’s I cannot share here.

As I continue this exciting journey, I’m reminded that mastering technology is as much about understanding its complexities as it is about embracing the learning process. To those embarking on a similar path, remember: every challenge is an opportunity to grow. Dive in, stay curious, and enjoy the ride in the world of tech testing!

Happy testing, and keep exploring!

Introduction

Welcome to the exciting world of software testing! If you’re a beginner contributor looking to delve into the realm of end-to-end testing for GNOME OS, you’ve come to the right place. In this post, I will walk you through the process of implementing end-to-end tests using a powerful open-source testing tool called openQA.This is my Outreachy project and am still on the journey as I write this.

What is openQA?

Simply openQA is an automated test tool for operating systems and the applications they run. It allows you to simulate a user’s interaction with your application and ensure that the entire application, including its user interface, works as expected. This is particularly useful for a complex environment like GNOME OS, where ensuring a smooth user experience is crucial.I promise you i still didn’t understand this at first until later in the process!

Step 1: Understanding the Basics of GNOME OS

Before diving into testing, it’s important to have a fundamental understanding of GNOME OS. GNOME OS is not a standalone operating system; rather, it’s a reference system for the GNOME desktop environment. It’s used by developers and testers to ensure that the latest codebase is functioning as expected.For this particular project I wondered how i was supposed to install it and realised i need a virtual environment to so this.Unfortunately i had an IOS system that was not supported to install it on real hardware even when i tried to install the GNOME OS using UTM for IOS.I was later advised to use Boxes from flathub.

Step 2: Setting up the environment

1. You must have the right hardware running on Modern Linux-based OS such as Fedora or Ubuntu At least 20GB of disk space free At least 4GB of RAM free Support for x86_64 hardware virtualization.
2. Install Boxes , download and install the GNOME OS installer and run the initial setup on there.
3. Follow steps on the README guide that also has a contributing guide to make your first contribution.Another major highlight not to forget is to enable KVM follow the steps here on Virtualization here.Without this you will not be able to proceed because when you run the end-to-end tests, openQA creates a x86_64 virtual machine using QEMU and KVM.
4. Don’t forget this part was really the most challenging to get environment ready so first take it seriously and follow the attached links and incase of any issues you can reach out to the GNOME OS community here, you might probably find me there too.

Step 3: Writing Test Scripts

openQA tests are written in Perl. Don’t worry if you’re not familiar with Perl; basic scripting skills and a willingness to learn are enough to get started.

1. Understand the API: Familiarize yourself with the openQA API. The openQA documentation is a great resource that highlights the TEST API showing you all methods exposed by the os-autoinst backend to be used within tests that you will be writing.
2. Start Simple: Begin with a basic test, now in the beginning all i know is i dived deep into documention and I was worried on how to start but this CONTRIBUTING GUIDE helped me narrow down on how to start contributing.In my case i started with adding a test in settings app extending to Search as i progressed slowly to more advanced tests like the one am currently writing, Using the Gnome On Screen Keyboard test. see a11y_screen_keyboard.pm file screenshot below.refer to line 13 in the file.
3. Needles:You will create screenshots for several steps simulating user actions taken called needles and you will reference them as you follow the contributing guide here.Line 13 above refers to the needle files a11y_typing.png and json files attached.The png highlights the screenshot showing the typing field and json file shows the exact coordinates of that typing field.

Step 4: Running Your Tests

Once you’ve written your tests, it’s time to run them:

1. Make sure you have the latest Podman as highlighted in the README.md file .
2. Ssams openqa tool:This is a small command line helper for working with the test tool OpenQA. This is what we used for working with GNOME’s OpenQA tests.This will help you to run the test.

Step 5: Analyzing Test Results

After the tests have run, analyze the results:

1. Review Output: openQA provides screenshots and videos of each step of your test. Review these to understand what happened during the test run. Use save_screenshot; to capture screenshots ,this is highlighted in the TEST API highlighted above and check the output directory for test results ,logs and the .ogv video.
2. Debug Failures: If a test fails, use the output to debug. It could be an issue with the test script highlighted in “_isotovideo.stderr.log” or an actual bug in GNOME OS.

Step 6: Iterating on Your Tests

1. Refine Scripts: Based on your test results, refine your scripts to cover more scenarios or improve reliability.
2. Continuous Learning: Keep learning more about openQA Test API and how to extend more useful tests.

Conclusion

Implementing end-to-end tests with openQA for GNOME OS might seem daunting at first, but with patience and practice, it becomes an invaluable part of the development process. Your contribution will not only enhance the quality of GNOME OS but also give you a strong foundation in software testing. Happy testing!

---

Remember, this is a journey of continuous learning and improvement. Don’t hesitate to seek help from the GNOME and openQA communities – they are incredibly supportive and a treasure trove of knowledge. Good luck!

End to End testing, GnomeOS, OPENQA testing
devops, fedora, gnome, linux, tech

The journey through any software development project is often fraught with challenges, and my experience with the GNOME project during the Outreachy internship has been no exception. One significant hurdle I’ve encountered is the task of creating needles—a crucial component in visual testing—without access to an OpenQA instance.

Understanding the Challenge

OpenQA is an automated testing tool used extensively for operating system-level testing. It’s particularly useful in the GNOME project for its ability to perform visual testing, a method that relies on graphical needle images to verify the appearance of the user interface in this case for GNOME OS. Without a local OpenQA instance, creating these needles becomes a complex task, necessitating a more manual and time-consuming approach of generating several click points, needle by needle.

The Need for Needles

In the context of GNOME, needles are critical for ensuring that the user interface elements appear and behave as expected. They serve as a reference point, allowing OpenQA to compare the current state of the UI with the expected state. This comparison is vital for detecting and rectifying any discrepancies or bugs.

Overcoming the Obstacles

1. Manual Captures and Comparisons: Without OpenQA, I had to resort to manually capturing screenshots of the UI and comparing them with expected images. This process was not so straight forward at the start.
2. Limited Testing Scope: The absence of an automated testing environment like OpenQA limits the scope of testing. Manual testing means fewer iterations, leading to a potential increase in undetected issues.
3. Learning Curve: Adapting to a manual process required a steep learning curve. I had to familiarize myself with the intricacies of GNOME’s UI and learn to use GNU tool to identify match areas and several click-points and upon several videos and with the help of my fellow intern mate and mentors I was able to understand this fully.

The Silver Lining

Despite these challenges, this experience has been incredibly educational. It has honed my problem-solving skills, taught me the value of meticulous attention to detail, and understand the importance of testing in software development. Moreover, it has given me a deeper appreciation of automated testing tools like OpenQA and their role in streamlining the development process.

Moving Forward

Navigating these challenges has been a testament to the resilience and adaptability required in software development. It has also highlighted the need for accessible testing tools and resources, especially in open-source projects. As I continue my journey with GNOME and Outreachy, I am more committed than ever to overcoming these hurdles and contributing to the enhancement of the GNOME user experience.

The struggles faced in creating needles without a local OpenQA instance may seem daunting, but they also present an opportunity for learning and growth. It’s a reminder that in the world of software development, challenges are not just obstacles but stepping stones to greater expertise and understanding.I have currently completed working on a few accessibility tests to support users with various impairments and special needs, particularly seeing and hearing a11y tests on GNOME.

We will also be exploring more on needle generation using the local instance, I will definitely share more if we get it to work locally. Hope you enjoyed this piece, see you next time..

Welcome back,Today I will share with you my three pivotal values: learning, community, and service. My journey exemplifies how integrating these principles can lead to meaningful technological innovations.

Learning:

My tech career is marked by an unending quest for knowledge. In the fast-paced tech sector, I try to stay ahead by continuously updating my skills and embracing new technologies. This commitment to lifelong learning has helped me to stay grounded, continuously learn, and not be left behind.

Community:

With my skills, I use my tech expertise to serve the community. From building an ERP for schools to building a fintech solution for the underbanked in my community, among others,I have been part of a team that crafts solutions that address local needs, making technology a tool for inclusion and problem-solving. This approach has not only advanced tech accessibility but also strengthened community bonds.

Service:

I love sharing what I have learned over the years through volunteer work with women and girls to encourage them to join the tech space, and this reflects my deep-rooted belief in service.

Without even noticing it, I have integrated my personal values into my professional life. My dedication to learning, community, and service makes me continue to aspire to make a positive impact through technology, not only with skill but with heart and purpose.

Hello, world! I’m Dorothy Kabarozi, a software engineer hailing from the vibrant heart of Uganda. Today marks a new chapter in my journey — one I’m thrilled to share with you. As the newest member of the GNOME team and an Outreachy intern from December 2023 to March 2024, I’m here to narrate a tale of passion, perseverance, and open source.

The Spark of Open SourceMy affair with open source began five years ago, not in a grand hall of tech but amidst the bustling community meetups of Pyladies Kampala. As a mentee turned coach, I dove deep into the world of collaborative coding. Imagine my delight when my first contribution to an open-source project earned a response from the project maintainer! That moment was a turning point, igniting a flame that would light my path for years to come.

The Outreachy AspirationThe road to Outreachy, however, was not a straight line. Since 2019, my attempts to join this internship program have resembled a dance — two steps forward, one step back. After many Twitter spaces, and meetups about contributing to open source, my initial applications were accepted, yet I found myself halted at the threshold, overwhelmed by the difficult technologies and my professional commitments. But, as they say, fortune favors the bold.

A Leap of FaithIn 2023, armed with resolve and the lessons of the past, I took a decisive leap. I resigned from my job at the end of September, betting on the chance of an Outreachy acceptance early in October. As the notification of my initial application approval came through, my heart raced with the possibilities that lay ahead. “Your Outreachy initial application is approved.”

Choosing GNOME

Amidst the sea of projects at Outreachy, GNOME stood out like a beacon. My initiation into the community was nothing short of magical — immediate feedback, heartwarming welcomes, and a sense of belonging got me. My mentors, Sam Thursfield and Sonny, were the guiding stars. However, a daunting challenge loomed: my computer specs were mismatched with the project requirements.

As I conclude,my unique journey to Outreachy has been so special as it unfolds.

Stay tuned as I share the twists and turns of tackling this technological hurdle and my ongoing adventure with GNOME.

My goals are to learn how to collaborate effectively, enhance my problem-solving skills, deepen my understanding of inclusive design principles through accessibility tests, and improve my quality assurance and debugging skills.