Mobx это умный стор для тупых клиентов. Redux-like предлагают наоборот - примитивный стор для умных.
Пока логики немного, первый вариант выигрывает. Но развивая подход, вся сложность оказывается сконцентрированной в одном месте и оно становится узким. Дирежировать квартетом и дирежировать оркестром из 1000 инструментов это принципиально разные по сложности задачи.
У вторых сложность распределяется по клиентам и подход лучше масштабируется. Единственное, в разработке требуется дисциплина (лучше что-нибудь из области математики), иначе вся эта хореография быстро превратится в хаос. Effector предоставляет неплохой набор инструментов для такой композиции.
const entry = createEvent<number>()
const a = createStore(0).on(entry, (state, v) => v)
const b = a.map((a) => a + 1)
const c = a.map((a) => a + 1)
const d = combine(b, c, (b, c) => b + c)
const e = d.map((d) => d + 1)
const f = combine(d, e, (d, e) => d + e)
const g = combine(d, e, (d, e) => d + e)
const h = combine(f, g, (h1, h2) => h1 + h2)
mol
const entry = new $mol_wire_atom('entry', (next: number = 0) => next)
const a = new $mol_wire_atom('mA', () => entry.sync())
const b = new $mol_wire_atom('mB', () => a.sync() + 1)
const c = new $mol_wire_atom('mC', () => a.sync() + 1)
const d = new $mol_wire_atom('mD', () => b.sync() + c.sync())
const e = new $mol_wire_atom('mE', () => d.sync() + 1)
const f = new $mol_wire_atom('mF', () => d.sync() + e.sync())
const g = new $mol_wire_atom('mG', () => d.sync() + e.sync())
const h = new $mol_wire_atom('mH', () => f.sync() + g.sync())
Чисто эстетически первое выглядит лучше - сразу вспомнился курс теорката. Второе больше напоминает какой-то ассемблер.
придти на PBR с чек-листом обеспечения качества... нужно ли что-то специфическое по безопасности
Чек-лист качества это мечта уровня философского камня, который будет превращать в золото все что угодно. Но если верить Гёделю, то будучи формальной системой, он окажется либо не полным, либо противоречивым. Со всеми вытекающими последствиями.
Давайте про безопасность. Как на практике. Желание приблизиться к полноте в таком важном вопросе, как безопасность, привела к появлению целого семейства стандартов - на разработку ISO/IEC 27000, и 15408 - на проверку. Крайне популярное и увлекательное чтиво в последнее время, покрывающее вопросы уровня огранизации, людей, физической безопасности и технологий - суммарно около 100 тем из разных областей. Вот пример классического чек-листа, затрагивающего лишь несколько из них https://github.com/RedHatInsights/secure-coding-checklist. Т е. если подходить к делу ответственно, то получить начальные сертификаты займет несколько месяцев, а внедрить и научиться осмысленно применять - миллионыгоды.
SAST, DAST, MPT, SCA, RE, PTasS, BAS, MAST - просто перечислить акронимы разного вида тестирования, необходимых, чтобы претендовать на соответствие стандартным требованиям - уже целое предложение.
Вы все ещё уверены, что тестировщики в скором времени останутся без работы? Мне кажется у для них с каждым годом работы только прибавляется.
В иксах уже много лет живёт настройка Xft.dpi и xrandr. Но поддержка тщательно поломана на уровне тулкитов и отдельных приложений https://wiki.archlinux.org/title/HiDPI .
Вы подняли интересную тем, но пока это выглядит как субъективое мнение и не понятно как оно привязано к практике. Тут здорово бы смотрелись примеры реальных ситуаций - какие тактики из области QA использовали тестировщики и как это сказалось на проекте и их личной карьере.
Покончите с зависимостью от контроля качества. Устраните потребность в массовых проверках, прежде всего встраивая качество в продукцию. Качество создается не в результате проверки, а благодаря улучшению производственного процесса.
Не бывает управления без изменения. Тестировщики как раз и выполняют такую функцию. Это основа и она ни куда не денется.
Согласно принципу Эшби, управляющая система должна иметь такое же или большее разнообразие как управляемая. Это значит, что на каждый вариант нежелательного отклонения, со стороны управления должно быть заготовлено соответствующее компенсирующее воздействие.
В самом деле, чем выше надёжность системы, тем меньше разных вариантов нештатных ситуаций и тем проще ей управлять. Но сложность, обусловленная разнообразием возможных проблем, ни куда не девается - она просто переходит в процессы управления качеством.
Как следствие, если QC достаточно уметь измерять результат, то QA должен детально разбираться в процессе, причинах возникновения отклонений и способах их компенсации. По сути такой персонаж должен обладать экспертизой уровня всей команды: разработчиков, менеджеров, архитекторов и всех остальных вместе взятых - чьи действия в своей области могут приводить к дефектам. А иначе, не обладая достаточными компетенциями, он сам станет причиной неверных решений и ошибок. Как вариант, он может решить абстрагироваться от сложных деталей, но тогда его функция становится чисто бюрократической, в роде коучинга.
А вывод такой, что управление качестом разумнее встраивать в существующую иерархию управления (начиная с самых низов - разработчиков, их менеджеров, менеджеров менеджеров и т.п.), а не городить параллельную ей структуру из отдельных QA. Функция контроля QC остаётся в любом случае востребованой на любом уровне.
Порядок в вещах уменьшает количество энергии, затрачиваемое на поиск свободного для них места и самих вещей в этом самом месте. Иначе, когда в квартире живёт несколько человек, "не поймешь, что где валяется, и когда все это кончится".
Тема конечно философская. Читабельность это не только про возможность специалисту разобраться как работает код. В идеале, глядя на код вы должны понимать исходную постановку задачи - что он должен делать. Одно из следствий - такой код проще поддерживать (не требуется отдельно писать документацию) и расширять (требования обычно меняются в тех же терминах, что и исходная постановка, значит код проще дорабатывать и верифицировать когда он написан в тех же терминах и общей логике).
если число делится нацело на 3, то вместо самого числа нужно вывести строку fizz, если же число делится нацело на 5, то нужно вывести строку buzz. Ну а если число делится нацело и на 3, и на 5, то на экран нужно вывести fizzbuzz
Здесь задача поставлена императивно. Поэтому реализация в виде кальки с if-else будет, на мой взгляд, наилучшей. Решение на итераторах элегантно остроумно. Но по сути это запись решения некоей эквивалентной задачи, поэтому оно довольно хрупкое. Глядя на код декомпилировать исходную постановку уже проблематично. Добавление новых условий в задачу сделает его или ещё более не эффективным или вообще заставит переписать целиком. Поэтому я сомневаюсь относительно читабельности.
Интересно, кто в вашем представлении занимается проектированием топологии сетей, настраивает шифрование данных и ротацию ключей, контролирует их потоки внутри периметров и наружу, проводит аудит и верификацию, тестирует безопасность, собирает метрики, конфигурирует дашборды и алерты. Неужели топы с аналитиками и юристами? Или девопсы и QA которые думают, что могут в этом ни чего не понимать, рассчитывая, что за них все придумают и сделают волшебные эльфы?
Ну вот эти эльфы, работающие головой, как раз и есть тот вид айтишников с нормальным образованием и нормальными деньгами. Для неквалифицированного персонала работы руками тоже хватает, но надо четко понимать свою ценность и соизмерять амбиции.
Айти даёт возможность расти, но для этого нужно реально много вкалывать своей головой, а не перекладывать на чужую. Это бизнес простых чисел: вы либо единица, либо ноль.
Хабр уже давно новостная площадка с корпоративными блогами, а не курилка для междусобочиков у инженеров. Новостные ресурсы не формируют повестку, они ее освещают и поддерживают, подчиняясь общим правилам. Кто не подчиняется получает бан в карму, но уже со стороны властей, спонсоров или рекламодателей. Принцип выжившего как есть, а выживает каждый как умеет.
Вы же понимаете, что в этом смысле, ценность профессиональных комментариев на хабре про Vue, многократно ниже рисков, которые получает площадка из-за высказываний, противоречащих текущей социально одобряемой доктрине в ключевых локациях ее аудитории и рекламодателей.
Вы правильно сделали, что попытались вступиться за пользователя. Но для решения по существу, требуется смена контекста снаружи (ну или машина времени, чтобы вернуться назад лет на 25, когда в эхах Фидо или раннем linux.org.ru можно было трындеть обо всем техническом и не очень, без оглядки на авторитетов, церемонии, темы и лексику).
Насколько я понимаю ваша задача научиться писать парсеры для HCL самому, и путь в ней важнее цели. Этим интересен ваш цикл статей, показывающий разработку от простого к сложному, с разбором различных альтернатив решений.
Так-то все эти синтаксические конструкции: блоки, переменные, циклы - в терраформе, который является идейным вдохновителем этого направления в индустрии, реализованы, а для создания ишью в джире есть готовый провайдер https://github.com/fourplusone/terraform-provider-jira .
Айти стало больше регулироваться со стороны законодательства. Уже недостаточно просто скопировать условный код со стак оверфлоу. Нужно соблюсти кучу церемоний - проверить на безопасность, соблюсти чистоту лицензий и т.п. Нельзя просто взять фотку из интернета и сохранить на диск - вы можете попасть на пару миллионов из-за очередного GDPR.
Так что разработка для бизнеса становится все рискованнее, и от айтишников будут требоваться не только знания алгоритмов, паттернов, но и кучи чисто юридических моментов.
Это ещё больше увеличит порог входа, как в прошлом веке стало, например, со врачами. Соответственно поднимутся и рейты. Ну а вайтишники после курсов окажутся на правах санитаров, где в материальном плане ловить действительно особо не чего.
А знаете ли вы ещё какие-нибудь интересные примеры итераторов и итерируемых объектов в стандартной библиотеке Python?
Обильное использование итераторов в коде, создаёт последующим поколениям разработчиков, кто будет заниматься сопровождением, множество не только увлекательных, но и не тривиальных задач. Как раз таких, про которые мы часто пишем в своих резюме.
В отличие от хаскелей, где декларативный код хорошо оптимизируется, итераторы в питоне создают овехед из-за необходимости вызвать дополнительные методы. Накладные расходы для передачи значения внутри длинных цепочек вложенных итераторов может оказаться больше, чем само вычисление.
Переписывание кода на традиционные циклы, зачастую не только возвращает вам понятные стектрейсы в случае ошибок, возможность отладки в дебагере по шагам, но и делает его быстрее.
В статье писали, что BPMN может применяться для генерации кода, где такая семантическая неоднозначность может быть проблемой. Интересно отчем думали дизайнеры нотации, предлагая такой вариант.
Я привык, что ИЛИ это бинарный оператор: два значения на входе, одно на выходе. Это легко обобщается до любого другого количества значений на входе больше двух, но на выходе все равно - одно.
В примере "Процесс утреннего пробуждения" ромбик справа вполне соответствует привычному определению.
Но у ромбика слева один вход и два выхода, а обозначение точно такое же. Тут нет ошибки, может здесь нужно использовать другой стмвол? Буду признателен за пруф, желательно ссылкой на описание в спецификации BPMN.
Mobx это умный стор для тупых клиентов. Redux-like предлагают наоборот - примитивный стор для умных.
Пока логики немного, первый вариант выигрывает. Но развивая подход, вся сложность оказывается сконцентрированной в одном месте и оно становится узким. Дирежировать квартетом и дирежировать оркестром из 1000 инструментов это принципиально разные по сложности задачи.
У вторых сложность распределяется по клиентам и подход лучше масштабируется. Единственное, в разработке требуется дисциплина (лучше что-нибудь из области математики), иначе вся эта хореография быстро превратится в хаос. Effector предоставляет неплохой набор инструментов для такой композиции.
Смотрю в код тестов по вашей ссылке
Effector
mol
Чисто эстетически первое выглядит лучше - сразу вспомнился курс теорката. Второе больше напоминает какой-то ассемблер.
Дети заказали статью для продвижения своего стартапа, на котором уже подняли $33 мульта. А сюда зачем-то ее перевели.
Чек-лист качества это мечта уровня философского камня, который будет превращать в золото все что угодно. Но если верить Гёделю, то будучи формальной системой, он окажется либо не полным, либо противоречивым. Со всеми вытекающими последствиями.
Давайте про безопасность. Как на практике. Желание приблизиться к полноте в таком важном вопросе, как безопасность, привела к появлению целого семейства стандартов - на разработку ISO/IEC 27000, и 15408 - на проверку. Крайне популярное и увлекательное чтиво в последнее время, покрывающее вопросы уровня огранизации, людей, физической безопасности и технологий - суммарно около 100 тем из разных областей. Вот пример классического чек-листа, затрагивающего лишь несколько из них https://github.com/RedHatInsights/secure-coding-checklist. Т е. если подходить к делу ответственно, то получить начальные сертификаты займет несколько месяцев, а внедрить и научиться осмысленно применять -
миллионыгоды.SAST, DAST, MPT, SCA, RE, PTasS, BAS, MAST - просто перечислить акронимы разного вида тестирования, необходимых, чтобы претендовать на соответствие стандартным требованиям - уже целое предложение.
Вы все ещё уверены, что тестировщики в скором времени останутся без работы? Мне кажется у для них с каждым годом работы только прибавляется.
В иксах уже много лет живёт настройка Xft.dpi и xrandr. Но поддержка тщательно поломана на уровне тулкитов и отдельных приложений https://wiki.archlinux.org/title/HiDPI .
Вы подняли интересную тем, но пока это выглядит как субъективое мнение и не понятно как оно привязано к практике. Тут здорово бы смотрелись примеры реальных ситуаций - какие тактики из области QA использовали тестировщики и как это сказалось на проекте и их личной карьере.
Не бывает управления без изменения. Тестировщики как раз и выполняют такую функцию. Это основа и она ни куда не денется.
Согласно принципу Эшби, управляющая система должна иметь такое же или большее разнообразие как управляемая. Это значит, что на каждый вариант нежелательного отклонения, со стороны управления должно быть заготовлено соответствующее компенсирующее воздействие.
В самом деле, чем выше надёжность системы, тем меньше разных вариантов нештатных ситуаций и тем проще ей управлять. Но сложность, обусловленная разнообразием возможных проблем, ни куда не девается - она просто переходит в процессы управления качеством.
Как следствие, если QC достаточно уметь измерять результат, то QA должен детально разбираться в процессе, причинах возникновения отклонений и способах их компенсации. По сути такой персонаж должен обладать экспертизой уровня всей команды: разработчиков, менеджеров, архитекторов и всех остальных вместе взятых - чьи действия в своей области могут приводить к дефектам. А иначе, не обладая достаточными компетенциями, он сам станет причиной неверных решений и ошибок. Как вариант, он может решить абстрагироваться от сложных деталей, но тогда его функция становится чисто бюрократической, в роде коучинга.
А вывод такой, что управление качестом разумнее встраивать в существующую иерархию управления (начиная с самых низов - разработчиков, их менеджеров, менеджеров менеджеров и т.п.), а не городить параллельную ей структуру из отдельных QA. Функция контроля QC остаётся в любом случае востребованой на любом уровне.
У него есть аналог https://httpyac.github.io/ с двумя плагинами к vscode, поддержкой скриптинга и запуска тестов из командной строки.
В pub-sub паблишер и получатель не имеют ссылок друг на друга, коммуникация идёт чисто с помощью данных - сообщений.
В редаксе стор в этом месте знает всех своих подписчиков в лицо и сам же вызывает их на каждый свой чих. Т.е это observable в чистом виде.
Просто у паттерна название имхо не очень удачное, поскольку активная роль здесь у observable, который и дирижирует всем этим оркестром из observer'ов.
Порядок в вещах уменьшает количество энергии, затрачиваемое на поиск свободного для них места и самих вещей в этом самом месте. Иначе, когда в квартире живёт несколько человек, "не поймешь, что где валяется, и когда все это кончится".
Тема конечно философская. Читабельность это не только про возможность специалисту разобраться как работает код. В идеале, глядя на код вы должны понимать исходную постановку задачи - что он должен делать. Одно из следствий - такой код проще поддерживать (не требуется отдельно писать документацию) и расширять (требования обычно меняются в тех же терминах, что и исходная постановка, значит код проще дорабатывать и верифицировать когда он написан в тех же терминах и общей логике).
Здесь задача поставлена императивно. Поэтому реализация в виде кальки с if-else будет, на мой взгляд, наилучшей. Решение на итераторах
элегантноостроумно. Но по сути это запись решения некоей эквивалентной задачи, поэтому оно довольно хрупкое. Глядя на код декомпилировать исходную постановку уже проблематично. Добавление новых условий в задачу сделает его или ещё более не эффективным или вообще заставит переписать целиком. Поэтому я сомневаюсь относительно читабельности.Интересно, кто в вашем представлении занимается проектированием топологии сетей, настраивает шифрование данных и ротацию ключей, контролирует их потоки внутри периметров и наружу, проводит аудит и верификацию, тестирует безопасность, собирает метрики, конфигурирует дашборды и алерты. Неужели топы с аналитиками и юристами? Или девопсы и QA которые думают, что могут в этом ни чего не понимать, рассчитывая, что за них все придумают и сделают волшебные эльфы?
Ну вот эти эльфы, работающие головой, как раз и есть тот вид айтишников с нормальным образованием и нормальными деньгами. Для неквалифицированного персонала работы руками тоже хватает, но надо четко понимать свою ценность и соизмерять амбиции.
Айти даёт возможность расти, но для этого нужно реально много вкалывать своей головой, а не перекладывать на чужую. Это бизнес простых чисел: вы либо единица, либо ноль.
Читаемость это важное свойство. Не сочтите за критику, у вас классная статья с выразительными примерами.
Хабр уже давно новостная площадка с корпоративными блогами, а не курилка для междусобочиков у инженеров. Новостные ресурсы не формируют повестку, они ее освещают и поддерживают, подчиняясь общим правилам. Кто не подчиняется получает бан в карму, но уже со стороны властей, спонсоров или рекламодателей. Принцип выжившего как есть, а выживает каждый как умеет.
Вы же понимаете, что в этом смысле, ценность профессиональных комментариев на хабре про Vue, многократно ниже рисков, которые получает площадка из-за высказываний, противоречащих текущей социально одобряемой доктрине в ключевых локациях ее аудитории и рекламодателей.
Вы правильно сделали, что попытались вступиться за пользователя. Но для решения по существу, требуется смена контекста снаружи (ну или машина времени, чтобы вернуться назад лет на 25, когда в эхах Фидо или раннем linux.org.ru можно было трындеть обо всем техническом и не очень, без оглядки на авторитетов, церемонии, темы и лексику).
Насколько я понимаю ваша задача научиться писать парсеры для HCL самому, и путь в ней важнее цели. Этим интересен ваш цикл статей, показывающий разработку от простого к сложному, с разбором различных альтернатив решений.
Так-то все эти синтаксические конструкции: блоки, переменные, циклы - в терраформе, который является идейным вдохновителем этого направления в индустрии, реализованы, а для создания ишью в джире есть готовый провайдер https://github.com/fourplusone/terraform-provider-jira .
На какой вы стадии стадии, чтобы реализовать свой движок Terraform? :)
Айти стало больше регулироваться со стороны законодательства. Уже недостаточно просто скопировать условный код со стак оверфлоу. Нужно соблюсти кучу церемоний - проверить на безопасность, соблюсти чистоту лицензий и т.п. Нельзя просто взять фотку из интернета и сохранить на диск - вы можете попасть на пару миллионов из-за очередного GDPR.
Так что разработка для бизнеса становится все рискованнее, и от айтишников будут требоваться не только знания алгоритмов, паттернов, но и кучи чисто юридических моментов.
Это ещё больше увеличит порог входа, как в прошлом веке стало, например, со врачами. Соответственно поднимутся и рейты. Ну а вайтишники после курсов окажутся на правах санитаров, где в материальном плане ловить действительно особо не чего.
Обильное использование итераторов в коде, создаёт последующим поколениям разработчиков, кто будет заниматься сопровождением, множество не только увлекательных, но и не тривиальных задач. Как раз таких, про которые мы часто пишем в своих резюме.
В отличие от хаскелей, где декларативный код хорошо оптимизируется, итераторы в питоне создают овехед из-за необходимости вызвать дополнительные методы. Накладные расходы для передачи значения внутри длинных цепочек вложенных итераторов может оказаться больше, чем само вычисление.
Переписывание кода на традиционные циклы, зачастую не только возвращает вам понятные стектрейсы в случае ошибок, возможность отладки в дебагере по шагам, но и делает его быстрее.
В статье писали, что BPMN может применяться для генерации кода, где такая семантическая неоднозначность может быть проблемой. Интересно отчем думали дизайнеры нотации, предлагая такой вариант.
Я привык, что ИЛИ это бинарный оператор: два значения на входе, одно на выходе. Это легко обобщается до любого другого количества значений на входе больше двух, но на выходе все равно - одно.
В примере "Процесс утреннего пробуждения" ромбик справа вполне соответствует привычному определению.
Но у ромбика слева один вход и два выхода, а обозначение точно такое же. Тут нет ошибки, может здесь нужно использовать другой стмвол? Буду признателен за пруф, желательно ссылкой на описание в спецификации BPMN.