Сталкивались ли вы когда нибудь с долгим поиском документации к используемой библиотеке или пакету? Я считаю странным, что исходный код не распространяется с пользовательской документацией. Ведь она такая же важная часть кода, как тесты или зависимости. Без хорошей пользовательской документации мы можем «убить» уйму времени на анализ кода и комментариев. Так почему бы не хранить пользовательскую документацию вместе с исходными кодами программы? Речь не о DocBlock и генерацию документации по API проекта, я говорю именно о пользовательской документации, которую мы так любим за последовательное повествование и множество примеров.

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

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

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

Модуль ферритовой памяти на 4000 символов в мейнфрейме IBM 1401

Мейнфрейм IBM 1401 был представлен в 1959 году, а к середине 60-х стал самым популярным компьютером в мире, намного опережая конкурентов. Особым спросом он пользовался у среднего и крупного бизнеса, в силу своей дешевизны. Ключевым фактором успеха 1401 была его память на магнитных сердечниках (ферритовая память) на 4000 символов, где данные хранились на крошечных намагниченных ферритовых кольцах — сердечниках.

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

В данной работе примеры приведены на языке програмиирования C.

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

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

Если вы плохо знакомы с применением эксплойтов, вам cледует сначала прочитать мою прошлую статью про взлом игр DS с помощью уязвимости целостности стека (stack smash) в файлах сохранений.

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

Язык Си не является объектно-ориентированным языком. И значит все что будет описано ниже это костыли и велосипеды.
ООП включает в себя три столпа: инкапсуляция, наследование, полиморфизм. Ниже я покажу как этих вещей можно добиться в С.

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

^{HCF, n. Mnemonic for ‘Halt and Catch Fire’, any of several undocumented and semi-mythical machine instructions with destructive side-effects <...>
Jargon File}

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

Понятиям MTTF (Mean Time To Failure — среднее время до отказа) и другим терминам теории надежности посвящено большое количество статей, в том числе на Хабре (см., например, тут). Вместе с тем, редкие публикации «для широкого круга читателей» затрагивают вопросы математической статистики, и уж тем более они не дают ответа на вопрос о принципах расчета надежности электронной аппаратуры по известным характеристикам ее составных элементов.

В последнее время мне довольно много приходится работать с расчетами надежности и рисков, и в этой статье я постараюсь восполнить этот пробел, отталкиваясь от своего предыдущего материала (из цикла о машинном обучении) о пуассоновском случайном процессе и подкрепляя текст вычислениями в Mathcad Express, повторить которые вы сможете скачав этот редактор (подробно о нем тут, обратите внимание, что нужна последняя версия 3.1, как и для цикла по machine learning). Сами маткадовские расчеты лежат здесь (вместе с XPS- копией).

Ядро Linux — кладезь как применяемых алгоритмов, так и некоторых хакерских или полухакерских трюков, призванных убыстрить и / или уменьшить размер в памяти (memory footprint). Об одном из таких полухахерских трюков я хочу рассказать далее.

Примечание переводчика: я заменил оригинальные обозначения сторон монеты head/tail на аверс/реверс, чтобы не вносить путаницу русскоязычными орёл/решка. На иллюстрации выше слева аверс (head), справа реверс (tail).

Спасение невозможно?

Это одна из тех типичных загадок о заключённых, в которых вы приговорены к смерти и можете спастись, только если докажете свои умственные способности тюремщику. Вы и ваш друг были заключены в тюрьму. Ваш тюремщик предлагает вам испытание. Если вы его выполните, вы оба будете освобождены.

Возможное, многие из вас думали после ситуации с Фобос-Грунтом — что такого особенного в микросхемах для космоса и почему они столько стоят? Почему нельзя поставить защиту от космического излучения? Что там за история с арестом людей, которые микросхемы экспортировали из США в Россию? Где все полимеры?

На эти вопросы я и попробую ответить в этой статье.

Disclaimer: Сведения получены из открытых источников и могут быть не вполне точными. Я лично с военной электроникой не работаю, а кто работает — те статьи писать не могут. Буду рад дополнить и исправить статью.

Прошло около года, с момента успешного подключения музыкального синтезатора YM2149F к LPT порту компьютера. LPT это конечно хорошо, однако время не стоит на месте, и найти компьютер или ноутбук с LPT портом становится все сложнее и сложнее. Да и сам автор (то есть я) устал лазить каждый раз под стол, где стоит системник, и перетыкать LPT плату на что-то другое, например программатор (у меня LPT-программатор Willem, ну да не суть). Поэтому на сей раз подключать чип YM2149F будем к USB. Ну и конечно, чтобы соотвествовать эпохе, будем это делать на копеечном древнем микроконтроллере PIC16F628.



Вкратце, YM2149F (или ее функциональный аналог AY-3-8910) — микросхема звукового трехголосного синтезатора, применялась в старых компьютерах типа Atari ST, Amstrad CPC, ZX Spectrum, MSX и некоторых других для проигрывания музыки. В России чип приобрел определенную известность благодаря установки в различные клоны ZX Spectrum'а. За время шествования ZX Spectrum по бывшему СССР музыкантами были написаны тысячи мелодий под этот звуковой программируемый генератор. Да и сейчас можно вполне найти людей, создающих музыку именно под этот чип. В конце статьи будут приведены ссылки на огромнейший архив чип-тюнов для YM/AY на сотни часов непрерывного прослушивания.

Недавно возникла данная задача — эмуляция носителя FAT32 на stm32f4.

Её необычность заключается в том, что среди обвязки микроконтроллера вовсе может не быть накопителя.

В моём случае накопитель был, но правила работы с ним не позволяли разместить файловую систему. В ТЗ, тем не менее, присутствовало требование организовать Mass Storage интерфейс для доступа к данным.

Результатом работы явился модуль, который я озаглавил «emfat», состоящий из одноимённого .h и .c файла.

Модуль независим от платформы. В прилагаемом примере он работает на плате stm32f4discovery.

Функция модуля — отдавать куски файловой системы, которые запросит usb-host, подставляя пользовательские данные, если тот пытается считать некоторый файл.

Пока крутые конструкторы проектируют правильные платы и заказывают производство на суперсовременных американо-европейских заводах, обратимся к опыту разработки печатных плат под возможности срочного производства одного из подмосковных (на самом деле Зеленоград – район Москвы) заводов с ручным подвальным монтажом (на самом деле ручные монтажники у них сидят аж на втором этаже, а в подвале стоит линия на 60,000 компонентов в час).

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

Продолжение, начало тут.

Определение исходных требований к устройству. Выбор «железа»

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

Общие требования

Решение должно быть:

• простым и не дорогим;
• построенным на доступных компонентах;
• устройство должно быть достаточно надежным, так как я планирую использовать его на выездах (то есть в крепком корпусе, разъемы навинчивающиеся и т.д.);
• устройство должно быть ремонтопригодным;
• разработка не должна требовать от меня действительно глубоких знаний в электронике и схемотехнике и сильно выходить за рамки школьного курса;
• разработка не должна затянутся не то что на месяцы, а даже на недели;
• я не хочу заниматься разводкой, травлением плат и т.п — хочется максимально использовать готовые компоненты, желательно в виде модулей.

.

Функционал

Основные функции устройства:

• вращение против часовой стрелки с заданной скоростью(тактовая кнопка, пока нажато — вращаем)
• вращение по часовой стрелке с заданной скоростью (тактовая кнопка, пока нажато — вращаем)
• регулировка скорости вращения (потенциометр)
• команда «освободить двигатель» – снять напряжение с двигателя (для экономии ресурса АКБ и для охлаждения двигателя, при необходимости)
• Кроме того, полезно вставить функцию автоматического снятия напряжения с двигателя если фокусером не пользуются продолжительное время (скажем, более 10 минут) – тут возможны варианты;
• Хорошо бы иметь на пульте ДУ простую индикацию величины скрорости вращения, например яркостью светодиода.

Исходя из способа применения, необходимо иметь как минимум два варианта управления фокусировочным устройством:

• с пульта управления при работе непосредственно у телескопа (в т.ч. при визуальных наблюдениях или при грубой фокусровке по изображению на дисплее цифровой камеры) — то есть меня вполне устроит кнопочный пульт на коротком кабеле ;
• с помощью собственного ПО с ноутбука под OS Windows, значит блок управления фокусером должен подключаться к ПК, например по USB;
• опционально, в будущем — с ПК с помощью ASCOM-драйвера.

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

Прочитав статью «Тестирование встроенных систем» и комментарии к ней я был несколько поражен тем фактом, что многие хабровчане знакомы с книгой «Test Driven Development for Embedded C (Pragmatic Programmers)» и framework-ом Unity, но не используют весь арсенал средств, которые предлагают ребята из throwtheswitch.org.

Хочу кратко поделится опытом использования этих самых средств.

Всем привет!

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

Итак, конструкция разработана, собрана на макетной плате, проверена в действии. Дальше — печатная плата. Если верить форумам, то многие (в том числе и мои знакомые) используют Sprint-Layout. Но ведь это ручная работа, тот же карандаш и бумажка, только в электронном виде. Зачем все эти ядра процессора и гигабайты памяти, если приходится всё равно работать ручками? Признаюсь, меня это всегда коробило.

Сейчас я расскажу, как добился удовлетворительного для меня результата в автоматическом режиме.


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

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

Собственно через регулярные выражения я к ним и пришёл.

Ученые участвующие в проекте — Baryon Oscillation Spectroscopic Survey (BOSS) измерили с точностью до 1% дистанции между галактиками на расстоянии более шести миллиардов световых лет от нас, что позволило им сделать выводы о форме Вселенной.