Я зубр и монстр 1С, но из-за текучки некогда изучать УФ, работаю с УТ 10.3, УТ 11 тоже не смотрел, например.
Понятно, что доведется если менять работу, то через франчайзи - кузницу кадров, там и УФ научат и УТ 11-му.
Ну а вообще, сейчас незнание УФ - это большой недостаток на рынке труда или нет. Если что, стаж с восьмеркой 10 лет, с 2005 года.

(0) Ты мамонт.

(1) это плохо?

(2) Они вымерли.

(2) Кто-то и на 7.7 сидит до сих пор.
УФ - стильно, модно, молодёжно. Правда наш паровоз вперёд летит, УФ уже не тренд, тренд - отказ от модальности и мобильные приблуды.

Это просто ограничит спектр вакансий. Всегда найдется работодатель с в хлам переписанной древней УПП, которому УФ никуда не впёрлись.

(0) Без УФ ты сейчас труп. Это модное слово не так давно дошло до кадровиков, теперь даже где УПП или 7.7 требуют УФ. Типа а вдруг будем переходить.

ЗЫ. Год плотно програмлю на УФ (плююсь, но програмлю) - очень много тонкостей и прыжков зайчиками.

(6) Мне больше всего поиск в динамических списках доставляет. А вам?

(6) УФ - уже труп....

УФ - мертвороженное дитя 1с, я уверен будущее в отказе от исполняемого кода на клиенте....

(8) Всё на сервере? А на клиенте даже сумму двух чисел не посчитать?

(9) я вижу именно так, это решит и проблемы мультеплатформености кода и веб клиентов, и безопасности и вообще всего....

собственно это идея не новая, и даже в 1с уже реализована в сервисах....

(10) Ну не знаю. В веб-приложениях много исполнимого кода на клиентах(знаю - сам писал, хоть и не люблю клиентский веб), на JS бешеный спрос. Интерактивность, туды её в качель. А в 1С всё тупо шлётся на сервер?

УФ это тонкая прослойка между простенькими старыми конфигурациями и лютыми БСП 2.2, асинхронными вызовами, разделением данных и прочими ERP.

Конечно, кто туда не заглядывал, видит только одни "ненужные" УФ - за деревьями леса не видно.

Поэтому беда совсем не незнание УФ. Беда это уровень ниже плинтуса и нулевой опыт во всех дальнейших плюхах.

(3) Не преувеличивай

(2) Очень

(8) как только отрасль перейдёт на БП 3.0, ЗиУП 3.0  и ERP 2.0 ты станешь трупом

(14) Это научно доказанный факт. Мамонты вымерли. Тут нет преувеличения.

(17) сколько раз не скажи "Халва", в роте слаще не станет

(18) в роте? Ладно, пофиг...
Не въехал к чему пост был.

(17) вообще-то их съели. Гению 1С это не грозит.

(20) Их ели, но популяция вымерла.

(21) Жрали точно, только они это выдержали..

(21) ОФФ. Есть две теории. Теория (скажем так) "консумации кроманьонцами"  и климатическая. Один интересный факт позволяет выбрать. Была островная популяция мамонтов, которая существовала 5000 лет назад. Несмотря на все климатические изменения. Пока к ним не приплыли охотники. И их съели.

(0) Читай (23) Тебя ждет то же самое!

(16) согласен,  все текущие решения написаны на уф.
(0) спецом ты был до выхода 8.2 сейчас остался опытный программист

(16) мой труп можно реанимировать двухнедельными курсами в 1с или же работой во франче. гыгыгы... УФ изучить можно (надеюсь) быстро. А вот 10 лет опыта - это уже немного более ценный капитал

(25) а разве УФ пришли в 8.2? Вроде как их придумали в 8.3.

(0) Не парься... скоро кодеры 1С разделять на backend и frontend , там уже и определишься куда тебе ближе.

(27) УФ с 8.2

Прочитать книжку Разработка управляемого интерфейса - и ты уже на уровне многих.

А прикладуха на конфах - фигня все это и учится на ходу.

(26) А бывают мамонты, которые уже давно освоили УФ. Как их догнать? ;)

(0) Все фигня, кроме пчел...

(31) годы стажа в кодинге - ничто. Технологии ограниченны, да еще и часто меняются стремительно.

(31)
это элементарно, Ватсон!
надо подождать когда фирма 1С откажется от УФ!
кстати недолго осталось ))))))

(33) c++ вечен!

(0) УФ -  не понял что там сложного нашел. Тот конструктор, только пишешь этот код на сервере, тот на клиента...

(36) сложность - изменить стиль.... то есть нужно при интерактивном действии как можно меньше передовать управление на сервер, в идеале только 1 раз.

(16) я 2 года сижу на бух 3.0, а до этого сидел год в документообороте. Я писал самописку на УФ... Я знаю УФ (и умею их готовить), но мне они не нравятся...

(36) Для фиксина это слишком сложно :)

(34) почему недолго осталось ?

(27) мдя... и этот человек называет себя "гением" 1с
*рукалицо*

(0) Конечно же не вредит!

Любой мистабол знает, что все эти нановебтехнологии типа УФ и Такси никому на самом деле не нужны, и это усатый все от скуки развлекается.
Да и вообще весь снеговик от скуки.

Вот надоест ему - он сядет в кресло у камина, выпьет вискаря, закруит сигару, и напишет информационное письмо о прекращении эксперимента с УФ, об остановке облаков, о возобновлении поддержки 1.6, о выпуске 7.7, нормально работающей на современных ОС и СУБД - и вообще о том, что теперь отныне все делается ради того, чтобы зубры и мамонты могли не напрягая извилин просто подставлять всем лопату для бабла.

Все так и будет, верьте.

(32) и пчелы тоже фигня!

гений, я разочаровался в тебе.

На самом деле ТС очень комплексует по поводу своего незнания УФ. Он мог бы как угодно пудрить всем мозги, называя себе гением ЖКК раньше, когда было пофиг, где какие команды выполнять, но теперь он сам видит собственное невежество. Это сильно задевает его самолюбие. Вот он лезет сюда, умоляя "Ну пожалуйста, скажите мне, что я не лох!"

(41) чем тебе облака не нравятся ?

(0)
Чо то поздновато ты во франчайзи собрался. :)
Самому изучить никак что ли?
ты ж "Гений".

Без знания УФ и клиент-серверной модели пока есть возможность устроиться, т.к. многие фирмы сидят на старых конфах и не думают переходить.
Но иметь представление нужно, хотя бы для понимания механизмов в БП 3.0, т.к. именно с ней в первую очередь приходится сталкиваться в плане УФ, да и поддержку БП 2.0 рано или поздно прекратят.

(45) Это ж как надо постараться, чтобы не разглядеть там сарказм?)

(46) Я кстати без проблем внедрил БП 3.0 без знаний УФ...
показалась очень похожей на 2.0 только интерфейс другой.
Причем я переделывал правила обмена из УТ 10.3 - БУХ 2.0 на УТ 10.3- БУХ 3.0... по структуре очень похоже...все взлетело.
....
вобщем не сильно нужны УФ для БУХии, потому что в Бухии интерфейсы ты переделываешь чрезвычайно редко, а на уровне сервера, там не сильно много изменений. Разве что какое-то фоновое выполнение появилось в документах... но я вобщем не заметил сложностей совсем... как обычно... все сделал, но ничего не понял :)))

БСП 2, мдя, использовать фоновые задания для формирования отчетов это сильно.
(48) ты бы еще подсистему бы написал в БП3.

(48)
БРП 3.0, как правило, встает влет, это да, но если придется там копаться в отладчике при решении проблем, или что то дорабатывать, то без знания УФ никуда не денешься.

(50) Ну может быть, я внедрил да уволился (первый квартал сдали если что, потом уволился) :))) но вроде парни не жалуются.
Да и когда внедрено и появляется какой-то баг... есть обычно время покопаться... это на внедрении много работы.

я, кстати недавно бизнесу посоветовал внедрить УТ10 вместо УТ11 и по мозгам не ездить до часа Х.

(50) знания по уф нужны уже и в бп 2.0

(50) не столько УФ, сколько БСП. Меня как-то попросили сделать ВПФ для 3.0 - я немного прифигел, пока разобрался...

Кстати, а это правда, что те проги, кто сейчас сидят на 7.7, бешеные бабки заколачивают?

а отличается сейчас у кого-нибудь ценник на создание аналогичного функционала: толстый клиент vs УФ (часы, стоимость часа)?

(48) еще-ю оно по структуре не было похоже - БП3 это по сути та же БП2 с другой мордой. А вот с ЗУП3 совсем другая песня.

(8) Да, УФ - мертворожден, это факт, но отказ от кода на клиенте - это бред. Посмотрите на смартфоны и на попытки фейсбука хотя бы отказаться от нативного клиента в пользу html5 и к чему это привело - все равно переписали все обратно на нативный клиент.
Пытаться все бездумно перенести в облако/на сервер - это фантазии, оторванные от реальности.

(58) > мертворожден

ПОЧЕМУ ?

Гений, берешь методичку http://infostart.ru/public/100837/ которую ты сам написал, сам отвечаешь на все твои вопросы, если все хорошо - значит проблем у тебя нет.

Какие УФ? В твоей методички это есть? Нет. Все хорошо, не переживай. Пиши побольше интересных, жизненных статей на ИСе. Ты же гений.

(60) и ногами его, ногами (с)

(56) ценник один, это квалификационное требование
УТ 11 не заточишь без УФ

(59) потому что они нифига не управляемые. Весь мир делает системы, где можно расставлять элементы с точностью до пикселя, а в УФ ты даже не можешь убрать строку заголовка формы!

Я вот ЗУП 3.0 ковыряю и офигеваю
Использовать фоновые вызовы для заполнения документов, среднего и прочих расчетов - это жесть.
Учитывая, что все это глючит ужасно, отлаживать совершенно невозможно

(61) человек сам пишет: "План проведения собеседования, лично использовал раз десять при собеседованиях при работе во франчайзи."

В чем проблема, самому распечатать свой собственный план, проставить там плюсики и понять ответ на вопрос в (0).

Все хорошо, нет проблем. Гений - он и в Африке Гений. Надо седлать волну мега-внедрений. У вас у всех жизнь сложилась, а у Гения - удалась.

(65) дык я с тобой согласен,
Г1С загнал себя в очевидную логическую ловушку , а твой ход признан исключительно смачным

(58) УФ это не отказ кода на клиенте)
УФ это разделение кода на клиент и на сервер, что очень хорошо.

(0) Да. Сильно.

В общем есть тенденция неимоверного усложнения типовых конф, и если не будет существенного повышения ЗП 1С программистов, то количество спецов сократится, но качество естественно возрастет. Нет особого смысла тратить столько времени на постоянное изучение новых сложных механизмов, еще все постоянно меняется, и при этом получать ЗП ненамного больше какого-нить рабочего. Я на примере провинции говорю, в Москве хз как там.

(64) да - фоновые вызовы это какая-то хрень. безотносительно даже сложности отладки - работают эти вызовы через одно место, сегодня работают, завтра нет.
Ларёчники без своих айтишников прям писаются от счастья.

(69)[ если не будет существенного повышения ЗП 1С программистов, то количество спецов сократится,]
не а, БП 3.0 ни даёт ни какого выигрыша в производительности и платить больше Заказчик за УФ не будет

а вот, то , что их профессии уйдут древние старцы, не умеющие учиться - да, это будет

(71) Думаешь, ТС уйдет из профессии? :)

(71) Я вот тоже не знаю УФ. Так, знакомился на уровне книжки Радченко год назад. Возможно я реально только очень поверхностно пробежался по УФ, но ничего запредельно сложного там не увидел...
В чем там основные трудности при разработке?

(71) Древние старцы могут не уйти и повысить значимость тех, кто умеет учиться))

(71)
1С может вынудить заказчика переходить на УФ/БСП, постепенно отказываясь от поддержки старых конф, что и наблюдается.
Про БП 2.0 вон сколько тем уже насоздавали, рано или поздно поддержку прекратят.

(75) 7.7 ЗиК еще на поддержке.... а ты говоришь...

(71)
Ну старцы то понятно, я вот тоже чувствую, что постепенно становлюсь таким, неинтересно стало копаться в этих дебрях БСП. ))
Я про несоизмеримость умственных, нервных и временных затрат на обучение и собственно саму разработку и получаемого от этого профита.
ну тут еще надо иметь в виду, что программирования как такового становится меньше, а больше настройки, грубо говоря, "расстановки галочек".

(72) в публичный дом?

(76) Ну значит ветеранам еще будет  возможность для работы.
Хорошо бы.

(78)
Скорее в порноиндустрию
:)
Будет снимать бюджетные фильмы.

(80) это было бы хитово - "100 кисок Фиксина"

о! кто-то сделал демотиватор в тему, правда где-то скрыт подвох:
http://savepic.su/3896152.jpg

(78) Кому он там нужен...

(81) Да, вот только проблема в том, что в "100 кисок фиксина" не верит никто, кроме самого фиксина.

50 оттенков сосипа

(77)[Я про несоизмеримость умственных, нервных и временных затрат на обучение и собственно саму разработку и получаемого от этого профита. ]
нет ни каких проблем с освоением новых технологий, ты просто стал немного старым (с)

(82) Только там дожна быть подпись:
вместо твоим, своим )))

(8) +1 будущее за умением бизнеса считать деньги и пониманием, что ремоут апп по 70 долл за лицензию на всю жизнь решает все проблемы. уф идут лесом!

(0) Это очень большой минус. Кому нужен Ваш обширный опыт в неактуальных технологиях?

(0) Спецу не вредит, т.к. для спеца изучить УФ труда не составляет. А для кого это проблема - это имхо не спец.

(0) помнишь ты мне скинул клиента на УФ? так вот там тоже целый франч в течении года изучал УФ на кошках и не помогло, если помнишь :))))

Меня на всех собеседованиях последние 4 месяца одним из первых вопросов спрашивали, владею ли я УФ

(92) Привет,ты работу недавно искал?

(93) Да, но уже а) не ищу и б) я уже не в Питере

(94) куда же перебрался ?

(18) "в роте"? может, "во рту"? Если речь, конечно, про рот и вкусовые ощущения.
(95) На Малую Родину

Вон и http://job.mista.ru/users.php?id=17673 в Херсон перебрался.

(95) Не столь существенно.

(98) мск ?

(96) Наоборот, на большую )))
(99) Она не резиновая, я туда ни ногой, только если прогуляться

(45) "Любой мистабол знает..." и далее по тексту)

>Я зубр и монстр 1С, но из-за текучки некогда изучать УФ, работаю с УТ 10.3

оксюморон

(0) Зубрдятл испытывает попоболь при виде УФ? Хехехе.

Гений вас разводит!
И весело ржет с вас под столом!

а что будет когда доберется до клиент&сервер...

(104) да уже давно понятно что толщина фиксина как тролля превышает допустимые пределы. Непонятно только - напуркуа ему известность с таким душком.

(105) Ждем новых статей в КнигеЗнаний, полных наркомании и феерии.

(107) "Мой гений дарит вам..."(с)

(104) почему же? я в самом деле не знаю УФ.
Недавно надо было выполнить код в Рознице 2.0 под УФ, так я необходимый код прописал в обработке на управляемых формах в событии ПриОткрыии, т.к. не знал, как туда кнопку добавить,  например.

(33) в 1с опыт важен, основная механика не меняется, а с годами узнаешь много нюансов

(91) помню, но ты меня и франча не отождествляй. Я все же покруче среднего франча буду. ;-)

(111) Зато средний франч УФ знает, ибо БП 3.0.

(111) дело то не в знании УФ, а в умении их готовить - там люди такого наворотили, что переписанная УТ встала раком в первый же день серьезной нагрузки :)

В чем проблема за неделю въехать в уф, если конфа с которой придется работать окажется на уф?
Да- не привычно, да- кнопочки по другому создаются и место выполнения процедур выбирается в зависимости от выполняемого кода, а не в одном мешке, ну и мелкое запоминание каких то моментов которые не работают на тонком клиенте и как их обойти, но ничего непосильного. Просто не привычно, так же как и при смене ОС на компе.

(114) надо привычки менять и вникать в нюансы управляемых форм. чтобы сделать что-то абы-кабы может недели и хватит.
чтобы стать специалистом по простым формам тоже время надо, так и там, тупо нужен опыт, которого у гени нет.

(0) Не принципиально.
Нужно знать хорошо то, с чем сейчас работаешь, а не все подряд понемногу.
1С достаточно примитивная штука, при появлении необходимости все нужное осваивается за месяц, если хороший базовый уровень программирования.
Если пока не нужно, то нет смысла забивать голову. Когда понадобится, возможно все уже полностью изменится.

>> в 1с опыт важен, основная механика не меняется, а с годами узнаешь много нюансов

ты бы еще вспомнил что на 77 писал, это тоже же опыт.

(117) а что, партионка сильно поменялась? или там торговое оборудование, штрихкоды и серийки? гыгыгы

(118) вот не поверишь но в УТ партионный учет совсем не похож на все что ты знал до этого :)

>а что, партионка сильно поменялась

жалкая пародия на волновое проведение

(0)влияет на сроки.на выполнение заявок изначально уходило в 2 раза больше времени.приходилось оценку занижать

(119) в УТ 11 по сравнению с УТ 10 не похож?
Можешь в двух словах объяснить, что поменялось?

какое забавное мероприятие - амнистия - сразу миста заиграла уже забытыми красками...

>миста заиграла уже забытыми красками...

50 оттенков гыгыгы

(122) в двух словах:
Приходные документы сразу формируют движения по партиям,
а расходные только при актуализации партий
и перепроведение документа сбрасывает границу последовательности партий
и еще до фига всего

(125) это ты отличия описал?

(124) 50 оттенков гения. Не, на а че?)

УФ тренд, все будут на него постепенно переходить.
очевидно что от УФ 1С в ближайшие 5-10 лет не откажется и ничего нового не предложит.

(128) давно уже тренд, после них обычные формы ничего кроме мата не вызывают

(129) +1
Особенно привязки...

(128)(129) зачем всех тянуть на технологии мобильных устройств?

1с как была в большенсве на персоналках так и будет ближайшие много лет....

я считаю, что 1с ради автоподгонки формы под параметры экрана потеряла очень много из того что было ей наработано за прошлые годы...

(131) А что именно потеряла? Есть недоработки, я согласен, но имхо потому, что руки ещё не дошли, а не по фундаментальным причинам.

(132) а я считаю, что именно есть фундаментальные проблеммы...

1с была хороша простотой, а сейчас попробуй просто инструкцию со скриншетами сделай для отдела из 30 человек у которых разные права, они тебя замордуют "у меня не так на экране"... то есть это простейшее действие по документированию....

1с слишком сильно ушло в уверсианализм....

(133) А по-моему это наоборот хорошо, что формы подгоняются под права, описывать проще, существенно реже ошибки доступа.
Мне УФ нравятся всем, кроме некоторых неоправданных ограничений.

(134) какие ограничения? например

(134) Динамические списки с поиском, недоступным программно.

+(136) Отсутствие обработчика "при обновлении формы".

Обработчик "При обновлении формы" и в обычном режиме считался г*внокодом.

(138) А в тонком клиенте он бы как раз пригодился для исполнения клиентского кода.

(139) Вот ни разу не пригодился. Даже не знаю куда бы его можно было воткнуть, если бы был.

(140) Ты его с "При выводе строки" не путаешь?

>Особенно привязки...

это вообще мелочи

(141) Я про "ОбновлениеОтображения"

И про неподвластный программисту поиск тоже хотелось бы чего-нибудь услышать.
А, ещё данные динамического списка недоступны, поэтому делать итог по колонке приходится через ЖПО. И не говорите мне, что мол "не нужен".

(143) Ну значит мы по-разному смотрим на проектирование GUI. Имхо, хоть он и не супер-востребованный, но всё же не помешал бы.

(145) Если форма работает как автомат - обновление отображения не нужно. Она четко меняет своё состояние/отображения по указанным событиям.

Если код помойка - конечно, легче восстанавливать состояние формы по каждому чиху.

(146) Ну в старых типовых такой помойки - как грязи.

+(147) Я про обычные формы, естессна.

(144) Вот реально не нужен. Множество элементов, отображаемых в дин списке не имеет какой-либо логической целостности, чтобы можно было им оперировать как единым целым. В отличие от, например, множества выбранных пользователем шифтом строк.

(149) Список документов с суммами, не?

Короче, может кому и не нужен, а я тем таких видел вагон и маленькую тележку.

Пишут же, стараются. Значит кому-то нужно:
http://www.develplatform.com/2013/02/blog-post.html

(0)
По поводу УФ
Само рисование форм - ерунда. Надо только привыкнуть к постоянной группировке реквизитов.
После того как в очередном релизе добавали шалоны групп с отображением и без стало просто.
имея типовую конфу перед глазами за 2-3 рисовать формы можно научится.

Клиент - Серверная кухня начального уровня тоже не сложная.
Однако при вхождении постоянно возникает напряги - то можно делать на клиенте, а что нельзя.
После того как при создании обработкичка события 1С добавила опять же шаблон выбора - создать на клиенте или на клиенте и сервере - стало меньше бесить.

Отдельная  песня с передачей данных между клиентом и сервером - пока привыкнешь упаковывать таблицу значений в массив структур - не раз помянешь 1С незлым теплым словом. потом правда привыкнешь.

Но это все цветочки.
Вот что бы разобраться с концепцией проведения и формирования проводок и перепривыкнуть к концепции той же БП 3.0 - нужно сильно  больше времени, равно как разобраться и перепривыкнуть к концепции формирования печатных форм согласно БСП.


А вообще потом привыкаешь.

Все равно по большому счету стоимость 1С-ника в первую очередь определяет знание и способности в предметной области - тонкости программирования в условиях наличия типовых конфигураций и курсов подготовки - это дело наживное.

(151) Тем про то, как из объекта обратиться к форме или вывести вопрос при проведении тоже немало.

А после подобных (152) извратов, пользователи начинают серьезно оперировать этими суммами, забывая про помеченные и непроведенные доки и т.п.

(152) Динамический список - по сути сильно урезанное табличное поле, с условным оформлением, но без событий вывода, без нормального поиска, без возможности использования временных таблиц. Одну фичку добавили, 10 других убрали(

>> а что, партионка сильно поменялась? или там торговое оборудование, штрихкоды и серийки? гыгыгы

откуда я знаю, я зарплатой занимаюсь, и последнюю ут видел лет 8 назад.

если сравнивать отличия зуп два с половиной от три то переделали дофига. все надо по новой вникать, опять как в первый раз в первый класс.

>пользователи начинают серьезно оперировать этими суммами, забывая про помеченные и непроведенные доки и т.п

это уже его проблемы как он интерпретирует эти цифири... но грид учетной системы должен уметь посчитать итого по выведенным/выделенным позициям... ничего в этом сверх-гигантского или крайне неверного нет

(157) +1
(154) Ну не надо - и не надо. Я ж тебя не заставляю делать.

(125) и че? у меня в УТ 10.3 партии формируются не при проведении, а в отдельном регл задании, чтобы не тормозить проведение. Ничего нового они не выдумали, ибо выдумать что-то сложно, об этом бы все уже галдели.

слыхал там в 1С идут религиозные войны насчет модальности форм, забавно.
То бишь 1с считает не круто такие функции как Предупреждение и Вопрос. А вменяемые люди типо считают нормальным их использование. Что-то вроде спора по поводу GoTo у классиков.

(152) пресекать надо подобную ИБД на корню. ;-) жаль эти УФ взлетели, придется когда-нибудь в них вникать. Эх, уже не дешево и не сердито

(161) Там вообще-то обещают реализовать всё это нормально, а не через одно место. Но (154) это не надо, ему и так хорошо.

+(162) Там - это 1С в платформе обещает сделать, в смысле.

(160) "То бишь 1с считает не круто такие функции как Предупреждение и Вопрос."

Вот так в одном предложении вскрывается вся глубина некомпетентности. Про "ПоказатьВопрос" гений не слышал, не говоря уже об обработчиках оповещения.

http://v8.1c.ru/o7/201410ext/index.htm - вон какую вкусноту обещают. Правда глюков опять будет выше крыши.

(164) Слушай, колеблющийся с линией партии... Что ты будешь делать, когда добавят то, что тебе сейчас не надо, а? :)

(165) на костыль смахивает... лучше уж базу пусть сделают раздельную -  операционную и olap

(167) Это не про то :) Хотя OLAP бы тоже не помешал, сейчас многие на коленке делают.

(155) в 8.3.6. вроде добавили события вывода

+(168) Как я понял, расширения - это типа плагинов, при этом типовая остаётся неизменной, а объединение выполняется платформой. По сути, развитие идеи поставки.

(169) Да там много чего добавили, я уже третий месяц слюной капаю :) Когда? В смысле, "доколе"? :)

(166) Казалось бы причем тут про "ПоказатьВопрос" в (164).

А что буду делать, странный вопрос.
Вот уже добавили - можно сунуть настройки ДС в компоновку и вычислить что угодно. Делать при этом надо одно - изучить как работает и отложить для тех задач, где это реально необходимо, а не там где дядя Вася с бодуна придумал.

http://s5.pikabu.ru/post_img/2014/05/23/6/1400835435_531193172.png

А расширения один хрен не обойдутся без хранения, хотя бы  своих настроек. Ожидаемо, в БСП будут наляпаны разные справочники для подобного храненения.

наверно особенное удовольствие доставят расширения любителям динамически обновляться)

(174) А зачем им обходиться без? Будут отдельные таблицы для объектов из расширения.

>Слушай, колеблющийся с линией партии... Что ты будешь делать, когда добавят то, что тебе сейчас не надо, а? :)

1с далеко не аппле, чтобы внятно доказать, что "не держите его так"

(176) Расширения не изменяют структуру БД. И чуется, что никогда не будут.

>Расширения не изменяют структуру БД

эффект от протухшего кэша помноженного на протухшее расширение будет ж.поразрывающим...

(179) Может будет, может нет. Там видно будет.

+(180) Может заодно добавят механизмы отслеживания "протухшего".

хренасе гений развел доверчивых дурачков...

Он у вас как знамя, у тех кто не уверен в себе.

Такое знамя лучше зжечь

и начать заново:-),

(183) У тебя с этим проблемы? Сходи к врачу, не плачь тут и не мешай взрослым дядям.

(186)Я сам взрослый дядь.Не мешай мне

Врочем дело ваше

я очень люблю наблюдать  со стороны за чужим идиотизмом..

все собссно:-)

1C отстой
дитё жадности

Вот так, февраль ещё не закончился, а сезонка уже косит наиболее упоротых.

а http://job.mista.ru/users.php?id=15364 пиарщик 1С, больше его слушайте

Ладно, 1С отстой :) Мне вообще без неё лучше живётся. И делаю кучу всякой фигни помимо, но совсем оторваться - никак не получается.

(192) Вот если я скажу, что ты урод.. Скажут, что ты прав..
А ничего не скажу- тоже скажут, что ты прав....



Знаешь -ТЫ ЧМО. ИВсе

(195) Вроде не пятница, а ты нажрался.

(165) пусть идут в попу со своими приблудами)

(196) Да нет,Так...Разфилосовствовался.

ладно спок ночи всем

Этого ебанько по амнистии выпустили?

(155) вот от этого и большинство проблем у тех, кто работает с УФ. Динамический список, это не ТЗ, ТЧ или что-то еще. Это список. Который считывает данные динамически и порциями. Все. Больше ничего. Нужны итоги, сложные расчеты полей, взаимодействие? Есть СКД и обработки.

(201) Ещё один :) Ну что мешает к списку итоги прикрутить? И данные получать, раз они уже выбраны.

(202) тебя слово порционно не смущает? А на семерке тебя пользователи не мучали, что бегунок под скулнм не скролится?

>тебя слово порционно не смущает?

а оно тут вообще причем?

(203) Вообще нет. Не понимаю, что мешает обратиться к отображаемым(то есть уже прочитанным) данным и получить итог по числовым полям исходя из текста запроса.

(205) Хм, ну давай подумаем. У тебя 1000 документов с реквизитом сумма. 1С получает их порциями по 50 штук по мере скролинга. Подгрузили первые 50 шт. Получили итог Сумма_1. Крутим вниз, следующие 50, у которых итог Сумма_2. Что выводим? Сумма_1+Сумма_2? А после этого мы прыгнем ползунком в конец списка. Как теперь считать? А пока мы бегали, добавили документ и надо бы пересчитать одну из прошлых порций.
Ну, и что будет давать эта информация? Какой ее смысл и что это даст пользователям?

(123) Вообще здорово. Типа робокопа - забастовка полицейских, преступники и сумасшедшие выпущены из заточения и устраивают беспредел на улицах мисты, в реале это было бы стрёмно, но тут здорово добавляет драйва и позитива.

(200) Сейчас кого только не выпускают...

(206) Мля... Почему бы не сделать то, что делается в (152), но на уровне платформы? Т.е. учитывать все установленные отборы/поиски автоматически и делать отдельный запрос для получения итоговой строки? Это совершенно небольшое количество ресурсов, плюс можно добавить флаги для числовых полей, получать итоги, или нет. Совершенно не проблема.

(209) Идеология у 1С не позволяет, видимо

(209) Тем, что это потребует постоянный пересчет. Списки-то динамические. У тебя операционная база, где каждые 5-10 секунд добавляют документ. И их уже пару лямов в системе. Ты же первый будешь кричать, что 1С тормозная.
Для этой информации есть отчеты на СКД. Зачем скрещивать ужа с ежом - непонятно.

(211) Не скрещивай. Отчёты - это отчёты, но какая-то информация может быть нужна и на форме. Не нужна - ваше право, не делайте.

Но не говорите мне, что "не получается нормально сделать" и "это хорошо и круто" - это синонимы.

А сдуру можно и хрен сломать, никто не мешает сейчас писать в динамических списках такие запросы, что всё колом встаёт.

(213) Это называется не "не получается нормально сделать", а "нельзя нормально сделать". Иначе динамичность идет просто лесом и система, обслуживающая что-то больше ларька, встанет колом.
Именно из-за потери масштабируемости 1С такого не будет делать в типовых, а потому 1С не станет этого делать в платформе. Ей бы основное докрутить нормально, а не обслуживать хотелки девианствующих гиков.

+(215) для них как раз и есть вариант из (152).

(215) Бугагашенька
http://v8.1c.ru/o7/201404list/index.htm

+(217) 1С по ходу не знает, что Drac0 думает о масштабируемости, и имеет на этот счёт своё мнение.

(217) "И чо?"(с). 1С просто дала возможность получить данные для отчета, используя настройки ДС. Не путай теплое с мягким. Кстати, вот и легкая возможность получить итоги и доп. данные из формы списка.

(219) Ну это же портит всю масштабируемость!!!!!!!1111111

(0) херась, я думал я один такой остался )
правда себе уже поставил бп 3.0. начну изучать

(220) 0_о. Это формирует схему СКД для генерации отчета по настройкам списка. Или чукча писатель?

(221) вот так вот и не заметишь как в динозавры записался...

(222) Ты со схемой СКД играться будешь, или таки исполнять её? Дурачком не прикидывайся.

(218) "Динамический список сам по себе не может предоставить вам такую информацию. Задача динамического списка - обеспечить быстрый просмотр больших объёмов данных. Поэтому он считывает данные порциями, требуемыми для отображения на одном-двух экранах. И «ничего не знает», например, об общем количестве данных, которые ему предстоит считать."

(225) Что не мешает ИСПОЛНИТЬ СХЕМУ СКД, содержащуюся в настройках списка, и получить что-то с учётом всех данных, а не только показанной области.

(224) Иди выпей кофе. Тебя заклинило. Я это буду исполнять, а может даже редактировать схему, и даже выводить пользователю. Но, блин, это будет ОТЕДЕЛЬНОЕ формироания ОТЧЕТА СКД, который тупо взял все настройки и параметры ДС. Это не будет динамическим списком.

(227) Facepalm. Всё же 1С калечит мозг, у 1С-ников все объекты полностью и принципиально неизменяемы.

(226) простите, вы пытаетесь доказать что можно сформировать запрос/схему, которая положит базу? Это типа "с дуру можно и хер сломать"?

(229) Я пытаюсь доказать, что встроить (152) в платформу - это не угроза производительности.

(230) Нет, ты таки не видишь разницу между формированием отчета СКД и динамическим списком.

(231) Потому что её нет. Динамический список лишь добавляет автоматически лимиты при выборке. Но это не мешает исполнить запрос без этих лимитов, если нужно.

+(232) Точней, принципиально не мешает. То, что этого не умеет конкретная реализация списка made by 1C - это лишь потому, что они так решили, а не из-за каких-то фундаментальных ограничений.

(233) В списке можно  снять галку "Динамичеакое считываение" и все будет читаться за 1 раз

(230) вы читали там вот это?
"Вообще, данный подход может отрицательно повлиять на производительность. Например, если программа будет подсчитывать итог без установленного отбора в динамическом списке, то количество выбираемых записей может быть огромным (например, за несколько лет). В итоге каждое обновление итогов может продолжаться десятки (!!!) секунд.  Поэтому имеет смысл подсчитывать итоги только если был установлен отбор. Данное условия поставил в тестовой конфигурации."

вообще это не имеет смысла, так как достаточно легко представить себе ситуацию когда итоги будут меняться несколько раз в секунду...

(234) Можно, но вряд ли от этого кому-то станет лучше. От (217) - станет.

(235) Блджад... Ну не имеет - и не имеет. Я что, сказал, что это "надо обязательно делать всё время в каждом списке"?

(233) Ну, сделай свою форму, где будет заполняться ТЗ при открытии, обновляться по обработчику ожидания. Замени ею формы списков, а потом собери отзывы пользователей. Если будешь жив - отпишись.

(238) Ты правда разницы не видишь, между передачей сотен тысяч строк на клиента, и передачей одной итоговой строки(+какого-то небольшого количества отображаемых строк)?

(239) А на сервере это все будет Боженька подготавливать? Думается, таки это будет СУБД. Которой, вполне возможно, придется это все пересчитывать раз в пару секунд и, как итог, вся система встанет колом. Т.е. возвращаемся к (215)

(240) У чего угодно есть ограничения, см (214). Пошли по кругу.

(233) на самом деле, на мой взгляд, бездумная возможность по изменению текста запроса в динамическом списке, или неосознанная - самое большое зло, которое появилось благодаря приоткрытию этого ящика Пандоры. В одной из конфигураций, на нашем проекте, где сильно жаловались на производительность простого динамического списка (штатная кнопка установки/снятия отбора отрабатывала больше 30 сек.), я собственными глазами наблюдал такую картинку, когда из-за одной функц.опции, вот так вот на пустом месте просто до нуля падала производительность. При этом, начав разбор сразу с плана запроса, я сразу не понял, откуда в одном куске текст запроса, появляются непонятные +100500 джойнов, которых в оригинальном тексте запроса просто нет. В итоге, путем глубокого погружения в самую клоаку, в +100500 вызове какой-то процедуры, текс запроса действительно менялся программно: в него добавлялось подсчет количества документов из РС. Измерения в этом рс - составного типа. Склейка по измерениям - вообще по строке. В итоге что получалось: фо отключаем - все летает. фо включаем - рулю конец. Налицо совершенно космическая логика при проектировке этого куска логики. И возможности динамического списка тут просто как вишенка на тортик :)

(238) как раз мечусь между ТЗ и динсписком.
с одной стороны пользователям нужны отборы сортировки по любой колонке и настройки списка
с другой - итоги по колонкам.

поставил 8.3.6 и заюзал:

ПолучитьИсполняемуюСхемуКомпоновкиДанных();
ПолучитьИсполняемыеНастройкиКомпоновкиДанных().

пользователи счастливы.

и да - что бы там не пели про быстродействие, в упр учте пользователям как правил хочется видеть итоги по журналу документов которые они смотрят прямо сейчас.

Причем челы там даже умудлярлись как-то сортировку по этим заджойненным полям доавлять. По плану запроса сразу +15% общей стоимости. Вот это все возникло просто на ровно месте :)

(242) И в чём тут повинен динамический список? Представь себе такой же отчёт на СКД. От этого там количество быдлокода уменьшится, что ли?

(241) Это в 99% процентах приведет к критической потери производительности на больших объемах данных. Поэтому осмысли аргумент из (215) и пойми 1С. Если хочешь бездумно исполнять каждую хотелку пользователей, вперед, возможности для этого есть.

и да, традицонно "ctrl+f"и  все ваши хитрорассчитанные итоги динсписка идиту в 0пу...

(246) Я охреневаю с вас. Ты эксперименты лично проводил, и цифру 99% лично вычислил? Или так - предположения исходя из собственного разумения?

(245) я не к виноватости. Я к тому, что многие граждане стали считать это панацеей. Я пихаю туда все то, что не запрещено, и все. На своих тестовых маленьких базках проверят - все гут. База до 50 гигов, продуктивная выросла - рулю конец. Кстати, отчет на СКД, просто тупо скопировав все это туда - более правильный, на мой взгляд вариант. Потому что, не нужна динамика. Запустил отчет, он сформировался за минут 10, сиди анализируй его потом. А в случае православного дин.списка, мы получаем SELECT DISTINCT TOP 45, и скролим, скролим, скролим...в итоге полная аливерда. Хотя, дс тут конечно не виноват :)

(249) Так не надо писать ни отчёты, ни вообще что бы то ни было. А то, что на динамическом списке это заметнее - ну такова уж его суть.

(248) 1% - это справочники, которые вряд ли в какой организации дорастут до сотен элементов. Но там и итоги такие тоже вряд ли понадобятся. ПО остальным - уверен на 100%. Чудес не бывает и Боженька не работает на стороне сервера.

(246) Я понимаю 1С, я не понимаю тебя, который кричит "я очень всем доволен".

(249) у большинства пользователей 1С продуктивная база до 50 гигов не вырастет никогда за период жизни организации..
так что тут еще вопрос :) стоит ли г0внокодить понимая что объемы базы позволяют определенные вольности или нужно рассчитывать что очередная ООО "Сумки" с одним магазином и объемом документооборота в 100-500 документов в месяц когданибудь вырастет до 50 гигов раньше чем закроет ООО, сделате новую базу с новым юрлицом и перенесет туда остатки? :) :) :)

(0) Всю ветку не читал.
> Сильно ли вредит спецу 1С отсутствие знания УФ?
- Да. Сильно.
УФ со всеми своими особенностями - это всего лишь частный случай клиент-серверного программирования.

> мой труп можно реанимировать двухнедельными курсами в 1с или же работой во франче

Наивное и опасное заблуждение. Потребуется значительно больше времени и усилий. Кроме того всего на курсах не расскажут. Огромное количество тонкостей и нюансов неожиданно "всплывают" уже в ходе работы.

(252) я не понимаю 1С только в одном: зачем надо было делать сворачивание/разворачивание групп на форме через серверный вызов?

(253) согласен с такой точкой зрения тоже.

(252) А где я кричал, что "я очень все доволен"? Ткни в пост.

(255) А то, что изменение видимости элементов, изменение заголовков тоже генерит серверный вызов, тебя не смущает? Меня так бесит :( Не думаю, что перерисовать форму это настолько трудоемко, чтобы не перенести это на клиента.

(258) с видимостью я частично согласен - нет особой необходимости интерактивно видимость передергивать.
а вот заведомо интерактивный элемент, да который в принципе не несет никаких событий связанных с изменением данных в базе вообще - этого я хоть убей не понимаю... ну вообще не понимаю...

(254) вот примерчик v8: очень медленно работает динамический список

(257) Блин, напишу специально эмуляцию динамического списка с итогами на чистом скуле, посмотрю, что ты будешь петь :) Лень бы перебороть :)

(261) Дадада, очень показательно будет, когда проверишь это на таблице с сотней строк и одним пользователем - тобой сидящим на серваке :)

(262) Сколько надо? 50 тыс? 100? Мильён?

(263) Сотня юзеров и таблица с лямом строк при постоянной активности.

+(264) Ладно, ладно. 3 десятка юзеров хотя бы.

(264) ну и нафига вы выдумываете нетипичные ситуации для 1с ?
не ну серьезно..

вот нафига?

много компаний сидящих в динамическом сложном списке  одновременно в сотню рыл да еще выводящие не какойнить "текущая неделя" а выборки по 10 лет?

(265) и смысл?
юзверов должно быть столько сколько сеансов на рпхосте разрешено..
иначе для твоего сеанса нового юзера стартует отдельный рпхост и быстродействие упрется в скуль..

(266) У нас больше двух сотен пользователей. По нескольку десятков с одинаковыми или пересекающимися функциями.

(267) Ну, упрется в скуль, верно. Или там Боженька данные готовит? :)

(268) а мы тестируем пропускную способность скуля или таки тормознутость 1С?

ну давайте между 1С и скулем сделаем 10 мегабит сетку по коаксиалу и будем ругать 1С за зависоны и тормозню.. не ?

(офф) "Я зубр и монстр 1С" - но не знаю КД, СКД, УФ и прочие новомодные аббревиатуры.

"Ты не зубр. Ты - мамонт. А они вымерли" - бинго!

(269) Мы говорим о системе в целом. Откидывать СУБД в этом случае, как минимум, странно.

(265) У меня нечем подобную эмуляцию устраивать :)

А на рабочей кто ж мне даст экспериментировать...

(0) кто мешает доработки в УТ делать на упр формах?

(271) а чо не файловую тогда ?

по мне так критикуя механизм платформы 1С делать пассажи типа "ну и что что тут тормозит СУБД - в главном то я прав, 1С-гомно, и разработчики пудаки" - не очень корректно

(274) то что выглядит это как отстой криворукий..

(272) Тогда ты должен понимать, что информативности такой тест не даст.

(275) Он такого и не утверждал.
(277) Приведи свои результаты.

Просто теоретические изыскания на тему "так низя" - это всего лишь теоретические изыскания.

(275) Ты меня удивляешь. Я от тебя даже не ожидал такой позиции. Т.е. 1С сгенерила запрос за секунду с планом выполнения на полчаса: 1С молодец, а СУБД - тормоз?

следите за руками...

>А пока мы бегали, добавили документ и надо бы пересчитать одну из прошлых порций. Ну, и что будет давать эта информация? Какой ее смысл и что это даст пользователям?

А пока мы выводили в таб. док. отчет, добавили документ и надо бы пересчитать одну из прошлых порций. Ну, и что будет давать эта информация? Какой ее смысл и что это даст пользователям?

ЗЫ все аргументы Drac0 высосаны из пальца...

(278) Наши результаты: все, что сложное элементарного левого или внутреннего соединения нах*й из динамических списков :)

(281) Дальше читай.

(280) ну так мы в контексте корректности тестирования производительности платформы или нет?

у тебя рпхост настроен на 10 сеансов.
сидят 10 пользователей.. загружают рпхостом твой сервак. процресурсы и тд.. - у них там одна степень тормознутости..

приходит еще 1 пользователь который подключается к другому рпхосту - вопрос - у него будет быстрее работать система чем у первых десяти? так же или медленнее?

как изменится быстродействие у первых десяти?

проц многоядерный и количество рпхостов соответствует количеству ядер.
запаса оперативки хватает..
скуль сидит отдельно на гигабите..

?

(284) В контексте производительности системы. Отдельно от СУБД это абсолютно некорректно. И таки в моем примере 1С молодей или нет?

(285) блин ну я понимаю что можно в динсписок нахерачить наглухо кривых запросов которые и в файловой монопольного вешать будут..

речь то идет о принципиальном тестировании - сколько генерить пользователей и какова будет погрешность..

ты же не сможешь реально организовать 100 физических машин, запустить там свой динсписок и одновременно на 100 машинах эмулировать то что делают пользователи.. просто потому что ты не знаешь что делают пользователи.. просто потому что ты не знаешь как часто они это будут делать  и как часто у них что то там делается вообще.

в итоге у тебя на 100 человеках будет определенная погрешность в тестировании..

а теперь ключевой вопрос: на сколько эта погрешность будет отличатся от погрешности результатов которые ты получишь тестируя по схеме "количетсво пользователей примерно равно максимальному количеству пользователей на рпхост" ?

лично я убежден что эта схема правильнее ибо:

1. мы исключаем аппаратные проблемы 1ССервера
2. мы исключаем аппаратные проблемы SQL сервера
3. по сути мы занимаемся отладкой всего того что доступно именно 1Снику через стандартный конфигуратор.. не углубляясь во всякие хитрые планы запросов, загрузки процессора и прочие пропускные способности каналов между скулем и 1Ссервером..
то есть ты целенаправленно ищеш и устраняешь узкое место в 1Совом участке..

>Для этой информации есть отчеты на СКД

для этой информации есть банальная выгрузка списка

отчет должен агрегировать или наоборот расшифровывать данные в нужной аналитике с произвольными отборами недоступными в тех же списках

с какого куа я должен формировать отчет или пыхтеть в калькуляторе чтобы узнать сумму трех выделенных полей в гриде - моя не понимай...

вопрос к знатокам:

10 рпхоств к скулю сделают 10 подключений или одно ?

(287) "с какого куа я должен формировать отчет или пыхтеть в калькуляторе чтобы узнать сумму трех выделенных полей в гриде - моя не понимай..."

Так это уже совсем другое. Что тебе мешает такое реализовать?

(288) Один рпхост - одно соединение.

(287) Ага. Полмиллиона доков. Я понимаю в 1С большинство ларьки автомтизирует, но для серьезных систем постоянное получение итогов неебической таблицы (типа итога в ДС) это нонсенс.

(287) Не нужно путать сумму выделенных пользователем документов и итог всей таблицы. Против первого никто ничего не имеет.

>Так это уже совсем другое.

почему "другое"?

>Что тебе мешает такое реализовать?

мешает костыли 1с и ипанутая объектная модель, где часть того что можно сделать в гуе нельзя сделать программно. до сих пор. со времен 7.7

я хочу чтобы это было доступно "из коробки"

(290) отсюда возвращаемся к моей теории..
у тебя допустим наглухо кривой план запроса.. ну вообще ч0кнутый..
но работает 2 рпхоста.

соответтсвенно опять же тестирование в пределе того количества пользователей которые умещаются в один рпхост позволяет более грамотно еще и нагрузку на скуль протестировать ибо всякие паралелизмы скуля тебя не колышат.. ты в одно соединение пихаешь запросы от десятка пользователей и скуль их колбасит там..

не?
чем логика хромает?



понятно что чем ближе условия к реальным боевым тем точнее тесты.. но все равно продакшн сервер и всех 500 пользователей тебе на месяц никто для тестов не выделит, по этому приходится упрощать но так чтобы погрешность при упрощении была минимальна..

пока я убежден что минимальная погрешность будет как раз при такой схеме - где у тебя количество тестовых пользователей примерно равно максимальному количетсву соединений рпхоста.. чтобы по максимому загрузить ядро сервака одним рпхостом и соответственно скуль одним потоком запросов динсписка..

(291) да не нужны мне итоги на поллимона строк, предлагаю начать с малого

(286) Заниматься оптимизацией производительности
>>не углубляясь во всякие хитрые планы запросов, загрузки процессора и прочие пропускные способности каналов между скулем и 1Ссервером.
абсолютно бессмысленнл

кстати глобально по теме:

мелкие конторы с приходящими бабушками-бухами плавно и массово переходят с 7ок на 8ки. причем сразу на крайние, и тащут за собой тех кто в ТИСе работал..

наблюдаю эту картину с декабря.

Спасибо 1Су и минфину за проверку ИНН :)

отсюда - даже если ты не работаешь на супермегапроекте - мелочь тоже уходит в такси..

(296) заниматься оптимизацией производительности надо постепенно.. шаг за шагом..

если у тебя тупо свопится сервер 1С упарываться планами запроса для скуля глупо..

(298) Конечно нужно комплексно подходить. Для начала выявить узкие места

(298) +1

(299) ну дык и среднестатистическому 1снику план работ то какой?

1. проверяем сервер 1С
2. проверяем гамногод на 1С (обращения через пять точек в циклах и прочие запросы в циклах)
3. тестируем всякие динсписки и проиче отчет на предмет завешивания сервера 1С и адекватности работы


то есть до планов запроса и прочих "тонкостей" - работы вал..
по моей практике - я когда занимаюсь оптимизацией у меня до планов запроса и копания в скуле и прочих высоких материй как правило не до ходит..
на уровне 2-3 уже пользователи счастливы.. и дальнейшие "оптимизации ради оптимизаций" не особо жаждут оплачивать..

(301)

исправлюсь

п.1 проверяем настройки сервера 1С и сервера SQL - те что админские.. с точки зрения настроек ПО и операционок с железом..

(0) возьми перепиши свои обработки/разработки на УФ.

(301) Не правильный план.
1 этап - это настрйока тж на сбор длительных операций

(303) бугага.. он откроет свою мегаразработку где на форму выводился вордовский активикс и заплакав пойдет пить горькую.. ибо в этих тупых УФ даже элементарного нельзя сделать..

список может быть сверх кривой, но юзаться раз в год

проблема с УФ не в том что она "плохая", а в том что ее функциональность урезана и местами непонятно почему, местами криво...

причем сначала 1с пытается ипать мозг в стиле "эта крута" и "не держите ее так"... а потом сама "переизобретает" показать в списке

"такси" это по сути вторая попытка перезапуска... ждем SP3

(293) "почему "другое"? "

Потому что получать данные из таблицы СУБД и из данных, которые уже пришли на клиент две большие разницы.

(295) ПриАктивизацииСтроки и ВыделенныеСтроки спасут отца российской демократии. Или 1С должна весь код за вас писать?

(304) хз.. честно  - я как понахватавшийся вершков ремесленник никогда тж не пользовался еще :)

(306) а мы тут не про те которе развгод а про те которые каждый день да толпой да постоянно

(305) Ну пусть функционал с 0 реализует :)

(307) в 8.3.7 сделали спплит окна..
недMDI - 2 окошка можно теперь открыть  :) :) :)

(298) Ну вот серьезно. Ты же сам должен понимать, что большинство проблем производительности - это именно взаимодействие 1С и СУБД. И без реального взгляда на возможности СУБД любое тестирование бессмысленно.

А то что бы говоришь - это код ревью, конечно его нужно проводить, вне зависимости ни от чего.
Но если это твой код?

(313) в 1С - нет
в 1С по крайней мере то с чем я сталкивался - это тупогомнокод и шизоидные даже с точки зрения логики 1С запросы..

(301) В итоге все три пункта связаны по факту с СУБД :)

(305) Если не знать, то да нельзя сделать.

(315) ты просто не сталкивался с реальной оптимизацией,а не с вычищением г-на

(276) не знаю что там у тебя не так выглядит... у всех все нормально.

>Ты же сам должен понимать, что большинство проблем производительности - это именно взаимодействие 1С и СУБД

проблемы 1с из-за 1с

(315) Как раз таки гомнокод и приводит к некорректному обращению к СУБД.

(320) Проблем нет только у Сибирского Ананаса. Просто потому, что самого сибирского ананаса нет :)

(0) Лучше учи что-нибудь с ЗП в твердой валюте )

(312) потом родит еще пару фишек запиндюрив 2-3 "флажка" в совместимость

сделают проведение "асинхронным"... Записать() -> НачатьЗаписывание()


тут зрители аплодируют, аплодируют кончили аплодировать

(323) например, технику выполнения лакокрасочных работ

(324) А что плохого в асинхронности?

+(326) Да и сейчас можно сделать проведение асинхронным, если напрячься.

(326) Она слишком сложная для рядового тупого 1Сника.

(328) Sad but true :(

(326) ничего.. равно как ничего плохого нет в клиентсерверной работе управляемых форм..

(326) плохого в самом подходе - ничего

но как это реализует 1с - это откровенное уебанство

(328) 5-ти минутка самокритичности?..

(332) Ну вообще то это ты жалуешься на асинхронность, мне как-то по барабану - ввели да и пожалуйста.

(333) чукча не читатель...

не отделяешь подход от реализации

(0)Уряяя! Я тоже как и Г1С не знаю УФов.

(334) Накидай в двух словах свою реализацию. Чтобы было с чем сравнить.

(331) Что, как и с итогом по выделенным строкам, самому писать код нужно?

(331) а как же ты еще предлагаешь обходить запрет веб-браузеров на модальные окна?

(338) еще раз.

проблема не в подходе, проблема в реализации

вместо того чтобы "спрятать" параметр в сигнатуру функции 1с делает новую функцию и плодит очередной признак в совместимости. зачем плодить сущности без необходимости??

(339) значит необходимость была.

(339) Приведи примеры реализации из других языков.

(339) Сергей Нуралиев достаточно грамотный человек, чтобы не пускать в продакш что-то "без необходимости"

слабоватый вброс

(341) реализацию чего?

необязательного параметра сигнатуры? это сама 1с "умеет"...

или просто как функцию перегрузить? полно в инете

(0) Странный вопрос. Если ты зубр, то сам почувствуешь момент, когда незнание какой-то технологии станет серьезно сказываться на твоей основной квалификации и кошельке. И, соответственно, освоишь технологию. ИМХО, рано или поздно сделать это придется.
Сама концепция УФ - то что надо. По сути, УФ = ДинамическийИнтерфейс(декларативный) + ТонкийКлиент. Никакие "терминалы" тонкого клиента не заменят. Кроме самоочевидных плюсов УФ открыли дорогу в веб и мобильное приложение. Другое дело, что изначально реализация подкачала и продвигается по факту итерационно. Но вот на "Такси" в последних релизах можно уже смотреть без содрогания. А в 8.3.6 вроде задекларировали лечение тормозов тяжелых форм тяжелых объектов. Развитие идет и идет в нужном направлении. Ругают технологию в основном те, кому тонкий клиент нафиг не впился (но это сегодня, а завтра элементарно может пригодиться). В этом  случае - да. Минуса начинают выпирать. Клиент-сервер ессно несколько сложнее разрабатывать (больше тонкостей надо учитывать, но что приятно - в основном это тонкости общепрограммистского характера а не чисто фичи 1С), больше ограничений при разработке интерфейса. Специфичные глюки и тормоза еще есть. Но даже в этом случае есть вкусные плюшки - динамический интерфейс, полнотекстовый поиск из коробки со сквозной интеграцией ну и по мелочи.

(345) вот скажи - кому ты сейчас все это объяснял?

(346) Частично ответ ТС. Частично реакция на критику УФ. Ну и ЧСВ потешить, куда ж без этого.

(347) с ТС разговаривать - это как разговаривать с копипастой

(348) Да ладно. Производит он в основном оригинальный контент. И при всех своих заскоках, как одинэсник он - выше средней температуры по больнице.

Когда то давно я вообще 1с-кой не занимался. Но занимался другой учетной системой, так получилось что пришлось искать новую работу. Когда меня на собеседовании спросили а знаю ли я 1с четно сказал что не знаю, но благодаря тому опыту котрый у меня есть и прочим знанием имею возможность быстро освоить, через 3 месяца состоялось мое первое успешное внедрение 8-ки.
Человек который называет себя зубром и монстром и при этом боиться остаться без работы из-за того что не знает какую то технологию по моему просто страдает завышенной самооценкой, ты не зубр ты не монстр ты обычный выпускник ПТУ который освоил газовую сварку и четко знает что для того что работать может только с ней, а вот для работы с электрической сваркой ему еще надо учиться.

+ (350) И еще всегда большое "уважение" вызывали люди которые не знают чего то но имеют об этом свое мнение.

(344) "реализацию чего? " Асинхронности

(352) выдыхай уже...

тебе про фому, ты продолжаешь долбить про ерему...

(353) Это ты как-то странно метаешься. То написать две строчки в ПриАктивацииСтроки - труд непосильный, то еще что.

На счет итогов в ДС все таки можно реализовать на уровне платформы проверку на отборы или вообще в виде кнопки - показать итог. Была бы мегарюшечка. Настроил отборы. Нажал кнопку. Если отбор установлен оно выдало итоги, если нет - пусто)

(353) Простой перегрузкой функции такого не реализовать. Вообще нет тривиальной реализации для такого синтаксического сахара. По-сути, ты предлагаешь чтобы рефакторинг кода для асинхронного вызова делался всегда автоматически и прозрачно для программиста. А это возможно только в простейших случаях, т.е. не всегда.

(355) Это можно сделать и сейчас. Только надо написать десяток другой строк.

(357) В 8.3.5 нужно написать не десяток-другой, а побольше. В 8.3.6, к счастью, стало проще.

>ты предлагаешь чтобы рефакторинг кода для асинхронного вызова делался всегда автоматически и прозрачно для программиста.

я предлагаю не городить костыли без крайней нужды

>Простой перегрузкой функции такого не реализовать.

точно знаешь? спорить не могу - т.к. не видел исходников

(357) та написать то можно. Вопрос в том, что бы это было на уровне платформы) В 7ке тоже реализовывали несколько табличных частей в документе и кнопочки сами рисовали. Только 1с прикладная программа, которая позволяет более оперативно решать прикладные задачи. Поэтому не хочется тратить время на игры с формами.

(359) Ну, вот у тебя пара функций - ВвестиЗначение и ПоказатьВводЗначения. Синхронная и асинхронная. Вот у тебя примерно такой код:

Если ВвестиЗначение(Значение) Тогда
   Сообщить("Зашибись"); // для простоты, не пинать
КонецЕсли;

Как ты это заменишь прозрачно на асинхронный вызов? Всё равно ведь должен сработать обработчик события. Пусть и прозрачно. Т.е. Сообщить("Зашибись") надо выносить в отдельную функцию. Ты предлагаешь, чтобы это делалось скрытно от программиста 1С и сохранялась логика работы исходного кода без доп-усложнений. Правильно?

>Как ты это заменишь прозрачно на асинхронный вызов? Всё равно ведь должен сработать обработчик события

если он есть в сигнатуре - сработает, нет - не сработает

есть, но нет самого обработчика - сломается. Что собственно сейчас и происходит, не смотря на "новую" функцию

(362) в текущей реализации тоже есть свои плюсы.
Например при переработки конфы на отказ от модальности при простом перегрузе процедур можно не заметить гдк нкжно менять а где нет. а так сразу видно

Я думаю, что в 1с стоял выбор как сделать, и они сделали вот так.

(362) Тьфу. Дошло. Ты просто небольшое упрощение предлагал, чтобы старая функция могла выступать и инициатором асинхронного вызова? А я вообразил невесть что :) Не, ну это вообще непринципиально. Я тут даже на стороне разработчиков 1С. Переписывать хоть так, хоть эдак. А так, несмотря на еще одну сущность, более наглядно получается.

>Например при переработки конфы на отказ от модальности при простом перегрузе процедур можно не заметить гдк нкжно менять а где нет

ради этого 1с внесло инструментарий по рефакторингу кода

>Переписывать хоть так, хоть эдак. А так, несмотря на еще одну сущность, более наглядно получается.

не согласен

1. доп. костыли в совместимости
2. .удацкий выбор имен для "новых" функций - вводят нефункциональный префикс "Начать"

(366) не всегда можно автоматом

(368) высосаные из пальца извраты предлагаю опустить

(367)
1. Эти "доп-костыли" введены для удобства, как ни странно. Чтобы этот момент можно было контролировать на уровне "рубильника". И при дальнейшей разработке физически не могли воткнуть модальное окно.
2. Это уже вкусовщина, непринципиально

>Эти "доп-костыли" введены для удобства, как ни странно. Чтобы этот момент можно было контролировать на уровне "рубильника"

т.е. чтобы понимать поведение конфигурации кроме платформы еще надо знать положения всех рубильников в совместимости

я не думаю что это "удобно"

(371) Конкретно этот рубильник как раз даст по рукам, не позволив сделать вредную вещь по незнанию. Несомненно, это удобно. А вообще, в период активного развития платформы естественно приходится изучать её состояния "до", "после" и "во время". Это не вопрос удобства. Это неизбежно.

Опять пилишь пилишь, бац - а прикрепление форм убрали, мать перемать все как обычно... может вернут к 9-ой версии.

(373) китайское проклятие - жить в эпоху перемен. 1с не хочет тупо рубить бабло, предпочитает любить мозг конфигурастам. ;-)