А в чём концептуальная проблема двунаправленной репликации? Помнится, в начале 2000-х писал систему, в качестве СУБД использовался Sybase SQL Anywhere. Четыре узла, все работают как мастера, репликация раз в 10 минут - никаких проблем за почти 10 лет работы системы. Единственное что, пришлось реализовать функции создания гарантированно уникальных первичных ключей (обычные последовательности по понятным причинам использовать нельзя было). Это было 20 лет назад
В октябре взял 3к в ЖК Поэт, чуть меньше 12 млн, 82 с копейками метра. Сознательно выбирал там - человейники типа Мурино и Парнаса не интересовали совсем, вторичка тоже не впечатлила (хотя были варианты 3к и по 9-9,5). А у нас вокруг 9-этажки (их сносить рано ещё), да школы с садиками. Опять же, до парка Сосновка 15 минут. Да, до метро 27 минут прогулочным шагом, но мы с сыном оба ИТ, оба на удалёнке - т.е., туда редко будем ходить. Даже сейчас, когда дом сдан, там стоимость 188 за метр.
Узлы (магазины) там могли изменять ВСЕ данные. Другое дело, что бизнес-кейс был такой, что репликации раз в 5-10 минут хватало на то, чтобы конфликтов репликации за всё время работы системы было меньше десятка.
Речь именно об асинхронной репликации. И именно в случае, когда нельзя допустить простоев узла при невозможности репликации из-за отсутствия связи.
В том решении на SQL Anywhere как раз было 4 территориально разнесённых розничных магазина одной компании. Естественно, они продолжали работать даже если вообще остановить репликацию. Использовался обмен файлами репликации, создаваемыми утилитой sql remote, за всё время работы (а работала система лет 5-7, точно не помню), был один (!) случай, когда что-то пошло не так и пришлось восстанавливать состояние репликации в узлах. Данные при этом потеряны не были.
Но, повторюсь, там изначально при создании системы схема БД создавалась с учётом данной специфики.
P.S. Да и сейчас для системы, которую собираемся делать, это одно из основных требований — её узлы должны оставаться работоспособными даже при отсутсвии связи между ними.
Рассматриваем сейчас Postgres как вариант для реализации одной системы. А не может ли кто-нибудь разъяснить, какие такие фундаментальные проблемы есть с этим у него?
Помнится, в начале 2000-х реализовывал одну систему на Sybase SQL Anywhere — так там у меня 4 узла реплицировались раз в 5-10 минут (двусторонняя репликация, индивидуальные настройки узлов) ПО МОДЕМАМ. И всё работало. Единственное, что пришлось предусмотреть в схеме БД — генерация первичных ключей с гарантией уникальности. А тут прошло почти 20 лет — и какие-то фундаментальные проблемы???
А что с авто не так? Сейчас при выборе авто самое главное это компромисс между «цена 1 км пути» и «безопасность». хотя для кого-то будут и др потребности «экологичность» если живешь в европе, или «частота поломок» если живешь в дали от сто или ритм жизни требует «чтобы не ломалось».
Взять тот же ford focus (у кого-то получилось что 1 км пути 3,3руб — это же дешево, навряд ли можно найти машину у которой 1 км пути будет дешевле и остальные параметры будут +- такими же) Тыц
Для меня главное надёжность авто (про безопасность даже не говорю — у меня два дня рождения и второй — благодаря машине, которая пошла в утиль после аварии, а у меня только одна царапина). Естественно, «функционал» (в смысле соответствия задачам) тоже важен (свой предыдущий экспедиционник сменил на немца именно после того, как задачи изменились).
Все свои машины содержал в таком техническом состоянии, чтобы я мог выйти из дома и поехать на 4000 — 5000 км. И чтобы нужно было только заехать на заправку.
А было время, когда я ездил в экспедиции в места, где цивилизации нет от слова «совсем». Полный привод, подготовленная машина и всё такое. Может, оттуда и пошла эта маниакальная тяга к надёжности.
А вот стоимость 1км пути меня никогда не интересовала. В жизни есть другие приоритеты и ценности.
Попробуйте Miele. И, может быть, Mercedes — но только не копромодели, а что-нибудь в районе E klasse и выше.
Да мне не нужно рассказывать про Мерсы. Особенно, про современные и их сравнение со 124-м, например. Я, кстати, езжу на дойчеавто, но 2015 года и с меганадёжным 3,6 (а не современным «пакетом сока» 2л).
Я не предлагаю выбирать дорогое, я говорю, что если хотите качественное, то должны платить больше…
Да большинство программных продуктов которые приносят прибыль — это круды и формочки.
Да ладно!.. :) Вот бизнес-то идиоты. Платят за формочки, а не за хранение и обработку(!) данных. Кстати, под обработкой понимается ОЧЕНЬ широкий спектр задач/операций (ну так, на всякий случай...)
Код должен быть понятный, даже если он хуже по производительности, потому что производство кода — это бизнесс. Вкладывать деньги в больше быстрого железа выгоднее и более предсказуемо, чем тратить их на поддержку непонятного, но очень быстрого кода.
Мы смотрим с какой точки зрения? Если бизнеса (заказчика) — то ему по барабану, как написан код (в смысле, понятно или непонятно). Ему главное, чтобы система работала в заданных рамках (производительности, надёжности и функциональности).
То, о чём Вы говорите имеет смысл или с точки зрения того менеджера, кому придётся сопровождать это всё, или с точки зрения менеджмента компании, если систему разрабатывало одно из подразделений компании и в разрезе исключительно TCO. Для стороннего заказчика как раз в первую очередь важна функциональность, стабильность и производительность.
Закрыли для себя Java — поздравляю! На нем писан не один движок сверхбыстрой алгоритмической торговли на биржах (угадайте откуда я это знаю?). Бизнесс доверяет большие бабки джаве и ее производительности…
Вы или передёргиваете, или невнимательны. Я ТОГДА закрыл для себя вопрос Java. Сейчас появились другие задачи (конкретно — «кровавый энтерпрайз» на web), поэтому пришлось вернуться к Java.
И да, про «сверхбыструю алгоритмическую торговлю» понравилось. А позвольте поинтересоваться — а с чем сравнивали?
Ну и так далее — динозавры пытаются сохранить свой статус кво непосредственно перед вымиранием. Ничего личного, но вы отрицаете, что система как она есть (на Java, Kotlin, С#, F#) как-то работает и ниша применения оооочень быстрых языков сокращается постоянно вместе и с потребностью в специалистах соответствующего класса. Ну и как-то работает система — пишу вам с телефона, сейчас бы вспомнить в какой заднице находится Nokia c ее С++ и Qt…
1. Вы сами это написали: «система КАК-ТО работает». Проблема именно в этом: а могла бы работать гораздо лучше (предположу, что в разы), если бы всё, что не «круды и формочки» делали не «кодируюшие макаки».
2. Видимо, Вы всё-таки не поняли: я не о том, что всё нужно писать на С++ или ассемблере. Даже на Java, C# и т.п. можно писать вдумчиво, а можно как «кодирующая макака».
Да, кстати, видимо, в вашем понимании я (и такие как я) как раз и те самые «динозавры». Возможно, это и так (в смысле, что нормальные спецы вымирают). Только вот думаю, что код написанные такими динозаврами будет лучше большинства «млекопитающих» (это по аналогии, что на смену динозаврам пришли именно они) и работать будет дольше.
Я с этим не согласен. Есть большой рынок качественных товаров. Все что угодно можно купить качественное и долговечное. Просто копропотребители всегда выбирают цену и получают соотвествующее качество — это проблемы исключительно копропотребителей.
А я с этим не согласен. КОЕ-ЧТО ещё можно купить качественное, но в основном — всё одноразовое. Бытовая техника, авто, электроника и т.д.
И, главное, цена ДАЛЕКО не всегда коррелирует с качеством.
И, кстати, не приведёте пример качественных и «долговечных» программных продуктов? На рынке (в отрасли), где была бы конкуренция и потребитель мог бы выбрать между несколькими поставщиками, заплатил бы побольше и остался доволен?
Даже если ваш посыл про копроэкономику верен, то не понятно, что предлагается — спасти весь мир и всю экономическую систему высококачественными крудами и формочками с идеальными рамочками написанными на монадах?
Огромное количество активностей в программировании сейчас невероятно простые и требуют только внимательности у усидчивости. Не вижу смысле на такие активности нанимать людей с PhD…
А при чём здесь «высококачественные круды и формочки с идеальными рамочками на монадах»? Напомню, что было написано в сообщении, которое я комментировал:
Есть мнение, что не надо «выжигать себе глаза», чтобы программировать на там уровне, на котором сейчас пишется большинство продуктов.
По вашему мнению, БОЛЬШИНСТВО продуктов — это круды и формочки?
И ещё из исходного сообщения:
В целом весь этот вой против вайтишников считаю попыткой засидевшихся и подзаржавевших (не в смысле Rust, а в другом — в плохом) сторожил защитить свой статус-кво. Боятся, что их смоет волной дешевых, молодых, амбициозных, не нюхавших матфизики кодирующих макак.
Вот как раз формочки и простейшие круды «кодирующие макаки» как раз писать могут. Проблема в том, что, как я говорил, современные системы — это не только эти простейшие операции. А вот тенденция ВСЕ компоненты систем реализовывать руками и «мозгами» «кодирущих макак» как-то настораживает.
Я в беседах с молодыми разработчиками часто привожу один пример: работал в 80-90-х на системах СМ-4 (RAM 256Kb), потом на СМ-1420 (RAM 2Mb), операционка RSX-11M. Максимальный размер программы — 64Кб.
Чисто информационная система (но достаточно критичная, городская справка), СУБД Adabas-M (да, вся СУБД меньше 64Кб), ужасная дисковая подсистема (пакеты на 20 Мб), пользователей (терминалов) чуть больше 20(!), из них очень активных (операторов) 16-18. В ЧНН (час наибольшей нагрузки) у оператора на то, чтобы принять звонок, выслушать абонента, понять, что ему нужно, набрать запрос, получить ответ, огласить его абоненту и нажать кнопку отбоя звонка уходило 22 секунды. Сам поиск информации в БД занимал меньше секунды (в редких случаях — меньше 2-х).
Когда во второй половине 90-х возникла потребность заменить данную систему, новая реализация была сделана на QNX4, в качестве СУБД — Watcom SQL. Скорость работы по сравнению с современниками на Linux, Windows, DOS впечатляла. Но вот пользователи жаловались, что скорость работы (т.е., поиска в БД) была существенно меньше, чем на СМ-ке.
При этом, работало это то ли на 386-х, то ли на 486- компах. Сравнивать их вычислительную мощность с СМ-кой даже смешно.
Так вот, моё глубокое убеждение, что разница в бОльшей степени обусловлена тем, что тот код (и ОС, и СУБД, и самой прикладной системы) писали совсем не макаки (скорее всего, ещё и на ассемблере). Плюс, не было такого нагромождения новомодных стеков и фреймворков.
А сейчас у меня ноут, с которого пишу, имеет памяти в 8192 раза больше (во сколько раз i7 превосходит ЦПУ СМ-ки — даже думать не хочется). Стало всё работать ли лучше/быстрее хотя бы раза в 2 — НЕТ.
Плюс, повсеместная тенденция, что код д.б. В ПЕРВУЮ ОЧЕРЕДЬ, читаемым (sic!). Помню, в начале 2000-х (вроде) решил познакомиться с Java, по старой привычке после беглого просмотра синтаксиса языка, стал смотреть исходники библиотек. Помню, смотрел реализацию какой-то коллекции. Так там для того, чтобы «красиво обойти» её, вводились фиктивный первый элемент (перед головой) и последний (после хвоста). Т.е., создание двух элементов (выделение памяти, инициализация и т.п.) — и всё ради того, чтобы написать просто цикл for, без проверки условий перед циклом. Нашёл ещё какой-то подобный прикол — и закрыл для себя Java (на достаточно длительное время).
Просто мы тогда как раз писали систему, где если информация не доставлена за заданное время — то это считалось отказом. Поэтому было странно такое видеть.
А такой вот подход (читаемость в ущёрб скорости) — это, к сожалению, мэйнстрим сейчас.
Если окажется, что это не работает, то компании вовремя повернут и заменят их и «настоящими» разрабами и мы вернемся к старым добрым временам. Ну или обанкротятся — не вижу смысла их принудительно спасать от этого. Нет причин для беспокойств.
Если окажется, что такая тактика работает, то и отлично — компании оптимизировали затраты на з.п. сотруднику со сверхквалификацией которая (как окажется) не нужна для выполнения требуемой работы. Сотрудники, в свою очередь, оптимизировали свои затраты времени и сил на обучение необходимое для получения работы. Везде сплошная оптимизация. В итоге потребитель получит продукт дешевле. Бизнес, производство материальных благ, ничего личного.
К сожалению, это больше не работает. Есть в сети такой короткий рассказ — «Копроэкономика» (почитайте. Ну, или, освежите в памяти).
По большому счёту, никто в бизнесе (начиная с грандов, а на них и помельче ориентируются) не заинтересован в выпуске на рынок качественного продукта. «Х… к, х… к — и в продакшн» (с)
В целом весь этот вой против вайтишников считаю попыткой засидевшихся и подзаржавевших (не в смысле Rust, а в другом — в плохом) сторожил защитить свой статус-кво. Боятся, что их смоет волной дешевых, молодых, амбициозных, не нюхавших матфизики кодирующих макак. Если это окажется возможным — что же, такова жизнь. Мы же не хотим нарушать работу рынка. Если это невозможно — то волноваться нечего — ничто старожилам не угрожает, их цена даже подрастет на фоне неумелых конкурентов. Тот факт, что старожилы крепко волнуются говорит мне о том, что они и сами знают о том, что чтобы писать круды, не нужно «сидеть днями и ночами».
Тут даже не знаю, что сказать. Если «старожил» за все эти годы научился максимум что «круды» писать — то туда ему и дорога (в смысле, «на свалку истории»).
У меня жизнь сложилась так, что пришлось поучаствовать в реализации проектов абсолютно разной тематики — был и свой мультивалютный опердень банка (середина 90-х), и серьёзная информационная система предприятия, и интересная с технической точки зрения «шабашка» (начало 2000-х, торговая система одной фирмы — 4 магазина с реляционной базой, реплицируемой практически в онлайне по модемным(!) каналам. да, репликация «мастер-мастер» 4х4, пользуясь случаем, передаю привет СОВРЕМЕННОЙ репликации PostgreSQL) и самый серьёзный проект — одна из подсистем на ЖД, непосредственно завязанная на управление движением. Кстати, недавно с удивлением узнал, что она до сих пор работает. На минутку: мы перестали её сопровождать в середине 2000-х годов. Обслуживающий персонал только выходящее из строя железо меняет и заливает нашу прошивку. А там «практически» жёсткий рантайм — оцените уровень надёжности.
А по поводу темы топика — у меня сейчас сын в универ поступил. Честно говоря, я ожидал худшего. Конечно, с нашим уровнем образования не сравнится, но некоторые ПРОФИЛЬНЫЕ предметы преподаются — моё почтение. Я «мониторю» его задания и как с него спрашивают. Сравнивать его знание, например, С++ с выпускником подобных курсов — это как сравнить кремниевое ружьё с АК-47.
Дискламер: 16 лет опыта разрабом, кодирую и сейчас, имею топовое российское образование по computer science.
Алаверды: овер 30 лет разработки (IBM 360, PDP 11/40-70, IBM RISC, теперь x86), одно из лучших образований в СССР и постоянное самообразование все эти годы. И да, до сих пор «играющий тренер».
А в чём концептуальная проблема двунаправленной репликации? Помнится, в начале 2000-х писал систему, в качестве СУБД использовался Sybase SQL Anywhere. Четыре узла, все работают как мастера, репликация раз в 10 минут - никаких проблем за почти 10 лет работы системы. Единственное что, пришлось реализовать функции создания гарантированно уникальных первичных ключей (обычные последовательности по понятным причинам использовать нельзя было). Это было 20 лет назад
А что с ними не так? Есть претензии к ним в части качества строительства ? Или Вы про их "репутацию", подпорченную, в частности , Лондон Парком?
В октябре взял 3к в ЖК Поэт, чуть меньше 12 млн, 82 с копейками метра. Сознательно выбирал там - человейники типа Мурино и Парнаса не интересовали совсем, вторичка тоже не впечатлила (хотя были варианты 3к и по 9-9,5). А у нас вокруг 9-этажки (их сносить рано ещё), да школы с садиками. Опять же, до парка Сосновка 15 минут. Да, до метро 27 минут прогулочным шагом, но мы с сыном оба ИТ, оба на удалёнке - т.е., туда редко будем ходить. Даже сейчас, когда дом сдан, там стоимость 188 за метр.
В том решении на SQL Anywhere как раз было 4 территориально разнесённых розничных магазина одной компании. Естественно, они продолжали работать даже если вообще остановить репликацию. Использовался обмен файлами репликации, создаваемыми утилитой sql remote, за всё время работы (а работала система лет 5-7, точно не помню), был один (!) случай, когда что-то пошло не так и пришлось восстанавливать состояние репликации в узлах. Данные при этом потеряны не были.
Но, повторюсь, там изначально при создании системы схема БД создавалась с учётом данной специфики.
P.S. Да и сейчас для системы, которую собираемся делать, это одно из основных требований — её узлы должны оставаться работоспособными даже при отсутсвии связи между ними.
Рассматриваем сейчас Postgres как вариант для реализации одной системы. А не может ли кто-нибудь разъяснить, какие такие фундаментальные проблемы есть с этим у него?
Помнится, в начале 2000-х реализовывал одну систему на Sybase SQL Anywhere — так там у меня 4 узла реплицировались раз в 5-10 минут (двусторонняя репликация, индивидуальные настройки узлов) ПО МОДЕМАМ. И всё работало. Единственное, что пришлось предусмотреть в схеме БД — генерация первичных ключей с гарантией уникальности. А тут прошло почти 20 лет — и какие-то фундаментальные проблемы???
For whom how ©
Для меня главное надёжность авто (про безопасность даже не говорю — у меня два дня рождения и второй — благодаря машине, которая пошла в утиль после аварии, а у меня только одна царапина). Естественно, «функционал» (в смысле соответствия задачам) тоже важен (свой предыдущий экспедиционник сменил на немца именно после того, как задачи изменились).
Все свои машины содержал в таком техническом состоянии, чтобы я мог выйти из дома и поехать на 4000 — 5000 км. И чтобы нужно было только заехать на заправку.
А было время, когда я ездил в экспедиции в места, где цивилизации нет от слова «совсем». Полный привод, подготовленная машина и всё такое. Может, оттуда и пошла эта маниакальная тяга к надёжности.
А вот стоимость 1км пути меня никогда не интересовала. В жизни есть другие приоритеты и ценности.
Да мне не нужно рассказывать про Мерсы. Особенно, про современные и их сравнение со 124-м, например. Я, кстати, езжу на дойчеавто, но 2015 года и с меганадёжным 3,6 (а не современным «пакетом сока» 2л).
Да ладно!.. :) Вот бизнес-то идиоты. Платят за формочки, а не за хранение и обработку(!) данных. Кстати, под обработкой понимается ОЧЕНЬ широкий спектр задач/операций (ну так, на всякий случай...)
Мы смотрим с какой точки зрения? Если бизнеса (заказчика) — то ему по барабану, как написан код (в смысле, понятно или непонятно). Ему главное, чтобы система работала в заданных рамках (производительности, надёжности и функциональности).
То, о чём Вы говорите имеет смысл или с точки зрения того менеджера, кому придётся сопровождать это всё, или с точки зрения менеджмента компании, если систему разрабатывало одно из подразделений компании и в разрезе исключительно TCO. Для стороннего заказчика как раз в первую очередь важна функциональность, стабильность и производительность.
Вы или передёргиваете, или невнимательны. Я ТОГДА закрыл для себя вопрос Java. Сейчас появились другие задачи (конкретно — «кровавый энтерпрайз» на web), поэтому пришлось вернуться к Java.
И да, про «сверхбыструю алгоритмическую торговлю» понравилось. А позвольте поинтересоваться — а с чем сравнивали?
1. Вы сами это написали: «система КАК-ТО работает». Проблема именно в этом: а могла бы работать гораздо лучше (предположу, что в разы), если бы всё, что не «круды и формочки» делали не «кодируюшие макаки».
2. Видимо, Вы всё-таки не поняли: я не о том, что всё нужно писать на С++ или ассемблере. Даже на Java, C# и т.п. можно писать вдумчиво, а можно как «кодирующая макака».
Да, кстати, видимо, в вашем понимании я (и такие как я) как раз и те самые «динозавры». Возможно, это и так (в смысле, что нормальные спецы вымирают). Только вот думаю, что код написанные такими динозаврами будет лучше большинства «млекопитающих» (это по аналогии, что на смену динозаврам пришли именно они) и работать будет дольше.
А я с этим не согласен. КОЕ-ЧТО ещё можно купить качественное, но в основном — всё одноразовое. Бытовая техника, авто, электроника и т.д.
И, главное, цена ДАЛЕКО не всегда коррелирует с качеством.
И, кстати, не приведёте пример качественных и «долговечных» программных продуктов? На рынке (в отрасли), где была бы конкуренция и потребитель мог бы выбрать между несколькими поставщиками, заплатил бы побольше и остался доволен?
А при чём здесь «высококачественные круды и формочки с идеальными рамочками на монадах»? Напомню, что было написано в сообщении, которое я комментировал:
По вашему мнению, БОЛЬШИНСТВО продуктов — это круды и формочки?
И ещё из исходного сообщения:
Вот как раз формочки и простейшие круды «кодирующие макаки» как раз писать могут. Проблема в том, что, как я говорил, современные системы — это не только эти простейшие операции. А вот тенденция ВСЕ компоненты систем реализовывать руками и «мозгами» «кодирущих макак» как-то настораживает.
Я в беседах с молодыми разработчиками часто привожу один пример: работал в 80-90-х на системах СМ-4 (RAM 256Kb), потом на СМ-1420 (RAM 2Mb), операционка RSX-11M. Максимальный размер программы — 64Кб.
Чисто информационная система (но достаточно критичная, городская справка), СУБД Adabas-M (да, вся СУБД меньше 64Кб), ужасная дисковая подсистема (пакеты на 20 Мб), пользователей (терминалов) чуть больше 20(!), из них очень активных (операторов) 16-18. В ЧНН (час наибольшей нагрузки) у оператора на то, чтобы принять звонок, выслушать абонента, понять, что ему нужно, набрать запрос, получить ответ, огласить его абоненту и нажать кнопку отбоя звонка уходило 22 секунды. Сам поиск информации в БД занимал меньше секунды (в редких случаях — меньше 2-х).
Когда во второй половине 90-х возникла потребность заменить данную систему, новая реализация была сделана на QNX4, в качестве СУБД — Watcom SQL. Скорость работы по сравнению с современниками на Linux, Windows, DOS впечатляла. Но вот пользователи жаловались, что скорость работы (т.е., поиска в БД) была существенно меньше, чем на СМ-ке.
При этом, работало это то ли на 386-х, то ли на 486- компах. Сравнивать их вычислительную мощность с СМ-кой даже смешно.
Так вот, моё глубокое убеждение, что разница в бОльшей степени обусловлена тем, что тот код (и ОС, и СУБД, и самой прикладной системы) писали совсем не макаки (скорее всего, ещё и на ассемблере). Плюс, не было такого нагромождения новомодных стеков и фреймворков.
А сейчас у меня ноут, с которого пишу, имеет памяти в 8192 раза больше (во сколько раз i7 превосходит ЦПУ СМ-ки — даже думать не хочется). Стало всё работать ли лучше/быстрее хотя бы раза в 2 — НЕТ.
Плюс, повсеместная тенденция, что код д.б. В ПЕРВУЮ ОЧЕРЕДЬ, читаемым (sic!). Помню, в начале 2000-х (вроде) решил познакомиться с Java, по старой привычке после беглого просмотра синтаксиса языка, стал смотреть исходники библиотек. Помню, смотрел реализацию какой-то коллекции. Так там для того, чтобы «красиво обойти» её, вводились фиктивный первый элемент (перед головой) и последний (после хвоста). Т.е., создание двух элементов (выделение памяти, инициализация и т.п.) — и всё ради того, чтобы написать просто цикл for, без проверки условий перед циклом. Нашёл ещё какой-то подобный прикол — и закрыл для себя Java (на достаточно длительное время).
Просто мы тогда как раз писали систему, где если информация не доставлена за заданное время — то это считалось отказом. Поэтому было странно такое видеть.
А такой вот подход (читаемость в ущёрб скорости) — это, к сожалению, мэйнстрим сейчас.
К сожалению, это больше не работает. Есть в сети такой короткий рассказ — «Копроэкономика» (почитайте. Ну, или, освежите в памяти).
По большому счёту, никто в бизнесе (начиная с грандов, а на них и помельче ориентируются) не заинтересован в выпуске на рынок качественного продукта. «Х… к, х… к — и в продакшн» (с)
Тут даже не знаю, что сказать. Если «старожил» за все эти годы научился максимум что «круды» писать — то туда ему и дорога (в смысле, «на свалку истории»).
У меня жизнь сложилась так, что пришлось поучаствовать в реализации проектов абсолютно разной тематики — был и свой мультивалютный опердень банка (середина 90-х), и серьёзная информационная система предприятия, и интересная с технической точки зрения «шабашка» (начало 2000-х, торговая система одной фирмы — 4 магазина с реляционной базой, реплицируемой практически в онлайне по модемным(!) каналам. да, репликация «мастер-мастер» 4х4, пользуясь случаем, передаю привет СОВРЕМЕННОЙ репликации PostgreSQL) и самый серьёзный проект — одна из подсистем на ЖД, непосредственно завязанная на управление движением. Кстати, недавно с удивлением узнал, что она до сих пор работает. На минутку: мы перестали её сопровождать в середине 2000-х годов. Обслуживающий персонал только выходящее из строя железо меняет и заливает нашу прошивку. А там «практически» жёсткий рантайм — оцените уровень надёжности.
А по поводу темы топика — у меня сейчас сын в универ поступил. Честно говоря, я ожидал худшего. Конечно, с нашим уровнем образования не сравнится, но некоторые ПРОФИЛЬНЫЕ предметы преподаются — моё почтение. Я «мониторю» его задания и как с него спрашивают. Сравнивать его знание, например, С++ с выпускником подобных курсов — это как сравнить кремниевое ружьё с АК-47.
Алаверды: овер 30 лет разработки (IBM 360, PDP 11/40-70, IBM RISC, теперь x86), одно из лучших образований в СССР и постоянное самообразование все эти годы. И да, до сих пор «играющий тренер».