yaja time что это
Сервис видеозвонков HUAWEI MeeTime уже доступен российским пользователям
HUAWEI объявила, что в России стал доступен сервис для видео- и голосового общения HUAWEI MeeTime. Помимо поддержки видео до 1080p, за счёт интеграции в ОС и оптимизации на аппаратном уровне приложение обеспечивает качественное изображение даже при слабом освещении и низком качестве связи.
HUAWEI MeeTime уже доступен на некоторых смартфонах, планшетах и ряде других устройств компании. Для запуска приложения необходимо войти в систему с помощью HUAWEI ID, выбрать контакт, имеющий устройство с поддержкой MeeTime, и нажать кнопку видеовызова. Используя сервис, можно быстро переключать текущий видеозвонок с фирменного смартфона на умный экран HUAWEI Vision S. В скором времени российским пользователям MeeTime станет доступна функция видеоконференций.
HUAWEI MeeTime поддерживает технологию Link Turbo, которая анализирует поведение пользователей и состояние сетей Wi-Fi и 4G, определяет оптимальную с точки зрения скорости загрузки и автоматически переключается между ними. Встроенные в HUAWEI MeeTime алгоритмы распознавания лиц и коррекции видео в реальном времени обеспечивают качественную картинку даже в условиях низкой освещённости. Также можно задействовать специальные эффекты. Например, если картинка слишком тёмная, пользователь может включить виртуальное освещение, просто нажав иконку лампочки на экране. Конфиденциальность во время общения обеспечивает технология сквозного шифрования, которая работает по умолчанию.
В настоящее время в России MeeTime доступен на смартфонах HUAWEI nova 8, HUAWEI P30, P30 Pro, HUAWEI P40, P40 Pro, P40 Pro+, HUAWEI nova 5T, планшетах HUAWEI MatePad Pro 12,6, MatePad 11, MatePad Pro 10,8 (2021), MatePad M6, MatePad Pro 1,8 (2019) и смарт-экранах HUAWEI Vision S. С 25 августа голосовые вызовы с помощью MeeTime можно будет делать со смарт-часов серии HUAWEI WATCH 3.
Как заполнить 100 таймшитов за 2 минуты
Пост о том, почему наши программисты теперь заполняют таймшит не 32, а только 2 минуты и о том, как можно наладить автоматический учет рабочего времени за счет импорта данных из трекинговых систем TFS, Redmine и Jira на Microsoft Project Server.
Статья будет интересна менеджерам проектов, руководителям компаний-разработчиков, а также программистам, интересующимся интеграцией различных систем управления проектами.
Проблема — бардак в заполнении таймшитов
Для 99% компаний-разработчиков учет рабочего времени программистов нужен как воздух, чтобы считать затраты. Поэтому многие заставляют сотрудников заполнять таймшиты (timesheet, своего рода — табель учета рабочего времени). Часто это подразумевает заполнение вручную таблицы с задачами и потраченным на них временем.
99% программистов, мягко говоря, недолюбливают эту процедуру. Еще бы, отличная перспектива для пятничного вечера — минут 30 сидеть и тупо копипастить все свои задачи за неделю из трекинговой программы в таймшит. А, как известно, когда люди делают тупую и ненавистную работу, то результат бывает так себе. Вот и в нашей компании половина таймшитов в пятничный вечер были далеки от совершенства. В чем это выражалось?
В первую очередь в том, что таймшиты не отражали всех «боевых» задач, которые решали разработчики. Программист мог написать, что просто все 40 часов работал по такому-то проекту. Или мог задачи из одного проекта по ошибке отнести в таймшите к другому.
Для борьбы со всем этим беспорядком прекрасная сотрудница из проектного офиса (фотография которой, несомненно, украсила бы статью, но публиковать ее мы все-таки не будем) нежно, но неотступно прессинговала 100 человек половину рабочего дня в понедельник. Потом по длинному чек-листу проверяла 1200 табличных строк всех таймшитов. И только ко вторнику руководство имело полную картину.
Результат: с задержкой в 3 рабочих дня руководители, наконец, получали отчет по затраченному рабочему времени за прошлую неделю.
Как было. Процедура сбора таймшитов.
Более трех дней
Решение — автоматизация процесса заполнения таймшитов
Решение проблемы выкристаллизовалось постепенно. Мы рассуждали так. Если программист всю свою работу фиксирует в трекере, то почему бы не брать данные о задачах и количестве рабочих часов прямо оттуда? Это позволит быстро получать информацию для анализа трудозатрат, кадрового документооборота и других менеджерских задач. Дальше дело было за малым — найти красивое технологическое решение по интеграции наших трекеров с системой, в которой мы учитываем рабочее время (Microsoft Project Server — подробнее о нем здесь).
Как стало. Процедура заполнения таймшитов
До 100 штук за 2 минуты!
Максимальное время сбора данных — 2 часа 10 минут.
Что мы получили?
Надо сказать, что волшебство работает только у тех, кто всю неделю соблюдал технологию ведения проектов в трекере: фиксировал задачи, а также планируемое и фактическое время на их выполнение. Эти хорошие ребята в пятницу получают плюсик в карму и автоматическое заполнение таймшита.
Автоматически заполненный таймшит
Бонусы волшебной кнопки
1. Сэкономили 200 рабочих часов
Если раньше у сотрудника на заполнение таймшитов уходило 30-40 минут, то сейчас 2 минуты. А если пересчитать на 100 человек в месяц, то мы сэкономили около 200 рабочих часов.
Сюда можно добавить еще 32 рабочих часа, которые уходили на проверку правильности заполнения таймшитов, вместо которых теперь уходит только 4 часа в месяц. Экономия времени объясняется просто: теперь в таймшиты выгружаются реальные задачи из трекеров, а не те, которые люди вбили руками.
2. Оперативно получаем аналитику по проектам за неделю
Теперь в 19:00 в пятницу полностью заполнены 91% таймшитов, и у менеджеров есть аналитика трудозатрат по проектам уже в конце недели. Раньше к этому времени было собрано меньше половины.
Пятница, 19:00. Количество полностью заполненных таймшитов
3. Привели к единообразию стандарты ведения всех проектов
Теперь во всех трекинговых системах все проекты, клиенты и прочие данные обозначены единообразно. Везде проставлены цифры по запланированному и фактическому времени на выполнение задач. А это уменьшает наши риски и повышает управляемость проектов.
4. Упростили контроль того, как соблюдается технология ведения проектов
Раньше, чтобы понять, как ведется проект, нужно было вручную заглянуть в трекер. Теперь контроль происходит автоматически при отправке таймшита. Например, если в Redmine не проставлены статусы задач и время на их выполнение, то эти задачи просто не выгрузятся в таймшит. И наоборот, если проектный офис видит правильно заполненный таймшит — это подтверждает, что его автор заполнил все поля в трекинговой программе.
По факту на выходе мы получили реинжиринг всего бизнес-процесса. Оборудовали работу так, как удобно нам, с нашими комплексными большими проектами.
5. Получаем аналитику по любым параметрам уже в пятницу
Если раньше аналитика за прошлую неделю приходила к менеджерам только во вторник-среду, то теперь уже в конце текущей недели, вечером в пятницу, 90% информации по таймшитам собрано. На основе ее выстроен OLAP-куб.
Сколько багов за неделю было исправлено? Сколько часов ушло на каждый из проектов? Где возникли узкие места и почему? Анализировать данные теперь можно более оперативно. Но это не предел. В следующий раз мы расскажем о том, как можно получать сводные данные по всем проектам из трекеров в режиме реального времени при помощи усовершенствованной версии нашего OLAP-куба.
А сейчас подробности, мясо и куски кода.
Автоматизация бизнес-процесса по шагам
Шаг 1. Стандартизировали ведение проектов в разных трекинговых системах
Сложность задачи заключалась в том, что в компании для управления разными по технологической начинке проектами используются три разных трекера (системы для управления проектами). Это продиктовано требованиями с точки зрения технологий и спецификой самих проектов.
| Управление проектами в отделах разработки — специализированные трекинговые системы | Учет рабочего времени и анализ бизнес-процессов в компании |
| TFS — для отдела технологий Microsoft. | Microsoft Project Server — система для управления портфелями проектов |
| Jira — проектами, в которых заказчик тоже пользуется системой Jira. | |
| Redmine — для отдела мобильных технологий, Java-разработчиков и дизайнеров. |
Стандарты ведения проектов в разных трекерах немного отличались. К примеру, для разных проектов могли быть приняты разные воркфлоу. Или комплексный проект для одного и того же заказчика мог в отделе мобильной разработки (в Redmine) называться, условно, «Мобилка для крутого клиента N», а в отделе веб-разработки (в TFS) «Внутренний сайт компании N».
Для интеграции весь этот зоопарк пришлось причесать — обеспечить, чтобы в каждой системе одинаковым проектам давалось идентичное название, везде было указано время выполнения задач и применялась общая методология ведения.
На уровне технологий это потребовало прикрутки некоторых возможностей к самим трекерам. Например, в TFS нет колонки, в которую можно вписать количество часов, которое ты потратил на задачу в определенную дату.
Шаг 2. Написали страницу, которая импортирует записи в MS Project Server
Расскажем, как можно сделать такую страницу. Наметим краткий план того, что нужно:
2.1. Кнопочка.
Давайте рассмотрим, как можно расширить интерфейс MS Project Server. Поскольку, как всем известно, MS Project Server работает поверх MS SharePoint Server, можно воспользоваться возможностями последнего, чтобы добавлять различные элементы в интерфейс MS Project. В частности, нам нужно было, чтобы пользователь запускал импорт непосредственно из страницы с таймшитом. Для этого в Ribbon таймшита можно добавить специальную кнопочку и связать ее с соответствующим действием. Для того чтобы иметь возможность развернуть это в MS SharePoint необходимо создать Feature, который содержит элемент типа Custom Action.
Внутри этого CA определяем соответствующее расширение.
Собственно, это довольно хорошо известно.
Единственная проблема, которая может возникнуть — как вычислить упомянутый Location. Мы хотим, чтобы кнопка появилась здесь.
Информации в интернете по этому вопросу не так много, поэтому основным источником информации и является файл pwaribbon. Файл довольно большой, но разобраться в нем можно. После того как мы нашли нужный Location, все просто:
Добавляем в него кнопку.
И определяем соответствующую команду.
Как видно из приведенного кода, команда просто перенаправляет пользователя на соответствующую страницу типа ApplicationPage. Эта страница, которую мы написали сами. Собственно внутри нее и происходят все дальнейшие «грязные» дела.
2.2. Чтение данных
Тут возникло две проблемы:
1. Как авторизоваться в трекерах для получения данных.
2. Как сопоставить пользователя MS Project с пользователем трекинговой системы.
Глобально тут можно выделить 2 подхода. Забегая вперед, скажем, что нам пришлось применить оба подхода для разных трекеров:
В случае Redmine все просто — в Redmine есть функция Log Work, которая работает ровно так, как нужно. То есть человек может зайти в задачу и отметить, сколько часов он потратил на задачу такого-то числа.
Дальше дело техники — сделать представление в базе данных Redmine (у нас Redmine использует MySQL), и все готово. Задача решена, мы можем получить данные.
В случае с системой TFS все чуть сложнее. Такой возможности, как в Redmine, в ней нет. Есть определенные Add-In’ы, которые ее дают, например, www.tfs-timetracker.com — вещь интересная, хотя и недешевая.
Но можно к этой задаче подойти с организационной точки зрения. Как? В TFS есть поле Completed Work, в которое разработчики должны записывать суммарно потраченные часы на задачу. В шаблонах проектов типа Scrum такое поле скрыто, но его можно отобразить. Далее по истории изменений Work Item можно отследить изменение этого поля и понять, когда добавлялись часы, когда, кем и сколько времени было потрачено. Конечно это требует очень плотной работы с трекером со стороны разработчика. Он не может зарепортить время задним числом, но, тем не менее, если все делать вовремя и аккуратно, то такой подход очень неплохо работает. Более того, он заставляет разработчиков вести себя более дисциплинированно.
JIRA
В нашем случае JIRA «хостится» в стороннем окружении. Поэтому ни суперпользователя, ни доступа к ее БД у нас нет. Но зато в JIRA есть замечательный REST API, который предоставляет то, что нужно (https://docs.atlassian.com/jira/REST/cloud/ ).
Чтобы считать данные, нужно авторизоваться по протоколу OAuth. После запуска импорта из JIRA человек перенаправляется на страницу авторизации JIRA, авторизуется там (если пользователь еще не авторизован), после чего возвращается на страницу импорта.
(К сожалению JIRA поддерживает только OAUTH 1, который на текущий момент немного староват, но прорваться можно.) Получив OAUTH token мы:
1. Вытаскиваем имя автора методом
И таким образом никакого сопоставления имен не надо, мы просто берем пользователя, который залогинился в JIRA.
2. Далее ищем все задачи, для которых пользователь залогировал время в определенный период.
На первый взгляд, это все, что нужно, но не совсем. MS Project поддерживает работу в режиме делегата, когда человек что-то делает от имени другого, и наши менеджеры активно этим пользуются. Здесь, конечно, случаются определенные коллизии, поскольку, если человек A олицетворяет в MS Project человека Б (обычно руководитель — подчиненного, либо ответственное лицо — сотрудника), то в JIRA он его не олицетворяет, а остается самим собой. И подобным запросом он получит задачи, назначенные на него самого, то есть на человека А, которые запишутся в timesheet человеку Б. Более того, к сожалению, нет метода (или мы не нашли его), чтобы получить все задачи по всем проектам, в которых указанный пользователь залогировал свои трудозатраты. И это еще не все — человек А вовсе может не иметь в JIRA соответствующих полномочий на чтение нужных задач. Впрочем, последний вопрос можно решить организационно.
Для того чтобы перебрать все задачи, приходится сначала получить все проекты методом:
Далее пробежаться по всем проектам и достать все задачи.
Для каждой найденной задачи получить залогированое время и выбрать то, что попадает в нужный период и принадлежат нужному автору.
В этом случае проблема сопоставления имен опять, конечно, весело встречает нас. Кроме того, такой процесс занимает очень много времени. Намного лучше, наверное, тут и не придумать, впрочем, если есть лучшее решение, были бы рады услышать.
2.3. Отображение данных.
Тут особо рассказать нечего — код на старом добром ASP.Net, который отрисовывает полученные данные.
2.4. Запись данных в Timesheet
Итак, мы перешли на специальную страницу, авторизовались, получили нужные записи, осталось записать их в MS Project. На самом деле у MS Project есть несколько видов API, но, поскольку мы работаем внутри него, мы использовали тот же самый, что используют страницы самого Project’a. API этот выглядит, скажем так, непривычно.
Например, чтобы считать ресурс, нужно вызвать метод.
И это вполне понятно, но потом придется провести еще много времени, пытаясь понять, где в этом DataSet нужная табличка, строка и колонка. Документации по этому вопросу довольно мало и, честно говоря, ни одного работающего с этим API примера добавления Timesheet Lines в Timesheet мы в интернете не нашли. Но, поковырявшись в «потрохах» MS Project Server с помощью ILSPY, мы в конце концов написали следующий код:
Этот код, собственно, и записывает нужные данные в MS SharePoint. Честно говоря, проблем при работе с MS Project было больше всего. Про это можно написать целую отдельную статью.
Шаг 3. Откатали технологию на тестовой группе пользователей.
30% сотрудников, и каждый раз перед полноценным запуском тренировались на небольшой группе из 3-5 «подопытных» пользователей, с которыми в спокойной обстановке проходили весь процесс и доводили его до production ready состояния, чтобы не получить в пятницу вечером шквал вопросов и негодования сразу от 30 человек.
Шаг 4. Собрали обратную связь
Что говорят сотрудники EastBanc Technologies о «волшебной кнопке» для заполнения таймшитов
Юрий Булкин, главный Java-архитектор.
Огонь. Когда я первый раз нажал кнопку и тут же увидел полностью заполненный таймшит — я просто глазам не поверил. Мне много раз говорили, что все будет так происходить. И я понимал, как это должно выглядеть. Но когда я сам получил автоматически заполненный двадцатью задачами таймшит, это было так круто, что я только тогда осознал все удобство этой штуки.
Александра Очеретинская, руководитель проектного офиса.
Мы поняли: то, что мы в пятницу заставляем программистов заполнять таймшиты — это неполезная, неинтеллектуальная деятельность. Мы требуем вручную вносить информацию, которая уже существует, просто в другом месте и в другом виде. И мы можем избавить людей от этой ненужной работы. Если люди в любом случае уже работают по задачам, которые заведены в трекерах, то почему бы просто не выгружать эту информацию для учета? Так мы и сделали.
Максим Подусов, инженер-программист.
Намного быстрее стал процесс заполнения таймшитов, минут на 30… Раньше было 32 минуты, а сейчас всего минуты 2.
Василий Лебедев, ведущий инженер-программист.
Классно! Меньше дублирующейся работы, больше детализация тасков. Смотришь, и таймшиты вовремя заполнять начну. 🙂
Ирина Мананникова, руководитель проектов
Конкретно в своей работе я избавилась от однообразного, рутинного ручного процесса еженедельной проверки таймшитов (трудозатрат). Быстрота заполнения таймшитов — это приятный бонус. А главной целью было — оперативно получать прозрачную и понятную картину по проектам в трекерах. Цель достигнута, в конце каждой недели у нас есть практически на 100% актуальная информация по каждому проекту по итогам прошедшей недели.
Практика работы со временем в разных часовых поясах в unix-like системах
Если ваше приложение зависит не только от локального времени, но и от его представлении в других часовых поясах, вы наверняка сталкивались со сложностью представления времени в разных временных зонах. Не сталкивались? Значит вы не портировали своё приложение в мир Unix.
Действительно, в ОС Windows для работы с временными зонами программисту предоставляется удобный набор специализированных функций WinAPI. Примером могут служить структура TIME_ZONE_INFORMATION и функция GetTimeZoneInformation к ней в придачу.
Но что делать, если вам необходимо знать смещение относительно UTC+0, правила перехода на «летнее время», учитывать при этом високосные годы с високосными секундами и прочую специфическую информацию для какого-нибудь региона, да всё это в unix-подобных операционных системах? Статья посвящена практике работы со всем этим барахлом на языке C/C++.
Эта тема неоднократно освещалась во многих статьях с разных точек зрения, но редко с практической на примерах конкретных языков, систем и технологий. Примеры можно найти на Stack Overflow (коих вопросов там огромное множество), да и на Хабре эту тему затрагивали достаточно глубоко, но с теоретической точки зрения. Кроме того, есть даже мини-исследование на тему локального времени, из которого можно почерпнуть, что проблема компьютерного времени совсем не тривиальна, какой кажется на первый взгляд. Проведя собственное расследование, я хотел бы кратко и доходчиво поделиться полученным немалым количеством сведений, оформив их в виде способов преобразования времени в разных часовых поясах.
Классика: стандартная библиотека языка C
Пример кода, использующего такой подход:
tz database, или жонглирование байтами
Использование в своих целях базы данных Олсона — наиболее предпочтительный вариант. Плюсы очевидны: база наиболее полным образом отражает все мыслимые правила переходов для любого уголка Земли (учитывая изменения в этих правилах с начала прошлого века), распространяется со многими системами (см. /usr/share/zoneinfo ) и имеет унифицированный формат, при этом база обновляется вместе с системой. Однако, попробовав поработать с ней, я решил отказаться и от этого варианта.
База распространяется в бинарном формате (для этого используется компилятор zic ). Описание формата можно найти в заголовочном файле tzfile.h (для его поиска воспользуйтесь официальным FTP базы). Инструментов для работы с базой я так и не нашел (возможно, плохо искал?). Но попробовав прочитать файлик нужной временной зоны, я столкнулся с проблемой интерпретации данных — во всех этих тонкостях и терминологии можно голову свернуть, забыв о цели всего этого копания. И, чтобы абстрагироваться от подобных мелочей, было решено пользоваться наиболее адекватным и удобным инструментом.
Boost.Date_Time
Как это часто бывает в подобных ситуациях, на помощь приходит именно boost. О широких возможностях набора библиотек Date_Time уже была статья, содержащая краткий перевод официальной документации. Кстати, хорошая новость для тех, кто не хочет вводить лишние зависимости в свой проект — библиотека является header-only (за исключением пары специфичных мест вроде создания объекта временной метки из строки определенного формата).
Для решения вопроса есть два пути: записывать правила для нужной временной зоны хардкодом в программе (и потом ненавидеть себя за это), либо хранить все правила в специальном файле CSV-формата. Такой файлик можно впоследствии автоматически обновлять (и поддерживать правила переходов в актуальном состоянии, что чрезвычайно важно). Файл распространяется с дистрибутивом boost’а (носит название date_time_zonespec.csv ), но может быть взят и из других мест. Плюс использования файла, кроме прочего, — в нём хранятся правила для всех регионов.
Без минусов тоже не обойдется. Что, если вам понадобится конвертировать ту временную метку, которая находится где-нибудь в начале двадцатого столетия, когда правила перехода были иными? Такие случаи тоже придется учитывать, и, к сожалению, boost здесь может мало помочь.
Для примера приведу код, использующий для конвертирования времени возможности набора библиотек Date_Time.
Чем ган-тайм отличается от чип-тайма
Ган-тайм считает время, которое бегун потратил на преодоление дистанции, и чип-тайм – тоже. Однако показания ган-тайма почти всегда существенно отличаются от записи в часах спортсмена. Почему так происходит, в чём разница между двумя понятиями и какое время считать объективным, разбираемся в этой статье.
Что такое ган-тайм
Ган-тайм (англ. gun time) – время на забеге, отсчитываемое от стартового выстрела, то есть от непосредственного начала гонки.
Если у организаторов есть подходящие возможности, вместо выстрела из пистолета производятся другие шумовые эффекты: выстрел из пушки, звон церковных колоколов и т.д.
Фото: boston.com
Что такое чип-тайм
Чип-тайм (англ. chip time) – личное время спортсмена, отсчитываемое с того момента, как он пересёк стартовую линию. Иногда его ещё называют «чистым временем», и именно оно показывает, сколько часов и минут атлет на самом деле потратил на преодоление своей дистанции.
С увеличением количества участников на забегах стали появляться кластеры, то есть отдельные блоки, позволяющие группировать бегунов по их способностям. Несколько тысяч атлетов стартовать одновременно с одной линии не смогут при всём желании. Поэтому в кластер А встают наиболее быстрые, в кластер B те, кто бежит чуть медленнее и т.д. Такое деление позволяет тихоходным бегунам не создавать проблем для более скоростных, а скоростным – не терять драгоценные секунды в попытках выбраться из медленной толпы.
Чем крупнее забег, чем больше атлетов стремится принять в нём участие, тем больше и количество кластеров. После стартового выстрела, когда уже пошёл отсчёт ган-тайма, основная масса участников ещё только продвигается пешком к стартовой линии. Добравшись до неё и перешагнув первый коврик с контрольной отметкой, можно нажимать кнопочку на часах, запуская собственный старт. С этого момента начинается чип-тайм.
Разница между ган-таймом и чип-таймом может достигать 40 и более минут, если участников очень много, а организаторы делают паузы между стартами кластеров.
Личный чип участник получает в стартовом пакете. Обычно чип сразу встроен в номер либо крепится куда-нибудь на тело. По всей дистанции будут встречаться специальные коврики с контрольными отметками, которые «схватывают» сигнал чипа с его уникальным кодом. Таким образом спортсмен «пингуется» на трассе. Обычно такие отсечки ставятся на разворотах или в тех местах, где есть соблазн срезать дистанцию.
Случайно повредить чип довольно сложно, однако организаторы всё-таки предупреждают о сохранении его целостности, чтобы результаты были объективны. Чип выдержит, если вы его уроните или если вас обольют водой (а на жарких забегах это обычная практика), будет работать в зной и в стужу, но специально мять его руками или ещё как-то повреждать не рекомендуется.
Тренировочные планы к марафону и полумарафону. Скачайте и начните подготовку сегодня.
Через некоторое время после финиша участник получает смс со своим результатом – это как раз чип-тайм, личное время атлета на забеге.
Победитель забега определяется чаще всего по ган-тайму. Поэтому претенденты на победу стартуют всегда из первых рядов. И даже если возникнет ситуация, что участник из дальнего кластера пробежит дистанцию с чистым временем быстрее всех – забег всё равно выиграет тот, кто первым пересёк финишную черту с момента стартового выстрела.
Впрочем, из этого правила есть исключения, поэтому лучше читать положение конкретного соревнования и ориентироваться на него. Чуть больше месяца назад в Санкт-Петербурге проходила гонка Ironman 70.3, где первое место занял Илья Слепов с результатом 4:00:14. Однако к финишу он пришёл не лидером, первым финишную черту пересёк Денис Крестин (4:02:12).
Илья, стартовав через 15 минут после Дениса, сумел показать лучшее время и в итоге стал победителем соревнований.