Шаблоны проектирования — это способ решения периодически возникающих проблем. Точнее, это руководства по решению конкретных проблем. Это не классы, пакеты или библиотеки, которые вы можете вставить в своё приложение и ожидать волшебства.

Как сказано в Википедии:

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

Будьте осторожны

• Шаблоны проектирования — не «серебряная пуля».
• Не пытайтесь внедрять их принудительно, последствия могут быть негативными. Помните, что шаблоны — это способы решения, а не поиска проблем. Так что не перемудрите.
• Если применять их правильно и в нужных местах, они могут оказаться спасением. В противном случае у вас будет ещё больше проблем.

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

Прошло 1 апреля. Часто первоапрельские шутки, выложенные в Интернете, продолжают свое шествие, и всплывают совершенно в неожиданное время. О такой шутке про язык Си и будет эта статья. В каждой шутке есть только доля шутки. Код из нее я взял на вооружение для беглого тестирования на знание языка Си.

Надо написать программу (с пояснениями), в которой будет работать следующая строка:

for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

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

Привет. Меня зовут Марко, и я системный программист в Badoo. Я очень люблю досконально разбираться в том, как работают те или иные вещи, и тонкости работы разделяемых библиотек в Linux не исключение. Я представляю вам перевод именно такого разбора. Приятного чтения.

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

В дополнение к этому я написал демонстрационную программу, в которой реализованы основные алгоритмы по устранению расфокусировки и смаза. Программа выложена на GitHub вместе с исходниками и дистрибутивами.

Ниже показан результат обработки реального размытого изображения (не с синтетическим размытием). Исходное изображение было получено камерой Canon 500D с объективом EF 85mm/1.8. Фокусировка была выставлена вручную, чтобы получить размытие. Как видно, текст совершенно не читается, лишь угадывается диалоговое окно Windows 7.



И вот результат обработки:



Практически весь текст читается достаточно хорошо, хотя и появились некоторые характерные искажения.

Под катом подробное описание проблем деконволюции, способов их решения, а также множество примеров и сравнений. Осторожно, много картинок!

— Вам уже 45? Но у нас коллектив очень молодой. Вы уверены, что хотели бы у нас работать?
— Да, конечно! Я много наслышан о вашей компании. Это мечта всей моей жизни!
— Ну ладно. Вот вам простой вопросик. Что означает буква L в аббревиатуре SOLID?
— Liskov Substitution Principle.

Жилой массив людей. Нет, серьёзно.

Холивары между ценителями Си и приверженцами его ублюдка сына в лице C++ начались ещё до моего рождения и прекратятся разве что после смерти обоих этих языков и меня заодно.

Адепты великого творения Кернигана-Ритчи до последней секунды рабочего дня готовы доказывать приспешникам Страуструпа аксиомы про вечность Си и его невероятную гибкость.
Те в ответ по-свойски советуют им лучше порадоваться рабочему дню, ведь он вот-вот окажется последним – двадцать первому веку кроссплатформенный ассемблер не нужен.
Распаляясь, сторонники Си приводят миллионы давно прошедших через голову навылет тезисов "почему Си лучше C++", при этом каждый раз подчёркивая, что второй все достоинства первого растерял ещё будучи в отцовской утробе, попутно утратив лик человеческий.
Обвиняемая сторона в обиде не остаётся и...

а хотя постойте, о чём это я.

Я люблю Си, уважаю C++ и не переношу холивары (честно). При этом я осознаю, что в Си действительно не хватает многого, и яркий тому пример – отсутствие удобной работы с данными. В C++ эту проблему во многом решает STL и свойства самого языка. На мой студенческий взгляд, здесь особо отличается всем знакомый std::vector. Если стало интересно, как я реализовал его аналог средствами C89 – прошу под кат.

Речь пойдёт о программах и библиотеках для UNIX-подобных систем, распространяемых в виде исходного кода (в том числе в виде тарболлов), написанных обычно на C и C++ (хотя этот же порядок работы может применяться к софту на любом языке). Многие вещи в этой статье написаны применительно конкретно к GNU/Linux, хотя многое из статьи может быть обобщено и на другие UNIX-подобные ОС.

Под словом «пакет» я понимаю в этой статье пакет с исходными текстами, причём не пакет конкретного дистрибутива GNU/Linux, а просто пакет, исходящий от оригинальных авторов софта (UPD от 2017-02-09: кроме тех случаев, где из контекста ясно, что слово «пакет» употреблено в другом смысле).

В этой статье я разберу следующие вопросы:

• Вот скачал программу или библиотеку. Как её собрать и установить? Как воспользоваться библиотекой?
• Что такое префикс (prefix) установки? В чём разница между сборкой и установкой? Куда обычно устанавливают программы?

Я разберу только совсем базовые вещи. Те, которые типичные участники сообщества свободного ПО, программирующие на C и C++ под UNIX-подобные системы, обычно уже знают. Как создавать тарболлы (на примере «голого» make) и как устанавливать чужие тарболлы. Advanced советы по созданию «хороших» пакетов я не дам. «Продвинутые» вещи читайте в документации систем сборки, в замечательной статье «Upstream guide» от Debian (в её конце есть ещё куча ссылок о создании «хороших» пакетов). Многое в этой статье можно было сделать по-другому, моя цель: дать хотя бы один способ, не пытаться объять необъятное.

Прочитав статью "Делаем backup Google или паранойя по поводу санкций. Owncloud и другие открытые решения", я решил, что пора дать второй шанс ownCloud'у после крайне неудачного опыта с 5 версией. В итоге оказалось, что за сей короткий промежуток времени ownCloud приобрел вполне добротный вид и способна работать в качестве повседневного инструмента — обнаруженные проблемы либо не существенны, либо имеют решение. Те, кто не знаком с ownCloud, могут узнать о его ключевых особенностях, к примеру, на официальном сайте или на opennet.ru. В этой статье я НЕ расскажу о том, как надо устанавливать ownCloud и как потом его с нуля настроить, потому что уже достаточно об этом писано-расписано-переписано, да и установка не представляет собой ничего сложного, я лишь кратко упомяну важные детали. Под катом будет информация о том, что же интересного умеет ownCloud, какие приложения в apps.owncloud.com мне показались стоящими внимания, затрону интеграцию с KDE и Android, а также скажу пару слов о подводных камнях и интересных местах, ну а в конце подведу итоги для тех, кому лень столько читать. ownCloud на своём сервере я использую в одиночестве, поэтому администрирование пользователями и всё сопутствующее будет описано крайне скудно. Осторожно: много картинок.

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

Принимаются любые замечания!

У функционального программирования много преимуществ, и его популярность постоянно растет. Но, как и у любой парадигмы программирования, у ФП есть свой жаргон. Мы решили сделать небольшой словарь для всех, кто знакомится с ФП.

В примерах используется JavaScript ES2015). (Почему JavaScript?)

Работа над материалом продолжается; присылайте свои пулл-реквесты в оригинальный репозиторий на английском языке.

В документе используются термины из спецификации Fantasy Land spec по мере необходимости.

Arity (арность)

Количество аргументов функции. От слов унарный, бинарный, тернарный (unary, binary, ternary) и так далее. Это необычное слово, потому что состоит из двух суффиксов: "-ary" и "-ity.". Сложение, к примеру, принимает два аргумента, поэтому это бинарная функция, или функция, у которой арность равна двум. Иногда используют термин "диадный" (dyadic), если предпочитают греческие корни вместо латинских. Функция, которая принимает произвольное количество аргументов называется, соответственно, вариативной (variadic). Но бинарная функция может принимать два и только два аргумента, без учета каррирования или частичного применения.

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

Благодаря reflection можно:
— Легко создавать редакторы, в том числе интерфейсов, так как есть удобный доступ к мета-информации о всех свойствах ваших объектов;
— Добавить binding для многих скриптовых языков сразу (Lua, Python, JavaScript и т.д.);
— Использовать мета-информацию для автоматической сериализаци;
— Использовать как фабрику объектов, создавая нужные экземпляры, имея лишь строку с именем тип;
— Использовать в качестве более легковесной замены dynamic_cast;
— И прочее прочее прочее, в зависимости от фантазии и потребностей.

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

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

Рассказывая о вероятностном программировании и Байесовской статистике, я обычно не уделяю особого внимания тому, как, на самом деле, выполняется вероятностный вывод, рассматривая его как некий «чёрный ящик». Вся прелесть вероятностного программирования заключается в том, что, на самом деле, для того, чтобы строить модели, не обязательно понимать, как именно делается вывод. Но это знание, безусловно, весьма полезно.

Как-то раз я рассказывал о новой Байесовской модели человеку, который не особенно разбирался в предмете, но очень хотел всё понять. Он-то и спросил меня о том, чего я обычно не касаюсь. «Томас, — сказал он, — а как, на самом деле, выполняется вероятностный вывод? Как получаются эти таинственные сэмплы из апостериорной вероятности?».

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

Ведение

Попав в отпуске в город на Неве и посетив множество красивых мест, я все таки, вечерами за чашкой пива, разбирался с UARTом. Тем более, что я купил неплохие наушники Fisher FA011, к которым пришлось прикупить USB SOUND BLASTER X-FI HD и хотел послушать музыку.
Предыдущие статьи вначале переехали на Geektime потом я обратно их перегнал, даже и не знаю, куда теперь их деть :)
Но так на всякий случай они тут:
STM32, C++ и FreeRTOS. Разработка с нуля. Часть 1
STM32, C++ и FreeRTOS. Разработка с нуля. Часть 2 и
STM32, C++ и FreeRTOS. Разработка с нуля. Часть 3 (LCD и Экраны)

Вот уже как неделю английская версия the art of command line висит в секции trending на Github. Для себя я нашел этот материал невероятно полезным и решил помочь сообществу его переводом на русский язык. В переводе наверняка есть несколько недоработок, поэтому милости прошу слать пулл-реквесты мне сюда или автору оригинальной работы Joshua Levy вот сюда. (Если PR отправите мне, то я после того, как пересмотрю изменения отправлю их в мастер-бранч Джоша). Отдельное спасибо jtraub за помощь и исправление опечаток.

Почти все разработчики программного обеспечения рано или поздно подходят к этапу, когда необходимо применить технологию распределения задач по отдельным потокам. Сейчас трудно представить разработку без применения того или иного фреймворка (framework).
Множество из них содержат необходимые инструменты для создания многопоточных приложений. Не исключение и Qt Framework.

Поговорим о методах Qt многопоточной разработки подробнее.

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

Выражаю отдельную благодарность А. Н. Боровскому за книгу «Qt4.7+.Практическое программирование на C++».
Рекомендую к обязательному прочтению!

Структура публикации

• Оговорка про крен
• Подготовка GPS-трека
• Как из массива векторов получить углы Крылова-Эйлера
• Имитация показаний гироскопа
• Вектор ускорения свободного падения и направление «на север»
• Имитация показаний акселерометра, компаса и барометра

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

В этом посте я постараюсь окончательно разобрать такие тонкие понятия в C и C++, как указатели, ссылки и массивы. В частности, я отвечу на вопрос, так являются массивы C указателями или нет.

Обозначения и предположения

• Я буду предполагать, что читатель понимает, что, например, в C++ есть ссылки, а в C — нет, поэтому я не буду постоянно напоминать, о каком именно языке (C/C++ или именно C++) я сейчас говорю, читатель поймёт это из контекста;
• Также, я предполагаю, что читатель уже знает C и C++ на базовом уровне и знает, к примеру, синтаксис объявления ссылки. В этом посте я буду заниматься именно дотошным разбором мелочей;
• Буду обозначать типы так, как выглядело бы объявление переменной TYPE соответствующего типа. Например, тип «массив длины 2 int'ов» я буду обозначать как int TYPE[2];
• Я буду предполагать, что мы в основном имеем дело с обычными типами данных, такими как int TYPE, int *TYPE и т. д., для которых операции =, &, * и другие не переопределены и обозначают обычные вещи;
• «Объект» всегда будет означать «всё, что не ссылка», а не «экземпляр класса»;
• Везде, за исключением специально оговоренных случаев, подразумеваются C89 и C++98.

Указатели и ссылки

Указатели. Что такое указатели, я рассказывать не буду. :) Будем считать, что вы это знаете. Напомню лишь следующие вещи (все примеры кода предполагаются находящимися внутри какой-нибудь функции, например, main):

int x;
int *y = &x; // От любой переменной можно взять адрес при помощи операции взятия адреса "&". Эта операция возвращает указатель
int z = *y; // Указатель можно разыменовать при помощи операции разыменовывания "*". Это операция возвращает тот объект, на который указывает указатель

Всем добрый день!

Недавно передо мной встала довольно интересная задача, сделать интерфейс пользователя для общения с одной железкой. Связь с ней осуществлялась посредством COM-порта. Так как работа предполагалась с системой реального времени (эта самая железка) в операционной системе Windows, для того, чтобы GUI не тормозил, было решено работу с COM-портом вынести в отдельный поток. Так как требования к самой системе постоянно менялись, для минимизации и ускорения исправлений также было решено писать используя паттерн проектирования MVP. В качестве среды разработки был выбран Qt. Просто потому, что мне нравится данная среда и ее возможности. Так и получилась связка Qt+MVP+Qthread. Кому интересно, что из этого всего вышло и по каким граблям я ходил, прошу под кат.