По мотивам cssing.org.ua.

Для вертикального выравнивания в блоках разработчики W3C создали замечательное свойство display: table-cell;, которое позволяет заставить какой-либо элемент отображаться как ячейка таблицы. При этом добавив vertical-align: middle; мы прекрасно справились бы с поставленной задачей, если бы не Internet Explorer, который ни в какую не хочет поддерживать свойство display: table-cell;.

Возникла у меня проблемка расширять стандартные HTMLElement объекты, только не в Firefox'e, а в IE. Можно использовать библиотеку Prototype или JSX. Но мне не понравилось это решение из-за того, что используется надстройка, а не приятный глазу механизм обращения к элементам через DOM. Например, хочу, чтобы в IE появился новый метод

someDOMElement.getLastChild()

Пост написан под влиянием поста пользователя pchelintsev_an.

В данной статье я постараюсь рассказать, с какими вычислительными трудностями можно столкнуться, если пойти по «наивному» пути вычисления матричной экспоненты. Статья может быть полезна тем, кто хотел бы познакомиться с вычислительной математикой, но уже знаком с такими понятиями как система обыкновенных дифференциальных уравнений и задача Коши. Эксперименты проводились с использованием системы GNU Octave.

В последнее время появилось достаточно много мониторов с высоким разрешением, 150 dbi и выше, особенно в ноутбуках. И при этом всё выглядит жутко маленьким.
Причина этого — система думает что у Вашего монитора разрешение 96..100 dpi.
Решать это только увеличением размера шрифта неправильно, т.к. размеры всех остальных элеменов интерфейса остаются маленькими. Надо чтобы графическая оболочка сама это делала.

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

Ниже будет идти список где что поправить, все параметры привожу для своего монитора — 13,3" при 2560x1600, это даёт 226 dpi. Более высокое разрешение сейчас я видел только в ноутбуке Fujistu U904 — 262 dpi.

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

Unable to execute dex: method ID not in [0, 0xffff]: 65536
Conversion to Dalvik format failed: Unable to execute dex: method ID not in [0, 0xffff]: 65536

И вы в ступоре, вы неспособны создать DEX файл для APK. Вы не имеете ни малейшего представления о том, что это и как это исправить. И что бы вы не делали, оно будет приводить вас к самому логичному состоянию: ПАНИКА.

Почти два года назад вышла статья «What no one told you about z-index» (и её перевод на Хабре «То, что вам никто не говорил о z-index»), авторы которой рассказывают о малоизвестной (76% проголосовавших пользователей Хабра слышат об этом впервые), но документированной возможности создания нового контекста наложения указав opacity меньше единицы.

Но несмотря на название статьи, авторы не рассказали вам ещё кое о чём.


Новый контекст наложения формируется в случаях:

• Корневой элемент () всегда содержит корневой контекст наложения. Любой элемент на странице, не участвующий в локальном контексте наложения (сформированном любым из последующих вариантов), участвует в корневом контексте наложения.
  Элемент с position отличным от static и значением z-index отличным от auto. Кроме одного исключения для position: fixed, но я это вынес в отдельный пункт.
  Элемент имеет значение opacity меньше, чем 1.
  

В жизни каждого умного дома возникает закономерный вопрос – как маленький нежный микроконтроллер своими пятью вольтами сможет коммутировать 220 вольт переменного тока?

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

Первый – щелкает. Раздражает. Да, человек – штука такая, ко всему приспособится, и можно привыкнуть, но зачем привыкать к плохому?

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

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

Совсем недавно вышла из бета-версии новая система непрерывной интеграции для PHP-проектов с открытым исходным кодом — PHPCI (текущая версия — 1.1.0), она вскользь упоминалась в дайджесте PHP №21.

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

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

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

От переводчика:

Доброго времени суток!
Недавно я искал способы повышения скорости работы детектора Виолы-Джонса и натолкнулся на интересную статью 2013 года «RASW: a Run-time Adaptive Sliding Windowto Improve Viola-Jones Object Detection». В ней представлен эффективный подход к улучшению работы детекторов, основанных на принципе сканирующего окна и каскадных классификаторах. Я не нашел описания данного подхода на русском языке и решил восполнить этот пробел. В данном переводе я опустил описание алгоритма Виолы-Джонса, так как о нём уже много рассказано, в том числе и на хабре habrahabr.ru/post/133826.

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

• Количеством транзакций порядка 5'000 — 10'000 в секунду
• Объемом примерно в 100ГБ (который бодро растёт)
• Примерно равным количеством операций на чтение/запись
• Преимущественно мелкими транзакциями

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

Я опишу некоторые проблемы, с которыми мы сталкиваемся, и применённые решения. Если кто-то сочтёт это полезным — ради Бога. Если кто-то поправит — я буду только рад обнаружить уязвимость в используемых подходах и увеличить эффективность работы БД. Описанное может быть применено без вмешательства в логику приложения, исключительно путём модификации схемы БД.

Привет, %username%! Сегодня я хочу поделиться опытом разработки одного приложения для Android и трудностями, с которыми пришлось столкнуться при не совсем честном использовании камеры.
Идея приложения «Страж» жила внутри отдела разработки достаточно давно, но первая реализация появилась на платформе Symbian 2 года назад. Сама идея незамысловата – делать фотографии человека, взявшего телефон в руки. В первой реализации приложение было разделено на сигнальные модули и модули обратных вызовов. Сигнальные модули отвечали за регистрацию изменений определённого состояния телефона. Например: извлечение или установка SIM-карты или карты памяти, входящий или исходящий звонок, или совсем хитрые – главным сенсором был сенсор акселерометра, который определял момент поднятия телефона со стола. Модули обратных вызовов – это действия, которые выполняются по сигналам сенсоров. Были реализованы фотография и запись звука.
При портировании приложения на платформу Android подход заметно поменялся. Да и вообще от старого приложения осталась только идея, оно перестало быть модульным, а из всего функционала остался только функционал фотографирования. О реализации этого функционала и хочется рассказать.

Не так уж и давно стало популярным использовать видеокарты для вычислений. В один прекрасный день, несколько лет назад и я взглянул на новую, тогда, технологию CUDA. В руках была хорошая карточка по тем временам GTX8800, да и задачки для распараллеливания тоже были.
Кто работал с GPU, знает про объединение запросов, конфликт банков и как с этим бороться, а если не работал, то можно найти несколько полезных статей по основам программирования на CUDA[1]. Карта GTX8800, в некотором смысле, была хороша тем, что была одной из первых и поддерживала только первые версии CUDA, поэтому на ней было четко заметно, когда есть конфликты банков или запросы в глобальную память не объединяются, потому что время в этом случае увеличивалось в разы. Все это помогало лучше понять все правила работы с картой и писать нормальный код.
В новые модели добавляют все больше и больше функциональности, что облегчает и ускорят разработку. Появились атомарные операции, кеш, динамический параллелизм и т.д.
В посте я расскажу про пространственно-временную фильтрацию изображений и реализацию для compute capability = 1.0, и как можно ускорить получившийся результат за счет новых возможностей.
Временная фильтрация может пригодиться при наблюдении за спутниками или в прочих ситуациях фильтрации, когда требуется точное подавление фона.

Отношение между «чистыми» и «прикладными математиками» основаны на доверии и понимании. «Чистые математики» не доверяют «прикладным математикам», а «прикладные математики» не понимают чистых математиков.

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

Доброго времени суток читатель. Сегодняшний пост будет посвящен вычислению приближенного значения фрактальной размерности плоского изображения, которая тесно связано с размерности Минковского. Это интересно как минимум по двум причинам. Во-первых оказывается, что размерность ограниченного множества в метрическом пространстве может быть не только целым числом, но и любым неотрицательным. Во-вторых значение размерности контура изображения (а это ограниченное множество в метрическом пространстве) является хорошим признаком. В рамках сегодняшнего поста не предусмотрено исследование робастности этого признака, но давайте рассмотрим показательный пример. Множество различных характеристик клеток опухолей молочной железы, полученное в результате анализа снимков тонкоигольной пункционной биопсии. Множество данных состоит из 30 признаков (поля таблицы) с пометкой злокачественная или доброкачественная опухоль, и одним из признаков является как раз фрактальная размерность ядер клеток опухоли. Под катом вас ждет объяснение смысла фрактальной размерности множества, по возможности доступным языком, алгоритм вычисления приближенного значения этой размерности, его реализация на c# и ряд примеров с картинками. Возможно вы открыли этот пост только из-за картинки справа, это изображение я позаимствовал из инстаграмма Jennifer Selter, и в конце мы вычислим фрактальную размерность, так сказать филейной части Дженифер. Хочется кстати вас попросить ответить на пару вопросов в конце поста.

Предисловие

Гуляя по англоязычным просторам интернета в поисках решения одной из наболевших тем на работе, наткнулся на очень интересный алгоритм под названием «Fast Threshold Clustering Algorithm». Данный алгоритм кластеризации, что примечательно, появился сравнительно недавно, а именно в ноябре этого года и автором является Дэвид Варади. Ссылка на первоисточник будет доступна в конце статьи.

Вы правильно поняли из названия, что это не совсем обычное описание алгоритма JPEG (формат файла я подробно описывал в статье «Декодирование JPEG для чайников»). В первую очередь, выбранный способ подачи материала предполагает, что мы ничего не знаем не только о JPEG, но и о преобразовании Фурье, и кодировании Хаффмана. И вообще, мало что помним из лекций. Просто взяли картинку и стали думать как же ее можно сжать. Поэтому я попытался доступно выразить только суть, но при которой у читателя будет выработано достаточно глубокое и, главное, интуитивное понимание алгоритма. Формулы и математические выкладки — по самому минимуму, только те, которые важны для понимания происходящего.

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

Если есть желание, то предлагаю пройти те же этапы самостоятельно параллельно со статьей. Проверить, насколько приведенные рассуждения подходят для разных изображений, попытаться внести свои модификации в алгоритм. Это очень интересно. В качестве инструмента могу порекомендовать замечательную связку Python + NumPy + Matplotlib + PIL(Pillow). Почти вся моя работа (в т. ч. графики и анимация), была произведена с помощью них.

Внимание, трафик! Много иллюстраций, графиков и анимаций (~ 10Мб). По иронии судьбы, в статье про JPEG всего 2 изображения с этим форматом из полусотни.

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

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

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

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

Введение

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

Идея производящих функций достаточно проста: сопоставим некоторой последовательности <g₀, g₁, g₂, ..., g_n> — дискретному объекту, степенной ряд g₀ + g₁z + g₂z² +… + g_nzⁿ +… — объект непрерывный, тем самым мы подключаем к решению задачи целый арсенал средств математического анализа. Обычно говорят, последовательность генерируется, порождается производящей функцией. Важно понимать, что это символьная конструкция, то есть вместо символа z может быть любой объект, для которого определены операции сложения и умножения.