731 — “Шапочка из фольги”

”Человек — единственное животное, способное краснеть. Впрочем, только ему и приходится. — Марк Твен”

731 — “Шапочка из фольги” — [18-Dec-2020]

Hosts:
— Arina
— Игорь
— MeIr

Вводное:
Может будет стрим после подкаста — CoD
— Если Вам вдруг хочется добавить тему в обсудить — не обязательно регистрироваться на сайте

О себе:
— Professional Scrum Developer certificate
— TFSA allows USD deposits ( и почему не стоит говорить с людьми )

ShowNotes:
Сезон охоты на пиратов открыт
Журналист из Норвегии решил узнать, кто и как именно следит за ним через приложения на смартфоне
Учёные создали дрон Smellicopter использующий усики бабочки для навигации по запахам
Даешь коммунизм в Европе к 2030 году
США запустила платформу для наблюдения за всем миром со спутника даже сквозь стены
OSX on Amazon EC2

731 — “Шапочка из фольги”: 5 комментариев

  1. Так-с. Сейчас буду свои мысли извергать.

    Женя как-то спрашивал как бы так деплоить свое приложение и менять версии.

    Был высказан вариан — ну просто папку меняй.

    В принципе такой вариант много кто раньше делал и его минус, в том что когда идет переименование веб-сервер может отдать 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 с новым конфигом и переключает все запросы сразу на новую версию.
    При таком подходе простоя не будет вообще, если говорить про сайт.

  2. Пришел вступиться за Константина и рассуждения про работу приложений.

    Довод — на телефоне много оперативки и процессора

    КонтрДовод — раньше устройства были слабее и мобильным разработчикам нужно тщательно следить за ресурсами, чтобы ничего не тупило.

    К пониманию того что значит тупит — если элемент интерфейса в течении 100 мс или околотого не отвечает, то пользователь сразу думает что все тупит.
    Поэтому нельзя на куче JS скриптах сделать сверх скорость. Небольшой лаг и пользователь думает, что все тупит.

    Сейчас устройства имеют кучу памяти, но нужно учитывать что современный iOS и Android кроме обработки приложений в фоне крутят еще кучу всего.

    Например:
    Постоянно работает Шагомер и пишет статистику
    Постоянно пишется статистика запуска приложений и экранного приложения.
    В айфоне гоняется маленькая нейросеть, чтобы делать быстрый поиск по фото.

    Отсюда вывод — памяти и процессора много, но нельзя ее всю забрать. Современные прошивки тоже требуют больше ресурсов.

    Поэтому нельзя все писать на кучке Javascript, который дико жрет процессор и память.

    По поводу адаптивной верстки и почему некоторые разделяют сайты:

    Адаптивная верстка это когда в Html страницу пихают сразу два слоя: один слой виден только для мобильной, второй только на компьютере и иногда еще отдельно версия для планшета.

    По итогу получается что если данных много в плане структуры html будет в три раза больше данных, которые нужно постоянно гонять.

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

    Также был пример — ну вот хабр простой сайт.
    А теперь посмотрим на мобильную версию хабра и видим, что на мобильной версии комментарии внутри поста не показываются сразу.
    Ибо их там может быть 500 штук. И как вот в адаптивной верстке вывести 500 комментариев сразу? все это грузить?
    писать кучку обработок по частичной загрузке?
    Поэтому там и разделена мобильная версия — чтобы там верстка была только для мобильного и не грузить те блоки, которые показываются на десктопе.

    Отсюда и получается так что мелкие вордпресс сайты адаптивны.
    А там где крупные сайты иногда разделяют версии. Ибо у крупных сайтах обычно  один rest api и два разных фронтенда. И там фронтендеры не мучаются
    как комбинировать все эти слои и отображение.

    Я когда адаптивную верстку правил или дополнял ее понимал что это процесс не простой.

    Как говорится в том меме:
    Поверьте!!! Я сама быдлокодер, пишу тут на ПХП  под wordpress. Просто поверьте, — у нас не все так однозначно… Никто не хочет мучаться с адаптивной версткой.

    1. Ну с версткой по большинству согласен. Опыт есть и в корпоративе и персональный.
      Стоит раскладывать только если очень много информации, но тогда нужно 7 раз подумать о самом UI и зачах — можно упростить процессы (в бизнесе) и уменьшить UI — тогда проблема решается на корню.

      На работе у нас перенасыщенный UI, бизнес решил проблему просто — если ты реально оформляешь заказы — то делай это или с компьютера или с планшета — телефон не поддерживаем! В итоге адоптивная верстка на деле заточена на маленькие разрешения и большие, но не на очень маленькие.

       

    2. По поводу мобильных приложений.

      Понятно что не все должно быть на JS — согласен с твоими доводами. Однако большинство прикладных приложений могут быть написаны на JS. Например: календарь, почта, программа подсчета калорий и другие программы по менедженту. Явно CoD не будет писать на JS, но большинство програм (в частности что мы пишем) — они не ресурсо-емкие. И тут я ещё раз нападу на Костика — нет, ни кто не пишет обработку транзакция на телефоне! Даже банковские приложения на телефон не нуждаются в нативности приложения. Я бы сказал что с бансковскими и другими подручными приложениями JS имеет не только смысл, но ещё и полную выгоду. За место того что бы 2 команды разрабатывало приложение под iPhone & Android, лучше одна команда, один проект, одно приложение.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.