Принцип логического и физического построения по первичным ключам: "от меньшего к большему, был давно известен". Только в Postgres это прямая сортировка слева направо, а в MS SQL частично-обратная. Но в любом случае, 8 байт идентификатора, в 99 случаях играет роль на нагрузку системы. Мы еще с 16-го года используем в своей системе, генерацию временной метки в UUID, до милисекунды. Да это частично нарушает стандарт UUID, но это работает уже 10 лет и проблем нет. Плюс легко по UUID определить точную дату создания записи.
Вы когда обращаетесь в поддержку, вам отвечают не разработчики. Это или техподдержка, или ваш клиентский менеджер.
То, как вам отвечает поддержка и менеджеры никак не зависит от квалификации разработчиков.
Все верно. Так я и не говорю про "первую линию", там вообще робот отвечает. И менеджер тут не причем, от передает. А техподдержка не может решить вопрос с разрабами (в во многих компаниях компаниях всегда так...).
А здесь: 1. Разработчики накосячили с кодом яндекс ID (визуально для пользователя все ок, а на бэке 500 я ошибка и полный блэкаут аккаунта. 2. Ок, со всеми бывает. Но можно же изнутри разблочить и найти косяк в коде: все последовательности известны. Но вместо этого банальный игнор вторую неделю. Я никогда не поверю, что через бэкенд невозможно внести корректировки в данные. Мы сами разрабатываем клиент-серверные решения и я точно знаю, что можно. Не берем во внимание согласования и ветки кода, сроки внесения в прод и т.д. это и так понятно.
Вот я и говорю: показатель компетенции сотрудников компании, не тест на пятичасовом собеседовании сортировкой "пузырьком", а реальная проблема на проде и оперативность её решения.
К сожалению напрямую. Смысл проводить такие усложненные собеседования, которые по идее должны отбирать качественных специалистов, если эти же "спецы" просто сидят на зарплате, при этом не имея компетенции в продукте собственной компании. Я уже про менеджеров не говорю, я говорю как тех специалист. Если разработчики создали продукт, по идее объяснили специалистам техподдержки (не важно какими средствами), а при возникновении серьезной проблемы, которая влияет на бизнес клиента, просто игнорят его и отписываются со словами "Мы не знаем как решить проблему собственного продукта". Тогда получается система собеседований не приносит желаемый результат и она неэффективна.
В it «Время» циклично… И некоторые процессы ходят по-кругу.
Мы крупных клиентов (от 50 ящиков) перенесли на их собственные железки, еще когда Яндекс сделал почту платной. А там, где расходы явно не уровняются с закупкой инфраструктуры под почту, тех оставили. И как всегда «лень сисадмина» говорила: «пусть пока так))».
После первого косяка уже начали готовить на своих мощностях основу для почтовых серверов. Теперь уже точно до конца года начнем инициализацию перехода всех клиентов с Яндекса на собственные почтовики.
не, недопрут (( и это реально страшно. Они даже корпоративных клиентов не слушают, когда сами же и звонят для опроса работы сервисов. Пол года боролись с проблемой самовольного объеденения аккаунтов Яндексом. два часа обсуждали и ни к чему не пришли, ну кроме стандарта: "наша компания, мы так хотим". Осенью перевели в срочном порядке с рядовго хостинга почту на яндекс, думали норм ребята... а две недели назад вообще заблокировали один из аккаунтов при смене номера телефона, и на просьбу "Ребят, ну решите вопрос", молчание. в итоге активная почта и все письма потеряны... Котя клиент боялся ровно наооборот )), что подвальный хостер все поломает.
Принцип логического и физического построения по первичным ключам: "от меньшего к большему, был давно известен". Только в Postgres это прямая сортировка слева направо, а в MS SQL частично-обратная. Но в любом случае, 8 байт идентификатора, в 99 случаях играет роль на нагрузку системы. Мы еще с 16-го года используем в своей системе, генерацию временной метки в UUID, до милисекунды. Да это частично нарушает стандарт UUID, но это работает уже 10 лет и проблем нет. Плюс легко по UUID определить точную дату создания записи.
Все верно. Так я и не говорю про "первую линию", там вообще робот отвечает. И менеджер тут не причем, от передает. А техподдержка не может решить вопрос с разрабами (в во многих компаниях компаниях всегда так...).
А здесь:
1. Разработчики накосячили с кодом яндекс ID (визуально для пользователя все ок, а на бэке 500 я ошибка и полный блэкаут аккаунта.
2. Ок, со всеми бывает. Но можно же изнутри разблочить и найти косяк в коде: все последовательности известны. Но вместо этого банальный игнор вторую неделю. Я никогда не поверю, что через бэкенд невозможно внести корректировки в данные. Мы сами разрабатываем клиент-серверные решения и я точно знаю, что можно. Не берем во внимание согласования и ветки кода, сроки внесения в прод и т.д. это и так понятно.
Вот я и говорю: показатель компетенции сотрудников компании, не тест на пятичасовом собеседовании сортировкой "пузырьком", а реальная проблема на проде и оперативность её решения.
К сожалению напрямую.
Смысл проводить такие усложненные собеседования, которые по идее должны отбирать качественных специалистов, если эти же "спецы" просто сидят на зарплате, при этом не имея компетенции в продукте собственной компании.
Я уже про менеджеров не говорю, я говорю как тех специалист. Если разработчики создали продукт, по идее объяснили специалистам техподдержки (не важно какими средствами), а при возникновении серьезной проблемы, которая влияет на бизнес клиента, просто игнорят его и отписываются со словами "Мы не знаем как решить проблему собственного продукта". Тогда получается система собеседований не приносит желаемый результат и она неэффективна.
В it «Время» циклично… И некоторые процессы ходят по-кругу.
Мы крупных клиентов (от 50 ящиков) перенесли на их собственные железки, еще когда Яндекс сделал почту платной. А там, где расходы явно не уровняются с закупкой инфраструктуры под почту, тех оставили.
И как всегда «лень сисадмина» говорила: «пусть пока так))».После первого косяка уже начали готовить на своих мощностях основу для почтовых серверов. Теперь уже точно до конца года начнем инициализацию перехода всех клиентов с Яндекса на собственные почтовики.
не, недопрут (( и это реально страшно. Они даже корпоративных клиентов не слушают, когда сами же и звонят для опроса работы сервисов.
Пол года боролись с проблемой самовольного объеденения аккаунтов Яндексом. два часа обсуждали и ни к чему не пришли, ну кроме стандарта: "наша компания, мы так хотим". Осенью перевели в срочном порядке с рядовго хостинга почту на яндекс, думали норм ребята... а две недели назад вообще заблокировали один из аккаунтов при смене номера телефона, и на просьбу "Ребят, ну решите вопрос", молчание. в итоге активная почта и все письма потеряны... Котя клиент боялся ровно наооборот )), что подвальный хостер все поломает.