Комментарии 1112
Но ведь по факту таки да. Советская экономика учила кучу инженеров, трудоустраивала их (пусть и за хлеб с водой, попутно гоняя «на картошку») и большинство было довольно. Сейчас же рынок инженерных специальностей значительно схлопнулся, а количество выпускающихся меньше не стало. Как итог — большинство идут «менеджерами» всяких субстанций. Причем да, со стороны бизнеса есть запрос — но совсем на другие квалификации, которые после вузов не образуются.
> закрыть годами не могут
Ну с вашей стороны тоже лукавство — любую вакансию можно закрыть, предложив достаточную компенсацию. Значит не очень надо.
любую вакансию можно закрыть, предложив достаточную компенсацию. Значит не очень надоНе всегда требуемая соискателями компенсация коррелирует с их уровнем. Но и это не всё — есть куча факторов, по которым отсматривают кандидата, и все их нужно брать в расчёт. Например, у нас нет собеседования с HR-сотрудником, предпочитаем не тратить своё и соискателя время. То есть нет тех самых «ламерских» факторов типа «агрессивный психотип в восьмой луне». Но тем не менее отобрать особо и некого.
Тут дело даже больше в том, что молодым менеджером можно заработать в теории больше, чем начинающим разработчиком. Просто потому что тот же продажник быстрее начинает создавать нужную конторе ценность.
Нет. Нужную конторе ценность создал разработчик (-ки). А продажник ее продал.
Просто работодатель не может оценить потенциальную ценность продукта, пока ее продажник не продаст. Поэтому ценит продажника. И продажник тоже себя ценит. А разработчик должен доказывать свою ценность фирме какими-то виртуальными показателями — тысячами SLOC, закрытыми тикетами, черти чем еще.
Любой (вру, не любой, — адекватный) бизнес поднимет зарплату хорошему сотруднику, и не раз. Но только в ответ на экономический эффект от работы сотрудника. Проще говоря, ты приносишь фирме больше — она тебя весомее благодарит.
Эти типично красивые слова не выдерживают проверки временем.
Ценность, которую принесет разработчик в большой продукт, может быть монетизирована фирмой через пару лет. К этому времени разработчик уже уволился, потому что фирма его не оценила — ровно потому, что ничего фирме он не принес.
А теперь внимание, вопрос — вы выплатите уже уволившемуся разработчику премию за его вклад двухлетней давности?
И, чтобы два раза не вставать, — офис, НН и Делфи — вы серьезно?
Нет. Нужную конторе ценность создал разработчик (-ки). А продажник ее продал.
Можно посмотреть с другой стороны: продажник создал потребность (нашел того, кто платит) и возможность компании заработать.
Не даром многие не хотят кодить на себя, им комфортнее, когда есть работодатель с штатом продаж.
Любой (вру, не любой, — адекватный) бизнес поднимет зарплату хорошему сотруднику, и не раз. Но только в ответ на экономический эффект от работы сотрудника. Проще говоря, ты приносишь фирме больше — она тебя весомее благодарит.
Не согласен. Вернее, это действует не везде. Например, в той же торговле, если сотрудник рвет задницу, перевыполняя план, и получает ЗП больше, чем рассчитывал платить работодатель, то либо ставится невыполнимый план, либо уменьшается процент. Да и не только в продажах так.
Хотя казалось бы, такой сотрудник — приносит больше пользы компании. Но работодателя жаба давит платить вменяемые деньги.
P.S. Я, если что, в торговле работал более 10 лет назад. Но, подобное до сих пор применяется.
Насколько я понял посыл статьи, речь идет о выпускниках институтов.
Вы реально видите много примеров, когда выпускник устроился джуном в компанию и сделал вклад в продукт, который оценивается большими деньгами?
Я сплошь и рядом вижу, что новички, пришедшие на первую свою должность, зачастую неспособны просто самостоятельно настроить себе рабочее место в соответствии с инструкцией на вики, месяца 2-3 тратят только на то, чтобы заполнить букмарки с важными инструментами в инфраструктуре. Но когда через полгода нужно сменить пароль, снова вместо того, чтобы поискать готовый ответ на внутренней вики, всех дергают, поскольку аккаунт залочился после 5-й попытки сделать красивый пароль, хотя при его смене требования к паролю написаны прямо на экране.
P.S. Исключения конечно есть, но они так редки, что лишь подтверждают правило…
Про монетизацию — не думаю, что автор и его коллега в этом тезисе "Но только в ответ на экономический эффект от работы сотрудника. Проще говоря, ты приносишь фирме больше — она тебя весомее благодарит." имели в виду только выпускников. Судя по этому комментарию, это общее правило для всех сотрудников.
Даже при всем понимании конкретного менеджера, а то и владельца компании, о том, что «кадры важны», как только компания достигает уровня 100-300 и более сотрудников, все становится слишком сложно, ибо нельзя найти 20-30 человек с одинаковой идеологией. А следовательно найти 20-30 руководителей на все посты, чтобы они одинаково следовали ценностям — тоже нельзя.
Всем нужно идти навстречу друг другу.
аккаунт залочился после 5-й попытки сделать красивый пароль,
хотя при его смене требования к паролю написаны прямо на экране
— в AD «лочится» за 5 неправильных «вводов» текущего пароля
и блокировка эта «на время» ( не связано это со сменой пароля)
— если новый пароль не соответствует,
то просто форма ввода не закрывается
вводишь до упора
готовый ответ на внутренней вики
Не меньше 8 + «буквы, цифры, запятые» — удостоены статьи в Wiki?
( и, кстати, есть или нет это «на экране» — не помню, хотя и пытался вспомнить)
всех дергаютвсех кроме сисадмина?
через полгодауменьшите срок до 40 дней, тогда есть шансы «довести до автоматизма»
В общем как только появляется что-то посложнее, чем один пароль и один сервис, что-то, что требует некоторых навыков самоорганизации, 99% выпускников на этом заваливаются по полной.
множество других авторизацийЯ таки предчувствовал
)
Всякую всячину надо бы интегрировать с AD
тестовые пользователиВыставьте в тестовой среде
опцию «не требовать смены пароля» на уч.записях
требует некоторых навыков самоорганизации,
Как бы это культурно выразить? Что бы без обид?
Но и промолчать мне, ведь то же вредно для вас же — что многое «не так» видно сходу ( по первому сообщению)
1) Вы зря «наехали» на «юных падованов»
2) следствие: у вашей орг-ции большие шансы «прославиться» «аки» Медок
P.S. Неужели у ваших заказчиков тоже множество систем и без SSO, и без «стыковки с AD»? Зачем вам тестировать на стенде не соответствующем реалиям заказчика?
P.P.S. к Jira и Сonfluence точно есть внешний компонент стыковки с AD по керберос
И даже при наличии такой интеграции, может быть двухфакторная авторизация, вторая часть которой обслуживается другой службой.
Вдобавок это может быть отдельный AD, развернутый в рамках тестирования проудкта, потому что часть проектного девелоперского окружения, а не корпоративной инфраструктуры, следовательно это внутренняя кухня проекта.
А если вы сами разработчик в microsoft, у вы его сами пищете — у вас этих тестовых AD инстансов может быть десятки.
1) не зря, в организации со сложной бюрократией и многослойной инфраструктурой тоже нужны джуны.
2) Вот вы вообще не с той стороны на мой комментарий смотрите.
— реальные пароли пользователя
— пароли для тестовых стендов
В идеальном случае паролей первого типа должно быть ровно 1. Т.е. все системы компании должны быть интегрированы в AD или SSO, чтобы пользователю не нужно было менять пароли во многих системах и запоминать их. К этим паролям могут предьявляться требования по сложности.
Пароли второго типа — это пароли, на которые не должны распространятся правила по смене/сложности пароля. В идеале можно ввести либо единый пароль, либо пароль = имя пользователя.
Если у вас не так, то не обвиняйте сотрудников, а наведите порядок в системах. Я уверен, что запоминание зоопарка паролей — это проблема не только для новичков…
Даже в обычном веб-проекте, пароль от mysql и shell — разные. Я реально не понимаю, почему при виде нескольких паролей, вы сразу обвиняете в беспорядке компанию.
Почему бы не предположить, что корпоративная система может быть достаточно комплексной, сложной, состоять из десятков тысяч сотрудников, и один единый пароль на все системы — нереален из-за инфраструктуры, которую нельзя упростить из-за совершенно объективных требоавний, а не «беспорядка».
В моей компании я использую всего 3 личных пароля для различных систем — особенности корпоративной иерархии. (Притом использую один и тот-же, чтобы не забывать и не путаться и меняю все одновременно.) Тут проблемы нет — т.к. 3 пароля запомнить легко. Для всего остального пароли хранятся в документации / конфигах или существуют правила (к примеру для всех тестовых юзеров 1 пароль) — и их не нужно менять каждые n дней.
У вас пароли лежат в документации/конфигах или существуют правила — все в порядке, а когдя я говорю, что новички не удосуживаются прочитать документацию и правила — вы придираетесь.
Двойные стандарты?
По поводу паролей в документации и конфигах — в том то и дело, что их не нужно менять и чаще всего даже вводить. Забрал последнюю версию конфига с TFS/Git, а там уже пароль лежит для подключения к БД. Запустил приложение протестировать, а там пароль такой-же как и имя пользователя. Красота! Обычно новички запоминают такое после первого объяснения и больше не спрашивают…
инстансов может быть десятки
Если требуется время жизни не меньше полугода,
то «всё» стыкуем с «местным» AD ( внутри DMZ зоны)
Внутри ещё TS или мини/midi :-) VDI
падованы и гуру заходят по RDP «давят» Yes
меняют пароль
И никого не «отвлекают каждые полгода» Ж-)
Т.е.:
«В идеальном случае паролей первого типа должно быть ровно 1». Т.е. я понимаю, что не всегда это возможно, но нужно к этому стремиться…
Позвал админа. Он попробовал чего-то добавить после звезд, не взлетело. Почесал затылок и забил
Зщшг-2017. Прокатило.
Истина не так уж проста, на рынке бывают перекосы. Если специалист или джун на рынке стоит Х, это не значит что есть значительное количество компаний которые могут это Х окупить с прибылью. Возможно есть компании которые в настоящее время без оглядки проедают бюджетные/инвестиционные деньги и перегревают рынок по этой позиции.
А если перекос в другую сторону (тупые изменения в налоговой политике из-за которых временная просадка) — это разговор в пользу бедных специалистов?
Мне, как специалисту, не выгодно ставить точку на балансе спроса и предложения. Потому что перекосы на самом деле есть и чаще разумнее их учитывать, чем просто идти "по рынку".
Многие семьи посматривают в сторону покупки второй машины при наличии первой, однако есть определенный лимит, выше которого платить не готовы. Это не значит, что таких денег в семье нет, а значит лишь то, что достаточных выгод от покупки Bentley они не получат, когда рассчитывают на Pajero, хотя Bentley своих денег стоит. Ровно также и в бизнесе: специалист просит 100к/месяц, его квалификация именно столько и стоит, но компания не готова платить более 60к, т.к. соответствующий продукт на выходе у специалиста принесет лишь 100-120к, а ведь еще налоги, различные платежи, оборудование, аренда. Так что в каждой ситуации есть определенные лимиты, которые работодатель может пересмотреть лишь в случае пересмотра отношения к самой вакансии (например, расширение списка задач для соответствующего сотрудника, или еще чего-нибудь).
Возможно есть компании которые в настоящее время без оглядки проедают бюджетные/инвестиционные деньги и перегревают рынок по этой позиции.
Интересно, а с какого рожна я должен входить в положение бедного нанимателя? Вот у нас например высокий % по кредиту, потому что гос. компании берут деньги и не возвращают, и этот невозврат закладывается в % по кредиту лично мне. Это такое же пердергивание рынка, и вы знаете, что-то еще ни один банк не вошел в мое положение и не выдал мне кредит под 2%, чтобы нивелировать передергивания. С чего вдруг я должен это делать?
Интересно, а с какого рожна я должен входить в положение бедного нанимателя?
А вы не должны. Нанимателю придется поискать другой путь решения кадровой проблемы если рыночная з.п. специалиста не вписывается в экономическую модель бизнеса. Иными словами, вы не получите эту работу а наниматель не получит специалиста.
Так что банку ну вообще не выгодно занять деньги под 8-9% и выдать вам под 2%.
компании берут деньги и не возвращают, и этот невозврат закладывается в % по кредиту лично мне
Это влияет только на маржу банка, а основная часть вашего процента — проценты ЦБ.
Вы так говорите как будто есть какая-то одна объективная мерка уровня соискатля и одна объективная цена. Это рынок, хоть и рынок труда. Не можете купить — предлагайте выше цену. Не можете предложить выше цену — это не значит что предложения мало, а это значит что предложения мало за те деньги которые вы готовы платить. Если ваши продукты и процессы не позволяют вам оплачивать сотрудников может быть стоит где-то оптимизировать бизнесс?!
> Любой (вру, не любой, — адекватный) бизнес поднимет зарплату хорошему сотруднику
Бизнес платит сотруднику столько, чтобы сотрудник не ушел работать в другой бизнес. Бизнес работает ради прибыли. Иначе это не бизнес, а благотворительность. Хороший сотрудник, который не показывает признаки мобильности будет сидть без повышений оплаты годами.
У меня при уходе из последних мест, все говорили, если разонравится на новом месте — возвращайся к нам, возьмем. Некоторые даже удержать пытались подъемом ЗП.
Мы, когда в 2014 году искали 2х весьма средних С++ разработчиков в Москве, просто с опытом не senior. Мы потратили просто тонну времени, чтоб найти адекватных. На двоих мы отсобеседовани около 50 человек по скайпу и около 10 очных провели. То есть это прям дофига и больше времени рабочего старших разработчиков. А это еще даже не включает времени на адоптацию новых сотрудников и все сопутствующие расходы.
Правда, статья не наша и десятилетней давности, но я не вижу причин, почему у нас все должно кардинально отличаться.
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% отказавшихся откажутся лишь потому, что не осилили. То есть, большая экономия времени интервьювера.
Ну если честно, то 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. или упростим — гласные желтым
( в TP — mod)
а если не захотел?А если он не захотел на какой-то другой вопрос отвечать? Значит, он сам себе злобный буратина, пусть в другое место идет работать.
куда печатать числа и буквы — на StdOut?Да куда угодно, для целей, которые ставятся перед этой задачей (быстро проверить, что человек умеет хоть что-то) это не важно. Есть сомнения — спросите.
я тут уже про кнопку F9-C-C упоминалВы и правда думаете, что найдется человек, который без Ctrl+Ins не сможет десять строчек набрать, но с Ctrl+Ins станет хорошим разработчиком? Думаю, это множество очень мало и им можно пренебречь.
может тестируемый без любимой кнопки уже и не может
в Clarion не уверен, что отдельный компилятор вообще естьА зачем вам в этой задаче вообще компилятор?
Ладно, будем считать это быстрым прототипом:
@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. Про не сможет или не захочет:
Самые битые жизнью отпросятся на экскурсию в места уед-ых ( студенты 3-их курсов мотайте на ус) раздумий
Ещё более тщательно оценят обстановку
( Вот здесь есть тонкость — контора может размещаться
на нескольких этажах или в раздных зданиях)
И собствено, тут при положительной ветви предсказателя ветвлений можно писать 100 строчник
alexeykuzmin0 не обижайтесь и не принимайте на свой счёт:
ваша модификация IQ теста как раз имеет отклонения к лучшему,
пишу я больше для начинающих тестируемых
Но не стоит забывать, что реально-то все эти приколы оценят интеллект эмоциональный ( у своего HR можно взять перевод термина Ж-) )
Элегантные 100 строчники принимаются? Ладно, будем считать это быстрым прототипомТакой пример сразу вызовет вопрос «а вы можете написать более читаемый код?». Хотя, насколько я понимаю, статья, на которую я сослался, говорит о том, что 99.5% соискателей даже такое написать не в состоянии.
Для разработки «через тесты»Что-то я сомневаюсь, что существуют хорошие разработчики, которые не могут написать FizzBuzz без TDD.
FizzBuzz без TDDТам как-раз подразумевался смайлик Ж-)
«а вы можете написать более читаемый код?»Как раз для .bat циклы и арифметика гораздо менее читаемы Ж-)
А при «красивом» коде можно, наоборот, спросить:
Задача явно разовая. Почему излишние потери рабочего времени?
Т.е. опять-таки задача на эм-ый инт-кт Ж-)
статья, на которую я сослался, говорит о том, что 99.5% соискателей даже такое написать не в состоянии.Точно так
Судя по выводимому логу — да.
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 — накопленный опыт показывает, что такие задачи на собеседованиях почему-то не позволяют отобрать нужных кандидатов — нужно как-то иначе проверять.
Видимо, нужно проверять еще и мотивацию — способность решить такие задачи гарантирует только то, что кандидат решит их на собеседовании, чтобы его пройти, но не гарантирует, что будет действовать так же в самой работе.
Есть современная альтернативная точка зрения.
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 г.
Возможно тогда была проблема с кандидатами на рынке и все валили из страны, хз либо сидели на своих местах и не рыпались.
Мы вообще почти знаний никаких не требовали. Знания языка базовые(мы не спрашивали про всякие virtual inheritance и вопросы с подвохом про С++), был вопрос как реализовано std::map/std::unordered_map в общих чертах по скайпу, но если кандидат не знает стандартной библиотеки, мы это пропускали. Но если пользовался std::map — и не читал исходников и не знает как оно работает, то это пробел.
Были несложные задачки на алгоритмы, про алгоритмическую сложность, базовое про знание float/double чисел, например, как сложить с минимальными потерами массив из float и какова сложность решения. Какие то базовые вещи про многопоточность, вроде mutex vs spinlock, написать mutex/spinlock.
Если взять реализацию, скажем, CriticalSection в Windows, то там будет и спинлок в юзерспецсе некоторое время, сколько-то итераций, и падение в ядро с ожиданием. Но это не значит, что мьютекс — непременно такая эффективная вещь.
Да, голый спинлок — это частный случай реализации мьютекса, пусть и неэффективный. Спинлок — реализация, мьютекс — абстракция (разделение доступа к ресурсу).
Это если пишет под Linux, в Windows же аналога ему нет. Наиболее низкоуровная вещь — CRITICAL_SESSION, но она в точности является мьютексом.
Ну тогда я не удивляюсь, почему нормальных кандидатов оказалось только 4. Возможно, требование должно было звучать как "опыт написания высокопроизодительных программ под Linux"
Для меня "опыт разработки под Linux" — слишком общее понятие, которое не подразумевает знания всей подноготной. То есть использование pthread с pthread_mutex_t — это и есть опыт разработки под Linux. Ну а лезть в недра glibc — это уже не задача рядового С++ программиста.
Мы скорее вели дискуссию про такое. Как бы кандидат это реализовал и почему.
Возможно, требование должно было звучать как «опыт написания высокопроизодительных программ под Linux»
У нас пару лет примерно такая вакансия и висела, но кандидатов вообще были единицы. Потом мы снизили порог, тк нужно было нанимать побыстрее.
Тогда вопросов нет. В принципе, научиться писать высокопроизводительный код под конкретной окружение не составит труда, если у кандидата уже есть опыт подобной оптимизации в других областях и понимание теории. Поэтому действительно проще подобрать способного кандидата, чем искать готового.
научиться писать высокопроизводительный код под конкретной окружение не составит труда, если у кандидата уже есть опыт подобной оптимизации в других областях и понимание теорииКак будто если подобного опыта нет, так научится этому составит много труда…
В любом случае работодатель за это заплатит, если не найдет дешевого падавана, на которого перекинет обязательство это выучить за недорого.
Да, это может занять несколько месяцев или даже пару лет. Одних знаний мало, нужен ещё и опыт. Не любой работодатель будет готов столько времени потратить на обучение.
А зачем к нему идти, нужно выбираться от туда где проблемы с деньгами или экономия на сотрудниках.
Но стоит обратить внимание, что даже человек с опытом тоже может отлаживать не один месяц.
Но да, новичку такая бага не по силам, ему нужно начать с чего попроще при поддержке того кто поопытней. Так что да, надежда на способного кандидата.
Вариант ответа: бинарное дерево без уточнения типа (красно-чёрное, AVL или ещё какое-нибудь) устроит? Главное, что время вставки/удаления/поиска — O(log N), а остальное — детали реализации.
Ну читать исходники C++ STL — сомнительное удовольствие, дефайн на дефайне и дефайном погоняет, плюс дикий объём кода.
Но AVL от RB довольно сильно отличается в некоторых вещах. И если пишешь на С++, то хорошо бы знать такие нюансы, так же знать сколько аллокаций требуется и памяти, например. Это совсем базовые вещи для С++. Иначе, тогда можно и на перле писать, если в таком не разбираться.
Высокопроизводительный код на С++ вообще не очень приятно писать. Если страшно читать STL, тогда лучше его не использовать, что многие и делают.
И если пишешь на С++, то хорошо бы знать такие нюансы, так же знать сколько аллокаций требуется и памяти, например.
Увы, этого знать невозможно просто потому, что стандарт языка не определяет детали реализации. В библиотеках MSVC, GCC, Intel реализации могут очень сильно отличаться друг от друга, и это нормально.
Это совсем базовые вещи для С++
Не соглашусь с данным утверждением.
Высокопроизводительный код на С++ вообще не очень приятно писать. Если страшно читать STL, тогда лучше его не использовать, что многие и делают.
Ну так высокопроизводительный код и универсальная STL — вещи малосовместимые.
В библиотеках MSVC, GCC, Intel реализации могут очень сильно отличаться друг от друга, и это нормально
Верно, но мы и не использовали такой набор компиляторов. У нас была одна версия gcc, который нас полностью удовлетворял, про которую мы много чего знали. И компилятор и ядра мы оооочень аккуратно и медленно обновляли. Лучше ограничить себе задачу и не поддерживать, например, сборку под macosx или windows, если никто и никогда этот код там не будет запускать. То же и про версии ядер и компиляторы.
Ну так высокопроизводительный код и универсальная STL — вещи малосовместимые.
Я скорее, про то, что оба занятия не самые простые и приятные. Но часто нужно читать реализацию, прежде чем использовать. Как, например, после чтения дикого сгенерированного кода protobuf выяснилось, что он работал медленнее, чем самописный реккурсивный json-parser. То есть бинарная десериализация работала медленнее, чем текстовая json. Из-за кучи различных аллокаций по месту и нет в protobuf-е.
Ага, а потом программистов почему-то начинают ругать за написание велосипедов.
У меня в проекте тоже используется самописный Json-конвертер, и он тоже быстрее библиотечных. И библиотека для распараллеливания у меня тоже своя (накладные расходы в parallel_for уменьшились в разы). Ускорение за счёт снижения универсальности — это нормально.
Ага, а потом программистов почему-то начинают ругать за написание велосипедов.
В том, месте работы у нас все было практически самописное, даже часто из-за проблем сопровождения opensource продуктов. Сейчас же у моей фирмы нет столько ресурсов или она их более рационально использует и мы по максимуму переиспользуем тукущие решения. И пишем что-то, только если вообще нет готового или оно совсем негодно. Но тут и нет таких требований по скорости. Но писать свое больше фана, чем рыться в чужих бага в JIRA-трекере проекта или заводить новые.
Ускорение за счёт снижения универсальности — это нормально.
Да, так и есть.
Если страшно читать STL, тогда лучше его не использовать, что многие и делают.Дело не в том страшно или нет, тяжело или нет, а в том, хватит ли у вас денег чтобы человек этим занимался за подходящую ему ЗП. Именно поэтому многие на C++ не пишут.
молодым менеджером можно заработать в теории больше, чем начинающим разработчиком
А откуда возьмётся молодой менеджер без руководящего опыта?
(реально интересно)
молодым менеджером можно заработать в теории больше, чем начинающим разработчикомНасколько я понимаю, джун без опыта в Москве вполне может получить тысяч 50. Неужели продажник без опыта имеет шансы получить больше?
Продолжают клепать спецов в количестве, значительно превышающем потребности рынка, а потом удивляются: чего это у нас так мало людей работает по специальности?
IMHO, инженеры АСУТП нужны, но платить им и обучать их мало кто готов.
Продолжают клепать спецов в количестве, значительно превышающем потребности рынка, а потом удивляются: чего это у нас так мало людей работает по специальности?
"Продолжают, удивляются" — кто продолжает и удивляется?
Ну не принудительно же людей в АСУТП затаскивают, они сами ведь идут, на что-то надеются. И скорее всего получают желаемое, работая в макдаке менеджером или переезжая туда, где спецы АСУТП нужны.
зацепился за фразу «любую». Есть вакансии, список потенциальных претендентов на нее исчисляется единицами и все они уже пригреты и обласканы. И сколько бы вы не предлагали денег (а у любого предложения есть верхний предел экономической целесообразности) сотрудник не бросит свою квартиру в уютном районе с хорошей инфраструктурой, с детсадом и школой для детей, парком, прикормленными уточками в соседнем пруду, сворой знакомых, родственников и т.д. Ну вот не повезло вам иметь свой офис не там где живет этот уникальный специалист. Хотя если бы повезло, то он бы к вам обошелся очень и очень бюджетно.
Конечно можно обойтись и без него, но его наличие дает кардинальный прирост в решении нестандартных проблем и задач. Именно такие придумывают решения которые устраивают сразу по многим параметрам.
Это как переводить с русского на английский имея под рукой только русско-монгольский, монголо-китайский, китае-немецкий и немецко-английского переводчиков. Причем каждый из них не в полной мере владеет предметной терминологией (точней все владеют, но в разных диапазонах).
Радует, что с русского на английский переводит нужно не часто. Но когда нужно, хочется просто застрелиться. А был бы русско-английский переводчик, всем было бы проще жить.
учила кучу инженеров,
Есть подозрение, что кучами лежат отнюдь не бриллианты. Да и орлы стаями не летают. А значит, 120рублевые инженеры в массе своей были инженеграми, пригодными только для распивания чаев и чего покрепче (сужу по рассказам тех, кто в советские времена в «Алмазе» работал — на отдел человека 4, которые тему тянут, остальные балласт для картошки)
Это я к тому, что сомнения в качестве своей работы и способность себя рационально оценивать не совсем коррелируют с "профессионализмом" и "экспертностью". Более того, у начинающих программистов обычно для этого оснований меньше, чем у уже 10-летних senior'ов, которые вроде как матерые ребята и все в это жизни видели.
К сожалению, на практике это людям без ЧСВ недоплачивают)
Если вам специалист таки нужен, а вакансия уже полтора года незакрытая висит — то наверное таки да. Доплачивать за ЧСВ и тщательно холить и лелеять.
Вообще-то не мне вас учить бизнесу, раз вы что-то таки продаёте, но ИМХО — у вас какие-то вредные шаблоны в голове. В комментариях неоднократно мелькали фразы: "вам шашечки или ехать", "рынок труда, а не ваше мнение, диктует цену" и тому подобные. Но вам как об стенку горох: вынь да положь готового перспективного спеца, согласного работать на устаревших технологиях, а ВЫ к тому же ещё и хотите решать — сколько платить и как часто повышать ему з/п.
Хочется спросить — у вас там капитализм уже или всё ещё советская власть?
Очевидно:
- работодатель считает "раз технология вышедшая из моды, то можно платить меньше", забывая о том, что речь не о пенсионере на старом заводе, который хочет дотянуть там до пенсии, и который уже ничего нового учить не станет
- работник видит, что если он будет работать на Java или C#, то он и через пять лет будет востребованным высокооплачиваемым работником, а если будет работать на Delphi, то через пять лет он рискует оказаться невостребованным
=> работник согласится работать на Delphi, только, если ему за него будут платить не меньше, а БОЛЬШЕ, чем за модные Java и C#, потому что только в этом случае будут покрыты будущие возможные риски связанные с перспективами на востребованность через несколько лет.
10 лет назад ушела он бац Ж-) и всё ещё жив
Как там у А.C.? «Вздыхать и думать про себя»?
P.S.
Он уважать себя заставил И лучше выдумать не мог.
то жив как технология
жив крайне мало гдеА Ваша выборка в терминах статистики репрезентативна?
Э.Дейкстра писал, что язык программированиия должен быть
способен заточить карандаш ( и не быть тупым топором)
Так вот, если перочинный нож выполняет свою задачу — то что?
Или кузнецов возьмём: ну не скучно им
Есть большая разница между фразами "я не знаю" и "я не знаю, но думаю что должно быть вот так". Разница как раз в том, что во втором случае у человека есть фундаментальные знания (бэкграунд), он в итоге может решить проблему или хотя бы знает куда копать.
Вот вы знаете, профессионалы и эксперты почему-то склонны в себе постоянно сомневаться
Как-то рассказывали о кандидате на должность программиста в крупную it-компани: «Сегодня приходил парень, вроде нормально рассказывал, но жутко неуверенный в себе. Не взяли, неуверенные нам не нужны».
С другой стороны, думаю, что если бы отвечал отлично, то взяли бы не смотря на неуверенность.
Я оставил delphi очень давно, так как, скажем, до сих пор не очень понимаю, чем он лучше для разработки, чем тот же C#, если говорить про Windows.
Апелляция к legacy системам, которые писать давно тоже не катит, так как на C#, Python, Java, C++ и еще куче языков тоже пишутся серьезные вещи и вполне успешно.
Но ведь Delphi таки кроссплатформенный. Довольно давно уже есть все возможности для разработки под MacOS, iOS, Android. А с не давних пор присутствует и LLVM-компилятор для Linux.
C# таки уже тоже кроссплатформенный. Именно потому, что он не вымерший и его развивают. .Net Standart, .Net Core, Xamarin, Mono и т.п.
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ое место в рейтинге
Вот и вопрос — настолько ли он мегапопулярен? Незанчительно выше Делфи по индексам :)
Потому как судя по вакансиям, ну вы поняли.
Если рейтинг составляется по признакам использования (например, на основании упоминания на форумах), это может говорить о разных вещах:
- Вакансии на Дельфи не появляются в изобилии по причине превышенич спроса у соискателей над предложением работодателей (быстро закрываются)..
- Вакансии на Дельфи заполняются в основном не на открытом рынке, а "своими", "по знакомству".
- Дельфи применяется в основном не для разработки больших коммерческих проектов, а "для дома" или для автоматизации каких-то рабочих процессов своими силами (например, какой-нибудь ученый ваяет на нем специфические программы для особенной обработки своих данных.
- Что-то еще.
В какой пропорции оно может быть намешано — пес его знает
Т.е. Вы, SirEdvin, берётесь переписать работающий проект с Delphi на C#/C++ / etc.?
И какой видите срок окупаемости?
Таки уже да, к сожалению, сразу эту инфу не нашел.
Т.е. Вы, SirEdvin, берётесь переписать работающий проект с Delphi на C#/C++ / etc.? И какой видите срок окупаемости?
Как я уже сказал
Апелляция к legacy системам, которые писать давно тоже не катит
Проблемы легаси это проблемы легаси.
про то что Вы лично ушли с Delphi я читал,
про бизнес последствия — здесь не было, по-моему
Вопрос про окупаемость был скорее риторический:
навряд ли фирма автора поста считает переход окупаемым
Или же привести другие разумные причины, почему все-таки нужен Delphi. Вот я не люблю Go, но мне понятно, почему на нем стоит писать. А почему стоит писать на Delphi?
> почему стоит писать на 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 и так далее.
Потому что runtime для python преобразовывает аппаратные ошибки для вас в софтверные. Или это плохо?
Приятель, ушедший туда тимлидом, рассказывал обратное. Стоит ли спорить о вкусе устриц с теми, кто их ел?
Не знаю, я сужу исключительно как потребитель.
Как вы планируете получить такого рода исключение в языках, выполнение которых контролирует специальная обертка, как в случае с практически всеми новыми языками, да еще и так, что бы она не была перехвачена этой оберткой?
А ещё бывают сбои памяти и процессора. И они приводят к тем же прерываниям. Особенно на разогнанных машинках. Или на не разогнанных, но случайно нагревшихся.
У нас даже процессор с отколотым уголком как-то был. Причем он работал, только пару раз в сутки вылетал. :-)
Смысл в том, что 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
А тот тоже «в кластере» Ж-)
криворукий админ выдернул шнур интернета у физической машины.
Интернет — чреват террактами и хакерами. На такого рода системах его нет. Даже клиентские машины изолированы от интернета физически. Только две собственных локалки.
Если для построение отказоустойчивой системы вы надеетесь на хостовую систему, в которой запущено приложение, вы совершаете большую ошибку.
Аналогично, если вы надеетесь только на одну линию обороны (резервный сервер) — вы тоже совершаете ошибку. Но, скорее всего, цена вашей ошибки мала, поэтому одной линии обороны вам хватит.
Аналогично у нас слабая защита от хакеров — только одна линия обороны: физическая изоляция от интернета. Если хакер устроился на завод — он сможет сделать всё. Но это уже к отделу кадров. :-)
Аналогично, если вы надеетесь только на одну линию обороны (резервный сервер) — вы тоже совершаете ошибку. Но, скорее всего, цена вашей ошибки мала, поэтому одной линии обороны вам хватит.
А подскажите другие линии обороны, которые бы помогли. Мне кажется, что если внезапно повреждается память на одной машине, вообще не важно, как упадет программа, так как все данные, кроме последней неудачной операции уже синхронизированы с другим сервером. Чем поможет вот эта возможность обработать повреждение памяти, если как уже указали ниже, это довольно сложно сделать правильно для всех случаев, и это решается другим необходимым средством?
А подскажите другие линии обороны, которые бы помогли.2-3 версии программ. Если клиент своими запросами свалил пару серверов — даем ему предыдущу версию. Устойчиво роняет и её — даем ему
вообще не важно, как упадет программа, так как все данные, кроме последней неудачной операции уже синхронизированы с другим сервером.
Вот именно в этом и отличия ваших веб-серверов с АСУТП. У вас цена состояния сервера — ноль. Или почти ноль. А в АСУТП обычно это самое ценное. Потому у вас и упор на сервера, а в АСУТП — на робастность кода.
Чем поможет вот эта возможность обработать повреждение памяти, если как уже указали ниже, это довольно сложно сделать правильно для всех случаевТем, что это сильно быстрее и сильно дешевле полной отладки «до последнего бага». Для всех — не сделать. Для наработки на отказ 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.
Лучше понимать, что из-за бага DOS-атака может придти и со стороны валидного клиента. Ну и принимать меры
предлагали всякие ADA и математическое доказательство правильности работы кодаДаже и не ADA, а подмножество ( SPARK)
И скорее, констатировал факт: идеи Э.Дейкстра потихоньку «идут в ход»
Смысл в том, что 36524 — это 36524 невзирая на все сбои.
Автоматический перезапуск после падения можно настроить независимо от языка.
И автоматический перезапуск, и дублирующий сервер — это всего лишь резервная линия обороны. Как единственная линия — они не годятся.
Как минимум — падающий сервер должен как-то предупредить резервный, что он уходит в даун. Ибо поднятие резервного по принципу мертвой руки — слишком медленно.
… но необходимо. Потому что у основного сервера могла уборщица провод выдернуть шваброй.
Но на тот случай когда вам нужно повышение скорости реакции хотя бы в некоторых случаях — есть std::set_terminate
.
std::set_terminate — Да, полезно, если на Си пишем. Ещё полезней — сигнализировать из батника после завершения (если это возможно).
На дельфи чуть лучше — любое нештатное завершение идет через исключение. И ловится до отработки финализации модулей. Лучше именно тем, что запихавши слишком многое в set_terminate можно и не завершиться. А полноценный контроль ошибок в нем не сделать — потеряна информация о том, что живо, а что нет.
А у нас процесс ловли ошибок многоуровневый. И деградация многоуровневая. Не справились на одном уровне — провались дальше, на более простой и грубый уровень.
Я бы осторожно сказал, что возможность удобно перехватить segfault как исключение ещё не делает язык более пригодным для высоконадёжных систем. Вот я не могу сходу придумать солидный пример, когда надёжнее попытаться восстановиться после аппаратного исключения. Вот вы его словили, и как вы хотите продолжать работать? У вас на руках система в неконсистентном состоянии, вполне возможно с повреждённой памятью, она себя дальше может повести непредсказуемо. Исключение полезно тогда, когда вы можете на него отреагировать каким-то осмысленным способом, а попытка восстановиться после чего-то неизвестного, много чем чревата.
что «ADA-Linter на Prolog-е» ( см.здесь же детали) обработать программу с исключениями не может.
Т.е. исключения всё-таки слегка «припудренный»/облагороженный, но 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 активно использовал при обработке событий — без него можно, но как-то совсем уж мутно Ж-)
Вот теория и практика — расходятся Ж-)
Увидеть гонку — намного сложнее. Даже на двух тредах, а уж если их больше…
И как раз к альтернативам склонились
> Увидеть гонку — намного сложнее.
О, как раз и на эту тему появился инструмент,
который доказывает как теорему, что с блокировками и т.п. «всё в порядке»
Входной язык — один в один как у Э.Дейкстры ( if/fi, do/od и семантика )
Можно ссылочку на альтернативы?
Кажется, именно здесь на Хабре и читал про 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 доказать правильность программы с исключениями не может.
Это вообще не аргумент — код на исключениях превращается в код без исключений стереотипным добавлением информации об ошибке в результат.Собственно исключения возникли из кризиса обработки ошибок в классическом структурном программировании, когда на одну строку целевого кода надо добавлять по три шаблонного с отработкой косяков.
В го такое объявили самым лучшим способом — ну, видимо в его сфере применения задачи простые, а цена ошибки высока.
Вот только на фоне раста, где за пропущенную обработку по рукам бьет компилятор это каменный век.
У вас на руках система в неконсистентном состоянии, вполне возможно с повреждённой памятью, она себя дальше может повести непредсказуемо.
Если в системе есть баги, то она в любой момент может повести себя непредсказуемо. Согласны? Ловля AV лишь увеличивает эту вероятность. По опыту — увеличивает несильно.
Пример по текущему проекту на С++. За 7 лет был пяток порчей памяти, ни один из них не проявлялся как AV. За те даже годы было полсотни AV — ни один из не привел к порче памяти.
На Дельфи — на сотни AV лишь несколько из них были вызваны порчей памяти. Все, кроме одной — были локальными, то есть касались лишь одного запорченного объекта. Одна — запортила структуру кучи.
На дельфи — постоянные assert и проверка инвариантов.
А какая у вас статистика? У вас есть конкретные данные, кроме опасений? Сколько раз вы ловили AV и сколько раз была порча данных помимо того, объекта, который вызвал AV? А сколько этих глобальных порч данных оставили живой структуру кучи? А структура кучи — это то, что проверяется при любом аппаратном исключении. В смысле мной проверяется.
Мы сидим на Java и хостимся на облаке, так что у нас все отказы — либо аппаратные, либо связанные с исчерпанием системых ресурсов. И выглядит это так: машина тупо виснет и не реагирует ни на что.
active-active либо отдельный хост в виде супервизора — единственный рабочий вариант.
- Вы на облаке, и цена инстанса мала
- Состояние сервера имеет малую цену
- Зависший запрос имеет малую цену.
- Полный отказ системы имеет малую цену
- Время переключение между интансами мгновенно
Поэтому вам хватило одной линии защиты. Скорее всего ваши сервера стоят в одной стойке (или вообще инстансы на одном физическом сервере). Ну о каком дублирующем дата-центре вы думаете.
Обычно в АСУТП:
- Цена сервера велика из-за стоимости аппаратуры сбора данных.
- Состояние сервера ценно
- Зависшая операция может вызвать катастрофу, вплоть до людских жертв
- Полный отказ системы фатален
- Время переключения между серверами — достаточно велико.
В итоге было выбрано 3 линии защиты: перезапуск подсистем (крупных объектов), перезапуск систем (тредов), перезапуск серверов. Ну и само собой — сервера в разном помещении и запитаны от разных фаз.
У нас был выбор: полная отладка (100% к цене проекта и 10 лет) или защита от программных ошибок (30% к цене и примерно год).
Кстати, с какой частотой вы видите ошибки в своей системе? Мы приостановке отладки дошли до уровня «за месяц — ни одного бага».
Мы на облаке, и отказ любого узла не приводит к отказу системы. Всё продублировано и восстанавливается автоматически. На AWS с 50 хостами железо отказывает в среднем раз в месяц.
В целом это вопрос дизайна и технологий — отказ любого компонента НЕ должен влиять на работоспособность системы.
Но для производства, пожалуй, проще заплатить большие деньги производителю железа и инженерам, которые умеют строить выч. центры с заданной надежностью, чем полагаться на софт.
Вторая единая точка отказа — пожар, цунами, падение самолета на ДЦ. Или вам облако гарантирует использование нескольких ДЦ одновременно?
Ещё раз повторю вопрос: с какой частотой вы видите программные ошибки в своей системе?
Для систем, подобных вашей — действительно, лучше дублировать сервера и ДЦ. Но единая точка отказа в виде бага в программе у вас все равно есть.
Помните баг с юникодом в сафари? Вот что-то вроде этого.
отказ любого компонента НЕ должен влиять на работоспособность системы.
А разве отказы клиентов вас не волнуют? Ваши клиенты имеют дублирования провайдеров, электропитания, компов???
Но для производства, пожалуй, проще заплатить большие деньги производителю железа и инженерам, которые умеют строить выч. центры с заданной надежностью, чем полагаться на софт.
Для АСУТП? В корне неверно. Представьте себе автомобиль, у которого управление газом и тормозами идет через облако. Чушь ведь?!
Вы не потащите 10 тысяч проводов в ДЦ. Значит — сериализация. А это — единые точки отказа вместо 10 тысяч отдельных точек. Дальше — проблемы с синхронизацией. Время отработки — обычно 20 мс, а одном из контроллеров — 4-5мс. Вы готовы гарантировать пинг в 1 мс?
Так что никто не тащит управляющий софт в ДЦ. Ни от автомобиля, ни от стана. Наоборот, его ставят максимально близко.
И ещё раз — с какой частотой вы видите программные ошибки в своей системе?
Похоже на взаимное недопонимание :-)
- да, каждая программа развернута минимум в двух экземплярах. Все программы и клиенты, которые к ней обращаются, умеют по таймауту реконнект к другому экземпляру
- да, облачные провайдеры позвлоляют размещать машины в независимых стойках, датацентрах и регионах
- если клиент программы/сервиса может определить, что сервис сломан, он пойдет в другой экземпляр. Если не может (сервис выдает правдоподобный мусор), то плохо. Но я такого не видел никогда.
- я неточно выразился, не отказ компонента, а отказ экземпляра компонента конечно же. Функционал системы в целом не страдает
- я собственно именно это и имел в виду — когда есть деньги на надежное железо с инфраструктурой и стоимость отказов очень высока — проще купить стойку или несколько и поставить поблизости.
Про программные ошибки: JVM ОЧЕНЬ стабильна и убить её может только нехватка системых ресурсов или аппаратный сбой. Мы не пишем системы управления, так что все алгоритмические ошибки у нас воспроизводимые.
JVM ОЧЕНЬ стабильна и убить её может только нехватка системых ресурсов или аппаратный сбой.Или баг в нативной библиотеке.
если клиент программы/сервиса может определить, что сервис сломан, он пойдет в другой экземплярНасколько быстро? Вот зависло TCP-соединение, через какое время клиент пойдет на другой сервер? Сделаете мало — будут проблемы при плохом инете. Сделаете много — тоже нехорошо. Потому и стараемся закрыть TCP-коннекции (точнее PIPE) штатно при отказе сервера.
я неточно выразился, не отказ компонента, а отказ экземпляра компонента конечно же.Так у вас единая точка отказа в программном коде. Если есть воспроизводимый баг, работающий на определенных данных, то клиент сваливает все сервера, к которым он полез с этими данными.
И все-таки — с какой частотой вы видите программные ошибки в своей системе? Если раз в 20 лет — вам не нужны лишние уровни защиты. А если раз в неделю — то стоит подумать. Например — о автоматической деградации на предыдущую версию.
когда есть деньги на надежное железо с инфраструктурой и стоимость отказов очень высока — проще купить стойку или несколько и поставить поблизости.
Это вас не спасет. Один баг в программе и один клиент с кривым запросом. И все — все ваши сервера в постоянной перезагрузке.
Про то что винда конвертики аппаратные исключения в SEH вы тоже не в курсе
И заодно, что возможность запихивать SIGSEGV в структурные исключения — не уникальная фича Delphi.
Который java пробросит, когда столкнется с проблемой выделение памяти.
Как в других случаях получить проблемы с памятью в java не прибегая к черной магии — у меня идей не было.
Вы лучше приведите пример приложения (GUI или консоль), написанного не на дельфи (или дельфийском варианте С++), которое бы выживало после access violation. Ну хоть одно найдете?
Я на прошлой работе выживающий после AV сервер писал на C#. Труднее всего оказалось этот самый AV вызвать, не получив вместо него скрытое повреждение кучи. Пришлось выделять неуправляемые буфера памяти через VirtualAlloc, окружая их защитными страницами. Но это были особенности используемой нативной говнобиблиотеки, сам язык перехватывать AV мне не мешал.
Вопрос лишь в том, есть ли у него полный комплекс для написания надежных программ. Но одна деталька есть — и то хорошо.
Деталек у него более чем нужно. Там и желанный вами try...finally есть, и желанный плюсовиками RAII (отягощенный необходимостью писать лишнее ключевое слово чтобы его включить).
И обработчик необработанных исключений есть куда поставить.
И про скорость я бы не говорил что заведомо хуже.
Ну и со скоростью тоже неверно. Во-первых, JIT-компилятор вполне себе генерирует нативный код, и не факт, что хуже, чем компилятор Delphi. Во-вторых, C# не используется для вычислений — какая разница, с какой скоростью работает программа, если она большую часть времени ожидает завершения операций ввода-вывода.
какая разница, с какой скоростью работает программа, если она большую часть времени ожидает завершения операций ввода-вывода.
На 18 Мгц тактовой частоты — все иначе. И даже на 144МГц.
Судя по быстрому поиску — даже на Андроид/iOS его нет
Как это нет? Xamarin — это миф?
Ну и в 512К на embeded он влезет? А в 64К?
А на Delphi под такое можно писать?
А на Delphi под такое можно писать?
Если захотеть — вполне. Надо только ручками SDK/DDK сделать.
Мы же про Windows для msvc есть try и except где можно поймать исключение втч и Access violation
В Linux каждый поток является процессом, и для того, чтобы создать новый поток, нужно создать новый процесс.
Поскольку пишем переносимо, то в подробностях, как оно там в linux, я не разбирался. Сильно многопоточно приходилось только под windows писать.
Но в любом случае всегда есть возможность сделать регион памяти, который для шедулера был бы на RW, а для исполняющих потоков — на RO.
Для большинства языков access violation фатален и приводит к немедленному завершению программы. А на delphi — это всего лишь аппаратный exception, который можно обработать.
Это достоинство VCL, а не Делфи, что exception ловится на верхнем уровне приложения.
К этому добавляются удобные конструкции try..finally и try..except.
Извините, а вы, помимо Object Pascal, с другими языками, например, с Java, C++, Python знакомы? Это типовые инструкции языка, они сейчас есть везде.
Это достоинство VCL, а не Делфи, что exception ловится на верхнем уровне приложения.
Ничто не мешает сделать то же самое и без VCL (у меня — до 7 слоев изоляции). Главное — что выдается структурное исключение, а не signal.
Отвечая на вопрос про __finally. Боюсь, что это расширение языка ввели для того, чтобы «комфортно» писать на С++ под .NET.
В конце концов — if, switch, while, do — необязательны. Все можно написать с использованием одного for. Но неудобно же!
А конкретная ситуация — «открыть А, открыть Б,… чтобы ни случилось — закрыть А, закрыть Б». То в RAll мы имеем пересечение времен жизни ресурсов. Извратиться — можно (как и с for). Но лучше — не извращаться.
Ещё ситуация — когда какой-то деструктор при некоторых условиях надо не выполнять. «открыть А, открыть Б,… чтобы ни случилось — закрыть А, если давления нет — закрыть Б, а если есть — не закрывать».
Чувствуете как это неудобно ложиться на RAll? И такого — навалом.
MSDN пишет так:
Оператор try-finally особенно полезен для подпрограмм, в которых в нескольких местах выполняется проверка на наличие ошибок, способных вызвать преждевременное возвращение из подпрограммы.
Ну и последнее, о чем уже писали. RAll плох тем, что ошибка в деструкторе вызывает std::terminate. finally избавлен от этого фатального недостатка.
А до него уже семь лет назад было.
А проект уже проработал 15 лет.
Только если ошибка возникает уже при раскрутке стека.
Угу, но шансы, что она возникнет — приличные. То есть свои деструкторы можно написать так, чтобы выполнялись всегда и везде. А вот библиотечные (особенно STL) — упадут со свистом.
P.S. В смыcле вторичного AV. Пояснения нужны?
А то такое впечатление, что вы тоже боитесь, что самолет на голову упадет.
Почти в каждом случае рано или поздно программа либо сегфолтилась, либо входила в дедлок из-за нарушения инвариантов.
То есть ни одного незамеченного искажения данных не было? Даже несмотря на то, что специально не боролись?
Ну так после AV — просто проверяете данные. По инвариантам, по второй копии. Зачем бояться того, что не бывает?
Было. assert'ы через строку, если сработало — надо падать вот прям щас.
Почти в каждом случае рано или поздно программа либо сегфолтилась, либо входила в дедлок из-за нарушения инвариантов.
Вам не кажется, что это взаимоисключающие параграфы?
Когда размер хипа процесса достигает двухста гигов,
Гениально! Взять особенности своей задачи и потребовать, что я дизайнил совсем иную задачу ровно так, как вашу. :-))
У нас все лезло в 20 мегов. И размер того, что важно — меньше 64К, типично 1-2К.
Отличается-то оно не сильно: если на выходе комплекса лажа, то некоторое количество важных шишек будет сильно недовольно.Давайте сравним это с гибелью людей. Ну вот девочка погибла из-за нажатия на кнопку не по инструкции.
Зато объемы данных — копеечные. 10 тысяч битов (2 килобайта) — это гигантский объем. Это 10 тысяч датчиков, каждый из которых может сломаться. Обычный объем идет на сотни битов.
Ассертами оно стало обкладываться уже после того, как я пришёл в проект. Ну и даже ассерты через строку не от всего спасают.
Мой совет — закрывайте каждый баг минимум трижды. При каждом баге задайте себе вопросы:
- Что можно сделать, чтобы программа работала после этого бага? Какую деградацию применить? Какое восстановление?
- Как обнаружить этот баг поближе к точке возникновения? Как обнаружить всю серию подобных багов?
- По какой причине произошел этот баг? В каких местах кода могла произойти такая же ошибка?
Ещё очень помогает 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 сделать логгирование, удобно поставить точку отладки, проверку диапазона, точку останова на конкретное значение (это будет быстрее, чем аналогичная ыункция в отладчике, т.к. та вычисляется на лету и медленно).
Ну что же поделитесь решением 2004ого года. Задача такая — заменить поле объекта на две функции (get/set) так, Чтобы использующий код этого не заметил… Ну разве что адрес такого поля будет не получить.
Мы при отладке не только ушами, но и хвостом готовы финты рисовать. Лишь бы был метод, находящий ошибку за заранее известное время.
Поле — публично видимая переменная? С учётом невзятия адреса вообще просто получается: пишется шаблонный класс с шаблонным (или нешаблонным, зависит) operator= от нужного типа и с переопределённым оператором приведения к этому типу.
printf поломается. И поменяется приоритет при определении правильного перегруженного метода. А еще вывод типов в шаблонах сломается...
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 слишком тяжел для этого. А вот предложенный мной метод с записью значений в одном треде — вполне годится.
Проперти в плюсах я делал в бородатом 2004-м году будучи школьником.
Только что в чужом коде, скорее всего, этих пропертей не будет нигде.
Для начала — давайте не путать AV с порчей памяти. Большинство AV — это отсутствие проверки на NULL. Специально для этого мы глобально закрыли use after free при помощи FreeAndNil.
За отсутствием проверки на NULL следует либо порча памяти, либо чтение неверных данных, либо AV.
FreeAndNil, внезапно, не обязательно защищает от use after free — он обнуляет только одну ссылку на объект, а не все, которые есть.
Имхо, проблемы с NULL — следствие избыточного использования NULL. В нормально написанных системах таких проблем не возникает, а в ненормально написанных — быдлокодеры плюются от NPE.
struct p {
char padding[0x7fffffff];
int data;
};
p *ptr = nullptr;
int data = ptr->data;
Ещё попытки будут? :-)
а вы попадите операцией записи в выделенную страницу с данными (желательно какой-нибудь древовидной структуры), намучаетесь потом с отладкой. "либо порча памяти, либо чтение неверных данных, либо AV".
Не, не сумею я туда попасть. В usersace в винде отмапленное адресное пространство начинается с 4 мегов. А у меня на все приложение — 20 мегов уходит. Ну где я вам
Выдумывайте дальше.
20 мегов уходит
А, ну ок. Как будет уходить 2000 мегов — практика развеет ваши иллюзии.
Если бы, да кабы, да во рту росли грибы, то это было бы другое приложение, на другом железе и писалось бы оно иначе.
P.S. 256мегов на тех серверах было. Физических.
3gb флагу меня с ним начало «глючить» всё подряд ещё до запуска собственно ПО
P.S. xdelta3 32bit-ная — потолок уже на 1.7Gb
P.P.S. 1.7Gb — с первого взгляда, «потолок» для очень многого
/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 назад
Как пример — в другой команде был сделан полнотекстовый поиск по упакованным данным без их распаковки. Данные паковались по словарю, и можно было вычислить, какие гнезда могут быть в совпадающем с запросом месте. Плюс запрос компилировался в машинный код на лету. Ускорение — в десяток раз.
Это 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, числом серверовЗависит от цели. Если цель — иметь как можно больше покупателей, то снижаем цену железа. Если покупатель один, то снижаем общую цену разработки. А программисты — подороже железа будут.
Ну там резиденты можно было использовать. Мог ли код резидента выполняться параллельно чтению с диска — уже и не помню Ж-)MS-DOSисполнять код во время движения головки дискаOS без многозадачности?
Грубо говоря, в идеале перед стартом чтения с диска хотелось задать процедуру, которая будет периодически вызваться во время ожидания позиционирования головки.
Проблема была в том, что был ещё коробочный продукт на той же кодовой базе -классификатор предприятий СССР с базой 80Мегабайт на диске. А он должен был запускать на любой машине.
Потому и библиотечную базу (которую мы ставили на железо сами) не переводили под DOS-extender с многозадачностью.
В иных задачах — процессор занимался ещё меньше.
Самый лучший ехтендер был из обрубленной до консоли OS/2. :-)
В OS/2 мне больше всего понравилась эмуляция устройств внутри DOS сессии. Это была единственная из доступных ОС, которая эмулировала DOS вместе с графикой, последовательными портами, корректно все это поддерживая.
Win95 это дело не эмулировала, а использовала. Там даже многозадачность отключалась при форматировании дискеты чтобы возможные досовские резиденты не поломались.
Win95 оптимизировалась на эмуляцию реально существующих программ на стандартном железе. И в этом, собственно, дошла до совершенства — десятки хаков под отдельные игры.
А вот эмуляция нестандартного железа видимо просто не была одной из целей.
В OS/2 мне больше всего понравилась эмуляция устройств внутри DOS сессии. Это была единственная из доступных ОС, которая эмулировала DOS вместе с графикой, последовательными портами, корректно все это поддерживая.
столкнулся с практической задачей — запустить на новом железе DOS программу, которая работает с графикой и нестандартными COM портами.
COM порты для DOS программ отлично работали и в NT 3.51
Как мне рассказали ( я сам видел «в деле» уже NT 4.0)
надо было запустить 4 экземпляра ПО для приёма-передачи файлов по модему.
( Не FIDO, версия ПО с 4 портами стоила дороже)
Так вот, очень много многозадачных оболочек над DOS,
но в них просто не заработало как надо ( или совсем)
Участвовал ли OS/2 — не спросил в своё время
Но т.к. в FIDO проявил себя хорошо, то, думаю, справился бы
Очевидный пример:
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.
а вот если сконвертировать исходный текст C2Ada.
Но уж если это делать по-честному, и 0 на Nil ( ну или Null) заменить... Скорее всего — уже в Runtime
Слабо проверить до поста на хабр?
P.S. я ошибся, с 4 мегов данные, с 1.3 мегабайта — растущий вниз стек.
Ваш пример с девочкой как раз аргумент против подхода "восстановление после AV". Потому что девочка погибла именно в следствии такого вот восстановления не глядя...
Собственно вот показания программиста:
На 4 странице распечатки в 19.41.09 диспетчер нажата кнопку – сброс состояния, чтобы убрать ошибки, которые на лифте.
Ровно затем и делают обработку, чтобы не потерять признаки аварии и вернуть все в безопасное положение. В случае лифта — это значит обесточить все при любом вылете или зависе программы управления.
Реакция на аварию — это установить признак аварии, установить исполнительные механизмы в безопасное положение, выключиться.
А вы предлагаете после обработки продолжить работу. Ровно то, что сделал диспетчер.
Реакция на аварию — это установить признак аварии, установить исполнительные механизмы в безопасное положение, выключиться.
Это, мягко говоря, сильно зависит от объекта управления.
Работа по AV по нашей схеме безопасна. Вот смотрите варианты порчи памяти:
- Испорчена память, AV не происходит
- Испорчена память, AV происходит однократно
- Испорчена память, AV многократный
Если вы страхуетесь от ситуации 1, то в чем разница между 1 и 2? У вас все равно программа может записать испорченные данные. Если же вы застраховались от 1, то вы застраховались и от 2.
А в ситуации 3 восстановление просто не поможет. Даже без контроля по времени вы все равно выйдете на самый верхний уровень обработки исключений и программа завершится или зависнет. Но контроль по времени у нас есть.
Если вы так боитесь порчи памяти — то помните, что ситуация 1 — это просто выход за границу массива. Это просто лишний инкремент указателя. И много-много что. Это самая частая ситуация.
Вторая по частоте — это ситуация 3. К ней относится запись в нулевой (в Дельфи) или -1ый (в Си) элемент динамического массива. В этом случае рушится структура кучи. А кучу при рекомендуется контролировать при каждом AV.
А ситуация 2 — это экзотика. Вживую не видел. Если она у вас встречалась — то расскажите, как вас угораздило.
Самая частая порча памяти — в стеке. Ошиблись индексом — и вышли за пределы массива. Что у нас в стеке в дельфи? Ничего важного. Объектов там нет. указатель на место передачи исключения — берется через регистр. Ссылка на следующий блок ловли исключения — в стеке. Самое ценное, что есть — это адрес возврата. Но даже если его потерли — не страшно, будет исключение и переход по адресу обработки исключения (из регистра). Даже указатели в стеке сидят редко.
А теперь взглянем, что у нас в Си. А в Си у нас в стеке — объекты Rall. Потерли мы стек или нет — а их деструкторы должны исполняться. А как им выполнится, если стек потерт? А ещё в стеке — указатели. И их много. Часть — от оптимизации, часть — ну такой уж стиль Си, что в нем локальных указателей много.
Так что опасения сишников, что память разрушится -вполне понятны. Угу, в си так и будет.
Как ни странно, Дельфи выигрывает за счет своей недообъектной модели и недооптимизации.
И ещё раз. RAll не заменять try..finally. EXCEPTION_REGISTRATION намного лучше защищен от порчи стека, чем RAll.
Только если ошибка возникает уже при раскрутке стека.Нет. Начиная с с++11 деструкторы неявно помечаются как noexcept в случае, если дефолтный деструктор был бы noexcept (то есть, почти всегда). А исключение из noexcept метода — сразу terminate
По поводу ситуации с применением __try...__finally отвечу цитатой здешнего жителя (увы! На память не помню его ника):
«Если вы собираетесь писать программы для Windows, читайте Рихтера.
Если вы ничего не поняли из прочитанного, перечитайте Рихтера.» (ц)
Рекомендую прочитать Рихтера, в его книге этой конструкции, __try...__finally (а также SEH и в чем отличие try...catch от __try...__finally), посвящена отдельная глава
Вот как раз системные дескрипторы — кандидат номер 1 для заворачивания в классы!
И да, реализация finally через выполнение кода в деструкторе плоха тем, что при возникновения исключения могут быть проблемы.
В С++ конструкция try...finlaly? Учите матчасть, её там нет. Есть лишь в борландовом (дельфийском) расширении.msdn.microsoft.com/en-us/library/9xtt5hxz.aspx
Главное — что нету ни в стандарте, ни в gcc/clang.
Кто и на каком основании вписал в рувики 1990, я не знаю.
__finally
уже было.Когда, говорите, оно появилось у Борланда?
Главное — что выдается структурное исключение, а не signal.Даже если и сигнал, всё ничего похожего на «access violation фатален и приводит к немедленному завершению программы», о чём вы утверждали выше.
Вы лучше найдите хоть одну программу на С++, где процесс выживает после access vioaltion. На delphi — все GUI-программы такие, ибо так устроен фреймворк. Хром не предлагать — у него процесс завершается после access vioaltion. Просто архитектура многопроцесная.
Я думаю, что Delphi себе это может позволить за счёт узкого круга поддерживаемых платформ. Но требование, чтобы аппаратное исключение преобразовывалось в исключение языка, не получится включить в стандарт и при этом не пожертвовать кроссплатформенностью, потому что в общем случае платформа вообще не обязана вам давать какие-то аппаратные исключения. Разыменование нулевого указателя на какой-то платформе выльется в access violation, а у другой платформы в те адреса память отображается, и вообще у неё никакого MPU нет.
у другой платформы в те адреса память отображается, и вообще у неё никакого 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 проекта взяли в «платный» Delphi ( вполне официально, ещё и пожертвование от фирмы внесли)
В случае с Делфи этого нет. Поведение программы полностью обусловлено поведением компилятора. Если компилятор сгенерировал именно такой машинный код — значит это и будет правильным поведением программы. Иными словами, любой код который выдает компилятор — считается правильным.
Мне можете не рассказывать — мой код работает на 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++.
с трудностями переноса я знакомВ ADA мире очень плотно занимались стандартизацией, как раз, для переноса ПО на разное железо...
Правильности в смысле соответствия стандарту мало. Надо ещё очень многое учесть.
А написать на переносимом подмножестве — можно на почти любом языке. Исключение разве что APL — там набор символов специфичный.
Не говоря о том, что Object Pascal вообще-то был придуман в Apple.
где-то формально описаны правила языкаНа Pascal есть ISO стандарт
Проблема в одном — Delphi, действительно, не чистый Паскаль
В Free Pascal есть штук 5 разновидностей опции компилятора ( или даже несколько семейств опций)
какому из Borland диалектов соответствовать
Т.е. на практике TP изучен вдоль и поперёк разработчиками компиляторов
скорость 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
Для большинства языков access violation фатален и приводит к немедленному завершению программы. А на delphi — это всего лишь аппаратный exception, который можно обработать. К этому добавляются удобные конструкции try..finally и try..except.
Ээ, што?
Назовите хотя бы один язык, где «access violation фатален и приводит к немедленному завершению программы».
Как пример. Имеем сложное представление данных в памяти в виде стрeктур с указателями. И просто плоское представление, в которое иногда, со всеми предосторожностями сохраняем. Если мы сломали структуры — то получаем исключение и пересоздаем структуры из плоского представления.
Я понимаю, что мир намного шире, чем стандарт. Поэтому большинство ОС позволяют приложениям перехватывать такие ошибки. Но на самом деле это не так уж и важно. Если вы упали с segfault — значит вы где-то ошиблись. Считайте, что segfault — это такой аппаратный assert. Что-то пошло не так, состояние программы больше не консистентно, лучше завалиться сейчас, чем наделать бед в будущем.
Собственно, поэтому и падает Word в вашем примере. Не то что бы он не мог захендлить это исключение и убить глючный модель проверки правописания. Но где гарантия, что ошибка в этом модуле не повредила память в другом месте? И это особенно важно для всяких энтерпрайз штук, типа CRM. Если где-то произошла ошибка такого уровня — лучше упасть, чем надеяться что состояние приложения осталось консистентым.
Ваш пример со структурами интересен, но куда логичнее проверять указатель на NULL, если он может быть NULL, а не надеятся на MMU и OS.
В интерактивных программах надо давать контроль над такими ситуациями пользователю. Это должен быть его выбор — сразу закрыть программу или попытаться спасти данные.
Просто вы ожидаете слишком большой компетентности от пользователя. Ему надо донести что данные уже возможно повреждены. И что не надо, например, перезаписывать поверх оригинальный документ. И что повреждения могут быть незаметными на первый взгляд. Например, пользователь сохраняет документ под новым именем, перезапускает программу, открывает документ и видит что всё вроде хорошо. А потом через месяц у него не сходится годовой отчет. Кто виноват? Программист, конечно.
Ну например, если падает некоторый плагин, пользователю надо дать возможность его отключить. Особенно если плагин падает при старте программы.
Но если плагин — это либа написанная на С++ — он может повредить не только свои данные, но и любую память. Поэтому да, вы можете убить плагин. Но у вас нет гарантий, что он перед смертью не повредил состояние вашей программы.
Но и гарантий обратного тоже нет!
Вы почему-то исходите из того что неправильная программа неправильна всюду. Но это же не так. Каждая ошибка при работе с указателями либо вызывает AV либо повреждает память. Причем ошибка вызвавшая AV память не повреждает!
Таким образом, ситуация "получили AV и повредили память" возможна только если ошибок оказалось минимум две (вторая может быть следствием первой). А вероятность такого события меньше чем вероятность просто единичной ошибки.
Когда я был студентом, мне дали какую-то программу чтобы делать в ней лабы, не помню уже что она делала. Так вот: при запуске она каждый раз выдавала окошко с надписью "Access violation", после чего продолжала работу. Был бы я как пользователь этой программы более счастлив если бы программа берегла меня от непредсказуемого повреждения памяти и завершала свою работу?
Вы почему-то исходите из того что неправильная программа неправильна всюду. Но это же не так. Каждая ошибка при работе с указателями либо вызывает AV либо повреждает память. Причем ошибка вызвавшая AV память не повреждает!
Я не раз сталкивался с ошибками, когда один код повреждает структуру, (например записывает нули не в свою память), а потом другой код обращается к этой структуре и падает. Это ровно одна ошибка, которая сначала приводит к повреждению данных, а потом — к падению с SIGSEGV.
Таким образом, ситуация «получили AV и повредили память» возможна только если ошибок оказалось минимум две (вторая может быть следствием первой). А вероятность такого события меньше чем вероятность просто единичной ошибки.
Как я уже сказал — достаточно одной ошибки (например use after free()). И на практике я с таким сталкивался не раз.
Когда я был студентом, мне дали какую-то программу чтобы делать в ней лабы, не помню уже что она делала. Так вот: при запуске она каждый раз выдавала окошко с надписью «Access violation», после чего продолжала работу. Был бы я как пользователь этой программы более счастлив если бы программа берегла меня от непредсказуемого повреждения памяти и завершала свою работу?
Если бы она сразу падала — то автор исправил бы ошибку. А так «Ну подумаешь выводит Access Violation. Работает же!». Я тоже когда-то был студентом и тоже забивал на такие ошибки. Но это неправильно. Было бы лучше, если бы язык сразу бил бы линейкой по рукам.
Если бы она сразу падала — то автор исправил бы ошибку.
Ха-ха-ха. Я думаю, у автора все работало.
Вы наверное шутите. От чего меня спасет защита данных при помощи CRC? Вы можете привести пример такой защиты данных?
Это ровно одна ошибка, которая сначала приводит к повреждению данных, а потом — к падению с SIGSEGV.
Вот чтобы проверить, затронула ли эта ошибка область важных данных и нужен CRC.
Альтернатива — ежесекундный сброс на диск. Но это хуже.
Сейчас при сбое пользователь теряет 10-15 минут работы. Делаем автосохранение раз в секунду, но не на диск, а в память. Причем не в кучу, а отдельно запрашиваем страницы памяти у ОС. И защищаем эту память при помощи CRC.
При сбое — получаем потерю лишь последней секунды. Мы или сбрасываем эту область на диск или прозрачно перезапускаемся сами и читаем из неё.
Да, последняя секунда теряется, но это меньше чем 10-15 минут работы.
Ели вы перфекционист, то за последнюю секунду сохраняете ещё и сообщения мыши и клавиатуры. Тоже в отдельную область и тоже с защитой.
А уведомить пользователя о сбое — разумеется, надо.
Как вы собираетесь это контролировать в многопоточной программе?
Как собираюсь — неинтересно. Как оно контролируется в реальной программе — ну допишу пост, там будет рассказ. Там порядка 20 тредов работало.
Опыт показал, что дельфи — это не С++. И порча памяти — зверь редкостный.
Главный принцип — любая ошибка закрывается минимум трижды:
- отлаживается восстановление
- ставится assert обнаружение (в Delphi assert вызывает исключение, а не завершение программы)
- только после этого правится сама ошибка. Иногда — дважды: и в вызывающем и вызываемом коде.
Ну да, дороговато. Зато быстрее, чем отладка вообще всех багов.
Что если ошибка привела к порче не документа, а к порче настроек, например? И ворд, согласно новым настройкам продолжить портить документ? Или даже не ворд, а какой-нибудь третий плагин.
Но по срокам разработки (при вышеупомятых требованиях) вы дельфистам уступите примерно геологическую эпоху.
У дельфи колоссальное преимущество в скорости компиляции и сборки, качестве информации об ошибках от компилятора, минимальном количестве неопределенного поведения.
Ну да, для ворда придется немного потрудится. Но главное — на дельфи это возможно. А на С++ — нет.
Что если ошибка привела к порче не документа, а к порче настроек, например?
Тру-ля-ля… Ворд все важные настройки сохраняет в документе.
Вы сравните ситуации:
- Ваша. Идет сбой, появляется сообщение о сбое, пользователь остается с документом 10минутной давности и руками перезапускает word.
- Моя. Идет сбой, появляется сообщение о сбое, пользователя остается с документом 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.
Зато в С++ много своих достоинств, которых нет в других языках. Тот же макропроцессор + шаблоны.
Ну не одинаковые языки, не одинаковые.
Но тут уже привели пример, что можно выкинуть исключение из обработчика SIGABRT.
Часть проблем это решает. Но не все. Проблема деструкторов в локальных объектах библиотечных функций остается.
#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;
}
handled by signal
#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;
}
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. Было бы полезней, если бы вы были правы, но увы.
P.S ваш «исправленный код с fpe тоже ловится SEH exception просто нужно не EXCEPTION_INT_OVERFLOW(с которым я налажал да) а EXCEPTION_INT_DIVIDE_BY_ZERO
- Сигналы работают везде, где ОС дает такую возможность. И в Windows и в POSIX и где угодно.
- На Windows в двух компиляторах из четырех (только VS++ и BCB) есть более удобная конструкция __except.
- Эта конструкция работает так, что на локальной области позволяет перекрыть сигналы. При выходе из области — опять будут работать сигналы.
Что вам не нравится в этой схеме?
Вопрос в том, зачем библиотеке это делать? Есть идеи, зачем писать (и использовать) библиотеки только для 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. " Вот и ответ на ваш вопрос
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%? И как вы будете определять, что не восстановились и надо падать, если в этом 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 — это аргумент в споре.
В системном вызове программа упасть не может, потому что не исполняется.
Да ну? Вполне себе падает в юзерспейсе. Во-первых часть вызовов вообще не идет в kernel space, во вторых ещё часть перед и после вызова ядра проходят обработку в библиотеке. например, у нас летел CharToOemBuff из user32.dll. Вполне себе системный вызов из WINAPI. Там, кажется, нужно было выравнивание на четырехбайтовую границу, о чем в документации не написано.
Нет, это же вы предложили делать dereference потенциально нулевого указателя. Я предлагаю проверять такие указатели перед разыменованием.
Откуда вы этот бред взяли? Проверять — надо. Но это не отменяет AV. Бывает все, что угодно, вплоть до сбоев памяти и процессора. Эффектов очень много, например — гонка.
Более того, существуют десятки языков, которые просто не позволят вам допустить Access violation, если вы ими правильно пользуетесь.
Приведите хоть один пример такого языка. Примеры AV в java, c# и kotlin я уже приводил.
Я за свою жизнь успел и поуправлять термопринтером на низком уровне
Тогда странно, что:
- Вы считаете, что любую программу можно отладить до уровня ни одного AV за 100 лет.
- Вы не понимаете, что причиной AV может быть перегрев, импульсная помеха по питанию, радиоактивный источник, сдыхающий процессор, трещина в плате и вообще черти что.
- Вы не цените механизм, позволяющий свести ущерб от 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 видели? А сдохший конденсатор, из-за которого бит С менял значение там, где не должен был?
Ну и catch без finally неудобен. А finally — есть только в дельфийском С++. Ну и ещё в VC++, вроде. Опять gcc/clang в пролете.
Собственно неудобства:
- Приходится писать объект с пустым конструктором только ради отработки деструктора.
- Деструктор пишется совем в другом месье кода, чем исполняется. В итоге алгоритм расползается по куче частей (деструтор, создание объекта, вызов дестурктора).
- Чтобы поменять местами порядок в finally, приходится менять местами создание объектов.
- Finally вставляется явно и делает только то, что явно написано. Деструкторы отрабатывают всегда все. То есть, если не нужна отработка дестурктора при исключении — приходится изворачиваться. А специфика access violation в том, что деструкторы многих вещей скорее выдадут вторичное исключение, чем сделают нечто полезное.
P.S. Не стоит спорить о вкусе устриц с теми, кто их ел. Напишите свое отказоустойчивое приложение и запустите его в режиме 365*24. Тогда многое вам увидится совсем в другом свете.
Finally на лямбде можно сделать, если вам надо. Единственный минус, который я вижу — это то что блок finally будет перед try...catch. Все пункты, которые вы привели, вроде бы адресованы.
Почему не исправит? Тот finally из ссылки как раз вставляется явно и делает то, что вы в теле лямбды написали.
Синтаксис — вопрос вкуса; во всяком случае кода в месте использования получается ненамного больше чем если бы finally был нативный. В любом случае, мы уже перешли из области "надо но нет" в область "есть но [мне] неудобно", об этом уже мало смысла спорить.
Итог — придется переписать значительную часть библиотечного кода. Ибо одно дело — при ошибке закрыть все клапаны и заново создать все нужные структуры. Другое — когда у нас выполняются все деструкторы с черт знает каким побочным эффектом. И, как уже написали, вторичная ошибка в деструкторе вызовет 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.
То, что критично — скорее всего на АДА, то есть на развитии того же паскаля/дельфи.
У Си/C++ есть преимущества для baremetal: переносимость, накопленная кодовая база, распространенность (доступность девелоперов), малое использование ОЗУ.
Ровно те же преимущества были у фортрана.
А повторит ли C/С++ судьбу фортрана и PL/1 — увидим через 30 лет.
на каких языках пишуется бортовые системы самолётов?
Боинг — на ADA, ИЛ-96 ( по слухам) — тоже
P.S. На Си, говорят, тоже можно
надо только макрос «eq» завести
и в if-ах сперва цифру потом eq потом переменную
P.P.S. И что только не придумывают «только бы не строить дороги» Ж-)
P.P.P.S. Ми-6 + Ми-26 Ж-)
Вы так пишите как будто __finally как-то блокирует выполнение библиотечных деструкторов :-)
Это ещё одна причина, почему системы 365*24 лучше писать на дельфи.
Деструкторы COM-объектов в Delphi вызываются в том числе и неявно.
Кстати, в С++ возможность отключить автоматический вызов деструктора тоже есть. Надо всего-то поставить звездочку и написать new.
А еще при желании можно сделать обертку, которая будет блокировать освобождение памяти в случае AV.
А все вместе, включая недоООП, позволяет прощать ошибки проектирования. То есть вместо «Шэф, мы без рефакторинга жить уже не можем», будет «Ну да, чуть некрасиво, но работает же!».
Вы забыли главное отличие. Для finally допустимо выкидывать свои исключения. Это хоть и считается плохим тоном — но не убивает программу. А вот исключение из деструктора вызывает std::terminate();
Все остальные отличия — просто дело привычки.
Все остальные отличия — просто дело привычки.
Так-то оно так. Подходы вида finally и RAII уж очень различаются, и в ряде случаев finally просто легче читается. Ну скажем, простой пример — нам надо закрыть соединение в конце работы. В одном случае мы можем это сделать напрямую, в другом надо создавать отдельный объект, непосредственно контроллирующий это соединение и закрывающий его при автоматическом уничтожении.
Здорово иметь возможность комбинировать оба подхода.
Выделения такого объекта требует не только принцип RAII, но и базовые принципы ООП. И приличные библиотеки такой объект предоставляют.
Деструктор пишется совем в другом месье кода, чем исполняется. В итоге алгоритм расползается по куче частей (деструтор, создание объекта, вызов дестурктора).
И это говорит адепт языка, в котором переменные нужно объявлять за километр от того места, где они впервые используются?
А почему адепт? Последние лет 10 я пишу на Си. У него тоже есть свои преимущества. Просто систему 365*24 лучше писать на дельфи. А переносимый код или embeded — на Си.
Не знаю, почему так. Возможно описание переменных воспринимается как данные. В конце концов в си параметры тоже описывают в заголовке функции и это ни у кого проблем не вызывает.
переменные нужно объявлять за километр от того места, где они впервые используютсяЕсли нужны «блоки» — возьмите ADA.
В Pascal, кстати, есть вложенные процедуры ( в Си — нет) тоже может помочь
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.
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.
А вот на каких-то платформах это может выливаться в segmentation fault.
У современных языков вылетает программная ошибка на уровне виртуальной машины, которая вполне себе обрабатывается. А говорить что потеряются данные от Access Violation везде кроме Dalphi — так от синего экрана они потеряются даже в делфи. Вот только для программиста Java синий экран наступит скорее, чем access violation.
Так что это какая-то надуманная проблема из серии "наша технология решает проблему Х… Ой, мы забыли сказать, что эта проблема есть только в нашей технологии".
Что касается устойчивости серверов — кластеры и только. Ну, можно Erlang — для любителей — но всё равно на кластере. Прямолинейный Паскаль для устойчивости подходит ничуть не лучше чем Питон.
Что касается виртуальных машин — они не защищают от access violation из-за бага в самой виртуальной машине. Вот вам access violation в java, а вот он же в С#, а вот он же в Kotlin.
В каком ещё языке якобы не бывает access violation?
А обрабатывать это все — по хорошему-то надо.
Только комплексная многоуровневая защита дает надежность.
Не забывайте, что к финансовым (да и людским) потерям больше всего приводит падение программы. Так что даже если и решили упасть — все равно надо выходы в безопасное состояние переключить. Причем безопасное состояние не «вообще», а для конкретной операции.
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.
- Мгновенная сборка проекта.
- Простота поиска и устранения утечек памяти.
- Простота оптимизации производительности.
- Нативное приложение без зависимостей на выходе.
- Способность работать и не жужжать на любом ПК заказчика.
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 секунд — достаточно быстро?
Во-вторых, скорость зависит от связностей модулей. 27 секунд — это самый медленный из проектов, второй собирается на моей машине (1.8 млн строк) за 13 секунд.
В-третьих я имею в виду, разумеется, полный rebuild. Так, на всякий случай. Ну и D7, старичок уже.
Видео (не моё :) ):
www.youtube.com/watch?v=Yq2mNUzcpE0
Посмотрите комментарии, там более прозаичные цифры, похожие на мои. Ну и да, 7ка же. Плюс модулей у меня под 2500. Но все равно, как ни крути, эти 13 и даже 27 секунд — это быстро по сравнению с сами знаете чем.
Скажем так — единицы секунд на миллион строк. Такой порядок. Медленнее — уже медленно. Я для ардуины кусочки писал, 30 секунд на компиляцию 50ти строк кода — это ад :)
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 модуль ни о чем.
Вопрос удобства.
Я не говорю, что это прям вот самое главное, нет. Но приятно.
Простота поиска и устранения утечек памяти.
Ха-ха.
Способность работать и не жужжать на любом ПК заказчика.
Если это правда — то откуда изо всех щелей лезут рекомендации ставить Delphi на компьютер заказчика?
Ха-ха.
Именно так.
Если это правда — то откуда изо всех щелей лезут рекомендации ставить Delphi на компьютер заказчика?
Пруфлинк на "все щели"? Мне вот как-то ни разу не довелось.
Я, конечно, давно не тыкал палочкой это вот всё, но… это какие-то неправильные рекомендации :)
Ха-ха.
Абсолютно.
Eureka + FastMM с полным MemLeakReport и все, с точностью до строчки.
Если это правда — то откуда изо всех щелей лезут рекомендации ставить Delphi на компьютер заказчика?
От отсутствия навыков. Ведь на каждом углу все кричат, что у дельфей низкий порог вхождения. Вот и результат, но это не норма.
Ха-ха.
А что хаха? Эврикалог, FastMM, MadExcpeption, JCL exception дадут место утечки и исключения до строчки + колл-стэки и еще кучу информации.
то откуда изо всех щелей лезут рекомендации ставить Delphi на компьютер заказчика?
Где такие, аж из всех щелей? :) Ни разу по форумам за 15 лет не видел. Инструменты я назвал, самые распространенные. Смысл Делфи где-то ставить?
Ну область такая, что иногда проще резистор припаять, чем пару строчек кода написать
Занёс себе в цитатник
Де-факто, высокоуровневые резисторы припаивал Ж-)
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. Правда, по слухам, срочное погружение, пока ПО не заработает Ж-)
Если не боитесь с военкой работать — говорите город, скажу что там пишется.
«Улыбнуло» — нет мол жизни Ж-) вне столиц
Вообще форму вам без вашего ведома и подписи присвоить не могут по идее, так что внезапно носителем тайны вы не станете. Но да, если проект секретный на голову свалится, то работа встанет — либо форму, либо уходить. Вообще вариантов много, но если не хочется связываться, то это вполне себе объяснимо.
Если вам стал известен секрет — это целиком и полностью вина того, кто его разгласил, всё остальное уже вне сферы закона, насколько я понимаю (если кто знает точнее, пусть поправит). Это не законное основание заставлять вас что-то подписывать.
Сдаюсь! Сдаюсь! :) Честное слово, я не хочу спорить о том, что за пределами правового поля, я просто говорю, что такие вещи не должны быть законными. Я понимаю, что законы у нас вертят как хотят, такая у нас жизнь. Поэтому и говорю, что если не хочется связываться, то это вполне достойная причина не идти работать на оборонку, не хуже любой другой — тут уж каждый сам для себя выбирает, стоит риск того или нет.
с тем же ураномбыла забавная история: как только публикации в научных журналах внезапно перестали появляться,
как физики-теоретики стали слать прямо из окопов Сталинграда письма верховному главнокомандующему: началось, мол
например, известную систему SAP
Поверьте, SAP, мягко говоря, далёк от эталона «крутого бизнес-софта».
Да, уже лет "-дцать" Ж-) всё умирает и умирает...
А новые версии среды разработки выходят, Q&A на форумах вовсю Ж-),
ещё и вакансии есть
А cobol умирает или нет? Просто вам стоит привыкнуть к тому, что языки программирования умирают оооооочень долго. Взгляните на python2, который топят всеми силами.
Можно почитать почему Cobol не умрёт
P.S.
Вы то предлагаете переписать проект автора статьи целиком, то наоборот Ж-)
Я, мягко говоря, не уверен, что хорошо «для планеты»
когда на языках «европейской школы» «пишут все меньше новых проектов»
Когда в МГУ уменьшают часы на изучения ADA в пользу Cи
Результат предсказанный Э.Дейкстра ( вреда от Си, в следующие сорок лет, будет не меньше чем от Fortran в передыдущие) вижу каждый день в виде бесконечных hotfixes к ОС и ПО
( Для любителей Си есть практически ценная задача:
«подлакировать» исходные коды xdelta3 под Win x64 )
Плюс многие «фокусы» в Си перекочевали из Algol-68
Особенно впечатлила программа строк на 12 на Алголе с подписью:
«ни одна строка не работает так, как вы подумали, бегло прочитав код»
Но самое главное, что Си и не думают развивать в нужном направлении.
Например, модули не попадают в стандарт языка уже как несколько итераций
А нужное мне направление — это структурная обработка аппаратных исключений. А не через сигналы и longjump. Думаю, что ещё лет 50 подождать придется.
(
Си рассматривался в моих сообщениях, в основном,
как наследник Алгол по любви к фокусам Ж-)
)
Влияние, как минимум, как предшественника по времени
Но Алгол-68 создавали как общемировой стандарт, всем миром
а он ( мир «компьютерщиков») исчислялся хорошо если тысячами,
а не как теперь миллионами,
поэтому не исключено, что влиял непосредственно Ж-)
C — он же развитие языка B Ж-)
Хотя: дурацкие ";" от которых сейчас избавляются ( например в Go)
в Алголе означали «выполнить последовательно»,
а запятые — «параллельно» ( т.е. точки с запятыми — имели смысл)
Как видим, весьма «молодёжная» идея даже сегодня
( Это, кстати, было в одной из 12 строк как «подводный камень»)
Вижу влияние ассемблера 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 похожий Ж-)
А языки "европейской школы" магическим образом избавляют нас от логических ошибок?
вижу каждый день в виде бесконечных 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? Если мне не хватает времени на тесты, мне так же будет не хватать времени на такие комментарии.
К идее «просто протестировать» ПО претензии классические:
да 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? Берутся случайные значения из промежутка?
Sorry: эти страницы закрыл, иначе опубликовал бы и ссылки, но в ddg.gg минут за 15 нашёлP.S. Где-то читал, что на Хабре URL «во вне» не приветствуется,Вроде должно быть нормально с этим…
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 числа)
— скажем так, трудоемко и требует циклов с отладкой
Кстати, вот в этом случае, не уверен что
«европейская школа» «сработала» бы лучше:
там и на самом деле нужен стиль работы
как в «высокоуровневом ассемблере»
А языки «европейской школы» магическим образом избавляют нас от логических ошибок?
Хотя бы большей смысловых избавляют — уже хлеб.
Современная среда разработки Delphi отнюдь не вымершая. Очень бурно развивается в последнее время, каждый год, а то и по два раза в год выходят новые версии с новыми фичами и поддержкой самых современных технологий. И действительно, огромное количество современных мировых производителей используют именно Delphi для разработки своих продуктов. Мир многообразен, в нем всегда найдется ниша и для Delphi, и для C#, C++ и других сред разработки. А иногда даже для всех вместе в одном проекте.
Нормально всё у Delphi. Новые версии каждый год выходят, native поддержка Windows отличная, кроссплатформенная — средняя, но тем не менее она есть. Мы тоже серьезные коммерческие проекты пишем на Delphi (2 проекта от 500 тыс до миллиона строк кода). Проектам 10 и более лет, продаются успешно.
2 проекта от 500 тыс до миллиона строк кода
Т.е. переписывать на «модное и молодёжное» не стремитесь?
( см. мои другие посты здесь — для контекста Ж-) )
Модное и молодежное — это такой красивый цветастый интерфейс с картинками и чатиком? Нет, мы создаем сложные профессиональные десктопные решения для бизнеса, а не фантики и побрякушки :).
это такой красивый цветастый интерфейс с картинками и чатиком?
мы создаем сложные профессиональные десктопные решения для бизнеса
Думаю, создатели АБС Бисквит, относительно недавно осознавшие необходимость графического интерфейса взамен текстового 80х25, думали так же.
И как он работает, по XWindow? Или на каждую рабочую станцию надо что-то копировать?
Я вижу два варианта, с сохранением логики интерфейса в процедурах .p — либо движок интерфейса перевели в XWindow, либо сделали свой графический терминал (как сделали в RS-Bank ~15 лет назад).
Модное и молодежное — это такой красивый... интерфейсПоложим не совсем так Ж-)
М&М это было про внутреннюю красоту:
там языки без ":=" и с фигурными скобочками должны были отбить все затраты на переход на них своими качествами Ж-)
Да не переписать их, трудозатратно слишком. Вот представляете пишут 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 живет и развивается. Недавно 'прикупили' себе Сенчу. Скоро будет ультра-быстрая разработка веба прямо из коробки.
2 Вы в РФ? У вас ЗП в 3500usd имеется?
Delphi не умер, конечно. Но есть проблема…
Когда с Delphi случился Embarcadero, он стал стоить каких-то совершенно невразумительных денег. Бесплатный Starter урезан до уровня D2, а потому смысла в нем никакого.
Поэтому, когда понадобился более-менее современный фреймворк, я нашел себе Qt под LGPL. То есть бесплатный. В котором есть все, чем мог похвастаться дорогой товарищ Delphi (из интересного мне), включая IDE, плюс еще много разного. И кроссплатформенность и opensource в подарок. И никаких проблем с подключением сишных библиотек, тоже бесплатных, да. Специально для знатоков даже есть возможность перехватывать неперехваченные exceptions.
А теперь любимая игрушка Python + PyQt. Вот вам практически нулевая скорость компиляции, лаконичный язык и все возможности фреймворка одновременно.
В одной знакомой лавке тоже есть работающие много лет приложения на Delphi + хронический дефицит дельфистов. Я думаю, что когда лавка решит перейти на что-то более современное, то она не дельфистов будет переучивать на C#/Java, а купит сторонний интегрированный продукт. Подозреваю, что он будет разработан не на Delphi.
Qt платный, если что.
Кто же заставляет статически собирать проект?
Мимо. Не верьте всему, что говорит бывшая Digia. Почитайте текст лицензии.
> Дефицит делфистов преодолевается элементарно, язык и среда настолько просты в обучении, что переучить человека можно за месяц-другой (по своему опыту).
Они не хотят учится Delphi.
Вы воспринимаете любую фирму как временное место?
Любая фирма это временное место, даже если фирма будет существовать дольше человеческой жизни, программист заскучает от однообразия.
Я работал в уютных коллективах, может быть если бы там была рыночная зарплата, я бы там всю жизнь работал-деградировал.
Но для меня главное:
1 Большая ЗП.
2 Изучение чего-то что обязательно повысит мою ЗП, не позже чем через полгода — год.
3 Не деградировать однообразием.
4 Уютный коллектив.
Но позиция вида «я тут на год-два, не больше, потому что мне надо идти „дальше“» тоже, мягко говоря, странная. Я бы фиг нанял человека, который объявляет, что после полу-года-года обучения он отработает год-полтора и уйдет.
Я бы фиг нанял человека, который объявляет, что после полу-года-года обучения он отработает год-полтора и уйдет.Но таковы реалии, я бы с удовольствием год поучился, было бы чему так долго учится. Но если ЗП не рыночная, то пойду искать ЗП.
Сколько вы учите и сколько я отрабатываю, об этом надо явно договариваться. Да и то, никак не проконтролируешь.
Если ответ будет год-полтора, я бы такого человека вообще не брал.Человек скажет вам хочу прокачать фронтенд, сейчас хочу икс, через полгода +10%, еще через полгода еще +10% и вы уже будете думать брать не брать, но через год ситуация меняется и рынок говорит что скилы стоят +30%, человек к вам приходит и говорит я себя чувствую ущемленным в ЗП, поднимайте или ухожу.
Я понимаю что сейчас есть много народа которые по какой то не денежной причине сидят на одной работе, но если вы молод, я считаю нужно почаще менять работу, да даже не молод, а просто способен менять работу — меняй работу.
один из возможных вопросов интервью со стороны рекрутера — сколько вы намереваетесь у нас работать. Если ответ будет год-полтора, я бы такого человека вообще не брал.Кто ж вам об этом скажет? Это такой же бессмысленный вопрос как «Почему вы уволились с прошлой работы?». Ответ будет прилизанным и стандартным и не факт что вообще коррелировать с реальностью.
Да и на вопрос про продолжительность работы я лично вообще не могу дать ответ. Откуда я знаю, как мне будет работаться в этой компании? Может я оттуда через две недели буду бежать и волосы назад. Может через год пойму что задачи унылые, зп не повышают. А может 5-10 лет счастливо отработаю над интересными сложными задачами и с хорошей зп.
Такой ответ вам бы подошел или вы ищете сотрудников, которые не учатся на своем опыте?
2. А что, фирма — это 1000летний рейх чтобы пережить поколения людей? Закладываться на вечность фирмы еще глупее, чем на вечность своей жизни.
Это никому и нахрен ни надо.
Ни студентам, которые в большинстве своем не хотят получить опыт, а хотят только разово подкалымить, не желая понимать, что они еще не заслужили того, чтобы им платили.
Ни предприятиям, большинству которых нужна рабочая сила пилить/таскать/красить или бумажки перекладывать.
Ни вузу, который в гробу все это видел, и не хочет даже минимально помочь людям на местах.
Есть конечно, исключения, но их мало.
Чем мы и начали заниматься, но из-за юридических сложностей (волонтёрская организация зарегистрирована в МСК, филиалов нигде нет, а договаривались с вузами из ЕКБ, Самары и другими. По старому закону (он отменён, но вузы не успели обновить внутренние положения) если организация для прохождения практики находится в отличном от местоположения университета городе, организация или университет обязаны отправить за свой счёт практикантов к месту прохождения практики. Не смотря на то, что наша организация — онлайн) пришлось остановить переговоры.
Выкормыши интернета. Это уже о студентах. Интернет для программиста бесценен: это и вопросы-ответы, и форумы, и опенсорс, и учебные видео-курсы-книги, и Хабр. Но им нужно уметь пользоваться и при этом контролировать себя, иначе получится так, как получается: молодые программисты схватывают информацию по верхушкам, находят готовые куски кода и тащат их сперва в курсовые и дипломные работы, а потом и в продакшен на работе. При этом они могут даже не проверить работу кода и не разобраться, как он поведёт себя в программе. Ну а если найденный код заработал — то всё, считайте, перед нами тру-программист. Ну точнее, он так о себе думает.
А code review у вас нет? Это тогда ваша проблема, можно и без интеренета страшных дел наворотить, например, писать свои сортировки и структуры данных :)
Найдите среднюю зарплату по вашему региону и умножте на 0.75-0.8 — это и есть достойная зарплата для джуниора.
Мид — 1.5 средней зарплаты.
Сеньёр — 2-3х средней зарплаты
Конечно это очень грубый подсчёт, но поможет вам определить примерный объём.
сколько нужно платит джуниору, который может решить проблему бизнесаСтолько же сколько и синьору. А точнее — на сколько хватит наглости запросить денег и насколько бизнесу припечет эта проблема и насколько хватит умения съездить по ушам бизнесу.
Для себя считаю, что 90-100 должны только профессионалы получать.Опасная ерунда. Не раз уже сказано — рынок программирования глобальный, как минимум, если есть разговорный английский, можно ориентироваться на зарплату джуна в штатах.
В зависимости от штата минималка уборщицы в сша 8 долларов в час.
«Неудивительно, что такие люди работают в компании по 10-15 лет» — тоже знаю таких знакомых, сидят на одном месте, практически не развиваются — долбят какую то старую систему, ждут новых перспектив (с зп в 3 раза ниже чем они стоят на рынке труда) — а их нет и нет, они не в доле этой компании и всегда останутся раб. силой, которую вполне легко можно заменить. И если они действительно профи, а не те кто приходит попить чайку и лишь бы быстрее день прошел, то рано или поздно они все равно уходят. Уходят и не всегда из за зарплаты, уходят чтобы перейти на что то новое, новые технологии, языки.
«Любите меня, я подарок» — учитывая спрос на программеров и других итешников, большая часть именно так и ведет себя. Почему — потому что если не вы, то другие. Современное собеседование это не только собеседование кандидата, но и собеседование компании — нужно также стараться понравится и понять насколько она данному человеку интересна и подойдет для его работы.
Не стоит забывать, что конкретный бизнес сам по себе может быть настолько неэффективным, что и предложить ему нечего. Корреляция между умениями программиста и его доходами весьма условная: я знаю чуть ли не гениев которые делают сложные штуки с машинным обучением за $200-300 в месяц (и их работодатель наверно считает это справедливой зарплатой) и знаю откровенно слабых программистов которые и код то пишут с трудом, но имеют солидные титулы в тех самых гуглах-майкрософтах и получают больше $200k в год.
А у людей с опытом, необязательно решения задач, подвешен язык и они могут рассказать о себе намного интереснее, избегая вопросов в которых плавают, оставив о себе лучшее впечатление.
Ну как бы пока есть желающие гении на зп 200-300$ смысл менять зарплаты им.
Рынок труда сам себя регулирует, обычно. Если фирма платит ниже рынка, оттуда все валят, и фирма загибается. Если фирма платит выше рынка — то фирма просто загибается от лишних неадекватных расходов.
Вот, собственно, основная проблема с которой я столкнулся после универа (дело происходит в Томске) — это то, что как бы ты ни был крут, платить тебе будут всё равно копейки. Я на первой работе работал за 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-е моя семья была нищей.
зачем тогда был ваш исходный набор вопросов другому оратору, ну да ладноМне казалось очевидным, то были исключительно риторические вопросы.
Но я очень рад, что вы не особо планируете размножатся, надеюсь в будущем будет больше места моим родственникам.
у меня машины нет, и я не умею (и не хочу учиться) водить.У меня нет машины и не хочу ее, я никогда не получал водительское удостоверение и не хочу учить ПДД, но водить умею (не по правилам видимо).
А смысла вообще нет.Есть, по крайней мере субъективный, например чувства как бы подсказывают цель (смысл), а логика — пути достижения.
Это состояния из разных классов, их нельзя сравнивать. Когда вы так говорите, вы подразумеваете, что всё равно остаётся некоторая сущность, которая даже будучи нерождённой может испытать опыт собственного нерождения и сравнивать. А это не имеет смысла.вы же упомянули безработицу и возможно имели в виду всякие несчастья, а я вам говорю, что несчастья — это ерунда, главное родиться.
Но я очень рад, что вы планируете потратить значимую часть своих ресурсов на размножениеА на что их еще тратить…
У всех по-разному складывается.
А уж гаже ситуации, где родителю(ям) наплевать на ребёнка, они его завели только чтобы такие советчики отвязались, вообще нет. На выходе три сломанных жизни — родителей и ребёнка.
А куда накопленное девать — это вообще не важно. Вас всё равно не будет, так что не всё ли равно. Мой вариант — просто найти какого-то достойного человека и внезапно его осчастливить :) ну или как крайний вариант — забугорный фонд борьбы с раком.
После 18 почти все мы будем только тупеть
Смешно :) 25-28 лет только более-менее ум развивается. Посмотрите на действительно умных людей — того же Энштейна, ум только во второй половине жизни раскрылся.
Биологическая задача не в работе, а в размножении.
Почему не оставить задачу биологического размножения тараканам, холопам и личному составу?
Биологическая задача не в работе, а в размножении
Отнюдь, размножение — это только лишь средство, а не цель или задача.
Никакое количество детей не гарантирует потомство даже в следующем поколении. И количество детей, равное трем, в контексте потомства индивида никакого особого смысла не имеет.
Даже для популяции оно не абсолютно и зависит от текущего уровня смертности, который в силу таких неприятных явлений как войны и эпидемии может заметно колебаться для конкретной группы людей.
Так что мы можем рассуждать лишь о вероятности оставления потомства в поколениях от внуков и дальше. И если вы хотите максимально увеличить эту вероятность, то оптимальной стратегией будет "настрогать" как можно больше детей от как модно большего количества женщин.
При любых катаклизмах выжить при текущем состоянии дел не получится. Катаклизмы очень разные бывают, а колонизацию других миров еще не завезли.
Есть еще один интересный момент. Если слишком заботиться о своих детях, то их выжываемость в катаклизмах только уменьшается. Они только в размеренной жизни без особых проблем преимущество получают, да и то не всегда.
Опять же, как показывает практика, у детей, о которыз слишком сильно заботились, отсутствуют как реальные полезные навыки (в силу отсутствия привычки что-либо делать самостоятельно), ни морали (в силу комплекса "мне все должны".
Кроме того, при катаклизмах на первое место обычно выходят навыки, крайне редко встречающиеся у детей, о которых слишком сильно заботились.
Ключевое слово тут "слишком".
Если же возвратиться к истокам ветки, то имеем минус к морали (любовница).
Любовницу не завёл, да и не вижу особо смысла. Так рисковать прочными отношениями всего-то ради секса? Серьезно? Цена сексу в современном мире, чуть больше новых штанов, что вообще несопоставимо с ценой времени, потраченного на выстраивание отношений :)
В общем, на выживание рода человеческого мне, в общем-то, наплевать :) Для поддержания роста популяции у нас есть страны с низким уровнем образования, они успешно справляются с рождением новых людей. Биологически нам ничего не грозит)
, на выживание рода человеческого мне, в общем-то, наплеватьНа выживание собственного рода тоже плевать? Ну и отличненько.
К тому же пришлось соврать об опыте работы, просто ради того, чтобы не относились как к студенту.«Уметь складно врать» стало одним из ключевых и необходимых навыков при устройстве на работу. Почему об этом никто не пишет? Почему все привыкли ко лжи в процессе устройства на работу? Такой общепринятый театр абсурда. При чем иногда надо привирать в плюс себе, иногда надо привирать в минус: дескать всю жизнь с пеленок только Delphi и занимался. Больше ни о чем не слышал. Привирание в минус бывет тоже достаточно эффективно.
А вот с точки зрения работодателей, правды все таки больше, на позиции мидл и выше, есть нехватка кадров, но и они пытаются обвинить в этом вузы и работников. Просто потому сложности есть, а кто виноват неясно.
В жизни полно иронии. Когда учился — очень любил Delphi, но вакансий просто не существовало на него, забил и стал сисадмином. Заходишь такой на хабр через 6 лет, а тут ищут человека именно на Delphi, который за давностью лет я уже забыл :)
См. десятичная точка или запятая в Algol
Это «европейская» и «американская» школы и подходы
Забавно, что для критических систем «по обоим сторонам океана» — ADA
Учи C#
А я понял одно: учить конкретный язык сродни зубрёжки стиха. Это инструмент, который осваивается за короткое время, если знаешь основы: ООП, технологии, паттерны и т.д. Ну а если ещё в теме бизнес-процессов, то и вообще отлично.
А фреймворки и IDE всякие осваиваются тоже быстро.
Свободный рынок и жизнь прекрасны как раз тем, что свои дороги моего выбирать или даже прокладывать сам. Те, кто ждут, что они проживут счастливо будучи винтиком в умирающей системе, имеют тоже на это право. (:
Вроде бы все верно и написано, в целом. Но отчего-то мне кажется что в вашу компанию народ не очень-то спешит работать.
Со всем согласен.
По образованию радиотехник, ВУЗ закончил три года назад и могу написать следующее:
Прежде всего, я поступил на обучение на базовую кафедру некоего предприятия, и это было в начале 4 курса универа (тогда ещё специалитет, т.е. 5 лет обучения). Выражаясь иначе — меня готовили к конкретной работе по конкретной тематике (разработка КВ усилителей) ещё в ВУЗ-е силами и средствами предприятия.
Но есть и минусы. Тематика работы специфическая и без перепрофилирования, при смене места работы, меня готовы взять лишь одна-две организации в Питере. Из этого вытекает ещё один минус — отсутствие конкуренции между предприятиями и претендентов на рабочие места делает зарплату стабильно "чуть ниже среднего" без шансов на ее повышение.
В моем случае было исключение, ибо: я радиолюбитель с позывным, у меня своя радиостанция, у меня тогда совпало обучение с получением позывного и начинанем работы для подготовки к выходу в эфир (а это целый комплекс мероприятий). Я бомбил преподов в универе тоннами вопросов, иначе ни черта бы я не знал и не умел.
Я пришел на работу и у меня был опыт в расчете, монтаже и настройки антенно-фидерных устройств. Для меня не был чужим паяльник (даже сейчас, кроме меня в отделе нормально паяет только начальник). И для меня была не совсем чужая схемотехника.
А кого выпустят из ВУЗ-а с таким опытом, крепко связанным со знанями? Никого, достаточно посмотреть на мою группу.
новичок ищет глазами гамак, пуфики, настольные игры и кроватки для послеобеденного сна.
<… но в офисе Regionsoft их нет>
А собственно почему? Действительно как-то глупо, что вы проигрываете конкуренцию за кадры даже не Avito, а картинкам из офиса Avito. Ваши проблемы с привлечением молодых кадров имеют объективные причины — CRM — скучнейшая область, технологии у вас дохлые. Естественно молодежь хочет игры, AI/ML, клевые технологии, с которыми можно релоцироваться в Калифорнию и красивые интересные офисы.
Открою маленький секрет — закупить пуфики, украсить офис и запостить фотки вот в этот корпоративный блог стоит 3 копейки, но может быть поубавиться причин размазывать сопли по лицу типа «джуны хотяяяяят нормальный офис, хнык-хнык». Но это, конечно, при условии, что ваших менеджеров не разорвет от ярости, если они увидят разработчика с ноутбуком с гамаке.
Сейчас работаю в отличном в материальном плане офисе
Таки ушли в другое место, значит причины были :-)
Навряд ли полезно для «спины»
>>> кроватки для послеобеденного сна
а вот это интересная идея
> разработчик с ноутбуком
Там же относительно «мелкие» экраны, неужели удобно?
«Не давит» ли «на глаза»?
А мышь? ( в варианте гамак / пуфик ?)
P.S.
> проигрываете конкуренцию... картинкам
Всё что выше — иллюстрация к «Картинки и Жизнь»
( как-то открыл, что подсел было на «кнопку» F9-C-C Ж-) )
Insert сам по себе — не нужен, согласен
P.S. Или не Apple? :-)
А фирма-конкурент — купила. И теперь "у студентов глазки не болят" и туда все идут, а вы — продолжайте плакаться.
Фирма "не только познакомилась с правилами", а уже Н лет на рынке. Парк техники обычно обновляется регулярно: компьютеры закупаются примерно 1 раз в 3 года. Если же там до сих пор работают на Pentium-II 400MHz — мне их вдвойне НЕ жаль.
А Делфи? :)
Таки есть и для Mac OS :-)
Кросс-компилятор точно был и отладка шла как раз на отдельном(?) комп-е с Маком
Ограниченно проперти смотреть можно
Помню, что настолько ограниченно, что просто швах. Переносил наш проект в Лазарус для эксперимента, с отладкой было тухло.
В 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 — если процедура вложенная, то процедурный тип для нее — это по сути лямбда — ссылка на саму процедуру + ссылка на зафиксированный контекст.
Насколько помню, в Си как раз потому и нет вложенных процедур — не ясно что делать с указателями на них
Например, мы выходим из родительской процедуры,
а указатель на вложенную в неё вернули в «дед»-код
А вложенная использует переменные из «отца»,
но их то в стеке уже нет
Короче, там ещё все «мутнее»
Выражения на лету может. Не может функции.
Сидеть на маке с ретиной, чтобы запускать делфи в винде в виртуальной машине — это как-то слишком.
a) «на крайний случай» т.е. требуйте у производителя обоснование пункт «B»
b) про Lazarus уже написали ( я просто не вспомнил сходу его название
и есть ли он на Mac как IDE или только на Linux)
потом retina
а про Дельфи пытались намекнуть,
что не взлетит он как IDE на модно-молодёжном Ж-)
Лично я про Lazarus читал + смотрел года три назад
А развивается он весьма динамично — поэтому
персонально и не стал писать про L.
И про VM: на Маке некоторого ПО ( и не обязательно
для программирования) просто нет
( да тот же MS Outlook для Mac не похож на MSO для Win )
Но почему-то VM как способ решения проблем — не хотят
Есть лукавство в его словах. Например, совершенно дикое рассуждение о том, что раньше экономика требовала кадры, а сейчас всё подспало. Вы на вакансии компаний посмотрите, которые они закрыть годами не могут, оцените рынок труда — современная экономика требует гигантское количество кадров, но хотя бы с минимальной квалификацией и пониманием того, как учиться работать в бизнесе.
Да нет же, мое мнение простое и понятное. В стране советов была корреляция между кафедрами и отраслью. Может быть не идеальная, местами убогая, местами замечательная.
Где-то до 60-х было нормой, чтобы не только кандидатские, но и курсовые (sic!) шли на производство. Сделают 5-7 студентов курсач, лучший пойдет в отрасль. Сейчас даже кандидатские по факту ни к чему не привязаны. Макулатура.
Сейчас этой корреляции почти нет даже в IT. Что уж говорить о других инженерных кафедрах. Имелось в виду именно это.
По поводу незакрытых вакансий — это лишь подтверждает мою точку зрения.
Вот, напирмер, мой хлеб — ИБ. Вот список вузов. Но свежих кадров — кот наплакал!
Да, что ИБ, мы полгода хорошего PHP программиста найти не можем!
P.S> пользуясь случаем: если это читает PHP разработчик — напиши мне в личку. Ты нам нужен!
Может, стоит-таки сравнивать не с давно несуществующей ситуацией в давно несуществующей стране, а с нынешней ситуацией в развитых странах?
Полностью занимаюсь самообразованием. По поводу предьяв к вузовскому образованию полностью согласен(учусь я в одном из лучших уников мск). Оно мало того что отстаёт на годы от реалий так ещё и попросту тратит моё время ненужными предметами. При этом отличное знание предмета так сказать не освобождает от ответственности. Вот зачем посещать «Базы данных» если я в каждом втором проекте использую postgres? А вот нужно.
Но у меня есть несколько предьяв к работодателям:
Во первых это ужаснейший подбор кадров. HR рассылает вакансию которая выглядит интересно. Ты отправляешь резюме(в котором выделенным шрифтом указано что ты студент и тебе нужен «гибкий» график). Тебе перезванивают. Ты повторно говоришь что ты студент. Тебя зовут на собеседование. На собеседование ты понимаешь что твоё резюме никто не читал и то что ты студент они не в курсе. «гибкий» график тебе никто не даёт. Они потратили твоё время. И это далеко не единичный случай. В отдельном котлу должны гореть работодатели которые ещё перед собеседованием даёт тестовое задание.
Ещё меня забавляют работодатели которые «выращивают» под себя. Я понимаю что трудоустройство студента накладывает определённые издержки. Но ведь не до «бесплатной»(или почти) степени же. Не хочешь кормить нахлебника? — плати ему за выполненные таски. У твоего «стажёра» стимул, а у тебя прекрасный инструмент оценки эффективности. А если у него хорошие скиллы на которые он потратил не один год то не один уважающий себя
А вакансии аля «не для стажёров» почти не светят. Придя на вакансию студент сталкивается с рынком. То есть помимо студента на эту вакансию претендуют и не студенты. И между дешёвым студентом но с гибким графиком работодатели отдают предпочтения не студенту с нормальным графиком.
После всего этого вообще пропадает желания откликаться на вакансии.
А вот с фрилансом всё хорошо. Студент может себе позволить демпинговать цены выполняя десяток заказов. Но правда количество «интересных» проектов стремится к «сделай сайт на wordpress» и совершенно нет стабильности.
Вы говорите — «Кстати, немного об ответе преподавателя-совместителя PavelMSTU. Есть лукавство в его словах. Например, совершенно дикое рассуждение о том, что раньше экономика требовала кадры, а сейчас всё подспало.»
Закончив все тоже МГТУ, зарплата в Москве на конструктора составляет 25-35к после 6 лет обучения, в гос проекты устраиваться по полгода проходя проверки и собирая справки. Причём за эти деньги компании хотят видить ещё и опыт работы.
В разработке джуниор получается аналогичные деньги, а то и больше с навыками которые можно получить за пол года, гибкий график вместо работы с 9-18.
Идейный альтруизм это конечно хорошо, но экономической заинтересованности в инженерах не видно ни разу.
Была такая компания, и не одна, которая растила узконаправленных спецов со студенческой скамьи, которые писали соответствующий код. В результате сформировалась весьма специфическая атмосфера, идеи и код по эволюционному развитию аналогичный Австралии по отношению к остальному миру. И разумеется до пуфиков они доросли только тогда, когда позвали хороших спецов со стороны,
Да мы и не претендуем на то, что наша точка зрения на персонал единственно верная. А может и вообще ошибочная — это с какой колокольни посмотреть. И что такое "крутой спец"? Для Вас это одни критерии, для нас другие. Вообще мы не крутые — мы обычные люди. И до Майкрософта нам как до неба. Мы не стесняемся этого, а смотрим правде в глаза.
По вопросу приема-увольнения могу ответить абсолютно честно. За последние 2, да нет, даже 4 или 5 лет от нас не ушел ни один разработчик. Вообще, если посмотреть по среднесписочному составу, сотрудники у нас работают в среднем по 8 — 10 и более лет. Понятно, что некоторые компании используют так называемую ротацию персонала, когда каждые полгода штатный состав должен обновляться на 30%. Но руководство RegionSoft этого не приемлет — у нас другая стратегия. Для кого-то она ошибочная, но не для нас.
Это называется болото. Чтобы оставаться в тонусе, разработчики должны видеть вокруг себя других, новых разработчиков — делиться знаниями. А вы — Delphi, и приковать к галере. И да, платформа ваша тоже сильно так себе. Это я как разработчик учетных систем с привязкой к VoIP говорю.
А кто сказал, что наши разработчики сидят только на Delphi? У нас ведутся разные работы. И для Windows, для iOS и Android, web-разработка, та же VoIP-телефония с привязкой к платформе Linux и т.д. Используются и C#, и Eclipse, и Anroid Studio, а также другие среды и методы разработки, в зависимости от задач. Мне кажется такая картина у всех вендоров.
Ну, а по поводу "так себе" могу сказать, что для компании в первую очередь важен голос клиентов, которые голосуют за или против своими деньгами.
Просто у меня сложилось ощущение, что у вас работают чуваки, которые начали на дельфи, написали большую систему, в которой разбираются только они, а теперь ещё и никуда свалить не могут, потому что кому нужен дельфи сейчас. Я на прав? Да ещё и морально тяжело свалить куда-то в неизвестность, бросив своё детище, которое чуть ли не с нуля сделал.
Когда я сказал, что от нас редко уходят сотрудники, я имел ввиду не только разработчиков, но и всех других: продажников, внедренцев, секретарей. Просто потому, что мы стараемся подбирать людей в команду так, чтобы они в нее влились по настоящему. Понятно, что рано или поздно каждый сотрудник уволится. Но нам важно, чтобы это было не скоро! Кому такой подход не нравится — это не наши проблемы :) Наша группа компаний работает уже 24 года.
Осмелюсь поинтересоваться, а Вы статью читали вообще? У меня вот ощущение, что нет.
Безусловно, я прочел статью, местами по горизонтали, как и большинство. Но все же, решил, что мой долг, как вашего коллеги по IT, сказать, что вам, безусловно, необратимо, необходим крутой дизайнер.
P.S. в следующий раз, когда наткнусь на вашу статью, напишу похожее сообщение. Я просто хочу помочь. Почему вы так это отторгаете?
С уважением (и кровью в глазах), Евгений
Евгений слишком ревностно относится к компании RegionSoft. Она ему не дает покоя :). Внимательно следит за постами и считает необходимым в каждую статью всунуть какой-нибудь грязный комментарий, даже не относящийся к теме статьи. Что-же, все люди разные. Кто-то радуется, что у соседа дела идут хорошо, а кто-то ему втихаря под забор гадит. Одно радует: раз есть такое пристальное внимание к компании, значит она идет верной дорогой :)
А то что там вам кто-то под забор гадит или завидует и прочее оставьте для разговоров на скамейках у дома.
А если не нравится его html и css, так зачем это вас заботит, не вы же его поддерживаете.
то вузы не дают нам тех специалистов, которые нам нужны
Ну с такой позицией и дальше давать не будет. Вы чего ждете?
Путина, который прилетит на вертолете в Мин. образования и наведет порядок?
Почему для студента — спасение утопающего дело рук самого утопающего, а для бизнеса обязательно должен быть добрый дядя который все за вас сделает?
Почему для студента — спасение утопающего дело рук самого утопающего, а для бизнеса обязательно должен быть добрый дядя который все за вас сделает?
Ну сейчас есть впечатление, что высшее образование требуют везде, даже где оно не нужно, в итоге люди идут получать ненужное образование на должность, где оно не нужно. (тут речь в контексте it).
то вузы не дают нам тех специалистов, которые нам нужны
Причем тут вузы, вуз не может заставить человека учиться, а как показывает прошлая статья и отчислить тоже. К вам может прийти такой же антиспец без образования, только там нельзя будет обвинить вуз.
Я вижу вакансии с неадекватными требованиями, как и соискателей с неадекватными запросами, что выглядит вполне логично. Строгость требований компенсируется необязательностью соответствия?
лозунг «Кадры решают все».Висит в Японии в цехах
мы просто не грузим соискателей тупыми тестами, вопросами про то, кем они себя видят через пять лет и просьбами решить задачу про канализационный люк.Так и хорошо
И об общечеловеческом:
( Не о политике, разве что кадровой)
Еще в 20-х г.г.Решил проверить, т.к. всё-таки помнилось, что прозвучало это после того,
как были построены «тракторные» ( и не только) заводы
И не зря: есть один показательный штрих:
Лозунг «Кадры решают все» впервые произнес Сталин И.В. в 1935 году.
Судя по стенограмме выступления Сталина на приеме выпускников военных академий РККА,
4 мая 1935 г., ставший столь популярным лозунг «Кадры решают все»
первоначально звучал так: «Кадры решают все, а не кобылы и машины».
И лишь после соответствующей сталинской редактуры он принял знакомый всем вид.
Про «основные фонды»+капитал первой трети прошлого века:
И тут же один из них стал торопиться куда-то, заявив, что «надо бы пойти кобылу напоить».+
«Людей мы завсегда сделать можем, а вот кобылу… попробуй-ка сделать кобылу»
На всякий, последнюю фразу не И.В.Сталин сказал, это ему свою кадровую политику дореволюционного времени местные сибиряки «коротенько» разъяснили
Что бы не на печальной ноте, «кадровикам» от т.Сталина:
Так вот, товарищи, если мы хотим изжить с успехом голод в области людей
и добиться того, чтобы наша страна имела достаточное количество кадров,
способных двигать вперед технику и пустить ее в действие,
мы должны прежде всего научиться ценить людей, ценить кадры,
ценить каждого работника, способного принести пользу нашему общему делу.
Надо, наконец, понять, что из всех ценных капиталов, имеющихся в мире,
самым ценным и самым решающим капиталом являются люди, кадры.
<TABLE class=topmenu align=center height=5 border=0 cellPadding=0 cellSpacing=0 width=1200 bgcolor='#FFFFFF' bordercolor='#CCCCCC'>
А если серьезно, то грех жаловаться на нехватку хороших кадров в компании практикующей устаревшие технологии.
Любой (вру, не любой, — адекватный) бизнес поднимет зарплату хорошему сотруднику, и не раз. Но только в ответ на экономический эффект от работы сотрудника. Проще говоря, ты приносишь фирме больше — она тебя весомее благодарит.
- Как думаете, вы адекватный бизнес или нет? Какой процент таких адекватных бизнесов в РФ?
- Как вы оцениваете экономический эффект программиста? В чем он по вашему заключается?
- Как у вас измеряется, сколько программист принес бизнесу?
- Как у вас рядовой программист может оказать экономический эффект? Для это организован какой-то бизнес процесс? Например, он может влиять на стратегические решения монетизации и т.п.?
- Если программист качественно сделал работу, но отдел маркетинга слабый, это как-то влияет на доходы программиста?
Можно продолжить, но пока остановлюсь на этом.
А сообществу, думаю, было бы интересно посмотреть на метрики, критерий, и процессы. Может быть научиться чему-то.
Без фактов, статья похожа на нытье.
Потому что с работодателями (управлением кадрами, их уровнем менеджмента БП и т.п.) возможно большая проблема чем с кадрами.
- Уверен, что "адекватный". Неадекватный бизнес не может существовать 24 года. ИМХО.
- Программисты бывают разные. Есть программисты, которые участвуют в проектах по внедрению, есть программисты, которые принимают участие в разработке типовых тиражных решений, есть кто создает компоненты, оказывает техподдержку и т.д. У всех разная задача и по разному можно оценить их вклад в общее дело. Однако возможно, конечно. Например, при работе над проектами по внедрению, оценивается скорость и качество этих работ, долевое участие конкретного программиста в группе проекта, своевременное закрытие актов в соответствии с техническим заданием, коэффициент стабильности создаваемых модулей и низкий уровень багтрекинга.
- см. п.2.
- Любой сотрудник, будь то программист или секретарь, влияет на экономику предприятия. Если не прямо, то косвенно. Работая эффективно, любой из них приносит пользу, которую можно монетизировать. А в чем эта польза и как ее монетизировать — это прерогатива руководства. В каждой компании и даже в разных отделах одной компании локальные цели могут быть также разными.
- Если отдел продаж курит бамбук вместо того, чтобы продавать, то от этого пострадают не только программисты, а все остальные. Бизнес придется закрыть, если не будет продаж. И неудел окажутся все. Навряд ли в одной компании, администрируемой одним руководством, один отдел может работать эффективно, а другой курить в это же время. Скорее всего либо эффективно работать будут все, либо никто. По крайней мере другой ситуации я не встречал. (Прошу не путать отделы с конкретными индивидумами)
У всех разная задача и по разному можно оценить их вклад в общее дело. Однако возможно, конечно.
Мой опыт говорит о том, что это в общем случае невозможно. Изредка, например, на внедрении, можно судить о вкладе программиста по подписанным актам. А в коробке ни один формальный 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, начиная с ключевых слов "Поставьте себя на место молодого программиста, который ищет работу". С точки зрения молодого программиста ваше понимание правды и лжи, модерна и старины инструментария, крутизны продукта, с которым он не работал, не имеет значения. Пока вы его не убедите, разумеется.
и о том, что знание(!) одного из языков программирования, чуть ли не помешает(!)
найти работу...
Иначе страшновато, например, за ответственные применения:
Сейсмоподвеска гостиницы «Казахстан» в Алматы, уникальное по тем временам сооружение в 10-балльной зоне, была спроектирована как дипломная работа моим преподавателем по термеху. Весь их выпуск работал над этим фактически, то есть реально можно было взять диплом выпускника кафедры сопромата и по этому диплому строить уникальное здание.
и всем удовлетворишьсяНе надо всего, в РФ достаточно 300000 рублей и родственника из фсб.
Как это котируется и непопулярен одновременно?
Ох уж эти сказки и сказочники.
что Delphi _специально_ изучать кому-либо просто и не потребуется
Паскалю и Ко учат ( Ok: не везде, но очень, и очень часто )
на первых же курсах, а то и раньше
Э-э-э, несколько принудительно Ж-)
Потому и писал: что есть предложение «вымарывать» из резюме?
Ибо увидев «не кошерное» не возьмут на работу?
Тогда совет: заводим 2 резюме Ж-)
Такая ситуация в любом бизнес-софте — потому что недостаточно знать язык или технологию — надо как-то разбираться в учете, экономике, планировании и т.п. ужасно скучных вещах!
То-ли дело клепать сайты или игрушки!
молодым просто НЕ ИНТЕРЕСНО все, что касается бизнес-софта!
Бизнес софт бывает оооооочень разный. Например, крутой аналитический софт с применением последних разработок в области ИИ. На мой взгляд весьма интересно.
Даже те же CRM могут быть очень разными с разными интеграциями и задачами. Никто не мешает в CRM включить анализ и предугадывание, а это вроде как интересные задачи, нет?
Даже те же CRM могут быть очень разными с разными интеграциями и задачами. Никто не мешает в CRM включить анализ и предугадывание, а это вроде как интересные задачи, нет?
Для молодых — в основном нет. Это сложно, матаппарат сложный.
Для молодых — в основном нет. Это сложно, матаппарат сложный.
Можно подумать у всех молодых все так плохо с матапаратом, особенно программистов, которые только вот закончили ВУЗ.
молодым просто НЕ ИНТЕРЕСНО все, что касается бизнес-софта!
Каждый сам расставляет приоритеты. Молодых программистов немало в разработке бизнес софта. Их незаметно по одной простой причине, например, чтоб стать опытным разработчиком на платформе 1С мало быть просто «кодером». Сама разработка на платформе сейчас существенно сложнее стала, а в дополнение нужно ещё и хорошо знать прикладную часть бизнес процессов: бухгалтерию, бюджетирование, производство, логистику и пр. В результате, реально себя специалисты проявляют ближе к 30 годам.
В отношении Microsoft Dynamics ситуация ещё жёстче: разработка сложнее, чем в 1С, да и сами системы сложнее. Поэтому средний возраст для опытных ИТ специалистов на этих платформах ещё выше.
Много работаю с молодыми программистами. Некоторые 20-23 летние могут в части технологий запросто утереть нос более опытным коллегам. Просто у них практического опыта пока не хватает. В хорошей команде такие специалисты себя прекрасно проявляют. Мне кажется, что многие, кто в этой ветке высказывается с недоверием к новым Junior специалистам просто забывают о том, что когда-то сами были «зелёными» и не знали с какой стороны подойти к технологиям.
На мой взгляд, работая с людьми, чтоб их понять, в первую очередь нужно ставить себя на их место, а не судить с высоты собственного опыта.
В результате, реально себя специалисты проявляют ближе к 30 годам.Не забудьте проявить их зарплату, чтобы мы поняли что там стоящего проявилось. А то я уже начинаю переживать за себя, неужели я зря 10 лет назад, с большим опытом в 1С, с 1С на .net + web перешел.
Разброс зарплат по вакансиям существенный. Есть отчаянные работодатели, которые пытаются найти программистов и за 30 тысяч рублей в месяц. Но реальность такова, что уровень зарплаты 1С разработчика с опытом и знанием прикладной части колеблется от 80 до 170 тысяч в месяц. Сумма зависит от специализации. Наиболее высокооплачиваемые – «производственники» и «финансисты». В частности те, кто работает с 1С ERP и 1С КА. Так же высокий уровень оплаты у программистов со специализацией по строительству на отраслевых решениях 1С БИТ Строительство Корпорация. Чуть меньше – разработчики, которые ограничиваются работой только с УТ, причём 11-й версии. 10-я сейчас не в тренде давно. Меньше всех – «зарплатники» со специализацией по ЗУП. Но с ЗУП есть один нюанс, если проект идёт на производстве, добыче или строительстве, где очень сложный расчёт з/п, там тоже могут быть достаточно достойные зарплаты – 120-150 тысяч.
Приведённые уровни зарплат верны, в первую очередь для Москвы и СПб, и касаются постоянки. Причём тут речь идёт о 100% белой зарплате. Вообще, хорошего спеца в Москве и Питере на серую зарплату найти сейчас сложно.
Если говорить об уровнях вознаграждения для проектной работы, то тут суммы выше. Опять же зависит от квалификации, знания прикладной области, специализации и формы сотрудничества. Выгоднее всего специалисту работать по договору подряда в качестве ИП. В этом случае при 100% официальных расчётах и заплаченных налогах, он получает максимальное вознаграждение.
Если Вы .NET программист, то не могу сказать, что размеры зарплат у Вас могут быть меньше. Другое дело, что российских работодателей по .NET маловато. Если Ваш нынешний уровень меньше указанного мной в отношении 1С, советую посмотреть в сторону зарубежных работодателей или устроится на работу к партнерам консалтерам, которые занимаются Microsoft Dynamics. Тогда и переучиваться не придётся.
Я хочу сказать молодым, чтобы учили English, он с нуля, за год учится, если заниматься по часу в день самостоятельно. (да, говорить самостоятельно так не научишься, но писать, читать и слушать — научишься.)
Не стоит идти на 1С, ни скорее всего на Microsoft Dynamics.
Не стоит работать на местных жлобов, особенно если работаешь не в столице, рынок программистов — глобальный, работай на тех кто больше платит.
учете, экономике, планировании и т.п. ужасно скучных вещахЭто не скучно и довольно доходно. Паче что, работая в CRM-вендоре, разработчики получают навыки и системной интеграции, и работы с другим софтом, и ведения проектов, и работы с клиентами. Полное погружение на сторону бизнеса — а бизнес это не менее интересно, чем игры или какие-либо сервисы.
разработчики получают навыки и системной интеграции, и работы с другим софтом, и ведения проектов, и работы с клиентами.Это типа — «вы получаете навыки и это наша плата вам.»?
Намекаете что «приходите к нам работать за копейки, зато получите опыт и будете думать что сможете себя продать подороже другой фирме!»?
Опыт не релевантен.
Полное погружение на сторону бизнеса — а бизнес это не менее интересно, чем игры или какие-либо сервисы.Я так и знал. Зачем деньги платить, вы же на работе удовольствие получаете.
Лично я выберу из двух мест, где комфортно и больше платят — то где больше платят.
Зачем навыки системной интеграции, и работы с другим софтом, и ведения проектов, и работы с клиентами, если на 1С, предел по ЗП был в 1200usd, с кучей лет опыта, когда на жаве от двух лет ЗП больше? :-)
Указывая на недостатки в описании Вашей системы, старался показать ход мыслей большинства разработчиков, как следствие обратить Ваше же внимание на проблемы, которые не очевидны. По крайней мере такой вывод напрашивается из Вашей статьи.
Если говорить о действительно квалифицированных кадрах, по себе и опыту найма специалистов вижу, что уровень зарплаты важен, но не является определяющим фактором. Поскольку специалисты сейчас анализируют и возможные перспективы собственного развития. Как следствие, предложение со старыми или невостребованными технологиями остаются без ответа.
Например, в приложении к тому же 1С, попытка сейчас найти хорошего программиста по платформе 7.7 не увенчается успехом, поскольку даже опытные и знающие эту платформу разработчики просто не пойдут на эту технологию.
В Вашем случае ситуация с наймом абсолютна аналогична приведённому выше примеру.
Кроме того, как разработчик, очень хорошо Вас понимаю, поскольку, с одной стороны сталкиваюсь и с такими горе соискателями, о которых Вы пишите, но с другой стороны, понимаю квалифицированных соискателей. И вот последние, скорее всего доходят до Ваших собеседований в совсем незначительном количестве по причинам, о которых написал Вам ранее.
В дополнение к вышесказанному, информация для размышления. Говоря о востребованных технологиях (.NET, Node.js, RoR, современные PHP Frameworks), приведу показательный пример: просто работа на UpWork позволяет спецу зарабатывать ~100-150К руб. в месяц уже через 4-6 месяцев активного выполнения заказов. Не говоря уже о прямых контрактах с заказчиками. При этом, вот прямо в настоящий момент запросов по разработке на Delphi там всего 51! На мой взгляд – это очень показательно.
Как вариант, можете поставить эксперимент и реализовать часть своей системы с использованием современных технологий. Вы сразу увидите рынок IT специалистов, с другой стороны. К Вам будут приходить на собеседование реально грамотные и опытные разработчики.
А у вас сколько лет опыта? Наверняка нее 1-2? Работали с вуза?
Впервые устроился на работу программистом в октябре 2015-го. Проработал 3 месяца, не вкатило, ушел на другую работу, где проработал чуть больше года за 35к. Там всё было хорошо, но потом другая компания и предложила раза в 2 больше, а потом еще и повысили через полгода. Вообще, если подумать, завтра будет ровно 2 года моего стажа)
Город Краснодар, в ту первую компанию привел своего одногруппника, который сидел дома почти год и «не мог найти работу», теперь там сидит, в коллектив вписался отлично :)
А что такого в 70тр с годом опыта? На мой взгляд, просто адекватная зарплата.
У вас спецы меньше имеют?
Можно просто поехать в Нидерланды и там устроиться на работу дворником. Там минимальная зарплата по закону 5500EUR. (больше 400 тыр.) Чего так париться? Еще какие-то языки программирования изучать...
Там минимальная зарплатаА в «гамбургерах»?
(Есть такой метод в эконм. науке)
Можете свалить и на 700. Не стоит стесняться лезть в гуглы: там отнюдь не гении работают, но за ту же работу будут платить совсем другие деньги.
Ни универ, ни диплом (будь он красный), никакие сертификаты, даже доверительное письмо с печатью президента не дадут понять кто сейчас перед тобой. Каждый будет доказывать своими умениями и знаниями, что он достоин места под солнцем. Я так же искал помощников себе, пытался обучать, но все заканчивалось на этапе установки веб-сервера без всяких пакетов «all inclusive». Но зато выслушал море «да веб-программист не должен этого уметь», «это уже все стоять должно по умолчанию», «да все равно мы работаем на сервере». Ну да =) Согласен. Смешно до ужаса, если б не было так печально для меня.
Лично я очень предвзят по отношению к «копипаст». Всякие возгласы «зачем делать то, что готово, это экономит время, оно уже оттестировано, исправлены все ошибки, прошло обкатку и бла бла» для меня звучит так «я не умею, и не смогу сделать это, извините у меня опыта и знаний нет». В тоже время я совершенно согласен со всеми этими доводами, если это говорит человек, который действительно может это сделать, т.е. у него есть опыт в данном направлении. В доказательство своих слов приведу пример: в 2009 году, когда я только становился на ноги, у меня случился баг. Плагин FancyBox неправильно позиционировал изображение при открытии. При этом только в Opera. Я открыл интернет и стал рыть. Потратив 40 минут и найдя советы от «смени браузер» до «поменяй на другой плагин или обнови библиотеки», я сильно разочаровался и просто подумал: «JavaScript знаком? знаком… позиционирование делал? делал… Ну так разберись». Через 3 минуты баг в плагине был поправлен, без хаков и всяких переписываний, буквально было добавлено пару значений в место где вычислялась высота. Вот с того момента я копипастеров не люблю. Они лишь могут доказывать свою несостоятельность.
А был у меня клиент, которого обслуживала студия всем известного веб-дизайнера. Клиент пригласил меня, и попросил сделать им проект. Точнее переделать тот, что вел тот самый печально известный дизайнер. Из их претензий к нему была банальщина. Идиотская и просто неописуемая, от генерации случайного числа, не возможно использовать встроенный редактор, до «извините но это технически не возможно», когда просили блок новостей поместить в другое место страницы. У меня от ладони на лбу след наверное недели лежал, когда я все это от них услышал… А все почему? Потому, что «набрали по объявлениям» разного рода «а сюда мы поставим этот плагин», и гребут бабки. Потом нормальные разработчики разгребают это <***>, извините.
Вообще у меня тоже много накипело. И про кадры, и про маркетинг, и про юзабилити. Я всегда за библиотеки, за готовые решения, за быстроту и минимум исправлений. Но я против, когда человек не может сделать ничего, кроме как поставить новый плагин интернет-магазина (дада, я таких встречал) за 30 000 рублей =)
Человек без знаний и опыта априори не должен получать больше того, у кого больше знаний и умений. И мне совершенно не понятны жалобы, типа «а почему он делает меньше, но получает больше?!».
Потому, что тебя можно уволить, а его себе дороже =)
пысы: извините за многабукаф, ну накипело =)
пысы2: всегда рад тем, кто жаждет нового. пусть начинает с установки всяких движков, плагинов, библиотек. но всегда задаст вопрос «а как это сделать», и проведет пару ночей в угаре, но добьется того же но своими силами. Пусть с лагами, ошибками, но добьется. я знаю таких людей, они очень быстро развиваются, их проекты в итоге грамотные, понятные, закоменчены и главное — они больше доверяют своим силам, а не чужим. я вообще «за», что бы со школы начинали внедрять начало программирования, а не то как в ворде слово «собака» жирным сделать. пусть школота знает как собрать системник, как поставить винду, линь и фряху и понимать их различия. минимум, что требует современный ИТ-мир. иначе так и будут мелькать на башорге, что то вроде «ххх: дайте IP какого-нить лоха! ууу: 127.0.0.1 ххх: Спасибо! Сейчас он умрет!» =)
Всю суть проблемы можно описать коротко: системное отсутствие трудолюбия. От этого и возникает перекос рынка. Работодатели выстаивают бизне-процессы исходя из того что, большинство разработчиков рукожопы, студенты не требуют от учебных заведений актуальных знаний (да, должны требовать, я считаю, но в силу своей лени просто едят что дают по старым и кривым учебным планам), сами учебные заведения не хотят заглянуть на полшага вперед и посмотреть на себя как на бизнес по продаже знаний. Всем все тотально лень. Лень думать, лень делать, лень шевелиться.
студенты не требуют от учебных заведений актуальных знаний
А как студентам эти знания требовать?
Если есть общий учебный план, составленный поросшими мхом бюрократами от образования, в котором самым сложным и востребованным дисциплинам выделили минимум часов, а основное время забили всякой фигней для галочки, то даже самые классные преподаватели (а у меня такие были) ничего толком не смогут дать…
погуглите "студенческое движение"
Много знаете случаев когда от этого движения был какой-то реальный положительный результат?
А что они могут? Про это писали и в прошлом ответе и уже много где — нет людей, которые бы могли обеспечить актуальные знания. А если и есть, то далеко не в тех масштабах, которые нужны.
Ну заставите вы кого-то пересмотреть план, их будут пересматривать те же люди, а значит будет тот же результат. А заменить этих людей некем, потому что никто туда больше не пойдет.
Поэтому почти никто из студентом этим не страдает, так как они понимают, что в целом они не могут ничего сделать, кроме как пойти преподавать, а этого, понятно, очень не многим хочется.
(PS: Это была не IT, а естественно-научная специальность)
А что они могут?
Как минимум не допустить, чтобы проблема стала данностью и не породила новые проблемы.
Всю суть проблемы можно описать коротко: системное отсутствие трудолюбия… Всем все тотально лень. Лень думать, лень делать, лень шевелиться.
“Почти все наши программисты пришли к нам студентами и всех мы вырастили сами, начиная с языка и заканчивая code style. Неудивительно, что такие люди работают в компании по 10-15 лет — они идеально к ней подходят.»
Есть у меня смутное подозрение, что «подходят» у вас люди по 15 лет лишь потому, что никому другому они с вашим «обучением» не подходят. У вас система на DELPHI и вы собрались кого-то учить code style? Серьезно?
Если вдруг это читает кто-то из молодых программистов, ребята, помните, никакая региональная конторка ничему хорошему вас не научит (как собственно и ВУЗ). В мире есть ограниченный список программистов, у которых стоит учиться. Он вряд ли шире 100 человек, и они не сидят в региональных конторах. Они выступают на топовых конференциях и пишут книги.
П.С. Если у кого и имеет смысл учиться code-style, так это у Robert C. Martin, ака «Uncle Bob».
Сейчас я архитектор в крупном международном банке.
политолог по образованиюКак раз не-математиков и любят мучать Паскалем ( хорошо если не 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Студентам — не ходите туда.
Работодателю — берите кобол, он проверен временем.
Я считаю что Delphi удобней c/c++, но в первую очередь нужно думать о деньгах которая дает работа и спросе инструментов на рынке. Ситуация такая что Delphi, к сожалению (или счастью), не выглядит перспективным.
А с ВУЗами сотрудничать — вы не пробовали? Не пробовали — заключать договора с ВУЗами на отсылку своих специалистов, читающих лекции. У вас получается: ВУЗы — виноваты, потому что не дают нужного и нового, студенты — виноваты, потому что долбодятлы и требуют сразу миллионов, а вы сами — все в белом. Но при этом — любите переманивать готовых специалистов у других, кто таки тратились на обучение и рублём не попрекали? Нет, ну серьёзно — вынь да положь вам готового специалиста, а уж вы, после тщательной оценки, может быть поднимете ему зарплату. Вот такой вот посыл я проследил, что оказывается принять на работу студента это затраты. Студент оценивается, не как сотрудник, который принесёт профит, не инвестиция в будущее, а как затрата, которую надо окупить. Даже покупку компьютера и IDE к этому прикрутили. Как вы с таким мировоззрением ВООБЩЕ ИМЕЕТЕ НАГЛОСТЬ ПЛАКАТЬСЯ, что "кадровый голод" и "нормальных студентов нету"? Ребята, я уже давное не студент, но, будучи им, я бы к вам — не пошёл бы. Да — ВУЗ не учит нужному, да — студенты имеют запросы… ну так что ж вы хотели-то? Если за какой-то вшивый айфончег, склёпанный голодными китайцами — хотят сразу 1000$, то почему меньше должен хотеть подающий надежды специалист? Дизайнер? Почему вы хотите мало того, что встать в позу "берём или не берём" (мне напомнить про тысячи объявлений с пометкой: "2-ух, 3-ёх, 5-тилетний опыт работы"), так ещё и диктовать условия по зарплате в достаточно наглом виде, сразу же записывая издержки на потенциального работника? Риски надо — разделять! А по хорошему — брать на себя (студент этого в принципе сделать не может) и искать потенциал.
P.S. Работая в нескольких компаниях (больше 5) — я только в ОДНОЙ получал регулярный пересчёт зарплаты и добавку не обращаясь к администрации. То бишь только одна компания из пяти вообще считала себя обязанной АВТОМАТИЧЕСКИ компенсировать сотрудникам инфляцию, поднимать зарплату, мотивацию и вообще следить за этим. Так что не надо свистеть о том, что "ты сначала поработай, а потом ужо мы посмотрим" — такое считается в одном случае из 5 (или ещё реже в моём случае). Обычно, пока не прийдёшь и не скажешь: "гоните бабло" (но культурно!) никто даже не почешется, потому твои проблемы — это не их проблемы.
P.P.S. ИМХО, не надо винить ВУЗы или студентов — надо подключаться к системе образования и помогать менять в лучшую сторону, если она вам не нравится. Ах что я слышу — опять вы скажете "это же огромные затраты!"? Ну если хочется сразу "готовых спецов" тогда — кушайте что дают.
Работая в нескольких компаниях (больше 5) — я только в ОДНОЙ получал регулярный пересчёт зарплаты и добавку не обращаясь к администрацииА по моему опыту, из нескольких компаний (больше 5) только в одной не было пересчетов. И то лишь потому, что это был стартап, не проживший и полгода.
Личный опыт — он у всех разный.
Раз в 3 года это перебор, наверняка уже просели по рыночной ЗП! Конечно это не относится к глубинке где нет работы, но там надо искать удаленку и учить разговорный английский, затем менять работу если не повышают по рынку или выше рынка.
Мое мнение — фирме выгодно, сотруднику, с двумя годами релевантного для фирмы опыта, повысить ЗП выше рыночной. Но фирма этого не делает, а ищет сотрудника по рыночной цене, но с не релевантным опытом — абсурд! :-)
практика показывает что менять работу, с целью повышения ЗП, лучше не реже чем раз в 1 — 2 годаПолностью согласен. Более того, на мой взгляд, присматриваться к рынку нужно как можно чаще, хотя бы дважды в год.
В моей практике была ситуация, когда один и тот же работодатель оставался оптимальным по зарплате в течение 2.5 лет. А потом в один прекрасный день пришел другой и перебил предложение вдвое.
Если менять работу раз в 2 года — компании могут перестать вас рассматривать в принципе, потому что по их мнению вы" ненадёжный". По мнению же некоторых индивидуумов, которые здесь пишут от имени компаний, точка зрения вообще может взлететь до: "они в в вас вложились и потратились, а вы их кинули через всего лишь два года иони не окупили затраты на вас".
Здесь же мешает озвученная проблема про то, что ВУЗам невыгодно отчислять студентов. Да, бизнесу на это плевать, он считает, что ВУЗы не выполняют свою функцию, но ВУЗ не может терять деньги и тем самым преподавателей, отчисляя лоботрясов. Если Минобр изменит своё поведение хотя бы для технических ВУЗов, тогда ситуация должна начать меняться. Тогда и практики на 100% будут другими, какими они должны быть, а не на 50% или в некоторых случаях ещё меньший %.
даёт возможность студентам попробовать свои силы поработать на предприятии в рамках учебной, производственной, научно-исследовательской практики. Но...А вот у меня это «но» в свое время выплыло с неожиданной стороны. Я уже работал на тот момент, и работодатель был готов заполнять все необходимые документы, но ВУЗ сказал «нет, ты проходишь практику у нас на кафедре», и в итоге практика у меня заключалась только в бумажке.
Хорошо хоть работать не мешали.
Очень радует, что вы готовы обучать дельфистов :) Я со школы пишу на Delphi, технология меня вполне устраивает.
Расскажу то, что, возможно, вы будете считать интересным, а именно, что мне, как студенту, хотелось получить от работы и как я ее искал. Во-первых, компанию я искал (поскольку Delphi и в Европе «вымерший, не имеющий преимуществ, а еще не кроссплатформенный» (нет)) через митап Дельфи программистов в Берлине. На сайты поиска работы надежды сильно не было, ибо вакансии обычно уровня «опыт работы от 5 лет». В итоге был выбор между двумя компаниями, но выбрал ту, где предлагали удаленную работу (учиться то надо), рабочий ноутбук (денег нет) и последнюю версию Delphi (юношеский максимализм + релевантный опыт ибо Delphi 7 никому не нужен). Зарплата была сначала небольшая, но через год запросил уже больше, потому что сам зарабатываю на жизнь (к слову, работаю по 3-4 часа в день). Цифры называть не буду, но зарплата чуть меньше обычных разработчиков, но больше среднестатистической для студента (в час, в сумме, конечно далеко до full-time оклада). Сначала был уверен в том, что на работе будет скукота, и задания будут не интересные. Очень ошибался. В последнее время мне также помогают в развитии моих Delphi-навыков, что я тоже очень ценю. Честно говоря, очень доволен своей работой. Стараюсь для них тоже делать все качественно, как умею.
Ради интереса: готовы ли вы, RegionSoft, дать все перечисленные плюшки студенту, если вдруг придет? :)
Нас мало. Знаю только двоих других дельфистов-студентов в городе. А вот фирм, которые ищут дельфистов, много (попадались вакансии от Motorola и Siemens). Возможно, компаниям, которые имеют дело с Delphi, стоит чаще говорить о том, что они ищут людей, иначе все будут думать, что дельфи уже умер, и никто его не будет учить.
По теме статьи:
Есть одна, очень тяжелая вещь для студента, а именно, понять, что значит «хороший специалист». Грубо говоря, человек оценивает себя по статьям с Хабра, насколько он их понимает. А почему нет? Вот, обучающийся умеет настраивать Jenkins, поднимать контейнер на Docker, писать на PHP, есть парочка достаточно неплохих проектов, знают про Design Patterns, тесты и основы алгоритмов. А что еще? Что дальше? На хабре все понятно, студент старается в своих проектах следовать прочитанному, думает, раз люди такое пишут, значит, я тоже уже готовый разработчик. Я на самом деле видел мало студентов, которые не понимают, что их ждет в разработке, как вы описываете в статье (в пунктах «Работа» и «Отношения»), скорее проблема в том, что студенты не могут адекватно оценить себя. От этого и приходят завышенные требования к технологиям, офису и зарплате. А иногда и не завышенные. Действительно видел студентов, которые приходили и обучали новым подходам и фреймворкам прогеров, которые уже работали в фирме. И фиг теперь фирма таких отпустит, а еще оклад максимально поднимет. И мне кажется, такое происходит, потому что, людям в IT надо часто переобучаться. Вот так, скача с технологии на технологию, с фреймворка на фреймвок, ты и остаешься вечным мидлом, а потом тебя уделывает какой-то студент, просто потому, что у него в универе было время хорошо разобраться в самом новом.
P.S. Ну я и графоман :)
А какая медианная ЗП мидла?
Если вы заинтересованы заполнить вакансию, то вы должны сообщать уровень оплаты.
Именно поэтому разглашать какие-либо цифры (средние, вилки, минимальные) на
публичном сайте работодатель не будет. Не требуйте от него невозможного, имейте уважение к акулам бизнеса.
Серьезные компании говорят вилку.
Исключение монстры индустрии, вроде гугла, майкрософта и т.д.Нет ли здесь противоречия? Ну и исключение составляют не только монстры индустрии — я вот, например, не знаю в Москве вообще ни одной компании с более, чем 100 разработчиками, которая указывала бы вилку зарплат.
Так что как раз серьезные компании вилку зарплат не указывают. Как бы грустно и неудобно для нас как для соискателей и разработчиков это ни было.
зачем мне тратить свое время на собеседования в компании например если они не могу предложить больше суммы n, в то время как меня устроит только сумма 3*nА вот это как раз всегда можно спросить при первом контакте рекрутера.
Я собеседовала девочку около года назад. Из опыта — это пара сверстанных страничек и самый минимум css, js — 0. В принципе нам требовался человек, что бы разгрузить меня, мы не ждали ни чего выдающегося.
Решили: «Что бы не попробовать, за месяц станет видно, ни она, ни мы ни чего не теряем».
О зп она договаривалась с эйчаром, в итоге 20косарей, работала по договору. Я давала самые легкие задачи, которые у меня заняли бы минут 15, но джуну требовалось час, полтора. Вполне ожидаемые показатели, первая работа, стресс, отсутствие опыта, не знакомый проект. По итогам я осталась довольна. Взяли по трудовой, с зарплатой в 30-ку. После окончания официального испытательного 45. После десяти месяцев — 55. Думаю к концу года 60.
Я с ней разговаривала об желаемой зарплате, повышения соответствовали ее ожиданиям на данный период.
Знания и уровень верстки ощутимо улучшились, а вот по js-у не такие впечатляющие достижения.
по первой части не согласен со всем:
- Деньги — я ищу работу. Первое на что я смотрю деньги. Про повышения мы не узнаем пока оно не наступит. Знаю несколько "солидных" компаний, которые живут только на "дешевых студентах", которые боятся уйти. По моим наблюдениям з/п для одного и того же человека в разных компаниях может разниться в 2 раза.
- Офис — я ищу работу. Я понимаю что я буду туда ходить и находится там солидное количество времени. Если будет выбор между двумя компаниями, но у одной из них столик для тенниса — я пойду в неё. Как минимум, потому что игровые на работе создают (хотя бы) иллюзию непринужденности.
- Работа — писать юнит тесты не любит никто. Процитирую одного человека: "У вас спросят на собеседовании: "любите ли вы писать юнит-тесты", и вы скажете "Конечно люблю" и тут мы улыбнёмся и поймём друг-друга, о том что вы врете. Юнит тесты не любит писать никто."
Не знаю кем бы я был, если бы на первой работе мне бы дали код и сказали "тестируй". Лучший старт:
- Тебе дают код
- Ты делаешь
- Комитишь
- Ревью тайм
- Пишут двадцать-тридцать пунктов, что нужно исправить
- Митинг, на котором тебе говорят, почему это важно
- Отношения
Тим билдинг это здорово. Нужно позволить разработчикам общаться друг с другом как им удобно. Активные разработчики, которые пытаются влиться в коллектив лучше, тех которые просто приходят молча на работу и молча смотрят в монитор. (имхо)
Как минимум потому что они будут знать кто чем занимается, и у кого можно будет спросить помощи с такой-то проблемой.
Я люблю писать юнит-тесты, соответственно, утверждение неверно.
Не, не то, чтобы мне очень нравился сам процесс их написания, но разработка без тестов — это еще хуже.
Не, не то, чтобы мне очень нравился сам процесс их написания, но разработка без тестов — это еще хуже.Сам хотел так ответить :-)
разработка без тестов — это еще хуже
С этим никто не спорит. Я говорю что заставлять новичков писать юнит тесты это плохо. Цитата из статьи:
Вы придёте и начнёте с малого — возможно, даже просто минимального тестирования.
Как минимум, потому что лучше девелопера который написал код, юнит тесты не напишет никто.
Поэтому и существует TDD, который не только "гарантирует" что написанный функционал будет покрыт тестами, но и позволяет программисту лучше задуматься о "граничных параметрах".
Мне кажется тут лучше всего подойдёт аналогия с кузнецами "Мастер — подмастерье":
Правильный подход(имхо): Подмастерье смотрит на работу мастера, делает что-то сам. Получается криво. Мастер говорит почему.
Подход из статьи: Мастер говорит подмастерье: "убирай за мной кузницу и полируй продукт". Подмастерье убирает и полирует.
С одной стороны, да он увидит как выглядит правильный продукт, полируя его и какой инструмент для чего используется. Но почему так, ему придётся догадываться самому.
В каждой компании по своему. На прошлой работе была игровая с теннисом и настольныv футболом. Все играли никто не жаловался.
На новой тоже самое + х-бокс, лаундж зоны и "книжные углы".
Опять же никто не жалуется.
По поводу "лишали привозной воды" советую почитать Трудовой кодекс РФ. Это просто незаконно (пункт о том что работодатель обязан обеспечить питьевой водой).
Ну и, пожалуй, бежать от такого работодателя куда глаза глядят.
бизнес поднимет зарплату хорошему сотруднику, и не раз.Ахахаха. Ага, поднимет, в 0.8 раз и не раз. Поднимают зарплату только тогда, когда человек уже нашёл другую работу и подошёл увольняться.
Офис. Опять же, на Хабре можно насмотреться на прекрасные офисы Google, Avito, Badoo…Пля, купите хотя бы кресла нормальные, чтобы хотя бы спину облакотить можно было и не свалиться, а не долбанные табуретки трудовика дяди Вовы за 40 рублей штука из ближайшего пту. Сидишь скрюченный весь, поясница болит. О какой продуктивной работе может идти речь? Конечно люди будут присматривать конторы где офисы лучше.
Во время такой стажировки студент усвоит требования бизнеса и сможет адекватно воспринимать программу обучения.Что бы не придумать, чтобы зарплату не платить студентам. Стажировка, практика… Обычно после таких стажировок в этой же компании не остаются т.к. на зарплату там расчитывать нельзя. Но зато в резюме можно написать что была работа, а там зп больше будет.
И нет, это не перегрузка ребёнка — во-первых, дети в школе закончились, а во-вторых, он/она один фиг дома за компьютер сядет. Так лучше с пользой, на работе и за деньги (за обучение).Да, мечтаааа работодателя, чтобы сотрудник работал сверхурочно за бесплатно 24*7. Нафиг людей нанимать, когда можно заставить рабов работать до ночи за бесплатно а на сэкономленные деньги слетать на Карибы и копить ещё один мерс. На каждом втором собеседовании вопросы про сверхурочку, хобби и семью — чтобы их не было, ноулайферам в айти дорога…
Мы говорим о российском рынке и стартапных небольших CRM для стартапов же на рынке — пруд пруди. Некоторые из них даже гранты выигрывают и в рекламу вбухивают, а потом резко «меняют направление бизнеса». Мы говорим о несложных, но известных системах, которые не подходят тем же производственным компаниям. Ну и о сложности разработки, да.
«Любите меня, я подарок»
Примерно с такой позицией приходят самые молодые
А знаете, на мой сторонний взгляд, ваша компания ведет себя примерно так же — «любите нас, мы работодатели». Мы мол им и обучение бесплатное предлагаем, и даже компьютер рабочий бесплатно дать готовы, а они еще и денег требуют. На мой же взгляд, очень странно попрекать работника тем, что вам нужно потратить деньги на обеспечение его рабочим инструментом, мне почему-то кажется, что если бы работодатель озвучил какому-нибудь токарю на заводе, что-то вроде: «Знаешь, твой станок обошелся мне в 200 000 рублей, поэтому тебе придется какое-то время поработать за еду», — он услышал бы о себе много матерных слов. Нет, есть конечно компании, которые продают свой товар своим «работникам», а потом предлагают бесплатно обучить их продавать его кому-то еще (MLM), но и отношение к ним соответствующее. Опять же, нахожу слегка странным желания бизнеса иметь готового спеца по выходу из вуза — фреймворкам, языкам, СУБД и прочей специфики в ИТ несть числа, и как вуз может угодить всем, особенно с учетом того, что модный вчера, легко может стать не модным завтра? Обратитесь в вуз, возьмите студентов на практику, а потом предложите работу. Да, тоже затраты денег и сил на организацию, но меня в школе учили, что бизнесмен ездит на дорогой машине, не потому что эксплуататор, а потому, что он берет на себя риски, а если риски не берет, то что же это тогда получается… :)
, никто их в жизни никому не озвучивает.
И тем не менее, в статье вы их озвучили, причём в подзаголовке, общую мысль которого можно выразить как «выпускники много просят». Я пытался вам донести, что использовать эти затраты как аргумент к уровню оплаты труда – как минимум странно, чтобы понять насколько, представьте, что нанимаете токаря, и озвучиваете ему ваш мысленный довод. А чтобы понять почему, достаточно помнить, что вы на дарите работнику рабочую машину и стол, и даже если работник вам не подошёл, то новый (вам же все равно его искать, если работники нужны) этих затрат уже не потребует.
И попрекнули, кстати — иначе как пассаж расценивать "Просто потому что пока ты — источник затрат: стол, компьютер, софт, IDE, обучение, еда-вода, Интернет и т.д. И пока ты эти затраты не окупаешь."
Как это расценивать иначе как: "Ай-ай-ай — ты ещё ничего не сделал, а мы за тебя уже заплатили"?
Так, как это выставлено в статье — выглядит как претензия. Лично для меня и возможно — не только меня.
Какой-то вы особый смысл в слово "попрекнули" вкладываете… Поясню свою точку зрения.
Студент приходит на собеседование и говорит, что хочет зарплату в 1000 Долларов на руки, на что ему говорят — "Ээээ, дарахой, ваапще-то мы тут тебе стол, стул, компьютер и IDE купили....".
С позиции любого потенциального работника (не только студента) — это выглядит как завуалированный упрёк при всём при том, что с точки зрения закона он ещё даже работать не начал, а ему уже ставят в вину то, что на него уже потратились буде он таки решится там работать и этим упрёком его прессуют с целью снизить его собственную цену.
Это крайне ущербная практика с позиции мотивации потенциального сотрудника. Зачем человеку работать в компании, в которой ему с самого начала начинают прививать чувство вины за то, что он там работает? Мало того на основе этого упрёка следуют обвинения в неадекватности (запросов) и предлагают ставить его финансовое положение в зависимость от настроения левой пятки неизвестного дядьки? Нет, есть люди, которым нравятся унижения и чувство вины, но я бы не назвал нормальным среднестатическим поведением профессионала и потенциального специалиста.
Спикер сводит до абсурда ситуацию со студентом "Любите меня таким", почему мне нельзя свести ситуацию до крайне негативного экстремума для работодателя — мне решительно непонятно. Сравнение максимально позитивной/негативной для работодателя/наёмного рабочего ситуаций есть задача, позволяющая вычислить некий баланс, к которому нужно стремиться.
Вам пытаются показать, как думает бизнес, вы отбрыкиваетесь и обижаетесь на что?Причем тут обижаться. Просто бизнес какой-то сказочный, как будто сотрудники должны думать о бизнесе, а не о своем кармане. Вам об этом все говорят.
А баланс должны только бизнесмены искать по вашему? А весь такой супер-пупер студент может не задумываться ни о чем, пусть его любят какой он есть?Сотрудника, трудности бизнеса не волнуют, вернее если у бизнеса трудности, значит не стоит идти в эту фирму.
Риск, это дело исключительно бизнеса, сотруднику за риск не платят и не штрафуют.
Так что задумываться об общих проблемах бизнеса сотруднику не стоит. Стоит задумываться только что входит в его оплачиваемые обязанности и доход.
Человек поделился своим виденьем ситуации, дабы розовые очки студентам не помешали в дальнейшем найти хорошую работу.Это всего лишь собственное мнение конкретного бизнеса. (ошибочное, на мой взгляд)
И, по-хорошему, это как раз в вузах должны были рассказать студентам.Да да, пропаганду для тех кого в жизни ни разу не обманывали, в которую абсолютное большинство не верит. Такое рассказывать в рыночной экономике как-то странно. У бизнеса свои проблемы, а у сотрудника свои.
Но это не значит, что это будет озвучиваться человеку в реальности, понимаете?Если это не озвучено, то есть нет договора/договоренности, то для взаимодействующих сторон этого вообще нет, остальное — это, всего лишь, безосновательные хотелки другой стороны.
Самый простой способ задрючить джуниора - спросить о внутреннем устройстве стандартной библиотеки, о деталях реализации виртуальной машины. Ну и конечно алгоритмы, тервер, дискретка, и прочий матан. Указанные компоненты можно смешивать в любых сочетаниях для достижения нужного уровня зубодробильности. Чел хочет заплату 80, а у тебя есть только 60? Нет ничего проще, спроси его почему реализация списков в стандартной библиотеке неправильная и как надо реализовать правильно, или дай какую-нибудь задачку, которую на прошлой неделе еле-еле решил самый умный в конторе кодер, а потом жди пока зарплата не опустится до запланированных 60 -)
Лично у меня ситуация, когда я собеседовался лишь в одной компании, была лишь однажды, и я в тот момент четко понимал, что готов работать у них за любые деньги.
«каждый джун с двумя офферами»
«по 10-20 кандидатов на вакансию джуна на рынке»
Затраты и риски на наём сотрудников — есть цена, которую приходится платить за развитие компании и сверхприбыли, разве не так? Я решительно не понимаю, почему студент должен брать на себя эти риски и вину за них (думать о них он должен, но брать на себя тем более после подобных заявлений потенциального работодателя) — хренушки.
То, что сам человек должен был бы понимать по хорошему на основе даже школьного курса экономикиЯ вот из школьного курса экономики понял, что цена на товар (в частности, на труд) определяется балансом спроса и предложения. Так что если другая компания готова предложить этому конкретно выпускнику золотые горы и крутой офис, то почему бы ему не спросить об этом и эту компанию? Не предложат — не беда, в первую пойдем.
Если вакансия не закрыта уже полтора года, а работу работать надо — да, предлагать. Обучать, материться, если не подходит, и давать блага, чтобы не ушёл после всех "затрат", коими работодатель изначально попрекает.
Как вы думаете — зачем вообще нужен диплом? Ведь все те науки, что даются в ВУЗе — можно и на дому изучать. Программа — известна и в общем доступе. Репетиторов нанять и устроить себе индивидуальный курс — по месяцу на предмет — за полтора года пройдёте. Т.к. курс индивидуальный понятные вещи пробежите быстро, сложные — пробежите медленнее и понятнее (для вас). Ну так зачем ВУЗ? Если есть 2 кандидата: один без "бумажки", а второй — с "бумажкой"… Кому работодатель отдаст предпочтение?
Почему-то работодатели обычно требуют — второго… "Подтверждённого" специалиста. А подтверждённый специалист тратил своё время и деньги — "на бумажку", а значит его запросы будут априори ВЫШЕ, чем Васи Пупкина, который прошёл экспресс курс по программированию от Pluralsight. Да, работодатели "не довольны", ну так, ребята, вы сами сидели в носу ковыряли и думали, что вот вы вакансию открыли по статистически (хрен знает откуда взятой) средней цене и к вам сразу ломанулись толпами?
Как говорил один известный американский актёр, играя русского миллиционера в США: "капЫталЫзм"
Замечу что на практике работодатель частенько может брать без профильной бумажки если проверит что у кандидата есть опыт и навыки.
понимание подобного должно служить для него стимулом для развития разных навыковА по-моему, нет. Полезнее все же быть здравым эгоистом, и стимулом скорее должно служить отсутствие навыков, за которые рынок предлагает большие деньги. А как эти навыки сможет применить потенциальный работодатель — с прибылью для себя, с убытком, еще как-то — это работодателю решать.
Наброшу, как человек с зашкаливающим ЧСВ.
Сразу после выпуска с универа по специальности физика, то есть имея 0 лет стажа, начал искать работу в Data Science. Вакансии с окладом меньше $10,000 грязными в месяц я не рассматривал, ибо не смешно.
Как ни странно, работу я нашел, правда на галере, и даже текст на эту тему написал на хабр.
Одногруппники, которые искали похожего типа позиции так сильно борзометр подручивать не стали и рассматривали гораздо менее высокооплачиваемые позиции, которые они и получили в итоге.
Это я к тому, что дерзость и прочее ЧСВ это не всегда плохо, а скорее даже хорошо, ибо рынок все выровняет и кому-то прийдется поднимать зарплаты работникам, а кому-то понижать свои зарплатные ожидания до адекватного уровня и начинать активно заниматься самообучением.
Через 8 месяцев я поменял работу, во-первых, потому что работать на галерах — это не мое, а во-вторых, потому что выяснилось, что $10,000 грязными в месяц — это сильно ниже рынка для моего набора навыков. Не последнюю роль сыграло то, что контора использовала MatLab, что среди Data Science в 99% случаев будет рассматриваться, как устаревшая технология, а очень хотелось качать скилы в чем-то более модном, молодежном, эффективном и востребованном.
Но в целом, этот комментарий, конечно, наброс, потому что у меня дело происходило в Кремниевой долине, а тут своя специфика.
В калифорнии 120к грязными в год — это вроде зарплата миддла.
Так и есть. Но вот мои одногруппники, которые привыкли жить на $25k в год в аспирантуре считали за счастье, когда им предлагали $40-60, или же были эпизоды, когда они озвучивали $100k, а работодатель им в ответ: "Ну у тебя же опыта работы нет, поэтому мы тебе будем платить вот столько-то, зато дадим laptop и ты у нас многому научишься и вообще наша контора не такая как все" и они на это покупались.
Но у них у всех было общее, что наглости было маловато, и то, что они не желали сутками учиться, закрывая дыры в знаниях, а хотели как-то чтобы их наняли исключительно с тем, что у них было после окончания вуза.
$10,000 грязными в месяц?
Но то, что как мне показалось, в статье отсутствует, так это обратная ситуация — когда студентами вдруг оказываются те, кто вас принимает на работу или является вашим будущим начальником. И таких новоиспеченных организаций, с неправильно трактованной теорией с форума, сейчас очень много.
Для себя или других, на любимых вам и современных (по вашему мнению) технологиях.
Вы познаете себя и познаете других.
Если вы в дальнейшем придете трудоустраиваться и покажете какой-никакой продукт, на вас будут смотреть по другому.
Это говорит о целеустремленности, самозаинтересованности, трудолюбии, и амбициях в хорошем понимании этого слова.
Ты не «пустышка», пусть это будет очередной тетрис.
По-моему, на первом никто толком не писал, т.к. он был новым, глючным и 16 разрядным. Все начинали с D2.
В 99-м вышел Delphi 5, к тому времени D3 уже пару лет как был. В 99-м на D3 у нас был проект на полмиллиона строк в паскале и 200 кстрок Transact-SQL.
Региональная (челябинская) ЗП моих знакомых delphi программистов так и осталась на уровне 1000$, она была такой в 2006, потом 2011 и сейчас такая. Я называю это проклятье «тыщщидолларов» и думаю что причины две:
- Отсутствие конкуренции. Ты delphi программист и никуда от нас не денешься, потому что на миллионный город нет вакансий лучше. И люди сидят по 10-15 лет как у топикстартера
- Заточенность большинства delphi проектов на СНГ рынок, который абсолютно не эластичен к изменению курса валют
Всегда есть две стороны, помним об этом.
И люди сидят по 10-15 лет как у топикстартера
Будто это плохо.
Не все хотят скакать по модным проектам каждые год-два.
Я даже не знаю в случае Delphi + CRM, что может быть из этих двух.
Например, я пишу на Delphi в одном месте уже 8 лет. Мне сложно будет просто так, с кондачка перейти на другой язык, придется пару месяцев потренироваться, что-то пописать, освежить память, посмотреть последние стандарты и best practices. Но и текущая работа очень интересная. Вот сейчас к старому backendу еще тянущему родословную со времен MS-DOS прикручиваем JS морду. Интересных задач — полно и в be и во fe. Считать ли это развитием? Не знаю, но интересно же.
Делфи — это только инструмент. С таким же успехом можно говорить, что и на сишарпе и на жаве и на PHP 'узкоспециализированные знания'. Чем они лучше?
Но я говорю об объективных минусах, например, отсутствие конкуренции между работодателями и вследствие меньшей средней ЗП. Например, компания закрывается, в городе 1-2 Delphi вакансии 10-15 Java/JS у каких девелоперов ситуация устойчивей? Да Delphi просто инструмент, но с ним сложно быть гибким при смене работы или повышений ЗП, потому что могут «перекупить»
Тем, что на них вакансий в мире на порядки больше, чем на Delphi и его потомках. Что на это скажете?
www.tiobe.com/tiobe-index/csharp
Помрёт ваш любимый язык, и окажется, что больше вы делать ничего нигде не способны. Что будете делать? В дворники? Или на кассу в гипер?
Любой (вру, не любой, — адекватный) бизнес поднимет зарплату хорошему сотруднику, и не раз.
Свежо придание…
А расскажите, как изменилась зарплата ваших мидлов с 2007 года в среднем? Сколько она была в 2007 и сколько сейчас?
Так что нет, это не закрытая информация. А еще её можно получить, сделав соответствующий запрос в налоговую. Правда, что будет в выписке вполне очевидное — несоответствие придания реальности.
Я и ещё один мой однокурсник работали на одной фирме:
— Он пришёл на фирму ещё при прохождении практики в универе и прошёл весь путь с низов
— Я после университета проработал в другой фирме полтора года и перешёл в эту. Причина перехода кстати была та же — нежелание повышать зарплату джуниору.
Так вот в результате моя зарплата была больше, чем у моего однокурсника на 20% и эта разница сохранилась и через 5 лет работы в компании.
Так что про желание повышать зарплаты соразмерно вкладу и опыту — это сказки. Любой кто приходит в компанию на такую же должность будет получать больше, чем тот, кто в компании работает 5 лет. Просто потому что при найме компания готова переплатить чуть за хорошего сотрудника с опытом, а тому, кто работает в компании давно, достаточно кинуть косточку в размере инфляции ±1-2% раз в год.
Ибо работодатели до сих пор не особо горят желанием поднимать уровень зарплат до докризисного уровня.
Все с кем довелось эту тему обсудить, у кого с тех пор выросли зарплаты добились этого за счет карьерного роста/смены места работы, но никак не внутри одной компании на той же должности.
Поэтому и не верю в скази про любого/адекватного. Единицы так делают.
В мире Delphi дефицит работодателей. Значит основная мотивация повышать отсутствует
Угу. Попробуй найди работника на Delphi вакансию… У нас берут со знанием любых языков и переучивают.
Работал я тогда на должности инженер — эколог, у очень крупного ритейлера, и взбрело мне в голову, что смогу я быть программистом.
Будучи экологов мне приходилось обрабатывать огромные массивы данных практически вручную, только Excel и выручал. И в какой то момент мне пришла в голову мысль, что весь этот процесс можно автоматизировать. И взялся я за углублённым изучение Basic, благо основы программирования в институте были. Через примерно пол года было готова 0.0.1 версия моей программы. После полного цикла тестирования программа была внедрена, в ней работали около 60 экологов на филиалах. Позднее потребовалась переработка программы, т. к. в качестве хранения данных я использовал один xml файл в связке с msxml, что работало крайне медленно с «потолстевшим» xml-ником.
Программа была переписала на Delphi, с БД firebird в качестве хранения данных.
В результате, четыре года назад я был специалистом с опытом разработки и внедрения собственного, востребованного приложения, и который умел работать с:
— БД firebird, т. е. с SQL пришлось познакомиться;
— xml, отчёты в контролирующие органы формировались в xml;
— потоками, выгрузка отчётов для печати осуществлялась в отдельных потоках.
И чем закончились мои поиски работы программистом Delphi…
Собеседованием по Skype (даже тестового задания не было), опыта работы программистом, который бы был подтверждаем документально, у меня не было, и собеседующий мне сказал, что учить им некогда. Хотя вакансия висит и по сей день…
В настоящее время работаю программистом на 1С, технология мне очень не нравится, но платят относительно неплохо.
Всё это я написал к тому, что быть/стать программистом не сложно если ты нужного склада ума. Мне кажется не нужно пытаться найти студента, которого можно сразу бросить в бой, а нужно найти человека, который может сделать простейшие вещи и научить тому, что нужно вам, как говорил мой бывший руководитель: «найти подходящий мозг и вылепить из него, то что нужно». Кроме того, обычно устанавливается испытательный срок и за 3 месяца по человеку уже все понятно…
Во-первых фраза «Наша система имеет мало общего с новомодными CRM-ками, так как рассчитана на уважающий себя бизнес, желающий жить на рынке долго и счастливо, а не два месяца» меня, как опытного разработчика, сразу напрягла. По таким фразам можно практически безошибочно находить компании, в которых все сотрудники «кому за 30-40» и кто пишет на устаревших технологиях, выдавая это за фишку и за коммерческое преимущество. И это всего-лишь вопрос времени когда такая компания загнётся, если не захочет измениться и, в какой-то мере, начать всё сначала. Сейчас 90% клиентов приходят и хотят веб-приложение и чтобы неприменно в облаке…
Второй неприятный момент — это отношение к офисному окружению и оборудованию. Конечно никто не просит гамаки и бесплатные обеды, но стол для работы сидя/стоя, удобное кресло, компьютер не старше 3-х лет, пара мониторов — это тот минимальный набор, который показывает заботу о сотруднике и его здоровье. Также должна быть вода и кофе, приличный туалет с туалетной бумагой и мылом.
Третий момент — это критика образования без желания изменить что-либо. Во-первых университетская программа не ставит целью дать готового специалиста, а учит теории и тому, как добывать знания самостоятельно. Если вы реально заинтересованы в свежих и квалифицированных кадрах — заключите соглашение с каким-либо колледжем или университетом. Откройте там свою лабораторию или хотя бы читайте лекции для студентов, а в замен получите возможность выбирать лучших для своей фирмы. Да хотя-бы будьте базой для прохождения практики…
По поводу молодёжи — рынок довольно жесток. Если такие новички приходят и просят заоблачные деньги, то либо они так и останутся без работы, либо их кто-то купит за такие деньги. Если к вам пришёл хороший кандидат, но с завышенной самооценкой, то просто скажите ему как есть: вы нам понравились и мы вам можем предложить зарплату в размере Х. Жаль что вас не устраивает… Если в течении 2х месяцев передумаете — то милости просим… Т.е. дайте человеку чуть времени на осознание того, что ваше предложение — достойный вариант и что лучшего он не найдёт…
P.S.: пользуясь случаем, напоминаем, что мы ищем программиста Delphi и web-разработчика
Господи, оно ещё не вымерло?
Только вакансий по нему в моём родном городе меньше десятка (а когда-то был свыше десятка).
На мой взгляд, вся проблема в высшем образовании (это касается не только ИТ). Из университета должен выходить готовый специалист. Сейчас этого не происходит. Частично причины этого описаны в статье.
Не нужно мне рассказывать, что студент должен параллельно учебе заниматься самообразованием, пилить пет-проекты и работать стажером за спасибо. Зачем тогда в этой схеме вообще нужен университет? 5-6 лет жизни только ради корочек?
В итоге имеем завышенные ожидания студентов, которые уверены, что после получения диплома о высшем образовании, их должны брать в любую компанию. Завышенные ожидания работодателя, который ожидает, что человек 6 лет учившийся на программиста должен уметь программировать на хорошем уровне (что вообще-то правильно). И абсолютное не соответствие этим ожиданиям самих университетов.
У нас в команде фронт веба пишет человек без высшего образования. Что, впрочем, не мешает делать замечательные вещи, за которые платят.
Отличная мозговправляющая статья. Спасибо!
Автор, у вас полный трэш начиная с того, что у вас директор — главный разработчик. Если бы он был нормальным директором, он бы вам объяснил, что зарплаты берутся не от "умения и опыта", а от рыночного спроса.
Не говоря уже о том, что вы пишете на Дельфи в 2017-ом году.
Ну, если прибыль — единственное, что важно, то есть более прибыльные сферы. Обычно важен ещё и интерес к процессу.
Вы на вакансии компаний посмотрите, которые они закрыть годами не могут, оцените рынок труда — современная экономика требует гигантское количество кадров, но хотя бы с минимальной квалификацией и пониманием того, как учиться работать в бизнесе.
Прям в точку. Прям крик души…
Burst, огорчу Вас, вероятно, но все вакансии у нас закрыты. Но тем не менее, у нас всегда висит призыв приходить к нам, как продажникам, так и разработчикам. Поскольку "звезда" может прийти не в тот момент, когда вакансия будет горячей. Если на горизонте появится достойный человек, вписывающийся в нашу команду, уж фронт работы для него мы найдем :)
Нет, это не будет в ущерб учёбе: всегда можно найти компанию, с которой договориться о работе на полдня или с плавающим графиком
Реальность, на мой взгляд выглядит несколько иначе:
1. Компаниям не нужны такие «на полдня» и с «плавающим графиком». Тут есть противоречие с желанием компаний чтобы сотрудник пришел и решал бизнес-задачи. Это нормальное желание бизнеса. Тех кто берет стажеров и учит и воспитывает, несравненно мало. Это могут позволить себе не все компании. Потому что это время (как известно — деньги). И сами деньги. То есть деньги вдвойне. Почему-то, предполагаю, что подавляющее большинство компаний с периферии не могут себе это позволить в принципе.
2. Реальность (возможно только в которой нахожусь я), говорит о том, что компании редко повышают компенсацию. Опять же не скажу за Москву, но, на мой взгляд, тут перекос снова в сторону регионов. Все по тем же причинам из п.1.
3. Реальность (по моим наблюдениям), такова, что, несколько нелепо выглядят жалобы работодателя на запросы разработчиков, и размеры компенсации, в условиях, когда компании «экономят» на сотрудниках. Сейчас поясню про какую экономию. Нелепо потому, что, давайте признаем факт, что достаточно компаний на рынке, которые платят не «белую» зарплату. Потому что вы знаете почему. Налоги, отчисления, в итоге «белая» зарплата разработчика скажем в 100 тысяч, «обходится» работодателю во все реальные 150 тысяч и возможно более. Так вот я хочу, только в данном аспекте, некой моральной хотя бы справедливости. Давайте говорить о завышенных требованиях разработчиков, и о желаемых ими требованиях компенсации, когда все компании перестанут ухищряться «экономить». И снова перекос между периферией и центром. Я работаю в условиях той реальности, что в регионы приходят компании из центра, с бо'льшими деньгами, и нанимают не по «центральным» зарплатам разработчиков, да еще и пытаются посадить на «две» зарплаты. Или другие варианты как оформление ИП и т.д.
4. Позитивный момент в том, что вариантов как для компаний так и для разработчиков довольно много, предложений и вариантов масса и на любой вкус и размер компенсации. И тогда, снова нелепо, выглядят жалобы бизнеса на «отсутствие» вариантов на рынке.
5. Реальность в которой живу я, такова что мир вообще не справедлив. И все эти разговоры всегда как качели — то в одну, то в другую сторону. Пример: в моей реальности, я хочу писать на Clojure, и ни одна компания, пока, не готова меня взять, просто потому, что на первый же вопрос о коммерческом опыте разработки на Clojure, получают отрицательный ответ, разворачиваются и уходят в интернет искать дальше Clojure ниндзя. Снова нелепо выглядят жалобы на отсутствие моего желания как разработчика и отсутствие предложений. Я, в свою очередь, понимая отсутствие оного опыта, существенно готов ущемить себя в размере финансовой компенсации. Прямо заявляю об этом. Но почему-то часть компаний это не интересует, а иногда, по моим наблюдениям, даже пугает. Но реальность такова, что это не значит, что я в тупике и выхода нет и все пропало. Он есть. И тот самый рынок, дает такие варианты.
Подводя итог: перекос всегда есть и будет. Не хочется сыпать прописными истинами, вроде той, которую только что «ляпнул», и подобными: «недовольные есть всегда и везде», «про трудности жизни и ведения бизнеса», «не бывает незаменимых сотрудников»(тема на отдельный холивар на 1000 комментариев) и т.д.
Надо просто сказать, спасибо тому что есть. А работать над «собой» надо обеим сторонам. Надеюсь я не был слишком категоричен.
Уверен, что ваша версия реальности может быть координально другой. Это нормально и я ее заведомо принимаю, по причинам указанным выше.
Шлифануть это парой фильмов про Силиконовую долину
Почему удалили мой комментарий, где я говорил, что правильно не Силиконовая долина, а Кремниевая? От этого долина не станет Силиконовой, поэтому это по прежнему ошибка.
Оба варианта используются, и незачем холиворить. К тому же, силиконовая звучит прикольнее)
Silicon Valley — Кремниевая Долина.
Silicone Valley — Силиконовая долина.
И незачем холиварить да, нужно просто использовать правильный перевод.
а тут дельфи на мегатонныНе только, и не столько:
в «масштабах планеты», желательно получить гибрид TP+Oberon+Modula-3+ADA с лучшими качествами и языков, и IDE, и систем доказательств правильности ПО
А ещё тут экскурсы в историю Ж-)
P.S. Начали дискуссию как-раз разочаровавшиеся в «европейской школе» Ж-)
Итак, мы — небольшая компания, которая делает CRM-системы и софт для бизнеса.я перестал читать
Вы не работник этой ли конторы?
Я к сожалению не помню сколько там строк кода было, но в чем вы меряете сложность, вам подавай много математики и алгоритмы на графах и подобном?
Но у вас, как мне кажется, замечательная реакция на критику. И правда, умный человек больше ценит обличение ошибок, нежели похвалу.
Удачи! :)
Необразованная молодёжь. Ответ бизнеса