Разработчики 1С с глубоким знанием бухучета это наоборот архаика. Ну, есть конечно свежая кровь на предприятиях где один человек и жрец и жнец, там выбора нет. А везде где покрупнее будет обычная связка БА+СА+лид+архитектор+разрабы. Элементарно потому что изучение всего сразу требует много лет. Людей, которые совмещают все 5 компетенций на хотя бы мидл - один на многие тысячи. А там ведь ещё девопс, администрирование, да тот же uiux
С каждым днём всё быстрее начинаю распознавать статьи, написанные с ллм. Этот стиль трудно описать в существующих терминах, но от него ощутимо воняет, отбивает желание читать.
В финтехе часто делают самописки именно для бухучета, т.к вариантов вести учет много, и типовые решения не подходят примерно никогда. У нас три соседних отдела сидели на двух различных самописках плюс одном глубоко доработанном типовом решении. И большая часть регламентированной отчетности по фин. продуктам шла из них. Плюс типовые зуп и бп чисто для административных нужд и внутрянки.
Сама по себе она не хороша и не плоха, но в данном примере избыточна. Со вторым абзацем согласен полностью, это надо читать когда сам уже хотя бы мидл и можешь не просто взять идеи, но перед этим обдумать, а стоит ли
Критический медицинский софт никто в одно лицо и не пишет. Там целый консилиум придумывает тесты на код, и консилиум поменьше придумывает тесты на тесты. У рядового разраба ответственность за код больше вымышленная, чем отличная от крудошлепов
Никто не будет заниматься пересадкой с 1С на галактику, это дурдом. С сапа, да, отчасти, но это очень инертный процесс, нужны компетенции, нужны деньги на принудительно-добровольную смену сапа (внезапно, с десятых ещё большинство компаний с него не слезло), проекты сами по себе очень длинные. Да и 1С на месте не лежит, сейчас ерп это самое денежное направление внутри 1С, куча вакансий. В лучшем случае, ещё лет за 10, поделят пирог, и очень вряд ли хотя бы пополам.
Галактика, это которая 1% ерп/мес рынка и 0% всего остального? На рынке, с которого продолжают уже несколько лет по капле выдавливать сап под флагом импортзама? Ну ок, ладно
Ну очевидно что встройка не лучшая из лучших, полубюджетный проц. В таких условиях любая карточка на 4гб, кроме совсем древнего хлама, будет лучше (да и то, зачастую видеопамять под текстуры всё равно будет пользу приносить)
Разработчик, скорее всего, генерирует прибыль путем замены расходов на неавтоматизированный процесс на автоматизированный + расходы на автоматизацию. Или если он сайт компании пилит - значит приводит клиентов, участвует (пусть и немного сбоку) в цепочке продаж и генерации выручки. Не генерирует прибыль какой-нибудь сисадмин, который поддерживает систему в рабочем состоянии. Ну или уборщица склада.
Люто плюсую. Потери на трение квадратичны размерам и количеству команд, а сроки на практике вообще в куб уходят. При этом ошибкоемкость тоже растет, потому что у каждой из взаимодействующих ячеек меньше пространство возможных решений и контекста проекта, что влияет на качество самих решений.
Разработчики 1С с глубоким знанием бухучета это наоборот архаика. Ну, есть конечно свежая кровь на предприятиях где один человек и жрец и жнец, там выбора нет. А везде где покрупнее будет обычная связка БА+СА+лид+архитектор+разрабы. Элементарно потому что изучение всего сразу требует много лет. Людей, которые совмещают все 5 компетенций на хотя бы мидл - один на многие тысячи. А там ведь ещё девопс, администрирование, да тот же uiux
На порядки это в 100 раз или 1000?
"универсальной" и "документ" лучше заменить, мало ли что в 2027 примут
С каждым днём всё быстрее начинаю распознавать статьи, написанные с ллм. Этот стиль трудно описать в существующих терминах, но от него ощутимо воняет, отбивает желание читать.
7 марта на отчисление..
В финтехе часто делают самописки именно для бухучета, т.к вариантов вести учет много, и типовые решения не подходят примерно никогда. У нас три соседних отдела сидели на двух различных самописках плюс одном глубоко доработанном типовом решении. И большая часть регламентированной отчетности по фин. продуктам шла из них. Плюс типовые зуп и бп чисто для административных нужд и внутрянки.
Могут ли розетки платить налоги..
Сама по себе она не хороша и не плоха, но в данном примере избыточна. Со вторым абзацем согласен полностью, это надо читать когда сам уже хотя бы мидл и можешь не просто взять идеи, но перед этим обдумать, а стоит ли
Зачем читать содержание книги, если ИИ выдаст главную мысль?
Сэм Альтман съел на завтрак бутерброд с авокадо
Дожили. Скайрим и Ведьмак 3 - старые игры.
Критический медицинский софт никто в одно лицо и не пишет. Там целый консилиум придумывает тесты на код, и консилиум поменьше придумывает тесты на тесты. У рядового разраба ответственность за код больше вымышленная, чем отличная от крудошлепов
Финансист пускай взятку дает
Блиин, так не смешно же!
Никто не будет заниматься пересадкой с 1С на галактику, это дурдом. С сапа, да, отчасти, но это очень инертный процесс, нужны компетенции, нужны деньги на принудительно-добровольную смену сапа (внезапно, с десятых ещё большинство компаний с него не слезло), проекты сами по себе очень длинные. Да и 1С на месте не лежит, сейчас ерп это самое денежное направление внутри 1С, куча вакансий. В лучшем случае, ещё лет за 10, поделят пирог, и очень вряд ли хотя бы пополам.
Галактика, это которая 1% ерп/мес рынка и 0% всего остального? На рынке, с которого продолжают уже несколько лет по капле выдавливать сап под флагом импортзама? Ну ок, ладно
Ну очевидно что встройка не лучшая из лучших, полубюджетный проц. В таких условиях любая карточка на 4гб, кроме совсем древнего хлама, будет лучше (да и то, зачастую видеопамять под текстуры всё равно будет пользу приносить)
Сама 1С правда не в курсе
Разработчик, скорее всего, генерирует прибыль путем замены расходов на неавтоматизированный процесс на автоматизированный + расходы на автоматизацию. Или если он сайт компании пилит - значит приводит клиентов, участвует (пусть и немного сбоку) в цепочке продаж и генерации выручки. Не генерирует прибыль какой-нибудь сисадмин, который поддерживает систему в рабочем состоянии. Ну или уборщица склада.
Люто плюсую. Потери на трение квадратичны размерам и количеству команд, а сроки на практике вообще в куб уходят. При этом ошибкоемкость тоже растет, потому что у каждой из взаимодействующих ячеек меньше пространство возможных решений и контекста проекта, что влияет на качество самих решений.