Поглядите код модулей регистров в 1С в типовых, к примеру. Реализовать подобные необходимые для решения бизнес задач вещи на голых FK? Вы быстро начнете объяснять что это не нужно, невозможно, что эти идиотские бизнес-процессы и пр.
Но бизнесу это надо и подобные отмазки, что вы не можете это сделать — просто заставят вас уволить. И на 1С это легко решается.
Пример в студию.
Вы и сами привели такой пример:
Нуда, а вы видимо никогда не видели развивающийся годами продукт, где этим никуда обмазано все сверху донизу в таком объеме, что даже тронуть страшно, а нужно.
Вот именно поэтому это и плохое решение.
Вариант предлагаемый 1С гораздо удобнее в модернизации при отличной гибкости.
даже тронуть страшно
Ага. Сложность на голых FK разрастается крайне радикальными темпами.
Вы почему-то забываете про вполне коммерческий продукт NGINXPlus и возможность заказать у разработчиков поддержку.
Мое мнение — F5 просто хочет консолидировать свои аппаратные решения и свежекупленный программный балансировщик (коим и является nginx) в некое пакетное предложение, новый продукт, с которым они в конечном счете вернутся на рынок.
А это уже разумное объяснение. Довольно правдоподобное.
В отличие от ерунды, что тут пишут про цель покупки другие комментаторы.
Инвестиция в сырье для твоего продукта, чтобы потом это сырье переварить и продавать продукт созданный на его основе — это да.
Затраты на такое не выглядят большими. Все равно отобьется при будущих продажах.
Могу ли я в РФ ЗАКОННО отгрузить покупателю товар без каких-либо документов, в которых указаны цены, а он в свою очередь принять его (в том числе и по бухгалтерскому учету)? Документы на оплату с ценами при этом ему выставить через месяц.
Это вообще не проблема софта и программиста.
Это проблема юриста и бухгалтера.
Знаю многих что так делают. С 1С.
Как это соответствует закону — не знаю.
Спросите лучше на форуме бухгалтеров.
По крайней мере под такой способ отгрузки никак доработать 1С не просят — значит, устраивает штатный механизм.
По Вашим словам могу предложить Вам самим написать продукт такого же уровня. Ну, а фигли — если это всего лишь 1 год и фикс прайс.
Разделите 40 миллиардов на 100 и посчитайте скольким высококвалифицированнейшим программистам вы сможете оплачивать этот год.
Я сам не фанат nginx (по определенным причинам), вижу сильные альтернативы, которые появились буквально недавно — envoy, traefik.
Все правильно. Их не столь уж недоступно сложно сделать.
Но и не могу не отметить сильную сторону nginx — каждый школьник его знает, он уже проник во многие организации (клиентская база) и под него напилено уже очень много модулей и собрана масса экспертизы.
Безусловно.
Но какой с этого прок F5?
Она и без покупки nginx вполне себе могла это всё использовать.
А брать деньги за всемирное использование nginx (как в своем время поступил хитрый немецкий институт, что держал патент на MP3) — лицензия не позволяет.
Вы помните истории, когда покупали компании, только из-за того, что у них были патенты, коллектив или еще что-либо нематериальное?
Может быть и так.
Но какие патенты могут быть в открытом решение. Как минимум такие вещи в коде прописываются (в комментарии номер патента).
:) Почему пыль? Актив — это не только станок и стена из бетона. MS миллиарды стоит не из-за того что ее windows и office от копирования защищены, а потому что она их кодом владеет и пользователей дохрена. У гугла вон тоже все бесплатно, и что? На их продуктах полмира подсажено.
Исходный код MS для большей части мира недоступен.
И при попытке его использовать, если вы его заполучили как-то — вы столкнетесь с дорогими неприятностями юридического свойства.
Гугль отдает в общее пользование только второстепенный код, который никак не могут повлиять на его бизнес. А вот логика работы поискового ядра — коммерческая тайна.
Теперь объясните мне — что именно дает F5 владение общедоступным nginx? Лицензия которого прямо говорит, что, мол, «бери и используй на здоровье».
Ну да, а если эти говнокодеры перейдут на русский, то все у них в момент наладиться и пони порозовеют, ага.
Исчезнет ненужно для внутрироссийской разработки лишнее звено, которое превращает процесс в детскую игру «испорченный телефон» (когда выстраиваются в цепочку и на ухо по очереди передают друг другу фразу, что к концу цепочки преобразуется в нечто странное).
Следовательно, качество результата (скорость его получения) улучшится, да.
Одно дело когда вы можете однозначно спросить у представителя предметной области просто произнеся пусть непонятный вам термин, но правильный.
Другое дело, когда вы переводите его с английского с искажением смысла.
Проблем нет только в общекомпьютерной терминологии, в универсальной терминологии, в простейших понятиях.
А стоит погрузиться в предметную область — все становится очень и очень непросто.
Даже профессиональный переводчик, если он не специализируется на этой области — и тот переведет некорректно.
Что же от программистов ожидать, у которых первичный навык должен быть совсем иным — все же программирование первичный навык.
я такие делал. и они из разряда «на 1с» быстро переходят в разряд «на sql», «на python» и т.п, а в 1с только формы ввода и остаются.
Видимо, вы сталкивались с крайне простыми бизнес-процессами, где дешево сделать на универсальных инструментах и это оправдано.
Так как узкоспециализированное но низкофункциональное решение (которое, имхо, должен быть способен написать любой квалифицированных программист средней руки) — безусловно будет высокопроизводительным.
Но, если речь идет о чем то сколько-нибудь сложном, полнофункциональном, универсальном — стоимость разработки и особенно поддержки — на упомянутых вами инструментах становится непомерно высока.
Потому что механизмы убогие и начинаются не там. Нахера, извините, сценарное тестирование форм, когда нет модульных и интеграционных тестов? А их нет, потому что модульность не завезли, DI не завезли, мокать невозможно, в IDE поддержки нет.
Типичный разработчик не эти глобальные вещи меняет вовсе.
То что вы написали — эти вещи только сама 1С да те кто полноценные конфигурации разрабатывают — тем и нужно. А там есть способы.
Практически все разработчики типовых используют тестирование — ERP/УПП, БП, ЗУП. Они об этом неоднократно говорили.
Вот франчи — да, там это скорее редкость. Но опять-таки это от культуры конкретной команды зависит.
И от задач.
Если это не какой-нибудь там Рарус, что полноценные конфигурации сам пишет — так задача у франча чаще «местного значения», весьма локальная, редко когда есть необходимость что-то полноценно тестировать.
Гораздо больше необходимость фунционального тестирования с пользователями (не автоматизированного тестирования), когда не столько технические ошибки выявляются, а вносятся корректировки в бизнес-процесс по мере знакомства пользователя с результатами разработки.
В этой схеме отдельное юнит-тестирование смысла не особо и полезно.
На счет тестов соглашусь — в 1С есть механизмы для этого, только никто их не использует. Да и не принято у 1Сников тратить на тестирование времени больше чем на разработку, потому как попробуйте объяснить своему директору говнорю-бизнесмену, который нанял вас за 3 копейки, что тестирование это важно
В известных мне веб-проектах — реализованные отдельные механизмы автоматизированного тестирования тоже редкость.
В 1С тоже кто-то использует, кто-то нет.
Ну и плюс специфика — этот функционал нужен еще вчера. А через три дня он будет уже изменен. А через полгода уже выключен.
Поэтому, чаще всего, фактически происходит тестирование на живую. Так нужно ради быстрых изменений бизнес-процессов.
А вот при написании сложных больших разработок, создаваемых как единое целое — вполне себе используется в 1С тестирование.
всю жизнь мечтал осуществлять контроль целостности ручками)
Видимо, вы только начинаете карьеру и еще не сталкивались с сколько нибудь сложными бизнес-процессами, когда без этого никуда.
На уровне движка, с бд 1с обращается как с тупой хранилкой.
И это правильно.
Позволяет реализовать крайне гибкие бизнес-процессы, которые контролировать одними только средствами СУБД или невозможно или гораздо более трудоемко.
Нуда, куда веселее, когда перетянул пользователя в другую папочку и у тебя отчеты раком встали.
Проблема высосана из пальца.
Если информирование разработчиков о косяках поставлено нормально, то максимум после второй такой ситуации перетягивание будет запрещено программно или сопровождаться комментариями, к чему это приводит, чтобы пользователь сам решал.
Ну а то что Вы никогда не косячите, я уже понял.
Впрочем, в это не верю.
И, например, вот это обстоятельство достаточно сильно влияет на логику процессов приемки и отгрузки. По этой причине тот же Odoo из коробки под РФ ну никак не подходит. Если конечно, не делать двойной ввод в 1С и иметь разную себестоимость в Odoo и 1C.
Вы путаете отгрузку, где себестоимость не нужна и аналитику, где уже важна себестоимость.
Их можно считать сразу, а можно и не сразу — зависит от бизнес-требований.
Мне известны вполне себе крупные бизнесы, которые свою себестоимость видят раз в месяц в лучшем случае.
Эта вещь не всегда связанная с отгрузкой.
Но есть бизнесы (низкоприбыльные), где себестоимость важна для каждой отгрузки. Иначе можно впухнуть.
Прежде чем браться за такой проект вам следут поработать полноценным разработчиком для той же 1С (нормальным, а не обновляльщиком типовых конфигураций) хотя бы года 3 (лучше 5-7), причем в разных придприятиях с разным учетом (или у франча, что разные предприятия обслуживает), чтобы начать понимать такие вещи.
> Да каким бы крутым разработчиком он ни был — не стоит это право столько. nginx не настолько сложный софт.
Извините, но это чушь. Или зависть (да, я тоже в каком-то смысле завидую Сысоеву — он молодец). Насчет сложный — наверное, уже нет. Но в ТО время — это реально было ноу-хау.
Извините, но чушь вы написали.
Там речь о 40 миллиардах рублей.
Полноценное решение типа nginx можно реализовать и оттестировать с нуля и за в сотни раз меньшую сумму и за разумные сроки в 1-2 года.
При этом ничто вам не мешает пользоваться параллельно бесплатным nginx, пока идет разработка.
Причина, по которой F5 потратил на приобретение фирмы nginx столько миллиардов — совсем иная.
Вот эту причину и хотелось бы понять.
Насчет сложный — наверное, уже нет. Но в ТО время — это реально было ноу-хау.
Речь то вовсе не о донате в признание былых заслуг Сысоева. Зачем? Если продукт открытый? Ну хотели бы поблагодарить — обошлись бы меньшей суммой.
А о покупке чего-то. Но чего? Не открытых же исходников nginx.
В 1С есть несколько способов перехвата записи/удаления объекта — выбирай удобный.
Там можно куда как более извращенную бизнес-логику реализовать. Что полезно при этом: в момент этой проверки вы имеет доступ ко всей прикладной сути.
В терминах СУБД этот функционал называется trigger.
P.S.:
В каком-то виде FK в 1С имеются, кстати.
Не скажу на уровне СУБД или на уровне движка платформы — не проверял/или проверял давно и не помню.
Но вы далеко не во всех случаях можете удалить объект из БД, если он где-то еще используется.
Другой довод против FK — зависимость от той или иной нормализации. А нормализация влияет на производительность и на удобство. То есть опять таки малая гибкость. Чтобы сделать FK нам нужно заточиться на определенную структуру.
Что вступает в противоречие с концепциями 1С: быстрая разработка, удобство, оперативные изменения под постоянно изменяющиеся бизнес-процессы.
Когда вы делаете отдельную таблицу только, чтобы включить FK, а для иного дела таблица и не нужна — это не гуд.
FK безусловно хорошо себя показывает только в сравнительно простой бизнес-логике. Но по мере усложнения — уже не все так однозначно.
и никто не в курсе, потому что документации нету от слова совсем.
Все денег стоит.
Хорошее документирование — существенно поднимает стоимость разработки и снижает скорость. А в бизнесе крайне важно «сделать еще вчера».
Иногда выгоднее полагаться на память разработчика, если он постоянный; на комментарии в отчете; или просто лишний раз попросить разработчика слазить в код проверить.
А иногда и талмуд с документацией (там другая проблема — и как в ней найти нужное в подробнейшей документации).
Универсального на все случаи идеального варианта решения нет.
Насколько помню в мире «белых людей» прайс производителей софта ExVAT то есть в прайсе не учитываются локальные налоги. Я считаю это правильно. По какой окончательной формуле будет показана для меня цена это вопрос к торговой площадке. Если производитель желает продать мне напрямую, то заморачиваются с платежной системой. НДС, доставка до меня и прочее.
Это вынуждено.
Если вы про ЕС — банально — там НДС очень разный в разных странах. Если про США, то там налог с продаж разный в разных местах.
В РФ в этом нет необходимости — ибо всё едино.
Загадка почему в Японии налог с продаж нужно самому добавлять, там вроде нет сложных исключений.
Эти бухгалтерши по факту были операторами ввода данных.
Ничего удивительного. Бухгалтера эникеев тоже нередко называют программистами.
Но бизнесу это надо и подобные отмазки, что вы не можете это сделать — просто заставят вас уволить. И на 1С это легко решается.
Вы и сами привели такой пример:
Вот именно поэтому это и плохое решение.
Вариант предлагаемый 1С гораздо удобнее в модернизации при отличной гибкости.
Ага. Сложность на голых FK разрастается крайне радикальными темпами.
А это уже разумное объяснение. Довольно правдоподобное.
В отличие от ерунды, что тут пишут про цель покупки другие комментаторы.
Инвестиция в сырье для твоего продукта, чтобы потом это сырье переварить и продавать продукт созданный на его основе — это да.
Затраты на такое не выглядят большими. Все равно отобьется при будущих продажах.
Это вообще не проблема софта и программиста.
Это проблема юриста и бухгалтера.
Знаю многих что так делают. С 1С.
Как это соответствует закону — не знаю.
Спросите лучше на форуме бухгалтеров.
По крайней мере под такой способ отгрузки никак доработать 1С не просят — значит, устраивает штатный механизм.
Разделите 40 миллиардов на 100 и посчитайте скольким высококвалифицированнейшим программистам вы сможете оплачивать этот год.
Все правильно. Их не столь уж недоступно сложно сделать.
Безусловно.
Но какой с этого прок F5?
Она и без покупки nginx вполне себе могла это всё использовать.
А брать деньги за всемирное использование nginx (как в своем время поступил хитрый немецкий институт, что держал патент на MP3) — лицензия не позволяет.
Может быть и так.
Но какие патенты могут быть в открытом решение. Как минимум такие вещи в коде прописываются (в комментарии номер патента).
Исходный код MS для большей части мира недоступен.
И при попытке его использовать, если вы его заполучили как-то — вы столкнетесь с дорогими неприятностями юридического свойства.
Гугль отдает в общее пользование только второстепенный код, который никак не могут повлиять на его бизнес. А вот логика работы поискового ядра — коммерческая тайна.
Теперь объясните мне — что именно дает F5 владение общедоступным nginx? Лицензия которого прямо говорит, что, мол, «бери и используй на здоровье».
Исчезнет ненужно для внутрироссийской разработки лишнее звено, которое превращает процесс в детскую игру «испорченный телефон» (когда выстраиваются в цепочку и на ухо по очереди передают друг другу фразу, что к концу цепочки преобразуется в нечто странное).
Следовательно, качество результата (скорость его получения) улучшится, да.
Одно дело когда вы можете однозначно спросить у представителя предметной области просто произнеся пусть непонятный вам термин, но правильный.
Другое дело, когда вы переводите его с английского с искажением смысла.
Проблем нет только в общекомпьютерной терминологии, в универсальной терминологии, в простейших понятиях.
А стоит погрузиться в предметную область — все становится очень и очень непросто.
Даже профессиональный переводчик, если он не специализируется на этой области — и тот переведет некорректно.
Что же от программистов ожидать, у которых первичный навык должен быть совсем иным — все же программирование первичный навык.
Видимо, вы сталкивались с крайне простыми бизнес-процессами, где дешево сделать на универсальных инструментах и это оправдано.
Так как узкоспециализированное но низкофункциональное решение (которое, имхо, должен быть способен написать любой квалифицированных программист средней руки) — безусловно будет высокопроизводительным.
Но, если речь идет о чем то сколько-нибудь сложном, полнофункциональном, универсальном — стоимость разработки и особенно поддержки — на упомянутых вами инструментах становится непомерно высока.
Типичный разработчик не эти глобальные вещи меняет вовсе.
То что вы написали — эти вещи только сама 1С да те кто полноценные конфигурации разрабатывают — тем и нужно. А там есть способы.
И от задач.
Если это не какой-нибудь там Рарус, что полноценные конфигурации сам пишет — так задача у франча чаще «местного значения», весьма локальная, редко когда есть необходимость что-то полноценно тестировать.
Гораздо больше необходимость фунционального тестирования с пользователями (не автоматизированного тестирования), когда не столько технические ошибки выявляются, а вносятся корректировки в бизнес-процесс по мере знакомства пользователя с результатами разработки.
В этой схеме отдельное юнит-тестирование смысла не особо и полезно.
В известных мне веб-проектах — реализованные отдельные механизмы автоматизированного тестирования тоже редкость.
В 1С тоже кто-то использует, кто-то нет.
Ну и плюс специфика — этот функционал нужен еще вчера. А через три дня он будет уже изменен. А через полгода уже выключен.
Поэтому, чаще всего, фактически происходит тестирование на живую. Так нужно ради быстрых изменений бизнес-процессов.
А вот при написании сложных больших разработок, создаваемых как единое целое — вполне себе используется в 1С тестирование.
Я не мог вспомнить. Наверное это они.
Там много чего из Европы — есть ПО общее с европейским офисом.
Но то ПО, что работает на нашей территории — там много уже нашего, ага.
В смысле, пустить пыль в глаза инвесторам?
Видимо, вы только начинаете карьеру и еще не сталкивались с сколько нибудь сложными бизнес-процессами, когда без этого никуда.
И это правильно.
Позволяет реализовать крайне гибкие бизнес-процессы, которые контролировать одними только средствами СУБД или невозможно или гораздо более трудоемко.
Проблема высосана из пальца.
Если информирование разработчиков о косяках поставлено нормально, то максимум после второй такой ситуации перетягивание будет запрещено программно или сопровождаться комментариями, к чему это приводит, чтобы пользователь сам решал.
Ну а то что Вы никогда не косячите, я уже понял.
Впрочем, в это не верю.
Вы путаете отгрузку, где себестоимость не нужна и аналитику, где уже важна себестоимость.
Их можно считать сразу, а можно и не сразу — зависит от бизнес-требований.
Мне известны вполне себе крупные бизнесы, которые свою себестоимость видят раз в месяц в лучшем случае.
Эта вещь не всегда связанная с отгрузкой.
Но есть бизнесы (низкоприбыльные), где себестоимость важна для каждой отгрузки. Иначе можно впухнуть.
Прежде чем браться за такой проект вам следут поработать полноценным разработчиком для той же 1С (нормальным, а не обновляльщиком типовых конфигураций) хотя бы года 3 (лучше 5-7), причем в разных придприятиях с разным учетом (или у франча, что разные предприятия обслуживает), чтобы начать понимать такие вещи.
Которые специалисту очевидны.
Извините, но чушь вы написали.
Там речь о 40 миллиардах рублей.
Полноценное решение типа nginx можно реализовать и оттестировать с нуля и за в сотни раз меньшую сумму и за разумные сроки в 1-2 года.
При этом ничто вам не мешает пользоваться параллельно бесплатным nginx, пока идет разработка.
Причина, по которой F5 потратил на приобретение фирмы nginx столько миллиардов — совсем иная.
Вот эту причину и хотелось бы понять.
Речь то вовсе не о донате в признание былых заслуг Сысоева. Зачем? Если продукт открытый? Ну хотели бы поблагодарить — обошлись бы меньшей суммой.
А о покупке чего-то. Но чего? Не открытых же исходников nginx.
Да запросто.
С голыми FK не столь гибко получается.
В 1С есть несколько способов перехвата записи/удаления объекта — выбирай удобный.
Там можно куда как более извращенную бизнес-логику реализовать. Что полезно при этом: в момент этой проверки вы имеет доступ ко всей прикладной сути.
В терминах СУБД этот функционал называется trigger.
P.S.:
В каком-то виде FK в 1С имеются, кстати.
Не скажу на уровне СУБД или на уровне движка платформы — не проверял/или проверял давно и не помню.
Но вы далеко не во всех случаях можете удалить объект из БД, если он где-то еще используется.
Другой довод против FK — зависимость от той или иной нормализации. А нормализация влияет на производительность и на удобство. То есть опять таки малая гибкость. Чтобы сделать FK нам нужно заточиться на определенную структуру.
Что вступает в противоречие с концепциями 1С: быстрая разработка, удобство, оперативные изменения под постоянно изменяющиеся бизнес-процессы.
Когда вы делаете отдельную таблицу только, чтобы включить FK, а для иного дела таблица и не нужна — это не гуд.
FK безусловно хорошо себя показывает только в сравнительно простой бизнес-логике. Но по мере усложнения — уже не все так однозначно.
Все денег стоит.
Хорошее документирование — существенно поднимает стоимость разработки и снижает скорость. А в бизнесе крайне важно «сделать еще вчера».
Иногда выгоднее полагаться на память разработчика, если он постоянный; на комментарии в отчете; или просто лишний раз попросить разработчика слазить в код проверить.
А иногда и талмуд с документацией (там другая проблема — и как в ней найти нужное в подробнейшей документации).
Универсального на все случаи идеального варианта решения нет.
Это вынуждено.
Если вы про ЕС — банально — там НДС очень разный в разных странах. Если про США, то там налог с продаж разный в разных местах.
В РФ в этом нет необходимости — ибо всё едино.
Загадка почему в Японии налог с продаж нужно самому добавлять, там вроде нет сложных исключений.