Re[4]: В поддержке опенсорса такое нынче нормально?
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 08.01.26 10:41
Оценка:
Здравствуйте, andyp, Вы писали:

A>нет никакого "принято" в этом вопросе.


Если прочитаете внимательно то, что писал о "принято", то сообразите, что оно было о другом.
Re[6]: В поддержке опенсорса такое нынче нормально?
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.01.26 13:58
Оценка: :))
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>С коммерческими проще понять — в поддержке сидят, как правило, нанятые сотрудники, которым судьба софта и проблемы у разработчиков по барабану. Но тех проще привести в чувство жалобами начальству. А опенсорсники вроде как занимаются поддержкой сами, и вроде как должны быть заинтересованы в любой информации, способной привести к ликвидации явных косяков в коде.


ЕМ>Я этого долгое время тоже не понимал, потом кто-то объяснил, что во многих конторах это прям часть регламента. Тупо потому, что 80% обращений выглядят в стиле "у меня ничего не работает, шозанах, я вам деньги заплатил, сделайте, чтоб работало". Чтоб предусмотреть отдельный путь для 20% вменяемых, нужно относительно разумное планирование поддержки, а с этим тоже проблемы.

Это как раз разумное планирование Я на одной из своих работ как раз застал переход поддержки от "хаотических доброжелателей" к "систематическому удовлетворению клиентов".
Руководить саппортом взяли тётеньку со стальными яйцами. Я ей до сих пор восхищаюсь. Так что имел возможность посмотреть на процесс "с другой стороны забора". У нас, кстати, в целом было неплохо всё организовано.
Например, была такая практика — разработчиков раз в год отправляли поработать в second-line саппорта на две недели. Очень помогало посмотреть на продукт незашоренными глазами.
А я, как продакт, периодически вычитывал тикеты по своему продукту. И вот там я и перестал верить в кастомер сатисфакшн — искал, кто пострадал от определённого бага (а это в ентерпрайзе не всегда легко выяснить, потому что саппорт репортит только те проблемы, которые им портят метрики. А если они нашли багу, для которой есть workaround — то это золотое дно: не нужно гадать и мучиться, можно быстро решить проблему клиента, а у таких клиентов удовлетворённость по статистике выше, чем у тех, кто вообще проблем не встретил). И вот нахожу, помнится, тикет, в котором саппортер написал чушь. Причём там понятно, что он просто тикетом промахнулся — потому что советы относятся вообще к другому продукту. Я уже там начинаю лихорадочно искать, какой же кнопкой ответить в тикет, чтобы спасти ситуацию (а там система — как в авиалайнере: куча кнопок, причём рядом друг с другом и с малоразличимыми названиями кнопки с чем-то совершенно невинным, типа добавить тег к тикету, и потенциально опасные действия вроде слияния тикета с каким-то ещё) — смотрю дальше, а там не просто тикет уже закрыт, там уже и опрос клиента проведён, и он пять звёзд поставил .
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: В поддержке опенсорса такое нынче нормально?
От: andyp  
Дата: 08.01.26 14:08
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, andyp, Вы писали:


A>>нет никакого "принято" в этом вопросе.


ЕМ>Если прочитаете внимательно то, что писал о "принято", то сообразите, что оно было о другом.


Более поздние биты в блутусе — левые и с этим ничего не поделать. Так что, если прервался и не принял весь октет, то для блутуса ЕСТЕСТВЕННО расширить принятое нулями ВЛЕВО. Ну вот так прям в стандарте и сказано — передается от lsb к msb каждого байта. По блутусовски хвосты в битах aik-а заканчиваются на bb, а не на dd, если конечно он писал принятую колбасу бит слева направо и там целое число октетов.
Re[6]: В поддержке опенсорса такое нынче нормально?
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 08.01.26 14:31
Оценка:
Здравствуйте, andyp, Вы писали:

A>если прервался и не принял весь октет, то для блутуса ЕСТЕСТВЕННО расширить принятое нулями ВЛЕВО.


Естественно расширять такие биты не "вправо" или "влево", а в сторону их следования, а когда доходит до human-readable отображаения — показывать так, чтоб не путать человека за экраном.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.