Защита от пиратства

[enotit]

Ну тут по одному Клифорду не сориентируешься, много кто их развертывает постоянно, мне ток за месяц от 2-5 челов пишут со своими "типо проблемами", хотя я не где не свечусь если что к клифорду отправляю, учитывая что я много подробных мануалов для таких создал.
Найт наверняка ещё развертывает, всеми известный якудза - тоже имеет спрос

Да это так, это чистый - самый адекватный в этой связи (ясные условия, я всегда тригерю его, кстати, он там жив? xD нираз не ответил)

 

[Reys]

Да это так, это чистый - самый адекватный в этой связи (ясные условия, я всегда тригерю его, кстати, он там жив? xD нираз не ответил)

Жив, когда к нему отправляю людей, и пишу отвечает, ставит им

 

[nerd]

Если кто-то опубликует скриншоты проекта и захочется сделать 1 в 1, но с 0 это тоже пиратство?

Вот это авторское право такое себе, торгаши никогда не правили и править не будут этой планетой. Не хочешь, чтобы пиратили и копировали, не показывай никому, нигде не публикуй, не делись и не продавай, храни локально)

Вон редагу слили и она стала популярнее всех сборок вместе взятых. Каждый разраб здесь уже поошивался. И с маджестиков и с гт5рп и с радмира, кого здесь только не было.

Лучше когда делишься и на гитхаб публикуешь. Больше людей узнает и все будут знать откуда это взято и кто сделал. Тупо вшивай что-нибудь в свои проекты или прямо пиши что указывайте меня или не копируйте пожалуйста, а то в суд подам.

 

[Inoi]

Раз уж кстати об этом пошла речь, че то есть настроение высрать ещё лонгрид

Я заранее извиняюсь, я всё таки как программист - самоучка, и хорошему проектированию всё ещё учусь постоянно, и до сих пор я вообще нихуя не знаю.
Но я попробую пояснить так, как могу.
Говорят, когда че то объясняешь - начинаешь понимать лучше.

Я просто пару раз в приступе какой-то шизофрении задумывался о том, чтобы написать какой-то паблик сервер с нуля, и в целом просто выложить его бесплатно - просто ради тренировки и каких-то новых знаний. Идея эта слава богу пошла по пизде, потому что то нейротянки, то теперь игры в веб аппках в телеграмме, то зовут менеджером куда-то и чужой код чекать приходится, но.

Но когда я о какой-то структуре думал, я тоже задумывался о том, что какую-то его часть можно сделать полностью закрытым, ну скомпилированной дллкой, которую ты подгружаешь в проект.
И собственно почему бы и нет?

А как какать?

Введение в лонгрид

В рейдже как и во всех таких паблик штуках, которые постоянно пишутся разработчиками-любителями, всё крайне хуёво с пониманием того, что вообще такое программирование на каком-то более менее адекватном уровне.
На базовом, хуёвом уровне, программирование - это просто написание кода, чтобы что-то, что ты написал - работало. Работало так, как задумано.
На 85 уровне разработчика - важны долговечность, понятность и масштабируемость кода.
И это на самом деле чуть сложнее, чем звучит.

Чтобы этого достичь - "чтобы работало" недостаточно. Это - хуёвый подход, который детектит зародыш разработчика.
Ты должен быть уверен в том, что код легко поддерживать. И это ну, не просто комментарии - это читаемость кода вообще без комментариев, на самом деле.
Гарантировать, то что изменения в любой одной части кода - ничего не сломают никогда в другой.
Ну и понимать, что такое принцип единственной ответственности и вообще весь солид, например.
"Эта часть" твоего кода - вообще не должна нихуя знать про "вот ту" - например класс Player должен отвечать только за данные игрока, а не за то, как они сохраняются в базе данных.
Высокоуровневые модули не должны зависеть от низкоуровневых. Оба они должны зависеть только от абстракций.
Например, бизнес-логика должна использовать интерфейс для работы с БД, а не напрямую обращаться к образной MySqlConnection.
Ведь завтра ты можешь захотеть переехать на EF - и тогда при правильном раскладе ты затронешь ровно 0 строчек старого кода, просто дописав новую реализацию интерфейса.
(пример с еф на самом деле хуёвый, но похуй)

Интуитивно совсем простой пример реализации такой истории, просто для попробовать - можно реализовать например интерфейсами или абстрактными классами.
Сначала ты пишешь себе консольное приложение, любое, заканчиваешь его, а потом решаешь переписать его на винформы. (ну например)
И когда ты первый раз после базового уровня разработки сюда попадаешь - ты такой "ага, ебать, теперь мне переписывать 75% моего кода со всеми зависимостями, заебись".
И если в этот момент возникает мысль - а можно ли блять писать код так, чтобы ему было не важно, где будет выход - в консоли, в винформах, на фтп сервере блять - то поздравляю, ты буквально в этот момент начинаешь во что-то окукливаться из личинки разработчика.

В этот момент ты задумываешься про дизайн своего кода. (Если ты не долбоёб) Когда есть несколько слоёв никак не зависящей друг от друга логики - ввода-вывода например, презентации данных и бизнес-логики приложения.
И начинаешь понимать, насколько важна архитектура.


Ты нахуй этот тут пишеш слыш

Дальше, неизменно следующим шагом будет собственно проектирование той самой архитектуры.
У код-дизайна есть буквально основы, которые описаны уже в сотнях книг, наверное, например слоистая архитектура.

* пока я в этом месте два часа говорил с человеком в дискордике, появилась ещё пара постов выше, ну ничо, не отвлекаемся *

Че вообще такое нахуй слои?

Ну начнём с того что я никогда не видел вообще хоть сколько-нибудь грамотного подхода к архитектуре ни в одном жта проекте.
Даже к разделению солюшена на проекты с хоть КАКИМ ТО БЛЯТЬ подобием - такое ощущение что у коммьюнити врожденное отвращение.
Ограничимся давайте блять CORE и CLIENT которые один от другого зависят, вот и всё, вот и заебись.

Ладно

Это абстрактные понятия, которые фактически как именно код - не то чтобы существуют, это вроде концепции.
Ну разве что как разные проекты внутри решения (хотя никто не мешает тебе связать их без какой-либо слоистой ответственности вообще, если ты дурачок).
Обычно они делятся на концепты:

Доменного слоя - каркаса с описанием объектов (например Player, Vehicle, House) с описанием базовых правил-проверок вроде проверок отрицательности денег у игрока. Буквально база, каркас. Это "где хранить", если можно так выразиться.

Доменной логики - то, что происходит внутри доменного слоя. Правила, сценарии - например "аренда машины" там, или "покупка дома". Это "что делать".
Это не отдельный типа "слой", на самом деле, это часть доменного слоя, но тем не менее, для понимания проще выделять.
Доменному слою похуй на всё остальное, ему плевать на формат, базы данных и взаимодействие с его данными и кодом.
Он существует единолично и комплексно сам по себе.
Ты буквально пишешь эту часть так - что её можно вытащить и использовать в вообще другой игре.

Бизнес-логики - (связывание доменных объектов с реализующими их сценариями - проверка баланса игрока при покупке дома например, процесс передачи дома или тачки там, списания бабок) Например если чел купил дом - бизнес логика распоряжается, что нужно вызывать уведомления, писать что то в бд и отправить админу в личку сообщение что ты читак, потому что домов на сервере нет, как нам подсказал доменный слой.

Бизнес логика знает о доменном слое, она содержит правила и сценарии по работе с ним, она использует репозиторий (например) инфраструктуры, о наличии которой - тоже в курсе, но при этом понятия не имеет как именно работает инфраструктура и в каком виде и где хранит на самом деле описанные в домене объекты.
Например, бизнес-логика может вызвать Save(player), но она не знает, как это реализовано - через скуль, носкуль, да хоть через тхт файлики.

Ну и инфраструктурный слой - это всё наше взаимодействие с чем-то вовне. Работа с апишкой какой-нибудь, базами данных, файлами - что там ещё может в воспалённую голову прийти. Инфраструктура - предоставляет репозитории, с которыми работает бизнес-логика. Бизнес логика - знает только о реализациях интерфейсов, описанных в инфраструктуре.
Т.е. бизнес-логика юзает какую нибудь реализацию интерфейса IPlayerRepository, которая описана как PlayerRepository - не имея ни малейшего понятия о том, что эта реализация использует DbContext, например. Этот слой нихуя не знает о бизнес-логике, ему похуй. Но знает о доменном слое, потому что работает с его сущностями.

• Доменный слой — "где хранить".
• Доменная логика — "что делать".
• Бизнес-логика — "как связать всё вместе".
• Инфраструктура — "как делать" на уровне технической реализации.

Очень интересно но нахуя мне эта информация

Да очень просто на самом деле - когда ты правильно проектируешь, тебе очень легко понять, какие части изолированной логики ты можешь легко держать в скомпилированном виде, например.

Ну например, ты можешь вообще в своём проекте написать инфраструктурный слой, который будет реализовывать все технические детали - как взаимодействие с бдшкой так и вообще скроет под своим капотом всё взаимодействие с рейдж-апи и даже с вызовами цефок, например.
Твоя бизнес-логика в результате будет работать с каким-то новым твоим IRageApi (например), не имея ни малейшего понятия о том, как они реализованы.
Т.е. пользователь сможет буквально писать свои новые правила и сценарии - но уже с твоим "апи".
Ты полностью скрываешь инфраструктуру (что по мне звучит довольно логично), оставляя для пользователя только твои, новые точки взаимодействия с ней.
По сути ты предоставляешь готовый инструмент для работы с апишкой, обёртку.

Ну и готовые доменный слой с бизнес-логикой, которая работает с твоей инфраструктурой, и будет работать с новыми своими кусочками.
Ты убираешь сложность - но оставляешь гибкость.

Ещё вариант - компилировать бизнес-логику, тем самым убирая у человека возможность сломать что-то в логике твоего сервера, но делая свой продукт скорее конечным, потому что это конечно убирает любую гибкость в плане имплементации (ебать слово, я хоть правильно его написал то) новых сценариев.
Или мб компилировать доменный слой?

Кароче бляяяяять

Если хочется заебаться - можно создать базовый доменный слой
Меня заебало объяснять, я буду показывать
Ну типа

public class Player
{
    public int Id { get; set; }
    public string Name { get; set; }
}

И компилировать и его тоже, если хочется.
Но оставить открытую часть доменного слоя - ну типа

public class CustomPlayer : Player
{
    public int Reputation { get; set; }
    public bool IsAdmin { get; set; }
}

Разумно и интересно, но я бы так не делал, я бы лучше компилировал только инфру в закрытую конечную дллку, которая бы содержала мой собственный апи-враппер и весь контекст взаимодействий с бдшками и клиенткой.

Это звучит просто ещё логичнее и оставляет клиенту наибольший простор для собственной кастомизации.
При этом, так как ты управляешь по факту всей инфраструктурой - ты можешь буквально зашить в неё валидацию сборки через какой-нибудь свой апи, проверку лицензии, да вообще что угодно.
Это буквально звучит как best practice.

А просто так переделать бизнес-логику которая уже написана с использованием твоих реализацией интерфейсов инфраструктуры и по факту твоих апи-врапперов ....
Не ну возможно конечно, наверное, но это прям надо мощнейше заебаться
Человеку который сможет это сделать - легче будет свой сервак просто написать, немного сэкономив на описании доменных сущностей.


К чему я всё это высрал

...

Я не знаю
Где я? Кто здесь?

Говорят, когда лишний раз что-то рассказываешь, ты чуть-чуть лучше это понимаешь сам лишний раз.
А это всегда полезно, потому что я всё ещё нихуя не знаю.

Это всё ещё никак не отменяет моего тейка про то что сразу ориентироваться на то чтобы "всё залочить" - это хуёво, который я озвучил в первом посте.
И на мой взгляд какая-то часть всегда должна быть бесплатной, пусть не самая свежая и клёвая.

Но базируясь на всём том бреде сумасшедшего что я озвучил уже в этом посте - довольно вроде бы очевидно, что именно нужно компилировать и накрывать, чтобы прятать от пользователя. Я бы делал именно так.


А прятать то, что по сути вообще находится за инфраструктурой даже, причём зачастую самую кастомизируемую часть (ну цефки)
Причём то что достаточно легко можно подменить, в целом
Ну хууууууууууууууууууууууй знает

 

[Dmitry_V]

Раз уж кстати об этом пошла речь, че то есть настроение высрать ещё лонгрид

Я заранее извиняюсь, я всё таки как программист - самоучка, и хорошему проектированию всё ещё учусь постоянно, и до сих пор я вообще нихуя не знаю.
Но я попробую пояснить так, как могу.
Говорят, когда че то объясняешь - начинаешь понимать лучше.

Я просто пару раз в приступе какой-то шизофрении задумывался о том, чтобы написать какой-то паблик сервер с нуля, и в целом просто выложить его бесплатно - просто ради тренировки и каких-то новых знаний. Идея эта слава богу пошла по пизде, потому что то нейротянки, то теперь игры в веб аппках в телеграмме, то зовут менеджером куда-то и чужой код чекать приходится, но.

Но когда я о какой-то структуре думал, я тоже задумывался о том, что какую-то его часть можно сделать полностью закрытым, ну скомпилированной дллкой, которую ты подгружаешь в проект.
И собственно почему бы и нет?

А как какать?

Введение в лонгрид

В рейдже как и во всех таких паблик штуках, которые постоянно пишутся разработчиками-любителями, всё крайне хуёво с пониманием того, что вообще такое программирование на каком-то более менее адекватном уровне.
На базовом, хуёвом уровне, программирование - это просто написание кода, чтобы что-то, что ты написал - работало. Работало так, как задумано.
На 85 уровне разработчика - важны долговечность, понятность и масштабируемость кода.
И это на самом деле чуть сложнее, чем звучит.

Чтобы этого достичь - "чтобы работало" недостаточно. Это - хуёвый подход, который детектит зародыш разработчика.
Ты должен быть уверен в том, что код легко поддерживать. И это ну, не просто комментарии - это читаемость кода вообще без комментариев, на самом деле.
Гарантировать, то что изменения в любой одной части кода - ничего не сломают никогда в другой.
Ну и понимать, что такое принцип единственной ответственности и вообще весь солид, например.
"Эта часть" твоего кода - вообще не должна нихуя знать про "вот ту" - например класс Player должен отвечать только за данные игрока, а не за то, как они сохраняются в базе данных.
Высокоуровневые модули не должны зависеть от низкоуровневых. Оба они должны зависеть только от абстракций.
Например, бизнес-логика должна использовать интерфейс для работы с БД, а не напрямую обращаться к образной MySqlConnection.
Ведь завтра ты можешь захотеть переехать на EF - и тогда при правильном раскладе ты затронешь ровно 0 строчек старого кода, просто дописав новую реализацию интерфейса.
(пример с еф на самом деле хуёвый, но похуй)

Интуитивно совсем простой пример реализации такой истории, просто для попробовать - можно реализовать например интерфейсами или абстрактными классами.
Сначала ты пишешь себе консольное приложение, любое, заканчиваешь его, а потом решаешь переписать его на винформы. (ну например)
И когда ты первый раз после базового уровня разработки сюда попадаешь - ты такой "ага, ебать, теперь мне переписывать 75% моего кода со всеми зависимостями, заебись".
И если в этот момент возникает мысль - а можно ли блять писать код так, чтобы ему было не важно, где будет выход - в консоли, в винформах, на фтп сервере блять - то поздравляю, ты буквально в этот момент начинаешь во что-то окукливаться из личинки разработчика.

В этот момент ты задумываешься про дизайн своего кода. (Если ты не долбоёб) Когда есть несколько слоёв никак не зависящей друг от друга логики - ввода-вывода например, презентации данных и бизнес-логики приложения.
И начинаешь понимать, насколько важна архитектура.


Ты нахуй этот тут пишеш слыш

Дальше, неизменно следующим шагом будет собственно проектирование той самой архитектуры.
У код-дизайна есть буквально основы, которые описаны уже в сотнях книг, наверное, например слоистая архитектура.

* пока я в этом месте два часа говорил с человеком в дискордике, появилась ещё пара постов выше, ну ничо, не отвлекаемся *

Че вообще такое нахуй слои?

Ну начнём с того что я никогда не видел вообще хоть сколько-нибудь грамотного подхода к архитектуре ни в одном жта проекте.
Даже к разделению солюшена на проекты с хоть КАКИМ ТО БЛЯТЬ подобием - такое ощущение что у коммьюнити врожденное отвращение.
Ограничимся давайте блять CORE и CLIENT которые один от другого зависят, вот и всё, вот и заебись.

Ладно

Это абстрактные понятия, которые фактически как именно код - не то чтобы существуют, это вроде концепции.
Ну разве что как разные проекты внутри решения (хотя никто не мешает тебе связать их без какой-либо слоистой ответственности вообще, если ты дурачок).
Обычно они делятся на концепты:

Доменного слоя - каркаса с описанием объектов (например Player, Vehicle, House) с описанием базовых правил-проверок вроде проверок отрицательности денег у игрока. Буквально база, каркас. Это "где хранить", если можно так выразиться.

Доменной логики - то, что происходит внутри доменного слоя. Правила, сценарии - например "аренда машины" там, или "покупка дома". Это "что делать".
Это не отдельный типа "слой", на самом деле, это часть доменного слоя, но тем не менее, для понимания проще выделять.
Доменному слою похуй на всё остальное, ему плевать на формат, базы данных и взаимодействие с его данными и кодом.
Он существует единолично и комплексно сам по себе.

Бизнес-логики - (связывание доменных объектов с реализующими их сценариями - проверка баланса игрока при покупке дома например, процесс передачи дома или тачки там, списания бабок) Например если чел купил дом - бизнес логика распоряжается, что нужно вызывать уведомления, писать что то в бд и отправить админу в личку сообщение что ты читак, потому что домов на сервере нет, как нам подсказал доменный слой.

Бизнес логика знает о доменном слое, она содержит правила и сценарии по работе с ним, она использует репозиторий (например) инфраструктуры, о наличии которой - тоже в курсе, но при этом понятия не имеет как именно работает инфраструктура и в каком виде и где хранит на самом деле описанные в домене объекты.
Например, бизнес-логика может вызвать Save(player), но она не знает, как это реализовано - через скуль, носкуль, да хоть через тхт файлики.

Ну и инфраструктурный слой - это всё наше взаимодействие с чем-то вовне. Работа с апишкой какой-нибудь, базами данных, файлами - что там ещё может в воспалённую голову прийти. Инфраструктура - предоставляет репозитории, с которыми работает бизнес-логика. Бизнес логика - знает только о реализациях интерфейсов, описанных в инфраструктуре.
Т.е. бизнес-логика юзает какую нибудь реализацию интерфейса IPlayerRepository, которая описана как PlayerRepository - не имея ни малейшего понятия о том, что эта реализация использует DbContext, например. Этот слой нихуя не знает о бизнес-логике, ему похуй. Но знает о доменном слое, потому что работает с его сущностями.

• Доменный слой — "где хранить".
• Доменная логика — "что делать".
• Бизнес-логика — "как связать всё вместе".
• Инфраструктура — "как делать" на уровне технической реализации.

Очень интересно но нахуя мне эта информация

Да очень просто на самом деле - когда ты правильно проектируешь, тебе очень легко понять, какие части изолированной логики ты можешь легко держать в скомпилированном виде, например.

Ну например, ты можешь вообще в своём проекте написать инфраструктурный слой, который будет реализовывать все технические детали - как взаимодействие с бдшкой так и вообще скроет под своим капотом всё взаимодействие с рейдж-апи и даже с вызовами цефок, например.
Твоя бизнес-логика в результате будет работать с каким-то новым твоим IRageApi (например), не имея ни малейшего понятия о том, как они реализованы.
Т.е. пользователь сможет буквально писать свои новые правила и сценарии - но уже с твоим "апи".
Ты полностью скрываешь инфраструктуру (что по мне звучит довольно логично), оставляя для пользователя только твои, новые точки взаимодействия с ней.
По сути ты предоставляешь готовый инструмент для работы с апишкой, обёртку.

Ну и готовые доменный слой с бизнес-логикой, которая работает с твоей инфраструктурой, и будет работать с новыми своими кусочками.
Ты убираешь сложность - но оставляешь гибкость.

Ещё вариант - компилировать бизнес-логику, тем самым убирая у человека возможность сломать что-то в логике твоего сервера, но делая свой продукт скорее конечным, потому что это конечно убирает любую гибкость в плане имплементации (ебать слово, я хоть правильно его написал то) новых сценариев.
Или мб компилировать доменный слой?

Кароче бляяяяять

Если хочется заебаться - можно создать базовый доменный слой
Меня заебало объяснять, я буду показывать
Ну типа

public class Player
{
    public int Id { get; set; }
    public string Name { get; set; }
}

И компилировать и его тоже, если хочется.
Но оставить открытую часть доменного слоя - ну типа

public class CustomPlayer : Player
{
    public int Reputation { get; set; }
    public bool IsAdmin { get; set; }
}

Разумно и интересно, но я бы так не делал, я бы лучше компилировал только инфру в закрытую конечную дллку, которая бы содержала мой собственный апи-враппер и весь контекст взаимодействий с бдшками и клиенткой.

Это звучит просто ещё логичнее и оставляет клиенту наибольший простор для собственной кастомизации.
При этом, так как ты управляешь по факту всей инфраструктурой - ты можешь буквально зашить в неё валидацию сборки через какой-нибудь свой апи, проверку лицензии, да вообще что угодно.
Это буквально звучит как best practice.

А просто так переделать бизнес-логику которая уже написана с использованием твоих реализацией интерфейсов инфраструктуры и по факту твоих апи-врапперов ....
Не ну возможно конечно, наверное, но это прям надо мощнейше заебаться
Человеку который сможет это сделать - легче будет свой сервак просто написать, немного сэкономив на описании доменных сущностей.


К чему я всё это высрал

...

Я не знаю
Где я? Кто здесь?

Говорят, когда лишний раз что-то рассказываешь, ты чуть-чуть лучше это понимаешь сам лишний раз.
А это всегда полезно, потому что я всё ещё нихуя не знаю.

Это всё ещё никак не отменяет моего тейка про то что сразу ориентироваться на то чтобы "всё залочить" - это хуёво, который я озвучил в первом посте.
И на мой взгляд какая-то часть всегда должна быть бесплатной, пусть не самая свежая и клёвая.

Но базируясь на всём том бреде сумасшедшего что я озвучил уже в этом посте - довольно вроде бы очевидно, что именно нужно компилировать и накрывать, чтобы прятать от пользователя. Я бы делал именно так.


А прятать то, что по сути вообще находится за инфраструктурой даже, причём зачастую самую кастомизируемую часть (ну цефки)
Причём то что достаточно легко можно подменить, в целом
Ну хууууууууууууууууууууууй знает

Когда выкатывают такие посты, чувствую себя даже не зародышем программиста, а так сперматозоидом плавающим и ожидающим одного из миллиарда шансов стать тру кодером.

 

[Inoi]

Когда выкатывают такие посты, чувствую себя даже не зародышем программиста, а так сперматозоидом плавающим и ожидающим одного из миллиарда шансов стать тру кодером.

Да это звучит для первого раза всё слегка ебаней, чем есть на самом деле
На самом деле нормальная архитектура кода - пиздец какая логичная вещь
Буквально попробовав пару раз ты просто не сможешь писать иначе

 

[Amazingevich]

Раз уж кстати об этом пошла речь, че то есть настроение высрать ещё лонгрид

Я заранее извиняюсь, я всё таки как программист - самоучка, и хорошему проектированию всё ещё учусь постоянно, и до сих пор я вообще нихуя не знаю.
Но я попробую пояснить так, как могу.
Говорят, когда че то объясняешь - начинаешь понимать лучше.

Я просто пару раз в приступе какой-то шизофрении задумывался о том, чтобы написать какой-то паблик сервер с нуля, и в целом просто выложить его бесплатно - просто ради тренировки и каких-то новых знаний. Идея эта слава богу пошла по пизде, потому что то нейротянки, то теперь игры в веб аппках в телеграмме, то зовут менеджером куда-то и чужой код чекать приходится, но.

Но когда я о какой-то структуре думал, я тоже задумывался о том, что какую-то его часть можно сделать полностью закрытым, ну скомпилированной дллкой, которую ты подгружаешь в проект.
И собственно почему бы и нет?

А как какать?

Введение в лонгрид

В рейдже как и во всех таких паблик штуках, которые постоянно пишутся разработчиками-любителями, всё крайне хуёво с пониманием того, что вообще такое программирование на каком-то более менее адекватном уровне.
На базовом, хуёвом уровне, программирование - это просто написание кода, чтобы что-то, что ты написал - работало. Работало так, как задумано.
На 85 уровне разработчика - важны долговечность, понятность и масштабируемость кода.
И это на самом деле чуть сложнее, чем звучит.

Чтобы этого достичь - "чтобы работало" недостаточно. Это - хуёвый подход, который детектит зародыш разработчика.
Ты должен быть уверен в том, что код легко поддерживать. И это ну, не просто комментарии - это читаемость кода вообще без комментариев, на самом деле.
Гарантировать, то что изменения в любой одной части кода - ничего не сломают никогда в другой.
Ну и понимать, что такое принцип единственной ответственности и вообще весь солид, например.
"Эта часть" твоего кода - вообще не должна нихуя знать про "вот ту" - например класс Player должен отвечать только за данные игрока, а не за то, как они сохраняются в базе данных.
Высокоуровневые модули не должны зависеть от низкоуровневых. Оба они должны зависеть только от абстракций.
Например, бизнес-логика должна использовать интерфейс для работы с БД, а не напрямую обращаться к образной MySqlConnection.
Ведь завтра ты можешь захотеть переехать на EF - и тогда при правильном раскладе ты затронешь ровно 0 строчек старого кода, просто дописав новую реализацию интерфейса.
(пример с еф на самом деле хуёвый, но похуй)

Интуитивно совсем простой пример реализации такой истории, просто для попробовать - можно реализовать например интерфейсами или абстрактными классами.
Сначала ты пишешь себе консольное приложение, любое, заканчиваешь его, а потом решаешь переписать его на винформы. (ну например)
И когда ты первый раз после базового уровня разработки сюда попадаешь - ты такой "ага, ебать, теперь мне переписывать 75% моего кода со всеми зависимостями, заебись".
И если в этот момент возникает мысль - а можно ли блять писать код так, чтобы ему было не важно, где будет выход - в консоли, в винформах, на фтп сервере блять - то поздравляю, ты буквально в этот момент начинаешь во что-то окукливаться из личинки разработчика.

В этот момент ты задумываешься про дизайн своего кода. (Если ты не долбоёб) Когда есть несколько слоёв никак не зависящей друг от друга логики - ввода-вывода например, презентации данных и бизнес-логики приложения.
И начинаешь понимать, насколько важна архитектура.


Ты нахуй этот тут пишеш слыш

Дальше, неизменно следующим шагом будет собственно проектирование той самой архитектуры.
У код-дизайна есть буквально основы, которые описаны уже в сотнях книг, наверное, например слоистая архитектура.

* пока я в этом месте два часа говорил с человеком в дискордике, появилась ещё пара постов выше, ну ничо, не отвлекаемся *

Че вообще такое нахуй слои?

Ну начнём с того что я никогда не видел вообще хоть сколько-нибудь грамотного подхода к архитектуре ни в одном жта проекте.
Даже к разделению солюшена на проекты с хоть КАКИМ ТО БЛЯТЬ подобием - такое ощущение что у коммьюнити врожденное отвращение.
Ограничимся давайте блять CORE и CLIENT которые один от другого зависят, вот и всё, вот и заебись.

Ладно

Это абстрактные понятия, которые фактически как именно код - не то чтобы существуют, это вроде концепции.
Ну разве что как разные проекты внутри решения (хотя никто не мешает тебе связать их без какой-либо слоистой ответственности вообще, если ты дурачок).
Обычно они делятся на концепты:

Доменного слоя - каркаса с описанием объектов (например Player, Vehicle, House) с описанием базовых правил-проверок вроде проверок отрицательности денег у игрока. Буквально база, каркас. Это "где хранить", если можно так выразиться.

Доменной логики - то, что происходит внутри доменного слоя. Правила, сценарии - например "аренда машины" там, или "покупка дома". Это "что делать".
Это не отдельный типа "слой", на самом деле, это часть доменного слоя, но тем не менее, для понимания проще выделять.
Доменному слою похуй на всё остальное, ему плевать на формат, базы данных и взаимодействие с его данными и кодом.
Он существует единолично и комплексно сам по себе.
Ты буквально пишешь эту часть так - что её можно вытащить и использовать в вообще другой игре.

Бизнес-логики - (связывание доменных объектов с реализующими их сценариями - проверка баланса игрока при покупке дома например, процесс передачи дома или тачки там, списания бабок) Например если чел купил дом - бизнес логика распоряжается, что нужно вызывать уведомления, писать что то в бд и отправить админу в личку сообщение что ты читак, потому что домов на сервере нет, как нам подсказал доменный слой.

Бизнес логика знает о доменном слое, она содержит правила и сценарии по работе с ним, она использует репозиторий (например) инфраструктуры, о наличии которой - тоже в курсе, но при этом понятия не имеет как именно работает инфраструктура и в каком виде и где хранит на самом деле описанные в домене объекты.
Например, бизнес-логика может вызвать Save(player), но она не знает, как это реализовано - через скуль, носкуль, да хоть через тхт файлики.

Ну и инфраструктурный слой - это всё наше взаимодействие с чем-то вовне. Работа с апишкой какой-нибудь, базами данных, файлами - что там ещё может в воспалённую голову прийти. Инфраструктура - предоставляет репозитории, с которыми работает бизнес-логика. Бизнес логика - знает только о реализациях интерфейсов, описанных в инфраструктуре.
Т.е. бизнес-логика юзает какую нибудь реализацию интерфейса IPlayerRepository, которая описана как PlayerRepository - не имея ни малейшего понятия о том, что эта реализация использует DbContext, например. Этот слой нихуя не знает о бизнес-логике, ему похуй. Но знает о доменном слое, потому что работает с его сущностями.

• Доменный слой — "где хранить".
• Доменная логика — "что делать".
• Бизнес-логика — "как связать всё вместе".
• Инфраструктура — "как делать" на уровне технической реализации.

Очень интересно но нахуя мне эта информация

Да очень просто на самом деле - когда ты правильно проектируешь, тебе очень легко понять, какие части изолированной логики ты можешь легко держать в скомпилированном виде, например.

Ну например, ты можешь вообще в своём проекте написать инфраструктурный слой, который будет реализовывать все технические детали - как взаимодействие с бдшкой так и вообще скроет под своим капотом всё взаимодействие с рейдж-апи и даже с вызовами цефок, например.
Твоя бизнес-логика в результате будет работать с каким-то новым твоим IRageApi (например), не имея ни малейшего понятия о том, как они реализованы.
Т.е. пользователь сможет буквально писать свои новые правила и сценарии - но уже с твоим "апи".
Ты полностью скрываешь инфраструктуру (что по мне звучит довольно логично), оставляя для пользователя только твои, новые точки взаимодействия с ней.
По сути ты предоставляешь готовый инструмент для работы с апишкой, обёртку.

Ну и готовые доменный слой с бизнес-логикой, которая работает с твоей инфраструктурой, и будет работать с новыми своими кусочками.
Ты убираешь сложность - но оставляешь гибкость.

Ещё вариант - компилировать бизнес-логику, тем самым убирая у человека возможность сломать что-то в логике твоего сервера, но делая свой продукт скорее конечным, потому что это конечно убирает любую гибкость в плане имплементации (ебать слово, я хоть правильно его написал то) новых сценариев.
Или мб компилировать доменный слой?

Кароче бляяяяять

Если хочется заебаться - можно создать базовый доменный слой
Меня заебало объяснять, я буду показывать
Ну типа

public class Player
{
    public int Id { get; set; }
    public string Name { get; set; }
}

И компилировать и его тоже, если хочется.
Но оставить открытую часть доменного слоя - ну типа

public class CustomPlayer : Player
{
    public int Reputation { get; set; }
    public bool IsAdmin { get; set; }
}

Разумно и интересно, но я бы так не делал, я бы лучше компилировал только инфру в закрытую конечную дллку, которая бы содержала мой собственный апи-враппер и весь контекст взаимодействий с бдшками и клиенткой.

Это звучит просто ещё логичнее и оставляет клиенту наибольший простор для собственной кастомизации.
При этом, так как ты управляешь по факту всей инфраструктурой - ты можешь буквально зашить в неё валидацию сборки через какой-нибудь свой апи, проверку лицензии, да вообще что угодно.
Это буквально звучит как best practice.

А просто так переделать бизнес-логику которая уже написана с использованием твоих реализацией интерфейсов инфраструктуры и по факту твоих апи-врапперов ....
Не ну возможно конечно, наверное, но это прям надо мощнейше заебаться
Человеку который сможет это сделать - легче будет свой сервак просто написать, немного сэкономив на описании доменных сущностей.


К чему я всё это высрал

...

Я не знаю
Где я? Кто здесь?

Говорят, когда лишний раз что-то рассказываешь, ты чуть-чуть лучше это понимаешь сам лишний раз.
А это всегда полезно, потому что я всё ещё нихуя не знаю.

Это всё ещё никак не отменяет моего тейка про то что сразу ориентироваться на то чтобы "всё залочить" - это хуёво, который я озвучил в первом посте.
И на мой взгляд какая-то часть всегда должна быть бесплатной, пусть не самая свежая и клёвая.

Но базируясь на всём том бреде сумасшедшего что я озвучил уже в этом посте - довольно вроде бы очевидно, что именно нужно компилировать и накрывать, чтобы прятать от пользователя. Я бы делал именно так.


А прятать то, что по сути вообще находится за инфраструктурой даже, причём зачастую самую кастомизируемую часть (ну цефки)
Причём то что достаточно легко можно подменить, в целом
Ну хууууууууууууууууууууууй знает

Ты в Chat GPT не подрабатываешь?) Я увидел объём поста - уже отдышка началась

 

[XDeveluxe]

Но когда я о какой-то структуре думал, я тоже задумывался о том, что какую-то его часть можно сделать полностью закрытым, ну скомпилированной дллкой, которую ты подгружаешь в проект.
И собственно почему бы и нет?

Как только я получаю твою обычно собранную дллку - я её раскрываю и забираю всё, что лежит внутри, как, например, я открываю тот же бутстраппер (внутренности) и могу пойти скопировать его на абсолютно новый со своими изменениями в нём.
И в чём смысОл этой такой закрытости тогда?

 

[Inoi]

Как только я получаю твою обычно собранную дллку - я её раскрываю и забираю всё, что лежит внутри, как, например, я открываю тот же бутстраппер (внутренности) и могу пойти скопировать его на абсолютно новый со своими изменениями в нём.
И в чём смысОл этой такой закрытости тогда?

Ну попробуй посмотри что внутри

donottouchme.rar

Посмотреть и скачать с Яндекс Диска

disk.yandex.ru

Пенис не отвалится, всё безобидно есче

 

[XDeveluxe]

Ну попробуй посмотри что внутри

donottouchme.rar

Посмотреть и скачать с Яндекс Диска

disk.yandex.ru

Пенис не отвалится, всё безобидно есче

По eatme.dll прошлись .NET Reactor'ом.

 

[Inoi]

Ну вот

Не сильно же похоже на то, что происходит при запуске, ды?
Вариантов кроме первого что я нагуглил шифрануть свою хуйню - чуть более чем до пизды.
И увидишь ты при "открытии" ровно что "Penis".

 

[DeAAmoN]

Скажу по опыту. Люди либо покупают 100% исходники, либо ничего.

Билд без возможности редактировать - никому не нужен
А привязку часто просто находят и вырезают.............

 

[XDeveluxe]

Ну вот

Посмотреть вложение 17838

Не сильно же похоже на то, что происходит при запуске, ды?
Вариантов кроме первого что я нагуглил шифрануть свою хуйню - чуть более чем до пизды.
И увидишь ты при "открытии" ровно что "Penis".

Я не знаю, что происходит при запуске, потому что не качал весь архив, а только обе .dll'ки.
Я уверен, что если захотеть (и при должных знаниях) - можно не слишком долго мучаясь увидеть то, что внутри этих методов.

 

[Inoi]

Я не знаю, что происходит при запуске, потому что не качал весь архив, а только обе .dll'ки.
Я уверен, что если захотеть (и при должных знаниях) - можно не слишком долго мучаясь увидеть то, что внутри этих методов.

Нуууу сними?
Я использовал всего три метода шифрования из демо-версии.

Чойто "уверен"?
Ты мне кажется конечно недооцениваешь немножечко эту сферу.
Это же не просто обфускатор, это достаточно сложный инструмент ващет.
А если я темидой накрою? А смартассемблеем? Тоже хуйня?
Получается редгейт, который их когда-то за какие то мульоны купил, и цена их софта в 700 баксов - наебалово всё шоли?


Вообще это странный тейк - ну типа, можно и дрм-защиту снять - их же снимает кто-то.
Можно, наверное, и Пентагон взломать "при должных знаниях".
И ядерную ракету можно ебануть при должных знаниях.
Хули нет-то.
Но я не очень много знаю людей, которые такими должными знаниями обладают.


Но вообще, ну, это мягко скажем довольно сложно. Это же ну, индустрия, ващето, люди деньги зарабатывают.
Даже при "должных знаниях" и опыте реверс-инжиниринга, которые уже нихуя не простые - всё это требует достаточно дохуя времени и прям прикладных знаний.

Вообще, конечно, абсолютно любой софт который запускается локально - можно сломать. Как бы охуенно он не был зашифрован или обфусцирован - в момент запуска он загружается в память в любом случае - ты всегда можешь сделать дамп и ковырять его до усрачки. Базара ноль.
Абсолютно все кто "гарантирует стопроцентную защиту" - пиздят.

Всё это - это просто усложнение этого процесса. Ты просто делаешь его настолько заёбным, что в нём нет никакого смысла.
Ну кроме спортивного интереса, конечно.

Я ж сам на прошлой странице рассказывал, как снимал обфускацию и шифровку на каком-то боте.
Но ну во-первых обфускация первая была просто угарная какая-то на уровне плагина к аутоиту.
Вот упаковщик я потом открывал пару недель - и у меня уже был опыт работы с ИДАой и анпакинга всякого такого нехитро запакованного говна, в процессе ползания по xorам.
И то ну, чел использовал какую то старую бесплатную паблик хуйню.

Я думаю, что чтобы сломать современные, нормальные платные шифраторы, если человек который запаковывал свой код хоть какие-то усилия приложил - нужно крайне основательно заебаться.
А учитывая что ты это совмещаешь обычно с какими то новыми версиями своего софта, обновляя и иногда меняя эти самые методы упаковки - я хуй знает сколько он должен стоить, чтобы кому то нужно было так с ним ебаться.

 

[X-Clusiv]

Вспоминается эра ICQ чатов.
Помнится сам занимался ими, сдавал в аренду.
Там было конечно все проще, так как небыло графического интерфейса.
Управление происходило через админку, т.е. установка названия чата, создание комнат, и прочая шалуха по типу игр викторин и т.п.. Это пользовалось популярностью в то время, и чаты брали весьма охотно.
Можно попробовать что-то подобное сделать, у самого была подобная идея. Тут не будет доступа к самому коду, и моду. Будет только веб морда.

 

[XDeveluxe]

Чойто "уверен"?

Уверен, потому что ты сам ответил на свой же вопрос.
Нет стопроцентной защиты и быть не может, это война чёрного с белым .
Если сильно захотеть - это можно сделать, вопрос потребности, а мне это, очевидно, не то чтобы нужно.
Если кому-то будет очень сильно надо - сделают. Это изначально то, о чём я вообще говорил. Ясное дело, что это не 2 секунды и не так быстро, если прикладывается хоть какая-то защита, но открой хотя бы тот же гитхаб, там этих ссылок десятки, а то и сотни. Я не говорю, что все они работают, я не проверял, но суть в том, что всегда будет обратная борьба и это база, от которой не уйти.

 

[Inoi]

Уверен, потому что ты сам ответил на свой же вопрос.
Нет стопроцентной защиты и быть не может, это война чёрного с белым .
Если сильно захотеть - это можно сделать, вопрос потребности.
Если кому-то будет очень сильно надо - сделают. Это изначально то, о чём я вообще говорил. Ясное дело, что это не 2 секунды и не так быстро, если прикладывается хоть какая-то защита, но открой хотя бы тот же гитхаб, там этих ссылок десятки, а то и сотни. Я не говорю, что все они работают, я не проверял, но суть в том, что всегда будет обратная борьба и это база, от которой не уйти.

Ну можешь и не открывать

Ни один не сработает.

Ещё раз - это странный тейк. Тот факт что может найтись один человек на миллион, который просто из-за фанатичного интереса может обойти любые меры защиты - абсолютно никак не означает что они не работают.
Они сработают ровно 999.999 раз.
Тем более когда речь идёт о коммьюнити, которое в большинстве своём вчера в штаны ещё какалось.

Если кому-то будет очень сильно надо - он и банк ограбит. Но это не значит что все отделения сбербанка могут нахуй снимать все меры предосторожности и просто бабки в отделениях на пол горками складывать.

Вспоминается эра ICQ чатов.
Помнится сам занимался ими, сдавал в аренду.
Там было конечно все проще, так как небыло графического интерфейса.
Управление происходило через админку, т.е. установка названия чата, создание комнат, и прочая шалуха по типу игр викторин и т.п.. Это пользовалось популярностью в то время, и чаты брали весьма охотно.
Можно попробовать что-то подобное сделать, у самого была подобная идея. Тут не будет доступа к самому коду, и моду. Будет только веб морда.

Так послотовые хостинги жиесть

 

[XDeveluxe]

Ну можешь и не открывать

Посмотреть вложение 17841

Ни один не сработает.

Ещё раз - это странный тейк. Тот факт что может найтись один человек на миллион, который просто из-за фанатичного интереса может обойти любые меры защиты - абсолютно никак не означает что они не работают.
Они сработают ровно 999.999 раз.
Тем более когда речь идёт о коммьюнити, которое в большинстве своём вчера в штаны ещё какалось.

Если кому-то будет очень сильно надо - он и банк ограбит. Но это не значит что все отделения сбербанка могут нахуй снимать все меры предосторожности и просто бабки в отделениях на пол горками складывать.

Ты со мной сейчас пытаешься воевать, будто я запрещаю тебе вселенскими силами использовать твою защиту.
Я высказываю своё мнение, имею на него право? Считаю, что да.
Понятное дело, что защита в целом хороша и полезна, но я уже приводил в самом первом своём посте касающегося этой темы про трипл-эй игры и Denuvo, и всё вот это вот.
Если будет очень надо - сделают и нет, это будет не один человек на миллион, потому что тебе не нужно быть этим одним человеком, тебе достаточно иметь нужное количество денег, чтобы нанять этого "одного", а уж бизнесменов хватает. Я высказал своё мнение: будет сильно надо - твою длл разберут. Если это будет никому не надо - то тебе и защита, как таковая, не нужна.
А сравнивать хуй пойми какую длл хуй пойми на каком мультиплеере с банком, ну, конечно, не серьёзно.
ИМХО, не вижу смысла воевать на этот счёт, т.к. это всего лишь моё мнение.

 

[DeAAmoN]

Ну можешь и не открывать

Посмотреть вложение 17841

Ни один не сработает.

Ещё раз - это странный тейк. Тот факт что может найтись один человек на миллион, который просто из-за фанатичного интереса может обойти любые меры защиты - абсолютно никак не означает что они не работают.
Они сработают ровно 999.999 раз.
Тем более когда речь идёт о коммьюнити, которое в большинстве своём вчера в штаны ещё какалось.

Если кому-то будет очень сильно надо - он и банк ограбит. Но это не значит что все отделения сбербанка могут нахуй снимать все меры предосторожности и просто бабки в отделениях на пол горками складывать.



Так послотовые хостинги жиесть

Да, но после этого "фанатичного дяди" скорее всего все окажется в открытом доступе = слито
И стоит ли пытаться что то изображать?

 

[Inoi]

Да я не пытаюсь воевать, я пытаюсь логично рассуждать.

Будет сильно надо - твою длл разберут. Если это будет никому не надо - то тебе и защита не нужна.

Ну мы же говорим о конкретном кейсе.
О разработке жта5рп сервера и кусочке его кода, который накрыт упаковщиком.

Тебе защита не может быть не нужна, если ты хочешь его продавать - потому что тебе нужно как-то валидировать единственного покупателя конкретного экземпляра.
Если защиты вообще не будет - твоя сборка полностью завтра появится на рагемп про.

И типа от того, нужно ли в теории кому-то сильно искать человека с определёнными знаниями, каким-то образом его заинтересовать ебаться с твоей защитой или нет - это ваще никак не зависит.
Если её не будет - появится. Если будет - ну конкретно эта версия твоего билда какое-то время не появится, достаточно длительное, если ты приложил усилия.
К моменту когда возможно появится - у тебя выйдет ещё двадцать билдов.

Как так не нужна то

Да, но после этого "фанатичного дяди" скорее всего все окажется в открытом доступе = слито
И стоит ли пытаться что то изображать?

Ну если ты изначально планируешь (абстрактный "ты", тут скорее @Vermilion получается, например, как ТС) выпустить что-то как продукт 1 раз и дальше на этом сидеть как на толчке, из которого вылезают деняшки - то ну, ты дурачок.
Конечно рано или поздно твою залупу сломают и всё пойдёт по пизде.

Но ну, нормальный разработчик не продаёт 1 версию.
Ты же че то доделываешь постоянно, придумываешь новое, через образных полгода-год, когда вдруг кто-то может теоретически умудрится что-то сломать - у тебя может выйти ещё билдов пять, на фоне последних из которых та версия, которую смогли сломать - тебе уже самому давно кажется неполноценной хуетой.
Ну и те, кто пользуются последней, конечно, это очевидно тоже ощущают.

Ну типа
Да и усилий по защите софта можно приложить просто дохуя - ну мало тебе шифрованной дллки, напиши свой инсталлер своего софта, который будет при запуске верифицировать комп покупателя через интернет и дестроить софт, если это пират. Ну сделай не одну дллку а три с закольцованными проверками по сети, тоже.
Ну используй нативные длл в конце концов для какой-нибудь верификации (я не ебу, возможно ли это в рейдже, просто теоретизирую, но почему нет?), это ваще пиздец начинается, ещё щас нам машинный код разбирать.

Было бы желание - нахуевертить можно я ебу.
Но как Павел справедливо замечает - глобально, это всё можно сломать.
Да, это сложно, пиздец, но не невозможно.

Поэтому в целом первое чем надо брать - это просто качественным обновлением платной части своего контента.
Твою хуйню сломали - но у тебя уже год как (дивинити ориджинал син 2 кстати, всем интернетом ломали год) куча новых пиздатых фишек.
Твоя то хуйня появится в паблике - но пользоваться ей будут те, кто и так бы её не купил.
Ты останешься со своими клиентами, а через тех, кто посмотрел на то что есть в спижженом варианте - только больше аудитории получишь, которая теперь захочет последнее, новое и вкусное.
А если ты старые версии в целом делаешь бесплатными, о чем я ещё на первой странице говорил - то ты ещё и эти проблемы отметаешь.
Ну типа

Мы в коммьюнити в котором я напомню - первые сервера спижженой когда-то редаги крашили буквально прописанной в Commands.cs командой, которая крашила сервер.
И 95% "админов" не понимали в ахуе что происходит.
А это защита там такая охуительная была

А вы тут на серьёзных щщах рассуждаете о взломе буквально промышленного софта