В первой части статьи, переведенной уважаемым skb7, было рассмотрено идиому Pimpl (pointer to implementation, указатель на реализацию), ее назначение и преимущества. Во второй части будет рассмотрено проблемы, возникающие при использовании этой идиомы, а также предложены некоторые варианты их решения.

Все началось в 2009 году. Я работал в крупной компании, занимающейся разработкой ПО. Наша команда занималась выполнением довольно большого проекта. Мои обязанности были довольно размыты. В то время как мой руководитель обеспечивал выполнение проекта с внешней стороны (он общался с дирекцией, менеджерами и т.п.), я занимался решением внутренних проблем проекта – проектировал, составлял планы, ставил задачи разработчикам, отслеживал направление работ и т.п. Незадолго до описываемых событий, в компании сменилось руководство, прошла весьма ощутимая реорганизация, курс развития компании в целом (и проекта в частности) изрядно сместился, по сравнению с первоначальным замыслом. И я не мог сказать, что новое направление развития меня устраивает.

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

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

Среди многочисленных проектов компании Google есть один очень важный проект, которым компания занимается уже более пяти лет, и в то же время он на удивление мало освещается в прессе. Речь идёт о стандарте GTFS (изначально Google Transit Feed Specification, но с 2009 года расшифровку сменили на General Transit Feed Specification) — общий протокол для расписания общественного транспорта, который компания Google предложила в 2006 году.



Сейчас Google получает информацию от 475 транспортных компаний США и Европы, но пока что расписание на Google Maps полноценно работает только в четырёх американских городах (Бостон, Портленд, Сан-Диего, Сан-Франциско) и двух европейских (Мадрид, Турин). Жители этих городов могут в привычном интерфейсе Google Maps смотреть, через сколько минут на остановку придёт нужный автобус, троллейбус или трамвай — c июня 2011 года для этих городов работает функция Live Transit Updates, то есть обновление в реальном времени информации о реальном местонахождении транспорта.

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

Почему же для устранения смаза и расфокусировки практически ничего нету (unsharp mask не в счет) – может быть это в принципе невозможно? На самом деле возможно – соответствующий математический аппарат начал разрабатываться примерно 70 лет назад, но, как и для многих других алгоритмов обработки изображений, все это нашло широкое применение только в недавнее время. Вот, в качестве демонстрации вау-эффекта, пара картинок:



Я не стал использовать замученную Лену, а нашел свою фотку Венеции. Правое изображение честно получено из левого, причем без использования ухищрений типа 48-битного формата (в этом случае будет 100% восстановление исходного изображения) – слева самый обычный PNG, размытый искусственно. Результат впечатляет… но на практике не все так просто. Под катом подробный обзор теории и практические результаты.
Осторожно, много картинок в формате PNG!

Вступление.

Часто в документации от Qt встречается термин Pimpl. Кроме того, те кто хоть немного копался в исходном коде Qt часто видел такие макросы как: Q_DECLARE_PRIVATE, Q_D. А также встречал так называемые приватные заголовочные файлы, название которых заканчивается на "_p.h".
В этой статье я попробую приоткрыть ширму за всей это структурой.

Pimpl, что это?

Pimpl — Pointer to private implementation. Это одно из названий паттерна программирования. Еще его называют чеширским котом — «Cheshire Cat» (это название мне больше нравится). В чем суть этого паттерна? Основная идея этого паттерна — это вынести все приватные члены класса и, в не которых случаях, функционала в приватный класс.
Отсюда название «чеширский кот» — видно только улыбку, а все остальное остается невидимым, но оно несомненно есть :-) Кто не помнит этого замечательного кота, может обратится к первоисточнику, к книге Льюиса Кэрролла «Алиса в стране чудес». Очень интересная книга, особенно если читать в оригинале.
Что это дает?

Вдохновившись статьёй Привет из свободного от libc мира, я так же решил проделать нечто подобное. Чтобы не заниматься этим бесцельно, я решил поставить перед собой следующую задачу. Сделать программу, выводящую какую-нибудь простую строку, вроде «ELF, hello!». Разобраться с тем, как именно она будет представлена в исполняемом файле. Ну и попутно, постараться уложиться в 100 байт.

Благодаря голливудским блокбастерам, мы знаем, что у людей с расстроенной психикой бывает множество заболеваний, например, они могут воображать себя кем-то другим и вести себя соответственно. Классический пример такого фильма, это «Бойцовский клуб» от Финчера, фильм снят крупными стежками, в книге Паланика, эта история рассказана полнее и лучше. Для тех, кто не знаком с фильмом или книгой, рекомендую наверстать упущенное, но здесь изложу краткий синопсис.
Главный герой устал от обыденности и однажды он встречает человека, который показывает ему выход из привычной жизни, это бойцовский клуб или бои с другими яппи, которые также утомлены окружающей действительностью. Бои дают вкус к жизни, открывают новые возможности, дают новый мир. В конце фильма герой осознает, что все это время он был двумя людьми одновременно, он узнает это по косвенным признакам и на этом картина и заканчивается. А наше повествование с этого и начинается.

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

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

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

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

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

О том какова стоимость моей поделки:

Низкий поклон Хабранароду!

Предисловие

Много мы все начитались и даже дочитались статьей о том, как улучшить работоспособность, эффективность и другую, простите — фигню.

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

Является преждевременная оптимизация дорогой в ад? Или подход «потом исправим» превращает программистов из «специалистов» в презираемую всеми «школоту»?

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

Доброго всем времени суток!
Итак, я решил продолжить рассказ о замечательном языке программирования D.
Моя прошлая статья была о мультипарадигменности языка, о том, что он естественным и гармоничным образом поддерживает большинство современных популярных стилей программирования.
В этот раз я задумал осветить другую сторону языка — менее общую и фундаментальную, но не менее полезную. А именно возможности метапрограммирования и compile-time computations.

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

После приобретения обновки в виде Asus P31SD и последующей установки на него Linux было очень обидно увидеть всего 6 часов автономной работы вместо желаемых 10-12. На Windows обратно вернуться не удалось (тут даже cywgin не помог), поэтому было решено запастись кофе и занять ближайшие выходные решением этих проблем.

Рассматриваем решение на примере Ubuntu 11.10.

P.S. В теории гайд подходит для всех ноутбуков с Sandybridge и Nvidia Optimus.

«на русской сцене мы удивляем друг друга тем, что вообще что-то делаем», © manwe
(из статуса SCRIMERS на demoscene.ru/forum)

Пятиминутка мета: в этом тексте вам, котятки, предстоит прочитать о том, как потратить свое время совершенно неэффективно с точки зрения отношения размера полученного продукта к потраченным времени и усилиям.
Предположим, что мы хотим сделать что-нибудь эдакое, например, интру размером до 4кб, но мы нищеброды, и у нас нет денег на виндовс и видеокарту с шейдерами, поддерживающими ветвления. Или мы просто не хотим брать стандартный набор из apack/crinkler/sonant/4klang/боже-что-там-еще-есть, делать очередную «смотрите все! я тоже умею рэймарчинг дистанс филдс!» и теряться среди десятков-сотен таких же. Ну или же мы просто любим выпендриваться как попало в надежде, что девочки на нас наконец-то обратят внимание.

В общем, не важно. Пусть у нас просто есть какой-нибудь линукс со слабой видеокартой и вся юность впереди. Попробуем со всем этим теперь создать запускаемый файл размером не более, скажем, 1024 байт, который при запуске умудрялся бы каким-нибудь образом создавать и показывать пользователю что-нибудь (эдакое).

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

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

Иллюстраций: 34, символов: 51 609.

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

По этому поводу мне пришла идея: а что если позаимствовать прием из сериалов — Клиффхэнгеры.

Смысл идеи очень прост: каждый день мы не начинаем новую историю, а узнаем чем же закончилась прошлая интригующая.
Применительно к программированию: каждый день дореализовываем вчера начатое и подготавливаем основу для завтра.
И таким образом более менее получилось решить лично для себя 2 проблемы:
1. Мотивация (начать что-то делать хочется, хотя бы чтобы увидеть как оно заработает (или из-за чего не заработает));
2. Планирование времени (закончить что-то вовремя становится чуть проще, потому что нацелен не только на полностью готовую фичу сегодня, но еще и на основу «интриги» на завтра);

А что вы думаете по этому поводу?

Сколько я себя помню, всегда мечтала сделать процессор. Наконец, вчера я его сделала. Не бог весть что: 8 бит, RISC, текущая рабочая частота — 4 кГц, но он работает. Пока что в программе моделирования логических цепей, но все мы знаем: «сегодня — на модели, завтра — на деле!».

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

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

1. Почему стоит начать работать «в белую»
2. Почему на начальном этапе ИП лучше ООО
3. Что делать, если партнёров несколько

Если вы – начинающий или уже опытный фрилансер и подумываете о работе «в белую», но ещё точно не определились с вопросами «Стоит ли оно того?» и «ИП или ООО?», вэлком

Доброго времени суток!
Некоторым программистам иногда приходит в голову мысль «а не изучить ли мне ассемблер?». Ведь на нем пишут самые (с некоторыми оговорками) маленькие и быстрые программы, да и охота ощутить вкус низкоуровневого программирования берет свое. Ну и для общего развития не повредит.
Мысль эта не обошла стороной и меня. Вдохновившись историей одного байта, я ринулся в бой…

… но оказалось, что найти материал по интересующей теме не так просто, как хотелось бы. Посему решено было создать на хабре пополняющийся пост-индекс статей/книг/мануалов/etc. об этом, несомненно, великом языке.
Под катом находится, собственно, список с краткими комментариями, разбитый по категориям.

UPD
В список начали добавляться ресурсы по программингу микроконтроллеров.