Crash

Советую курс по алгоритмам от МФТИ (прямо с пар запись, но хорошая):
https://www.youtube.com/playlist?list=PLRDzFCPr95f...

Крайне интересная подача и хороший уровень, на языке Python, но пусть это не пугает, я вот PHP-программист и мне все понятно

статей не нашёл

Создание собственных событий

Уточню: как браузер понимает, что событие "tellFuckYou" произошло? это главное, о чём нигде не написано

// Создание события
var event = document.createEvent('Event');

// Назначить имя событию
event.initEvent('build', true, true);

// Слушаем событие
document.addEventListener('build', function (e) {
  // e.target соотетствует объекту document
}, false);

// target события может быть любой элемент
document.dispatchEvent(event);

Вообще не понимаю, зачем создавать свои события?

Если не понимаете, значит вам это не нужно.

"PHP 7 в подлиннике" хорошо читается

Прочитал описание задачи, выглядит очень странно.

Есть проект на .net, его нужно переписать на python/java - при этом главным критерием стоит масштабирование и вопрос кадров.

На Python кадров не так много. Найти middle/seniour на Python достаточно сложно. Чаще всего попадаются люди, кто что-то делал на Php, но при этом как-то ковырял Python. Да и масштабирование так себе под Python, т.е. можно, но с геройством.

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

Мб как вариант, вам докинуть зп до уровня адекватных Java- разрабов в 140-160 тысяч. А там глядишь и нормальные ребята на .net к вам подтянутся?

что бесит в 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

Сначала нужен gitignore а потом уже файлы.
Временно перемести delete_file_old, коммит, потом можно вновь их добавить.

Можно через

git rm -r --cached .
git add .
git commit -m ".gitignore"

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

Вероятнее всего, транзакция не фиксируется.
Для экспорта-импорта лучше всего использовать специализированные инструменты типа https://sypex.net/ или на худой конец mysqldump - но никак не MySQL Workbench и прочие клиенты.
Очень много нюансов при восстановлении дампа - от правильного порядка восстановления последовательностей и индексов до соблюдения таймаутов и помещения в транзакцию определенной порции данных, а не всей таблицы.

Это потому что вы верстальщик. Там конкуренция большая. Так как эту работу могут делать даже школьники. И да много ботов на FL.ru и это очень не удобно.

Изучите что то сложное. На пример работу с видео чатами и видео трансляциями. И бота не понадобится так как конкуренция ниже а стоимость работ такая что заказчик в любом случаи рассмотрит все предложения.
На пример вот я делал заказы https://freelancehunt.com/project/konsultatsiya-po... и https://freelancehunt.com/project/nastroit-videopl... оба без ставок. Хотя если бы это была вёрстка то заявок тоже было около 50.

POST запрос подразумевает создание записи, результатом ее должены быть пустое тело ответа и заголовок location c uri нового объекта.

PUT — подмена записей. Тобиш обновить одно какое-то поле у записи нельзя. Опять же, если вы заменили объект — то вы уже имеете на руках все нужные данные, посему ответом может быть опять же заголовок location.

есть еще метод PATCH, который позволяет именно обновлять запись (конкретное поле или несколько из них). Тут тоже подразумевается возврат только URI. По сути какие либо данные вам может вернуть только GET запрос.

И есть еще куча заморочек со статус кодами, мол 200 это хорошо только для GET, так как оно имеет тело ответа. А для большинства других нужен 204, который говорит что все хорошо, но есть только заголовки.

НО… это если по феншую и именно RESTFull, причем это далеко не все. Обычно дальше GET/POST/PUT/DELETE никто не идет… PATCH вообще редко используют, а вот LINK вообще ниразу не видел что бы на реальных проектах применяли…

рекомендую вам не очень парится по поводу теории, а просто ограничиться POST и GET. В нашем проекте сделали всё по правилам, а потом выяснилось, что Флекс-код с другого сервера ни PUT, ни DELETE слать не может, пришлось делать проксирование.

Оформление ИП и договор - нормальная ситуация. Особенно если компания берет на себя оформление и ведение ИП (что часто бывает в оутсорс, где 90% сотрудников - ИП).
Но и просто работа по контракту, когда вы ИП - нормально.

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