Хаброюзер allan_sundry во флейме про ботнет под Mac OS X не поверил, что недавняя уязвимость в Linux-овом udev действительно широка, глубока и в ряде случаев даже опасна. В ответ я решил написать этот топик, демонстрирующий, что создать рабочий эксплойт для опубликованной уязвимости нередко может даже фриланствующий студент-недоучка, потратив пару-тройку часов воскресным вечером.

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

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

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

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

Начнем с построения пропорции. Возьмем отрезок AB.



Примем его за радиус и построим окружность с центром в A.



Теперь построим вторую окружность с тем же радиусом, но с центром в B.



У нас получилась фигура ACBD, имеющая огромное значение для наших предков. Она называется Vescica Piscis (пузырь рыбы). Самый простой и важный пример — она давно является символом христианства.



Я продолжу под катом. Спорим, никогда не догадаетесь чем там все закончится :)

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

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

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

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

Содержание

1. Дефисы, тире, минусы и другие палочки
2. Кавычки и чёрточки
3. Скобки
4. Многоточие
5. Заголовки, списки

Данный обзор написан специально для SEO Digest — популярного онлайн-журнала среди вебмастеров и поисковых оптимизаторов. Публикуемые в нем материалы рассчитаны на широкую аудиторию пользователей: от профессионалов Рунета до любителей и начинающих. Журнал доступен в PDF и онлайн версии.

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

Основные положения

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

• База данных
• Компиляция серверных скриптов (PHP)
• Статические страницы
• Клиентская составляющая

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

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




Но знаем ли мы почему возникли именно такие пропорции? Какой смысл в них закрыт? Что видели древние и почему упорно применяли их для создания произведений искусства, особенно, носивших религиозный смысл?



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

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

Под катом я еще немного ее обрисую.

Перевод статьи Эрика Синка (Eric Sink) — DVCS and DAGs (Part 1 and Part 2).

Прим. переводчика: В этой статье я буду ис­поль­зо­вать ори­гиналь­ные анг­ло­языч­ные сокращения DVCS и DAG для обозначения расп­ре­делён­ных систем контроля версий (Distributed Version Control System — DVCS) и нап­равлен­ных ацикличных графов (Directed Acyclic Graph — DAG).

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

MailLink

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

Конечно у него есть и свои минусы:

1. адрес будет показываться только при всключенном JavaScript
2. если у робота есть поддержка JS, то он может распознать скрываемый e-mail

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

Создать графический примитив и анимировать его, например передвинув его с точки А в точку В с постоянной скоростью – дело нехитрое. Но что если нужно расположить несколько объектов в определенной последовательности и потом их нелинейно анимировать? Для этого ни в WPF ни в Silverlight нет встроенных функций. В этом очерке я покажу, как можно создавать объекты и анимацию динамически, используя лямбда-делегаты и функции высшего порядка.

Memcached community предприняло немало попыток написать «родные» патчи для кода memcached, добавляющие в него поддержку тэгов. Наиболее известный из таких патчей — проект memcached-tag. К сожалению, memcached-tag все еще очень далек от стабильной версии: нетрудно написать скрипт, приводящий к зависанию пропатченного memcached-сервера. Похоже, на момент написания данной статьи не существует ни одного надежного решения проблемы тэгирования на уровне самого memcached-сервера.

Библиотека Dklab_Cache

Dklab_Cache — это (в основном) библиотека поддержки тэгирования ключей для memcached, использующая интерфейсы Zend Framework. Сама библиотека написана на чистом PHP. Вот полный список возможностей библиотеки:

• Backend_TagEmuWrapper: тэги для memcached и любых других backend-систем кэширования Zend Framework;
• Backend_NamespaceWrapper: поддержка пространств имен для memcached и др.;
• Backend_Profiler: подсчет статистики по использованию memcached и др. backend-ов;
• Frontend_Slot, Frontent_Tag: каркас для высокоуровневого построения систем кэшиирования в сложных проектах.

Собственно, для поддержки тэгов имеется класс TagEmuWrapper. Он представляет собой декоратор («обертку») для backend-классов кэширования Zend Framework. Другими словами, вы можете с его помощью «прозрачно» добавить поддержку тэгов в любую подсистему кэширования Zend Framework. Мы будем рассматривать backend для работы с memcached: Zend_Cache_Backend_Memcached, но, если в вашем проекте используется какой-то другой backend-класс, вы можете подключить тэгирование и к нему без каких-либо особенностей.

TagEmuWrapper реализует стандартный backend-интерфейс Zend_Cache_Backend_Interface, поэтому с точки зрения вызывающей системы он сам является кэш-backend'ом. Вообще, Zend Framework хорош тем, что на уровне интерфейса он поддерживает тэги с самого начала! Например, в методе save() уже имеется параметр, позволяющий снабдить ключ тэгами. Однако ни один из backend-ов в составе Zend Framework тэги не поддерживает: попытка добавить тэг к некоторому ключу вызывает исключение (в частности, для Zend_Cache_Backend_Memcached).

Технические подробности, документацию, а также примеры использования можно посмотреть тут: dklab.ru/lib/Dklab_Cache

Что такое тэги?

Работа с типичной кэширующей системой (в том числе с memcached) заключается в выполнении трех основных операций:

• save($data, $id, $lifetime): сохранить данные $data в ячейке кэша с ключом $id. Можно указать «время жизни» ключа $lifetime; спустя это время данные в кэше «протухнут» и удалятся.
• load($id): загрузить данные из ячейки с ключом $id. Если данные недоступны, возвращается false.
• remove($id): очистить ячейку кэша с ключом $id.

В этой статье я проиллюстрирую основные возможности Ruby для построения Domain Specific Languages(DSL). DSL, это небольшие, узкоспециализированные языки для решения конкретных задач. В отличие от языков общего назначения, таких как C++ или Java, DSL обычно очень компактны, и обладают высокой выразительностью в контексте решаемой задачи.

Различные DSL широко распространены в библиотеках и фреймворках для Ruby. Например в Rails DSL используются для создания миграций.

А теперь, давайте посмотрим какие возможности Ruby предоставляет для построения DSL

Какое-то время назад мне по работе пришлось провести небольшое исследование. Суть его состояла в поиске наилучшего pdf-парсера реализованного на java.

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

Долгое время документы парсились при помощи библиотеки PDFBOX, работа которой не вызвала ни у кого радости: долго и со сбоями.
В итоге были выбраны 4 библиотеки, сравнением которых я занялся: PDFBOX, JPod, iText и Acrobat.

Ruby — это гибкий язык, позволяющий создавать на своей основе различные DSL. Появилась идея написать DSL для SQL-запросов (для SELECT'ов), максимально приближенный к оригиналу. Кажется, получилось. Получившаяся штука называется Boroda. Далее следуют примеры кода.

require 'boroda'

sql = Boroda.build do
  from :posts, :users
  select posts.*
  where (posts.author_id == users.id) & (users.name == 'Vlad Semenov')
end

Получим:

SELECT posts.*
FROM posts, users
WHERE (posts.author_id = users.id) AND (users.name = 'Vlad Semenov')

Если кто не понял — мы пишем SQL-запросы на чистом Руби. Теперь попробуем что-нибудь посложнее.

В данной статье автор Steve Souders приводит наглядные доказательства, почему не стоит использовать import для загрузки стилей в документ.

LINK vs. import

Существует 2 способа загрузки файлов стилей. Использовать тег LINK:

<link rel='stylesheet' href='a.css'>

Или импортировать файлы с помощью import:

<style>
@import url('a.css');
</style>

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

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

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

Допустим, что она должна выглядеть примерно так:

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

После небольшого исследования выяснилось, что не всегда данный размер возможно получить обычными способами. Будь то методы jQuery, prototype или обычное обращение к параметрам DOM.

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

0. Присказка

В некотором царстве, в некотором государстве жил-был программист. Звали его, как полагается, Иван. Был он настоящим спецом, обладал всеми Тремя Великими Добродетелями Программиста, то есть был ленив, спесив и нетерпелив. Случилась в том царстве печаль великая: кризис. И выгнали Ваню с работы без выходного пособия. Горевал Ваня долго, а потом собрался с духом и разослал резюме по всему белу свету. Долго ли, коротко ли, вызвали Ваню на собеседование. Требований к соискателю было много, но главное — требовалось хорошо владеть регулярными выражениями. До собеседования — почти месяц, готовься — не хочу. Будучи человеком серьёзным, готовиться Иван решил обстоятельно. 3 недели и 3 дня он лежал на печи, почитывал Хабр и думал, как же неслыханно обстоятельно он будет готовиться. До собеседования остался 1 день. Ванюша мысленно обругал работодателей, которые назначают собеседование так скоро, что совсем подготовиться не успеваешь, слез с печи, сдал пивные бутылки и на вырученные деньги купил книжку по регексам. Читал он её до полного изнеможения, пока не отключился. Утром мы найдём сонную физиономию Ванюши лежащей, как на подушке, на этой самой книжке под Хабракатом.