German Jet

оторый позволяет получить власть над соц сетями

Сервер сам написан на yii2

Я так понимаю нужно что-то типа:
reformal.ru
Хотя хз. Стоит ли что-то советовать человеку, который написал на yii сервер и подчинил соц сети.

с псд любой дурак может, с пережатого жпега попробуй, вот где скилл )

по предюниоровскому трудоустройству

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

И не надейтесь.
Ни к чему такому интересному даже джуна не сразу подпускают.

{% for category in categorys %}
{{ category }}
{% for book in category.category_book.all %}
{{ book }}
{% endfor %}
{% endfor %}

Это в шаблоне, а во вьюхе:

model = Category
context_object_name = 'categorys'

Не надо делать 1с на моей джанго

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

Что касается "пол года писал то, что никому не нужно", привыкайте, в этом вся суть работы программиста.

Работодатель не будет смотреть весь функционал, что вы там на ваяете, мб обратит внимание на какие то интересные сложные моменты, показывающие Ваш скилл, но врядли. Код просят, чтобы посмотреть стиль оформления и наличие говнокода (лишние/не объявленные переменные например).

Что написать? В основном это crm.

1.
pip freeze - из под виртуалки покажет все пакеты.
pip freeze > requirements.txt - сохранит список пакетов в файл, потом можно будет все установить на боевой сервак pip install -r requirements.txt
2.
я думаю вариантов переноса много, но в общем если это vps, то надо сначала настроить сам сервак, установить требуемые пакеты, перенести сам проект, поправить в нем как минимум settings.py, настроить статику - просто скопировать проект как есть в папку на сервере не получится.
3.
если это mysql, то переносить можно и через phpmyadmin, только может быть проблема при переносе крупной базы, тк есть ограничения в php по размеру загружаемого файла.

busy-brain.ru/post/9 - тут все по шагам на русском)

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

2. Данные из post принимай через $this->input->posts('name'). Посмотри встроенную библиотеку input-.

3. На предмет наличия файла view проверку не делай. Если файла нет страница ошибки выйдет сама.

4. Header и footer лучше подключать во view файле, а не контроллере.

5. Ну и собственно у тебя все в куче в модели. Все действия нужно разнести в отдельный методы. Или даже Объекты.

что бесит в CI:
1. $this->loader->library("lib_name");
- подключение зависимостей происходит через лоадер, любая библиотека, является singliton объектом,это порождает некоторые проблемы в тех местах где нужны новые экземляры, а нужны синглитоны в 2% случаях
- автоподстоновка в IDE не работает
- отсутствие многослойности, мы можем get_instance()->loader->library("lib_name"); сделать в любом месте даже в классе ядра, что позволяет разрабатывать сильно связанный монолитный код
как нужно:
class Controller function __construct(LibName $lib_name){} - все

2. Класс к бд простой query builder, как ни крути в результате много дублирующего кода, - работа с массивами зло, когда строишь приложение и пишешь CRUD справочники например для админки, то придется писать прослойки - CRUD классы, а это тот же Repository, иногда нужно одни и те же модели отделять от слоя хранения а это уже datamapper, и вообще удобно использовать коллекции а не массивы данных получаемых из бд, если все вместе взять то тут и приходит необходимость использовать ORM который имеет под капотом все необходимое.

3. Логгер, ну не psr он, нельзя отказаться от хранилища в файлах и логировать в бд, или выводить на экран в консоль. После использования monolog, логгер CI выглядет убого

4. Миграции, если честно пробовал запускать, работают из браузера, а должны из консоли, можно создать консольные контроллеры с накаткой миграций, но тем не менее приходится много править в миграциях и коде когда меняется структура таблиц, например простейшая задача сменили название колонки, прошлись по коду сменили все использования этой колонки, создали миграцию, изменили модели, если проект большой сделать это не просто. В Propel2 ORM это делается в одном месте в xml конфиге и модели, миграции, перестраиваются одной командой.

5. тесты под капотом они убоги, просто так unit тесты не запустить нужно долго плясать с бубном.
6. Exception просто отсутствуют, работа с исключениями ведется через собственный механизм
7. PSR не используется
8. Работа с конфигами, они разделяются по папкам окружения, не кошерно, особенно когда все добро с доступом к бд комитят в гит, используйте .env

п.с. в новой версии знаю уже многие вещи будут исправлены но тем не менее проще собрать приложения на каркасе https://github.com/mmeyer724/Frameworkless

Что это за безумная каша из конструкций {% url 'main:blog/get_absolute_url' %}? Тег {% url %} ожидает получить имя url'а, то есть в вашем случае {% url 'main:blog' blog.slug %}, после чего возвращает url. И метод get_absolute_url делает то же самое. То есть вы пытаетесь получить url из объекта blog и передать его опять тегу url. Зачем? К тому же методы не вызываются через косую черту. И ещё, зачем у вас в шаблоне, после тега extends запятая?

Вы не совсем правильно понимаете, как это всё происходит, мне кажется. Нет такой команды, которая возьмёт и добавит всё в базу. На клиенте вам нужно поймать onclick события(читайте javascript события), потом передать какие-то данные на сервер через XMLHttpRequest / более новый fetch, затем обработать их любым серверным языком, в том числе серверным javascript, и через него добавить их в базу. Если не хочется писать говнокод - лучше не использовать jQuery и прочие тяжеловесные и бессмысленные на данном этапе фреймворки.

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

Можно и на php. Храните данные в хорошо доступном хранилище - redis/memcached и вынимайте их в обход php - например модули nginx для работы с memcached/redis - это позволит иметь горячие и доступные данные независимо от тормозов бакенда.
Важно понимать, что эти данные - кеш и этот кеш должен писаться в момент изменения/сохранения данных, а не в момент запроса; т.е. кеш должен быть всегда горячим и генерируемым при сохранении данных, не иметь expires и изменятся только событийно.
При такой архитектуре ваши данные будут всегда доступны из быстрого хранилища напрямую из nginx (в нем можно использовать например ssi для получения этих данных в контент страниц).
Оповещение js-фронтенда в realtime можно реализовать на websocket-ах, примеров массы, но я бы советовал не гонять очень много данных через него - только события о факте изменения и минимальные данные (всё что нужно можно забрать аяксом тогда когда нужно).

Я бы попробовал использовать паттерн Factory.
Фабрика будет создавать форму для конкретного типа документа, в ней не должно быть дублирования кода.
Список полей и правила их валидации для каждого типа договоров хранить в конфигурационных файлах concrete-document-type.php:

<?php
return [
    'elements' => [
        'name',
        'surname',
        'phone' => [
            'validators' => ['by']
        ],
        ...
    ],
    ...
];

Структуру привёл условную. Фабрика должна уметь по требуемому типу договора получить нужный конфигурационный файл и по нему построить нужную форму договора.

У вас получится 70 конфигурационных файлов. Дальше можно думать, как их максимально упростить. Например, у вас есть PhoneElement формы, использующий PhoneValidator, вы создаёте его наследника PhoneByElement с валидатором беларусского номера телефона. И конфигурационный файл превращается в:

<?php
return [
    'elements' => [
        'name',
        'surname',
        'phone_by',
        ...
    ],
    ...
];

Или добавляете понятие локали в конфигурационный файл:

<?php
return [
    'country' => 'by',
    'elements' => [
        'name',
        'surname',
        'phone',
        ...
    ],
    ...
];

def example(request):
    try:
        data = json.loads(request.body.decode())
    except ValueError:
        return JsonResponse({
            'error': 'bla bla bla',
        })

Если сервер 1 (допустим backend и frontend на разных доменах), то можно, например в backend конфиге

'components' => [
        'cache' => [
            'class' => 'yii\caching\FileCache',
            'cachePath' => '@frontend/runtime/cache' //делаем общий кеш
        ],
        'request' => [
            'csrfParam' => '_csrf-myap', //тоже делаем такое же как и на frontend
            'cookieValidationKey' => 'nk34HGdd8w6rf', //тоже делаем такое же как и на frontend
        ],

Должно получиться.