Имхо такого отношения крайне мало осталось, даже на забугорном рынке. Вот сидишь перед коллегией интервьюеров: эйчар, начдеп, CTO и твой агент. Все дружно тебя собеседуют в два смычка. И в итоге успешно все проходишь, всем вроде нравится, но когда видишь своего нового тимлида, то сходу понимаешь что совершенно не можешь с ним сработаться. Отсюда вывод: собеседуют и нанимают совершенно не те люди с которыми будешь работать бок о бок. Поэтому им вся эта ваша технологическая романтика и "разговоры за жизнь" не нужны совершенно.
В суд кто пришел Банк или клиент? Понятно что клиент, раз Банку это ни к чему. Еще раз: кто пришел - тот и доказывает. А ругань до суда когда данные биометрии уже уплыли это сотрясание воздуха и ничего более.
Предоставив факт явного волеизъявления об отказе. Например из самого простого это скриншот чата переписки с поддержкой, в котором сотрудник Банка ответил, что отказ от биометрии зарегистрирован. Или по-классике железобетонное: 2 заказных письма одно в Банк с уведомлением, другое себе.
Бремя доказательства лежит на оспаривающей стороне. Банку это и не надо, он выполняет свои обязательства и предоставляет свои услуги в полном объеме и так. Поэтому если клиент не согласен и если дело дойдет до суда, то это клиенту надо будет доказывать, что он не соглашался на биометрию, а не Банку.
Видимо они выжидали и наблюдали схавает ли крупняк такую наглость от Unity. Судя по всему схавали. Поэтому и они решили, что они не хуже и тоже смогут доить рынок.
Поддерживаю. Сергей Немчинский тоже подобную историю на стримах рассказывал, когда работал на галере и ему надо было исправить хитрый баг в индусском коде. Он искал одну строчку (или даже один символ) почти месяц. Нашел и исправил.
Если принята практика после аппрува MR все коммиты его составляющие сжимать в один и только потом мержить, то статистика в таком случае будет одинаковая.
Нет законной обязанности гражданину иметь номер телефона, а уж тем более смартфон. И никто не в праве с него это требовать. Но про это все дружно забывают когда пишут очередные сервисы-поделки. Любой поставщик услуг работающий с физиками обязан по закону иметь оффлайн кассу для приема оплаты наличными, в данном случае работающий паркомат с купюроприемником.
Как вам выше справедливо заметили без подробностей настроек БД смысла говорить о результатах мало. На таких малых объемах и с такими малыми длинами записей и тривиальными индексами во взрослых RDBMS вся ваша БД будет держаться в памяти, а не на диске. А подчас даже данные вероятно будут лежат в самом индексе, а не в таблицах. И вы своими тестами скорее будете измерять скорость доступа к RAM и производительность CPU, нежели эффективность механизмов самой БД. Чтобы проводить подобные осмысленные тесты, надо сначала почитать как организовано хранение данных в той или иной БД. Потом почитать как организован поиск этих данных. Потом возможно взглянуть какие оптимизации используются для чтения\записи. И уже с учетом этих знаний пытаться что-то измерять на данных приближенных к боевым с боевыми запросами, а не на синтетически сгенерированных на коленке с тривиальными запросами.
Потому, что с 1 сентября 2022 вступили в силу поправки к закону о рекламе, которые обязывают всех участников рекламного рынка исполнять новые требования. Другое дело почему участник статьи только сейчас в 2023 озаботился этим.
И еще, в новости от Консультанта есть оговорка: "Отметим, что не нужно передавать информацию о рекламе своих товаров, которую рассылают по электронной почте или в виде сообщений для групп пользователей". Обоснование этой оговорки естественно скрыто за pay-wall.
Ряд проектов онлайн школ (не айтишной тематики) которые я видел (знакомые просили распарсить и слить видео-курсы для личного архива), не отличаются оригинальностью и в целом сильно похожи. Думаю после 5 сданных проектов можно хорошо набить руку и далее клепать их безо всяких ТЗ, лишь корректируя очередные хотелки заказчика.
ЗЫ: интеграция платежки всегда боль, если для нее нет хорошей либы-обертки
то что исполнитель не справился не рассматривается ?
Странно звучит, учитывая выше ваши громкие заявления:
Каждый член команды важен, никто не передает недоделанную или сделанную плохо работу дальше по цепочке. Все без исключения понимают, какие задачи бизнеса они выполняют своей работой
Такие заявления подразумевают найм исполнителей уровня сильно выше среднего, чтобы обладать навыками аналитика, менеджера и разработчика\дизайнера в одном лице. В таком случае исполнитель может не справиться с задачей в срок только если ему не дали исчерпывающей информации или она была некорректная (не берем в расчет факторы самого исполнителя: заболел\забухал\запрокрастинировал, для high-grade спецов такое недопустимо). А раз такое случается, то это явный косяк управления. Либо же вы лукавите и нанимаете зеленых юнцов с горящими глазами, но малым опытом, которые не могут на лету придумывать реализацию лишь по одной бизнес-хотелке в силу отсутствия опыта в таких задачах.
Ваш кликбейтный заголовок работает лишь для очень ограниченного скоупа работ, в ограниченном домене бизнеса и с очень крутой командой. Без этого проекты будут обречены на провал. К примеру я работаю на бэке в "кровавом энтерпрайзе" и у нас без ТЗ результат не то что не ХЗ, а его вообще не может быть. У нас заинтересованных (и не очень) сторон владельцев систем, которых затрагивает очередная модификация нашей системы может быть цать штук. И со всеми надо договориться, согласовать документы и сроки. У вас ТЗ составляет до 25% от объема проекта, а у нас вся первичная документация до 50% всех трудозатрат проекта, реализация лишь порядка 20%, тестирование еще 20%, остальное это нецелевые потери ТДЗ. У вас можно без ТЗ придумать и реализовать на ходу новый бизнес-процесс по продаже товара из корзины, выбору нового партнера доставки, проведению чекаута и его финальной оплаты через новую платежку. Оформление страниц, шрифты, цвета и надписи кнопок не столь важны. Потому как вам известен финальный пункт - проведение платежа и известны промежуточные этапы. У нас же в рамках одной интеграции с партнером может быть один-пять-цать бизнес-процессов. И часто бывает что бизнес-процессы похожи в коде, но различаются по сути. К примеру есть два разных канала приема сообщений от партнера, два бизнес-процесса помимо многих прочих, но внутри нашей системы они выглядят в коде одинаково, одинаково обрабатываются и складываются в одну и ту же таблицу БД. И надо добавить функционал: при ответе партнеру на его сообщение, добавлять еще и вложения скачанные из двух разных смежных систем в зависимости от канал приема (сканы подписанных бух доков). И ответ надо отправлять через тот же канал, откуда пришел изначальный запрос. Вопрос в какой бизнес процесс это добавлять если в коде он един? И на каком этапе обработки? Без ТЗ все это выяснить читая лишь один код крайне затруднительно (а подчас невозможно). И это лишь самое простое, а в нашей области такое сплошь и рядом. Это результат n-лет эволюции функционала систем, понятно что с нуля так никто писать не будет. И когда мне приходит очередная задача на разработку в бизнес-процессе который я ранее не знал, я ищу все ТЗ в нашей knowledge-base касающиеся сабжа и читаю описания что, куда и зачем. Только так можно понять и реализовать то, что требуется. Да у нас тоже бывают факапы, когда приходится работать на выходных. Но это исключительная ситуация, случается 1<= в год и полностью оплачивается т.к. руководство понимает, что это их прокол. Ситуаций когда разработчик "не успел" и вынужден работать на выходных за свой счет не должно быть и в хороших фирмах не практикуется.
Подобная реклама идей no-code всплывает каждые пару-тройку лет. И каждый раз в конце одно и тоже - оно в итоге никому не нужно. Как показала практика в серьезных задачах такой подход неприменим. А как показывает история даже в простых задачах такие идеи не приживаются. Еще в лохматые времена, когда SQL изобретался как язык близкий к естественному, для аналитиков и менеджеров, чтобы заменить программистов как no-code решение, чтобы они сами себе могли выбирать данные из БД и строить требуемые отчеты. Но системы росли, данных становилось все больше, а человек ленив по своей натуре. Поэтому даже SQL пришлось в итоге писать самим программистам и отдавать уже готовые отчетики менеджерам и аналитикам. Вспомним с чего начинался html. Потом портянки кода стали очень длинными и их стали заменять скриптами. Скрипты стали писать и обслуживать программисты. Потом скрипты усложнились и их автоматизировали в различные конструкторы, движки и crm системы, так же рекламируя no-code подход при работе с ними. А потом и они усложнились и теперь для их использования снова нанимают программистов. Wordpress-программист: такую специальность слышали?
Все эти розовые пони с ноу-код решениями не работают в перспективе далее прототипов. Как только система наполняется данными или чуть усложняется, всегда приглашают программистов.
Это вы такой пример страны-победителя привели? Вы там сами-то бывали или только по слухам утверждаете? Я вот там был и могу с уверенностью сказать, что ни черта они там не обжили и не освоили. И ни в какой плюс они там не вышли. Там уныло, дорого и сплошные ограничения. И лично знаком с беженцами которые потеряли все что было нажито и осталось на турецкой стороне. Они тупо пришли и отжали все то, что было. Там даже не надо быть экспертом чтобы сравнить текущий уровень развития на стороне Кипра и то днище, когда въезжаешь на оккупированные территории. И это видно даже с учетом маленького Кипра, экономика которого всю дорогу дотационная и он на подсосе у ЕС, а Турция такая большая с мощной промышленностью, огромным товарооборотом и экспортной выручкой, но все равно не развивает сколько-нибудь заметно так легко отжатые территории.
Через прошедшие годы смотрим на эту задумку и видим, что как всегда интересную технологию стали абьюзить все кому не лень. Прикручивать в нее не только уведомления, кеши, но и распределенные вычисления на клиентах у пользователей без их ведома. Тысячи воркеров на клиентах грузят проц как не в себя и пользователи негодуют. А все почему? Потому, что гугл не озаботился дать механизмы управления этой штукой в руки самого пользователя, а оставил все на откуп эффективным совам из компаний, которые эти сервисы с воркерами и пилят. В итоге количество статей "как навсегда заблокировать регистрацию service workers в chrome" растет как на дрожжах. Ну и правильно, туда ей и дорога.
Корень проблемы тянется из идеи чтобы условно прежний дизайн сайтов из нулевых который был заточен под ПК сделать пригодным для телефонов и пальцев. Т.е. не разрабатывать два продукта и не поддерживать две кодовые базы, а как-то извернуться и обойтись одним продуктом. Отсюда и огромные контролы которые съедают полезное пространство. Сейчас мониторы и разрешения стали в разы больше, а места под полезный контент стало меньше. Как же так? А вот так - даже на ваших скринах сравните размер кнопки в панели меню chrome devtools и рядом контрол сайта "лайк" который в четыре раза больше. Для ПК это излишне, а на телефоне норм. Что бы было хорошо - надо делать хорошо и под конкретные условия. А пока что все клепают компромиссы под всевозможные интерфейсы. Получается хреновенько, подчас неудобно, но в целом работает. Так и живем.
Имхо такого отношения крайне мало осталось, даже на забугорном рынке. Вот сидишь перед коллегией интервьюеров: эйчар, начдеп, CTO и твой агент. Все дружно тебя собеседуют в два смычка. И в итоге успешно все проходишь, всем вроде нравится, но когда видишь своего нового тимлида, то сходу понимаешь что совершенно не можешь с ним сработаться. Отсюда вывод: собеседуют и нанимают совершенно не те люди с которыми будешь работать бок о бок. Поэтому им вся эта ваша технологическая романтика и "разговоры за жизнь" не нужны совершенно.
В суд кто пришел Банк или клиент? Понятно что клиент, раз Банку это ни к чему. Еще раз: кто пришел - тот и доказывает. А ругань до суда когда данные биометрии уже уплыли это сотрясание воздуха и ничего более.
Предоставив факт явного волеизъявления об отказе. Например из самого простого это скриншот чата переписки с поддержкой, в котором сотрудник Банка ответил, что отказ от биометрии зарегистрирован. Или по-классике железобетонное: 2 заказных письма одно в Банк с уведомлением, другое себе.
Бремя доказательства лежит на оспаривающей стороне. Банку это и не надо, он выполняет свои обязательства и предоставляет свои услуги в полном объеме и так. Поэтому если клиент не согласен и если дело дойдет до суда, то это клиенту надо будет доказывать, что он не соглашался на биометрию, а не Банку.
Видимо они выжидали и наблюдали схавает ли крупняк такую наглость от Unity. Судя по всему схавали. Поэтому и они решили, что они не хуже и тоже смогут доить рынок.
Поддерживаю. Сергей Немчинский тоже подобную историю на стримах рассказывал, когда работал на галере и ему надо было исправить хитрый баг в индусском коде. Он искал одну строчку (или даже один символ) почти месяц. Нашел и исправил.
Если принята практика после аппрува MR все коммиты его составляющие сжимать в один и только потом мержить, то статистика в таком случае будет одинаковая.
Нет законной обязанности гражданину иметь номер телефона, а уж тем более смартфон. И никто не в праве с него это требовать. Но про это все дружно забывают когда пишут очередные сервисы-поделки. Любой поставщик услуг работающий с физиками обязан по закону иметь оффлайн кассу для приема оплаты наличными, в данном случае работающий паркомат с купюроприемником.
Поэтому для критически важных вещей надо использовать on-premise решения и желательно с открытым кодом.
Как вам выше справедливо заметили без подробностей настроек БД смысла говорить о результатах мало. На таких малых объемах и с такими малыми длинами записей и тривиальными индексами во взрослых RDBMS вся ваша БД будет держаться в памяти, а не на диске. А подчас даже данные вероятно будут лежат в самом индексе, а не в таблицах. И вы своими тестами скорее будете измерять скорость доступа к RAM и производительность CPU, нежели эффективность механизмов самой БД. Чтобы проводить подобные осмысленные тесты, надо сначала почитать как организовано хранение данных в той или иной БД. Потом почитать как организован поиск этих данных. Потом возможно взглянуть какие оптимизации используются для чтения\записи. И уже с учетом этих знаний пытаться что-то измерять на данных приближенных к боевым с боевыми запросами, а не на синтетически сгенерированных на коленке с тривиальными запросами.
Потому, что с 1 сентября 2022 вступили в силу поправки к закону о рекламе, которые обязывают всех участников рекламного рынка исполнять новые требования. Другое дело почему участник статьи только сейчас в 2023 озаботился этим.
https://www.consultant.ru/legalnews/20117/
И еще, в новости от Консультанта есть оговорка: "Отметим, что не нужно передавать информацию о рекламе своих товаров, которую рассылают по электронной почте или в виде сообщений для групп пользователей". Обоснование этой оговорки естественно скрыто за pay-wall.
У меня тоже финтех. Подписываюсь под каждым словом. Все так.
Ряд проектов онлайн школ (не айтишной тематики) которые я видел (знакомые просили распарсить и слить видео-курсы для личного архива), не отличаются оригинальностью и в целом сильно похожи. Думаю после 5 сданных проектов можно хорошо набить руку и далее клепать их безо всяких ТЗ, лишь корректируя очередные хотелки заказчика.
ЗЫ: интеграция платежки всегда боль, если для нее нет хорошей либы-обертки
Странно звучит, учитывая выше ваши громкие заявления:
Такие заявления подразумевают найм исполнителей уровня сильно выше среднего, чтобы обладать навыками аналитика, менеджера и разработчика\дизайнера в одном лице. В таком случае исполнитель может не справиться с задачей в срок только если ему не дали исчерпывающей информации или она была некорректная (не берем в расчет факторы самого исполнителя: заболел\забухал\запрокрастинировал, для high-grade спецов такое недопустимо). А раз такое случается, то это явный косяк управления. Либо же вы лукавите и нанимаете зеленых юнцов с горящими глазами, но малым опытом, которые не могут на лету придумывать реализацию лишь по одной бизнес-хотелке в силу отсутствия опыта в таких задачах.
Ваш кликбейтный заголовок работает лишь для очень ограниченного скоупа работ, в ограниченном домене бизнеса и с очень крутой командой. Без этого проекты будут обречены на провал. К примеру я работаю на бэке в "кровавом энтерпрайзе" и у нас без ТЗ результат не то что не ХЗ, а его вообще не может быть. У нас заинтересованных (и не очень) сторон владельцев систем, которых затрагивает очередная модификация нашей системы может быть цать штук. И со всеми надо договориться, согласовать документы и сроки. У вас ТЗ составляет до 25% от объема проекта, а у нас вся первичная документация до 50% всех трудозатрат проекта, реализация лишь порядка 20%, тестирование еще 20%, остальное это нецелевые потери ТДЗ. У вас можно без ТЗ придумать и реализовать на ходу новый бизнес-процесс по продаже товара из корзины, выбору нового партнера доставки, проведению чекаута и его финальной оплаты через новую платежку. Оформление страниц, шрифты, цвета и надписи кнопок не столь важны. Потому как вам известен финальный пункт - проведение платежа и известны промежуточные этапы. У нас же в рамках одной интеграции с партнером может быть один-пять-цать бизнес-процессов. И часто бывает что бизнес-процессы похожи в коде, но различаются по сути. К примеру есть два разных канала приема сообщений от партнера, два бизнес-процесса помимо многих прочих, но внутри нашей системы они выглядят в коде одинаково, одинаково обрабатываются и складываются в одну и ту же таблицу БД. И надо добавить функционал: при ответе партнеру на его сообщение, добавлять еще и вложения скачанные из двух разных смежных систем в зависимости от канал приема (сканы подписанных бух доков). И ответ надо отправлять через тот же канал, откуда пришел изначальный запрос. Вопрос в какой бизнес процесс это добавлять если в коде он един? И на каком этапе обработки? Без ТЗ все это выяснить читая лишь один код крайне затруднительно (а подчас невозможно). И это лишь самое простое, а в нашей области такое сплошь и рядом. Это результат n-лет эволюции функционала систем, понятно что с нуля так никто писать не будет. И когда мне приходит очередная задача на разработку в бизнес-процессе который я ранее не знал, я ищу все ТЗ в нашей knowledge-base касающиеся сабжа и читаю описания что, куда и зачем. Только так можно понять и реализовать то, что требуется. Да у нас тоже бывают факапы, когда приходится работать на выходных. Но это исключительная ситуация, случается 1<= в год и полностью оплачивается т.к. руководство понимает, что это их прокол. Ситуаций когда разработчик "не успел" и вынужден работать на выходных за свой счет не должно быть и в хороших фирмах не практикуется.
Подобная реклама идей no-code всплывает каждые пару-тройку лет. И каждый раз в конце одно и тоже - оно в итоге никому не нужно. Как показала практика в серьезных задачах такой подход неприменим. А как показывает история даже в простых задачах такие идеи не приживаются. Еще в лохматые времена, когда SQL изобретался как язык близкий к естественному, для аналитиков и менеджеров, чтобы заменить программистов как no-code решение, чтобы они сами себе могли выбирать данные из БД и строить требуемые отчеты. Но системы росли, данных становилось все больше, а человек ленив по своей натуре. Поэтому даже SQL пришлось в итоге писать самим программистам и отдавать уже готовые отчетики менеджерам и аналитикам. Вспомним с чего начинался html. Потом портянки кода стали очень длинными и их стали заменять скриптами. Скрипты стали писать и обслуживать программисты. Потом скрипты усложнились и их автоматизировали в различные конструкторы, движки и crm системы, так же рекламируя no-code подход при работе с ними. А потом и они усложнились и теперь для их использования снова нанимают программистов. Wordpress-программист: такую специальность слышали?
Все эти розовые пони с ноу-код решениями не работают в перспективе далее прототипов. Как только система наполняется данными или чуть усложняется, всегда приглашают программистов.
Это вы такой пример страны-победителя привели? Вы там сами-то бывали или только по слухам утверждаете? Я вот там был и могу с уверенностью сказать, что ни черта они там не обжили и не освоили. И ни в какой плюс они там не вышли. Там уныло, дорого и сплошные ограничения. И лично знаком с беженцами которые потеряли все что было нажито и осталось на турецкой стороне. Они тупо пришли и отжали все то, что было. Там даже не надо быть экспертом чтобы сравнить текущий уровень развития на стороне Кипра и то днище, когда въезжаешь на оккупированные территории. И это видно даже с учетом маленького Кипра, экономика которого всю дорогу дотационная и он на подсосе у ЕС, а Турция такая большая с мощной промышленностью, огромным товарооборотом и экспортной выручкой, но все равно не развивает сколько-нибудь заметно так легко отжатые территории.
Журналистское косноязычие. Во всем мире это обычно называется software shipment\delivery или по-русски поставка ПО.
Через прошедшие годы смотрим на эту задумку и видим, что как всегда интересную технологию стали абьюзить все кому не лень. Прикручивать в нее не только уведомления, кеши, но и распределенные вычисления на клиентах у пользователей без их ведома. Тысячи воркеров на клиентах грузят проц как не в себя и пользователи негодуют. А все почему? Потому, что гугл не озаботился дать механизмы управления этой штукой в руки самого пользователя, а оставил все на откуп эффективным совам из компаний, которые эти сервисы с воркерами и пилят. В итоге количество статей "как навсегда заблокировать регистрацию service workers в chrome" растет как на дрожжах. Ну и правильно, туда ей и дорога.
Корень проблемы тянется из идеи чтобы условно прежний дизайн сайтов из нулевых который был заточен под ПК сделать пригодным для телефонов и пальцев. Т.е. не разрабатывать два продукта и не поддерживать две кодовые базы, а как-то извернуться и обойтись одним продуктом. Отсюда и огромные контролы которые съедают полезное пространство. Сейчас мониторы и разрешения стали в разы больше, а места под полезный контент стало меньше. Как же так? А вот так - даже на ваших скринах сравните размер кнопки в панели меню chrome devtools и рядом контрол сайта "лайк" который в четыре раза больше. Для ПК это излишне, а на телефоне норм. Что бы было хорошо - надо делать хорошо и под конкретные условия. А пока что все клепают компромиссы под всевозможные интерфейсы. Получается хреновенько, подчас неудобно, но в целом работает. Так и живем.
Ога, а еще просыпаться пораньше, что б подольше ни черта не делать)