Коллега, не скажу, что мне нравится предлагаемое в статье решение (выше предложили множество других хороших вариантов), но пример приведу.
Есть список графиков отпусков сотрудников - множество строк, ну и структура 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 секунд.
А пруфы есть? Знаю только про казнь введением под маску азота. Не нашел никаких подтверждений, что это больнее инъекции и уж точно лучше электрического стула или расстрела.
Издательство "Питер". Роберт Мартин "Чистая архитектура Искусство разработки программного обеспечения":
Принципиальное отличие науки от математики заключается в том, что правильность научных теорий и законов нельзя доказать
Фраза вводит в ступор и вызывает подозрение что в издании ошибка. Для русскоязычного читателя математика несомненно "наука". Два года назад я им написал и даже удостоился ответа. Если выразить его суть немного грубо и кратко "Мы лучше знаем, идите нафиг, ничего делать не будем".
Есть небольшое, но важное дополнение к переводу книги Роберт Мартин "Чистая архитектура Искусство разработки программного обеспечения". Пожалуйста передайте эту информацию переводчикам и по возможности дополните электронную версию.
В тексте встречается рассуждения про науку (см. подзаголовок "Наука во спасение"). Некоторые утверждения выглядят странно и непонятно. Дело в том что речь идет о естественных науках. Слово "Наука" в русском языке имеет более широкое значение, чем "science" в английском.
Очень хорошо разница объяснена в примечании переводчика в книге "Ружья, микробы и сталь" Джаред Мэйсон Даймонд. Там аналогичная проблема проявилась при размышлении автора является ли история наукой, что для русскоязычного читателя выглядит также странно:
"Английский термин «political science» (буквально, «политическая наука») — эквивалент русского термина «политология». В отличие от английского языка, в русском словосочетание «историческая наука» — устоявшийся термин. Несмотря на то что английское слово «science» в большинстве случаев переводится на русский как «наука», оно имеет более узкое значение, примерно соответствующее понятию «естественная наука» или «эмпирическая наука». То же неполное соответствие существует между английскими «scientific» и «scientist», с одной стороны, и русскими «научный» и «ученый» — с другой. — Примеч. перев."
Предлагаю добавить подобную сноску. Как вариант можно везде писать "естественных науках", "естественнонаучный", но это громоздко.
Коллега, не скажу, что мне нравится предлагаемое в статье решение (выше предложили множество других хороших вариантов), но пример приведу.
Есть список графиков отпусков сотрудников - множество строк, ну и структура 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 секунд.
А пруфы есть? Знаю только про казнь введением под маску азота. Не нашел никаких подтверждений, что это больнее инъекции и уж точно лучше электрического стула или расстрела.
Несколько часов в общественном транспорте часто тоже не очень хорошо влияют на психику.
Издательство "Питер". Роберт Мартин "Чистая архитектура Искусство разработки программного обеспечения":
Фраза вводит в ступор и вызывает подозрение что в издании ошибка. Для русскоязычного читателя математика несомненно "наука".
Два года назад я им написал и даже удостоился ответа. Если выразить его суть немного грубо и кратко "Мы лучше знаем, идите нафиг, ничего делать не будем".
вернее сказать - "даташит" окончательно скатывался в шит ;)