Дядя Боб пишет, что состояние потока - вредно и его нужно избегать. У меня к этому мнению двойственное отношение, но возможно, что плюс парного программирования также и в том, чтобы вывести из потока и заставить маленько думать и критически относиться к тому, что мастрячишь в коде.
Философия, история, практика и интуиция говорит, что эффективность команды интенсивно повышается только при включении в нее специфично развитых членов. Это и в марвеловских фильмах очень хорошо показано.
Добавление в команду точно такого-же члена, как в команде были, не увеличивает производительность в два раза (экстенсивное развитие). Даже если у каждого по компьютеру и они работают ПАРАЛЛЕЛЬНО. Тем более, если они работают на одном компе и второй по-сути, простаивает.
Интенсивное развитие достижимо только в том случае, если в команду добавляются специфичные по скиллам участники (при этом работают параллельно и совместно).
Суть интенсификации любого производства - в специализации участников. В промпроизводстве это известно уже триста лет. И только в ИТ предлагается добавлять в команду однородных участников.
Парная работа (как частный случай командной работы) может быть эффективен, когда оба участника очень специфичны в скиллах и направлениях.
Например, я вижу смысл, когда очень сильный постановщик (специалист по бизнесу) сидит бок о бок (буквально на одном столе, но каждый со своим ноутом) с бекэндером, и они работают практически над одним и тем-же, постоянно и плотно обмениваясь информацией. После завершения задачи пара разбегается и бэкендер подсаживается (или наоборот) к другому постановщику и начинают работать над другой задачей.
Игра в планирование с карточками - по сути попытка приблизиться к описанному сейчас идеалу, но у создателей Экстр. Пр. не хватило смелости и мужества довести задумку до конца.
Единственный плюс парного программирования - что оба человека стесняются друг перед другом бакланить и начинают работать.
Вот сколько "рекламных" статей про реактивку читал и везде юзают один и тот-же кейс с рестораном. Совершенно не отражающий суть процессов. В примере с рестораном оператор один. В реальности - получает оплату, отдает чек и переходит к следующему клиенту. Клиент ждет, когда придет заказ. В обычном нереактивном приложении "оператор" не один, более того, при увеличении нагрузки количество операторов увеличивается динамически. Физически и оператор и повар - один процесс. Никто никого не ждет, кроме случая доступа к диску, там ОС отправляет процесс поспать. Единственная проблема - суперпростой сервис, получающий десятки тысяч запросов в секунду, при котором создание процессов средствами ОС становится накладным. В обычных монолитных приложениях для бизнеса такого не бывает.
Сколько ни читал, никаких реальных преимуществ по времени реактивка не показывала, кроме специально сгенерированных случаев.
Создается впечатление, что реакт - очередная велосипедосамодеятельность. С внедрением легковесных потоков, решающих проблему суперпростых сервисов и тысячных нагрузок, реакт необходимо выбросить.
Будет пенсия у восьмидесятников. По тем-же причинам, по которым государство платит нынешним пенсионерам. Если государство не будет платить пенсии - будет социальный взрыв, развешивание элит на фонарях, гражданская война и прочие прелести.
Или вы всерьез думаете, что государство сейчас платит пенсии из побуждений добра? При нынешней капиталистической идеологии государство с удовольствием бы перевесило нынешнюю систему на накопительную, сиречь на самих работников. И даже пыталось это сделать. С ожидаемым успехом.
Поэтому платить пенсии будут. Будут изыскивать средства, продавать нефть, печатать деньги и прочее. Если часть (хотя бы часть) этих затрат будут платить следующее поколение - вообще замечательно будет! И да, пенсии будут ровно настолько минимальными, чтобы не вызвать социального взрыва. Как впрочем, и сейчас.
Не переживайте. Пенсии у вас будут. Но хреновенькие.
Зачем? У руководителей денег жопой жуй, они своим любовницам и так покупают и айфоны и джипы. А разрешать мелким чиновникам растащить домой... зачем им это (руководству)? Потенциальные проблемы огрести?
Они на этих купленных ранее за государственные деньги айфоны откатов заимели не то что на свои айфоны, а на особняки и джипы. Эта техника уже "окупилась" давным-давно и интереса никакого не представляет.
Значит, Чжао разработает еще один инструмент, который будет определять, "отравленная" картинка или нет. И разработчики моделей будут платить большие деньги Чжао за этот инструмент. Что вы паникуете? Деньги решат любые проблемы.
Совершенно верно. Но - по убывающей. А раз каждый последующий мир проще и меньше, то значит, эта цепочка конечная. Я бы даже сказал, очень конечная. И опять же это ставит крест на "доказательстве" Маска о том, что вложенных друг в друга симуляций бесконечное множество и, соответственно, вероятность, что мы уже живем в одной из них приближается к единице.
По-вашему, камень, брошенный по параболе мальчиком, сначала существует, пока на него смотрит мальчик. Симуляция производится, компьютер бога итерациями просчитывает траекторию полета камня. Потом мальчик отворачивается и камень исчезает. Компьютер прекращает обсчитывание полета камня. Затем мальчик снова взглядывает на камень и камень опять появляется. Опа! Но уже в другом месте. Как компьютер бога узнал, в каком месте продолжить итерации? Напомню, по задаче трех тел нет возможности формулой узнать место продолжения итераций. Только численно, только итерациями.
Только по этому мысленному эксперименту фраза про "наблюдателся" - чепуха.
Симуляцию необходимо проводить для всех N частиц вселенной и для всех переносчиков взаимодействий, для гравитации - N*(N-1)/2 постоянно, независимо от наблюдателя.
Для хранения характеристики (квантового числа) чего угодно, например электрона, требуется как минимум, один бит. Один бит может храниться в самом лучшем случае, одним квантовым объектом. Один квантовый объект имеет несколько характеристик минимум. Следовательно, для моделирования хотя бы одного квантового объекта, требуется множество квантовых объектов. На каждое взаимодействие между ними - еще несколько (взаимодействия, как мы помним, описываются частицами-переносчиками). В реальности потребуются миллионы и миллиарды квантовых частиц для моделирования хотя бы одного.
Как вывод - одна вселенная не может моделировать другую.
Подвывод - Маск (или кто там?) нес чепуху, когда говорил, что в одном компьютере моделируется целый мир, а в этом мире множество компьютеров, которые моделируют свои внутренние.
А с гравитацией еще проблема такая, что на всякой симуляции ставит крест. В отличии от других взаимодействий, гравитация простирается на бесконечные расстояния, то есть, фактически, нужно моделировать связь КАЖДОЙ частицы с другими ВСЕМИ частицами во вселенной.
Приходится приходить к метафизике и признавать, что симулировать вселенную под силу только богу.
Как энтерпрайзник, скажу - да, никто не требует писать правильно и хорошо. Наоборот, требуют делать быстро и не заморачиваться оптимизацией. Хотя под "не выполнять оптимизацию" вся контора начинать понимать, что надо писать ПЛОХОЙ код. А потом при запуске клиентом расчета по всем своим клиентам-потребителям вдруг внезапно выясняется, что вместо примемлемых трех-пяти часов расчет по всей базе клиентов выполняется несколько суток.
И начинается беготня и горение пуканов.
Да, между "неоптимизированным" и "плохим" кодом огромная пропасть.
Если уж охота вытягивать тепло этим способом, то только в комплекте с обычным сжиганием газа или угля: из дымовых газов забирать все тепло вплоть до отрицательной температуры дымового газа. Гнать его придется вентилятором, конечно.
Промораживание земли или озер - это настолько дико и неэкологично, что необходимо запрещать законом, имхо.
Почему вы у разработчика спрашиваете, готова ли фича? После его работы фича проходит стадии документирования, тестирования, деплоя. За все это отвечают другие люди и команды. Разработчик честно сказал, что он выполнил свою часть работы, вы выкатываете к нему претензии, что фича не на проде. Как так?
В этой ситуации виноват конкретно тот, кто спрашивает. Он не знает, кто за что ответственен? Он не знает, какие этапы проходит фича?
Здесь картиночки, Done, Potentially shippable не поможет.
Необходимо внедрение процесса разработки, воркфлоу, контроля передачи ответственности и закрытия этапов/работ. Короче Jira (хотя бы) спасет отца русской демократии.
Почему по старинке не делаете - набором таблиц, а документом сохраняете информацию? Таблица banners отдельно, отдельно embeddings, counters и так далее? И апдейтите свои счетчики - поля int в строках.
А то выглядит так - перешли на волне моды на NoSQL, а теперь героически боретесь с основополагающими недостатками документ-ориентированной технологии.
Даже сейчас считаю возможным выделить часто изменяющиеся данные типа счетчиков в отдельные таблицы, да и вообще говоря, применить не sql-сервера, а например, хранилища ключ-значение.
Дядя Боб пишет, что состояние потока - вредно и его нужно избегать. У меня к этому мнению двойственное отношение, но возможно, что плюс парного программирования также и в том, чтобы вывести из потока и заставить маленько думать и критически относиться к тому, что мастрячишь в коде.
Философия, история, практика и интуиция говорит, что эффективность команды интенсивно повышается только при включении в нее специфично развитых членов. Это и в марвеловских фильмах очень хорошо показано.
Добавление в команду точно такого-же члена, как в команде были, не увеличивает производительность в два раза (экстенсивное развитие). Даже если у каждого по компьютеру и они работают ПАРАЛЛЕЛЬНО. Тем более, если они работают на одном компе и второй по-сути, простаивает.
Интенсивное развитие достижимо только в том случае, если в команду добавляются специфичные по скиллам участники (при этом работают параллельно и совместно).
Суть интенсификации любого производства - в специализации участников. В промпроизводстве это известно уже триста лет. И только в ИТ предлагается добавлять в команду однородных участников.
Парная работа (как частный случай командной работы) может быть эффективен, когда оба участника очень специфичны в скиллах и направлениях.
Например, я вижу смысл, когда очень сильный постановщик (специалист по бизнесу) сидит бок о бок (буквально на одном столе, но каждый со своим ноутом) с бекэндером, и они работают практически над одним и тем-же, постоянно и плотно обмениваясь информацией. После завершения задачи пара разбегается и бэкендер подсаживается (или наоборот) к другому постановщику и начинают работать над другой задачей.
Игра в планирование с карточками - по сути попытка приблизиться к описанному сейчас идеалу, но у создателей Экстр. Пр. не хватило смелости и мужества довести задумку до конца.
Единственный плюс парного программирования - что оба человека стесняются друг перед другом бакланить и начинают работать.
Вот сколько "рекламных" статей про реактивку читал и везде юзают один и тот-же кейс с рестораном. Совершенно не отражающий суть процессов. В примере с рестораном оператор один. В реальности - получает оплату, отдает чек и переходит к следующему клиенту. Клиент ждет, когда придет заказ. В обычном нереактивном приложении "оператор" не один, более того, при увеличении нагрузки количество операторов увеличивается динамически. Физически и оператор и повар - один процесс. Никто никого не ждет, кроме случая доступа к диску, там ОС отправляет процесс поспать. Единственная проблема - суперпростой сервис, получающий десятки тысяч запросов в секунду, при котором создание процессов средствами ОС становится накладным. В обычных монолитных приложениях для бизнеса такого не бывает.
Сколько ни читал, никаких реальных преимуществ по времени реактивка не показывала, кроме специально сгенерированных случаев.
Создается впечатление, что реакт - очередная велосипедосамодеятельность. С внедрением легковесных потоков, решающих проблему суперпростых сервисов и тысячных нагрузок, реакт необходимо выбросить.
Будет пенсия у восьмидесятников. По тем-же причинам, по которым государство платит нынешним пенсионерам. Если государство не будет платить пенсии - будет социальный взрыв, развешивание элит на фонарях, гражданская война и прочие прелести.
Или вы всерьез думаете, что государство сейчас платит пенсии из побуждений добра? При нынешней капиталистической идеологии государство с удовольствием бы перевесило нынешнюю систему на накопительную, сиречь на самих работников. И даже пыталось это сделать. С ожидаемым успехом.
Поэтому платить пенсии будут. Будут изыскивать средства, продавать нефть, печатать деньги и прочее. Если часть (хотя бы часть) этих затрат будут платить следующее поколение - вообще замечательно будет! И да, пенсии будут ровно настолько минимальными, чтобы не вызвать социального взрыва. Как впрочем, и сейчас.
Не переживайте. Пенсии у вас будут. Но хреновенькие.
Эта статья отлично сочетается с https://habr.com/ru/companies/cloud_mts/articles/793428/
Очень спорные правила наименования тестовых методов.
sql надо писать под конкретную базу?
ON DUPLICATE KEY UPDATE qty = #{count} - это для mySql, похоже?
А как пилить на такой помощи?
Зачем? У руководителей денег жопой жуй, они своим любовницам и так покупают и айфоны и джипы. А разрешать мелким чиновникам растащить домой... зачем им это (руководству)? Потенциальные проблемы огрести?
Они на этих купленных ранее за государственные деньги айфоны откатов заимели не то что на свои айфоны, а на особняки и джипы. Эта техника уже "окупилась" давным-давно и интереса никакого не представляет.
Значит, Чжао разработает еще один инструмент, который будет определять, "отравленная" картинка или нет. И разработчики моделей будут платить большие деньги Чжао за этот инструмент. Что вы паникуете? Деньги решат любые проблемы.
Совершенно верно. Но - по убывающей. А раз каждый последующий мир проще и меньше, то значит, эта цепочка конечная. Я бы даже сказал, очень конечная. И опять же это ставит крест на "доказательстве" Маска о том, что вложенных друг в друга симуляций бесконечное множество и, соответственно, вероятность, что мы уже живем в одной из них приближается к единице.
По-вашему, камень, брошенный по параболе мальчиком, сначала существует, пока на него смотрит мальчик. Симуляция производится, компьютер бога итерациями просчитывает траекторию полета камня. Потом мальчик отворачивается и камень исчезает. Компьютер прекращает обсчитывание полета камня. Затем мальчик снова взглядывает на камень и камень опять появляется. Опа! Но уже в другом месте. Как компьютер бога узнал, в каком месте продолжить итерации? Напомню, по задаче трех тел нет возможности формулой узнать место продолжения итераций. Только численно, только итерациями.
Только по этому мысленному эксперименту фраза про "наблюдателся" - чепуха.
Симуляцию необходимо проводить для всех N частиц вселенной и для всех переносчиков взаимодействий, для гравитации - N*(N-1)/2 постоянно, независимо от наблюдателя.
Мир существует независимо от нас.
-> Fiat lux
Для хранения характеристики (квантового числа) чего угодно, например электрона, требуется как минимум, один бит. Один бит может храниться в самом лучшем случае, одним квантовым объектом. Один квантовый объект имеет несколько характеристик минимум. Следовательно, для моделирования хотя бы одного квантового объекта, требуется множество квантовых объектов. На каждое взаимодействие между ними - еще несколько (взаимодействия, как мы помним, описываются частицами-переносчиками). В реальности потребуются миллионы и миллиарды квантовых частиц для моделирования хотя бы одного.
Как вывод - одна вселенная не может моделировать другую.
Подвывод - Маск (или кто там?) нес чепуху, когда говорил, что в одном компьютере моделируется целый мир, а в этом мире множество компьютеров, которые моделируют свои внутренние.
А с гравитацией еще проблема такая, что на всякой симуляции ставит крест. В отличии от других взаимодействий, гравитация простирается на бесконечные расстояния, то есть, фактически, нужно моделировать связь КАЖДОЙ частицы с другими ВСЕМИ частицами во вселенной.
Приходится приходить к метафизике и признавать, что симулировать вселенную под силу только богу.
Как энтерпрайзник, скажу - да, никто не требует писать правильно и хорошо. Наоборот, требуют делать быстро и не заморачиваться оптимизацией. Хотя под "не выполнять оптимизацию" вся контора начинать понимать, что надо писать ПЛОХОЙ код. А потом при запуске клиентом расчета по всем своим клиентам-потребителям вдруг внезапно выясняется, что вместо примемлемых трех-пяти часов расчет по всей базе клиентов выполняется несколько суток.
И начинается беготня и горение пуканов.
Да, между "неоптимизированным" и "плохим" кодом огромная пропасть.
Если уж охота вытягивать тепло этим способом, то только в комплекте с обычным сжиганием газа или угля: из дымовых газов забирать все тепло вплоть до отрицательной температуры дымового газа. Гнать его придется вентилятором, конечно.
Промораживание земли или озер - это настолько дико и неэкологично, что необходимо запрещать законом, имхо.
Совершенно неактуальная статья для начала 2024 года.
У вас нет разграничение зон ответственности.
Почему вы у разработчика спрашиваете, готова ли фича? После его работы фича проходит стадии документирования, тестирования, деплоя. За все это отвечают другие люди и команды. Разработчик честно сказал, что он выполнил свою часть работы, вы выкатываете к нему претензии, что фича не на проде. Как так?
В этой ситуации виноват конкретно тот, кто спрашивает. Он не знает, кто за что ответственен? Он не знает, какие этапы проходит фича?
Здесь картиночки, Done, Potentially shippable не поможет.
Необходимо внедрение процесса разработки, воркфлоу, контроля передачи ответственности и закрытия этапов/работ. Короче Jira (хотя бы) спасет отца русской демократии.
Почему по старинке не делаете - набором таблиц, а документом сохраняете информацию? Таблица banners отдельно, отдельно embeddings, counters и так далее? И апдейтите свои счетчики - поля int в строках.
А то выглядит так - перешли на волне моды на NoSQL, а теперь героически боретесь с основополагающими недостатками документ-ориентированной технологии.
Даже сейчас считаю возможным выделить часто изменяющиеся данные типа счетчиков в отдельные таблицы, да и вообще говоря, применить не sql-сервера, а например, хранилища ключ-значение.
Увы, в мире рынка компании будут писать компактные программы только тогда, когда это будет выгодно.
Когда будет выгодно писать компактные программы?
Когда клиенты будут покупать десктопные приложения, а не web-энтерпрайз.
Когда эксплуатация компактных десктопных приложений будет дешевле web-приложений.