Мобильные приложения это все-таки отдельная история. Определенное пересечение с веб-фронтендом конечно есть, например React Native близок к React.js, а некоторые мобильные приложения включают в себя части веб-приложений в виде WebView. На этом можно построить много всего, однако и ограничения тоже есть. Для некоторых задач эти ограничения могут оказаться существенными, так что придется или писать какие-то нативные компоненты, или вообще писать все приложение целиком на нативных технологиях под каждую платформу. Оптимальный выбор технологий для разных проектов может быть разным.
Стоит ли изучать разработку под андроид – зависит от вас :) Если интересно, так почему бы не попробовать.
нет :) Боюсь, не получится объяснить в рамках комментария, слишком обширная тема. Может как-нибудь соберусь статью накатать на эту тему. А может вы свою накатаете, и разобьете эти предрассудки в пух и прах
Каждый, разумеется, вкладывает в этот термин что-то свое. Мне близко определение из википедии, которое по запросу "Коммуникация (психология)" перенаправляет на статью Общение:
сложный многоплановый процесс установления и развития контактов между людьми (межличностное общение) и группами (межгрупповое общение), порождаемый потребностями совместной деятельности...
В этой фразе "проблемы коммуникации" понимаются в более широком смысле, нежели чем какие-то ситуационные сложности с перепиской или звонками. Здесь имеются в виду любые виды проблем, когда одному человеку не удается грамотно, вовремя и достаточно убедительно донести свою мысль другому, например:
Постановка целей - когда менеджмент не может ясно донести команде зачем все это делается;
Работа с требованиями - когда их составитель провел недостаточно хорошую работу по выяснению нужд пользователей;
Оценка рисков - когда команду разработки вообще не спрашивали насколько это сложно сделать, или же ей не удалось убедительно донести свою мысль;
Оценка текущего состояния проекта - когда менеджмент плохо представляет себе реальное положение дел;
Командное взаимодействие - когда люди не могут конструктивно решить возникшие между ними разногласия;
... и т.д.
Если вы взглянете на "проблемы коммуникации" именно в таком, более широком смысле, то да, окажется что они скрываются за большинством проблем проектов.
Прямого аналога папкам и индивидуальным правилам для фильтрации сообщений в слеке нет, это все-таки другой формат общения. Что тут есть:
Каналы у всех одинаковы, но каждый пользователь сам выбирает в какие каналы подключаться, может сгруппировать их у себя удобным ему образом, и настроить режим оповещений индивидуально для каждого канала;
Также есть довольно богатые глобальные настройки оповещений, в которых можно настроить свой список ключевых слов, расписание, оповещать ли об ответах в тредах и другое;
В каждом канале сообщения можно добавлять в закладки, как персональные (Saved items) так и глобальные для всех (Pin to channel);
Сообщения можно помечать обратно как непрочитанные, чтобы вернуться к ним позже;
Можно отправлять сообщения самому себе. Например, пересылать самому себе какие-то сообщения чтобы вести там архив, или просто писать какие-то заметки для себя.
В телеграм-чатах - да, полностью согласен. В Slack ситуация получше обстоит. Способ организации каналов, треды, то как работает поиск, как сообщения отмечаются прочитанными, закладки - в целом, ситуация заметно лучше по сравнению с телеграммой, на мой взгляд.
Тем не менее, даже со всякими улучшениями формат чата плохо подходит для использования его в качестве вики, документации, таск-треккера или чего-то подобного - для этого есть свои специализированные инструменты. Например, инструкцию по развертыванию проекта лучше все же хранить в Readme в репозитории проекта, ну а в чат можно скинуть ссылку если кто спросит.
Discord - сам не пользовался пока, но слышал хорошие отзывы. MS Teams - пользовался, чат (на мой вкус) сильно проигрывает слеку. Зато у MS Teams на удивление неплохие видео-митинги
Электропочта все-таки отличается от чата, потому что для прочтения каждого письма нужно сделать клик. В чате все сообщения идут подряд и мы их просто скроллим. Разница вроде и небольшая, но привычки в использовании меняет очень сильно. Я порой тоже попадаю в копию длинных переписок в электропочте и это реально боль. Но в чате другая история, там не так.
У нас их несколько. Размеры команд мы стараемся держать небольшим, в идеале не более 5-6 человек. Если команда разрастается, значит разбиваем на две, выделяя каждой свою область ответственности, свой канал в чате, проект в таск-треккере, итд.
Среди наших клиентов есть организации в которых несколько сотен человек, но и там такой же подход - все делятся на относительно небольшие команды.
На мой взгляд, самый большой "барьер в общении" - то что многие люди просто не хотят общаться. Или стесняются, или боятся выглядеть неловкими, или им не кажется это важным, или же просто не хотят утруждаться.
Я имел в виду и то и другое, да :) Но вообще, я уже не раз натыкался на исследования о том что записи от руки более полезны для мозга, например - https://pubmed.ncbi.nlm.nih.gov/28536546/
Впрочем, и у компьютерных заметок тоже есть свои преимущества, самое яркое на мой взгляд - ими просто поделиться с другими.
... накат миграций через liquibase при старте приложения на проде будет выключен средствами конфигурации. А в конфигурации для локального окружения разработчика он будет включен. И будет всё очень удобно
+1, отличный вариант.
Конечно, есть старая програмистская мудрость, что надо стремиться чтобы окружение разработки было максимально приближено к продакшену. Однако, в современных реалиях веб-разработки абсолютно точного сходства прямо во всем-всем-всем добиться очень сложно, да и не нужно. Касательно ОС, версий библиотек и фреймворков - без проблем, дело важное и нужное, тем более что системы сборки и всякие докеры значительно упростили задачу, грех не пользоваться.
Однако, когда дело касается инфраструктуры - на мой взгляд, стремиться к точному сходству не стоит. В продакшене у нас может быть Kubernetes, а локально - Docker Compose, и это нормально. В продакшене приложение запускается в нескольких экземплярах, а локально - в один, и это хорошо. В продакшене миграции запускаются одним образом, а локально - другим, и так удобнее.
Наверняка можно при помощи настройки закрутить конфигурацию так, чтобы по сути отказаться от параллельного запуска новых инстансов и запускать их последовательно и строго по одной попытке.
Даже если риск с повторными миграциями и уйдет, на мой взгляд это неоправданная жертва, которая серьезно затормозит процесс раскатки новой версии, и которой можно легко избежать, заменив запуск миграций на старте приложения запуском их отдельно перед началом раскатки на кластер.
CI/CD в статье упомянут только в контексте накатки миграций в проде. Это только способ запуска, который никак не ограничивает какой фреймворк для миграций будет использован. Я абсолютно ничего не имею против flyway, liquibase и любых других инструментов. Речь всего лишь о том, как их запускать.
В окружении разработчика, разумеется, CI/CD не нужен. Мы же не пытаемся обеспечить там zero-downtime, верно? И вообще, зачем пытаться запускать окружение разработчика на кластере и за балансировщиком нагрузки?
Каким образом flywaydb, при запуске в виде <run-db-migrations> && <launch-the-app>, в Kubernetes или другом оркестраторе (ECS, Swarm, ...), в случае сбоя миграции на первом инстансе остановит дальнейшую раскатку приложения, которая выполняется одновременно и параллельно на нескольких инстансах?
Там же не только про то, что нельзя чтобы в один момент времени работало несколько миграций. Там еще и про ретрайи, поэтому меня настораживает фраза у flywaydb про "Auto-migration on startup". Наверняка существуют окружения в которых это допустимо, но если у нас традиционное веб-приложение на кластере - то я бы так не рисковал.
А что бы вы посоветовали?
Мобильные приложения это все-таки отдельная история. Определенное пересечение с веб-фронтендом конечно есть, например React Native близок к React.js, а некоторые мобильные приложения включают в себя части веб-приложений в виде WebView. На этом можно построить много всего, однако и ограничения тоже есть. Для некоторых задач эти ограничения могут оказаться существенными, так что придется или писать какие-то нативные компоненты, или вообще писать все приложение целиком на нативных технологиях под каждую платформу. Оптимальный выбор технологий для разных проектов может быть разным.
Стоит ли изучать разработку под андроид – зависит от вас :) Если интересно, так почему бы не попробовать.
нет :) Боюсь, не получится объяснить в рамках комментария, слишком обширная тема. Может как-нибудь соберусь статью накатать на эту тему. А может вы свою накатаете, и разобьете эти предрассудки в пух и прах
Каждый, разумеется, вкладывает в этот термин что-то свое. Мне близко определение из википедии, которое по запросу "Коммуникация (психология)" перенаправляет на статью Общение:
В этой фразе "проблемы коммуникации" понимаются в более широком смысле, нежели чем какие-то ситуационные сложности с перепиской или звонками. Здесь имеются в виду любые виды проблем, когда одному человеку не удается грамотно, вовремя и достаточно убедительно донести свою мысль другому, например:
Постановка целей - когда менеджмент не может ясно донести команде зачем все это делается;
Работа с требованиями - когда их составитель провел недостаточно хорошую работу по выяснению нужд пользователей;
Оценка рисков - когда команду разработки вообще не спрашивали насколько это сложно сделать, или же ей не удалось убедительно донести свою мысль;
Оценка текущего состояния проекта - когда менеджмент плохо представляет себе реальное положение дел;
Командное взаимодействие - когда люди не могут конструктивно решить возникшие между ними разногласия;
... и т.д.
Если вы взглянете на "проблемы коммуникации" именно в таком, более широком смысле, то да, окажется что они скрываются за большинством проблем проектов.
Прямого аналога папкам и индивидуальным правилам для фильтрации сообщений в слеке нет, это все-таки другой формат общения. Что тут есть:
Каналы у всех одинаковы, но каждый пользователь сам выбирает в какие каналы подключаться, может сгруппировать их у себя удобным ему образом, и настроить режим оповещений индивидуально для каждого канала;
Также есть довольно богатые глобальные настройки оповещений, в которых можно настроить свой список ключевых слов, расписание, оповещать ли об ответах в тредах и другое;
В каждом канале сообщения можно добавлять в закладки, как персональные (Saved items) так и глобальные для всех (Pin to channel);
Сообщения можно помечать обратно как непрочитанные, чтобы вернуться к ним позже;
Можно отправлять сообщения самому себе. Например, пересылать самому себе какие-то сообщения чтобы вести там архив, или просто писать какие-то заметки для себя.
Вот, например, статья на Forbes с отсылками к нескольким исследованиям и опросам - от PwC, IBM, PMI, HBR.
В телеграм-чатах - да, полностью согласен. В Slack ситуация получше обстоит. Способ организации каналов, треды, то как работает поиск, как сообщения отмечаются прочитанными, закладки - в целом, ситуация заметно лучше по сравнению с телеграммой, на мой взгляд.
Тем не менее, даже со всякими улучшениями формат чата плохо подходит для использования его в качестве вики, документации, таск-треккера или чего-то подобного - для этого есть свои специализированные инструменты. Например, инструкцию по развертыванию проекта лучше все же хранить в Readme в репозитории проекта, ну а в чат можно скинуть ссылку если кто спросит.
Discord - сам не пользовался пока, но слышал хорошие отзывы. MS Teams - пользовался, чат (на мой вкус) сильно проигрывает слеку. Зато у MS Teams на удивление неплохие видео-митинги
Электропочта все-таки отличается от чата, потому что для прочтения каждого письма нужно сделать клик. В чате все сообщения идут подряд и мы их просто скроллим. Разница вроде и небольшая, но привычки в использовании меняет очень сильно. Я порой тоже попадаю в копию длинных переписок в электропочте и это реально боль. Но в чате другая история, там не так.
У нас их несколько. Размеры команд мы стараемся держать небольшим, в идеале не более 5-6 человек. Если команда разрастается, значит разбиваем на две, выделяя каждой свою область ответственности, свой канал в чате, проект в таск-треккере, итд.
Среди наших клиентов есть организации в которых несколько сотен человек, но и там такой же подход - все делятся на относительно небольшие команды.
На мой взгляд, самый большой "барьер в общении" - то что многие люди просто не хотят общаться. Или стесняются, или боятся выглядеть неловкими, или им не кажется это важным, или же просто не хотят утруждаться.
Я имел в виду и то и другое, да :) Но вообще, я уже не раз натыкался на исследования о том что записи от руки более полезны для мозга, например - https://pubmed.ncbi.nlm.nih.gov/28536546/
Впрочем, и у компьютерных заметок тоже есть свои преимущества, самое яркое на мой взгляд - ими просто поделиться с другими.
Если приложение уже не использует колонку и при этом она не nullable, то вставки новых записей в эту таблицу будут блокированы.
+1, отличный вариант.
Конечно, есть старая програмистская мудрость, что надо стремиться чтобы окружение разработки было максимально приближено к продакшену. Однако, в современных реалиях веб-разработки абсолютно точного сходства прямо во всем-всем-всем добиться очень сложно, да и не нужно. Касательно ОС, версий библиотек и фреймворков - без проблем, дело важное и нужное, тем более что системы сборки и всякие докеры значительно упростили задачу, грех не пользоваться.
Однако, когда дело касается инфраструктуры - на мой взгляд, стремиться к точному сходству не стоит. В продакшене у нас может быть Kubernetes, а локально - Docker Compose, и это нормально. В продакшене приложение запускается в нескольких экземплярах, а локально - в один, и это хорошо. В продакшене миграции запускаются одним образом, а локально - другим, и так удобнее.
Наверняка можно при помощи настройки закрутить конфигурацию так, чтобы по сути отказаться от параллельного запуска новых инстансов и запускать их последовательно и строго по одной попытке.
Даже если риск с повторными миграциями и уйдет, на мой взгляд это неоправданная жертва, которая серьезно затормозит процесс раскатки новой версии, и которой можно легко избежать, заменив запуск миграций на старте приложения запуском их отдельно перед началом раскатки на кластер.
CI/CD в статье упомянут только в контексте накатки миграций в проде. Это только способ запуска, который никак не ограничивает какой фреймворк для миграций будет использован. Я абсолютно ничего не имею против flyway, liquibase и любых других инструментов. Речь всего лишь о том, как их запускать.
В окружении разработчика, разумеется, CI/CD не нужен. Мы же не пытаемся обеспечить там zero-downtime, верно? И вообще, зачем пытаться запускать окружение разработчика на кластере и за балансировщиком нагрузки?
Каким образом flywaydb, при запуске в виде
<run-db-migrations> && <launch-the-app>, в Kubernetes или другом оркестраторе (ECS, Swarm, ...), в случае сбоя миграции на первом инстансе остановит дальнейшую раскатку приложения, которая выполняется одновременно и параллельно на нескольких инстансах?Там же не только про то, что нельзя чтобы в один момент времени работало несколько миграций. Там еще и про ретрайи, поэтому меня настораживает фраза у flywaydb про "Auto-migration on startup". Наверняка существуют окружения в которых это допустимо, но если у нас традиционное веб-приложение на кластере - то я бы так не рисковал.
поправил. К сожалению, вместе с исправлением пришлось убрать искрометную фразу про "трехфазный деплой", жаль...