— Здравствуй *с широко развевающейся по лицу улыбкой* дружок.
 — Ваа! *с ярким блеском в широко распахнутых глазах* Тётя Ася приехала!
 — Да, и у меня есть для тебя новая сказка *присела и взяла малыша за руки* хочешь послушать?
 — Конечно! *слегка смутился и отвёл взгляд* Мне тут дядя такие страшные истории рассказывал…
 — Ну, надеюсь моя история тебя не испугает *потрепала его по волосам* Она должна научить тебя мыслить шаблонно.
 — Эээ? *лицо перекосилось от недопонимания* Это как?
 — М… сейчас узнаешь *подмигнула и взяла на ручки* Вот когда тебе нужно вставить переменные в строку — ты как поступишь?
 — Ну… *взял карандаш и чирканул на лежащей рядом бумажке* примерно так:

var query= 'xxx'
var resultCount= 512
var message= 'По запросу <kbd>' + query + '</kbd> найдено страниц: ' + resultCount

 — Ты ничего не забыл? *победоносно подняла голову*
 — Да вроде нет… *уткнулся носом в код, ещё раз внимательно его проверяя*
 — Что, если пользователь введёт… *выдержала многозначительную паузу и добавила*

CSS может связываться с HTML элементами используя любые из его атрибутов. Вы наверняка знаете о классах и ID. Проверим это в HTML:

<h2 id="first-title" class="magical" rel="friend">David Walsh</h2>

Этот один элемент имеет три аттрибута: ID, class и rel. Для выбора элемента в CSS вы можете использовать селектор ID (#first-title) и селектор class (.magical). Но знаете ли вы, что можно использовать для выбора атрибут rel? Это так называемый селектор атрибута:

h2[rel=friend] {
  /* woohoo! */
}

Хочу поднять вопрос, который, как мне кажется, никто не рассматривал ранее системно. Вопрос звучит так:

как называть узлы и интерфейсы узлов в сети?

Для начала обрисую суть проблемы: когда у вас 2-3-5-10 серверов, то их названия, адреса и т.д. вы быстро запоминаете, и особой путаницы они не вызывают. Но если у вас несколько тысяч серверов (добавим к реальным ещё виртуальные), если у вашего маршрутизатора несколько сотен реальных или виртуальных (в виланах) интерфейсов, каждому из которых нужно дать имя (хотя бы для PTR/A записей в DNS), когда у вас есть интерфейсы для конфигурирования коммутаторов, принт-серверов, сетевых принтеров… В этих условиях нужно реально садиться и думать, как их называть. Лучше садиться думать до того, как начали называть, чем после.

Итак, сегодня мы соберём генератор миниатюрок на базе любимого народом веб-сервера — nginx-а. Что примечательно, сделаем мы это без единого гвоздя, т.е. без единой строчки кода, не считая конфигурации.

Приветствую всех. Не так давно у нас с женой была первая годовщина свадьбы и я сделал ей первый подарок своими руками. Решил поделится идеей и её реализацией, время до 8 марта еще есть :)

Публикации о высокотехнологичных подарках (см. Ссылки [1] и [2]) вдохновили меня на создание собственной хрени прикольной вещицы.

Прежде чем приступить к практике, зададимся некоторыми весьма интересными вопросами: почему консоль, зачем использовать видеокодек Ogg Theora, каким образом и с какими параметрами лучше конвертировать видео.

Начнём с матчасти:

Видеокодек — это программа/алгоритм сжатия (то есть уменьшения размера) видеоданных (видеофайла, видеопотока). Кодек — файл-формула, которая определяет, каким образом можно «упаковать» видеоконтент и, соответственно, проиграть видео. Также возможно кодирование кроме видео и аудиоинформации, добавления субтитров, векторных эффектов и т. п.

На сегодняшний день, самые популярные видеокодеки — это знакомые всем DivX, XviD, H.264, WMV, Apple QuickTime и множество других. Ogg Theora всегда была в тени своих коллег и на то, видимо, были какие-то свои причины. Может быть потому, что это относительно новый кодек (он появился только в 2004-м году), может потому-что он изначально ориентировался на применение в интернете, а не для кодирования видеофильмов… Это уже не важно.

Бесплатные решения Mozilla Foundation под Windows для электронной почты и интернета уже давно используются в нашей организации — функциональные, удобные и относительно стабильные.
И всё бы ничего — но рано или поздно встает вопрос об автоматизации обновления этих продуктов.
Пробороздив просторы интернета, удалось узнать, что существует несколько интересных способов обновлений.
Один из них — создание собственного сервера обновлений — в общем всем хороший способ, но с ходу не получилось с ним разобраться (если у кого-то есть опыт — делитесь!). Доступно по ссылке.
Я же расскажу про другой способ.

Выпущена новая версия Google Earth.

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

Начиная с версии 5.1 mySQL поддерживает горизонтальное партицирование таблиц. Что это такое? Партиционирование (partitioning) — это разбиение больших таблиц на логические части по выбранным критериям.. На нижнем уровне для myISAM таблиц, это физически разные файлы, по 3 на каждую партицию (описание таблицы, файл индексов, файл данных). Для innoDB таблиц в конфигурации по умолчанию – разные пространства таблиц в файлах innoDB (не забываем, что innoDB позволяет настраивать индивидуальные хранилища на уровне баз данных или даже конкретных таблиц).

Как это выглядит?

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

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

Итого, нам нужно грузить в дополнение к данным страницы: скин с константами и стили с формулами. Только две клиентские технологии позволяют сделать это: JS и XSLT. Однако первую очень любят отключать, а вторую отключать просто нет смысла. Поэтому вынесем CSS в XSLT контейнер, а заодно и не забудем про технологию XHTML-инклудов.

Marak Squires выпустил в свет JSLINQ — реализацию LINQ для JavaScript, работающую как на стороне браузера, так и на стороне сервера (к примеру, node.js). Поддерживаются такие конструкции, как JOIN, UNION, RANGE, DISTINCT, COUNT etc.

Смотрите:

• Код и примеры на GitHub;
• Живая демонстрация на сайте автора.

Зачастую пользователям и системным администратором необходимо отслеживать, к каким файлам обращается приложение. В Linux-е уже есть все средства для этого, и тем удивительнее постоянно слышать на форумах — есть ли аналог Sysinternal Filemon. В данной статье я опишу использование утилиты strace, и рассмотрю ряд моментов, которые ускользают от некоторых пользователей, полагающих, что приложениям надо ограничивать права даже на чтение, например, ограничить доступ mplayer-а только к показываемому фильму.

Аннотация
Введение
1. auto
2. decltype
3. Ссылка на временный объект (R-value reference)
4. Правые угловые скобки
5. Лямбда-функции (Lambdas)
6. Suffix return type syntax
7. static_assert
8. nullptr
9. Новые стандартные классы
10. Новые направления в развитии статических анализаторов кода
Заключение
Библиографический список

Аннотация

В статье рассмотрены новые возможности языка Си++, описанные в стандарте C++0x и поддержанные в Visual Studio 2010. На примере PVS-Studio рассмотрено, как изменения языка отразятся на инструментах статического анализа кода.

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

Сразу скажу, что получение денег на пластиковую карту без уплаты налогов может вылиться в серьезные проблемы (про ответственность написано в конце топика). Объяснения, что деньги «от бабушки внучку на мороженное» при суммах больше 10К$ в год уже не прокатывают, особенно если в реквизитах «бабушки» будет стоять что-то вроде «GMBH Star Development» Вероятность того, что возьмут за задницу достаточно высокая и поэтому лучше не рисковать и делать все по Закону, тем более, что ничего сложного в этом нет

Сегодня я хотел бы рассказать об одном из способов создания приложения, имеющего один экземпляр — библиотека LibUnique.

Очередное эссе из разряда «нечеткой логики».

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

Вообще, это интуитивное понятие — атмосфера — и поэтому описать его строго сложно. Это скорее ощущение. Атмосферы бывают сильные и слабые, доброжелательные, враждебные, тоскливые и т.д. Это что-то вроде внутреннего настроя и состояния нескольких человек. Чем больше народу в одной атмосфере, тем она сильнее. Яркий пример: похороны. Все находятся в состоянии подавленности и грусти, даже если не очень этого хотят!

Есть несколько важных моментов:
1. Атмосферу можно создать в-одиночку
2. Атмосферу можно «сломать»
3. Деструктивные атмосферы имеют свойство самоусиливаться (например, агрессивная толпа)

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

Разберем несколько примеров.

ГАИшник. (Мой любимый пример.)
Ситуация первая: вас тормозит на посту работник ГАИ. Ваши эмоции? Если вы торопитесь часто возникает мысль «Какого фига! Я же ничего...», она перерастает в раздражение, которое трудно скрыть и это чувствует ГАИшник. Теперь поставьте себя на его место: было бы вам приятно если бы вас на работе ни за что ни про что поливали эмоциональной грязью (раздражение я считаю именно такой субстанцией)?

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации

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

Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

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

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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