Темная материя ослабевает, это что значит? Что скорость увеличения разлета галактик, сиречь, ускорение разлета, не постоянна, а снижается? А какова скорость снижения ускорения?
Сколько всего лишнего. Почему просто не контролировать шероховатость отверстий? Вы ведь не ввели операцию контроля шероховатости стенки. Какая разница, почему вдруг шероховатость полетела? Тем более, почему это должно волновать вас, как производство на следующем этапе?
Шероховатость может полететь из-а тысячи причин: плохая заточка, плохая сталь сверла, превышение скорости подачи, превышение скорости вращения шпинделя, биение из-за износа шпинделя, биение из-за низкого качества шпинделя, вибрация в станке, плохая затяжка сверла, неправильная и неравномерная затяжка сверла в шпинделе, кривые китайские сверла... тысячи их.
Где вообще входной контроль? Его как не было, так и не стало. Макулатуры только нагородили по iso 9000.
Самое главное (думаю) - китайцы не понесли наказания. Не было спецификации шероховатости отверстий. Соответствующего входного контроля не было.
Самое главное (имхо). Причем тут шероховатость? Каким образом большая шероховатость отверстия ухудшает заполняемость припоем? Вот в этой вот мутной фразе: "Но маленькие переходные отверстия были идеальными. Значит, стенки крупных отверстий пришли на металлизацию уже дефектными. " - вам не кажется, что страдает логика?
Вот эта фраза тоже совершенно нелогична: "И это произошло только с отверстиями определенных диаметров — тех, в которые паяются те самые разъемы. Это подтвердило: проблема в платах, не в процессе монтажа у заказчика. ". С чего бы это?
Может, плохая заполняемость отверстия, судя по тому, что шпилька сдвинута к одной стороне, а на другой стороне, где образовалась слишком большая щель - обусловлено просто тем, что слишком большое расстояние между стенкой отверстия и стенкой шпильки для данной высоты отверстия, смачиваемости припоем и поверхностным натяжением расплава припоя.
Приведите пожалуйста размеры, а также стандарты на пайку и расчеты, которые доказывают, что конструктивно тут все правильно. Мне, как технологу, видится, что здесь неправильно спроектирована конструкция посадки и нарушена технология пайки. Имхо, отверстие слишком велико для такого штыря и слишком большая несоосность.
Ишь, отбрехались перед начальством, что китайцы плохую шероховатость сделали. А китайцам тоже не жарко - они никаких санкций не понесли, отбрехались, что будут более тщательно сверла фотографировать.
Так кто-ж спорит? Конечно. В наивном представлении. Для нормальной рыночной экономики.
Дискуссия в том, является ли кейс с РКН, махом и Телеграмом "коммунистической гнилью", или это полностью следствие капиталистической системы.
Я утверждаю, что то, что творится сейчас - следствие капиталистической системы в последней стадии. ВК со своим махом сращивается с государством в виде РКН. Вместе они делают не то, что нужно обществу и людям ("капиталисты удовлетворяют потребности людей и общества", бгг), а то, что приводит к обогащению конкретных людей. В свете обсуждаемого кейса ваше "Хорошо удовлетворил - обогатился, плохо удовлетворил - разорился. " - это наивный лепет из разряда "атлант расправил плечи".
При капитализме цель любого производства (не говоря уж о спекуляции) - обогащение капиталиста. Цель производства при социализме - удовлетворение потребностей общества.
Не надо плести ахинеи типа "внезапно для марксистов ... и не "чтоб хозяин имел доход" ". Прибыль, прибыль и только прибыль. "Наша миссия в бла-бла-бла" - это для слабоумных.
Мне кажется, правительству еще нужно, чтобы Телеграм перестал быть СМИ. То есть, все каналы, блогеры и прочие борцы за лайки, должны быть выкинуты на мороз. Прерогатива вещать должна остаться только у государства и государевых людей (я так предполагаю).
При чем коммунистическая гниль? Сращивание сверхкрупного бизнеса и государства - это чисто капиталистическая фишка (первая стадия империализма). Строго по Марксу-Ленину.
Не очень понятно, кто заполняет спецификацию? Проблема была в том, что никто не описывает и не документирует API. Как open api решает эту проблему? Никак? Если разработчик будет вместо Java программировать на Yaml, кто и что гарантирует, что он будет заполнять поля с описанием методов api в Yaml-файле? Если это делает специально обученный проектировщик api, что гарантирует, что он будет документировать методы своего api?
Давать работу исполнителю с нужным уровнем компетенции.
Давать ему в работу однозначно полный для реализации проект. Чертеж.
Контролировать результат работы на соответствие проекту (функциональным и нефункциональным требованиям, в том числе корпоративным стандартам оформления).
Ключевое замечание - контроль должен проводить специально обученный человек - фунциональные требования тестирует тестировщик. На соответствие корпоративным стандартам должен проверять что-то типа нормоконтроль (Айтишники до этого еще не доросли).
Выпускать работу в тестирование должен непосредственный руководитель (тимлид, в промышленности это начальник техбюро), он же и требует выполнения определенного технического уровня. То есть лицо, а) в непосредственном подчинении которого находится исполнитель, б) несет ответственность за сроки выполнения работ и техническое качество изделия.
Но извините, чтобы твою работу проверял (ревьювил) какой-то Вася, которому ты не подчиняешься, который не несет никакой ответственности ни за твой результат, ни за сроки, ни за процесс разработки, который не следует стандартам предприятия, а руководствуется в своих придирках исключительно своими личными предпочтениями, убеждениями и чувством прекрасного и при этом может докапываться как хочет, на козе не подъедешь - это просто п...ц. Хуже систему, имхо, сложно придумать.
Всегда считал, что code review - это чушь и вред. Если при работе в ИИ pr - вред, то и при работе с хуманами, это точно такой-же вред, просто не настолько очевидный.
Какая структура payment_document ? Какие индексы у payment_document? Как отсортированы исходные данные и отсортированы ли? Ладно, можно предположить, что индекс на account_id, и исходные данные отсортированы по account_id. Тогда при вставке данные ложатся по-порядку в индексы. Если account_id в исходных данных не по-порядку, то сервер будет будет складывать записи в разных местах индекса, подгружая страницы из разных мест. При этом будет большая деградация и ваши батчи будут бесполезны. Знакомая проблема с guid-ами в качестве ключей.
Также, если индекс содержи даты, а в исходных данных даты как попало.
Короче, надо исхитриться, чтобы при вставке записи вставлялись в последнюю страницу в дереве, и перебалансировок дерева не было.
Интересно также, секционирована ли таблица и как данные ложатся по секциям.
Вызывает скепсис, что многопоточность может увеличить скорость, при том, что данные по разным потокам будут иметь разные ключи payment_document, из-за чего (теоретически) строки от разных потоков будут писаться в страницы индекса вперемешку, что приведет к частым перебалансировкам дерева индекса. Разве что распределить данные по разным секциям и сделать, чтобы каждый поток писал в свою секцию.
Если индексов в таблице много, имеет ли смысл отключить их на момент массовой вставки, а потом пересоздать? Было ли это в данной работе сделано?
Темная материя ослабевает, это что значит? Что скорость увеличения разлета галактик, сиречь, ускорение разлета, не постоянна, а снижается? А какова скорость снижения ускорения?
Натягивание совы науки на глобус капитализма.
Интересно. Можно уточнить: кто делал
pausePartition,это потребитель-приложение ваше?
Сколько всего лишнего. Почему просто не контролировать шероховатость отверстий? Вы ведь не ввели операцию контроля шероховатости стенки. Какая разница, почему вдруг шероховатость полетела? Тем более, почему это должно волновать вас, как производство на следующем этапе?
Шероховатость может полететь из-а тысячи причин: плохая заточка, плохая сталь сверла, превышение скорости подачи, превышение скорости вращения шпинделя, биение из-за износа шпинделя, биение из-за низкого качества шпинделя, вибрация в станке, плохая затяжка сверла, неправильная и неравномерная затяжка сверла в шпинделе, кривые китайские сверла... тысячи их.
Где вообще входной контроль? Его как не было, так и не стало. Макулатуры только нагородили по iso 9000.
Самое главное (думаю) - китайцы не понесли наказания. Не было спецификации шероховатости отверстий. Соответствующего входного контроля не было.
Самое главное (имхо). Причем тут шероховатость? Каким образом большая шероховатость отверстия ухудшает заполняемость припоем? Вот в этой вот мутной фразе: "Но маленькие переходные отверстия были идеальными. Значит, стенки крупных отверстий пришли на металлизацию уже дефектными. " - вам не кажется, что страдает логика?
Вот эта фраза тоже совершенно нелогична: "И это произошло только с отверстиями определенных диаметров — тех, в которые паяются те самые разъемы. Это подтвердило: проблема в платах, не в процессе монтажа у заказчика. ". С чего бы это?
Может, плохая заполняемость отверстия, судя по тому, что шпилька сдвинута к одной стороне, а на другой стороне, где образовалась слишком большая щель - обусловлено просто тем, что слишком большое расстояние между стенкой отверстия и стенкой шпильки для данной высоты отверстия, смачиваемости припоем и поверхностным натяжением расплава припоя.
Приведите пожалуйста размеры, а также стандарты на пайку и расчеты, которые доказывают, что конструктивно тут все правильно. Мне, как технологу, видится, что здесь неправильно спроектирована конструкция посадки и нарушена технология пайки. Имхо, отверстие слишком велико для такого штыря и слишком большая несоосность.
Ишь, отбрехались перед начальством, что китайцы плохую шероховатость сделали. А китайцам тоже не жарко - они никаких санкций не понесли, отбрехались, что будут более тщательно сверла фотографировать.
Потому что СССР в виде государства и министерства внешней торговли не закупало всякое говно. Закупало только хорошие товары.
Поэтому у советского человека создалось представление, что импортное - это значит хорошее.
Откуда такое убеждение? По материалам журнала "Огонек"? Почему не сравнивать с Китаем?
:)
Так кто-ж спорит? Конечно. В наивном представлении. Для нормальной рыночной экономики.
Дискуссия в том, является ли кейс с РКН, махом и Телеграмом "коммунистической гнилью", или это полностью следствие капиталистической системы.
Я утверждаю, что то, что творится сейчас - следствие капиталистической системы в последней стадии. ВК со своим махом сращивается с государством в виде РКН. Вместе они делают не то, что нужно обществу и людям ("капиталисты удовлетворяют потребности людей и общества", бгг), а то, что приводит к обогащению конкретных людей. В свете обсуждаемого кейса ваше "Хорошо удовлетворил - обогатился, плохо удовлетворил - разорился. " - это наивный лепет из разряда "атлант расправил плечи".
При капитализме цель любого производства (не говоря уж о спекуляции) - обогащение капиталиста. Цель производства при социализме - удовлетворение потребностей общества.
Не надо плести ахинеи типа "внезапно для марксистов ... и не "чтоб хозяин имел доход" ". Прибыль, прибыль и только прибыль. "Наша миссия в бла-бла-бла" - это для слабоумных.
Вот! Верхи не могут, низы не хотят.
Мне кажется, правительству еще нужно, чтобы Телеграм перестал быть СМИ. То есть, все каналы, блогеры и прочие борцы за лайки, должны быть выкинуты на мороз. Прерогатива вещать должна остаться только у государства и государевых людей (я так предполагаю).
А вы уверены, что это счастье?
Не бизнес, а производство.
При чем коммунистическая гниль? Сращивание сверхкрупного бизнеса и государства - это чисто капиталистическая фишка (первая стадия империализма). Строго по Марксу-Ленину.
Не очень понятно, кто заполняет спецификацию? Проблема была в том, что никто не описывает и не документирует API. Как open api решает эту проблему? Никак? Если разработчик будет вместо Java программировать на Yaml, кто и что гарантирует, что он будет заполнять поля с описанием методов api в Yaml-файле? Если это делает специально обученный проектировщик api, что гарантирует, что он будет документировать методы своего api?
С технической стороны к статье вопросов нет.
Давать работу исполнителю с нужным уровнем компетенции.
Давать ему в работу однозначно полный для реализации проект. Чертеж.
Контролировать результат работы на соответствие проекту (функциональным и нефункциональным требованиям, в том числе корпоративным стандартам оформления).
Ключевое замечание - контроль должен проводить специально обученный человек - фунциональные требования тестирует тестировщик. На соответствие корпоративным стандартам должен проверять что-то типа нормоконтроль (Айтишники до этого еще не доросли).
Выпускать работу в тестирование должен непосредственный руководитель (тимлид, в промышленности это начальник техбюро), он же и требует выполнения определенного технического уровня. То есть лицо, а) в непосредственном подчинении которого находится исполнитель, б) несет ответственность за сроки выполнения работ и техническое качество изделия.
Но извините, чтобы твою работу проверял (ревьювил) какой-то Вася, которому ты не подчиняешься, который не несет никакой ответственности ни за твой результат, ни за сроки, ни за процесс разработки, который не следует стандартам предприятия, а руководствуется в своих придирках исключительно своими личными предпочтениями, убеждениями и чувством прекрасного и при этом может докапываться как хочет, на козе не подъедешь - это просто п...ц. Хуже систему, имхо, сложно придумать.
Ну и тесты писать.
Всегда считал, что code review - это чушь и вред. Если при работе в ИИ pr - вред, то и при работе с хуманами, это точно такой-же вред, просто не настолько очевидный.
"Правильная точка зрения"? Автор вообще, понимает, что означает "Правда" и "Точка зрения"?
Какая структура payment_document ? Какие индексы у payment_document? Как отсортированы исходные данные и отсортированы ли? Ладно, можно предположить, что индекс на account_id, и исходные данные отсортированы по account_id. Тогда при вставке данные ложатся по-порядку в индексы. Если account_id в исходных данных не по-порядку, то сервер будет будет складывать записи в разных местах индекса, подгружая страницы из разных мест. При этом будет большая деградация и ваши батчи будут бесполезны. Знакомая проблема с guid-ами в качестве ключей.
Также, если индекс содержи даты, а в исходных данных даты как попало.
Короче, надо исхитриться, чтобы при вставке записи вставлялись в последнюю страницу в дереве, и перебалансировок дерева не было.
Интересно также, секционирована ли таблица и как данные ложатся по секциям.
Вызывает скепсис, что многопоточность может увеличить скорость, при том, что данные по разным потокам будут иметь разные ключи payment_document, из-за чего (теоретически) строки от разных потоков будут писаться в страницы индекса вперемешку, что приведет к частым перебалансировкам дерева индекса. Разве что распределить данные по разным секциям и сделать, чтобы каждый поток писал в свою секцию.
Если индексов в таблице много, имеет ли смысл отключить их на момент массовой вставки, а потом пересоздать? Было ли это в данной работе сделано?
Искажения коммуникации были всегда. Алгоритмы тут ни при чем.