Представьте, что мы не пишем код, а удаляем flight_time_in_seconds. Где гарантии, что HOUR_IN_SECONDS не останется висеть мертвым, уже никому не нужным кодом? Как понять, что на HOUR_IN_SECONDS ни кто больше не завязан и его удаление будет безопасным? Значит нужно заблаговременно позаботиться и убрать лишнее из all (а ещё лучше в приватный модуль). Вау, архитектура.
С другой стороны, всех этих проблем можно легко избежать, если не плодить сущности сверх меры. Если не подходит timedelta (допустим, нам эту константу нужно сериализовывать), и нужно лишний раз напомнить читателям кода про нюансы арифметики, я бы рекомендовал ограничиться комментарием как в "Лучше, но всё ещё плохо". К тому же, IDE потом будет выводить этот коммент в подсказке.
По моему, Docker вписывается в концепцию бомж-автоматизации только на линуксах, где он родной и плюс-минус понятный. Для пользователей Windows это означает изучение кучи новых инструментов, не связанных напрямую с решаемой задачей, что может надолго отвлечь от основной работы. Поэтому я боюсь тут что-то советовать.
Тогда почему же мы не применяем доказательную модель к различным методологиям и техникам разработки?
В крупных системах такие решения принимаются не на уровне отдельных разработчиков или даже команд, а спускаются им свыше в виде таких вот постулатов. Всей картинки в смысле why они могут и не видеть. Даже если архитекторы объяснили им свой vision на старте, то проблема в последствии повторяется при онбординге новых людей, которым уже ни кто ни чего персонально не объясняет.
В идеале надо, конечно же, отдельный компьютер с сервером сборки (Зомбик), чтобы на него могли заходить все заинтересованный в артефактах: разработчики, тестировщики, интеграторы, клиенты. Общий доступ можно организовать через TeamViewer или RDP
"Васюки переименовываются в Нью-Москву, а Москва — в Старые Васюки. Ленинградцы и харьковчане скрежещут зубами, но ничего не могут поделать. Нью-Москва становится элегантнейшим центром Европы, а скоро и всего мира. — Всего мира! ! !" :)
На самом деле хорошая инструкция как сделать себе автоматизацию на коленках для локалхоста. Но боюсь, что дальше вы так просто уже не отделаетесь)
В теории теория и практика одно и то же, но на практике абсолютно разные вещи. Тот факт, что 30 лет тому назад нечто обсуждалось на уровне концепции, совсем не означает того, что вы сегодня сможете взять как технологию и применить в продакшн, не имея в этом ни какого опыта. Один и тот же функционал с availability 99.9 и с 99.999 архитектурно будут совершенно разными решениями, с разницей по стоимости на порядки. Да и сами технологии мутируют до неузнаваемости. Вон выше пишут, что с++ времён его изобретения и современный это по сути два разных языка.
Умение переключаться это что-то из области темперамента. Мне всегда лучше удавалось писать код в состоянии потока, когда снаружи ни что не отвлекает. Поэтому часто работал по ночам. Трындеть же на митингах могу хоть весь день, на абсолютно разные темы.
Простые, доступные инструменты высокого уровня позволяют стартануть огромному количеству мелких игроков
У меня на телефоне приложение от самого мелкого бизнеса это Navitel. Остальное написано гигантами типа Google, Microsoft и т.п. Доступность инструментов создаёт условия для пополнения рынка до какой-то степени обученными и замотивированными кадрами. Но выводить самим что-то на рынок становится только сложнее.
Порог входа с каждым годом лишь увеличивается. Если 10 лет тому назад основной проблемой для стартапа a'la аналог Фейсбука, было найти дешёвый хостинг и выстроить продвижение, то сейчас к этому добавилось бесчисленное множество требований со стороны различных локальных регуляторов - иначе рынки закрыты. Элементарная задача хранения фоток, если на них могут быть какие-то люди, теперь уже целый архитектурно-юридический танец с бубнами на много денег.
Главное, чтобы не было как в анекдоте про машинистку: могу печать со скоростью 400 знаков в минуту, но такая ерунда получается.
Въезжать в новую технологию, как правило, проще, чем в новую предметную область. Потому, что технология начинает бить по рукам за ошибки быстрее, и специалисты быстрее учатся их избегать.
Просчеты в дизайне со стороны архитектуры или бизнес домена при таком brute-force подходе становятся заметны лишь на этапах эксплуатации, а исправление обходится дорого. Если вам удалось собрать достаточно такого опыта и не выгореть к 30, вы счастливчик.
Мне кажется у каждого свой инфопузырь, определяемый локальными условиями. В 2001 моя первая работа была связана с развитием Delphi+JS+IIS ASP, где в десктопные приложения встраивалось, как бы сейчас сказали web view (IE5 как компонент ActiveX). В 2003 бекенд переписал на LAMP и предпринимал попытки переделать формы Delphi на TCL/TK. В обоих случаях я не угадал, куда через 20 лет повернется индустрия. :)
Предыдущие 1С это локальная вариация на тему COBOL: такой же бизнес ориентированный DSL, и с такими же специфичными проблемами в плане сопровождения. Деление на сисмемных программистов и прикладных с узкой специализацией в своих предметных областях это не мейнстрим. Рынок подталкивает разработчиков к универсализации.
Старую собаку не научить новым трюкам (я не про технологии, а про отношении к работе вообще). Кто жгет в 30, жгут и в 50, без относительно ролей. Кто в этом видит лишь способ заработка, продолжают решать свои однотипные задачи.
Если не идеализировать, то айти ни чем принципиально не отличается от других видов интеллектуального труда. Ощущения исключительности это сигнал, что пора расширить кругозор.
Как-то мы решили, что наши бэкенд разработчики (разработчики серверной части web-приложений) должны владеть PHP и Python одновременно. На освоение нового языка мы им давали как раз 2 недели.
Интересно, из каких соображений был выбран именно такой срок, и каковы были результаты через 2 недели? Только честно.
Я смотрел на Glassdoor, там предлагают $50K - $130K, что вполне сопоставимо со обычными цифрами по рынку. Понятно, что это не мейнстрим, вакансий мало и учить с нуля смысла нет. Но если уже есть навыки, то работу ещё можно найти.
Наша крупная зарубежная контора на этой почве ещё плотнее заинтегрировалась с Майкрософт. Т.е. формально, да, наверное мы стали меньше у себя хранить. Зато мелкомягие получили дополнительные биты себе в копилку. Я считаю это признаками такой же консолидации данных в руках нескольких игроков - разница лишь в механиках.
Данные это новая нефть. Развитие идет в сторону снижения вероятности аварий и утечек, а не минимизации собираемых данных. Ни кто в здравом уме не откажется от денег, которые буквально лежат под ногами.
Дальнейшее закручивание гаек со стороны законотворцев и безопасников приведет к тому, что на рынке останется лишь несколько администраторов ПД, способных выполнить все эти требования, и тесно интегрированных с государством (по типу газмяса). Думаю цель в этом.
Представьте, что мы не пишем код, а удаляем flight_time_in_seconds. Где гарантии, что HOUR_IN_SECONDS не останется висеть мертвым, уже никому не нужным кодом? Как понять, что на HOUR_IN_SECONDS ни кто больше не завязан и его удаление будет безопасным? Значит нужно заблаговременно позаботиться и убрать лишнее из all (а ещё лучше в приватный модуль). Вау, архитектура.
С другой стороны, всех этих проблем можно легко избежать, если не плодить сущности сверх меры. Если не подходит timedelta (допустим, нам эту константу нужно сериализовывать), и нужно лишний раз напомнить читателям кода про нюансы арифметики, я бы рекомендовал ограничиться комментарием как в "Лучше, но всё ещё плохо". К тому же, IDE потом будет выводить этот коммент в подсказке.
По моему, Docker вписывается в концепцию бомж-автоматизации только на линуксах, где он родной и плюс-минус понятный. Для пользователей Windows это означает изучение кучи новых инструментов, не связанных напрямую с решаемой задачей, что может надолго отвлечь от основной работы. Поэтому я боюсь тут что-то советовать.
В крупных системах такие решения принимаются не на уровне отдельных разработчиков или даже команд, а спускаются им свыше в виде таких вот постулатов. Всей картинки в смысле why они могут и не видеть. Даже если архитекторы объяснили им свой vision на старте, то проблема в последствии повторяется при онбординге новых людей, которым уже ни кто ни чего персонально не объясняет.
"Васюки переименовываются в Нью-Москву, а Москва — в Старые Васюки. Ленинградцы и харьковчане скрежещут зубами, но ничего не могут поделать. Нью-Москва становится элегантнейшим центром Европы, а скоро и всего мира. — Всего мира! ! !" :)
На самом деле хорошая инструкция как сделать себе автоматизацию на коленках для локалхоста. Но боюсь, что дальше вы так просто уже не отделаетесь)
В теории теория и практика одно и то же, но на практике абсолютно разные вещи. Тот факт, что 30 лет тому назад нечто обсуждалось на уровне концепции, совсем не означает того, что вы сегодня сможете взять как технологию и применить в продакшн, не имея в этом ни какого опыта. Один и тот же функционал с availability 99.9 и с 99.999 архитектурно будут совершенно разными решениями, с разницей по стоимости на порядки. Да и сами технологии мутируют до неузнаваемости. Вон выше пишут, что с++ времён его изобретения и современный это по сути два разных языка.
Умение переключаться это что-то из области темперамента. Мне всегда лучше удавалось писать код в состоянии потока, когда снаружи ни что не отвлекает. Поэтому часто работал по ночам. Трындеть же на митингах могу хоть весь день, на абсолютно разные темы.
У меня на телефоне приложение от самого мелкого бизнеса это Navitel. Остальное написано гигантами типа Google, Microsoft и т.п. Доступность инструментов создаёт условия для пополнения рынка до какой-то степени обученными и замотивированными кадрами. Но выводить самим что-то на рынок становится только сложнее.
Порог входа с каждым годом лишь увеличивается. Если 10 лет тому назад основной проблемой для стартапа a'la аналог Фейсбука, было найти дешёвый хостинг и выстроить продвижение, то сейчас к этому добавилось бесчисленное множество требований со стороны различных локальных регуляторов - иначе рынки закрыты. Элементарная задача хранения фоток, если на них могут быть какие-то люди, теперь уже целый архитектурно-юридический танец с бубнами на много денег.
Главное, чтобы не было как в анекдоте про машинистку: могу печать со скоростью 400 знаков в минуту, но такая ерунда получается.
Въезжать в новую технологию, как правило, проще, чем в новую предметную область. Потому, что технология начинает бить по рукам за ошибки быстрее, и специалисты быстрее учатся их избегать.
Просчеты в дизайне со стороны архитектуры или бизнес домена при таком brute-force подходе становятся заметны лишь на этапах эксплуатации, а исправление обходится дорого. Если вам удалось собрать достаточно такого опыта и не выгореть к 30, вы счастливчик.
А что за предметная область и что и с чем сравнивали?
Мне кажется у каждого свой инфопузырь, определяемый локальными условиями. В 2001 моя первая работа была связана с развитием Delphi+JS+IIS ASP, где в десктопные приложения встраивалось, как бы сейчас сказали web view (IE5 как компонент ActiveX). В 2003 бекенд переписал на LAMP и предпринимал попытки переделать формы Delphi на TCL/TK. В обоих случаях я не угадал, куда через 20 лет повернется индустрия. :)
Предыдущие 1С это локальная вариация на тему COBOL: такой же бизнес ориентированный DSL, и с такими же специфичными проблемами в плане сопровождения. Деление на сисмемных программистов и прикладных с узкой специализацией в своих предметных областях это не мейнстрим. Рынок подталкивает разработчиков к универсализации.
5 лет назад и здесь толком этого не было. Но сейчас появились машинки с CUDA в облаке, которые те же задачи вывозят быстрее и за в разы меньше денег.
Старую собаку не научить новым трюкам (я не про технологии, а про отношении к работе вообще). Кто жгет в 30, жгут и в 50, без относительно ролей. Кто в этом видит лишь способ заработка, продолжают решать свои однотипные задачи.
Если не идеализировать, то айти ни чем принципиально не отличается от других видов интеллектуального труда. Ощущения исключительности это сигнал, что пора расширить кругозор.
Интересно, из каких соображений был выбран именно такой срок, и каковы были результаты через 2 недели? Только честно.
Перемножайте на GPU, eсли у вас что-то серьезное. В остальных случаях решения отличаются плюс-минус чисто эстетически.
Я смотрел на Glassdoor, там предлагают $50K - $130K, что вполне сопоставимо со обычными цифрами по рынку. Понятно, что это не мейнстрим, вакансий мало и учить с нуля смысла нет. Но если уже есть навыки, то работу ещё можно найти.
Есть программисты на Delphi. Кто помнит как называется язык стоят уже нормальных денег.
Наша крупная зарубежная контора на этой почве ещё плотнее заинтегрировалась с Майкрософт. Т.е. формально, да, наверное мы стали меньше у себя хранить. Зато мелкомягие получили дополнительные биты себе в копилку. Я считаю это признаками такой же консолидации данных в руках нескольких игроков - разница лишь в механиках.
Данные это новая нефть. Развитие идет в сторону снижения вероятности аварий и утечек, а не минимизации собираемых данных. Ни кто в здравом уме не откажется от денег, которые буквально лежат под ногами.
Дальнейшее закручивание гаек со стороны законотворцев и безопасников приведет к тому, что на рынке останется лишь несколько администраторов ПД, способных выполнить все эти требования, и тесно интегрированных с государством (по типу газмяса). Думаю цель в этом.
В аду есть отдельный котел для тех, кто просит оценить трудоемкость отдельных задач, а простом спрашивает по результатам как за сроки.
Если у вас такое практикуется, чтобы держать команду в тонусе, ни какие закладки их не спасут - работы всегда будет больше, чем capacity.
По крупному, вы скорее всего не видите всей картинки, чтобы комитаться по срокам. Так не делайте этого. :)