Notes RSS feed

Зачем я переношу проекты на субдомены и как настроил 301-редирект

Ведение блога — не моя сильная сторона, но идея иметь единую площадку для аккумуляции всего, что я публикую в интернете, мне всегда нравилась. Изначально для этих целей я завел отдельный домен refdev.ru. Однако спустя полгода я пришел к выводу, что это излишне. Гораздо рациональнее располагать новые проекты на субдоменах основного хаба https://assetsfirst.ru/. Такой подход проще в поддержке и логичнее с финансовой точки зрения: новый проект — новый субдомен, а если проект взлетает, всегда можно раскошелиться на отдельный домен за счет его же выручки.

Настраиваем 301-редирект

Поскольку refdev.ru уже проиндексирован поисковиками, а домен еще оплачен на полгода вперед, я решил настроить постоянный (301) редирект со старого домена на новый. Это позволит передать накопленный вес страниц и не потерять читателей. Мой хостинг-провайдер использует Apache, где такое перенаправление легко реализуется через файл .htaccess.

После небольшого исследования я остановился на этом решении:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^refdev\.ru$ [NC,OR]
RewriteCond %{HTTP_HOST} ^www\.refdev\.ru$ [NC]
RewriteRule ^(.*)$ https://blog.assetsfirst.ru/$1 [R=301,L]
</IfModule>

Что делает этот код?

RewriteEngine On — активирует механизм перезаписи URL.

RewriteCond — проверяет условие. В нашем случае, совпадает ли имя запрашиваемого домена с refdev.ru (с флагом NC для игнорирования регистра) ИЛИ (директива OR) с www.refdev.ru.

RewriteRule — если условие выполнено, правило перенаправляет (R=301) любой запрос (^(.*)$) на тот же путь на новом домене https://blog.assetsfirst.ru/$1. Флаг L означает, что это последнее правило, которое должно обрабатываться.

Важные моменты:

• Редирект сработает для любой страницы старого сайта (например, refdev.ru/post-1 станет blog.assetsfirst.ru/post-1).
• После внесения изменений стоит проверить редирект с помощью онлайн-сервисов или браузера в режиме инкогнито.

Итог: теперь весь трафик со старого домена плавно и правильно перетекает на новый, а я могу спокойно развивать свои проекты под единым крылом assetsfirst.ru. Надеюсь, мой скромный опыт окажется полезным и для вас.

“If you’re not embarrassed by the first version of your product, you’ve launched too late.”

Reid Hoffman’s legendary quote hit me like a ton of bricks—unfortunately, a little too late. 😅

There’s a special kind of demoralization that creeps in when you’re building, building, building… and still have nothing to show for it. It’s the silent killer of side projects, the motivation drain that leaves brilliant ideas gathering digital dust.

Sound familiar?

As engineers, we’re wired for quality. We have this “sixth sense”—an almost compulsive need to ship polished, feature-rich, bug-free masterpieces. And because of this noble pursuit of perfection, we often refuse to launch, paralyzed by thoughts like:

• “It’s missing too many features…”
• “What if users hate it?”
• “What if it breaks?”

But here’s the liberating truth I learned the hard way:

Nobody cares about your app when it doesn’t exist. And that’s your superpower.

The Cost of Waiting for “Perfect”

I once fell into the “ideal solution” trap—tweaking, refining, over-engineering—and it cost me almost a year before I launched. A year of lost feedback, momentum, and opportunity. 🤦‍♂️

The lesson? Speed beats perfection.

• ✅ Done fuels motivation. Small wins keep you excited.
• ✅ Feedback > Assumptions. Real users reveal what actually matters.
• ✅ Progress compounds. A working v1 today beats a “perfect” v1 that never ships.

This Applies Everywhere

Even in coding interviews, a brute-force solution that works is better than freezing for the “optimal” one. Progress > polish.

My New Rule: Launch in 1-2 Weeks

Now, I force myself to ship fast—even if it’s imperfect. The faster you launch, the faster you learn (and the sooner success finds you).

What about you?

• Do you struggle with over-polishing before launching?
• What’s the smallest version of your project you could ship this week?

Drop your thoughts below—I’d love to hear your take! 👇

The Java ecosystem is buzzing with the potential of Coordinated Restore at Checkpoint (CRaC) in Spring Boot. If implemented effectively, CRaC could revolutionize how we handle JVM startup times and resource efficiency—traditionally areas where frameworks like Micronaut and Quarkus have shined. CRaC allows applications to save their state at a checkpoint and restore it instantly, bypassing the slow startup and warm-up phases. Imagine deploying Spring Boot apps that start in milliseconds, rivaling the performance of native-image-based frameworks. This could make the need for Micronaut or Quarkus redundant for many use cases.

Why is this a big deal?

✅ Faster startups: Near-instant application boot times. ✅ Resource efficiency: Reduced memory and CPU overhead. ✅ Seamless integration: Leverage Spring’s rich ecosystem without compromise. While CRaC is still evolving, its potential to level the playing field is undeniable. Could this be the end of the “framework wars”? Only time will tell, but one thing’s clear: Spring Boot is not backing down. What’s your take? Will CRaC make Micronaut and Quarkus obsolete, or will they evolve to stay ahead? Let’s discuss! 💬