Сергей Горностаев, справедливости ради, там не 2 часа, вникание в классы-представления, написание собтсвенных тэгов, валидирование форм, админ панель и много чего еще, если изучать это неповерхностно, занимает довольно много времени.
Ладно, перефразирую вопрос: стоит ли учить часть, связанную с формами, шаблонами и прочим околофронтедерским набором инструментов для бэкендера в современных реалиях?
Я к тому, работают ли сегодня бэкендеры с шаблонами, классами представлений, формами и прочими инструментами на стыке фронтенда и бэкенда? Все базовые вещи, вроде моделей и настроек важных, я не имею в виду.
Ноут erchips travel. Нет, блютуз наушники с вай ваем идеально работали, к тому же через ifconfig wireless адаптер отдельно стоит, а в lsusb блютуз адаптер тоже отдельно. Сам ноут видит мышь, но отказывает в сопряжении, думаю, проблема связана именно с операционкой, но в убунту я новичок, так что полез за ответами сюдаб
Максим Федоров, то есть фронтендер просто посредством js кода обращается к апи бэкенда и получает всю инфу для страницы оттуда? Это, я так понимаю, через ajax запросы?
VoidVolker, Да яп свой я уже, мне кажется, достаточно изучил. Следующая ступень - это выполнение реальных задач, которые есть только при выходе на полноценную работу, на которых знание фреймворков обязательно.
VolgaVolga, ну допустим у меня есть вьюшка с get аргументами page и type. Следовательно, ссылка, чтобы эта вьюшка сработала, будет: ...href="{url 'some_url'?page=2&type=1}". Так как фронтендер поймет название урла и аргументов? Бэкендер ему просто говорит: "Ну значица, если ссылку на это хошь, название урла такое, а аргументов - такое"?
Значит ли это, что фронтедер должен под каждый фреймворк учить использующийся для него шаблонизатор?
Justa Gain, Ну да, так и есть. Я же говорю, моя ошибка происходит из-за того, что в представлениях и формах идет обращение к бд. Я же хочу, чтобы миграции выполнились, не затрагивая корректность определения форм и представлений. Можно вообще такое сделать?
ValdikSS, то есть правильно ли я понимаю, что этот метод реализуется следующим образом:
Есть какой то сервер со статичным айпи в сети. Два компьютера из разных сетей подключаются к этому серверу и благодаря нему идентифицируют друг друга и покидают этот сервер. А потом они строят все взаимодействие чисто между собой на основе той инфы, которую им дал тот самый промежуточный сервер в сети, используя те самые STUN и TURN методы?
hint000, Думаю, мне достаточно знаний того, как работает NAT. Но ведь вроде при запросе на сервер с белым айпи локальный адрес и порт клиента переписываются под нужды провайдера. Приходит запрос с серого айпишника провайдера к сервису, сервис просто отправляет ответ на серый айпишник провайдера и определенный порт, привязанный к локальной сети, из которой пошёл запрос, то есть для сервера условного серый айпишник и определенный порт - это адрес конечного клиента. Далее пакет получает локальная сеть. Далее в таблице маршрутизации маршрутизатор уже сам понимает, какому устройству какой пакет был предоставлен. Тут всё логично, ибо в данном случае для ответа определенному клиенту серверу нужен инициатор подключения, который сразу говорит свой более точный ЗАнатовский адрес, который гарантирует доставку на точный адрес клиента.
Но при контакте серого и серого айпи всё ведь ломается. Изначально, даже отправив запрос на серый айпи адрес инициативно, произойдет ошибка, ибо маршрутизатор провайдера отклонит этот запрос за незнанием того, кому именно отправлять запрос.
Вопрос про второй случай. Как они могут связаться друг с другом напрямую, имея только айпи адрес, если у них серые айпишники. Для этого кто то должен быть инициатором подключения к серому айпи адресу, когда такое невозможно, в первом варианте, я так понял, работает что-то по типу туннелирования запросов, верно?
То есть фактически вместо localhost я могу привязать сокет и к адресу сетевого адаптера в моей локальной сети, устаговленного в моей машине? Скажем, к 192.168.0.100?
