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

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

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

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

В итоге работа с БД может стать узким местом в производительности нашего приложения.

Чтобы избавить себя от подобного рода проблем, я предлагаю рассмотреть различные аспекты тестирования баз данных. К которым можно отнести нагрузочное тестирование и проверку производительности SQL Server в целом при помощи юнит-тестов.

This constructor is so secret, not even STL maintainers know about it...

Stephan T. Lavavej

Этот конструктор настолько секретный, что даже сопровождающие STL не знают о нём...

пер.: Door

У std::shared_ptr есть небольшой секрет: очень полезный конструктор, о котором большинство программистов даже не слышали. Он был добавлен только в стандарте С++11, и его не было даже в TR1 версии shared_ptr. Однако он поддерживается gcc с версии 4.3, и компилятором MSVC еще с времен Visual Studio 2010. В Boost он появился примерно с 1.35.0.

В большинстве обучающих материалов, в которых описывается std::shared_ptr ничего нет об этом конструкторе. Скотт Майерс ни словом не обмолвился о нем в «Effective Modern C++», другой автор — Nicolai Josuttis уделил этому конструктору около половины страницы в своей книге «The C++ Standard Library».

Итак, что представляет собой этот секретный конструктор?

Потоки ввода-вывода в стандартной библиотеке C++ просты в использовании, типобезопасны, устойчивы к утечке ресурсов, и позволяют простую обработку ошибок. Однако, за ними закрепилась репутация «медленных». Этому есть несколько причин, таких как широкое использование динамической аллокации и виртуальных функций. Вообще, потоки — одна из самых древних частей стандартной библиотеки (они начали использоваться примерно в 1988 году), и многие решения в них сейчас воспринимаются как «спорные». Тем не менее, они широко используются, особенно когда надо написать какую-то простую программу, работающую с текстовыми данными.

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

Сегодня в комментариях у посту возникло обсуждение о медленности iostreams. В частности, freopen пишет

Забавно смотреть на ваши оптимизации, расположенные по соседству со считыванием через cin :)

а aesamson даёт такую рекомендацию

Можно заменить на getchar_unlocked() для *nix или getchar() для всех остальных.
getchar_unlocked > getchar > scanf > cin, где ">" означает быстрее.

В этом посте я развею и подтвержу некоторые мифы и дам пару рекомендаций.

последняя редакция статьи доступна на сайте makeloft.xyz

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

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

Данная статья входит в получившийся цикл статей о системе документирования Doxygen:

1. Документируем код эффективно при помощи Doxygen
2. Оформление документации в Doxygen
3. Построение диаграмм и графов в Doxygen

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

Данная статья входит в получившийся цикл статей о системе документирования Doxygen:

1. Документируем код эффективно при помощи Doxygen
2. Оформление документации в Doxygen
3. Построение диаграмм и графов в Doxygen

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

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

Данная статья входит в получившийся цикл статей о системе документирования Doxygen:

1. Документируем код эффективно при помощи Doxygen
2. Оформление документации в Doxygen
3. Построение диаграмм и графов в Doxygen

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

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

Про настройку и визуализацию музыки с помощью openFrameworks мы недавно рассказывали. К сожалению русскоязычной информации по фреймворку OpenFrameworks достаточно мало. Для заполнения этого вакуума — начинаем серию публикаций лекций, что были прочитаны в Екатеринбурге в Институте математики и механики им. Н.Н.Красовского (УрО РАН) Денисом Переваловым.

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

Что такое цифровой звук, и звук вообще?



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

Когда вы последний раз программировали на C++?

Может быть это ваша каждодневная работа, а мой последний (до вчерашнего дня) проект на С++ был в далеком 2000 году — дипломный проект на базе Visual Studio 4.2 (хорошая, кстати, система была), и с тех пор перешёл в веб-разработку — скриптовые языки.

То есть сейчас я — начинающий на C++, но это не помешало мне за пару часов развернуть инфраструктуру, сделать и собрать мультимедийное приложение на C++, которое визуализирует музыку с разными эффектами. И в этом мне помогли:

• открытый фреймворк для создания интерактивных приложений — openFrameworks
• бесплатное IDE Code::Blocks

А начиналось всё так — после очередного прослушивания музыки от одного композитора из Самары, я подумал — было бы интересно попробовать сделать визуализацию музыки, и обратился к Денису Перевалову (кто не первый год занимается созданием разнообразных интерактивных арт/перформанс систем) — он мне ответил, что это делается без проблем на базе openFrameworks и что в примерах к его книге (а он автор книги по openFrameworks), есть реализация такой задачи.

То есть мне нужно было всего лишь — установить фреймворк, доработать и собрать пример на С++… Об этом процессе — установке, настройки, и кратком описании openFrameworks и будет эта статья.

openFrameworks — это система с помощью которой можно запрограммировать интерактивное мультимедийное приложение, то есть арт, перформансы и т.п., она бесплатная, открытая и кроссплатформенная система (linux, mac, win), и так же есть версии для ARM (к примеру для RPi), и сборки для iPhone и Android.

Кстати на КДПВ — одна из инсталляций на базе openFrameworks (Семь Видеогидов. выставлено на ВДНХ в экспозиции Политехнического музея. Москва, 2014).

Кто, если не ты? Когда, если не сейчас?



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

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

Недавно на isocpp.org была опубликована ссылка на статью Eli Bendersky «Perfect forwarding and universal references in C++». В этой небольшой статье есть простой ответ на простой вопрос — для решения каких задач и как нужно использовать rvalue-ссылки.

Введение

Большую часть времени, разработка под Windows Runtime приносит ни с чем не сравнимое удовольствие. Дел-то всего ничего: налепил контролов, добавил щепотку MVVM, а потом сидишь, и любуешься своим кодом. Так происходит в 99% случаев. В оставшейся сотой доле, начинаются настоящие пляски с бубном.

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

Кэп, ты где?

Итак, мысленно перенесемся в гипотетическую ситуацию. У нас есть приложение, пусть это будет клиент для kinopoisk.ru под Windows 8.1. И постер какого-либо голливудского AAA проекта с многомиллионным бюджетом и супергероями из любимых нами комиксов. Задача – отобразить пользователю постер в идеальном качестве. Под словом «идеальное» я имею в виду соответствие 1 пиксель изображения == 1 пиксель физический.

Казалось бы, пустяк, создаем Image и присваиваем его свойству Source нужный BitmapImage с картинкой. Вот только размер картинки настораживает – 9300 x 12300. Взяв в руки калькулятор, начинаю считать: 9300 * 12300 пикс * 4 Б/пикс = 436 МБ. Довольно внушительная цифра, но в 21 веке такими вещами уже не удивишь. Средний настольник 2010 года без проблем переваривает такие объемы данных, так что жмём F5 и наслаждаемся своим творением. Всё отлично работает, по меньшей мере на моём компьютере, и ладно. На этом статью можно было бы и закончить…

Сегодня я расскажу о процессе проектирования приложений Windows Phone, которым я пользуюсь. Хотя многое из этого представляет собой обычные этапы для процесса проектирования, я попытаюсь объяснить их именно с точки зрения дизайна приложений для Windows Phone. Пишите мне в твиттер, если у вас есть какие-либо замечания, вопросы, или оставьте комментарий в блоге.

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

Принципы Metro-дизайна

Обычно мы употребляем слово «Metro» как название стиля дизайна пользовательского интерфейса, который компания Microsoft использует в своей собственной платформе и также предлагает использовать разработчикам и дизайнерам при создании приложений для Windows Phone (в этой серии статей я фокусируюсь на Windows Phone). Но давайте немного углубимся в суть термина «Metro» и выясним, что же в действительности он означает. Начнем с того, что Metro определяется двумя вещами: принципами Metro-дизайна и языком Metro-дизайна.

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

Ранее, в Windows 7 был обнаружен так называемый «Режим Бога» (специальная возможность, которая предоставляет удобный доступ ко множеству настроек системы из единой точки), который можно было активировать с помощью нескольких бесхитростных действий. В Windows 8 эта возможность была сохранена. Напомню, как ее активировать.

1. Создаем на рабочем столе новую папку.

Данная статья демонстрирует, как написать простейший музыкальный плеер под Windows Phone.

Основные возможности: плеер работает с плейлистом, можно управлять музыкой (переключать мелодии), плеер может играть в фоне.

Автор в первую очередь руководствовался статьей, в которой не были освещены некоторые элементарные, но не всегда очевидные, аспекты написания плеера. Они и разобраны в данной статье.

Привет, %username%, %wpdeveloper%, %designer% и все, кто ещё читает этот топик!

До окончания приёма заявок на Imagine Cup: Windows Phone Challenge осталось чуть больше 2х недель, самое время ею заняться! Но к заявке должен быть приложен ещё и прототип приложения, выполненный в SketchFlow. О том, как его создать, сегодня и поговорим.

Осторожно, много картинок под катом!

Ready to Get Started?