Во-вторых к процессу нужно подходить с душой, необходимо найти контакт с пациентом и т.д. В конце-концов необходимо уважать свои рабочие инструменты. А у вас всё как-то слишком утилитарно и грубо, IMHO не стоит заниматься работой, которая вам совсем не по душе!
Главный минус ООО, это невозможность прямого обмена имущества владельца ООО с самим ООО.
То есть деньги на счету ИП — это уже мои деньги, деньги на счету ООО — это деньги ООО, и их надо как-то получить, например заплатив себе ЗП, что обойдётся ещё в 13% только налога на доходы физ.лиц.
Скорее всего договор с этим издательством не позволяет подобных вольностей в общем случае. А чтобы у тебя был не общий случай, надо иметь такой статус, чтобы все издательства сами за тобой бегали.
Я не проверял статус коммерческих журналов, но подозреваю, что и среди них могут быть ВАКовские.
Ещё мне что-то подсказывает, что существует бизнес «цифровых» библиотек для мелких издательств, который в наше время иначе как паразитированием не назвать — стоит дорого, качество нулевое(поиск или уныл, или вообще только по абстрактам), но альтернативы нет.
Ну тут есть сложность в том, что для некоторых вещей, например, защита диссертации или «отчёт» по гранту необходимы публикации в журналы со специальными статусами (всякие там ВАКовские журналы).
А кто их даст полузакрытым сообществам? Это же тогда поступлений в кормушку меньше будет!
Тут я создал "__default__"-сущность, ибо лично я не люблю, когда на одном уровне конфига есть разные логические сущности и создал dict для «сложных» типов обработчиков. Это так же позволяет передавать прямо callable объекты, а не только строки, хотя для settings оно скорее всего излишне, а то и вредно.
Как вариант, можно сделать вариант «int|bool|str», а в str всегда указывать тип аргумента:
Идея хорошая, но мне кажется, что вы слишком уж много типов значений(и вариантов поведения) для ключа «post» сделали — рано или поздно начнутся ошибки.
IMHO стоит разбить на отдельные параметры с говорящими именами.
Для «генерации хаоса» ни в коем случае нельзя использовать исходные сообщения в общем случае, ибо исходное сообщение, в реальных применениях, имеет какой-либо практический смысл, следовательно, оно не является случайным!
Так что использовав исходное сообщение мы практически наверняка понизим криптостойкость.
Есть небольшая проблема — эксплоиты имеют способность утекать от исследователей в руки скрипт-кидисов и просто людей не имеющих морали. Так что скорее ваши деньги будут воровать совсем другие люди.
Во-вторых к процессу нужно подходить с душой, необходимо найти контакт с пациентом и т.д. В конце-концов необходимо уважать свои рабочие инструменты. А у вас всё как-то слишком утилитарно и грубо, IMHO не стоит заниматься работой, которая вам совсем не по душе!
Сейчас такое доступно только обладателям паяльных станций…
То есть деньги на счету ИП — это уже мои деньги, деньги на счету ООО — это деньги ООО, и их надо как-то получить, например заплатив себе ЗП, что обойдётся ещё в 13% только налога на доходы физ.лиц.
Ещё мне что-то подсказывает, что существует бизнес «цифровых» библиотек для мелких издательств, который в наше время иначе как паразитированием не назвать — стоит дорого, качество нулевое(поиск или уныл, или вообще только по абстрактам), но альтернативы нет.
А кто их даст полузакрытым сообществам? Это же тогда поступлений в кормушку меньше будет!
}
Тут я создал "__default__"-сущность, ибо лично я не люблю, когда на одном уровне конфига есть разные логические сущности и создал dict для «сложных» типов обработчиков. Это так же позволяет передавать прямо callable объекты, а не только строки, хотя для settings оно скорее всего излишне, а то и вредно.
Как вариант, можно сделать вариант «int|bool|str», а в str всегда указывать тип аргумента:
ну и т.д.
То есть тут различие только в синтаксисе — или парсим строку, или получаем готовый dict.
IMHO стоит разбить на отдельные параметры с говорящими именами.
Так что использовав исходное сообщение мы практически наверняка понизим криптостойкость.