1с:Битрикс не кликабельные ссылки в письме на согласие о получении рассылок
Возможно кому то сократит время.
ссылки в письме не кликабельны, так как не имеют на домена, ни скрипта который их должен обрабатывать. Все из за отсутствия файла: (корень)pub/mail/consent.php
<?
include_once($_SERVER['DOCUMENT_ROOT'].'/bitrix/modules/main/include/urlrewrite.php');
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/header.php");
$APPLICATION->SetTitle("Согласие на рассылки");
?>
<div class="maxwidth-theme">
<div class="wrapper_inner">
<div class="container_inner">
<?php
$APPLICATION->IncludeComponent(
"bitrix:sender.consent",
".default",
array()
);
?>
</div>
</div>
</div>
<?require($_SERVER["DOCUMENT_ROOT"]."/bitrix/footer.php");?>
Почему паттерны GoF наконец начали укладываться у меня в голове только с практикой
С паттернами GoF у меня долго была одна и та же проблема: читаешь описание, вроде все логично, примеры тоже понятны, а потом открываешь реальный код — и все это знание куда-то испаряется.
Особенно тяжело было с паттернами, которые на бумаге выглядят почти очевидно, а вживую постоянно путаются между собой.
Я пришел в .NET из 1С, и у меня с этим был затык. Книги и статьи давали теорию, но не давали ощущения, что ты действительно начал узнавать эти вещи в коде.
В какой-то момент я поменял подход. Вместо того чтобы просто читать, стал учиться через короткие практические задачи:
- посмотреть на код и понять, какой здесь паттерн;
- попробовать объяснить, почему это именно он;
- сравнить с похожими вариантами, с которыми его легко перепутать;
- разобрать, где решение нормальное, а где уже есть запахи.
Позже подключил ИИ как помощника именно для такой практики. Не чтобы он просто писал код за меня, а чтобы подкидывал задания, задавал новые вариации и помогал разбирать, где моя логика хромает. И вот тогда паттерны начали восприниматься не как абстрактная теория, а как повторяющиеся ходы, которые реально можно замечать в проектировании.
Для себя я из этого вынес простую мысль: паттерны нормально заходят не через чтение определений, а через многократное распознавание, сравнение и разбор.
В итоге я даже собрал для себя небольшой тренажерный формат, чтобы гонять такие упражнения регулярно. Не как “энциклопедию паттернов”, а именно как практику на узнавание, различение и разбор решений.
Вообще интересно, у кого как это было.
У вас паттерны тоже начали нормально укладываться только через практику?
Или, наоборот, книги по паттернам GoF сразу заходят без боли?
Панель разработчика или как мы отслеживаем результаты
Сразу предупреждаем: да, это пост про инди-игру.
И да, мы знаем, что на Пикабу у многих рефлекс — захейтить любую инди-разработку просто по факту её существования 😄
Но вместо «смотрите наш трейлер» мы хотим показать кое-что реально полезное: как мы отслеживаем результаты разработки, финансы, вклад команды и будущие роялти — и почему без этого в маленькой студии начинается хаос.
Проблема: инди-разработка — это не романтика, а бухгалтерия и выживание
Наша команда небольшая, но в ней есть несколько человек, которые имеют право претендовать на Royalty с продаж нашей игры Medieval Contrast.
И тут появляется главный вопрос, который убивает большинство инди-проектов ещё до релиза:
Кто сколько вложил денег?
Кто сколько реально работал?
Кто сколько должен получить с продаж?
Потому что в реальности один человек может вкладывать деньги, второй — вкладывать сотни часов работы, а третий — помогать периодически. И если это не фиксировать, то после выхода игры начинается классическое:
«Я вкладывал больше»
«Я делал больше»
«Я тащил проект»
«Я вообще тогда работал бесплатно»
Наше решение: сделать динамическую систему расчёта долей (роялти) как в стартапах
Мы решили подойти к этому не “по дружбе”, а по-взрослому.
Сделали систему, которая рассчитывает процент доли каждого участника, учитывая:
финансовые вложения (кто платил за что и сколько)
потраченные человеко-часы (кто сколько работал)
итоговую долю в проекте (динамическая ставка)
будущий доход с продаж (Royalty)
То есть примерно как в стартапах: один вкладывает деньги, другой делает продукт — а итоговая доля рассчитывается справедливо, а не «на глаз».
Название дали простое: Studio
Мы не стали выдумывать пафосные названия и назвали систему просто — Studio.
Изначальная цель была максимально прагматичная:
учитывать расходы по проекту
фиксировать, кто и на что вкладывает деньги
учитывать часы работы команды
рассчитывать доли и будущие выплаты
отображать статус игры, прогресс, отзывы в Steam и т.д.
Почему на чистом PHP?
Да, можно было сделать всё на Laravel, Symfony, Node.js или вообще на микросервисах.
Но мы выбрали путь попроще:
чистый PHP + MySQL, потому что:
этого достаточно для такой системы
разработка быстрее и дешевле
поддержку можно вести без отдельного backend-разработчика
проект не превращается в «платформу ради платформы»
Результат: разработка и контроль стали в разы проще
И вот тут самое интересное: мы реально почувствовали, что проект перестал быть «на энтузиазме» и стал управляемым.
Стало проще:
видеть вклад каждого
понимать, где горит по финансам
оценивать, кто сколько реально сделал
планировать разработку и бюджет
Следующим шагом мы начали делать то, что обычно подключают через сторонние сервисы — но нам захотелось встроить это в Studio.
Добавили мониторинг посещений официального сайта игры:
учёт всех визитов
проверка уникальности (visit_key, ip_hash и т.д.)
отслеживание UTM-меток
фиксация источников перехода (Яндекс, Google, прямые заходы и т.п.)
корректное определение реферера
То есть теперь мы видим не только разработку, но и то, как аудитория реально реагирует на проект.
Если пост зайдёт — покажем, как всё устроено внутри: структура базы, логика уникальности, расчёт долей, интерфейс и какие выводы мы сделали по трафику.
Далее мы планируем привязать к кабинету число продаж, ключей и прочее, что можно интегрировать через API Steamworks. Так же планируем добавить различные заметки, план задач со статусами и прочее, что упростит и улучшит работу в рамках собственной системы в одном месте, а не с использованием нескольких других сервисов.
Встречное предложение на собеседовании
Вообще рекрутинговые агентства часто примерно так и работают: за закрытие вакансии берут 1-2 оклада (платит их компания, а не сотрудник), а в случае, если не прошёл испытательный срок, то бесплатно находят замену.
Другие мои посты про необычных кандидатов и собеседования:
❤️ Телеграм-канал / 🤝 Канал в Сетке
Халяльная вакансия для программиста
Никогда не был свидетелем халяльной истерии...
Но кажется оно добралась уже до разработки.
Что дальше? Халяльные деньги? Халяльные услуги?
Ответ на пост «Зумеры добрались до тендерных площадок»2
Мы как-то поддерживали портал местной областной администрации - порядка 200+ сайтов на Windows. Всё, в принципе, было настроено, так что проектная стоимость была определена в районе 400-500к в год. Сумма большая, так что запустили через тендер. Ну, поставил автобиддинг с точкой отсечения в 300к, думаю - если кто-то ниже упадёт, хер с ним, пускай сам ебётся за такие деньги. Захожу через полчаса после завершения торгов - в районе 50 ставок, выигрышная, кажется, 46к. 46 000 рублей за год обслуживания! И там ещё надо гарантийный взнос внести сначала, перенести всё к себе на площадку, настроить, изучить и поддерживать! Какой-то ИП то-ли из Йошкар-Олы, то-ли из другой жопы мира. Ну, думаю, безумству храбрых поём мы песню!
Через пару недель администрация (а мы были с ней в хороших вполне отношениях) попросила поучавствовать и проконсультировать ребят. Ну, ОК, пусть пишут на email, даже интересно послушать что же могло пойти не так. Оказалось - парни купили самый дешманский хостинг на linux/php, развернули там наш архив проекта на windows/asp.net и спрашивают а чо это он не работает?! Для далёких людей - это примерно как в бензиновый двигатель дизеля ливануть и удивляться что это он не запускается...
В общем, итог - ип отказался от договора и улетел в чёрный список, администрация резко вышла на переторговку с уточнённой документацией, мы месяц поддерживали проект "за спасибо".






