![](http://webcf.waybackmachine.org/web/20210403211856im_/https://habrastorage.org/getpro/habr/avatars/f21/3b3/003/f213b3003c2998c75b24427732866017.jpg)
Декодер для 7-сегментного индикатора
![](https://webcf.waybackmachine.org/web/20210403211856im_/https://habrastorage.org/getpro/habr/upload_files/154/074/d84/154074d84fba38b8eeef182eb8a72a14.jpg)
Как часто вы работали с 7-сегментными индикаторами? Вам не надоедало, что для каждого из них, надо тянуть пачку проводов? В этот статье мы попробуем решить данную проблему насколько это возможно.
Как часто вы работали с 7-сегментными индикаторами? Вам не надоедало, что для каждого из них, надо тянуть пачку проводов? В этот статье мы попробуем решить данную проблему насколько это возможно.
Здравствуйте, уважаемая аудитория! Предлагаю вашему вниманию первую часть перевода большой обзорной статьи на тему рекомендательных систем, а именно - одной из ее областей, рекомендаций с обоснованием.
С работой алгоритмов рекомендаций большинство пользователей сталкивается ежедневно - в соцсетях, при походах в магазин, выборе товаров в онлайн-магазинах, при поиске информации. Рекомендации с обоснованием не только предлагают вариант выбора, но также объясняют, почему именно этот вариант подходит пользователю лучше остальных. C этой точки зрения проблема рекомендаций с обоснованием также затрагивает исследование поведения пользователей и процессов принятия решений.
В статье проблема обоснований в рекомендательных системах рассматривается с нескольких точек зрения, анализируются открытые проблемы и задачи в данной области и затрагивается тема обоснований в глубоком обучении и ИИ в целом.
Статья может быть интересна всем, кто желает составить целостное и подробное представление о истории развития рекомендательных систем, методах, которые в них применяются, методах оценки моделей с обоснованием и посмотреть на примеры использования рекомендаций с обоснованием в приложениях.
Я пишу в основном из желания поучаствовать в дискуссии, развернувшейся вокруг статьи «Доказательное программирование». Форма статьи была выбрана автором иронично-саркастическая, «первоапрельская», а вопросы затронуты, как мне кажется, очень даже серьёзные и важные, требующие долгого и обстоятельного комментария. С другой стороны, @wetnose «всё сказал», и вторгаться в его личное пространство после этого я не хочу. Поэтому − отдельная статья.
И всё-таки почему программисты постоянно создают новые языки программирования? Почему они так много внимания уделяют выбору языка? Существуют ли объективные критерии превосходства одного языка над другим?
Мы привыкли создавать некоторые элементы пользовательского интерфейса с помощью JavaScript, например аккордеоны, всплывающие подсказки (тултипы), усечение текста и т. д. Но, поскольку HTML и CSS постоянно получают новые функции, а старые браузеры больше не нужно поддерживать, мы можем использовать намного меньше JavaScript-кода для создания элементов пользовательского интерфейса и больше фокусироваться на логической части (проверки, обработка данных и т. д.).
Большинство разработчиков, которые использовали рекурсию для решения своих задач, видели такую ошибку:
RangeError: Maximum call stack size exceeded.
Многие полагают, что браузер ограничивает нас именно в количестве вызовов, но это не так. В данной статье я покажу на простых примерах, как это ограничение работает на самом деле.
Большинство фронтэнд-разработчиков откроют для себя в этой статье что-то новенькое!
Пытаясь реализовать обратный поиск изображений для своего сайта, я столкнулся с огромным миром поиска изображений. Ниже приведены краткие описания и варианты применения некоторых подходов обратного поиска/поиска похожих изображений.
Некоторое время назад я занимался одной интересной задачей, относящейся к спутниковой навигации. Требовалось вычислить координаты объекта при известных координатах спутников в глобальной системе и известных координатах этих же спутников в локальной системе координат навигационного объекта. Задачу удалось решить, используя свойства кватернионов.
В на стоящее время известна масса библиотек для JavaScript таких как Moment.js, Day.js, Luxon и.т.д. Но не смотря на работоспособность выше указанных, здесь речь пойдет только Moment.js и Day.js. В конце этой статьи будет понятно почему выбор пал на эти библиотеки.
Здравствуйте, коллеги.
В этой статье решил рассказать о том, что и почему чаще всего спрашивают на позицию автоматизатора в тестировании. Я постараюсь рассказать о как можно большем количестве направлений. При этом не буду придумывать конкретные вопросы - их может быть великое множество. Своей задачей я вижу только наметить области, чтобы у вас осталась своего рода карта знаний.
Само собой, если вы проходите собеседование на позицию junior, от вас не будут требовать опыта и знаний по всем вопросам. Будет круто, если вы разбираетесь хотя бы в ~30% всего этого. От позиции middle я бы ожидал примерно ~50%-60% знаний перечисленных мною тем. Ну и далее по восходящей.
Форт и сейчас известен, главным образом, среди разработки встроенных систем, как что-то вроде необычайного высокоуровневого ассемблера, например, для микроконтроллеров - AmForth и Mecrisp. Однако, когда-то давным давно был известен в другой ипостаси - как язык программирования научных приложений.
Форт был выбран в качестве средства, с помощью которого объясняются детали программной реализации систем, основанных на знаниях, по следующим причинам: во-первых, транслятор с этого языка имеется практически на всех типах микрокомпьютеров, во-вторых, он достаточно дешевый, и, наконец, имеет много общего с языками искусственного интеллекта, в частности с Лиспом.
Таунсенд К., Фохт Д. ПРОЕКТИРОВАНИЕ И ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ЭКСПЕРТНЫХ СИСТЕМ НА ПЕРСОНАЛЬНЫХ ЭВМ. М.: Финансы и статистика, 1990.
windows.close()
не всегда закрывает окно браузера. А в консоли инструментов разработчика браузера при этом выводится сообщение, указывающее на то, что скрипты могут закрывать только окна, которые ими же и открыты:Scripts may close only the windows that were opened by them.
Наверное как и большая часть Хабра я вчера проглядел эту статью — "Собеседование в Яндекс: театр абсурда :/". Она занятная и чего уж таить греха, я чувствовал такие же "нотки", когда ходил в Яндекс на собеседование на роль… менеджера несколько лет назад. Еще мне предложили купить их акций на свои деньги вместо опционов… хм. В принципе довольно очевидно, какие "качества" они проверяют таким образом.
Но не суть. Нужно всегда пытаться свести все к созиданию, а не разрушению. Конструктивная постановка вопроса состоит в том, а можно ли сделать нормально в отдельно взятой отрасли, например в машинном обучении? Или собеседования сломаны как класс?
Некоторое время назад я написал такую статью в личном блоге, но постеснялся выкладывать ее дальше личного блога. И наверное зря, т.к. многие мои знакомые довольно высоко ее оценили. Если коротко — я лично пропустил через себя около 150 кандидатов и в итоге мы остались довольны результатом и люди, которых мы нашли, до сих пор успешно справляются со своими задачами, все тепло и лампово.
Прочитав вчерашнюю статью, я понял, что мне есть чего добавить по сути. Последние несколько лет я выкладывал на Хабр как правило сугубо технические статьи (релизы датасетов, моделей, тесты железа) и зачастую грустил, потому что они не находили должного отклика пропорционального количеству вложенных усилий. Так что позвольте мне минутку слабости и я постараюсь "починить" сломанный подход Яндекса для отдельно взятого кейса.
TLDR: Сломаны ли собеседования как класс? Короткий ответ — нет, но надо приложить очень много усилий со своей стороны в первую очередь. И подход всегда будет уникальным для каждой сферы деятельности.
Чем проще и понятнее описаны требования — тем меньше багов будет в функционале. Потому что не будет разных прочтений, додумок и прочего. А еще в простыне текста легко потеряться и что-то просто забыть реализовать.
Как же сделать ТЗ понятнее? Можно улучшить текст — вместо скупого текста составить вариант использования. А можно использовать визуализацию. То есть добавить в требования картинки, диаграммы, таблицы...
Причем сделать это может не только аналитик, но и любой член команды. Тестировщикам особенно полезно визуализировать ТЗ, потому что это помогает сразу увидеть проблемные места и уточнить их ещё до реализации. Раннее тестирование и всё такое =)
А ещё техники, помогающие лучше понять требования, относятся к техникам тест-дизайна. Значит, о них стоит знать! В одну статью всё запихивать не стала и сделала отдельные:
Сотрудники лаборатории машинного обучения Университета ИТМО занимаются не только теорией, но и прикладными проектами. Некоторым из них удается вдохновлять участников научного и профессионального сообщества по всему миру, преображать бизнес и цифровое пространство. Такую работу ведет Media Research Group под руководством профессора Александра Фарсеева. Сегодня он рассказывает об исследованиях и проектах его команды.
Все-таки самоизоляция не проходит бесследно. Сидишь себе дома, а в голову разные мысли приходят. Как, чем осчастливить человечество? И вот оно: CDD! (CDD - Cli Driven Development - Новый подход).
Зачем нужны комментарии. Правда ли, что хороший код должен быть без них и как команды замедляют разработку в 4 раза, забывая о "смысле жизни".