Зачем? У руководителей денег жопой жуй, они своим любовницам и так покупают и айфоны и джипы. А разрешать мелким чиновникам растащить домой... зачем им это (руководству)? Потенциальные проблемы огрести?
Они на этих купленных ранее за государственные деньги айфоны откатов заимели не то что на свои айфоны, а на особняки и джипы. Эта техника уже "окупилась" давным-давно и интереса никакого не представляет.
Значит, Чжао разработает еще один инструмент, который будет определять, "отравленная" картинка или нет. И разработчики моделей будут платить большие деньги Чжао за этот инструмент. Что вы паникуете? Деньги решат любые проблемы.
Совершенно верно. Но - по убывающей. А раз каждый последующий мир проще и меньше, то значит, эта цепочка конечная. Я бы даже сказал, очень конечная. И опять же это ставит крест на "доказательстве" Маска о том, что вложенных друг в друга симуляций бесконечное множество и, соответственно, вероятность, что мы уже живем в одной из них приближается к единице.
По-вашему, камень, брошенный по параболе мальчиком, сначала существует, пока на него смотрит мальчик. Симуляция производится, компьютер бога итерациями просчитывает траекторию полета камня. Потом мальчик отворачивается и камень исчезает. Компьютер прекращает обсчитывание полета камня. Затем мальчик снова взглядывает на камень и камень опять появляется. Опа! Но уже в другом месте. Как компьютер бога узнал, в каком месте продолжить итерации? Напомню, по задаче трех тел нет возможности формулой узнать место продолжения итераций. Только численно, только итерациями.
Только по этому мысленному эксперименту фраза про "наблюдателся" - чепуха.
Симуляцию необходимо проводить для всех N частиц вселенной и для всех переносчиков взаимодействий, для гравитации - N*(N-1)/2 постоянно, независимо от наблюдателя.
Для хранения характеристики (квантового числа) чего угодно, например электрона, требуется как минимум, один бит. Один бит может храниться в самом лучшем случае, одним квантовым объектом. Один квантовый объект имеет несколько характеристик минимум. Следовательно, для моделирования хотя бы одного квантового объекта, требуется множество квантовых объектов. На каждое взаимодействие между ними - еще несколько (взаимодействия, как мы помним, описываются частицами-переносчиками). В реальности потребуются миллионы и миллиарды квантовых частиц для моделирования хотя бы одного.
Как вывод - одна вселенная не может моделировать другую.
Подвывод - Маск (или кто там?) нес чепуху, когда говорил, что в одном компьютере моделируется целый мир, а в этом мире множество компьютеров, которые моделируют свои внутренние.
А с гравитацией еще проблема такая, что на всякой симуляции ставит крест. В отличии от других взаимодействий, гравитация простирается на бесконечные расстояния, то есть, фактически, нужно моделировать связь КАЖДОЙ частицы с другими ВСЕМИ частицами во вселенной.
Приходится приходить к метафизике и признавать, что симулировать вселенную под силу только богу.
Как энтерпрайзник, скажу - да, никто не требует писать правильно и хорошо. Наоборот, требуют делать быстро и не заморачиваться оптимизацией. Хотя под "не выполнять оптимизацию" вся контора начинать понимать, что надо писать ПЛОХОЙ код. А потом при запуске клиентом расчета по всем своим клиентам-потребителям вдруг внезапно выясняется, что вместо примемлемых трех-пяти часов расчет по всей базе клиентов выполняется несколько суток.
И начинается беготня и горение пуканов.
Да, между "неоптимизированным" и "плохим" кодом огромная пропасть.
Если уж охота вытягивать тепло этим способом, то только в комплекте с обычным сжиганием газа или угля: из дымовых газов забирать все тепло вплоть до отрицательной температуры дымового газа. Гнать его придется вентилятором, конечно.
Промораживание земли или озер - это настолько дико и неэкологично, что необходимо запрещать законом, имхо.
Почему вы у разработчика спрашиваете, готова ли фича? После его работы фича проходит стадии документирования, тестирования, деплоя. За все это отвечают другие люди и команды. Разработчик честно сказал, что он выполнил свою часть работы, вы выкатываете к нему претензии, что фича не на проде. Как так?
В этой ситуации виноват конкретно тот, кто спрашивает. Он не знает, кто за что ответственен? Он не знает, какие этапы проходит фича?
Здесь картиночки, Done, Potentially shippable не поможет.
Необходимо внедрение процесса разработки, воркфлоу, контроля передачи ответственности и закрытия этапов/работ. Короче Jira (хотя бы) спасет отца русской демократии.
Почему по старинке не делаете - набором таблиц, а документом сохраняете информацию? Таблица banners отдельно, отдельно embeddings, counters и так далее? И апдейтите свои счетчики - поля int в строках.
А то выглядит так - перешли на волне моды на NoSQL, а теперь героически боретесь с основополагающими недостатками документ-ориентированной технологии.
Даже сейчас считаю возможным выделить часто изменяющиеся данные типа счетчиков в отдельные таблицы, да и вообще говоря, применить не sql-сервера, а например, хранилища ключ-значение.
Этот фреймворк слишком большой (перечисление всего, что написано в этой статье). Нужно написать новый фреймворк. Легкий. Быстрый. Безопасный.
Слишком много ошибок в велосипедах. Много кода. Читать невозможно. Применим вот эти и эти библиотеки. Они надежны.
Пользователи жалуются, что фреймворк почти ничего не умеет. Необходимо добавить два десятка фич. Открываем проект, даем всем желающим добавлять нужный функционал.
Фреймворк еле шевелится. Читать его невозможно. Апи невменяемое, глючное, противоречивое, непонятное. Размер огромный. При каждом изменении версий библиотек проект разваливается.
Два замечания. Нативный запрос (если я не ошибаюсь) выдает результат без помещения объектов в контекст, что может давать проблемы при использовании этих запросов в одной транзакции с нормальными jpa jpql запросами. Это надо учитывать.
Второе, хотелось бы подробное исследование по универсальным запросам - как сделать так, чтобы универсальные запросы по разным полями адекватно использовали индексы?
Можно, мы так и делаем. Во всяких отчетах, где нет возможности оперировать запросом, только так.
Но такой стиль плохо на производительность влияет. Впрочем, в универсальных запросах с условиями по разным полям с производительностью и так все плохо.
Про возраст сильно зависит от конторы. В каких-то "потогонках" спецом берут только молодняк. В других, высокотехнологичных, берут людей с опытом. Если контора клепает сайтики - там конечно нет высокого возраста. Если контора разрабатывает электронику - там обязательно будут водиться "зубры".
Зачем? У руководителей денег жопой жуй, они своим любовницам и так покупают и айфоны и джипы. А разрешать мелким чиновникам растащить домой... зачем им это (руководству)? Потенциальные проблемы огрести?
Они на этих купленных ранее за государственные деньги айфоны откатов заимели не то что на свои айфоны, а на особняки и джипы. Эта техника уже "окупилась" давным-давно и интереса никакого не представляет.
Значит, Чжао разработает еще один инструмент, который будет определять, "отравленная" картинка или нет. И разработчики моделей будут платить большие деньги Чжао за этот инструмент. Что вы паникуете? Деньги решат любые проблемы.
Совершенно верно. Но - по убывающей. А раз каждый последующий мир проще и меньше, то значит, эта цепочка конечная. Я бы даже сказал, очень конечная. И опять же это ставит крест на "доказательстве" Маска о том, что вложенных друг в друга симуляций бесконечное множество и, соответственно, вероятность, что мы уже живем в одной из них приближается к единице.
По-вашему, камень, брошенный по параболе мальчиком, сначала существует, пока на него смотрит мальчик. Симуляция производится, компьютер бога итерациями просчитывает траекторию полета камня. Потом мальчик отворачивается и камень исчезает. Компьютер прекращает обсчитывание полета камня. Затем мальчик снова взглядывает на камень и камень опять появляется. Опа! Но уже в другом месте. Как компьютер бога узнал, в каком месте продолжить итерации? Напомню, по задаче трех тел нет возможности формулой узнать место продолжения итераций. Только численно, только итерациями.
Только по этому мысленному эксперименту фраза про "наблюдателся" - чепуха.
Симуляцию необходимо проводить для всех N частиц вселенной и для всех переносчиков взаимодействий, для гравитации - N*(N-1)/2 постоянно, независимо от наблюдателя.
Мир существует независимо от нас.
-> Fiat lux
Для хранения характеристики (квантового числа) чего угодно, например электрона, требуется как минимум, один бит. Один бит может храниться в самом лучшем случае, одним квантовым объектом. Один квантовый объект имеет несколько характеристик минимум. Следовательно, для моделирования хотя бы одного квантового объекта, требуется множество квантовых объектов. На каждое взаимодействие между ними - еще несколько (взаимодействия, как мы помним, описываются частицами-переносчиками). В реальности потребуются миллионы и миллиарды квантовых частиц для моделирования хотя бы одного.
Как вывод - одна вселенная не может моделировать другую.
Подвывод - Маск (или кто там?) нес чепуху, когда говорил, что в одном компьютере моделируется целый мир, а в этом мире множество компьютеров, которые моделируют свои внутренние.
А с гравитацией еще проблема такая, что на всякой симуляции ставит крест. В отличии от других взаимодействий, гравитация простирается на бесконечные расстояния, то есть, фактически, нужно моделировать связь КАЖДОЙ частицы с другими ВСЕМИ частицами во вселенной.
Приходится приходить к метафизике и признавать, что симулировать вселенную под силу только богу.
Как энтерпрайзник, скажу - да, никто не требует писать правильно и хорошо. Наоборот, требуют делать быстро и не заморачиваться оптимизацией. Хотя под "не выполнять оптимизацию" вся контора начинать понимать, что надо писать ПЛОХОЙ код. А потом при запуске клиентом расчета по всем своим клиентам-потребителям вдруг внезапно выясняется, что вместо примемлемых трех-пяти часов расчет по всей базе клиентов выполняется несколько суток.
И начинается беготня и горение пуканов.
Да, между "неоптимизированным" и "плохим" кодом огромная пропасть.
Если уж охота вытягивать тепло этим способом, то только в комплекте с обычным сжиганием газа или угля: из дымовых газов забирать все тепло вплоть до отрицательной температуры дымового газа. Гнать его придется вентилятором, конечно.
Промораживание земли или озер - это настолько дико и неэкологично, что необходимо запрещать законом, имхо.
Совершенно неактуальная статья для начала 2024 года.
У вас нет разграничение зон ответственности.
Почему вы у разработчика спрашиваете, готова ли фича? После его работы фича проходит стадии документирования, тестирования, деплоя. За все это отвечают другие люди и команды. Разработчик честно сказал, что он выполнил свою часть работы, вы выкатываете к нему претензии, что фича не на проде. Как так?
В этой ситуации виноват конкретно тот, кто спрашивает. Он не знает, кто за что ответственен? Он не знает, какие этапы проходит фича?
Здесь картиночки, Done, Potentially shippable не поможет.
Необходимо внедрение процесса разработки, воркфлоу, контроля передачи ответственности и закрытия этапов/работ. Короче Jira (хотя бы) спасет отца русской демократии.
Почему по старинке не делаете - набором таблиц, а документом сохраняете информацию? Таблица banners отдельно, отдельно embeddings, counters и так далее? И апдейтите свои счетчики - поля int в строках.
А то выглядит так - перешли на волне моды на NoSQL, а теперь героически боретесь с основополагающими недостатками документ-ориентированной технологии.
Даже сейчас считаю возможным выделить часто изменяющиеся данные типа счетчиков в отдельные таблицы, да и вообще говоря, применить не sql-сервера, а например, хранилища ключ-значение.
Увы, в мире рынка компании будут писать компактные программы только тогда, когда это будет выгодно.
Когда будет выгодно писать компактные программы?
Когда клиенты будут покупать десктопные приложения, а не web-энтерпрайз.
Когда эксплуатация компактных десктопных приложений будет дешевле web-приложений.
"Калькулятор" нужно писать на Delphi/Lazarus.
Этот фреймворк слишком большой (перечисление всего, что написано в этой статье). Нужно написать новый фреймворк. Легкий. Быстрый. Безопасный.
Слишком много ошибок в велосипедах. Много кода. Читать невозможно. Применим вот эти и эти библиотеки. Они надежны.
Пользователи жалуются, что фреймворк почти ничего не умеет. Необходимо добавить два десятка фич. Открываем проект, даем всем желающим добавлять нужный функционал.
Наворотили фич, кода. "Все желающие" также наворотили фич, кода, понадобавляли библиотек.
Фреймворк еле шевелится. Читать его невозможно. Апи невменяемое, глючное, противоречивое, непонятное. Размер огромный. При каждом изменении версий библиотек проект разваливается.
Перейти к п. 1.
Два замечания. Нативный запрос (если я не ошибаюсь) выдает результат без помещения объектов в контекст, что может давать проблемы при использовании этих запросов в одной транзакции с нормальными jpa jpql запросами. Это надо учитывать.
Второе, хотелось бы подробное исследование по универсальным запросам - как сделать так, чтобы универсальные запросы по разным полями адекватно использовали индексы?
Можно, мы так и делаем. Во всяких отчетах, где нет возможности оперировать запросом, только так.
Но такой стиль плохо на производительность влияет. Впрочем, в универсальных запросах с условиями по разным полям с производительностью и так все плохо.
И даже так, сложность hasmap не является константой, а от O(1) в лучшем случае до O(n) в худшем.
В аналитики.
В каких вы конторах работали?
Про возраст сильно зависит от конторы. В каких-то "потогонках" спецом берут только молодняк. В других, высокотехнологичных, берут людей с опытом. Если контора клепает сайтики - там конечно нет высокого возраста. Если контора разрабатывает электронику - там обязательно будут водиться "зубры".
Пиши про второе высшее.