Comments 45
UFO just landed and posted this here
Сегодня таких проблем радикально меньше.
Тем более что на беке свои танцы с бубном.
А где интереснее/сложнее/больше платят зависит от проекта.
Я бы весы, в среднем сдвинул в сторону бека, но в конечном итоге все зависит от человека и его умения договариваться искать правильный проект.
P.S.
Тем более сегодня клиентское ПО сильно усложняется и уже 50% вакансий это разделение верстки и программирование на JS.
интровертам в бэке комфортнее: никто не пристает с "поехавшим дизайном в браузере ХХХ" и можно спокойно вылизывать свой код (в идеале, конечно).
имхо, миф о сложности основан на требованиях к стабильности, которые влекут за собой требования к ответственности и/или опыту.
падение красивого фронта всяко приносит меньше проблем, чем падение непонятного бэка: откатить страничку (утрировано) всяко сложнее/дольше/дороже, чем базу/сервер.
И на фронте и на бэке свои плюшки. У фронтов постоянные проблемы типа «а на моем телефоне не работает».
На бэке — сопровождение «поставку не согласуем т.к. фукнция xxx жрет 30% процссорных ресурсов выделенных заданию что недопустимо».
Или как недавно было — все тесты прошли, включая нагрузку, а на проме упало. По джоблогам и дампам примерно понятна проблема, но воспроизвести не удается никак и нигде. Соответственно, подозрительный участок кода переписан, но внедряться страшно т.к. проверить что помогло не получается.
А модуль работает в таком участке, где лажать нельзя — прокол может обернуться штрафом со многими нулями от регулятора (в лучшем случае).
На бэке — сопровождение «поставку не согласуем т.к. фукнция xxx жрет 30% процссорных ресурсов выделенных заданию что недопустимо».
Или как недавно было — все тесты прошли, включая нагрузку, а на проме упало. По джоблогам и дампам примерно понятна проблема, но воспроизвести не удается никак и нигде. Соответственно, подозрительный участок кода переписан, но внедряться страшно т.к. проверить что помогло не получается.
А модуль работает в таком участке, где лажать нельзя — прокол может обернуться штрафом со многими нулями от регулятора (в лучшем случае).
интровертам в бэке комфортнее: никто не пристает с «поехавшим дизайном в браузере ХХХ» и можно спокойно вылизывать свой код (в идеале, конечно).
Ну…
Мне например приходится время от времени вступать в дискуссии с project owner потому что он считает, что всю работу в бекенде можно сделать быстро и дёшево и уже вчера. А я просто цену себе набиваю.
Не видя визуальной части, он считает, что тут на бэкенде как бы ничего и не делается.
Фронтендеру-интраверту, имхо, проще — ничего объяснять не нужно, всё видно.
Всегда скучно было рисовать интерфейсы. Ну не мое это. А вот колупаться в потрохах, системных API, быть близко к железу, в том числе и нестандартному, это нравилось и нравится.
Хотя интерфейсы разрабатывать приходилось, и получалось неплохо в плане функциональности и удобства. Но не увлекало. Так что в сторону бэка сместился уже очень давно.
Хотя к вебу никакого отношения не имею и не имел. Долгое время занимался разработкой системы мониторинга инженерного оборудования зданий. Система была гетерогенной, распределенной, построенной на микроядре. Т.е. в центре некое ядро, к нему цепляются и через него общаются удаленные микроконтроллеры (IP-шлюзы, за которыми уже на 485-м интерфейсе висели контроллеры нижнего уровня) и удаленные же интерфейсные клиенты (различной тематической направленности). Там занимался тем самым микроядром — архитектура, протоколы обмена и все прочее.
Сейчас банк. Ядровые функции автоматизированной банковской системы. То, что работает на мейнфрейме IBM i. В общем случае все, что работает на фронтах, общается с АБС через вебсервисы. Которые вызывают некие универсальные процедуры на мейнфрейме, а те уже дергают различные обработчики — вот их и пилим.
Хотя интерфейсы разрабатывать приходилось, и получалось неплохо в плане функциональности и удобства. Но не увлекало. Так что в сторону бэка сместился уже очень давно.
Хотя к вебу никакого отношения не имею и не имел. Долгое время занимался разработкой системы мониторинга инженерного оборудования зданий. Система была гетерогенной, распределенной, построенной на микроядре. Т.е. в центре некое ядро, к нему цепляются и через него общаются удаленные микроконтроллеры (IP-шлюзы, за которыми уже на 485-м интерфейсе висели контроллеры нижнего уровня) и удаленные же интерфейсные клиенты (различной тематической направленности). Там занимался тем самым микроядром — архитектура, протоколы обмена и все прочее.
Сейчас банк. Ядровые функции автоматизированной банковской системы. То, что работает на мейнфрейме IBM i. В общем случае все, что работает на фронтах, общается с АБС через вебсервисы. Которые вызывают некие универсальные процедуры на мейнфрейме, а те уже дергают различные обработчики — вот их и пилим.
как тесен мир!
это я про веб-сервисы, которые дергают EQ :)
Можно узнать, а какой стек на IBM i?
Это бывшая AS/400 со всеми вытекающими. ILE, включающая в себя CL, RPG, COBOL, C/C++ (компиляторы встроенные, любой программный объект может содержать несколько модулей на разных языках, главное правилтно интерфейсы прописать, функции сишной RTL можно высывать, например, из программ на RPG). Отладчик встроенный, БД встроенная, DB2.
Пишем в основном на RPG, но бывает и на С, если это удобнее. Достаточно много сервисных программ написано на С/С++.
Средства разработки — RDi (IDE на базе эклипса, заточенная на работу с ас-кой. Т.е. пишешь на обычном компе, потом оно все забрасывает на сервер и там собирает. Для пущего удобства приручен gradle — пишутся сборочные скрипты, которые обрабатываются плагином.
Обычный путь — сначала гредлом с компа ставим в девелоперский юнит (проверка что все собирается), оттуда ручным запуском сгенерированного гредлом же инсталлятора в эмуляторе терминала ставим в песочнтцу (копия юнита компонентного тестирования). Если там работает, то коммитися в битбакет, оттуда подхватывает дженкинс и кладет поставку в артифактори. А оттуда уже аналитики девопсом ставят куда им надо для тестов.
В целом как везде — есть типовые задачи, а есть такие, над которыми думать надо.
Пишем в основном на RPG, но бывает и на С, если это удобнее. Достаточно много сервисных программ написано на С/С++.
Средства разработки — RDi (IDE на базе эклипса, заточенная на работу с ас-кой. Т.е. пишешь на обычном компе, потом оно все забрасывает на сервер и там собирает. Для пущего удобства приручен gradle — пишутся сборочные скрипты, которые обрабатываются плагином.
Обычный путь — сначала гредлом с компа ставим в девелоперский юнит (проверка что все собирается), оттуда ручным запуском сгенерированного гредлом же инсталлятора в эмуляторе терминала ставим в песочнтцу (копия юнита компонентного тестирования). Если там работает, то коммитися в битбакет, оттуда подхватывает дженкинс и кладет поставку в артифактори. А оттуда уже аналитики девопсом ставят куда им надо для тестов.
В целом как везде — есть типовые задачи, а есть такие, над которыми думать надо.
Интересно, спасибо.
Да не за что. Система очень мощная не похожая ни на что другое (концептуально она объекно-ориентированная — «все есть объект»). И самодостаточная. Т.е. в ней сразу есть все что надо. И компиляторы и отладчик и БД и инструменты администрирования.
Если кому интересно — книга одного из отцов-основателей: Френк Солтис «Основы AS/400». От истории создания до внутреннего устройства весьма доходчивым языком.
От ILE (Integrated Language Environment) просто в восторге. Поскольку до этого без малого 30 на С/С++, то возможность часть задачи, там где это удобнее, писать на С, а часть на RPG очень радует. В целом работа с таблицами, строками, экранными и принтерными формами на RPG удобнее, а вот всякие системные вещи типа организации распараллеливания с межпроцессным взаимодействием через сокеты, динамические массивы и списки — это удобнее на С/С++.
Пишешь кусок кода на RPG, кусок на C/C++. Потом каждый кусок компилится в отдельный модуль (аналог объектного файла) и потом уже все модули собираются в единый программный объект.
Если кому интересно — книга одного из отцов-основателей: Френк Солтис «Основы AS/400». От истории создания до внутреннего устройства весьма доходчивым языком.
От ILE (Integrated Language Environment) просто в восторге. Поскольку до этого без малого 30 на С/С++, то возможность часть задачи, там где это удобнее, писать на С, а часть на RPG очень радует. В целом работа с таблицами, строками, экранными и принтерными формами на RPG удобнее, а вот всякие системные вещи типа организации распараллеливания с межпроцессным взаимодействием через сокеты, динамические массивы и списки — это удобнее на С/С++.
Пишешь кусок кода на RPG, кусок на C/C++. Потом каждый кусок компилится в отдельный модуль (аналог объектного файла) и потом уже все модули собираются в единый программный объект.
Я относительно неплохо был знаком с System/370 (MVS, VM), но AS/400 уже не застал, потрогать руками не довелось. Знаю только, что принципиально отличается во всём, совершенно другая система. Поэтому было интересно в общих чертах узнать. :)
Собственно это система, которую все хотят создать — но ни у кого не получается. Потому что, как бы, даже здесь видно: всё зашибись, классно, «в ней сразу есть все что надо»… вот только среда разработки… оп-па — на базе Eclipse на совсем другой операционке.
То есть уже видно, что оно нифига не самодостаточное — вот те задачи, которые решили на нём поддержать разработчики — те и нормально отрабатываются. А что «не шмогли» (или не захотели) — того и нету вообще.
А вот для персоналок (или смартфонов) — такой подход не прокатывает. Так как они зачастую — единственная железяка, которая у пользователя есть. Соответственно если что-то на вашей платформе нельзя сделать, а на платформе конкурента можно… так и всё, собственно. Вы проиграли.
То есть уже видно, что оно нифига не самодостаточное — вот те задачи, которые решили на нём поддержать разработчики — те и нормально отрабатываются. А что «не шмогли» (или не захотели) — того и нету вообще.
А вот для персоналок (или смартфонов) — такой подход не прокатывает. Так как они зачастую — единственная железяка, которая у пользователя есть. Соответственно если что-то на вашей платформе нельзя сделать, а на платформе конкурента можно… так и всё, собственно. Вы проиграли.
Система самодостаточна в рамках своего предназначения — высокопроизводительные коммерческие серверы.
Саодостаточность в том, что в нее все необходимое уже интегрировано на уровне самой системы. Т.е. таблица БД это не просто файл, но системный объект.
Там сразу будет и БД и компиляторы и отладчик. И да, есть SEU — редактор для написания кода. Есть интерактивный SQL.
Но это сервер. У него нет монитора, нет клавиатуры. Общение с ним идет черех удаленный терминал IBM5250 или его программный эмулятор. Там все хардкорно — текстовые менюшки и команды языка CL.
Понятно, что через RDi работать удобнее. Хотя можно пользоваться любой средой, есть любители Visual Code, кто-то вообще в Notepad++ пишет. Без разницы, если настроишь гредл.
Есть проект, в нем исходники плюс скрипты под гредл плагин. Написал, потом gradle as400syncdeploy и оно само сгенерируе программу инсталлятор, забросит все на сервер, скомпилирует и запустит там инсталлятор.
Просто в RDi это делается нажатием кнопки, а к другой среде или прикручивать в инструменты или просто запустить из командной строки.
Это нормальная кроссплатформенная разработка. Это свой мир со своими порядками.
Саодостаточность в том, что в нее все необходимое уже интегрировано на уровне самой системы. Т.е. таблица БД это не просто файл, но системный объект.
Там сразу будет и БД и компиляторы и отладчик. И да, есть SEU — редактор для написания кода. Есть интерактивный SQL.
Но это сервер. У него нет монитора, нет клавиатуры. Общение с ним идет черех удаленный терминал IBM5250 или его программный эмулятор. Там все хардкорно — текстовые менюшки и команды языка CL.
Понятно, что через RDi работать удобнее. Хотя можно пользоваться любой средой, есть любители Visual Code, кто-то вообще в Notepad++ пишет. Без разницы, если настроишь гредл.
Есть проект, в нем исходники плюс скрипты под гредл плагин. Написал, потом gradle as400syncdeploy и оно само сгенерируе программу инсталлятор, забросит все на сервер, скомпилирует и запустит там инсталлятор.
Просто в RDi это делается нажатием кнопки, а к другой среде или прикручивать в инструменты или просто запустить из командной строки.
Это нормальная кроссплатформенная разработка. Это свой мир со своими порядками.
… оп-па — на базе Eclipse на совсем другой операционке.
А что не так?
Почему вы считаете минусом, что система, где установлено ПО разработки отличается от целевой системы?
Например, чтобы разрабатывать на целевую ОС Android удобно запускать среду разработки вовсе не на смартфоне.
Или для микроконтроллеров — вы бы тоже предпочли IDE на микроконтоллере самом запускать? Через маленький индикатор, подключенный к микроконтролеру, смотреть свой код и 3-мя кнопками управлять этой IDE?
Там, кстати, очень много софта идет в комплекте именно для кроссплатформенной разработки.
Ставится IBM Installation Manager, а потом уже через него много чего можно поставить. WAS для запуска вебсервисов, которые будут работать с аской, RAD — тоже на базе эклипса, но заточена под разработку вебсервисов.
Access i Client Solution — пакет где эмулятор терминала, интерактивный sql, средство для просмотра спулов (вывод на принтер), средство для работы и файлами бд…
Там очень много софта, позволяющего работать с сервером. А сам сервер… Такая дура размером с большой холодильник. Ниимонитора ни клавиатуры там нет.
Ставится IBM Installation Manager, а потом уже через него много чего можно поставить. WAS для запуска вебсервисов, которые будут работать с аской, RAD — тоже на базе эклипса, но заточена под разработку вебсервисов.
Access i Client Solution — пакет где эмулятор терминала, интерактивный sql, средство для просмотра спулов (вывод на принтер), средство для работы и файлами бд…
Там очень много софта, позволяющего работать с сервером. А сам сервер… Такая дура размером с большой холодильник. Ниимонитора ни клавиатуры там нет.
А что не так?А где я сказал, что это плохо?
Почему вы считаете минусом, что система, где установлено ПО разработки отличается от целевой системы?
Это нормально… Для серверной платформы. Однако во-первых это очевидно делает утверждение о том, что операционка самодостаточна — ложью, а во-вторых показывает почему этот подход никак не может прижиться где-то ещё…
Например, чтобы разрабатывать на целевую ОС Android удобно запускать среду разработки вовсе не на смартфоне.Тем не менее среды разработки, работающие на смартфонах тоже существуют — и именно этот факт «развёл» в своё время BlackBerry, Windows Phone — и Андроид.
Или для микроконтроллеров — вы бы тоже предпочли IDE на микроконтоллере самом запускать? Через маленький индикатор, подключенный к микроконтролеру, смотреть свой код и 3-мя кнопками управлять этой IDE?А что — кто-то где-то когда-то позиционировал микроконтроллер как нечто самодостаточное?!
Вы, наверное, не так поняли.
RDi здесь поставляется всего лишь как IDE для более комфотной разработки. Никто не мешает писать текст прямо на сервере, пользуясь встроенным редактором SEU. Сборка программы в любом случае происходит на сервере. Вне зависимости от того, где пишется ее текст. Если работаем в RDi, то пишем текст, забрасываем его на сервер и там запускаем компилятор.
Самодостаточность — это значит, что покупая сервер мы сразу получаем и железо и ОС, в которую интегрирована и БД и компиляторы и все средства администрирования. Ничего другого для работы нам уже не надо.
БД там является неотъемлемой частью системы. Те же транзакции поддерживаются на уровне ОС. Любая программа может быть использована в качестве встроенной функции БД.
Аналогично с компиляторами — они не поставляются как-то отдельно, они есть в составе ОС.
RDi здесь поставляется всего лишь как IDE для более комфотной разработки. Никто не мешает писать текст прямо на сервере, пользуясь встроенным редактором SEU. Сборка программы в любом случае происходит на сервере. Вне зависимости от того, где пишется ее текст. Если работаем в RDi, то пишем текст, забрасываем его на сервер и там запускаем компилятор.
Самодостаточность — это значит, что покупая сервер мы сразу получаем и железо и ОС, в которую интегрирована и БД и компиляторы и все средства администрирования. Ничего другого для работы нам уже не надо.
БД там является неотъемлемой частью системы. Те же транзакции поддерживаются на уровне ОС. Любая программа может быть использована в качестве встроенной функции БД.
Аналогично с компиляторами — они не поставляются как-то отдельно, они есть в составе ОС.
Вы, наверное, не так поняли.А мне кажется вы меня как-то не поняли.
Самодостаточность — это значит, что покупая сервер мы сразу получаем и железо и ОС, в которую интегрирована и БД и компиляторы и все средства администрирования. Ничего другого для работы нам уже не надо.Ну как же не надо-то. Вы же сами пишите:
RDi здесь поставляется всего лишь как IDE для более комфотной разработки.Так что таки вам надо что-то ещё: ещё один компьютер, дополнительная операционка и куча всего ещё.
Никто не мешает писать текст прямо на сервере, пользуясь встроенным редактором SEU.Ну так и на микроконтроллере можно, если приловчиться, программу вбивать кнопочками — прямо в машинных кодах. Когда-то давно, полвека назад, так, собственно и делали. Вы говорите, что SEU достаточно… возможно — но какой процент пользуется RDi, а какой — редактором SEU?
БД там является неотъемлемой частью системы. Те же транзакции поддерживаются на уровне ОС. Любая программа может быть использована в качестве встроенной функции БД.Всё это прекрасно. Но заметьте, что удалось всю эту красоту наладить только и исключительно за счёт сознательного отказа от поддержки массы выщей.
GUI у нас системой не поддерживается, рассчитать 3D-ролик мы не можем, подключить TPU — тоже никак… всё заточено под некоторую вполне определённую нишу… и туда даже не вошла среда разработки (хотя вошли компиляторы)!
Я, собственно, о том, что ни о какой «самодостаточности» тут нет и речи. Даже и близко. Это как говорить о «самодостаточном» двигателе для автомобиля. Да, двигатель многое определяет и недавром даже в названиях команд формулы-1 производитель двигателя явно фигурирует… но сам по себе он никому нафиг не нужен.
Вот то же самое и с AS/400 — оно, конечно, может являться ядром IT-системы фирмы… но само по себе оно неспособно ни на что вообще. Ну вот совсем ни на что. Ни платёжку распечатать, ни сеточку нейронную насчитать.
Потому и удалось сделать такую красивую архитектуру, что все задачи, которые в неё не вписываются — «вынесли за скобки». Перенесли на другие, сопряжённые системы. А это, в некотором смысле антипод самодостаточности…
Я вот именно о месте AS/400 в мире, а не о том, как оно устроено внутри.
У IBM параллельно есть еще платформа IBM z, про нее ничего не знаю, видел доки на их сайте. Она, вроде, есть развитие 370-390.
Таблица востребованности:
— Так так, C#, .net ну хорошо, в качестве джуниора мы Вас возьмем.
— Начинайте изучать PHP
— Так так, C#, .net ну хорошо, в качестве джуниора мы Вас возьмем.
— Начинайте изучать PHP
может быть там подразумевается "а теперь переводите это на net core"?
ну, я надеюсь, во всяком случае: видимый мною "кровавый энтерпрайз" выбирает либо java либо dotnet. php запретили на уровне архитекторов. но у меня субъективное видение, конечно: в пределах организации.
Node.js в кровавом интерпрайзе я тоже не встречал, разве что в качестве сервера моков.
он там (у нас) только в качестве вспомогательного инструмента: сборка фронта и всякие внутренние (неофициальные) мелкие поделки (геймификация, запись в спортзал).
Нуу, компания Hola с вами не согласится) Несколько мне известно, там и бэк и фронт на JS. И на бэке Node.js)
У них серверная часть vpn на node.js? Хотелось бы верить но верится с трудом…
Ну верить или нет — ваше личное дело) у меня там бывший коллега работает. Он на js и фронт и бэк пишет. Он и рассказал) впн они там пишут на ноде или внутреннюю админку — этого к сожалению сказать не могу. Но это по-любому уже не сервер моков)
Ну сайт визитка, с функциями регистрации и оплаты это все-таки не кровавый интерпрайз. Вот если VPN, тогда соглашусь, что это хороший пример, но скорее исключение подтверждающее правило. В моем представление кровавый интерпрайз это необходимость в постоянной поддержке и актуализации софта например под требования ФНС, а не просто разработал фичу поправил баги и пусть живет.
Не понимаю, причем тут нода. Вы с таким же успехом можете написать на джаве, без соблюдения требований ФНС.
Ну и сайт визитка и админка для клиентов — это разные вещи как по функционалу, так и по сложности. И я кстати не исключаю, что впн они скорее всего тоже на ноде пишут, поскольку мы обсуждали масштабирование, и он как раз упомянул, что нода отлично масштабируется горизонтально.
Вы меня извините, но статья ни по теме, ни по стилистике, ни по содержанию для Хабра совсем не годится. Это в Яндекс.Дзен лучше отправить. Потому что статью «Кто такой бэкенд разработчик с точки зрения домохозяйки» лучше адресовать домохозяйкам, а не бэкенд разработчикам.
И выше вилка с зарплатами.
Вот только ничего, что согласно исследованиям Хабр-Карьеры, Go — один из самых высокооплачиваемых языков, а PHP — наоборот habr.com/ru/company/habr_career/blog/478880?
Intern: C++, C#, Golang
Lead: PHP
И выше вилка с зарплатами.
Вот только ничего, что согласно исследованиям Хабр-Карьеры, Go — один из самых высокооплачиваемых языков, а PHP — наоборот habr.com/ru/company/habr_career/blog/478880?
Вы меня извините, но статья ни по теме, ни по стилистике, ни по содержанию для Хабра совсем не годится. Это в Яндекс.Дзен лучше отправить. Потому что статью «Кто такой бэкенд разработчик с точки зрения домохозяйки» лучше адресовать домохозяйкам, а не бэкенд разработчикам.
Хабр объявил смену политики контента. Количество рекламных постов увеличилось втрое. **звук из третьих героев**
Приветствую. У меня тоже сегодня настроение не очень, понимаю вас ;-) Если что, опыт в фуллстек-разработке — 4 года, управления и подбора — 12 лет. Но как бы хотелось быть домохозяином, а ещё лучше — домовладельцем в небольшом посёлке. Эх… ваши бы слова!
Коллега, никто не говорил об оплачиваемости конкретного навыка. Тот список, который вы видите, это основные навыки, которые указали те, кто закинул свою зарплату в статистику. Логично, что молодые ребята уже стартуют с более актуального Golang, а у остальных — старый добрый PHP. Это говорит лишь о популярных навыках, которые могут пригодится и которые примут к сведению.
Коллега, никто не говорил об оплачиваемости конкретного навыка. Тот список, который вы видите, это основные навыки, которые указали те, кто закинул свою зарплату в статистику. Логично, что молодые ребята уже стартуют с более актуального Golang, а у остальных — старый добрый PHP. Это говорит лишь о популярных навыках, которые могут пригодится и которые примут к сведению.
Тогда непонятно, зачем вы пишете статью на таком низком техническом уровне детализации на техническом ресурсе.
Да, вы прямо не говорите о связи этих таблиц, но человек, не искушённый в статистике, не видя исходных данных, сделает вывод о связи php -> lead -> высокие зарплаты, это напрашивается. Это если не прямой обман, то грязный трюк.
вы прямо не говорите о связи этих таблиц, но человек, не искушённый в статистике, не видя исходных данных, сделает вывод о связи php -> lead -> высокие зарплаты, это напрашивается. Это если не прямой обман, то грязный трюк.Грязный трюк — чтобы что? Чтобы продвинуть PHP в массы? :-) Я прислушался к вашему совету и под таблицей написал, что это за скиллы, чтобы сомнений не осталось.
зачем вы пишете статью на таком низком техническом уровне детализации на техническом ресурсеЦель серии о профессиях — написать о том, что может ждать при выборе специальности. Это материалы для тех, кто ещё не выбрал или думает «перескочить» и, может быть, даже для их преподавателей, родителей и работодателей. Если я насую в статью кучу инфы из своей головы о шардировании, партиционировании, паттернах, нереляционных СУБД, синтаксисе, горутинах — кому нафиг будет полезна эта статья? Бэкендерам, которые уже в деле? Незачем. Нужно думать о целях и каких-то задачах. Тем более, что в статье ничего не продаётся и не продвигается (не считая стандартного баннера) — она именно для полезноты.
Ну не знаю… Долгое время вообще не задумывался. Фронт, бэк… Нужно было делать интерфейсы — делал интерфейсы. С нуля. Т.е. сам придумывал, проектировал, писал. Потом понял что мне больше нравится колупаться в поторохах. Алгоритмы обработки данных, протоколы обмена, использование системных API для получения максимальной функциональности и эффективности…
Когда менял работу, тоже особо не задумывался. Но сложилось удачно — попал в самы глубокий бэк, команда ядровых функций АБС. Что идет от вебсервисов из мобильного клиента, интернет банка, из Пеги, попадает к нам. Ну и то, что работает в фоне — обработчики очереди сообщений, журнальные мониторы, репликаторы, регулярные отчеты…
Есть немного интерфейсов, но онииспецифические — текстовые. Т.н. «опции» для интерактивного ввода и редактирования различных таблиц.
Когда менял работу, тоже особо не задумывался. Но сложилось удачно — попал в самы глубокий бэк, команда ядровых функций АБС. Что идет от вебсервисов из мобильного клиента, интернет банка, из Пеги, попадает к нам. Ну и то, что работает в фоне — обработчики очереди сообщений, журнальные мониторы, репликаторы, регулярные отчеты…
Есть немного интерфейсов, но онииспецифические — текстовые. Т.н. «опции» для интерактивного ввода и редактирования различных таблиц.
Я прислушался к вашему совету и под таблицей написал, что это за скиллы, чтобы сомнений не осталось.
Спасибо, так гораздо лучше.
Цель серии о профессиях — написать о том, что может ждать при выборе специальности
Возможно, у меня просто припекает от того, что Хабр уже не тот. Не берите в голову.
И выше вилка с зарплатами.
Вот только ничего, что согласно исследованиям Хабр-Карьеры, Go — один из самых высокооплачиваемых языков, а PHP — наоборот habr.com/ru/company/habr_career/blog/478880?
Эта средняя температура по больнице. Кто-то с жаром, а кто-то в холодильнике в морге.
На PHP полным-полно массовых недорогих систем, полным полно программистов, что пашут за копейки над этими массовыми «сайтами-визитками». Поэтому средняя цена PHP-шника ниже.
Но это не имеет никакого отношения к тем разработчикам, что на PHP делают сложные системы.
Просто сайты-визитки на Go не делают. На Go меньше дешевых и простых работ. Поэтому среднее по больнице сдвинуто в высокие зарплаты.
Но:
1) Для вас лично имеет значение не средняя планка по больнице, а то, что лично вы разрабатываете, где лично вы работаете.
2) Если уж вы считаете, что весь ключ именно в языке программирования, то просто смените его. Переход с одного языка на другой — легок и прост, если вы уже опытный разработчик. Автор этих строк изучил Go за 2 дня (по 3-4 часа в день). Go был у меня 15-м языком.
Опять статья вышла очень интересной. Я успел полюбить этот формат!
Но я просто умиляюсь тому, что разница зарплаты между junior и middle разработчиком равна пятидесяти тысячам рублей, но...
Но я просто умиляюсь тому, что разница зарплаты между junior и middle разработчиком равна пятидесяти тысячам рублей, но...
Если сравнить с заработной платой фронтендеров, то рост незначительный
Спасибо за отзыв, он вдохновляет! Осталось как минимум 3 серии в «Профессии», причём одну идею подкинули сами читатели — написать про мобильных разработчиков как отдельный вид. И действительно, опыт с этими ребятами был интересным и не без находок.
Что касается зарплатных ножниц, это же примерная статистика на относительно небольшой (в статистическом понимании!) выборке «Карьеры». Я бы назвал это тенденцией, трендом, но, конечно, не фактом. На практике бывает всякое: можно остаться в компании и через 2 года перейти на новый уровень с +5 тыс. руб., можно перейти в новую компанию и сделать гап чуть ли не на 40-50 тыс. руб., а можно и наоборот. Это очень дискуссионный момент и сильно зависит от отношения компании к сотруднику и сотрудника к проекту.
Что касается зарплатных ножниц, это же примерная статистика на относительно небольшой (в статистическом понимании!) выборке «Карьеры». Я бы назвал это тенденцией, трендом, но, конечно, не фактом. На практике бывает всякое: можно остаться в компании и через 2 года перейти на новый уровень с +5 тыс. руб., можно перейти в новую компанию и сделать гап чуть ли не на 40-50 тыс. руб., а можно и наоборот. Это очень дискуссионный момент и сильно зависит от отношения компании к сотруднику и сотрудника к проекту.
У нее другие корни, насколько знаю.
System/3 — System/36 — System/38 — AS/400 (Advansed System/400).
Абсолютно ничего общего с win и *nix Это принципиально иная школа осостроения. Одни TIMI (Technology Independant Machine Instructions) чего стоит. Там принципиальнотнет ассемблера. Есть эти самые MI. Каждая из которых работает с объектом (все есть объект). Вся система состоит из объектов. У каждого объекта имя и тип. Файлов как таковых тожеинет — объекты.
Программный объект кроме исполняемого кода содержит еще timi код. И при каждом запуске проверяется — собран ли этот программный побъект под данную архитектуру или нет. Если нет, то исполняемый код автоматически перегенерируется из timi.
Вот заменили у нас сервер с powers 824 на powers 924 (тестовый сервер для разработки). После этого все pgm при первом запуске на новом проце автоматически перегенерировались под него. С оптимизацией под данный конкретный проц.
Де модели памяти — одноуровневая singlelevel и terraspace (ее не разрешают нам). В одноуровневой сквозная адресация памяти и диска. Вот есть такой объект userspace — что-то типа двоичного файла в других ос. На него можно получить указатель и работать с ним как с областью памяти.
Размер указателей, кстати, 16 байт :-)
Концепция групп активации тоже не сразу заходит в голову. Это нечто типа изолированного контейнра памяти. В рамках одной задачи их может быть несколько. Когда запускается новая программа (а она может запускаться из другой программы в рамках одной задачи), она может создавать свою группу активации или запускаться в той, которой работает запускающая программа.
Глобальные и статические переменные будут сохранять свое значение пока группа активации не закроется. Т.е. можно в рамках одной задачи запускать одну программу несколько раз и глобалы и статики будут сохранять свои значения с прошлого запуска…
System/3 — System/36 — System/38 — AS/400 (Advansed System/400).
Абсолютно ничего общего с win и *nix Это принципиально иная школа осостроения. Одни TIMI (Technology Independant Machine Instructions) чего стоит. Там принципиальнотнет ассемблера. Есть эти самые MI. Каждая из которых работает с объектом (все есть объект). Вся система состоит из объектов. У каждого объекта имя и тип. Файлов как таковых тожеинет — объекты.
Программный объект кроме исполняемого кода содержит еще timi код. И при каждом запуске проверяется — собран ли этот программный побъект под данную архитектуру или нет. Если нет, то исполняемый код автоматически перегенерируется из timi.
Вот заменили у нас сервер с powers 824 на powers 924 (тестовый сервер для разработки). После этого все pgm при первом запуске на новом проце автоматически перегенерировались под него. С оптимизацией под данный конкретный проц.
Де модели памяти — одноуровневая singlelevel и terraspace (ее не разрешают нам). В одноуровневой сквозная адресация памяти и диска. Вот есть такой объект userspace — что-то типа двоичного файла в других ос. На него можно получить указатель и работать с ним как с областью памяти.
Размер указателей, кстати, 16 байт :-)
Концепция групп активации тоже не сразу заходит в голову. Это нечто типа изолированного контейнра памяти. В рамках одной задачи их может быть несколько. Когда запускается новая программа (а она может запускаться из другой программы в рамках одной задачи), она может создавать свою группу активации или запускаться в той, которой работает запускающая программа.
Глобальные и статические переменные будут сохранять свое значение пока группа активации не закроется. Т.е. можно в рамках одной задачи запускать одну программу несколько раз и глобалы и статики будут сохранять свои значения с прошлого запуска…
Насчёт того, что вакансий в два раза больше, сомнительно. Там же 444 вакансии по всем языкам бэка. А во фронте один язык и несколько фреймворков. Так же нельзя сравнивать
Sign up to leave a comment.
Профессия: бэкенд-разработчик