Комментарии 25
DevOps ведь не ограничивается средствами по автоматизации тестирования и развертывания кода.
В данной статье я хотел рассказать о том, как за счет формализации кодовой базы нашей компании удалось повысить производительность (увеличить количество внедренных фич и выпущенных релизов).
А так, само собой, в своей работе мы используем GitLab CI/CD для автоматизации тестирования и сборки, и OpenStack в качестве облачного сервиса.
Просто в этой статье я хотел сделать упор на автоматизации процесса написания кода, а не на автоматизацию тестирования или развертывания.
А под «XXX подразумевает под собой набор методов и средств, позволяющих повысить производительность команды, увеличить количество и качество выпускаемых релизов, ускорить процесс поставки продукта клиенту.» подходит тот же Agile, TDD и еще куча всего
Blazor хороший пример этого веяния.
Раз уж DevOps, то нужно идти до конца и генерировать скрипты фронта на бэке при пуше изменений. Тогда и клиенту будет легче и… можно все сделать на питоне ;)
Мы отказались от самописных JS SPA библиотек в пользу фреймворка Vue.js.
Т.е. в самой первой версии
механизм, парсящий схему OpenAPI и генерирующий представления
был написан на vanilla-js?
JS объекты с параметрами представлений, сформированные на этапе парсинга схемы OpenAPI, передают некоторые из своих свойств в качестве входных параметров компонентам, которые занимаются рендерингом.
В обоих версиях механизм, парсящий схему OpenAPI, реализован на нативном JS, но эта реализация отличается.
Блок, занимающийся рендерингом и маршрутизацией, в первой версии был реализован с помощью библиотек для создания SPA приложения, которые были написаны вне этого проекта одним из наших разработчиков. Они содержат в себе свой шаблонизатор, роутер и т. д. Они были некой альтернативой JS фреймворкам типа Angular’а, React’а или Vue.
Во второй версии для рендеринга и маршрутизации мы используем Vue.js.
Представляю как вы удивитесь, когда увидите, как в 1С модели бэкенда, фронтэнда и в бд меняются синхронно в конструкторе описания объекта, вообще без изменения кода ;)
Да это и грустно и смешно)
То, что в этой статье представляется как что-то новое реально в 1С используется уже 20 лет)) А потом говорят они, на русском пишут, на русском))
А вот и "Свидетели 1С" подтянулись…
Вот я против 1С на той нише где оно изначально работает ничего против не имею, но вы серьёзно сейчас?:)
Вы понимаете разницу между веб-фреймворком на любом ЯП и проприоретарной платформой со скиптовым внутренним языком?
Это всё равно что сказать, что на Python/PHP/любом ЯП уже давно можно работать через web, а 1С только несколько лет назад научились.
Научились в 2008 если не ошибаюсь. Но вот тот гемор, который приходится побеждать на других языках при изменении модели, в 1С отсутствует как класс, это факт.
Не-в-1С добавление поля в модель влечёт кучу лишних телодвижений и порождает решения похожие тем, что в статье. В 1С модель на первом месте, все сопутствующее: схема БД, GUI — изменяются сами
Думаю, что если бы в конструкторе был бы гемор с моделями, которые в нём представлены, то 1С вообще бы никто и никогда не смог и не захотел бы использовать. Я же говорю, это люто некорректное сравнение конструктора (коим 1С является) и веб-фреймворка. Если их сравнивать, то последний однозначно победит, хотя бы за счёт возможностей языка и производительности.
Вывести на рынок систему, написав ее на 1С можно очень быстро.
… и дорого! Потому что это приложение будет зависеть от платформы, которое за каждого пользователя хочет лицензионный ключ. И продаётся уже не ваш продукт, а 1С.
Хейтить 1С за то что там «кодят на русском» — однозначно не стоит.
Причём здесь русский язык? Там и на английском можно, просто никто не пишет ибо незачем: зарубежом никто (бывшие из СССР не считаются) не использует 1С.
Нафига толстый клиент, в таком случае? Можно просто использовать генерацию HTML на сервере.
Генерация моделей на основе API — это как бы совсем не новость и давно есть инструменты для описания и генерации, например, как у protobuf и многое другое.
Хоть для чего-то примитивного это и удобно, но концептуально уровень отображения чего-то клиенту и уровень обработки данных на сервере — это вообще не одно и тоже.
P.S. Если это DevOps, то с таким успехом снять квартиру ближе к офису и не опаздывать на работу — это тоже DevOps.
Модельки на сервере и клиенте пишутся отдельными людьми. Вы изобретаете велик для того чтобы генерить DTO клиента и сервера на основе некоторого описания API, что-то похожее на swagger-gen или JHipster (в дотнетовском мире наверняка есть аналоги посимпатичнее). Бывает так, что к фронту особых требований нет и можно сразу генерировать например формочки. А для статьи вы называете свой велик девопс-фреймворком.
DevOps в разработке: автоматизация написания кода веб-приложений