Аноним:
а культурнее это как? Если они Вам ответят «Извините, нет» — так лучше?))
Абдула:
иди ты нахрен гребенная обида
Аноним:
Че за нет. Че за че, все твое че прочекали до боли обида по жизни. соболезную за не сложившуюся несчастливую жизнь. злоба обида, походу ты неудачник чикало
Санжар:
у меня есть проблема
{МодульУправляемогоПриложения(12)}: Ошибка при вызове метода контекста (Предупреждение)
Предупреждение(«Ish vaqti tugagan»);
по причине:
Использование модальных окон в данном режиме запрещено!
Кирилл:
Используйте метод «Сообщить()»
Gummi:
Если хотите использовать именно Предупреждение, то используйте ПредупреждениеАсинх. Не забудьте и процедуру тоже объявить, как Асинх. Ну и почитайте про асинхронные методы.
Тесты можно было бы писать с ключевым словом «НАПРИМЕР», «НУДОПУСТИМ», «ПРЕДПОЛОЖИМ», всё с различной семантикой.
Для mock objects можно разработать не имеющие аналогов операторы «КАКБЫ», «КАКБУДТО».
Вместо примитивных exceptions нужны «УКЛОНЕНИЕ», «ВОЛЬНОСТЬ».
catch заменить на «ПРИНЯТЬМЕРЫ» как более менее лучшее усовершенствование.
type switch усовершенствовать в «НУТИПА».
Все еще выше чем порог входа в JS :) Опять же, простота использования бизнес объектов это преимущество. Более сложные вещи там тоже есть, объединения как в SQL, планом видов характеристик (EAV) и прочее.
Можно сколько угодно зубоскалить, но когда сталкиваешься с необходимостью автоматизации воинской части где нужны зарплатные и финансовые ведомости на год, которые печатают на А3, с динамическим количеством колонок и столбцов и при хочется укладываться по времени расчетов хотя бы минут в 5 то приходится вызывать 1С-ников, т.к. только они могут сделать такую систему за вменяемые сроки.
Вы просто не сталкивались с серьезными проектами на 1С. Это на уровень выше чем сайтики клепать с масштабированием на AWS.
Фирма 1С «не осилила»/«не захотела» решить этот вопрос.
Он решаем и скорость работы по сети раз в шесть быстрее, чем в 1С 7.7.
Вообщем-то вполне приемлемо даже для работы с базами где-то до 50GB (это 100%).
Впрочем как никак 1С 7.7 это 1996 год и для того времени это была весьма прогрессивная новая технология.
Путь использования реляционных баз для обеспечения возможности использования объектов 1С это «милостыня бедному».
То что реализовано лишь подтверждает качественную реализацию MSSQL.
Никогда не было желания разработать а-ля run-time 1С, но нужно
признать, что некоторые объекты в 1С неплохо реализованы.
Правда их архитектура представления данных (как бы это сказать) - «кастрированная».
Так как ныне компьютера имеют быстродействующие CPU, ..., то это
«сглаживает» любую не очень качественную (речь не о 1С) архитектуру работы с данными.
Архитектура представления данных в SQL пригодна лишь для некой ниши задач.
Популярна она потому, что в эту нишу попадает класс (некоторых) учетных задач.
Проблема ныне в том, что лет шестьдесят назад были разработаны ХОРОШИЕ технологии, которые были неплохо приспособлены к возможностям ЭВМ тех годов.
К сожалению пока
Воз и ныне там.
Ныне разработано много NOSQL баз данных.
ИМХО их основная проблема в том, все они пытаются «натянуть сову на глобус».
Забавно, как вы кинулись что-то читать и выискивать косяки чтобы доказать какая 1С кривая. Ну какая v7.7 если на дворе v8.3? Это настолько устаревшая версия что существует наверное в совсем полуподвальных шарашках на 5 чел, там ее скорости хватает с головой.
которые несколько переусложнены ещё на бумажной стадии развития бумагооборота как адаптивная реакция на специфичность фикции собственности в постимперской России
затем цельнотянута в электронную форму
ну а сей период именно благодаря лёгкости внесения нормативных изменений в нпа и даже(о нет) законы - и провидящие будущее апдейты разработчиков однойS - и привило к динамической монополии
т.е. все довольны - учёт и контроль есть!
постоянные изменения(ой- усовершенствования) нормативной базы есть!
синхронное изменение софта есть
синхронное изменение норм что бы была необходимость быть клиентом софто-поставщика есть
Кстати, 1С ещё и хорошо сочетается с темой. Язык 1С создавался примерно для той же ниши, что и Go: надо, чтобы не очень грамотные программисты не могли ничего кардинально сломать, но могли напрограммировать всё, что им надо.
И тоже: вроде недостаточно абстракций, свои классы создавать нельзя, функции в переменные сохранять нельзя. Зато как в Go есть корутины, так в 1С есть вшитые ORM и GUI.
Они ничего не могут. Какие-то дебило-интеграторы просили им специальную апи сделать под их конфиг, когда же я написал что можно обойтись одни видом и вызовом процедуры, это существо сказало, что sql не знает и слилось. Хотели 200.000 за интеграцию, но конфиги для них какой-то гениальный 1сник написал, который программировать могет, а они нет даже 100 строчек написать не в стоянии за 200k. Тогда я и понял, что шутки про 1сников - это не тож самое, что угнетение похапешников, последние программисты, но все стебутся с используемого ими языка… Тут же у нас что-то вроде виндовых сисьадминов, не умеющих в сосноли три команды набрать
Тут же у нас что-то вроде виндовых сисьадминов, не умеющих в сосноли три команды набрать
«1сник» просто такое же абстрактное понятие как «компьютерщик». Если эникея, который джумлу ставит, попросить что-то к ней дописать, он тоже скажет, что пэхапэ не знает. Отсюда надо делать вывод, что все компьютерщики тупые?
Так выбирая язык программирования, выбираешь и единообразие.
В 1С почти аналогично. С одной стороны, компилятор не ограничивает. С другой стороны все программы на базе готовых решений 1С и волей-неволей приходится подстраиваться под их стиль.
Художествами дома заниматься, с женой, или с лишпом, если жены нет. А на работе нужно художника по рукам бить, чтоб все художники писали унифицированно и единообразно. Иначе буизнес будет тратить лишние бапки на резгребания творчеств этих самых художников, а это буизнесу сильно не нравится.
ЗЫ истинное художество-это архитектура, алгоритмы, схемы и системы, а не ЯП и его синтаксические конструкции, названия переменных и функций etc. Вот такие художества буизнес приветствует. Придумать эффективное, качественное и остроумное решение, вот что прикольно. На чем его описать вообще по барабану, хоть на азвуке Морзе. На ЯП-ы дрючат как раз импотенты в этом плане, они так сублемируют, как тот чувак на свой лишп.
это полумеры! предлагаю погромистов еще и по росту подбирать, чтоб не выше 160 были. тогда их больше в одну комнату посадить можно. и кормить макаронами.
алгоритмы от роста не зависят! а макароны - прекрасный источник творческих сил.
это полумеры! предлагаю погромистов еще и по росту подбирать, чтоб не выше 160 были
Если у какого-то буизнеса офис с высотой потолков 160см, то придется этому буизнесу и по росту подбирать. Не нравится, никто не заставляет там работать. Тутошние прогроммистеры забывают, что он прогроммистер только благодаря тому, что какой-то буизнес решил применить его навык, иначе этот прогроммистер был бы любителем. Значит прогроммистер должен исходить прежде всего от потребностей буизнеса, а не своих влажных маняфантазий.
Нет, не довольны. Но есть объективная реальность, с которой необходимо как-то существовать и если требуется отчет по форме установленной форме то, например, налоговую вообще не волнует ваши размышления о неэффективности гос аппарата вообще и документооборота в частности.
Кстати, 1С ещё и хорошо сочетается с темой. Язык 1С создавался примерно для той же ниши, что и Go: надо, чтобы не очень грамотные программисты не могли ничего кардинально сломать, но могли напрограммировать всё, что им надо.
И тоже: вроде недостаточно абстракций, свои классы создавать нельзя, функции в переменные сохранять нельзя. Зато как в Go есть корутины, так в 1С есть вшитые ORM и GUI.
Приятно, когда в общей беседе есть собеседники которые понимают тему обсуждения. Бессмысленный спор и попытки объяснить превращаются в диалог. Спасибо.
Это ложь. Современная бухгалтерская/зарплатная конфа размером от 1 до 3Гб отжирает в работе около 2-4Гб RAM на одного юзера в реальной работе - и это только процесс 1ски отжирает, а ведь еще винда тоже кушать хочет.
это(огр на 1600мм на рост прг-истов) нарушает ТК в части ужесточения(необоснованое) а точнее не предоставление обычных(нормальных по санпинам и прочим регламентам) условий труда для программиста -
эти требования - в общем виде легко выгугливаются - вы всё таки в РФ в правовом государстве
Они ничего не могут. Какие-то дебило-интеграторы просили им специальную апи сделать под их конфиг, когда же я написал что можно обойтись одни видом и вызовом процедуры, это существо сказало, что sql не знает и слилось.
Вы правы в том что многих разработчиков 1С нужно пороть розгами на конюшне. Из-за низкого порога вхождения туда часто попадают не те люди которых стоило бы пускать на порог ИТ отдела. Точно такая же ситуация с JS-разработчиками.
По теме - я вообще не знаю ни одного реального примера который не мог бы быть автоматизирован на 1С. Если базовых возможностей 1С и ActiveX не хватало, то писалась внешняя компонента (dll) и все необходимое приводилось к сущностям 1С.
это(огр на 1600мм на рост прг-истов) нарушает ТК в части ужесточения(необоснованое)
Расскажи это айбиему, увольняющему чуваков старше некоторого возраста, и это его потоковая практика. У буизнесов есть юротдел, и они свой хлеб не зря едят, так что шансов поймать буизнес на чем-то у среднестатистического погроммистешки мало.
Художествами дома заниматься, с женой, или с лишпом, если жены нет.
Можно же чередовать :)
А на работе нужно художника по рукам бить, чтоб все художники писали унифицированно и единообразно. Иначе буизнес будет тратить лишние бапки на резгребания творчеств этих самых художников, а это буизнесу сильно не нравится.
Проблема в том что далеко не на каждом проекте есть системный архитектор который бьет по рукам тому художнику который говорит например «О, я на хабре прочитал про докер и кубер, прикольно - все используют. нужно и у нас поставить, заодно разберусь что это такое».
ЗЫ истинное художество-это архитектура, алгоритмы, схемы и системы, а не ЯП и его синтаксические конструкции, названия переменных и функций etc. Вот такие художества буизнес приветствует. Придумать эффективное, качественное и остроумное решение, вот что прикольно. На чем его описать вообще по барабану, хоть на азвуке Морзе.
Ну, язык тоже необходимо выбирать как минимум с учетом возможности сопровождения в будущем, если весь отдел разработки собъет автобус. В остальном полностью согласен.
На ЯП-ы дрючат как раз импотенты в этом плане, они так сублемируют, как тот чувак на свой лишп.
Тут не в потенции дело. А в психологии. Я сейчас тезис вброшу: максимально забуриваются в детали реализации языка - программисты-анальники (по Веронике Степановой). Они как мышки-полевки, роют землю, обустраивают себе норку-зону комфорта где они все знают в деталях и напрочь отказываются подняться в воздух и взглянуть на ситуацию в целом. Такие люди могут быть очень крутыми спецами, но эта специализация вызывает сильную проф. деформацию, сравнимую с контузией.
Системные архитекторы же вынуждены парить в воздухе как орлы чтобы видеть ситуацию в целом и не допускать неверных решений на проекте и клевать чаек пролетающих мимо. Им также необходимо понимать что твориться в норках (на низком уровне ЯП) чтобы регулярно спускаться на землю, засовывать голову в норку и спрашивать «ты что там делаешь? ты что ебанутый?» (с) и затем объяснять ПОЧЕМУ нужно сделать иначе. Это сравнимо с авторским надзором в строительных проектах.
Есть те кто продолжает парить покрикивая сверху, это не орлы - это чайки. И реализуют они чайка-менеджмент.