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

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

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

В этом посте я расскажу о новых серверах DELL PowerEdge серии C (С – от Cloud), а также о том, как благодаря новому оборудованию мы удвоили емкость нашей площадки в ДЦ и при этом сохранили затраты на эксплуатацию на прежнем уровне.

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

Чаще всего используется моделирование данных, распределённых по нормальному закону. К сожалению, MS Excel и распространённые статистические пакетаы (SPSS, Statistica) позволяют моделировать только одномерные статистические распределения. Конечно, можно составить многомерное распределение из нескольких одномерных, но только в том случае, если переменные независимы. Если же нужно исследовать данные с зависящими друг от друга переменными, придётся писать программу.

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

1. Поделиться со всеми интересным алгоритмом и его реализацией на С++ (стандарт С++11);
2. Узнать, есть ли у данного алгоритма название и/или формальное описание;

Привет!

Ребята с ресурса Data Visualization собрали несколько очень интересных решений для представления данных:



Datavisualization.ch Selected Tools

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

Datavisualization.ch является одним из ведущих ресурсов в интернете, рассказывающих о визуализации данных и инфографике. На сайте обсуждаются и исследуются интересные и инновационные идеи в этих областях.

На сегодняшний день уже существуют box-reflect и mask-image, которые позволяют создавать отражение элементов, но данные свойства доступны только в Safari и Chrome, да и работают не так как хотелось бы. Поэтому я хочу рассказать Вам как реализовать кроссбраузерное отражение на CSS.

Листая страницы хаба «Алгоритмы», наткнулся на топик, посвященный решению задачи локализации точки в многоугольнике: задан многоугольник (замкнутая ломаная линия без самопересечений), требуется определить — находится ли заданная точка A внутри этого многоугольника или нет. В одном из последних комментариев к топику было высказано недоумение, какое отношение такая чисто математическая задача имеет к теории алгоритмов. Имеет-имеет, причем самое непосредственное. Задача локализации является классической задачей вычислительной геометрии (не путать с компьютерной графикой). В качестве разминки предлагается взглянуть на картинку справа, на которой изображен многоугольник типа кривой Пеано (источник [1]), и попытаться ответить на вопрос — красная точка ты видишь суслика? и я не вижу, а он есть! находится внутри или снаружи многоугольника? А ниже мы (исключительно в образовательных целях) рассмотрим простую вариацию данной задачи, когда заданный многоугольник является выпуклым.

История Pinterest очень похожа на Instagram. Феноменальный рост, огромное количество пользователей и хранимых данных, при этом поразительно мало сотрудников. А еще все в облаке.

Действительно, ни Pinterest ни Instagram не сделали больших научных или технологических открытий, но это скорее является следствием простоты использования облачных технологий, нежели признаком заката эры инноваций в Кремниевой Долине (Золотой век Кремниевой долины окончен, и мы танцуем на её могиле – прим. переводчика). Цифры в заголовке и оценки стоимости этих компании настолько велики, что нам кажется, будто бы за ними стоит некий вид технологической революции, обеспечивающей их бурный рост. Однако, эта революция гораздо более искусна – она показывает, насколько легко добиться столь быстрого роста, если вы способны реализовать хорошую идею. Привыкайте. Теперь это норма.

«Какой препроцессорный язык стоит использовать для CSS?» является очень актуальным вопросом в последнее время. Несколько раз меня спрашивали об этом лично, и казалось бы, каждые пару дней этот вопрос поднимался в сети. Очень приятно что беседа перешла из темы о плюсах и минусах препроцессинга к обсуждению какой же язык является лучшим. За дело!

Если быть кратким: SASS.

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

Развернутый ответ: ниже

На сайте sortbenchmark.org ежегодно проводятся конкурсы по сортировке больших наборов данных. Один из видов соревнований — minute sort, в котором необходимо за минуту прочитать с диска и сортировать как можно большее число записей и сохранить результат в файл. Конкурс проходит в двух категориях — Indy, без ограничений на используемое железо, и Daytona — должны использоваться только обычные компьютеры “из магазина”.

Команде Microsoft Research удалось многократно превысить державшийся с 2009 года рекорд Yahoo в категории Daytona. Их кластер, состоящий из 1033 дисков на 250 машинах, справился с 1401 гигабайтом данных. Это почти втрое лучше результата Yahoo (500 гигабайт), при том, что кластер Yahoo был почти в шесть раз больше (5624 диска на 1406 машинах). Более того, майкрософтовский кластер побил и прошлогодний рекорд в категории Indy (1353 гигабайта).

В отличие от Европы и Америки в России к сайтам знакомств преобладает осторожное отношение. Однако, надежда нажать на волшебную кнопочку и найти себе любовь не гаснет в сердцах многих. И мы должны эту надежду оправдывать. Конечно, сразу найти идеально подходящую “половинку” мы не обещаем, но предложить десятки, сотни или в отдельных случаях тысячи вариантов, отвечающих именно вашим запросам, просто обязаны. Что и делаем, причем очень быстро.

Средний поиск по базе из 11 миллионов анкет, имеющих от 4 до 30 параметров каждая, занимает у нас в среднем 3.5 милисекунды. И при этом кроме поиска демон-серчер «Мамбы» выполняет следующие, в том числе не вполне традиционные задачи:

• для каждой конкретной анкеты выдает ее место в поиске (каждый пользователь, заходя в свою анкету, видит сообщение «Вы находитесь на N месте в поиске»)
• выдает конкретную анкету из списка по первичному ключу
• производит непосредственный поиск анкеты по заданным параметрам

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

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

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

Недавно мы настраивали SMTP-сервер для нашего проекта. Вопрос стоял так: что нужно сделать, чтобы письма, отправленные нашим пользователям, не попадали в папку со спамом или попадали туда как можно реже?

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

Приведенные советы актуальны только если вы используете свой собственный SMTP-сервер. При использовании, например, SMTP сервера Google всё уже сделано за нас. Как правило. В любом случае рекомендую проверить (см. подразделы Как проверить?).

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

Локализация здесь осуществляется довольно нехитро. Все строки, требующие перевода, оборачиваются в макрос _TR():

wprintf(L"%s\n", _TR("Some translating string"));

Макрос возвращает нужную версию текста в зависимости от текущего используемого языка. Определён он следующим образом:

#define _TR(x) g_Translator.Translate(x)

Здесь происходит обращение к глобальному объекту g_Translator, который в функции Translate() считает в рантайме crc32 от указанной строки, ищет в своей xml-базе перевод с совпадающей контрольной суммой и возвращает его.

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

Немного погуглив по запросу «compile-time crc32» я быстро понял, что задача это не самая тривиальная, а готовых решений мне найти так и не удалось.

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

Можно каждый раз писать JavaScript-код и стили к нему, но со временем это приводит к разрастанию кода, с чем в определенный момент мы и столкнулись.

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

Если ваше приложение зависит не только от локального времени, но и от его представлении в других часовых поясах, вы наверняка сталкивались со сложностью представления времени в разных временных зонах. Не сталкивались? Значит вы не портировали своё приложение в мир Unix.

Действительно, в ОС Windows для работы с временными зонами программисту предоставляется удобный набор специализированных функций WinAPI. Примером могут служить структура TIME_ZONE_INFORMATION и функция GetTimeZoneInformation к ней в придачу.

Но что делать, если вам необходимо знать смещение относительно UTC+0, правила перехода на «летнее время», учитывать при этом високосные годы с високосными секундами и прочую специфическую информацию для какого-нибудь региона, да всё это в unix-подобных операционных системах? Статья посвящена практике работы со всем этим барахлом на языке C/C++.

Примерно год назад я всерьез задумался над недавно пошумевшими на хабре темами про ненависть к html. Действительно, html — это просто средство разметки текста, его нельзя применять для построения UI, который на 90% состоит из layout'ов. Вернее можно, но получается ад. Кроме всего прочего, случай с html — это когда данные смешиваются с представлением. Не получится скачать отдельно html, а отдельно данные. Возникает идея парсеров.

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

На мой взгляд, единственная задача html — это отображать br,strong,a, ну и так далее. Нет никакой необходимости пытаться верстать блочно, потому что блочная верстка — это попытка средставми html сделать layout. И вся эта идея иерархичности блочного контента рассыпается в пыль, когда child вылезает за пределы parent'a. Кому в голову вообще пришла такая издевательская над инкапусяцией идея, почему это вообще ВОЗМОЖНО? WYSIWYG с точки зрения кода какой-то странный получается — видишь один код, а отображаться он может как и где угодно. Зачем нужна эта двусмысленность?

И не получится сделать сложный блочный ui без костылей вида -999px и т.д. Кстати, почему до сих пор нет нативной поддержки layout'ов? Уже на языке низкого уровня быстрее описать интерфейс, чем на вебе. И заметьте: каждый дизайнер изголяется над созданием/стайлингом/размещением контролов, которые уже ДАВНО есть в ЛЮБОЙ ОС. Так зачем столько телодвижений для создания такого же, но другого? Чтобы что? Кстати, а для чего каждый сайт должен иметь уникальный дизайн? Разве это чем-то вынуждено? Почему desktop ui с одинаковыми контролами не приедается, а шибко пестрые-нестандартные интерфейсы на десктопе считаются моветоном? Ну да, можно написать еще штук 20 шаблонизаторов, позволяющих абстрагироваться от печальных реалий. А дизайнеры пускай сами своими -99999px гвоздями прибивают ui к html.

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

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

7 марта прошлого года W3C, после 10-летнего перерыва, возобновила работу над HTML.

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

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

Я решил выложить их в виде статьи, переработав и снабдив иллюстрациями и примечаниями.

Содержание:

1. Вступление
2. Сценарии гибели
   • Гибель ментальная, или HTML — новый ассемблер
   • Гибель физическая, или HTML — новый Turbo Pascal
3. Все ли так серьезно?
   • Ментальной гибели не будет, если web-технологии будут правильно поняты
   • Физической гибели не будет, если web-технологии будут развиваться
4. Заключение
5. Примечания

В настоящий момент мир вступает в эпоху расцвета богатых web-приложений.

Программы, работающие через Веб, все больше вытесняют традиционные десктопные приложения. Gmail, Google Map, online-офис, даже web-операционные системы… Список можете продолжить сами.

Однако, по мере продвижения web-приложений, все больше возрастают требования к основным клиентским web-технологиям: xHTML, CSS, JavaScript.

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