Обзор новой версии 1C:Enterprise Development Tools
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(1)Субъективно у меня стала по шустрее работать и более плавно (возможно связано с указанной оптимизацией для linux), но ресурсов потребляет все равно очень прилично (тестировала на типовой БП 3, edt + java примерно 5 Гб оперативы и 1 ядро проца загружено почти на 100%)
Хорошо, что пытаются оптимизировать, но мне лично больше интересно, когда они сделают нормальную работу с поддержкой конфигурации
Хорошо, что пытаются оптимизировать, но мне лично больше интересно, когда они сделают нормальную работу с поддержкой конфигурации
(12)
я не заметил что IDEA сильно быстро работает как и все продукты JetBrains. Даже когда вводишь код с клавиатуры -> чувствуется подтормаживание по сравнению с тем же VS Code или просто VS. Даже конфигуратор 1С быстрее реагирует, ибо С++ :)
к пользователь IDEA не м
я не заметил что IDEA сильно быстро работает как и все продукты JetBrains. Даже когда вводишь код с клавиатуры -> чувствуется подтормаживание по сравнению с тем же VS Code или просто VS. Даже конфигуратор 1С быстрее реагирует, ибо С++ :)
Не понятно, почему 1С не бросает разработку EDT. Первая предварительная версия вышла еще в 2015 году, финальная версия в 2017 году. Но несмотря на три года разработки (а реально - больше, так как разработка предварительной версии также также потребовала определенного времени), производительность оставляет желать лучшего. Плюс ошибки и функционал не весь. Неужели еще надеются допилить до приемлемого состояния?
Между первой версией 8.0 (2003 г.) и 8.3 (2013 г.) прошло десять лет.
Возможно, за десять лет EDT превратится во что-то приемлемое.
Однако есть сомнения насчет улучшений скорости работы, так как
за три года никаких существенных подвижек в этом направлении не наблюдается.
Возможно, за десять лет EDT превратится во что-то приемлемое.
Однако есть сомнения насчет улучшений скорости работы, так как
за три года никаких существенных подвижек в этом направлении не наблюдается.
(16)
Однако есть сомнения насчет улучшений скорости работы, так как
за три года никаких существенных подвижек в этом направлении не наблюдается.
Сомнения усугубляются еще тем, что практически неработоспособная версия называется "финальной", а не остается в статусе "бета".
за три года никаких существенных подвижек в этом направлении не наблюдается.
(44)
Это несерьезно, потому что есть сильный фактор морального старения.
За 10 лет производительность компьютеров подрастёт.
Судя по загрузке процессора, EDT умеет их все использовать.
Этак можно было лет 15 назад и про 7.7 мечтать: "Подождем, лет через 15 производительность MS SQL подрастет" :)
Судя по загрузке процессора, EDT умеет их все использовать.
Это несерьезно, потому что есть сильный фактор морального старения.
(44)
(16) За 10 лет производительность компьютеров подрастёт.
Судя по загрузке процессора, EDT умеет их все использовать.
Я правильно понимаю, что к вопросу практического использования EDT можно вернуться лет через 10? А пока сидим в старом конфигураторе и "слушаем свои валенки"? Я сам такой же энтузиаст, как в (36), но увидев состояние продукта и, главное - скорость развития - тоже поутих.
(16) За 10 лет производительность компьютеров подрастёт.
Судя по загрузке процессора, EDT умеет их все использовать.
Я правильно понимаю, что к вопросу практического использования EDT можно вернуться лет через 10? А пока сидим в старом конфигураторе и "слушаем свои валенки"? Я сам такой же энтузиаст, как в (36), но увидев состояние продукта и, главное - скорость развития - тоже поутих.
(53)
EDT 1.* неработоспособен, и жалкий ход с изменением статуса на "финальный" только подтверждает это, хорошая мина при плохой игре. Назвали "финальной" неработоспособную версию, "финальная"-провальная :)
И не в Эклипс тут дело, как говорят некоторые. На Эклипс есть немало удовлетворительно работающих продуктов, да и сама Эклипс живет уже 17 лет, что говорит о ее неизрасходованном потенциале.
Полагаю, некая ошибка (или ряд ошибок) была допущена в самом начале проектирования EDT, это ошибка концепции. Ошибки концепции исправлять тяжелее всего, потому что в большинстве случаев надо переделывать 90% сделанного. Что-то крайне важное не учли или плохо просчитали... И все пошло не так. Полагаю, одной из такой ошибок была реализация двойного XML-преобразования при взаимодействии с базой. Вначале XML-выгрузка объектов конфиуграции на диск про помощи прежнего Конфигуратора (охренеть!), а потом еще преобразование этого формата в формат файлов рабочей области проекта, ибо они по XML-структуре не одинаковы (еще раз охренеть!). Ну, и еще что-нибудь подобное. Два-три таких стратегических просчета - и вот, плз, продукт неработоспособен...
Конечно, видимо, им придется перепроектировать и переписывать EDT, если не полностью, то в весьма значительной мере. Что делать с обменом объектами с конфигурацией, точно не знаю. Может быть, будут на лету эмулировать файловую структуру эклипсовского workspace, как я помечтал здесь:
Или что-то еще придумают.
Так что я тоже не полный пессимист. Ждем заново перепиленного EDT 2.* :)
Я правильно понимаю, что к вопросу практического использования EDT можно вернуться лет через 10? А пока сидим в старом конфигураторе и "слушаем свои валенки"? Я сам такой же энтузиаст, как в (36), но увидев состояние продукта и, главное - скорость развития - тоже поутих.
Я со своей маленькой кочки выскажусь так.
EDT 1.* неработоспособен, и жалкий ход с изменением статуса на "финальный" только подтверждает это, хорошая мина при плохой игре. Назвали "финальной" неработоспособную версию, "финальная"-провальная :)
И не в Эклипс тут дело, как говорят некоторые. На Эклипс есть немало удовлетворительно работающих продуктов, да и сама Эклипс живет уже 17 лет, что говорит о ее неизрасходованном потенциале.
Полагаю, некая ошибка (или ряд ошибок) была допущена в самом начале проектирования EDT, это ошибка концепции. Ошибки концепции исправлять тяжелее всего, потому что в большинстве случаев надо переделывать 90% сделанного. Что-то крайне важное не учли или плохо просчитали... И все пошло не так. Полагаю, одной из такой ошибок была реализация двойного XML-преобразования при взаимодействии с базой. Вначале XML-выгрузка объектов конфиуграции на диск про помощи прежнего Конфигуратора (охренеть!), а потом еще преобразование этого формата в формат файлов рабочей области проекта, ибо они по XML-структуре не одинаковы (еще раз охренеть!). Ну, и еще что-нибудь подобное. Два-три таких стратегических просчета - и вот, плз, продукт неработоспособен...
Конечно, видимо, им придется перепроектировать и переписывать EDT, если не полностью, то в весьма значительной мере. Что делать с обменом объектами с конфигурацией, точно не знаю. Может быть, будут на лету эмулировать файловую структуру эклипсовского workspace, как я помечтал здесь:
Или что-то еще придумают.
Так что я тоже не полный пессимист. Ждем заново перепиленного EDT 2.* :)
Поддержу комментарий выше и добавлю,что даже когда EDT чудом догонит конфигуратор,доработка конфигуратора у фирмы 1С будет в приоритете,и он всё равно будет развиваться быстрее чем EDT.Ситуацию всё исправит изменение приоритетов ,но это очень вряд ли.
(10)1С уже больше года не дорабатывает конфигуратор, если не заметили. На партнёрском форуме осенью Нуралиев говорил, что планируют догнать функционал конфигуратора в 2018 году и тогда же перевести разработчиков типовых на EDT.
(20)Может я что-то не понимаю но платформа 8.3.11 включает в себя конфигуратор(были добавлены возможности работы с расширениями+новые возможности для мобильной разработки) .Последние релизы практически всех типовых конфигураций требуют платформу 8.3.11 ну или по крайней мере точно стоит в рекомендуемых.
И EDT только сейчас стал совместим с платформой 8.3.11 ,т.е. это разве не самый наглядный пример отставания? Сейчас уже есть 8.3.12,через некоторое время она будет практически везде,и только через год EDT станет совместима с 8.3.12,к этому времени выйдет 8.3.13 и так уже есть и так будет.
И EDT только сейчас стал совместим с платформой 8.3.11 ,т.е. это разве не самый наглядный пример отставания? Сейчас уже есть 8.3.12,через некоторое время она будет практически везде,и только через год EDT станет совместима с 8.3.12,к этому времени выйдет 8.3.13 и так уже есть и так будет.
(22)
Не путайте минимальную поддержку функционала и придумывание новых фишек.
И EDT только сейчас стал совместим с платформой 8.3.11 ,т.е. это разве не самый наглядный пример отставания? Сейчас уже есть 8.3.12,через некоторое время она будет практически везде,и только через год EDT станет совместима с 8.3.12,к этому времени выйдет 8.3.13 и так уже есть и так будет.
Не путайте минимальную поддержку функционала и придумывание новых фишек.
(23)Думаю, на ближайшие года 2 функционал оригинального конфигуратора (и, отчасти, платформы) - притормозят - на крайняк будут стараться сразу всё внедрять почти одновременно с EDT. Да, и в ожидании платформы 8.4 особо нет смысла развивать конфигуратор и платформу 8.3 - фичи лучше придержать до выхода 8.4. Просто, она, уже по сроку должна была выйти максимум в 2017 году. Но не вышла (и судя по тому, как про неё молчат - в ближайший год и не выйдет, даже бета версия). Видать что-то там буксует очень.... может проблемы с новой серверной архитектурой. А может попросту не было на неё времени - до этого очень сильно буксовал некоторый функционал 8.3.11(12) - так что пришлось его отодвигать отодвигать, а часть уже готовых фич перенести с 11 на 10 релиз. Возможно то же с 8.4 - и в платформу 8.3 сейчас попросту переносят то, что должно было бы быть только в 8.4 (тот же сервер взаимодействия - более логично бы смотрелся в новой серверной архитектурное 8.4 - но его ввели в 8.3.10(11) - хотя, скорее всего, больше на пробу - в 8.4 его, вероятно, существенно переработают под новую серверную архитектуру.
В общем - ждём 1С Платформу 8.4, а затем EDT 2.0 - а там уже присматриваться к ним будет более пристально, и использовать в коммерческой практике!
В общем - ждём 1С Платформу 8.4, а затем EDT 2.0 - а там уже присматриваться к ним будет более пристально, и использовать в коммерческой практике!
(22)
Конфигуратор будет всегда свой для каждой платформы, в таком топорном виде как сейчас, просто набор базового функционала.
EDT - отдельное приложение независимое от платформы. Инструмент, которую каждый может сам под себя настроить, доработать.
конфигуратор(были добавлены возможности работы с расширениями+новые возможности для мобильной разработки)
А куда, блин, тогда эти возможности добавлять если не в конфигуратор? Значит есть платформы мобильные и с расширениями, но их нельзя будет разрабатывать?))
Конфигуратор будет всегда свой для каждой платформы, в таком топорном виде как сейчас, просто набор базового функционала.
EDT - отдельное приложение независимое от платформы. Инструмент, которую каждый может сам под себя настроить, доработать.
Рано или поздно 1C откажется от поддержки оригинального конфигуратора вовсе - а затем вообще выведет его из состава платформы. Другой вопрос - когда это случится... может, конечно, 8-ка успеет дотянут до своей кончины, тяня за собой уже совсем, к тому времени, устаревший конфигуратор.
Думаю, эпоха EDT настанет не ранее чем выйдет в свет 1С Платформа 8.4 - тогда же следует ожидать и редакцию EDT 2.0 (возможно существенно доработанную и оптимизированную относительно 1.x; которая выйдет, возможно, не одновременно с выходом 8.4, а несколько позже, но не раньше 8.4). Тогда же, EDT 2.0 уже не будет работать через конфигуратор - у него будет свой сервис взаимодействия с метаданными ИБ. А 1С Платформа 8.4, видимо, выйдет не ранее, чем EDT по функционалу догонит конфигуратор 8.3, чтобы уже на 8.4 функционал EDT не был ущербным, относительно конфигуратора 8.4 (функцинал оригинального конфигуратора относительно 8.3 тут тоже должен значительно подрасти – может от того он пока не сильно растёт – придержали для будущей платформы).
Тогда с выходом какой-нибудь из подредакций EDT 2.x - возможно 1С начнёт плавно забивать на оригинальный конфигуратор, в основном развивая EDT (и вряд ли ранее выхода EDT 2.0 разработчики типовых конфигураций на него полноценно перейдут, так, чтобы больше почти не использовать оригинальный конфигуратор). Где-то с версии EDT 2.2 этот инструмент, скорее всего, уже будет вполне рабочим, и не особо глючным - и большинство (по крайней мере, почти все франчайзи принудительно) будут разрабатывать уже на нём.
Ну, а далее, когда-нибудь (лет через 10-20), выйдет 8.5 – и это будет последняя платформа, с оригинальным и очень ущербным конфигуратором - далее - лишь EDT 3.x
Но, вероятно, 8.5 будет последней платформой на 8-ке (хотя, допускаю, что под занавес - будет ещё 8.6, как раз перед выходом 9-ки - для обеспечения плавности миграции, уже без оригинального конфигуратора – RIP).
Появление 9-ой платформы 1С вряд ли стоит ожидать в ближайшие лет 10, 20, а то и 30,40. Вполне, возможно, 8.5 будет сама долгоиграющая подредакция 8-ой платформы - которая продержится на рынке лет так 20-30, а то и больше (9-ая платформа, конечно, в виде беты, выйдет немного раньше, чем пройдёт весь этот срок).
Так что, конфигуратор ещё долго будет жить. Но лет через 10 почти все уже в основном будут кодить на EDT, лишь изредка запуская конфигуратор, а лет через 40 и конфигуратора то уже не будет :-(
Думаю, эпоха EDT настанет не ранее чем выйдет в свет 1С Платформа 8.4 - тогда же следует ожидать и редакцию EDT 2.0 (возможно существенно доработанную и оптимизированную относительно 1.x; которая выйдет, возможно, не одновременно с выходом 8.4, а несколько позже, но не раньше 8.4). Тогда же, EDT 2.0 уже не будет работать через конфигуратор - у него будет свой сервис взаимодействия с метаданными ИБ. А 1С Платформа 8.4, видимо, выйдет не ранее, чем EDT по функционалу догонит конфигуратор 8.3, чтобы уже на 8.4 функционал EDT не был ущербным, относительно конфигуратора 8.4 (функцинал оригинального конфигуратора относительно 8.3 тут тоже должен значительно подрасти – может от того он пока не сильно растёт – придержали для будущей платформы).
Тогда с выходом какой-нибудь из подредакций EDT 2.x - возможно 1С начнёт плавно забивать на оригинальный конфигуратор, в основном развивая EDT (и вряд ли ранее выхода EDT 2.0 разработчики типовых конфигураций на него полноценно перейдут, так, чтобы больше почти не использовать оригинальный конфигуратор). Где-то с версии EDT 2.2 этот инструмент, скорее всего, уже будет вполне рабочим, и не особо глючным - и большинство (по крайней мере, почти все франчайзи принудительно) будут разрабатывать уже на нём.
Ну, а далее, когда-нибудь (лет через 10-20), выйдет 8.5 – и это будет последняя платформа, с оригинальным и очень ущербным конфигуратором - далее - лишь EDT 3.x
Но, вероятно, 8.5 будет последней платформой на 8-ке (хотя, допускаю, что под занавес - будет ещё 8.6, как раз перед выходом 9-ки - для обеспечения плавности миграции, уже без оригинального конфигуратора – RIP).
Появление 9-ой платформы 1С вряд ли стоит ожидать в ближайшие лет 10, 20, а то и 30,40. Вполне, возможно, 8.5 будет сама долгоиграющая подредакция 8-ой платформы - которая продержится на рынке лет так 20-30, а то и больше (9-ая платформа, конечно, в виде беты, выйдет немного раньше, чем пройдёт весь этот срок).
Так что, конфигуратор ещё долго будет жить. Но лет через 10 почти все уже в основном будут кодить на EDT, лишь изредка запуская конфигуратор, а лет через 40 и конфигуратора то уже не будет :-(
(32)В EDT сейчас планируем вести несколько разработанных самостоятельно (одна обычная и одна мобильная) - это пилотный проект, далее рассматриваем перевод доработанной ERP. И еще несколько других.
Я думаю, что смогу поделиться своим мнением наверное через 1-2 месяца.
Я думаю, что смогу поделиться своим мнением наверное через 1-2 месяца.
(34) EDT сейчас очень даже хорошо работает для маленьких конфигураций, для ERP конечно подмораживает факт кеширования/компиляции при изменении, но терпимо.
Работать уже сейчас приятнее чем в типовом конфигураторе. Поэтому перефразирую заголовок "Особенности разработки бизнес приложений в EDT для платформы 1С" )
Работать уже сейчас приятнее чем в типовом конфигураторе. Поэтому перефразирую заголовок "Особенности разработки бизнес приложений в EDT для платформы 1С" )
(31)
слияние заработало (осталось еще чуть поправить)
Поправили, но осталось еще чуть поправить? Потом еще чуток и еще чуть - чуточек, но главное поправили! То что не работает - не важно, главное поправили же как и просили. Как же это по - одинэсовски.
(0)
Считаю, что смело переходить можно тогда, когда "флагманский продукт ERP" будет открываться не медленнее конфигуратора, плюс выгружаться-загружатсья из XML. Вот тогда в тот же день можно.
Считаю, что смело переходить можно тогда, когда "флагманский продукт ERP" будет открываться не медленнее конфигуратора, плюс выгружаться-загружатсья из XML. Вот тогда в тот же день можно.
(17)1. А вы сами пробовали открывать ERP в EDT?
Время открытия сейчас сопоставимо с конфигуратором. Плюс есть отличительное преимущество, то что операции в EDT выполняются асинхронно.
2. Импорт проекта сейчас происходит из EDT именно в XML и обновление конфигурации базы выполняется из XML.
Отсюда делаем вывод, что уже можно работать.
Время открытия сейчас сопоставимо с конфигуратором. Плюс есть отличительное преимущество, то что операции в EDT выполняются асинхронно.
2. Импорт проекта сейчас происходит из EDT именно в XML и обновление конфигурации базы выполняется из XML.
Отсюда делаем вывод, что уже можно работать.
(58)
Образно говоря, если для движения автомобиля по обычной дороге требуется мощный буксир, то говорить о приемлемых эксплуатационных характеристиках автомобиля нельзя.
Xeon E5-1630 3.7 GHz, 128 GB, SSD
Однако разработчик нигде не заявлял, что у пользователей EDT для сколько-нибудь приемлемой эксплуатации должны быть "128 GB" и "SSD".
Образно говоря, если для движения автомобиля по обычной дороге требуется мощный буксир, то говорить о приемлемых эксплуатационных характеристиках автомобиля нельзя.
Интересно наблюдать динамику на партнерке. Внезапно рождается на свет очередной энтузиаст EDT, это может быть не обязательно новичок на форуме.
Неделю-другую идет поток восторженных восклицаний вместе с потоком вопросов по поведению и использованию. Потом поток с необходимостью иссякает, иссякает... и энтузиазм неизбежно сливается... Участник остывает, возвращается к насущным делам, посты от него уже касаются работы в Конфигураторе и прочих забот разработчика/внедренца...
Итерация повторяется, уже с новым "энтузиастом".
Плакать или смеяться? Походу обе эмоции наплывают одновременно :)
Неделю-другую идет поток восторженных восклицаний вместе с потоком вопросов по поведению и использованию. Потом поток с необходимостью иссякает, иссякает... и энтузиазм неизбежно сливается... Участник остывает, возвращается к насущным делам, посты от него уже касаются работы в Конфигураторе и прочих забот разработчика/внедренца...
Итерация повторяется, уже с новым "энтузиастом".
Плакать или смеяться? Походу обе эмоции наплывают одновременно :)
реального применения для обычных задач разработки в продукте не нашел. ранее его анонсировали для более удобной разработки мобильных приложений, м.б. и так. Когда то тестил мобильное на обычном конфигураторе - все устраивало и без EDT.
Тыкаешься как слепой котенок по новому интерфейсу только и всего. Но дело не только в привычке. Что то просто не работает - ни ошибок ни результата.
Попробовал режим сравнения конфигураций, там теперь добавилась возможность указать общего предка, думал ну наконец то 3-х стороннее нормальное будет. Но нет, работает все еще хуже чем в конфигураторе. Полноценной трехсторонки так и нет. Режимы объединения вялые, элементарно слить две правки в одном модуле так и не вышло. Так что все как и раньше - через обновление поставки или сторонние утилиты.
Наделал тестовых изменений в проекте, вернул все в базу. EDT говорит ОК а реально изменений нет. Особенно страшно, например, добавить разные реквизиты в один объект через конфигуратор и EDT - или вообще потом не сольешь, или молча затрет половину.
Кто смог получить реальную пользу от edt - делитесь кейсами
Тыкаешься как слепой котенок по новому интерфейсу только и всего. Но дело не только в привычке. Что то просто не работает - ни ошибок ни результата.
Попробовал режим сравнения конфигураций, там теперь добавилась возможность указать общего предка, думал ну наконец то 3-х стороннее нормальное будет. Но нет, работает все еще хуже чем в конфигураторе. Полноценной трехсторонки так и нет. Режимы объединения вялые, элементарно слить две правки в одном модуле так и не вышло. Так что все как и раньше - через обновление поставки или сторонние утилиты.
Наделал тестовых изменений в проекте, вернул все в базу. EDT говорит ОК а реально изменений нет. Особенно страшно, например, добавить разные реквизиты в один объект через конфигуратор и EDT - или вообще потом не сольешь, или молча затрет половину.
Кто смог получить реальную пользу от edt - делитесь кейсами
Как-нибудь соберусь и попробую ещё раз.
Пытался на прошлых версиях редактировать обработки. Столкнулся с ошибками. Отложил на пару недель. Ничего не трогал. Открываю проект, а обработок нет. одни названия остались и невнятные ошибки, мол не смог открыть.
Ладно, установил новую на тот момент EDT и попробовал открыть проект с обработками. Не открылся.
Если в конфигураторе я могу открыть обработку или её копию или сменить конфигуратор и в 99% случаях продолжить работу над ней, то с EDT какая-то неопределенность. В один момент может всё встать.
Если с обработкой можно делать её копии, то при работе с EDT нужно переезжать на виртуалку и бэкапить её целиком?
Пытался на прошлых версиях редактировать обработки. Столкнулся с ошибками. Отложил на пару недель. Ничего не трогал. Открываю проект, а обработок нет. одни названия остались и невнятные ошибки, мол не смог открыть.
Ладно, установил новую на тот момент EDT и попробовал открыть проект с обработками. Не открылся.
Если в конфигураторе я могу открыть обработку или её копию или сменить конфигуратор и в 99% случаях продолжить работу над ней, то с EDT какая-то неопределенность. В один момент может всё встать.
Если с обработкой можно делать её копии, то при работе с EDT нужно переезжать на виртуалку и бэкапить её целиком?
Версия давно вышло из беты, уже 1.7.0.625, но продукт не подходит для серьезной разработки. 1.7 Карл! Не важно какая скорость, просто не хватает базовых функционалов из конфигуратора.
Разве продукт для энтузиастов и развлечения можно выводить из беты?
Разве продукт для энтузиастов и развлечения можно выводить из беты?
Читаю каменты, ребят, зрите в корень - этим проектом 1с выходит из своего уютного, но ограниченного мирка на новый уровень. 1C: EDT - это глобальный инструмент, тут явна видна цель создать свою полноценную ООП среду. Видно, что разрабы 1с злобно косятся на Visual Studio и мечтают когда-нибудь заткнуть его за пояс. И мне кажется, что им это удастся, по крайней мере на российском рынке уж точно. Давайте пожелаем 1с довести дело до конца, ведь дело-то стоящее.
Наличие такого глобального супер-инструмента позволит нам, к примеру, безболезненно конвертировать внешние обработки в разные форматы, что позволит намного проще интегрировать 1с-ные решения с другими средами. Мечтали когда-нибудь о таком? Вот для вас люди стараются, проявите уважение
Наличие такого глобального супер-инструмента позволит нам, к примеру, безболезненно конвертировать внешние обработки в разные форматы, что позволит намного проще интегрировать 1с-ные решения с другими средами. Мечтали когда-нибудь о таком? Вот для вас люди стараются, проявите уважение
уважения, обещания, перспективы ... это все понятно, никто не посягает, путь растет.
Просто конкретный вопрос - вышел продукт уже 2 релиза как финальный, т.е. с ним уже сейчас что то можно делать, как то использовать в работе. Вот и вопрос - кто как смог использовать?
Просто конкретный вопрос - вышел продукт уже 2 релиза как финальный, т.е. с ним уже сейчас что то можно делать, как то использовать в работе. Вот и вопрос - кто как смог использовать?
(62)Никакой наивности, а лишь:
- Особенности совмещения разных внутренних технологий, библиотек, API - архитектуру 8-й платформы 1С постоянно, от версии к версии, допиливает, обратная совместимость не всегда удаётся в рамках текущего API - да и билдить/тестировать некоторые технологии лучше отдельно, от мейнстрима, чтобы не завязываться на его этапы развития и хронологию выхода новых версий.
- Чистой воды маркетинг - чтобы показать стабильное развитие платформы - нужно в ключевых точках изменения версий показать значимый рост функциональности и эффективности новых решений. Хотя после выхода платормы 8.3 таких точек стало намного больше, чем до 8.3, всё же надо ожидать от 8.4 чего-то бОльшего, чем просто очередной релиз 8.3.х. Нужны новые громкие лозунги, которыми можно заполнить пиар продукта нового поколения, коим должена быть платоформа 8.4, чтобы не стать попросту очередной 8.3.100.500
- Я не привязывал жёстко EDT 2.x к выходу 1С Платформы 8.4, я лишь сказал, что ждать EDT 2.0 ранее 8.4 не стоит, но EDT 2.0 может и не быть ранее появления 1С Платформы 8.5... я лишь предположил, что EDT 2 потребует существенного пересмотра принципа взаимодействия с платформой, а так же существенной внутренней доработки библиотек взаимодействия (которые с C++ для обычного конфигуратора в EDT переписываются на Java для Eclipse). Сравнить, например, можно УПП - версии 1.x были очень ущербными (но клиенты брали и использовали, т.к. до выхода КА (причём 1.х была попросту урезанной УПП), альтернативы вообще не было). Но, вот, теперь есть, хотя бы ERP 2.0 - существенно переработанная учётная система, идущая на смену УПП (и KA 2.x кому нужно что-то по-проще). Но выход ERP 2.x потребовал выхода 1С Платформы 8.3 и Такси (а так же новой версии БСП 2.x), т.к. использовал новые концепции построения внешней и внутренней архитектуры (хотя, формально, ERP 2.0 можно было бы построить и на 8.2, да и на 8.1 тоже - на обычных формах).
- Особенности совмещения разных внутренних технологий, библиотек, API - архитектуру 8-й платформы 1С постоянно, от версии к версии, допиливает, обратная совместимость не всегда удаётся в рамках текущего API - да и билдить/тестировать некоторые технологии лучше отдельно, от мейнстрима, чтобы не завязываться на его этапы развития и хронологию выхода новых версий.
- Чистой воды маркетинг - чтобы показать стабильное развитие платформы - нужно в ключевых точках изменения версий показать значимый рост функциональности и эффективности новых решений. Хотя после выхода платормы 8.3 таких точек стало намного больше, чем до 8.3, всё же надо ожидать от 8.4 чего-то бОльшего, чем просто очередной релиз 8.3.х. Нужны новые громкие лозунги, которыми можно заполнить пиар продукта нового поколения, коим должена быть платоформа 8.4, чтобы не стать попросту очередной 8.3.100.500
- Я не привязывал жёстко EDT 2.x к выходу 1С Платформы 8.4, я лишь сказал, что ждать EDT 2.0 ранее 8.4 не стоит, но EDT 2.0 может и не быть ранее появления 1С Платформы 8.5... я лишь предположил, что EDT 2 потребует существенного пересмотра принципа взаимодействия с платформой, а так же существенной внутренней доработки библиотек взаимодействия (которые с C++ для обычного конфигуратора в EDT переписываются на Java для Eclipse). Сравнить, например, можно УПП - версии 1.x были очень ущербными (но клиенты брали и использовали, т.к. до выхода КА (причём 1.х была попросту урезанной УПП), альтернативы вообще не было). Но, вот, теперь есть, хотя бы ERP 2.0 - существенно переработанная учётная система, идущая на смену УПП (и KA 2.x кому нужно что-то по-проще). Но выход ERP 2.x потребовал выхода 1С Платформы 8.3 и Такси (а так же новой версии БСП 2.x), т.к. использовал новые концепции построения внешней и внутренней архитектуры (хотя, формально, ERP 2.0 можно было бы построить и на 8.2, да и на 8.1 тоже - на обычных формах).
Интересно читать комментарии. Но возникает вопрос: а зачем языку 1С такой инструмент, как ЕДТ? Языку, полагаю, особо он и не нужен, а вот 1С'у нужен для дальнейшего развития. Возможно даже языка.
Вообще, суть любой программы - перемещение данных из одной области памяти в другую и их преобразование. Суть программирования на 1С сводится к созданию версий типовых объектов (справочник, документ, регистр) для хранения в них неких первичных данных, характеризующих точку бизнес-процесса, отражающих входящую в базу данных информацию этой точки. Для этого создается форма с реквизитами, которые пользователь заполняет, также формируются проверки связей между реквизитами справочников, документов и регистров, которые в ходе заполнения, проведения и прочих операций (то же печати печатной формы) добавляются, изменяются и уничтожаются.
Все. В этом основная суть функционала любой учетной системы: получили данный от пользователя (в перспективе - от автомата), положили в базу данных. Дальше получили запрос от пользователя (в перспективе - от веб-сайта, мобильного приложения, нейроинтерфейса, ...) - возвратили требующиеся данные.
Так вот, для того, чтобы написать код, достаточно блокнота (или даже nano/mcedit/vim/...). Сложности возникают в том, чтобы красиво выделить ключевые слова, чтобы бросались в глаза, обрамить циклы, блоки IF, прочие блоки (есть такие в 1С?) - было бы достаточно линиями слева указать такой блок (зеленая полоска для циколв, синяя для IF'ов). Дальше автоматическое дополнение вводимой строки + тот самый intellisence (или как его там). Вот для этого всего обеспечения удобства разработки на настоящий момент (как мне кажется) достаточно и конфигуратора. По крайней мере мне. Но мне бы и блокнота, который умеет выделять ключевые слова, хватило )))
Исходя из этого вот какой вопрос у меня возникает: а что конкретно не хватает в конфигураторе, что есть где-то еще? Ну понятно, что поддержка только 1С-ного мягко говоря кривого и косого, медленного и практически лишенного толковой функциональности, хранилища - это основное, что тормозит профессиональную разработку и без серьезной системы контроля версий тут обойтись непросто. А что еще-то нужно для счастья?
Вообще, суть любой программы - перемещение данных из одной области памяти в другую и их преобразование. Суть программирования на 1С сводится к созданию версий типовых объектов (справочник, документ, регистр) для хранения в них неких первичных данных, характеризующих точку бизнес-процесса, отражающих входящую в базу данных информацию этой точки. Для этого создается форма с реквизитами, которые пользователь заполняет, также формируются проверки связей между реквизитами справочников, документов и регистров, которые в ходе заполнения, проведения и прочих операций (то же печати печатной формы) добавляются, изменяются и уничтожаются.
Все. В этом основная суть функционала любой учетной системы: получили данный от пользователя (в перспективе - от автомата), положили в базу данных. Дальше получили запрос от пользователя (в перспективе - от веб-сайта, мобильного приложения, нейроинтерфейса, ...) - возвратили требующиеся данные.
Так вот, для того, чтобы написать код, достаточно блокнота (или даже nano/mcedit/vim/...). Сложности возникают в том, чтобы красиво выделить ключевые слова, чтобы бросались в глаза, обрамить циклы, блоки IF, прочие блоки (есть такие в 1С?) - было бы достаточно линиями слева указать такой блок (зеленая полоска для циколв, синяя для IF'ов). Дальше автоматическое дополнение вводимой строки + тот самый intellisence (или как его там). Вот для этого всего обеспечения удобства разработки на настоящий момент (как мне кажется) достаточно и конфигуратора. По крайней мере мне. Но мне бы и блокнота, который умеет выделять ключевые слова, хватило )))
Исходя из этого вот какой вопрос у меня возникает: а что конкретно не хватает в конфигураторе, что есть где-то еще? Ну понятно, что поддержка только 1С-ного мягко говоря кривого и косого, медленного и практически лишенного толковой функциональности, хранилища - это основное, что тормозит профессиональную разработку и без серьезной системы контроля версий тут обойтись непросто. А что еще-то нужно для счастья?
(63) Ну, GIT сейчас и к обычному конфигуратору прикручивают (через одно место, конечно, но прикручивают).
Для счастья нужно бы ещё (что зависит от среды разработки):
1. Более гибкого инструментария по сравнения метаданных и текстов, форм, макетов (хоть к обычному конфигуратору тоже прикручиваются уже внешние тулзы - этого пока тоже тут через одно место и не так гибко как хотелось бы); даже без GIT
2. Более широкого инструменатрия для командной разработки и учёта доработок задач: т.е. возможность более гибкой интеграция c Coloboration-инструментарием и Servicedesk, в т.ч. ревизии кода, to-do листы, инструменты общения, пр.
3. Многие ждут повышения скорости обработки метаданных в больших конфигурациях
4. Открытые возможности по создания собственных плагинов и инструментов к среде разработки (а не нарушающих лиц. соглашение всяких эксплойтов типа Снегопата и Турбоконфа для конфигуратора). Нужен откртый API, в т.ч. внешний, как OLE-Automation
5. Более продвинутые инструменты по анализу, рефакторингу, скриптованию, и визуализированию метаданных конфигурации и текстов.
6. Поддержки разных шаблонов, текстовых макросов и препроцессоров для предобработки кода (и метаданных) до компиляции в байткод стековоймашины 1С.
7. Широкую кросплатформенность, включая ARM-архитектуру (за которой, как многие считают, будущее, в т.ч. десктопное) даже для среды разработки. Да и поддерживать такое ПО (написанное на Java) в дальнейшем на разных платформах будет намного удобнее, чем сей кучу разных отдельных программ для разных проектов, написанных на С++ индивидуально для каждой платформы отдельно. А когда-нибудь будет и через WEB-браузер кодить - для особых случае, это было бы не заменимо!
8. Ну и, в идеале, хотелось бы появления поддержки модульности архитектуры конфигураций - чтобы её можно было разбивать на отдельные, условно независимые проекты, и объединять их (после работы препроцессорных скриптов, учитывающих настроенные опции сборки) в конечное решение (со всеми расширениями) - которое будет установлено на ИБ. Тут основная работа как раз на плечи среды разработки ложится (и принципиально пересматривается подход к работе с конфигурацией, в отличии от стандарого конфигуратора), хотя поддержка платформы тоже нужна.
Для счастья нужно бы ещё (что зависит от среды разработки):
1. Более гибкого инструментария по сравнения метаданных и текстов, форм, макетов (хоть к обычному конфигуратору тоже прикручиваются уже внешние тулзы - этого пока тоже тут через одно место и не так гибко как хотелось бы); даже без GIT
2. Более широкого инструменатрия для командной разработки и учёта доработок задач: т.е. возможность более гибкой интеграция c Coloboration-инструментарием и Servicedesk, в т.ч. ревизии кода, to-do листы, инструменты общения, пр.
3. Многие ждут повышения скорости обработки метаданных в больших конфигурациях
4. Открытые возможности по создания собственных плагинов и инструментов к среде разработки (а не нарушающих лиц. соглашение всяких эксплойтов типа Снегопата и Турбоконфа для конфигуратора). Нужен откртый API, в т.ч. внешний, как OLE-Automation
5. Более продвинутые инструменты по анализу, рефакторингу, скриптованию, и визуализированию метаданных конфигурации и текстов.
6. Поддержки разных шаблонов, текстовых макросов и препроцессоров для предобработки кода (и метаданных) до компиляции в байткод стековоймашины 1С.
7. Широкую кросплатформенность, включая ARM-архитектуру (за которой, как многие считают, будущее, в т.ч. десктопное) даже для среды разработки. Да и поддерживать такое ПО (написанное на Java) в дальнейшем на разных платформах будет намного удобнее, чем сей кучу разных отдельных программ для разных проектов, написанных на С++ индивидуально для каждой платформы отдельно. А когда-нибудь будет и через WEB-браузер кодить - для особых случае, это было бы не заменимо!
8. Ну и, в идеале, хотелось бы появления поддержки модульности архитектуры конфигураций - чтобы её можно было разбивать на отдельные, условно независимые проекты, и объединять их (после работы препроцессорных скриптов, учитывающих настроенные опции сборки) в конечное решение (со всеми расширениями) - которое будет установлено на ИБ. Тут основная работа как раз на плечи среды разработки ложится (и принципиально пересматривается подход к работе с конфигурацией, в отличии от стандарого конфигуратора), хотя поддержка платформы тоже нужна.