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

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

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

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

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

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

В этот раз добавим к нему компилируемую библиотеку, а также поговорим о компоновке модулей друг с другом.

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

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

Многие ругают CMake, и часто заслуженно, но если разобраться, то не всё так плохо, а в последнее время очень даже неплохо, и направление развития вполне позитивное.

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

1. Сборку;
2. Автозапуск тестов;
3. Замер покрытия кода;
4. Установку;
5. Автодокументирование;
6. Генерацию онлайн-песочницы;
7. Статический анализ.

Кто и так разбирается в плюсах и си-мейке может просто скачать шаблон проекта и начать им пользоваться.

Привет, хабравчане!

Меня зовут Михаил Матросов, я технический менеджер в компании Align Technology. Сегодня я поработаю капитаном и немного расскажу об основах современного С++.

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

Мне бы хотелось поговорить об этих основах и начну я со своей любимой темы. Будем говорить об операторах new и delete. А точнее, об их отсутствии. Я расскажу, как писать надёжный и современный код на С++ без использования операторов new и delete.

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

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


Изображение взято с сайта behappy.me

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

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

Шесть месяцев назад ребром встал вопрос о тексте для моего дипломного перевода. Результатом помощи коллективного разума стало решение переводить главу Scalable Web Architecture and Distributed Systems за авторством Kate Matsudaira. Нужно отметить, что это мой первый перевод такого объема и сложности. Текст, был мною относительно успешно переведен, хотя по качеству перевода я поставил бы себе 6-7 из 10. Дабы мои усилия не пропали втуне, публикую результат своих трудов.

По просьбам читателей Хабра, теперь полная версия в виде топика.

Масштабируемая веб-архитектура и распределенные системы

Кейт Матсудейра

Перевод: jedi-to-be.
Коррекция: Anastasiaf15, sunshine_lass, Amaliya, fireball, Goudron.

Если вы программист (или чего хуже архитектор), то можете ли вы ответить на такой простой вопрос: как писать НЕ тестируемый код? Призадумались? Если с трудом можете назвать хотя бы 3 способа добиться не тестируемого кода, то статья для вас.

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

Почитать описание других паттернов.

Проблема

Необходимо иметь эффективное представление запросов к некоторой системе, не обладая при этом знаниями ни об их природе ни о способах их обработки.

Описание

Существует по крайней мере три мотивации к использованию шаблона “Команда”:

• инкапсулирование запроса в виде объекта для последующего протоколирования/логирования и т.п.
• наделение сущности “вызов метода объекта” свойствами самостоятельного объекта;
• объектно-ориентированный обратный вызов (callback);
  
  

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

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

  #ruby
  puts 'What is your name?'
  name = gets
  process_name(name)
  puts 'What is your quest?'
  quest = gets
  process_quest(quest)

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

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

  require 'tk'
  root = TkRoot.new()
  name_label = TkLabel.new() {text "What is Your Name?"}
  name_label.pack
  name = TkEntry.new(root).pack
  name.bind("FocusOut") {process_name(name)}
  quest_label = TkLabel.new() {text "What is Your Quest?"}
  quest_label.pack
  quest = TkEntry.new(root).pack
  quest.bind("FocusOut") {process_quest(quest)}
  Tk.mainloop()

Теперь между этими двумя программами большая разница в потоке управления — в частности, в управлении временем, когда вызываются методы process_name и process_quest. В примере с коммандной строкой я контролирую, когда эти методы вызываются, но в примере с оконным приложением нет. Вместо этого я передаю контроль оконной системе (команда Tk.mainloop). Далее она решает, когда вызвать мои методы, основываясь на связях, которые я настроил при создании формы. Управление инвертировано — управляют мной, а не я управляю фреймворком. Это явление и называется инверсией управления (также известно как Принцип Голливуда — «Не звони нам, мы сами позвоним тебе» — Hollywood Principle — «Don't call us, we'll call you»).

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

После суток жизни поста я начал замечать утечку кармы, так что заранее прошу прощение за возможно недопустимый стиль изложения в статье и субъективизм

Привет, Хабрахабр!

Последнее время я не мог не обратить внимание на популярность темы Qt на хабрике, но тем не менее, в комментах продолжают встречаться люди, которые говорят откровенно лживые и непонятные вещи. Этим постом я хотел развеять малость заблуждений о Qt и рассказать, почему же ты должен пересесть со своих Java/Obj-C/.NET на мягкий и пушистый Qt.

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

Ну, что, поехали?

Введение

Очень часто, нам разработчикам необходимо измерить время выполнения своего (и не только своего) кода. Когда я только начал программировать, я использовал структуру DateTime для этих целей. Прошло время, и я узнал о классе Stopwatch и начал его активно использовать. Думаю аналогичная ситуация была и у вас. Не то, чтобы я раньше не задавался вопросом о том, как работает Stopwatch, просто на тот момент знаний о том, что он позволяет измерять затраченное время точнее, чем DateTime мне хватало. Пришло время разъяснить себе, а так же читателям то, как на самом деле работает класс Stopwatch, а так же выяснить его преимущества и недостатки по сравнению с использованием DateTime.

“Не стоит следовать некоторой идиоме только потому, что так делают все или так где-то написано”

Мысли автора статьи во время чтения и рефакторинга чужого кода

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

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

От переводчика. Судя по своему опыту, а также по опыту знакомых коллег-программистов, могу сказать, что для начинающего разработчика среди всех базовых функций языка C# и платформы .NET делегаты и события являются одними из наиболее сложных. Возможно, это из-за того, что необходимость делегатов и событий на первый взгляд кажется неочевидной, или же из-за некоторой путаницы в терминах. Поэтому я решил перевести статью Джона Скита, рассказывающую о делегатах и событиях на самом базовом уровне, «на пальцах». Она идеальна для тех, кто знаком с C#/.NET, однако испытывает затруднение в понимании делегатов и событий.

Представленный здесь перевод является вольным. Однако если под «вольным», как правило, понимают сокращённый перевод, с упущениями, упрощениями и пересказами, то здесь всё наоборот. Данный перевод является немного расширенной, уточнённой и обновлённой версией оригинала. Я выражаю огромную благодарность Сергею Теплякову aka SergeyT, который внёс неоценимый вклад в перевод и оформление данной статьи.

Люди часто испытывают затруднения в понимании различий между событиями и делегатами. И C# ещё больше запутывает ситуацию, так как позволяет объявлять field-like события, которые автоматически преобразуются в переменную делегата с таким же самым именем. Эта статья призвана прояснить данный вопрос. Ещё одним моментом является путаница с термином «делегат», который имеет несколько значений. Иногда его используют для обозначения типа делегата (delegate type), а иногда — для обозначения экземпляра делегата (delegate instance). Чтобы избежать путаницы, я буду явно использовать эти термины — тип делегата и экземпляр делегата, а когда буду использовать слово «делегат» — значит, я говорю о них в самом широком смысле.

Готовился я как-то к собеседованию по C# и среди прочего нашел вопрос примерно следующего содержания:

«Как организовать потокобезопасный вызов события в C# с учетом того, что большое количество потоков постоянно подписываются на событие и отписываются от него?»

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

Особо внимательный читатель сможет найти в статье два комикса в стиле xkcd.
(Осторожно, внутри две картинки примерно по 300-400 кб)

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

• проективная геометрия и однородные координаты
• модель камеры
• эпиполярная геометрия (epiporal geomerty), фундаментальная и существенная матрицы (fundamental matrix, essential matrix)
• триангуляция стереопары точек
• карта глубины(depth map), карта смещений(disparity map) и идея, лежащая в основе ее вычисления

Практически весь материал статьи основан на книге "Multiple View Geometry in Computer Vision" by Hartley, R. I. and Zisserman, A., а раздел про построение карты глубины описан на основе материала из "Learning OpenCV" by Gary Bradski, Adrian Kaehler.

Для понимания содержимого статьи достаточно иметь общее представление об аналитической геометрии и линейной алгебре: знать, что такое матрица, вектор, скалярное и векторное произведение.

В недавно вышедшей Visual Studio 11 Beta встроена новая и главная фишка будущего C# 5 — асинхронное программирование с помощью async/await. Про нее уже написано достаточно много статей в том, числе на хабре — например, эта серия статей. Однако, я для себя так и не понял в чем суть нового синтаксиса, пока сам не попробовал его в деле. Данная статья — попытка самому структурировать и до конца разобраться с этим достаточно интересным инструментом и поделиться результатами с сообществом, рассказав про него немного иначе. Итак, поехали…

Мне очень хочется показать, что в многопоточности С++ «очень быстро» не исключает «очень безопасно». А значит можно писать эффективные и стабильные программы со сколь угодно большим количеством потоков и при этом избегать траты кучи времени на отладку многопоточности. Если Вам интересно, как мне удаётся не выстрелить себе в ногу, и чем я за это плачу, добро пожаловать