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


Материал разбит на части, от самых общих практических правил, интересных начинающим, до конкретных вопросов, актуальных опытным программистам.
В первой части я на практике дам свой ответ на самые базовые вопросы. Как вообще писать программу, в особенности — сложную программу? Что следует сделать в самом начале, чтобы потом не переделывать с нуля? Как создать оптимальную структуру программы?

Поучительная история о техниках оптимизации наглядно.

Техзадание

Объявим в рамках топика небольшой конкурс по архитектурно-ориентированной оптимизации программного обеспечения.
Вкратце, код состоит из пачки функций, производящих невнятные на первый взгляд манипуляции с исходными данными, и примочки-драйвера, который n раз запускает неоптимизированную версию, затем оптимизированную, сравнивает насчитанные циферки, и, в случае их совпадения, выдает отношение времени выполнения. Вот так:

Executing original code… done
Executing optimized code… done
Checking results… PASSED
Number of runs: 3
Original code average time: 11.954537 sec.
Optimized code average time: 1.052994 sec.
Speedup: 11.35

Разрешено использовать любые техники оптимизации, компилятор GCC с любыми опциями, и, скажем, сервер с двумя четырехъядерными процессорами Intel Xeon E5420 2.5 GHz.
Вот, кстати, код:

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

Ну а чтобы не было скучно, совместим этот пример с ещё одной темой — icq, чтобы у нас получился icq-bot.

Здравствуй, уважаемый Хабр.

Если у Вас есть mp3-файлы с тегами в windows-1251 кодировке, то Amarok в своей базе данных такие файлы показывает криво.

Этот пост — для тех, кто ранее использовал Rus-Xmms
проект для быстрого и удобного избавления от головной боли, связанной с кодировкой mp3-тегов и получил ее снова с выходом KDE4 и
нового Amarok.

Этот пост — также для тех, кто не совсем понимает, как в Linux можно корректно и рекурсивно перекодировать теги у
множества mp3 файлов в юникод и версию ID3v2.4.

Постараюсь преподнести это максимально лаконично, поэтому не буду описывать установку программы в [здесь подставить
название Вашего любимого дистрибутива].

Рецепт приготовления прост и находится под катом.

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

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

Общий API-интерфейс

В конечном счете, каждый API-вызов проходит через один общий интерфейс с 4-я аргументами: имя службы (например, 'datastore_v3' или 'memcache'), имя метода (например, 'Get' или 'RunQuery'), запрос и ответ. Запрос и ответ являются буферами протоколов — двоичным форматом, широко используемым в Google для обмена структурированными данными между процессами. Конкретный тип запроса и ответа буферов протокола зависит от вызванного метода. Когда происходит вызов API, буфер протокола запроса формируется из данных, отправленных в запросе, а буфер протокола ответа остается пустым и в дальнейшем заполняется данными, возвращенными ответом API-вызова.

Сложно в это поверить, но современный процессор является самым сложным готовым продуктом на Земле – а ведь, казалось бы, чего сложного в этом куске железа?



Как и обещал – подробный рассказ о том, как делают процессоры… начиная с песка. Все, что вы хотели знать, но боялись спросить )

В качестве предисловия к переводу. Открываем Firefox/Opera, переходим по ссылке, смотрим исходный код страницы и удивляемся. Потому что его нет. Под катом рассказ, как такое можно сделать.

Инженер Apple Эндрю Кэрол (Andrew Carol) с помощью конструктора Lego создал аналог антикитерского механизма (датирован 150-100 гг до н.э.). Это уникальная система шестерён с передаточным соотношением 254:19, которая моделирует движение Солнца и Луны относительно неподвижных звёзд.



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

Привет, читатель. Есть много прекрасных и мощных JavaScript-фреймворков. JQuery, MooTools, ExtJS, и множество других. Они кроссбраузерны и громадны. И пользоваться ими — одно удовольствие.

Но иногда, бывает, хочется написать какой-нибудь небольшой скриптик на 5 килобайт и как-то совесть мучает подключать JQuery, который весит в сжатом виде 75 килобайт. И каждый раз начинаешь писать свой мини-фреймворк:

var dom = {
	id  : function (id)  { return document.getElementById(id); },
	tag : function (tag) { return document.getElementsByTagName(tag); },
};

Вроде бы, больше для начала и не надо. А потом вспоминаешь про createElement, легкий способ присвоить CSS, наследование, расширение прототип. И в общем каждый раз пишешь свой велосипед.
В этот раз я решил написать миниатюрный фреймворк, который можно было бы без зазрений совести подключать даже к самым маленьким проектам. В сжатом виде он весит всего 4 килобайта (в 20 раз меньше JQuery).
И в нём есть еще одно преимущество по сравнению со всеми современными фреймворками — полный отказ от устаревших браузеров, за счёт чего в эти 4 килобайта вместилася половина JQuery.

Итак, приветствуйте, JavaScript-фреймворк Nano

Читайте актуальную вторую часть!

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

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

Pivot не нуждается в представлении. Если вбить это слово в поиск хабра, результатом будут 37 статей, среди которых есть как обзоры, так и туториалы. Поэтому я решил сосредоточить свои усилия лишь на одном аспекте работы с Pivot — на картинках.

Выпущен релиз Google App Engine SDK 1.4.0

2 декабря разработчики Google App Engine выпустили новую версию SDK. Без преувеличений, этот релиз богат на нововведения и улучшения. Узнать о новых возможностях и других вкусностях новой версии можно под катом.

«Если единственный язык, который вы знаете — это Java или C#, я не думаю, что вы профессиональный программист — вы как молодой плотник, который пока работал только с одним видом дерева.»
Дядя Боб

Несколько месяцев назад я начал разрабатывать приложения для iPhone. Переключение с платформы .NET и C# на Cocoa и Objective-C проходило не без приключений, но было достаточно интересным и познавательным. Скоро мне предстоит помогать осваивать новую платформу и другим разработчикам нашей компании. Поэтому решил написать серию вводных заметок, которые, надеюсь, сделают этот переход более плавным.

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

«Я не использую эту методологию (TDD) из-за того, что главный для меня вопрос остается без ответа. Я знаю, что использование TDD уменьшает количество багов, но что насчет времени, необходимого при работе по этой методологии?
Я хотел бы знать как изменяется время на разработку корпоративного приложения с использованием TDD — уменьшается, увеличивается или остается неизменным.
Надеюсь, вы сможете ответить, так как TDD и BDD меня очень интересуют.»

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

Под катом много фото и видео трафика. Будьте аккуратны.

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

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

Перевод статьи молодого греческого программиста «Why I bill hourly»

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

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

Клиент: Вот участок, на котором мы будем строиться. Вот наброски того, что мы хотим построить. Можете назвать точную стоимость постройки?

Любой инженер-строитель шарахнется от такого предложения, программисты же в своей жажде заключить сделку прикинут смету, удвоят ее, добавят 30% и будут надеяться на лучшее. Как отвечаю на такой вопрос я?

Дорогие хабражители и хабрагости, хочу поделиться с вами своим новым увлечением — 3D-фотографией.
Нет, я не являюсь владельцем 3D-говномыльницы, у меня обычная зеркалка от Sony и далее в этой статье я расскажу о том, как сделать вот такую анаглифную фотографию без специальной техники и за 5 минут времени:

Представляю вам способ формирования цены, который выглядит как самая тупая ошибка нуба.
Назовем его «заполните пустой счёт». Или «заплатите, сколько считаете нужным».

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

Но на самом деле, это довольно оригинальная тактика, которой должен уметь пользоваться любой фрилансер, когда ветер дует в нужную сторону. (Заметьте, я сказала «когда ветер дует в нужную сторону». Мы вернемся к этому позже.)

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

Итак, для тех кому это интересно, расскажу об составляющих частях этого проекта.