учёт поставить на автоматику не через 1С, а в смартфоне
Улыбнуло. Знаете, там давно все автоматизировано. Но вот беда…каждый раз приходит государство и наваливает еще требований и новых учетов. Как бы в районе 2005х бухучет фирмы реально было вести старым дедовским способом “в амбарной книге”. Минимальная автоматизация и это доступно каждому! А сейчас требования возросли настолько, что это смерти подобно - уже даже речи не идет о том, чтобы осилить это без программ.
Напомню, что УСН как режим при появлении заявлялся как пара платежей и все готово - настолько простым, что даже учет не нужен. Сейчас же он стал столь тяжелым, что пришел новый “АУСН” ему на смену с тем же намерением.
Я пробовал дуолингво на детях с нулевого уровня. Полгода и ничего (все также не могут читать и понимать А1), зато там куча пройденных таблеток. Те же полгода, потраченные на частотный словарь по 15-20 мин в день - дали куда более весомый результат, прям вот в разы.
Детальной статистики, я, конечно, не вел. Это все эмпирические ощущения.
Версионирование объясняет и внезапные вопросы к tempdb.
У меня нет статистики, но, думаю, что нет.
Основным источником нагрузки являются временные таблицы.
Они используются потому, что в язык SQL не завезли вообще никакой вариант отладки - ну т.е. не существует никакого варианта прогнать сложный запрос по шагам и где-то там найти баг. Отсюда каждый шаг сохраняют во временную таблицу. Это неправильное состояние информационной системы (будто бы всегда включен режим отладки и расширенных логов), но другого просто нет.
От сложности запросов тоже никуда не уйти. По шкале OLTP-OLAP - 1с исторически система сильно сдвинутая в OLAP, т.е. в аналитическую часть. Для них характерны большие sql запросы с агрегациями. Если вот 1с принудительно разделить на OLTP (ввод доков) и OLAP (отчеты и аналитически-сложные вещи вроде партионного учета) - то в OLTP базе не будет сильного использования tempdb.
Это вообще один из хороших и простых советов по улучшению работы с базой - максимально разнести нагрузку OLAP и OLTP. Потому что эти 2 вида систем не могут прийти к компромиссу: то, что хорошо для одной (больше индексов! больше денормализации и витрин данных!) - очень сильно убивает производительность второй. И так с любым тюнингом (в том числе и СУБД) - улучшим в одну сторону, во второй много потеряем. Отсюда вынос всех “пользователей-аналитиков” в отдельную базу с обновлением раз в сутки - очень действенное решение. Оно может прям в разы улучшить ситуацию с тормозами.
Вендор может и ушел, а преступлением это быть не перестало. Там даже без возмещения чего-то правообладателю, насколько помню: особо крупный размер (>1млн) => уголовка до 6 лет участникам, штраф и возможно конфискация оборудования фирме - этим силовики могут начать заниматься в любой момент.
Я отношу оценку алгоритмической сложности, проблемы N+1 к компетенциям разработчика. Поэтому
в которой значения из справочника/регистра вычитываются по одному и сравниваются в цикле, или вообще сортируются “пузырьковым методом” на самом 1С
такое на совести разработчика. Но вот тюнинг СУБД под конкретные нагрузки и конкретные особенности железа - это отдельное искусство у DBA - вот именно его не будет.
Очень часто быстродействие возрастает когда оптимизируют код запросов в базу на стороне 1С, убедился в этом не один раз особенно когда конфигурация не типовая.
Да не часто, а всегда. Типовая или не типовая вообще без разницы. Другое дело, что это очень дорогостоящий путь, где нужно под лупой рассматривать каждый тяжелый запрос вместе с бизнес-требованиями к нему и характером использования.
У администратора компетенция в операционных системах и сети, у разработчика в конфигурациях и проводках. Уровень СУБД остаётся между ними
не между ними, а кмк вообще ничей. Роль DBA столь специфичная, что ни один, ни другой ей не будет обладать. Просто по экономическим соображениям: в найме этот человек будет выглядеть дороже и бизнес не захочет переплачивать без болезненных проблем прямо сейчас.
Отсюда подход “а давайте заранее подумаем” крайне редкий.
но и цитату из этого фрагмента, а кодом проверять, что цитата в нём буквально есть
У меня есть опыт применения этого. Sonnet-4.6 high reasoning. Между 5 и 10% на элементов на выходе нельзя найти в тексте (и это при том, что я использую нечеткий поиск с довольно низким коэффициентом срабатывания).
Так что без цикла “вот эти 5 пунктов не прошли проверку, доработай” эта штука неработоспособна - она почти всегда будет заворачивать документ на этапе приемки-проверки.
Дело за малым, осталось написать это на всех языках мира и во всех возможных оборотах. Ах, да, еще надо учесть, что новый язык может быть описан в другой части промпта /s
разбор аргументов, доп проверки их совместимости, рабочие папки и мьютекс на нее, прямые вопросы модели, что-то про оркестрацию задач, OCR, разборы книги (на главы что ль), шаги пайплайна - все в одной функции. И все это вперемешку с объявляемыми внутри main подфункциями (зачем? почему не отделить функции а код сделать высокоуровневым и читаемым? почему это перемешано?)
начали на 290 строке, закончили на 897. 600 строк. Огромная мега-функция “сделать все”.
Все это еще сдобрено переменным в глобальной области видимости (для усложения отладки?)
Еще меня очень сильно бесит безрамочность (или крайне блеклые рамки). Я вот 3 окна вешаю в темной теме друг на другом и…теперь фиг знает, где их границы. Теперь приходится взглядом находить узловые элементы вроде заголовка, он них мысленно чертить продолжения границ и куда-то в пересечения тыкать.
Это вот они пару пикселей сэкономили, рекламную картинку сделали приятнее и столько проблем мне добавили?
В самолетах еще используются рычажки “туды-сюды”. Я так понимаю, чтобы на ощупь по ним ориентироваться в полутемноте или перегрузке. Но внешний вид ползунка андройд крайне далек от “рычажка”.
или чисто cpu-intensive задачи. В них, несомненно, хороший компилируемый язык будет сильно впереди. Но не суть. Таких задач относительно мало. Чаще же всего у нас гибрид, где важнее io с дисками.
и именно поэтому выигрывают нейроотклики. Они же делаются за секунды в отличие от живого человека, который не живет на хх 24/7.
А hr точно хотели именно эту группу фокусить? Как будто бы они сами придумывают фильтры, которые дают преимущества совсем не хорошим для них специалистам.
Что вполне логично, ведь hr неподходящие по скилам для этого процесса (выбор фильтров для отсеивания нужных групп). Чтобы подходить - надо быть аналитиком и уметь в мат статистику, а я что-то сомневаюсь, что среди hr у нас есть аналитики в сколь-нибудь отличимых от нуля количествах.
смех смехом, но мы ничего не можем поделать с принципами: дырявостью, тяп-ляп и в продакшн, нулевая ответственность производителя софта. И суперпозиция этих принципов ничего хорошего нам не сулит.
Идея изоляции выглядит довольно здравой. Например что-то наподобие AppArmor, bubblewrap. Под виндовс, жаль, ничего такого нет.
когда прототип перестает быть игрушкой и становится активом компании. Когда в него приходят реальные пользователи, реальные деньги, персональные данные, интеграции, SLA, бухгалтерия, поддержка и ответственность.
я для себя пришел к очень простому разделению. Когда мы на стадии MVP - все затраты - это лишь код, наша система состоит из одного лишь кода. Когда мы перешли в реальную эксплуатацию, у нас начинают накапливаться данные, их стоимость начинает расти. И когда стоимость данных перевешивает стоимость кода - можно говорить, что мы перешли в enterprise.
Вот первая стадия отлично ложится на вайбкодинг из-за почти нулевых потерь при потере данных. Вайбкодинг дает (условно) шанс уничтожения данных 10%? Да и фиг с ним, у нас только тестовые, заново загрузим.
Но это становится неприемлемо дорогим на второй стадии. И тут подходит AI-augmentation (который выше назвали AI‑assisted development) - т.е. некая совместная работа человека и ИИ - это может быть “помощник думания”, “более продвинутый поиск по документации” и до “кодер, но с обязательным и пристальным ревью человека”. Общая цель - удержать шанс уничтожения данных околонулевым.
единственное что может сделать цод это отдать физические хосты и схд
или, временно отключив их на профилактику, сделать с них побайтовые копии. Это мало меняет суть. Они по роду деятельности могут забрать данные клиента, а вместе с иммунитетом - это идеальное место для продажи налево.
но он не только предоставляет инфраструктуру. Сама суть его взаимодействия с правоохранительными органами, когда выдается снимок виртуалки, предопределяет возможность вмешательства и кражи данных.
Если теперь сделать ему иммунитет к штрафу/преследованию, то получится участник, которому очень удобно продавать данные клиентов налево и ничего ему за это не будет.
Тем более, что Dota 2 сжимается аж на 35ГБ - ну вплоть до ближайшего обновления игры, которая может поменять и перезаписать половину из этого приобретённого места.
понимаете, это сэкономленное место как бы есть, но как бы его и нет - и от него вреда больше, чем пользы. Пользователь вот смотрит, что у него 50 гигов свободно - качает туда фильмы. Потом прилетает обновление доты и останавливает всю систему из-за исчерпания диска до нуля. При чем, для пользователя ничего не предвещало беды - дельта с прошлой папкой доты - ну пару гигов всего.
А если мы начинаем задумываться и резервировать пустое свободное пространство под эти случаи…то чем это отличается от занятого пространства?
Улыбнуло. Знаете, там давно все автоматизировано. Но вот беда…каждый раз приходит государство и наваливает еще требований и новых учетов. Как бы в районе 2005х бухучет фирмы реально было вести старым дедовским способом “в амбарной книге”. Минимальная автоматизация и это доступно каждому! А сейчас требования возросли настолько, что это смерти подобно - уже даже речи не идет о том, чтобы осилить это без программ.
Напомню, что УСН как режим при появлении заявлялся как пара платежей и все готово - настолько простым, что даже учет не нужен. Сейчас же он стал столь тяжелым, что пришел новый “АУСН” ему на смену с тем же намерением.
Я пробовал дуолингво на детях с нулевого уровня. Полгода и ничего (все также не могут читать и понимать А1), зато там куча пройденных таблеток. Те же полгода, потраченные на частотный словарь по 15-20 мин в день - дали куда более весомый результат, прям вот в разы.
Детальной статистики, я, конечно, не вел. Это все эмпирические ощущения.
У меня нет статистики, но, думаю, что нет.
Основным источником нагрузки являются временные таблицы.
Они используются потому, что в язык SQL не завезли вообще никакой вариант отладки - ну т.е. не существует никакого варианта прогнать сложный запрос по шагам и где-то там найти баг. Отсюда каждый шаг сохраняют во временную таблицу. Это неправильное состояние информационной системы (будто бы всегда включен режим отладки и расширенных логов), но другого просто нет.
От сложности запросов тоже никуда не уйти. По шкале OLTP-OLAP - 1с исторически система сильно сдвинутая в OLAP, т.е. в аналитическую часть. Для них характерны большие sql запросы с агрегациями. Если вот 1с принудительно разделить на OLTP (ввод доков) и OLAP (отчеты и аналитически-сложные вещи вроде партионного учета) - то в OLTP базе не будет сильного использования tempdb.
Это вообще один из хороших и простых советов по улучшению работы с базой - максимально разнести нагрузку OLAP и OLTP. Потому что эти 2 вида систем не могут прийти к компромиссу: то, что хорошо для одной (больше индексов! больше денормализации и витрин данных!) - очень сильно убивает производительность второй. И так с любым тюнингом (в том числе и СУБД) - улучшим в одну сторону, во второй много потеряем. Отсюда вынос всех “пользователей-аналитиков” в отдельную базу с обновлением раз в сутки - очень действенное решение. Оно может прям в разы улучшить ситуацию с тормозами.
Вендор может и ушел, а преступлением это быть не перестало. Там даже без возмещения чего-то правообладателю, насколько помню: особо крупный размер (>1млн) => уголовка до 6 лет участникам, штраф и возможно конфискация оборудования фирме - этим силовики могут начать заниматься в любой момент.
Я отношу оценку алгоритмической сложности, проблемы N+1 к компетенциям разработчика. Поэтому
такое на совести разработчика. Но вот тюнинг СУБД под конкретные нагрузки и конкретные особенности железа - это отдельное искусство у DBA - вот именно его не будет.
Да не часто, а всегда. Типовая или не типовая вообще без разницы. Другое дело, что это очень дорогостоящий путь, где нужно под лупой рассматривать каждый тяжелый запрос вместе с бизнес-требованиями к нему и характером использования.
не между ними, а кмк вообще ничей. Роль DBA столь специфичная, что ни один, ни другой ей не будет обладать. Просто по экономическим соображениям: в найме этот человек будет выглядеть дороже и бизнес не захочет переплачивать без болезненных проблем прямо сейчас.
Отсюда подход “а давайте заранее подумаем” крайне редкий.
Почему меня не покидает ощущение, что комменты тоже написаны ИИ?
“честное”
“Одно опасение по существу”
“и это стоило проговорить в статье громче, чем я сделал”
обилие “не про …, а про …”
У меня есть опыт применения этого. Sonnet-4.6 high reasoning. Между 5 и 10% на элементов на выходе нельзя найти в тексте (и это при том, что я использую нечеткий поиск с довольно низким коэффициентом срабатывания).
Так что без цикла “вот эти 5 пунктов не прошли проверку, доработай” эта штука неработоспособна - она почти всегда будет заворачивать документ на этапе приемки-проверки.
Дело за малым, осталось написать это на всех языках мира и во всех возможных оборотах. Ах, да, еще надо учесть, что новый язык может быть описан в другой части промпта /s
P.S. обожаю вайбкодеров с их “защитами”.
Я в некотором шоке, кааак вы читаете свой код-то?
https://github.com/sukamenev/booktrans/blob/main/src/booktrans/cli.py функция main()
разбор аргументов, доп проверки их совместимости, рабочие папки и мьютекс на нее, прямые вопросы модели, что-то про оркестрацию задач, OCR, разборы книги (на главы что ль), шаги пайплайна - все в одной функции. И все это вперемешку с объявляемыми внутри main подфункциями (зачем? почему не отделить функции а код сделать высокоуровневым и читаемым? почему это перемешано?)
начали на 290 строке, закончили на 897. 600 строк. Огромная мега-функция “сделать все”.
Все это еще сдобрено переменным в глобальной области видимости (для усложения отладки?)
Еще меня очень сильно бесит безрамочность (или крайне блеклые рамки). Я вот 3 окна вешаю в темной теме друг на другом и…теперь фиг знает, где их границы. Теперь приходится взглядом находить узловые элементы вроде заголовка, он них мысленно чертить продолжения границ и куда-то в пересечения тыкать.
Это вот они пару пикселей сэкономили, рекламную картинку сделали приятнее и столько проблем мне добавили?
В самолетах еще используются рычажки “туды-сюды”. Я так понимаю, чтобы на ощупь по ним ориентироваться в полутемноте или перегрузке. Но внешний вид ползунка андройд крайне далек от “рычажка”.
или чисто cpu-intensive задачи. В них, несомненно, хороший компилируемый язык будет сильно впереди. Но не суть. Таких задач относительно мало. Чаще же всего у нас гибрид, где важнее io с дисками.
и именно поэтому выигрывают нейроотклики. Они же делаются за секунды в отличие от живого человека, который не живет на хх 24/7.
А hr точно хотели именно эту группу фокусить? Как будто бы они сами придумывают фильтры, которые дают преимущества совсем не хорошим для них специалистам.
Что вполне логично, ведь hr неподходящие по скилам для этого процесса (выбор фильтров для отсеивания нужных групп). Чтобы подходить - надо быть аналитиком и уметь в мат статистику, а я что-то сомневаюсь, что среди hr у нас есть аналитики в сколь-нибудь отличимых от нуля количествах.
смех смехом, но мы ничего не можем поделать с принципами: дырявостью, тяп-ляп и в продакшн, нулевая ответственность производителя софта. И суперпозиция этих принципов ничего хорошего нам не сулит.
Идея изоляции выглядит довольно здравой. Например что-то наподобие AppArmor, bubblewrap. Под виндовс, жаль, ничего такого нет.
я для себя пришел к очень простому разделению. Когда мы на стадии MVP - все затраты - это лишь код, наша система состоит из одного лишь кода. Когда мы перешли в реальную эксплуатацию, у нас начинают накапливаться данные, их стоимость начинает расти. И когда стоимость данных перевешивает стоимость кода - можно говорить, что мы перешли в enterprise.
Вот первая стадия отлично ложится на вайбкодинг из-за почти нулевых потерь при потере данных. Вайбкодинг дает (условно) шанс уничтожения данных 10%? Да и фиг с ним, у нас только тестовые, заново загрузим.
Но это становится неприемлемо дорогим на второй стадии. И тут подходит AI-augmentation (который выше назвали AI‑assisted development) - т.е. некая совместная работа человека и ИИ - это может быть “помощник думания”, “более продвинутый поиск по документации” и до “кодер, но с обязательным и пристальным ревью человека”. Общая цель - удержать шанс уничтожения данных околонулевым.
или, временно отключив их на профилактику, сделать с них побайтовые копии. Это мало меняет суть. Они по роду деятельности могут забрать данные клиента, а вместе с иммунитетом - это идеальное место для продажи налево.
но он не только предоставляет инфраструктуру. Сама суть его взаимодействия с правоохранительными органами, когда выдается снимок виртуалки, предопределяет возможность вмешательства и кражи данных.
Если теперь сделать ему иммунитет к штрафу/преследованию, то получится участник, которому очень удобно продавать данные клиентов налево и ничего ему за это не будет.
понимаете, это сэкономленное место как бы есть, но как бы его и нет - и от него вреда больше, чем пользы. Пользователь вот смотрит, что у него 50 гигов свободно - качает туда фильмы. Потом прилетает обновление доты и останавливает всю систему из-за исчерпания диска до нуля. При чем, для пользователя ничего не предвещало беды - дельта с прошлой папкой доты - ну пару гигов всего.
А если мы начинаем задумываться и резервировать пустое свободное пространство под эти случаи…то чем это отличается от занятого пространства?