Пособие релиз инженера 1с и не только pdf
Обновлено: 07.07.2024
Разберём плюсы и минусы применения практик CI/CD с учетом ограничения технологической платформы 1С:Предприятие.
5) Всё очень долго – импорт проекта, запуск проекта, открытие формы и т.п. теряется драгоценное время. А именно оно ценно для среды разработки. Eclipse традиционно был самой тугой средой разработки, а с появлением в ней кучей «плюшек» для разработки 1С стал просто невыносим.6) В основу взят Eclipse, в то время как наши соотечественники из JetBrains разработали куда лучшую IDE даже для того же Java (IntelliJ IDEA). В настоящий момент времени Eclipse уже безнадежно проигрывает по всем параметрам ведущим современным IDE, так что даже после завершения разработки EDT, уровень наш инструментов будет далёк от того, которым пользуются наши коллеги из других языков разработки.
Верно сказано. EDT это мертворожденный ребенок, хоть и более желанный чем старенький конфигуратор.
Кроме того EDT не работает с платформами ниже 8.3.8.
Если 1С рожает мертворожденных то может и для самого 1С лучшие времена уже позади ? (32)
А может быть, на примере с EDT нужно сделать вывод, что 1С не будет тем же, что и другие языки? 1С всегда отличался, и будет отличаться. Эти отличия, конечно, несут и минусы. Но эти же отличия несут и фундаментальные плюсы, благодаря которым платформа и заняла свой рынок и продолжает его отвоёвывать у прямых зарубежных конкурентов. Медленно, но верно. Годы идут, но 1С не теряет актуальности. Хотя и 10 лет назад говорили, что "1С уже фсё", и 15 лет назад.
А меж тем, зарплаты разработчиков 1с то же растут. Это происходит естественным путём, благодаря здоровой конкуренции на рынке. И это говорит о том, что 1с на этом рынке конкурентоспособна.
Невозможность распараллеливания работы над одним объектом привело к тому, что 1Сник - "и на дуде дудец, и на гитаре трындец", в то время как веб-разработчики более подвержены профдеформации, и через 2-3 года работы с одним фреймверком на одном направлении атрофируют другие навыки разработки. Да, мы не станем "специалистом по правой ноздре", так чтобы знать все, но с другой стороны мы можем (что чаще всего и происходит) самостоятельно разрабатывать, внедрять поддерживать всю учетную систему, а специализация конкретного навыка (например знание принципов работы с внешними источниками данных) в принципе может и не всегда нужна, или быть достигнута при помощи коллег/формумов/рабочего выходного.
За статью спасибо.
Ссылки не совсем корректные - добавлен лишний символ, который переводит на страницу 404.
Даа. просто "клюква" про Eclipse, Java, скорость java, интерфейс десктопных java приложений. Написано это всё на Java, соответственно будет медленно, прожорливо и иметь убогий внешний вид. Java – не тот язык разработки, на котором следует разрабатывать нативные приложения с пользовательским интерфейсом разработали куда лучшую IDE даже для того же Java (IntelliJ IDEA) 4) Написано это всё на Java, соответственно будет медленно, прожорливо и иметь убогий внешний вид. Java – не тот язык разработки, на котором следует разрабатывать нативные приложения с пользовательским интерфейсом. Сам отклик интерфейса будет дольше, не говоря уже о прожорливости JVM.Какой то вброс негативной информации, без пруфов.
Возможно java проигрывает с++ в качестве числодробилки в один поток, но хадуп, спарк, кассандра, кафка, зукипер, дженкинс что вы о них скажете? (7) полагаю, Олег имел в виду именно GUI-приложения Java. Я видел только одно нормальное - IDEA от Jenbrains. Но там кастомный, вылизанный GUI. Все "типовые" библиотеки для интерфейсов под Java - адское говнище (в данном случае - медицински точный, выверенный термин, а не захлестнувшие эмоции) Все "типовые" библиотеки для интерфейсов под Java - адское говнище к строке запуска и jar-ник с темой.
Просто на java никто не любит писать гуешные приложения, дa и SWT( гуи эклипса) - совсем не стандартная.
з.ы. Не стоит судить по всей java и java-gui по заложенным 10 лет назад стереотипам. Не стоит судить по всей java и java-gui по заложенным 10 лет назад стереотипам.
Почему-то других почти не попадается. Допускаю, что я плохо искал. Не стоит судить по всей java и java-gui по заложенным 10 лет назад стереотипам
Ну просто это не цель для Java разработчиков.. Java это таки энтерпрайз, и основа для web приложений. Для других целей есть другие нгормальные инструменты. (9) Ну не только GUI. В высоконагруженных системах JVM тоже лишняя роскошь. Но интерфейс это именно то как ты сказал :)
Туфта. Это пишет человек, не пробовавший разветвленную технологию в работе.
Никаких затрат, и никакой сложности. А уж мёрж, благодаря технологии файлов поставок, прост как две копейки.
(10) Если бы не пробовавший. Не было бы этой статьи.
" А уж мёрж, благодаря технологии файлов поставок, прост как две копейки."
А это пишет человек который не видел что такое простой мёрж
(20) Ой да ладно.
Поставка - Обновить - Только дважды измененные - Выполнить.
Поэтому сразу видно кто "просто читал", а кто использовал. (26) Скорее всего Олега попросили внедрить инженерные практики - но это вызвало у него боль отраженную в статье. Он просто не дошел до применения инструментов - поэтому и ошибся упоминая v8unpack ;-) который уже давно не нужен. не. я 2 раза пытался. Сам. В "не 1С" - зашло на ура. в 1С.. ну просто несопоставимые трудозатраты
Ну видимо надо было ещё раскрыть детальнее эту "одну кнопку" в СППР. не обманывайте людей (35) В карточке техпроекта одна кнопка чтобы создать хранилище техпроекта на основании транка и вторая чтобы хранилище техпроекта слить в транк. (35) В карточке техпроекта одна кнопка чтобы создать хранилище техпроекта на основании транка и вторая чтобы хранилище техпроекта слить в транк.
Баян.
А теперь трудозатраты на "добавить реквизит" по СППР-Workflow :). А самое интересное - трудозатраты на "слить ветку". Ну не говоря ещё про "протестировать изменения", сделать ветку от ветки.
Для компаний которые не выполняют проектирование и хреначат все сразу в прод - наверное чтобы "добавить реквизит" это все не нужно. Для остальных - надо делать техпроекты.
Трудозатраты на атомарные операции - выше безусловно. Экономия времени за счет продумывания и предварительного проектирования покрывает этот расход. Надо к СППР-Workflow относится не как к процессу "что-то изменить к конфигурации", а как к процессу "что-то изменить в продукте".
Чтобы "протестировать изменения" достаточно запустить CI на ветке техпроекта) Обычно настройка этого не занимает времени вообще.
Читайте также: