В прошлом году я протестировал 198 аккумуляторов (44 модели AA и 35 моделей AAA). Тогда я измерял ёмкость аккумуляторов сразу после зарядки, а так же через неделю и месяц хранения.

Я провёл дополнительный тест большинства моделей аккумуляторов через семь месяцев после зарядки. Результаты получились интересными.

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

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

Я смирился с мыслью, что мой лучший код уже написан — в прошлом. Мне было уже 54 года (немало!) и я, вероятно, уже не мог писать код так же хорошо, как и раньше. Кто знает — может быть у меня уже начала отказывать память, ну или я просто выучил всё, что был способен в жизни выучить. Мой настрой подкреплялся наблюдениями окружающей меня реальности. Все новые технологии выглядели для меня чудаковато. Я ненавидел Node.js. Я считал все фреймворки для веб-разработки ужасными. И я сетовал на то, что классические способы разработки ПО разрушились и превратились в набор клише, которые нынче впариваются под умными названиями типа Agile или «экстремальное программирование». Я скучал за днями, когда люди писали спецификацию на будущее ПО, программировали, а затем тщательно тестировали его. И когда в каждой статье не было тысячи жаргонных словечек.

Пролог

Астронавты Олдрин (слева) и Армстронг в Хьюстоне во время тренировки выхода на лунную поверхность (22 апреля 1969 года)

Знаете, кого мне всегда напоминали сторонники теорий заговора? Назойливых шахматистов.

Да-да, бывают такие, которые продолжают ходить королем против вашей ладьи. И вы теряетесь, разинув рот от неожиданности: он что, не читал стандартных эндшпилей и не знает своей судьбы — мат не позднее 16-го хода? Что происходит? Он надеется, что вы забыли, как это делается, что вам станет скучно и вы бросите играть?

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

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

А что же тогда делать? Да все очень просто. Надо замолчать. А затем попросить теоретика заговора рассказать все с начала. Нет-нет, не пересказывать теорию, которая обычно является «сутью произошедшего». А описать. Все. Как было сделано. Подробно. С самого начала.

Давайте так и сделаем на примере лунного заговора, который живуч на фоне миссий LRO, Opportunity, Rosetta и сегодняшних ежедневных снимков все приближающегося Плутона.

Генератор случайных чисел во многом подобен сексу: когда он хорош — это прекрасно, когда он плох, все равно приятно (Джордж Марсалья, 1984)

Популярность стохастических алгоритмов все растет. Многие из них базируются на генерации большого количества различных случайных величин. Далеко не всегда равномерно распределенных. Здесь я попытался собрать информацию о быстрых и точных генераторах случайных величин с известными распределениями. Задачи могут быть разными, разными могут быть и критерии. Кому-то важно время генерации, кому-то — точность, кому-то — криптоустойчивость, кому-то — скорость сходимости. Лично я исходил из предположения, что мы имеем некий базовый генератор, возвращающий псевдослучайное целое число, равномерно распределенное от 0 до некого RAND_MAX

unsigned long long BasicRandGenerator() {
    unsigned long long randomVariable;
    // some magic here
    ...
    return randomVariable;
}

и что этот генератор достаточно быстрый. Я имею ввиду, что дешевле сгенерировать с десяток случайных чисел, нежели чем посчитать логарифм или возвести в степень одно из них. Это могут быть стандартные генераторы: std::rand(), rand в MATLAB, Java.util.Random и т.д. Но имейте ввиду, что подобные генераторы редко подходят для серьезной работы. Зачастую они проваливают разные статистические тесты. А также, помните, что вы полностью зависите от них и лучше использовать свой собственный генератор, чтобы иметь представление о его работе.

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


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

Равномерное распределение

Данная статья является продолжением поста Генераторы непрерывно распределенных случайных величин. В этой главе учитывается, что все теоремы из предыдущей статьи уже доказаны и генераторы, указанные в ней, уже реализованы. Как и ранее, у нас имеется некий базовый генератор натуральных чисел от 0 до RAND_MAX:

unsigned long long BasicRandGenerator() {
    unsigned long long randomVariable;
    // some magic here
    ...
    return randomVariable;
}

С дискретными величинами все интуитивно понятнее. Функция распределения дискретной случайной величины:


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

Распределение Бернулли

Думаю, никому не нужно объяснять, насколько широко в играх (и не только) используются гексагональные сетки. Как для заданной шестиугольной ячейки найти координаты ее центра и вершин — достаточно очевидно. Обратное же преобразование (т.е. поиск ячейки, в которую попала данная точка с координатами x и y) уже не столь тривиально. О нём и пойдет речь в данном топике.

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

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

Развлекаясь на досуге с OpenGL, решил научиться делать скриншоты средствами программы, а не системы. Довольно быстро нагуглил функцию glReadPixels, но вот с сохранением картинки вышла проблема. Вспомнил былые времена, когда полностью своим кодом сохранял в bmp, нашел функцию сохранения в tga, понял, что все эти варианты попахивают велосипедизмом и решил использовать широко распространенную библиотеку. Выбор пал на libpng.
Дальше пошли грабли.

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

Сегодня вас ждет рассказ об исходном коде Doom 3 и о том, насколько он красив.
Да, красив. Позвольте мне объясниться.

Всем привет!
Хочу начать вольный перевод книги «ZeroMQ.Use ZeroMQ and learn how to apply different message patterns». Уверен, что многие захотят разобраться с этой интересной библиотекой.

Содержание

• Глава 1: Приступая к работе
• Глава 2: Знакомство с сокетами
• Глава 3: Использование топологии сокетов
• Глава 4: Дополнительные паттерны

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

• Обзор того, что представляет собой очередь сообщений
• Зачем использовать ZeroMQ и что отличает ее от других технологий работы с очередями сообщений
• Основы клиент/серверной архитектуры
• Рассмотрим первый паттерн: запрос-ответ
• Как мы можем обрабатывать строки в C
• Проверка установленных версий ZeroMQ

Недавно на хабре появилась неплохая статья про вычисление N-ного числа фибоначи за O(log N) арифметических операций. Разумный вопрос, всплывший в комментариях, был: «зачем это может пригодиться на практике». Само по себе вычисление N-ого числа фибоначи может и не очень интересно, однако подход с матрицами, использованный в статье, на практике может применяться для гораздо более широкого круга задач.

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

loop 1000000000
  loop 1000000000
    loop 1000000000
      a += 1
      b += a
    end
  end
end
end

Незамедлительно выведет a = 1000000000000000000000000000, b = 500000000000000000000000000500000000000000000000000000, несмотря на то, что если бы программа выполнялась наивно, интерпретатору необходимо было бы выполнить октиллион операций.

Мы в «Латере» занимаемся созданием биллинга для операторов связи и рассказываем на Хабре о разработке своего продукта, а также публикуем интересные технические переводные материалы. И сегодня мы представляем вашему вниманию адаптированный перевод одной из глав книги «Архитектура open-source-приложений», в которой описываются предпосылки появления, архитектура и организация работы популярного веб-сервера nginx.

Профессор эволюционной биологии Арманд Лерой (Armand Leroi) решил проверить, насколько эволюционные алгоритмы подходят для генерации музыки. Его базовый тезис состоит в том, что приятная мелодия — это результат естественного отбора (эволюции) звуков. Результаты эксперимента подтвердили, что случайный шум действительно может превратиться в музыку без помощи композитора. Научную работу и образцы сгенерированных мелодий можно изучить на сайтах DarwinTunes и Evolectronica.

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

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

Обычный шум (из той самой статьи):


Шум Перлина:


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

Эта статья написана прежде всего для программистов C/C++, использующих в своей работе Visual Studio 2013. Поскольку я, как говорится, totally windows guy, то я не могу оценить полезность этой статьи для программистов, не использующих эту среду в своей работе. Итак.

Не секрет, что стандартный аллокатор new/delete/malloc/free в языке C/C++ не блещет быстродействием. Конечно, всё зависит от реализации, но, если говорить об оной от компании Microsoft, то это факт. Кроме того, стандартная реализация аллокатора обладает еще одним фатальным недостатком — фрагментацией памяти. Если в вашей программе происходят частые выделения/освобождения памяти, вы можете обнаружить, что спустя несколько часов работы ваша программа упала по причине нехватки памяти, хотя свободной памяти еще достаточно — просто в результате фрагментации в пуле аллокатора не осталось свободного участка достаточного размера. (Это, кстати, абсолютно реальный случай, который произошел на одном из проектов, в котором я принимал непосредственное участие.)

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

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

Под катом много картинок, аккуратнее с траффиком.

Я пишу мультипротокольный (но не мультиплатформенный, увы, сейчас только windows) мессенджер, который пока что поддерживает только протокол TOX. Но речь не о мессенджере, а о его интерфейсе, а если точнее, об основной его функции — AlphaBlend. Да, я решил написать свой велосипед GUI. Ну а какой современный GUI без полупрозрачных элементов и плавных закруглений? Поэтому остро встала необходимость смешивать изображения с учетом полупрозрачности, т.е. альфа-смешивание или alpha blending. К счастью, в windows GDI такая функция имеется — AlphaBlend. Работает как надо, делает то что нужно. Но я тот еще строитель велосипедов, и мне стало интересно, смогу ли я написать такую же функцию, но более быструю. Результат моих трудов под катом.

На выходных решил поискать open-source реализации отечественных криптографических стандартов. Прежде всего интересовали новые: хэш-функция Стрибог (ГОСТ Р 34.11-2012), Кузнечик (ГОСТ Р 34.12-2015) и ЭЦП (ГОСТ Р 34.10-2012 или 2001 (без 512-бит) ). Старый ГОСТ 28147-89 специально не искал, поскольку найти его реализацию никаких проблем нет уже давно.
Итак, давайте посмотрим, что же получилось. Сразу предупреждаю, что корректность реализаций не проверял.