Дорогой, AI, найди мне лучших оптовых покупателей для чехлов для телефонов, которые я купил на Али, так что -ли? (Бывшие SEO потирают руки от открывшихся перспектив)
Очень зависит от начальства. В худшем случае, Через 3 года, прикручивая очередную 10+ хотелку бизнеса в этот алгоритм, ты все проклянешь - ведь выделят тебе на это по прежнему только 15 минут.
Для ЛЛ: Делайте хорошо, не делайте плохо и занимайтесь зарядкой по утрам. Тестировщик должен ... Тестировщику следует ... Без единого практического примера.
>При обсуждении проектов старайтесь отклоняться от поверхностного обсуждения (плохо не >делайте – делайте хорошо или когда будет готово всё) и максимально подробно обсуждать >технические детали. Зароетесь в детали и упустите суть.
Был же пример, что в обсуждении конструкции атомной электростанции больше всего времени уйдет на обсуждение стоянки для автомобилей, потому что она понятна всем и ее конструкция не требует спец. знаний. А конструкция реактора будет обсуждаться по минимуму, потому что требует специальных знаний.
Есть же куча литературы о сборе требований, го ведении переговоров.Нельзя это просто сократить до одного пункта.
> Поэтому я и отказался от вопросов в лоб. Люто поддерживаю. > Люди не видят связи между инструментом и кейсом его применения. В защиту кандидатов: Потому что куча подводных камней, и теория далеко отстоит от практики. Сложность при доступе к данным никого не интересует, важна скорость и ресурсы. И если на практике сложный алгоритм окажется быстрее, выберут его. Поэтому в реальной жизни и table full scan часто быстрее вообще любого индекса, и 90% таблиц в классической БД будут иметь "более медленный" b-tree индекс.
Конструкцию из петель для дверей мебели + электрический доводчик не рассматривали? Там встречаются интересные механические решения, например, для накладных дверей для встроенной техники.
Есть куча психологических приемов, почему бы ими не пользоваться? Есть из маленьких тарелок, не ходить в магазин голодным, пить стакан воды перед едой и т.д. , куча их. По отдельности эти меры помогут слабо, а в комплексе могут принести видимые изменения. Большинство этих приемов особой силы воли не требуют.
Хорошие индусы есть и их много. Только они, как не странно, денег хотят, и работают чаще напрямую на клиентов. А индусов набирают чтобы сэкономить, особенно на галеры . Поэтому нанимают самое дно.
Фича конечно интересная, но неужели кто-то ей реально пользуется? Вместо того, чтобы разгребать этот trigger hell, не проще ли сделать пакет, какой-нибудь dml_orders, который будет единственным разрешенным интерфейсом для обновления данных в таблицах? Если планируются mass updates, то лучше предусмотреть отдельную функцию с каким нибудь ref cursor на входе, чем городить лапшу из триггеров.
<sarcasm> потому что это перенос бизнес логики в базу, код ревью не пройдет </sarcasm> Вообще жесть какая-то, что для простейшей в общем-то задачи надо разбираться в кишках hibernate.
Хм, посчитал приблизительно. Если к данным из википедии добавить данные о мини-гидтроэлектростанциях (около 4000 в австрии, по одной на каждых 2000 человек, около 40% от всей гидроэнергии ) то получается 75%. Как аналогия - по одной мини - гидроэлектростанции электростанции на среднюю московскую многоэтажку. Их реально много. Они реально их почти на каждом ручье строят.
Наушник агента Смита. Закрываете плеер с динамиком в металлическую коробку, резиновую трубку в ухо - и никаких излучений -)
Дорогой, AI, найди мне лучших оптовых покупателей для чехлов для телефонов, которые я купил на Али, так что -ли?
(Бывшие SEO потирают руки от открывшихся перспектив)
Чем это лучше updatable views? Не критикую, просто интересно.
Серебряной пули нет, но есть варианты
https://habr.com/ru/articles/101544/ + комменты
Очень зависит от начальства. В худшем случае, Через 3 года, прикручивая очередную 10+ хотелку бизнеса в этот алгоритм, ты все проклянешь - ведь выделят тебе на это по прежнему только 15 минут.
Для ЛЛ: Делайте хорошо, не делайте плохо и занимайтесь зарядкой по утрам. Тестировщик должен ... Тестировщику следует ...
Без единого практического примера.
В большой компании, на разных проектах, всегда будут и хорошие менеджеры и бесполезные болтуны. Учится взаимодействовать придеться со всеми.
Со всем согласен, кроме
>При обсуждении проектов старайтесь отклоняться от поверхностного обсуждения (плохо не >делайте – делайте хорошо или когда будет готово всё) и максимально подробно обсуждать >технические детали.
Зароетесь в детали и упустите суть.
Был же пример, что в обсуждении конструкции атомной электростанции больше всего времени уйдет на обсуждение стоянки для автомобилей, потому что она понятна всем и ее конструкция не требует спец. знаний. А конструкция реактора будет обсуждаться по минимуму, потому что требует специальных знаний.
Есть же куча литературы о сборе требований, го ведении переговоров.Нельзя это просто сократить до одного пункта.
> Поэтому я и отказался от вопросов в лоб.
Люто поддерживаю.
> Люди не видят связи между инструментом и кейсом его применения.
В защиту кандидатов:
Потому что куча подводных камней, и теория далеко отстоит от практики. Сложность при доступе к данным никого не интересует, важна скорость и ресурсы. И если на практике сложный алгоритм окажется быстрее, выберут его. Поэтому в реальной жизни и table full scan часто быстрее вообще любого индекса, и 90% таблиц в классической БД будут иметь "более медленный" b-tree индекс.
Конструкцию из петель для дверей мебели + электрический доводчик не рассматривали?
Там встречаются интересные механические решения, например, для накладных дверей для встроенной техники.
Есть куча психологических приемов, почему бы ими не пользоваться?
Есть из маленьких тарелок, не ходить в магазин голодным, пить стакан воды перед едой и т.д. , куча их.
По отдельности эти меры помогут слабо, а в комплексе могут принести видимые изменения. Большинство этих приемов особой силы воли не требуют.
Рассматривайте этот комментарий как "+" к оригинальному с аргументацией -)
Хорошие индусы есть и их много. Только они, как не странно, денег хотят, и работают чаще напрямую на клиентов. А индусов набирают чтобы сэкономить, особенно на галеры . Поэтому нанимают самое дно.
Фича конечно интересная, но неужели кто-то ей реально пользуется? Вместо того, чтобы разгребать этот trigger hell, не проще ли сделать пакет, какой-нибудь dml_orders, который будет единственным разрешенным интерфейсом для обновления данных в таблицах? Если планируются mass updates, то лучше предусмотреть отдельную функцию с каким нибудь ref cursor на входе, чем городить лапшу из триггеров.
А здесь не понял. Что мешает отбрасывать их на уровне запроса? Заодно и план запроса улучшится, возможно, получится задействовать индексы и т.д.
Для тех, кто удалил аккаунт с госуслуг: что может случится, если мошенники зарегистрируют новый аккаунт с украденными паспортными данными /СНИЛС?
1C или SAP или APEX - это low code или еще нет?
<sarcasm> потому что это перенос бизнес логики в базу, код ревью не пройдет </sarcasm>
Вообще жесть какая-то, что для простейшей в общем-то задачи надо разбираться в кишках hibernate.
Не смог найти там не агрегированных, исходных данных. А на графиках можно нарисовать что угодно.
Хм, посчитал приблизительно. Если к данным из википедии добавить данные о мини-гидтроэлектростанциях (около 4000 в австрии, по одной на каждых 2000 человек, около 40% от всей гидроэнергии ) то получается 75%. Как аналогия - по одной мини - гидроэлектростанции электростанции на среднюю московскую многоэтажку. Их реально много. Они реально их почти на каждом ручье строят.
https://www.wasserkraft-soelden.at/fileadmin/userdaten/bilder/kraftwerk_rettenbach/wasserkraft_soelden_kraftwerk_rettenbach_04.jpg
Электростанции на газе используются в основном в комбинации с центральным горячим водоснабжением в крупных городах, всего 17 на всю страну.