Под визуальный стиль написано и придумано куда меньше средств снижения сложности. ООП с объединением данных и методов работы с ними, модули, функции, пространства имен. А без этого вы на порядки быстрее добежите до максимально-осознаваемой человеческим мозгом сложности. IDE с кодом работают в разы лучше: та же пошаговая отладка с функционалом "пропустить до ... выхода из функции/входа в функцию/следующего шага в текущей функции", остановок по условию, навигация. Под код заточены инструменты совместной разработки.
С некоторыми проблемами выше я сталкивался лично на примере бизнес-процессов в битриксе24. Вот пример с навигацией: Открываю бизнес процесс, вижу бизнес-схему на 6 экранов в ширину и 10 в высоту. Слежу за потоком выполнения - вот условный оператор, стрелка влево от него уходит на 2 экрана и стрелка вправо на 2: представляете, какая удобная навигация? То, что в коде делается сворачиванием ветки условного оператора одним кликом в области фокуса внимания - тут я вынужден хватать полосу прокрутки внизу окна и ездить влево-вправо, следя за линией, где она повернет. Повернула? Теперь хватаем вертикальную полосу прокрутки и опускаемся вниз до следующего визуального элемента. Что можно сказать о производительности у разработчика с этим инструментом? Да я, похоже, в "лабиринты" играю больше, чем полезное что-то делаю.
Как вы собираетесь компенсировать эти инструменты?
Отчасти да. Потому что у любого бизнеса без роста есть вполне ограниченное число мест, где автоматизация принесет прибыль. Их можно отсортировать в порядке убывания прибыли и начать делать - и мы получим убывающую эффективность у каждого нового шага. В какой-то точке она перейдет отметку 0 и все последующие действия убыточны. Без роста числа бизнесов и/или без роста размера каждого бизнеса отсюда получается довольно ограниченная потребность в программистах. Это скорее разовая проектная работа, а дальше нужна техподдержка, а не программист. --- В эту картину вносит искажение глобальное смещение рынков - переход торговли в инет, переход покупателей на смартфоны и чуть более локальные, но все еще огромные: изменения схемы расчета налогов и т.д. - они играют как будто "рост", только без самого роста.
Я как-то занимался проблемой оптимизации склада торговой сети: была похожая картинка, что есть FP ошибки (слишком много храним, теряем деньги на складских помещениях) и FN ошибка (слишком мало храним, не смогли продать) - правда, относительно статьи расстановка обратная - т.е. FN очень дорогая, а FP намного дешевле. После мат обсчета вышло, что огромная часть склада просто перезатарена (слишком много храним) - я не помню сейчас точные цифры за давностью, но кажется в районе 25% в принципе лишнего, которое без какого-то катаклизма в росте продаж не будет использоваться никогда. И еще 25% спорные - их можно сократить, потеряв 0,5-1% продаж. Терпимо было в ситуациях, когда менеджер должен был решать задачу о количестве запаса (т.е. речь о цифре выше 1, и чем выше - тем лучше), но особенно плохо было в задаче о том, нужна ли тут позиция вообще (т.е. выбор между 0 и 1). Я пришел к выводу, что люди без специального для этого образования крайне плохо работают с вероятностными величинами. Они их совсем не понимают. Они прикидывают на глаз, какая больше и приводят ее к бесконечно большой, а вторую, соответственно, к бесконечно малой. И так выходило, что при выборе между 0 и 1 всегда выбирался 1 (потому что "штраф" за 1 выше штрафа за "0"), абсолютно не взирая на вероятность появления. И навыбирали, как видите, огромную гору - гораздо выше, чем стоили бы дорогие ошибки FN.
Есть у меня подозрение, что тут мы имеем похожую проблему в головах. Найм неподходящего сотрудника притягивается к бесконечно большим затратам, поэтому пропуск подходящих кандидатов притягивается к нулевым.
Ох, если бы под каждым таким решением в основе лежали цифры и a/b тесты, это было бы круто. Но у нас то "тарологи", то "наметанный глаз", то "психологические приемы", то еще какие-то на коленке выдуманные только вчера признаки.
Я не согласен с тем, что отфильтрованный сотрудник ничего не стоит. Он стоит: - репутации, когда в следующую трехлетку часть кандидатов не захочет идти, потому что там "идиоты в найме" - затрат на персонал (даже того же HR) - недополученной прибыли и месту в конкуренции. Ведь если в двух словах описать все ИТ, то это автоматизация, а это либо снижение издержек, либо создание какой-то новой ценности для клиентов.
Так причина проста: у HR нет ровно никакой ответственности за ложно-отрицательный результат (отказ подходящему кандидату). Это ошибка с нулевой стоимостью, которую можно не учитывать при достижении kpi для премий. Как в головах руководства эта ситуация поменяется, эти циферки начнут отслеживать и из оплаты HR начнут вычитать затраты, так все и изменится.
Как тут не вспомнить фразу: Люди делают не то, что вы от них ожидаете, а то, что проверяете.
А зачем тогда существует онбординг по 2 недели (и более)? Ведь в этой сессии вы исходите из того, что собеседуемый уже разобрался в архитектуре проекта. И тогда можно проверить его на реальных задачах. Думаю, что это применимо только в очень небольших нишах - там, где проект небольшой - если у вас условный микросервис на 5 сущностей, его можно окинуть взглядом за 10 минут, то применимо. В остальных же случаях это будет проваленное собеседование (причем независимо от знаний соискателя) и масса потраченного времени: как вашей фирмы, так и соискателей.
Тут еще большие опасения вызывает ситуация конфликта интересов, кода хантинговое агенство идет в обучение - тогда ведь обучающиеся могут обходить стандартные процедуры поиска/приоритезации выдачи и прочее. Уж очень лакомым тут выглядит вариант "поставить этих ребят" выше в поиске (сюда вот уже можно отнести работу не с полным объемом соискателей, а по одному - это уже дает преимущества в проходе hr-фильтра).
Думаю, что основная проблема проистекает совсем не из ИТ. Основная проблема - в нестабильности бизнес климата в рф, которая последние 2 года в принципе лежит на дне, но и до этого ощутимо снижалась. Отсюда работодатели не хотят брать людей на вырост: ну а какой вырост, если горизонт планирования полгода-год; на этом промежутке любой стажер - это только убытки и ничего больше. Любой джун - это потенциально ноль прибыли или убытки. Это и формирует основное отличие: во времена в районе 2010 не было проблем взять человека на вырост, поэтому выбирали по обучаемости и стремлению, а сейчас - режим пожара - нужен специалист, который через неделю начнет решать задачи вот в этом специфичном стеке, потому что через полгода, возможно, и бизнеса то уже не будет. Отсюда мы получаем крайне сложный порог входа. ИТ сфере достается больше всего проблем от нестабильности, потому что она оперирует огромными объемами обучения и быстрым темпом изменения. Те же печники, которых упоминали в комментариях, не требуют дообучения каждый год, им достаточно только наработки опыта - а в ИТ нужно и то, и другое - поэтому в долгосроке ИТ специалисты дороже. У них банально больше затрат на обучение.
Так вся сложность скрыта за фразой "найти ... видео, которые мы бы хотели посмотреть". Это не такая уж простая задача, если за идею брать не только пару фильмов, вышедших за последний за месяц - но захватывать и потенциальные видео по сферам интересов, которые захочется посмотреть в будущем месяце. Думаю, что при реализации довольно быстро мы придем к чему-то похожему на сервер кеша гугл и очень немалым требованиям к каналу и объему дискового пространства.
мы практиковали этот вариант в необычном исполнении: знакомый ехал на серверную площадку м9 обслуживать сервера хостинга и в процессе этого качал на хард фильмы по заказанному списку :)
ну пусть будет 9ОО - 95% клиентов не заметит разницы. Смс был и остается ненадежным каналом. И вот у нас остается единственный фактор верификации - подделываемое имя отправителя. Раньше еще можно было полагаться на аккаунт разработчика, но сейчас - то Зухра, то индус, то еще кто. Добавим сюда еще спешку как очень негативный фактор для принятия решений (ведь не зря все мошенники упор делают на срочность). Вот и получаем крайне низкую безопасность.
Насколько я слышал, в США в ИЖС практикуются специальные противоштормовые крепления крыши. Которые представляют из себя толстенный трос, одним концом цепляющийся за крышу, проходящий через отверстие в стене и вторым концом цепляющийся за фундамент - и вся эта система находится в преднатяженном состоянии.
Ага, приложения банков от левых разработчиков, неизвестно кому принадлежащий корневой сертификат с 30-летним правом на все, протухшие "валидные" сертификаты и карты с неизвестным сроком действия. Прям чувствуется, что безопасность все повышается с каждым шагом. /s
Не хватает у эпла автоматизации пока что. Им стоило бы подписаться на уведомления от сбера о выходе новых версий, тогда после ручной проверки можно через час после выхода блокировать. В принципе быстрее, чем кто-то из пользователей среагирует.
Я не очень понимаю, почему даже 45? Какой толк от сбора, если на его администрирование уходит почти половина суммы? Деятельность ради деятельности. Это даже выше, чем берут площадки маркетплейсы - а в них входит и поддержание площадки для десятков миллионов клиентов, и реклама, и логистика/доставка. А эти ребята будто новый маркетплейс открыли, только его не существует - для обслуживания их деятельности достаточно программы, написанной на коленке одним человеком.
Тут еще отдельный вопрос - а кто оценивает стоимость одной лицензии? Заинтересованная в завышении сторона - окуп?
Не той лицензии. Вы пишете о нарушении лицензии бандла SQL - это дешевый вариант лицензии, но привязанный к использованию только платформой 1с. Но нарушается лицензия на саму 1с: п.4 Лицензиат обязуется ... не совершать и не допускать совершения третьими лицами ... вносить какие-либо изменения в содержимое баз данных ... за исключением тех изменений, которые вносятся штатными средствами (1с) ... и описанными в сопроводительной документации (1с).
--- Простыми словами - любое изменение данных в обход платформы 1с - это нарушение лицензии.
Я и не предлагаю перенос в пустую базу. 1) добавляете план обмена в основную базу на все документы (один узел = одной новой базе, как-то там деля по организациям между ними)
2) Создаете 2 "разделенные базы" копиями с основной. 3) Удаляете в них ненужные части (длительная операция, без прямого доступа к СУБД) 4) Делаете предварительную сверку (данные должны быть актуальными на момент создания копии) 5) Доставляете накопившееся в плане обмена до разделенных баз 6) Допроверяете перенесенное (ориентировочно за 14 дней доки тут будут) 7) Переводите пользователей на разделенные базы --- С 5 по 7 пункты накрываем блокировкой входа пользователей во все базы - это и будет даунтайм. Если хочется его сократить, то можно сделать эти пункты в 2 итерации: в первую итерацию без блокировки входа перенести за 14 дней и допроверить их, а потом с блокировкой еще накопившийся за это время кусок (врятли он будет больше 2х дней).
Что мешало создать 2 новые "разделенные" базы заранее, не останавливая деятельность основной и доставлять туда новые появляющиеся документы? Могли бы и за час тогда перейти.
Ваш путь с прямым удалением в SQL:
во-первых, нарушает лицензию 1с у клиента. Сейчас за таким никто не гоняется, но в любой момент могут начать. Донесли ли вы до клиента, что если этот кейс получит юридические претензии, то клиенту потом заново лицензии покупать? Плюс условный миллион рублей на затраты
во-вторых, крайне сложно проверить целостность данных. Тестирование и исправление - не панацея. А последствия этого метода вполне могут выявится не сразу при приемке, а спустя время, чем сильно все осложнить.
Под визуальный стиль написано и придумано куда меньше средств снижения сложности. ООП с объединением данных и методов работы с ними, модули, функции, пространства имен. А без этого вы на порядки быстрее добежите до максимально-осознаваемой человеческим мозгом сложности.
IDE с кодом работают в разы лучше: та же пошаговая отладка с функционалом "пропустить до ... выхода из функции/входа в функцию/следующего шага в текущей функции", остановок по условию, навигация.
Под код заточены инструменты совместной разработки.
С некоторыми проблемами выше я сталкивался лично на примере бизнес-процессов в битриксе24. Вот пример с навигацией:
Открываю бизнес процесс, вижу бизнес-схему на 6 экранов в ширину и 10 в высоту. Слежу за потоком выполнения - вот условный оператор, стрелка влево от него уходит на 2 экрана и стрелка вправо на 2: представляете, какая удобная навигация? То, что в коде делается сворачиванием ветки условного оператора одним кликом в области фокуса внимания - тут я вынужден хватать полосу прокрутки внизу окна и ездить влево-вправо, следя за линией, где она повернет. Повернула? Теперь хватаем вертикальную полосу прокрутки и опускаемся вниз до следующего визуального элемента.
Что можно сказать о производительности у разработчика с этим инструментом? Да я, похоже, в "лабиринты" играю больше, чем полезное что-то делаю.
Как вы собираетесь компенсировать эти инструменты?
Отчасти да. Потому что у любого бизнеса без роста есть вполне ограниченное число мест, где автоматизация принесет прибыль. Их можно отсортировать в порядке убывания прибыли и начать делать - и мы получим убывающую эффективность у каждого нового шага. В какой-то точке она перейдет отметку 0 и все последующие действия убыточны.
Без роста числа бизнесов и/или без роста размера каждого бизнеса отсюда получается довольно ограниченная потребность в программистах. Это скорее разовая проектная работа, а дальше нужна техподдержка, а не программист.
---
В эту картину вносит искажение глобальное смещение рынков - переход торговли в инет, переход покупателей на смартфоны и чуть более локальные, но все еще огромные: изменения схемы расчета налогов и т.д. - они играют как будто "рост", только без самого роста.
Я как-то занимался проблемой оптимизации склада торговой сети: была похожая картинка, что есть FP ошибки (слишком много храним, теряем деньги на складских помещениях) и FN ошибка (слишком мало храним, не смогли продать) - правда, относительно статьи расстановка обратная - т.е. FN очень дорогая, а FP намного дешевле. После мат обсчета вышло, что огромная часть склада просто перезатарена (слишком много храним) - я не помню сейчас точные цифры за давностью, но кажется в районе 25% в принципе лишнего, которое без какого-то катаклизма в росте продаж не будет использоваться никогда. И еще 25% спорные - их можно сократить, потеряв 0,5-1% продаж.
Терпимо было в ситуациях, когда менеджер должен был решать задачу о количестве запаса (т.е. речь о цифре выше 1, и чем выше - тем лучше), но особенно плохо было в задаче о том, нужна ли тут позиция вообще (т.е. выбор между 0 и 1).
Я пришел к выводу, что люди без специального для этого образования крайне плохо работают с вероятностными величинами. Они их совсем не понимают. Они прикидывают на глаз, какая больше и приводят ее к бесконечно большой, а вторую, соответственно, к бесконечно малой. И так выходило, что при выборе между 0 и 1 всегда выбирался 1 (потому что "штраф" за 1 выше штрафа за "0"), абсолютно не взирая на вероятность появления. И навыбирали, как видите, огромную гору - гораздо выше, чем стоили бы дорогие ошибки FN.
Есть у меня подозрение, что тут мы имеем похожую проблему в головах. Найм неподходящего сотрудника притягивается к бесконечно большим затратам, поэтому пропуск подходящих кандидатов притягивается к нулевым.
Ох, если бы под каждым таким решением в основе лежали цифры и a/b тесты, это было бы круто. Но у нас то "тарологи", то "наметанный глаз", то "психологические приемы", то еще какие-то на коленке выдуманные только вчера признаки.
Я не согласен с тем, что отфильтрованный сотрудник ничего не стоит. Он стоит:
- репутации, когда в следующую трехлетку часть кандидатов не захочет идти, потому что там "идиоты в найме"
- затрат на персонал (даже того же HR)
- недополученной прибыли и месту в конкуренции. Ведь если в двух словах описать все ИТ, то это автоматизация, а это либо снижение издержек, либо создание какой-то новой ценности для клиентов.
Так причина проста: у HR нет ровно никакой ответственности за ложно-отрицательный результат (отказ подходящему кандидату). Это ошибка с нулевой стоимостью, которую можно не учитывать при достижении kpi для премий. Как в головах руководства эта ситуация поменяется, эти циферки начнут отслеживать и из оплаты HR начнут вычитать затраты, так все и изменится.
Как тут не вспомнить фразу: Люди делают не то, что вы от них ожидаете, а то, что проверяете.
А зачем тогда существует онбординг по 2 недели (и более)? Ведь в этой сессии вы исходите из того, что собеседуемый уже разобрался в архитектуре проекта. И тогда можно проверить его на реальных задачах. Думаю, что это применимо только в очень небольших нишах - там, где проект небольшой - если у вас условный микросервис на 5 сущностей, его можно окинуть взглядом за 10 минут, то применимо.
В остальных же случаях это будет проваленное собеседование (причем независимо от знаний соискателя) и масса потраченного времени: как вашей фирмы, так и соискателей.
А до этого: можно ли программисту приходить со справочником по языку? Вобщем, сколько профессия существует.
А есть ли тут вообще проблема, если он таким же образом сможет решать все рабочие задачи?
Тут еще большие опасения вызывает ситуация конфликта интересов, кода хантинговое агенство идет в обучение - тогда ведь обучающиеся могут обходить стандартные процедуры поиска/приоритезации выдачи и прочее. Уж очень лакомым тут выглядит вариант "поставить этих ребят" выше в поиске (сюда вот уже можно отнести работу не с полным объемом соискателей, а по одному - это уже дает преимущества в проходе hr-фильтра).
Думаю, что основная проблема проистекает совсем не из ИТ. Основная проблема - в нестабильности бизнес климата в рф, которая последние 2 года в принципе лежит на дне, но и до этого ощутимо снижалась. Отсюда работодатели не хотят брать людей на вырост: ну а какой вырост, если горизонт планирования полгода-год; на этом промежутке любой стажер - это только убытки и ничего больше. Любой джун - это потенциально ноль прибыли или убытки.
Это и формирует основное отличие: во времена в районе 2010 не было проблем взять человека на вырост, поэтому выбирали по обучаемости и стремлению, а сейчас - режим пожара - нужен специалист, который через неделю начнет решать задачи вот в этом специфичном стеке, потому что через полгода, возможно, и бизнеса то уже не будет. Отсюда мы получаем крайне сложный порог входа.
ИТ сфере достается больше всего проблем от нестабильности, потому что она оперирует огромными объемами обучения и быстрым темпом изменения. Те же печники, которых упоминали в комментариях, не требуют дообучения каждый год, им достаточно только наработки опыта - а в ИТ нужно и то, и другое - поэтому в долгосроке ИТ специалисты дороже. У них банально больше затрат на обучение.
Так вся сложность скрыта за фразой "найти ... видео, которые мы бы хотели посмотреть". Это не такая уж простая задача, если за идею брать не только пару фильмов, вышедших за последний за месяц - но захватывать и потенциальные видео по сферам интересов, которые захочется посмотреть в будущем месяце.
Думаю, что при реализации довольно быстро мы придем к чему-то похожему на сервер кеша гугл и очень немалым требованиям к каналу и объему дискового пространства.
мы практиковали этот вариант в необычном исполнении: знакомый ехал на серверную площадку м9 обслуживать сервера хостинга и в процессе этого качал на хард фильмы по заказанному списку :)
ну пусть будет 9ОО - 95% клиентов не заметит разницы. Смс был и остается ненадежным каналом. И вот у нас остается единственный фактор верификации - подделываемое имя отправителя. Раньше еще можно было полагаться на аккаунт разработчика, но сейчас - то Зухра, то индус, то еще кто. Добавим сюда еще спешку как очень негативный фактор для принятия решений (ведь не зря все мошенники упор делают на срочность). Вот и получаем крайне низкую безопасность.
Насколько я слышал, в США в ИЖС практикуются специальные противоштормовые крепления крыши. Которые представляют из себя толстенный трос, одним концом цепляющийся за крышу, проходящий через отверстие в стене и вторым концом цепляющийся за фундамент - и вся эта система находится в преднатяженном состоянии.
Ага, приложения банков от левых разработчиков, неизвестно кому принадлежащий корневой сертификат с 30-летним правом на все, протухшие "валидные" сертификаты и карты с неизвестным сроком действия. Прям чувствуется, что безопасность все повышается с каждым шагом. /s
Не хватает у эпла автоматизации пока что. Им стоило бы подписаться на уведомления от сбера о выходе новых версий, тогда после ручной проверки можно через час после выхода блокировать. В принципе быстрее, чем кто-то из пользователей среагирует.
Я не очень понимаю, почему даже 45? Какой толк от сбора, если на его администрирование уходит почти половина суммы? Деятельность ради деятельности.
Это даже выше, чем берут площадки маркетплейсы - а в них входит и поддержание площадки для десятков миллионов клиентов, и реклама, и логистика/доставка. А эти ребята будто новый маркетплейс открыли, только его не существует - для обслуживания их деятельности достаточно программы, написанной на коленке одним человеком.
Тут еще отдельный вопрос - а кто оценивает стоимость одной лицензии? Заинтересованная в завышении сторона - окуп?
Не той лицензии. Вы пишете о нарушении лицензии бандла SQL - это дешевый вариант лицензии, но привязанный к использованию только платформой 1с.
Но нарушается лицензия на саму 1с:
п.4 Лицензиат обязуется ... не совершать и не допускать совершения третьими лицами ... вносить какие-либо изменения в содержимое баз данных ... за исключением тех изменений, которые вносятся штатными средствами (1с) ... и описанными в сопроводительной документации (1с).
---
Простыми словами - любое изменение данных в обход платформы 1с - это нарушение лицензии.
Я и не предлагаю перенос в пустую базу.
1) добавляете план обмена в основную базу на все документы (один узел = одной новой базе, как-то там деля по организациям между ними)
2) Создаете 2 "разделенные базы" копиями с основной.
3) Удаляете в них ненужные части (длительная операция, без прямого доступа к СУБД)
4) Делаете предварительную сверку (данные должны быть актуальными на момент создания копии)
5) Доставляете накопившееся в плане обмена до разделенных баз
6) Допроверяете перенесенное (ориентировочно за 14 дней доки тут будут)
7) Переводите пользователей на разделенные базы
---
С 5 по 7 пункты накрываем блокировкой входа пользователей во все базы - это и будет даунтайм. Если хочется его сократить, то можно сделать эти пункты в 2 итерации: в первую итерацию без блокировки входа перенести за 14 дней и допроверить их, а потом с блокировкой еще накопившийся за это время кусок (врятли он будет больше 2х дней).
Что мешало создать 2 новые "разделенные" базы заранее, не останавливая деятельность основной и доставлять туда новые появляющиеся документы? Могли бы и за час тогда перейти.
Ваш путь с прямым удалением в SQL:
во-первых, нарушает лицензию 1с у клиента. Сейчас за таким никто не гоняется, но в любой момент могут начать. Донесли ли вы до клиента, что если этот кейс получит юридические претензии, то клиенту потом заново лицензии покупать? Плюс условный миллион рублей на затраты
во-вторых, крайне сложно проверить целостность данных. Тестирование и исправление - не панацея. А последствия этого метода вполне могут выявится не сразу при приемке, а спустя время, чем сильно все осложнить.