Connect with us

Статьи

Групповые видеозвонки: 7 сервисов на замену Skype

Организовать удаленную работу можно по-разному: использовать Slack или мессенджеры, сервисы для организации задач или устраивать регулярные созвоны. При организации видеоконференций стабильность и надежность связи напрямую влияет на качество совместной работы.

Анна Гуляева

Опубликовано

/

     
     

Skype хоть и остается популярным, но в силу своих не проходящих ошибок и непонятных изменений постепенно сходит со сцены. Какие еще существуют программы для организации видеозвонков на большое количество человек? В этой статье семь сервисов, которые позволят вам организовать встречу – даже на расстоянии.

Zoom

Сервис позволяет бесплатно организовать конференцию до 100 участников. Один участник выступает в роли организатора и приглашает в звонок остальных людей, которым даже не обязательно иметь учетную запись. В бесплатном плане длительность конференции — до 40 минут, платные тарифы позволяют общаться неограниченно долго, а также позволяет управлять записями пользователей, назначать организаторов самостоятельно и создавать отчеты.

Appear.in

В Appear.in один организатор создает комнату, в которую по ссылке могут войти до 4 участников или до 12 в платной версии. Участие в конференции не требует регистрации или загрузки приложения. Appear.in поддерживает функцию показа экрана и доступен с любого устройства.

GoToMeeting

В сервисе можно создать свою комнату, в которой можно составлять расписание звонков. Групповые звонки в базовом тарифе поддерживают до 10 участников и функцию показа экрана. Все тарифы в GoToMeeting платные: 19, 29 и 49 долларов в месяц.

BlueJeans

Платное решение для организации видеозвонков до 100 участников, а также более масштабных событий и вебинаров до 15 тысяч человек. Систему BlueJeans можно использовать в пробной версии 30 дней. Самый дешевый тариф стоит 12,49 долларов в месяц и позволяет устраивать конференции до 50 человек.

Discord

Изначально созданный как мессенджер и голосовой чат для геймеров, Discord сейчас поддерживает функцию групповых видеозвонков. Одновременно могут общаться до 10 участников, и во время звонка можно использовать показ экрана. Скачивать программу необязательно, запускать звонки можно из окна браузера.

Slack

Платная версия Slack поддерживает создание групповых видеозвонков до 15 человек. Помимо основной функции, Slack можно интегрировать и с другими сервисами для видеоконференций, например, appear.me, Skype или BlueJeans.

Join.me

Бесплатная версия join.me позволяет создавать видеоконференции до 3 участников, а платные версии — до 10 человек. Стоимость платных версий — 20 и 30 долларов в месяц.

Видеоконференции в мессенджерах

Видеоконференции доступны и в ряде распространенных мессенджеров. В конце 2016 года функция появилась в Facebook Messenger: общаться по видео могут до 6 человек, но в целом к группе может присоединиться до 50 человек — в таком случае видно будет только организатора звонка.

Видеоконференцию до 10 участников можно организовать также в Google Hangouts. Во время звонка нельзя поделиться изображением экрана, но можно отправлять файлы и изображения в чат. Для звонка нужен только аккаунт Google, и общаться через Hangouts можно как из браузера, так и из приложений для компьютера, Android или iOS.

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Аналитика магазинов

Как iOS и Android разделили мобильный рынок

Ходят легенды, что раньше на рынке мобильных устройств было много операционных систем, и они делили рынок на примерно равноценные части… AppCraft рассказывает о том, как было все на самом деле, и что происходит с платформами сейчас.

AppCraft

Опубликовано

/

Автор:

Беглый поиск в Google позволил найти занимательную информацию о том, что первые изменения начались в недалеком 2010-ом. В августе того года на geektimes опубликовали статью с заголовком “Android вырвался на 3-е место по продажам на рынке мобильных ОС”, и в комментариях помимо баталий начались предсказания даты, когда Android захватит мир.

Выглядел переходный момент вот так:

Распределение операционных систем проданных смартфонов за 2 кв. 2010 года

Диаграмма показывает статистику по проданным смартфонам по всему миру за второй квартал 2010 года от исследователей из Gartner, а к апрелю 2011 года компания Nielsen подбила статистику по США, что позволяет нам сегодня легко определить ту самую отправную точку успеха Android:

Распределение операционных систем проданных смартфонов в США в марте 2011 года:

Распределение операционных систем проданных смартфонов в США в марте 2011 года

И уже в августе 2011 года аналитики Сanalys опубликовали информацию о том, что Android захватил половину рынка, став самой распространенной платформой среди пользователей смартфонов.

Распределение мирового рынка операционных систем в 2011 году

Заканчивая небольшую историческую справку, скажу, что даже сооснователь Apple Стив Возняк в том же 2010 году в интервью De Telegraaf беспристрастно заявил, что Android станет доминирующей платформой, поэтому назвать текущее положение дел на рынке удивительным не получится – тенденция к этому была очень наглядной и устойчивой.

Распределение операционных систем в 2017 году

На сегодняшний день Android сохраняет лидерские позиции по количеству пользователей в мире с большим отрывом от других участников рынка. Однако в ряде стран показатели сильно расходятся со среднестатистическими данными. Статистический сервис StatCounter удобно демонстрирует результаты аналитики рынка мобильных операционных систем с разбивкой по месяцам, странам и другим параметрам. Вот так распределялись платформы по рынку за последний год:

На долю Android приходится 73.54% рынка, на iOS – 19.91%, оставшиеся 6.5% распределены между другими системами.

Но если взять данные за этот же промежуток времени – с декабря 2016 по декабрь 2017, но по Канаде, то мы увидим совсем иное распределение:

Именно такие нюансы нужно учитывать при выборе платформы для разработки вашего приложения. Подобные графики можно посмотреть на StatCounter по миру, Европе, Африке, Азии и некоторым крупным странам за период с 2009 по 2017 год.

Платежеспособность iOS и Android пользователей

Финансовые возможности пользователей двух основных операционных систем регулярно сравнивают практически все аналитические фирмы в сфере IT. Из года в год результаты меняются не кардинально, но проследить некоторую динамику в существующих изменениях можно. Исследовательская компания App Annie наглядно продемонстрировала, что несмотря на рост скачиваний приложений из Google Play, платить за контент пользователи Apple готовы значительно больше.

Количество загруженных приложений

Количество потраченных денег

Говоря о динамике, хочется обратить внимание на разрыв в выручке между App Store и Google Play – он почти не сокращается. Здесь и раскрывается вопрос платежеспособности владельцев девайсов на этих платформах.

Разберемся подробнее:

  1. Число загрузок из App Store за год практически не изменилось, а пользователи Android стали скачивать больше приложений.
  2. За второй квартал 2017 года из Google Play было загружено 17 миллиардов приложений – на 135% больше, чем из App Store за тот же период. Разница в количестве скачиваний между операционными системами по сравнению с прошлым годом увеличилась практически на 30%.
  3. Пользователи iOS при том же количестве загрузок стали платить за контент гораздо больше, а траты владельцев Android увеличились незначительно.

Вывод получается однозначным: пользователи iOS тратят больше денег на покупки в мобильных приложениях, хотя скачиваний на Android больше в 2,5 раза.

Так для какой платформы разрабатывать приложения?

До запуска рекламной кампании сложно предсказать, какая именно платформа принесет больше прибыли для конкретного приложения. Выбор платформы в первую очередь должен быть связан с идеей вашего приложения и его целевой аудиторией. Причем целевой аудиторией в широком смысле: важен не только возраст и интересы, но и регион проживания, ведь где-то соотношение iOS к Android практически 1/1.

Монетизация приложений для двух описанных платформ разная: как мы выяснили, пользователи техники Apple тратят больше денег на покупки в приложениях, поэтому приложения, подразумевающие премиум–аккаунты, внутренние покупки и прямую монетизацию пользователя в приложении, стоит разрабатывать скорее для iOS.

В то же время столбец с доходами Google Play не на нуле. Мы уже писали, что пользовательское внимание сегодня стоит дорого, поэтому самым простым и популярным способом вывода в прибыльность Android–приложений является реклама. Когда ваше приложение скачивают миллиарды пользователей, найти рекламодателей, желающих урвать хотя бы 15 секунд внимания своей целевой аудитории, не сложно.

В результате, все зависит от рынка, на который вы выходите. Разрабатывать приложение можно сразу на две операционные системы, если у вас уже есть аудитория – например, когда речь о корпоративном продукте. Но мы всегда советуем своим заказчикам для начала разработать MVP продукта на одну платформу – это удобно сразу по нескольким причинам: чем скорее запустится проект, тем быстрее можно будет понять его востребованность, выявить сильные и слабые стороны, и, естественно, сэкономить деньги.

Комментарии
Продолжить чтение

Разработка

Почему структура команды разработки может вас замедлять

Выход новой функции опять затянулся? Дело может быть в неэффективной структуре команды разработки. В этой статье собраны признаки того, что вам пора задуматься об изменении распределения ответственности.

Анна Гуляева

Опубликовано

/

“Почему мы так медленно выпускаем новые функции так медленно?” — думал я спустя год после присоединения к быстро растущему стартапу. Релиз каждой новой функции был болезненно долгим. Это не то, чего я ожидал — стартапы должны двигаться быстро. Особенно, если вы ещё не нашли свою нишу. В начале моей работы у нас было три команды разработки. Спустя год и несколько миллионов инвестиций у нас в распоряжении было девять команд разработки. Наша способность к разработке утроилась, но новые функции выходили с той же скоростью. В чем же дело? Я думаю, что дело было в законе Брукса, который утверждает, что добавление новых разработчиков в проект на поздней стадии, приводит к ещё большему замедлению проекта. Мы наняли многих отличных разработчиков, но им нужно было понять что замедляло остальных сотрудников.

Наш мотивирующий постер для разработчиков

Спустя полгода мы по-прежнему выпускали новые функции медленно. Поэтому, очевидно, закон Брукса был уже не при чем. Должна была существовать ещё одна причина, но какая? Потом мы столкнулись с проблемой в производстве, которая указала мне на возможного виновника.

Проблема и урок

Мы только выпустили новую функцию фильтрации по тегам. Поддержка получала жалобы о том, что функция не работает. Первым делом я попытался загрузить картинку и отметить её как “Не хот-дог”. Потом я попробовал отфильтровать картинки по этому тегу и убедился, что фильтрация не работает. Я составил список команд, которые участвовали в создании функции. Каждая команда была ответственна за свой компонент:

  1. Загрузка и обработка изображений.
  2. Elasticsearch.
  3. Фронтенд фотоальбома.
  4. Команда DevOps, ответственная за инфраструктуру и развертывание новых функций в облаке.

Я решил сначала поговорить с командой по загрузке изображений. Я спросил руководителя команды, почему их функция не работала. Он посмотрел, что теги были сохранены и предположил, что они не были проиндексированы, что привело меня к команде Elasticsearch. Разработчик из следующей команды заглянул в Elasticsearch. Тег был проиндексирован, все выглядело отлично. Поэтому он отправил меня к команде фронтенда альбома. Они обнаружили, что фронтенд-библиотека была развернута в более старой версии. Функция фильтрации зависит от этой библиотеки, поэтому это, вероятно, было причиной проблемы. Фронтенд-команда посоветовала мне поговорить с командой DevOps, чтобы они развернули нужную библиотеку. Я устал ходить от одной команды к другой и сказал им, чтобы они сразу исправили эту проблему. Наконец проблема была решена. Я понял, что командам не хватало ответственности за то, что они создавали. Команды были разбиты по компонентам, и никто из них не чувствовал ответственности за функции – каждый работал только над маленьким кусочком пазла. Разбитие команд по компонентам сделала быстрый выпуск новых функций сложным. Все их усилия были тесно связаны. Если одна из четырех команд не работала или задерживалась, это влияло на выпуск всего функционала.

Почему компании начали разбивать команды по компонентам?

В начале разработки продукта команды часто самостоятельно разбиваются по компонентам. Если сам продукт пока не имеет структуры, то технические компоненты для его работы понятны. Поэтому команды проще организовать по этим компонентам. Эта идея довольно проста — каждая команда ответственна за один или более компонентов. Такая структура помогает увеличить продуктивность разработчиков, которые работают над конкретными частями системы. Создание чего-то нового на Amazon RedShift? Только одна команда должна беспокоиться об изучении RedShift. Недостаток таких команд заключается в том, что менеджеры должны беспокоиться о выпуске функций. Границы между командами создают зависимости, которые требуют активного управления. Это возможно, если у вас не так много компонентов или функции не распределены между множеством команд. Представьте, что вы владелец продукта и хотите внедрить Feature 2,  как на картинке ниже. Она зависит от двух компонентов, за которые отвечают разные команды. Функция выйдет, только если обе команды завершат необходимую работу над своими компонентами. Вернемся к примеру с фильтрацией тегов. Так как даже причину неисправности было сложно установить, представьте, как неэффективно было заставлять все эти команды координироваться ради одной маленькой функции. Любая задержка в любом компоненте вызывала задержку релиза функции. Чем больше компонентов и команд вовлекалось в дело, тем больше возникало проблем с координацией и вынужденного ожидания. Если один спринт одной команды проваливается, функция не может быть выпущена.

Альтернатива: команды по функциям

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

Переход к командам по функциям

Многие команды начинают с команд по компонентам, потому что структура продукта неясна в начале существования проекта. Но в какой-то точке команды по компонентам могут начать вас тормозить. Вот симптомы, которые подскажут вам, что ваша структура вас замедляет:

  1. Разработка небольших функций занимает больше времени, чем вы ожидали, потому что они находятся в зонах ответственности разных команд.
  2. При возникновении проблем все показывают пальцем друг на друга. Никто не несет ответственность за функцию.

Если это происходит, вам стоит рассмотреть переход на команды по функциям. Такая работа имеет свои сложности: вам нужно будет придумать лучшее распределение компонентов между командами и подстроить свою архитектуру, чтобы разъединить как можно больше компонентов. Переход к командам по функциям — это самая сложная часть работы с подобной структурой. Как структурировать команды? Как передавать знания? Как убедиться, что организация разрешит вам изменить структуру? Этому будет посвящена уже другая статья.    https://apptractor.ru/develop/myi-uvolili-nashego-luchshego-razrabotchika.html https://apptractor.ru/info/articles/vyi-uvolili-luchshego-razrabotchika-nadeyus-vyi-dovolnyi.html  

Комментарии
Продолжить чтение

Программирование

Создание анимации в 7 строк кода

Android-разработчик Леонардо Пирро рассказывает, как создать простую анимацию при помощи ConstraintLayout и ConstraintSet.

Анна Гуляева

Опубликовано

/

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

ConstraintLayout + ConstraintSet

Я хочу поделиться с вами новым способом создания анимаций в приложении при помощи всего семи строк кода, используя Keyframe Animations, ConstraintLayout и ConstraintSet. Эта концепция заключается в создании двух разных макетов: одного для начальной точки и одного для конечной точки анимации. Давайте посмотрим, что мы хотим создать: наша цель — создать плавную анимацию детали, которая будет появляться при нажатии пользователем на экран.

Анимация создается при помощи двух файлов макета: circuit.xml and circuit_detail.xml. Эти макеты очень похожи и различаются только тем, что на первом элементы вынесены за экран, а на втором — находятся в нужной позиции.

Поэтому давайте создадим анимацию и увидим, как просто создавать анимацию при помощи ConstraintLayout и ConstraintSet.

Пусть магия произойдет

Сначала создадим отдельный ConstraintSet, куда мы скопируем ограничения второго макета, вызвав метод clone():

val constraintSet = ConstraintSet()
constraintSet.clone(this, R.layout.circuit_detail)

Теперь создадим объект перехода, используемый для установки интерполятора и продолжительности анимации:

val transition = ChangeBounds()
transition.interpolator = AnticipateOvershootInterpolator(1.0f)
transition.duration = 1200

Сейчас вызовем TransitionManager.beginDelayedTransition(), который используется для осуществления перехода на следующий кадр рендеринга. Затем мы вызываем applyTo(), чтобы начать анимацию.

TransitionManager.beginDelayedTransition(constraint, transition)

constraintSet.applyTo(constraint)

Это действительно семь строк кода. Вот и все! Вы можете посмотреть полный пример в моем репозитории GitHub по этой ссылке.

Комментарии
Продолжить чтение

Статьи

Как лучшие руководители сочетают два подхода к видению мира

Что общего между Генри Фордом и Биллом Гейтсом? Дело в сочетании двух подходов к своей работе, которое могут применять люди любых профессий, считает основатель рассылки Design Luck Зат Рана.

Анна Гуляева

Опубликовано

/

Когда Microsoft впервые представила Windows, это не произвело особого шума. Первая версия вышла в 1985 году и почти не привлекла внимания. В последующие годы популярность начала расти, но только в начале 1990-х система начала набирать обороты.

Несколько первых десятилетий существования Microsoft Билл Гейтс был очень вовлечён в каждый аспект своего бизнеса. Первые пять лет существования компании он просматривал каждую строчку кода лично. Компании несколько раз крупно повезло, но даже если учесть это, то вряд ли люди, отличающиеся от Гейтса, смогли бы развить Microsoft до нынешнего размера.

То же самое касается Стива Джобса. Многие его коллеги рассказывали о его маниакальном внимании к мельчайшим деталям. Теперь мы можем видеть, как это вывело Apple на вершину.

Теперь их подходу во многом следует Илон Маск. Он создал уже не одну компанию, обладающую потенциалом изменить мир. Интересно, что около 80% своего времени он проводит, работая над дизайнерскими и инженерными проблемами.

Фокус на деталях

Безусловно, лидер должен мыслить глобально. Мы предполагаем, что на высшем уровне руководители либо устраняют крупные проблемы, либо заключают крупные сделки. Это часть работы CEO.

Но любопытно, что успех многих самых влиятельных лидеров в истории можно отследить до мельчайших и, казалось бы, неважных вещей. Это относится ко всем людям – от Томаса Эдисона, Альфреда Слоуна и Генри Форда до Гейтса, Джобса и Маска.

Так, например, в биографии Маска Эшли Вэнс рассказывает о письме, которое он лично отправил каждому сотруднику SpaceX. Это было предупреждение о чрезмерном употреблении аббревиатур. Маск посчитал, что это выходит из-под контроля и может в будущем привести к неэффективной коммуникации, если создание новых слов и смыслов продолжится. Этот человек работает от 80 до 100 часов в неделю над революционными проектами, и довольно необычно, что он потратил час или два, чтобы написать о такой небольшой проблеме.

В этом и заключается секрет. Маск может видеть эффекты второго и третьего порядка, которые возникают от таких незначительных вещей. Аббревиатуры кажутся безвредными, но в конечном счёте они могут вызвать значительное нарушение в коммуникации внутри компании.

Эффект формирующего

Рэй Далио — основатель крупнейшего хедж-фонда в мире Bridgewater Associates. В своей книге он поделился тем, что провел несколько лет за анализом того, что делает некоторых людей более эффективными в достижении больших результатов при управлении крупными компаниями. Многие преемники людей, вроде Джобса или Гейтса, справляются не так хорошо, и чтобы избежать того же для своей компании, он хотел лучше понять, что отличает таких людей. Далио разработал тесты для понимания людей, которых он нанимает, их сильных и слабых сторон.

Чуть позже он пригласил Гейтса и Маска пройти некоторые из этих тестов, как и других людей, достигших уникального успеха. Он обнаружил, что многих из этих людей можно назвать «формирующими», и их особенность заключается в том, что они сильны как в стратегических, так и в тактических вопросах. Они эффективны и в работе над небольшими деталями, и в разработке глобальных планов, которые будут вести их на протяжении долгого времени.

Что это значит?

В зависимости от того, чем вы занимаетесь, у вас, скорее всего, одна способность развита сильнее другой. Если вы работаете в некоммерческой организации с людьми, которым вы помогаете, вы, вероятно, сильны в тактике и сконцентрированы на том, чтобы все ваши небольшие шаги были правильными. Если же вы топ-менеджер в банке, то вас наняли для разработки стратегии и видения на годы и десятилетия вперёд.

В обеих позициях все равно стоит посмотреть на другую сторону. Если вы объедините оба подхода, вы сможете увидеть вещи, которые не видят другие. Это расширит ваше поле зрения и взгляд на мир.

 

Комментарии
Продолжить чтение

Постеры для разработчиков

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.