Спасибо. Беглый гуглеж показал что " В среднем, типичные часы реального времени могут иметь погрешность от 1,7 до 8,6 секунд в день.". Не ожидал, что все настолько плохо. Электронные наручные часы конца прошлого века обеспечивали лучшую точность. Непонятно почему не берут системное время синхронизируемое по NTP в этом случае.
Так таймер же у нас есть на обоих устройствах. Через час записи и устройство захвата видео и устройство захвата видео имеют точную информацию, что данный фрагмент соответствует таймингу 01:00:00.000.
Вопрос дилетанта. На ленте видео и звук физически же записаны синхронно и читаться с отставанием/опережением ну никак не могут. Почему не получается сохранить в синхронном виде и приходится "шаманить"? Существующие форматы хранения аудио не позволяют так сделать? Нет никаких меток, что данный фрагмент соответствует 01:15:24.125 исходника, т. е. информация просто теряется при записи?
Коллега, не скажу, что мне нравится предлагаемое в статье решение (выше предложили множество других хороших вариантов), но пример приведу.
Есть список графиков отпусков сотрудников - множество строк, ну и структура JSON соответствующая. Для каждой строки с учетом полномочий текущего пользователя нужно отобразить кнопки действий вида "Согласовать"/"Отказать". Получение действий выполняется от внешней системы очень медленно. Если формировать все одним запросом, время ожидания получается совершенно неприемлемым. Также прежде чем нажимать на кнопку, пользователя явно нужно некоторое время на просмотр и размышление. Т. е. кнопки можно отобразить существенно позже, без ухудшения пользовательского опыта. Возможно он вообще их пока нажимать не планирует - просто посмотрит все ли строки заполнены. Сейчас запросы с фронта:
1) получить контент для отображения (достаточно качественный, с рендерингом проблем особых нет)
2) получить кнопки-действия (можно частями - то что вне видимой в данный момент части, можно позже)
Спасибо за разъяснение. Единственное замечание - вся проверка технически элементарно реализуема голосовым запросом. Т. е. покупатель должен просто спросить.
Почему "узнаешь поздно", если сам сервер Яндекса в момент покупки явно подтверждает чем данное устройство является? Т. е. это настоящее устройство или оно взломано так, что не существует способа на серверной стороне найти отличие от настоящего.
Это тоже фиксится элементарно:
В каждом устройстве прошиваем уникальный токен Если появляется на связи его дубль колонка должна сказать "Ваше устройство взломано. Дальнейшее функционирование невозможно. Обратитесь к продавцу или в сервисный центр". Легитимный покупатель устройства получит новый токен. Копия работать не будет.
В этом случае вообще можно защитой не парится. Хоть вообще в опенсорс клиентскую часть выложить.
И наиболее надежный и понятный способ описать контракт в ТЗ это OpenAPI. Пробовали разные варианты.
В виде таблиц
Это очень простой пример. Часто 3-4 уровня вложенности и получается нечто монструозное и плохочитаемое
В виде примера JSON
{
"users": [ // Пользователи, по которым запрашивается информация
{ // Хотя бы один из параметров структуры должен быть передан
"id": 12, // Id сотрудника по версии системы, nullable
"userName": "ivanov", // userName сотрудника, nullable
"userSystemId": "ivanov-8b192ad9fd1bec094f944783bfa87caffdecec0bac0912e6cf0493aec837ba77" // системный идентификатор пользователя, nullable
}
],
"withFired": "lastPositionWhenNotActive", // Флаг передачи информации по уволенным сотрудникам. Nullable. По умолчанию "no"
"expand": ["UserInfoOnly", "DepartmentInfo"], // Список передаваемых структур. Nullable.
"start": 0, // Начальная позиция отображения полученных результатов
"limit": 5 // Максимальное количество найденных результатов
}
Часто возникало недопонимание, уточнения. Причем ошибки очень сложно отловить, уверен что у нас в старых контрактах из-за этого множество дыр.
А если написать вот так:
parameters:
- name: systemId
description: systemId заявки
in: path
required: true
schema:
type: string
example: SPT165.WFT3561.WF12.D40
# и т. д.
то это намного снижает вероятность ошибки и легко выявляется при тестировании. Можно описать абсолютно все детали совершенно однозначным и понятным способом.
Я почти тот самый безумец, по совместительству системный аналитик. И не далее как сегодня я писал спеку в формате OpenAPI. И она никак не могла взяться из кода сервера потому что его еще не существует. Вернее их несколько не существует - одного микросервиса внутри и одной внешней системы. По какой-то непонятной причине :) разработчики не хотят разрабатывать пока не получат явные спеки описывающие, что собственно должно быть на входе и на выходе, и как системы должны взаимодействовать. Генерировать автоматом из спеки особо не хотят, видимо действительно не очень удобно. Но как можно вообще без спеки не понимаю. Делать в виде текста или табличек, сложные структуры крайне неудобно.
Искра-1030» навсегда останется надёжной и удобной персоналкой,
Утверждение насчёт надёжности кажется откровенным издевательством стебом. Мой опыт свидетельствует о крайне низкой надёжности. Речь об Искрах курского счетмаша, возможно у других было лучше.
Кстати, чтобы хулиганы не нажимали резет, на него клали монету. Какую точно не помню, но явно из советских.
Еще вспомнилось. В кодировке символов почему-то кириллическая "р" на Искре заменялась латинской "p". Было два учебных класса - в одном Искры, в другом "нормальные" компьютеры на 286 проце (модель не помню). Набрал программу на прологе на Искре, а отлаживал в другом классе. Интерпретатор писал, что-то вроде: нет такого предиката "поискпрохода". А он есть. Ты его видишь. Сличаешь побуквенно. Удаляешь все лишнее, оставляя совсем мало кода. Бьешься головой о стену. Решаешь, что программиста из тебя не выйдет и пора все бросить. Тупо от безысходности перепечатываешь название и все работает! Экспериментально находишь проблемный символ. Навсегда отказываешься от кириллических символов в коде в пользу латиницы. Раздумываешь где найти пистолет и разработчиков этой фигни
Немного дополню Вашу мысль. Аргументированно говоря "нет", он вполне мог сэкономить миллионы, если не десятки миллионов долларов многократно окупив свою з/п. Сколько он при этом потратил времени не имеет никакого значения, в ИТ таймшиты весьма условная, если не вредная вещь. Да, он больше выполнял роль менеджера, а не разработчика, но это дело десятое.
Именно для данного случая ситуация странная. Даже совершенно поверхностная автоматическая проверка должна была выявить проблему - тестовые стенды в BSOD. Не представляю как такое можно пропустить, если только не выкатывать в прод вообще без тестирования.
QA? Если он у них есть конечно. Бывают нетривиальные, сложновоспроизводимые сценарии. Но как можно пропустить BSOD, которым подвержены «все продукты Microsoft»?!?!?
Эмм, ну и что там мы увидим? "Задача....", плановый срок выполнения через 3 месяца, начата неделю назад. Полезной информации почти 0. Точно все идёт как надо и будет сделано как надо и когда надо? А другие пути решения есть? Может более эффективно хотя бы часть проблем решить на уровне коллег по команде, а сейчас они даже не в курсе? И да, если действительно все идёт как надо, ваша речь на митинге вряд-ли будет дольше 30 секунд.
Спасибо. Беглый гуглеж показал что " В среднем, типичные часы реального времени могут иметь погрешность от 1,7 до 8,6 секунд в день.". Не ожидал, что все настолько плохо. Электронные наручные часы конца прошлого века обеспечивали лучшую точность. Непонятно почему не берут системное время синхронизируемое по NTP в этом случае.
Так таймер же у нас есть на обоих устройствах. Через час записи и устройство захвата видео и устройство захвата видео имеют точную информацию, что данный фрагмент соответствует таймингу 01:00:00.000.
Вопрос дилетанта. На ленте видео и звук физически же записаны синхронно и читаться с отставанием/опережением ну никак не могут. Почему не получается сохранить в синхронном виде и приходится "шаманить"? Существующие форматы хранения аудио не позволяют так сделать? Нет никаких меток, что данный фрагмент соответствует 01:15:24.125 исходника, т. е. информация просто теряется при записи?
А как же IP с себестоимостью 50р? Или он отключен?
Коллега, не скажу, что мне нравится предлагаемое в статье решение (выше предложили множество других хороших вариантов), но пример приведу.
Есть список графиков отпусков сотрудников - множество строк, ну и структура JSON соответствующая. Для каждой строки с учетом полномочий текущего пользователя нужно отобразить кнопки действий вида "Согласовать"/"Отказать". Получение действий выполняется от внешней системы очень медленно. Если формировать все одним запросом, время ожидания получается совершенно неприемлемым. Также прежде чем нажимать на кнопку, пользователя явно нужно некоторое время на просмотр и размышление. Т. е. кнопки можно отобразить существенно позже, без ухудшения пользовательского опыта. Возможно он вообще их пока нажимать не планирует - просто посмотрит все ли строки заполнены. Сейчас запросы с фронта:
1) получить контент для отображения (достаточно качественный, с рендерингом проблем особых нет)
2) получить кнопки-действия (можно частями - то что вне видимой в данный момент части, можно позже)
Не отменяя всего сказанного, можно еще добавить "Используйте подход DDD". Это значительно уменьшает недопонимание.
На тему отзывчивости большинства разработчиков ядра к проблемам пользователей со старым железом. Вспомнилась статья аж 2009 года
https://habr.com/ru/articles/69622/
Спасибо за разъяснение. Единственное замечание - вся проверка технически элементарно реализуема голосовым запросом. Т. е. покупатель должен просто спросить.
Почему "узнаешь поздно", если сам сервер Яндекса в момент покупки явно подтверждает чем данное устройство является? Т. е. это настоящее устройство или оно взломано так, что не существует способа на серверной стороне найти отличие от настоящего.
Это тоже фиксится элементарно:
В каждом устройстве прошиваем уникальный токен
Если появляется на связи его дубль колонка должна сказать "Ваше устройство взломано. Дальнейшее функционирование невозможно. Обратитесь к продавцу или в сервисный центр". Легитимный покупатель устройства получит новый токен. Копия работать не будет.
В этом случае вообще можно защитой не парится. Хоть вообще в опенсорс клиентскую часть выложить.
Эмм. Ну это же решается простейшим образом:
1) Включаем и ждем когда загрузится
2) "Алиса, назови свой серийный номер и статус подписки"
3) "Алиса, вызови полицию по адресу ... тут мошенник"И наиболее надежный и понятный способ описать контракт в ТЗ это OpenAPI. Пробовали разные варианты.
В виде таблиц
В виде примера JSON
Часто возникало недопонимание, уточнения. Причем ошибки очень сложно отловить, уверен что у нас в старых контрактах из-за этого множество дыр.
А если написать вот так:
то это намного снижает вероятность ошибки и легко выявляется при тестировании. Можно описать абсолютно все детали совершенно однозначным и понятным способом.
Я почти тот самый безумец, по совместительству системный аналитик. И не далее как сегодня я писал спеку в формате OpenAPI. И она никак не могла взяться из кода сервера потому что его еще не существует. Вернее их несколько не существует - одного микросервиса внутри и одной внешней системы. По какой-то непонятной причине :) разработчики не хотят разрабатывать пока не получат явные спеки описывающие, что собственно должно быть на входе и на выходе, и как системы должны взаимодействовать. Генерировать автоматом из спеки особо не хотят, видимо действительно не очень удобно. Но как можно вообще без спеки не понимаю. Делать в виде текста или табличек, сложные структуры крайне неудобно.
Дополню. За счёт грамотных абстракций и названий можно добиться понимания "как это работает", но часто никак не объяснить "зачем".
На 5 знак факториала должен быть снаружи квадратного корня.
А как решали проблему электропитания? Обычная тупая сигналка практически всегда на аккумуляторе и не требует никакой сетевой обвязки.
Утверждение насчёт надёжности кажется откровенным
издевательствомстебом. Мой опыт свидетельствует о крайне низкой надёжности. Речь об Искрах курского счетмаша, возможно у других было лучше.Кстати, чтобы хулиганы не нажимали резет, на него клали монету. Какую точно не помню, но явно из советских.
Еще вспомнилось. В кодировке символов почему-то кириллическая "р" на Искре заменялась латинской "p". Было два учебных класса - в одном Искры, в другом "нормальные" компьютеры на 286 проце (модель не помню).
Набрал программу на прологе на Искре, а отлаживал в другом классе. Интерпретатор писал, что-то вроде: нет такого предиката "поискпрохода". А он есть. Ты его видишь. Сличаешь побуквенно. Удаляешь все лишнее, оставляя совсем мало кода. Бьешься головой о стену. Решаешь, что программиста из тебя не выйдет и пора все бросить. Тупо от безысходности перепечатываешь название и все работает! Экспериментально находишь проблемный символ. Навсегда отказываешься от кириллических символов в коде в пользу латиницы.
Раздумываешь где найти пистолет и разработчиков этой фигниНемного дополню Вашу мысль. Аргументированно говоря "нет", он вполне мог сэкономить миллионы, если не десятки миллионов долларов многократно окупив свою з/п. Сколько он при этом потратил времени не имеет никакого значения, в ИТ таймшиты весьма условная, если не вредная вещь. Да, он больше выполнял роль менеджера, а не разработчика, но это дело десятое.
Именно для данного случая ситуация странная. Даже совершенно поверхностная автоматическая проверка должна была выявить проблему - тестовые стенды в BSOD. Не представляю как такое можно пропустить, если только не выкатывать в прод вообще без тестирования.
QA? Если он у них есть конечно. Бывают нетривиальные, сложновоспроизводимые сценарии. Но как можно пропустить BSOD, которым подвержены «все продукты Microsoft»?!?!?
Эмм, ну и что там мы увидим? "Задача....", плановый срок выполнения через 3 месяца, начата неделю назад. Полезной информации почти 0. Точно все идёт как надо и будет сделано как надо и когда надо? А другие пути решения есть? Может более эффективно хотя бы часть проблем решить на уровне коллег по команде, а сейчас они даже не в курсе? И да, если действительно все идёт как надо, ваша речь на митинге вряд-ли будет дольше 30 секунд.