Сергей Шлоков

Сергей Шлоков

Был в сети 06 ноября 2025, 19:54
Заказы не принимаю
Ну считаем дальше. 2 инвестора вложили по 25 тыс. в этот продукт. В магазине собственник один. И все деньги отправляются ему. И он должен поделиться со вторым (а то ещё и с третьим/четвертым и т.д.). И про программиста не забыть. Риск обмана и надежда на совесть.
Дальше. В продажу поставили за 1 тыс. руб. Т.е. за минусом комиссии инвесторы получат 700 руб. Из них 500 они должны отдать программисту за поддержку. Остаётся 200 р. Таким образом, прибыль инвесторы будут получать только с 251 продажи. А программист получает львиную долю — с каждой продажи по 500 р. И к тому моменту, как инвесторы получат первую прибыль, он к своим 50 тыс. дополнительно заработает ещё 125 тыс. При этом программист может вообще не оказывать никаких услуг, ну или в единичных случаях. А получает он с каждой продажи. В общем, самая проигрышная сторона — это инвестор.
А дальше встанет вопрос о развитии продукта — прикрутить какую-нибудь супер фичу. Опять же нужно собрать деньги. Один из инвесторов откажется вкладываться. Нашелся другой. И какие доли теперь будут у инвесторов? У отказавшегося доля может упасть так сильно, что он годами будет возвращать инвестиции. На что изначально он не подписывался. И это только математика. А если ещё юридические вопросы копнуть, то вообще расстроишься.

Перед тем как предлагать идею, её нужно сначала проработать, погрузиться в неё. Почитай как найти инвестора для стартапа, чтобы понимать вопрос. Да и вообще, тема инвестиций в России ещё не развита. Это в Америке люди готовы вкладываться. У них уже на генетическом уровне — «Вложусь, вдруг получится». У них даже домохозяйки вкладываются в фондовый рынок. У нас другой подход — «Не вложусь, вдруг не получится». Так что данный вопрос пока не своевременный.
Остается 70%. Пример: где 50% мастер, 20% инвесторы.
Получается, что мастер будет работать за гипотетическую прибыль в будущем и таким образом становится инвестором. Думаю, мастер захочет деньги все и сразу. И эти деньги выкладывают инвесторы.
Дальше. Продукт получится чей? Автора идеи или инвесторов? Соответственно как инвесторы будут возвращать деньги? Как его дальше сопровождать и развивать? И вопросов ещё много.

Начать статью можно было так — «Жили-были ...». А закончить — «И жили они долго и счастливо». Чтоб все понимали, что это сказка про идеальный мир с джентельменами и альтруистами. :))
В новой версии будет. А ещё будет специальный класс, который позволяет работать с цепочками
// Вызываем функцию без аргументов и используем цепочки
email()
	->to('user1@mail.ru')
	->toUser(5)
	->cc('user2@mail.ru')
	->subject('Тема письма')
	->content('тело сообщения')
	->from('Администратор')
	->replyTo('admin@gmail.com')
	->attach('file1.jpg')
	->attach('file2.png')
	->send();
Ок. Пусть будет
Спасибо!
но нужно предусмотреть возможность отключения.
readOnly=`1`
А как быть с заданием прав на календарь?
Использовать сниппет-обёртку типа такого
[[!wrapCalendar? 
	&allowGroups=`admin,secretaries` 
	&teacher=`5` // id учителя
	&calendars=`1` // id календаря
	&readOnly=`1` // Редактирование запрещено
]]
А внутри проверять группы и учителя и выставлять readOnly в 0 для них.
Не думаю, что человек в здравом уме будет вести свой личный календарь на каком-то левом сайте
А вариант с правым сайтом не рассматривается? Бесит уже этот американский образ мышления — мне это не нужно, значит это никому не нужно.
На самом деле у сниппетов одна очень важная отличительная особенность — это параметры по умолчанию. Поэтому сниппеты можно вызвать без параметров. А вот вызывать файловый «сниппет» нужно всегда с параметрами. В остальном различия несущественные. Ну и понятно, что кэшировать файл нет необходимости.
Кстати, сниппеты кэшируются в 2 директории — core/cache/includes/elements/modsnippet/ и core/cache/scripts/elements/modsnippet/.
Обновил библиотеку. В основном доработки коснулись менеджера коллекции — добавлено несколько методов и возможность использовать callback функции.
// Получение списка с заголовками с использованием callback функции.
return resources()->where(['id:IN'=>children(5)])->each(function($resource, $idx){ return "<li>{$idx}. ".$resource['pagetitle']."</li>";});
// Получение массива заголовков дочерних элементов ресурса 5 с использованием UNION.
$array = resources()
            ->where(['id:IN'=>children(5)])
            ->union('select pagetitle from ' . table_name('modResource') . ' WHERE id = 1')
            ->union(['pagetitle'=>'New pagetitle'])
            ->get('pagetitle');
// Получаем всех пользователей группы "Managers"
$usersArray = users()->members('Managers')->toArray();
Ну если контент-манагер не в состоянии поменять местами строчки в шаблоне и не в состоянии освоить компонент Structures, то наверно ты прав. Готов вместо такого менеджера порекомендовать своего пятилетнего сына. Недорого. :)
Я в своё время думал про такое, но так и не смог выделить все преимущества, чтобы заставить пользователей отказаться от использования шаблона
<head>
...
</head>
<body>
	[[$header]]
	[[$mainMenu]]
	[[$gallery]]
	[[$content]]
	[[$footer]]
</body>
Только лишние запросы в БД. А вариант с шаблоном даёт большую гибкость, особенно с fenom.

П.С. Ну и ещё есть дополнения типа Structures для блочного редактирования.