Gagatyn

Бtз проблем такое делается на haproxy.
Делаем два acl-а со списком ip-адресов и со списком url-ов. На эти два акла и проверяем, посылая на нужные запросы 404.

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

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

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

Все же зависит от постановки задачи, т.е. если прототип Ваш и его можно корректировать, то некоторые моменты я бы поправил. А если прототип утвержден, а Вам нужно отрисовать интерфейс, то и об удобстве рассуждать не приходится :)
По существу: заголовки слева меня смущают больше всего, но если таблица не очень широкая, а заголовки в одно слово, то вариант. Если мы о веб, то на трубках все равно придется сделать заголовки над таблицей, так чего тянуть?)
С текстом под таблицей не вижу проблем, главное стили: текст инфоблока нельзя отделять линией (бордером) от строки, иначе потеряется принадлежность. По этой причине таблица должна быть без вертикальных бордеров, иначе получится ужас. Сам текст инфоблока можно заключить в какой-то "бабл", который будет указывать на строку. И тогда все будет прилично выглядеть даже если строчек 100 (можно еще закрывать инфоблок, при открытии другого, но если они большие - страница будет дергаться).
Что касается взаимодействия, то поведение чекбокса немного не логично. Как правило сначала пользователь должен увидеть подсказку, а потом уже сделать выбор. Если это не тест, то можно выводить инфоблок тултипом при наведении на чекбокс, а по клику "раздвигать" строку и оставлять инфоблок на виду.

Советы могли бы быть более конкретными, если было бы понимание, что за продукт, где используется, кем :)

let [data, setData] = useState([]);
useEffect(() => { setData(getNews()); }, []);

У тебя в data попадет промис.

Всё-таки использовать async/await следует, только разобравшись с промисами и вообще с асинхронностью...

мало понимать, как работает код - нужно понимать, как работает бизнес

1) Не берется чужая реклама. Тебе то кто заплатит, если ты рекламу воруешь xd
есть набор рекламодателей, каждому ты говоришь 1 доллар за просмотр.
Он присылает тебе рекламу - ты ротируешь её, платишь 0.6$ юзеру, 0.4 себе в карман
2) ??? какая разница в контексте твоего вопроса? Хоть биткоины принимай. Что удобнее будет рекламодателю и юзеру
3) сразу ему говори сколько дашь за просмотр, зачем говорить сколько за него получишь ты и сколько положишь себе в карман
4) накрутка реальна и спокойно реализуема, это будет бесконечная борьба тебя как разраба и юзера как хацкера
начиная виртуальными машинами заканчивая просто арбитражем
5) не востребован, сейчас вся реклама интегрирована напрямую во всё - youtube, mobile apps, ну кому такое нужно из рекламодателей если тебе похвастаться будет нечем и ты делаешь велосипед в принципе

peace

В репозитории на Github необходимо создать новую ветку с именем 'gh-pages' . Перейти в Settings репозитория, пролистать страницу вниз до GitHub Pages и в настройках указать данную ветку.
И еще в gulpfile.js нужно прописать путь, где находится скомпилированный проект, примерно так

const gulp = require('gulp');
const ghPages = require('gulp-gh-pages');

gulp.task('deploy', function() {
    return gulp.src('./dist/**/*')
        .pipe(ghPages());
});

где dist - это папка с готовой компиляцией проекта
И все заработает.

Сделай таску в package json.
gulp build - такска из галпка для сборки проекта, gh-pages -d build автоматически создаст ветку gh-pages, и закинет в нее собраный проект и изменит все настройки, что остается просто только открыть сайт по ссылке.

Перед этим создай репозиторий, и соедени удаленный с локальным.

"scripts": {
    "deploy": "gulp build && gh-pages -d build"
  },

Если знаешь англ, тут подробно объясняется как все легко настроить
https://www.youtube.com/watch?v=SKXkC4SqtRk&ab_cha...

Привет,
Словосочетание "правильная разработка" порождает лишь неразбериху.
К примеру, ты делаешь какой-то компонент на фронте, на бекенде довольно стандартный CRUD. Но ты можешь сделать один метод Edit, а можешь сделать два метода Create и Update. И то и то правильно в зависимости от ситуации. Дальше, к примеру в методе Create у тебя проставляются пользователь, создавший запись и какое-то ещё поле, которое заполняется на бекенде. При этом, можно использовать одну и ту же модель во всех методах, Details/Create/List/Update. При этом, в метод Create попадёт модель с лишними полями, тот же пользователь, создавший запись. Кто-то скажет, это неправильно, нужно под все методы делать свои модели, если поля не используются, не должно быть возможности их передать. А кто-то скажет, неправильно плодить лишние сущности, пусть поле не используется, оно всё равно на бекенде перезаписывается. А кто-то скажет, что вообще не нужна даже одна промежуточная сущность, можно использовать сущность, которая генерится каким-нибудь инструментом с БД, так как проект представляет собой закрытую админку для внутреннего пользования.
Немного сумбурно, но, надеюсь, понятно.
Дальше идёт расхождение в инструментах, к примеру, требуется делать валидацию входящей модели. Можно использовать Fluent валидацию или использовать декларативный синтаксис через Data Annotation. И то правильно и это правильно, в одном проекте, разумеется, должно использоваться что-то одно, но подход и синтаксис различаются очень сильно. Или так же, необходимо использовать IoC/DI, а инструментов под это несколько и все правильные.
Что касается архитектуры. Опять же, есть несколько подходов и несколько стилей. Нельзя сказать, что один из них правильный, а другой неправильный. Я видел несколько отвратительных проектов, написанных в ООП стиле. При этом, не могу сказать. что подход неправильный и нет хороших проектов, написанных по такому принципу. Я видел огромный проект, отлично написанный в процедурном стиле со слоёной архитектурой контроллер/модель/интерфейс/сервис/энтити. Даже представить себе не могу, если бы его попытались сделать в Domain Driven Design или в компонентном стиле, типа микросервисов.
В общем, нет в этом деле серебряной пули.
Что касается основных "правильных" вещей. Есть спецификации языка и им надо следовать. Если взять, к примеру, ангуляр. То в нём есть свои стандарты, есть сайт с документацией, в которой прописаны правила наименований и прочее. Им надо следовать. Если взять .net, то при выходе новой версии, вместе с ней выходит и спецификация на новые фишки. Так же, в нормальных проектах ведётся свой файл со спецификацией, в котором указаны, в каком порядке следует размещать публичные/приватные поля, что один публичный класс должен быть в отдельном файле и имя файла должно совпадать с именем класса. Так же, при выходе новой версии IDE, под .net это visual studio, внутрь уже встраиваются подсказки, например, если ты написал класс с маленькой буквы, студия это подчеркнёт и укажет, что наименование класса должно быть в PascalCase. В общем, этому надо следовать. Могу скинуть свои файлы на почту.
Могу так же скинуть свой проект на гитхабе, но, как я уже говорил, не факт, что архитектура из того проекта подойдёт, когда вы придёте в другую разработку, там архитектор скажет "это неправильно, мы не так делаем"

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

1. «Реальная» разработка часто полный антоним «правильной». Причин тому много: фантастические дедлайны, талантливые сотрудники, проверенный временем легаси код, эффективные менеджеры. Худший код, с которым я сталкивался, был в самых дорогих b2b энтерпрайз решениях — реальнее некуда.

2. Перечисленные фреймворки к вопросу не приложились, но т.к. в тегах жаваскрипт, будем считать, что реакт.

Из последнего, на что натыкался, мне понравился Doctocat — это сделанный в Гитхабе шаблон для Gatsby. На мой взгляд, это реально классный пример интеграции реакт-компонент. Используется в продакшене, так что реальная разработка, все дела.

На что обратить внимание:

– Собственно компоненты, их композиция.
– Как задается тема (цвета, шрифты), и как это попадает в стили
– Интеграция с third parties: подсветка кода, поиск
– Кастомизация: через shadowing и всякий ad-hoc
– Работа с MDX, реэкспорт layouts и т.п.

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

Ну и да, не бывает идеальной архитектуры, везде свои плюсы и минусы.

С радостью отвечу на вопросы, тут же есть ЛС, правда?

Удачи!

Скачать PyCharm он сам создает джанго проект.
https://www.jetbrains.com/pycharm

Эти картинки отсутствуют на сервере, потому что никто их туда не кладёт. Сервер(webpack devserver) работает не от локальной папки, а от структурированного как описано в конфиге результата сборки. Сделайте build и посмотрите в папку dist: именно так и выглядит структура файлов на сервере.

Вы можете положить эту папку с картинками туда использовав copy-webpack-plugin. Если на сервер эта папка будет класться вручную и в прод. dist она вам не нужна - можете подключать этот плагин только для develpment.
Альтернативно вы можете настроить devserver (используя before/after), чтоб он просто отдавал файлы из этой папки по соответствующему запросу(читая их содержимое вручную средствам node fs).
Главное не забыть потом положить эту папку на сервер руками.

можно ли получиться полезную информацию с дампа памяти?

"полезный" - категория относительная. И то, что будет полезно мне, может оказаться совсем неинтересно Вам. И наоборот, конечно же.
Например программа xcomutil (для игры UFO Defence: Enemy Unknown 1996 года) показывает относительные координаты вражеского юнита и его состояние. Для того, кто играет в нее - это бесценная инфа. Для того, кто не играет - она совершенно бесполезна :)

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

Вот пример(ы) для освоения:

for(let i=0; i<=65; i++) {
  console.log(i + ' % 26 == ', i % 26);
}

Запустите в консоли, и сразу станет легко осваиваться.