> сейчас всё подспало
Но ведь по факту таки да. Советская экономика учила кучу инженеров, трудоустраивала их (пусть и за хлеб с водой, попутно гоняя «на картошку») и большинство было довольно. Сейчас же рынок инженерных специальностей значительно схлопнулся, а количество выпускающихся меньше не стало. Как итог — большинство идут «менеджерами» всяких субстанций. Причем да, со стороны бизнеса есть запрос — но совсем на другие квалификации, которые после вузов не образуются.

> закрыть годами не могут
Ну с вашей стороны тоже лукавство — любую вакансию можно закрыть, предложив достаточную компенсацию. Значит не очень надо.

Да, честно говоря, и вакансий начального уровня много. Тут дело даже больше в том, что молодым менеджером можно заработать в теории больше, чем начинающим разработчиком. Просто потому что тот же продажник быстрее начинает создавать нужную конторе ценность. А вот то, что в будущем программист растёт быстрее, чем менеджер — кто ж об этом думает поначалу…

любую вакансию можно закрыть, предложив достаточную компенсацию. Значит не очень надо
Не всегда требуемая соискателями компенсация коррелирует с их уровнем. Но и это не всё — есть куча факторов, по которым отсматривают кандидата, и все их нужно брать в расчёт. Например, у нас нет собеседования с HR-сотрудником, предпочитаем не тратить своё и соискателя время. То есть нет тех самых «ламерских» факторов типа «агрессивный психотип в восьмой луне». Но тем не менее отобрать особо и некого.
Тут дело даже больше в том, что молодым менеджером можно заработать в теории больше, чем начинающим разработчиком. Просто потому что тот же продажник быстрее начинает создавать нужную конторе ценность.

Нет. Нужную конторе ценность создал разработчик (-ки). А продажник ее продал.
Просто работодатель не может оценить потенциальную ценность продукта, пока ее продажник не продаст. Поэтому ценит продажника. И продажник тоже себя ценит. А разработчик должен доказывать свою ценность фирме какими-то виртуальными показателями — тысячами SLOC, закрытыми тикетами, черти чем еще.
Любой (вру, не любой, — адекватный) бизнес поднимет зарплату хорошему сотруднику, и не раз. Но только в ответ на экономический эффект от работы сотрудника. Проще говоря, ты приносишь фирме больше — она тебя весомее благодарит.

Эти типично красивые слова не выдерживают проверки временем.
Ценность, которую принесет разработчик в большой продукт, может быть монетизирована фирмой через пару лет. К этому времени разработчик уже уволился, потому что фирма его не оценила — ровно потому, что ничего фирме он не принес.
А теперь внимание, вопрос — вы выплатите уже уволившемуся разработчику премию за его вклад двухлетней давности?

И, чтобы два раза не вставать, — офис, НН и Делфи — вы серьезно?
Все зависит от того, что за софт вы продает. Если речь о коробке это одно, если речь о тяжелом энтерпрайз софте, то ценность для покупателя это сам софт, процессы, ноу-хау внедренца, и еще тьма всего, плюс визуализация этого в убедительном расчете ROI. Тут много ролей, и, к сожалению, до разработчика медальки не доходят и ни в каких саксес стори вы его не увидите.
От софта конечно зависит, но дело больше в психологии и памяти людской. Разработчик как правило работает на далёкую и не всем очевидную перспективу, а продажник приносит деньги здесь и сейчас. Поэтому и выглядит в глазах например бухгалтера добытчиком. А разработчик с его запросами купить новый SSD-наоборот растратчиком. Через несколько лет картина такая-в продажнике никто не нуждается потому что хороший софт продат себя сам(рекомендации коллег, положительные отзывы на Хабре и т.д). А про разработчика уже забыли. Он ведь получал зарплату за свою работу тогда, несколько лет назад?
Да-да! Всецело согласен! Работаю в компании, производящей учебное оборудование. Но 16родажники толкают сферическое оборудование в вакууме, с зачастую нереальными сроками поставки. В итоге продажникам процент от продаж и дифирамбы, а инженерам? А инженерам ненормированный рабочий день в 15-16 часов из-за сокращенных сроков (политика компании: дешевле, быстрее, качественнее) и символическая премия.
Оба раза точно в десятку. И про отношение работодателя к продажникам, и про ценность и вклад разработчика…
Нет. Нужную конторе ценность создал разработчик (-ки). А продажник ее продал.


Можно посмотреть с другой стороны: продажник создал потребность (нашел того, кто платит) и возможность компании заработать.
Не даром многие не хотят кодить на себя, им комфортнее, когда есть работодатель с штатом продаж.
Мне однажды премию выплатили через два месяца после увольнения.
Мне через 2 года, с джунской позиции, 5000р.
Любой (вру, не любой, — адекватный) бизнес поднимет зарплату хорошему сотруднику, и не раз. Но только в ответ на экономический эффект от работы сотрудника. Проще говоря, ты приносишь фирме больше — она тебя весомее благодарит.

Не согласен. Вернее, это действует не везде. Например, в той же торговле, если сотрудник рвет задницу, перевыполняя план, и получает ЗП больше, чем рассчитывал платить работодатель, то либо ставится невыполнимый план, либо уменьшается процент. Да и не только в продажах так.
Хотя казалось бы, такой сотрудник — приносит больше пользы компании. Но работодателя жаба давит платить вменяемые деньги.
P.S. Я, если что, в торговле работал более 10 лет назад. Но, подобное до сих пор применяется.
«Ценность, которую принесет разработчик в большой продукт, может быть монетизирована фирмой через пару лет. „

Насколько я понял посыл статьи, речь идет о выпускниках институтов.
Вы реально видите много примеров, когда выпускник устроился джуном в компанию и сделал вклад в продукт, который оценивается большими деньгами?
Я сплошь и рядом вижу, что новички, пришедшие на первую свою должность, зачастую неспособны просто самостоятельно настроить себе рабочее место в соответствии с инструкцией на вики, месяца 2-3 тратят только на то, чтобы заполнить букмарки с важными инструментами в инфраструктуре. Но когда через полгода нужно сменить пароль, снова вместо того, чтобы поискать готовый ответ на внутренней вики, всех дергают, поскольку аккаунт залочился после 5-й попытки сделать красивый пароль, хотя при его смене требования к паролю написаны прямо на экране.
P.S. Исключения конечно есть, но они так редки, что лишь подтверждают правило…
Может быть, у вас просто не умеют отбирать кандидатов?

Про монетизацию — не думаю, что автор и его коллега в этом тезисе "Но только в ответ на экономический эффект от работы сотрудника. Проще говоря, ты приносишь фирме больше — она тебя весомее благодарит." имели в виду только выпускников. Судя по этому комментарию, это общее правило для всех сотрудников.
Простите, это не у «нас» — я даже живу не в той же стране, что автор. Но я воспринимаю посыл статьи именно как общее направление, а не частные случаи.

Даже при всем понимании конкретного менеджера, а то и владельца компании, о том, что «кадры важны», как только компания достигает уровня 100-300 и более сотрудников, все становится слишком сложно, ибо нельзя найти 20-30 человек с одинаковой идеологией. А следовательно найти 20-30 руководителей на все посты, чтобы они одинаково следовали ценностям — тоже нельзя.
Всем нужно идти навстречу друг другу.
Удивили детали:
аккаунт залочился после 5-й попытки сделать красивый пароль,
хотя при его смене требования к паролю написаны прямо на экране

— в AD «лочится» за 5 неправильных «вводов» текущего пароля
и блокировка эта «на время» ( не связано это со сменой пароля)

— если новый пароль не соответствует,
то просто форма ввода не закрывается
вводишь до упора

готовый ответ на внутренней вики

Не меньше 8 + «буквы, цифры, запятые» — удостоены статьи в Wiki?
( и, кстати, есть или нет это «на экране» — не помню, хотя и пытался вспомнить)
всех дергают
всех кроме сисадмина?

через полгода
уменьшите срок до 40 дней, тогда есть шансы «довести до автоматизма»
И какое отношение имеет уровень программирования к навыкам смены пароля? Навыки корпоративного user-а несколько ортогональны
Кроме AD есть еще множество других авторизаций. ldap, websso, какая-то база Оракла соседнего проекта, в котором заводятся тестовые пользователи для разработчиков, и если ты забыл пароль, то нужно обращаться не к сисадмину, а к этому проекту.
В общем как только появляется что-то посложнее, чем один пароль и один сервис, что-то, что требует некоторых навыков самоорганизации, 99% выпускников на этом заваливаются по полной.
(
множество других авторизаций
Я таки предчувствовал
)

Всякую всячину надо бы интегрировать с AD

тестовые пользователи
Выставьте в тестовой среде
опцию «не требовать смены пароля» на уч.записях

требует некоторых навыков самоорганизации,

Как бы это культурно выразить? Что бы без обид?

Но и промолчать мне, ведь то же вредно для вас же — что многое «не так» видно сходу ( по первому сообщению)

1) Вы зря «наехали» на «юных падованов»
2) следствие: у вашей орг-ции большие шансы «прославиться» «аки» Медок

P.S. Неужели у ваших заказчиков тоже множество систем и без SSO, и без «стыковки с AD»? Зачем вам тестировать на стенде не соответствующем реалиям заказчика?
P.P.S. к Jira и Сonfluence точно есть внешний компонент стыковки с AD по керберос
Зачем все интегрировать с одним и тем же AD?
И даже при наличии такой интеграции, может быть двухфакторная авторизация, вторая часть которой обслуживается другой службой.

Вдобавок это может быть отдельный AD, развернутый в рамках тестирования проудкта, потому что часть проектного девелоперского окружения, а не корпоративной инфраструктуры, следовательно это внутренняя кухня проекта.
А если вы сами разработчик в microsoft, у вы его сами пищете — у вас этих тестовых AD инстансов может быть десятки.

1) не зря, в организации со сложной бюрократией и многослойной инфраструктурой тоже нужны джуны.
2) Вот вы вообще не с той стороны на мой комментарий смотрите.
Пароли можно разделить на 2 вида:
— реальные пароли пользователя
— пароли для тестовых стендов

В идеальном случае паролей первого типа должно быть ровно 1. Т.е. все системы компании должны быть интегрированы в AD или SSO, чтобы пользователю не нужно было менять пароли во многих системах и запоминать их. К этим паролям могут предьявляться требования по сложности.

Пароли второго типа — это пароли, на которые не должны распространятся правила по смене/сложности пароля. В идеале можно ввести либо единый пароль, либо пароль = имя пользователя.

Если у вас не так, то не обвиняйте сотрудников, а наведите порядок в системах. Я уверен, что запоминание зоопарка паролей — это проблема не только для новичков…
Если в вашей организации пароль локальной машины и например от оракл базы совпадают и автоматически синхронизируются между собой — мне даже интересно, где вы работает.

Даже в обычном веб-проекте, пароль от mysql и shell — разные. Я реально не понимаю, почему при виде нескольких паролей, вы сразу обвиняете в беспорядке компанию.
Почему бы не предположить, что корпоративная система может быть достаточно комплексной, сложной, состоять из десятков тысяч сотрудников, и один единый пароль на все системы — нереален из-за инфраструктуры, которую нельзя упростить из-за совершенно объективных требоавний, а не «беспорядка».
Пароль от локальной машины — это моя учётка в AD. Пароля локального админа я не знаю, да и не должен знать. В базы данных также хожу под своей доменной учёткой — благо и Oracle и MS SQL отлично работают с AD-пользователями.

В моей компании я использую всего 3 личных пароля для различных систем — особенности корпоративной иерархии. (Притом использую один и тот-же, чтобы не забывать и не путаться и меняю все одновременно.) Тут проблемы нет — т.к. 3 пароля запомнить легко. Для всего остального пароли хранятся в документации / конфигах или существуют правила (к примеру для всех тестовых юзеров 1 пароль) — и их не нужно менять каждые n дней.

То есть в вашей компании три пароля вас устраивает, а когда я говорю «у нас больше одного пароля», вы придираетесь.

У вас пароли лежат в документации/конфигах или существуют правила — все в порядке, а когдя я говорю, что новички не удосуживаются прочитать документацию и правила — вы придираетесь.

Двойные стандарты?
По поводу 3-х паролей, нет, меня не устраивает — хочу иметь 1 пароль на всё. К тому же в комментарии выше я писал «В идеальном случае паролей первого типа должно быть ровно 1». Т.е. я понимаю, что не всегда это возможно, но нужно к этому стремиться…

По поводу паролей в документации и конфигах — в том то и дело, что их не нужно менять и чаще всего даже вводить. Забрал последнюю версию конфига с TFS/Git, а там уже пароль лежит для подключения к БД. Запустил приложение протестировать, а там пароль такой-же как и имя пользователя. Красота! Обычно новички запоминают такое после первого объяснения и больше не спрашивают…
Отвечу лучше здесь ( так удобней для чтения ):
инстансов может быть десятки

Если требуется время жизни не меньше полугода,
то «всё» стыкуем с «местным» AD ( внутри DMZ зоны)

Внутри ещё TS или мини/midi :-) VDI
падованы и гуру заходят по RDP «давят» Yes
меняют пароль

И никого не «отвлекают каждые полгода» Ж-)

Т.е.:
«В идеальном случае паролей первого типа должно быть ровно 1». Т.е. я понимаю, что не всегда это возможно, но нужно к этому стремиться…
> Не всегда требуемая соискателями компенсация коррелирует с их уровнем.

Вам шашечки или ехать? Если не можете закрыть вакансию с текущим уровнем компенсации — это ваше понимание взаимосвязи уровня компетенций и компенсации не коррелирует с финансовыми реалиями рынка.

Истина не так уж проста, на рынке бывают перекосы. Если специалист или джун на рынке стоит Х, это не значит что есть значительное количество компаний которые могут это Х окупить с прибылью. Возможно есть компании которые в настоящее время без оглядки проедают бюджетные/инвестиционные деньги и перегревают рынок по этой позиции.

> Если специалист или джун на рынке стоит Х, то он стоит X.

Все рассуждения о перекосах (даже если они есть и растет очередной пузырь) — нытье в пользу бедных нанимателей. Цена на рынке определяется балансом спроса и предложения. На этом нужно ставить точку.
После того, как знакомая HR искала кузнеца на 500К оклада, я перестал считать IT вакансии дорогими.

А если перекос в другую сторону (тупые изменения в налоговой политике из-за которых временная просадка) — это разговор в пользу бедных специалистов?


Мне, как специалисту, не выгодно ставить точку на балансе спроса и предложения. Потому что перекосы на самом деле есть и чаще разумнее их учитывать, чем просто идти "по рынку".

> А если перекос в другую сторону (тупые изменения в налоговой политике из-за которых временная просадка) — это разговор в пользу бедных специалистов?

Так вы же написали что просадка временная. Такое у всех бывает из-за внешних факторов, особенно неожиданных. Другое дело, что если это было известно заранее — надо было готовиться чтобы просадки не было.

> Потому что перекосы на самом деле есть и чаще разумнее их учитывать, чем просто идти «по рынку».

Ну вот расскажите пожалуйста, что такое перекосы. Возьмем для примера физический рынок рядом с момим домом. Там в одном магазине есть помидоры за 200 рублей и помидоры за 600 рублей килограмм. Это перекос? Да нет, это просто объективная реальность — у разного товара разная цена. Или вот например те же самые помидоры в пятерочке будут стоить меньше 200 рублей. Но они дальше от моего дома, поэтому закономерно что цена ближе к дому выше. Т.к. я покупаю товар у дома и доплачиваю деньгами за скорость. А соседка покупает в пятерочке и денег платит меньше, но тратит больше времени и сил. В итоге мы с ней покупаем немного разные помидоры.

В итоге на рынке есть самые разные предложения и запросы. Просто потому, что у людей разные потребности. Ну это же естественно, при чем тут перекосы?

Вот вы пишете, что перекосы нужно учитывать и не просто идти по рынку. Так прикол в том, чтобы вы не можете уйти с рынка, вы и есть его часть т.к. что-то продаете и покупаете. Конечно, коньюнктуру полезно учитывать если хотите больше денег. А как же иначе.
Скорее продолжительное время не закрываемая вакансия может являться показателем того, что компания может обходиться и без такого специалиста. В таких случаях наниматель готов платить ровно столько, сколько (как ему кажется) он сможет сэкономить/заработать на данном конкретном специалисте, не более.

Многие семьи посматривают в сторону покупки второй машины при наличии первой, однако есть определенный лимит, выше которого платить не готовы. Это не значит, что таких денег в семье нет, а значит лишь то, что достаточных выгод от покупки Bentley они не получат, когда рассчитывают на Pajero, хотя Bentley своих денег стоит. Ровно также и в бизнесе: специалист просит 100к/месяц, его квалификация именно столько и стоит, но компания не готова платить более 60к, т.к. соответствующий продукт на выходе у специалиста принесет лишь 100-120к, а ведь еще налоги, различные платежи, оборудование, аренда. Так что в каждой ситуации есть определенные лимиты, которые работодатель может пересмотреть лишь в случае пересмотра отношения к самой вакансии (например, расширение списка задач для соответствующего сотрудника, или еще чего-нибудь).
Пример с семьей и машиной отличной. Только в таких случаях обычно адекватные члены семьи не жалуются на хабре, что «автомобилей — жуткая нехватка, не можем найти автомобиль, все цены неадекватно высокие!». Автомобилей-то полно, по разным ценам. Была бы настоящая необходимость — купили бы тот, который доступен.

Чуть ниже про это как раз отлично написали.
Возможно есть компании которые в настоящее время без оглядки проедают бюджетные/инвестиционные деньги и перегревают рынок по этой позиции.

Интересно, а с какого рожна я должен входить в положение бедного нанимателя? Вот у нас например высокий % по кредиту, потому что гос. компании берут деньги и не возвращают, и этот невозврат закладывается в % по кредиту лично мне. Это такое же пердергивание рынка, и вы знаете, что-то еще ни один банк не вошел в мое положение и не выдал мне кредит под 2%, чтобы нивелировать передергивания. С чего вдруг я должен это делать?

Интересно, а с какого рожна я должен входить в положение бедного нанимателя?

А вы не должны. Нанимателю придется поискать другой путь решения кадровой проблемы если рыночная з.п. специалиста не вписывается в экономическую модель бизнеса. Иными словами, вы не получите эту работу а наниматель не получит специалиста.

Да это-то понятно. Я к тому что "передергивания рынка" не являются оправданиями ни для работодателя ни для специалиста.

У нас высокий процент по кредиту не поэтому. Банк, чтобы выдать вам кредит, занимает деньги либо у вкладчиков, либо на денежном рынке. А на денежном рынке у нас регулятор есть — ЦБ, выдающий кредиты по базовой ставке и берущий вклады чуть дешевле.
Так что банку ну вообще не выгодно занять деньги под 8-9% и выдать вам под 2%.
компании берут деньги и не возвращают, и этот невозврат закладывается в % по кредиту лично мне

Это влияет только на маржу банка, а основная часть вашего процента — проценты ЦБ.
> Не всегда требуемая соискателями компенсация коррелирует с их уровнем.

Вы так говорите как будто есть какая-то одна объективная мерка уровня соискатля и одна объективная цена. Это рынок, хоть и рынок труда. Не можете купить — предлагайте выше цену. Не можете предложить выше цену — это не значит что предложения мало, а это значит что предложения мало за те деньги которые вы готовы платить. Если ваши продукты и процессы не позволяют вам оплачивать сотрудников может быть стоит где-то оптимизировать бизнесс?!

> Любой (вру, не любой, — адекватный) бизнес поднимет зарплату хорошему сотруднику

Бизнес платит сотруднику столько, чтобы сотрудник не ушел работать в другой бизнес. Бизнес работает ради прибыли. Иначе это не бизнес, а благотворительность. Хороший сотрудник, который не показывает признаки мобильности будет сидть без повышений оплаты годами.
Именно так и есть, для того чтобы тебя оценили надо уволиться) Сталкивался с таким циничным подходом-решать проблему тогда когда она возникнет. Собрался уволиться человек? Пусть уходит, другого найдём. Не можем найти такого же или лучше за эти же деньги? Хорошо, поднимем планку ЗП и будем искать дальше, но тому «предателю» повышать ЗП и удерживать не будем.
Это пример однозначно плохого работодателя, который не ценит свои деньги и время, а ведется на какие то глупости.
У меня при уходе из последних мест, все говорили, если разонравится на новом месте — возвращайся к нам, возьмем. Некоторые даже удержать пытались подъемом ЗП.
Мы, когда в 2014 году искали 2х весьма средних С++ разработчиков в Москве, просто с опытом не senior. Мы потратили просто тонну времени, чтоб найти адекватных. На двоих мы отсобеседовани около 50 человек по скайпу и около 10 очных провели. То есть это прям дофига и больше времени рабочего старших разработчиков. А это еще даже не включает времени на адоптацию новых сотрудников и все сопутствующие расходы.
Если не секрет, каких знаний вы требовали от этих разработчиков? Просто не верится, что из 60 С++ программистов, 58 оказались дураками…
Есть и более суровые наблюдения в этой сфере. Например, есть статья, в которой утверждается, что 199 из 200 разработчиков не могут решить задачу fizzbuzz.
Правда, статья не наша и десятилетней давности, но я не вижу причин, почему у нас все должно кардинально отличаться.
a game children often play (or are made to play) in schools in the UK. An example of a Fizz-Buzz question is the following:

Write a program that prints the numbers from 1 to 100. But for multiples of three print «Fizz» instead of the number and for the multiples of five print «Buzz». For numbers which are multiples of both three and five print «FizzBuzz».

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes.
А на «пуркуа» решать детские головоломки, да ещё и на время?
А программа на Prologe засчитывается?
И зачем леса истреблять? Ж-) (про бумагу)
Соискателю — для того, чтобы его взяли на работу.
Работодателю есть смысл предлагать такие задачи потому, что 99% отказавшихся откажутся лишь потому, что не осилили. То есть, большая экономия времени интервьювера.
( 99% отказавшихся откажутся --не потому)

Ну если честно, то FizzBuzz лучше чем тесты на IQ, но не намного...

Вы их, конечно, поручаете проводить «девушке из кадров»?

Тогда ещё есть шансы, что тестируемый подумает:
— Опять кадровики Инета начитались

P.S. На основе всё ещё ждущего модерации ком-та:
Загадка -- угадай фирму
Решал практическую задачу:
набрал в ddg.gg
ZZZ курсы английского

Курсов не нашёл ( их не для сотрудников, кажется, не существует ),
но впечатлений от чтения первой пары дюжин ссылок — масса, рекомендую

Cобствено вопрос: с 2014 года тесты не поменялись
Например, про (n-m)/(n!-m!) спрашиваете?


А всё же:
А программа на Prologe засчитывается?
И зачем леса истреблять? Ж-) (про бумагу)
99% отказавшихся откажутся — не потому
А почему? Чем этот вопрос отличается от любого другого вопроса по программированию?
FizzBuzz лучше чем тесты на IQ, но не намного
Не согласен. Если человек сдал тест IQ на низкий балл, это мало что значит — он все еще может быть хорошим разработчиком. А вот если он не смог написать FizzBuzz — не может.
А программа на Prologe засчитывается?
И зачем леса истреблять? Ж-) (про бумагу)
Если бы я проводил такое собеседование, я бы не имел ничего против любого языка программирования (или даже просто алгоритмического языка, как в ЕГЭ по информатике), который мне понятен. И не был бы против программирования этой задачи на компьютере. Правда, вероятно, я бы предложил google doc или что-то вроде того, потому что требование соискателя дать ему IDE для решения такой задачи ничего хорошего о нем не говорит. И разумеется, я бы предложил бумагу и доску, потому что есть люди, которым комфортнее писать на собеседовании не на компьютере.
если он не смог написать FizzBuzz

а если не захотел? Ж-)

Напишите программу, которая печатает цифры от 1 до 100. Но для кратных трех напечатать «Fizz» вместо номера и для кратных пяти напечатать «Buzz». Для чисел, кратных как трех, так и пяти печатным «FizzBuzz».

вот куда печатать числа и буквы — на StdOut?
И это в год столетия 1917-го? И 60-летия спутника?

В ADA вообще для этого надо отдельный модуль подключать

в Сlarion ( не сейчас, давно) полистал 3-х сантиметровую книгу --нашёл ( TYPE) Раз в жизни применил Ж-)

требование соискателя дать ему IDE
я тут уже про кнопку F9-C-C упоминал
может тестируемый без любимой кнопки уже и не может

а в Clarion не уверен, что отдельный компилятор вообще есть,
но что на практике от о.к. в C. пользы мало — уверен

P.S. Уточняющие «вводные» — заметно меняют дело, надо обдумать

P.P.S. Идея: в FizzBuzz --шипящие согласные печатать красным цветом
P.P.P.S. или упростим — гласные желтым
Забавно: в Clarion уже и не вспомню как делить по модулю Ж-)
( в TP — mod)
а если не захотел?
А если он не захотел на какой-то другой вопрос отвечать? Значит, он сам себе злобный буратина, пусть в другое место идет работать.
куда печатать числа и буквы — на StdOut?
Да куда угодно, для целей, которые ставятся перед этой задачей (быстро проверить, что человек умеет хоть что-то) это не важно. Есть сомнения — спросите.
я тут уже про кнопку F9-C-C упоминал
может тестируемый без любимой кнопки уже и не может
Вы и правда думаете, что найдется человек, который без Ctrl+Ins не сможет десять строчек набрать, но с Ctrl+Ins станет хорошим разработчиком? Думаю, это множество очень мало и им можно пренебречь.
в Clarion не уверен, что отдельный компилятор вообще есть
А зачем вам в этой задаче вообще компилятор?
Элегантные 100 строчники принимаются?

Ладно, будем считать это быстрым прототипом:

@echo 1
@echo 2
@echo Fizz
@echo 4
@echo Buzz
@echo Fizz
@echo 7
@echo 8
@echo Fizz
@echo Buzz
@echo 11
@echo Fizz
@echo 13
@echo 14
@echo FizzBuzz


Ну и так далее

Про набрать: когда я редактировал autoexec.bat ( или .sh)
в редакторе TP использовались ^K^B и ^K^C
Особенно для label

И это экономило время на отладку в cmd /c /y

А зачем вам в этой задаче вообще компилятор?
Для разработки «через тесты»

P.S. Про F9-C-C — это не аналог ^V
Вообще-то, мне на MacBook от испарившейся клавишы
надо Ctrl-Alt-Ins на ".."

P.P.S. Смайлики опущены Ж-) Но кое-где их нет
( выше по тексту — скорее есть,
ниже — всё довольно серьёзно )

P.P.P.S. Про не сможет или не захочет:
Сперва тестируемый окинет взглядом интерьер
представит лицо мамы/невесты/жены ( нужное подчеркнуть) по возвращении с охоты. На это будет упущено 30 сек.

Самые битые жизнью отпросятся на экскурсию в места уед-ых ( студенты 3-их курсов мотайте на ус) раздумий
Ещё более тщательно оценят обстановку

( Вот здесь есть тонкость — контора может размещаться
на нескольких этажах или в раздных зданиях)

И собствено, тут при положительной ветви предсказателя ветвлений можно писать 100 строчник

alexeykuzmin0 не обижайтесь и не принимайте на свой счёт:
ваша модификация IQ теста как раз имеет отклонения к лучшему,
пишу я больше для начинающих тестируемых

Но не стоит забывать, что реально-то все эти приколы оценят интеллект эмоциональный ( у своего HR можно взять перевод термина Ж-) )

Элегантные 100 строчники принимаются? Ладно, будем считать это быстрым прототипом
Такой пример сразу вызовет вопрос «а вы можете написать более читаемый код?». Хотя, насколько я понимаю, статья, на которую я сослался, говорит о том, что 99.5% соискателей даже такое написать не в состоянии.
Для разработки «через тесты»
Что-то я сомневаюсь, что существуют хорошие разработчики, которые не могут написать FizzBuzz без TDD.
FizzBuzz без TDD
Там как-раз подразумевался смайлик Ж-)
«а вы можете написать более читаемый код?»
Как раз для .bat циклы и арифметика гораздо менее читаемы Ж-)

А при «красивом» коде можно, наоборот, спросить:
Задача явно разовая. Почему излишние потери рабочего времени?

Т.е. опять-таки задача на эм-ый инт-кт Ж-)
статья, на которую я сослался, говорит о том, что 99.5% соискателей даже такое написать не в состоянии.
Точно так
Поправка: 199 из 200 кандидатов на позицию разработчика. Это не одно и то же.
FizzBuzz и для профи проблематичен тем, что экзотика ( см. здесь же)
50, а не 60. Нормальных реально было 4. 1 ушел в другую команду, 1 хотел от 250К — мы же его во столько не оценивали. Примерно 10 было Qt-ов, которые вообще ни на что тольком не могли ответить без Qt, для задачек мы им разрешали использовать Qt-е контейнеры, что они знали вместо std-ых. Но всеравно они все были никакие без базового понимания.
Возможно тогда была проблема с кандидатами на рынке и все валили из страны, хз либо сидели на своих местах и не рыпались.
Мы вообще почти знаний никаких не требовали. Знания языка базовые(мы не спрашивали про всякие virtual inheritance и вопросы с подвохом про С++), был вопрос как реализовано std::map/std::unordered_map в общих чертах по скайпу, но если кандидат не знает стандартной библиотеки, мы это пропускали. Но если пользовался std::map — и не читал исходников и не знает как оно работает, то это пробел.
Были несложные задачки на алгоритмы, про алгоритмическую сложность, базовое про знание float/double чисел, например, как сложить с минимальными потерами массив из float и какова сложность решения. Какие то базовые вещи про многопоточность, вроде mutex vs spinlock, написать mutex/spinlock.
Какие то базовые вещи про многопоточность, вроде mutex vs spinlock, написать mutex/spinlock.

Написать мьютекс самому руками в юзерспейсе?
Через CMPXCHG spinlock…
Так это спинлок. А мьютекс, с нежгущей CPU блокировкой и отдачей процессора другому треду?
Там всё веселее. Нормальный мьютекс — это несколько итераций спинлока, и только потом системный вызов. Причём спинлок — это не долбаханье CMPXCHG в цикле (это только будет лочить шину почём зря), а CMPXCHG с паузой в виде какой-нибудь бесполезной операции на 50-100 тактов (длина цикла может быть случайной).
Секундочку, мьютекс — это сущность, позволяющая в каждый момент времени только одному потоку захватывать разделяемый ресурс. А уж эффективно он реализован или нет, с ожиданием и передачей кванта другому потоку или нет — совсем другое дело.
Если взять реализацию, скажем, CriticalSection в Windows, то там будет и спинлок в юзерспецсе некоторое время, сколько-то итераций, и падение в ядро с ожиданием. Но это не значит, что мьютекс — непременно такая эффективная вещь.
Да, голый спинлок — это частный случай реализации мьютекса, пусть и неэффективный. Спинлок — реализация, мьютекс — абстракция (разделение доступа к ресурсу).
Я паршу «написать мьютекс/спинлок» вот так, через слеш, как два варианта одного задания. А если это два варианта, то они должны отличаться. Если это неправильная интерпретация — да, вы правы, конечно.

Тут ещё, кстати, про одноядерные машины и preemption можно было бы поговорить, но то такое.
Вопрос терминологии. Для меня «написать mutex/spinlock» звучит как «сделать мебель/табуретку», потому что мьютекс — более абстрактное понятие, более высокого уровня, а спинлок — уже деталь или способ реализации. Но не суть, мы друг друга поняли.
Этот вопрос как раз и показывает, понимает ли кандидат как оно работает. Если понимает, то в процессе размышлений должен спросить про примитив уровня ядра вида futex, на котором и должна базироваться реализация. Ну этот вопрос как раз почти всегда отвечали хорошо, кроме Qt-ов. Из них никто даже скайповое не прошел…
> Если понимает, то в процессе размышлений должен спросить про примитив уровня ядра вида futex

Это если пишет под Linux, в Windows же аналога ему нет. Наиболее низкоуровная вещь — CRITICAL_SESSION, но она в точности является мьютексом.
У нас в требованиях был опыт разработки под Linux.

Ну тогда я не удивляюсь, почему нормальных кандидатов оказалось только 4. Возможно, требование должно было звучать как "опыт написания высокопроизодительных программ под Linux"


Для меня "опыт разработки под Linux" — слишком общее понятие, которое не подразумевает знания всей подноготной. То есть использование pthread с pthread_mutex_t — это и есть опыт разработки под Linux. Ну а лезть в недра glibc — это уже не задача рядового С++ программиста.

У нас не было конкретных вопросов про все детали(комментарием ниже я скорее сбился в процесс работы, чем то, что мы спрашивали реально), типа сколько байт занимает node в std::map или про дебри реализаций.
Мы скорее вели дискуссию про такое. Как бы кандидат это реализовал и почему.

Возможно, требование должно было звучать как «опыт написания высокопроизодительных программ под Linux»

У нас пару лет примерно такая вакансия и висела, но кандидатов вообще были единицы. Потом мы снизили порог, тк нужно было нанимать побыстрее.
> У нас пару лет примерно такая вакансия и висела, но кандидатов вообще были единицы. Потом мы снизили порог, тк нужно было нанимать побыстрее.

Тогда вопросов нет. В принципе, научиться писать высокопроизводительный код под конкретной окружение не составит труда, если у кандидата уже есть опыт подобной оптимизации в других областях и понимание теории. Поэтому действительно проще подобрать способного кандидата, чем искать готового.
научиться писать высокопроизводительный код под конкретной окружение не составит труда, если у кандидата уже есть опыт подобной оптимизации в других областях и понимание теории
Как будто если подобного опыта нет, так научится этому составит много труда…
В любом случае работодатель за это заплатит, если не найдет дешевого падавана, на которого перекинет обязательство это выучить за недорого.
> Как будто если подобного опыта нет, так научится этому составит много труда…

Да, это может занять несколько месяцев или даже пару лет. Одних знаний мало, нужен ещё и опыт. Не любой работодатель будет готов столько времени потратить на обучение.
Несколько месяцев — допустим, да, не любой работодатель потянет.
А зачем к нему идти, нужно выбираться от туда где проблемы с деньгами или экономия на сотрудниках.

Но стоит обратить внимание, что даже человек с опытом тоже может отлаживать не один месяц.

Но да, новичку такая бага не по силам, ему нужно начать с чего попроще при поддержке того кто поопытней. Так что да, надежда на способного кандидата.
> Но если пользовался std::map — и не читал исходников и не знает как оно работает, то это пробел.

Вариант ответа: бинарное дерево без уточнения типа (красно-чёрное, AVL или ещё какое-нибудь) устроит? Главное, что время вставки/удаления/поиска — O(log N), а остальное — детали реализации.

Ну читать исходники C++ STL — сомнительное удовольствие, дефайн на дефайне и дефайном погоняет, плюс дикий объём кода.
Ну детали имплементации сильно могут влиять. Для skype вопроса такой бы ответ устроил.
Но AVL от RB довольно сильно отличается в некоторых вещах. И если пишешь на С++, то хорошо бы знать такие нюансы, так же знать сколько аллокаций требуется и памяти, например. Это совсем базовые вещи для С++. Иначе, тогда можно и на перле писать, если в таком не разбираться.
Высокопроизводительный код на С++ вообще не очень приятно писать. Если страшно читать STL, тогда лучше его не использовать, что многие и делают.
И если пишешь на С++, то хорошо бы знать такие нюансы, так же знать сколько аллокаций требуется и памяти, например.

Увы, этого знать невозможно просто потому, что стандарт языка не определяет детали реализации. В библиотеках MSVC, GCC, Intel реализации могут очень сильно отличаться друг от друга, и это нормально.


Это совсем базовые вещи для С++

Не соглашусь с данным утверждением.


Высокопроизводительный код на С++ вообще не очень приятно писать. Если страшно читать STL, тогда лучше его не использовать, что многие и делают.

Ну так высокопроизводительный код и универсальная STL — вещи малосовместимые.

В библиотеках MSVC, GCC, Intel реализации могут очень сильно отличаться друг от друга, и это нормально

Верно, но мы и не использовали такой набор компиляторов. У нас была одна версия gcc, который нас полностью удовлетворял, про которую мы много чего знали. И компилятор и ядра мы оооочень аккуратно и медленно обновляли. Лучше ограничить себе задачу и не поддерживать, например, сборку под macosx или windows, если никто и никогда этот код там не будет запускать. То же и про версии ядер и компиляторы.

Ну так высокопроизводительный код и универсальная STL — вещи малосовместимые.

Я скорее, про то, что оба занятия не самые простые и приятные. Но часто нужно читать реализацию, прежде чем использовать. Как, например, после чтения дикого сгенерированного кода protobuf выяснилось, что он работал медленнее, чем самописный реккурсивный json-parser. То есть бинарная десериализация работала медленнее, чем текстовая json. Из-за кучи различных аллокаций по месту и нет в protobuf-е.
> Как, например, после чтения дикого сгенерированного кода protobuf выяснилось, что он работал медленнее, чем самописный реккурсивный json-parser.

Ага, а потом программистов почему-то начинают ругать за написание велосипедов.

У меня в проекте тоже используется самописный Json-конвертер, и он тоже быстрее библиотечных. И библиотека для распараллеливания у меня тоже своя (накладные расходы в parallel_for уменьшились в разы). Ускорение за счёт снижения универсальности — это нормально.
Ага, а потом программистов почему-то начинают ругать за написание велосипедов.

В том, месте работы у нас все было практически самописное, даже часто из-за проблем сопровождения opensource продуктов. Сейчас же у моей фирмы нет столько ресурсов или она их более рационально использует и мы по максимуму переиспользуем тукущие решения. И пишем что-то, только если вообще нет готового или оно совсем негодно. Но тут и нет таких требований по скорости. Но писать свое больше фана, чем рыться в чужих бага в JIRA-трекере проекта или заводить новые.

Ускорение за счёт снижения универсальности — это нормально.

Да, так и есть.
Я на всякий случай переспрошу: вы чтением кода выяснили, что он работает медленнее? Не профилированием всего приложения, не чем-то таким, а чтением?
Мы решили просто посмотреть, что он генерит, затем было видно по коду(возможно сейчас это уже давно не так), что делается много лишних теледвижений вроде аллокаций и копирований памяти туда-сюда. Потом мы сравнили скорость на наших данных. И поняли, что оно хуже нашего текущего json-парсера, и решили нигде его особо не использовать, где важна скорость. Хотя до этого была идея попробовать из-за удобства для использования в различных языках.
Если страшно читать STL, тогда лучше его не использовать, что многие и делают.
Дело не в том страшно или нет, тяжело или нет, а в том, хватит ли у вас денег чтобы человек этим занимался за подходящую ему ЗП. Именно поэтому многие на C++ не пишут.
Я обожаю С++, это мой самый любимый язык из императивных, хлебом не корми дай шаблонами обмазаться и vtune по коду погонять, но хедеры libstdc++ я читать патологически не могу. Шланговская libc++ вот поприятнее уже будет.
самый наркоманский по чтению STL, имхо, у MSVC++
Есть два варианта, или в фирме типовые задачи, или она быстро разорится. В обоих случаях — отлично что ушли. Кстати, если есть восприятие, что фирма хорошая, то можно через полгода зайти узнать как дела, и вернуться на полуторную-двойную зарплату.
молодым менеджером можно заработать в теории больше, чем начинающим разработчиком

А откуда возьмётся молодой менеджер без руководящего опыта?
(реально интересно)

Из контекста я понял что менеджер в статье подразумевается в широком смысле, не только руководитель. Конкретно менеджер по продажам.

У менеджеров по продажам обычно очень небольшие оклады. И проценты с продаж, разумеется.

Менеджер — специалист управляющий процессом (продажи, логистика, закупки т.д.), не обязательно персоналом.
молодым менеджером можно заработать в теории больше, чем начинающим разработчиком
Насколько я понимаю, джун без опыта в Москве вполне может получить тысяч 50. Неужели продажник без опыта имеет шансы получить больше?
Согласен, за примерами далеко ходить не надо. Я учился в городе чуть выше 400 тыс. населением, где практически все производство уже давно исчезло или находится в умирающем состоянии. В городе минимум 2 вуза, обучающих спецов по АСУТП. Каждый год — по 50+ человек с соответствующим дипломом. А сколько нужно таких людей региону? Никого это не волнует. В советское время их могли бы распределить туда, где есть недостаток соответствующих кадров, а сейчас человек может это сделать лишь самостоятельно. При этом если выигрыш в зарплате будет минимален (если вообще будет), жильем никто не обеспечит, и прочие прелести рыночной экономики.
Продолжают клепать спецов в количестве, значительно превышающем потребности рынка, а потом удивляются: чего это у нас так мало людей работает по специальности?
Живу и работаю в промышленном городе, где больше половины предприятий завязаны на 1,5 компании предлагающие услуги спецов АСУТП. Естественно, руководство каждого завода считает их цены оху завышенными и хочет инженера АСУТП за 25-30 тысяч в месяц в режиме 24/7, так как нанимать двух штатных специалистов — это уже слишком. Или повесить эти обязанности на сисадмина, а то он не занят.
IMHO, инженеры АСУТП нужны, но платить им и обучать их мало кто готов.
Продолжают клепать спецов в количестве, значительно превышающем потребности рынка, а потом удивляются: чего это у нас так мало людей работает по специальности?

"Продолжают, удивляются" — кто продолжает и удивляется?
Ну не принудительно же людей в АСУТП затаскивают, они сами ведь идут, на что-то надеются. И скорее всего получают желаемое, работая в макдаке менеджером или переезжая туда, где спецы АСУТП нужны.

> любую вакансию можно закрыть, предложив достаточную компенсацию. Значит не очень надо.
зацепился за фразу «любую». Есть вакансии, список потенциальных претендентов на нее исчисляется единицами и все они уже пригреты и обласканы. И сколько бы вы не предлагали денег (а у любого предложения есть верхний предел экономической целесообразности) сотрудник не бросит свою квартиру в уютном районе с хорошей инфраструктурой, с детсадом и школой для детей, парком, прикормленными уточками в соседнем пруду, сворой знакомых, родственников и т.д. Ну вот не повезло вам иметь свой офис не там где живет этот уникальный специалист. Хотя если бы повезло, то он бы к вам обошелся очень и очень бюджетно.
Все так, но мы ведь говорим не о лауреатах нобелевской премии и не о стиве джобсе, а больше о «программиста на delphi». Ну а если есть «верхний предел целесообразности» и как-то и так обходитесь по многу лет — значит и не нужен вам особо этот специалист, правда?
Да ладно, про нобелевку и джобса. Просто его одного приходится заменять на 5-6 узких спецов. А это приводит к тому, что для решения проблемы на стыке всех этих специальностей приходится проводить совещания такой кучей народа (с соответствующим расходом времени нервов и разных языков). А был бы один, он там в голове чего-то пошевелил извилиной и все.
Конечно можно обойтись и без него, но его наличие дает кардинальный прирост в решении нестандартных проблем и задач. Именно такие придумывают решения которые устраивают сразу по многим параметрам.
Это как переводить с русского на английский имея под рукой только русско-монгольский, монголо-китайский, китае-немецкий и немецко-английского переводчиков. Причем каждый из них не в полной мере владеет предметной терминологией (точней все владеют, но в разных диапазонах).
Радует, что с русского на английский переводит нужно не часто. Но когда нужно, хочется просто застрелиться. А был бы русско-английский переводчик, всем было бы проще жить.
Всегда удивлялся существованию таких мифических персонажей. Он и бэкэнд выстроит, чтоб безопасно и фронт напишет на cutting edge-технологиях, еще и железку космосоустойчивую спаяет. Конечно все хотят такого, но насколько его хватит и какая очередь задач при этом к нему выстроится, учитывая, что его одного заменяют аж пятеро узких спецов? И через сколько времени будет готов некоторый продукт в таком случае? Да и люди не железные.
Они есть. Просто чаще встречаются там где занимаются НИОКР-ами, а не линейной разработкой. Он не заменяет 5 узких, он служит им дополнением (тут вопрос спорный, кто кому служит дополнением), чтобы все что делают пять узких могло нормально работать в комплексе.
Как бы главные архитекторы для этого и придуманы, разве нет? Разве что сама сфера узкая и соотвествующие специалисты разброснаы территориально. Вроде того чувака, который по удаленке отлаживал свой код на реальной железке.
Советская экономика учила кучу инженеров, трудоустраивала их (пусть и за хлеб с водой, попутно гоняя «на картошку») и большинство было довольно.
Советская экономика трудоустраивала по принципу «обязаны дать работу всем». Из-за этого отделы были раздуты, в реальности в отделе инженером могло быть только парочку человек, а остальные — просто с дипломом. Конкуренции полноценной не было. И результаты труда тоже не требовались конкурентные. В результате неэффективные структуры, которые спокойно можно посылать на картошку.
Сейчас же рынок инженерных специальностей значительно схлопнулся, а количество выпускающихся меньше не стало.
За счет массового внедрения компьютеризации, а так же из-за того, что парочку внятных инженеров сделают больше, чем десятка-два никаких. Вот только в бизнесах так же не хватает шарящих людей.
Пример из мебели, в глубинке: два человека из 6 делали больше половина объема индивидуальных заказов мебели каждый месяц. Причем когда я пришел и начал там автоматизировать и внедрять новую версию ПО, то в результате оформление упростилось в разы. Но расклады по объемам изменились мало. Более того, из кучи людей, что там работало до и после — кроме меня и этой парочки ударников труда никто вот вообще не задумывался над упрощением и автоматизацией. Всем было поооофиг. Найти не пофигистов — практически не реально…

Сейчас друг сменил мебельную фирму (уже про Мск). Сделал во второй месяц заказов на зп выше сотки, сотрудник, который работал ещё до него — тысяч на 40-50. Мой друг причем оказался при этом еще и недозагружен. Да и количество ошибок при этом относительное меньше имеет. Угадайте, кстати, кто из них номинально старший в отделе?

В бизнесе есть запрос на тех, кто может развиваться, а не сидеть на попе ровно. Этому в вузах действительно не обучают.
учила кучу инженеров,


Есть подозрение, что кучами лежат отнюдь не бриллианты. Да и орлы стаями не летают. А значит, 120рублевые инженеры в массе своей были инженеграми, пригодными только для распивания чаев и чего покрепче (сужу по рассказам тех, кто в советские времена в «Алмазе» работал — на отдел человека 4, которые тему тянут, остальные балласт для картошки)
«Любите меня, я подарок» — с такой позицией приходит кто угодно, и вчерашние студенты и бывшие сотруднии крупных компаний. И я бы не сказал, что кого-то из них явно больше. Если соискатель к вам не пошел, это означает, что он получил более выгодное предложение от другой компании, а не то, что у него завышенные ожидания, и он остался сидеть на диване ждать офера из гугла.
Вот вы знаете, профессионалы и эксперты почему-то склонны в себе постоянно сомневаться и исходя из этих сомнений расти, учиться, экспериментировать. А вот молодые специалисты прекрасны априори — сомнения в сторону, яжпрограммист.
Эксперт эксперту рознь. ЧСВ как бы никто не отменял.
А нам за ЧСВ бонус доплачивать? :-)

Это я к тому, что сомнения в качестве своей работы и способность себя рационально оценивать не совсем коррелируют с "профессионализмом" и "экспертностью". Более того, у начинающих программистов обычно для этого оснований меньше, чем у уже 10-летних senior'ов, которые вроде как матерые ребята и все в это жизни видели.

Это же рынок. Не доплатите вы, доплатит кто-то другой.
а может и никто не доплатит, и эти специалисты будут жаловаться что работы нет(тм)
Значит, не так уж нужна работа.
Это же рынок.
Самые базовые понятия экономики, не нужно объяснять, надеюсь?
А потом вот эти люди устраивают программисту классическое собеседование с просьбой продать ему ручку, и оценкой социальных качеств. (и не говорите что вы не такие, не раз видел ситуацию когда берут человека с харизмой вместо знаний, и потом плачут… )
А как собеседовать джуниора только что выпустившегося из института без каких-либо знаний? За огонек в глазах и берут. Сам так делал, а как его еще оценить?
Не такие. Трюк с ручкой — устаревший хлам. Собеседование у нас больше похоже на разговор + рабочая часть (техническая или коммерческая), без социальных тестов и прочей фигни типа «подловить на чём-то». И да, огонёк в глазах что-то да значит.

К сожалению, на практике это людям без ЧСВ недоплачивают)

Если вам специалист таки нужен, а вакансия уже полтора года незакрытая висит — то наверное таки да. Доплачивать за ЧСВ и тщательно холить и лелеять.
Вообще-то не мне вас учить бизнесу, раз вы что-то таки продаёте, но ИМХО — у вас какие-то вредные шаблоны в голове. В комментариях неоднократно мелькали фразы: "вам шашечки или ехать", "рынок труда, а не ваше мнение, диктует цену" и тому подобные. Но вам как об стенку горох: вынь да положь готового перспективного спеца, согласного работать на устаревших технологиях, а ВЫ к тому же ещё и хотите решать — сколько платить и как часто повышать ему з/п.
Хочется спросить — у вас там капитализм уже или всё ещё советская власть?

Очевидно:


  • работодатель считает "раз технология вышедшая из моды, то можно платить меньше", забывая о том, что речь не о пенсионере на старом заводе, который хочет дотянуть там до пенсии, и который уже ничего нового учить не станет
  • работник видит, что если он будет работать на Java или C#, то он и через пять лет будет востребованным высокооплачиваемым работником, а если будет работать на Delphi, то через пять лет он рискует оказаться невостребованным
    => работник согласится работать на Delphi, только, если ему за него будут платить не меньше, а БОЛЬШЕ, чем за модные Java и C#, потому что только в этом случае будут покрыты будущие возможные риски связанные с перспективами на востребованность через несколько лет.
Абсолютно согласен, люди прогнозируют свою будущую востребованность. Именно поэтому 10 лет назад ушел с Delphi
10 лет назад ушел
а он бац Ж-) и всё ещё жив
Как там у А.C.? «Вздыхать и думать про себя»?

P.S.
Он уважать себя заставил И лучше выдумать не мог.
Он жив крайне мало где. Вот как раз в таких конторах, которые годами пилят один и тот же софт с одними и теми же фреймворками, одними и теми же людьми.
Раз выходят новые коммерческие версии и есть Free Pascal,
то жив как технология

жив крайне мало где
А Ваша выборка в терминах статистики репрезентативна?

Э.Дейкстра писал, что язык программированиия должен быть
способен заточить карандаш ( и не быть тупым топором)

Так вот, если перочинный нож выполняет свою задачу — то что?

Или кузнецов возьмём: ну не скучно им
Если я приду на собеседование и начну сомневаться в себе, то итог абсолютно предсказуем.
если честно говорить: «не знаю»/«забыл» и тд — то это повышает шанс приема на работу
Это не так. Я проверял :)
Значит у нас разнится опыт, потому что я тоже проверял)
С какой стороны вы проверяли? Тут без подробностей частный случай рассматривать как кальку общего нельзя:)
Никогда не стеснялся честно признать, что не знаком с предметом про который меня спрашивают. Три раза подряд трудоустраивался, три раза подряд не стеснялся признаваться в незнании, три раза подряд это не помешало, и предложение я получил(два раза принял)
Это зависит от того на сколько толковый попадется работодатель.

Есть большая разница между фразами "я не знаю" и "я не знаю, но думаю что должно быть вот так". Разница как раз в том, что во втором случае у человека есть фундаментальные знания (бэкграунд), он в итоге может решить проблему или хотя бы знает куда копать.

Сошлюсь на обратный «эффект Даннинга — Крюгера», так что есть вероятность, что как раз «профессионалы и эксперты» будут в итоге получать меньше.
Вот вы знаете, профессионалы и эксперты почему-то склонны в себе постоянно сомневаться


Как-то рассказывали о кандидате на должность программиста в крупную it-компани: «Сегодня приходил парень, вроде нормально рассказывал, но жутко неуверенный в себе. Не взяли, неуверенные нам не нужны».
С другой стороны, думаю, что если бы отвечал отлично, то взяли бы не смотря на неуверенность.
Вы пишете про устаревшие учебный планы, и ищете программиста на почти умершем Delphi. Повеселило :-)
Выбираете шутки за 300? :-) Delphi — мощный язык, который позволяет писать крутой бизнес-софт, например, известную систему SAP. А ещё кучу игр, средств разработки, промышленного софта и т.д. И Embarcadero свои продукты отлично развивает и лихо на них зарабатывает — ввиду востребованности крупными разработчиками.
Он довольно низок в рейтинге языков и, скажем так, в целом не обладает рядом хоть каких-то удобных фич, которые бы мотивировали на него перейти. Более того, delphi еще и не кросс-платформенный, а значит разработка обязательно под Windows.

Я оставил delphi очень давно, так как, скажем, до сих пор не очень понимаю, чем он лучше для разработки, чем тот же C#, если говорить про Windows.

Апелляция к legacy системам, которые писать давно тоже не катит, так как на C#, Python, Java, C++ и еще куче языков тоже пишутся серьезные вещи и вполне успешно.

Но ведь Delphi таки кроссплатформенный. Довольно давно уже есть все возможности для разработки под MacOS, iOS, Android. А с не давних пор присутствует и LLVM-компилятор для Linux.

C# таки уже тоже кроссплатформенный. Именно потому, что он не вымерший и его развивают. .Net Standart, .Net Core, Xamarin, Mono и т.п.

Может оно и так. Но в индексе, которым постоянно попрекают Delphi позиции шарпа за последнее время сильно поиссякли. И это всё не взирая на кроссплатформенность и открытие сырцов:
www.tiobe.com/tiobe-index/csharp
Так что вопрос о вымирании открыт. Прогноз отрицательный. Если так пойдет дальше то скоро он 'догонит' Делфи в индексе :)
Делфи же, как говорится, со стабильным прогнозом, висит на своём, почетном, десятом, месте десятилетиями:
www.tiobe.com/tiobe-index/delphi-object-pascal
А в последнее время еще и поднялся.
Отлично вы цифрами манипулируете:
Лучше посмотрите сюда:
www.tiobe.com/tiobe-index

Во-первых C# — 4.8% от рынка разработки, а Delphi — 1.8%. Получается только исходя из этого можно сказать, что для шарпеев рабочих мест в 2-3 раза больше. Прибавьте сюда 2% от VB.Net (который родной брат C#-а и разница только в синтаксисе — т.е. переучиться максимум 2 недели).

По поводу взлётов и падений — вот Java уже много лет на первом месте, но за последний год потеряла аж 5% (т.е. больше чем весь C# целиком). Думаете это значит, что джаву не стоит учить?! Что в C#, что в Java кода написано столько, что ещё очень надолго хватит, да и для Enterprise — продуктов пока ничего лучше не придумали…
Кстати у мегапопулярного сейчас JavaScript — только 2% и 7ое место в рейтинге…
Я показывал тренды. А тренды, увы, далеко не в пользу шарпа.

Кстати у мегапопулярного сейчас JavaScript — только 2% и 7ое место в рейтинге

Вот и вопрос — настолько ли он мегапопулярен? Незанчительно выше Делфи по индексам :)
Я думаю это говорит о странном подсчете индекса tiobe.
Потому как судя по вакансиям, ну вы поняли.

Если рейтинг составляется по признакам использования (например, на основании упоминания на форумах), это может говорить о разных вещах:


  1. Вакансии на Дельфи не появляются в изобилии по причине превышенич спроса у соискателей над предложением работодателей (быстро закрываются)..
  2. Вакансии на Дельфи заполняются в основном не на открытом рынке, а "своими", "по знакомству".
  3. Дельфи применяется в основном не для разработки больших коммерческих проектов, а "для дома" или для автоматизации каких-то рабочих процессов своими силами (например, какой-нибудь ученый ваяет на нем специфические программы для особенной обработки своих данных.
  4. Что-то еще.

В какой пропорции оно может быть намешано — пес его знает

Методика расчета есть у них где-то на сайте. Можно посмотреть что и как. То, что индекс, очевидно, не коррелирует с количеством вакансий может указывать на то, что нельзя измерять популярность, полезность и необходимость языка одними только вакансиями. Стат. данные нужно очень внимательно изучать, иначе можно сделать соверешенно неверные выводы. Программистам ли это не знать? :)
Начнем с того, что хз что такое «популярность». И связано ли оно с кол-вом вакансий. Если у нас больше людей знают Х, чем нужно рынку, т.е. вакансий нет вообще — это популярность? Ну, ведь вон сколько людей им владеют.
( «не кросс-платформенный» — по-моему, уже «кросс»)

Т.е. Вы, SirEdvin, берётесь переписать работающий проект с Delphi на C#/C++ / etc.?
И какой видите срок окупаемости?

Таки уже да, к сожалению, сразу эту инфу не нашел.


Т.е. Вы, SirEdvin, берётесь переписать работающий проект с Delphi на C#/C++ / etc.? И какой видите срок окупаемости?

Как я уже сказал


Апелляция к legacy системам, которые писать давно тоже не катит

Проблемы легаси это проблемы легаси.

> Как я уже сказал

про то что Вы лично ушли с Delphi я читал,
про бизнес последствия — здесь не было, по-моему

Вопрос про окупаемость был скорее риторический:
навряд ли фирма автора поста считает переход окупаемым
Значит, фирме автора стоит сказать, что так и так, у нас legacy, а не делать вид, что delphi нормальный язык программирования, на котором стоит начинать что-то разрабатывать.
Или же привести другие разумные причины, почему все-таки нужен Delphi. Вот я не люблю Go, но мне понятно, почему на нем стоит писать. А почему стоит писать на Delphi?
( Go — начал читать, смотреть и т.д.)

> почему стоит писать на Delphi?

Мне лично Modula-2 нравился больше чем Turbo Pascal ( в своё время)
И Clarion больше чем Delphi

Но...

Доступной ( не за деньги, а поизучать) ADA для x64 нет,
Modula-3 — нет отладчика под Win, c Oberon — часто хотят отдельную(!) OS
И т.д. и т.п.

Выходит, Delphi «достаёт» ненужным ключевым словом «begin»,
но на практике кроме него и нет особо сред разработки языков «европейской школы»
Выходит, Delphi «достаёт» ненужным ключевым словом «begin»

А мне begin с end-ом в паскале и его производных как раз нравится.
Фигурные скобки не очень хорошо цепляются взглядом, в отличие от словесных скобок.

А мне begin с end-ом в паскале и его производных как раз нравится.
Фигурные скобки не очень хорошо цепляются взглядом, в отличие от словесных скобок
Да, это так и есть

Поясню про «излишние begin-ы»:

DECLARE 
   a number(3) := 100; 
BEGIN 
   IF ( a = 10 ) THEN 
      dbms_output.put_line('Value of a is 10' ); 
   ELSIF ( a = 20 ) THEN 
      dbms_output.put_line('Value of a is 20' ); 
   ELSIF ( a = 30 ) THEN 
      dbms_output.put_line('Value of a is 30' ); 
   ELSE 
       dbms_output.put_line('None of the values is matching'); 
   END IF; 
   dbms_output.put_line('Exact value of a is: '|| a );  
END; 


Это PL/SQL ( на ADA похож неимоверно)

смотреть Ж-) где ELSIF — находим там отличия от TP
«не вооруженным взглядом» Ж-)

Меньше «букв» — мелочь, а приятно Ж-)

с циклами нечто похожее

P.S. вот PL/SQL уж точно годится для «зарабатывания денег» в IT
Это встроенный язык Oracle
То, что вы не видите ряда удобных фич — не означает, что их нет. Ну как пример…

Для большинства языков access violation фатален и приводит к немедленному завершению программы. А на delphi — это всего лишь аппаратный exception, который можно обработать. К этому добавляются удобные конструкции try..finally и try..except.

В итоге, даже у новичка, access violation означает лишь отказ одной функции из сотни функций GUI-программы. Тогда как на других языках- это вылет приложения без сохранения данных.

А у профи… У меня северное приложение работает 15 лет в режиме 365 на 24.

Так что любую бизнес-задачу, разовый отказ которой грозит потерями миллиона рублей — есть смысл делать на дельфи. В том числе и CRM.
Для большинства языков access violation фатален и приводит к немедленному завершению программы. А на delphi — это всего лишь аппаратный exception, который можно обработать. К этому добавляются удобные конструкции try..finally и try..except.

В Java и Python — это вполне себе exception, который так же можно отловить через try ..except.


GUI абсолютно аналогично просто выдаст ошибку, если правильно написано, а не упадет все. Абсолютно аналогично работает и большинство веб-серверов на этих языках программирования, только один запрос вернет ошибку. Я более чем уверен, что C# работает абсолютно так же.

В Java и Python — это вполне себе exception, который так же можно отловить через try ..except.

Насколько мне говорили в java для этого нужно запускать с ключом.

Вы лучше приведите пример приложения (GUI или консоль), написанного не на дельфи (или дельфийском варианте С++), которое бы выживало после access violation. Ну хоть одно найдете?

Увы, Микрософт уже 30 лет не может сделать, чтобы ворд не падал при ошибке языкового чекера.

Веб-сервера работают на совсем иных механизмах восстановления. Там многопоточность и при ошибке поток просто падает. А при запросе ищется свободный поток. Если его нет — поток создается. Аналогично работает и chrome, причем у него вместо потоков — процессы.
Веб-сервера работают на совсем иных механизмах восстановления. Там многопоточность и при ошибке поток просто падает. А при запросе ищется свободный поток. Если его нет — поток создается. Аналогично работает и chrome, причем у него вместо потоков — процессы.

Простите, что? Попробуйте, например, flask. Там просто стоит отлов всех exception и их транслирование в запихивание ошибки в response, а само приложение не падает. И это все работает в один поток. Потому что python пробрасывает ошибку PyErr_NoMemor в случае чего.


Вы лучше приведите пример приложения (GUI или консоль), написанного не на дельфи (или дельфийском варианте С++), которое бы выживало после access violation. Ну хоть одно найдете?

Мммм… https://github.com/odoo/odoo? Вроде работает, даже если возникнут какие-то проблемы с выделением памяти, которые реально сложно получить.


Увы, Микрософт уже 30 лет не может сделать, чтобы ворд не падал при ошибке языкового чекера.

Проблема исключительно в том, что в Микрософт нанимают исключительно тех людей, кто может писать только отвратительные продукты. Корпоративная политика.

PyErr_NoMemor — опять софтверная ошибка. Аппаратные — access violation, stack overflow и так далее.

Проблема исключительно в том, что в Микрософт нанимают исключительно тех людей, кто может писать только отвратительные продукты.

Приятель, ушедший туда тимлидом, рассказывал обратное. Стоит ли спорить о вкусе устриц с теми, кто их ел?
PyErr_NoMemor — опять софтверная ошибка. Аппаратные — access violation, stack overflow и так далее.

Потому что runtime для python преобразовывает аппаратные ошибки для вас в софтверные. Или это плохо?


Приятель, ушедший туда тимлидом, рассказывал обратное. Стоит ли спорить о вкусе устриц с теми, кто их ел?

Не знаю, я сужу исключительно как потребитель.

Плохо — это непонимание, чем аппаратные исключения (внутрение прерывания)отличаются от софтверных ошибок. Курс по архитектуре процессоров проходили? Если да, то могу пояснить.

Как вы планируете получить такого рода исключение в языках, выполнение которых контролирует специальная обертка, как в случае с практически всеми новыми языками, да еще и так, что бы она не была перехвачена этой оберткой?

Знаете, если бы все писалось идеально, то нужды бы в этом механизме не было. Но обертки пишут люди, системные вызовы — тоже люди, даже JVM и JIT — люди, так что ошибки бывают.

А ещё бывают сбои памяти и процессора. И они приводят к тем же прерываниям. Особенно на разогнанных машинках. Или на не разогнанных, но случайно нагревшихся.

У нас даже процессор с отколотым уголком как-то был. Причем он работал, только пару раз в сутки вылетал. :-)

Смысл в том, что 365*24 — это 365*24 невзирая на все сбои. И именно потому delphi и применяется для такого рода систем. А CRM — это как раз 365*24.

365*24 достигается только кластерами, все остальное в целом от лукавого, так как у вас, например, может умереть сам сервер по разным причинам и аппаратное прерывание вам не поможет.

365*24 достигается только кластерами

Да

Плюс спец. железо ( т.е. лучше одновременно и кластер, и HW)
Ну да, но резервный сервер — это последняя линия обороны, а не единственная.

Но необходимая.
Если у вас нет резервного сервера, все ваше 365 на 24 не работает.


Отвечу вам тут же на предыдущий комент:


Как минимум — падающий сервер должен как-то предупредить резервный, что он уходит в даун. Ибо поднятие резервного по принципу мертвой руки — слишком медленно.

Нет, так это не работает. Падающий сервер не предупреждает о том, что он упал. Это резервный понимает, что другой сервер упал, потому что больше не выходит с ним на связь. Для отказоустойчивости вам не подходит решение "основной работающий и резервный, который иногда работает", вам подходит только кластер, где все узлы работают одновременно и падение одного из них не приводит к недоступности всей системы. И падение может произойти как угодно, вплоть до того, что какой-то криворукий админ выдернул шнур интернета у физической машины.


Если для построение отказоустойчивой системы вы надеетесь на хостовую систему, в которой запущено приложение, вы совершаете большую ошибку.

криворукий админ выдернул шнур интернета у физической машины.
Как все два шнура? Ж-)

P.S. Патч-кордов, как правило, минимум два
P.P.S. Отключение одно ( хотя бы и для работ) — штатное событие
P.P.P.S. Но всё равно — согласование сроков, план и т.д.

Ах, да: потому и обязательна система мониторинга,
что один шнур/диск не заметен, а когда уже «все» в down, тогда «поздно боятся, надо было раньше»

И инет не сразу, а через firewall
А тот тоже «в кластере» Ж-)
И не просто два патч-корда, а к двум физически разным сетям. Причем у нас ещё и на разных принципах (оптика и витая пара). И проложены они по разным коридорам. :-)
Резервный сервер необходим, не спорю. Но он не должен быть единственной линией защиты. Поднятие резервного сервера по принципу мертвой руки — слишком медленно. То есть само собой, что оно есть. Просто это тоже — последний резерв. А штатно — сервер перед перезапуском сервиса или ребутом закрывает соединения с клиентами и уведомляет резервный сервер о том, что ему надо стать мастером. В итоге задержка у клиентов — от 100 мс до пары секунд (если совсем не повезло). При переходе по мертвой руке задержка от 30 секунд.

криворукий админ выдернул шнур интернета у физической машины.

Интернет — чреват террактами и хакерами. На такого рода системах его нет. Даже клиентские машины изолированы от интернета физически. Только две собственных локалки.

Если для построение отказоустойчивой системы вы надеетесь на хостовую систему, в которой запущено приложение, вы совершаете большую ошибку.

Аналогично, если вы надеетесь только на одну линию обороны (резервный сервер) — вы тоже совершаете ошибку. Но, скорее всего, цена вашей ошибки мала, поэтому одной линии обороны вам хватит.

Аналогично у нас слабая защита от хакеров — только одна линия обороны: физическая изоляция от интернета. Если хакер устроился на завод — он сможет сделать всё. Но это уже к отделу кадров. :-)
Аналогично, если вы надеетесь только на одну линию обороны (резервный сервер) — вы тоже совершаете ошибку. Но, скорее всего, цена вашей ошибки мала, поэтому одной линии обороны вам хватит.

А подскажите другие линии обороны, которые бы помогли. Мне кажется, что если внезапно повреждается память на одной машине, вообще не важно, как упадет программа, так как все данные, кроме последней неудачной операции уже синхронизированы с другим сервером. Чем поможет вот эта возможность обработать повреждение памяти, если как уже указали ниже, это довольно сложно сделать правильно для всех случаев, и это решается другим необходимым средством?

А подскажите другие линии обороны, которые бы помогли.
2-3 версии программ. Если клиент своими запросами свалил пару серверов — даем ему предыдущу версию. Устойчиво роняет и её — даем ему заглушку примитивную lite-версию.

вообще не важно, как упадет программа, так как все данные, кроме последней неудачной операции уже синхронизированы с другим сервером.

Вот именно в этом и отличия ваших веб-серверов с АСУТП. У вас цена состояния сервера — ноль. Или почти ноль. А в АСУТП обычно это самое ценное. Потому у вас и упор на сервера, а в АСУТП — на робастность кода.
Чем поможет вот эта возможность обработать повреждение памяти, если как уже указали ниже, это довольно сложно сделать правильно для всех случаев
Тем, что это сильно быстрее и сильно дешевле полной отладки «до последнего бага». Для всех — не сделать. Для наработки на отказ 500 лет — сделали.

К вам тот же вопрос — насколько часто обнаруживаются баги в вашем коде? И что бы вы сделали, если бы вам надо было довести период между обнаружением багов до 10-20 лет?
2-3 версии программ. Если клиент своими запросами свалил пару серверов — даем ему предыдущу версию. Устойчиво роняет и её — даем ему заглушку примитивную lite-версию.

Звучит как что-то очень странное… А масштабировать не проще?


Вот именно в этом и отличия ваших веб-серверов с АСУТП. У вас цена состояния сервера — ноль. Или почти ноль. А в АСУТП обычно это самое ценное. Потому у вас и упор на сервера, а в АСУТП — на робастность кода.

Не ноль. Но вам все равно нужен кластер для отказоустойчивости. Не резервная копия, а кластер. У вас его нет, у вас нет отказоустойчивости. А если кластер позволяет игнорировать такого рода ошибки, какой мне толк от этого?


Тем, что это сильно быстрее и сильно дешевле полной отладки «до последнего бага». Для всех — не сделать. Для наработки на отказ 500 лет — сделали.

Как связаны баги с этим? Баги это в большей степени ошибки в логике, которые никак не коррелируют в тем, можете вы восстановится после повреждения памяти или нет.


К вам тот же вопрос — насколько часто обнаруживаются баги в вашем коде? И что бы вы сделали, если бы вам надо было довести период между обнаружением багов до 10-20 лет?

Уже вот предлагали всякие ADA и математическое доказательство правильности работы кода. Вот что-то из этого, вот только это работает на маленьких критически важных системах. В больших системах это не работает, и сделать там период обнаружение багов хотя бы 1 год уже что-то из разряда фантастики. Хотя с критическими багами то проще.

Звучит как что-то очень странное… А масштабировать не проще?

На самом деле не очень странно. Уж насколько мы обычно с Jef239 не согласны, но не здесь: иметь параллельно две версии системы, со старой и новой моделью — это разумно. Пропускать входные данные через два по-разному сделанных движка и смотреть, где различие, тоже разумно.

Даже когда второй движок медленный, и пропускается оно всё потом оффлайн.
Это имеет смысл в рамках отказоустойчивости? В духе, если упал новый, вернуть данные со старого?
Да. Новая модель, конечно, лучше, но старая лучше, чем ничего.
Скорее если от этого клиента упало два новых — роутить его на старый, пока программисты не исправят баг. Или в обслуживании отказать, пока он вам все сервера не уронил.

Рассматривайте клиента, уронившего вам пару серверов, как хакера, проводящего DOS-атаку. Так понятнее будет?
Звучит как что-то очень странное… А масштабировать не проще?

Проще, когда денюшки чужие. Давайте посчитаем. Клиент делает запрос, который валит ваш сервер так, что час восстанавливается копия базы. Клиент ждет ответа на запрос 1000мс, не дождался — новый запрос. Вам нужно как минимум 3600 серверов на одного такого клиента.

А если таких клиентов будет тысяча — то 3.6 миллиона по минимуму. За чужой счет — запросто.

А по уму — хватит счетчика падений, который переведет такого клиента на инстанс со старой версией. И её уронит — значит будет для клиента отказ в обслуживании.

Ну не бывает надежных систем, у которых есть единая точка отказа. А у вас единая точка — баги в в вашем коде.

Но вам все равно нужен кластер для отказоустойчивости. Не резервная копия, а кластер. У вас его нет, у вас нет отказоустойчивости.

Что значит нет? Судя по вики, у нас как раз кластер с теплым резервом.

Горячий резерв нельзя по простой причине. Представьте себе двоих за рулем одной машины. Как думаете, через сколько минут будет авария? У пилотов два штурвала, но управляет один: «отдал-принял», то же самое на тепловозе, причем с блокировкой — взял управление на себя, значит второго принудительно перевел в резерв.

Так что active-active — это путь к близкой аварии. Максимум что делается — две машины на одном тактовом генераторе со сравнением результатов работы процессоров после каждого такта. И вторая пара — в холодном резерве. Но это не персоналки, а контролеры со специальной архитектурой. Персоналки так не запустить.

А если кластер позволяет игнорировать такого рода ошибки, какой мне толк от этого?

Ваш кластер позволяет игнорировать лишь плавающие сбои. Если баг не плавающий — кластер вам не поможет. Ну разве что миллионы инстансов туда ставить. Чтобы пока одни клиенты валят инстанс за инстансом, другие могли бы работать.

Как связаны баги с этим?

Да все просто. Если багов нет, отказы связаны только со сбоями аппаратуры и тогда действительно лучше сразу передавать управление слейву, а потом выключаться. Персонал оповестит уже слейв.

А когда баги есть, то отказы — это прежде всего следствия багов. Стратегия «сразу упасть» может привести к тому, что баг повториться на всех машинах. Поэтому восстанавливаемся на трех уровнях, из которых лишь последний — резервирование серверов. Более того, если мы начали слишком часто переключаться между серверами, то ещё и деградируем в отдельных местах. Тот кусок, где работает код, созданный моим собственным компилятором, он просто автоматически отключается.
Вот что-то из этого, вот только это работает на маленьких критически важных системах. В больших системах это не работает

Можно ваш критерий большой системы? Ну вот на ПАК ФА — 4 млн строк кода, это какая система? Наша — видимо маленькая, 135 тысяч строк.
сделать там период обнаружение багов хотя бы 1 год уже что-то из разряда фантастики.

Обнаружения или проявления? У нас период обнаружения бага — порядка месяца, проявления (влияния бага на функции системы) — по рассчетам порядка 500 лет. При этом всякие опечатки в логах я считаю за баг.
Клиент ждет ответа на запрос 1000мс, не дождался — новый запрос.

Клиент напрямую из своей кривой приложухи шлет запрос и эту приложуху вы никак не можете поменять? Звучит очень печально.


Что значит нет? Судя по вики, у нас как раз кластер с теплым резервом.

Мне казалось, что у вас автоматического failover нет по словам "когда падает, должен кого-то уведомить". Я ошибся?


А когда баги есть, то отказы — это прежде всего следствия багов. Стратегия «сразу упасть» может привести к тому, что баг повториться на всех машинах.

Так при повреждении памяти вам все равно нужно падать, потому что альтернативное поведение, когда вы продолжаете работать с поврежденной памятью как бы ни разу не лучше. Вы же не восстанавливаете и не анализируете состояние всей памяти, а только перехватываете и продолжаете работу. Или я запутался и неправильно вас понял?


Можно ваш критерий большой системы? Ну вот на ПАК ФА — 4 млн строк кода, это какая система? Наша — видимо маленькая, 135 тысяч строк.

Покатит любая система, которая используется больше чем 2 людьми и позволяет делать больше чем две задачи. Разумеется, определение с головы.


У нас период обнаружения бага — порядка месяца, проявления (влияния бага на функции системы) — по рассчетам порядка 500 лет.

Интересно, а как вы это подсчитали? Вот я у вас новый программист и вы мне дали кусок задачи. Например, по работе с датами, будем надеяться они у вас там есть. А так как я криворукий парень, то взял и написал код, который подставляет неправильные даты. И потом эти даты пошли клиентам, в базы данных и везде. Или от такого вы тоже как-то страхуетесь? Не можете же вы вводить новую версию ПО целых 500 лет полностью.

Клиент напрямую из своей кривой приложухи шлет запрос и эту приложуху вы никак не можете поменять? Звучит очень печально.
Ваш клиент из вашей приложухи шлет запрос вашему серверу. А сервера падают. Или хакер умышленно роняет ваши сервера один за одним.

Мне казалось, что у вас автоматического failover нет по словам «когда падает, должен кого-то уведомить». Я ошибся?
Ошиблись. Failover по принципу мертвой руки есть, но тормозной — то ли 15, то ли 30 секунд таймаута. Слишком уж было боязно, что 2 системы одновременно станут работать.

Так при повреждении памяти вам все равно нужно падать, потому что альтернативное поведение, когда вы продолжаете работать с поврежденной памятью как бы ни разу не лучше.
При каком повреждении? Физическом? При физическом повреждении получим столько AV, что точно упадем.

А логическая порча памяти обычно не обнаруживается очень долго. Ошиблись на единичку, записали в другой элемент массива — вот и порча. И как вы это поймаете? Да никак. Только тесты + вычитка кода.

У AV, как правило, причины не в порче памяти. Большинство AV — это обращения через нулевой указатель. То есть пропущенная проверка на NULL.

Ну как пример — в дельфи при исключении в конструкторе вызывается деструктор. И этот деструктор должен понимать, что объект недоконструирован. А иногда — не понимает. Вот и появляется AV.

Use adter free у нас практически нету, ибо используется FreeAndNil.

Так что реально есть две ситуации: AV единичный и AV постоянный. Ко второму типу относится и ваша любимая глобальная порча памяти.

А вот что-то среднее — редкость. Это надо так попортить память, чтобы не задеть структуру кучи (она проверяется), не сломать инварианты (они постоянно проверяются), но сломать ровно 1-2 указателя. 3 сломали — будет 3 AV, выйдем на следующий уровень защиты. Указатели не задели — значит AV не будет.

Чувствуете, насколько это редкая и специфичная проблема?

А так как я криворукий парень, то взял и написал код, который подставляет неправильные даты. И потом эти даты пошли клиентам, в базы данных и везде. Или от такого вы тоже как-то страхуетесь?
Угу, физическим недопуском криворуких к коду. :-))) Систему писали 4 зубра (пятый зубр генерил идеи), один из них придумал потом идею языка Котлин, другой — потом написал Auslogics Registry Defrag … Ну в общем криворуких там не было.

Интересно, а как вы это подсчитали?
Потолочный расчет тут.

Не можете же вы вводить новую версию ПО целых 500 лет полностью.

Переведите, плиз?

Если вы имеете ввиду время между релизами, то, пардон, как часто вы обновляете ПО в стиральной машине? А в микроволновке? Купили — и работает. Помрет со смертью железа.
Большинство AV — это обращения через нулевой указатель. То есть пропущенная проверка на NULL.

И тут мы пришли к тому, что то, что вы в delphi делаете через отлов AV, в других язык является софтверным исключением. То есть им банально не нужен отлов AV, потому что повреждение памяти самой программы runtime не допускает, а с внешними проблемами никто не может помочь.


Потолочный расчет тут.

Самая большая проблема с вашим расчетом в том, что цифры взяты с потолка в большинстве случаев. Занижены они или завышены в целом не важно. Тот же "а у нас багов не было месяц" — это не о чем. Вот я тоже написал простого чатбота, так он проработал 3 месяца без багов, а как только я начал разрабатывать его дальше, так баги и посыпались. Или у вас только минимальные правки без каких-то там рефакторингов, оптимизации работы и прочего?


Угу, физическим недопуском криворуких к коду. :-))) Систему писали 4 зубра (пятый зубр генерил идеи), один из них придумал потом идею языка Котлин, другой — потом написал Auslogics Registry Defrag … Ну в общем криворуких там не было.

ну окей, не криворуких, там у кого-то из разработчиков большая запара, случилось что-то и тут нужно срочно что-то пофиксить. Вот и получается такое. Человеческий фактор то все равно работает.


Переведите, плиз?

Если вы имеете ввиду время между релизами, то, пардон, как часто вы обновляете ПО в стиральной машине? А в микроволновке? Купили — и работает. Помрет со смертью железа.

То есть ваш продукт вы не обновляете? Ну и современные штуки таки иногда обновляются :)

И тут мы пришли к тому, что то, что вы в delphi делаете через отлов AV, в других язык является софтверным исключением

Смотря в каких. В С++, например, будет аппаратное исключение. А вообще-то для нашей схемы ничего не меняется, она одинаково работает для любых исключений.
То есть им банально не нужен отлов AV, потому что повреждение памяти самой программы runtime не допускает, а с внешними проблемами никто не может помочь.

Самое важное — что никто помочь не может. Это означает, что отказоустойчивый софт на них лучше не писать. Это азы АСУТП — при любом сбое в безопасное состояние. Даже если электричество пропало — все равно будет безопасное состояние. Оно для этого специально как 0 кодируется. Софт должен реагировать на максимальное число проблем. Аварию по питанию, насколько помню, я тоже ловлю.

Или у вас только минимальные правки без каких-то там рефакторингов, оптимизации работы и прочего?
Какие правки? Вы о чем? Это АСУТП. Вначале опытная эксплуатация, потом опытно-промышленная, потом промышленная. Если мы делаем правки, то по ГОСТ должны опять проводить предварительные испытания, опытную эксплуатацию, потом приемочные испытания… Правки минимальны и втихаря, то есть неофициально.

Сервер правили один раз. Сервера там были на Pentium-III 300 Мгц под WIN NT 4. В некоторый момент там сменили и машины и ОС. Поскольку машины поставили двухпроцессорные, то перекомпилили сервер (там был ifdef на однопроцессорную и многопроцессорную конфигурацию, для однопроцессорной у нас была своя быстрая критсекция).

Клиента обновили, когда вводили второй экземпляр системы на соседний стан. И потом ещё раз — была мелкая проблема с новой windows.

Вот и получается такое. Человеческий фактор то все равно работает.

Так от «у нас готово» до «система сдана» минимум год проходит. Ну минимальные сроки опытной и опытно-промышленной эксплуатации — по полгода.

Это как надо логирование писать, чтобы такой жирный баг за год в логах не увидеть?

То есть ваш продукт вы не обновляете? Ну и современные штуки таки иногда обновляются :)

Ну а кого вы обновляли? Стиралку? Микроволновку? Холодильник? Телевизор? Лифт? Автомобиль? Не было желания двигатель в машине поменять? Или в телевизоре конденсаторы обновить? :-))))

А главное — зачем? Бесплатной работы вам хочется, что ли????

Это заказная работа. Нам заказали систему — мы её сделали. Дальше — гарантия, после неё только авторский надзор.

АСУТП проще рассматривать как устройства (приборы), а не как софт. Вот сделана железка — и работает.

Не, конечно бывает, ползучая модернизация, но там софт меняется вслед за сменой железа. Но это делают сами заводчане. В очень веселом режиме — раз в месяц ППР — и у всех трое суток без сна. И два часа на отладку, когда на выходе из ППР идет плановый брак.
Проще, когда денюшки чужие. Давайте посчитаем. Клиент делает запрос, который валит ваш сервер так, что час восстанавливается копия базы. Клиент ждет ответа на запрос 1000мс, не дождался — новый запрос. Вам нужно как минимум 3600 серверов на одного такого клиента.

А и не всегда поможет — положил 2 сервера из-за ошибки, положит и 10, и 3600.
Не совсем так. Если иметь серверов больше, чем время восстановления, деленное на время между фатальными запросами, то поможет. Но это огромные расходы, вместо 1 сервера на тысячи клиентов — тысячи серверов на одного клиента.

Лучше понимать, что из-за бага DOS-атака может придти и со стороны валидного клиента. Ну и принимать меры
Не, ну конечно, если рассматривать это с точки зрения времени восстановления, то да. Но я говорю с позиции «абсолюта», худшего случая. Пусть у нас сть клиент, очень часто генерирующий запросы, выводящие сервер из строя. Откат в рабочей версии — продолжение работы с гарантией. Просто перенаправление на другой сервер, который так же упадет — нет.
Согласен. Если стоит цель — дать ответ такому клиенту, то нужно или переключение на старую версию кода или обработка ошибки с деградацией функциональности. В идеале — и то и то.
предлагали всякие ADA и математическое доказательство правильности работы кода
Даже и не ADA, а подмножество ( SPARK)

И скорее, констатировал факт: идеи Э.Дейкстра потихоньку «идут в ход»
Смысл в том, что 36524 — это 36524 невзирая на все сбои.

Автоматический перезапуск после падения можно настроить независимо от языка.

Исходя из ветки обсуждения их Delphi умеет чуть ли не железо воскрешать
Воскрешать — не умеет. Умеет иногда корректно завершаться на сдохшем железе.
И??????

И автоматический перезапуск, и дублирующий сервер — это всего лишь резервная линия обороны. Как единственная линия — они не годятся.

Как минимум — падающий сервер должен как-то предупредить резервный, что он уходит в даун. Ибо поднятие резервного по принципу мертвой руки — слишком медленно.

… но необходимо. Потому что у основного сервера могла уборщица провод выдернуть шваброй.


Но на тот случай когда вам нужно повышение скорости реакции хотя бы в некоторых случаях — есть std::set_terminate.

Необходимо, конечно. Уборщики у нас провод не выдернут (сервер в шкафу, электропитание — под фальшполом), но винчестер может тупо сдохнуть. Или БП сгореть.

std::set_terminate — Да, полезно, если на Си пишем. Ещё полезней — сигнализировать из батника после завершения (если это возможно).

На дельфи чуть лучше — любое нештатное завершение идет через исключение. И ловится до отработки финализации модулей. Лучше именно тем, что запихавши слишком многое в set_terminate можно и не завершиться. А полноценный контроль ошибок в нем не сделать — потеряна информация о том, что живо, а что нет.

А у нас процесс ловли ошибок многоуровневый. И деградация многоуровневая. Не справились на одном уровне — провались дальше, на более простой и грубый уровень.

Я бы осторожно сказал, что возможность удобно перехватить segfault как исключение ещё не делает язык более пригодным для высоконадёжных систем. Вот я не могу сходу придумать солидный пример, когда надёжнее попытаться восстановиться после аппаратного исключения. Вот вы его словили, и как вы хотите продолжать работать? У вас на руках система в неконсистентном состоянии, вполне возможно с повреждённой памятью, она себя дальше может повести непредсказуемо. Исключение полезно тогда, когда вы можете на него отреагировать каким-то осмысленным способом, а попытка восстановиться после чего-то неизвестного, много чем чревата.

Самое интересное,
что «ADA-Linter на Prolog-е» ( см.здесь же детали) обработать программу с исключениями не может.

Т.е. исключения всё-таки слегка «припудренный»/облагороженный, но GoTo
Ну тогда и continue и break — это goto. И if вместе с for — тоже goto. Собственно этим и хорош Си — понятно, во что он транслируется.

P.S. Ссылочку с деталями дайте, все-таки.
(
Ссылочку с деталями дайте, все-таки.
Если про SPARK, то здесь приводил парочку.
Жаль, что с какого-то момента — некоторые цитаты всё-таки в google придётся искать Ж-( Sorry / виноват, каюсь
В оправдание: реально где-то в правилах было, что внешние URL не приветствуются
)
этим и хорош Си — понятно, во что он транслируется.
Так и Modula-2 понятно во что. Идёшь step by step в Topspeed отладчике и Assembler изучаешь Ж-) ( в отдельном под-окошке)

continue и break — это goto
Да ( в точности так же, как и исключения см. далее )

if вместе с for — тоже goto
а вот и нет Ж-)

Ведь борьба Э.Дейкстра &Co с Goto началась для того,
что бы программу можно было читать сверху вниз
( без бесконечной перемотки полотна распечатки)
и доказывать блок за блоком её верность

Сам по себе GoTo на уровне машинных кодов никому не мешал и не мешает

Поэтому: моё «это же goto» просто читаем как «делает программу сильно не очевидной» Ж-)

P.S. Break активно использовал при обработке событий — без него можно, но как-то совсем уж мутно Ж-)
Вот теория и практика — расходятся Ж-)
Кому как. Я привык, что из любой строки может вывалиться исключение. Это заставляет жестче относиться к порядку операторов.

Увидеть гонку — намного сложнее. Даже на двух тредах, а уж если их больше…
Исключения и их альтернативы в Go вовсю обсуждалось
И как раз к альтернативам склонились

> Увидеть гонку — намного сложнее.

О, как раз и на эту тему появился инструмент,
который доказывает как теорему, что с блокировками и т.п. «всё в порядке»

Входной язык — один в один как у Э.Дейкстры ( if/fi, do/od и семантика )
В го исключения переименовали в панику, рекомендовали паттерн «код возврата» (на интерфейсе Error), после чего гордо заявили что «исключений у нас нет».
Можно ссылочку на альтернативы? А то я GO так и не изучил.
Можно ссылочку на альтернативы?

Кажется, именно здесь на Хабре и читал про Go

плюс Bonart точно описал и мои впечатления:
«код возврата» (на интерфейсе Error), после чего гордо заявили что «исключений у нас нет».
Правда в Go функции могут возвращать несколько значений,
а слева от "=" могут быть несколько переменных.
В одну из них попадает код ошибки и далее «классика жанра»: CASE Errorcode
А ловля аппаратных исключений?
А ловля аппаратных исключений?
В Go — см. в ответе Bonart про «панику»

От меня: к концу обучения выяснилось
что в Tubo Pascal можно всякие деления на ноль обрабатывать как код ошибки:

{$I-}
x:=y/0
{$I+}
If IOResult() then обработка

( Плюс и минус в директиве компилятора мог и перепутать местами)

Юмор ещё и в том что основное назначение {$I+}
— обработка при открытии файлов

А я-то про сперва рассчитывал знаменатель, проверял что бы был «не ноль»

Сказал про себя — эх, знать бы на первых курсах Ж-)
Теория структурного программирования одобряет переходы вперед-вверх.
Исключения — самый общий случай такого перехода.
Теория структурного программирования одобряет переходы вперед-вверх.
Исключения — самый общий случай такого перехода.

( У меня дома даже книга по ней есть,
но настолько детально не вычитывал — может и так Ж-) )

Сложности с закрытием файлов и возвращением ресурсов в «кучу» всё равно есть

и с этим:

Самое интересное,
что SPARK доказать правильность программы с исключениями не может.

тоже

Т.е., подход Go, похоже, довольно обоснован

Какой именно подход?
Исключения в го есть и успешно применяются, просто вместо throw-catch-finally у них panic-recover-defer


Самое интересное,
что SPARK доказать правильность программы с исключениями не может.

Это вообще не аргумент — код на исключениях превращается в код без исключений стереотипным добавлением информации об ошибке в результат.Собственно исключения возникли из кризиса обработки ошибок в классическом структурном программировании, когда на одну строку целевого кода надо добавлять по три шаблонного с отработкой косяков.
В го такое объявили самым лучшим способом — ну, видимо в его сфере применения задачи простые, а цена ошибки высока.
Вот только на фоне раста, где за пропущенную обработку по рукам бьет компилятор это каменный век.

Собственно исключения возникли из кризиса обработки ошибок в классическом структурном программировании
Может быть, в PL/1 они уже были
Как минимум словленное исключение дает возможность корректно закрыться. Ну то есть выключить то, что было включено. И тем самым — избежать аварии. Ну представьте автомобиль, который ушел в перезагрузку на скорости 120 км/ч? Ну явно безопасней выключить двигатель, включить тормоза, а уж потом — перезагружаться.

У вас на руках система в неконсистентном состоянии, вполне возможно с повреждённой памятью, она себя дальше может повести непредсказуемо.

Если в системе есть баги, то она в любой момент может повести себя непредсказуемо. Согласны? Ловля AV лишь увеличивает эту вероятность. По опыту — увеличивает несильно.

Пример по текущему проекту на С++. За 7 лет был пяток порчей памяти, ни один из них не проявлялся как AV. За те даже годы было полсотни AV — ни один из не привел к порче памяти.

На Дельфи — на сотни AV лишь несколько из них были вызваны порчей памяти. Все, кроме одной — были локальными, то есть касались лишь одного запорченного объекта. Одна — запортила структуру кучи.

И что я делаю не так? :-)
На самом деле я знаю, что я делаю не так — я не использую STL и шаблоны. И вообще пишу на Си с мелкой примесью С++.
На дельфи — постоянные assert и проверка инвариантов.


А какая у вас статистика? У вас есть конкретные данные, кроме опасений? Сколько раз вы ловили AV и сколько раз была порча данных помимо того, объекта, который вызвал AV? А сколько этих глобальных порч данных оставили живой структуру кучи? А структура кучи — это то, что проверяется при любом аппаратном исключении. В смысле мной проверяется.

Мы сидим на Java и хостимся на облаке, так что у нас все отказы — либо аппаратные, либо связанные с исчерпанием системых ресурсов. И выглядит это так: машина тупо виснет и не реагирует ни на что.


active-active либо отдельный хост в виде супервизора — единственный рабочий вариант.

Давайте проанализируем:

  1. Вы на облаке, и цена инстанса мала
  2. Состояние сервера имеет малую цену
  3. Зависший запрос имеет малую цену.
  4. Полный отказ системы имеет малую цену
  5. Время переключение между интансами мгновенно

Поэтому вам хватило одной линии защиты. Скорее всего ваши сервера стоят в одной стойке (или вообще инстансы на одном физическом сервере). Ну о каком дублирующем дата-центре вы думаете.

Обычно в АСУТП:

  1. Цена сервера велика из-за стоимости аппаратуры сбора данных.
  2. Состояние сервера ценно
  3. Зависшая операция может вызвать катастрофу, вплоть до людских жертв
  4. Полный отказ системы фатален
  5. Время переключения между серверами — достаточно велико.


В итоге было выбрано 3 линии защиты: перезапуск подсистем (крупных объектов), перезапуск систем (тредов), перезапуск серверов. Ну и само собой — сервера в разном помещении и запитаны от разных фаз.

У нас был выбор: полная отладка (100% к цене проекта и 10 лет) или защита от программных ошибок (30% к цене и примерно год).

Кстати, с какой частотой вы видите ошибки в своей системе? Мы приостановке отладки дошли до уровня «за месяц — ни одного бага».

Мы на облаке, и отказ любого узла не приводит к отказу системы. Всё продублировано и восстанавливается автоматически. На AWS с 50 хостами железо отказывает в среднем раз в месяц.


В целом это вопрос дизайна и технологий — отказ любого компонента НЕ должен влиять на работоспособность системы.


Но для производства, пожалуй, проще заплатить большие деньги производителю железа и инженерам, которые умеют строить выч. центры с заданной надежностью, чем полагаться на софт.

У вас сколько вариантов программы? Если один, то возможен запрос, который положит любой инстанс. То есть выдали пару сотен запросов — и положили всех.

Вторая единая точка отказа — пожар, цунами, падение самолета на ДЦ. Или вам облако гарантирует использование нескольких ДЦ одновременно?

Ещё раз повторю вопрос: с какой частотой вы видите программные ошибки в своей системе?

Для систем, подобных вашей — действительно, лучше дублировать сервера и ДЦ. Но единая точка отказа в виде бага в программе у вас все равно есть.

Помните баг с юникодом в сафари? Вот что-то вроде этого.

отказ любого компонента НЕ должен влиять на работоспособность системы.

А разве отказы клиентов вас не волнуют? Ваши клиенты имеют дублирования провайдеров, электропитания, компов???

Но для производства, пожалуй, проще заплатить большие деньги производителю железа и инженерам, которые умеют строить выч. центры с заданной надежностью, чем полагаться на софт.

Для АСУТП? В корне неверно. Представьте себе автомобиль, у которого управление газом и тормозами идет через облако. Чушь ведь?!

Вы не потащите 10 тысяч проводов в ДЦ. Значит — сериализация. А это — единые точки отказа вместо 10 тысяч отдельных точек. Дальше — проблемы с синхронизацией. Время отработки — обычно 20 мс, а одном из контроллеров — 4-5мс. Вы готовы гарантировать пинг в 1 мс?

Так что никто не тащит управляющий софт в ДЦ. Ни от автомобиля, ни от стана. Наоборот, его ставят максимально близко.

И ещё раз — с какой частотой вы видите программные ошибки в своей системе?

Похоже на взаимное недопонимание :-)


  • да, каждая программа развернута минимум в двух экземплярах. Все программы и клиенты, которые к ней обращаются, умеют по таймауту реконнект к другому экземпляру
  • да, облачные провайдеры позвлоляют размещать машины в независимых стойках, датацентрах и регионах
  • если клиент программы/сервиса может определить, что сервис сломан, он пойдет в другой экземпляр. Если не может (сервис выдает правдоподобный мусор), то плохо. Но я такого не видел никогда.
  • я неточно выразился, не отказ компонента, а отказ экземпляра компонента конечно же. Функционал системы в целом не страдает
  • я собственно именно это и имел в виду — когда есть деньги на надежное железо с инфраструктурой и стоимость отказов очень высока — проще купить стойку или несколько и поставить поблизости.

Про программные ошибки: JVM ОЧЕНЬ стабильна и убить её может только нехватка системых ресурсов или аппаратный сбой. Мы не пишем системы управления, так что все алгоритмические ошибки у нас воспроизводимые.

JVM ОЧЕНЬ стабильна и убить её может только нехватка системых ресурсов или аппаратный сбой.
Или баг в нативной библиотеке.

если клиент программы/сервиса может определить, что сервис сломан, он пойдет в другой экземпляр
Насколько быстро? Вот зависло TCP-соединение, через какое время клиент пойдет на другой сервер? Сделаете мало — будут проблемы при плохом инете. Сделаете много — тоже нехорошо. Потому и стараемся закрыть TCP-коннекции (точнее PIPE) штатно при отказе сервера.

я неточно выразился, не отказ компонента, а отказ экземпляра компонента конечно же.
Так у вас единая точка отказа в программном коде. Если есть воспроизводимый баг, работающий на определенных данных, то клиент сваливает все сервера, к которым он полез с этими данными.

И все-таки — с какой частотой вы видите программные ошибки в своей системе? Если раз в 20 лет — вам не нужны лишние уровни защиты. А если раз в неделю — то стоит подумать. Например — о автоматической деградации на предыдущую версию.

когда есть деньги на надежное железо с инфраструктурой и стоимость отказов очень высока — проще купить стойку или несколько и поставить поблизости.

Это вас не спасет. Один баг в программе и один клиент с кривым запросом. И все — все ваши сервера в постоянной перезагрузке.

Про то что винда конвертики аппаратные исключения в SEH вы тоже не в курсе

А RTL их обратно в сигналы перекидывает, не знали? Ибо стандарт у С/C++ такой.
Никто ничего не перехватывает, обработчики SEH(написанные вами или ещё кем) работают до конвертации в сигналы и то, конвертация в сигналы происходит не для всех типов исключений
И вот тут в игру вступает вопрос: а как приложение в юзерспейсе может поймать аппаратное исключение? Ответ один — никак. Его поймает ядро и пришлет сигнал приложению. Приложение же вольно обрабатывать сигнал как захочет. Или как позволяет райнтайм языка на котором оно написано. Если рантайм поймет SIGSEGV и завернет его в исключение языка — то в чем проблема?
А если рантайм не завернёт, то программист сам напишет для SIGSEGV хэндлер из одной строчки, бросающей то же самое исключение.
вы случайно веткой не ошиблись?
Да нет, вы там бравировали пониманием внутренней архитектуры процессора. Я вам намекнул что между вашем приложением и процессором находится ещё ядро, которое нивелирует вот такие тонкости работы процессора.
И заодно, что возможность запихивать SIGSEGV в структурные исключения — не уникальная фича Delphi.
Значит я так невнятно написал, что вы не поняли смысл. Суть в том, что факт наличия исключения No Memory ничего не говорит о том, что будет при AV — падение виртуальной машины или передача исключения коду.

я не знаток java, но беглый поиск показал, что скорее падение, чем выдача исключения.
Почему же у них такие отвратительные продукты?
Что именно? MS SQL? Visual Studio? Word? Отвратительным был Windows 95 (98, me), но он умер.
А Win NT вообще дело рук ушедших из DEC
Насколько мне говорили в java для этого нужно запускать с ключом.

Нет, у java это стандартный exception, который выглядит, например, так.

Вы путаете софтверные исключения с аппаратными. java.io.IOException — софтверный.

Который java пробросит, когда столкнется с проблемой выделение памяти.


Как в других случаях получить проблемы с памятью в java не прибегая к черной магии — у меня идей не было.

Нехватка памяти — тоже софтверное исключение. Вполне возможно, что в JAVA аппаратных исключений (вроде access violation) вообще нет.

А бывают они при вызове из JAVA сишного кода. Например, системных вызовов.
Вы лучше приведите пример приложения (GUI или консоль), написанного не на дельфи (или дельфийском варианте С++), которое бы выживало после access violation. Ну хоть одно найдете?

Я на прошлой работе выживающий после AV сервер писал на C#. Труднее всего оказалось этот самый AV вызвать, не получив вместо него скрытое повреждение кучи. Пришлось выделять неуправляемые буфера памяти через VirtualAlloc, окружая их защитными страницами. Но это были особенности используемой нативной говнобиблиотеки, сам язык перехватывать AV мне не мешал.

Ну что ж, запишем, что С# может. С переносимостью у него — не лучше, чем у дельфи. Со скоростью — чуть хуже, ибо вирт.машина. Но — может.

Вопрос лишь в том, есть ли у него полный комплекс для написания надежных программ. Но одна деталька есть — и то хорошо.

Деталек у него более чем нужно. Там и желанный вами try...finally есть, и желанный плюсовиками RAII (отягощенный необходимостью писать лишнее ключевое слово чтобы его включить).


И обработчик необработанных исключений есть куда поставить.


И про скорость я бы не говорил что заведомо хуже.

А выдача исключений при срабатывании assert?
А в чем, собственно, проблема?
Тоже верно.
Почему вы считаете, что C# плохо переносим? Потому что нужен Framework для работы программ? Зато программу даже перекомпилировать не нужно.

Ну и со скоростью тоже неверно. Во-первых, JIT-компилятор вполне себе генерирует нативный код, и не факт, что хуже, чем компилятор Delphi. Во-вторых, C# не используется для вычислений — какая разница, с какой скоростью работает программа, если она большую часть времени ожидает завершения операций ввода-вывода.
Потому что на embeded не пойдет. Судя по быстрому поиску — даже на Андроид/iOS его нет. Ну и в 512К на embeded он влезет? А в 64К?

какая разница, с какой скоростью работает программа, если она большую часть времени ожидает завершения операций ввода-вывода.

На 18 Мгц тактовой частоты — все иначе. И даже на 144МГц.
Судя по быстрому поиску — даже на Андроид/iOS его нет

Как это нет? Xamarin — это миф?


Ну и в 512К на embeded он влезет? А в 64К?

А на Delphi под такое можно писать?

Дельфи использует память примерно на уровне Си/C++. Так что под 64К писать можно. Но под MS-DOS на х86. Для FreeRTOS и прочего embeded его нет.
Ну это уже надо к FPC соответствующий кодогенератор прикручивать и вперед.
Кодогенератор там есть. Библиотека нужна.
Тем легче.
А под attiny с одним килобайтом памяти?
Ну тут или ассемблер или Си или форт с кросс-компиляцией.
А я ноктюрн сыграл на плюсах умудрялся писать. С RAII и темплейтами.
и темплейтами.

можно было добавить «и с мегабайтами комментариев».
Я потерялся в интерпретациях этой шутки.
Я имел в виду, что шаблон — это больше фича времени компиляции, а не выполнения.
Ну, есть определённые стереотипы, пусть и не безосновательные, что от темплейтов результирующий код раздувается.
А на Delphi под такое можно писать?

Если захотеть — вполне. Надо только ручками SDK/DDK сделать.
> Судя по быстрому поиску — даже на Андроид/iOS его нет.
ru.wikipedia.org/wiki/Mono
> Ну и в 512К на embeded он влезет? А в 64К?
en.wikipedia.org/wiki/.NET_Micro_Framework
Жавы, к слову, на iOS тоже нет. Увы, пока кросс-платформенность Java или, особенно, .net'а ограничена. В отличие от C (плюсов) или Pascal (Delphi).
Вот только кросс-платформенность ограничена бибиотеками, а не компилятором. Стандартная бибилиотека — неотъемлимая часть как .NET Framework, так и Java. В случае C++/Pascal вы можете не использовать библиотеку и получить компактный код. В случае C#/Java это невозможно by design, и это нормально.
> Жавы, к слову, на iOS тоже нет.
На macOS есть, а на iOS беглый гуглеж показал, что тоже реально:
software.intel.com/en-us/multi-os-engine
github.com/google/j2objc
docs.gluonhq.com/javafxports/#_overview

про .Net ссылки в предыдущем комменте.
Вопрос в том, сколько времени нужно, чтобы С# заработал на вашей собственной плате. Си начинает работать сразу.

Мы же про Windows для msvc есть try и except где можно поймать исключение втч и Access violation

Теоретически можно. Только всем важнее следование стандарту С++, чем надежность. Только на Delphi ловля исключений является правилом, ибо внесена в каркас фреймворка.
Вы лет на 20 отстали от реалей мира java.
Щито? Вы не можете рассчитывать на корректность состояния всего процесса после того, как там поток упал.
Ну так обычно в linux в этой схеме делают один поток на процесс. fork — вообще-то так и работает.
Там многопоточность и при ошибке поток просто падает. А при запросе ищется свободный поток. Если его нет — поток создается. Аналогично работает и chrome, причем у него вместо потоков — процессы.

То есть, тут надо везде вместо «потоки» читать «процессы», даже в последней фразе?
ну человек просто слышал что процесс и поток порождаются в ядре одинаково через clone через CLONE_THREAD. А про главное отличие процесса от потока(ресурсы и пр) забыл
Про наследование хендлов забыли? А про разделяемые регионы памяти? А про доступ к ним на RO? А про Copy on write? Насколько я помню, pthread_create может быть реализован как многими потоками в одном процессе, так и одним процессом на поток. Ну вот вам цитата (возможно устаревшая):
В Linux каждый поток является процессом, и для того, чтобы создать новый поток, нужно создать новый процесс.
Поскольку пишем переносимо, то в подробностях, как оно там в linux, я не разбирался. Сильно многопоточно приходилось только под windows писать.

Но в любом случае всегда есть возможность сделать регион памяти, который для шедулера был бы на RW, а для исполняющих потоков — на RO.
Между потоками адресное пространство шарится (и это самое важное, пожалуй, различие между ними и процессами), и один кривой поток вполне может попорить состояние всех остальных.
Шарится, но не всегда все и не всегда на RW. Можно покопать, как изоляция у того же хрома сделана. Формально у него процессы, фактически — скорее потоки.
никак, но можно минимальными средствами снять с себя юзеровый дамп(если озаботится кое-каким выделением памяти заранее при старте)
Для большинства языков access violation фатален и приводит к немедленному завершению программы. А на delphi — это всего лишь аппаратный exception, который можно обработать.

Это достоинство VCL, а не Делфи, что exception ловится на верхнем уровне приложения.
К этому добавляются удобные конструкции try..finally и try..except.

Извините, а вы, помимо Object Pascal, с другими языками, например, с Java, C++, Python знакомы? Это типовые инструкции языка, они сейчас есть везде.
В С++ конструкция try...finlaly? Учите матчасть, её там нет. Есть лишь в борландовом (дельфийском) расширении. А gcc/clang — опаньки.

Это достоинство VCL, а не Делфи, что exception ловится на верхнем уровне приложения.

Ничто не мешает сделать то же самое и без VCL (у меня — до 7 слоев изоляции). Главное — что выдается структурное исключение, а не signal.
Я что-то не могу придумать ситуации, когда бы в С++ потребовался try...finally)
Вагон таких. Описать? Вы думаете зря в MS VS++ вставили __finally?
Сюрприз, его вставили в MSVC чтобы можно было с типо-аналог деструкторами на C90 писать
Можно пруф?
Да, я бы честно не против описания хотя бы одной ситуации (без фамильярности и сарказма). Просто всё что ни приходит в голову, решается деструктором класса. Под любую задачу можно написать scoped-обёртку, которая финализирует любой ресурс.

Отвечая на вопрос про __finally. Боюсь, что это расширение языка ввели для того, чтобы «комфортно» писать на С++ под .NET.
В C++ Builder try...finally был введен, так как объекты классов из Дельфийской библиотеки нельзя было создавать на стеке, только оператором new.
Ну представьте себе, что у вас есть десяток локальных переменных, которые нужно анализировать в finally. Удобно вам будет создавать объект с десятком ссылок? В С++11 можно применить лямбду, а до него?

В конце концов — if, switch, while, do — необязательны. Все можно написать с использованием одного for. Но неудобно же!

А конкретная ситуация — «открыть А, открыть Б,… чтобы ни случилось — закрыть А, закрыть Б». То в RAll мы имеем пересечение времен жизни ресурсов. Извратиться — можно (как и с for). Но лучше — не извращаться.

Ещё ситуация — когда какой-то деструктор при некоторых условиях надо не выполнять. «открыть А, открыть Б,… чтобы ни случилось — закрыть А, если давления нет — закрыть Б, а если есть — не закрывать».

Чувствуете как это неудобно ложиться на RAll? И такого — навалом.

MSDN пишет так:

Оператор try-finally особенно полезен для подпрограмм, в которых в нескольких местах выполняется проверка на наличие ошибок, способных вызвать преждевременное возвращение из подпрограммы.

Ну и последнее, о чем уже писали. RAll плох тем, что ошибка в деструкторе вызывает std::terminate. finally избавлен от этого фатального недостатка.
В С++11 можно применить лямбду, а до него?

А до него уже семь лет назад было.

Ещё ситуация — когда какой-то деструктор при некоторых условиях надо не выполнять. «открыть А, открыть Б,… чтобы ни случилось — закрыть А, если давления нет — закрыть Б, а если есть — не закрывать».

Решается захваченными по ссылке флагами либо мувом объекта, зависит.

Ну и последнее, о чем уже писали. RAll плох тем, что ошибка в деструкторе вызывает std::terminate.

Только если ошибка возникает уже при раскрутке стека.
А до него уже семь лет назад было.

А проект уже проработал 15 лет.

Только если ошибка возникает уже при раскрутке стека.

Угу, но шансы, что она возникнет — приличные. То есть свои деструкторы можно написать так, чтобы выполнялись всегда и везде. А вот библиотечные (особенно STL) — упадут со свистом.
А вот библиотечные (особенно STL) — упадут со свистом.

Какие STL'ные деструкторы бросают исключения?
После AV — любые.
P.S. В смыcле вторичного AV. Пояснения нужны?
Идея рассчитывать на адекватность хоть чего-то после AV мне не очень нравится (и да, я читал ваши посты о защищённых страницах с дампами рядом).
Повторюсь — давайте вашу статистику.

А то такое впечатление, что вы тоже боитесь, что самолет на голову упадет.
Про плюсовые приложения только, ладно? На хаскеле-то вообще ничего не портится (кроме одного раза, когда я takusen дёргал, это байндинги к ораклу, исключительно паршиво сделанные).

Сколько раз у вас на проекте была порча памяти?

О, много. Очень. Не в проде, но в процессе разработки регулярно, увы.

Сколько раз порча памяти вызвала AV?

Почти в каждом случае рано или поздно программа либо сегфолтилась, либо входила в дедлок из-за нарушения инвариантов.

Сколько было AV без порчи памяти?

Тоже достаточно часто. В основном нарушения инвариантов и логики.
Почти в каждом случае рано или поздно программа либо сегфолтилась, либо входила в дедлок из-за нарушения инвариантов.

То есть ни одного незамеченного искажения данных не было? Даже несмотря на то, что специально не боролись?

Ну так после AV — просто проверяете данные. По инвариантам, по второй копии. Зачем бояться того, что не бывает?
То есть ни одного незамеченного искажения данных не было? Даже несмотря на то, что специально не боролись?

Было. assert'ы через строку, если сработало — надо падать вот прям щас.

Случаи, когда я по паре недель отлаживал, чего это они сработали, и само искажение происходило в совершенно другом треде, другом месте и полчаса назад, были.

Ну так после AV — просто проверяете данные. По инвариантам, по второй копии. Зачем бояться того, что не бывает?

Когда размер хипа процесса достигает двухста гигов, и вам нужно иметь гарантии ответа за 10-50 мс (при том, что обработка запроса занимает вот примерно ту самую нижнюю границу в 10 мс), у вас нет особо роскоши иметь рядом вторую копию и проверять данные. Вы вынуждены дизайнить систему так, чтобы она в этом случае падала, а обработку подхватывала другая нода. А на более высоком уровне — чтобы если вдруг все ноды от этого запроса упадут, ваши убытки были не сильно большими.
Было. assert'ы через строку, если сработало — надо падать вот прям щас.

Почти в каждом случае рано или поздно программа либо сегфолтилась, либо входила в дедлок из-за нарушения инвариантов.

Вам не кажется, что это взаимоисключающие параграфы?

Ассертами оно стало обкладываться уже после того, как я пришёл в проект. Ну и даже ассерты через строку не от всего спасают.

Так что нет, не кажется.
Вы что, продолжали выполнение после ассертов?
как может быть и ассерт и AV одновременно?
Не может. Я где-то написал, что вообще всё отлавливалось ассертами?
Когда размер хипа процесса достигает двухста гигов,

Гениально! Взять особенности своей задачи и потребовать, что я дизайнил совсем иную задачу ровно так, как вашу. :-))

У нас все лезло в 20 мегов. И размер того, что важно — меньше 64К, типично 1-2К.
Отличается-то оно не сильно: если на выходе комплекса лажа, то некоторое количество важных шишек будет сильно недовольно.
Сразу на пару ваших постов отвечу.
Отличается-то оно не сильно: если на выходе комплекса лажа, то некоторое количество важных шишек будет сильно недовольно.
Давайте сравним это с гибелью людей. Ну вот девочка погибла из-за нажатия на кнопку не по инструкции.

Зато объемы данных — копеечные. 10 тысяч битов (2 килобайта) — это гигантский объем. Это 10 тысяч датчиков, каждый из которых может сломаться. Обычный объем идет на сотни битов.

Ассертами оно стало обкладываться уже после того, как я пришёл в проект. Ну и даже ассерты через строку не от всего спасают.

Мой совет — закрывайте каждый баг минимум трижды. При каждом баге задайте себе вопросы:

  1. Что можно сделать, чтобы программа работала после этого бага? Какую деградацию применить? Какое восстановление?
  2. Как обнаружить этот баг поближе к точке возникновения? Как обнаружить всю серию подобных багов?
  3. По какой причине произошел этот баг? В каких местах кода могла произойти такая же ошибка?


Ещё очень помогает FreeAndNil. То есть принудительно обнуляйте указатель на любой удаленный объект.

Но я бы в вашей ситуации вообще бы завершался не только при ошибке, но и после каждого запроса.

Случаи, когда я по паре недель отлаживал, чего это они сработали, и само искажение происходило в совершенно другом треде, другом месте и полчаса назад, были.

Мда… очень запущено… Типичный такой С++.… На дельфи такое происходит реже, ибо меньше способов выстрелить себе в ногу. А какой размер кода? Может дешевле потихоньку переписать?

Кстати, это как раз тот случай, когда статанализаторы будут полезны.

Интересно, а вы понимаете, что у нас была совсем иная ситуация?
Что можно сделать, чтобы программа работала после этого бага? Какую деградацию применить? Какое восстановление?

Ничего. Ничего не надо. Проще и эффективнее оказывается дизайн, толерантный к падениям отдельной ноды.

Как обнаружить этот баг поближе к точке возникновения? Как обнаружить всю серию подобных багов?

Обкладываться ассертами на каждый чих, что я вскоре после прихода и начал делать.

Впрочем, это повезло, что требовательный к производительности код был достаточно локализован для того, чтобы ассерты во всех прочих местах не сильно били по производительности.

По какой причине произошел этот баг? В каких местах кода могла произойти такая же ошибка?

Потому что человеческий attention span ограничен, увы, а пропагандируемая вами вычитка непозволительна по ряду причин.

Ещё очень помогает FreeAndNil. То есть принудительно обнуляйте указатель на любой удаленный объект.

shared_ptr так и делает. Только а толку, если в этом месте объект ну точно должен быть жив. Если он мёртв, то мы где-то очень сильно накосячили в логике, и надо валиться в корку и потом её долго и мучительно ковырять.

Но я бы в вашей ситуации вообще бы завершался не только при ошибке, но и после каждого запроса.

Тогда мы точно никаких гарантий по производительности не дадим. Вся эта многонодовая ерунда работает в предположении, что ноды падают не сильно часто, и что множества валящих запросов на старой и на новой модели не сильно пересекаются.

Мда… очень запущено… Типичный такой С++.… На дельфи такое происходит реже, ибо меньше способов выстрелить себе в ногу.

Там дело не в забытом где-то free, условно, а в том, что логика едет, алгоритм кривой, если хотите. Поэтому и статические анализаторы не помогут, помогут пруверы, но средний тырпрайз к пруверам не очень готов.

А какой размер кода? Может дешевле потихоньку переписать?

Не всегда это можно дёшево сделать, к сожалению.

Интересно, а вы понимаете, что у нас была совсем иная ситуация?

Конечно. У нас у всех разные ситуации. Но я, правда, уже подзабыл, с чего тред начался. Кажется, там было что-то про негодных студентов.
Ничего. Ничего не надо. Проще и эффективнее оказывается дизайн, толерантный к падениям отдельной ноды.

Собственно потому у вас память и портиться. Зачем вам чинить? Падает и падает, такой дизайн. Портит память — и будет портить, ну дизайн такой.

Ну что же, пусть и дальше портит память, больше советовать не буду. Порча памяти и С++ — как близнецы-братья, где одно — там обычно и другое.

Но я, правда, уже подзабыл, с чего тред начался.

С того, что топикстартер искал разработчика на дельфи.
Собственно потому у вас память и портиться.

Как-то мы резко перешли от вашего дизайна, где порча памяти чинится резервными копиями, к обвинениям в том, что у меня вообще память портится. Зачем вам все эти резервные страницы и продолжение работы, если у вас AV не бывает? А? Бывает? Ну так не надо выпендриваться тогда.

Зачем вам чинить?

Потому что это говорит о проблемах с логикой, а их вот чинить точно надо.

Порча памяти и С++ — как близнецы-братья, где одно — там обычно и другое.

Больше стереотипов богу стереотипов.
Зачем вам все эти резервные страницы и продолжение работы, если у вас AV не бывает? А? Бывает?
Для отказоустойчивости.

Для начала — давайте не путать AV с порчей памяти. Большинство AV — это отсутствие проверки на NULL. Специально для этого мы глобально закрыли use after free при помощи FreeAndNil.

AV при отладке было много. Пока не поняли, что деструкторы надо писать так, чтобы они отрабатывали на полусозданных объектах. Дело в том, что в Delphi возможен вызов деструктора при исключении из конструктора.

И порча памяти при отладке была несколько раз. И гонки. И на всём этом отрабатывалась система восстановления. На каждом баге — сначала восстановление, потом добавление проверки, потом закрытие бага.

А естm ли AV сейчас — не знаю. На опытной и опытно-промышленной эксплуатации — AV были. К моменту перехода к промышленной эксплуатации AV не было примерно полгода.

После трех лет промышленной эксплуатации я приезжал и смотрел логи. Хранятся они порядка полугода, AV не было. Последние 12 лет — просто не знаю.

Повторюсь, система специально физически изолирована от интернета. Для просмотра логов нужно специально просить людей их прислать.

И ещё раз. Трехуровневое восстановление работает при любых проблемах, а не только при AV. Сбой связи, например, обрабатывается примерно так же — пересоздание объекта, если пару раз не помогло — перезапуск подсистемы, если не помогло — перезапуск сервиса с передачей роли мастера на второй сервис, если совсем не помогло — ребут компа.

Это я, кстати, видел в логах, 12 лет назад.

Потому что это говорит о проблемах с логикой, а их вот чинить точно надо.

Или логика или гонка.

Вы бы для тредов отдельные кучи выделили (по куче натред + глобальная) — это уменьшит ваши проблемы. Или это в С++ тоже не делается?
Вы бы для тредов отдельные кучи выделили (по куче натред + глобальная) — это уменьшит ваши проблемы.

Не уменьшит. У тредов слишком много общего состояния, почти всё будет в общей куче. Конечно, можно переделать так, чтобы его было мало, но тогда уже сразу лучше на хаскеле и в STM всё это завернуть.

Откуда вы гонку-то взяли, кстати? Ни слова не было.

Или это в С++ тоже не делается?

В плюсах это тоже можно сделать.
Откуда вы гонку-то взяли, кстати? Ни слова не было.

Из опыта. Симптомы очень похожи.
Не всегда, если есть потоки, то есть и гонки.
Когда человек жалуется, что ассерты должны были бы помочь, но вот беда — не помогают, первая мысль о том, что у человека гонка. Кстати, у нас сейчас больше прерывания, чем треды.

Вообще есть хорошее правило — переменная читается во многих тредах, но устанавливается — только в одном.

Если нужно писать в двух тредах — делается финт ушами с расщеплением значений и флагом. Первый тред читает и пишет основное значение. Второй тред пишет во второе значение и устанавливает флаг. Первый тред перед чтением основного значения проверяет флаг, если установлен, то копирует второе значение в первое и сбрасывает флаг.

Механизм пропертей в дельфи позволяет ввести такой финт пост-фактум, без переделки кода. Как это сделать в С++ — не знаю, вроде такого синтаксического сахара нет.
Когда человек жалуется, что ассерты должны были бы помочь, но вот беда — не помогают, первая мысль о том, что у человека гонка.

Но вот беда: ассертами проверяются не все условия.

Механизм пропертей в дельфи позволяет ввести такой финт пост-фактум, без переделки кода.

Если уж описывать какие-то адекватные решения, то лучше говорить про STM, а не про такие финты ушами.

Как это сделать в С++ — не знаю, вроде такого синтаксического сахара нет.

Проперти в плюсах я делал в бородатом 2004-м году будучи школьником.
Если уж описывать какие-то адекватные решения, то лучше говорить про STM, а не про такие финты ушами.

В чем финт-то? Это удобный механизм добавления посредника.

Проперти в плюсах я делал в бородатом 2004-м году будучи школьником.

Мне кажется, что так же гибко не реализовать.
В чем финт-то?

Это я термин из предыдущего комментария использовал.

Это удобный механизм добавления посредника.

Но доказывать корректность не столь тривиально, скейлить на большее число тредов не столь тривиально, и так далее.

И я сходу не вижу, какие профиты это даёт при условии аккуратного кодинга что этого случая, что прямого чтения-записи в шаренную переменную.

Мне кажется, что так же гибко не реализовать.

Я не дельфист, поэтому не знаю, что из гибкости может потеряться, но мне было бы любопытно, в чём меньшая гибкость.
И я сходу не вижу, какие профиты это даёт при условии аккуратного кодинга что этого случая, что прямого чтения-записи в шаренную переменную.

Так property позволяет не изменяя ничего завернуть данные в функцию обработки (лога и т.д.).

Я не дельфист, поэтому не знаю, что из гибкости может потеряться, но мне было бы любопытно, в чём меньшая гибкость.

На всякий случай, выше я имею в виду вот что: есть у нас такие строки в объявлении класса:
TMyClass = class
private
  fSomeField: integer;
public
  property SomeField: integer read fSomeField write fSomeField;
end;

Но property позволяет не просто зампаить внутренние поля, но и прокрутить через геттеры и сеттеры, поэтому мы можем легко сделать что-то вроде:
TMyClass = class
private
  fSomeField: integer;
  procedur