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

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

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

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

Итак, у нас есть свежеустановленная по инструкции Beginners' Guide система ArchLinux с окружением Gnome 3. Логинимся, осматриваемся. Мое и не только мое мнение — очень непривычно и неудобно. Столкнувшись с рядом проблем подумывал о бегстве на KDE, но посидев на форумах и арчивики пару дней довел все до удобного мне вида. Вот только на доработку системы требуется от силы пол часа, а те почти два дня ушли на поиск способов решения появившихся проблем. Сейчас я постараюсь сделать краткий и емкий список решений для популярных проблем, без лишних картинок и слов, дабы сэкономить другим и себе из будущего (который забудет как это все делается) время. Посмотреть «большую картинку» можно тут.

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

PHPUnit содержит расширение для тестирования базы данных. Расширение выполняет следующие функции:

• перевод базы данных в заранее известное состояние,
• выполнение необходимых модификаций данных,
• проверка, что в базе данных созданы ожидаемые записи.

К сожалению в этом списке отсутствует одна очень нужная нам фича — восстановление данных в состояние, в котором они находились до тестов. Я хочу предложить 2 варианта решения этой проблемы. Так же попутно остановлюсь на проблеме внешних ключей, которая часто возникает при накатывании не полных тестовых данных на «рабочую» базу.

Итак, я предлагаю 2 варианта решения проблемы: как после проведения юнит теста вернуть базу данных в исходное состояние:
Первый путь — «Транзакционный». Суть которого сводится к выполнению всего теста в рамках одной транзакции, и последующему rollback'у транзакции.
Второй — Перед выполнением теста скопировать структуру «рабочей» базы и проводить тестирование на ней.

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

Поговорим о случае, когда нужно автоматизировать запуск тестов и сбор статистики покрытия, к примеру, для гипотетической клиентской JS библиотеки. Задача не совсем тривиальна, поскольку для нормальной работы библиотеки требуется полноценный браузер — библиотека является визуальной оберткой над стандартными компонентами формы. Библиотека должна быть написана так, чтобы все взаимодействие с ее объектами можно было производить с помощью методов, которые они предоставляют, а не только через непосредственные манипуляции с DOM (т.е. любое действие юзера может быть запущено не только событием, допустим, клика по чему-то, но и руками через метод). Но тем не менее, надо этот DOM иметь, чтобы результаты работы методов помимо изменения внутреннего состояния объектов также отображались и в DOM. В целом напоминает приложения на Sencha (ExtJS).

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

Введение

Недавно я описывал созданную мной систему мониторинга транзитного VoIP методом прогнозирования. Самым сильным плюсом данного метода в задаче мониторинга транзитного VoIP является то, что нет необходимости выставлять критерии того, что считать нормальной работой величин, находящихся под мониторингом, а что – потенциальным сбоем.
Ядром системы является rrdtool, в котором реализованы прогнозирование методом Хольта-Винтерса и механизм выявления аберраций.
Мониторинг методом прогнозирования можно использовать не только для VoIP, но и для любого другого типа трафика, а так же, для величин, которые изменяются во времени с некой прогнозируемой цикличностью. В отличие от стандартных методов, при мониторинге с помощью прогнозирования не осуществляет мониторинг состояния величин, находящихся под мониторингом, зато осуществляется мониторинг динамики изменения их состояний во времени.
Если вам интересна математика прогнозирования рекомендую прочесть. Чтобы быть хоть немного в курсе темы, прочтите главу “Метод прогнозирования реализованный в rrdtool” моего предыдущего поста.

Так вышло, что в офисе я работаю за Маком, а вот ноут — «17 MacBook Pro — не самый лучший, на мой взгляд, вариант в разрезе производительность/цена. Anyway, это тема другого разговора. Ноут под Ubuntu.
А теперь вопрос: если кодить на Ruby/RoR — кто ваш лучший ТекстовыйПриятель? Все верно, Textmate — Великий Фетиш и Идол всех программистов на Ruby под Mac. Итак задача была предельно проста — найти инструмент под Linux, максимально приближенный к Textmate по тому объему функционала который я использую в работе.

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

«Я понял одну нехитрую истину. Она в том, чтобы делать чудеса своими руками.»
© А. Грин «Алые Паруса»



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

Жизнь была прекрасна и все было в этом мире хорошо, пока почта с моего сайта не стала активно посылаться в спам практически всеми крупными почтовыми серверами. Особенно усердствовал в этом Gmail. Частенько меня принимали за спамера в Yandex, реже в mail.ru и rambler.

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

Часто приходится «насыщать» интерфейсы с помощью JavaScript. В основном работаю через jQuery, всё нравится, но одна беда – валидация. Постоянно приходится изобретать «велосипед», искать в сети обрывки кода; а ведь хочется написать пару строчек без углубления в детали. Радость не заставила себя ждать: нашёл библиотеку Valid8 (произносится как validate), и, наконец, решил проблему написания кода валидации.

Как пользоваться

Пользоваться библиотекой оказалось очень просто, чего не скажешь о склеивании jQuery «обрезков» из интернета. Чтобы подключить библиотеку, нужно зайти сюда и нажать заветный Download. Скачается архив, в котором особый интерес представляет файл jquery.valid8.js, его копируем в папку с js файлам нашего проекта и подключаем библиотеку в html:

<script src="/js/jquery-1.6.3.js" type="text/javascript" charset="utf-8"></script>
<script src="/js/jquery.valid8.js" type="text/javascript" charset="utf-8"></script>

Допустим у нас есть форма:

<form><ul>
<li><input type="text" id="inputSome" /></li>
</ul></form>

Добавляем валидацию (по умолчанию только проверка обязательности заполения), передавая в качестве параметра строку с сообщением об ошибке. Работаем в стиле jQuery:

$('#inputSome').valid8("Заполни это поле!");

После того как поле получит фокус и вы из него выйдете не заполнив, объемлющий тег (в нашем случае li) получит класс стиля error.
Для визуализации ошибок добавим CSS в head нашего документа:

<style>
.error input { background:pink; }
</style>

Валидация готова. Все.

При наличии большого количества статистических данных, например таких, как котировки валют (и прочие данные, связанные с финансовой тематикой), потребление чего-либо (воды и т.д.), вообще говоря, любых данных, которые так или иначе можно представить в виде пары «дата — значение», бывает удобно представить их в графическом виде. Так как данные могут быть собраны за достаточно большой период времени, имеет смысле представлять их в виде пары графиков: «мастер»-график, на котором будут отображены все точки, и график «детали», где будут отображены точки за требуемый период. В данной статье я постараюсь рассказать, как построить график подобного типа при помощи стандартных средств библиотек HighCharts и jQuery UI.

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

Есть задачи, которые в рамках реляционных СУБД не имеют универсальных решений и для того чтобы получить хоть какой-то приемлемый результат, приходится придумывать целый набор костылей, который ты потом гордо называешь “Архитектура”. Не так давно мне как раз встретилась именно такая.

Предположим, имеется некоторые сущности А и Б, связанные между собой по принципу One-to-Many. Количество экземпляров данных сущностей достаточно велико. При отображении сущностей для пользователя необходимо применить ряд независимых критериев, как для сущности А так и для сущности Б. Причем результатом применения критериев являются множества достаточно большой мощности — порядка нескольких миллионов записей. Критерии фильтрации и принцип сортировки задается пользователем. Как (я бы ещё спросил: Зачем им миллионы записей на одном экране? — но говорят надо) показать все это пользователю за время 0 секунд?
Решать такие задачи всегда интересно, но их решение сильно зависит от СУБД, под управлением которой крутится твоя база данных. Если у тебя в рукаве козырной туз в виде Oracle, то есть шанс, что эти костыли он подставит сам. Но спустимся на землю — у нас есть только MySQL, так что придется почитать теорию.

Nodeload, первому проекту команды GitHub, выполненному с использованием node.js, недавно исполнился 1 год. Nodeload, — это тот сервис, который упаковывает содержимое Git-репозитория в ZIP-архивы и тарболы. С тех пор нагрузка на сервис росла в течение года, и мы столкнулись с различными проблемами. Почитайте о происхождении Nodeload, если вы не помните, почему это работает так, как работает сейчас.

По существу, у нас стало слишком много запросов, проходящих через один сервер nodeload. Эти запросы запускали процессы git archive, которые запускали SSH-процессы для общения с файловыми серверами. Эти запросы постоянно записывали гигабайты данных, а также передавали их через nginx. Одной простой идеей было заказать больше серверов, но это создало бы дубликат кэша заархивированных репозиториев. Я хотел избежать этого, если возможно. Итак, я решил начать все сначала и переписать Nodeload с нуля.

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

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

Создан Юргом Лени и Джонатаном Пакей, Paper.js является фреймворком сценариев векторной графики с открытым исходным кодом, который работает поверх HTML5 Canvas. Он предлагает чистый Scenegraph / DOM и много ярких функций, для создания и работы с векторной графикой и кривыми Безье.

Paper.js основана на и в значительной степени совместимы с Scriptographer, средой сценариев для Adobe Illustrator, первоначально разрабатывающаяся Юргом и Джонатананом более чем 10 лет.

Как и было обещано, мы выпускаем под LGPL нашу библиотеку эмуляции эмулятора терминала linux, которую мы используем для показа консолей виртуальных машин в облаке. Называется она, соответственно, pyte (PYthon Terminal Emulator).

По нашим собственным оценкам, покрытие «текстового» функционала console_codes приближается к 100% (от 80 до 90%, как подсказывают пессимисты из числа оппортунистов среди разработчиков).

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

Зато реализованы все остальные сложные функции, такие, как блокировка регионов экрана для записи, скроллинга, управление режимами переноса строк, правильная обработка атрибутов при различных видов удаления текста и т.д. — всё то, что нужно существующим приложениям, таким как nano, adom (на картинке фрагмент ESC-кодов и получающегося изображения как раз из ADOM'а), vim, emacs, mc, aptitude, dialog, yast2 и т.д. для полноценной отрисовки.

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

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

История создания

Демонстрируем некоторые особенности написания TeX-макросов, встраивая в TeX калькулятор теоретико-числовых функций.

Постановка задачи

Время от времени мне приходится набирать очередной текст, сопровождаемый примерами вычисления теоретико-числовых функций: функция Эйлера φ, функция делителей τ, функция Кармайкла λ. Раньше это делалось так: запускаем любимый калькулятор (мой выбор — PARI/GP), в нем все считаем и копируем выкладки в ТеХ. Изменились исходные данные — снова в калькулятор и обратно. Много возни, много шансов забыть заменить какой-то промежуточный результат. Да и просто мышкой махать надоедает. Хочется автоматизировать этот процесс хотя бы для самых распространенных функций, чтобы можно было написать

$\phi(1001)=\Phi(1001)$

и получить на печати

О проекте

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

Введение

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

Я хочу рассказать о том, как собрать такую штуку дома.

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

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

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