При чем коммунистическая гниль? Сращивание сверхкрупного бизнеса и государства - это чисто капиталистическая фишка (первая стадия империализма). Строго по Марксу-Ленину.
Не очень понятно, кто заполняет спецификацию? Проблема была в том, что никто не описывает и не документирует 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, из-за чего (теоретически) строки от разных потоков будут писаться в страницы индекса вперемешку, что приведет к частым перебалансировкам дерева индекса. Разве что распределить данные по разным секциям и сделать, чтобы каждый поток писал в свою секцию.
Если индексов в таблице много, имеет ли смысл отключить их на момент массовой вставки, а потом пересоздать? Было ли это в данной работе сделано?
Причем тут заявления? Это сугубо мое мнение. Давным-давно, еще в молодости, я читал подробную статью в "Наука и жизнь", где поминутно было все расписано. И меня поразило, что началось все с того, что научный персонал на станции (или в министерстве энергетики, плохо помню) решило получить ответ на вопрос - сколько еще будет станция выдавать ток, если реактор мгновенно заглушить? Каков выбег или как-то так. Провести эксперимент на работающем реакторе. Насколько помню, такие режимы работы запрещались инструкциями.
Это вообще как, нормально по-вашему, играться с реактором?
Причем тут конструктивные недостатки? Причем тут крайне редкие стечения обстоятельств? В случае Фукусимы можно кивать на крайне редкие стечения обстоятельств. В данном случае какие редкие стечения обстоятельств? Что в Минэнерго СССР собралось столько идиотов, решивших поиграть с ядеркой?
После этого, между прочим, все ядерные электростанции передали в ведение Минсредмаша (если кто понимает, что это такое) а потом и вовсе - создали специализированное Министерство ядерной энергетики.
Upd. А Магатэ, конечно, будет педалировать тему, что советские ядерные реакторы опасны. Этого следовало ожидать.
Как это в Чернобыле не человеческий фактор? Причиной аварии был эксперимент, который руководство и научный персонал станции решило провести на работающем ядерном реакторе.
Могу свой кейс рассказать. Во время диспансеризации делал подробные анализы крови. Врачи толком ничего не сказали. Все хорошо.
Я загнал pdf-ки с анализами в дипсик и попросил проанализировать и дать рекомендации. Дипсик сказал, что все хорошо, но повышен уровень холестерина повышенный. Объяснил про риски, к которым это ведет. Сказал, что надо делать - тренировки на дорожке с высокой нагрузкой на сердце три раза в неделю. Через несколько месяцев делал повторно анализы - все пришло в норму.
Во-первых, надо брать функцию с минимальной степенью. Во-вторых, делить данные на обучающую и тестовую выборку. Если после прогона обучающей выборки, ваша модель дает те-же результаты, что и в тестовой выборке, то поздравляю - это ваша цифровая копия. Если ваша цифровая копия дает те-же ответы в типичных диалогах, что и вы бы дали, и например, ваши родные не могли заподозрить, что отвечает ваша копия, а не вы, то можно предположить, что создана ваша цифровая копия.
Тут же была уже статься с визуализацией. Между звездными системами чудовищные расстояния. Вероятность появления жизни и развития до цивилизации, способной отправить сигнал - невероятно низкая. Продолжительность жизни цивилизации - по меркам планеты крайне мала (даже миллион лет). Пока сигнал идет от цивилизации до другой цивилизации, которая в этот момент может существовать - проходит миллионы и миллиарды лет.
Я предлагаю вам еще раз прочитать эту статью, полностью. В этой статье не только не говорится, что это миф, но тащемта, только подтверждаются мои слова.
Исследование, посвящённое саамским языкам Норвегии, Швеции и Финляндии, содержит заключение о том, что в них имеется около 180 слов, относящихся к снегу и льду, а также до тысячи слов для обозначения оленей[8]. Другое исследование, посвящённое конноспортивной лексике в киргизском языке, выявило более десяти определений для наименования возрастных групп лошадей[9].
До закона открытия закона всемирного тяготения существовали слова "предмет", "отпущенный", "земля", "падает". Вот фраза "Отпущенный предмет падает на землю" на языке тумбука: "Chinthu icho chafumiskika chikuwa pasi".
Занимательный факт. В языке индейцев, живущих у Амазонки, в языке существует несколько десятков (до ста) названий рыб. У алеутов десятки названий для снега и льда. Как думаете, почему? Да потому что это требовалось для выживания. Именно для выживания язык (точнее, понятийный аппарат) становится критическим фактором. Конкретно вы, попав в джунгли или в прошлое к дикарям, не выживете, потому что у вас нет соответствующего понятийного аппарата (и соответственно, слов) и вы просто не сможете, как говорится, "посоображать".
При чем коммунистическая гниль? Сращивание сверхкрупного бизнеса и государства - это чисто капиталистическая фишка (первая стадия империализма). Строго по Марксу-Ленину.
Не очень понятно, кто заполняет спецификацию? Проблема была в том, что никто не описывает и не документирует 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, из-за чего (теоретически) строки от разных потоков будут писаться в страницы индекса вперемешку, что приведет к частым перебалансировкам дерева индекса. Разве что распределить данные по разным секциям и сделать, чтобы каждый поток писал в свою секцию.
Если индексов в таблице много, имеет ли смысл отключить их на момент массовой вставки, а потом пересоздать? Было ли это в данной работе сделано?
Искажения коммуникации были всегда. Алгоритмы тут ни при чем.
Административные методы еще более подвластны человеку.
Причем тут заявления? Это сугубо мое мнение. Давным-давно, еще в молодости, я читал подробную статью в "Наука и жизнь", где поминутно было все расписано. И меня поразило, что началось все с того, что научный персонал на станции (или в министерстве энергетики, плохо помню) решило получить ответ на вопрос - сколько еще будет станция выдавать ток, если реактор мгновенно заглушить? Каков выбег или как-то так. Провести эксперимент на работающем реакторе. Насколько помню, такие режимы работы запрещались инструкциями.
Это вообще как, нормально по-вашему, играться с реактором?
Причем тут конструктивные недостатки? Причем тут крайне редкие стечения обстоятельств? В случае Фукусимы можно кивать на крайне редкие стечения обстоятельств. В данном случае какие редкие стечения обстоятельств? Что в Минэнерго СССР собралось столько идиотов, решивших поиграть с ядеркой?
После этого, между прочим, все ядерные электростанции передали в ведение Минсредмаша (если кто понимает, что это такое) а потом и вовсе - создали специализированное Министерство ядерной энергетики.
Upd. А Магатэ, конечно, будет педалировать тему, что советские ядерные реакторы опасны. Этого следовало ожидать.
Да оба хуже
Как это в Чернобыле не человеческий фактор? Причиной аварии был эксперимент, который руководство и научный персонал станции решило провести на работающем ядерном реакторе.
При чем тут правительство, кстати говоря? Злодейство совершила частная компания. Экономит и косячит одни люди, а разгребать должно государство...
Не "рискуя", а ценой своей жизни и здоровья.
Доверяю по вопросам здоровья.
Могу свой кейс рассказать. Во время диспансеризации делал подробные анализы крови. Врачи толком ничего не сказали. Все хорошо.
Я загнал pdf-ки с анализами в дипсик и попросил проанализировать и дать рекомендации. Дипсик сказал, что все хорошо, но повышен уровень холестерина повышенный. Объяснил про риски, к которым это ведет. Сказал, что надо делать - тренировки на дорожке с высокой нагрузкой на сердце три раза в неделю. Через несколько месяцев делал повторно анализы - все пришло в норму.
Есть свидетельства о взаимодействии шаровых молний с предметами. Оплавления, обгорания и прочее - это не галлюцинации, а реальные предметы.
Во-первых, надо брать функцию с минимальной степенью. Во-вторых, делить данные на обучающую и тестовую выборку. Если после прогона обучающей выборки, ваша модель дает те-же результаты, что и в тестовой выборке, то поздравляю - это ваша цифровая копия. Если ваша цифровая копия дает те-же ответы в типичных диалогах, что и вы бы дали, и например, ваши родные не могли заподозрить, что отвечает ваша копия, а не вы, то можно предположить, что создана ваша цифровая копия.
Виды снега (состояние и консистенция):
Aputiit — снежные заструги (гребни, вырезанные ветром).
Pukak — рыхлый снег внизу, похожий на соль.
Pukaksaq — старый рыхлый снег, пригодный для строительства иглу (если его утрамбовать).
Maujaq — снег настолько глубокий и мягкий, что вязнешь.
Massak — топкий, мокрый снег, по которому трудно идти (каша).
Autilautaq — мокрый снег, который можно скатать в шар.
Katiksunniq — плотный снег, по которому хорошо идти.
Pukirtaq — снег, который проваливается под ногами с хрустом.
Aniu — снег, смешанный с землей (грязный снег весной).
Процессы и явления:
Qanniq — сам процесс снегопада.
Qannialuk — сильный снегопад, пурга.
Qanniapik — легкий снегопад, снежинки в воздухе.
Natiruvaaq — первый снег (еще не укрывший землю полностью).
Pitsiutaq — метель, поземка (низовой ветер со снегом).
Pigsiq — сильная метель, буран (когда ничего не видно).
Виды льда:
Siku — лед вообще.
Sikuliaq — молодой, тонкий лед (первый лед на воде).
Sikuaq — тонкий лед, только что покрывший воду.
Qinuq — лед, который намерзает слоями (наслоенный лед).
Tugaq — ледяной торос, нагромождение льда.
Ivuniq — ледяной холм, торос (большое скопление обломков льда).
Puktaaq — льдина, дрейфующая в воде.
Puttak — полынья, открытая вода во льду (продушина).
Qaannuq — лед, который только начинает ломаться.
Kaimukvee — лед, вздыбленный течением.
Agnak — глыба пресного льда (например, отколовшаяся от ледника).
Nilak — пресная вода, намерзшая на морском льду (сверху), пригодная для питья.
Тут же была уже статься с визуализацией. Между звездными системами чудовищные расстояния. Вероятность появления жизни и развития до цивилизации, способной отправить сигнал - невероятно низкая. Продолжительность жизни цивилизации - по меркам планеты крайне мала (даже миллион лет). Пока сигнал идет от цивилизации до другой цивилизации, которая в этот момент может существовать - проходит миллионы и миллиарды лет.
Я предлагаю вам еще раз прочитать эту статью, полностью. В этой статье не только не говорится, что это миф, но тащемта, только подтверждаются мои слова.
До закона открытия закона всемирного тяготения существовали слова "предмет", "отпущенный", "земля", "падает". Вот фраза "Отпущенный предмет падает на землю" на языке тумбука: "Chinthu icho chafumiskika chikuwa pasi".
Занимательный факт. В языке индейцев, живущих у Амазонки, в языке существует несколько десятков (до ста) названий рыб. У алеутов десятки названий для снега и льда. Как думаете, почему? Да потому что это требовалось для выживания. Именно для выживания язык (точнее, понятийный аппарат) становится критическим фактором. Конкретно вы, попав в джунгли или в прошлое к дикарям, не выживете, потому что у вас нет соответствующего понятийного аппарата (и соответственно, слов) и вы просто не сможете, как говорится, "посоображать".