Atom Engineer, нужно комплексно решать реальные задачи, а после решения - переделывать, искать способ сделать лучше, доводить до состояния когда этим удобно пользоваться и ПО не падает чуть что не так, смотреть как сделано в похожих проектах на github. Есть типовые, даже не алгоритмы, а подходы к организации кэширования, мультиязычности, работе с датами/временем, авторизацией, взаимодействию с БД и внешними api, вот их и нужно отточить на практике.
На начальном этапе для этого можно сделать свой пет-проект в который как-то привлечь пользователей, подключить в него что-либо для мониторинга ошибок и исправлять эти ошибки, сделать чат с обратной связью от юзеров для той же цели и непрерывно его улучшать, прогонять код через SonarQube / другие анализаторы. Тут важно то что вы не можете как на фрилансе или может в некоторых компаниях выполнить задачу / заказ чтобы его приняли и забыть про неё. Когда вы сами из своего кармана платите за свои ошибки, когда вам нужно оплачивать сервера помощнее - очень мотивирует написать более оптимальный отказоустойчивый код, даже если предыдущее решение было неплохим ) В общем нужен тестовый полигон и реальные вызовы, придется пройтись по всем граблям и в процессе вы найдёте красивые способы их обходить. Будете читать какой-нибудь refactoring.guru статьи по архитектуре и сразу понимать где в вашем проекте их можно применить. Стоит быть готовым к тому что будет плохо получаться и не опускать руки, отдыхать и возвращаться с новыми силами.
Дальше в идеале все-таки устроиться работать в команду с хорошими спецами и там перенимать их опыт.
caches - доступен только в случае если сайт открыт по протоколу https
для локальной разработки без https можно как-то исключение добавить для домена в настройках хрома
Дмитрий Путилов, Object.values - получает массив значений объекта по ключам первого уровня.
.map перебирает этот массив и преобразует с помощью нашей функции - тут и происходит рекурсия. Каждый вложенный объект обрабатывается этой же функцией которая снова обрабатывает каждый вложенный объект, пока Object.values не станет пустым массивом
Object.keys берет ключи первого уровня влажности.
Так как у нас на выходе получается массив массивов - юзается .flat()
Чтобы избавиться от дубликатов, массив преобразуется в Set , потом обратно в массив
В идеале вот так сделать - https://github.com/DaoCasino/Game-Channels-Paper/b...
чтобы можно было много раз "кубики бросать" пока один из игроков не решит уйти.
Там каждый раунд подписывается data, в конце контракт валидирует подписи сторон.
То есть это нужно чтобы после каждого броска кубиков не отправлять транзакцию на возврат средств, видимо потом игроки еще раз захотят сыграть и тогда им все по новой придется делать холдить деньги потом выводить.
но сложна )
Назарий Лазарчук, ну а почему js метод массива find не выбрасывает ошибку в случае если элемент не найден?
Потому что это не исключение, а вполне ожидаемое поведение. Так работают методы получения во всех orm.
При таком подходе код будет во многих местах проще, без try / catch можно будет проверить наличие чего либо.
Решать является ли отсутствие элемента ошибкой или нет нужно уровнем выше. Это не дело orm.
kvxz2114, нет, в контекст не зачем его класть.
Он скорее всего статичный, так что можно просто хранить в каком-нибудь файле типа config.js или constants.js и импортировать только в компоненте с меню.
Смотрите, вы перебираете и читаете все файлы из директории, я не вижу никакого фильтра по типу файла. Возможно у вас там среди этих файлов какой-нибудь архив лежит с картинками на 500mb
Опять же, перед чтением файла, в консоли выведите путь к нему, чтобы по логам понять из-за какого файла кончилась память
На начальном этапе для этого можно сделать свой пет-проект в который как-то привлечь пользователей, подключить в него что-либо для мониторинга ошибок и исправлять эти ошибки, сделать чат с обратной связью от юзеров для той же цели и непрерывно его улучшать, прогонять код через SonarQube / другие анализаторы. Тут важно то что вы не можете как на фрилансе или может в некоторых компаниях выполнить задачу / заказ чтобы его приняли и забыть про неё. Когда вы сами из своего кармана платите за свои ошибки, когда вам нужно оплачивать сервера помощнее - очень мотивирует написать более оптимальный отказоустойчивый код, даже если предыдущее решение было неплохим ) В общем нужен тестовый полигон и реальные вызовы, придется пройтись по всем граблям и в процессе вы найдёте красивые способы их обходить. Будете читать какой-нибудь refactoring.guru статьи по архитектуре и сразу понимать где в вашем проекте их можно применить. Стоит быть готовым к тому что будет плохо получаться и не опускать руки, отдыхать и возвращаться с новыми силами.
Дальше в идеале все-таки устроиться работать в команду с хорошими спецами и там перенимать их опыт.
https://habr.com/ru/companies/alconost/articles/341304/