Соображения на тему использования режимов и состояний компонентов пользовательского интерфейса. Рассмотрим применение подхода при работе с препроцессорами стилей. Осторожно, в статье слишком много примеров кода.

Регулярные выражения (РВ) это, по существу, крошечный язык программирования, встроенный в Python и доступный при помощи модуля re. Используя его, вы указывается правила для множества возможных строк, которые вы хотите проверить; это множество может содержать английские фразы, или адреса электронной почты, или TeX команды, или все что угодно. С помощью РВ вы можете задавать вопросы, такие как «Соответствует ли эта строка шаблону?», или «Совпадает ли шаблон где-нибудь с этой строкой?». Вы можете также использовать регулярные выражения, чтобы изменить строку или разбить ее на части различными способами.

Урок курса «Android. Быстрый старт»

Операционная система Android, начиная с момента первого релиза, всегда притягивала к себе внимание людей из самых разных сфер бизнеса, программирования и академической среды. Сам факт ее появления на свет принес ее создателям, калифорнийскому стартапу из четырех друзей-программистов, кругленькую сумму в 130 млн. долларов.

История течет так быстро, что уже только убелённые сединами хипстеры начала этого века помнят, что в одном из гаражей города Пало Альто совсем недалеко от стен альма-матери множества IT-корпораций, в том числе, Sun Microsystems – Стэнфордского Университета, в 2003 году во время товарищеской вечеринки были сформулированы основные идеи программного продукта, который позже стал мировым хитом.

Базовые ценности никто не отменял

Почему мы упомянули Стэнфорд и Sun? Не только для того, чтобы передать тот дух свободы и творчества, который царил в это время в Кремниевой Долине, но и для того, чтобы с момента своего знакомства с Android, начинающие программисты понимали – эта ОС не появилась как бы сама собой на клочке бумаги и не была написана вот так «на коленке» юным дарованием.

За ней стояли люди, которые прекрасно понимали, что и зачем они делают. А заработанные ими 130 млн. долларов в 2005 году от продажи своего продукта корпорации Google только это доказывают.

Прошло уже три дня с тех пор, как исследователь Parvez Anwar опубликовал информацию о множественных dll hijacking уязвимостях в продуктах Microsoft Office, а какой-либо реакции не наблюдается. Ни CVE, ни сообщений на специализированных ресурсах, Windows Update не качает свежих патчей. Что ж, может, так и нужно, может быть, это не уявимость, а особенность продукта?
Между тем, эксплуатация этой особенности проста и доступна даже ребенку. И, раз уж производитель пока эту «фичу» не удалил, почему бы не написать о ней небольшую статью.

Речь пойдет о Windows 7. Работает ли это на других версиях — мне на текущий момент неизвестно, нужно проверять. Принцип действия описываемого явления (как и многих других, впрочем) основан на старой доброй технологии COM/OLE/ActiveX.

Решили мы как-то перевести свой проект на Visual Studio 2015 — там ведь столько захватывающих фич! Вчера вот только решили, а уже сегодня утром я запустил её инсталлятор. Небо было безоблачным, ничто не предвещало беды. Ну что, в самом деле, может пойти не так? Сколько уже этих Visual Studio переставлено — не счесть (я, помнится, ещё 6.0 когда-то ставил). Кто бы мог подумать, что эта тривиальнейшая задача может вылиться в весьма неожиданный забег по граблям длинной почти в целый рабочий день.

Похрустев немного жестким диском, красивый инсталятор показал мне совершенно некрасивое сообщение об ошибке. Вот такое:


Хм. Не поставился значит, Team Explorer и ещё пару минорных пакетов. Ну ок. Закрываем, переустанавливаем. Не помогает. Удаляем студию, перезагружаемся, устанавливаем — та же ошибка. Лезем в Гугл с вопросом об ошибке установки Visual Studio 2015 на этапе инсталляции компонента Team Explorer и понимаем, что проблема это массовая — десятки ссылок с тем же описанием:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

Отвечают на все эти вопросы специалисты первой линии техподдержки Microsoft, советы которых сводятся к «отключите антивирус», «проверьте чексуму образа со студией», «проверьте диск на ошибки». Ничего из этого, конечно, не помогает, о чём им и рассказывают, после чего они пропадают и больше не отвечают. Очень дружелюбная пользовательская поддержка, ничего не скажешь.

Ну что же, пора включать голову, брать в руки инструменты и разбираться. Поехали.

Важное уточнение — калькулятор обычный, без кнопки sin. Как в бухгалтерии или на рынке.



Под катом три разных варианта решения из разных эпох, от древнего Самарканда до США времён холодной войны.

Проблема решена: 317 кликов исправили ошибку

В 1992 году я считал себя лучшим программистом в мире. В свое оправдание могу сказать лишь, что тогда я только закончил колледж (это было еще до появления Интернета) и жил в Боулдере, штат Колорадо, подрабатывая в мелких компаниях – я почитал за большую удачу возможность просто услышать о других программистах, не говоря уже о том, чтобы повстречаться с ними.

В итоге я познакомился с человеком по имени Билл О’Нил, который нанял меня в качестве программиста, работающего по контракту. Он создал компанию с довольно неоригинальным названием Computer Research & Technologies, и мы стали работать над различными задачами вместе.

Мы занимались разработкой CRUD-приложений [Create, Read, Update, Delete – вариант приложения с базовыми функциями создания, просмотра, обновления и удаления записей в базе данных – прим. перев.] для бизнеса на Visual Basic и FoxPro под Windows 3.1 (и иногда под DOS, так как предчувствовали, что новомодный графический интерфейс останется с нами надолго).

Билл был первым профессиональным программистом, с которым я когда-либо работал. Да что тут говорить, он был первым программистом вообще, с которым я когда-либо работал. Он выдавал мне техзадание, по нему я писал программу на Visual Basic и затем отдавал ее на проверку Биллу. После этого он спокойно объяснял мне, что мой код никуда не годится.

Вступление

Отступление

С последней написанной мною статьи прошло уже довольно много времени, за что прошу прощения: ЕГЭ, поступление, начало учебы. Теперь же, когда до сессии еще далеко, а учебный процесс уже отнимает не так много времени, я могу продолжить писать статьи об освоении нашего К1986ВЕ92QI.

План работы

В комментариях к предыдущим статьям меня просили осветить не только работу с микроконтроллером через настройку регистров, но и с использованием SPL (Универсальной библиотеки для авто настройки периферии.). Когда мы только начинали, я не стал этого делать, ибо соблазн использовать SPL вместо ручной настройки по средствам CMSIS был бы велик, и вы бы, очень вероятно, вопреки здравому смыслу, начали бы использовать SPL везде, где только можно было бы. Сейчас же, научившись работе с некоторыми блоками периферии вручную, мы можем коснуться SPL и сравнить КПД обоих подходов в реальной задачи.

Цель

В качестве учебной цели, давайте помигаем светодиодом по средствам ШИМ-а (Широтно-импульсной модуляции.), при этом регулируя кнопками его частоту. Кнопки так же будем опрашивать в прерывании, вызванного другим таймером, а в момент опроса — будем инвертировать состояние второго светодиода. В реализации данной задачи нам понадобится:

1. Настроить вывод порта ввода-вывода, подключенного к светодиоду, для ручного управления. Этим светодиодом будем показывать, что мы зашли в прерывание и опросили кнопки.
2. Настроить вывод порта ввода-вывода, подключенного ко второму светодиоду, в режим управления от таймера. Именно сюда будет подаваться ШИМ сигнал от первого таймера.
3. Настроить первый таймер в режим подачи ШИМ сигнала на второй светодиод.
4. Настроить таймер для вызова прерывания, в котором мы будем опрашивать клавиши.
5. Разрешить использование прерываний на уровне таймера (по конкретному событию) и на уровне общей таблице векторов прерываний от второго таймера в целом.

Думаю, никто не будет спорить, что знания нужны (я про те, которые имеют определение «профессиональные»). Нужно ли высшее образование? Вот тут-то можно подискутировать. Что же касается знаний, ответ достаточно очевиден, во всяком случае, мне так кажется. Вопрос их качества, глубины и широты оставим за кадром. Очень многое зависит от контекста, где они применяются. Предлагаю поговорить о закономерностях, связанных с профессиональными знаниями. А так как область деятельности носит определяющий характер их состава и качества, сразу оговорюсь, речь пойдёт про знания инженеров в системном интеграторе.

В этой статье мы рассмотрим два способа поиска с помощью регулярных выражений. Один широко распространён и используется в стандартных интерпретаторах многих языков. Второй мало где применяется, в основном в реализациях awk и grep. Оба подхода сильно различаются по своей производительности:



В первом случае поиск занимает A?ⁿAⁿ времени, во втором — Aⁿ.

Степени обозначают повторяемость строк, то есть A?³A³ — это то же самое, что и A?A?A?AAA. Графики отражают время, требуемое для поиска через регулярные выражения.

Обратите внимание, что в Perl для поиска строки из 29 символов требуется более 60 секунд. А при втором методе — 20 микросекунд. Это не ошибка. При поиске 29-символьной строки Thompson NFA работает примерно в миллион раз быстрее. Если нужно найти 100-символьную строку, то Thompson NFA справится менее чем за 200 микросекунд, а Perl понадобится более 10¹⁵ лет. Причём он взят лишь для примера, во многих других языках наблюдается та же картина — в Python, PHP, Ruby и т. д. Ниже мы рассмотрим этот вопрос более детально.

Наверняка вам трудно поверить приведённым данным. Если вы работали с Perl, то вряд ли подмечали за ним низкую производительность при работе с регулярными выражениями. Дело в том, что в большинстве случаев Perl обращается с ними достаточно быстро. Однако, как следует из графика, можно столкнуться с так называемыми патологическими регулярными выражениями, на которых Perl начинает буксовать. В то же время у Thompson NFA такой проблемы нет.

Возникает логичный вопрос: а почему бы в Perl не использовать метод Thompson NFA? Это возможно и следует делать, и об этом пойдёт далее речь.

Ты просто-напросто ненавидишь Git? Ты абсолютно счастлив с Mercurial (или, фу, с Subversion), но раз в месяц тебе приходится отважно сталкиваться с Git, потому что каждый, даже его чертова собака, теперь использует GitHub? Тебя терзают смутные подозрения, что половина всех команд Git на самом деле удалят всю твою работу навсегда, но ты не знаешь какие именно и не хочешь проводить три недели, углубляясь в документацию?

Хорошие новости! Я написал тебе этот изумительный Интернет-пост. Я надеюсь, что смогу размазать достаточно Git-а по твоему лицу, чтобы понизить вероятность сделать что-то непоправимое, а так же уменьшить твой страх что-то сломать. Этого должно быть также достаточно, чтобы сделать документацию Git немного более понятной; она крайне тщательно и глубоко проработана и очень глупо, если ты все еще не прочитал половину.

Я постараюсь излагать коротко, но также, чтобы это было потенциально полезно тем людям, кто вообще никогда не сталкивался с контролем версий, поэтому повсюду будет разбросан 101 совет. Не бойся! Я не думаю, что пользователи Mercurial понятия не имеют, что такое патч.

Доброго здравия хабражителям!

Когда я заглянул в исходники MODx Evolution, меня едва ли не хватил удар. Рефакторить, рефакторить и рефакторить, как, наверное, сказал бы Ильич. По сему меня хватило едва ли на пару недель рефакторинга, после чего я забросил это дело, ибо времени откровенно не было. Но разговор пойдёт не об этом.

Система шаблонизации MODx на мой взгляд — одна из самых лучших. Особенно хорошо постарались разработчики в MODx Revolution. Всё логично, расширяемо, гибко и прям-таки пасторально. Можно сказать, синтаксис шаблонизации MODx — это почти что отдельный язык разметки. Именно такое вот восхищение стало причиной, по которой я стал использовать эту методику в других проектах. И для того, чтобы не заколачивать микроскопом гвозди, то есть не ставить для лендингов MODx, но иметь возможность использовать эту шаблонизацию, я написал отдельный класс шаблонизатора. И даже дал название — QuadBraces.

Приветствую!

В прошлый раз мы остановились на том, что подняли DMA в FPGA.
Сегодня мы реализуем в FPGA примитивный LCD-контроллер и напишем драйвер фреймбуфера для работы с этим контроллером.

Вы ещё раз убедитесь, что разработка под FPGA и написание драйверов под Linux дело очень простое, но интересное.

Также в конце есть маленький опрос — хочется узнать мнение сообщества. Если не сложно, прошу проголосовать.

Git — штука не то чтобы особо сложная, но гибкая. Иногда эта гибкость приводит к забавным последствиям. К примеру, посмотрите на этот коммит на GitHub. Он выглядит как нормальный коммит, но если вы клонируете себе данный репозиторий, то такого коммита в нем не найдете. Потому что это потерянный коммит, более известный как git loose object или же orphaned commit. Под катом — немного про внутренности Git, откуда такое берется и что делать, если оно вам встретилось.

Вступление

В прошлой статье я поделился личными впечатлениями о полученном мною наборе и запрограммировал контроллер демонстрацонным проектом с помощью MT-LINK (так же был предоставлен). Теперь, когда мы детально рассмотрели весь комплект, настало время начать его осваивать.
Для нетерпеливых — итог.

Внятной документации на этот экран я не нашел поэтому пришлось разбираться с тем что есть и экспериментировать. В качестве управляющего устройства я использовал Raspberry PI. Так-же была написана программа позволяющая превратить этот экран в мини-монитор.

Описание

Данный дисплей имеет разрешение 132 x 176 пикселей и даёт возможность работать с тремя цветовыми палитрами 16(5-6-5), 12(4-4-4) и 8(3-3-2) бит.

И вновь приветствую, Хабр!

Моя новая идея посвящена использованию цветовых пространств в микроконтроллерах.
То что моя новость кому-то таковой не покажется, я нисколько не удивлюсь.
Однако я предлагаю метод и его реализацию, подобных которому я не встречал.

Было обычное хмурое зимнее утро, мы с коллегами по обыкновению пили утренний кофе, делились новостями, ничто не предвещало беды. Но тут приятель рассказал… далее цитата из скайп чата:

Как-то читал статейку как парень в метро вытянул у чавака из сетчатого кармана сумки флеху, на которой 128 было написано. Пришел домой, вставил в ноут -> спалил пол компа… Написал на флехе 129 и теперь носит в наружном кармане своей сумки...

Картинка для привлечения внимания:



Так как я работаю на предприятии, которое занимается разработкой и производством электроники, то мы с коллегами принялись активно обсуждать варианты реализации такой флешки, — которая “спаливала бы полкомпа.” Было множество хардкорных, фантастических, а также вполне реальных вариантов. И всё бы так и закончилось этим весёлым обсуждением, если бы я не собирался заказывать изготовление печатных плат для других своих проектов.

Немногим менее года назад была опубликована статья «Микропроцессор «из гаража»» и, возможно, сейчас наступил неплохой момент чтобы снова напомнить о проекте.

Пожалуй, главная новость это расширение системы команд, названное «Версия 1.1». Её отличие от предыдущей это расширенные возможности адресации. Но обо всём по порядку. Чтобы представить о чём идёт речь, взгляните на карту системы команд (картинка кликабельна):

Разметка структурированных данных позволяет показывать дополнительную информацию с вашего сайта в результатах поиска и сервисах Google. Мы рады представить несколько обновлений, которые помогут создавать разметку на сайте:

• Новый Инструмент проверки структурированных данных, который показывает, как Google интерпретирует ваш контент.
• Дополненная документация и правила использования возможностей Google, основанных на технологии структурированных данных.
• Расширенная поддержка синтаксиса разметки JSON-LD.

Инструмент проверки структурированных данных

Новый Инструмент проверки структурированных данных лучше показывает то, как Google интерпретирует разметку структурированных данных на странице сайта.