Попадался ноутбук Panasonic — необычайно лёгкий, вообще выглядящий как игрушечный, со слегка выпуклой верхней крышкой с косыми рёбрами жёсткости, благодаря которым тонкий пластик хорошо держал нажим, почти не прогибаясь.
Похоже, конструктор корпуса в детстве много экспериментировал с механическим воздействием на жуков.
Ребра жесткости и т.п. известны в строительстве и технике уже не одно столетие.
Так что к изготовителям этого ноутбука информация пришла уже в готовом виде из книг/лекций.
А какие-то древние техники и архитекторы наверняка учились у природы.
Сколько типов цен нужно завести и кто и в какой момент их будет менять?
Зачем тут вообще типы цен (которые в справочниках)?
Если тип склада розничный, то цена хранится в регистрах, как и остатки.
А запись в регистры вносится в момент проведения документа при оприходовании товара.
Причем чтобы не набивать вручную приходная накладная вводится на основании расходной накладной по которой отправляли товар из центрального офиса (с оптового склада) — в момент, когда товар физически добирается до магазина.
Эта приходная накладная пишет в регистры вместе с розничными ценами и остатки.
Как конкретно называются документы — зависит от того как вы ведете учет, например, с ордерами или нет.
Вот не верю ) У меня студенты перестали становиться программистами 1с. Программистом веба/мобилок в Омске быть выгоднее, перспективней (половина мигрирует в Москву/Питер/Европу) и проще (уровень входа в мобильную разработку сильно ниже, чем в какое-нибудь СКД).
Безотносительно того, верны ли ожидания студентов или ошибочны, но студенты это не тот источник истины, чтобы их мысли о потенциальных доходах были бы верным критериями…
что же до магазинов с очередями на кассах — таки там другие аппараты. не думаю, что пятёрочка, магнит и прочие не умеют считать деньги.
У этих федеральных сетей и так расходы миллиардные.
Плюс-минус подороже-подешевле фискальник федеральным сетям неважно.
А еще у них огромные скидки от объема покупаемого оборудования.
Это как ИТ маленькая компания ровняется на технологии Гугля…
Кое что применять еще можно.
Но какие-то вещи будут крайне не выгодны на мелких масштабах.
То есть по достижению момента записи (момента постановки в очередь за запись) происходит переключение одно-потока на следующую транзакцию?
При этом в целом сервер однопоточен?
ЕМНИП всё так потому, что меркурий в положении догоняющего. и оказался он в таком положении не просто так, а потому, что заработал себе репутацию «лучше доплатить, но взять штрих/феликс».
В какой нибудь Мск, возможно, это и так.
А у нас на периферии Штрихи были для многих неразумно дорогим решением.
Инсталляций Штрихов я видел чуть ли не в 20 раз меньше.
Не способен человек не работающий в индустрии создания продукта выдавать качественный, устойчивый, сопровождаемый код. Навскидку тонкие моменты: многоплатформенность, спектр поддерживаемого оборудования, наработка на отказ, версионность (апгрейд, даунгрейд на целевой машине), совместная разработка (передача своей задачи другому и перехват чужой задачи), ведение документации...
Чё-то вы преувеличивайте: уже как минимум отдельная профессия по апгрейду и даунгрейду на целевой машине (админы, DevOps).
Многоплатформенность за вас решает ваш универсальный инструмент, который написали совсем другие люди. Вряд ли вы под продукт пишете специальные модули совместимости под различные ОС.
Совместная разработка — это всего лишь несколько навыков как вести разработку в разных ветках и не ломать код коллег. За неделю разберетесь.
не специалист по бд, но разве синхронная репликация только в ОЗУ не надежнее отсутствия репликации вообще, но ожидания физической записи на диск?
В принципе без разницы откуда вы получили подтверждение что запись успешно завершена — от локального диска или от удаленного сервера.
Но речь то о другом — пока вы не получили подтверждения вы не можете быть уверенными что данные точно сохранены. И транзакция всё это время ждет в незавершенном состоянии. Что не вяжется с производительностью.
А в чем тут проблема? Однопоточно копим пачку, потом ее записываем.
А транзакция из потока при этому уже подтверждена или или еще не подтверждена?
Если речь о надежной записи, то клиент должен ждать пока сервер окончательно запишет на диск, вытолкнет все буфера и кэши и только после этого сервер сообщит клиенту об успешном завершении его транзакции.
То есть подтверждение идет пачкой — значит клиенты получают информацию о коммитах всех своих транзакций тоже пачкой.
В чем же тогда однопоточность? Что сама обработка данных идет в один поток? А параллельность во входящем сетевом соединении от клиентов всё же поддерживается Тарантулом?
Разработчики Tarantool в своё время как про преимущество свой разработки говорили про однопоточность. Что если, мол, нужно распараллеливать — то просто запускайте отдельные СУБД на каждом ядре. И шардингом распараллеливайте. Говорили, что причиной выбора однопоточности явилось упрощение обработки транзакций, что нет блокировок, все проходит быстро.
С другой стороны разработчики Тарантула как про преимущество своей разработки говорили про надежность хранения. В т.ч. и после сбоев.
С третьей стороны — про производительность высочайшую.
Эти вещи уже противоречат.
Не может быть одновременно и высочайшей производительности в однопоточном режиме с обязательной записью транзакций на диск чтобы подстраховаться от сбоев. Ниже подробнее напишу почему так.
Теперь добавляется синхронная репликация. Что тоже не увеличивает производительность. А где же истина?
Почему так как я говорю? Вот почему:
m.habr.com/ru/company/selectel/blog/521168
Если мы начинаем писать на диск маленькими порциями с обязательным проталкиванием данных из кэша, с ожиданием реального завершения операции записи — то при записывании транзакции по одном — получаем крайне низкую скорость записи. Чуть ли не в 1000 раз меньше, чем при записи большими порциями.
Записывать транзакции пачками мы не можем, так как обработка однопоточная. Блокировок и версионирования нет. Значит, отдельные записи на диск будут мааааленькими, размером в одну транзакцию, это считанные байты зачастую.
Не записывать на диск для завершения каждой транзакции мы не можем — так как иначе не получим гарантию надежного сохранения данных.
Асинхронная репликация тоже не давала таких гарантий.
Синхронная же репликация, как в случае с диском, даёт нам блокировку транзакции до тех пор, пока запись не окажется на другом сервере. Это плата за надежность.
Параллельное исполнение позволяет увеличить порции, которые передаются по сети и записываются на диск при завершении транзакции, что существенно увеличило бы скорость.
Я так подозреваю что вы хоть и выполняете транзакции в 1 поток, но при записи блокируете их пачками, в ожидании завершения записи? Разумеется в предположении, что включена синхронная запись на диск и синхронная репликация.
А вот вероятность, что C++03 перестанут использовать (или будут использовать в следовых количествах, примерно на одном уровне с коболом) до ухода на пенсию — уже вполне себе ощутима.
Не страшно.
1) Это не произойдет мгновенно. Даже инерция одного человека велика, а уж инерция групп людей — страшная сила. Изменения будут подавать тебе звоночки долгими годами.
Ты успеешь отреагировать.
2) Перейти на более свежий стандарт не так уж сложно, даже будучи в возрасте и обладая уже не таким гибким мозгом как в юности. Это же не полностью новый язык.
Тогда уточню. Когда я говорил о бизнесе, я имел ввиду тот, который зарабатывает деньги благодаря своему айти продукту. Какой-нибудь ресторан, которому из айтишного нужен лишь лендинг и автоматизация бухгалтерии — это немного не про то.
Ну дык вторых-то бизнесов как раз подавляющее большинство.
Мы же в реальном мире живем, нам нужно есть, жить в тепле, мыться, одеваться…
А первые, чисто ИТ-продуктовые фирмы как раз и могут себе позволить эксплуатацию новых технологий, ибо персонала квалифицированного в ИТ у них много.
Но этих подавляющее меньшинство.
И ИТ-шников в свою очередь там тоже работает мало.
Директор грузоперевозок не будет закупать грузовики, запчасти к которым больше не производятся
Данная аналогия не верна.
Все сложнее.
Подобные грузовики могут продаваться с большой скидкой. И если они окупят себя раньше, чем выйдут из строя, то покупка может быть выгодной.
Так что может и выберет.
А многие запчасти можно сделать кустарным образом на токарном станке. К старым моделям — тем более. Это даже штатно практиковалась. Тенденция менять агрегаты целиком, а не разбирать-ремонтировать-собирать — это новая тенденция. Старые модели как раз более ремонтнопригодны.
Плюс у коммерческих автомобилей огромная совместимость — отдельные запчасти и по 40 лет в разных моделях применяются без изменений…
Да и ресурс там повыше чем у обычных легковых автомобилей.
У вашей аналогии есть и второе несоответствие:
Язык программирования — это не автомобильные запчасти, каждый экземпляр которой нужно сделать физически.
Если язык существует — он уже никуда не исчезнет, если у вас есть исходники.
В третьих:
Новые-модные технологии не все взлетают высоко и надолго. Вспомните CoffeeScript или Ruby. Вспомните первые версии Angular, Vue, React… Где это всё? И сколько нужно усилий, чтобы адаптировать старый код — в таких случаях просто оставляют работать уже написанный код на старых отживших свое версиях. Но если продукт эксплуатируются, то он нуждается в поддержке…
В четвертых:
Мы живем в реальном мире где нет бесконечного числа программистов любой специализации.
И приходится брать тех, кто есть.
В общем, далеко не всегда руководитель ИТ-фирмы выберет самую новую и самую модную технологию. А скорее всего он возьмет что-то уже достаточно развитое находящееся в середине своего жизненного цикла. Когда полно уже и библиотек на все случаи жизни и прочих инструментов достаточно.
И через несколько лет эта технология вступит в стадию умирания. В современном ИТ это не исключительная ситуация.
Однако так как на этой технологии уже создано множество продуктов, то есть и специалистов довольно много и community, и умирать технология будет десятки лет — посмотрите хоть на Delphi, посмотрите на PHP4. На них есть проекты. И новые в том числе.
Да, об них не пишут статьи «как я запилил крестики нолики на новомодном языке программирования».
Но, судя по тому, как продолжают развиваться средства разработки того же Delphi (например, IDE Lazarus), тот, кто умер еще в начале века на самом деле еще жив. А сейчас, напоминаю, 2020 год.
P.S.:
А уже система создается на базе модных на сегодня микросервисов, то ничто вам не мешает запилить отдельные сервисы на других языках программирования и менять сервисы поочередно не спеша на новые их версии, переписанные на более современных инструментах. Если это вообще будет нужно сделать, а то и вовсе «работает не трогай».
Чтобы преподать заказчику наглядный урок при первой же потребности в переделке?
А если он сильно обидится? )
Ну почему.
Если вы единственный в жизни заказчика программист — огорчится.
А вот если ему есть с кем сравнить — поймет, что есть люди и поразумнее организующие разработку. И будет чесать репу с кем работать в будущем. Подороже, но без геморроя; или подешевле, но вот с такими непредсказуемыми (с точки зрения заказчика это было сюрпризом, неожиданностью) вещами.
Это человеческая психология.
Мы существа социальные, живущие в ранговой системе, и желание самоутвердиться в доминировании в нас неисправимо.
И зачастую это желание выпирает настолько явно, как в вашей ситуации у вас тестирующих людей.
Объективно они не настолько выше вас профессиональным классом, насколько они вам это показали.
Понятно, что это не приятно.
Понятно, что следует проявлять уважение к коллегам и так не делать.
Понятно, что эта ситуация не связана никак с конечной целью собеседования.
Тем не менее примите как данность — оно встречается.
Но при этом ничего не говорит ни о фирме.
Ни о потенциальных коллегах.
Будучи принятыми в коллектив и уже будучи с ними в равном положении вы могли узнать насколько они приятные люди.
Для бизнеса все эти «правильные микросервисы с репликациями» только непонятные слова и удорожание бюджета разработки.
Для бизнеса важен результат, в том виде в котором его соизволят приготовить ИТшники. Ибо, учитывая цену ИТшников — бизнес позволяет делать на тех технологиях, что удобнее ИТшникам сами, лишь бы это было дешевле.
Ну ОК, иногда есть жирные бюджеты и экономить не нужно. Тогда разработчики могут развернуться в своих экспериментах. Вон куча навороченного качественного открытого ПО, созданного на коммерческие деньги изначально для использования внутри фирм — тому типичный пример хороших бюджетов.
Еще есть хайпы. Иногда бизнес делает заказ на разработку по хайповой технологии.
У меня вон заказчик крупный долго хотел мобильное приложение.
Не состоялось его разработка пару лет по разным причинам.
Он подумал. Было время.
И до него дошло что ему не нужно мобильное приложение.
Для бизнеса гораздо проще идти в ногу со временем — потому что иначе заколебется потом искать людей, согласных на этом вашем php4 писать — за рыночную ставку какой дурак согласится на это, придется доплачивать за вредность.
Эти вещи знает не любой бизнес, а какой нибудь технический директор, к тому же достаточно высокой квалификации, что встречается не так и часто.
В остальном выбор бизнеса технологии вовсе не настолько осознанный, как вы пишете.
Ну а выбор ИТшников бывает разным.
Могу признаться, что и я за деньги клиентов просто изучал новые вещи и ставил интересные мне эксперименты, при том, что точно знал, что задачу можно решить быстрее и дешевле.
А кто-то из ИТшников принимающих решения о выборе технологий, напротив, предпочитает максимально проверенные вещи и не любит новинки. Знаю я такого технического директора лично. Но ничё, продукт разработанный его командой с нуля (а значит можно было выбрать любую технологию), вполне себе поддерживает миллиард рублей оборота бизнеса в месяц.
Если у вас система работает в режиме, когда и остатки и цены фиксируются в регистре, то да.
То есть совсем другие люди и совсем другой взгляд?
А как быть с зависимыми данными?
Если транзакция №2 использует то, что навычисляла транзакция №1, а транзакция №1 откатывается?
В этой статье обещают Serializable…
сие есть модный дизайн.
Ребра жесткости и т.п. известны в строительстве и технике уже не одно столетие.
Так что к изготовителям этого ноутбука информация пришла уже в готовом виде из книг/лекций.
А какие-то древние техники и архитекторы наверняка учились у природы.
Зачем тут вообще типы цен (которые в справочниках)?
Если тип склада розничный, то цена хранится в регистрах, как и остатки.
А запись в регистры вносится в момент проведения документа при оприходовании товара.
Причем чтобы не набивать вручную приходная накладная вводится на основании расходной накладной по которой отправляли товар из центрального офиса (с оптового склада) — в момент, когда товар физически добирается до магазина.
Эта приходная накладная пишет в регистры вместе с розничными ценами и остатки.
Как конкретно называются документы — зависит от того как вы ведете учет, например, с ордерами или нет.
Безотносительно того, верны ли ожидания студентов или ошибочны, но студенты это не тот источник истины, чтобы их мысли о потенциальных доходах были бы верным критериями…
У этих федеральных сетей и так расходы миллиардные.
Плюс-минус подороже-подешевле фискальник федеральным сетям неважно.
А еще у них огромные скидки от объема покупаемого оборудования.
Это как ИТ маленькая компания ровняется на технологии Гугля…
Кое что применять еще можно.
Но какие-то вещи будут крайне не выгодны на мелких масштабах.
Мы говорим о вполне конкретном Тарантуле.
Как там на входе происходит?
Транзакция №1 начата, данные изменены, ожидает записи.
Транзакция №2 начата, данные изменены, ожидает записи.
Транзакция №3 начата, данные изменены, ожидает записи.
Последовательность гарантирована?
Затем пачкой записываем 3 штуки.
Ожидаем записи.
Подтверждаем клиенту транзакцию №1
Подтверждаем клиенту транзакцию №2
Подтверждаем клиенту транзакцию №3
Так?
То есть по достижению момента записи (момента постановки в очередь за запись) происходит переключение одно-потока на следующую транзакцию?
При этом в целом сервер однопоточен?
В какой нибудь Мск, возможно, это и так.
А у нас на периферии Штрихи были для многих неразумно дорогим решением.
Инсталляций Штрихов я видел чуть ли не в 20 раз меньше.
Чё-то вы преувеличивайте: уже как минимум отдельная профессия по апгрейду и даунгрейду на целевой машине (админы, DevOps).
Многоплатформенность за вас решает ваш универсальный инструмент, который написали совсем другие люди. Вряд ли вы под продукт пишете специальные модули совместимости под различные ОС.
Совместная разработка — это всего лишь несколько навыков как вести разработку в разных ветках и не ломать код коллег. За неделю разберетесь.
В принципе без разницы откуда вы получили подтверждение что запись успешно завершена — от локального диска или от удаленного сервера.
Но речь то о другом — пока вы не получили подтверждения вы не можете быть уверенными что данные точно сохранены. И транзакция всё это время ждет в незавершенном состоянии. Что не вяжется с производительностью.
А транзакция из потока при этому уже подтверждена или или еще не подтверждена?
Если речь о надежной записи, то клиент должен ждать пока сервер окончательно запишет на диск, вытолкнет все буфера и кэши и только после этого сервер сообщит клиенту об успешном завершении его транзакции.
То есть подтверждение идет пачкой — значит клиенты получают информацию о коммитах всех своих транзакций тоже пачкой.
В чем же тогда однопоточность? Что сама обработка данных идет в один поток? А параллельность во входящем сетевом соединении от клиентов всё же поддерживается Тарантулом?
Разработчики Tarantool в своё время как про преимущество свой разработки говорили про однопоточность. Что если, мол, нужно распараллеливать — то просто запускайте отдельные СУБД на каждом ядре. И шардингом распараллеливайте. Говорили, что причиной выбора однопоточности явилось упрощение обработки транзакций, что нет блокировок, все проходит быстро.
С другой стороны разработчики Тарантула как про преимущество своей разработки говорили про надежность хранения. В т.ч. и после сбоев.
С третьей стороны — про производительность высочайшую.
Эти вещи уже противоречат.
Не может быть одновременно и высочайшей производительности в однопоточном режиме с обязательной записью транзакций на диск чтобы подстраховаться от сбоев. Ниже подробнее напишу почему так.
Теперь добавляется синхронная репликация. Что тоже не увеличивает производительность. А где же истина?
Почему так как я говорю? Вот почему:
m.habr.com/ru/company/selectel/blog/521168
Если мы начинаем писать на диск маленькими порциями с обязательным проталкиванием данных из кэша, с ожиданием реального завершения операции записи — то при записывании транзакции по одном — получаем крайне низкую скорость записи. Чуть ли не в 1000 раз меньше, чем при записи большими порциями.
Записывать транзакции пачками мы не можем, так как обработка однопоточная. Блокировок и версионирования нет. Значит, отдельные записи на диск будут мааааленькими, размером в одну транзакцию, это считанные байты зачастую.
Не записывать на диск для завершения каждой транзакции мы не можем — так как иначе не получим гарантию надежного сохранения данных.
Асинхронная репликация тоже не давала таких гарантий.
Синхронная же репликация, как в случае с диском, даёт нам блокировку транзакции до тех пор, пока запись не окажется на другом сервере. Это плата за надежность.
Параллельное исполнение позволяет увеличить порции, которые передаются по сети и записываются на диск при завершении транзакции, что существенно увеличило бы скорость.
Я так подозреваю что вы хоть и выполняете транзакции в 1 поток, но при записи блокируете их пачками, в ожидании завершения записи? Разумеется в предположении, что включена синхронная запись на диск и синхронная репликация.
И сколько между ними лет? Лет со звоночками «обрати внимание, разберись»?
Не страшно.
1) Это не произойдет мгновенно. Даже инерция одного человека велика, а уж инерция групп людей — страшная сила. Изменения будут подавать тебе звоночки долгими годами.
Ты успеешь отреагировать.
2) Перейти на более свежий стандарт не так уж сложно, даже будучи в возрасте и обладая уже не таким гибким мозгом как в юности. Это же не полностью новый язык.
Ну дык вторых-то бизнесов как раз подавляющее большинство.
Мы же в реальном мире живем, нам нужно есть, жить в тепле, мыться, одеваться…
А первые, чисто ИТ-продуктовые фирмы как раз и могут себе позволить эксплуатацию новых технологий, ибо персонала квалифицированного в ИТ у них много.
Но этих подавляющее меньшинство.
И ИТ-шников в свою очередь там тоже работает мало.
Данная аналогия не верна.
Все сложнее.
Подобные грузовики могут продаваться с большой скидкой. И если они окупят себя раньше, чем выйдут из строя, то покупка может быть выгодной.
Так что может и выберет.
А многие запчасти можно сделать кустарным образом на токарном станке. К старым моделям — тем более. Это даже штатно практиковалась. Тенденция менять агрегаты целиком, а не разбирать-ремонтировать-собирать — это новая тенденция. Старые модели как раз более ремонтнопригодны.
Плюс у коммерческих автомобилей огромная совместимость — отдельные запчасти и по 40 лет в разных моделях применяются без изменений…
Да и ресурс там повыше чем у обычных легковых автомобилей.
У вашей аналогии есть и второе несоответствие:
Язык программирования — это не автомобильные запчасти, каждый экземпляр которой нужно сделать физически.
Если язык существует — он уже никуда не исчезнет, если у вас есть исходники.
В третьих:
Новые-модные технологии не все взлетают высоко и надолго. Вспомните CoffeeScript или Ruby. Вспомните первые версии Angular, Vue, React… Где это всё? И сколько нужно усилий, чтобы адаптировать старый код — в таких случаях просто оставляют работать уже написанный код на старых отживших свое версиях. Но если продукт эксплуатируются, то он нуждается в поддержке…
В четвертых:
Мы живем в реальном мире где нет бесконечного числа программистов любой специализации.
И приходится брать тех, кто есть.
В общем, далеко не всегда руководитель ИТ-фирмы выберет самую новую и самую модную технологию. А скорее всего он возьмет что-то уже достаточно развитое находящееся в середине своего жизненного цикла. Когда полно уже и библиотек на все случаи жизни и прочих инструментов достаточно.
И через несколько лет эта технология вступит в стадию умирания. В современном ИТ это не исключительная ситуация.
Однако так как на этой технологии уже создано множество продуктов, то есть и специалистов довольно много и community, и умирать технология будет десятки лет — посмотрите хоть на Delphi, посмотрите на PHP4. На них есть проекты. И новые в том числе.
Да, об них не пишут статьи «как я запилил крестики нолики на новомодном языке программирования».
Но, судя по тому, как продолжают развиваться средства разработки того же Delphi (например, IDE Lazarus), тот, кто умер еще в начале века на самом деле еще жив. А сейчас, напоминаю, 2020 год.
P.S.:
А уже система создается на базе модных на сегодня микросервисов, то ничто вам не мешает запилить отдельные сервисы на других языках программирования и менять сервисы поочередно не спеша на новые их версии, переписанные на более современных инструментах. Если это вообще будет нужно сделать, а то и вовсе «работает не трогай».
Ну почему.
Если вы единственный в жизни заказчика программист — огорчится.
А вот если ему есть с кем сравнить — поймет, что есть люди и поразумнее организующие разработку. И будет чесать репу с кем работать в будущем. Подороже, но без геморроя; или подешевле, но вот с такими непредсказуемыми (с точки зрения заказчика это было сюрпризом, неожиданностью) вещами.
Это человеческая психология.
Мы существа социальные, живущие в ранговой системе, и желание самоутвердиться в доминировании в нас неисправимо.
И зачастую это желание выпирает настолько явно, как в вашей ситуации у вас тестирующих людей.
Объективно они не настолько выше вас профессиональным классом, насколько они вам это показали.
Понятно, что это не приятно.
Понятно, что следует проявлять уважение к коллегам и так не делать.
Понятно, что эта ситуация не связана никак с конечной целью собеседования.
Тем не менее примите как данность — оно встречается.
Но при этом ничего не говорит ни о фирме.
Ни о потенциальных коллегах.
Будучи принятыми в коллектив и уже будучи с ними в равном положении вы могли узнать насколько они приятные люди.
Причины этого явления хорошо были показаны, например, в тюремном эксперименте в Стенфорде:
Если людям предоставить ненаказуемую возможность поиздеваться, то окажется, что большая часть из нас — сущее говно.
И только в ситуациях, когда можно, хотя бы теоретически, получить ответную защитную реакцию угнетаемых — тогда нападок на вас не будет.
В обычных ситуациях — мы примерно равны по возможности дать отпор, поэтому в обычной жизни такой неприятной ситуации вам не встречалось.
Технологию выбирают прежде всего ИТшники.
Для бизнеса все эти «правильные микросервисы с репликациями» только непонятные слова и удорожание бюджета разработки.
Для бизнеса важен результат, в том виде в котором его соизволят приготовить ИТшники. Ибо, учитывая цену ИТшников — бизнес позволяет делать на тех технологиях, что удобнее ИТшникам сами, лишь бы это было дешевле.
Ну ОК, иногда есть жирные бюджеты и экономить не нужно. Тогда разработчики могут развернуться в своих экспериментах. Вон куча навороченного качественного открытого ПО, созданного на коммерческие деньги изначально для использования внутри фирм — тому типичный пример хороших бюджетов.
Еще есть хайпы. Иногда бизнес делает заказ на разработку по хайповой технологии.
У меня вон заказчик крупный долго хотел мобильное приложение.
Не состоялось его разработка пару лет по разным причинам.
Он подумал. Было время.
И до него дошло что ему не нужно мобильное приложение.
Эти вещи знает не любой бизнес, а какой нибудь технический директор, к тому же достаточно высокой квалификации, что встречается не так и часто.
В остальном выбор бизнеса технологии вовсе не настолько осознанный, как вы пишете.
Ну а выбор ИТшников бывает разным.
Могу признаться, что и я за деньги клиентов просто изучал новые вещи и ставил интересные мне эксперименты, при том, что точно знал, что задачу можно решить быстрее и дешевле.
А кто-то из ИТшников принимающих решения о выборе технологий, напротив, предпочитает максимально проверенные вещи и не любит новинки. Знаю я такого технического директора лично. Но ничё, продукт разработанный его командой с нуля (а значит можно было выбрать любую технологию), вполне себе поддерживает миллиард рублей оборота бизнеса в месяц.