В статье рассматриваются способы формального построения тестов и задача минимизации их количества. Приводится пример применения классического метода построения минимального набора тестов и более простой способ — метод нейтрального элемента. Статья может быть интересна широкому кругу читателей из области информационных технологий, специалистам по тестированию.
Когда я был ещё джуном, мой менеджер иногда на наших еженедельных встречах тет-а-тет делился своим возмущением. Он указывал на проект, над которым работала другая команда, и говорил: «Я не верю, что этот проект достигнет какого-то успеха. Они решают не ту задачу». Я отвечал любопытством: «Но вы же старший, почему бы просто не пойти и не поговорить с ними?» Мне казалось странным, что при наличии возможности повлиять на ситуацию человек предпочитает молчать.
И ирония не обошла меня стороной. На прошлой неделе я сам поймал себя на том, что рассказываю новичку, почему соседней команде придётся кардинально менять свой проект, так как они изначально пошли не тем путём. И он справедливо задал мне тот же вопрос, что и я задавал многие годы назад: «А почему вы просто не поделитесь с ними своим мнением?» С тех пор эта ситуация засела в моей голове, так как я осознал, что за прошедшие годы моя позиция по этому вопросу изменилась.
Что мы поняли, запустив за 1 месяц простое приложение, которое обучает решению задач по математике в США. И как вышли на +$1200/месяц спустя 4 месяца после запуска.
В последнее время набирают популярность low-code и no-code платформы. В них для разработки приложений предлагается использовать визуальное программирование. При таком подходе, разработчики, в качестве которых выступают обычные бизнес-пользователи, вместо написания программного кода создают приложение при помощи мыши в графическом интерфейсе. Также визуальное программирование в некотором виде используется, например, в Конфигураторе 1С.
Однако, возникает вопрос. Какие преимущества дает визуальное программирование по сравнению с Domain Specific Language ? Безусловно это зависит области применения. С одной стороны, в классических языках визуальное программирование практически не используется. В то же время при разработке графического интерфейса такой подход конечно же имеет много преимуществ. Однако, при создании интерфейсов, например, с помощью популярной библиотеки React все-таки больше используется плоский код.
🚀 Новая статья: От Intel 086 до нейросетей: исповедь охотника за бизнес-процессами
Почему отличные идеи застревают на бумаге? Почему стратегии теряются в дороге от менеджера до программиста? Проблема не в людях - проблема в инструментах.
🧠 Когнитивная нагрузка - главный враг эффективности. Исследования показывают: наш мозг может удерживать всего 4±1 элемента одновременно. А что мы ему даём? BPMN-схемы с сотнями элементов, UML-диаграммы для разработчиков, текстовые ТЗ, которые никто не дочитывает. Это не управление знаниями - это интеллектуальный терроризм.
Я работал бизнес-аналитиком на крупном предприятии. Описывал бизнес-процессы, улучшал зарплатные схемы, связывал руководителей и программистов. И понял: стандартные инструменты не работают. Они создают "испорченный телефон" - идея искажается на каждом этапе.
Решение оказалось неожиданным - язык ДРАКОН. Созданный в СССР Владимиром Паронджановым, он учитывает особенности человеческого восприятия. Принципы симультанизации (увидеть всю картину сразу) и эргономики делают сложное простым.
В статье я делюсь личным опытом:
✅ Как одна схема ДРАКОН заменила месяцы работы программистов.
✅ Как коллективное обсуждение схемы выявило разногласия между руководителями.
✅ Как непрофессионал создавал CRM-систему визуально.
✅ Как ДРАКОН стал единой платформой вместо BPMN+UML.
ДРАКОН - не просто язык. Это способ мышления, делающий бизнес управляемым. Он устраняет фрагментацию знаний, сокращает время на разработку на 40-60%, повышает качество решений.
Привет, Хабр! Меня зовут Кирилл, и я технический директор в компании АйПиДжи (интегратор Битрикс24). Хочу рассказать, как размещать статичные приложения, которые не требуют баз данных и не содержат очередей, в Маркете Битрикс24. В этом способе сочетаются простота деплоя и внесения доработок и низкая цена хостинга.
В начале 2025 года Битрикс24 выпустил официальный UI Kit для разработчиков приложений для Маркета. Набор компонентов построен на базе фреймворка Nuxt, соответственно, это не просто набор раскрашенных кнопок, а скорее подход к созданию интерактивных одностраничных решений. Они могут иметь достаточно навороченную бизнес-логику и при этом работать на чистом фронтенде, обращаясь к REST API через JS SDK Битрикс24. Могу сказать, что таких приложений в Маркете Битрикс24 довольно много — и они пользуются популярностью у пользователей. Так что, если вы разрабатываете решения для Битрикс24 и пока не знакомы с Nuxt, рекомендую посмотреть в эту сторону.
Принципиально разработка приложения устроена следующим образом: вы пишете код своего приложения на локальном компьютере, тут же запускаете локальный Nuxt, чтобы он на ходу «собирал» из вашего кода итоговый код для браузера. А вот для продакшн-версии на хостинге надо будет размещать уже «собранный» (или, как его называют, client side rendered) JS/HTML, а не изначальный код — этот набор статичных файлов тоже предоставит вам Nuxt.
Но в предложенном мной способе даже это не потребуется. Вы сможете продолжать заниматься разработкой и отладкой приложения на локальном компьютере, отправлять протестированный код в GitHub, а хостинг будет забирать эти изменения, запускать пересборку и доставлять обновленное приложение пользователям.
В статье описан теоретический метод, позволяющий прояснить математические истоки алгоритмической макроконструкции силуэт.
На практике построение конструкции силуэт не представляет трудности и делается несколькими щелчками мыши. Но речь не об этом. Мы пойдем неочевидным путем и построим силуэт в два этапа. Сначала создадим графическую заготовку классическим методом Ашкрофта-Манны. Затем с помощью специального приема преобразуем заготовку в силуэт.
Этой мини-серией статей я хочу объединить свои заметки для математического кружка о различных необычных, но полезных числовых системах, основанных на парах чисел. План знакомства с числовыми системами будет такой:
1. В этой статье мы (признаюсь, достаточно занудно) построим из натуральных чисел целые, при этом познакомимся с важнейшими инструментами математики: упорядоченной парой, эквивалентностью и факторизацией.
2. Во второй части от целых мы перейдём к рациональным числам, которые тоже можно представить в виде пары — рациональной дроби. Главный вопрос на который мы постараемся ответить: «А чего у дробей всё так сложно-то?»
3. В третьей части мы сконструируем Гауссовы числа и порассуждаем над более общим вопросом: «Что такое число?». В этой части мы перейдём от пар к матричным представлениям чисел, что позволит нам ввести их классификацию.
4. Четвёртая часть будет посвящена эллиптическим арифметикам: комплексным числам и числам Эйзенштейна. Здесь мы порассуждаем над сакраментальным вопросом: «Реальная ли мнимая единица?»
5. В пятой части мы рассмотрим гиперболические арифметики и познакомимся с двойными числами, и немного используем их на практике, чтобы понять «Как работает формула Бине?»
6. Шестая часть завершит эту серию. Она расскажет о параболических арифметиках, в частности, о дуальных числах, которые позволят арифметике быть неточной. Кроме того, мы порассуждаем о том как вписать в нашу классификацию рациональные дроби.
Впрочем, поскольку материал рассчитан на старшеклассников или младшекурсников, изложение будет неспешным и основательным. В духе туториала или методического пособия.
Привет! Мы — партнеры Битрикс24 и создаем для бизнеса приложения с генеративным ИИ, интегрируя их с корпоративными порталами.
В этой статье мы расскажем о созданном нами решении, которое позволяет любым разработчикам легко подключать свои чаты и другие приложения с LLM-моделями к Битрикс24. Речь идет о MCP-сервере — помощнике для ИИ, который позволяет получать из портала Битрикс24, например из раздела CRM, точные данные для ответа пользователю.
Как проверить идеи, архитектуру и алгоритмы без написания кода? Как сформулировать и проверить их свойства? Что такое model-checkers и model-finders? Требования и спецификации — пережиток прошлого?
Привет. Меня зовут Васил Дядов, сейчас я работаю программистом в Яндексе, до этого работал в Intel, ещё раньше разрабатывал RTL-код (register transfer level) на Verilog/VHDL для ASIC/FPGA. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.
Это первая моя статья из цикла, призванного привлечь внимание разработчиков и менеджеров к инженерному подходу к разработке ПО. В последнее время он незаслуженно обойдён вниманием, несмотря на революционные изменения в подходе и инструментах поддержки.
Не буду лукавить: основная задача статьи — возбудить интерес. Так что в ней будет минимум пространных рассуждений и максимум конкретики.
За визуальной частью любого цифрового продукта стоит концептуальная идея. Но что делать, если на проверку этой идеи не хватает времени? Можно ли браться за отрисовку визуала, если еще не определена главная ценность для пользователя?
На протяжении моей карьеры, — а я работал в графическом дизайне, в продукте и консалтинге, — я снова и снова слышу одну и ту же претензию, причем не только в свой адрес, но и в адрес коллег из смежных департаментов:
«На это уйдет слишком много времени. Когда мы сможем увидеть готовый результат?»
Такое всегда немного раздражает. В такие моменты я злюсь не только на собеседника, — а это зачастую стейкхолдер, — но и на себя, ведь это я не смог изменить его представление о дизайне как об этапе производства на восприятие дизайна (включая UX-исследования) как процесса.
Как и многие другие сферы (например, управление продуктом), дизайн похож на айсберг: за простотой конечного результата скрывается сложность работы. Чтобы результат был полезен, важно собрать все детали и отсеять те, что не влияют на конечный результат. Это ключевая часть работы дизайнера.
Еще дизайн часто ассоциируют только с итоговым продуктом или решением, потому что подготовительная работа не видна (и снова хороший пример — управление продуктом). Отсюда и неверные обобщения — «продакт-менеджеры всё время составляют Roadmap и ставят тикеты в Jira», а «дизайнеры только рисуют дизайн-макеты».
Если мы переносим роль дизайнера в такую упрощенную плоскость, значит строгость дизайн-процесса дала слабину. Всё-таки лишь очень небольшая его часть посвящена отработке визуальной составляющей, и когда команды отказываются от инструментов для отработки концепции, они попадают в ловушку форм-фактора.
В этой статье я не теоретизирую. Каждый из блоков — это то, что работает. Если вы разработчик, который хочет думать как архитектор — статья для вас.
Если вы архитектор, которому надоело рисовать схемы ради схем — этот список тоже для вас.
А если вы просто строите что-то серьёзное — сохранить, перечитать, внедрить. Это основа.
Упомянутая в заглавии книга (далее H&H) - это про железо [15]. Я - про программирование, но на базе "железной модели" конечного автомата. И там и там математическая основа одна. Все это, действительно, крутая железная концепция, помогающая поставить не только синтез цифровых схем, но и программирование на совершенно другие рельсы, определяющие его будущее.
Параллелизм у программистов нынче в моде. Но, видимо, они (программисты) совсем не в курсе, что разработчики железа давным-давно погружены в эту тему. А потому им (я все про программистов) есть у кого поучиться. Но, похоже, некие амбиции-заскоки этому мешают. Но, если вы этим не страдаете, то прочитайте книгу H&H и дойдите, ну, хотя бы до 4-й главы. Попробуйте реализовать одно-два упражнения, используя свой, программистский инструментарий - всякие там корутины, потоки и весь сопутствующий этому террариум. Убедитесь в его полном бессилии. И тогда, может, это заставит кое-что пересмотреть, переосмыслить. Только представьте: логический элемент - отдельный процесс, десятки, сотни, тысячи элементов - множество параллельных процессов, и все это в вашей ладошке (это я про смартфон) и даже работает!
Но пришло время исполнять обещанное (см. предыдущую часть темы в [1]). И пусть количество "плюсов" пока не достигло заданной планки, но ... если каждый "минус" считать за два "плюса", то это уже более чем ... ;) Так что спасибо всем, давшим положительную оценку - нет, не автору, а затронутой теме. Области знаний, от которой многое сейчас зависит. Это те слова, которые мы вправе сказать в адрес теории, посвященной синтезу цифровых схем, в адрес тех, кто занимался и занимается ее развитием, становлением и внедрением в практику.
Старые программы покрываются коркой сомнительных фич.
ls просто создаёт список файлов, cat просто выводит содержимое файлов, grep просто фильтрует данные, wc просто подсчитывает слова и так далее. У каждой программы есть несколько опций, меняющих её поведение, но не слишком сильно. Например: wc можно сконфигурировать для подсчёта строк или слов, но не для подсчёта количества абзацев или вхождений какой-то фразы.wc, если с этим уже способна справиться grep?
Недавно я попробовал pthreads и был приятно удивлен — это расширение, которое добавляет в PHP возможность работать с несколькими самыми настоящими потоками. Никакой эмуляции, никакой магии, никаких фейков — все по-настоящему.
Я рассматриваю такую задачу. Есть пул заданий, которые надо побыстрее выполнить. В PHP есть и другие инструменты для решения этой задачи, тут они не упоминаются, статья именно про pthreads.
Стоит отметить, что автор расширения, Joe Watkins, в своих статьях предупреждает, что многопоточность — это всегда не просто и надо быть к этому готовым.
Кто не испугался, идем далее.
Думаете зарабатывать по 1 миллиону долларов ежемесячно — сложно? Ха! Спросите у астрологов — эти ребята точно знают как делать такие деньги не особо напрягаясь. И сейчас речь пойдёт не про эзотерические практики, а про маркетинг чистой воды.
Читайте большой материал с интересными примерами и используйте их в своих продуктах.
