Привет!
Большинство DevOps pipeline, что я видел, мягко говоря не быстрые. Даже в теории чтобы просто докатить commit до ПРОМа нужны часы. Возможно у компаний с лучшими практиками DevOps это десятки минут. Можно ли быстрее?
Теоретически - да, и существует даже действующая модель:
https://medium.com/darklang/how-dark-deploys-code-in-50ms-771c6dd60671
https://docs.darklang.com/tutorials/first-dark-application#open-the-editor
В чем суть: ребята объединили язык, среду разработки, среду выполнения, хранилище данных и DevOps включая запуск тестов в одном продукте. В язык и среду встроены feature toggles, т.е. любое несовместимое изменение должно включаться по своему feature toggle. Естественно в выключенном состоянии. Это касается кода, таблиц в БД, новых библиотек. Таблицы и библиотеки получают новые версии, использование которых нужно явно включать. Сохранение срочки кода = commit. Невалидный код сохранить нельзя. Коммит идет сразу на ПРОМ после прогона тестов. Возможности языка ограничены, т.к. среда управляет инфраструктурой. По сути получаем serverless. Среда хранит логи и трасировки запросов, в т.ч. невалидные запросы, для последних можно быстро создать обработчик, т.е. получаем trace based development.
Мои выводы по результатам краткого знакомства.
1) концепт интересный, я бы даже сказал крутой
2) разработка в браузере смущает
3) возможности языка ограничены, но возможно спасают библиотеки
4) и главное - непонятно как с этим работать более чем одному разработчику и\или если число строк кода более 100. Если разработчики где-то будут пересекаться по коду - есть риск, что они не будут знать про чужие feature toggles и проверять их не будут. Или если фича большая, включает десятки функций и обработчиков, а у каждого свой feature toggle, спроектировать и проверить их в нужном порядке не совсем элементарная задача. В обоих случаях получаем feature toggle hell.
Но концепт красивый)
#devops #lang #concepts
Большинство DevOps pipeline, что я видел, мягко говоря не быстрые. Даже в теории чтобы просто докатить commit до ПРОМа нужны часы. Возможно у компаний с лучшими практиками DevOps это десятки минут. Можно ли быстрее?
Теоретически - да, и существует даже действующая модель:
https://medium.com/darklang/how-dark-deploys-code-in-50ms-771c6dd60671
https://docs.darklang.com/tutorials/first-dark-application#open-the-editor
В чем суть: ребята объединили язык, среду разработки, среду выполнения, хранилище данных и DevOps включая запуск тестов в одном продукте. В язык и среду встроены feature toggles, т.е. любое несовместимое изменение должно включаться по своему feature toggle. Естественно в выключенном состоянии. Это касается кода, таблиц в БД, новых библиотек. Таблицы и библиотеки получают новые версии, использование которых нужно явно включать. Сохранение срочки кода = commit. Невалидный код сохранить нельзя. Коммит идет сразу на ПРОМ после прогона тестов. Возможности языка ограничены, т.к. среда управляет инфраструктурой. По сути получаем serverless. Среда хранит логи и трасировки запросов, в т.ч. невалидные запросы, для последних можно быстро создать обработчик, т.е. получаем trace based development.
Мои выводы по результатам краткого знакомства.
1) концепт интересный, я бы даже сказал крутой
2) разработка в браузере смущает
3) возможности языка ограничены, но возможно спасают библиотеки
4) и главное - непонятно как с этим работать более чем одному разработчику и\или если число строк кода более 100. Если разработчики где-то будут пересекаться по коду - есть риск, что они не будут знать про чужие feature toggles и проверять их не будут. Или если фича большая, включает десятки функций и обработчиков, а у каждого свой feature toggle, спроектировать и проверить их в нужном порядке не совсем элементарная задача. В обоих случаях получаем feature toggle hell.
Но концепт красивый)
#devops #lang #concepts
Medium
How Dark deploys code in 50ms
Speed of developer iteration is the single most important factor in how quickly a technology company can move. In Dark, deploys take 50ms!
👍1
PHP становится Java-ой?
Недавно посмотрел видео о перспективах PHP https://vkvideo.ru/video-224967259_456239053 Я на PHP писал мало, но т.к. он широко распространён - интересно, развивается ли он и как именно. Он развивается, и я этому не удивлён. Да, есть распространённое негативное мнение про PHP и его разработчиков. Любой простой язык привлекает непрофессионалов. Но ситуация сложнее, чем кажется, на это намекает официальный code style языка https://php-psr.ru/accepted/PSR-12-extended-coding-style-guide/ Обязательность строк разделителей, фиксированное число пробелов, регистр символов - все серьёзно. Небольшое отступление - к аббревиатуре PSR из статьи выше мы ещё вернёмся.
Так вот, PHP становится похожим на Java.
Чтобы понять как именно - стоит вспомнить, чем он характеризовался изначально?
1) динамическая типизация. От неё уходят, с костылями в виде объявления типов в комментариях и проверке статическим анализатором типа checkstyle. Причина - невозможно работать со сложным проектом и динамической типизацией. Если ты конечно не хочешь "гов..кодить".
2) интерпретация вместо компиляции. Тоже уходят, есть AOT и JIT компиляторы PHP. Также фреймворки, например, IoC контейнеры, могут предварительно сохранять конфигурацию на диске. По соображениям производительности
Да, в PHP тоже есть IoC контейнеры.
3) малоизвестный факт - исходно в PHP была т.наз умирающая модель процессов. После обработки запроса клиента контекст процесса полностью очищается. Такой true stateless. Причём очищались не просто клиентские данные, а все бины IoC контейнера, т.е. вообще все. Побочные эффекты такого подхода противоположные. Положительный: PHP компоненты инициализируются очень быстро, по другому никак. Отрицательный: на утечки памяти можно забить, т.е. "гов...кодим") Так вот, от этой модели тоже уходят. Снова по соображениям производительности
В общем язык развивается, т.к. наследие огромное.
P.S. Чтобы не было пренебрежительного отношения к PHP - поговорим про стандартизацию. В PHP есть такое понятие, как middleware. Вот его неплохое описание https://laravel.com/docs/12.x/middleware
Ключевой момент - компоненты middleware переиспользуются в различных фреймворках. Как это получается? Потому что многое стандартизируется, с помощью PSR. В Java тоже есть стандарты - JPA, JDBC, http сервлеты и фильтры, но видится, что их меньше. Когда-то этим занимался проект Java EE, не смог, умер и воскрес, а за это время возникло несколько экосистем - Spring, Quarkus, Micronaut... И это я Kotlin не беру) Почему я назвал их экосистемами - каждая старается привязать к своим компонентам. Так что как ни странно - PHP выглядит более стандартизированным)
#java #PHP #lang
Недавно посмотрел видео о перспективах PHP https://vkvideo.ru/video-224967259_456239053 Я на PHP писал мало, но т.к. он широко распространён - интересно, развивается ли он и как именно. Он развивается, и я этому не удивлён. Да, есть распространённое негативное мнение про PHP и его разработчиков. Любой простой язык привлекает непрофессионалов. Но ситуация сложнее, чем кажется, на это намекает официальный code style языка https://php-psr.ru/accepted/PSR-12-extended-coding-style-guide/ Обязательность строк разделителей, фиксированное число пробелов, регистр символов - все серьёзно. Небольшое отступление - к аббревиатуре PSR из статьи выше мы ещё вернёмся.
Так вот, PHP становится похожим на Java.
Чтобы понять как именно - стоит вспомнить, чем он характеризовался изначально?
1) динамическая типизация. От неё уходят, с костылями в виде объявления типов в комментариях и проверке статическим анализатором типа checkstyle. Причина - невозможно работать со сложным проектом и динамической типизацией. Если ты конечно не хочешь "гов..кодить".
2) интерпретация вместо компиляции. Тоже уходят, есть AOT и JIT компиляторы PHP. Также фреймворки, например, IoC контейнеры, могут предварительно сохранять конфигурацию на диске. По соображениям производительности
Да, в PHP тоже есть IoC контейнеры.
3) малоизвестный факт - исходно в PHP была т.наз умирающая модель процессов. После обработки запроса клиента контекст процесса полностью очищается. Такой true stateless. Причём очищались не просто клиентские данные, а все бины IoC контейнера, т.е. вообще все. Побочные эффекты такого подхода противоположные. Положительный: PHP компоненты инициализируются очень быстро, по другому никак. Отрицательный: на утечки памяти можно забить, т.е. "гов...кодим") Так вот, от этой модели тоже уходят. Снова по соображениям производительности
В общем язык развивается, т.к. наследие огромное.
P.S. Чтобы не было пренебрежительного отношения к PHP - поговорим про стандартизацию. В PHP есть такое понятие, как middleware. Вот его неплохое описание https://laravel.com/docs/12.x/middleware
Ключевой момент - компоненты middleware переиспользуются в различных фреймворках. Как это получается? Потому что многое стандартизируется, с помощью PSR. В Java тоже есть стандарты - JPA, JDBC, http сервлеты и фильтры, но видится, что их меньше. Когда-то этим занимался проект Java EE, не смог, умер и воскрес, а за это время возникло несколько экосистем - Spring, Quarkus, Micronaut... И это я Kotlin не беру) Почему я назвал их экосистемами - каждая старается привязать к своим компонентам. Так что как ни странно - PHP выглядит более стандартизированным)
#java #PHP #lang
VK Видео
Какое будущее ждет PHP? / Валентин Удальцов.. — Видео | VK Видео
Смотрите онлайн Какое будущее ждет PHP? / Валентин Удальцов.. 1 ч 42 мин 1 с. Видео от 10 октября 2024 в хорошем качестве, без регистрации в бесплатном видеокаталоге ВКонтакте! 1021 — просмотрели. 30 — оценили.
Сколько языков можно запустить на JVM?
Скорее всего, кроме собственно Java большинство вспомнит Kotlin и Scala. Еще возможно Groovy - хотя Groovy, созданный как язык общего назначения, сейчас стал нишевым языком для реализации DSL: Gradle, Jenkins как самые известные примеры.
Но JVM - это не только слой абстракции на операционной системой, позволяющий не думать о поддержке разных процессорных архитектур, операционных систем, оптимизациях, сборке мусора, профилировании и многом другом. Благодаря всему вышеперечисленному JVM дает возможность всем желающим (ладно, не всем, а умеющим и желающим)))) придумать свой язык программирования. Или перенести существующий на JVM.
Вот список https://en.wikipedia.org/wiki/List_of_JVM_languages
Да, я подозреваю половина из этих языков уже мертва. Но найти там можно почти все: Python, Go, PHP, Ruby, JS и даже таких старичков как Cobol, Delphi, Visual Basic и Lisp.
Вывод: да, у подхода с использованием виртуальной машины конечно есть и минусы: увеличившаяся сложность системы и производительность. Но и плюсы очевидны, в т.ч. и неожиданные - появляется полигон для создания новых и адаптации существующих языков.
P.S. Virtual machine по большому счету реализовали 2 крупные компании: Sun\Oracle и Microsoft. Причем .NET реализация - CLR - выглядит проще JVM, в частности JIT - Just in Time - компиляция там происходит при старте программы, а не по мере накопления статистики использования кода в runtime. Но у .NET тоже неплохой список поддерживаемых языков https://ru.wikipedia.org/wiki/Список_.NET-языков
P.P.S. Вначале хотел написать, что портировать С, C++ или Rust на виртуальную машину смысла нет, но потом вспомнил про .NET))) Хотя Managed C++ явно отличается от обычного C++ в плане работы с памятью, но он есть.
#lang
Скорее всего, кроме собственно Java большинство вспомнит Kotlin и Scala. Еще возможно Groovy - хотя Groovy, созданный как язык общего назначения, сейчас стал нишевым языком для реализации DSL: Gradle, Jenkins как самые известные примеры.
Но JVM - это не только слой абстракции на операционной системой, позволяющий не думать о поддержке разных процессорных архитектур, операционных систем, оптимизациях, сборке мусора, профилировании и многом другом. Благодаря всему вышеперечисленному JVM дает возможность всем желающим (ладно, не всем, а умеющим и желающим)))) придумать свой язык программирования. Или перенести существующий на JVM.
Вот список https://en.wikipedia.org/wiki/List_of_JVM_languages
Да, я подозреваю половина из этих языков уже мертва. Но найти там можно почти все: Python, Go, PHP, Ruby, JS и даже таких старичков как Cobol, Delphi, Visual Basic и Lisp.
Вывод: да, у подхода с использованием виртуальной машины конечно есть и минусы: увеличившаяся сложность системы и производительность. Но и плюсы очевидны, в т.ч. и неожиданные - появляется полигон для создания новых и адаптации существующих языков.
P.S. Virtual machine по большому счету реализовали 2 крупные компании: Sun\Oracle и Microsoft. Причем .NET реализация - CLR - выглядит проще JVM, в частности JIT - Just in Time - компиляция там происходит при старте программы, а не по мере накопления статистики использования кода в runtime. Но у .NET тоже неплохой список поддерживаемых языков https://ru.wikipedia.org/wiki/Список_.NET-языков
P.P.S. Вначале хотел написать, что портировать С, C++ или Rust на виртуальную машину смысла нет, но потом вспомнил про .NET))) Хотя Managed C++ явно отличается от обычного C++ в плане работы с памятью, но он есть.
#lang
Wikipedia
List of JVM languages
Wikimedia list article
❤1
Что станет с языками программирования?
Недавно на одной AI конференции услышал две довольно радикальные мысли.
1) программирование на высокоуровневых языках исчезнет повторив судьбу ассемблера. Останутся только архитекторы.
2) если модели не нравится ваш код - в смысле она не может его доработать - значит проблема в коде
Вот мои мысли по этому поводу.
1) Эти два утверждения работают только вместе. Т.е. если LLM модель пишет код, то он стандартизирован. И тогда любой нестандартный код - плохой. Т.к. он нарушает code style. Назовем его AI code style. И потому что раз уж мы отдали писать код модели - не надо ей мешать
2) С одной стороны аналогия с заменой ассемблера языками высокого уровня красива. И некие аналогии тут есть. Скорость разработки в теории может так же ускориться. Сложность систем, которые можно разработать, вырастет. А запрос как на повышение скорости разработки, так и на создание все более сложных систем, есть. Да, программирование на LLM - это тоже переход на более высокий уровень
3) Где аналогия хромает? Что общего у ассемблера и Java. Оба они детерминированы. Как и разработка в целом. Да, у нас есть место случайности, но она сосредоточена в нескольких местах - реализация функции random, генерация уникальных идентификаторов приходят на ум. А LLM принципиально недетермирована. Использование недетермированной машины для выполнения детерминированного процесса - ну такое себе.
4) Программирование уже пытались убрать из процесса разработки коммерческого ПО. Вот сейчас появилось много AI платформ для no code (low code) разработки. Знакомые же слова. Я про "no code". Да, BPMN системы. И различные проприетарные low code платформы. Свою ниши они заняли, но эти ниши достаточно узкие. Tilda самый очевидный пример. Но если говорить о глобальной замене программирования и программистов - не взлетело
Что думаете по этому поводу?
#ai #llm #lang
Недавно на одной AI конференции услышал две довольно радикальные мысли.
1) программирование на высокоуровневых языках исчезнет повторив судьбу ассемблера. Останутся только архитекторы.
2) если модели не нравится ваш код - в смысле она не может его доработать - значит проблема в коде
Вот мои мысли по этому поводу.
1) Эти два утверждения работают только вместе. Т.е. если LLM модель пишет код, то он стандартизирован. И тогда любой нестандартный код - плохой. Т.к. он нарушает code style. Назовем его AI code style. И потому что раз уж мы отдали писать код модели - не надо ей мешать
2) С одной стороны аналогия с заменой ассемблера языками высокого уровня красива. И некие аналогии тут есть. Скорость разработки в теории может так же ускориться. Сложность систем, которые можно разработать, вырастет. А запрос как на повышение скорости разработки, так и на создание все более сложных систем, есть. Да, программирование на LLM - это тоже переход на более высокий уровень
3) Где аналогия хромает? Что общего у ассемблера и Java. Оба они детерминированы. Как и разработка в целом. Да, у нас есть место случайности, но она сосредоточена в нескольких местах - реализация функции random, генерация уникальных идентификаторов приходят на ум. А LLM принципиально недетермирована. Использование недетермированной машины для выполнения детерминированного процесса - ну такое себе.
4) Программирование уже пытались убрать из процесса разработки коммерческого ПО. Вот сейчас появилось много AI платформ для no code (low code) разработки. Знакомые же слова. Я про "no code". Да, BPMN системы. И различные проприетарные low code платформы. Свою ниши они заняли, но эти ниши достаточно узкие. Tilda самый очевидный пример. Но если говорить о глобальной замене программирования и программистов - не взлетело
Что думаете по этому поводу?
#ai #llm #lang
👍1🔥1