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

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

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

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

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

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

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