Комментарии 94
Имхо, зря минусуют статью. Попытка применения интрументов анализа кода и практик devops в 1с — это как минимум свежо.
Спасибо. Мое мнение, что использование devops сможет все таки приподнять уровень качества программного кода на прикладных решениях. К тому же сама концепция уже хорошо известна, и успешно работает в других IT областях, а вот в 1С это жутко не хватает. И как капитан-очевидность, скажу что низкое качество кода — это первая причина тормозов в 1С. С этим нужно бороться. И не жутким наращиванием железа, а для начала повышением собственной компетенции.
свежо, но есть хабровская и общая аллергия на 2 буквы «1с».
Хотя devops это методология, которая применима почти где угодно.
Хотя devops это методология, которая применима почти где угодно.
Название работы должно содержать не более 11 слов. Иначе оно не воспринимается аудиторией.
Смотря какой аудиторией. «Осесимметрическая задача о падении тупого твёрдого тела на поверхность несжимаемой жидкости при дозвуковой скорости движения границы области контакта» — в своё время никого не смутила. Подскажете, может, какое слово тут можно выбросить?
А вы ко всем подходили и спрашивали: «а вас не смутило название?» Или все молча сидели с каменными лицами «нам все понятно, заканчивай быстрее»?
А название придумать так, чтобы уместить смысл в нужное число слов — это часть работы над дипломом.
А название придумать так, чтобы уместить смысл в нужное число слов — это часть работы над дипломом.
Всегда говорил, что у айтишников жизнь лёгкая — и ведь Вы айтишник? :-)
Ту же самую работу можно было назвать «приводнение капсулы космического корабля»… если бы речь шла о посте на гиктаймсе. А «там» сидели как раз люди в теме, которым название должно было строго описывать содержание. Изменение одного слова может означать, что решается совсем другая задача. Так что с теми, к кому можно было подойти — всё было в порядке.
Ту же самую работу можно было назвать «приводнение капсулы космического корабля»… если бы речь шла о посте на гиктаймсе. А «там» сидели как раз люди в теме, которым название должно было строго описывать содержание. Изменение одного слова может означать, что решается совсем другая задача. Так что с теми, к кому можно было подойти — всё было в порядке.
Явно зря минусуют.
НЛО прилетело и опубликовало эту надпись здесь
Ну вы что, это ж 1С!
Каждый эникейщик считает своим долгом отреагировать: «Гыгыгыгы вы видели, там буковки русские! Да и ПО русское, что за говно. Тоже мне программисты! Вот мы на первом курсе в Visual Basic формочки рисовали, вот это, да, вот это программирование было!».
Большинство таких людей никогда не видело других подобных систем (потому что в России их в мелком/среднем бизнесе и нет в общем-то) и просто не представляют всех реальных плюсов и минусов платформы 1С.
Впрочем, есть и объективные причины для прохладного отношения к 1С-никам, но это тема отдельной статьи и причины эти к данному случаю точно не относятся.
Каждый эникейщик считает своим долгом отреагировать: «Гыгыгыгы вы видели, там буковки русские! Да и ПО русское, что за говно. Тоже мне программисты! Вот мы на первом курсе в Visual Basic формочки рисовали, вот это, да, вот это программирование было!».
Большинство таких людей никогда не видело других подобных систем (потому что в России их в мелком/среднем бизнесе и нет в общем-то) и просто не представляют всех реальных плюсов и минусов платформы 1С.
Впрочем, есть и объективные причины для прохладного отношения к 1С-никам, но это тема отдельной статьи и причины эти к данному случаю точно не относятся.
По моему за русскоязычный синтаксис уже давно не высмеивают. Высмеивают общий низкий уровень программистов, также высмеивают слишком простой язык с большим количеством ограничений по сравнению с другими современными языками. Еще иногда вендора высмеивают, но это уже знающие больше. Хотя есть конечно отдельные хейтеры простопотомушта, но таких мало.
Тогда вам повезло. Мне в основном встречаются те, что «простопотомушта».
Вы перечислили объективные причины как раз, плюс еще пару я бы добавил.
Но обычно начинаешь спрашивать, чем конкретно не нравится 1С/1С-ники, ничего вразумительного ответить не могут. Может мне просто не везет так.
Вы перечислили объективные причины как раз, плюс еще пару я бы добавил.
Но обычно начинаешь спрашивать, чем конкретно не нравится 1С/1С-ники, ничего вразумительного ответить не могут. Может мне просто не везет так.
Да в общем за те же причины (убогость языка в каких то аспектах и низкий средний уровень) и js с php любят высмеивать. Хотя их поменьше хейтят. Про бейсик и вспоминать не буду.
А сравнивать по хорошему надо 1С с другими DSL типа ABAP и как подсказывает гугл X++
А смысл? Мы же обсуждаем почему не любят 1с и 1сников, а не чем 1с хуже/лучше аналогичных продуктов (по моему все такие продукты довольно скучные).
Просто на абаперов вроде не так сильно возбуждаются. Или они себя программистами не называют?
Хз, если бы хоть одного в жизни видел — может быть ответил бы.
Потому что 1С стоит везде — от пивного ларька, до крупной конторы. А SAP себе могут позволить единицы, поэтому их гораздо реже встречают другие IT-шники.
Ну и устоявшийся термин, насколько я знаю, все же SAP-консультант. Видимо, не называют себя программистами, да.
Кстати, на Хабре была шикарнейшая статья про SAP, которую потом выпилили. Можете найти в поисковике по запросу «пушномолочная свинья несушка sap».
Ну и устоявшийся термин, насколько я знаю, все же SAP-консультант. Видимо, не называют себя программистами, да.
Кстати, на Хабре была шикарнейшая статья про SAP, которую потом выпилили. Можете найти в поисковике по запросу «пушномолочная свинья несушка sap».
У меня один хороший знакомый «громит» 1с на основании знакомства с версией 5,0 под DOS. Другой руководитель ИТ любит поговорить о «недостатках архитектуры» и я предполагаю что последняя версия с которой он был знаком это 7.7/dbf. (В качестве «альтернативы» он пишет «свою ERP» на Delfi 5.0 +… BDE)
С моей точки зрения у 1с есть два существеных недостатка которые не дают занять ему нишу в системах класса управления предприятием — этл 1) отсутсвие эффективного планирующего модуля (того который решает неполиномиальные задачи построения графиков за полиномиальое время) и 2) Интеграция с Android и iOS может быть проведена только через слабо масштабируемый модуль сервера Apache (чрез rest/SOAP)
Но если что сейчас на какие-то мобильные устройства устанавливается Windows 10 то наверное 2-й пункт решается сам собой и на него можно устанвливать уже просто десктопного клиента 1с. Ну а 1-й пункт это не недостаток системы 1с а просто отсутсвие таого алгоритма. Если кто-то его напишет в конфигурации или в виле нативного модуля то это будет работать.
С моей точки зрения у 1с есть два существеных недостатка которые не дают занять ему нишу в системах класса управления предприятием — этл 1) отсутсвие эффективного планирующего модуля (того который решает неполиномиальные задачи построения графиков за полиномиальое время) и 2) Интеграция с Android и iOS может быть проведена только через слабо масштабируемый модуль сервера Apache (чрез rest/SOAP)
Но если что сейчас на какие-то мобильные устройства устанавливается Windows 10 то наверное 2-й пункт решается сам собой и на него можно устанвливать уже просто десктопного клиента 1с. Ну а 1-й пункт это не недостаток системы 1с а просто отсутсвие таого алгоритма. Если кто-то его напишет в конфигурации или в виле нативного модуля то это будет работать.
Ну, не совсем апач, можно и IIS. Плюс можно кроме rest (платформенного: oData) и soap — свой api поверх http написать.
Плюс есть «Мобильный клиент», довольно интересная вещь по идее, работает тоже по http, но тут от прикладного программиста этот уровень скрыт, используется стандартное клиент-серверное взаимодействие 1сное, для программиста довольно простое. Насчет производительности — мне кажется не совсем плохо будет. И кстати, можно например на разных серверах публикации сделать, такая себе «ручная балансировка», если считаете именно взаимодействие http->1с слабым местом
Плюс есть «Мобильный клиент», довольно интересная вещь по идее, работает тоже по http, но тут от прикладного программиста этот уровень скрыт, используется стандартное клиент-серверное взаимодействие 1сное, для программиста довольно простое. Насчет производительности — мне кажется не совсем плохо будет. И кстати, можно например на разных серверах публикации сделать, такая себе «ручная балансировка», если считаете именно взаимодействие http->1с слабым местом
Если у Вас есть инфа расскажите пожалуйста. Ведь свой API это как я понимаю через теже модули Apache/IIS проходит? И мобильный клинет тоже — обращается ли он напрямую к серверу (как например десктопный клиент) или же там все опять реально идет все через тот же модуль Apache/IIS?
Нет, там все будет идти через тот же модуль, но честно говоря мне трудно себе представить чтобы он узким местом был. Во первых, выше уже писал, можно на нескольких серверах публикацию сделать. Во вторых — был вот такой вот доклад.
Признаюсь что доклад не сильно впечатлил. В заголовке доклада 3000 одновременно пользователей. Но потом оказывается что они раз в 30 минут создают один документ. Круто. Говоря по другому можно сказать что 30000 пользователей создают документы раз в 5 часов. Но я бы скорее сказал что это эквивалентно что 100 пользователей создают документ раз в минуту.
В принципе я работаю со всем этим со стороны бэкэнд мобильного приложения и в реальности знаю о проблемах. Я не буду говорить какая часть проблем это проблема 1с какая часть это проблема разработчиков конфигурации а какая часть это настройка сервера ну и собственно производительность железа.
Нагрузка у меня довольно высокая. Это 1000 клиентов которые могут все в часы пик начать работать с приложением производя до 10 запросов в минуту. И пришлось довольно долго требовать от стороны 1С чтобы они проработали оптимизацию всей системы. Явных отказов я сейчас уже не наблюдаю. Но время ответа может весьма варьироваться. Такое впечатление что модуль апача не обрабатывает запросы параллельно, хотя все параметры которые в документации с этим связаны были заданы.
Пока что распараллеливания запросы на несколько апачей не делали пока система справляется. Но я не уверен что распараллеливания обязательно даст положительный результат. если узкое место вдруг окажется не на стыке моего бэкэнд с апачем а на стыке апача с 1с то ускорения не получится.
Конечно кто то сказал да там или сисадмина не те или разработчики. Предположим что это так. Но где взять других. В следующий раз когда нужно будет аналогичную связку делать могут быть специалисты получше а могу и похуже. Так что интеграция с мобильными девайсами все же воспринимается как ограничивающий у масштабированию приложения фактор.
В принципе я работаю со всем этим со стороны бэкэнд мобильного приложения и в реальности знаю о проблемах. Я не буду говорить какая часть проблем это проблема 1с какая часть это проблема разработчиков конфигурации а какая часть это настройка сервера ну и собственно производительность железа.
Нагрузка у меня довольно высокая. Это 1000 клиентов которые могут все в часы пик начать работать с приложением производя до 10 запросов в минуту. И пришлось довольно долго требовать от стороны 1С чтобы они проработали оптимизацию всей системы. Явных отказов я сейчас уже не наблюдаю. Но время ответа может весьма варьироваться. Такое впечатление что модуль апача не обрабатывает запросы параллельно, хотя все параметры которые в документации с этим связаны были заданы.
Пока что распараллеливания запросы на несколько апачей не делали пока система справляется. Но я не уверен что распараллеливания обязательно даст положительный результат. если узкое место вдруг окажется не на стыке моего бэкэнд с апачем а на стыке апача с 1с то ускорения не получится.
Конечно кто то сказал да там или сисадмина не те или разработчики. Предположим что это так. Но где взять других. В следующий раз когда нужно будет аналогичную связку делать могут быть специалисты получше а могу и похуже. Так что интеграция с мобильными девайсами все же воспринимается как ограничивающий у масштабированию приложения фактор.
У нас мобильных пользователей около 1.5к реальных, правда мобилка на 1с, и у нас все основные данные на мобилку загружаются, а потом пользователь периодически на сервер пакеты данных отправляет или забирает, иногда выполняет полную загрузку всех данных с нуля, пока что упирались больше в то что сервер тормозит из за перегруженных бизнес требований, из за которых в свое время запросов накостылили тяжелых. Хотя запросов у нас к серверу немного, раз в 10-20 минут проверка на наличие обновлений, или отправка собранной истории местоположения, сообщений, документов, логов. Некоторые тяжелые запросы (подготовка слепка полных данных пользователя для закачки в мобилку например) перевели на асинхронный режим, чтобы зазря не ждать и не забивать соединение. И это при том, признаюсь честно, что архитектура кривая. По моим прикидкам 1сную часть еще довольно заметно ускорить можно было бы, будь у нас на это ресурсы. И у нас тоже все пока работает на одном веб-сервере где 1с подвесили. Если добавить второй — ускорения не добьемся из за той самой кривой архитектуры.
Ускорения не выйдет только в одном случае — перегруз сервера 1с. По сути если у вас два апача на двух машинах в связке с 1с — они будут работать как два клиента к 1с, вместо одного. Соответственно если сервер 1с свободен — не вижу никаких препятствий чтобы ускорение получить.
Правда скажу честно — замеры не делал, и рассуждаю обо всем этом больше теоретически.
Но я не уверен что распараллеливания обязательно даст положительный результат. если узкое место вдруг окажется не на стыке моего бэкэнд с апачем а на стыке апача с 1с то ускорения не получится.
Ускорения не выйдет только в одном случае — перегруз сервера 1с. По сути если у вас два апача на двух машинах в связке с 1с — они будут работать как два клиента к 1с, вместо одного. Соответственно если сервер 1с свободен — не вижу никаких препятствий чтобы ускорение получить.
Правда скажу честно — замеры не делал, и рассуждаю обо всем этом больше теоретически.
Если будете когда-нибудь оптимизировать сервисы мтогу поделиться одной «находкой». После всякого прода оптимизаций (я их не котролировал т.к. это актически другие разработчики и админы) все равно не было сильно большого эффекта. Пока не увеличили количествопользователей 1с (те который указываются в авторизации для SOAP) спасибо подсказал один консултант по этому вопросу.
Где-то на формумах я тоже подобную рекоменацию читал. Вцелом выход на хайлоад такому решению не грозит. А жаль для 1с это был бы огромный плюс если модно было бы связать например миллион орткрытых девайсов с сервером
Где-то на формумах я тоже подобную рекоменацию читал. Вцелом выход на хайлоад такому решению не грозит. А жаль для 1с это был бы огромный плюс если модно было бы связать например миллион орткрытых девайсов с сервером
«Огромный» ли плюс? 1С ведь не позиционируется как замена доске объявлений типа Avito или социальной сети, а компаний в миллионом сотрудников у нас не найти (если только всех военных не объединить), даже в сбере только около полумиллиона сотрудников.
Другое дело, что скорости много не бывает и можно было бы найти новые применения для такой 1С, только это фантастика — под дикие скорости писать всегда неудобно, а фишка 1С — удобная разработка.
Другое дело, что скорости много не бывает и можно было бы найти новые применения для такой 1С, только это фантастика — под дикие скорости писать всегда неудобно, а фишка 1С — удобная разработка.
НЛО прилетело и опубликовало эту надпись здесь
Мысль о покупке готовой работы не рассматривалась. Хотелось реально что-то сделать самому.
Вариантов тем дипломных проектов рассматривалось много… Короче много всего что было в голове, но ничего из этого не вдохновляло.
Сдаётся мне, эти две фразы исчерпывающе описывают состояние обучения как минимум на данной специальности в как минимум данном вузе. Отсутствие мотивации как у студентов, так и у преподавателей?
Господа, вот вы тут требуете от студента знание методологии DevOps, ITIL, а ничего, что человек на 4 курсе института? Вспомните себя? Или вы уже на третьем все поголовно были Standart, а то уже и Senior! Если, видите, что человек "смотрит" не туда, так покажите ему, куда смотреть и вам зачтется в карму.
Хотя, это наверное все из за того, что "1С" ее почему, то очень многие сильно не любят и любого, кто ей занимается готовы уничтожить.
nlruslan спасибо за статью. Скинул ее знакомым 1С'никам, они довольны.
Спасибо!
НЛО прилетело и опубликовало эту надпись здесь
Честно, но лучше такие выводы ставить в конец. И вместо процентов употреблять слова «несколько», «незначительно» и.т.д в общем понятно.
Спасибо, учту.
Дело в том, что применение DevOps практик должно обеспечить как раз противоположный эффект
В 1С с этим сложнее. Как я уже говорил, сложность заключается в том, что сами программисты 1С слишком сложно воспринимает технологии из других областей. Например, программист пишущий на C++ привычный к чтению англоязычной документации, а вот у 1С-ников это зачастую вызывает ступор. Но опять же, это мое наблюдение. И я буду рад, если это окажется не так.
Дело в том, что применение DevOps практик должно обеспечить как раз противоположный эффект и лучше вчера.
Это если у программистов уже имеется необходимый скиллсет — например, навык писать тестируемый код. Иначе пока они научатся и будет та самая просадка 20-30% производительности.
---а ничего, что человек на 4 курсе института? Вспомните себя?
В томском политехе на втором курсе занимался расчетами ядерного взрыва под Токио.
На третьем — индувидиальное обучение и уже фактически только работа на кафедре — госразработка робота для Чернобыля в должности ведущего разработчика.
Но автор молодец — статья и работа грамотно написана.
В томском политехе на втором курсе занимался расчетами ядерного взрыва под Токио.
На третьем — индувидиальное обучение и уже фактически только работа на кафедре — госразработка робота для Чернобыля в должности ведущего разработчика.
Но автор молодец — статья и работа грамотно написана.
Извиняюсь за оффтопик, но
Мысль о покупке готовой работы не рассматривалась.Неужели для современных вузов самостоятельное написание диплома такое неординарное событие, что это стоит отдельно подчёркивать?
Странно что GitLab до сих пор рассматривается только как сервер исходных кодов. Хотя у него довольно мощная CI/CD часть. Тоже есть runner, отлично работает как под Windows, так и под Linux.
Ну тут возражений нет. Просто как то привычнее Jenkins с его безумным количеством плагинов на каждый случай жизни.
У GitLab есть один маленький недостаток, он в бесплатной версии не может быть использован только как CI/CD для сборки внешних репозиториев. Repository mirroring есть только в EE редакции. А в Jenkins можно сделать сборку того же nginx из официального репозитория опираясь на их теги.
Минус поставил бы, просто потому — что это будут читать бизнеса.И это чтиво им противопоказано.Принятие де-юре научным сообществом? Слишком громкие слова, потому что по части "выводов" знающие поставили бы двойку. По поводу свежести — да свежо.Но для написания кейса реализации просто на хабре, а не вырезками из диплома, объявлением признания научным сообществом де-юре.И включением это в пособие для всех остальных. Даешь шутки "1С ники настолько крутые, что пособия для них пишут студенты их Томского".Без обид, но просто статья — да, полезно.Вытаскивать это как диплом — не стоило
Ок. Вы знающий. А по сути? Что именно в выводах Вас смутило? Почему описание бизнес-процесса не может быть темой дипломной работы, и почему 5 членов комиссии с интересом слушали и задавали вопросы?
Документооборот это кстати очень интересная тема. Просто ит-сппциалисты не всегда ее представляют во всем объеме, в связи с реальными процессами. При этом не только студенты или разработчики с галер но и те кто работает внутри предприятия и как им кажется знают суть этого вопроса. В этом смысле правильно что Вы ее не взяли.
Какие бизнеса читают это ресурс? Почему противопоказано? Что знают знающие про девопс в 1с? При чем тут Томск?
Поставил бы минус просто потому, что вы после точки пробел не ставите.
Если без лирики, то это квалификационная работа по специальности «бизнес-информатика». Бизнес есть, информатика есть. Кому-то эта работа нужна и приносит материальную выгоду. Перечисленные факты вкупе показывают, что автор подтвердил квалификацию бакалавра.
Термин DevOps звучит красиво, но в данном случае немножко некорректно его применять.
В статье покрыта только та половина ЖЦ, которая относится к «dev». Этим, кстати, в очень большой конторе может заниматься отдельный человек в должности билд-инженера, — когда действительно много проектов, которые все нужно правильно собирать, тестировать, и запаковывать, — на билд-ферме из десятков машин. Но обычно за эту часть процесса (до того, как собранные артефакты попадают в репозиторий) отвечают сами разработчики.
А вот «ops» после публикации артефакта только начинается. Во-первых, среда для тестового/staging деплоя должна автоматизированно разворачиваться в каком-нибудь приватном облаке. В следующих правилам конторах, если operations engineer в своём уме, он никогда не опубликует релизный артефакт сразу в продакшен, даже если все тесты на CI были зелёные. Его нужно прогнать через staging с полной репликой боевого окружения — чтобы убедиться, что он не упадёт копии настоящей базы и приближенной к боевой инфраструктуре. Также, артефакт должен быть автоматически сконфигурирован под тестовое окружение — чтобы не пытаться лазить в боевые инстансы внешних сервисов во время тестирования.
Во-вторых, после успешной проверки staging (тоже автоматизированной — со своим набором интеграционных и нагрузочных тестов) деплой идёт на бэкап продакшена. И только если и этот этап пройден успешно, можно выкатывать релиз в прод. Даже если он сломается при выкате — уже есть функционирующий, держащий нагрузку, бэкап на новой версии, на который можно переключиться (снова автоматически) на время расследования инцидента.
Естественно, инфраструктура и бэкапа, и прода в хороших руках управляется из-под системы оркестрирования ресурсов, предполагающей обязательный сбор телеметрии, которая агрегируется в свой собственный набор отчётов — примерно такой же значимости, что и отчёты по тестам. По которым можно ставить задачи по оптимизации перфоманса и ликвидации узких мест… в идеале — аналогично, автоматизированно, прямо в трекер.
Так что operations тема отдельная, и во многом интереснее, чем сборка с автотестами.
Впрочем, даже внедрение первой половины методологии в применении к 1С — это уже неплохо (культуру-то надо повышать). Можно только пожелать автору дойти до конца, и показать когда-нибудь полное внедрение со всеми полагающимися шагами.
В статье покрыта только та половина ЖЦ, которая относится к «dev». Этим, кстати, в очень большой конторе может заниматься отдельный человек в должности билд-инженера, — когда действительно много проектов, которые все нужно правильно собирать, тестировать, и запаковывать, — на билд-ферме из десятков машин. Но обычно за эту часть процесса (до того, как собранные артефакты попадают в репозиторий) отвечают сами разработчики.
А вот «ops» после публикации артефакта только начинается. Во-первых, среда для тестового/staging деплоя должна автоматизированно разворачиваться в каком-нибудь приватном облаке. В следующих правилам конторах, если operations engineer в своём уме, он никогда не опубликует релизный артефакт сразу в продакшен, даже если все тесты на CI были зелёные. Его нужно прогнать через staging с полной репликой боевого окружения — чтобы убедиться, что он не упадёт копии настоящей базы и приближенной к боевой инфраструктуре. Также, артефакт должен быть автоматически сконфигурирован под тестовое окружение — чтобы не пытаться лазить в боевые инстансы внешних сервисов во время тестирования.
Во-вторых, после успешной проверки staging (тоже автоматизированной — со своим набором интеграционных и нагрузочных тестов) деплой идёт на бэкап продакшена. И только если и этот этап пройден успешно, можно выкатывать релиз в прод. Даже если он сломается при выкате — уже есть функционирующий, держащий нагрузку, бэкап на новой версии, на который можно переключиться (снова автоматически) на время расследования инцидента.
Естественно, инфраструктура и бэкапа, и прода в хороших руках управляется из-под системы оркестрирования ресурсов, предполагающей обязательный сбор телеметрии, которая агрегируется в свой собственный набор отчётов — примерно такой же значимости, что и отчёты по тестам. По которым можно ставить задачи по оптимизации перфоманса и ликвидации узких мест… в идеале — аналогично, автоматизированно, прямо в трекер.
Так что operations тема отдельная, и во многом интереснее, чем сборка с автотестами.
Впрочем, даже внедрение первой половины методологии в применении к 1С — это уже неплохо (культуру-то надо повышать). Можно только пожелать автору дойти до конца, и показать когда-нибудь полное внедрение со всеми полагающимися шагами.
Спасибо за замечание. Записал себе в заметки и обязательно подумаю над этим.
НЛО прилетело и опубликовало эту надпись здесь
PastorGL Обдумал Ваши слова. Как и сказал alexey-lustin, в статью мало попало данных по «ops», хотя в дипломе они были. Сейчас уже начинаю понимать, что возможно не достаточно и тему желательно развить. Думаю в 2-х направлениях:
1. настройка контуров dev-stage-uat-prod
2. Логирование и анализ данных.
1. настройка контуров dev-stage-uat-prod
2. Логирование и анализ данных.
Как по тексту так и по комментариям, замечание всем:
Методология — это наука о методиках.
говорите правильно: Методика
Учусь в ТУСУРе заочно на последнем курсе. Диплом собираюсь писать сам :) Может кто и покупает, флаг им в руки. А парень молодец, сделал сам свою тему. Да, это не вечный двигатель, но он молодец, можно только похвалить.
nlruslan alexey-lustin
На конкурс пойдет?
http://konkurs.1c.ru/diplom/
Возможно) Во всяком случае планировал.
НЛО прилетело и опубликовало эту надпись здесь
Если не пытаться, то точно ничего не получится.
СППР умеет хранить исходники??
НЛО прилетело и опубликовало эту надпись здесь
Все можно заменить :)
СППР — Jira — Redmine — GitLab Issue
GitConverter можно вообще не использовать если разрабатываешь в формате EDT
Сценарное тестирование — Ванесса — xUnit
Тест-центр — Zabbix
Центр администрирования — Gitlab CI — Jenkins — Ansible — Kubernetes (все завсит от того любишь ты больше оркестрацию или развертку)
SonatQube — АПК
Так же в списке нет — отдельно юнит-тесты пишут с расширениями в роли моков.
А еще есть механики, которые проверить можно только SikuliX, например нажатие на кнопочку загрузки файла в веб-клиенте.
Плюс под все окружение нужны обертки снимающие журнал регистрации, технологический журнал и дампы в случае падения или зависания.
Очень похожая история. Я учился по направлению «Системы корпоративного управления», параллельно работал в вузе в отделе поддержки и разработки внутренних информационных систем. Работали с 1С…
шучу, не с ним, а с 1С Битрикс.
Т.к. в штате были одни студенты пришлось добавлять в процесс разработки процедуры контроля качества кода, начиная от банального написания подробной инструкции как у нас принято писать код и заканчивая развёртыванием собственного CI сервера. не долго думая я взял все свои наработки и оформил в качестве диплома.
шучу, не с ним, а с 1С Битрикс.
Т.к. в штате были одни студенты пришлось добавлять в процесс разработки процедуры контроля качества кода, начиная от банального написания подробной инструкции как у нас принято писать код и заканчивая развёртыванием собственного CI сервера. не долго думая я взял все свои наработки и оформил в качестве диплома.
Отлично! Только за труд по систематизации инструментов по 1С 8.х надо диплом дать!
Большую часть того что тут написано, многие «синьеры» от 1С не понимают не хотят знать.
А уж статическое или функциональное тестирование код 1С, это вообще для большинства программистов просто фантастика.
Сейчас это только в больших коллективах, где хоть кто-то из руководства понимает необходимость этого.
Большую часть того что тут написано, многие «синьеры» от 1С не понимают не хотят знать.
А уж статическое или функциональное тестирование код 1С, это вообще для большинства программистов просто фантастика.
Сейчас это только в больших коллективах, где хоть кто-то из руководства понимает необходимость этого.
Devops в 1с не оправдан, эффективность затраты/результат низкая. Платформа такие практики не поддерживает, пока не перейдет на модель работы с текстовыми файлами, как у других языков. Пытаться прикрутить их через сторонние решения лишь удлинняет время разработки и удорожает стоимость (г...)кода студентов-"программистов" 1с.
Позвольте не согласиться с вами:
1. Выгрузка в файлы уже давно реализована v8.1c.ru/overview/Term_000000606.htm. Используемые инструменты, зачастую являются оболочками над пакетным запуском 1С.
2. 1C сама развивает свою конфигурацию для тестирования wonderland.v8.1c.ru/blog/1s-tsentr-administrirovaniya-administrirovanie-eto-prosto Насколько она хороша/плоха говорить не буду.
3. EDT, который позиционируется как будущая замена конфигуратора — использует GIT как основной инструмент хранения версий. Причем, хранилище (старую систему контроля версий) — разработчик сказал поддерживать не будет v8.1c.ru/overview/release_IDE_beta
1. Выгрузка в файлы уже давно реализована v8.1c.ru/overview/Term_000000606.htm. Используемые инструменты, зачастую являются оболочками над пакетным запуском 1С.
2. 1C сама развивает свою конфигурацию для тестирования wonderland.v8.1c.ru/blog/1s-tsentr-administrirovaniya-administrirovanie-eto-prosto Насколько она хороша/плоха говорить не буду.
3. EDT, который позиционируется как будущая замена конфигуратора — использует GIT как основной инструмент хранения версий. Причем, хранилище (старую систему контроля версий) — разработчик сказал поддерживать не будет v8.1c.ru/overview/release_IDE_beta
Вот уж нет. Мои 4 года в стиле автоматизации dev и ops для 1С говорят ровно об обратном. После получения кнопки «развернуть в продуктив» на веб-морде сервера интеграции, отдел эксплуатации (то бишь, ops) уже ни в какую не хотят жить без нее. А после получения приемочно-дымовых тестов, позволяющих тыкнуть мордой разработчиков (dev), приславших кривой релиз — они вообще стали счастливы.
Далее следует переход на парадигму «dev+ops живут в одной лодке», но у нас в конторе до этого пока не доросли ментально обе стороны. Тем не менее, польза налицо.
Далее следует переход на парадигму «dev+ops живут в одной лодке», но у нас в конторе до этого пока не доросли ментально обе стороны. Тем не менее, польза налицо.
Devops в 1с не оправдан, эффективность затраты/результат низкая.
Весьма сомнительное утверждение — конечно, одно дело когда надо «а потомучто главбух хочет» немного какой-то отчет поправить в конторе на 1.5 человека, там не нужны ни DevOps, ни (периодически) даже программист (ключевое преимущество 1С для российского рынка — при необходимости, видел сам примеры, бухгалтера сами могли что-то «дорисовать» потому что по-русски и часто понятно), с другой — заваленный релиз даже среднего размера конторе (500+ человек) с самописным решением грозит минимум дневным простоем, что сразу окупает даже двукратный рост сроков разработки
А можно ссылку на библиотеку для расчета цикломатичности кода для onescript? Что-то нигде найти не могу. Или она сейчас входит в состав Vanessa-ADD?
НЛО прилетело и опубликовало эту надпись здесь
А можете что-нибудь порекомендовать по такой теме анализа дерева вызова процедур или функций? Есть некоторые публикации на эту тему, но они не очень свежие:
Трассировка кода: infostart.ru/public/164960
Граф вызовов для модулей 1С + GML на ОФ: infostart.ru/public/190199
Аналог предыдущего на УФ: github.com/SergeFocus/1C-Functin-to-yEd
Хотелось бы узнать, вы чем-то подобным пользуетесь, и как вообще сейчас можно быстро построить такое дерево? Какие-то может еще инструменты для этого есть?
Трассировка кода: infostart.ru/public/164960
Граф вызовов для модулей 1С + GML на ОФ: infostart.ru/public/190199
Аналог предыдущего на УФ: github.com/SergeFocus/1C-Functin-to-yEd
Хотелось бы узнать, вы чем-то подобным пользуетесь, и как вообще сейчас можно быстро построить такое дерево? Какие-то может еще инструменты для этого есть?
Можно посмотреть в эту сторону: github.com/Lead-Bullets/BSL-Parser
Выводы интересные в статье про экономический эффект, повышение стабильности и снижение трудозатрат.
Здесь хочу вспомнить цитату компьютерного учёного Дэвида Уилера: «Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности».
Наверное, DevOps — это новый уровень косвенности, который при росте сложности информационной системы становится просто необходим, чтобы сохранять контроль над ней.
И нужно понимать, что сама сложность с внедрением DevOps никуда не девается, а ещё даже и приумножается. Т.е. вам всё равно нужны будут дополнительные ресурсы, чтобы помимо разработки непосредственно программы, выделять их ещё и средствам автоматизации разработки.
Грубо говоря, раньше вы чинили программу. Сейчас вам нужно чинить ещё и DevOps, когда он ломается.
Что DevOps действительно даёт вам, так это резерв времени: вы узнаёте о том, что что-то сломалось раньше и успеваете починить программу до того, как дефект доходит до конечного пользователя.
Здесь хочу вспомнить цитату компьютерного учёного Дэвида Уилера: «Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности».
Наверное, DevOps — это новый уровень косвенности, который при росте сложности информационной системы становится просто необходим, чтобы сохранять контроль над ней.
И нужно понимать, что сама сложность с внедрением DevOps никуда не девается, а ещё даже и приумножается. Т.е. вам всё равно нужны будут дополнительные ресурсы, чтобы помимо разработки непосредственно программы, выделять их ещё и средствам автоматизации разработки.
Грубо говоря, раньше вы чинили программу. Сейчас вам нужно чинить ещё и DevOps, когда он ломается.
Что DevOps действительно даёт вам, так это резерв времени: вы узнаёте о том, что что-то сломалось раньше и успеваете починить программу до того, как дефект доходит до конечного пользователя.
Хороший диплом, показывающий, что человек не поленился и скомпоновал актуальные инструменты в полезную систему, решающую его прикладные задачи. Насчёт научной ценности — очень сомневаюсь, а вот как повод принять автора на работу — отлично.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я написал и защитил диплом по DEVOPS и инженерным практикам в 1С с нуля