”Человек — единственное животное, способное краснеть. Впрочем, только ему и приходится. — Марк Твен”
731 — “Шапочка из фольги” — [18-Dec-2020]
Hosts:
— Arina
— Игорь
— MeIr
Вводное:
— Может будет стрим после подкаста — CoD
— Если Вам вдруг хочется добавить тему в обсудить — не обязательно регистрироваться на сайте
О себе:
— Professional Scrum Developer certificate
— TFSA allows USD deposits ( и почему не стоит говорить с людьми )
ShowNotes:
— Сезон охоты на пиратов открыт
— Журналист из Норвегии решил узнать, кто и как именно следит за ним через приложения на смартфоне
— Учёные создали дрон Smellicopter использующий усики бабочки для навигации по запахам
— Даешь коммунизм в Европе к 2030 году
— США запустила платформу для наблюдения за всем миром со спутника даже сквозь стены
— OSX on Amazon EC2
Так-с. Сейчас буду свои мысли извергать.
Женя как-то спрашивал как бы так деплоить свое приложение и менять версии.
Был высказан вариан — ну просто папку меняй.
В принципе такой вариант много кто раньше делал и его минус, в том что когда идет переименование веб-сервер может отдать 502 ошибку и прочие радости, ибо
клиент в эту секунду пытался дергать страницу.
В больших энтерпрайз и всяких стартапах на вопрос как деплоить все сразу выбирают Кубернетис.
Там все это делается так:
Делаем докер образ.
В Кубернетис кластере делаем сервис.
Для этого сервиса есть такая вещь как deployments. Это когда одна версия сервиса меняется другой.
И дальше Кубернетис умеет по умному подменять одну версию другой версией приложения.
Если интересно можно на ютубе видосики посмотреть.
https://www.youtube.com/watch?v=aavsiTbL9zc
В этом варианте только один минус: Нужен managed kubernetes. Ибо самому такое поднимать очень тяжко и муторно.
В твоем случае я вижу такие варианты деплоя:
Собрать контейнер с новой версией.
Поменять docker-compose.yaml и указать новую версию контейнера
docker-compose up -d в папке и оно перезапустит контейнер и пользователи увидят новую версию.
Минусы — по факту это все то же, как и с заменой папок, ибо в течении 1-10 секунд может отображаться пустая страница.
Второй вариант:
В приложении все запросы на изменение данные обернуть в какую-то функцию и реализовать режим read only.
При включении этого режима пользователь может все смотреть, но при попытке хоть что-то в данных изменить пользователю выдается сообщение «Извините идут технические работы, временно нельзя вносить изменения».
А дальше сделать так:
nginx reverse proxy, который перекидывает запросы в docker.
Скриптом в docker на старой версии включается режим read only.
Параллельно запускается новая версия приложения с docker-compose
Делается копия базы данных или важных данных.
После запуска новой версии nginx делает nginx -s reload с новым конфигом и переключает все запросы сразу на новую версию.
При таком подходе простоя не будет вообще, если говорить про сайт.
Напомни к какой дискусии это относиться? Я забыл что я говорил.
Пришел вступиться за Константина и рассуждения про работу приложений.
Довод — на телефоне много оперативки и процессора
КонтрДовод — раньше устройства были слабее и мобильным разработчикам нужно тщательно следить за ресурсами, чтобы ничего не тупило.
К пониманию того что значит тупит — если элемент интерфейса в течении 100 мс или околотого не отвечает, то пользователь сразу думает что все тупит.
Поэтому нельзя на куче JS скриптах сделать сверх скорость. Небольшой лаг и пользователь думает, что все тупит.
Сейчас устройства имеют кучу памяти, но нужно учитывать что современный iOS и Android кроме обработки приложений в фоне крутят еще кучу всего.
Например:
Постоянно работает Шагомер и пишет статистику
Постоянно пишется статистика запуска приложений и экранного приложения.
В айфоне гоняется маленькая нейросеть, чтобы делать быстрый поиск по фото.
Отсюда вывод — памяти и процессора много, но нельзя ее всю забрать. Современные прошивки тоже требуют больше ресурсов.
Поэтому нельзя все писать на кучке Javascript, который дико жрет процессор и память.
По поводу адаптивной верстки и почему некоторые разделяют сайты:
Адаптивная верстка это когда в Html страницу пихают сразу два слоя: один слой виден только для мобильной, второй только на компьютере и иногда еще отдельно версия для планшета.
По итогу получается что если данных много в плане структуры html будет в три раза больше данных, которые нужно постоянно гонять.
Кроме того для фронтендеров начинаются мучения как все аккуратно скомпоновать, чтобы вся эта каша из слоев корректно выводилась.
Также был пример — ну вот хабр простой сайт.
А теперь посмотрим на мобильную версию хабра и видим, что на мобильной версии комментарии внутри поста не показываются сразу.
Ибо их там может быть 500 штук. И как вот в адаптивной верстке вывести 500 комментариев сразу? все это грузить?
писать кучку обработок по частичной загрузке?
Поэтому там и разделена мобильная версия — чтобы там верстка была только для мобильного и не грузить те блоки, которые показываются на десктопе.
Отсюда и получается так что мелкие вордпресс сайты адаптивны.
А там где крупные сайты иногда разделяют версии. Ибо у крупных сайтах обычно один rest api и два разных фронтенда. И там фронтендеры не мучаются
как комбинировать все эти слои и отображение.
Я когда адаптивную верстку правил или дополнял ее понимал что это процесс не простой.
Как говорится в том меме:
Поверьте!!! Я сама быдлокодер, пишу тут на ПХП под wordpress. Просто поверьте, — у нас не все так однозначно… Никто не хочет мучаться с адаптивной версткой.
Ну с версткой по большинству согласен. Опыт есть и в корпоративе и персональный.
Стоит раскладывать только если очень много информации, но тогда нужно 7 раз подумать о самом UI и зачах — можно упростить процессы (в бизнесе) и уменьшить UI — тогда проблема решается на корню.
На работе у нас перенасыщенный UI, бизнес решил проблему просто — если ты реально оформляешь заказы — то делай это или с компьютера или с планшета — телефон не поддерживаем! В итоге адоптивная верстка на деле заточена на маленькие разрешения и большие, но не на очень маленькие.
По поводу мобильных приложений.
Понятно что не все должно быть на JS — согласен с твоими доводами. Однако большинство прикладных приложений могут быть написаны на JS. Например: календарь, почта, программа подсчета калорий и другие программы по менедженту. Явно CoD не будет писать на JS, но большинство програм (в частности что мы пишем) — они не ресурсо-емкие. И тут я ещё раз нападу на Костика — нет, ни кто не пишет обработку транзакция на телефоне! Даже банковские приложения на телефон не нуждаются в нативности приложения. Я бы сказал что с бансковскими и другими подручными приложениями JS имеет не только смысл, но ещё и полную выгоду. За место того что бы 2 команды разрабатывало приложение под iPhone & Android, лучше одна команда, один проект, одно приложение.