Легаси код поддерживают в основном по экономическим причинам. Но экономика легаси кода на php или питоне мне понятна. Компаниям дешевле нанять студентов на entry level зарплату, чем переписывать.
Но с теми проблемами которые вы описали в статье (в том числе нехватки кадров), неужели выгоднее находить программистов мейнфреймов, чем переучивать или нанять новых итд?
Тот же пример с водительскими правами. Я, конечно, не в курсе всех деталей, но мне почему то кажется, что это симптом плохого управления, а не конкретных технических решений. Зачем вообще локальному DMV свои кастомные решения? Почему нельзя воспользоваться готовыми? А если нельзя, то я уверен, что талантливая команда ребят с горящими глазами, и опытным лидом, может написать систему управления выдачи водительских прав на современном стэке, за несколько месяцев. Зачем им свои программисты, почему нельзя нанять подрядчика? Да и какие там задачи требуют вычислений на мейнфреймах? Это же же обычный CRUD.
Как и с другими статьями о мейнфреймах, основной вопрос который остался после прочтения — "зачем"?
Ну то есть реально интересно, какие задачи сегодня все еще требуют разработки на мейнфреймах, и не могут быть решены в облаке (более эффективно)? Понимаю, что статья не об этом, но мне правда любопытно.
Надеюсь, к 2035му году до Рогозина дойдет, что современная наука и космонавтика в том числе, строится на коллаборации ученых всего мира, и нет никаких причин сегодня запускать "свое и только свое" (ну, кроме, политических конечно).
Если вам нужна ленивая загрузка, вам не нужна IDE, вам нужен текстовый редактор со встроенным браузером файлов. Каким образом должны работать инструменты рефакторинга, IntelliSense, Find References итд, без загрузки всего проекта и индексации содержимого? Так работает любая IDE.
Проблема в том, что в 14 лет не каждый подросток может осозновать то, что он делает, особенно если это может нанести непоправимый вред его здоровью или психике. Понятно, что можно спорить о том "что", и "в каком возрасте", и "наносит ли это реально вред", но суть именно в этом.
Я имею ввиду классика — скачанные с торрентов пиратские версии CMS, форумных движков итд, где через N месяцев обнаруживаются бэкдоры, зашитые авторами торрентов. К моменту когда торрент удаляется, в зависимости от навыков автора, у него тысячи скачиваний и сотни сайтов с владельцев которых можно вымогать деньги. Ну а потом бэкдор уходит в паблик
По моему этим в середине / конце 2000ых болели половина форумов на IPB, vBulletin, XenForo и другие фан сайты на платных движках где владельцы просто не могли себе позволить лицензию в сотни долларов.
Понятно, что любая логика исполняемая на клиентской машине, может быть подвергнута реверс-инжинирингу, и обфускация это лишь попытка сделать реверс сложнее/дороже.
Из интересного по теме:
Помню довольно долгое время не могли зареверсить клиент дропбокса, потому что он был написан на Python и скомпилирован кастомным компилятором с измененными оп-кодами (opcode remapping).
В результате зареверсили-таки (линк кому интересно) но в целом техника мне понравилась.
На тот момент казалось перспективным способом обфускации — по сути написание программы на кастомном языке, для чего атакующему необходимо было бы зареверсить сам язык (рантайм, виртуальную машину итд) и написать для него декомпилятор.
По поводу устаревшего парка — очень тяжело объяснить руководству, особенно старой закалки, с какой стати оборудование закупленное всего-лишь 5-6 лет назад, уже "устарело" и все нужно менять. Особенно если речь о производстве — огромное количество всяких CNC и проч. до сих пор работает на Windows XP, и закупались станки с расчетом амортизации на десятилетия. Так что их тоже можно понять.
В местах где скрам был крайне эффективен — каким образом боролись со "срезанием углов"? Кто отвечал за качество кода? Что происходило когда после выпуска новой фичи обнаруживали баги — меняли задачи посередине спринта, или ждали 2 недели что бы исправить? Как трэкался technical debt и кто решал когда стоило сделать technical investment (и оценить его)?
Читая пресс-релиз, существенное изменение заключается в том, что теперь при нарушении правил, Apple даст возможность исправить нарушение при следующем обновлении.
Это конечно хорошо, но не решает основной проблемы, которая заключается в том что правила трактуются как угодно и применяются выборочно, и зависит это от того, кто вы, какой ревьювер вам попался на этом конкретном обновлении, как совпали звезды, итд. Особенно когда версия от предыдущей отличается исправлением мелких багов, и ревьюеры начинают находить нарушения правил, которых до этого в 10 версиях почему-то не было.
Но в основном, конечно, решает насколько крупный вы игрок. Ежу понятно, что gmail никто блокировать не будет. И именно поэтому они не хотят уточнять эти правила, потому что тогда окажется, что половину приложений в App Store надо бы заблокировать. Поэтому они отнекиваются и на аргумент "так сделано у всех" отвечают что-то в духе "а вы не смотрите как у других, вы делайте как мы вам говорим".
C# классный, но очень хотелось бы, что бы улучшилась ситуация с AOT и гейм девом в целом. К сожалению, половина разработчиков на Unity все еще сидят на .NET 3.5, а сами Unity отказываются реализовывать даже базовые фичи и рассматривают C# как "скриптовый язык", реализовывая свои велосипеды под любую задачу (отсутствие NuGet, убогий дегаббер от Mono, assembly definitions вместо нормальной поддержки файлов проектов итд). Все это крайне затрудняет развитие кросс-платформенной экосистемы .NET.
Xamarin немного улучшает ситуацию, но очень печально что проекты типа MonoGame находятся в полуживом состоянии.
Так что когда я читаю про фичи типа Reference Assemblies, или Source Generators, становится и весело и грустно.
Тут мы подходим к одному серьезному ограничению при разработке модов для Unity-игр — у нас нет редактора Unity.
В чем проблема сделать все что нужно в редакторе и сохранить в Asset Bundle? А затем из кода мода подгрузить ваш canvas через
var bundle = AssetBundle.Load(...);
var prefab = bundle.LoadAsset<GameObject>(...);
var instance = Instantiate(prefab);
var canvas = instance.GetComponent<Canvas>();
Есть два противоположных мнения. С одной стороны, если начинать с более мелких стартапов, где можно wear different hats и набраться опыта в более передовых технологиях, это даст более широкий кругозор (сравнивая с крупняком, где будешь год майнор баги в чужом говнокоде фиксить перед тем, как доверят что-то серьезное).
С другой стороны, иметь к 25-30 годам в резюме опыт работы в FB или Гугле, позволит ставить свои условия на собеседованиях в те-же мелкие стартапы.
Удивлен, что автор не упомянул артикли, ведь это основная "лакмусовая бумажка", по которой можно моментально определить не нейтив спикера. За исключением случаев, когда родным является артиклевый язык (например немецкий), с правильной расстановкой проблемы у всех.
К проблеме добавляется то, что при обучении английскому, при изучении артиклей обычно начинают с исключений и правил, вместо того, что бы понять их смысл и зачем они вообще нужны.
Я считаю что именно талантливые и уникальные люди создают успешные продукты, и такие люди — залог успеха любой компании. И как правило они выполняют 90% полезной работы и двигают всех остальных вперёд. Если вы так не считаете, ваше право.
Все заказчики стильные-молодежные до тех пор, пока им не предлагают вложить неизвестное количество $ для получения неизвестного результата. Их тоже можно понять :)
Очень круто! Есть ли исходник проекта, поизучать?
Легаси код поддерживают в основном по экономическим причинам. Но экономика легаси кода на php или питоне мне понятна. Компаниям дешевле нанять студентов на entry level зарплату, чем переписывать.
Но с теми проблемами которые вы описали в статье (в том числе нехватки кадров), неужели выгоднее находить программистов мейнфреймов, чем переучивать или нанять новых итд?
Тот же пример с водительскими правами. Я, конечно, не в курсе всех деталей, но мне почему то кажется, что это симптом плохого управления, а не конкретных технических решений. Зачем вообще локальному DMV свои кастомные решения? Почему нельзя воспользоваться готовыми? А если нельзя, то я уверен, что талантливая команда ребят с горящими глазами, и опытным лидом, может написать систему управления выдачи водительских прав на современном стэке, за несколько месяцев. Зачем им свои программисты, почему нельзя нанять подрядчика? Да и какие там задачи требуют вычислений на мейнфреймах? Это же же обычный CRUD.
Как и с другими статьями о мейнфреймах, основной вопрос который остался после прочтения — "зачем"?
Ну то есть реально интересно, какие задачи сегодня все еще требуют разработки на мейнфреймах, и не могут быть решены в облаке (более эффективно)? Понимаю, что статья не об этом, но мне правда любопытно.
Надеюсь, к 2035му году до Рогозина дойдет, что современная наука и космонавтика в том числе, строится на коллаборации ученых всего мира, и нет никаких причин сегодня запускать "свое и только свое" (ну, кроме, политических конечно).
Если вам нужна ленивая загрузка, вам не нужна IDE, вам нужен текстовый редактор со встроенным браузером файлов. Каким образом должны работать инструменты рефакторинга, IntelliSense, Find References итд, без загрузки всего проекта и индексации содержимого? Так работает любая IDE.
Проблема в том, что в 14 лет не каждый подросток может осозновать то, что он делает, особенно если это может нанести непоправимый вред его здоровью или психике. Понятно, что можно спорить о том "что", и "в каком возрасте", и "наносит ли это реально вред", но суть именно в этом.
Я имею ввиду классика — скачанные с торрентов пиратские версии CMS, форумных движков итд, где через N месяцев обнаруживаются бэкдоры, зашитые авторами торрентов. К моменту когда торрент удаляется, в зависимости от навыков автора, у него тысячи скачиваний и сотни сайтов с владельцев которых можно вымогать деньги. Ну а потом бэкдор уходит в паблик
По моему этим в середине / конце 2000ых болели половина форумов на IPB, vBulletin, XenForo и другие фан сайты на платных движках где владельцы просто не могли себе позволить лицензию в сотни долларов.
Ну а сегодня просто желание сэкономить
Классика жанра, не?
Понятно, что любая логика исполняемая на клиентской машине, может быть подвергнута реверс-инжинирингу, и обфускация это лишь попытка сделать реверс сложнее/дороже.
Из интересного по теме:
Помню довольно долгое время не могли зареверсить клиент дропбокса, потому что он был написан на Python и скомпилирован кастомным компилятором с измененными оп-кодами (opcode remapping).
В результате зареверсили-таки (линк кому интересно) но в целом техника мне понравилась.
На тот момент казалось перспективным способом обфускации — по сути написание программы на кастомном языке, для чего атакующему необходимо было бы зареверсить сам язык (рантайм, виртуальную машину итд) и написать для него декомпилятор.
По поводу устаревшего парка — очень тяжело объяснить руководству, особенно старой закалки, с какой стати оборудование закупленное всего-лишь 5-6 лет назад, уже "устарело" и все нужно менять. Особенно если речь о производстве — огромное количество всяких CNC и проч. до сих пор работает на Windows XP, и закупались станки с расчетом амортизации на десятилетия. Так что их тоже можно понять.
Хочу вам задать такой же вопрос, как и в предыдущем комментарии.
В вашем личном опыте:
Мне действительно любопытен опыт людей, которые успешно применяли именно textbook scrum.
В местах где скрам был крайне эффективен — каким образом боролись со "срезанием углов"? Кто отвечал за качество кода? Что происходило когда после выпуска новой фичи обнаруживали баги — меняли задачи посередине спринта, или ждали 2 недели что бы исправить? Как трэкался technical debt и кто решал когда стоило сделать technical investment (и оценить его)?
Читая пресс-релиз, существенное изменение заключается в том, что теперь при нарушении правил, Apple даст возможность исправить нарушение при следующем обновлении.
Это конечно хорошо, но не решает основной проблемы, которая заключается в том что правила трактуются как угодно и применяются выборочно, и зависит это от того, кто вы, какой ревьювер вам попался на этом конкретном обновлении, как совпали звезды, итд. Особенно когда версия от предыдущей отличается исправлением мелких багов, и ревьюеры начинают находить нарушения правил, которых до этого в 10 версиях почему-то не было.
Но в основном, конечно, решает насколько крупный вы игрок. Ежу понятно, что gmail никто блокировать не будет. И именно поэтому они не хотят уточнять эти правила, потому что тогда окажется, что половину приложений в App Store надо бы заблокировать. Поэтому они отнекиваются и на аргумент "так сделано у всех" отвечают что-то в духе "а вы не смотрите как у других, вы делайте как мы вам говорим".
А как же старый-добрый NotePad++?
Интересное интервью, спасибо.
C# классный, но очень хотелось бы, что бы улучшилась ситуация с AOT и гейм девом в целом. К сожалению, половина разработчиков на Unity все еще сидят на .NET 3.5, а сами Unity отказываются реализовывать даже базовые фичи и рассматривают C# как "скриптовый язык", реализовывая свои велосипеды под любую задачу (отсутствие NuGet, убогий дегаббер от Mono, assembly definitions вместо нормальной поддержки файлов проектов итд). Все это крайне затрудняет развитие кросс-платформенной экосистемы .NET.
Xamarin немного улучшает ситуацию, но очень печально что проекты типа MonoGame находятся в полуживом состоянии.
Так что когда я читаю про фичи типа Reference Assemblies, или Source Generators, становится и весело и грустно.
В чем проблема сделать все что нужно в редакторе и сохранить в Asset Bundle? А затем из кода мода подгрузить ваш canvas через
Есть два противоположных мнения. С одной стороны, если начинать с более мелких стартапов, где можно wear different hats и набраться опыта в более передовых технологиях, это даст более широкий кругозор (сравнивая с крупняком, где будешь год майнор баги в чужом говнокоде фиксить перед тем, как доверят что-то серьезное).
С другой стороны, иметь к 25-30 годам в резюме опыт работы в FB или Гугле, позволит ставить свои условия на собеседованиях в те-же мелкие стартапы.
Удивлен, что автор не упомянул артикли, ведь это основная "лакмусовая бумажка", по которой можно моментально определить не нейтив спикера. За исключением случаев, когда родным является артиклевый язык (например немецкий), с правильной расстановкой проблемы у всех.
К проблеме добавляется то, что при обучении английскому, при изучении артиклей обычно начинают с исключений и правил, вместо того, что бы понять их смысл и зачем они вообще нужны.
Я считаю что именно талантливые и уникальные люди создают успешные продукты, и такие люди — залог успеха любой компании. И как правило они выполняют 90% полезной работы и двигают всех остальных вперёд. Если вы так не считаете, ваше право.
Все заказчики стильные-молодежные до тех пор, пока им не предлагают вложить неизвестное количество $ для получения неизвестного результата. Их тоже можно понять :)