Ну С тут условный, скорее какой нибудь питон с jupiter ом. ))
Код делает то что надо, но совсем не в тех количествах. И разработка уже дальше перепилит, чтоб оно молотило не 100 мегабайт за час, а пару терабайт и в параллель на нескольких машинах.
У меня в примере прям сейчас пара контор где по несколько аналитиков сидят, строят модели и тд, но вот их код… Делает то что нужно, но запускать нельзя. У каждого своя песочница. А когда это надо встраивать в основной сервис, их proof-of-concept-ы просто переписываются на других языках.
Формализовать сразу без их участия, ну практически не реально, канал связи маркетологи <-> разработка наверно возможен, но ни разу нормального не видел, писать сразу нормально просто бессмысленно, там 80% теорий просто не срабатывают.
Человек делает прототип который устраивает заказчика и решает его проблему, но оставляет желать лучшего с точки зрения стабильности и качества, потом этот код переписывается профессионалами которые плюются от кода, но вполне понимают что должно получится в итоге. Итеративный процесс вроде получается? только количество итераций уменьшается.
У всех свой опыт. Квалификация менеджеров бизнес аналитиков и тд играет не маловажную роль. Скажем так, с моей спецификой приходится погружаться в контекст достаточно сильно, и разговаривать как с владельцем так и с разработчиками.
Мне в почту пришло несколько редакций сообщения, вот разработчик встраиваемых систем это уже достаточно узкая специализация на мой взгляд, как правило задачи в этой сфере четко сформулированы именно профессионалами в контекстной области, а так далеко не везде.
Он может читать и понимать код написанный другими (более профессиональными) разработчиками, он может им описать контекст области разработки им понятным языком, он может говорить с профессионалами из 2 областей зачастую перпердикулярных знаний на одном языке.
Ну знаете вы 30 фрэймворков, за плечами у вас 10 лет профессионального програмирования, работали например на финтех все 10 лет, в RTB придите, там уже контекст сильно другой, начиная с терминологии. И подходы там уже сильно другие. А это в принципе не сильно отдаленные области. Медицина или строительство уже сильно дальше, а там тоже автоматизация нужна, и не на уровне давайте склепаем вебсайтик с рекламой нашей клиники.
Скажем так, все кубики из которых строится кубер я использовал еще до того как он появился. Сложного я в нем ничего не вижу. Для использования k8s разработчиком знаний не много нужно, администрировать кластера — тут по больше, но объем знаний тоже не сильно большой (если знаешь кирпичи из которых он сделан)
А так называемые обертки, это CRD, их действительно много всяких разных.
И если вернуться к вопросу «Как строить архитектуру системы в k8s», ну вначале посмотрите как он сам построен ))
Там реально ничего сложного, вас никто не заставляет детально разбираться с реализацией автоскэйлинга, cni, csi и тд. просто посмотрите как устроенно взаимодействие компонентов, куча вопросов отпадет.
Если человек просто выучил С, но при этом плавает как рыба в контексте «домена» разработки, он на порядок более ценен чем тот кто знает фрэймворки и тд, но не владеет областью которую описывает.
Давайте так, тут есть выбор, учиться или нет.
Ну и у врачей он есть, только сильно жестче.
У строителей, аналогично жестче.
И тут можно вписать кучу профессий.
И будут ли IT специализации на вершине сложности, вопрос весьма провокационный с учетом топика. Что собственно и наблюдается.
Да простой он на самом деле, там архитектура простая, аж завораживает. Но сверху налепили… + родовые болячки тянут, и названий своих напридумывали. А так на 2 дня почитать, пару недель попользоваться. И уже можно в чатике по теме гуру быть.
очень старый кусок кода, из IO мне нужны эфФекты AJAX, пнуть сообщение в консоль, модифицировать DOM
В сравнении со стэкированием монад в haskell это сильно проще, ниже порог входа кардинально.
Я прям наблюдаю за развитием проекта, не давно понадобился дашборд к github
и неожиданно нашел готовый на этом языке. )
А вот тут не согласен. 15 лет назад в трэнде был живой переезд процесса (виртуальные машины и openvz умели, да и сейчас умеют)
Потом появился докер, микросервисы и все такое.
Вроде новое, но вот не совсем. «Девиз» erlang «let it crash».
Все эти микросервисы и прочие это развитие этой идеи.
И вот если честно куберу до erlang еще далеко. Но там можно писать на чем угодно, тем и берет.
Изучить кубер разработчику это потратить 3 дня на чтение + пара недель опыта работы с ним. Знать вот всю структуру данных которая описывает deploy или sts или ingress можно конечно, но обычно смысла мало.
Вот вопрос, что проще написать спеку для сборки rpm(deb) пакета
или Dockerfile?
А ответ на вопрос и раскрывает тему почему docker выстрелил. k8s кстати не факт что будет жить долго. Как то слишком сложно для «5 бинарей»
И вот это сложно эт не мое, это по опыту внедрения.
Глядя на то куда катится этот мир представить что будет дальше ))
Думаю уже скоро процессоры очень сильно обрастут специализированными ядрами (apple уже задал трэнд)
Через какое то время понятие жесткий диск исчезнет как класс.
Каналы связи будут обеспечивать возможность прокачивать 8k или больше по воздуху.
Допилят устройства виртуальной реальности (без лупы в маленький экран), думаю индустрия порно закачает денег на это направление.
Страничка в браузере, в очках виртуальной реальности с прогнозом погоды (который конечно же не точен как и сейчас) будет так же тормозить, несмотря на 300 ядер с десятком терабайт на борту (девайс переносной, потому слабенький, батарейка иначе тяжелая)
Телевизионные передачи и фильмы сольются с рекламой в единое целое донося до наших мозгов правильные трэнды.
Спутниковая связь подешевеет в пару раз, или наоборот подорожает раз 5 (хотя куда уж дороже то)
Алиса наконец сможет поддерживать разговор с 3 летним ребенком, но он к тому моменту станет здоровым детиной, одна надежда на внуков.
Выйдет 3 или 4 ремейк вашего любимого фильма, в новом супер разрешении с ощущением приближенным к реальности (тут возможно и наркотики соответствующие добавятся, но не везде)
Человек высадится на Луне в прямом эфире.
Оптимистично как то получилось. )
Но лучше так чем опять дубины и шкуры ))
Из этой, сразу видно.
Я наверно динозавр (ну почти, всего 44 годика)
В настоящий момент участвую в 6 проектах, как раз учу молодежь CI/CD, Kubernetes, Docker, podman, облака и тд. Стабильно пару раз в месяц вижу как начинают пилить какой то кривой велосипед который давно написан, рассказываю, показываю и экономлю время. Не давно стало скучно, решил опять код пописать, промежуток лет 6 — 7, поменялось несколько версий компилятора, изменились инструменты сборки, добавилось несколько новых фич. Но особых каких то проблем не вижу. Читаешь доки, пишешь, словарный запас пополняется за пару месяцев до приемлемого уровня. Потом просто пишешь.
Почитайте про extensible effects. На базе одной этой идеи целый язык программирования сделали, just for fun, и не ожиданно комьюнити организовалось, пилят, без вливания денег гуглом.
А про проникновение, как учат в той парадигме и программируют.
Код делает то что надо, но совсем не в тех количествах. И разработка уже дальше перепилит, чтоб оно молотило не 100 мегабайт за час, а пару терабайт и в параллель на нескольких машинах.
У меня в примере прям сейчас пара контор где по несколько аналитиков сидят, строят модели и тд, но вот их код… Делает то что нужно, но запускать нельзя. У каждого своя песочница. А когда это надо встраивать в основной сервис, их proof-of-concept-ы просто переписываются на других языках.
Формализовать сразу без их участия, ну практически не реально, канал связи маркетологи <-> разработка наверно возможен, но ни разу нормального не видел, писать сразу нормально просто бессмысленно, там 80% теорий просто не срабатывают.
Мне в почту пришло несколько редакций сообщения, вот разработчик встраиваемых систем это уже достаточно узкая специализация на мой взгляд, как правило задачи в этой сфере четко сформулированы именно профессионалами в контекстной области, а так далеко не везде.
Ну знаете вы 30 фрэймворков, за плечами у вас 10 лет профессионального програмирования, работали например на финтех все 10 лет, в RTB придите, там уже контекст сильно другой, начиная с терминологии. И подходы там уже сильно другие. А это в принципе не сильно отдаленные области. Медицина или строительство уже сильно дальше, а там тоже автоматизация нужна, и не на уровне давайте склепаем вебсайтик с рекламой нашей клиники.
А так называемые обертки, это CRD, их действительно много всяких разных.
И если вернуться к вопросу «Как строить архитектуру системы в k8s», ну вначале посмотрите как он сам построен ))
Там реально ничего сложного, вас никто не заставляет детально разбираться с реализацией автоскэйлинга, cni, csi и тд. просто посмотрите как устроенно взаимодействие компонентов, куча вопросов отпадет.
Да и в каждой шутке есть доля шутки.
Ну и у врачей он есть, только сильно жестче.
У строителей, аналогично жестче.
И тут можно вписать кучу профессий.
И будут ли IT специализации на вершине сложности, вопрос весьма провокационный с учетом топика. Что собственно и наблюдается.
А база да, haskell, выкинули легаси, добавили свои плюшки.
очень старый кусок кода, из IO мне нужны эфФекты AJAX, пнуть сообщение в консоль, модифицировать DOM
В сравнении со стэкированием монад в haskell это сильно проще, ниже порог входа кардинально.
Я прям наблюдаю за развитием проекта, не давно понадобился дашборд к github
и неожиданно нашел готовый на этом языке. )
Потом появился докер, микросервисы и все такое.
Вроде новое, но вот не совсем. «Девиз» erlang «let it crash».
Все эти микросервисы и прочие это развитие этой идеи.
И вот если честно куберу до erlang еще далеко. Но там можно писать на чем угодно, тем и берет.
Изучить кубер разработчику это потратить 3 дня на чтение + пара недель опыта работы с ним. Знать вот всю структуру данных которая описывает deploy или sts или ingress можно конечно, но обычно смысла мало.
Вот вопрос, что проще написать спеку для сборки rpm(deb) пакета
или Dockerfile?
А ответ на вопрос и раскрывает тему почему docker выстрелил. k8s кстати не факт что будет жить долго. Как то слишком сложно для «5 бинарей»
И вот это сложно эт не мое, это по опыту внедрения.
Думаю уже скоро процессоры очень сильно обрастут специализированными ядрами (apple уже задал трэнд)
Через какое то время понятие жесткий диск исчезнет как класс.
Каналы связи будут обеспечивать возможность прокачивать 8k или больше по воздуху.
Допилят устройства виртуальной реальности (без лупы в маленький экран), думаю индустрия порно закачает денег на это направление.
Страничка в браузере, в очках виртуальной реальности с прогнозом погоды (который конечно же не точен как и сейчас) будет так же тормозить, несмотря на 300 ядер с десятком терабайт на борту (девайс переносной, потому слабенький, батарейка иначе тяжелая)
Телевизионные передачи и фильмы сольются с рекламой в единое целое донося до наших мозгов правильные трэнды.
Спутниковая связь подешевеет в пару раз, или наоборот подорожает раз 5 (хотя куда уж дороже то)
Алиса наконец сможет поддерживать разговор с 3 летним ребенком, но он к тому моменту станет здоровым детиной, одна надежда на внуков.
Выйдет 3 или 4 ремейк вашего любимого фильма, в новом супер разрешении с ощущением приближенным к реальности (тут возможно и наркотики соответствующие добавятся, но не везде)
Человек высадится на Луне в прямом эфире.
Оптимистично как то получилось. )
Но лучше так чем опять дубины и шкуры ))
Я наверно динозавр (ну почти, всего 44 годика)
В настоящий момент участвую в 6 проектах, как раз учу молодежь CI/CD, Kubernetes, Docker, podman, облака и тд. Стабильно пару раз в месяц вижу как начинают пилить какой то кривой велосипед который давно написан, рассказываю, показываю и экономлю время. Не давно стало скучно, решил опять код пописать, промежуток лет 6 — 7, поменялось несколько версий компилятора, изменились инструменты сборки, добавилось несколько новых фич. Но особых каких то проблем не вижу. Читаешь доки, пишешь, словарный запас пополняется за пару месяцев до приемлемого уровня. Потом просто пишешь.
А про проникновение, как учат в той парадигме и программируют.