Это круто технически, но у меня есть сомнения в финансовой стороне. Вы потратили невероятную кучу ресурсов, чтобы спуститься до уровня асма в библиотеках окружения. Получили ускорение в 2 раза для относительно редко-выполняемой части (расчет себестоимости). Какой срок окупаемости у этого? Точно это надо было делать?
Штамп: s - stamp Занимает в памяти 10 байтов и содержит дату, время и номер пользователя, создавший этот штамп.
А где этот "номер пользователя"? Его нет ни в описании, ни в примерах. Да и вообще существование номера пользователя в типе данных о времени нехарактерно. Вот если бы это была попытка изобрести разновидность уникального идентификатора, то тогда смесь времени и номера пользователя была бы объяснимой - получился бы в целом нормальный идентификатор, но без поддержки распределенных систем.
Версия "Я на суде выйду и скажу - они не соблюдали нормы рабочего пространства, поэтому я прогулял рабочий день - и судья мне тут же заапплодирует стоя" выглядит несколько инфантильной.
Нет, зачем же. Отсутствие рабочего места с соблюдением норм = простой по вине работодателя. Оплачиваемый. Уведомляем об этом официально и идем в больницу. Собственно, когда работодатель указывает, что берет сотрудника по ТК работать в офисе - эти нормы тоже входят в суть ТК. Почему то нарушение условий труда прям с порога при работе с сотрудником считается нормой. А затем нарушения этих же условий в части графика работы и оплаты (переработки). Можно заглянуть еще в страны, где построже с учетом времени работы и законностью - там и руководство самостоятельно против переработок при отсутствии каких-то супернеординарных причин. Это банально дорого вне обычного рабочего ритма.
Все равно выходит странно. У вас правая часть как будто бы и является самым точным определением типа. А то, что это тип является и объектом заодно обычно в языках следует из иерархии наследования. Если вы правую часть используете только как подсказку IDE, то реальная типизация выполнена по первой букве - и тогда в эту переменную можно положить любой объект. Если мы рассуждаем об ООП языках, то в них оперируем сразу кучей разных классов. Зачем нужна столь слабая типизация? Обычно типизация же защищает от ошибок, а тут, похоже, я могу таки положить в oTrv совсем не характерный для нее объект.
так это ж совсем другая часть огромного полотна текста. А в описании between ничего не намекает, что с частью типов данных она откажется работать, хотя визуально в нее они влезают (т.к. входят в variant). Я все же ожидаю этого в описании функции.
А это как? я так понял, что variant - это "любой тип данных". К любым у вас относятся и объекты. Как вы операторы больше/меньше/равно для них реализуете, чтобы можно было "между" вычислить? У вас там перегружаемые операторы сравнения?
Почему выбрали одновременно строгую типизацию для свойств объектов и одновременно отсутствие типизации в переменных? Часто языки притягиваются к чему-то одному: уж либо все типизируем, либо нет. А такая частичная типизация, имхо, соберет недостатки от обоих подходов: и многословность от строгой типизации, и ошибки во время выполнения от отсутствия.
О, в эту игру можно играть вдвоем! Со стороны работодателя этих нарушений ничуть не меньше: напомню о нормах рабочего пространства, противопожарке, обязательных перерывах в работе, невозможности односторонних ухудшений должностных обязанностей. Это скорее вам попался сотрудник без юриста рядом. В этом большая беда юридической отрасли, что по сути права есть, но их одновременно и нет, т.к. они не защищены, потому что в ней огромный имущественный ценз (стартовые затраты на юриста в несколько зарплат работника).
...и если руководитель хочет на этом мстить, то с этого места работы стоит уходить. Потому что эти 20 минут ниоткуда не вычитаются, вы их и отработаете. Эти 20 минут не просто прихоть - чаще всего это невозможность обходных вариантов решения, вы уже все попробовали, но в больницу только в это время можно прийти. И, как правило, о них известно сильно заранее и даже часто день можно выбрать другой. Это даже близко не равновесные ситуации.
Тут я наблюдаю забавную закономерность: чем старше человек, тем дольше, по его мнению, инфляцию занижают. Я, кстати, понимаю, почему так происходит, надеюсь, и вы догадаетесь тоже. Те, кто помоложе, жалуются на ковидный кризис.
Так расскажите свое понимание, к чему эти полунамеки? Я сомневаюсь, что под ними есть какие-то аргументы. Я вот думаю, что тем старше этот человек, тем раньше он это понял. Поэтому и период больше. А методика "понимания" сходна с Задачей о разборчивой невесты (https://ru.wikipedia.org/wiki/Задача_о_разборчивой_невесте) и поэтому пропускает первую треть данных. У тех, кто помоложе, это пропускание не позволяет выбирать события раньше ковида: т.е. по сути выбора у них лишь 2 - либо ковид, либо война.
Мысль первая из статьи: остальные статьи ошибаются, сравнивая несравнимое - обертку в США и реальную жизнь в России.
Мысль вторая: давайте сравним жизнь в Москве и захолустье в США (Портланд)!
Что тут может быть не так? :) Да, наверно, почти все! Уж давайте столицу со столицей сравнивать. Я в вики нашел данные численности населения за 2010 год: так вот диспропорция между этими городами в 22 (!!!) раза.
В смысле ? Так в типовой ? И некоторые 1Совцы еще смеются, что бесплатный и открытый MyCompany - это примитив. Даже там можно писать сколько угодно комментариев к задачам (и ко многом другому).
Да. И это довольно легко следует из истории развития. 1с ведь вышла на рынок с автоматизацией малого бизнеса (и это в целом об учете товаров). А потом со временем росла до среднего и крупного. Поэтому многие решения в типовых - они больше для условного ларька (это, конечно, утрировано - ну ок, для фирмы в 5-10 человек). Сейчас 1с заходит к этому как бы снизу и добавляет в платформу систему взаимодействий, где можно хранить много комментов, чаты, звонки и вот это все, характерное больше для веба, чем для системы учета.
Вы, я так понимаю, идете обратным путем. У вас модель продажи решений - для продуктов стоимостью 1 млн+. У вас флагман ERP, а из нее откушена какая-то малая часть и выделена в MyCompany. Поэтому и решения ближе к среднему/крупному бизнесу (наверно. инфы прям немного). У вас будут обратные проблемы, что пользователь из ларька будет смотреть на это и задаваться вопросом "а зачем мне много комментариев? кто и когда их писать то будет?".
Именно поэтому Справочники/Документы/Строки/Регистры - это все дырявые абстракции.
в какой-то мере. Это крупные блоки, ими быстро собирается прототип. При соблюдении методологии это избавляет новичков от большого числа ошибок. Но если поведение блока сильно не подходит, то да - неудобно. Это не смертельно, как я и описал выше - многое можно собрать из композиции сущностей и я бы не сказал, что это приходится делать часто. У вас более низкоуровневый подход. Тут сущность изначально аморфна и может стать чем угодно. Это шире возможности, куча мест для совершения ошибок, а также каждую сущность надо пристально рассматривать, потому что общего поведения в них не заложено.
Возьмем, например, Задачи по Лидам. В терминологии 1С - это что ? Строки документа ? А если у Задач есть комментарии, то что тогда ? Строки строк документов ?
Скорее всего задача будет документом. Самым частым поведением тут является 1 комментарий на документ, поэтому 1с сделала в типовых конфигурациях именно так. Но это не догма, я в своей практике выносил комментарии в отдельную сущность (мне было достаточно регистра сведений, но вполне можно выбрать и другие) и да, там можно их создать много к 1 документу (и заодно этим переносом я добивался адресации комментариев и авторства, когда можно сказать что вот этот комментарий написан для производства, этот для отдела продаж, а этот для логистики).
А если Лид - Справочник, а ему нужна логика "проведения", то что тогда ? Справочник переделывать в Документ ? А в платформе 1С есть такой рефакторинг ?
То тогда используют композицию сущностей. Будет часть в справочнике, часть в документе. И даже бывает со связью один-к-одному, но редко. Все же обычно это один-ко-многим (т.е. у "статичного" лида произошло много событий).
Необходимость же "Справочник переделывать в Документ" редкая, чтобы прям сильно это автоматизировать. Какими-то кусками это переносится: это будет существенно быстрее, чем создание документа с нуля, но это, несомненно, далеко от возможностей IDE аля "переделай мне этот кусок вот так".
И в целом правильно выбирают. 1с - это документоориентированная система. А вы говорите о другом лагере: процесноориентированных систем. Они различаются в подходах и при попытке запихать одно в другое выходит не очень (причем в любую сторону).
Там даже хрен поймешь, что такое Лид в терминологии 1С. Ведь это и не Документ, и не Справочник.
Думаю, больше всего Лид - это справочник (документы предназначены для событий - "что-то случилось во времени и все изменилось"). Но сущность сложная и, конечно, в ее форме будет отображено и много других связанных. И я не вижу каких-то особенных отличий в других системах: вот прямо сейчас копаюсь в лиде в битрикс24 и бОльшую часть его формы тоже составляют связанные сущности, а вовсе не он сам.
И если по направлению CRM-системы компания 1С на сегодняшний день сумела стать почти монополистом
Вот откуда у вас такие заявления? Можно узнать источник этих данных? Потому что весь мой опыт работы говорит ровно об обратном: в качестве CRM выбирают что угодно, а 1с - это скорее про учет товаров, финансов и налогов.
И это не просто 2-3 цифры, а объемная работа, которая потребует от коллег определенных временных затрат. Другими словами, мой запрос для них — это дополнительный «напряг». ... не объяснила, кто я, почему с этим запросом пришла именно к этим сотрудникам, почему это так важно и вообще, какой смысл мне помогать
Перестаньте, пожалуйста, решать косяки вашего руководителя через сложнейшие навыки. В целом в фирме все должно быть так: вам дают задачу и к ней дают необходимые ресурсы - и делает это тот, у кого эти ресурсы имеются, вплоть до гендиректора. Ресурсом в том числе является и время всех сотрудников смежных отделов. Если вам дали задачу и наврали о ресурсах (не выдали, или таких ресурсов вообще никогда не было или еще что-то) - это не ваша проблема.
CASE
WHEN statusHttp() > 299 THEN
MESSAGE 'Ошибка - ' + STRING(statusHttp());
WHEN NOT statusHttp() THEN
MESSAGE 'Ошибка - нет связи с хостом АТОЛ v.10';
ELSE
MESSAGE 'Ошибка - потеряна связь с хостом АТОЛ v.10';
Пробежался по коду интеграции с фр АТОЛ. Блок обработки статусов ошибок является копипастой, повторенной 7 раз. Это антипаттерн почти во всех языках. А у вас?
да, но это экономия времени оборудования, а не сотрудников. Это время обычно массово никому не нужно по ночам. Поэтому у меня и такие сомнения.
И ускорение совсем не бесплатное. Огласите, пожалуйста, размер затрат (хотя бы в часах работы, если нельзя суммы называть).
Это круто технически, но у меня есть сомнения в финансовой стороне. Вы потратили невероятную кучу ресурсов, чтобы спуститься до уровня асма в библиотеках окружения. Получили ускорение в 2 раза для относительно редко-выполняемой части (расчет себестоимости). Какой срок окупаемости у этого? Точно это надо было делать?
А где этот "номер пользователя"? Его нет ни в описании, ни в примерах. Да и вообще существование номера пользователя в типе данных о времени нехарактерно. Вот если бы это была попытка изобрести разновидность уникального идентификатора, то тогда смесь времени и номера пользователя была бы объяснимой - получился бы в целом нормальный идентификатор, но без поддержки распределенных систем.
Нет, зачем же. Отсутствие рабочего места с соблюдением норм = простой по вине работодателя. Оплачиваемый. Уведомляем об этом официально и идем в больницу. Собственно, когда работодатель указывает, что берет сотрудника по ТК работать в офисе - эти нормы тоже входят в суть ТК. Почему то нарушение условий труда прям с порога при работе с сотрудником считается нормой. А затем нарушения этих же условий в части графика работы и оплаты (переработки).
Можно заглянуть еще в страны, где построже с учетом времени работы и законностью - там и руководство самостоятельно против переработок при отсутствии каких-то супернеординарных причин. Это банально дорого вне обычного рабочего ритма.
Все равно выходит странно.
У вас правая часть как будто бы и является самым точным определением типа. А то, что это тип является и объектом заодно обычно в языках следует из иерархии наследования. Если вы правую часть используете только как подсказку IDE, то реальная типизация выполнена по первой букве - и тогда в эту переменную можно положить любой объект. Если мы рассуждаем об ООП языках, то в них оперируем сразу кучей разных классов. Зачем нужна столь слабая типизация? Обычно типизация же защищает от ошибок, а тут, похоже, я могу таки положить в oTrv совсем не характерный для нее объект.
так это ж совсем другая часть огромного полотна текста. А в описании between ничего не намекает, что с частью типов данных она откажется работать, хотя визуально в нее они влезают (т.к. входят в variant). Я все же ожидаю этого в описании функции.
А, я понял. Т.е.
oTrv as treeview
тут одновременно и "o" первой буквой участвует в типизации, и "as treeview"? Тогда получается типизация разорвана на 2 разных участка?
А это как? я так понял, что variant - это "любой тип данных". К любым у вас относятся и объекты. Как вы операторы больше/меньше/равно для них реализуете, чтобы можно было "между" вычислить? У вас там перегружаемые операторы сравнения?
Почему выбрали одновременно строгую типизацию для свойств объектов и одновременно отсутствие типизации в переменных?
Часто языки притягиваются к чему-то одному: уж либо все типизируем, либо нет. А такая частичная типизация, имхо, соберет недостатки от обоих подходов: и многословность от строгой типизации, и ошибки во время выполнения от отсутствия.
О, в эту игру можно играть вдвоем! Со стороны работодателя этих нарушений ничуть не меньше: напомню о нормах рабочего пространства, противопожарке, обязательных перерывах в работе, невозможности односторонних ухудшений должностных обязанностей. Это скорее вам попался сотрудник без юриста рядом. В этом большая беда юридической отрасли, что по сути права есть, но их одновременно и нет, т.к. они не защищены, потому что в ней огромный имущественный ценз (стартовые затраты на юриста в несколько зарплат работника).
...и если руководитель хочет на этом мстить, то с этого места работы стоит уходить. Потому что эти 20 минут ниоткуда не вычитаются, вы их и отработаете. Эти 20 минут не просто прихоть - чаще всего это невозможность обходных вариантов решения, вы уже все попробовали, но в больницу только в это время можно прийти. И, как правило, о них известно сильно заранее и даже часто день можно выбрать другой. Это даже близко не равновесные ситуации.
Так расскажите свое понимание, к чему эти полунамеки? Я сомневаюсь, что под ними есть какие-то аргументы.
Я вот думаю, что тем старше этот человек, тем раньше он это понял. Поэтому и период больше. А методика "понимания" сходна с Задачей о разборчивой невесты (https://ru.wikipedia.org/wiki/Задача_о_разборчивой_невесте) и поэтому пропускает первую треть данных. У тех, кто помоложе, это пропускание не позволяет выбирать события раньше ковида: т.е. по сути выбора у них лишь 2 - либо ковид, либо война.
Мысль первая из статьи:
остальные статьи ошибаются, сравнивая несравнимое - обертку в США и реальную жизнь в России.
Мысль вторая: давайте сравним жизнь в Москве и захолустье в США (Портланд)!
Что тут может быть не так? :)
Да, наверно, почти все! Уж давайте столицу со столицей сравнивать. Я в вики нашел данные численности населения за 2010 год: так вот диспропорция между этими городами в 22 (!!!) раза.
Да. И это довольно легко следует из истории развития. 1с ведь вышла на рынок с автоматизацией малого бизнеса (и это в целом об учете товаров). А потом со временем росла до среднего и крупного. Поэтому многие решения в типовых - они больше для условного ларька (это, конечно, утрировано - ну ок, для фирмы в 5-10 человек). Сейчас 1с заходит к этому как бы снизу и добавляет в платформу систему взаимодействий, где можно хранить много комментов, чаты, звонки и вот это все, характерное больше для веба, чем для системы учета.
Вы, я так понимаю, идете обратным путем. У вас модель продажи решений - для продуктов стоимостью 1 млн+. У вас флагман ERP, а из нее откушена какая-то малая часть и выделена в MyCompany. Поэтому и решения ближе к среднему/крупному бизнесу (наверно. инфы прям немного). У вас будут обратные проблемы, что пользователь из ларька будет смотреть на это и задаваться вопросом "а зачем мне много комментариев? кто и когда их писать то будет?".
в какой-то мере. Это крупные блоки, ими быстро собирается прототип. При соблюдении методологии это избавляет новичков от большого числа ошибок. Но если поведение блока сильно не подходит, то да - неудобно. Это не смертельно, как я и описал выше - многое можно собрать из композиции сущностей и я бы не сказал, что это приходится делать часто.
У вас более низкоуровневый подход. Тут сущность изначально аморфна и может стать чем угодно. Это шире возможности, куча мест для совершения ошибок, а также каждую сущность надо пристально рассматривать, потому что общего поведения в них не заложено.
Скорее всего задача будет документом. Самым частым поведением тут является 1 комментарий на документ, поэтому 1с сделала в типовых конфигурациях именно так. Но это не догма, я в своей практике выносил комментарии в отдельную сущность (мне было достаточно регистра сведений, но вполне можно выбрать и другие) и да, там можно их создать много к 1 документу (и заодно этим переносом я добивался адресации комментариев и авторства, когда можно сказать что вот этот комментарий написан для производства, этот для отдела продаж, а этот для логистики).
То тогда используют композицию сущностей. Будет часть в справочнике, часть в документе. И даже бывает со связью один-к-одному, но редко. Все же обычно это один-ко-многим (т.е. у "статичного" лида произошло много событий).
Необходимость же "Справочник переделывать в Документ" редкая, чтобы прям сильно это автоматизировать. Какими-то кусками это переносится: это будет существенно быстрее, чем создание документа с нуля, но это, несомненно, далеко от возможностей IDE аля "переделай мне этот кусок вот так".
И в целом правильно выбирают. 1с - это документоориентированная система. А вы говорите о другом лагере: процесноориентированных систем. Они различаются в подходах и при попытке запихать одно в другое выходит не очень (причем в любую сторону).
Думаю, больше всего Лид - это справочник (документы предназначены для событий - "что-то случилось во времени и все изменилось"). Но сущность сложная и, конечно, в ее форме будет отображено и много других связанных. И я не вижу каких-то особенных отличий в других системах: вот прямо сейчас копаюсь в лиде в битрикс24 и бОльшую часть его формы тоже составляют связанные сущности, а вовсе не он сам.
Вот откуда у вас такие заявления? Можно узнать источник этих данных? Потому что весь мой опыт работы говорит ровно об обратном: в качестве CRM выбирают что угодно, а 1с - это скорее про учет товаров, финансов и налогов.
Перестаньте, пожалуйста, решать косяки вашего руководителя через сложнейшие навыки. В целом в фирме все должно быть так: вам дают задачу и к ней дают необходимые ресурсы - и делает это тот, у кого эти ресурсы имеются, вплоть до гендиректора. Ресурсом в том числе является и время всех сотрудников смежных отделов. Если вам дали задачу и наврали о ресурсах (не выдали, или таких ресурсов вообще никогда не было или еще что-то) - это не ваша проблема.
Не, прямо символ-в-символ повторяется блок 7 раз
Пробежался по коду интеграции с фр АТОЛ. Блок обработки статусов ошибок является копипастой, повторенной 7 раз. Это антипаттерн почти во всех языках. А у вас?