Тут речь не о нежелании, а об очень высоких требованиях к информационной безопасности.
У нас даже уделенный доступ к тестовому серверу организован с кучей приплясов (чтобы «пообщаться» с ним нужно сначала зайти в банковскую внутреннюю сеть по VPN с персональным сертификатом — сервер свой, сертификаты тоже свои, привязаны к логину сотрудника, затем из этой сети зайти на виртуалку удаленным рабочим столом с двухфакторной аутентификацией по персональному токену и только на ней можно запустить терминал 5250 для работы на тестовом сервере), что уж говорить о боевом.
И это не сисадмины. Точнее, не только сисадмины. Это дежурная смена службы сопровождения. Те люди, которые должны моментально реагировать на любой сбой работы системы и устранять его в кратчайшие сроки. Это может быть откат некорректно работающего патча, отключение какой-либо подсистемы, мешающей работе всего остального и еще куча невообразимых нештатных ситуаций.
Увы, но есть строго определенные регламенты по срокам устранения нештатных ситуаций. Диктуются они регулятором по времени недоступности разного уровня систем банка. Нарушение сроков ведет не только к финансовым и репутационным потерям, но и штрафам со многими нулями со стороны регулятора.
Ну… Не знаю. Не жил там достаточно долго чтобы судить об этом.
Чтобы составить суждение о системности проблем нужно или там жить, или регулярно мониторить местную прессу. Такие вещи в первую очередь вылазят там, а не в «новостях со всего мира». Вряд ли в евроньюс или подобных СМИ вы часто встретите новость о том, как в каком-нибудь пригороде Парижа полицейские подбросили пакет травы какому-нибудь арабу. И с поверхностной точки зрения системной проблемы как бы и нет.
Равно как и рядовой француз тоже не в курсе насколько часто это случается у нас.
Европа весьма неоднородна. В Англии у патрульных вообще оружия нет. Во Франции полиция та еще в плане морального облика.
Но в целом во всем мире главное назначение силовых структур отнюдь на в защите граждан.
В общем, я б не стал идеализировать. Более-менее адекватно сравнивать можно пожив там (и поработав) годик-другой. Просто чтобы на все это изнутри посмотреть.
У меня просто нет информации изнутри. И нет такой же информации, скажем, а NASA. Сравнивать можно только по внешним данным.
Аварии и неудачные запуски бывают везде. В том числе и с тяжелыми последствиями и человеческими жертвами.
Ну и космос такая штука… НА сегодняшний день уже практически признали что ни одна страна в мире не может полностью самостоятельно вести рентабельные космические программы в полном объеме. Т.е. спутник сделать можем, но вывести на орбиту нечем. Или все есть, но нет двигателей для носителей.
Тут ничего не могу сказать — не эксперт и не претендую на компетентность. Могу только озвучить взгляд со своей болотной кочки.
Мне кажется, что проблема автоваза в отсутствии конкуренции. Точнее, в недобросовестной конкуренции. Убери все дотации и поддержки со стороны государства — он разорится. А пока есть поддержка, можно особо не заботится о прибылях и убытках — государство все равно все покроет просто ради того, чтобы он был. Т.е. нет мотивации для нормальной работы.
Про роскосмос вообще ничего не могу сказать. На мой взгляд там все в среднем не хуже чем у остальных. «Победоносное его шествие» во времена былые — видимость. Там все было настолько закрыто, что мы просто не знали как оно там внутри на самом деле. Сейчас узнали и нам кажется что все плохо.
Ну и плюс условия финансирования и работы стали совсем другие. А это очень ресурсоемкая отрасль.
Но это всего лишь мои ощущения, без претензий на истину.
Я так понимаю, что сейчас вопрос встанет в иной плоскости: «нам нужно вот это, но заплатить больше чем… мы не можем. Хотите — беритесь за озвученную сумму, не хотите — не беритесь».
Более-менее все останется как было в тех областях, которые меньше просядут. Но, по моему разумению, это те области где раньше доходы IT не были топовыми по отрасли.
Иными словами, произойдет общее снижение доходов при их выравнивании.
А с чего ему быть иным? Дело не в дотационности, а в количестве «шальных» денег в экономике. Тех денег, что обеспечены не производством некоего материального продукта, но продажей ресурсов по завышенным ценам (та самая «нефть по 140»).
А дальше простой баланс — денег много, а единиц товара, которые можно за них купить, мало. Соответственно, каждая единица будет стоить дорого.
Когда количество денег снижается, а единиц товара остается столько же, стоимость единицы, естественно, падает.
Весьма примитивно, но в целом как-то так.
ИТ — это в некоторой степени сфера услуг. И цена на нее формируется исходя из того, сколько заказчик себе может позволить (состояние его кошелька). Когда кошелек худеет, заказчик или сокращает свои хотелки, или предлагает за них меньшую цену.
А теперь прикиньте что останется вам в таком варианте — американец нанимает задешево (в его понимании) индуса, который опять же задешево (уже в своем понимании) нанимает вас.
А какие характерные времена у Вас используются?
Не пробовали усреднение добавлять? Скажем, время измерения 1сек, считается усредненная температура за 10 последних измерений?
Усреднение может быть как арифметическим, так и по алгоритму ФНЧ —
Y[i] = a * X[i] + (1 — a) * Y[i-1]
Первый вариант более гладкий, второй быстрее реагирует на изменения температуры
Ну можно еще с двойным экспоненциальным сглаживанием поиграться:
Y[i] = a * X[i] + (1 — a) * (Y[i — 1] + b[i — 1])
b[i] = c * (Y[i] — Y[i — 1) + (1 — c) * b[i — 1]
А вот тут позвольте с Вами согласиться. На личном опыте.
Долгое время занимался разработкой в области, близкой к промавтоматизации — распределенная гетерогенная система на микроядерной архитектуре. Получил большой опыт в области многопоточной обработки и межпроцессного обмена данными. Просто на уровне понимания как надо такие вещи строить. От протоколов и до распределения функционала по нагрузке.
Потом пришел в финтех. Абсолютно другая платформа (AS/400 это вам не винда или никсы какие), другой язык (точнее, другая концепция — ILE — Integrated Language Environment где можно написать несколько модулей на разных языках и собрать все в единую программу), другие сущности.
И попалась мне задача, где нужно было обработать в сжатое время существенный объем данных. Решается путем распараллеливания обработки на несколько заданий (job). Одно задание — мастер — раздает пачки десяти исполнителям, получает и фиксирует результаты.
Очень мог предыдущий опыт. Достаточно было просто разобраться с транспортами, которые предоставляет платформа (а их несколько — unixsocket, socketpair, pipe, dataqueue, userqueue) и использовать те, что наиболее подходят для реализации данной конкретной задачи.
Все это по большей части от стеков не зависит, вещи скорее архитектурные. Стеки уже на уровне конкретной реализации задействуются. Когда знаешь что и как реализовывать.
стажер — ? работает 20 часов в неделю. Обычно или человек совсем без опыта или студенты старших курсов
разработчик — джуниор
старший разработчик может быть как джуниором, так и мидлом
ведущий — мидл или сеньор (у нас тимлид долго был ведущим — не было ставок главных)
главный — сеньор
Так что все эти деления достаточно условны на самом деле.
Вообще, по-хорошему, грамотный разработчик должен еще неплохо себе представлять что внутри у того или иного фреймворка. А также ориентироваться в чисто архитектурных вопросах — где выгоднее использовать многопоточность, а где удобнее разделить выполнение на процессы. В каком случае выгоднее использовать синхрон в разных потоках/процессах, а в каком асинхрон в одном. Какие бывают транспорты и протоколы обмена данными между потоками и процессами и их плюсы и минусы.
При многопоточной/многопроцессоной работе как правильно распределить функции (нагрузку) между потоками/процессами.
Во всем этом неплохо хотя бы просто ориентироваться, а не упираться в возможности конкретной библиотеки.
Ну… А как отличить джуна от мидла? У нас в конторе джун — прежде всего то, кто пишет строго по FSD во-первых и требует обязательного кодревью во-вторых.
Мидл уже может более творчески подходить к FSD (он способен увидеть решение более оптимальное, нежели написано в FSD) и не требует столь жесткого контроля в плане кодревью.
Сеньор уже сам может участвовать в разработке FSD (как в плане алгоритмирования, так и в оценке), сам проводить кодревью и вообще быть наставником для джунов.
У нас сеньор кроме технологий разработки еще должен неплохо понимать тонкости платформы под которую идет разработка и еще неплохо ориентироваться в предметной области и понимать бизнес-процесс.
Иными словами, джуниор пишет строго по FSD, а сеньор может сам вносить корректировки в FSD. И при разработке FSD к нему как минимум могут обратиться за советом.
FSD в нашем случае это не только ТЗ, но и документация по задаче. Если задача потом кому-то придет на доработку, то FSD поможет человеку быстрее вникнуть в чужой код.
К сожалению, некоторые рекрутеры именно так и считают. Точнее, они ищут готового разработчика под конкретный стек и начальную позицию в компании определяют именно исходя из того, насколько человек знает этот стек
Человек с опытом разработки уже обладает как минимум навыками алгоритмического мышления.
Кроме того, имея опыт разработки на условном cobol, человек знает как его сильные, так и слабые стороны. И, переходя на новый стек, такой человек найдет там для себя то, чего ему не хватало в старом. И будет этим пользоваться.
У нас даже уделенный доступ к тестовому серверу организован с кучей приплясов (чтобы «пообщаться» с ним нужно сначала зайти в банковскую внутреннюю сеть по VPN с персональным сертификатом — сервер свой, сертификаты тоже свои, привязаны к логину сотрудника, затем из этой сети зайти на виртуалку удаленным рабочим столом с двухфакторной аутентификацией по персональному токену и только на ней можно запустить терминал 5250 для работы на тестовом сервере), что уж говорить о боевом.
И это не сисадмины. Точнее, не только сисадмины. Это дежурная смена службы сопровождения. Те люди, которые должны моментально реагировать на любой сбой работы системы и устранять его в кратчайшие сроки. Это может быть откат некорректно работающего патча, отключение какой-либо подсистемы, мешающей работе всего остального и еще куча невообразимых нештатных ситуаций.
Увы, но есть строго определенные регламенты по срокам устранения нештатных ситуаций. Диктуются они регулятором по времени недоступности разного уровня систем банка. Нарушение сроков ведет не только к финансовым и репутационным потерям, но и штрафам со многими нулями со стороны регулятора.
Чтобы составить суждение о системности проблем нужно или там жить, или регулярно мониторить местную прессу. Такие вещи в первую очередь вылазят там, а не в «новостях со всего мира». Вряд ли в евроньюс или подобных СМИ вы часто встретите новость о том, как в каком-нибудь пригороде Парижа полицейские подбросили пакет травы какому-нибудь арабу. И с поверхностной точки зрения системной проблемы как бы и нет.
Равно как и рядовой француз тоже не в курсе насколько часто это случается у нас.
Но в целом во всем мире главное назначение силовых структур отнюдь на в защите граждан.
В общем, я б не стал идеализировать. Более-менее адекватно сравнивать можно пожив там (и поработав) годик-другой. Просто чтобы на все это изнутри посмотреть.
Аварии и неудачные запуски бывают везде. В том числе и с тяжелыми последствиями и человеческими жертвами.
Ну и космос такая штука… НА сегодняшний день уже практически признали что ни одна страна в мире не может полностью самостоятельно вести рентабельные космические программы в полном объеме. Т.е. спутник сделать можем, но вывести на орбиту нечем. Или все есть, но нет двигателей для носителей.
Полицаи везде полицаи. И в некоторых конкретных странах прав у них больше чем в других конкретных странах. В том числе и в плане применения оружия.
Где-то героин в карман, где-то стреляют на поражение потому что «показалось что потянулся за пистолетом».
Мне кажется, что проблема автоваза в отсутствии конкуренции. Точнее, в недобросовестной конкуренции. Убери все дотации и поддержки со стороны государства — он разорится. А пока есть поддержка, можно особо не заботится о прибылях и убытках — государство все равно все покроет просто ради того, чтобы он был. Т.е. нет мотивации для нормальной работы.
Про роскосмос вообще ничего не могу сказать. На мой взгляд там все в среднем не хуже чем у остальных. «Победоносное его шествие» во времена былые — видимость. Там все было настолько закрыто, что мы просто не знали как оно там внутри на самом деле. Сейчас узнали и нам кажется что все плохо.
Ну и плюс условия финансирования и работы стали совсем другие. А это очень ресурсоемкая отрасль.
Но это всего лишь мои ощущения, без претензий на истину.
Я так понимаю, что сейчас вопрос встанет в иной плоскости: «нам нужно вот это, но заплатить больше чем… мы не можем. Хотите — беритесь за озвученную сумму, не хотите — не беритесь».
Более-менее все останется как было в тех областях, которые меньше просядут. Но, по моему разумению, это те области где раньше доходы IT не были топовыми по отрасли.
Иными словами, произойдет общее снижение доходов при их выравнивании.
А дальше простой баланс — денег много, а единиц товара, которые можно за них купить, мало. Соответственно, каждая единица будет стоить дорого.
Когда количество денег снижается, а единиц товара остается столько же, стоимость единицы, естественно, падает.
Весьма примитивно, но в целом как-то так.
ИТ — это в некоторой степени сфера услуг. И цена на нее формируется исходя из того, сколько заказчик себе может позволить (состояние его кошелька). Когда кошелек худеет, заказчик или сокращает свои хотелки, или предлагает за них меньшую цену.
А какие характерные времена у Вас используются?
Не пробовали усреднение добавлять? Скажем, время измерения 1сек, считается усредненная температура за 10 последних измерений?
Усреднение может быть как арифметическим, так и по алгоритму ФНЧ —
Y[i] = a * X[i] + (1 — a) * Y[i-1]
Первый вариант более гладкий, второй быстрее реагирует на изменения температуры
Ну можно еще с двойным экспоненциальным сглаживанием поиграться:
Y[i] = a * X[i] + (1 — a) * (Y[i — 1] + b[i — 1])
b[i] = c * (Y[i] — Y[i — 1) + (1 — c) * b[i — 1]
Долгое время занимался разработкой в области, близкой к промавтоматизации — распределенная гетерогенная система на микроядерной архитектуре. Получил большой опыт в области многопоточной обработки и межпроцессного обмена данными. Просто на уровне понимания как надо такие вещи строить. От протоколов и до распределения функционала по нагрузке.
Потом пришел в финтех. Абсолютно другая платформа (AS/400 это вам не винда или никсы какие), другой язык (точнее, другая концепция — ILE — Integrated Language Environment где можно написать несколько модулей на разных языках и собрать все в единую программу), другие сущности.
И попалась мне задача, где нужно было обработать в сжатое время существенный объем данных. Решается путем распараллеливания обработки на несколько заданий (job). Одно задание — мастер — раздает пачки десяти исполнителям, получает и фиксирует результаты.
Очень мог предыдущий опыт. Достаточно было просто разобраться с транспортами, которые предоставляет платформа (а их несколько — unixsocket, socketpair, pipe, dataqueue, userqueue) и использовать те, что наиболее подходят для реализации данной конкретной задачи.
Все это по большей части от стеков не зависит, вещи скорее архитектурные. Стеки уже на уровне конкретной реализации задействуются. Когда знаешь что и как реализовывать.
Скорее так
стажер — ? работает 20 часов в неделю. Обычно или человек совсем без опыта или студенты старших курсов
разработчик — джуниор
старший разработчик может быть как джуниором, так и мидлом
ведущий — мидл или сеньор (у нас тимлид долго был ведущим — не было ставок главных)
главный — сеньор
Так что все эти деления достаточно условны на самом деле.
Вообще, по-хорошему, грамотный разработчик должен еще неплохо себе представлять что внутри у того или иного фреймворка. А также ориентироваться в чисто архитектурных вопросах — где выгоднее использовать многопоточность, а где удобнее разделить выполнение на процессы. В каком случае выгоднее использовать синхрон в разных потоках/процессах, а в каком асинхрон в одном. Какие бывают транспорты и протоколы обмена данными между потоками и процессами и их плюсы и минусы.
При многопоточной/многопроцессоной работе как правильно распределить функции (нагрузку) между потоками/процессами.
Во всем этом неплохо хотя бы просто ориентироваться, а не упираться в возможности конкретной библиотеки.
стажер
разработчик
старший разработчик
ведущий разработчик
главный разработчик
ну и далее еще более размыто:
консультант направления
архитектор направления
руководитель направления
И кто из них кто?
Мидл уже может более творчески подходить к FSD (он способен увидеть решение более оптимальное, нежели написано в FSD) и не требует столь жесткого контроля в плане кодревью.
Сеньор уже сам может участвовать в разработке FSD (как в плане алгоритмирования, так и в оценке), сам проводить кодревью и вообще быть наставником для джунов.
Деление несколько условное, но примерно так.
У нас сеньор кроме технологий разработки еще должен неплохо понимать тонкости платформы под которую идет разработка и еще неплохо ориентироваться в предметной области и понимать бизнес-процесс.
Иными словами, джуниор пишет строго по FSD, а сеньор может сам вносить корректировки в FSD. И при разработке FSD к нему как минимум могут обратиться за советом.
FSD в нашем случае это не только ТЗ, но и документация по задаче. Если задача потом кому-то придет на доработку, то FSD поможет человеку быстрее вникнуть в чужой код.
Человек с опытом разработки уже обладает как минимум навыками алгоритмического мышления.
Кроме того, имея опыт разработки на условном cobol, человек знает как его сильные, так и слабые стороны. И, переходя на новый стек, такой человек найдет там для себя то, чего ему не хватало в старом. И будет этим пользоваться.