DEV Community: Ivole32

The Berlin Wall in Our Heads | What Founders Can Learn About Mindset

Ivole32 — Wed, 15 Jul 2026 02:30:00 +0000

The Berlin Wall in Our Heads

The Berlin Wall is usually remembered as one of the most visible symbols of division. For almost three decades it separated families, friends, and an entire city. Looking back, it is easy to focus on the concrete, the guard towers, and the fences. But what interests me even more is something that cannot be photographed. Over time, the wall became part of how people thought. It was no longer just a barrier across Berlin. It became a boundary in people's minds.

That is what makes the stories of those who escaped so remarkable. Before someone dug a tunnel, built a homemade hot air balloon, or hid in a car, they had already done something much harder. They questioned the assumption that escape was impossible. They lived under the same conditions as everyone else, yet they refused to believe that the limits around them were absolute.

I think about this often when building software. The biggest obstacles are rarely technical. More often they are ideas we accept without noticing. We tell ourselves that a market is already won, that a competitor is too large, that we need more funding before we can start, or that we are not experienced enough to build something meaningful. Sometimes those concerns are valid, but many of them survive simply because nobody stops to ask whether they are still true.

The founders I admire are not necessarily the smartest people in the room. What makes them different is that they spend less time accepting the world as it is and more time asking why it has to be that way. They treat assumptions as something to investigate rather than something to inherit. That mindset changes the kinds of problems they choose to solve and the products they decide to build.

Software has always rewarded this way of thinking. Many products that feel obvious today began as ideas that experienced people dismissed. Search engines, online payments, cloud computing, and now AI all followed a similar pattern. At first, the common reaction was that they would never work or that nobody would use them. The people who built them were not ignoring reality. They were questioning whether the limits everyone accepted were actually permanent.

There is another lesson in the history of the Berlin Wall. A physical wall needs guards, maintenance, and constant effort to keep people from crossing it. A mental wall is different. Once enough people believe that something cannot be done, the barrier starts maintaining itself. Nobody has to enforce it anymore because people stop trying.

I think many of us carry walls like that. We inherit them from school, from previous jobs, from experts, or simply from hearing the same advice often enough. Over time these assumptions begin to feel like facts even though nobody remembers where they came from.

Every meaningful product begins by questioning one of those assumptions. Every startup is built on the belief that the world could work differently than it does today. That does not mean every idea succeeds, but it does mean that progress usually starts with someone who is willing to see possibility where others only see limits.

The Berlin Wall eventually disappeared because people stopped believing it would stand forever. That may be the most interesting part of its history. Every wall looks permanent until it no longer is.

The same is true for the walls in our own heads.

Core Concepts & Overview of RedisBrowse | Open-Source Redis Debugging

Ivole32 — Tue, 14 Jul 2026 03:00:00 +0000

Hello and welcome back to another blog post from the QueueForge team. We are excited to introduce our new open-source project in this dedicated post.

While developing our main product, QueueForge, which is heavily based on Redis, we ran into a problem: we couldn't find a tool that allowed us to conveniently inspect and debug Redis Streams. So we decided to build our own solution: RedisBrowse.

RedisBrowse is a lightweight Redis debugging tool designed to inspect Redis data, with a special focus on Redis Streams. In this post, we'd like to give you an overview of the project, its current features, and our plans for the future.

Is it open source?

Absolutely! RedisBrowse is fully open source and licensed under the MIT License. We believe it can become a useful tool for developers around the world.

We chose the MIT License because we want everyone to be able to use, modify, fork, and contribute to the project. Every contribution—whether it's fixing a typo, reporting a bug, or implementing a new feature—helps move RedisBrowse forward.

Current Features

Although RedisBrowse is still in its early stages, it already provides a solid set of features:

Live overview of all Redis keys
CLI configuration for remote hosts, databases, and authentication
Automatic detection of Redis data types
Support for Lists, Streams, Strings, Sets, and Hashes
Instant refresh of the key list
Modern terminal interface with mouse and keyboard support

Roadmap

RedisBrowse is just getting started, and we have plenty of ideas for the future. Some of the features we're planning include:

Creating, editing, and deleting Redis data
Publishing standalone executables in addition to the Python package
Improved navigation and filtering
Support for additional Redis data types and commands
General usability and performance improvements

Of course, this roadmap isn't set in stone. We'd love to hear your ideas and learn which features would make RedisBrowse even more useful.

How to Contribute

Since the source code is freely available on GitHub, everyone is welcome to contribute.

Whether you'd like to fix bugs, improve the documentation, implement new features, or simply suggest ideas, we'd be happy to have you involved. Please make sure to read our Code of Conduct and Contribution Guidelines before submitting a pull request.

Feedback

RedisBrowse is built by developers, for developers. If you've found a bug, have a feature request, or simply want to share your experience, we'd love to hear from you.

Feel free to open an issue, start a discussion, or submit a pull request on GitHub. Every bit of feedback helps us improve RedisBrowse and shape its future.

Happy coding,

The QueueForge Team

Security Monday #3: Two Security Issues Found in ClickMigrate

Ivole32 — Mon, 13 Jul 2026 03:00:00 +0000

A few hours after releasing ClickMigrate as an open source project, we performed an additional security review of the codebase. During that review, we identified two security issues and fixed both of them before continuing development.

Neither issue is likely to affect typical ClickMigrate users, but we believe documenting these findings improves transparency and demonstrates the importance of reviewing even small open source projects from a security perspective.

Issue #1: Path Traversal in the Revision Command

The first issue affected the clickmigrate revision command. Under certain conditions, it was possible to supply a crafted migration name that caused the generated SQL file to be written outside of the configured migrations directory.

The vulnerability required a very specific setup. An attacker would first need to control the migration name supplied to the command, for example through an automated development or CI/CD pipeline that accepted untrusted input. The attacker would not gain permissions beyond those already granted to the user executing ClickMigrate, but arbitrary .sql files could be created anywhere that user had write access.

Although the practical impact is limited, this is still a valid Path Traversal vulnerability and has been addressed. We published a GitHub Security Advisory describing the issue: GHSA-vgf9-9mxx-hq54. We are also evaluating whether the issue should receive a CVE identifier.

The fix was straightforward. We introduced strict validation of migration names, allowing only letters, numbers, hyphens, and underscores. Any other input is rejected before reaching the file creation logic.

The complete fix is available in commit 6b1f2c0.

Issue #2: A Theoretical SQL Injection Scenario

During the same review, we also identified a second issue involving SQL query construction.

Under very specific circumstances, it was technically possible to influence the SQL query through the configured migration table name. However, exploiting this would already require an attacker to control ClickMigrate's configuration or otherwise have the ability to influence the database queries being executed.

Because of these prerequisites, we consider the practical impact to be extremely low. Nevertheless, it was still worth fixing to eliminate unnecessary attack surface.

We addressed the issue using the same approach as before by introducing strict validation. The migration table name now only accepts letters, numbers, hyphens, and underscores, preventing unexpected characters from reaching the SQL query.

The fix can be found in commit 360f703.

Lessons Learned

Neither issue required a complicated fix. Both vulnerabilities were resolved by introducing strict input validation, resulting in only a few lines of additional code.

This serves as a good reminder that security reviews are valuable even for relatively small projects. Looking at code with a security mindset often reveals edge cases that would otherwise go unnoticed.

Not every finding results in a critical vulnerability, but identifying and addressing smaller issues before they become larger problems is an important part of secure software development.

Highlights

Identified and fixed two security issues in ClickMigrate.
Published a GitHub Security Advisory for the Path Traversal vulnerability.
Currently evaluating whether the Path Traversal issue should receive a CVE identifier.
Resolved a theoretical SQL injection scenario with very limited practical impact.
Strengthened input validation across multiple parts of ClickMigrate.

Looking Ahead

We'll continue performing regular security reviews of both QueueForge and our open source projects. Finding issues early is significantly easier than responding to them later.

If you'd like to receive future Security Monday articles, consider subscribing to our newsletter.

See you next Monday,

The QueueForge Security Team

Security Monday #2: Server Security Audits & Integrity Monitoring

Ivole32 — Mon, 06 Jul 2026 03:00:00 +0000

Security Monday #2: Auditing Our Server Infrastructure

Welcome back to Security Monday. Last time we shared how we approached hardening our new server infrastructure. This week we'd like to share some of the progress we've made since then.

Over the past week, we conducted a comprehensive security audit of our servers using Ubuntu Security Guide (USG). The goal was not to achieve a perfect score, but to identify areas where the systems could be improved while keeping them practical for our infrastructure.

After implementing a number of hardening measures, our servers now achieve an audit score of approximately 86%.

While there is still room for improvement, we're satisfied with this result. Most of the remaining recommendations are not practical for our environment because they would either reduce usability or conflict with the way certain services operate. Security always involves balancing protection with operational requirements.

Building an Integrity Monitoring Pipeline

One of the biggest improvements this week was the implementation of a complete file integrity monitoring pipeline based on AIDE (Advanced Intrusion Detection Environment).

The pipeline performs scheduled integrity scans of the operating system and compares the current file state against a trusted baseline. Whenever unexpected changes are detected, an email alert is generated automatically.

We also wanted to ensure that integrity reports themselves cannot easily be lost or modified. After every scan, the generated reports are uploaded to Cloudflare R2 while a second server maintains additional backups of those reports.

Having multiple independent copies of integrity reports gives us additional confidence when investigating changes and provides historical data that can be reviewed whenever necessary.

Continuous Improvements

Infrastructure security is not something that can be completed once and forgotten. New services, updates, and configuration changes all require continuous review.

Our goal is to automate as much of this process as possible while keeping manual reviews as part of our regular security workflow.

Highlights of the Week

Completed a comprehensive security audit using Ubuntu Security Guide (USG).
Improved our audit score to approximately 86%.
Implemented a complete AIDE-based file integrity monitoring pipeline.
Added automatic email alerts for integrity changes.
Stored integrity reports in Cloudflare R2 and on a secondary backup server.

Looking Ahead

Over the coming weeks we'll continue reviewing our infrastructure, improving automation, and further strengthening our monitoring capabilities.

In an upcoming Security Monday article, we'll also take a closer look at several security issues we identified while developing ClickMigrate, how we discovered them, and what we changed to address them.

If you'd like to receive future Security Monday articles, consider subscribing to our newsletter.

See you next Monday,

The QueueForge Security Team

Recap Sunday #5: Open Sourcing ClickMigrate & Strengthening QueueForge

Ivole32 — Sun, 05 Jul 2026 02:00:00 +0000

Welcome to the fifth edition of Recap Sunday, our weekly series where we share what happened behind the scenes at QueueForge during the previous week.

This week we continued developing the QueueForge core queue service while also spending a significant amount of time improving the security and stability of our infrastructure.

We also open sourced another internal developer tool: ClickMigrate.

ClickMigrate is a lightweight migration framework for ClickHouse that uses plain SQL files to manage database schema changes. We originally built it to simplify our own workflow, and after refining it, we decided to release it as an open source project.

As with our other open source projects, we plan to continue improving ClickMigrate over time based on our own needs and community feedback.

Infrastructure & Security

Besides development, we spent a considerable amount of time hardening our servers and reviewing different parts of our infrastructure. Small improvements in this area add up over time and help us build a more secure platform.

We also carried out security testing on ClickMigrate and successfully identified a few smaller security issues. None of them were critical, but they were interesting enough to document and fix before they could become larger problems.

Highlights of the Week

Continued development of the QueueForge core queue service.
Open sourced ClickMigrate.
Continued improving QueueForge's infrastructure.
Performed additional server hardening.
Conducted security testing on ClickMigrate and resolved several smaller issues.

Looking Ahead

Next week we'll continue developing the QueueForge core queue service while also working on the next improvements for ClickMigrate.

We're also preparing two new Security Monday articles. One will cover the security issues we identified in ClickMigrate, how they were discovered, and how they were fixed. Another article will take a closer look at the server hardening measures we've implemented and the reasoning behind them.

If you'd like to receive these articles as soon as they're published, consider subscribing to our newsletter so you don't miss future Security Monday posts and weekly development updates.

See you next week,

The QueueForge Team

Stats Saturday #5: Website Growth, SEO Progress & Development Stats

Ivole32 — Sat, 04 Jul 2026 20:30:00 +0000

Welcome back to another Stats Saturday. Every week, we share our progress, the numbers behind QueueForge, and what we're currently focusing on.

Website Stats

This week was a great one for us in terms of website traffic. Compared to last week, we saw strong growth across most of our website metrics.

Here are this week's website statistics:

35 unique visitors (+105.9%)
41 total visits
65 page views (+91.2%)
1.6 pages per visit
75.6% bounce rate (+28.6%)
Average visit duration: 1 minute and 24 seconds

We're really happy with these numbers. Considering our still relatively small reach, seeing our traffic nearly double compared to last week is very encouraging.

We also noticed a noticeable increase in bot traffic, which we interpret as a sign of increased indexing and crawling activity on our website. This reminded us to review our host header filtering rules that we introduced some time ago. During that review, we removed a few expressions that could have resulted in false positives. We're not sure yet whether this change will have any measurable impact, but it felt like a worthwhile improvement.

Another highlight this week was a significant increase in Google Search impressions. At the same time, our average ranking position dropped, which was a bit concerning at first. However, this is most likely just Google testing our pages for additional search queries, which is a normal part of the indexing process.

Development

Development continued throughout the week, and we committed around 2,700 lines of code. We also open-sourced one of our internal projects, which we're excited to share more about soon.

Productivity

We paid a bit more attention to how we spent our time this week.

We spent approximately 18 hours on TikTok. While that's still more than we'd like, it's an improvement compared to last week and a reminder that building better habits is an ongoing process.

Our goal remains the same: spend less time consuming content and more time building QueueForge.

Other Stats

Lines of code committed: ~2,700
One internal project open sourced
Money spent: €0

Overall, this was one of our best weeks so far. Website traffic increased significantly, Google continues to discover more of our content, and development kept moving forward. We're excited to see what next week brings.

Thanks for following our journey. If you'd like to receive future Stats Saturday updates, consider subscribing to our newsletter.

See you next week,

The QueueForge Team

Recap Sunday #4: Core Development & Open Sourcing RedisBrowse

Ivole32 — Sun, 28 Jun 2026 21:08:16 +0000

Welcome to the fourth edition of Recap Sunday, our weekly series where we share what happened behind the scenes at QueueForge during the previous week.

This week our primary focus was continuing development of the QueueForge core queue service. We spent most of our time improving the foundation of the platform and preparing it for future functionality.

Alongside our work on QueueForge, we also decided to release one of our internal developer tools as an open source project. The tool is called RedisBrowse.

RedisBrowse was originally built to help us inspect Redis keys and debug Redis Streams during development. Having a dedicated tool made it easier to understand queue state and troubleshoot issues while working on QueueForge.

We believe the tool can also be useful for other developers working with Redis, which is why we decided to make it publicly available.

This is only the beginning for RedisBrowse. We plan to continue expanding it with additional functionality, including the ability to modify data directly and other features that simplify working with Redis during development.

Looking beyond RedisBrowse, we also plan to open source more of the internal developer tools we build while developing QueueForge. Many of these tools solve common development problems, and we hope they can be useful to the wider developer community as well.

Highlights of the Week

Continued development of the QueueForge core queue service.
Open sourced our internal developer tool, RedisBrowse.
Released a tool for inspecting Redis keys and Redis Streams.
Began planning additional functionality for RedisBrowse.
Started preparing more internal developer tools for future open source releases.

Looking Ahead

Next week we plan to continue development of the QueueForge core queue service while also making further improvements to RedisBrowse based on our own development workflow.

We also expect to continue identifying internal tools that could be useful as open source projects and share them with the community over time.

See you next week,

The QueueForge Team

Stats Saturday #4: Website Traffic, SEO Progress & Development Stats

Ivole32 — Sat, 27 Jun 2026 21:51:53 +0000

Welcome back to another Stats Saturday. Every week, we share our progress, the numbers behind QueueForge, and what we're currently focusing on.

Website Stats

This week was relatively stable compared to the previous one. While we didn't experience a major traffic spike, we're happy to see consistent growth in the areas that matter most for the long term.

Here are this week's website statistics:

18 unique visitors (+28.6%)
19 total visits
37 page views (+32.1%)
1.9 pages per visit
57.9% bounce rate (-13.2%)
Average visit duration: 37 seconds

The biggest highlight continues to be SEO. After fixing the indexing issue a few weeks ago, Google is steadily discovering more of our content.

Google Search Console still shows relatively small numbers, but the trend keeps moving in the right direction. Over the last few months we've received 20 clicks from Google Search with 549 impressions , a 3.6% click-through rate , and an average ranking position of 17.3.

Those numbers may still look modest, but for a young project they're a great sign. SEO takes time, and seeing Google gradually send more visitors confirms that the work we've been putting into our content is starting to pay off.

Development

Development continued throughout the week with bug fixes, improvements, and preparations for upcoming features. We also open-sourced one of our internal projects to give something back to the developer community.

We'll publish a dedicated blog post soon explaining why we decided to open source it, what it does, and how you can use it yourself. If you don't want to miss that article, make sure to subscribe to our newsletter.

Productivity

This week wasn't our best when it came to screen time.

We spent approximately 25 hours on TikTok and another 6 hours on Instagram. That's significantly more than we'd like and a noticeable step backwards compared to previous weeks.

While it's frustrating to see those numbers increase again, we believe it's important to be transparent about both progress and setbacks. Building better habits isn't a straight line, and this week reminded us that consistency is something we still need to improve.

Our goal for next week is simple: spend less time scrolling and more time building QueueForge.

Other Stats

Lines of code committed: ~1,145
One internal project open sourced
Money spent: €0

Overall, we're happy with the direction QueueForge is moving in. SEO continues to improve, we're shipping new code every week, and we're excited to share more details about our open-source project soon.

Thanks for following our journey. If you'd like to receive future Stats Saturday updates and be the first to read about our upcoming open-source release, consider subscribing to our newsletter.

Recap Sunday #3: Infrastructure, Progress & Product Decisions

Ivole32 — Sun, 21 Jun 2026 19:48:36 +0000

Welcome to the third edition of Recap Sunday, our weekly series where we share what happened behind the scenes at QueueForge during the previous week.

This week was a little different from the last few. While we continued working on QueueForge, much of our focus was directed toward improving the foundation that the platform runs on.

During the first part of the week, we spent a significant amount of time migrating QueueForge to new servers. Infrastructure work is not always the most visible part of building a product, but it is essential for ensuring long-term reliability, scalability, and performance.

Since this migration came with a number of challenges, we decided to share some of the lessons we learned along the way. You can read the full breakdown here.

Beyond the migration, development of the core QueueForge product continued throughout the week. Rather than focusing exclusively on new features, we spent time evaluating different approaches, refining existing ideas, and discussing the overall direction of the platform.

Several important design and product decisions were made during these discussions. These decisions will influence how future features are implemented and help us keep QueueForge focused on solving real operational challenges for teams working with message queues.

Overall, this week was about strengthening both the technical foundation and the long-term vision of QueueForge.

Highlights of the Week

Migrated QueueForge infrastructure to new servers.
Improved the platform's foundation for future growth.
Continued development of the core product.
Made several important design and product decisions.
Prepared groundwork for future improvements and features.

Looking Ahead

Next week we plan to continue building on the work completed during the migration and begin turning some of this week's decisions into actual implementation work.

With much of the infrastructure work completed, we can spend more time focusing on the user experience and the next stage of QueueForge's development.

We are excited about the progress being made and look forward to sharing more updates soon.

See you next week,

The QueueForge Team

Stats Saturday #3: Website Traffic, Productivity & Development Stats

Ivole32 — Sat, 20 Jun 2026 17:21:44 +0000

Welcome to the next edition of Stats Saturday. Every week, we share a few numbers from our work, the habits that help us make progress, and the things that slowed us down.

Website Stats

This week's stats were not significantly better than the previous weeks. However, we're starting to see a clear direction for our marketing efforts, especially when it comes to SEO.

Here are the results:

Unique visitors decreased by 6%
Bounce rate increased by 28%
Average visit duration increased by 115%

One positive development is that we fixed a technical issue that prevented some of our blog posts from being indexed correctly by Google. Since deploying the fix, we're starting to see encouraging signs in Google Search Console and believe this could have a positive impact on our traffic over the coming weeks.

While the overall numbers are still below where we want them to be, seeing an upward trend in search visibility is motivating and confirms that our SEO efforts are beginning to pay off.

What about our TikTok challenge?

TikTok remains one of our biggest productivity challenges, but we're continuing to make progress.

This week, we spent 16 hours on TikTok. While that's still much more than we'd like, it's another improvement compared to previous weeks and brings us closer to our goal.

Reducing our screen time is a gradual process, but the trend is moving in the right direction. Our goal for next week is to continue building on this progress and get even closer to the target we've set for ourselves.

Other Stats

Besides traffic and productivity metrics, here are a few additional numbers from this week:

Lines of code committed: ~1160
Money spent: €0
Purchases considered but not made: €0

We'll share another update next Saturday.

Website Downtime in the Past Days

Ivole32 — Wed, 17 Jun 2026 17:52:01 +0000

Today we want to talk about the downtime and errors some users may have experienced while visiting our marketing website during the past two days. We would like to explain what happened, how we fixed it, and what we learned from the experience.

During the last two days, we migrated our marketing website to our new Hetzner servers, as announced in Future Friday #2: New Servers. While carrying out the migration, we made a few mistakes that resulted in temporary issues on the website.

The migration was divided into two parts. First, we set up the new infrastructure. Second, we migrated all required data from the old database. The main problems occurred during the infrastructure setup.

We encountered issues with communication between Docker containers. Unfortunately, it took longer than expected to identify the cause because we were troubleshooting late at night. After investigating several possibilities, we discovered that the problem was a small configuration mistake.

A missing allowed host entry caused backend API requests to fail whenever the frontend attempted to communicate with the backend. While the fix itself was simple, finding the exact source of the problem was difficult because the relevant configuration was spread across multiple files and locations.

We also ran into a few smaller issues. One example was an incorrect file permission that prevented the QueueForge logo from loading correctly. There were also several other minor configuration errors that needed to be resolved during the migration process.

Although the marketing website is not our main product, we take reliability seriously. Every issue is an opportunity to improve our processes and infrastructure. We want to learn these lessons now so we can provide a stable and reliable experience when we launch our first product.

What We Learned

Test infrastructure changes in a dedicated environment before deployment.
Keep configuration files organized and well documented.
Create deployment checklists for recurring tasks.
Verify file permissions as part of every migration.
Improve monitoring and error reporting to detect issues faster.

While no migration goes perfectly, every challenge helps us improve. We appreciate your patience and understanding while we continue building a reliable platform.

The QueueForge Team

QueueForge Is Taking a Break

Ivole32 — Tue, 09 Jun 2026 14:00:00 +0000

This week will be a little different from usual.

The QueueForge team is taking a short break and spending some time away from development. Over the past months, a significant amount of time has gone into building the platform, planning new features, improving infrastructure, and preparing for future growth.

While we enjoy working on QueueForge, we also believe that taking time off is important for maintaining a healthy balance and returning with fresh ideas and motivation.

Because of this, regular development activities will be paused for most of the week. New features, larger infrastructure projects, and long term planning tasks will continue once the team returns.

That does not mean QueueForge is completely unattended. We will continue monitoring our systems and will remain available for important support requests.

In addition, if critical bugs, stability issues, or security related problems are identified, we will continue to deploy patches when necessary. Keeping the platform reliable remains a priority, even during periods where active development is reduced.

This short break also gives us an opportunity to step back and review our plans for the coming months. Sometimes taking a pause is the best way to return with a clearer perspective on what should come next.

We appreciate everyone who continues to follow our journey and support QueueForge while we build the platform.

What Will Continue This Week

Monitoring of platform infrastructure and services.
Handling important support requests.
Deploying critical bug fixes when required.
Deploying security related patches when necessary.
Planning improvements for after the break.

Looking Ahead

Regular development is expected to resume next week. Once we are back, we will continue working on infrastructure improvements, platform development, and the projects currently on our roadmap.

Until then, QueueForge will remain online, monitored, and maintained while the team takes a short break.

See you soon,

The QueueForge Team