Как стать автором
Обновить

Комментарии 1112

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

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

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

любую вакансию можно закрыть, предложив достаточную компенсацию. Значит не очень надо
Не всегда требуемая соискателями компенсация коррелирует с их уровнем. Но и это не всё — есть куча факторов, по которым отсматривают кандидата, и все их нужно брать в расчёт. Например, у нас нет собеседования с 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». Т.е. я понимаю, что не всегда это возможно, но нужно к этому стремиться…
Как-то нужно было сделать пароль на локальной учетке. Розы. РозыКрасивые. РозыКрасивые2017. РозыКрасивые2017+. РозыКрасивые2017+!.. РозыКрасивые2017+! ЧеТебеНеХватает***.
Позвал админа. Он попробовал чего-то добавить после звезд, не взлетело. Почесал затылок и забил
Зщшг-2017. Прокатило.
НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь
После того, как знакомая HR искала кузнеца на 500К оклада, я перестал считать IT вакансии дорогими.

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


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

НЛО прилетело и опубликовало эту надпись здесь
Скорее продолжительное время не закрываемая вакансия может являться показателем того, что компания может обходиться и без такого специалиста. В таких случаях наниматель готов платить ровно столько, сколько (как ему кажется) он сможет сэкономить/заработать на данном конкретном специалисте, не более.

Многие семьи посматривают в сторону покупки второй машины при наличии первой, однако есть определенный лимит, выше которого платить не готовы. Это не значит, что таких денег в семье нет, а значит лишь то, что достаточных выгод от покупки 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 и для профи проблематичен тем, что экзотика ( см. здесь же)
Хм… А это правильное решение?
Судя по выводимому логу — да.

FizzBuzz implementation
using System.Globalization;
using System.Globalization;
using System.Linq;
using static System.Console;

namespace FizzBuzz
{
	class FizzBuzz
	{
		private static bool IsFizz(int value) => value % 3 == 0;

		private static bool IsBuzz(int value) => value % 5 == 0;

		public static string GetFizzBuzz(int value)
		{
			bool isFizz = IsFizz(value);
			bool isBuzz = IsBuzz(value);

			if (isFizz && isBuzz)
				return "FizzBuzz";

			if (isFizz)
				return "Fizz";

			if (isBuzz)
				return "Buzz";

			return value.ToString(CultureInfo.InvariantCulture);
		}
	}

	class Program
    {

        static void Main(string[] args)
        {
			const int beginValue = 1;
			const int endValue = 100;

			//foreach (int i in Enumerable.Range(beginValue, endValue))
			//{
			//	WriteLine(FizzBuzz.GetFizzBuzz(i));
			//}

			for (int i = beginValue; i <= endValue; i++)
			{
				WriteLine(FizzBuzz.GetFizzBuzz(i));
			}

			ReadLine();
        }
    }
}


Однако, смущает в вашем исходном посыле, точнее, в статье, на которую даны ссылка, вот что:
Нормальный программист должен написать такую программу на бумажке за пару минут. Но вот что интересно: многие люди с профильным образованием вообще не могут справится с этой задачей. Были даже случаи, когда кандидаты, подававшие резюме на вакансию «Senior developer» тратили на эту программу больше 15 минут.

Ок — увидеть решение и написать простой цикл у меня заняло как раз пару минут.
Поскольку оставлять все в методе Main неправильно, вынесение логики в класс заняло как раз минут 15.

Когда просят сделать подобную задачу «за пару минут», то возникают вопросы:
Интервьюеру что нужно?

1. Увидеть, как я быстро схватываю задачу и вижу решение?
И тогда по боку проверки аргументов/входных данных (начиная от проверок на null и на диапазон, и далее по списку), побоку — должен быть в классе-хелпере сервисный метод статическим или нет, и нужен ли вообще это класс.
Ибо иначе не уложимся в «пару минут».

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

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

Ну и насчет посыла, что задачку FizzBuzz может решить только 1 программист из 200 — явная неправда.
Да, к примеру не все знают/не все владеют техникой применений операций, чуть менее распространенных, чем сложение/вычитание, умножение/деление.
(То же касается и логических и битовых операций — почти все знают про «и», «или» и «не», а с исключающим «или» уже сложнее.)

Но об операции получения остатка от деления — в любом случае, знают и умеют явно больше, чем 1 из 200.
Так что в той статье явное преувеличение.
А это правильное решение?
Правильное, вы бы прошли этот тест. Я бы написал иначе, на мой взгляд, лучше, но, думаю, это скорее связано с общепринятыми стилями в разных языках.
Когда просят сделать подобную задачу «за пару минут», то возникают вопросы:
Интервьюеру что нужно?
Казалось бы, это можно уточнить у интервьювера, он же рядом сидит. Что-нибудь вроде «Это довольно простая задача. Я могу написать ее быстро в acm-стиле, без всяких проверок и тд, либо потратить больше времени и написать хороший код, хорошо читающийся, поддерживающийся, расширяемый и тд, но это будет дольше. В production я всегда пишу код второго типа».
Ну и насчет посыла, что задачку FizzBuzz может решить только 1 программист из 200 — явная неправда.
За что купил, за то и продаю. Кроме того, статья написана в другой стране и несколько лет назад, так что может отличаться от наших реалий. И не «1 из 200 программистов», а «1 из 200 соискателей». Казалось бы, те, кто программировать почти не умеет, должны проходить больше собеседований до успеха.
Но об операции получения остатка от деления — в любом случае, знают и умеют явно больше, чем 1 из 200.
Применить остаток от деления — не проблема. Проблема — составить алгоритм с циклом и двумя ветвлениями.

Да, возможно, в статье преувеличение, но не думаю, что очень сильное.
Казалось бы, это можно уточнить у интервьювера, он же рядом сидит. Что-нибудь вроде «Это довольно простая задача. Я могу написать ее быстро в acm-стиле, без всяких проверок и тд,

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


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

Тоже не так все однозначно. Судя по тому, что я видел в значительном количестве проектов в production коде и то, какой код поощрялся, фраза "В production я всегда пишу код второго типа" может сыграть не в плюс.


Применить остаток от деления — не проблема. Проблема — составить алгоритм с циклом и двумя ветвлениями.

О, да. Как раз такой код (с проблемами на уровне цикл — пара ветвлений) часто можно видеть в production, что говорит о том, что собеседования с задачками FizzBuzz, видимо, не достигают своей цели.


Например, приходилось иметь дело таким кодом:


            var items = new List<object>();
            foreach (var item in items)
            {
                int itemIndex = items.IndexOf(item);
                // Do something with item ..
            }

где метод IndexOf в стандартной библиотеке, если пропустить промежуточные вызовы методов-оберток, реализован так:


    internal virtual int IndexOf(T[] array, T value, int startIndex, int count)
    {
      int num = startIndex + count;
      for (int index = startIndex; index < num; ++index)
      {
        if (this.Equals(array[index], value))
          return index;
      }
      return -1;
    }

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


И, естественно, в официальной документации к методу указано, что его сложность — O(n).


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


Рассылка вида "ребята, давайте так не делать, давайте лучше делать так":


            for (int i = 0; i < items.Count; i++)
            {
                int itemIndex = i;
                // Do something with item ..
            }

вызывала в ответ только тягостное молчание, в т.ч. со стороны руководства.
При этом не были задеты ничьи чувства, т.к. человек написавший foreach/IndexOf уже пару лет как уволился и успешно отбыл в одну из стран в Южном полушарии продолжать писать столь же успешный код.


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


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


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

https://tproger.ru/news/programmers-are-confessing-their-sins-to-protest-against-whiteboard-interview/
Есть современная альтернативная точка зрения.

Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles.

— DHH (@dhh) 21 февраля 2017 г.

Что-то мне подсказывает, что любой из них в состоянии написать 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.
НЛО прилетело и опубликовало эту надпись здесь
Через CMPXCHG spinlock…
НЛО прилетело и опубликовало эту надпись здесь
Там всё веселее. Нормальный мьютекс — это несколько итераций спинлока, и только потом системный вызов. Причём спинлок — это не долбаханье CMPXCHG в цикле (это только будет лочить шину почём зря), а CMPXCHG с паузой в виде какой-нибудь бесполезной операции на 50-100 тактов (длина цикла может быть случайной).
Секундочку, мьютекс — это сущность, позволяющая в каждый момент времени только одному потоку захватывать разделяемый ресурс. А уж эффективно он реализован или нет, с ожиданием и передачей кванта другому потоку или нет — совсем другое дело.
Если взять реализацию, скажем, CriticalSection в Windows, то там будет и спинлок в юзерспецсе некоторое время, сколько-то итераций, и падение в ядро с ожиданием. Но это не значит, что мьютекс — непременно такая эффективная вещь.
Да, голый спинлок — это частный случай реализации мьютекса, пусть и неэффективный. Спинлок — реализация, мьютекс — абстракция (разделение доступа к ресурсу).
НЛО прилетело и опубликовало эту надпись здесь
Вопрос терминологии. Для меня «написать 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++ не пишут.
НЛО прилетело и опубликовало эту надпись здесь
самый наркоманский по чтению STL, имхо, у MSVC++
Есть два варианта, или в фирме типовые задачи, или она быстро разорится. В обоих случаях — отлично что ушли. Кстати, если есть восприятие, что фирма хорошая, то можно через полгода зайти узнать как дела, и вернуться на полуторную-двойную зарплату.
молодым менеджером можно заработать в теории больше, чем начинающим разработчиком

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

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

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

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

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

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


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

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

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

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

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

Очевидно:


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

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

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

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

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

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

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

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


Как-то рассказывали о кандидате на должность программиста в крупную it-компани: «Сегодня приходил парень, вроде нормально рассказывал, но жутко неуверенный в себе. Не взяли, неуверенные нам не нужны».
С другой стороны, думаю, что если бы отвечал отлично, то взяли бы не смотря на неуверенность.
НЛО прилетело и опубликовало эту надпись здесь
Выбираете шутки за 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 год уже что-то из разряда фантастики. Хотя с критическими багами то проще.

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

Рассматривайте клиента, уронившего вам пару серверов, как хакера, проводящего 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 соответствующий кодогенератор прикручивать и вперед.
Кодогенератор там есть. Библиотека нужна.
Тем легче.
НЛО прилетело и опубликовало эту надпись здесь
Ну тут или ассемблер или Си или форт с кросс-компиляцией.
НЛО прилетело и опубликовало эту надпись здесь
и темплейтами.

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

Если захотеть — вполне. Надо только ручками SDK/DDK сделать.
НЛО прилетело и опубликовало эту надпись здесь
Жавы, к слову, на iOS тоже нет. Увы, пока кросс-платформенность Java или, особенно, .net'а ограничена. В отличие от C (плюсов) или Pascal (Delphi).
Вот только кросс-платформенность ограничена бибиотеками, а не компилятором. Стандартная бибилиотека — неотъемлимая часть как .NET Framework, так и Java. В случае C++/Pascal вы можете не использовать библиотеку и получить компактный код. В случае C#/Java это невозможно by design, и это нормально.
НЛО прилетело и опубликовало эту надпись здесь
Вопрос в том, сколько времени нужно, чтобы С# заработал на вашей собственной плате. Си начинает работать сразу.

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

Теоретически можно. Только всем важнее следование стандарту С++, чем надежность. Только на Delphi ловля исключений является правилом, ибо внесена в каркас фреймворка.
Вы лет на 20 отстали от реалей мира java.
НЛО прилетело и опубликовало эту надпись здесь
Ну так обычно в linux в этой схеме делают один поток на процесс. fork — вообще-то так и работает.
НЛО прилетело и опубликовало эту надпись здесь
ну человек просто слышал что процесс и поток порождаются в ядре одинаково через 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 избавлен от этого фатального недостатка.
НЛО прилетело и опубликовало эту надпись здесь
А до него уже семь лет назад было.

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

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

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

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

Ну так после AV — просто проверяете данные. По инвариантам, по второй копии. Зачем бояться того, что не бывает?
НЛО прилетело и опубликовало эту надпись здесь
Было. assert'ы через строку, если сработало — надо падать вот прям щас.

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

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

НЛО прилетело и опубликовало эту надпись здесь
Вы что, продолжали выполнение после ассертов?
как может быть и ассерт и AV одновременно?
НЛО прилетело и опубликовало эту надпись здесь
Когда размер хипа процесса достигает двухста гигов,

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но property позволяет не просто зампаить внутренние поля, но и прокрутить через геттеры и сеттеры, поэтому мы можем легко сделать что-то вроде:
TMyClass = class
private
  fSomeField: integer;
  procedure SetSomeField(AValue: integer);
public
  property SomeField: integer read fSomeField write SetSomeField;
end;

И потом в SetSomeField сделать логгирование, удобно поставить точку отладки, проверку диапазона, точку останова на конкретное значение (это будет быстрее, чем аналогичная ыункция в отладчике, т.к. та вычисляется на лету и медленно).
НЛО прилетело и опубликовало эту надпись здесь
Ай, значит, не так понял, ну, извините. Все равно, property рулят.
Каждый судит по себе. Помню я ваши рассказы про отладку, да инварианты. Так что думаю, что ассерты выставлены знатно, не в них дело.

Ну что же поделитесь решением 2004ого года. Задача такая — заменить поле объекта на две функции (get/set) так, Чтобы использующий код этого не заметил… Ну разве что адрес такого поля будет не получить.

Мы при отладке не только ушами, но и хвостом готовы финты рисовать. Лишь бы был метод, находящий ошибку за заранее известное время.
НЛО прилетело и опубликовало эту надпись здесь
Поле — публично видимая переменная? С учётом невзятия адреса вообще просто получается: пишется шаблонный класс с шаблонным (или нешаблонным, зависит) operator= от нужного типа и с переопределённым оператором приведения к этому типу.

printf поломается. И поменяется приоритет при определении правильного перегруженного метода. А еще вывод типов в шаблонах сломается...

НЛО прилетело и опубликовало эту надпись здесь

Например — при вызове метода template <typename T> foo(bar<T> b) компилятор не сможет вывести T если ему передать значение типа property<bar<T>>.

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

struct A;
class B {
public:
A ccc[D];
}

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

Логировать обращения вместе или раздельно? Если вместе, то все совсем просто:


class B {
public:
    class ccc_t {
        A item[D];
    public:
        A& operator [] (ptrdiff_t index) {
            //логируем
            //еще assert на индекс можно воткнуть
            return items[index];
        }
        A const& operator [] (ptrdiff_t index) const {
            //логируем
            //еще assert на индекс можно воткнуть
            return items[index];
        }
    } ccc;
}

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


При желании можно сделать обобщенную реализацию через шаблоны.

Угу, при всей моей нелюбви к шаблонам, именно тут шаблон очень полезен.
НЛО прилетело и опубликовало эту надпись здесь
В переводе на русский: причиной некоторых сбоев были гонки. Ну собственно об этом я вам и писал.

За код спасибо. Использовать можно?
НЛО прилетело и опубликовало эту надпись здесь
Почитал я про STM. Хорошее решение для разработки, но неадекватное отладке.

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

С другой стороны, механизм пропертей и все, что можно спрятать под его капотом, очень удобен именно для отладки.
НЛО прилетело и опубликовало эту надпись здесь
Не STM отлаживать, а ваш проект отлаживать при помощи STM. Есть такой метод, очень дешевый для Дельфи. При отладке заменяем быстрое обращение к полям объекта, на медленное, но более надежное логгируемое. И смотрим — ушли ли ошибки. Если теоретически поведение программы меняется не должно, а оно сменилось — значит баги связаны с полем, к которому заменен доступ.

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

Как самый известный пример — 1С-бухгалтерия. Она выкачивала с SQL-сервера таблицы в память и обрабатывала их на клиенте. За счет чего были нагружены все трое: клиент, сервер и сеть между ними.
Да, есть такое. Свойства для отладки крайне полезны. Особенно на больших проектах.
Проперти в плюсах я делал в бородатом 2004-м году будучи школьником.

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

За отсутствием проверки на NULL следует либо порча памяти, либо чтение неверных данных, либо AV.
FreeAndNil, внезапно, не обязательно защищает от use after free — он обнуляет только одну ссылку на объект, а не все, которые есть.
Имхо, проблемы с NULL — следствие избыточного использования NULL. В нормально написанных системах таких проблем не возникает, а в ненормально написанных — быдлокодеры плюются от NPE.

Каким образом вы прочитаете неверные данные «За отсутствием проверки на NULL»? Каким образом проверка на NULL предохраняет от порчи памяти?
 struct p { 
      char padding[0x7fffffff];
 int data;
};
p *ptr = nullptr;
int data = ptr->data; 


Ещё попытки будут? :-)

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

Вспомнился старый-старый анекдот
В исполком пришла жалоба: «Напротив моего окна женская баня. Мне все видно и это отвлекает меня и вообще действует на мой моральный облик. Прошу предоставить мне новую квартиру». Приехала комиссия, смотрят в окно. — Ну и что? Ничего не видно! — А вы на шкаф залезьте! — Ну, залез, — говорит представитель, — все равно не видно! — Двигайтесь левее… — Все равно не видно! — Еще левее! Тут представитель двигается и падает с края шкафа. — Вот видите! А я так целый день!

Не, не сумею я туда попасть. В usersace в винде отмапленное адресное пространство начинается с 4 мегов. А у меня на все приложение — 20 мегов уходит. Ну где я вам кролика объект такого размера найду?


Выдумывайте дальше.
20 мегов уходит

А, ну ок. Как будет уходить 2000 мегов — практика развеет ваши иллюзии.

Вы не в курсе, что у Windows NT 4 все адресное пространство для приложений — 2 гигабайта? Ну в общем, все как в анекдоте от Путина…



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

P.S. 256мегов на тех серверах было. Физических.
2gb только для 32битных приложений, и то если забыть про 3gb флаг(т.е использовать win2k/nt4)
3gb флаг
у меня с ним начало «глючить» всё подряд ещё до запуска собственно ПО

P.S. xdelta3 32bit-ная — потолок уже на 1.7Gb
P.P.S. 1.7Gb — с первого взгляда, «потолок» для очень многого
Начнем с того, что проект начал писаться примерно с ноября 1998ого года. Какой-такой win2k?

/3GB был начиная с NT4 sp3. Но зачем он нам на 256 мегах памяти?

64 бита появились в WinXP, но вначале только для итаниум.

Дельфи тех времен в 64бита не транслировал.

Короче, вы тогда не жили. :-)) Ну то есть не работали. :-)
/3GB был начиная с NT4 sp3. Но зачем он нам на 256 мегах памяти?
...
Короче, вы тогда не жили. :-)) Ну то есть не работали. :-)


Ну отчего же Ж-) NT4 TS 720Mb RAM на 32 сессии

Про /3GB сразу приходит на ум при чтении:
Как будет уходить 2000 мегов

ещё PAE можно вспомнить

P.S. Как раз 64bit-а и купили у Free Pascal
P.P.S. И относительно недавно: года 3-4 назад
я рассказываю про конкретный пример. Если бюы уходило 2GB — это была бы другая задача, с другими методами обеспечения надежности и производительности.

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

Это 1993 год, на 386DX40 год, скорость поиска была в два раза ниже скорости чтения с диска в память. Так что всерьез обсуждали, не переписать ли дисковый драйвер так, чтобы исполнять код во время движения головки диска.
2GB — это была бы другая задача

Что другая это понятно

Написал для общества:
— что /3GB может потянутьпроблемы
— что 1.7GB может оказаться «практическим потолком» для 32bit «екзешника»

запрос компилировался в машинный код на лету. Ускорение — в десяток раз
JIT в 1993 — респект

полнотекстовый поиск
Сейчас «давят грубой силой» — числом дисков, SSD, числом серверов

исполнять код во время движения головки диска
OS без многозадачности?
JIT в 1993 — респект

Не JIT. просто динамическая. Одна из первых компиляций поисковых запросов на лету принадлежит Кеннету Томпсону, 1968 год.

Ну в общем не удивительно, когда из трех программистов — двое компиляторщики. Собственно, Антон, который писал это известен как автор паскаля-УКНЦ и TMT-паскаля. Мозги так заточены у компиляторщиков.

Мне вот тоже, при реализации виртуального контроллера OMRON, показалось, что откомпилировать в x86 проще, чем делать эффективную интерпретацию.

OS без многозадачности?

MS-DOS. Не windows 3.1 же!

Сейчас «давят грубой силой» — числом дисков, SSD, числом серверов
Зависит от цели. Если цель — иметь как можно больше покупателей, то снижаем цену железа. Если покупатель один, то снижаем общую цену разработки. А программисты — подороже железа будут.
исполнять код во время движения головки диска
OS без многозадачности?
MS-DOS
Ну там резиденты можно было использовать. Мог ли код резидента выполняться параллельно чтению с диска — уже и не помню Ж-)
Многозадачность и асинхронность — разные вещи. Собственно многозадачность для этого была не нужна — хватило бы асинхронности.

Грубо говоря, в идеале перед стартом чтения с диска хотелось задать процедуру, которая будет периодически вызваться во время ожидания позиционирования головки.
Да, асинхронность — это, таки, полезно
Это Asynchronous I/O, overlapped и так далее получается. То, что сейчас и используют для уменьшения простоя при работе с IO.
Угу, именно AsyncIO и хотелось в идеале.
Мочь-то мог, только нитка выполнения все равно одна.
Полторы — вторая в таймерном прерывании.

Проблема была в том, что был ещё коробочный продукт на той же кодовой базе -классификатор предприятий СССР с базой 80Мегабайт на диске. А он должен был запускать на любой машине.

Потому и библиотечную базу (которую мы ставили на железо сами) не переводили под DOS-extender с многозадачностью.
Я имею в виду — процессор один. Хоть сто программных таймеров на восьмое прерывание повесь — все равно только 1 будет работать за раз.
Не совсем так… В этой задаче на пике процессор работает 50% времени, остальное — ожидание ввода-вывода. Так что ускорение — в 2 раза минус оверхед.

В иных задачах — процессор занимался ещё меньше.

Самый лучший ехтендер был из обрубленной до консоли OS/2. :-)
Да пусть хоть 99% ускорение.
В OS/2 мне больше всего понравилась эмуляция устройств внутри DOS сессии. Это была единственная из доступных ОС, которая эмулировала DOS вместе с графикой, последовательными портами, корректно все это поддерживая.
Win95 разве хуже эмулировала? Просто она появилась позже.

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

Вывод в окне — это именно эмуляция (DOS-приложения рассчитывали на полнооконный режим), доступ к диску — тоже эмуляция, Win95 для DOS-сессии эмулировала BIOS, хотя сама обычно обращалась к диску через 32битный драйвер.
хотя сама обычно обращалась к диску через 32битный драйвер.

Хххха.
Знали. Еще я помню роль ДОСовского MSCDEX и статью Реймонда Чена на эту тему.
Намного, как оказалось, когда я столкнулся с практической задачей — запустить на новом железе DOS программу, которая работает с графикой и нестандартными COM портами.
В win95 было много удивительного. Например у коллеги она работала больше месяца между перезагрузками, несмотря на десяток тяжелых приложений типа MS Project, Outlook и так далее.

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

А вот эмуляция нестандартного железа видимо просто не была одной из целей.
В OS/2 мне больше всего понравилась эмуляция устройств внутри DOS сессии. Это была единственная из доступных ОС, которая эмулировала DOS вместе с графикой, последовательными портами, корректно все это поддерживая.


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

COM порты для DOS программ отлично работали и в NT 3.51
Как мне рассказали ( я сам видел «в деле» уже NT 4.0)
надо было запустить 4 экземпляра ПО для приёма-передачи файлов по модему.
( Не FIDO, версия ПО с 4 портами стоила дороже)

Так вот, очень много многозадачных оболочек над DOS,
но в них просто не заработало как надо ( или совсем)

Участвовал ли OS/2 — не спросил в своё время
Но т.к. в FIDO проявил себя хорошо, то, думаю, справился бы
Там была задача работы с COM3, COM4 И графикой одновременно, на современной карточке.
В общем, все, кроме OS/2 слили в том или ином аспекте.

Очевидный пример:


int f(int*p){
// if(!p)throw ...; // проверка на NULL, если бы она была
return p[100500];
}
void g(int*p){
// if(!p)throw ...; // проверка на NULL, если бы она была
p[100500]=3;
}

f(0); // неверные данные или AV
g(0); // повреждение памяти или AV
Кстати, интересно пройдёт ли передача константы в процедуру с InOut ( в терминах ADA) компиляцию…
Это некоторые Сишники так Nil записывают. Так что пройдет. Там же 0, а не &0.
Кстати, интересно пройдёт ли передача константы в процедуру с InOut ( в терминах ADA) компиляцию…
Это некоторые Сишники так Nil записывают. Так что пройдет. Там же 0, а не &0.
На Си, скорее всего, компиляция пройдёт «на ура» ( тут просто в комментах писали про проверку типов в Си),
а вот если сконвертировать исходный текст C2Ada.

Но уж если это делать по-честному, и 0 на Nil ( ну или Null) заменить... Скорее всего — уже в Runtime
AV! AV! АВ-АВ-АВ!!!

Слабо проверить до поста на хабр?

P.S. я ошибся, с 4 мегов данные, с 1.3 мегабайта — растущий вниз стек.

Ваш пример с девочкой как раз аргумент против подхода "восстановление после AV". Потому что девочка погибла именно в следствии такого вот восстановления не глядя...

Вы понимаете разницу между реакцией на аварию и сброса признаков аварии без реакции? С лифтом было второе. У меня — первое. У вас, при переходе на резервный сервер — тоже будет второе.

Собственно вот показания программиста: На 4 странице распечатки в 19.41.09 диспетчер нажата кнопку – сброс состояния, чтобы убрать ошибки, которые на лифте.

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

Реакция на аварию — это установить признак аварии, установить исполнительные механизмы в безопасное положение, выключиться.


А вы предлагаете после обработки продолжить работу. Ровно то, что сделал диспетчер.

Реакция на аварию — это установить признак аварии, установить исполнительные механизмы в безопасное положение, выключиться.

Это, мягко говоря, сильно зависит от объекта управления.
Диспетчер сбросил признаки аварии перезапуском ПО. При перезапуске есть такой трудный выбор между «Стартуем с чистого листа» и «надо бы сохранять признак аварии». У обоих вариантов — есть свои недостатки.

Работа по AV по нашей схеме безопасна. Вот смотрите варианты порчи памяти:

  1. Испорчена память, AV не происходит
  2. Испорчена память, AV происходит однократно
  3. Испорчена память, AV многократный


Если вы страхуетесь от ситуации 1, то в чем разница между 1 и 2? У вас все равно программа может записать испорченные данные. Если же вы застраховались от 1, то вы застраховались и от 2.

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

Если вы так боитесь порчи памяти — то помните, что ситуация 1 — это просто выход за границу массива. Это просто лишний инкремент указателя. И много-много что. Это самая частая ситуация.

Вторая по частоте — это ситуация 3. К ней относится запись в нулевой (в Дельфи) или -1ый (в Си) элемент динамического массива. В этом случае рушится структура кучи. А кучу при рекомендуется контролировать при каждом AV.

А ситуация 2 — это экзотика. Вживую не видел. Если она у вас встречалась — то расскажите, как вас угораздило.

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


Я говорю что аналогия с той девочкой — некорректна.

Понял.
Мда, пожалуй я понял, почему в С++ не получится повторить то, что я сделал в Delphi.

Самая частая порча памяти — в стеке. Ошиблись индексом — и вышли за пределы массива. Что у нас в стеке в дельфи? Ничего важного. Объектов там нет. указатель на место передачи исключения — берется через регистр. Ссылка на следующий блок ловли исключения — в стеке. Самое ценное, что есть — это адрес возврата. Но даже если его потерли — не страшно, будет исключение и переход по адресу обработки исключения (из регистра). Даже указатели в стеке сидят редко.

А теперь взглянем, что у нас в Си. А в Си у нас в стеке — объекты Rall. Потерли мы стек или нет — а их деструкторы должны исполняться. А как им выполнится, если стек потерт? А ещё в стеке — указатели. И их много. Часть — от оптимизации, часть — ну такой уж стиль Си, что в нем локальных указателей много.

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

Как ни странно, Дельфи выигрывает за счет своей недообъектной модели и недооптимизации.

И ещё раз. RAll не заменять try..finally. EXCEPTION_REGISTRATION намного лучше защищен от порчи стека, чем RAll.
Только если ошибка возникает уже при раскрутке стека.
Нет. Начиная с с++11 деструкторы неявно помечаются как noexcept в случае, если дефолтный деструктор был бы noexcept (то есть, почти всегда). А исключение из noexcept метода — сразу terminate
НЛО прилетело и опубликовало эту надпись здесь
Начну с обратного. __try...__finally в MSVS появился еще в те времена, когда .Net'ом и не пахло (во всяком случае за пределами Редмонта).
По поводу ситуации с применением __try...__finally отвечу цитатой здешнего жителя (увы! На память не помню его ника):
«Если вы собираетесь писать программы для Windows, читайте Рихтера.
Если вы ничего не поняли из прочитанного, перечитайте Рихтера.» (ц)
Рекомендую прочитать Рихтера, в его книге этой конструкции, __try...__finally (а также SEH и в чем отличие try...catch от __try...__finally), посвящена отдельная глава
Постоянно хочется его использовать, т.к. иначе приходится заворачивать многие вещи в классы и пихать код для finally в деструктор. Пример таких вещей — какие-нибудь системные дескрипторы.

Вот как раз системные дескрипторы — кандидат номер 1 для заворачивания в классы!

НЛО прилетело и опубликовало эту надпись здесь
Я прекрасно понимаю, что имеющимися средствами можно эмулировать подобный функционал. Но с другой стороны, почему нельзя сделать язык более удобным? Вы же, наверняка, не пишете на C++11, а предпочитаете использовать возможности и C++14, и C++17, хотя после C++11 никаких фундаментальных изменений в языке не произошло. Так почему бы и finally не стандартизировать?

И да, реализация finally через выполнение кода в деструкторе плоха тем, что при возникновения исключения могут быть проблемы.
std::unique_ptr + std::remove_pointer
В С++ конструкция try...finlaly? Учите матчасть, её там нет. Есть лишь в борландовом (дельфийском) расширении.
msdn.microsoft.com/en-us/library/9xtt5hxz.aspx
Угу, и оно в же в VC++. Причем в борланде, если не путаю, появилось лет на 10 раньше.

Главное — что нету ни в стандарте, ни в gcc/clang.
В VC++ оно уже было в 1998, документацию более старых версий я просто не могу найти. А у Борланда оно, наверное, появилось в 1988? (Есличо, первая версия Borland C++ вышла только в 1992)
И моя память и вики, утверждают, что Borland C++ 2.0 появился в 1990 году. В Borland C++ 4.0 (1993 год) __finally уже было. Мне тоже более раннюю документацию не найти. А скачивать и запускать — лень.

Будем считать, что спутал и разница 5 лет, а не 10?

Самые первые упоминания Borland C++ 2.0 в usenet относятся к 1991; англовики тоже считает, что он вышел в 1991.
Кто и на каком основании вписал в рувики 1990, я не знаю.
Не знаю, вероятно там копирайт 1990 года был. Давайте закроем этот спор, мне не так важно, кто был первым. Более того, первым мог быть кто-то третий, например watcom.
Впрочем, нашёл подтверждение, что в VC++ 4.0 (1995) __finally уже было.
Когда, говорите, оно появилось у Борланда?
Как минимум — с 1993 года (BC++ 4.0). Скорее всего было и в 3.1 (1992 год), но я пока что пруфов не нашел.
Главное — что выдается структурное исключение, а не signal.
Даже если и сигнал, всё ничего похожего на «access violation фатален и приводит к немедленному завершению программы», о чём вы утверждали выше.
То-то word немедленно вылетает при сбое спеллчекера… :-)

Вы лучше найдите хоть одну программу на С++, где процесс выживает после access vioaltion. На delphi — все GUI-программы такие, ибо так устроен фреймворк. Хром не предлагать — у него процесс завершается после access vioaltion. Просто архитектура многопроцесная.

Я думаю, что Delphi себе это может позволить за счёт узкого круга поддерживаемых платформ. Но требование, чтобы аппаратное исключение преобразовывалось в исключение языка, не получится включить в стандарт и при этом не пожертвовать кроссплатформенностью, потому что в общем случае платформа вообще не обязана вам давать какие-то аппаратные исключения. Разыменование нулевого указателя на какой-то платформе выльется в access violation, а у другой платформы в те адреса память отображается, и вообще у неё никакого MPU нет.

Вы будете удивлены не меньше меня. Насчет «не получится» — signal включен в стандарт ISO С вместе с SIGILL, SIGSEGV, SIGBUS и даже SIGTRAP.

у другой платформы в те адреса память отображается, и вообще у неё никакого MPU нет.

Более того, и на одной платформе в одной программе в указателе может быть разный мусор. И один мусор вызовет прерывание, а другой — отобразится в нормальный адрес памяти. Это специфика, она не мешает стандартизации.

Вы почитайте текст стандарта:


An implementation need not generate any of these signals, except as a result of explicit calls to the raise function.

Это всё implementation-specific, вы не можете полагаться на это в кроссплатформенном коде. Да, API есть, но стандарт вам не обещает, что это будет работать.

Стандарт обещает, что если сигнал возникнет — я его смогу обработать. Ровно тоже он может обещать и для исключений.

Стандарт не обещает лишь генерацию сигналов. Мало ли — на машине ММU нет. Или нет понятия терминала.

Кстати, то, что стандарт обещает, тоже не всегда есть. Например open/fopen на embeded без файловой системы. FreeRTOS, например.

И что? Теперь файлами не пользоваться?

Так что внести в стандарт аппаратные исключения можно.
Это специфика, она не мешает стандартизации.

Но ведь у Delphi нет стандарта. Это язык, у которого ровно одна реализация.
Таки нет: минимум две ( есть free аналог)

Забавно, что многое как раз из free проекта взяли в «платный» Delphi ( вполне официально, ещё и пожертвование от фирмы внесли)
ну окей, две. Просто стандарт языка С гарантирует, что правильно написанная программа будет работать одинаково на разных платформах и разных компиляторах. При чем её поведение полностью описано стандартом. Грубо говоря, можно взять текст программы, текст стандарта и гарантированно рассказать что будет делать эта программа. Без компиляторов и прочего.
В случае с Делфи этого нет. Поведение программы полностью обусловлено поведением компилятора. Если компилятор сгенерировал именно такой машинный код — значит это и будет правильным поведением программы. Иными словами, любой код который выдает компилятор — считается правильным.
Что, правда? Ну-ну раскажите, сколько ОС поддерживает ваша программа? На скольки компиляторах компилируется? Вы расскажите ребятам из PVS-Studio — они из-за трудностей переноса программы под 64битную архитектуру свой анализатор родили.

Мне можете не рассказывать — мой код работает на 7 операционках (MS-DOS, Windows, QNX, FreeBSD, Linux, МСВС, FreeRTOS) и компилируется 6 компиляторами (BC++ 3.1, BCB 5.0, gcc, lcc, clang, MS VC++). Может лучше я вам лекцию прочитаю про проблемы переноса?

Перенос из Delphi на Free Pascal был намного проще переноса между gcc и MS VC++.
Моя программа не поддерживает нисколько ОС, потому что сама является или ОС или её заменителем. Так уж получилось, что я занимаюсь opensource embedded разработкой и контрибьючу в такие проекты как linux, xen, optee. Они конечно же собираются в основном gcc (но публичные хидеры везде совместимы с ANSI C) и работают на самых разных аппаратных платформах (мы вообще с armv7 и armv8 работаем в основном). И с трудностями переноса я знаком не по наслышке. Точнее, я знаком с трудностями написания переносимого кода. И в своем предыдущем комментарии я не зря упоминал про правильно написанную программу. Очевидно, что если писать не думая — то потом намучаешься с переносом, никакая PVS-Studio не поможет.
с трудностями переноса я знаком
В ADA мире очень плотно занимались стандартизацией, как раз, для переноса ПО на разное железо...
Ну что же, перенесите ваш код в MS VC++. Получится?

Правильности в смысле соответствия стандарту мало. Надо ещё очень многое учесть.

А написать на переносимом подмножестве — можно на почти любом языке. Исключение разве что APL — там набор символов специфичный.
А что случилось с остальными? TMT Pascal, Free Pascal? Был ещё Virtual Pascal и Turbo51.
Не говоря о том, что Object Pascal вообще-то был придуман в Apple.
И что, где-то формально описаны правила языка, которые позволят достигнуть одинакового поведения программы подо всем этим зоопарком паскалей?
где-то формально описаны правила языка
На Pascal есть ISO стандарт
Проблема в одном — Delphi, действительно, не чистый Паскаль

В Free Pascal есть штук 5 разновидностей опции компилятора ( или даже несколько семейств опций)
какому из Borland диалектов соответствовать

Т.е. на практике TP изучен вдоль и поперёк разработчиками компиляторов
ну да, особенно режим delphi, режим tp в fpc радуют. Ещё помню скорость 1 единицы трансляции была сильно выше чем у gcc
скорость 1 единицы трансляции была сильно выше чем у gcc
Именно это — подарок из 70-го от Н.Вирта: компиляция в один проход, выверенная грамматика языка и т.п.

Писал здесь про модули в Си и включение их в стандарт

Так вот их все ждут для ускорения компиляции
( сейчас .h приходится обрабатывать для каждого include)

а в M-2/ADA/TP уже из коробки модули и ускорение компиляции больших проектов

P.S. потому и в Си хотят, но не... Ж-)
Совместимость мешает
В С++ конструкция try...finlaly? Учите матчасть, её там нет.

Для этого есть деструкторы, которые, в отличие от Delphi, будут гарантированно вызваны, поэтому в finally необходимость не возникает.
Это достоинство VCL, а не Делфи, что exception ловится на верхнем уровне приложения.

Э, нет.
Это вообще-то делается в рамках модуля System (т.е. прямо ядра-ядра языка, рантайм), никаких VCLей.
Что «это делается»? Показывает сообщение и работает дальше? Нет же.
Вопрос — что сделает консольное приложение на исключении при отсутствии TApplication?
Подскажу
program ConsoleExceptionHandling;
{$APPTYPE CONSOLE}
 
uses
  SysUtils;
 
procedure ExecuteProgram;
begin
  // Program does something
  raise Exception.Create('Unforeseen exception');
end;
 
begin
  try
    ExecuteProgram;
  except
    // Handle error condition
    WriteLn('Program terminated due to an exception');
    // Set ExitCode <> 0 to flag error condition (by convention)
    ExitCode := 1;
  end;
 
end.

docwiki.embarcadero.com/RADStudio/Tokyo/en/Console_Applications
Что «это делается»?

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

Ээ, што?
Назовите хотя бы один язык, где «access violation фатален и приводит к немедленному завершению программы».
Вроде в C/C++ такие штуки могут привести в segmentation fault, если использовать сырые массивы. Я не прав?
В C/C++ так же как и в Delphi операции с невалидными указателями (через ^) уронят процесс.
В дельфи (и дельфийском варианте С++) — процесс не падает, а выдается структурное исключение. Которое очень легко потом поймать в любой объемлющей функции. Более того, есть два стандартных перехвата — в VCL, на уровне диспетчера виндовых сообщений и в RTL.

Как пример. Имеем сложное представление данных в памяти в виде стрeктур с указателями. И просто плоское представление, в которое иногда, со всеми предосторожностями сохраняем. Если мы сломали структуры — то получаем исключение и пересоздаем структуры из плоского представления.
Правильно написанная программа не С не обращается к нулевому указателю и не вызывает segfault. Если ваша программа падает с segfault — в ней есть ошибка. Так нам говорит стандарт языка.
Я понимаю, что мир намного шире, чем стандарт. Поэтому большинство ОС позволяют приложениям перехватывать такие ошибки. Но на самом деле это не так уж и важно. Если вы упали с segfault — значит вы где-то ошиблись. Считайте, что segfault — это такой аппаратный assert. Что-то пошло не так, состояние программы больше не консистентно, лучше завалиться сейчас, чем наделать бед в будущем.
Собственно, поэтому и падает Word в вашем примере. Не то что бы он не мог захендлить это исключение и убить глючный модель проверки правописания. Но где гарантия, что ошибка в этом модуле не повредила память в другом месте? И это особенно важно для всяких энтерпрайз штук, типа CRM. Если где-то произошла ошибка такого уровня — лучше упасть, чем надеяться что состояние приложения осталось консистентым.
Ваш пример со структурами интересен, но куда логичнее проверять указатель на NULL, если он может быть NULL, а не надеятся на MMU и OS.

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

Ну так тот же Word и так штатно бекапит открытый документ.

Просто вы ожидаете слишком большой компетентности от пользователя. Ему надо донести что данные уже возможно повреждены. И что не надо, например, перезаписывать поверх оригинальный документ. И что повреждения могут быть незаметными на первый взгляд. Например, пользователь сохраняет документ под новым именем, перезапускает программу, открывает документ и видит что всё вроде хорошо. А потом через месяц у него не сходится годовой отчет. Кто виноват? Программист, конечно.

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

А если плагин падает во время работы над документом? Хорошо в managed языках — там можно заранее сделать копию документа и быть уверенным что плагин до нее не дотянется.
Но если плагин — это либа написанная на С++ — он может повредить не только свои данные, но и любую память. Поэтому да, вы можете убить плагин. Но у вас нет гарантий, что он перед смертью не повредил состояние вашей программы.

Но и гарантий обратного тоже нет!


Вы почему-то исходите из того что неправильная программа неправильна всюду. Но это же не так. Каждая ошибка при работе с указателями либо вызывает AV либо повреждает память. Причем ошибка вызвавшая AV память не повреждает!


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


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

Вы почему-то исходите из того что неправильная программа неправильна всюду. Но это же не так. Каждая ошибка при работе с указателями либо вызывает AV либо повреждает память. Причем ошибка вызвавшая AV память не повреждает!

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

Таким образом, ситуация «получили AV и повредили память» возможна только если ошибок оказалось минимум две (вторая может быть следствием первой). А вероятность такого события меньше чем вероятность просто единичной ошибки.

Как я уже сказал — достаточно одной ошибки (например use after free()). И на практике я с таким сталкивался не раз.

Когда я был студентом, мне дали какую-то программу чтобы делать в ней лабы, не помню уже что она делала. Так вот: при запуске она каждый раз выдавала окошко с надписью «Access violation», после чего продолжала работу. Был бы я как пользователь этой программы более счастлив если бы программа берегла меня от непредсказуемого повреждения памяти и завершала свою работу?


Если бы она сразу падала — то автор исправил бы ошибку. А так «Ну подумаешь выводит Access Violation. Работает же!». Я тоже когда-то был студентом и тоже забивал на такие ошибки. Но это неправильно. Было бы лучше, если бы язык сразу бил бы линейкой по рукам.
Если бы она сразу падала — то автор исправил бы ошибку.

Ха-ха-ха. Я думаю, у автора все работало.

А вот — я не уверен. К сожалению, академическая среда совершенно не располагает к написанию корректного кода. Автор вполне мог решить что эта ошибка не важна.
А почему вы решили, что VisSim (вспомнил название!) был написан в академической среде?
Я решил это из своего опыта. Просто вспомнил, как мы делали лабы в симуляторе написанном на нашей же кафедре. Вы же не сказали, каким приложением пользовались :)
Ещё раз — вас спасет защита данных при помощи CRC.
Wat?

Вы наверное шутите. От чего меня спасет защита данных при помощи CRC? Вы можете привести пример такой защиты данных?
От не обнаруженного искажения данных в результате порчи памяти. CRC верный — значит эта область памяти не испорчена.

Это ровно одна ошибка, которая сначала приводит к повреждению данных, а потом — к падению с SIGSEGV.

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

Альтернатива — ежесекундный сброс на диск. Но это хуже.
Что есть «важные данные»? Возвращаюсь к ворду — документ — это важные данные? Настройки самого ворда — это важные данные? Положение курсора — важные данные? Состояние десятка плагинов — это важные данные? Как вы собираетесь это контролировать в многопоточной программе?
Запустите ворд, поработайте в нём и сравните объем занятой им памяти с объемом документа. Видите отличие?

Сейчас при сбое пользователь теряет 10-15 минут работы. Делаем автосохранение раз в секунду, но не на диск, а в память. Причем не в кучу, а отдельно запрашиваем страницы памяти у ОС. И защищаем эту память при помощи CRC.

При сбое — получаем потерю лишь последней секунды. Мы или сбрасываем эту область на диск или прозрачно перезапускаемся сами и читаем из неё.

Да, последняя секунда теряется, но это меньше чем 10-15 минут работы.

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

А уведомить пользователя о сбое — разумеется, надо.

Как вы собираетесь это контролировать в многопоточной программе?

Как собираюсь — неинтересно. Как оно контролируется в реальной программе — ну допишу пост, там будет рассказ. Там порядка 20 тредов работало.

Опыт показал, что дельфи — это не С++. И порча памяти — зверь редкостный.

Главный принцип — любая ошибка закрывается минимум трижды:

  1. отлаживается восстановление
  2. ставится assert обнаружение (в Delphi assert вызывает исключение, а не завершение программы)
  3. только после этого правится сама ошибка. Иногда — дважды: и в вызывающем и вызываемом коде.


Ну да, дороговато. Зато быстрее, чем отладка вообще всех багов.
О, ну вот видите. Уже и сохранение в память и прозрачный перезапуск. Как-то мало похоже на простую обработку исключения. Опять же, это всё можно сделать на С++, не вижу преимуществ одного языка над другим.
Что если ошибка привела к порче не документа, а к порче настроек, например? И ворд, согласно новым настройкам продолжить портить документ? Или даже не ворд, а какой-нибудь третий плагин.
На плюсах можно сделать все.
Но по срокам разработки (при вышеупомятых требованиях) вы дельфистам уступите примерно геологическую эпоху.
У дельфи колоссальное преимущество в скорости компиляции и сборки, качестве информации об ошибках от компилятора, минимальном количестве неопределенного поведения.
Уже писали, что на С++ нельзя, ибо исключение из деструктора вызывает std::terminate();

Ну да, для ворда придется немного потрудится. Но главное — на дельфи это возможно. А на С++ — нет.

Что если ошибка привела к порче не документа, а к порче настроек, например?

Тру-ля-ля… Ворд все важные настройки сохраняет в документе.

Вы сравните ситуации:

  1. Ваша. Идет сбой, появляется сообщение о сбое, пользователь остается с документом 10минутной давности и руками перезапускает word.
  2. Моя. Идет сбой, появляется сообщение о сбое, пользователя остается с документом 1 секундной давности, ворд перезапустился автоматически и работает.

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

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

Кстати, хороший пример, что эта схема работает — это Андроид и его OOM-киллер. Тоже иногда процессы падают (или прибиваются), а потерь данных — нет.
например use after free

В надежном коде use after free почти не бывает. Там используется только FreeAndNil. И указатель — почти всегда лишь в одной копии. Это азы надежности.

Я тоже когда-то был студентом и тоже забивал на такие ошибки

Потому вы и не понимаете, как писать надежные программы. Мы даже на хинты не забиваем. То есть компилируем -wall -wextra без елиного варинига или хинта.

Обычно все работает у автора и заказчика. Но потом сменилась версия ОС (или библиотеки или иного соффа) — и опаньки.
Потому вы и не понимаете, как писать надежные программы. Мы даже на хинты не забиваем. То есть компилируем -wall -wextra без елиного варинига или хинта.


Скажите, что вам непонятно в фразе «Я тоже когда-то был студентом и тоже забивал на такие ошибки.»?
Обращаю ваше внимание, что там используется прошедшее время. Давайте не будет пользоваться аргументом ad hominem, хорошо?
Вот это вот непонятно.

Было бы лучше, если бы язык сразу бил бы линейкой по рукам.

Ибо лучше только тем, что любители забивать болт на ошибки получат по рукам.

Зато всем остальным — приходится много от чего отказываться. Например — от обработки assert как ещё одного вида исключений.

P.S. Это не ad hominem, это просто разный подход к надежности. Для меня нормально было городить огород при частоте возникновения access violation — примерно раз в год. Для вас — нормально было забивать болт на нефатальные ошибки.

Единственное что — мой подход на 30% дороже обыного. Потому и применяется редко. Но это дешевле, чем довести частоту access vioaltion до 1 раза в 10 лет.
Ибо лучше только тем, что любители забивать болт на ошибки получат по рукам.

И это очень правильно. Особенно во время обучения.

Зато всем остальным — приходится много от чего отказываться. Например — от обработки assert как ещё одного вида исключений.


Вы считаете что assert — это языковая конструкция? Почему нельзя написать свою имплементацию assert(), которая будет бросать исключение? Это можно сделать на любом языке, который поддерживает исключения как таковые.
От чего ещё приходится отказываться программистам на С++/другом популярном языке?
И это очень правильно. Особенно во время обучения.

Во время обучения — согласен. Но только во время него.

Почему нельзя написать свою имплементацию assert(), которая будет бросать исключение?

Можно, но что вы сделаете с библиотеками? Перекомпилите все используемые?

Вы считаете что assert — это языковая конструкция?

Вы понимаете отличие между внутренними и внешними процедурами? Или фортран не проходили?

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

Так вот, assert не просто определен в стандарте Си. Он ещё и внутренняя процедура. То есть кодогенерация на него — особая.

От чего ещё приходится отказываться программистам на С++/другом популярном языке?

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

Другой пример — в С++ нельзя создавать свои ключевые слова, как в forth.

Зато в С++ много своих достоинств, которых нет в других языках. Тот же макропроцессор + шаблоны.

Ну не одинаковые языки, не одинаковые.
Рассмотрим win/linux в linux вы можете перехватить sigabrt и бросить как вам уже показали, В Win32 вы можете точно также поймать его и в __except блоке выбросить что вам нужно
Гм, у нас или стандарт и SIGABRT или непонятно какой диалект.

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

Часть проблем это решает. Но не все. Проблема деструкторов в локальных объектах библиотечных функций остается.
Да, вы правы про SIGABRT его шлют при assert raiseом в __wcassert. Но.
sigfpe не
#include <windows.h>
#include <stdio.h>
#include <signal.h>
LONG ExFilter(unsigned long code) 
{
  return (code==EXCEPTION_INT_OVERFLOW) ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH;
}  
void FpeHandler(int)
{ 
  printf("handled by signal\n");
}
int main()
{
  signal(SIGFPE, FpeHandler);
  __try
  {
    int a = 1 / 0;
  }
  __except(ExFilter(GetExceptionCode())
  {
    printf("Handled by SEH\n"); 
  }
  return 0;
}
и т.к код обработки seh может быть и установлен не вами, полагаться под win32 на наличие сигналов (кроме SIGABRT) бесмыссленно
Знаете, если бы ваш пример компилился — я бы вам даже поверил. Но отсутствие закрывающей скобки в __except показывает, что Вы свой пример не запускали. Потому что результат: handled by signal

Исправленный пример
#include <windows.h>
#include <stdio.h>
#include <signal.h>
LONG ExFilter(unsigned long code)
{
return (code==EXCEPTION_INT_OVERFLOW)? EXCEPTION_EXECUTE_HANDLER: EXCEPTION_CONTINUE_SEARCH;
}
void FpeHandler(int)
{
printf(«handled by signal\n»);
exit(0); // Сигнал возвращает нас в точку ошибки,
// а не на следующую инструкцию
}
int main()
{
signal(SIGFPE, FpeHandler);
__try
{
int zero=0; // Деление константы на константу оптимизируется
int i = i/zero; // значение неиспользуемых переменных
printf(«i=%d\n»,i); // не вычисляется
}
__except(ExFilter(GetExceptionCode()))
{
printf(«Handled by SEH\n»);
}
return 0;
}

одна тонкость из signal.c
/*----------------------------- NOTE! — Normal ANSI operation resets ALL signals, Microsoft® doesn't reset SIGFPE.
Remove ANSI_CONFORMING define for MS style SIGFPE operation.
Default configuration is ANSI conforming SIGFPE operation.

Собственно целое деление — плохой выбор для демонстрации сигнала плавающей точки. MS любит идти своими путями и вполне мог именно для FPE_INTDIV0. Кроме того у MS довольно интересная оптимизация:

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

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


Так что для MS VS++ код придется править, а на BCB, увы, работает.

P.S. Было бы полезней, если бы вы были правы, но увы.
забыли про /fp:strict /fp:except ладно не любите SIGFPE вот SIGILL pastebin.com/5fHXtPT8 тоже скажете оптимизации?
P.S ваш «исправленный код с fpe тоже ловится SEH exception просто нужно не EXCEPTION_INT_OVERFLOW(с которым я налажал да) а EXCEPTION_INT_DIVIDE_BY_ZERO
Отлично!!! Давайте подытожим, что у нас вышло:

  1. Сигналы работают везде, где ОС дает такую возможность. И в Windows и в POSIX и где угодно.
  2. На Windows в двух компиляторах из четырех (только VS++ и BCB) есть более удобная конструкция __except.
  3. Эта конструкция работает так, что на локальной области позволяет перекрыть сигналы. При выходе из области — опять будут работать сигналы.


Что вам не нравится в этой схеме?
1)Обработка исключений может быть не только в _except блоке е veh обработчики и top-level exception filter Ну мне не нравятся 2 вещи 1) если вы пишете приложение вставляете в него обработчики своих сигналов (хукаете signal чтобы не переопределяли )и используете сторонние библиотеки которые могут сделать вам AddVectoredExceptionHandler(1,libhandler) и похерить вашу обработку сигналами. 2)множество исключений сильно больше множества сигналов, если защищаться то придется и их обработчики писать
Сторонние библиотеки способны очень много что сделать. Например — найти в коде все открытия файлов и удалять каждый открываемый файл. При этом даже не надо линковаться с библиотекой — достаточно внедрить DLL в адресное пространство процесса. Так работает часть вирусов.

Вопрос в том, зачем библиотеке это делать? Есть идеи, зачем писать (и использовать) библиотеки только для windows? Есть идеи, зачем писать (и использовать) библиотеки, которые не пойдут на gcc/clang?

Если я использую сигналы — значит мое приложение рассчитано на мультиплатформенность. Значит — gcc/clang и мультиплатформенные библиотеки.

множество исключений сильно больше множества сигналов

Пример приведите, плиз. Что там у нас не обрабатывается в singnal.c?
Пример приведите, плиз. Что там у нас не обрабатывается в singnal.c?

signal — 6 сигналов
GetExceptionCode — 23 разных кода

И что? Вопрос был — какое структурное исключение не обрабатывается как сигнал. А вовсе не о том, что информация о конкретном типе исключения передается как сабкод.

P.S. для ответа на вопрос — откройте signal.c

"The SIGILL and SIGTERM signals are not generated under Windows. They are included for ANSI compatibility. " Вот и ответ на ваш вопрос

SIGTERM не имеет отношения к структурным исключениям, это сигнал снятия задачи от утилиты Kill без флага -9.

Что касается SIGILL, то взгляните на кусок кода от signal.c из BCB
case XCPT_ILLEGAL_INSTRUCTION:
Index = SIGILL_INDEX;
FpeCode = ILL_EXECUTION;
break;

case XCPT_PRIVILEGED_INSTRUCTION:
Index = SIGILL_INDEX;
FpeCode = ILL_PRIVILEGED;
break;

case STATUS_BREAKPOINT:
Index = SIGILL_INDEX;
FpeCode = ILL_BREAKPOINT;
break;

case STATUS_SINGLE_STEP:
Index = SIGILL_INDEX;
FpeCode = ILL_SINGLE_STEP;
break;


То, что MS VС++ в очередной раз показал свою нестандартность — не удивляет. Ну или стандарты — или MS. Бизнес-стратегия у них такая. К gcc/clang/bcb какие претензии?

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

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

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

В итоге шанс что программа поломает данные, а мы этого не поймем — поменьше, чем шанс, что сдохнет винчестер.

Мне это обсуждение очень напоминает спор о вкусе устриц с тем, кто их ел.

Мне любопытно, как вы посчитали эту вероятность — 99%? И как вы будете определять, что не восстановились и надо падать, если в этом 1% вы в другом месте программы тихо запишете на диск повреждённые данные, например, или используете их в расчётах? Вы выше приводили пример с оборудованием — вы готовы к тому, что на сто сбоев один вам принесёт убытка на 100 тысяч? Мне кажется, что фраза "по опыту" едва ли должна звучать в embedded, тем более в safety critical / mission critical.


И да — я ел устрицы, спасибо. :)

Посчитал — по опыту. В процессе отладки порчи памяти были.

И как вы будете определять, что не восстановились и надо падать,

Счетчиками. 3 нештатных исключения в течении минуты — значит надо завершаться. При порче памяти на самом деле их возникает десятки.
если в этом 1% вы в другом месте программы тихо запишете на диск повреждённые данные,

Вопрос из серии «вы перестали пить коньяк по утрам, да или нет?». :-)

Вы понимаете, что вероятность записать поврежденные данные у вас больше, чем у меня? Потому что у вас большой шанс их записать до получения access violation, а у меня примерно по ассерту на каждые 15-20 строк.

Это ещё одна особенность дельфи — assert вызывает исключение, а не завершение программы.

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

вы готовы к тому, что на сто сбоев один вам принесёт убытка на 100 тысяч?

Ну давайте посчитаем. Мы довели программу до уровня — за месяц ни одного бага. Включая опечатки в текстовых строках. Шанс ошибки расцениваю как 12 раз в год. Разумно? Из ошибок access violation — 10%. Порча памяти — это 10% от access violation. Глобальная порча памяти (испорчен не один класс), а много кто — 10% от порчи. Глобальная порча без нарушения структуры кучи (а структура тоже проверяется) — 10%.
Все 4 цифры — скорее завышены, чем занижены.
Итого 0.0012 фатального сбоя в год.

Иными словами — да, раз в 500 лет я готов к сбою с убытком в 100 тысяч рублей. Даже к сбою на 40 тысяч долларов готов. Экономический эффект напрямую от программы — не меньше полмиллиона долларов год.

Не напрямую… Только сядьте… Благодаря данным нашей программы рулон стали стал выпускаться раз в 40 минут, а не раз в час. Посчитайте эффект сами с учетом цены рулона.

Так что готов. И заказчики готовы.

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

Наши — не готовы. У наших минимум 3 года подряд (пока я отслеживал систему) было «ни минуты простоя в год по вине службы автоматики». И это не только мы, а весь комплекс программ, работающих на стане.
3 нештатных исключения в течении минуты — значит надо завершаться.

То есть вы судите о природе неизвестной вам ошибки, которая, возможно, оставила вашу программу в нерабочем состоянии, на основании некой эмпирически выведенной для вашего проекта частоты возникновения ошибок? Ну… хорошо. :)


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

У меня, это если при access violation падать? Тогда у вас должна быть вероятность меньше нуля. Потому что я не предполагаю записывать данные вообще, если уж такое произошло.


Ну давайте посчитаем. Мы довели...

То есть вы не готовы к тому, что однажды жарким летом где-то остановится вентилятор и перегревшийся (вы вроде выше приводили такой пример) процессор начнёт давать вам сбои чаще ваших эмпирических цифр? Или поставят дефектную память? Или возрастёт ЭМИ?


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

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


Извините, но я даже уже не знаю, как дискутировать дальше, когда идут апелляции к опыту и неким эмпирическим данным с одного проекта. Я вам говорю о конкретных рисках, а вы мне "мне мой опыт подсказывает" и "у нас всё так редко глючит, что можно с уверенностью сказать: выкарабкиваться из access violation безопасно". Я пью чай по утрам, и на меня никогда не нападал динозавр. Я нашёл средство против динозавров? Это несерьёзно.

То есть вы судите о природе неизвестной вам ошибки, которая, возможно, оставила вашу программу в нерабочем состоянии, на основании некой эмпирически выведенной для вашего проекта частоты возникновения ошибок? Ну… хорошо. :)

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

У меня, это если при access violation падать?

У вас — это получить порчу памяти без AV. Просто ошибка ±1 при индексации массива. У меня на это есть контроль инвариантов, а у вас что?

То есть вы не готовы к тому, что однажды жарким летом где-то остановится вентилятор и перегревшийся (вы вроде выше приводили такой пример) процессор начнёт давать вам сбои чаще ваших эмпирических цифр?

То есть мы и к этому готовы. Два компа в двух помещениях, у каждого — отдельное питание от отдельной электросети, две сетки между ними…
Просто не надо это ставить единственным рубежом обороны.

Это если вместо попыток ковылять дальше с риском 1% (в вашем случае)

Вообще-то риск — 0.1% в год. При падении — риск намного выше. Ну вот взяли и решили резервный сервер от пыли почистить. Или UPS у него сгорел.
На опытно-промышленной эксплуатации как-то 3 недели работали без резервного сервера. Причину уже подзабыл, кажется UPS по гарантии меняли.

Я вам говорю о конкретных рисках, а вы мне «мне мой опыт подсказывает»

Ну так подсчитайте риски, исходя из своего опыта.

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

Давайте данные — подсчитаем вероятность для вашего проекта. И порчи памяти без AV и какой процент AV был вызван порчей памяти.

Уже писал, что мы везде использовали FreeAndNil, так что вместо use after free с порчей памяти мы получали AV.

Я пью чай по утрам, и на меня никогда не нападал динозавр. Я нашёл средство против динозавров? Это несерьёзно.

Для меня наш спор выглядит так:
— Не ходи на улицу, на тебя может упасть самолет.
— Вот статистика, вот расчет вероятностей, шанс — один раз в тысячу лет.
— Все равно не ходи, а вдруг он упадет.
— Так меня может и дома падающим самолетом убить.
— Это несерьёзно! Все равно не ходи!

Мне грустно, что наш спор идет на таком уровне. А вам?
У вас — это получить порчу памяти без AV. Просто ошибка ±1 при индексации массива. У меня на это есть контроль инвариантов, а у вас что?

Каким образом вы от поведения при AV перешли к отсутствию контроля инвариантов у оппонента?

Вот цитата:
если в этом 1% вы в другом месте программы тихо запишете на диск повреждённые данные, например,

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

Если человек боится порчи данных при AV — значит он от порчи данных не страхуется вообще.

Ну подумайте, вы вышли за границы массива (частая причина порчи данных). Что вы потрете с большей вероятностью? Указатель или соседние данные?
Если ваша программа падает с segfault — в ней есть ошибка. Так нам говорит стандарт языка.

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

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

Это элементарно. Важные данные храним в двух копиях, защищенных CRC.

логичнее проверять указатель на NULL, если он может быть NULL,

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

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

Думаете лучше потерять 100 тысяч рублей, чем тысячу? Интересная у вас экономика.

Мой опыт показывает, что можно написать приложение так, что несмотря на все ошибки за 15 лет работы 365 на 24 оно ни разу не потеряло данные. Да, это дорого. 30% стоимости ушло на обеспечение надежности. Да, там в качестве последнего резерва сдублировано все — сервера, сети…

Но отлаживались бы мы до полного исключения багов — лет 50. Хотя бы потому, что баги редки. А на дельфи мы отладились до состояния — ни одного бага за месяц. Остальное — та самая многоуровневая система безопасности. В начале — пересоздание объектов. Не помогло — перезапуск подсистем (threadов). Совсем не помогло — ну тогда переход на резервный сервер по принципу мертвой руки.

В этом и есть преимущество дельфи — на нем можно написать систему с такой надежность.

P.S. Особый смак — на комплексную отладку на стане было 2 часа в месяц. Цена сбоя — 40 тысяч долларов (рулон стали, улетевший в брак). Космическое исполнение там не годилось — в космосе за месяц не выпадает миллиметр металлической окалины. :-)

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


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

А стандарт нам говорит вот что:

Undefined behavior — behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately-valued objects, for which the Standard imposes no requirements. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

и
Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, or the address of an object that has automatic storage duration when execution of the block in which the object is declared and of all enclosed blocks has terminated.

Это именно то что приводит к Access Violation на винде.

Это элементарно. Важные данные храним в двух копиях, защищенных CRC.

Что есть «важные данные»? Я думаю что «важные данные» — это полное состояние программы. А вы?

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

Нет, это же вы предложили делать dereference потенциально нулевого указателя. Я предлагаю проверять такие указатели перед разыменованием.

В этом и есть преимущество дельфи — на нем можно написать систему с такой надежность.

Точно то же самое можно сделать ещё на куче других языков. Более того, существуют десятки языков, которые просто не позволят вам допустить Access violation, если вы ими правильно пользуетесь. Я не вижу тут никаких преимуществ delphi.

P.S. Особый смак — на комплексную отладку на стане было 2 часа в месяц. Цена сбоя — 40 тысяч долларов (рулон стали, улетевший в брак). Космическое исполнение там не годилось — в космосе за месяц не выпадает миллиметр металлической окалины. :-)


Думаю, каждый из нас может рассказать такие или похожие истории из жизни. Я за свою жизнь успел и поуправлять термопринтером на низком уровне (упадешь в исключение или зазеваешься — аппарат тупо загорится синим пламенем), попроводить платежные транзакции (допустишь ошибку — компания попадет на деньги), попрограммировать автомобильные headunit'ы и всякое другое. Поэтому, я считаю, что anecdotal evidence — это аргумент в споре.
Упс. Последнее предложение следует читать как «Поэтому, я считаю, что anecdotal evidence — это не аргумент в споре.»
В системном вызове программа упасть не может, потому что не исполняется.

Да ну? Вполне себе падает в юзерспейсе. Во-первых часть вызовов вообще не идет в kernel space, во вторых ещё часть перед и после вызова ядра проходят обработку в библиотеке. например, у нас летел CharToOemBuff из user32.dll. Вполне себе системный вызов из WINAPI. Там, кажется, нужно было выравнивание на четырехбайтовую границу, о чем в документации не написано.

Нет, это же вы предложили делать dereference потенциально нулевого указателя. Я предлагаю проверять такие указатели перед разыменованием.

Откуда вы этот бред взяли? Проверять — надо. Но это не отменяет AV. Бывает все, что угодно, вплоть до сбоев памяти и процессора. Эффектов очень много, например — гонка.

Более того, существуют десятки языков, которые просто не позволят вам допустить Access violation, если вы ими правильно пользуетесь.

Приведите хоть один пример такого языка. Примеры AV в java, c# и kotlin я уже приводил.

Я за свою жизнь успел и поуправлять термопринтером на низком уровне

Тогда странно, что:

  1. Вы считаете, что любую программу можно отладить до уровня ни одного AV за 100 лет.
  2. Вы не понимаете, что причиной AV может быть перегрев, импульсная помеха по питанию, радиоактивный источник, сдыхающий процессор, трещина в плате и вообще черти что.
  3. Вы не цените механизм, позволяющий свести ущерб от AV к минимуму.

Вот как это у вас в голове совмещается?
Да ну? Вполне себе падает в юзерспейсе. Во-первых часть вызовов вообще не идет в kernel space, во вторых ещё часть перед и после вызова ядра проходят обработку в библиотеке. например, у нас летел CharToOemBuff из user32.dll. Вполне себе системный вызов из WINAPI.

Вроде бы по определению, системный вызов исполняется в контексте ядра.

Откуда вы этот бред взяли?

Вот отсюда:

Как пример. Имеем сложное представление данных в памяти в виде стрeктур с указателями. И просто плоское представление, в которое иногда, со всеми предосторожностями сохраняем. Если мы сломали структуры — то получаем исключение и пересоздаем структуры из плоского представления.


Приведите хоть один пример такого языка. Примеры AV в java, c# и kotlin я уже приводил.

Давайте не будем путать язык с его имплементацией. Если у Delphi есть одна «правильная» имплементация которая выступает как образец, то это не значит что все языки такие.

Вы считаете, что любую программу можно отладить до уровня ни одного AV за 100 лет.

Я такого не утверждал. Мне вообще слабо понятна такая метрика.

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

Скажите, вы сталкивались с таким на практике? Я сталкивался. Обычно в результате таких штук страдает состояние процессора (просто потому что в процессоре чаще всего используется более мелкий процесс и он работает на больших частотах/меньших напряжениях). Как побочный эффект мы можем получить Data abort/Prefetch abort/Access Violation. Но беда в том, что это побочный эффект. В каком состоянии находится процессор уже неизвестно. Поэтому — только аппаратный сброс.

Вы не цените механизм, позволяющий свести ущерб от AV к минимуму.

Вы смешиваете аппаратные ошибки с ошибками программиста и хотите исправлять эти ошибки одинаково. Это абсолютно неправильно.

Вот как это у вас в голове совмещается?

Просто я очень много и очень близко работал с железом. И видел совершенно феерические баги. Как программные, так и аппаратные. Поэтому я знаю что нельзя грести все под одну гребенку. Я рад, что ваша программа стабильна и зарабатывает миллионы. Но у меня опыт немного шире вашего и я могу смотреть на проблему с разных углов.
Вроде бы по определению, системный вызов исполняется в контексте ядра.
Есть два понятия. Одно вызов системной процедуры (WINAPI или POSIX), другое — собственно trap в ядро. Я имел ввиду первое. А оно иногда обрабатывается в userspace. Или как в windows — в зависимости от версии код GDI сидит или в ядре или в юзерспейсе.

Откуда вы этот бред взяли?
Вот отсюда:
И где там же там «предложили делать dereference потенциально нулевого указателя»? Из какой фразы вы это вывели?

Скажите, вы сталкивались с таким на практике? Я сталкивался.
Угу. Даже с процессором с отломанным уголком кристалла работал. Кстати, жил почти нормально, только пару раз в день kernel panic. А на импульсную помеху у меня реагировала клавиатура (1993 год). Пришлось писать программку для перезапуска и вызывать её мышкой.

Как побочный эффект мы можем получить Data abort/Prefetch abort/Access Violation. Но беда в том, что это побочный эффект.
А счастье в том, что этот эффект повторяется часто. Это не разовый сбой раз в час. Это череда сбоев много раз в секунду. Потому и по счетчику сбоев передадим управление резервному серверу. Или зависнем — и передача управления по принципу мертвой руки.

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

И видел совершенно феерические баги.
Будем меряться опытом? Баги в микрокоде процессора видели? А баг в процессоре, из-за которого 2==16 видели? А сдохший конденсатор, из-за которого бит С менял значение там, где не должен был?
В С++ это точно такой же аппаратный exception, который можно обработать. С точно такими же удобными конструкциями try..catch — разницы с Delphi в этой области вот вообще никакой.
Да ну?? Ссылочку на описание, плиз! Visual Studio позволяет транслировать аппаратные исключения в exception. gcc/clang этого не умеют, ибо в стандарте нет.

Ну и catch без finally неудобен. А finally — есть только в дельфийском С++. Ну и ещё в VC++, вроде. Опять gcc/clang в пролете.

Нет, finally можно сделать, если нужно, а вообще авторы C++ дали вам для этого деструктуры, как утверждают там же.

RAII — это не finally, это замена. Причем во многих случаях — неудобная замена.

Собственно неудобства:

  1. Приходится писать объект с пустым конструктором только ради отработки деструктора.
  2. Деструктор пишется совем в другом месье кода, чем исполняется. В итоге алгоритм расползается по куче частей (деструтор, создание объекта, вызов дестурктора).
  3. Чтобы поменять местами порядок в finally, приходится менять местами создание объектов.
  4. Finally вставляется явно и делает только то, что явно написано. Деструкторы отрабатывают всегда все. То есть, если не нужна отработка дестурктора при исключении — приходится изворачиваться. А специфика access violation в том, что деструкторы многих вещей скорее выдадут вторичное исключение, чем сделают нечто полезное.

P.S. Не стоит спорить о вкусе устриц с теми, кто их ел. Напишите свое отказоустойчивое приложение и запустите его в режиме 365*24. Тогда многое вам увидится совсем в другом свете.

Finally на лямбде можно сделать, если вам надо. Единственный минус, который я вижу — это то что блок finally будет перед try...catch. Все пункты, которые вы привели, вроде бы адресованы.

Извратиться можно. Но — неудобно. И пункт 4 это не исправит. Потому в VC++ и C Builder и вставили __finally.

Почему не исправит? Тот finally из ссылки как раз вставляется явно и делает то, что вы в теле лямбды написали.


Синтаксис — вопрос вкуса; во всяком случае кода в месте использования получается ненамного больше чем если бы finally был нативный. В любом случае, мы уже перешли из области "надо но нет" в область "есть но [мне] неудобно", об этом уже мало смысла спорить.

Потому что пункт 4 — он о том, что при исключении выполнится любой деструктор. В том числе — и библиотечные. А у нас — access violation. То есть структуры данных разрушены. И деструкторы писать надо очень аккуратно.

Итог — придется переписать значительную часть библиотечного кода. Ибо одно дело — при ошибке закрыть все клапаны и заново создать все нужные структуры. Другое — когда у нас выполняются все деструкторы с черт знает каким побочным эффектом. И, как уже написали, вторичная ошибка в деструкторе вызовет std::terminate();

Так что единственный выход — локальные объекты писать только свои и только для реализации finally. И не переписать весь библиотечный код, использующий локальные объекты.

Не понимаю. Мы говорим про вот эту конкретную конструкцию, заменитель finally. Никто не заставляет вас писать и использовать какие-то другие деструкторы, вы можете вообще писать на C++ как на C если захотите. Код из примера выполняет как раз то, что вы написали в теле лямбды. Вы начали с жалобы на то, что в языке нет finally, а закончили жалобой на то, что в языке существуют деструкторы (в том числе в библиотеке). Это разные вещи.


А у нас — access violation. То есть структуры данных разрушены. И деструкторы писать надо очень аккуратно.

Во-первых, мы сейчас обсуждаем наличие/отсутствие в языке try...finally. Access violation вы обсуждаете в другой ветке. :) Во-вторых, если у вас структуры разрушены, сделайте самую безопасную вещь для своих данных — сделайте дамп стека, упадите и поднимитесь снова. Не полагайтесь на то, что у вас ещё есть откуда создавать эти структуры.


И, как уже написали, вторичная ошибка в деструкторе вызовет std::terminate();

Вам написали и про то, что и в Delphi это считается дурным тоном — бросать исключения из finally. В официальной документации тоже не рекомендуется. Вы так часто полагаетесь на эту часть семантики finally, что вариант из C++ вам не подходит?

Никто не заставляет вас писать и использовать какие-то другие деструкторы

Из try-блока я вызываю другие процедуры. Из них библиотечные. В библиотечной — есть локальные объекты (например std::string). И что мне делать, если access vioaltion возникает в библиотечной процедуре?

сделайте самую безопасную вещь для своих данных — сделайте дамп стека, упадите и поднимитесь снова

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

А самолет тоже предложите во время полета перезапустить? :-) Там дублирование, конечно, но это не отменяет факт, что при сбое нужно выходы привести в безопасное состояние. И не все, а лишь задетые сбойной операцией.

Вы так часто полагаетесь на эту часть семантики finally, что вариант из C++ вам не подходит?

ДА. я полагаюсь, что если в библиотечном коде возник access violation, то исключение до меня дойдет. Независимо от того, используются ли в этом коде локальные объекты или нет. Более того, мне все равно, какое исключение я получу из библиотечной функции — первичное или вторичное (из деструктора).
И что мне делать, если access violation возникает в библиотечной процедуре?

Я уже выше написал, что делать при access violation, нет? :) Упадите. Вы не можете в общем случае прогнозировать, что сделает ваш код, если состояние программы неконсистентно.


Это — полная потеря состояния. У нас есть стан с сотней задвижек. Мы открыли пару для перекачки. <...>

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


Самолёт — да, тоже, кстати. С конкретно авиатематикой я не связан, но там тоже падение одной конкретной системы не должно вызывать падение самолёта. Вот вам из MISRA-C "Rule 20.8 (required): The signal handling facilities of <signal.h> shall not be used." Так что нет у вас возможности отреагировать на access violation, согласно стандартам индустрии. Корректный дизайн оборудования должен это тоже покрывать.


Зачем вам нужно получать сигнал об access violation именно исключением в таких условиях — я даже спрашивать не буду. Просто напомню, что мы обсуждаем наличие/отсутствие в языке finally, а не проброс access violation в исключения, эти вещи никак не связаны. :)

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

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

ДА. Неконсистентное состояние с сохранением всех детерминатов (контрактов), это фантастическая редкость. Ну это примерно как сбойные данные по TCP. Да, может быть коллизия контрольной суммы, но вы хоть раз о таком слыхали?

Так что шансы на редкий баг портящий данные без access violation, они побольше, чем порча данных при access violation, но без нарушений детерминатов. Первое — это, например, ошибка типа ±1 при индексации массива. Никакого AV нет, но данные не верны.
А при AV порча памяти либо портит довольно большую область (и тогда летят и детерминанты и структура кучи) либо причина AV — вовсе не порча памяти, а преждевременное освобождение объекта с обнулением ссылки на него. Второе — бывает раз в 10-50 чаще.

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

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

А реально… Вы что думаете, мы отладили систему, а потом приделали к ней механизмы восстановления? Реально при любой ошибке прежде всего отлаживались механизмы восстановления, потом механизмы контроля (чтобы обнаруживать ошибку до AV), а уж потом — правился баг.

Поэтому те цифры, что я говорю — они взяты из реальной отладки. И на реальной отладке было видно, что никакой порчи данных нет. Или восстановились, или имеем постоянные AV + assert. А на этот случай сделаны счетчики, которые эскалируют проблему дальше. с объекта — на подсистему, с подсистемы — на уровень перезапуска компа с передачей управления резервному серверу.

Просто напомню, что мы обсуждаем наличие/отсутствие в языке finally, а не проброс access violation в исключения, эти вещи никак не связаны. :)

Оно только в комплексе работает нормально: аппаратные исключения, finally, куча assert в итоговом коде, тройное закрытие ошибок, отладка до уровня «ни одного бага за месяц» + все известное закрыто. Убрать один из компонентов — станет ненадежно.

Мораль в том, что на delphi этот комплекс сделать — это 30% стоимости проекта. А С++ — наверное 70% будет.

Потому там, где нужна надежность и не нужна переносимость во всё, что можно — там лучше Delphi. Или что-то паскалеподобное, например АДА. А там, где нужна переносимость — там Си. Ну или С++.

P.S. Ещё не щупал rust и go. Так что о них ничего не скажу.
А самолет тоже предложите во время полета перезапустить? :-)

Отгадайте, на каких языках пишуется бортовые системы самолётов?
Намекну, что не на Delphi.
На чем угодно, зависит от критичности. Наша нынешняя часть — на Си с элементами С++ под FreeRTOS. Это для беспилотника.

То, что критично — скорее всего на АДА, то есть на развитии того же паскаля/дельфи.
НЛО прилетело и опубликовало эту надпись здесь
Самое главное тут — «в том числе». Как известно, софт для миссии на Марс писали на фортране. Это что, что-то говорит о преимуществах фортрана или GOTO?

У Си/C++ есть преимущества для baremetal: переносимость, накопленная кодовая база, распространенность (доступность девелоперов), малое использование ОЗУ.

Ровно те же преимущества были у фортрана.

А повторит ли C/С++ судьбу фортрана и PL/1 — увидим через 30 лет.
Насколько я знаю, ADA — основной язык военки в США.
Как известно, в ответ на разработку языка Ада русские развернули преподавание в школах на языке Рая (он же Ершол).

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

Боинг — на ADA, ИЛ-96 ( по слухам) — тоже

P.S. На Си, говорят, тоже можно
надо только макрос «eq» завести
и в if-ах сперва цифру потом eq потом переменную

P.P.S. И что только не придумывают «только бы не строить дороги» Ж-)

P.P.P.S. Ми-6 + Ми-26 Ж-)

Вы так пишите как будто __finally как-то блокирует выполнение библиотечных деструкторов :-)

В Delphi деструкторы вызываются явно. Так что есть выбор — вызывать их перед finally (отработают только если не было ошибки) или после (отработают всегда).

Это ещё одна причина, почему системы 365*24 лучше писать на дельфи.

Деструкторы COM-объектов в Delphi вызываются в том числе и неявно.


Кстати, в С++ возможность отключить автоматический вызов деструктора тоже есть. Надо всего-то поставить звездочку и написать new.


А еще при желании можно сделать обертку, которая будет блокировать освобождение памяти в случае AV.

И каждую библиотечную процедуру переписывать? Или только ту тысячу, что вызывается из кода? Про оверхед при размещении объектов в куче вместо стека и не говорю
Делфи гибче в вызове деструкторов а также (насколько я знаю) предковых методов (inherited).
Намного важнее, что дельфи гибче в плане делегирования. В дельфи мы передаем ссылку на конкретный метод конкретного экзепмляра.

А все вместе, включая недоООП, позволяет прощать ошибки проектирования. То есть вместо «Шэф, мы без рефакторинга жить уже не можем», будет «Ну да, чуть некрасиво, но работает же!».

Вы забыли главное отличие. Для finally допустимо выкидывать свои исключения. Это хоть и считается плохим тоном — но не убивает программу. А вот исключение из деструктора вызывает std::terminate();


Все остальные отличия — просто дело привычки.

Спасибо!
Все остальные отличия — просто дело привычки.

Так-то оно так. Подходы вида finally и RAII уж очень различаются, и в ряде случаев finally просто легче читается. Ну скажем, простой пример — нам надо закрыть соединение в конце работы. В одном случае мы можем это сделать напрямую, в другом надо создавать отдельный объект, непосредственно контроллирующий это соединение и закрывающий его при автоматическом уничтожении.
Здорово иметь возможность комбинировать оба подхода.

Выделения такого объекта требует не только принцип RAII, но и базовые принципы ООП. И приличные библиотеки такой объект предоставляют.

Нет, я наверно выразился недостаточно ясно — объект, контроллирующий соединение, есть в обоих случаях. Есть ситуации, когда нам нужно что-то сделать гарантированно, в случае проброса исключения — тоже. И в случае с RAII системой мы можем сделать это только через автоматически вызываемый деструктор. Т.е. для выполнения такого действия надо создавать какие-то обертки.
НЛО прилетело и опубликовало эту надпись здесь
Угу, в среде тех, чьи программы регулярно падают без сохранения данных, рассказы, что можно писать надежно — это ересь. Причем жуткая ересь. Не удивлюсь, если и карму сольют ниже нуля.

Это как раз я хорошо понимаю.
НЛО прилетело и опубликовало эту надпись здесь
Деструктор пишется совем в другом месье кода, чем исполняется. В итоге алгоритм расползается по куче частей (деструтор, создание объекта, вызов дестурктора).

И это говорит адепт языка, в котором переменные нужно объявлять за километр от того места, где они впервые используются?
Не пишите функций длиной километр. На самом деле это воспринимается примерно как необходимость писать заголовок функции и в .h и в .cpp.

А почему адепт? Последние лет 10 я пишу на Си. У него тоже есть свои преимущества. Просто систему 365*24 лучше писать на дельфи. А переносимый код или embeded — на Си.
НЛО прилетело и опубликовало эту надпись здесь
По опыту, исключительно по опыту. Описание переменных в начале функции проблем не вызывает, а описание там же вложенных функций — обычно мешает чтению.

Не знаю, почему так. Возможно описание переменных воспринимается как данные. В конце концов в си параметры тоже описывают в заголовке функции и это ни у кого проблем не вызывает.
НЛО прилетело и опубликовало эту надпись здесь
Да
переменные нужно объявлять за километр от того места, где они впервые используются
Если нужны «блоки» — возьмите ADA.
В Pascal, кстати, есть вложенные процедуры ( в Си — нет) тоже может помочь
СПАСИБО! Плюс вам в карму. Будете в Питере — с меня кофе.

Если удастся запустить на FreeRTOS — будет отлично.
Подсказка Kernelbase!RaiseException(генерящий SEH) при столь любимых вами аппаратных exceptionах вызывается не рантаймом msvc а вполне себе самой виндой
Угу, вот только по стандарту Cи оно транслируется в сигнал. Кроме того — есть ещё *nix. На железках — обычно Linux и FreeRTOS, а не windows.
В стандарте C нигде не написано что такое аппаратные исключения и что они должны транслироваться в сигналы.Как выше уже заметили никто не гарантирует вам что сигнал от ос будет вам послан. В Win32 классический способ обработки это перехват или обработка SEH
Почитайте стандарт (раздел 7.14):

SIGABRT abnormal termination, such as is initiated by the abort function
SIGFPE an erroneous arithmetic operation, such as zero divide or an operation resulting in overflow
SIGILL detection of an invalid function image, such as an invalid instruction
SIGINT receipt of an interactive attention signal
SIGSEGV an invalid access to storage
SIGTERM a termination request sent to the program

Гарантий нету (реализация не обязана), но есть рекомендация. Поэтому все делают именно так, как рекомендовано в стандарте.

Поправка: не по стандарту Си, а по стандарту POSIX.

Читаем стандарт С99:

SIGABRT abnormal termination, such as is initiated by the abort function
SIGFPE an erroneous arithmetic operation, such as zero divide or an operation resulting in overflow
SIGILL detection of an invalid function image, such as an invalid instruction
SIGINT receipt of an interactive attention signal
SIGSEGV an invalid access to storage
SIGTERM a termination request sent to the program


Читаем обоснования С99:

7.14 Signal handling <signal.h>

This facility was retained from /usr/group since the C89 Committee felt it important to provide some standard mechanism for dealing with exceptional program conditions. Thus a subset of the signals defined in UNIX were retained in the Standard, along with the basic mechanisms of declaring signal handlers and, with adaptations, raising signals (see §7.14.2.1). For a discussion of the problems created by including signals, see §5.2.3.

The signal machinery contains many misnomers: SIGFPE, SIGILL, and SIGSEGV have their roots in PDP-11 hardware terminology, but the names are too entrenched to change. The
occurrence of SIGFPE, for instance, does not necessarily indicate a floating-point error. A conforming implementation is not required to field any hardware interrupts.

В C/C++ это undefined behavior.
А вот на каких-то платформах это может выливаться в segmentation fault.
С++. Вы что, никогда не видели, как падает word?

У современных языков вылетает программная ошибка на уровне виртуальной машины, которая вполне себе обрабатывается. А говорить что потеряются данные от Access Violation везде кроме Dalphi — так от синего экрана они потеряются даже в делфи. Вот только для программиста Java синий экран наступит скорее, чем access violation.


Так что это какая-то надуманная проблема из серии "наша технология решает проблему Х… Ой, мы забыли сказать, что эта проблема есть только в нашей технологии".


Что касается устойчивости серверов — кластеры и только. Ну, можно Erlang — для любителей — но всё равно на кластере. Прямолинейный Паскаль для устойчивости подходит ничуть не лучше чем Питон.

Ну тогда давайте считать С++ архаизмом. :-)) Ибо основная конкуренция — именно с ним.

Что касается виртуальных машин — они не защищают от access violation из-за бага в самой виртуальной машине. Вот вам access violation в java, а вот он же в С#, а вот он же в Kotlin.

В каком ещё языке якобы не бывает access violation?
Кстати, да, в C# я уже сталкивался с двумя случаями, когда JIT-компилятор генерил некорректный код, и программа падала.
НЛО прилетело и опубликовало эту надпись здесь
Это не важно. Как факт — AV возможен. Ни один язык не даст полной защиты от него, ибо бывает перегрев процессора, сбои памяти, импульсные помехи, трещины на плате и так далее и далее.

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

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

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

P.S. Про инопланетян не знаю, а вот залет жука в процессор известен.
P.P.S. Когда на заводе стоит мегаватный двигатель в холостом режиме лишь для повышения косинуса фи, как-то странно шутить про импульсные помехи. Line-interactive UPS, разумеется стоит, но помеха может и сквозь него пройти.
что потеряются данные от Access Violation... — так от синего экрана они потеряются даже в делфи
На всякий: BSOD обычно ошибка минимум на уровне OS / драйверов,
а чаще всего — сбой «железа».
Delphi или нет в прикладном ПО не влияет

P.S. Хотя, есть ведь OS и на ADA. Говорят, что аки «крест животворящий» демонов синеэкранных изгоняет Ж-) ( на 3 дублированом HW, включая RAM)

Кроссплатформенный там сейчас новый GUI фреймворк (FireMonkey). Старый фреймворк VCL — тот да, только под Windows.

в целом не обладает рядом хоть каких-то удобных фич
Я оставил delphi очень давно

Вам не кажется, что эти высказывания противоречат друг другу?


Более того, delphi еще и не кросс-платформенный

Давно уже неправда.


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

  1. Мгновенная сборка проекта.
  2. Простота поиска и устранения утечек памяти.
  3. Простота оптимизации производительности.
  4. Нативное приложение без зависимостей на выходе.
  5. Способность работать и не жужжать на любом ПК заказчика.

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

Мгновенная сборка проекта.

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


Простота поиска и устранения утечек памяти.
Простота оптимизации производительности.

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


Нативное приложение без зависимостей на выходе.

Windows 7 из под коробки поставляет .Net 3.5, если не ошибаюсь. Пишите на нем и будет вам счастье.


Способность работать и не жужжать на любом ПК заказчика.

Это в тому, что потребляет меньше ресурсов? Сомнительная штука, с учетом того, что мы все-таки не про Python говорим, в C# вроде как нет оверхедов по памяти на каждую переменную.

> Это так не работает

Это именно так и работает. На скорость компиляции и сборки заточено все — от синтаксиса языка до формата объектных файлов. За совсем свежие версии не поручусь — может успели испортить. Типичный вариант — после правок в коде проект стратует под отладчиком раньше, чем успеваешь отпустить горячую клавишу. Там REPL нафиг не был нужен — компилятор справлялся быстрее.
Полная пересборка на мусорном уже тогда железе занимала меньше времени чем сейчас на аналогичном по размеру шарповом проекте с SSD и 16 гигами ОЗУ.

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

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

> Windows 7 из под коробки поставляет .Net 3.5, если не ошибаюсь

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

> Но это приводит к сложностям с манипуляцией памятью

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

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

Если правильно настроить сборку для C#, то получается точно так же, так как там есть точно такие же объектные файлы. Может быть парсится файл быстрее, но очень сомневаюсь, что это хоть как-то заметно.


более простого устройства кучи (лучше читаемого как человеком так и машиной дампа)

Это как? Например, для C# есть такая штука, которая позволяет получать такие картинки. Куда читабельнее?


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

Всегда можно упаковать с приложением еще и mono runtime, А рассуждения про недостаток ресурсов на машине заказчика можно продолжать до безумия, вплоть до того, что каждые 5 минут пользователь за комьютером будет убивать случайное приложение, но если заказчик не может выдать вам лишних 300 МБ в наше то время — это реально очень странно.


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

Я не говорю, что они сложнее, но они другие и за одно вы платите другим. Что не очень похоже на преимущество.

Если правильно настроить сборку для C#, то получается точно так же, так как там есть точно такие же объектные файлы. Может быть парсится файл быстрее, но очень сомневаюсь, что это хоть как-то заметно.

Нет по всем пунктам. У шарпа немало преимуществ перед дельфи, но скорость компиляции и сборки к ним не относится. И "точно таких же" объектных файлов там нет.
https://docs.microsoft.com/ru-ru/dotnet/csharp/language-reference/compiler-options/command-line-building-with-csc-exe


В результате вызова компилятора C# файлы объектов (OBJ-файлы) не создаются; выходные файлы создаются непосредственно. По этой причине компилятору C# не требуется компоновщик.

Это как? Например, для C# есть такая штука, которая позволяет получать такие картинки. Куда читабельнее?

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


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

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


Я не говорю, что они сложнее, но они другие и за одно вы платите другим. Что не очень похоже на преимущество.

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


в целом не обладает рядом хоть каких-то удобных фич

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

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

Я не совсем понимаю, что вы имеете ввиду. Delphi показывает в каких функциях у вас произошла утечка памяти? Или то, что там не нужно пользоваться сторонними утилитами? Алсо, это не картинка, а вроде как просто в Visual Studio открывается окно, где можно в момемнт выполнения программы просмотреть кучу. Что с ней можно делать кроме этого мне совсем не понятно.

Что с ней можно делать кроме этого мне совсем не понятно.

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


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

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

Два миллиона строк — 27 секунд — достаточно быстро?
Нет. Миллион, три секунды — достаточно. Delphi. Я вообще не представляю, как можно проект медленнее нескольких секунд собирать. К хорошему, увы, привыкаешь быстро.
Во-первых, у меня достаточно слабая машинка с медленным IO плюс исходники на зашифрованном томе.
Во-вторых, скорость зависит от связностей модулей. 27 секунд — это самый медленный из проектов, второй собирается на моей машине (1.8 млн строк) за 13 секунд.
В-третьих я имею в виду, разумеется, полный rebuild. Так, на всякий случай. Ну и D7, старичок уже.
Жесткий у меня тоже не сильно что бы быстрый ) 4200 на буке. Ну и ребилд, конечно, иначе особо и смысла сравнивать нет :)

Видео (не моё :) ):

www.youtube.com/watch?v=Yq2mNUzcpE0
Это подстанова (с).
Посмотрите комментарии, там более прозаичные цифры, похожие на мои. Ну и да, 7ка же. Плюс модулей у меня под 2500. Но все равно, как ни крути, эти 13 и даже 27 секунд — это быстро по сравнению с сами знаете чем.
>2,045,960 lines of code (431 Object Pascal units) about 9
Скажем так — единицы секунд на миллион строк. Такой порядок. Медленнее — уже медленно. Я для ардуины кусочки писал, 30 секунд на компиляцию 50ти строк кода — это ад :)
Это 431 модуль, а не 2500 с перекрестными ссылками, как у меня.
Here: 1.07 million lines, 12 seconds, 1600 units of real, shipping code compiled in 12 seconds on an i5 with SSD

Это ССДшка, 12 секунд — сравните с моим 1,8 млн за 13.
Here is compilation time of some real production code: 2,045,960 lines of code (431 Object Pascal units) about 9 sec on (I7 2.8 GHz 16GB RAM, SSD)

Это I7 и ССДшка.
Сам пример в видео — синтетический, 1 модуль ни о чем.
НЛО прилетело и опубликовало эту надпись здесь
Ну так и здесь вы можете не пересобирать модуль, если не хотите. Но это не отменяет того, что у меня целый проект в 2млн строк полностью пересоберется быстрее вашего модуля на 200.
НЛО прилетело и опубликовало эту надпись здесь
Скорость компиляции? Да, важно. Пусть будет не целый проект, а только набор модулей — уменя соберется за 1 секунду, вы будете курить десятки.
Вопрос удобства.
Я не говорю, что это прям вот самое главное, нет. Но приятно.
НЛО прилетело и опубликовало эту надпись здесь
Ну так вы каждый день код пишете, каждый день что-то компилируете. Не то, так другое.
НЛО прилетело и опубликовало эту надпись здесь
Ну, скажем так тогда: если мы берем бесконечное число модулей среднего размера и проверяем время компиляции каждого, оно будет стремиться к некоей величине вида строк/с. Если взять большой проект со множество разных модулей разного уровня связности, то скорость его компиляции в строк/с будет приближением той величины. Именно этим приближением, по сути, мы и меряемся.
Простота поиска и устранения утечек памяти.

Ха-ха.


Способность работать и не жужжать на любом ПК заказчика.

Если это правда — то откуда изо всех щелей лезут рекомендации ставить Delphi на компьютер заказчика?

Ха-ха.

Именно так.


Если это правда — то откуда изо всех щелей лезут рекомендации ставить Delphi на компьютер заказчика?

Пруфлинк на "все щели"? Мне вот как-то ни разу не довелось.

Delphi на компьютер заказчика? Вот это поворот. Я даже представить себе не могу, зачем это может понадобиться. Помнится только, что в Borland C++ Builder по дефолту надо было набор либ с собой таскать, но выключалось это одной галкой в настройках компоновщика.

Я, конечно, давно не тыкал палочкой это вот всё, но… это какие-то неправильные рекомендации :)

На самом деле там либо BorlndMM надо было поставить, либо BDE.


Но студенты-недоучки, дающие советы другим студентам-недоучкам на крупнейшем российском форуме для студентов-недоучек таких сложных слов не знали… :-)

Ха-ха.

Абсолютно.
Eureka + FastMM с полным MemLeakReport и все, с точностью до строчки.

Если это правда — то откуда изо всех щелей лезут рекомендации ставить Delphi на компьютер заказчика?

От отсутствия навыков. Ведь на каждом углу все кричат, что у дельфей низкий порог вхождения. Вот и результат, но это не норма.
Ха-ха.

А что хаха? Эврикалог, FastMM, MadExcpeption, JCL exception дадут место утечки и исключения до строчки + колл-стэки и еще кучу информации.
то откуда изо всех щелей лезут рекомендации ставить Delphi на компьютер заказчика?

Где такие, аж из всех щелей? :) Ни разу по форумам за 15 лет не видел. Инструменты я назвал, самые распространенные. Смысл Делфи где-то ставить?
Я так думаю, что эта байка («Ставить Delphi вместе с программой») родилась в те времена, когда некоторые разработчики собирали свои проекты с опцией пакаджей (bpl) в погоне за уменьшением размера exe-файла.
НЛО прилетело и опубликовало эту надпись здесь
Видимо потому, что вы не видите их трудов. Для вас микроволновка и стиральная машина — ну совсем не компы. Embeded — это довольно изолированная область. Но embedчики очень ценятся. Особенно full-stack, то есть разработка платы + написание софта под неё. Ну область такая, что иногда проще резистор припаять, чем пару строчек кода написать.
Ну область такая, что иногда проще резистор припаять, чем пару строчек кода написать

Занёс себе в цитатник
Так иногда резистор и вправду лучше. Резистор подтягивает GPIO с момента подачи питания, а программная инициализация — с момента этой самой инициализации.
А вот «дедушка Вирт» под языки программирования и ОС, и железо «подтягивал»
Де-факто, высокоуровневые резисторы припаивал Ж-)
Про железо — можно пруф? Де факто этим занимались мои знакомые из лаборатории Терехова ЛГУ. Книжка называется «Как Паскаль и Оберон попадают на «Самсон». Они придумали собственную архитектуру процессора, максимально удобную для компилятора. Выигрыш на той же тактовой был в десяток раз.
( про ЛГУ: признаюсь честно Ж-) не помню читал или нет
M-2 в СССР был довольно популярен, про комп-р MAРC толи в Правде ( или в Известиях), толи в Н&Ж были статьи на весь разворот и т.д.)

Про железо — можно пруф?

Я собственно, считал, что про Н.Вирта, как практика,
уж Ж-) настолько часто упоминают, что можно и полунамёком Ж-)

Просто напишу, где лично я про это читал

Собственно ( про M-2 в Союзе см.ниже) про то, что Н.Вирт начиная с Modula-2 делал ещё HW + OS «к языку» есть во всех его биографиях ( пару URL далее)

Про Lilith впервые прочитал в книге Н.Вирта «Программирование на языке Модула-2» ( в предисловии). Издательство «Мир», кажется.
«Мир» печатал классику неплохими тиражами.
Книги были даже в публичной библиотеке Заводского района ( кстати, это и оф.название Ж-) )

Никлаус Вирт в Академгородке
в 1980 создана была аппаратная реализация Modula-2 — персональный компьютер Lilith

Там же про Modula-2 в СССР и в РФ

P.S.
Ещё биография + факт говорящий:
Никлаус Вирт — патриарх надежного программирования

Брайан Керниган, известный популяризатор языка Си, соавтор классического руководства по Си (K&R), написал критическую статью «Почему Паскаль не является моим любимым языком программирования»

Ремарка: её, кстати, «завернули» из журнала IEEE ещё при рецензировании
( лучше сразу укажу, что пишу по памяти: журнал «наикрутейший» точно,
c названием «могу допустить неточность» Ж-) )

... 2 апреля 1981 г., т.е. через два года (!) после реализации группой Вирта в ETH первого компилятора Modula-2 и через год после выпуска аппаратной реализации Modula-2 — персонального компьютера Lilith.

Выходит, за дело: вместо сравнения с «доведённым» до практического применения языка ( из крупного: AZ/400 до перевода «на объекты» и C++) сравнивали с «академическим» прародителем

P.P.S. Только сегодня сопоставил даты: раньше казалось, что Б.К. просто имел мало шансов узнать про новости из Швейцарии
P.P.P.S. Статья классическая и критика её тоже «всем известна»
Спасибо
НЛО прилетело и опубликовало эту надпись здесь
где кроме Питера и Москвы в принципе есть вакансии на Embedded?

А, как раз Ж-), на обоих берегах
берег Белого моря с северным Черного

уже не нужны? Ж-)

P.S. Правда, по слухам, срочное погружение, пока ПО не заработает Ж-)
В Чебоксарах, в Смеле, в набережных Челнах, в Ижевске, в Красноярске… Мне что вам, ссылки на всех смежников постить? :-))

Если не боитесь с военкой работать — говорите город, скажу что там пишется.
Лично мне «берега» напомнили про основного заказчика встроенного Ж-)
«Улыбнуло» — нет мол жизни Ж-) вне столиц
НЛО прилетело и опубликовало эту надпись здесь
Ну GPS/ГЛОНАСС и все, что вокруг него, всегда было и будет двойного назначения. Секретности нет, остальное — неважно.
НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

Если вам стал известен секрет — это целиком и полностью вина того, кто его разгласил, всё остальное уже вне сферы закона, насколько я понимаю (если кто знает точнее, пусть поправит). Это не законное основание заставлять вас что-то подписывать.

НЛО прилетело и опубликовало эту надпись здесь

Сдаюсь! Сдаюсь! :) Честное слово, я не хочу спорить о том, что за пределами правового поля, я просто говорю, что такие вещи не должны быть законными. Я понимаю, что законы у нас вертят как хотят, такая у нас жизнь. Поэтому и говорю, что если не хочется связываться, то это вполне достойная причина не идти работать на оборонку, не хуже любой другой — тут уж каждый сам для себя выбирает, стоит риск того или нет.

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
с тем же ураном
была забавная история: как только публикации в научных журналах внезапно перестали появляться,
как физики-теоретики стали слать прямо из окопов Сталинграда письма верховному главнокомандующему: началось, мол
Ну что делать… От газонокосилки до робота с пулеметом — один шаг. Только сменить то, что на шасси стоит. :-)
Личного опыта нет, но по рассказам знакомых, которым выдалось там работать, сложилось впечатление, что на «Эларе» такие спецы если и ценятся, то вряд ли в денежном эквиваленте.
Не знаю, судя по виду сотрудников (и машинам у входа) — ценятся. Но в Чебоксарах жизнь сильно дешевле, чем в Москве.
и машинам у входа

Кайен или панамера может быть генина или очередной секретутки гены, так что «машины у входа» — ни разу не показатель отношения владельцев к ИТР.
Сейчас бы игры на Delphi писать. Вы меня простите, но нет.
например, известную систему SAP

Поверьте, SAP, мягко говоря, далёк от эталона «крутого бизнес-софта».
Это в каком же месте SAP написан на Delphi? Просветите, пожалуйста!
Никто не спорит, но молодежь не пойдет писать на Делфи. Кому они потом продадут эти знания? Только таким же местечковым компаниям.
Ну не любят за океаном «дедушку Вирта».
Есть версия, что мешал ( и мешает) делать «плясь плясь и в» кассу Ж-)
( это из «получен аванс — полный успех проекта»)
Любовь приходит и уходит, а кушать хочется всегда.
Текстовые редакторы — условно ладно, пусть зарабатывают,
а вот ещё какое не то производство начнут программировать — страшно Ж-)
Учитывая, через что мне пришлось пробраться до вашего комментария, я бы не сказал что «никто не спорит» :)
Видимо Delphi не так уж и мертв как некоторые считают
Взгляд со стороны:
Да, уже лет "-дцать" Ж-) всё умирает и умирает...
А новые версии среды разработки выходят, Q&A на форумах вовсю Ж-),
ещё и вакансии есть

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

Здесь на Хабре была статья про крупный скандинавский банк
Можно почитать почему Cobol не умрёт

P.S.
Вы то предлагаете переписать проект автора статьи целиком, то наоборот Ж-)
Я ничего не предлагаю переписывать. Просто стоит понимать, что когда говорят, что язык умирает — это означает, то на нем пишут все меньше новых проектов. Legacy вечно, но если язык живет только одним legacy, то он уже вполне мертв.
Именно Delphi, сам по себе, меня, если уж совсем честно, волнует мало...

Я, мягко говоря, не уверен, что хорошо «для планеты»
когда на языках «европейской школы» «пишут все меньше новых проектов»

Когда в МГУ уменьшают часы на изучения ADA в пользу Cи

Результат предсказанный Э.Дейкстра ( вреда от Си, в следующие сорок лет, будет не меньше чем от Fortran в передыдущие) вижу каждый день в виде бесконечных hotfixes к ОС и ПО
Си был очень хорош как структурный ассемблер PDP-11. Увы, люди просто не видят, насколько многое в нем было сделано криво, непосредственно под задачу…
Что Си местами структурированный ассемблер — «таки да»

( Для любителей Си есть практически ценная задача:
«подлакировать» исходные коды xdelta3 под Win x64 )

Плюс многие «фокусы» в Си перекочевали из Algol-68

Особенно впечатлила программа строк на 12 на Алголе с подписью:
«ни одна строка не работает так, как вы подумали, бегло прочитав код»

Но самое главное, что Си и не думают развивать в нужном направлении.
Например, модули не попадают в стандарт языка уже как несколько итераций
Хочу пруф о влиянии алгола-68 на Си. Лично я этого не вижу.

А нужное мне направление — это структурная обработка аппаратных исключений. А не через сигналы и longjump. Думаю, что ещё лет 50 подождать придется.
>> пруф о влиянии алгола-68 на Си.

(
Си рассматривался в моих сообщениях, в основном,
как наследник Алгол по любви к фокусам Ж-)
)

Влияние, как минимум, как предшественника по времени

Но Алгол-68 создавали как общемировой стандарт, всем миром
а он ( мир «компьютерщиков») исчислялся хорошо если тысячами,
а не как теперь миллионами,
поэтому не исключено, что влиял непосредственно Ж-)

C — он же развитие языка B Ж-)

Хотя: дурацкие ";" от которых сейчас избавляются ( например в Go)
в Алголе означали «выполнить последовательно»,
а запятые — «параллельно» ( т.е. точки с запятыми — имели смысл)

Как видим, весьма «молодёжная» идея даже сегодня

( Это, кстати, было в одной из 12 строк как «подводный камень»)
CPL — 1963 год, BCPL — 1966 год, B — 1969ый, Си — 1972ой. Некоторое влияние алгола-60 заметно, а вот влияние алгола-68 — не вижу совсем.

Вижу влияние ассемблера PDP-11, например do dst++=src++ while (*src); — это две команды на PDP-11.

$1: MOV (R5)++, (R3)++
JNE $1


++ и — - они из PDP-11 пришли.
влияние алгола-60 заметно, а вот влияние алгола-68 — не вижу совсем.
Вполне возможно

Плюс многие «фокусы» в Си перекочевали из Algol-68

Особенно впечатлила программа строк на 12 на Алголе с подписью:
«ни одна строка не работает так, как вы подумали, бегло прочитав код»

Просто хотел напомнить, что многие «фокусы» — веяния того времени, когда 64kb «должно было хватать всем»

P.S. и 640k через лет 5 — действительно было
как 2^48 в сегодняшнем Win x64,
т.е. числом взятым с большим запасом, «на вырост»
Просто хотел напомнить, что многие «фокусы» — веяния того времени, когда 64kb «должно было хватать всем»

Это неверно. К моменту переписи Unix с Би на Си они уже рассчитывали на PDP-11/70 с четырьмя мегабайтами адресного пространства. Это 1974ый год. Комплектовался он физической памятью MJ11 с модулями по 32/64 кб на слот модуля. Сколько там было памяти — неизвестно (скорее всего 1-2 мегабайта), но UNIX рассчитывался на полный комплект, то есть 4 мега (без 8 килобайт страницы IO).
и 640k через лет 5 — действительно было
как 2^48 в сегодняшнем Win x64,

Не знаю, я привык к мегабайтам на ЕС ЭВМ (IBM/360/370). Ну и к тому, что 200 терминалов на одну машину — это нормально. :-)
я привык к мегабайтам на ЕС ЭВМ (IBM/360/370). Ну и к тому, что 200 терминалов на одну машину — это нормально. :-)

Как раз примерно это и хотел сказать Ж-)

Я скорее «образно» написал:
64k сегменты скорее из Intel мира и т.д., и т.п.

Впрочем:
PDP-11/70 случайно не старшая модель? А потом уже VAX?

Это я к чему: 32Mb было и в 50-м на одной машине на весь мир

потому, возможно, 1-2Mb в 74-ом на дорогих «внедрениях»,
а массово — уже и поменьше Ж-)

а даже если и пару «метров» --масштаб с нынешними десятками гигабайт RAM похожий Ж-)

PDP-11/70 — первая из машин с 4мя мегабайтами адресного пространства. Но далеко не последняя. Старшая — видимо PDP-11/94.
В ходе практики от школьного УПК на ЭВМ из СМ линейки с 8-ми дюймовой дискетой за две недели лета выучил по «Руководству пользователя» весь Basic
( в УПК раз в неделю учили по 1 оператору в день Ж-) )

А языки "европейской школы" магическим образом избавляют нас от логических ошибок?


вижу каждый день в виде бесконечных hotfixes к ОС и ПО

А подскажите, как бы от этого нас избавили языки "европейской школы"? Как от этого вообще может избавить какой-то язык программирования? Вот я сам делаю hotfix, потому что у меня в коде мало тестов, а значит я втыкают один функционал проверить, когда задеваю его разработкой смежного, причем тут язык программирования?

> у меня в коде мало тестов

Для ADA сделан на Prolog-е «высокоуровневый linter»,
который доказывает программу как теорему

( На самом деле, я слегка всё упростил — есть «детали»,
но смысл подхода — понятен)

> языки ( программирования) избавляют нас от логических ошибок?

Смотря от каких Ж-)

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

А «дедушка» Вирт стремился компилятором всё что можно «отловить»

P.S. Мне просто не очень нравится критика Delphi/ADA без учёта их плюсов

P.P.S. И не нравится заокеанский подход:
Си «на экспорт», а для себя любимых — наоборот,
на «языке, который отправит в т. ад» ( из газеты «Правда»)
Для ADA сделан на Prolog-е «высокоуровневый linter»,
который доказывает программу как теорему

И сколько он будет работать для какой-то CRM? Несколько веков? Ну и как мне кажется, эту теорему еще нужно будет составить, что опять же таки приводит нас к тестам, которые просто пишутся по другому.


Мне просто не очень нравится критика Delphi/ADA без учёта их плюсов

Каких плюсов? Все, что есть в Delphi, есть в том же Python, Java, C# но + у них есть еще куча других фич. Я просто искренне не понимаю, какие преимущества любого языка из семейства Pascal перед тем же Python ну или Java?


А «дедушка» Вирт стремился компилятором всё что можно «отловить»

Именно поэтому динамический массив в turbo pascal состоит на 90% из магии. Идея про отлов всего компилятором работает для простых программ, требования к которым можно легко написать, но в мире остались считанные отрасли, в которых нужны такие программы.


Смотря от каких Ж-)

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


Си «на экспорт», а для себя любимых — наоборот,

Всмысле? Куча же в том числе и заокеанского софта написаного на C.

Все, что есть в Delphi, есть в том же Python, Java, C# но + у них есть еще куча других фич.

Есть слухи Ж-), что Java и С# начинали как замаскированный фигурными скобочками TP Ж-)

динамический массив в turbo pascal состоит на 90% из магии.

Берём ADA

( в лабах на TP сам делал — просто много "^", не эстетично,
но работало ведь Ж-) )

Ошибка «не выделенной памяти» в C в более поздних языках успешно перетекла в NullPointerException

так Oberon же Ж-) со сборкой мусора в компилируемом языке
В Modula-3 — вообще одновременно для одной «кучи» сборщик,
а для другой — можно вручную

про отлов всего компилятором


Таки да: используют и ИИ ( см. ниже)

VVM>> Для ADA сделан на Prolog-е «высокоуровневый linter»,
VVM>> который доказывает программу как теорему

И сколько он будет работать для какой-то CRM? Несколько веков? Ну и как мне кажется, эту теорему еще нужно будет составить


Скорее всего, если в модуль не вносили изменений, то и доказывать заново не надо ( а-ля компиляция в .obj)

Пред- пост- условия, инварианты циклов задаются как комментарии в исходном коде
( естественно, как специально оформленные)

Очень многое просто «вычитывается» из исходного кода

От всяких целочисленных переполнений просто избавляемся,
так как «ADA-linter» рассчитывает допустимый диапазон параметров
функций и так снизу вверх по всей программе

P.S. Использования «ADA-linter» попросту обязательное условие тендеров в сфере, где ADA и применяется Ж-)

Хочешь хлеб с маслом — докажешь верность программы

Всё очень просто в орг.плане

P.P.S.

Си «на экспорт», а для себя любимых — наоборот,

Всмысле? Куча же в том числе и заокеанского софта написаного на C.

про помощь с xdelta3 — я вполне серьёзно, заодно и станет понятно зачем ADA/Modula-2 понадобились к 80-му году прошлого века ( и кому, см. список заказчиков )
Пред- пост- условия, инварианты циклов задаются как комментарии в исходном коде
( естественно, как специально оформленные)

Очень многое просто «вычитывается» из исходного кода

От всяких целочисленных переполнений просто избавляемся,
так как «ADA-linter» рассчитывает допустимый диапазон параметров
функций и так снизу вверх по всей программе

Чем это отличается, скажем от doctest для python? Если мне не хватает времени на тесты, мне так же будет не хватать времени на такие комментарии.

( Не уверен про doctest — сравнение с Rust годится? )

К идее «просто протестировать» ПО претензии классические:
да simple можно проверить полным перебором,
а вот double — не удастся

Скорее всего, «ADA-linter» — это SPARK:
SPARK is a restricted subset of Ada for formally verifying programs. It provide features comparable to languages like Rust and ATS. A recent article comparing SPARK to Rust caught my eye and I decided to spend some time learning Ada and SPARK.

Пред- пост- условия таки элемент языка:
function Saturate (Val : Unsigned_16) return Unsigned_16 with
  SPARK_Mode,
  Post => Saturate'Result <= 255 and then
         (if Val <= 255 then Saturate'Result = Val);


Забавно, уже готовы и тестирование применять:
Hybrid Verification

Hybrid Verification is an innovative approach to demonstrating the functional correctness of a program using a combination of automated proof and unit testing.
Once the functional behaviour or low-level requirements of a program have been captured as SPARK 2014 contracts, the verification toolset can be applied to automatically prove that the implementation is correct and free from run-time exceptions.
Only where verification cannot be completed automatically is it necessary to write unit tests — with the same contracts used to check the correct run-time behaviour of the relevant subprograms.

Но в крайнем случае

P.S. Где-то читал, что на Хабре URL «во вне» не приветствуется,
поэтому — цитатами
P.S. Где-то читал, что на Хабре URL «во вне» не приветствуется,

Вроде должно быть нормально с этим ...


К идее «просто протестировать» ПО претензии классические:
да simple можно проверить полным перебором,
а вот double — не удастся

В runtime можно делать при помощи таких штук как контракты, например.


Ну и мне не совсем понятно, как решается вот это:


а вот double — не удастся

Для ADA? Берутся случайные значения из промежутка?

P.S. Где-то читал, что на Хабре URL «во вне» не приветствуется,
Вроде должно быть нормально с этим…
Sorry: эти страницы закрыл, иначе опубликовал бы и ссылки, но в ddg.gg минут за 15 нашёл


double полностью перебрать не удастся

Для ADA? Берутся случайные значения из промежутка?


В принципе не удастся Ж-) Там числа сравнимые с числом атомов в пол-вселенной — комп-р не построить Ж-)

Для тестирование можно взять числа около нуля, единицы, в начале и конце каждого значения экпоненты,
плюс минус единица, максимум, минимум

А SPARK, надеюсь, «доказывает теоремы» как в высшей математике Ж-):

Automating the Verification of Floating-Point Programs
native support for floating-point arithmetic recently added in the SMT-LIB standard. Our approach is implemented in the Why3 environment and its front-end SPARK 2014 for the development of safety-critical Ada programs

и

Satisfiability modulo theories

Computer-aided verification of computer programs often uses SMT solvers. A common technique is to translate preconditions, postconditions, loop conditions, and assertions into SMT formulas in order to determine if all properties can hold.

There are also many verifiers built on top of the Alt-Ergo SMT solver. Here is a list of mature applications:
•Why3, a platform for deductive program verification, uses Alt-Ergo as its main prover;
•SPARK, uses CVC4 and Alt-Ergo (behind GNATprove) to automate the verification of some assertions in SPARK 2014;

Symbolic-execution based analysis and testing

An important application of SMT solvers is symbolic execution for analysis and testing of programs...


P.S. Забавно, там и Си есть:
•CAVEAT, a C-verifier developed by CEA and used by Airbus; Alt-Ergo was included in the qualification DO-178C of one of its recent aircraft;
•Frama-C, a framework to analyse C-code, uses Alt-Ergo in the Jessie and WP plugins (dedicated to «deductive program verification»);
Все, что есть в Delphi, есть в том же Python, Java, C#

Нет одного — нативности. В C# всё хорошо, кроме дотнета. В Жаве — кроме VM.

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

Отлов всего, конечно, идеал. Но даже отлов 80% — это уже отлично.
НЛО прилетело и опубликовало эту надпись здесь
В Си на практике выходит не так уж и «типизировано»

В xdelta3 при обработке файлов больше 3Gb перестроить
структуры данных под Win x64 (при 64bit pointers, 32bit числа)
— скажем так, трудоемко и требует циклов с отладкой

Кстати, вот в этом случае, не уверен что
«европейская школа» «сработала» бы лучше:
там и на самом деле нужен стиль работы
как в «высокоуровневом ассемблере»
НЛО прилетело и опубликовало эту надпись здесь
А языки «европейской школы» магическим образом избавляют нас от логических ошибок?

Хотя бы большей смысловых избавляют — уже хлеб.
Только вот вакансий на нем все меньше и меньше, а если по % с мейнстримом типа Java/JavaScript/C# сравнивать, то совсем грустно выходит. При этом денег не так чтобы на порядки больше предлагали.

Современная среда разработки Delphi отнюдь не вымершая. Очень бурно развивается в последнее время, каждый год, а то и по два раза в год выходят новые версии с новыми фичами и поддержкой самых современных технологий. И действительно, огромное количество современных мировых производителей используют именно Delphi для разработки своих продуктов. Мир многообразен, в нем всегда найдется ниша и для Delphi, и для C#, C++ и других сред разработки. А иногда даже для всех вместе в одном проекте.

Нормально всё у Delphi. Новые версии каждый год выходят, native поддержка Windows отличная, кроссплатформенная — средняя, но тем не менее она есть. Мы тоже серьезные коммерческие проекты пишем на Delphi (2 проекта от 500 тыс до миллиона строк кода). Проектам 10 и более лет, продаются успешно.

2 проекта от 500 тыс до миллиона строк кода

Т.е. переписывать на «модное и молодёжное» не стремитесь?
( см. мои другие посты здесь — для контекста Ж-) )

Модное и молодежное — это такой красивый цветастый интерфейс с картинками и чатиком? Нет, мы создаем сложные профессиональные десктопные решения для бизнеса, а не фантики и побрякушки :).

это такой красивый цветастый интерфейс с картинками и чатиком?

мы создаем сложные профессиональные десктопные решения для бизнеса

Думаю, создатели АБС Бисквит, относительно недавно осознавшие необходимость графического интерфейса взамен текстового 80х25, думали так же.
Бисквит графический? Да ладно!
И как он работает, по XWindow? Или на каждую рабочую станцию надо что-то копировать?
Увы, не подскажу, самому работать с ним не приходилось. Мне больше интересно как прикручивали клиент к приложению, логика которого неразрывно связана с представлением.
Жаль, так как именно это мне тоже интересно.
Я вижу два варианта, с сохранением логики интерфейса в процедурах .p — либо движок интерфейса перевели в XWindow, либо сделали свой графический терминал (как сделали в RS-Bank ~15 лет назад).
О, ну у нас такой перевод делали, когда наше приложение переводили из мира MS-DOS в Windows. Вся логика сервера осталась той самой, 80*25 логикой. Клиент при этом — вполне себе «моднявый». Сейчас еще и Web FE прикрутили.
Модное и молодежное — это такой красивый... интерфейс
Положим не совсем так Ж-)
М&М это было про внутреннюю красоту:
там языки без ":=" и с фигурными скобочками должны были отбить все затраты на переход на них своими качествами Ж-)
На Делфи часто пишутся сложные, надежные и дорогие системы. Банки, те же упомянутые CRM, космос, медицина, заправки, локальные системы управления производством, управление АЭС и прочее. Многие даже не догадываются, где такой софт работает.

Да не переписать их, трудозатратно слишком. Вот представляете пишут 2 разраба 10 лет проект. На Delphi. Каждый день что-то кодят. А сколько времени нужно чтобы его переписать целиком на другом языке? Я не представляю. Даже если бы оба разраба знали бы оба языка в идеале. Чтобы так переписать, нужно тогда как минимум сначала исходники как-то автоматизированно сконвертировать под новый язык (чтобы хоть технически вручную поменьше менять), а дальше править уже архитектурно, но это на мой взгляд задачка та еще. Если бы это было приложение без GUI и не использовало сторонние компоненты/библиотеки, тогда еще куда ни шло. А все эти завязки делают миграцию на другой стек технологий практически нереальным.

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

Я-то как раз это понимаю

Так как видел такое
исходники как-то автоматизированно сконвертировать под новый язык
в реальной жизни,
как это для начала непросто и всё равно требует «дожимать» вручную

И это был перенос между разными диалектами SQL,
а уж Delphi с грамматикой разросшийся до размеров ADA

Оставлю здесь историю вопроса
т.к. если бы не пришло сообщение на почту
и не понял бы Ж-), что это ответ на мой комментарий так всё «разрослось»:
Он довольно низок в рейтинге языков и, скажем так, в целом не обладает рядом хоть каких-то удобных фич, которые бы мотивировали на него перейти.
...
Я оставил delphi очень давно, так как, скажем, до сих пор не очень понимаю, чем он лучше для разработки, чем тот же C#, если говорить про Windows.
Апелляция к legacy системам, которые писать давно тоже не катит, так как на C#, Python, Java, C++ и еще куче языков тоже пишутся серьезные вещи и вполне успешно.

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

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

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

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

Вроде, есть автоматический конвертор кода с Delphi на C# (компоненты, конечно, придётся заменить).

(компоненты, конечно, придётся заменить)
ну вот: уже «ручная» работа + потенциальная «русская рулетка» Ж-(

автоматический конвертор кода с Delphi на C#
Так как раз техническая возможность совершить переход,
делает вопрос «стоит ли игра свеч» ещё более интересным Ж-)

На практике-то, ответ понятен см. выше и здесь, и предыдущие ком-ии ( и не только мои)
Кто вам такой бред про почти умерший Delphi сказал? :)
Три миллиона пользователей не согласны.
Delphi живет и развивается. Недавно 'прикупили' себе Сенчу. Скоро будет ультра-быстрая разработка веба прямо из коробки.
1 Всем плевать. Нет вакансий. Нет вакансий с большой ЗП.
2 Вы в РФ? У вас ЗП в 3500usd имеется?
И много в России (особенно в регионах) вакансий с ЗП 3500usd? Даже и не Делфи? Вакансий по 3500 нет не из-за Делфи, а несколько по другим причинам.
В регионе необходимо искать удаленную работу, вероятно на заграницу.
Помнится, Borland тоже много чего прикупал. Как раз перед тем, как избавиться от Delphi.

Delphi не умер, конечно. Но есть проблема…
Когда с Delphi случился Embarcadero, он стал стоить каких-то совершенно невразумительных денег. Бесплатный Starter урезан до уровня D2, а потому смысла в нем никакого.
Поэтому, когда понадобился более-менее современный фреймворк, я нашел себе Qt под LGPL. То есть бесплатный. В котором есть все, чем мог похвастаться дорогой товарищ Delphi (из интересного мне), включая IDE, плюс еще много разного. И кроссплатформенность и opensource в подарок. И никаких проблем с подключением сишных библиотек, тоже бесплатных, да. Специально для знатоков даже есть возможность перехватывать неперехваченные exceptions.

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

В одной знакомой лавке тоже есть работающие много лет приложения на Delphi + хронический дефицит дельфистов. Я думаю, что когда лавка решит перейти на что-то более современное, то она не дельфистов будет переучивать на C#/Java, а купит сторонний интегрированный продукт. Подозреваю, что он будет разработан не на Delphi.
Qt платный, если что. И хорошо платный. Для коммерческих проектов, конечно. Так что мимо. Дефицит делфистов преодолевается элементарно, язык и среда настолько просты в обучении, что переучить человека можно за месяц-другой (по своему опыту).
> Qt платный, если что.
Мимо. Не верьте всему, что говорит бывшая Digia. Почитайте текст лицензии.

> Дефицит делфистов преодолевается элементарно, язык и среда настолько просты в обучении, что переучить человека можно за месяц-другой (по своему опыту).
Они не хотят учится Delphi.
Стесняюсь спросить, а что за опыт у Вас тогда получит человек при работе с этой «настолько простой средой»? Вала вакансий на Дельфи я не вижу, в отличие от Java, например. Куда он потом пойдет свой опыт продавать? В унитаз спускать?
Если программист хороший, перейти ему с Delphi на тот же шарп — месяц максимум. Не средой ценен программист, а гибкостью ума.
Осталось понять, как «гибкость ума» отражать эффективно в резюме. А то эта самая гибкость устойчиво ассоциируется с «быстрообучаемый» и пр. jack of all trades. С ожидаемым продолжением — master of nothing/
Быстро разбирающийся в чужом коде, например.
И как это ХРюше преподнести и не попасть в категорию «быстрообучаемых»?
Если ХРюша нормальный — то он сам хорошо знает, что нужно от человека. Мы тоже отчасти 'ХРюши', так как периодически берем людей на работу (компания небольшая, приходится самим заниматься). Знание конкретной среды/языка — бонус, но далеко не решающий.
Почему он непременно должен идти куда-то?
Вы воспринимаете любую фирму как временное место?
Вспомним что все воспринимали СССР как нечто постоянное.
Любая фирма это временное место, даже если фирма будет существовать дольше человеческой жизни, программист заскучает от однообразия.
Смотря чем компания занимается. Автор, вон, больше 20ти лет занимается своей темой и явно от однообразия не страдает.
Автор, если не ошибаюсь, работает на себя.
Я работал в уютных коллективах, может быть если бы там была рыночная зарплата, я бы там всю жизнь работал-деградировал.
Но для меня главное:
1 Большая ЗП.
2 Изучение чего-то что обязательно повысит мою ЗП, не позже чем через полгода — год.
3 Не деградировать однообразием.
4 Уютный коллектив.
НЛО прилетело и опубликовало эту надпись здесь
Это ясно.
Но позиция вида «я тут на год-два, не больше, потому что мне надо идти „дальше“» тоже, мягко говоря, странная. Я бы фиг нанял человека, который объявляет, что после полу-года-года обучения он отработает год-полтора и уйдет.
Я бы фиг нанял человека, который объявляет, что после полу-года-года обучения он отработает год-полтора и уйдет.
Но таковы реалии, я бы с удовольствием год поучился, было бы чему так долго учится. Но если ЗП не рыночная, то пойду искать ЗП.
Сколько вы учите и сколько я отрабатываю, об этом надо явно договариваться. Да и то, никак не проконтролируешь.
Если люди в компании задерживаются только на год, то с этой компанией явно что-то не так. Это — уже текучка явная. Вот — один из возможных вопросов интервью со стороны рекрутера — сколько вы намереваетесь у нас работать. Если ответ будет год-полтора, я бы такого человека вообще не брал. Исключение — особые знания у человека. Мы, например, на таких условиях сейчас взяли себе хорошего математика, он будет у нас до следующего года работать, потом уезжает в Штаты. За год подтянет нашу 'матчасть'.
Если ответ будет год-полтора, я бы такого человека вообще не брал.
Человек скажет вам хочу прокачать фронтенд, сейчас хочу икс, через полгода +10%, еще через полгода еще +10% и вы уже будете думать брать не брать, но через год ситуация меняется и рынок говорит что скилы стоят +30%, человек к вам приходит и говорит я себя чувствую ущемленным в ЗП, поднимайте или ухожу.
Я понимаю что сейчас есть много народа которые по какой то не денежной причине сидят на одной работе, но если вы молод, я считаю нужно почаще менять работу, да даже не молод, а просто способен менять работу — меняй работу.
один из возможных вопросов интервью со стороны рекрутера — сколько вы намереваетесь у нас работать. Если ответ будет год-полтора, я бы такого человека вообще не брал.
Кто ж вам об этом скажет? Это такой же бессмысленный вопрос как «Почему вы уволились с прошлой работы?». Ответ будет прилизанным и стандартным и не факт что вообще коррелировать с реальностью.
Да и на вопрос про продолжительность работы я лично вообще не могу дать ответ. Откуда я знаю, как мне будет работаться в этой компании? Может я оттуда через две недели буду бежать и волосы назад. Может через год пойму что задачи унылые, зп не повышают. А может 5-10 лет счастливо отработаю над интересными сложными задачами и с хорошей зп.
Спросить можно. И не факт, что каждый будет врать. Мы, как я говорил, спрашивали, когда математика искали. Он рассказал о своих планах на работу, нас всё удовлетворило, мы раздаём задачи исходя из его ситуации.
Я бы на такой вопрос ответил «Я надеюсь работать у вас до пенсии, но если у меня будут сильные причины уйти (большое количество переработок, разница по зарплате раза в два с оффером другой компании или что-то в этом духе), то я буду идиотом, если не уйду. Пока что в среднем такая сильная причина у меня появлялась спустя примерно год работы — где-то меньше (вплоть до пары месяцев), где-то — больше (вплоть до 3 лет)».
Такой ответ вам бы подошел или вы ищете сотрудников, которые не учатся на своем опыте?
НЛО прилетело и опубликовало эту надпись здесь
1. Мы все в этом мире временые до погоста.
2. А что, фирма — это 1000летний рейх чтобы пережить поколения людей? Закладываться на вечность фирмы еще глупее, чем на вечность своей жизни.
Знаете, я вам как ответственный за практику студентов на кафедре скажу. Не IT, правда, а энергетика.

Это никому и нахрен ни надо.

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

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

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

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

Чем мы и начали заниматься, но из-за юридических сложностей (волонтёрская организация зарегистрирована в МСК, филиалов нигде нет, а договаривались с вузами из ЕКБ, Самары и другими. По старому закону (он отменён, но вузы не успели обновить внутренние положения) если организация для прохождения практики находится в отличном от местоположения университета городе, организация или университет обязаны отправить за свой счёт практикантов к месту прохождения практики. Не смотря на то, что наша организация — онлайн) пришлось остановить переговоры.
Правильно, студентам это не надо, потому что вы всем учебным процессом выхолащиваете образование и выбиваете из него прикладной смысл, замещая его псевдно-научными знаниями о том, как оформлять титульный лист и список литературы. К концу первого курса студентам уже ничего не надо, кроме того чтобы им тупо поставили оценку и отстали со своей дурью. Они приходят к вам в институт с горящими глазами, а выходят с потухшими. Это исключительно ваша заслуга, что студентам ничего не надо. Такими их делает университет.
Да, так и есть. Я хотел это как-то переломить, хоть чуть-чуть и локально, но дон-кихотов тут не любят, и вытравливают дон-кихотство всеми силами.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Это не только c программистами косяк. Если обобщить, то на просторах СНГ нет сформировавшегося устойчивого понимания стоимости тех или иных работ, услуг и товаров. Завод может производить дешевые носки за 20 рублей, при этом ему нужны специалисты, но платить им он не хочет и не может, потому что все жутко неэффективно, да и кто они такие, когда директору новая тачка нужна. Повысить стоимость носков? Тогда уборщицы не смогут их себе позволить. Тогда придется и им зарплату повышать. Это замкнутый круг. Вот и получается, что население в основном и страдает и удивляется, а что это заграницами такая дорогая медицина.
Индусы с вами не согласны )
Выкормыши интернета. Это уже о студентах. Интернет для программиста бесценен: это и вопросы-ответы, и форумы, и опенсорс, и учебные видео-курсы-книги, и Хабр. Но им нужно уметь пользоваться и при этом контролировать себя, иначе получится так, как получается: молодые программисты схватывают информацию по верхушкам, находят готовые куски кода и тащат их сперва в курсовые и дипломные работы, а потом и в продакшен на работе. При этом они могут даже не проверить работу кода и не разобраться, как он поведёт себя в программе. Ну а если найденный код заработал — то всё, считайте, перед нами тру-программист. Ну точнее, он так о себе думает.

А code review у вас нет? Это тогда ваша проблема, можно и без интеренета страшных дел наворотить, например, писать свои сортировки и структуры данных :)

У нас code review на первом месте — и на это есть намёк в посте. Как и рефакторинг — об этом мы уже неоднократно рассказывали. Мы о ситуации в целом и о хитропопых молодых ребятах, которые пытаются показать себя умными на основе лишь одного гугла :-)
НЛО прилетело и опубликовало эту надпись здесь
Написано же, «лишь одного гугла». Т.е. На любой тривиальный для профи вопрос тот лезет в гугл
Верно.
НЛО прилетело и опубликовало эту надпись здесь
У студента вилка желаний простая: 1) сразу много денег, как компенсацию за потраченные в универе годы 2) мало денег, но крутая компания (ценная строчка в резюме) 3) мало денег, но быстрое обучение на высокооплачиваемого разработчика в модном направлении с самым современным стеком технологий. Разумеется, если студент придёт в неизвестную ему компанию, а тут предлагают поработать тестировщиком и/или писать на Delphi, студент покрутит у виска и сбежит как ошпаренный.
Чаще третье, причем вкалывают без обеда и после работы, что бы получить практический опыт. Теоретический уже есть, так как прошли собеседование, дальше требуется шлифовка.
НЛО прилетело и опубликовало эту надпись здесь
-я так скажу — зажравшиеся куски мяса! Хотят много денег надо доказать, что достоин их!

С таким мнением — вы даже студентов будете искать оооооочень дооооолго. И поделом.

Просто для интереса: сколько нужно платит джуниору, который может решить проблему бизнеса, использую современный стек технологий? Не минусуйте, сам джуниор и недавний выпускник. 30? 70? Для себя считаю, что 90-100 должны только профессионалы получать. Но 30 это деньги, на которые возможна лишь модель выживания, а не обычной жизни.
Цифры могут отличаться на порядок в зависимости от страны, города и т.д.
Найдите среднюю зарплату по вашему региону и умножте на 0.75-0.8 — это и есть достойная зарплата для джуниора.
Мид — 1.5 средней зарплаты.
Сеньёр — 2-3х средней зарплаты

Конечно это очень грубый подсчёт, но поможет вам определить примерный объём.
Пример. Средняя зарплата по Москве — 67 899 рублей.
По моему методу определения получается:
Джуниор — примерно 50 000.
Мид — 90 000 — 100 000
Сеньёр — 120 000 — 180 000
сколько нужно платит джуниору, который может решить проблему бизнеса
Столько же сколько и синьору. А точнее — на сколько хватит наглости запросить денег и насколько бизнесу припечет эта проблема и насколько хватит умения съездить по ушам бизнесу.

Для себя считаю, что 90-100 должны только профессионалы получать.
Опасная ерунда. Не раз уже сказано — рынок программирования глобальный, как минимум, если есть разговорный английский, можно ориентироваться на зарплату джуна в штатах.
В зависимости от штата минималка уборщицы в сша 8 долларов в час.
Всё как всегда. «Бизнес» считает себя самым важным и нужным, работник считает себя незаменимым, претендент на работу считает себя самым крутым, преподаватель в вузе считает себя самым умным, студен считает себя самым хитрым. Будьте проще и всё наладится.
НЛО прилетело и опубликовало эту надпись здесь
как то все про молодежь, да про молодежь… Одно дело амбициозные джуниоры, которым внушили что они достойны большего, другое дело уже профессионалы своего дела — они знают и свою работу, и сколько они действительно стоят. По данной статье больше склонен полагать, что данной компании нужна именно более дешевая раб сила. Пока народ будет приходить и будет верить словам о светлом будущем — такая стратегия управления персоналом вполне может существовать. Но все рано или поздно заканчивается.
«Неудивительно, что такие люди работают в компании по 10-15 лет» — тоже знаю таких знакомых, сидят на одном месте, практически не развиваются — долбят какую то старую систему, ждут новых перспектив (с зп в 3 раза ниже чем они стоят на рынке труда) — а их нет и нет, они не в доле этой компании и всегда останутся раб. силой, которую вполне легко можно заменить. И если они действительно профи, а не те кто приходит попить чайку и лишь бы быстрее день прошел, то рано или поздно они все равно уходят. Уходят и не всегда из за зарплаты, уходят чтобы перейти на что то новое, новые технологии, языки.
«Любите меня, я подарок» — учитывая спрос на программеров и других итешников, большая часть именно так и ведет себя. Почему — потому что если не вы, то другие. Современное собеседование это не только собеседование кандидата, но и собеседование компании — нужно также стараться понравится и понять насколько она данному человеку интересна и подойдет для его работы.
Ну вы говорите про профессионалов. Как я понял, все эти недавние статьи про начинающих программистов.
НЛО прилетело и опубликовало эту надпись здесь
в смысле «узнаете»?

Не стоит забывать, что конкретный бизнес сам по себе может быть настолько неэффективным, что и предложить ему нечего. Корреляция между умениями программиста и его доходами весьма условная: я знаю чуть ли не гениев которые делают сложные штуки с машинным обучением за $200-300 в месяц (и их работодатель наверно считает это справедливой зарплатой) и знаю откровенно слабых программистов которые и код то пишут с трудом, но имеют солидные титулы в тех самых гуглах-майкрософтах и получают больше $200k в год.

НЛО прилетело и опубликовало эту надпись здесь
Зачем минусовать? Человек предлагает отличный способ проверки гиппотезы чуть-ли-не-гениальности, который еще и прибыль принесет.
Вернемся к вопросу софт скиллов, умение продать себя вообще теряется, все делают акцент на навыках. Студенты не имеют представления о бизнесе, нет опыта прохождения собеседований и единственное, что можно у них проверить это знания.
А у людей с опытом, необязательно решения задач, подвешен язык и они могут рассказать о себе намного интереснее, избегая вопросов в которых плавают, оставив о себе лучшее впечатление.
Ну как бы пока есть желающие гении на зп 200-300$ смысл менять зарплаты им.

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

НЛО прилетело и опубликовало эту надпись здесь

Я сам в каком-то роде на стороне автора поста, т.к. по работе приходится время от времени искать и нанимать разработчиков. И (о ужас!) для разработки на Delphi :)

НЛО прилетело и опубликовало эту надпись здесь
Я вот подумываю, может мне написать статью «Необразованная молодёжь. Ответ выпускника, который смог.»?

Вот, собственно, основная проблема с которой я столкнулся после универа (дело происходит в Томске) — это то, что как бы ты ни был крут, платить тебе будут всё равно копейки. Я на первой работе работал за 13 тысяч рублей, и нет я реально писал софт. Хотя мои навыки были не хуже тех же миддлов, которые получали 50к. Я выдавал результат, программы работали, претензий по коду или незнанию технологий никто не предъявлял. Однако, когда я поднял вопрос о повышении зарплаты, максимум который мне согласились платить — 28 тысяч. Естественно, через две недели я работал уже в другой компании.

Но и там было не лучше. Платили мне там 30к, однако через полгода у меня на поддержке было 4 проекта + еще пилил свою часть в том проекте, на который меня взяли. Справлялся, не косячил критично, к коду вроде ни разу претензий не было. Однако больше 35к получить зарплату было просто нереально. Ни внутри компании, ни снаружи. Просто НИКТО в бизнесе не готов хочет платить вчерашнему студенту, все хотят поиметь его нахаляву.

В итоге, ушел работать по удалёнке, потому что на ней я мог зарабатывать 30 тысяч в неделю, не особо напрягаясь. Единственная проблема, что С++ разработчику найти работу по удалёнке немного проблематичнее, чем веб-программисту и мне в некотором смысле просто повезло. К тому же пришлось соврать об опыте работы, просто ради того, чтобы не относились как к студенту.
Оппа, я тоже из Томска, приветствую!
Java — мой основной профиль. Буквально «на этот» месяц были предложения со 150к/мес. и 170к/мес, тут, в городе, без релокаций в дефолт-сити. Мой стаж 4 полных года в области QA-engineer. Разработка автоматических тестов и «все такое». Да, по первой работал за еду — 4-года назад начал кажется с 15/мес. Но стоило «немного» попотеть и теперь «все двери открыты».
Ах да, дополню пожалуй — дипломов нет, забил на универ и ушел «учиться сам». Смог.
Я доучился и не жалею. Специальность у меня правда ИБ-шная, мало связана с программированием, но уже несколько раз мне корочка помогла. Я пишу софт в сфере ИБ, я знаю законодательство в сфере ИБ, знаю требования регуляторов и реального мира. В этом плане, образование мне действительно помогло, хотя и было мягко говоря дерьмовым с точки зрения обучения работы с техническими средствами защиты.

Универ оказался очень полезным местом в плане становления личности. Было время подумать о том, чего хочется, завести знакомст, научиться решать бюрократические проблемы, да и просто отдохнуть от бренности этого бытия. Это было время свободы и творчества, т.к. денег для жизни нужно было 5-7 тысяч только на продукты, а жить было где. Читал кучу разной литературы, увлекался всякой фигней, играл на гитаре, гулял до пяти утра, ковырялся во всяком софте, дискутировал с друзьями, работал когда хотелось и т.п. За учёбы я получал хорошую стипендию (примерно 20к), так что родителей не напрягал, жил в своё удовольствие.

Не всё же деньгами и крутостью должности жизнь измерять :) С точки зрения образования ВУЗ — сомнительное место. Однако, назвать студенсчество бесполезным периодом в жизни я не могу, в плане становления моей личности это было ключевое событие в жизни и я всем молодым парням, которым сейчас по 17 лет, рекомендовал бы поступать в ВУЗ. Просто всегда надо помнить, что никто не положит тебе в голову знания их придется получать самому и найти столько времени для их получения, сколько даёт тебе ВУЗ, в жизни уже мало когда получится :)
Просто всегда надо помнить, что никто не положит тебе в голову знания их придется получать самому и найти столько времени для их получения, сколько даёт тебе ВУЗ, в жизни уже мало когда получится


Категорически не согласен — ВУЗ времени вообще никак не дает. Это время — лишь следствие того, что не все время чем-либо «обязательным» занято.

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

У меня в универе свободы не было — пары с утра и до поздней ночи. Таскали " и в хвост и в гриву". Куча абсолютно не нужных мне предметов. По нужным дисциплинам — почти везде был один хлам. Это РФФ, ТГУ образца 2008-го года. Единственное сильное, что было — физика и математика. Они были очень и очень мощными (не сарказм).

А вот это все:
Универ оказался очень полезным местом в плане становления личности. Было время подумать о том, чего хочется, завести знакомст, научиться решать бюрократические проблемы, да и просто отдохнуть от бренности этого бытия. Это было время свободы и творчества, т.к. денег для жизни нужно было 5-7 тысяч только на продукты, а жить было где. Читал кучу разной литературы, увлекался всякой фигней, играл на гитаре, гулял до пяти утра, ковырялся во всяком софте, дискутировал с друзьями, работал когда хотелось и т.п.

Универ не дает — это на самом деле вы сами для себя так сделали. И все это точно так же делается и вне онного. Причем, если вы на этом так напираете, то могу сделать некоторой степени достоверности вывод, что лично для вас это важно. Но университет тут вообще ни при чем. Ибо — мой рабочий день заканчиваться может в 2-3 часа дня — но никаких грузящих факторов, плюс я сам могу для себя выбирать чему/как/когда учиться… или маяться фигней, тюленить и гулять до 5 утра (шучу — я последние годы ночью спать люблю, ибо сон ночью — залог работы мозга и денег в кошельке).
Категорически не согласен — ВУЗ времени вообще никак не дает. Это время — лишь следствие того, что не все время чем-либо «обязательным» занято.

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

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


А в ВУЗе я мог неделю вообще не появляться :) Или появляться 1-2 дня для видимости. С работой такая фишка не пройдет. Работай ты хоть по 4 часа суперэффективно, не будет у тебя 4 месяца за год отпуска, если учитывать каникулы :) Это ОЧЕНЬ много действительно свободного времени)

У меня в универе свободы не было — пары с утра и до поздней ночи. Таскали " и в хвост и в гриву". Куча абсолютно не нужных мне предметов. По нужным дисциплинам — почти везде был один хлам.

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

Универ не дает — это на самом деле вы сами для себя так сделали.

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

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

Да, важно, я этого и не скрывал.

Я сейчас работаю относительно свободно, у меня гибкий график, хорошая зарплата. И учить я могу всё что угодно)) И заниматься чем угодно) И гулять хоть до утра :) Вот только всё точно также как и у вас — сон ночью важнее, т.к. нужен для работы и денег, развиваюсь обычно в том, над чем работаю, потому что это нужно для работы и денег. Вообще всё стало как-то вертеться вокруг работы и денег. Разве это свобода?
Прелесть бесполезной фигни, что при должной сноровке, эту бесполезную фигню можно выучить за 4-5 дней. Если тратить меньше времени на переживания о бесполезности бытия, а просто один раз выучить и забыть, то это не такая уж и большая печаль.

ИМХО, зависит от упоротости преподавателя. Иногда по второстепенному предмету могут нормально загрузить письменными работами.

P.S. закончил универ в 2006, интернет дома появился в 2008, комп в 2003 (после второго курса). Может сейчас с этим полегче.
Сейчас накопилось огромное количество «баз данных» с предыдущих курсов. Взял, исправил циферки, подправил вёрстку немного, изменил фамилию и год и сдал. Для особо упоротый преподов, можно специально внести пару новых ошибок или недосказанностей, чтобы потом на защите этой макулатуры тебя спросили ровно о том, к чему ты готов. В общем, технология-то проста)
В этом плане, университет полон ресурсов, нужно лишь правильно ими пользоваться.

Большая часть происходящего с нами от нас не зависит никак. Начиная от места рождения, разреза глаз, пола и года, от момента большого взрыва. Универ у всех разный — сильная наивность думать, что все препода/кафедры доступны для «хака» с ресурсами обычного студента. А умный человек биться головой об бетонную стену не будет — он будет стремиться решать проблему/задачу максимально эффективно. И самым эффективным решением являлось послать на три буквы весь ВУЗ и уйти работать. Я тем самым обрел самую большую степень свободы, какую только мог сделать сам себе — вся моя жизнь, в пределах рамок законов, стала под моим управлением. Я сам выбирал что, где и как мне делать. А так же «когда».

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

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

После универа моей работой стал суши-бар «якудза» (может слышали о нем). Я там был глав-горячником. Пришел без малейшего образования. Убедил, что «я им нужен». Выучился. Потом отучил еще целую кучу поварят. На всю жизнь прокачал скилл «кулинария». Затем пошел работать… в свой ВУЗ, уже программистом. И только потом пошел в коммерческую фирму за «миску риса», ибо потенциал видел громадный (оказался прав).

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

P.S. Порой вижу своих однопоточников-дипломников. Один работает клоуном на детских утренниках. Другого увидел в точке продаж китайских мобильников. Из тех, кто дошел до диплома — только сущий мизер теперь что-то дельное представляют в этой жизни. Зато ранее да, кутеж, тусовки, «короли жизни». А теперь очень многое наоборот.
Я сам выбирал что, где и как мне делать. А так же «когда».

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

Принято говорить на «вы» как бы…

Прошу прощения. Я настолько отвык на работе от общения «на вы» (принято со всеми, вне зависимости от возраста «на ты»), что периодически меня заносит.

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

Так это же не 4 месяца подряд. Это 2 месяца летом и 2 месяца «прогулов» на протяжении года. Просто спонтанный отпуск, скататься в другой город там или даже устроить кодомарафон с друзьями на 48 часов. В общем, это не отдых «пролежнем», это нормальная смена деятельности.

А труд — он облагораживает, когда не нужно пахать у станка по 9-12 часов в сутки разумеется.

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

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

Тут я соглашусь. В плане прокачки профессиональных навыков работа куда лучше универа. Большую часть практических навыков я получил именно на первых работах. Однако, время потраченное на чтение книжек и просто расширения кругозора мне сейчас возвращается сторицей, позволяя работать на стыке технологий без необходимости траты времени на то, чтобы «въехать».

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

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

… сущий мизер теперь что-то дельное представляют в этой жизни

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

Всех денег мне всё равно не заработать

Вы квартиру себе купили? Двух детей вырастили, в универе их уже отучили? Детям по квартире купили? Ведь статистика говорит что большинство людей неспособны заработать на квартиру, значит вероятно вам придется купить жилье вашим детям. Любовницу завели? А третьего ребенка, который от любовницы, в институте выучили?
Некоторые «биологи» говорят что мозг нам дан чтобы успешней размножаться.
НЛО прилетело и опубликовало эту надпись здесь
А зачем всё это?
Что всё? Я же написал зачем. Давайте по пунктам спросите если что непонятно.
Если хотите чтобы у вас остались потомки, количество детей должно быть не меньше 2.1, то есть 3.
Если вам это не надо, поздравляю, меньше конкурентов — легче дышать.
НЛО прилетело и опубликовало эту надпись здесь
Чтобы развернуто ответить, не хватит одной статьи.
Если кратко то, число 2.1 ребенка, откуда то появилось в расчетах, когда-то какую-то статью с расчетами/статистикой видел, может и желтоватую, в общем если одна женщина рожает в среднем меньше чем 2.1 ребенка то популяция со временем вымрет.
Не все дети выживают, не все дают потомство, не все рожают больше чем одного ребенка.
Женщины часто хотят родить только одного ребенка, потому нужна любовница или две. :-)
Жены могут развестись и оттяпать часть квартиры, потому необходимо несколько квартир, чтобы одна квартира полностью была твоя, либо не женится, что разумней. :-)
То есть, выходит, если перейти от статистики, конкретно к тебе, то для биологической задачи необходимо 3 ребенка, возможно от разных женщин. :-)
НЛО прилетело и опубликовало эту надпись здесь
Это вы объяснили, зачем это нужно популяции для роста размера этой популяции
Нет. Это я объяснил зачем это нужно, конкретному биологическому организму.
1. Мне плевать на популяцию и социум. Тем не менее, мне необходимость роста для популяции очевидна.
2. Пусть не конкретно именно вас. Но и не с позиции социума. Это с позиции биологической функции смертного животного с половым размножением.

Мне лень кому-то, что-либо объяснять, доказывать или спорить на эту тему. Поэтому дискуссию закончу.
НЛО прилетело и опубликовало эту надпись здесь
требования выживания популяции не порождают автоматически таковых требований к индивиду, особенно в наш-то просвещённый век.
Зря вы притягиваете популяцию.

Иными словами, биологическая функция может остаться неисполненной,
Да

и индивид будет жить долго и счастливо.
на счет счастливо — я в этом не уверен.

Ещё более иными словами, что конкретный индивид потеряет от неисполнения этой функции?
Наличие потомства.

безработица растёт, как минимум, все дела.
И что с того. Биологическая задача не в работе, а в размножении. К смыслу существования разума особого отношения не имеет.
По мне так лучше родится бедным и нищим, чем не родится. А в 90-е моя семья была нищей.

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

Но я очень рад, что вы не особо планируете размножатся, надеюсь в будущем будет больше места моим родственникам.
НЛО прилетело и опубликовало эту надпись здесь
у меня машины нет, и я не умею (и не хочу учиться) водить.
У меня нет машины и не хочу ее, я никогда не получал водительское удостоверение и не хочу учить ПДД, но водить умею (не по правилам видимо).

А смысла вообще нет.
Есть, по крайней мере субъективный, например чувства как бы подсказывают цель (смысл), а логика — пути достижения.

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

Но я очень рад, что вы планируете потратить значимую часть своих ресурсов на размножение
А на что их еще тратить…
А на что их еще тратить…

А если на развлечения или хобби? Я понимаю, что размножение тоже может быть хобби, но…
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Почему, если вы к чему-то пришли в жизни, то остальные должны придти к тому же?.. Есть те, кто всегда хотел детей, ещё лет с 20. Есть те, кто вдруг в 40 понял, что хочет. Есть те, кто о них и в 60 не думает.
У всех по-разному складывается.
А уж гаже ситуации, где родителю(ям) наплевать на ребёнка, они его завели только чтобы такие советчики отвязались, вообще нет. На выходе три сломанных жизни — родителей и ребёнка.

А куда накопленное девать — это вообще не важно. Вас всё равно не будет, так что не всё ли равно. Мой вариант — просто найти какого-то достойного человека и внезапно его осчастливить :) ну или как крайний вариант — забугорный фонд борьбы с раком.
НЛО прилетело и опубликовало эту надпись здесь
После 18 почти все мы будем только тупеть

Смешно :) 25-28 лет только более-менее ум развивается. Посмотрите на действительно умных людей — того же Энштейна, ум только во второй половине жизни раскрылся.
Так на эффективность работы влияет не только ум, но и опыт. И опыт, в отличие от ума, увеличивается более или менее всю жизнь.
НЛО прилетело и опубликовало эту надпись здесь
Биологическая задача не в работе, а в размножении.


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

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

Отнюдь, размножение — это только лишь средство, а не цель или задача.
НЛО прилетело и опубликовало эту надпись здесь
Есть, конечно.
Размножение — это результат того, что те, кто не размножались, не выжили.

Процесс не может быть результатом.
НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

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


Если же возвратиться к истокам ветки, то имеем минус к морали (любовница).

А нафига? Квартиру куплю когда-нибудь, когда выберу город в котором буду жить. Дети, если и будут, пусть сами крутятся как хотят, это их жизнь. Мне же родители не покупали квартир, машин, крутого образования. Даже в универе я уже после второго курса с них денег не брал. Вроде не сильно меня это печалит, я с ними в хороших отношениях.

Любовницу не завёл, да и не вижу особо смысла. Так рисковать прочными отношениями всего-то ради секса? Серьезно? Цена сексу в современном мире, чуть больше новых штанов, что вообще несопоставимо с ценой времени, потраченного на выстраивание отношений :)

В общем, на выживание рода человеческого мне, в общем-то, наплевать :) Для поддержания роста популяции у нас есть страны с низким уровнем образования, они успешно справляются с рождением новых людей. Биологически нам ничего не грозит)
, на выживание рода человеческого мне, в общем-то, наплевать
На выживание собственного рода тоже плевать? Ну и отличненько.
НЛО прилетело и опубликовало эту надпись здесь
Дай пять, бро. Прошу прощения за фамильярность.
«Род» и прочее, на что вы упираете уже несколько комментариев — это просто эмоции, находящиеся только у вас в голове. Даже будь вы гением (а вы вряд ли гений, иначе бы занимались чем-нибудь более полезным), никакого толка от вашего потомства бы не было, потому что вероятность гениев среди них была бы ровно такая же, как и среди любых других людей. Так что вы просто наплодите ещё несколько (десятков) индивидов, ничем не отличающихся от потомства вашего соседа по этажу. Но это в целом конечно хорошо, должен же кто-то пополнять популяцию :)
никакого толка от вашего потомства бы не было
Для кого? Для неопределенного круга лиц? А мне есть дело до этого круга?
Ну если вы не отрицаете что это ваши субъективные личные предпочтения, то никаких вопросов
Не кормите троля, он и так раскормленный!
К тому же пришлось соврать об опыте работы, просто ради того, чтобы не относились как к студенту.
«Уметь складно врать» стало одним из ключевых и необходимых навыков при устройстве на работу. Почему об этом никто не пишет? Почему все привыкли ко лжи в процессе устройства на работу? Такой общепринятый театр абсурда. При чем иногда надо привирать в плюс себе, иногда надо привирать в минус: дескать всю жизнь с пеленок только Delphi и занимался. Больше ни о чем не слышал. Привирание в минус бывет тоже достаточно эффективно.
Одно дело «умение складно врать», а другое дело «умение оправданно врать», т.е. врать о том, что потенциально ты вполне мог бы осилить. Как пример, когда я «врал об опыте работы», я просто рассказывал о тех задачах, которые решались моими коллегами, но которые я вполне мог сделать сам, если бы мне их дали. Более того, я читал их код и знаю как делались те вещи и по какой логике, я знаю, что смогу сделать не хуже, а местами и лучше. Да, это некрасиво, с точки зрения этики, нельзя присваивать достижения других людей себе, но как мне еще придумать правдоподобных бизнес-задач, чтобы докинуть себе опыта?
Да, это некрасиво, с точки зрения этики


Осталось рассказать про это Мумбаям, Хайдарабаду и прочему Бангалору. А ведь тенденции в ИНДУСтрии задают именно они, как со стороны работников, так и со стороны их будущих начальников-раджей :)
Поддерживаю. Причем ложь, делая ситуацию еще абсурднее, двусторонняя: компания врет о том, что надо будет делать, кандидат врет о том, что он умеет делать. Дальше сплошная лотерея в надежде, что реальности задач и навыков как-то пересекутся. Об этом все знают, все стороны мучаются и все продолжают эту игру…
Большая часть статей, что от студентов (иногда бывших) идет именно от тех, у кого все плохо, кто не может найти работу мечты и пытается обвинить в этом вуз. Ошибка выжившего, мы видим только ситуацию со стороны тех кто не смог.
А вот с точки зрения работодателей, правды все таки больше, на позиции мидл и выше, есть нехватка кадров, но и они пытаются обвинить в этом вузы и работников. Просто потому сложности есть, а кто виноват неясно.
>>мы ищем программиста Delphi
В жизни полно иронии. Когда учился — очень любил Delphi, но вакансий просто не существовало на него, забил и стал сисадмином. Заходишь такой на хабр через 6 лет, а тут ищут человека именно на Delphi, который за давностью лет я уже забыл :)
История «противостояния» предшественников и наследников Pascal/Modula-2 и Си — гораздо длиннее ( в годах) чем кажется с первого взгляда...

См. десятичная точка или запятая в Algol

Это «европейская» и «американская» школы и подходы

Забавно, что для критических систем «по обоим сторонам океана» — ADA
Учи C# :) Вакансий хренова гора, но язык по своему духу очень похож на Delphi (собственно отчасти потому, что делался создателем Delphi). В общем, программист Delphi — это программист поддержки. Новых проектов на нём по пальцам пересчитать, а старых и крутых — да, много, но хочется ли заниматься только их поддержкой — на этот вопрос каждый отвечает себе сам.
Учи C#

А я понял одно: учить конкретный язык сродни зубрёжки стиха. Это инструмент, который осваивается за короткое время, если знаешь основы: ООП, технологии, паттерны и т.д. Ну а если ещё в теме бизнес-процессов, то и вообще отлично.
А фреймворки и IDE всякие осваиваются тоже быстро.
НЛО прилетело и опубликовало эту надпись здесь
Ну согласитесь, что если он идёт семимильными шагами, то что профи, что головастому новичку в .NET (но имеющему большой опыт в других направлениях) надо быть всегда в тренде, и рано или поздно последний догонит первого. Как быстро — зависит от способностей. А если нет знаний основ или опыта их применения — всё завязнет на долго.
НЛО прилетело и опубликовало эту надпись здесь
C# уже не тот:
www.tiobe.com/tiobe-index/csharp
так что — вопрос спорный, стоит ли его 'учить'.
Ещё относительно недавно вузы заменялись форумами типа инатака и античата, в которых кроме практических знаний прививались хакерские ценности. Да и шли туда уже ради знаний, а не потому что математику в школе хорошо сдал, а айтишникам платят много. *Тут могло бы быть много нытья на эту тему*. В любом случае, имхо, эти статьи не являются реальной выжимкой мнений сторон всей отрасли. Не всё ждут от вуза чего-то, а кто-то из него сваливает или даже не заходит. Не все преподают херню часами. Есть люди, которые в свободное от основной работы время ведут специализированные полезные курсы в интернете или при тех же именитых шарагах. Ну и далеко не все компании тащвт тебя в офис и выставляют, будто обучение тебя языку, на котором на найдешь нормальной работы или заказов на фрилансе, это что-то великое. А ты такой красивый попал на десятилетие работы.

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

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

Со всем согласен.
По образованию радиотехник, ВУЗ закончил три года назад и могу написать следующее:
Прежде всего, я поступил на обучение на базовую кафедру некоего предприятия, и это было в начале 4 курса универа (тогда ещё специалитет, т.е. 5 лет обучения). Выражаясь иначе — меня готовили к конкретной работе по конкретной тематике (разработка КВ усилителей) ещё в ВУЗ-е силами и средствами предприятия.
Но есть и минусы. Тематика работы специфическая и без перепрофилирования, при смене места работы, меня готовы взять лишь одна-две организации в Питере. Из этого вытекает ещё один минус — отсутствие конкуренции между предприятиями и претендентов на рабочие места делает зарплату стабильно "чуть ниже среднего" без шансов на ее повышение.

Немного оффтоп: из вуза разве не радиоинженеры выходят?
Из ВУЗ-а выходят пустышки, даже с красным дипломом знающие лишь какую-то платформенную основу и не готовые к продуктивной работе. Как автор писал выше, надо тратить время на их обучение. И так всегда, прямо 99,9%, через наш отдел прошло N-ое кол-во студентов, я знаю о чем пишу.
В моем случае было исключение, ибо: я радиолюбитель с позывным, у меня своя радиостанция, у меня тогда совпало обучение с получением позывного и начинанем работы для подготовки к выходу в эфир (а это целый комплекс мероприятий). Я бомбил преподов в универе тоннами вопросов, иначе ни черта бы я не знал и не умел.
Я пришел на работу и у меня был опыт в расчете, монтаже и настройки антенно-фидерных устройств. Для меня не был чужим паяльник (даже сейчас, кроме меня в отделе нормально паяет только начальник). И для меня была не совсем чужая схемотехника.
А кого выпустят из ВУЗ-а с таким опытом, крепко связанным со знанями? Никого, достаточно посмотреть на мою группу.
новичок ищет глазами гамак, пуфики, настольные игры и кроватки для послеобеденного сна.

<… но в офисе Regionsoft их нет>
А собственно почему? Действительно как-то глупо, что вы проигрываете конкуренцию за кадры даже не Avito, а картинкам из офиса Avito. Ваши проблемы с привлечением молодых кадров имеют объективные причины — CRM — скучнейшая область, технологии у вас дохлые. Естественно молодежь хочет игры, AI/ML, клевые технологии, с которыми можно релоцироваться в Калифорнию и красивые интересные офисы.
Открою маленький секрет — закупить пуфики, украсить офис и запостить фотки вот в этот корпоративный блог стоит 3 копейки, но может быть поубавиться причин размазывать сопли по лицу типа «джуны хотяяяяят нормальный офис, хнык-хнык». Но это, конечно, при условии, что ваших менеджеров не разорвет от ярости, если они увидят разработчика с ноутбуком с гамаке.
В этим соглашусь. С учётом того, что требования к кандидатам на стажера/джуна в команиях, где офис покруче, как-то не очень логично получается говорить, что кандидаты обращают внимания на офис. Если голова на плечах есть, то возьмут и в Avito, и в гугл, пускай на ту же небольшую зарплату, но с более крутым офисом. Хотя с другой стороны, я работал в компании с ужаснейшим по современным меркам офисом, ни тебе пуфиков, ни тебе гамаков, ни тебе даже дивана. Даже кухни можно сказать не было :) Однако атмосфера стартапа тащила, все были увлечены работой, всех всё устраивало. Работа напоминала тусовку профессионалов в общаге :) Сейчас работаю в отличном в материальном плане офисе, да и коллеги вроде тоже хорошие и приветливые, но нет здесь этого ощущения единения)
Сейчас работаю в отличном в материальном плане офисе

Таки ушли в другое место, значит причины были :-)
Я скажу что за причины были :) Когда есть зарплата N и зарплата 2,5N, то как бы просто было бы глупо оставаться в проекте. Доли в нём у меня не было, так сильно поднять зарплату они мне тоже не могли. Расстались мы с ребятами и начальством очень по-дружески с пониманием. Просто так сложилась ситуация и каждый из них меня понял. Иногда так просто бывает)
> гамак, пуфики

Навряд ли полезно для «спины»

>>> кроватки для послеобеденного сна

а вот это интересная идея

> разработчик с ноутбуком

Там же относительно «мелкие» экраны, неужели удобно?
«Не давит» ли «на глаза»?

А мышь? ( в варианте гамак / пуфик ?)

P.S.
> проигрываете конкуренцию... картинкам

Всё что выше — иллюстрация к «Картинки и Жизнь»

15' ретина — вполне удобно
А отсутствие «кнопки» Ж-) Ctrl-Ins?
( как-то открыл, что подсел было на «кнопку» F9-C-C Ж-) )

Insert сам по себе — не нужен, согласен

P.S. Или не Apple? :-)
15' ретина — недешевое удовольствие и невсегда необходимое. У нас в прошлой компании при хорошем уровне зарплат, была только пара корпоративных маков.
Примерно месячная зарплата на основной рабочий инструмент на несколько лет — почему нет?
Месячная зарплата студента только закончившего вуз? Это как покупать самые дорогие клюшки для гольфа, только знакомясь с правилами.

А фирма-конкурент — купила. И теперь "у студентов глазки не болят" и туда все идут, а вы — продолжайте плакаться.
Фирма "не только познакомилась с правилами", а уже Н лет на рынке. Парк техники обычно обновляется регулярно: компьютеры закупаются примерно 1 раз в 3 года. Если же там до сих пор работают на Pentium-II 400MHz — мне их вдвойне НЕ жаль.

НЛО прилетело и опубликовало эту надпись здесь
А Делфи — неудобно :)
А Делфи? :)

Таки есть и для Mac OS :-)
Кросс-компилятор точно был и отладка шла как раз на отдельном(?) комп-е с Маком
НЛО прилетело и опубликовало эту надпись здесь
На крайний случай — virtual machine
НЛО прилетело и опубликовало эту надпись здесь
Lazarus в помощь. Работает прямо на маках, линухах и вообще — всём подряд, вплоть то распбери. Сам отлаживал довольно толстый проект на линуксе в нём. Успешно.
Отладчик Lazarusа, который через gdb работает — полное днище, простите мой французский. Он очень медленный по сравнению с дельфийским, не позволяет смотреть properties, и вычислять выражения на лету. С ним можно отлаживать только пошагово, да смотря значения непосредственно переменных и полей. Этого, мягко говоря, мало.
Ограниченно проперти смотреть можно. Удобнее всего связка Дефли (win) + Лазарь (линукс либо еще что-то) на одних сырцах. Основная отладка идёт в Делфи/win, системно-зависимые фишки — в Лазаре по месту. Именно так я и делал, успешно было несколько проектов на линукс перенесено. Один порядка 800 тысяч строк. За 3 месяца где-то.
Ограниченно проперти смотреть можно

Помню, что настолько ограниченно, что просто швах. Переносил наш проект в Лазарус для эксперимента, с отладкой было тухло.
Еще вспомнил разницу FPC, которая мне много нервов попортила:
В Delphi процедурный тип — это всегда просто указатель на процедуру, даже если она вложенная. В FPC — если процедура вложенная, то процедурный тип для нее — это по сути лямбда — ссылка на саму процедуру + ссылка на зафиксированный контекст. И одно в другое тихонько компилируется, чоздавая AV.
Например:
procedure Abc(const APointerToCallback: TCBFunc; ASomething: TList; ASomethingElse: Boolean);
begin
...
end;

Далее есть у нас
procedure Def(g,h,i: integer);
var
 a,b,c: integer;
  procedure Ghi();
  begin
  ...
  end;
begin
  Abc(@Ghi, 1, False);
end;

У нас в APointerToCallback придет ссылка на Ghi, в ASomething — ссылка на окружение Ghi'я, на a,b,c, g,h,i. А ссылка на список упадет в булевую ASomethingElse, третий же параметр вообще уедет хз куда. И все это прекрасно откомпилируется без всяких предупреждений.
В FPC — если процедура вложенная, то процедурный тип для нее — это по сути лямбда — ссылка на саму процедуру + ссылка на зафиксированный контекст.

Насколько помню, в Си как раз потому и нет вложенных процедур — не ясно что делать с указателями на них

Например, мы выходим из родительской процедуры,
а указатель на вложенную в неё вернули в «дед»-код

А вложенная использует переменные из «отца»,
но их то в стеке уже нет

Короче, там ещё все «мутнее»
Локальные процедуры не могут быть колл-бэками, насколько я помню. В Делфи это просто запрещено. FCP, возможно ошибку не пишет.

Выражения на лету может. Не может функции.

А если выражение включает вызов функции?
Какой-нибудь тривиальный property Count: integer read GetCount и всё.

Это я и имел ввиду. Простые выражения может, с функциями не может.
Конечно, неприятная особенность, мягко говоря.

Сидеть на маке с ретиной, чтобы запускать делфи в винде в виртуальной машине — это как-то слишком.

a) «на крайний случай» т.е. требуйте у производителя обоснование пункт «B»
b) про Lazarus уже написали ( я просто не вспомнил сходу его название
и есть ли он на Mac как IDE или только на Linux)
Насколько я знаю — Лазарь + FPC работает под множеством операционок, Маки, Линуксы (включая распебери), различные Юниксы.
Ветка начиналась с пуфиков Ж-) потом добавился Apple
потом retina

а про Дельфи пытались намекнуть,
что не взлетит он как IDE на модно-молодёжном Ж-)

Лично я про Lazarus читал + смотрел года три назад
А развивается он весьма динамично — поэтому
персонально и не стал писать про L.

И про VM: на Маке некоторого ПО ( и не обязательно
для программирования) просто нет
( да тот же MS Outlook для Mac не похож на MSO для Win )

Но почему-то VM как способ решения проблем — не хотят
Да, согласен. В этом они прогирывают и понимают это. Но делают вид что не понимают.
Так может пусть молодежь поедет в Калифорнию, поработает там официантом и по совместительству учеником программиста для начала? А так — учить того, кто через год намылился уехать — какой смысл?
Есть лукавство в его словах. Например, совершенно дикое рассуждение о том, что раньше экономика требовала кадры, а сейчас всё подспало. Вы на вакансии компаний посмотрите, которые они закрыть годами не могут, оцените рынок труда — современная экономика требует гигантское количество кадров, но хотя бы с минимальной квалификацией и пониманием того, как учиться работать в бизнесе.

Да нет же, мое мнение простое и понятное. В стране советов была корреляция между кафедрами и отраслью. Может быть не идеальная, местами убогая, местами замечательная.
Где-то до 60-х было нормой, чтобы не только кандидатские, но и курсовые (sic!) шли на производство. Сделают 5-7 студентов курсач, лучший пойдет в отрасль. Сейчас даже кандидатские по факту ни к чему не привязаны. Макулатура.

Сейчас этой корреляции почти нет даже в IT. Что уж говорить о других инженерных кафедрах. Имелось в виду именно это.

По поводу незакрытых вакансий — это лишь подтверждает мою точку зрения.
Вот, напирмер, мой хлеб — ИБ. Вот список вузов. Но свежих кадров — кот наплакал!

Да, что ИБ, мы полгода хорошего PHP программиста найти не можем!

P.S> пользуясь случаем: если это читает PHP разработчик — напиши мне в личку. Ты нам нужен!
НЛО прилетело и опубликовало эту надпись здесь
А какие требования к хорошему PHP разработчику? И почему не можете найти? Было бы интересно почитать.

Может, стоит-таки сравнивать не с давно несуществующей ситуацией в давно несуществующей стране, а с нынешней ситуацией в развитых странах?

Ещё полгода дотянете, пока я стану хорошим PHP-разработчиком? )))
Как студент не могу не прокомментировать.
Полностью занимаюсь самообразованием. По поводу предьяв к вузовскому образованию полностью согласен(учусь я в одном из лучших уников мск). Оно мало того что отстаёт на годы от реалий так ещё и попросту тратит моё время ненужными предметами. При этом отличное знание предмета так сказать не освобождает от ответственности. Вот зачем посещать «Базы данных» если я в каждом втором проекте использую postgres? А вот нужно.

Но у меня есть несколько предьяв к работодателям:
Во первых это ужаснейший подбор кадров. HR рассылает вакансию которая выглядит интересно. Ты отправляешь резюме(в котором выделенным шрифтом указано что ты студент и тебе нужен «гибкий» график). Тебе перезванивают. Ты повторно говоришь что ты студент. Тебя зовут на собеседование. На собеседование ты понимаешь что твоё резюме никто не читал и то что ты студент они не в курсе. «гибкий» график тебе никто не даёт. Они потратили твоё время. И это далеко не единичный случай. В отдельном котлу должны гореть работодатели которые ещё перед собеседованием даёт тестовое задание.
Ещё меня забавляют работодатели которые «выращивают» под себя. Я понимаю что трудоустройство студента накладывает определённые издержки. Но ведь не до «бесплатной»(или почти) степени же. Не хочешь кормить нахлебника? — плати ему за выполненные таски. У твоего «стажёра» стимул, а у тебя прекрасный инструмент оценки эффективности. А если у него хорошие скиллы на которые он потратил не один год то не один уважающий себя программистчеловек не будет работать за еду даже если он студент.
А вакансии аля «не для стажёров» почти не светят. Придя на вакансию студент сталкивается с рынком. То есть помимо студента на эту вакансию претендуют и не студенты. И между дешёвым студентом но с гибким графиком работодатели отдают предпочтения не студенту с нормальным графиком.
После всего этого вообще пропадает желания откликаться на вакансии.

А вот с фрилансом всё хорошо. Студент может себе позволить демпинговать цены выполняя десяток заказов. Но правда количество «интересных» проектов стремится к «сделай сайт на wordpress» и совершенно нет стабильности.
Да, помню как во времена студенчества я демпинговал по-жесткому :) Правда я это только сейчас понимаю. Не было острой нужды в деньгах, жильё было общагой, на еду хватало и свободного времени была достаточно. Поэтому я вполне мог не особо запариваясь делать вещи задёшево и хапнул на этом опыта дофигищу) Это не были крутейшие сложные проекты, это были тупые и несложные вещи, на которых я оттачивал тупые навыки, вроде владения Git-ом, умение работать с отладчиком и IDE, вбивал себе синтаксис языка в подсознание, чтобы и посреди ночи не преходилось вспоминать как ж там правильно шаблонный метод в шаблонном классе определить снаружи класса :)
как ж там правильно шаблонный метод в шаблонном классе определить снаружи класса
Что?
НЛО прилетело и опубликовало эту надпись здесь

Вы говорите — «Кстати, немного об ответе преподавателя-совместителя PavelMSTU. Есть лукавство в его словах. Например, совершенно дикое рассуждение о том, что раньше экономика требовала кадры, а сейчас всё подспало.»


Закончив все тоже МГТУ, зарплата в Москве на конструктора составляет 25-35к после 6 лет обучения, в гос проекты устраиваться по полгода проходя проверки и собирая справки. Причём за эти деньги компании хотят видить ещё и опыт работы.
В разработке джуниор получается аналогичные деньги, а то и больше с навыками которые можно получить за пол года, гибкий график вместо работы с 9-18.
Идейный альтруизм это конечно хорошо, но экономической заинтересованности в инженерах не видно ни разу.

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

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


По вопросу приема-увольнения могу ответить абсолютно честно. За последние 2, да нет, даже 4 или 5 лет от нас не ушел ни один разработчик. Вообще, если посмотреть по среднесписочному составу, сотрудники у нас работают в среднем по 8 — 10 и более лет. Понятно, что некоторые компании используют так называемую ротацию персонала, когда каждые полгода штатный состав должен обновляться на 30%. Но руководство RegionSoft этого не приемлет — у нас другая стратегия. Для кого-то она ошибочная, но не для нас.

Ну не, если за 5 лет от вас не ушёл вообще никто, то вы и правда сказочная страна Оз. Тогда ваш опыт уникален, но применим только к вам. В любом крупном городе большинство контор довольно активно нанимают спецов, потому что так же активно теряют, в том числе за бугор (последнее время эпидемия).

Вероятно не Delphi некуда терять, особенно за бугор…
Да и вообще, вот чисто психологически — какие амбиции могут быть у человека, который не поддался ни на один хайп и пошёл работать на Delphi? Не говорю, что это плохо, но ответ очевиден!

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

А кто сказал, что наши разработчики сидят только на Delphi? У нас ведутся разные работы. И для Windows, для iOS и Android, web-разработка, та же VoIP-телефония с привязкой к платформе Linux и т.д. Используются и C#, и Eclipse, и Anroid Studio, а также другие среды и методы разработки, в зависимости от задач. Мне кажется такая картина у всех вендоров.


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

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

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

В очередной раз натыкаюсь как вы нахваливаете свою CRM. В этот раз даже попытались оправдать ее скупой вид, тем что она для серьезный вещей. Но это глупо. Наймите нормального дизайнера, он вам за неделю объяснит и покажет как правильно, а как нет. В следующих статьях уже будете говорить, что вы современная компания, которая заботится не только о «уважающем себя бизнесе» но и просто о людях.
Евгений, здравствуйте.
Осмелюсь поинтересоваться, а Вы статью читали вообще? У меня вот ощущение, что нет.
Добрый день, Алексей.

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

P.S. в следующий раз, когда наткнусь на вашу статью, напишу похожее сообщение. Я просто хочу помочь. Почему вы так это отторгаете?

С уважением (и кровью в глазах), Евгений

Евгений слишком ревностно относится к компании RegionSoft. Она ему не дает покоя :). Внимательно следит за постами и считает необходимым в каждую статью всунуть какой-нибудь грязный комментарий, даже не относящийся к теме статьи. Что-же, все люди разные. Кто-то радуется, что у соседа дела идут хорошо, а кто-то ему втихаря под забор гадит. Одно радует: раз есть такое пристальное внимание к компании, значит она идет верной дорогой :)

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

А то что там вам кто-то под забор гадит или завидует и прочее оставьте для разговоров на скамейках у дома.
Дизайн сайта regionsoft.ru, как по мне так он нормальный, мгновенно открывается на моем глючном интернете, информация на сайте удобно организована.
А если не нравится его html и css, так зачем это вас заботит, не вы же его поддерживаете.
Неожиданно :-) На самом деле, клиенты как раз любят сайт за информацию, прайсы, калькулятор и подробные описания. Не знаю, выскажу прямо своё субъективное мнение — я устал от однообразных сайтов с крупными элементами, слайдерами, навигацией а-ля лендинг, спрятанными ценами и минимумом информации. Всё же мы про бизнес-софт, а не про приложения для знакомств…
то вузы не дают нам тех специалистов, которые нам нужны


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

Почему для студента — спасение утопающего дело рук самого утопающего, а для бизнеса обязательно должен быть добрый дядя который все за вас сделает?
Почему это? Мы берём людей и обучаем их под себя: программистов ли, продажников ли, маркетолога ли… Я так делает довольно много компаний вне зависимости от размера, сферы и положения на рынке. Никто на новой работе в первый день не сядет и чудеса творить не начнёт.
Почему для студента — спасение утопающего дело рук самого утопающего, а для бизнеса обязательно должен быть добрый дядя который все за вас сделает?

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

Причем тут вузы, вуз не может заставить человека учиться, а как показывает прошлая статья и отчислить тоже. К вам может прийти такой же антиспец без образования, только там нельзя будет обвинить вуз.
Я вижу вакансии с неадекватными требованиями, как и соискателей с неадекватными запросами, что выглядит вполне логично. Строгость требований компенсируется необязательностью соответствия?
Ребята в этой конторе просто еще не поняли что работа по кадрам это отдельная и большая тема, серьезноая работа, а не 3 часа проговорить с ген. директором и получить какие-то ощущения. Еще в 20-х г.г. КПСС это поняла и работала под лозунгом «Кадры решают все». По этому для работы по кадрам наймите себе кадровина, или HR, как счас модно, а то дров наломаете. И гендир не будет мучатся по 3 часа)
лозунг «Кадры решают все».
Висит в Японии в цехах
У нас есть кадровик, точнее HR. Но мы просто не грузим соискателей тупыми тестами, вопросами про то, кем они себя видят через пять лет и просьбами решить задачу про канализационный люк. «У нас свои методы работы с молодёжью» (с)
мы просто не грузим соискателей тупыми тестами, вопросами про то, кем они себя видят через пять лет и просьбами решить задачу про канализационный люк.
Так и хорошо

И об общечеловеческом:

( Не о политике, разве что кадровой)
Еще в 20-х г.г.
Решил проверить, т.к. всё-таки помнилось, что прозвучало это после того,
как были построены «тракторные» ( и не только) заводы

И не зря: есть один показательный штрих:
Лозунг «Кадры решают все» впервые произнес Сталин И.В. в 1935 году.

Судя по стенограмме выступления Сталина на приеме выпускников военных академий РККА,
4 мая 1935 г., ставший столь популярным лозунг «Кадры решают все»
первоначально звучал так: «Кадры решают все, а не кобылы и машины».
И лишь после соответствующей сталинской редактуры он принял знакомый всем вид.

Про «основные фонды»+капитал первой трети прошлого века:
И тут же один из них стал торопиться куда-то, заявив, что «надо бы пойти кобылу напоить».
+
«Людей мы завсегда сделать можем, а вот кобылу… попробуй-ка сделать кобылу»


На всякий, последнюю фразу не И.В.Сталин сказал, это ему свою кадровую политику дореволюционного времени местные сибиряки «коротенько» разъяснили

Что бы не на печальной ноте, «кадровикам» от т.Сталина:

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

<TABLE class=topmenu align=center height=5 border=0 cellPadding=0 cellSpacing=0 width=1200 bgcolor='#FFFFFF' bordercolor='#CCCCCC'>
а ведь кто то все эти калькуляторы и прочие радости на сайт добавляет — то есть он не мертвый с ним явно взаимодействуют)
А вы как думали? Конечно, взаимодействуют, и крайне активно. И потом, разве компания с мёртвым сайтом или продуктом решится писать на Хабр, который вечно «на острие атаки», да ещё в блог, да ещё не так, как пишут про CRM остальные вендоры?
Был опыт преподавания в техникуме по совместительству (специальность — автоматизация) на Крайнем Севере. Зав. кафедры пошёл на уступки, чтобы позволить преобразить программу обучения. Также, использовали связи и организовывали экскурсии на реальном производстве. Студентам очень нравилось, успеваемость повышалась. Но такое встречается редко, к сожалению.
Щас бы пойти учиться программировать на Delphi в 2017. Фортран и бейсик в комплекте?

А если серьезно, то грех жаловаться на нехватку хороших кадров в компании практикующей устаревшие технологии.
в порядке «выкрика из зала» Ж-)

Quick Basic — вполне себе хорош для обучения

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


  1. Как думаете, вы адекватный бизнес или нет? Какой процент таких адекватных бизнесов в РФ?
  2. Как вы оцениваете экономический эффект программиста? В чем он по вашему заключается?
  3. Как у вас измеряется, сколько программист принес бизнесу?
  4. Как у вас рядовой программист может оказать экономический эффект? Для это организован какой-то бизнес процесс? Например, он может влиять на стратегические решения монетизации и т.п.?
  5. Если программист качественно сделал работу, но отдел маркетинга слабый, это как-то влияет на доходы программиста?

Можно продолжить, но пока остановлюсь на этом.
Что-то не отвечают.

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

Без фактов, статья похожа на нытье.

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

  1. Уверен, что "адекватный". Неадекватный бизнес не может существовать 24 года. ИМХО.
  2. Программисты бывают разные. Есть программисты, которые участвуют в проектах по внедрению, есть программисты, которые принимают участие в разработке типовых тиражных решений, есть кто создает компоненты, оказывает техподдержку и т.д. У всех разная задача и по разному можно оценить их вклад в общее дело. Однако возможно, конечно. Например, при работе над проектами по внедрению, оценивается скорость и качество этих работ, долевое участие конкретного программиста в группе проекта, своевременное закрытие актов в соответствии с техническим заданием, коэффициент стабильности создаваемых модулей и низкий уровень багтрекинга.
  3. см. п.2.
  4. Любой сотрудник, будь то программист или секретарь, влияет на экономику предприятия. Если не прямо, то косвенно. Работая эффективно, любой из них приносит пользу, которую можно монетизировать. А в чем эта польза и как ее монетизировать — это прерогатива руководства. В каждой компании и даже в разных отделах одной компании локальные цели могут быть также разными.
  5. Если отдел продаж курит бамбук вместо того, чтобы продавать, то от этого пострадают не только программисты, а все остальные. Бизнес придется закрыть, если не будет продаж. И неудел окажутся все. Навряд ли в одной компании, администрируемой одним руководством, один отдел может работать эффективно, а другой курить в это же время. Скорее всего либо эффективно работать будут все, либо никто. По крайней мере другой ситуации я не встречал. (Прошу не путать отделы с конкретными индивидумами)
У всех разная задача и по разному можно оценить их вклад в общее дело. Однако возможно, конечно.

Мой опыт говорит о том, что это в общем случае невозможно. Изредка, например, на внедрении, можно судить о вкладе программиста по подписанным актам. А в коробке ни один формальный KPI не работает, только вредит.
Однако возможно, конечно. Например, при работе над проектами по внедрению, оценивается скорость и качество этих работ, долевое участие конкретного программиста в группе проекта, своевременное закрытие актов в соответствии с техническим заданием, коэффициент стабильности создаваемых модулей и низкий уровень багтрекинга.
Это всё субъективно. Это всё bullshit.
Надеюсь, что мой комментарий не будет воспринят, как оскорбление, а скорее – здоровая критика. Мне кажется, что выражу общее мнение многих ИТ специалистов по поводу статей такого плана.

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

На самом деле, основная проблема в Вашей ситуации связана не с разработчиками, а с подходом к разработке конкретно Вашего продукта.

Объясню по пунктам:

Во-первых, как сами разработчики воспринимают Вашу компанию и требования.

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

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

Писать на Delphi сейчас готовы или Old School программисты, которые тупо не способны перестроиться под новые реалии рынка или зелёные студенты, которые ещё не поняли в какое болото влезают, поскольку потом с таким багажом нигде не найдут себе работу.

Во-вторых, сам продукт вызывает множество вопросов.

С высоты опыта внедрений Enterprise CRM систем (Microsoft Dynamics CRM и 1С:CRM) не вижу в Вашем продукте ни одного существенного преимущества. По крайней мере такой вывод можно сделать из представленной на сайте информации. Даже по цене он выходит сопоставимо, а в некоторых ситуациях существенно дороже той же 1С уже с порога 25-30 лицензий, если 1С приобретается вкупе, например, с 1С Бухгалтерией, как обычно и происходит.

Теперь сами здраво подумайте, куда пойдёт молодой специалист: в никому неизвестную локальную компанию с устаревшими технологиями разработки и спорной методологией или в хорошо развитую партнёрскую сеть, где софт развивается очень динамично, есть развитое сообщество, современная методология автоматизации, высокие зарплаты и есть возможность с одним и тем же набором технологий переходить между различными решениями?! Последнее в равной степени относится и к 1С и к Microsoft Dynamics.

Вот и весь ответ, почему у Вас так мало хороших программистов.

Поверьте, на рынке огромное количество крутых спецов. Знаю это точно, поскольку на свои проекты и в компании клиентов регулярно подбираю программистов: 1С, .NET, RoR, NodeJS, PHP. Замечу, что подбор на проекты – более сложная задача, чем поиск на постоянку. Просто не только специалисты должны следовать за технологиями, но и компании их нанимающие.

И ещё одно – о вашем корпоративном сайте, который по логике является лицом компании, и имеет не последнее значение при найме специалистов, не говоря уже о продвижении Вашего продукта. На мой взгляд в 2017 году негоже ИТ компании иметь такой архаичный сайт. Более того «Лицо» Вашей компании содержит только на главной странице почти 300 ошибок, в него встроены Flash-баннеры, которые не поддерживаются многими устройствами, архаичный дизайн, устаревшая структура и вагон других проблем. Вы считаете такое положение вещей нормальным?

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

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

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

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

С высоты опыта внедрений Enterprise CRM систем (Microsoft Dynamics CRM и 1С:CRM) не вижу в Вашем продукте ни одного существенного преимущества. По крайней мере такой вывод можно сделать из представленной на сайте информации.
Как опытный (а вы называете серьёзные системы для внедрения, их абы кто обычно не внедряет) внедренец, вы делаете выводы о продукте по описанию на сайте. Вам это не кажется странным? Нам вот ещё и непрофессиональным кажется, например.

в никому неизвестную локальную компанию с устаревшими технологиями разработки и спорной методологией или в хорошо развитую партнёрскую сеть, где софт развивается очень динамично, есть развитое сообщество, современная методология автоматизации, высокие зарплаты и есть возможность с одним и тем же набором технологий переходить между различными решениями?! Последнее в равной степени относится и к 1С и к Microsoft Dynamics.
Это вы с чьего-то маркетингового буклета списали, да? Печально. 1. Мы не локальная компания — у нас 6000+ внедрений (!) по России и СНГ. Если мы сидим в Нижнем Новгороде (кстати, городе с огромным ИТ-кластером, что отдельно мешает искать людей — конкуренция огромная просто), то это не значит, что мы не работаем для любой точки Земли. 2. У нас нет устаревших технологий и методологий. 3. А как партнёрская сеть и сообщество соотносятся с работой программиста и его выгодами? Похоже, вы давно отошли от рынка CRM и не в теме, как он сейчас функционирует.

у Вас так мало хороших программистов
Кто вам такое сказал? Мы растём, нам нужны ещё :-)
У нас нет устаревших технологий и методологий.

Как минимум, два есть — Delphi и ваше требование full-time в офисе. Сами же говорите, что вокруг огромный ИТ-кластер, но почему-то пытаетесь с ним конкурировать устаревшим способом. Особенно это требование странно смотрится в сочетании с этим:
… у нас 6000+ внедрений (!) по России и СНГ
… это не значит, что мы не работаем для любой точки Земли

По поводу Delphi — все правильно написал msav, начиная с ключевых слов "Поставьте себя на место молодого программиста, который ищет работу". С точки зрения молодого программиста ваше понимание правды и лжи, модерна и старины инструментария, крутизны продукта, с которым он не работал, не имеет значения. Пока вы его не убедите, разумеется.
Что-то обсуждение статьи на 50% стало обсуждением наследства «дедушки Вирта»
и о том, что знание(!) одного из языков программирования, чуть ли не помешает(!)
найти работу...
За то время, что начинающий программист потратит на освоение Делфи для этой работы, на другой работе он мог бы освоить что-то гораздо более котируемое на рынке труда.
На ADA вместо Delphu — согласен

Иначе страшновато, например, за ответственные применения:

Сейсмоподвеска гостиницы «Казахстан» в Алматы, уникальное по тем временам сооружение в 10-балльной зоне, была спроектирована как дипломная работа моим преподавателем по термеху. Весь их выпуск работал над этим фактически, то есть реально можно было взять диплом выпускника кафедры сопромата и по этому диплому строить уникальное здание.

Delphi котируется, и ещё как — да, он не столь популярен, как тот же PHP или Java, но зато он нужен в таких проектах, куда придёшь работать — и всем удовлетворишься: промышленность, энтерпрайз, среды разработки и т.д.
и всем удовлетворишься
Не надо всего, в РФ достаточно 300000 рублей и родственника из фсб.
Как это котируется и непопулярен одновременно?
Ох уж эти сказки и сказочники.
Непопулярен = мало специалистов, пишущих на нем; котируется = эти специалисты хорошо оплачиваются.
Отвечу, наверно, здесь: мне почему-то казалось,
что Delphi _специально_ изучать кому-либо просто и не потребуется

Паскалю и Ко учат ( Ok: не везде, но очень, и очень часто )
на первых же курсах, а то и раньше
Э-э-э, несколько принудительно Ж-)

Потому и писал: что есть предложение «вымарывать» из резюме?
Ибо увидев «не кошерное» не возьмут на работу?

Тогда совет: заводим 2 резюме Ж-)
В моем ВУЗе меня на первом крусе в 2006 учили в рамках предмета «Алгоритимизация и структурное программирование» как раз Паскалю, и ООП на его основе. А сейчас уже учат Java'е.
Вот и я начал подозревать, что уже может и меньше обучают Паскалю
НЛО прилетело и опубликовало эту надпись здесь
Вы не обижайтесь, но судя по многим вашим репликам здесь на хабре, у вас достаточно специфические вкусы и потребности.
НЛО прилетело и опубликовало эту надпись здесь
Delphi вполне нормально осваивается за несколько месяцев. Перейти на тот же сишарп достаточно просто, если нужно.
Да что все привязались к Дельфи? Вопрос не выбора я зыка и платформы — фича в том, что молодым просто НЕ ИНТЕРЕСНО все, что касается бизнес-софта! Хоть ты 3 раза на NodeJS пиши!
Такая ситуация в любом бизнес-софте — потому что недостаточно знать язык или технологию — надо как-то разбираться в учете, экономике, планировании и т.п. ужасно скучных вещах!
То-ли дело клепать сайты или игрушки!
молодым просто НЕ ИНТЕРЕСНО все, что касается бизнес-софта!

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


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

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

Для молодых — в основном нет. Это сложно, матаппарат сложный.
Для молодых — в основном нет. Это сложно, матаппарат сложный.

Можно подумать у всех молодых все так плохо с матапаратом, особенно программистов, которые только вот закончили ВУЗ.

Не у всех, но и предложенная задача не массовая! Уж CRM всяких и ERP на порядки больше.
НЛО прилетело и опубликовало эту надпись здесь
молодым просто НЕ ИНТЕРЕСНО все, что касается бизнес-софта!

Каждый сам расставляет приоритеты. Молодых программистов немало в разработке бизнес софта. Их незаметно по одной простой причине, например, чтоб стать опытным разработчиком на платформе 1С мало быть просто «кодером». Сама разработка на платформе сейчас существенно сложнее стала, а в дополнение нужно ещё и хорошо знать прикладную часть бизнес процессов: бухгалтерию, бюджетирование, производство, логистику и пр. В результате, реально себя специалисты проявляют ближе к 30 годам.

В отношении Microsoft Dynamics ситуация ещё жёстче: разработка сложнее, чем в 1С, да и сами системы сложнее. Поэтому средний возраст для опытных ИТ специалистов на этих платформах ещё выше.

Много работаю с молодыми программистами. Некоторые 20-23 летние могут в части технологий запросто утереть нос более опытным коллегам. Просто у них практического опыта пока не хватает. В хорошей команде такие специалисты себя прекрасно проявляют. Мне кажется, что многие, кто в этой ветке высказывается с недоверием к новым Junior специалистам просто забывают о том, что когда-то сами были «зелёными» и не знали с какой стороны подойти к технологиям.

На мой взгляд, работая с людьми, чтоб их понять, в первую очередь нужно ставить себя на их место, а не судить с высоты собственного опыта.
В результате, реально себя специалисты проявляют ближе к 30 годам.
Не забудьте проявить их зарплату, чтобы мы поняли что там стоящего проявилось. А то я уже начинаю переживать за себя, неужели я зря 10 лет назад, с большим опытом в 1С, с 1С на .net + web перешел.
Зарплата 1С программистов совсем не секрет. Чтоб понять уровень, достаточно зайти, скажем на Head Hunter.

Разброс зарплат по вакансиям существенный. Есть отчаянные работодатели, которые пытаются найти программистов и за 30 тысяч рублей в месяц. Но реальность такова, что уровень зарплаты 1С разработчика с опытом и знанием прикладной части колеблется от 80 до 170 тысяч в месяц. Сумма зависит от специализации. Наиболее высокооплачиваемые – «производственники» и «финансисты». В частности те, кто работает с 1С ERP и 1С КА. Так же высокий уровень оплаты у программистов со специализацией по строительству на отраслевых решениях 1С БИТ Строительство Корпорация. Чуть меньше – разработчики, которые ограничиваются работой только с УТ, причём 11-й версии. 10-я сейчас не в тренде давно. Меньше всех – «зарплатники» со специализацией по ЗУП. Но с ЗУП есть один нюанс, если проект идёт на производстве, добыче или строительстве, где очень сложный расчёт з/п, там тоже могут быть достаточно достойные зарплаты – 120-150 тысяч.

Приведённые уровни зарплат верны, в первую очередь для Москвы и СПб, и касаются постоянки. Причём тут речь идёт о 100% белой зарплате. Вообще, хорошего спеца в Москве и Питере на серую зарплату найти сейчас сложно.

Если говорить об уровнях вознаграждения для проектной работы, то тут суммы выше. Опять же зависит от квалификации, знания прикладной области, специализации и формы сотрудничества. Выгоднее всего специалисту работать по договору подряда в качестве ИП. В этом случае при 100% официальных расчётах и заплаченных налогах, он получает максимальное вознаграждение.

Если Вы .NET программист, то не могу сказать, что размеры зарплат у Вас могут быть меньше. Другое дело, что российских работодателей по .NET маловато. Если Ваш нынешний уровень меньше указанного мной в отношении 1С, советую посмотреть в сторону зарубежных работодателей или устроится на работу к партнерам консалтерам, которые занимаются Microsoft Dynamics. Тогда и переучиваться не придётся.
Это был сарказм.
Я хочу сказать молодым, чтобы учили English, он с нуля, за год учится, если заниматься по часу в день самостоятельно. (да, говорить самостоятельно так не научишься, но писать, читать и слушать — научишься.)
Не стоит идти на 1С, ни скорее всего на Microsoft Dynamics.
Не стоит работать на местных жлобов, особенно если работаешь не в столице, рынок программистов — глобальный, работай на тех кто больше платит.
учете, экономике, планировании и т.п. ужасно скучных вещах
Это не скучно и довольно доходно. Паче что, работая в CRM-вендоре, разработчики получают навыки и системной интеграции, и работы с другим софтом, и ведения проектов, и работы с клиентами. Полное погружение на сторону бизнеса — а бизнес это не менее интересно, чем игры или какие-либо сервисы.
Меня за советскую власть агитировать не надо! Это становится интересно лет с 30. Нет, есть конечно отдельные личности, но в основном — просто не хотят с этим заморачиваться. Им подавай «чистое» программирование — а разноска накладной — не, не хотят!
разработчики получают навыки и системной интеграции, и работы с другим софтом, и ведения проектов, и работы с клиентами.
Это типа — «вы получаете навыки и это наша плата вам.»?
Намекаете что «приходите к нам работать за копейки, зато получите опыт и будете думать что сможете себя продать подороже другой фирме!»?
Опыт не релевантен.
Полное погружение на сторону бизнеса — а бизнес это не менее интересно, чем игры или какие-либо сервисы.
Я так и знал. Зачем деньги платить, вы же на работе удовольствие получаете.

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

Зачем навыки системной интеграции, и работы с другим софтом, и ведения проектов, и работы с клиентами, если на 1С, предел по ЗП был в 1200usd, с кучей лет опыта, когда на жаве от двух лет ЗП больше? :-)
Видимо, я не очень доходчиво выразился. И да, очень печально, что Вы пытаетесь сразу переводить все на личности, указывая, что своё мнение я где-то списал. Как понимаете, если у меня есть опыт внедрения крупных CRM систем, коммерческое предложение или продающее письмо для ИС в состоянии написать грамотно, а тем более – обычный комментарий к статье.

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

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

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

В Вашем случае ситуация с наймом абсолютна аналогична приведённому выше примеру.

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

В дополнение к вышесказанному, информация для размышления. Говоря о востребованных технологиях (.NET, Node.js, RoR, современные PHP Frameworks), приведу показательный пример: просто работа на UpWork позволяет спецу зарабатывать ~100-150К руб. в месяц уже через 4-6 месяцев активного выполнения заказов. Не говоря уже о прямых контрактах с заказчиками. При этом, вот прямо в настоящий момент запросов по разработке на Delphi там всего 51! На мой взгляд – это очень показательно.

Как вариант, можете поставить эксперимент и реализовать часть своей системы с использованием современных технологий. Вы сразу увидите рынок IT специалистов, с другой стороны. К Вам будут приходить на собеседование реально грамотные и опытные разработчики.
Текст напомнил прошлое место работы, там тоже разработчики работают по 5 лет с з/п 25-35 тысяч. Один я со своими завышенными ожиданиями и опытом в год свалил на 70 :)
Интересный опыт! Вы бы подробнее рассказали — город, сфера, стек, ваш возраст. А то, если строить догадки по нику, то можно и не поверить :-)
Вы правда думаете, что люди 94-го рождения не могут требовать 70 и могут только 25-35? :) Просто я вот 93-го и зарабатываю больше (С++, разного рода софт по управлению сетевыми устройствами).
Возраст не имеет значения. Нас больше интересует факт «поработал и свалил». То есть человек в 23 года уже устроился, получил опыт, смог промоутиться на 70 тыс. Искренне интересно, как он это сделал, что за сфера и главное — город.

А у вас сколько лет опыта? Наверняка нее 1-2? Работали с вуза?
Работал с четвертого в ВУЗе админом в маленькой конторке с компьютерным парком на 22 машины. Программировал только по фрилансу (также с 4-го курса), но в основном всякие курсачи да дипломы делал. Были пара коммерческих заказов, но это скорее везение.

Впервые устроился на работу программистом в октябре 2015-го. Проработал 3 месяца, не вкатило, ушел на другую работу, где проработал чуть больше года за 35к. Там всё было хорошо, но потом другая компания и предложила раза в 2 больше, а потом еще и повысили через полгода. Вообще, если подумать, завтра будет ровно 2 года моего стажа)
У меня было 4 года опыта сисадмином в конторе на 12 компов, 10 месяцев работы в эксплуатации CRM в большом телекоме (OracleSQL хранимки и джобы) и последнее — 2 месяца Golang+Angular2 разработчиком маленькой CRM. Не планировал так быстро уходить, просто забыл скрыть резюме и не смог отказаться от предложения. Ушел на Python Backend разработчика. Пишу на питоне еще с начала универа — всякие свои утилитки и курсачи, но никто меня не хотел брать без реального опыта написания RESTful API по Agile Kanban методологии с покрытием юнит-тестами, просто умения программировать для джуна было мало. А тут, наверно, сам факт, что я уже устроился программистом, сыграл в мою пользу.
Город Краснодар, в ту первую компанию привел своего одногруппника, который сидел дома почти год и «не мог найти работу», теперь там сидит, в коллектив вписался отлично :)
Я из Иркутска. В 17 пошёл работать техником ЭВМ. В 22 уже был маленьким начальником небольшого отдела. В 25 уже имел почти 40 человек в прямом подчинении и отвечал за ИТ-инфраструктуру компании, покрывающей территорию трёх стран. Так что Diman_94 вполне мог успеть.
НЛО прилетело и опубликовало эту надпись здесь
В Иркутске есть множество федералов и отраслевиков, у которых можно начать в филиале и через несколько лет стать сотрудником центрального офиса.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

А что такого в 70тр с годом опыта? На мой взгляд, просто адекватная зарплата.
У вас спецы меньше имеют?

В регионах 70 килорублей — это большая зарплата, до неё долго добираться.
А что странного-то? Я вот в свое время (январь 2012) начал работать на 2 курсе. Чуть больше, чем через год, в середине 3 курса, получил оффер на 120к, что было заметно больше моей тогдашней зарплаты. Правда, я этот оффер отклонил, но то совсем уже другая история.

Можно просто поехать в Нидерланды и там устроиться на работу дворником. Там минимальная зарплата по закону 5500EUR. (больше 400 тыр.) Чего так париться? Еще какие-то языки программирования изучать...

1500 евро, если быть точным
Там минимальная зарплата
А в «гамбургерах»?
(Есть такой метод в эконм. науке)
Я просто оставлю это здесь.

Можете свалить и на 700. Не стоит стесняться лезть в гуглы: там отнюдь не гении работают, но за ту же работу будут платить совсем другие деньги.

Гуляя с приятелем программистом лет 5 назад, я говорил, что через 3 года настанет момент, когда проявит себя деградация среди людей разработчиков. Уже тогда потенциальные работники, студенты, соискатели хотели сразу много и быстро. Даже с моим приятелем был шутливый спор, почему его студента не берут нигде на работу из-за отсутствия опыта. И вот статья проливает на свет эту самую проблему.

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

Лично я очень предвзят по отношению к «копипаст». Всякие возгласы «зачем делать то, что готово, это экономит время, оно уже оттестировано, исправлены все ошибки, прошло обкатку и бла бла» для меня звучит так «я не умею, и не смогу сделать это, извините у меня опыта и знаний нет». В тоже время я совершенно согласен со всеми этими доводами, если это говорит человек, который действительно может это сделать, т.е. у него есть опыт в данном направлении. В доказательство своих слов приведу пример: в 2009 году, когда я только становился на ноги, у меня случился баг. Плагин FancyBox неправильно позиционировал изображение при открытии. При этом только в Opera. Я открыл интернет и стал рыть. Потратив 40 минут и найдя советы от «смени браузер» до «поменяй на другой плагин или обнови библиотеки», я сильно разочаровался и просто подумал: «JavaScript знаком? знаком… позиционирование делал? делал… Ну так разберись». Через 3 минуты баг в плагине был поправлен, без хаков и всяких переписываний, буквально было добавлено пару значений в место где вычислялась высота. Вот с того момента я копипастеров не люблю. Они лишь могут доказывать свою несостоятельность.

А был у меня клиент, которого обслуживала студия всем известного веб-дизайнера. Клиент пригласил меня, и попросил сделать им проект. Точнее переделать тот, что вел тот самый печально известный дизайнер. Из их претензий к нему была банальщина. Идиотская и просто неописуемая, от генерации случайного числа, не возможно использовать встроенный редактор, до «извините но это технически не возможно», когда просили блок новостей поместить в другое место страницы. У меня от ладони на лбу след наверное недели лежал, когда я все это от них услышал… А все почему? Потому, что «набрали по объявлениям» разного рода «а сюда мы поставим этот плагин», и гребут бабки. Потом нормальные разработчики разгребают это <***>, извините.

Вообще у меня тоже много накипело. И про кадры, и про маркетинг, и про юзабилити. Я всегда за библиотеки, за готовые решения, за быстроту и минимум исправлений. Но я против, когда человек не может сделать ничего, кроме как поставить новый плагин интернет-магазина (дада, я таких встречал) за 30 000 рублей =)

Человек без знаний и опыта априори не должен получать больше того, у кого больше знаний и умений. И мне совершенно не понятны жалобы, типа «а почему он делает меньше, но получает больше?!».

Потому, что тебя можно уволить, а его себе дороже =)

пысы: извините за многабукаф, ну накипело =)
пысы2: всегда рад тем, кто жаждет нового. пусть начинает с установки всяких движков, плагинов, библиотек. но всегда задаст вопрос «а как это сделать», и проведет пару ночей в угаре, но добьется того же но своими силами. Пусть с лагами, ошибками, но добьется. я знаю таких людей, они очень быстро развиваются, их проекты в итоге грамотные, понятные, закоменчены и главное — они больше доверяют своим силам, а не чужим. я вообще «за», что бы со школы начинали внедрять начало программирования, а не то как в ворде слово «собака» жирным сделать. пусть школота знает как собрать системник, как поставить винду, линь и фряху и понимать их различия. минимум, что требует современный ИТ-мир. иначе так и будут мелькать на башорге, что то вроде «ххх: дайте IP какого-нить лоха! ууу: 127.0.0.1 ххх: Спасибо! Сейчас он умрет!» =)
НЛО прилетело и опубликовало эту надпись здесь
«ххх: здравствуйте, это канал anime? ууу: да ххх: как пропатчить КДЕ под freebsd?»
Стараюсь все сам делать. Но в абсолютном большинстве все устраивает ас из.
Грустно все это :( Еще грустнее становится от тех людей, которых готовы браться обучать, а они ворочают носом еще и что-то требует сверх своих знаний, либо требуют и учиться не хотят

Всю суть проблемы можно описать коротко: системное отсутствие трудолюбия. От этого и возникает перекос рынка. Работодатели выстаивают бизне-процессы исходя из того что, большинство разработчиков рукожопы, студенты не требуют от учебных заведений актуальных знаний (да, должны требовать, я считаю, но в силу своей лени просто едят что дают по старым и кривым учебным планам), сами учебные заведения не хотят заглянуть на полшага вперед и посмотреть на себя как на бизнес по продаже знаний. Всем все тотально лень. Лень думать, лень делать, лень шевелиться.

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

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

погуглите "студенческое движение"

Ага, вместо того чтобы хотя бы самообразованием заняться, трудолюбивый студент пойдет «флагами махать» за идею…
Много знаете случаев когда от этого движения был какой-то реальный положительный результат?

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

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


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


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

Самое обидное, что у нас преподаватели были — грамотные и опытные, готовые делится знаниями, причем по очень актуальным в современной науке предметам, но на их предметы выделяли по семестру всего, а вот устаревшей и никому не интересной и не нужной фигней было забито все расписание…
(PS: Это была не IT, а естественно-научная специальность)
НЛО прилетело и опубликовало эту надпись здесь
А что они могут?

Как минимум не допустить, чтобы проблема стала данностью и не породила новые проблемы.
Всю суть проблемы можно описать коротко: системное отсутствие трудолюбия… Всем все тотально лень. Лень думать, лень делать, лень шевелиться.

image

Хех, как любил говорить наш преподаватель по организации ЭВМ, когда мы решали задачу в лоб: «Ребята, судя по вашему решению, вы мало лежали на диване».
«P.S.: пользуясь случаем, напоминаем, что мы ищем программиста Delphi и web-разработчика… „

“Почти все наши программисты пришли к нам студентами и всех мы вырастили сами, начиная с языка и заканчивая code style. Неудивительно, что такие люди работают в компании по 10-15 лет — они идеально к ней подходят.»

Есть у меня смутное подозрение, что «подходят» у вас люди по 15 лет лишь потому, что никому другому они с вашим «обучением» не подходят. У вас система на DELPHI и вы собрались кого-то учить code style? Серьезно?

Если вдруг это читает кто-то из молодых программистов, ребята, помните, никакая региональная конторка ничему хорошему вас не научит (как собственно и ВУЗ). В мире есть ограниченный список программистов, у которых стоит учиться. Он вряд ли шире 100 человек, и они не сидят в региональных конторах. Они выступают на топовых конференциях и пишут книги.

П.С. Если у кого и имеет смысл учиться code-style, так это у Robert C. Martin, ака «Uncle Bob».
Я политолог по образованию. Программировать начал с макросов для Ultima Online Pilot, а там добрый друг подарил мне Кернигана и Ритчи «Язык программирования C». Потом VBA для автоматизации работы со статистикой и Action Script 3 чтоб открыточки рисовать. А там -книжка по C#, по SQL, по WPF, по JS, опять по C# и ещё штук 20 на разные темы…
Сейчас я архитектор в крупном международном банке.
политолог по образованию
Как раз не-математиков и любят мучать Паскалем ( хорошо если не Basic-ом, причём тем что с нумерацией строк)
добрый друг подарил мне Кернигана и Ритчи «Язык программирования C».
А мне вот подарили тоненькую книгу зелёно-белую.
Во второй половине — штуки три новеллы Э.Дейкстры и ещё парочку про социальную ответственность программиста...

P.S. вот он как социализм людей не так ориентировал Ж-)
просят суммы, совершенно не соответствующие квалификации и умениям
Как будто платят за квалификацию, а не согласно ситуации на рынке и умению найти халяву и искусству себя продать. Если кандидаты найдут где больше платят, то они уйдут, а вы будете и дальше ныть.

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

Думаю, иногда менталитет наших работодателей не позволяет повышать работнику зарплату, но охотно её повышают следующему человеку, пришедшему на то место.
бизнес поднимет зарплату хорошему сотруднику, и не раз. Но только в ответ на экономический эффект от работы сотрудника.
Меня, как не владельцу Твоей собственной компании, не очень то волнуют экономические трудности бизнеса, скорее наоборот, если у бизнеса проблемы — ищем работу там где нет экономических проблем.
От программиста зависит экономический эффект? А как вы его рассчитываете, поделитесь секретом.
Проще говоря, ты приносишь фирме больше — она тебя весомее благодарит.
Это вранье и ваши фантазии.
Но когда ты пришёл и компании предстоит тратить эффективное рабочее время инженеров на твоё обучение, она никогда не заплатит тебе сумму уровня миддла. Просто потому что пока ты — источник затрат: стол, компьютер, софт, IDE, обучение, еда-вода, Интернет и т.д. И пока ты эти затраты не окупаешь. Так что стоит реальнее относиться к зарплатным ожиданиям.
она никогда не заплатит тебе сумму уровня миддла
Заплатит. И даже зарплату синьора, запросто.
Это ваши проблемы что вам нужны специализированные знания, и вы их сами и будете окупать, если не можете найти человека с готовыми знаниями, вы найдете человека без знаний и заплатите за его обучение. Я трачу свое время на получение нужных вам званий, платите столько сколько стоит мое время на рынке. Мне нет никакого дела до того, что вы тратите на мое обучение еще больше чем платите мне зарплату.

Это и относительно жунов мидлов и синьоров. Никто вашей компании ничем не обязан. Извините, у нас не диктатура, каждый может пойти где теплее и мухи не кусают.
А через год, когда затрону вопрос повышения ЗП, не надо мне втирать, что — «мы тебя пол года учили». У нас не было договора что вы мне платите синьерскую зп, пол года учите и я на вас обязан еще два года отработать без пересчета ЗП.
Хватит ныть.
НЛО прилетело и опубликовало эту надпись здесь
+ вам
Пост замечательный! По нему можно оценить всю боль и полыхание седалища у руководителей небольших контор. Самое забавное предположим что разработчики которые пишут код в этой конторе 10-15 лет получают сферические 50-60к рублей, и вот к ним приходит разработчик и просит 70к рублей, и ему отказывают, через пару месяцев(лет) контора решает таки нанять программиста за 70к рублей, внезапно вся эта братия которая работала за 50-60к начинает задаваться вопросом, а что это новенькому платят больше чем нам, мы тут лучшие годы жизни конторе посвятили же! )))

Есть у меня друг, открыл свою небольшую типографию, сам там и работник и директор и курьер, бизнес пошел в рост, и вот сидим мы и он не жалуется:
— Люди совсем зажрались, мне вот нужен помощник, что бы на плоттере печатать, неполный рабочий день 25к, сиди себе в ус не дуй только кнопку принт нажимай, всем 40 тысяч минимум подавай
— Хех ты и вправду посадишь человека с зп 25к на многомиллионное оборудование? Или может ты всерьез считаешь что 25к это зп на которую можно нормально жить? Вот скажи почему человек должен меньше кушать только потому что по твоему мнению работа не сложная?
— …

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

Проблема в том что 80% нашего бизнеса работает по принципу «Нефть подоражала — бензин подорожал, нефть подешевела… бензин подорожал» т.е. если в конторе все хорошо к вам никогда не подойдут и не скажут «Серега мы в этом месяце сделали план продаж по CRM 500% ты как главный разработчик получаешь премию в размере 3 окладов молодец!», но как только бизнес пошел на спад так сразу к вам прибегут и скажут «Времена нынче трудные так что премии не будет вообще, а повышение зп откладывается до лучших времен… я уверен ты поймешь ты же лояльный сотрудник!»
Вообще — спасибо вам за дискуссию. Где-то объективно говорите, где-то троллите, но в целом интересно и живо. Мы не ноем — мы факты рассказываем. Точнее — это мы ещё не ноем :-)
У меня было несколько случаев недопониманий как в качестве когда я соискатель, так и в качестве когда я ищу программистов. Но за программистов в любом случае платил мой заказчик, а не я лично.

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

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

Если человек умеет программировать, умеет немного морды рисовать, знает SQL — берешь и дальше сам ему подсказываешь что да как. ЗП были от 800 usd и от 1200 usd и выше.

Для меня эта позиция, по капитански, очевидна, ее я тут и отстаивал.
Самое главное я не написал.
Через какое то время, скажем через год, они уходили уже с каким то опытом. Понятно что рынок уже мог предложить им больше, но не наш бюджет.
И что, у нас не диктатура. Я им что должен был говорить, ты у нас отучился — теперь отрабатывай?
Это же программисты, а не идиоты, зачем им беспокоится по чужому поводу.
Выгодно бери учи и отпускай, не выгодно — не учи.
Хах, кучу лет искал вакансию Delphi и web-программиста :) И вот она, родимая, но я уже слишком далеко от Нижнего Новгорода ))
Я немного все утрирую, но бизнес работников видит примерно так: Умеешь нарастить миллион прибыли, тебе половину оттуда, умеешь убрать миллион убытков, твои сто тысяч. Умеешь и то и то, твои шестьсот тысяч.

А твои дипломы/знания/регалии и т.д. бизнес мало волнуют. Бизнес есть бизнес.
Не, обычно бизнес видит работников как-то так: «Умеешь принести 1 миллион дохода? На тебе 100 тысяч. Умеешь принести 10 миллионов? На тебе 100 тысяч! Умеешь 100 миллионов? Господи, ты заслужил повышения — на тебе 150 тысяч».
Для бизнеса нормально мечтать о протяжной негритянской песне, доносящейся с бескрайних хлопковых полей. Никто не откажется получать много, отдавая мало. Платить много бизнес будет только тому, кого боится потерять. А это не только тот, кто умеет заработать миллион, десять или даже 100 миллионов, но и тот, кто готов прямо сегодня начать зарабатывать их конкуренту.
начнут пилить полностью какую-то Программу, а лучше игру. Не-а. Вы придёте и начнёте с малого — возможно, даже просто минимального тестирования.
Давай до свидания.
Я тут на программиста устраивается собрался, а не на тестировщика.

мы ищем программиста Delphi
Студентам — не ходите туда.
Работодателю — берите кобол, он проверен временем.
Я считаю что Delphi удобней c/c++, но в первую очередь нужно думать о деньгах которая дает работа и спросе инструментов на рынке. Ситуация такая что Delphi, к сожалению (или счастью), не выглядит перспективным.
Задача бизнеса — получать максимальную прибыль, в том числе за счёт снижения расходов на сотрудников. Если в нужные моменты не проявлять, как вы это называете, амбициозность и наглость, есть риск сидеть на зарплате ниже рыночной очень долго, не смотря на уровень знаний и опыт.
CRM — тяжёлая и возможно, не самая интересная разработка. Вижу, который раз обсуждают ваш сайт. Но могу сказать, что взяться и написать такой пост в ответ на предыдущие могла только опытная и уверенная в себе компания — так что молодцы, третье мнение реально оказалось важным и интересным. Желаю найти вам всех, кого ищете :-)

А с ВУЗами сотрудничать — вы не пробовали? Не пробовали — заключать договора с ВУЗами на отсылку своих специалистов, читающих лекции. У вас получается: ВУЗы — виноваты, потому что не дают нужного и нового, студенты — виноваты, потому что долбодятлы и требуют сразу миллионов, а вы сами — все в белом. Но при этом — любите переманивать готовых специалистов у других, кто таки тратились на обучение и рублём не попрекали? Нет, ну серьёзно — вынь да положь вам готового специалиста, а уж вы, после тщательной оценки, может быть поднимете ему зарплату. Вот такой вот посыл я проследил, что оказывается принять на работу студента это затраты. Студент оценивается, не как сотрудник, который принесёт профит, не инвестиция в будущее, а как затрата, которую надо окупить. Даже покупку компьютера и IDE к этому прикрутили. Как вы с таким мировоззрением ВООБЩЕ ИМЕЕТЕ НАГЛОСТЬ ПЛАКАТЬСЯ, что "кадровый голод" и "нормальных студентов нету"? Ребята, я уже давное не студент, но, будучи им, я бы к вам — не пошёл бы. Да — ВУЗ не учит нужному, да — студенты имеют запросы… ну так что ж вы хотели-то? Если за какой-то вшивый айфончег, склёпанный голодными китайцами — хотят сразу 1000$, то почему меньше должен хотеть подающий надежды специалист? Дизайнер? Почему вы хотите мало того, что встать в позу "берём или не берём" (мне напомнить про тысячи объявлений с пометкой: "2-ух, 3-ёх, 5-тилетний опыт работы"), так ещё и диктовать условия по зарплате в достаточно наглом виде, сразу же записывая издержки на потенциального работника? Риски надо — разделять! А по хорошему — брать на себя (студент этого в принципе сделать не может) и искать потенциал.
P.S. Работая в нескольких компаниях (больше 5) — я только в ОДНОЙ получал регулярный пересчёт зарплаты и добавку не обращаясь к администрации. То бишь только одна компания из пяти вообще считала себя обязанной АВТОМАТИЧЕСКИ компенсировать сотрудникам инфляцию, поднимать зарплату, мотивацию и вообще следить за этим. Так что не надо свистеть о том, что "ты сначала поработай, а потом ужо мы посмотрим" — такое считается в одном случае из 5 (или ещё реже в моём случае). Обычно, пока не прийдёшь и не скажешь: "гоните бабло" (но культурно!) никто даже не почешется, потому твои проблемы — это не их проблемы.
P.P.S. ИМХО, не надо винить ВУЗы или студентов — надо подключаться к системе образования и помогать менять в лучшую сторону, если она вам не нравится. Ах что я слышу — опять вы скажете "это же огромные затраты!"? Ну если хочется сразу "готовых спецов" тогда — кушайте что дают.

только вот тоже самое хотел написал, даже залогинился для этого. Спасибо, что вы есть :)
Работая в нескольких компаниях (больше 5) — я только в ОДНОЙ получал регулярный пересчёт зарплаты и добавку не обращаясь к администрации
А по моему опыту, из нескольких компаний (больше 5) только в одной не было пересчетов. И то лишь потому, что это был стартап, не проживший и полгода.
Личный опыт — он у всех разный.
Я за годы работы, лично опросил по этому поводу не менее 50 человек, судя по их отклику и общению их с ихними собеседниками, могу говорить что опыт в несколько сотен человек, на мой взгляд, однозначно утверждает — всегда меняй работу.
Ну, дисбалансы в экономике всегда присутствуют, так что совершенно очевидно, что рано или поздно возникнет такая ситуация, что будет просто по деньгам выгоднее уйти в другое место. Но не всегда такая ситуация возникает в первые пару лет.
А вы не сдаетесь :-) Что же, уточню, практика показывает что менять работу, с целью повышения ЗП, лучше не реже чем раз в 1 — 2 года!
Раз в 3 года это перебор, наверняка уже просели по рыночной ЗП! Конечно это не относится к глубинке где нет работы, но там надо искать удаленку и учить разговорный английский, затем менять работу если не повышают по рынку или выше рынка.
Мое мнение — фирме выгодно, сотруднику, с двумя годами релевантного для фирмы опыта, повысить ЗП выше рыночной. Но фирма этого не делает, а ищет сотрудника по рыночной цене, но с не релевантным опытом — абсурд! :-)
практика показывает что менять работу, с целью повышения ЗП, лучше не реже чем раз в 1 — 2 года
Полностью согласен. Более того, на мой взгляд, присматриваться к рынку нужно как можно чаще, хотя бы дважды в год.
В моей практике была ситуация, когда один и тот же работодатель оставался оптимальным по зарплате в течение 2.5 лет. А потом в один прекрасный день пришел другой и перебил предложение вдвое.

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

Ну так-то два года в одной компании — вполне средний срок.
Скажем так, это ответ компании, которая является на рынке скорее исключением, чем правилом. Ибо бизнес хочет готового специалиста, а возиться и выращивать не один год — нет, это к ВУЗу. Однако ВУЗ не может готовить конкретного человека под конкретную вакансию. ВУЗ даёт в большинстве своём академическое образование. И да, в том числе даёт возможность студентам попробовать свои силы поработать на предприятии в рамках учебной, производственной, научно-исследовательской практики. Но… Здесь наступает большое НО. Компании берут не всех подряд. Не все компании вообще согласны отбирать и возиться со студентами. Кто это готов делать — ВУЗы с ними работают.
Здесь же мешает озвученная проблема про то, что ВУЗам невыгодно отчислять студентов. Да, бизнесу на это плевать, он считает, что ВУЗы не выполняют свою функцию, но ВУЗ не может терять деньги и тем самым преподавателей, отчисляя лоботрясов. Если Минобр изменит своё поведение хотя бы для технических ВУЗов, тогда ситуация должна начать меняться. Тогда и практики на 100% будут другими, какими они должны быть, а не на 50% или в некоторых случаях ещё меньший %.
даёт возможность студентам попробовать свои силы поработать на предприятии в рамках учебной, производственной, научно-исследовательской практики. Но...
А вот у меня это «но» в свое время выплыло с неожиданной стороны. Я уже работал на тот момент, и работодатель был готов заполнять все необходимые документы, но ВУЗ сказал «нет, ты проходишь практику у нас на кафедре», и в итоге практика у меня заключалась только в бумажке.
Хорошо хоть работать не мешали.
Это странно. Видимо какая-то странная политика либо кафедры либо самого ВУЗа. Практики они для того и придуманы, чтобы обучающийся получил опыт работы на предприятии в процессе обучения.
Это очень странно. Но мне на тот момент было неважно — я и так и так работал.
очередной и вечный холи-вар.
Напишу о своем пути, пути немного другого вектора. Я вот учился на факультете радиоэлектроники. Из 18 человек в группе учебой интересовалось около 4-х человек, остальные галера. И вот мы выпустились, я погнал на завод, зеленый и с амбициями сделать что-то полезное для народа, после завода я поработал в шарашке и далее уже в коммерческих компаниях. Из всей группы я единственный кто работает по специальности. И я до сих пор вспоминаю препода по цифровой схемотехнике, который мне сказал, ставя 4 ку за экзамен: «В 80х эти вопросы были на тройку», вот тогда стало стыдно и интересно, какими же скилами нужно было обладать в те времена(а учился я с охотой и интересом, проблем у меня не было). Сейчас я потихоньку учусь программировать, пытаюсь где-то найти стажировку или работу. Вот тут я как раз и столкнулся с проблемами, которые у меня были после универа снова. Овер 10 лет опыта, куча технологий(должен то, должен это и в конце еще тарантеллу станцевать). А как получить опыт? С электроникой мне повезло, я его получил на заводе, туда мало мальски из-за нехватки кадров брали молодых специалистов =)
Здрасьте! Я тот самый студент, подрабатывающий на Delphi, набирающий опыт у фирмы, разрабатывающей ПО для строителей и архитекторов (BIM всякий), правда, живу в Берлине :)

Очень радует, что вы готовы обучать дельфистов :) Я со школы пишу на Delphi, технология меня вполне устраивает.

Расскажу то, что, возможно, вы будете считать интересным, а именно, что мне, как студенту, хотелось получить от работы и как я ее искал. Во-первых, компанию я искал (поскольку Delphi и в Европе «вымерший, не имеющий преимуществ, а еще не кроссплатформенный» (нет)) через митап Дельфи программистов в Берлине. На сайты поиска работы надежды сильно не было, ибо вакансии обычно уровня «опыт работы от 5 лет». В итоге был выбор между двумя компаниями, но выбрал ту, где предлагали удаленную работу (учиться то надо), рабочий ноутбук (денег нет) и последнюю версию Delphi (юношеский максимализм + релевантный опыт ибо Delphi 7 никому не нужен). Зарплата была сначала небольшая, но через год запросил уже больше, потому что сам зарабатываю на жизнь (к слову, работаю по 3-4 часа в день). Цифры называть не буду, но зарплата чуть меньше обычных разработчиков, но больше среднестатистической для студента (в час, в сумме, конечно далеко до full-time оклада). Сначала был уверен в том, что на работе будет скукота, и задания будут не интересные. Очень ошибался. В последнее время мне также помогают в развитии моих Delphi-навыков, что я тоже очень ценю. Честно говоря, очень доволен своей работой. Стараюсь для них тоже делать все качественно, как умею.

Ради интереса: готовы ли вы, RegionSoft, дать все перечисленные плюшки студенту, если вдруг придет? :)

Нас мало. Знаю только двоих других дельфистов-студентов в городе. А вот фирм, которые ищут дельфистов, много (попадались вакансии от Motorola и Siemens). Возможно, компаниям, которые имеют дело с Delphi, стоит чаще говорить о том, что они ищут людей, иначе все будут думать, что дельфи уже умер, и никто его не будет учить.

По теме статьи:
Есть одна, очень тяжелая вещь для студента, а именно, понять, что значит «хороший специалист». Грубо говоря, человек оценивает себя по статьям с Хабра, насколько он их понимает. А почему нет? Вот, обучающийся умеет настраивать Jenkins, поднимать контейнер на Docker, писать на PHP, есть парочка достаточно неплохих проектов, знают про Design Patterns, тесты и основы алгоритмов. А что еще? Что дальше? На хабре все понятно, студент старается в своих проектах следовать прочитанному, думает, раз люди такое пишут, значит, я тоже уже готовый разработчик. Я на самом деле видел мало студентов, которые не понимают, что их ждет в разработке, как вы описываете в статье (в пунктах «Работа» и «Отношения»), скорее проблема в том, что студенты не могут адекватно оценить себя. От этого и приходят завышенные требования к технологиям, офису и зарплате. А иногда и не завышенные. Действительно видел студентов, которые приходили и обучали новым подходам и фреймворкам прогеров, которые уже работали в фирме. И фиг теперь фирма таких отпустит, а еще оклад максимально поднимет. И мне кажется, такое происходит, потому что, людям в IT надо часто переобучаться. Вот так, скача с технологии на технологию, с фреймворка на фреймвок, ты и остаешься вечным мидлом, а потом тебя уделывает какой-то студент, просто потому, что у него в универе было время хорошо разобраться в самом новом.

P.S. Ну я и графоман :)
Рабочий ноутбук и последнюю версию Delphi дадим — как иначе? Плюс обучим всему, что непонятно и не бросим «пилить код», а будем работать совместно, анализировать, разбирать, — так строится команда. Что касается полной удалёнки — то нет, это просто невозможно ввиду специфики проекта. Но совмещение с учёбой — пожалуйста, мы через это не раз проходили, все защитились с комфортом.
Какая у вас минимальная ЗП синьора?
А какая медианная ЗП мидла?
Это закрытая информация, обсуждается на собеседовании.
НЛО прилетело и опубликовало эту надпись здесь
Обычно на русский это переводится как «мы хотим платить не только ниже рынка но и ниже вилки».
Если вы заинтересованы заполнить вакансию, то вы должны сообщать уровень оплаты.
Серьезные кампании такого не сделают. Зарплату кандидат узнает отдельно, причем она может различаться между коллегами одного уровня. Квалификация у всех разная, перспективность — тоже.
> она может различаться между коллегами одного уровня
Именно поэтому разглашать какие-либо цифры (средние, вилки, минимальные) на
публичном сайте работодатель не будет. Не требуйте от него невозможного, имейте уважение к акулам бизнеса.
Именно это я и сказал, зачем вы повторяете?
Я с вами согласился :) Мог и не писать, конечно.
НЛО прилетело и опубликовало эту надпись здесь
Серьезные компании говорят вилку.
Исключение монстры индустрии, вроде гугла, майкрософта и т.д.
Нет ли здесь противоречия? Ну и исключение составляют не только монстры индустрии — я вот, например, не знаю в Москве вообще ни одной компании с более, чем 100 разработчиками, которая указывала бы вилку зарплат.
Так что как раз серьезные компании вилку зарплат не указывают. Как бы грустно и неудобно для нас как для соискателей и разработчиков это ни было.
зачем мне тратить свое время на собеседования в компании например если они не могу предложить больше суммы n, в то время как меня устроит только сумма 3*n
А вот это как раз всегда можно спросить при первом контакте рекрутера.
Могу рассказать про нашего джуна.
Я собеседовала девочку около года назад. Из опыта — это пара сверстанных страничек и самый минимум css, js — 0. В принципе нам требовался человек, что бы разгрузить меня, мы не ждали ни чего выдающегося.
Решили: «Что бы не попробовать, за месяц станет видно, ни она, ни мы ни чего не теряем».
О зп она договаривалась с эйчаром, в итоге 20косарей, работала по договору. Я давала самые легкие задачи, которые у меня заняли бы минут 15, но джуну требовалось час, полтора. Вполне ожидаемые показатели, первая работа, стресс, отсутствие опыта, не знакомый проект. По итогам я осталась довольна. Взяли по трудовой, с зарплатой в 30-ку. После окончания официального испытательного 45. После десяти месяцев — 55. Думаю к концу года 60.
Я с ней разговаривала об желаемой зарплате, повышения соответствовали ее ожиданиям на данный период.
Знания и уровень верстки ощутимо улучшились, а вот по js-у не такие впечатляющие достижения.

по первой части не согласен со всем:


  • Деньги — я ищу работу. Первое на что я смотрю деньги. Про повышения мы не узнаем пока оно не наступит. Знаю несколько "солидных" компаний, которые живут только на "дешевых студентах", которые боятся уйти. По моим наблюдениям з/п для одного и того же человека в разных компаниях может разниться в 2 раза.
  • Офис — я ищу работу. Я понимаю что я буду туда ходить и находится там солидное количество времени. Если будет выбор между двумя компаниями, но у одной из них столик для тенниса — я пойду в неё. Как минимум, потому что игровые на работе создают (хотя бы) иллюзию непринужденности.
  • Работа — писать юнит тесты не любит никто. Процитирую одного человека: "У вас спросят на собеседовании: "любите ли вы писать юнит-тесты", и вы скажете "Конечно люблю" и тут мы улыбнёмся и поймём друг-друга, о том что вы врете. Юнит тесты не любит писать никто."
    Не знаю кем бы я был, если бы на первой работе мне бы дали код и сказали "тестируй". Лучший старт:
    1. Тебе дают код
    2. Ты делаешь
    3. Комитишь
    4. Ревью тайм
    5. Пишут двадцать-тридцать пунктов, что нужно исправить
    6. Митинг, на котором тебе говорят, почему это важно
  • Отношения
    Тим билдинг это здорово. Нужно позволить разработчикам общаться друг с другом как им удобно. Активные разработчики, которые пытаются влиться в коллектив лучше, тех которые просто приходят молча на работу и молча смотрят в монитор. (имхо)
    Как минимум потому что они будут знать кто чем занимается, и у кого можно будет спросить помощи с такой-то проблемой.

Я люблю писать юнит-тесты, соответственно, утверждение неверно.


Не, не то, чтобы мне очень нравился сам процесс их написания, но разработка без тестов — это еще хуже.

Не, не то, чтобы мне очень нравился сам процесс их написания, но разработка без тестов — это еще хуже.
Сам хотел так ответить :-)
разработка без тестов — это еще хуже

С этим никто не спорит. Я говорю что заставлять новичков писать юнит тесты это плохо. Цитата из статьи:


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

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


Мне кажется тут лучше всего подойдёт аналогия с кузнецами "Мастер — подмастерье":
Правильный подход(имхо): Подмастерье смотрит на работу мастера, делает что-то сам. Получается криво. Мастер говорит почему.
Подход из статьи: Мастер говорит подмастерье: "убирай за мной кузницу и полируй продукт". Подмастерье убирает и полирует.
С одной стороны, да он увидит как выглядит правильный продукт, полируя его и какой инструмент для чего используется. Но почему так, ему придётся догадываться самому.

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

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

В каждой компании по своему. На прошлой работе была игровая с теннисом и настольныv футболом. Все играли никто не жаловался.
На новой тоже самое + х-бокс, лаундж зоны и "книжные углы".
Опять же никто не жалуется.


По поводу "лишали привозной воды" советую почитать Трудовой кодекс РФ. Это просто незаконно (пункт о том что работодатель обязан обеспечить питьевой водой).
Ну и, пожалуй, бежать от такого работодателя куда глаза глядят.

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

Офис. Опять же, на Хабре можно насмотреться на прекрасные офисы Google, Avito, Badoo…
Пля, купите хотя бы кресла нормальные, чтобы хотя бы спину облакотить можно было и не свалиться, а не долбанные табуретки трудовика дяди Вовы за 40 рублей штука из ближайшего пту. Сидишь скрюченный весь, поясница болит. О какой продуктивной работе может идти речь? Конечно люди будут присматривать конторы где офисы лучше.

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

И нет, это не перегрузка ребёнка — во-первых, дети в школе закончились, а во-вторых, он/она один фиг дома за компьютер сядет. Так лучше с пользой, на работе и за деньги (за обучение).
Да, мечтаааа работодателя, чтобы сотрудник работал сверхурочно за бесплатно 24*7. Нафиг людей нанимать, когда можно заставить рабов работать до ночи за бесплатно а на сэкономленные деньги слетать на Карибы и копить ещё один мерс. На каждом втором собеседовании вопросы про сверхурочку, хобби и семью — чтобы их не было, ноулайферам в айти дорога…
«Наша система имеет мало общего с новомодными CRM-ками, так как рассчитана на уважающий себя бизнес, желающий жить на рынке долго и счастливо, а не два месяца» — забористый пассаж. Не поленился глянуть Gartner CRM magic quadrant — кто же делает CRM-ки для не уважающего себя бизнеса на 2 месяца? Salesforse, Microsoft, Oracle и прочие SAPы
Не передёргивайте. Мы не претендуем на рейтинги, да и не до них нам — там же процедуры подачи кандидатур, определённые формальные требования и т.д. Это же только накрутку к стоимости лицензий даст.

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

А знаете, на мой сторонний взгляд, ваша компания ведет себя примерно так же — «любите нас, мы работодатели». Мы мол им и обучение бесплатное предлагаем, и даже компьютер рабочий бесплатно дать готовы, а они еще и денег требуют. На мой же взгляд, очень странно попрекать работника тем, что вам нужно потратить деньги на обеспечение его рабочим инструментом, мне почему-то кажется, что если бы работодатель озвучил какому-нибудь токарю на заводе, что-то вроде: «Знаешь, твой станок обошелся мне в 200 000 рублей, поэтому тебе придется какое-то время поработать за еду», — он услышал бы о себе много матерных слов. Нет, есть конечно компании, которые продают свой товар своим «работникам», а потом предлагают бесплатно обучить их продавать его кому-то еще (MLM), но и отношение к ним соответствующее. Опять же, нахожу слегка странным желания бизнеса иметь готового спеца по выходу из вуза — фреймворкам, языкам, СУБД и прочей специфики в ИТ несть числа, и как вуз может угодить всем, особенно с учетом того, что модный вчера, легко может стать не модным завтра? Обратитесь в вуз, возьмите студентов на практику, а потом предложите работу. Да, тоже затраты денег и сил на организацию, но меня в школе учили, что бизнесмен ездит на дорогой машине, не потому что эксплуататор, а потому, что он берет на себя риски, а если риски не берет, то что же это тогда получается… :)
Ну и намешали вы в комментарии — винегрет просто! А мы разве кого-то попрекаем и эксплуатируем? В статье просто перечислены первичные затраты, никто их в жизни никому не озвучивает. И учёбой, и внутренним обучением никто никого не попрекает.
, никто их в жизни никому не озвучивает.

И тем не менее, в статье вы их озвучили, причём в подзаголовке, общую мысль которого можно выразить как «выпускники много просят». Я пытался вам донести, что использовать эти затраты как аргумент к уровню оплаты труда – как минимум странно, чтобы понять насколько, представьте, что нанимаете токаря, и озвучиваете ему ваш мысленный довод. А чтобы понять почему, достаточно помнить, что вы на дарите работнику рабочую машину и стол, и даже если работник вам не подошёл, то новый (вам же все равно его искать, если работники нужны) этих затрат уже не потребует.

И попрекнули, кстати — иначе как пассаж расценивать "Просто потому что пока ты — источник затрат: стол, компьютер, софт, IDE, обучение, еда-вода, Интернет и т.д. И пока ты эти затраты не окупаешь."
Как это расценивать иначе как: "Ай-ай-ай — ты ещё ничего не сделал, а мы за тебя уже заплатили"?

НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

Какой-то вы особый смысл в слово "попрекнули" вкладываете… Поясню свою точку зрения.
Студент приходит на собеседование и говорит, что хочет зарплату в 1000 Долларов на руки, на что ему говорят — "Ээээ, дарахой, ваапще-то мы тут тебе стол, стул, компьютер и IDE купили....".
С позиции любого потенциального работника (не только студента) — это выглядит как завуалированный упрёк при всём при том, что с точки зрения закона он ещё даже работать не начал, а ему уже ставят в вину то, что на него уже потратились буде он таки решится там работать и этим упрёком его прессуют с целью снизить его собственную цену.
Это крайне ущербная практика с позиции мотивации потенциального сотрудника. Зачем человеку работать в компании, в которой ему с самого начала начинают прививать чувство вины за то, что он там работает? Мало того на основе этого упрёка следуют обвинения в неадекватности (запросов) и предлагают ставить его финансовое положение в зависимость от настроения левой пятки неизвестного дядьки? Нет, есть люди, которым нравятся унижения и чувство вины, но я бы не назвал нормальным среднестатическим поведением профессионала и потенциального специалиста.
Спикер сводит до абсурда ситуацию со студентом "Любите меня таким", почему мне нельзя свести ситуацию до крайне негативного экстремума для работодателя — мне решительно непонятно. Сравнение максимально позитивной/негативной для работодателя/наёмного рабочего ситуаций есть задача, позволяющая вычислить некий баланс, к которому нужно стремиться.

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

А баланс должны только бизнесмены искать по вашему? А весь такой супер-пупер студент может не задумываться ни о чем, пусть его любят какой он есть?
Сотрудника, трудности бизнеса не волнуют, вернее если у бизнеса трудности, значит не стоит идти в эту фирму.
Риск, это дело исключительно бизнеса, сотруднику за риск не платят и не штрафуют.
Так что задумываться об общих проблемах бизнеса сотруднику не стоит. Стоит задумываться только что входит в его оплачиваемые обязанности и доход.

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

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

Но это не значит, что это будет озвучиваться человеку в реальности, понимаете?
Если это не озвучено, то есть нет договора/договоренности, то для взаимодействующих сторон этого вообще нет, остальное — это, всего лишь, безосновательные хотелки другой стороны.
Не совсем по теме, но напомнило:
Самый простой способ задрючить джуниора - спросить о внутреннем устройстве стандартной библиотеки, о деталях реализации виртуальной машины. Ну и конечно алгоритмы, тервер, дискретка, и прочий матан. Указанные компоненты можно смешивать в любых сочетаниях для достижения нужного уровня зубодробильности. Чел хочет заплату 80, а у тебя есть только 60? Нет ничего проще, спроси его почему реализация списков в стандартной библиотеке неправильная и как надо реализовать правильно, или дай какую-нибудь задачку, которую на прошлой неделе еле-еле решил самый умный в конторе кодер, а потом жди пока зарплата не опустится до запланированных 60 -)
В том числе для защиты от таких «умных» работодателей стоит иметь на руках хотя бы два оффера. Ну не согласится джун на 60, если в другом таком же месте уже предложили 80, как ты его ни опускай.
Честно говоря, не вижу проблемы в том, чтобы два оффера получить. Один же откуда-то взялся, почему бы и второй таким же образом не получить?
Лично у меня ситуация, когда я собеседовался лишь в одной компании, была лишь однажды, и я в тот момент четко понимал, что готов работать у них за любые деньги.
Я вижу проблему во взаимоисключающих параграфах в виде
«каждый джун с двумя офферами»
«по 10-20 кандидатов на вакансию джуна на рынке»
А я не вижу. Рынок высоколиквиден.
Из того, что продавцов помидоров в 10-20 раз больше, чем покупателей, никак не следует, что покупатель не может часть помидоров купить в одной палатке, а часть — в соседней.
Кхм, меньше, конечно же. Опечатка.

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

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

Если вакансия не закрыта уже полтора года, а работу работать надо — да, предлагать. Обучать, материться, если не подходит, и давать блага, чтобы не ушёл после всех "затрат", коими работодатель изначально попрекает.
Как вы думаете — зачем вообще нужен диплом? Ведь все те науки, что даются в ВУЗе — можно и на дому изучать. Программа — известна и в общем доступе. Репетиторов нанять и устроить себе индивидуальный курс — по месяцу на предмет — за полтора года пройдёте. Т.к. курс индивидуальный понятные вещи пробежите быстро, сложные — пробежите медленнее и понятнее (для вас). Ну так зачем ВУЗ? Если есть 2 кандидата: один без "бумажки", а второй — с "бумажкой"… Кому работодатель отдаст предпочтение?
Почему-то работодатели обычно требуют — второго… "Подтверждённого" специалиста. А подтверждённый специалист тратил своё время и деньги — "на бумажку", а значит его запросы будут априори ВЫШЕ, чем Васи Пупкина, который прошёл экспресс курс по программированию от Pluralsight. Да, работодатели "не довольны", ну так, ребята, вы сами сидели в носу ковыряли и думали, что вот вы вакансию открыли по статистически (хрен знает откуда взятой) средней цене и к вам сразу ломанулись толпами?
Как говорил один известный американский актёр, играя русского миллиционера в США: "капЫталЫзм"

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

Наброшу, как человек с зашкаливающим ЧСВ.


Сразу после выпуска с универа по специальности физика, то есть имея 0 лет стажа, начал искать работу в Data Science. Вакансии с окладом меньше $10,000 грязными в месяц я не рассматривал, ибо не смешно.


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


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


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


Через 8 месяцев я поменял работу, во-первых, потому что работать на галерах — это не мое, а во-вторых, потому что выяснилось, что $10,000 грязными в месяц — это сильно ниже рынка для моего набора навыков. Не последнюю роль сыграло то, что контора использовала MatLab, что среди Data Science в 99% случаев будет рассматриваться, как устаревшая технология, а очень хотелось качать скилы в чем-то более модном, молодежном, эффективном и востребованном.


Но в целом, этот комментарий, конечно, наброс, потому что у меня дело происходило в Кремниевой долине, а тут своя специфика.

В калифорнии 120к грязными в год — это вроде зарплата миддла.

Так и есть. Но вот мои одногруппники, которые привыкли жить на $25k в год в аспирантуре считали за счастье, когда им предлагали $40-60, или же были эпизоды, когда они озвучивали $100k, а работодатель им в ответ: "Ну у тебя же опыта работы нет, поэтому мы тебе будем платить вот столько-то, зато дадим laptop и ты у нас многому научишься и вообще наша контора не такая как все" и они на это покупались.


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

Всё же я думаю, у вас немного другое. Вы data scientist, здесь важен не столько опыт, сколько знания, можно, например, взять человека без опыта и он будет прекрасно справляться, выучить новый тул дело не особо чтобы долгое для этого уровня. Ни в US, ни в Европе обычного программера из университета тоже в нормальную компанию не возьмут кроме как graduate. Ну в принципе зарплата-то не особо чтобы наглая для этого уровня (если не брать отсутствие опыта), не удивляюсь что вы работу с таким запросом и скиллами нашли.
НЛО прилетело и опубликовало эту надпись здесь
Бишопе/Гудфеллоу/Воронцове
Кто все эти люди можно ссылки/книги?
А лучше список чего почитать/посмотреть, на чем можно «далеко уехать».
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Что значит
$10,000 грязными в месяц
?
НЛО прилетело и опубликовало эту надпись здесь
Да, да и есть целая профессия — спец-ы по заполнению налоговых деклараций
Сейчас и в СНГ решили её «внедрить»: принимают законы об ответственности такий спе-ов
А, это имелось ввиду, про отличие налоговой системы знаю, но обычно так и говорят «до налогов». Спасибо.
Грязными — общеупотребительный термин в СНГ.
Ни разу не слышал.
А откуда вы?
Иногда требования к кандидату до смешного до ходят, в плате теории и тестов. Вот я в свое время по 10 собеседований на неделе обходил, и старался все-таки узнать результаты и причины, по которым я им не подошел. Так вот, так бывает, что один и тот же достаточно простой вопрос, оказывается, имеет абсолютно противоположные правильные ответы. А иногда перефразировка или пересказ термина своими словами считается не верным. И уж самое странное это когда вопрос стоит про уровни протоколов сопровождающие данные в сетевом пакете, а в ответ как правильно слышишь рассказ о физической передаче сигналов между сетевыми картами.

Но то, что как мне показалось, в статье отсутствует, так это обратная ситуация — когда студентами вдруг оказываются те, кто вас принимает на работу или является вашим будущим начальником. И таких новоиспеченных организаций, с неправильно трактованной теорией с форума, сейчас очень много.
Я хочу сказать студентам, ребята, начинайте «пилить» свой проект уже сегодня.
Для себя или других, на любимых вам и современных (по вашему мнению) технологиях.
Вы познаете себя и познаете других.
Если вы в дальнейшем придете трудоустраиваться и покажете какой-никакой продукт, на вас будут смотреть по другому.
Это говорит о целеустремленности, самозаинтересованности, трудолюбии, и амбициях в хорошем понимании этого слова.
Ты не «пустышка», пусть это будет очередной тетрис.
Начинал с DELPHI1 в 1999 сейчас XE7. В промежутке — Embedded Linux, WINCE Предпоследнее место работы — филиал крупной международной компании, 4.5 года, XE2-XE7. До сих пор есть проекты писанные на D3-D5, приходилось поддерживать и их. Примерно полтора года обратно решили свернуть это направление, пришлось заняться бэкэндом С++ и питоном. Сейчас с нуля JAVA и Android. Смешно но платят больше чем за DELPHI… ИМХО переход с него на любой другой язык (среду) визуального программирования (не веб) достаточно легок…
> Начинал с DELPHI1 в 1999
По-моему, на первом никто толком не писал, т.к. он был новым, глючным и 16 разрядным. Все начинали с D2.
В 99-м вышел Delphi 5, к тому времени D3 уже пару лет как был. В 99-м на D3 у нас был проект на полмиллиона строк в паскале и 200 кстрок Transact-SQL.
Тоже спрыгнул с этого паровоза на Java, правда мне хватило всего 5 лет комерческой разработки на Delphi и то считаю, что «пересидел». Java джуниором стал получасть сразу больше, чем было Delphi сеньором. А это было только начало…

Региональная (челябинская) ЗП моих знакомых delphi программистов так и осталась на уровне 1000$, она была такой в 2006, потом 2011 и сейчас такая. Я называю это проклятье «тыщщидолларов» и думаю что причины две:

  1. Отсутствие конкуренции. Ты delphi программист и никуда от нас не денешься, потому что на миллионный город нет вакансий лучше. И люди сидят по 10-15 лет как у топикстартера
  2. Заточенность большинства delphi проектов на СНГ рынок, который абсолютно не эластичен к изменению курса валют
Вы делаете Delphi хорошую рекламу. Если смотреть со стороны бизнеса. Ведь бизнесу выгоднее держать дешевых программистов, чем дорогих. Относительная дороговизна инструмента окупается многократно дешевыми специалистами + скоростью разработки.
Всегда есть две стороны, помним об этом.
НЛО прилетело и опубликовало эту надпись здесь
Для продуктового. Для аутсорса, конечно, выгоднее покупать подороже и продавать подороже. Меньше головной боли (меньше людей), а выхлоп такой же. Цена с качеством коррелирует до какой-то степени. Но уж точно не с коэффициентом = 1. Можно найти хорошие варианты, не все любят на аутсорсе сидеть, даже зарплата выше. По своему опыту наёма.
не все любят на аутсорсе сидеть, даже зарплата выше

читать: не все любят на аутсорсе сидеть, даже если зарплата выше
НЛО прилетело и опубликовало эту надпись здесь
И люди сидят по 10-15 лет как у топикстартера

Будто это плохо.
Не все хотят скакать по модным проектам каждые год-два.
Это может как плохо так и не очень, все зависит от первопричин. Ты сидишь 15 лет в одной конторе потому что у тебя очень узкоспециализированные знания, тебя «растили под себя» и больше ты никому не нужен. Либо твоя работа такая интересная, каждая задача — новый вызов, регулярное развитие.

Я даже не знаю в случае Delphi + CRM, что может быть из этих двух.
Возможен и вариант, когда совмещаются оба пункта.
Например, я пишу на Delphi в одном месте уже 8 лет. Мне сложно будет просто так, с кондачка перейти на другой язык, придется пару месяцев потренироваться, что-то пописать, освежить память, посмотреть последние стандарты и best practices. Но и текущая работа очень интересная. Вот сейчас к старому backendу еще тянущему родословную со времен MS-DOS прикручиваем JS морду. Интересных задач — полно и в be и во fe. Считать ли это развитием? Не знаю, но интересно же.
Считать ли это развитием? Не знаю
Денег, в пересчете на usd, всё больше и больше платят? Да — развитие, нет — нет.
А, вы в этом плане…
Да, таки платят.
Как будто в Делфи нет развития :) Да мы за всем еле поспеваем: порт на Линукс, работа с облаками, веб, дестопный + мобильный, сейчас порт на УниГуй. Мобильные навороты, правда, не используем, но кому-то они явно полезны. В Делфи собран большой массив технологий и новые 'растут' как грибы после дождя (вспоминая купленную Сенчу). За развитием с трудом успеваем, а вы говорите :)
Делфи — это только инструмент. С таким же успехом можно говорить, что и на сишарпе и на жаве и на PHP 'узкоспециализированные знания'. Чем они лучше?
Ничего против delphi не имею, у самого 5+ лет рабочего опыта там плюс любовь со школы )

Но я говорю об объективных минусах, например, отсутствие конкуренции между работодателями и вследствие меньшей средней ЗП. Например, компания закрывается, в городе 1-2 Delphi вакансии 10-15 Java/JS у каких девелоперов ситуация устойчивей? Да Delphi просто инструмент, но с ним сложно быть гибким при смене работы или повышений ЗП, потому что могут «перекупить»
Чем они лучше?

Тем, что на них вакансий в мире на порядки больше, чем на Delphi и его потомках. Что на это скажете?
Нормальный программист должен иметь гибкий ум, а не способность работать на каком-то одном языке. Я уже кидал графики и повторюсь:
www.tiobe.com/tiobe-index/csharp
Помрёт ваш любимый язык, и окажется, что больше вы делать ничего нигде не способны. Что будете делать? В дворники? Или на кассу в гипер?
Delphi… у нас весь софт лдя ПК на нём написан, а я ОТК пишу на С++, ой как в своих программах доставляет их ДЛЛки использовать.
Любой (вру, не любой, — адекватный) бизнес поднимет зарплату хорошему сотруднику, и не раз.

Свежо придание…
А расскажите, как изменилась зарплата ваших мидлов с 2007 года в среднем? Сколько она была в 2007 и сколько сейчас?
Это закрытая информация. Но они довольны :-)
Федеральный Закон 98 Статья 5 Пункт 5.
Так что нет, это не закрытая информация. А еще её можно получить, сделав соответствующий запрос в налоговую. Правда, что будет в выписке вполне очевидное — несоответствие придания реальности.

Может, они в конвертике бОльшую часть платят :-)

Из личного опыта.
Я и ещё один мой однокурсник работали на одной фирме:
— Он пришёл на фирму ещё при прохождении практики в универе и прошёл весь путь с низов
— Я после университета проработал в другой фирме полтора года и перешёл в эту. Причина перехода кстати была та же — нежелание повышать зарплату джуниору.
Так вот в результате моя зарплата была больше, чем у моего однокурсника на 20% и эта разница сохранилась и через 5 лет работы в компании.

Так что про желание повышать зарплаты соразмерно вкладу и опыту — это сказки. Любой кто приходит в компанию на такую же должность будет получать больше, чем тот, кто в компании работает 5 лет. Просто потому что при найме компания готова переплатить чуть за хорошего сотрудника с опытом, а тому, кто работает в компании давно, достаточно кинуть косточку в размере инфляции ±1-2% раз в год.
Да вот и я о том же.
Большинство работодателей любят рассказывать, что они регулярно и честно повышают зарплаты. Но по факту именно что «косточку кидают».
Прямо заинтриговали, может хотя бы приведете приблизительный ценовой диапазон?
Уверен, что в долларовом эквиваленте практически никак )
А я вот удивлюсь, если окажется что она хотя бы сохранилась на прежнем уровне.
Ибо работодатели до сих пор не особо горят желанием поднимать уровень зарплат до докризисного уровня.
Все с кем довелось эту тему обсудить, у кого с тех пор выросли зарплаты добились этого за счет карьерного роста/смены места работы, но никак не внутри одной компании на той же должности.
Поэтому и не верю в скази про любого/адекватного. Единицы так делают.
В delphi случае вполне может быть и уменьшилась, бизнес хорошо повышает ЗП не «хорошему сотруднику» (взрослые, а в сказки верят), а тому кто может уйти в другую компанию с похожим технологическим стеком и прибавкой к ЗП. В мире Delphi дефицит работодателей. Значит основная мотивация повышать отсутствует
В мире Delphi дефицит работодателей. Значит основная мотивация повышать отсутствует

Угу. Попробуй найди работника на Delphi вакансию… У нас берут со знанием любых языков и переучивают.
Это как с COBOLом, вначале язык уступает свои позиции другим ЯП, которым в следствие чего будущие программисты отдают предпочтение. А потом начинается голод программистов на коболе. Но о популярности языка это не говорит ничего )
Одно другому не мешает. Рынок не ликвиден.
Где же вы были 4 года назад, когда я искал работу разработчиком Delphi (сам живу в Нижнем, в Центре Сормово)?
Работал я тогда на должности инженер — эколог, у очень крупного ритейлера, и взбрело мне в голову, что смогу я быть программистом.
Будучи экологов мне приходилось обрабатывать огромные массивы данных практически вручную, только Excel и выручал. И в какой то момент мне пришла в голову мысль, что весь этот процесс можно автоматизировать. И взялся я за углублённым изучение Basic, благо основы программирования в институте были. Через примерно пол года было готова 0.0.1 версия моей программы. После полного цикла тестирования программа была внедрена, в ней работали около 60 экологов на филиалах. Позднее потребовалась переработка программы, т. к. в качестве хранения данных я использовал один xml файл в связке с msxml, что работало крайне медленно с «потолстевшим» xml-ником.
Программа была переписала на Delphi, с БД firebird в качестве хранения данных.
В результате, четыре года назад я был специалистом с опытом разработки и внедрения собственного, востребованного приложения, и который умел работать с:
— БД firebird, т. е. с SQL пришлось познакомиться;
— xml, отчёты в контролирующие органы формировались в xml;
— потоками, выгрузка отчётов для печати осуществлялась в отдельных потоках.
И чем закончились мои поиски работы программистом Delphi…
Собеседованием по Skype (даже тестового задания не было), опыта работы программистом, который бы был подтверждаем документально, у меня не было, и собеседующий мне сказал, что учить им некогда. Хотя вакансия висит и по сей день…
В настоящее время работаю программистом на 1С, технология мне очень не нравится, но платят относительно неплохо.
Всё это я написал к тому, что быть/стать программистом не сложно если ты нужного склада ума. Мне кажется не нужно пытаться найти студента, которого можно сразу бросить в бой, а нужно найти человека, который может сделать простейшие вещи и научить тому, что нужно вам, как говорил мой бывший руководитель: «найти подходящий мозг и вылепить из него, то что нужно». Кроме того, обычно устанавливается испытательный срок и за 3 месяца по человеку уже все понятно…
Вот и результат. Приходится работать на нелюбимой работе с ужасным инструментом (не моя оценка, если что).
И чем закончились мои поиски работы программистом Delphi…

Свой продукт делайте. Если Делфи Про дорого — можно начать со Стартера + Лазаря.
Статья в целом правильная, но есть пара мест, которые меня задели.
Во-первых фраза «Наша система имеет мало общего с новомодными CRM-ками, так как рассчитана на уважающий себя бизнес, желающий жить на рынке долго и счастливо, а не два месяца» меня, как опытного разработчика, сразу напрягла. По таким фразам можно практически безошибочно находить компании, в которых все сотрудники «кому за 30-40» и кто пишет на устаревших технологиях, выдавая это за фишку и за коммерческое преимущество. И это всего-лишь вопрос времени когда такая компания загнётся, если не захочет измениться и, в какой-то мере, начать всё сначала. Сейчас 90% клиентов приходят и хотят веб-приложение и чтобы неприменно в облаке…

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

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

По поводу молодёжи — рынок довольно жесток. Если такие новички приходят и просят заоблачные деньги, то либо они так и останутся без работы, либо их кто-то купит за такие деньги. Если к вам пришёл хороший кандидат, но с завышенной самооценкой, то просто скажите ему как есть: вы нам понравились и мы вам можем предложить зарплату в размере Х. Жаль что вас не устраивает… Если в течении 2х месяцев передумаете — то милости просим… Т.е. дайте человеку чуть времени на осознание того, что ваше предложение — достойный вариант и что лучшего он не найдёт…
Да прямо здесь целая дискуссия Ж-) Почитайте Ж-)
Делфи хоронят, на моей памяти, столько, сколько он существует :) А он до сих пор здравствует и активно развивается.

Только вакансий по нему в моём родном городе меньше десятка (а когда-то был свыше десятка).

Свои создайте. Как вон, компания, пост написавшая.
Да я бы не сказал, что активно, вакансий по миру на том же C# в разы больше.
Я про активное развитие, если что. Не всех вакансии интересуют.
Вакансии — это показатель того, насколько технология популярна и нужна бизнесу.
Сейчас важнее хайп + насколько инструмент раскручен. Качества, увы, отходят на второй план.
С каких пор job security уходит на второй план? Только если работник — прирожденный холуй.
Увы, но смысл вашего ответа для меня остался загадкой.
Студенты жалуются, что их плохо учат; преподаватели жалуются, что им мало платят и нельзя отчислить всех двоечников; работодатели жалуются, что преподаватели дают «for any nondeterministic turing machine...» вместо «как запилить очередную CRM-ку» и выпускники не хотят делать их скучные однотипные интересные задачи за еду или мифическое «обучение». Ждём очередных откровений.
В третий раз переписываю коментарий, чтобы он не выглядел как нытье и горение.
На мой взгляд, вся проблема в высшем образовании (это касается не только ИТ). Из университета должен выходить готовый специалист. Сейчас этого не происходит. Частично причины этого описаны в статье.
Не нужно мне рассказывать, что студент должен параллельно учебе заниматься самообразованием, пилить пет-проекты и работать стажером за спасибо. Зачем тогда в этой схеме вообще нужен университет? 5-6 лет жизни только ради корочек?
В итоге имеем завышенные ожидания студентов, которые уверены, что после получения диплома о высшем образовании, их должны брать в любую компанию. Завышенные ожидания работодателя, который ожидает, что человек 6 лет учившийся на программиста должен уметь программировать на хорошем уровне (что вообще-то правильно). И абсолютное не соответствие этим ожиданиям самих университетов.
Если человек сам хочет научится — то ему и универ, может так статься, не нужен. А если не хочет — то и универ не поможет, что совершенно точно.
У нас в команде фронт веба пишет человек без высшего образования. Что, впрочем, не мешает делать замечательные вещи, за которые платят.
Университеты никогда не смогут подготовить специалиста до такого уровня, чтобы он мог сразу после выпуска прийти и начать работать самостоятельно. Потому что у каждого предприятия своя специфика и свои внутренние правила и процессы. А в ИТ это ещё сложнее, из-за огромного выбора технологий и фреймворков. Поэтому если компания ноет, что нет достойных кандидатов, то проблема, не в университетах, а в этой компании… Возьмите новичка, заключите с ним договор, что он обязуется отработать в компании не меньше 2х лет, а иначе он должен выплатить стоимость обучения. После чего тратите пол-года на его обучение, но в результате имеете специалиста который работает именно так, как вам нужно и знает все процессы вашей компании… Договор защитит вас от того, что человек сразу после обучения от вас убежит…
НЛО прилетело и опубликовало эту надпись здесь
Давно ищу работу программистом, однако сталкиваюсь с проблемой, это сверхнизкая зарплата, которой не хватит даже на съём жилья. Если бы можно было позволить себе не платить за проживание можно было бы начать практические занятия. Удалённой работы так и не нашёл. Из готовых проектов реализовал почтовый сервер рассылки емаил на Qt5 C++. Тест на джуниор разработчика не прошёл. Готов поработать за небольшую плату но только удалённо, есть варианты?
На плюсах мало удаленных вакансий, гораздо проще искать onsite. Да и шансов чему-то научиться у коллег (а для начинающего это важнее всего, потому что это будущие деньги) на удаленке очень мало. Так что я бы порекомендовал все же посмотреть на локальные вакансии или рассмотреть вариант переезда (ибо не знаю, откуда вы). Тот же Яндекс несколько лет назад брал на стажировку всех подряд, оплачивал общежитие и платил очень и очень неплохие деньги.
Снять комнату в Москве 20к, в Подмосковье 15к. Джуном можно устроиться на 30к, за полгода-год вырасти до 60к+.

Отличная мозговправляющая статья. Спасибо!

Автор, у вас полный трэш начиная с того, что у вас директор — главный разработчик. Если бы он был нормальным директором, он бы вам объяснил, что зарплаты берутся не от "умения и опыта", а от рыночного спроса.


Не говоря уже о том, что вы пишете на Дельфи в 2017-ом году.

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

Ну, если прибыль — единственное, что важно, то есть более прибыльные сферы. Обычно важен ещё и интерес к процессу.

И соглашусь и нет. Согласен с Вашими доводами, но в тоже время если разработчикам интересно именно в этом ключе работать, то почему бы и нет? Просто не нужно следовать моде, а делать то что нравится и\или получается, но и не забывать о развитии -=) Я вот лично для себя поставил цель перейти с WEB на обычные языки программирования, типа Java, C++ и так далее. Хоть это мне и не нужно на практике, но надо куда-то развиваться.
НЛО прилетело и опубликовало эту надпись здесь
Ни один язык никогда не вызывает столько споров, сколько Delphi :)
НЛО прилетело и опубликовало эту надпись здесь
Может быть. Но если где-то упоминается Delphi, вместе с другими языками или без — очередной холивар по поводу его смерти почти гарантирован.
НЛО прилетело и опубликовало эту надпись здесь
А никак. У него нет ни славы умирающего, ни славы языка для школьников, которые только кнопки по форме раскидывать умеют и так далее.
НЛО прилетело и опубликовало эту надпись здесь
Вот я, совладелец компании и главный разработчик. Что совершенно не мешает, а очень помогает. Тоже Делфи, 15 лет, весьма успешные проекты. Как говорится — грех жаловаться. Прибыль приносит. Back плюс, скоро, front (УниГуй) веба — на Делфи же.
Вы на вакансии компаний посмотрите, которые они закрыть годами не могут, оцените рынок труда — современная экономика требует гигантское количество кадров, но хотя бы с минимальной квалификацией и пониманием того, как учиться работать в бизнесе.

Прям в точку. Прям крик души…

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

Если вам нужны «звезды», то не странно ли искать их среди джунов?
Нет, это не будет в ущерб учёбе: всегда можно найти компанию, с которой договориться о работе на полдня или с плавающим графиком

Реальность, на мой взгляд выглядит несколько иначе:
1. Компаниям не нужны такие «на полдня» и с «плавающим графиком». Тут есть противоречие с желанием компаний чтобы сотрудник пришел и решал бизнес-задачи. Это нормальное желание бизнеса. Тех кто берет стажеров и учит и воспитывает, несравненно мало. Это могут позволить себе не все компании. Потому что это время (как известно — деньги). И сами деньги. То есть деньги вдвойне. Почему-то, предполагаю, что подавляющее большинство компаний с периферии не могут себе это позволить в принципе.
2. Реальность (возможно только в которой нахожусь я), говорит о том, что компании редко повышают компенсацию. Опять же не скажу за Москву, но, на мой взгляд, тут перекос снова в сторону регионов. Все по тем же причинам из п.1.
3. Реальность (по моим наблюдениям), такова, что, несколько нелепо выглядят жалобы работодателя на запросы разработчиков, и размеры компенсации, в условиях, когда компании «экономят» на сотрудниках. Сейчас поясню про какую экономию. Нелепо потому, что, давайте признаем факт, что достаточно компаний на рынке, которые платят не «белую» зарплату. Потому что вы знаете почему. Налоги, отчисления, в итоге «белая» зарплата разработчика скажем в 100 тысяч, «обходится» работодателю во все реальные 150 тысяч и возможно более. Так вот я хочу, только в данном аспекте, некой моральной хотя бы справедливости. Давайте говорить о завышенных требованиях разработчиков, и о желаемых ими требованиях компенсации, когда все компании перестанут ухищряться «экономить». И снова перекос между периферией и центром. Я работаю в условиях той реальности, что в регионы приходят компании из центра, с бо'льшими деньгами, и нанимают не по «центральным» зарплатам разработчиков, да еще и пытаются посадить на «две» зарплаты. Или другие варианты как оформление ИП и т.д.
4. Позитивный момент в том, что вариантов как для компаний так и для разработчиков довольно много, предложений и вариантов масса и на любой вкус и размер компенсации. И тогда, снова нелепо, выглядят жалобы бизнеса на «отсутствие» вариантов на рынке.
5. Реальность в которой живу я, такова что мир вообще не справедлив. И все эти разговоры всегда как качели — то в одну, то в другую сторону. Пример: в моей реальности, я хочу писать на Clojure, и ни одна компания, пока, не готова меня взять, просто потому, что на первый же вопрос о коммерческом опыте разработки на Clojure, получают отрицательный ответ, разворачиваются и уходят в интернет искать дальше Clojure ниндзя. Снова нелепо выглядят жалобы на отсутствие моего желания как разработчика и отсутствие предложений. Я, в свою очередь, понимая отсутствие оного опыта, существенно готов ущемить себя в размере финансовой компенсации. Прямо заявляю об этом. Но почему-то часть компаний это не интересует, а иногда, по моим наблюдениям, даже пугает. Но реальность такова, что это не значит, что я в тупике и выхода нет и все пропало. Он есть. И тот самый рынок, дает такие варианты.
Подводя итог: перекос всегда есть и будет. Не хочется сыпать прописными истинами, вроде той, которую только что «ляпнул», и подобными: «недовольные есть всегда и везде», «про трудности жизни и ведения бизнеса», «не бывает незаменимых сотрудников»(тема на отдельный холивар на 1000 комментариев) и т.д.
Надо просто сказать, спасибо тому что есть. А работать над «собой» надо обеим сторонам. Надеюсь я не был слишком категоричен.
Уверен, что ваша версия реальности может быть координально другой. Это нормально и я ее заведомо принимаю, по причинам указанным выше.
Шлифануть это парой фильмов про Силиконовую долину

Почему удалили мой комментарий, где я говорил, что правильно не Силиконовая долина, а Кремниевая? От этого долина не станет Силиконовой, поэтому это по прежнему ошибка.
И от того, что кто-то будет минусовать коммент и карму, перевод «Силиконовая» тоже не становится верным, это так не работает :)
Устоявшийся термин. Что тут еще скажешь?
Он используется из-за тупых переводчиков, но тот факт, что кто-то так говорит, не делает перевод правильным. Это примерно как с ихний и евошний, среди определённых людей это тоже устоялось…

Оба варианта используются, и незачем холиворить. К тому же, силиконовая звучит прикольнее)

Только вот один из них неправильный.
Silicon Valley — Кремниевая Долина.
Silicone Valley — Силиконовая долина.
И незачем холиварить да, нужно просто использовать правильный перевод.
Ну Силиконовая долина тем не менее тоже существует. Только это совсем другая долина.
Ну так речь то в посте не про неё)
Черт возьми, зашел почитать про кандидатов, студентов, работодателей, а тут дельфесрач на мегатонны комменатриев. И опять придется поддерживать Delphi.
а тут дельфи на мегатонны
Не только, и не столько:
в «масштабах планеты», желательно получить гибрид TP+Oberon+Modula-3+ADA с лучшими качествами и языков, и IDE, и систем доказательств правильности ПО

А ещё тут экскурсы в историю Ж-)

P.S. Начали дискуссию как-раз разочаровавшиеся в «европейской школе» Ж-)
НЛО прилетело и опубликовало эту надпись здесь
полезная статья, ясно чо потом делать
После фразы
Итак, мы — небольшая компания, которая делает CRM-системы и софт для бизнеса.
я перестал читать
Нууу… Что сказать — проявили себя, высказали позицию.
Не конторе, занимающейся созданием хело-ворлдов (коими являются ваши cms/crm) судить о знаниях. Откуда вам это может быть известно?
А что cms/crm со всем набором всяких модулей не может быть сложней чем, например, сервер баз данных?
Мда… Вы сервер баз данных в соей жизни хоть раз видели, чтобы такое сравнивать?
Вы не работник этой ли конторы?
Скажите, ПО где несжатые, не кодогенерированные исходники объемом более одного гигабайта, это сложнее чем сервер бд?
Я к сожалению не помню сколько там строк кода было, но в чем вы меряете сложность, вам подавай много математики и алгоритмы на графах и подобном?
Нет, и если почитаете комментарии, то увидите, что даже не особо и наш поклонник. Но Varim прав. Начнём с того, что ставить CMS и CRM рядом как минимум странно — это даже приблизительно не системы одного класса. Мы понимаем, что вы сейчас просто озлобленно троллите (у вас могут быть причины на это — почему нет?), но ведь вы же демонстрируете свою полную некомпетентность в разработке — профессиональный программист может не любить корп. софт, но никогда не скажет, что он простой. Очевидно, что любая серьёзная CRM — сложный, — СЛОЖНЕЙШИЙ! — проект со сложной архитектурой и логикой.
Много вам, конечно, наговорили – хорошего и плохого.
Но у вас, как мне кажется, замечательная реакция на критику. И правда, умный человек больше ценит обличение ошибок, нежели похвалу.
Удачи! :)
Спасибо! Да, и нам разного наговорили, и в соцсетях много чего было сказано, мы постарались всем ответить, и вообще резонанс оказался выше, чем мы могли подумать. Самое обидное, что кто-то даже обижался на статью, — целей таких точно не было, просто наша часть диалога. Приятно, что сложилась такая гигантская ветка обсуждения Delphi — он заслуживает внимания. Стараемся реагировать и разъяснять :-)