Какое-то время назад ко мне в Skype и «Мой круг» постучалось несколько человек с одним и тем же вопросом: «Как и где можно защитить диссертацию по QA?». Вопросы удивили. Давно не слышал о том, что кто-то хочет писать научные труды, особенно по QA. Вместе с тем, в последнее время я начал замечать, что ко мне все чаще стали приходить на собеседования люди, которые или уже пишут научную работу, или планируют заняться научной деятельностью.

После этого я решил узнать, а много ли существует случаев, когда человек защитил диссертацию по QA. Примеров оказалось немало, вот только некоторые из них:

• «Тестирование на основе формальных спецификаций в процессах разработки программных комплексов» (Петренко Александр Константинович, д.ф.-м.н),
• «Методы и программные средства управления конфигурациями проектов разработки встроенных систем» (Налютин Никита Юрьевич, к.т.н.),
• «Методы реализации регрессионного тестирования по расширенным тестовым наборам» (Епифанов Николай Анатольевич, к.т.н),
• «Разработка метода построения комплекса нагрузочного тестирования распределенной информационной системы» (Ермыкин Алексей Александрович, к.т.н).

Однако все это были уже готовые и законченные работы, так сказать, финал. Мне же была интересна «предыстория». Личный успешный опыт защиты диссертации (правда, по экспериментальной физике) на тот момент позволял видеть лишь общую картину, без какой-либо конкретики. Поэтому я собрал некоторую информацию, добавил мысли из личного опыта и решил поделиться всем этим.

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

В результате стандартный консервативный аллокатор выстраивает все запросы в очередь на pthread_mutex / critical section. И наш многоядерный процессор медленно и печально едет на первой передаче.

И что с этим делать? Познакомимся поближе с деталями реализации метода Scalable Lock-Free Dynamic Memory Allocation. Maged M. Michael. IBM Thomas J. Watson Research Center.

Самый простой код что я сумел найти — написан под LGPL камрадами Scott Schneider и Christos Antonopoulos. Его и рассмотрим.

Сервотестер это прибор, предназначенный для проверки работоспособности сервопривода, определения его крайних углов, скорости передвижения, минимального шага, а также рысканья. Он может быть очень полезен строителям роботов, так как позволяет запустить привод и проверить функционирование модели до того как готова управляющая электроника. Подобные штуки используют в магазинах радиоуправляемых моделей для демонстрации покупателям возможностей сервомашинок. Однако, хочется иметь подобную вещь под рукой всегда. Конечно, можно купить самые разные тестеры, но гораздо интереснее сделать самому.

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

Довольно часто в домашних электронных поделках возникает необходимость посмотреть тот или иной сигнал, причем достаточно его цифрового представления — что передает МК по I2C, правильно ли настроен ШИМ и т.п. Если на работе есть хороший осциллограф, то покупать его для дома — слишком дорогое удовольствие, особенно, когда необходимость возникает лишь от случая к случаю.
В последнее время появились недорогие (в пределах $50) логические анализаторы, однако меня от их покупки всегда останавливало одна мысль: штука то предельно простая, почему бы не сделать её своими руками из подручных материалов?
В данной статье я расскажу, как сделать простой логический анализатор с минимальными финансовыми затратами — все что нужно это отладочная плата Stm32F4Discovery.

Изначально для основного освещения одной из комнат, где шёл капитальный ремонт, планировалась обычная люстра. Но недавно мне на глаза попалась суперяркая светодиодная лента Ultra 5000 со светодиодами smd 5630 торговой марки Arlight. Решение было принято быстро, окончательно и бесповоротно — хочу такую ленту в качестве основного света в комнате.

Доброго времени суток всем хабражителям.

Этот пост относится к разделу «Сделай сам» и описывает простой (на мой взгляд) способ решения задачи контроля питания.

На досуге ковыряю паяльником здоровенный бумбокс в корпусе древнего советского магнитофона "Электроника 211 Стерео", задача — собрать портативный агрегат с полным фаршем, достаточной выходной звуковой мощностью и продолжительностью работы для выезда на природу, занятий в тренажерном зале и для озвучки гаража. Вот требования, которые я выдвигал при разработке устройства к его питанию:

— стабильное питание для встроенных мною цифровых 5-вольтовых устройств со средним током не менее 1А — устаревшего КПК, плеера, а также внешних устройств — флешек USB и SD, жесткого диска;
— питание усилителя мощности напряжением от 11 до 18В;
— автономное питание, достаточное для продолжительного функционирования устройства на максимальной громкости с постоянной производительностью;
— внешнее питание от сети 220 вольт;
— внешнее питание от бортовой сети автомобиля;
— электронное управление питанием;
— нулевое потребление энергии аккумуляторов в ждущем режиме;
— контроль разрядки батареи Li-Ion аккумуляторов с предупреждением о разряде и автоотключением;
— подбор деталей по возможности из бросовых элементов (места в корпусе бумбокса с большим избытком).

По моему мнению, все пункты разработки оказались успешно реализованы, частично кроме последнего — пришлось все же потратить $6.2 на покупку модуля эффективного DC-DC преобразователя, еще $13.2 соответственно аккумуляторы 4 шт. и $2.8 батарейный бокс на 4 штуки. Остальные детали были спаяны с горелых материнских плат и древнего советского железа в ассортименте.

Этот пост снова посвящается цикловым оптимизациям. Почему вообще речь зашла о цикловых перестановочных оптимизациях? Дело в том, что это одна из самых эффективных частей оптимизирующего компилятора. В число цикловых перестановочных оптимизаций входит как автовекторизация так и автопараллелизация. У этих оптимизаций существует своя специфика, но в целом у всех цикловых оптимизаций общие проблемы и общие методы их решения.
Часто приходится слышать мнение, что компилятор во многих случаях «тупит». Мне хочется здесь побыть адвокатом компилятора, чтобы показать, что жизнь компилятора не так уж легка, возможно вызвать легкую долю сочувствия к его нелегкой доле и показать, какие существуют объективные трудности при обработке программы и почему во многих случаях компилятор совершенно обоснованно не может сделать ту или иную оптимизацию, которая кажется очевидной программисту. Ну и заодно я хочу продемонстрировать некоторые возможности помочь компилятору в его работе. Понятно, что иногда существуют и субъективные факторы, в лице разработчиков, которые по како-либо причине не реализовали ту или иную функциональность внутри компилятора.

Если в коде на C++ был создан массив объектов с помощью «new[]», удалять этот массив нужно с помощью «delete[]» и ни в коем случае не с помощью «delete» (без скобок). Разумный вопрос: а не то что?

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

В соответствии со Стандартом C++, в этой ситуации поведение не определено. Все предположения – не более чем популярные городские легенды. Разберем подробно, почему.

Под катом фото, описание процесса, немного схем и детальное описание некоторых моментов создания этого чуда.

Ниже описан мой первый опыт общения с программируемым микроконтроллером в лице STM32VLDiscovery, результатом которого явилась машинка из LEGO, управляемая с телефона, и ещё кое-что. Я постарался изложить свой путь в виде пошагового руководства к действию, но, предупреждаю сразу, не руководства «как делать правильно». Первые два раздела являются предисловием и не относятся непосредственно к данному микроконтроллеру.

Содержание:

1. Первый контакт с микроэлектроникой.
2. Строительство машинки на непрограммируемых логических элементах.
3. Начало работы с STM32. Среда разработки. Подключение микроконтроллера к машинке.
4. Определяем угол поворота передних колёс — обратная связь через АЦП.
5. Использование ЦАП для воспроизведения звуков.

Всем доброго времени суток. Как-то раз у меня появилась идея купить флешку, с которой не будет страшно лезть ни в огонь ни в воду, ни стираться с ней в стиральной машинке. Нашёл в интернете штуки и за тысячу рублей и за две. Денег мало, жаба задушила, пришлось что-то выдумывать.

Сразу скажу, что из инструментов у меня только паяльная станция, хотя по-хорошему хватит и обыкновенного советского паяльника. И ёще, под катом много фоток!

Для разработки системы управления одной железякой после длительных поисков мною был выбран ARM-микроконтроллер семейства STM32 — STM32F103 (в «стоножечном» исполнении). А в качестве макетки для разработки и отладки — STM32P103 (там ножек хоть и меньше, но ядро то же самое). «Истории успеха» я понемногу выкладывал в своей ЖЖшке, но вот решил собрать все воедино и рассказать о том, каково же оно — программировать микроконтроллеры в линуксе. Сам проект лежит на sourceforge.

Добрый день, уважаемые хабровчане. В сегодняшней статье мы предадимся ностальгии, поработаем со старым добрым железом, и постараемся прикрутить к нему не менее доброе новое. А заодно вспомним, как работает шина ISA и как вообще происходит общение х86-процессора с периферией.

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

Сегодня рассмотрим менее экзотический сценарий использования ключевого слова volatile.

Прочитал статью «Почему программисты ошибаются в оценке сроков?», которая вызвала у меня некоторое возмущение. К сожалению, не могу оставить комментарий, поэтому решил написать статью в песочницу.

Вообще-то, вопрос «Почему … ошибаются в оценке сроков?» применим к любой производственной деятельности. И вместо многоточия можно указать кого угодно (программисты, сантехники, плотники, слесари, кондитеры и т.д.).

На сегодняшний момент проект Maximite является моим любимым в области рукодельных микрокомпьютеров. Собрав его оригинальный черно-белый вариант, я после запустил на нем RetroBSD, затем даже свой эмулятор Радио-86РК. Что подкупает в проекте, так это законченность. Конструктивно Maximite простой, PIC32 делает почти всю работу. Но Maximite — это не просто идея в виде схемы. Для Maximite разработана плата, корпус и, собственно, прошивка — MMBasic, продвинутый диалект Бейсика, дающий доступ ко всей периферии, а она у Maximite внушительна. В небольшом интервью автор и разработчик Maximite, Джеф Грэхем, рассказал, почему ему фактически пришлось довести проект для столь законченного вида.

Недавно автор выпустил новую, цветную версию, и данный обзор посвящен именно ей.

Цель проекта Codebender — создать удобную облачную платформу для программирования микроконтроллеров. За последние несколько лет создание устройств на основе микроконтроллеров стало гораздо более доступным и популярным делом. Сейчас не проблема найти подходящий контроллер со всем необходимым железом — вокруг Arduino уже сформировалась внушительная экосистема. А вот с софтом пока дела обстоят хуже. Обычно для написания, отладки и прошивки встроенных программ используются нативные приложения, которые работают не на всех платформах и часто имеют совершенно не дружественный интерфейс. Codebender — это работающий в браузере редактор кода c возможностью проверки его корректности и прошивкой устройств через USB или Ethernet.

Перевод статьи: Blurring of the lines by Dmitry Fadeyev (Usabilitypost.com).

Якоб Нильсен опубликовал осуждающий юзабилити-отчет Windows 8. Ключевые проблемы выделены ниже:

• создание когнитивных издержек из-за необходимости управления двумя различными рабочими пространствами: стартовый экран Metro и старый традиционный рабочий стол;
• отсутствие многооконности в Metro-приложениях;
• трудности поиска отличий между кнопками и метками в плоском Metro UI;
• низкая информационная плотность в приложениях Metro;
• сложности различий между плашками приложений, которые показывают слишком много контента нежели идентифицируют само приложение;
• сложные, способствующие ошибкам жесты.

Сегодня ровно 20 дней с момента запуска нашего нового проекта «Фрилансим». Под катом вкратце о нововведениях прошедшей недели.

Для начала посмотрите тизер:

(если вдруг Vimeo отказывается работать, ссылка)