livedev.org

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

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

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

• лестница с удобным поручнем;
• специальный заезд для детских и инвалидных колясок в общественных местах;
• наличие брайлевских надписей на кнопках банкомата;
• полное ручное управление в автомобиле.

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

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

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

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

• Слепая художница Лариса Павлова;
• Слепой фотограф Evgen Bavcar;
• Художник рисующий ртом Александр Верейнов;
• Барабанщик Rick Allen (Def Leppard), играет на ударной установке одной рукой;

Полный список известных людей с различными инвалидностями и болезнями (англ.) на www.reddisability.org.uk.

Еще впечетляют картинки из google images — disabled artists.

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

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

1. UI-patterns — коллекция типовых решений (примеров) и скриншотов для создания веб-интерфейсов. Хорошо отсортирована. Будет полезна для вдохновения или поиска готового решения.

2. Quince UX Design Patterns Listing — еще одна подборка подобная предыдущей, но тут более детальное описание каждого примера и дополнительные иллюстрации.

3. UX Booth — блог о юзабилити и вообщем интерфейсах. Проводят периодически публичное юзабилити–тестирование разных сервисов и пишут критику.

4. Product Planner — онлайн–сервис, позволяющий группе разработчиков описывать движение (навигацию) по страницам сайта (user flow на буржуйском). Сервис этот не сложный, функционал довольно ограниченный, но со своей узкой задачей справляется отлично.

5. I ♥ wireframes — блог сербской девушки веб-дизайнера, собирающей фотографии и скриншоты wireframes (не знаю как перевести) и процесса их создания, которые используются для прототипирования интерфейсов. Хороший ресурс для вдохновения, особенно если вы еще толком не пробовали проектировать интерфейсы.

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

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

Ну кого я удивлю такой темой? Удивлять не буду. Все знают про твиттер! Нет? загляните тогда в гугл.

А написать я хочу про несколько правил, которым следую публикуя информацию в твиттере и общаясь в этой среде. Оговорюсь про терминологию. Хорошее английское слово follow трудно перевести удачно в контексте твиттера, поэтому я буду употреблять слово «френдить», такой себе ЖЖ-шный слэнг :-)

1. По каким критериям я оцениваю френдить человека или нет:

   • на сколько часто он пишет (для меня оптимально читать не больше 10 твитов в день от каждого френда);
   • тематика само-собой, но важнее интересная подача и оригинальный контент;
   • если у него число читателей меньше хоть в половину, чем число людей кого он читает, настораживает;
   • больше хочется читать человека, пишущего свое, с меньшим кол-вом ответов на чужие твиты (reply);
   • интересный профайл и ссылка на персональный веб-сайт — самый главный критерий, пожалуй.

2. Про что пишу сам:

   • веб-разработка (еще бы!);
   • фотография;
   • mac/unix;
   • немного личного.

Так что если мы еще не френды в твиттере, напишите мне :-)

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

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

Об одном из таких компромиссов я хотел бы сегодня рассказать. Любой веб-разработчик знает про существование веб-стандартов, придуманных, как и любой стандарт, для облегчения работы и координации множества людей при выполнении схожих или одинаковых задач. Весь веб построен на стандарте HTML, и я думаю, что 99% веба работает с использованием CSS. HTML и CSS — две главные технические составляющие дизайна любого веб-сайта. Но как известно, мало кто из дизайнеров пользуется веб-стандартами (HTML/CSS) для создания дизайна, у них есть свои инструменты (графические редакторы) для решения этой задачи.

Процессом превращения картинок дизайна в HTML/CSS представление занимаются как раз выше упомянутые веб-разработчики, процесс этот называется версткой.

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

Перехожу к сути. Для настройки стиля (читай дизайна) HTML-документа в веб-стандартах предусмотрено использование CSS. Часто возникает ситуация, при которой в HTML документ попадает избыточное кол-во элементов, которые не несут никакого содержимого для пользователя, а используются только в CSS для придания стиля/дизайна документу. Это некорректно с точки зрения семантики HTML. Но это не так страшно. Более серьезная проблема в том, что частенько приходится нарушать сам стандарт разметки документа (HTML) ради придания ему определенных стилей (через CSS). Профессионалы называют это на сленге «невалидный код», от английского «valid — верный, корректный».

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

Так вот теперь о компромиссах. Есть еще не упомянутая сегодня веб-технология JavaScript. С помощью JavaScript и DOM можно в момент загрузки страницы браузером корректировать ваш код. В нашем случае интересует именно HTML. Так вот это и есть простой и эффективный компромисс, модифицировать готовый корректный HTML с целью добавления элементов, которые используются чисто для дизайна. При относительно небольшом кол-ве таких элементов, скорость загрузки/отображения страницы для пользователя останется незаметной.

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

PS: статья получилась довольно общая и возможно не совсем интересная для «бывалых», но это только первая статья из серии посвященной веб-стандартам. To be continued...

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

Отпуском думаю это и нужно считать, т.к. в моей жизни произошло очень важное событие, про которое не написать я просто не могу. У меня родился сын — Александр, я третий раз в жизни стал папой. Семейный отпуск — это главная причина, почему я так долго не обновлял этот блог. Мы с Аней уже «вошли в колею», Саша немножко подрос и появилось больше времени заняться своими проектами.

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

Сейчас о блоге. В ближайшем будующем я планирую писать больше про клиентское веб-программирование и построение удобных веб-интерфейсов. В связи с чем есть вопросы к вам, уважаемые читатели. Заполните, пожалуйста, простую форму (по ссылке или прямо на странице ниже), чтобы мне стало понятно, возможно мне стоит завести отдельный блог, где я буду писать про клиентские технологии (frontend), т.к. мне кажется, что текущая аудитория больше интересуется серверным программированием (backend) и в частности Python/Django.

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

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

Почему же я пишу этот пост? Дело в том, что последнее время меня все чаще посещали мысли о смене моей профессии. Нет, не радикально, я все же не хочу пока отрываться от ИТ.

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

После почти двух лет фриланса меня пригласили в мой первый крупный веб-проект. На сегодня я отлично владею как серверным так и клиентским веб-программированием на базе Python (PHP и Perl уже давно в прошлом) и HTML/JS/CSS стэка.

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

1. Пропаганда веб-технологий, стандартов или сервисов. Говоря на заморском языке — Technology evangelist (да, это слово приобрело нехристианский оттенок). Мне нравиться писать, говорить перед аудиторией, знакомиться с новыми людьми и обучать интересующихся. К сожалению мне еще ни разу не попадались подобные вакансии на просторах рунета, даже и на зарубежных job-board они не часты.

2. Работа с людьми. Мне легко находить общий язык, у меня хорошо получается организовывать небольшие команды. Поэтому есть интерес к менеджменту проектов. Давно интересуюсь так называемыми agile методиками работы команды.

3. Дизайн и разработка пользовательских интерфейсов. Это наиболее давнее мое стремление (моей творческой половины), но в нем у меня менее всего опыта. Так получилось, что моя карьера пошла по чисто техническому пути, хотя я все время интересовался дизайном в общем и дизайном веб-приложений в частности. Я довольно хорошо владею графическими программами, отлично верстаю в HTML/CSS и оживляю его с помощью JavaScript. Но мне всегда не хватало практических задач, где бы я мог набраться опыта. Мне бы хотелось попробовать себя в качестве Junior UI/UX designer или взяться за какие-то фриланс-проекты в этой области.

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

Мой имейл: dobrych@gmail.com, резюме пришлю по запросу.

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

PS2: Мне не надоело программировать, просто стараюсь развивать другие свои способности.

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

• Visual Event почетно занимает в этом списке первое место! Отличный JavaScript инструмент, выполненный в виде букмарклета. Позволяет просматривать привязку событий JavaScript к элементам страницы визуально. Поддерживает jQuery, YUI и MooTools. Отличный инструмент для дебага JavaScript. Посмотреть демо.

• JS Bin — следующий инструмент для дебага JavaScript/HTML/CSS, позволяет интерактивно совместно нескольким разработчикам тестировать код. Поддерживает все мажорные JavaScript библиотеки (кроме ExtJS). Описать функционал трудно, попробуйте, в нем легко разобраться или посмотрите видео.

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

• JazzRecord JavaScript ORM — новый проект, один из немногих решивших попробовать реализовать ORM на JavaScript. Проект вполне актуален, т.к. уже есть ряд технологий, где он может быть использован (Adobe AIR, Google Chrome и другие, используещие браузерные базы данных). Синтаксис ORM подобен ActiveRecord из Ruby on Rails.

На момент выхода версии 1.0 Django, одним из самых значительных изменений стал механизм загрузки (upload) и хранения (storage) файлов. Загрузка файлов без FileField в модели базы данных конечно очень редкий случай, поэтому начнем именно с одного из обязательных параметров FileField — upload_to.

Главная инновация — это гибкая возможность настройки этого самого upload_to. Раньше можно было только передавать строку с кодированными strftime параметрами. Тем самым можно было разбивать загруженные файлы по директориям, создаваемыми по дате, типа uploads/mp3/2008-12/uploaded.mp3. Сейчас параметром upload_to может быть и callable, т.е. к примеру функция, которая должна возвращать полный путь с именем файла, куда будет сохраняться загруженный файл. Функция должна принимать два параметра: instance и filename.

• instance — это экземпляр объекта модели, которой и принадлежит поле с типом FileField.
• filename — юникодное имя файла.

Эта функция будет запускаться перед сохранением в базу, поэтому если объект новый (вы не редактируете существующий объект, а создаете новый), то поле pk/id будет пустым и соотвественные Django сигналы еще не выполнены. Думаю, что с примером кода все будет наиболее хорошо понятно.

Итак функция-callback, которую мы будем использовать в upload_path:

def make_upload_path(instance, filename):
    """Generates upload path for FileField"""
    return u"uploads/%s/%s" % (instance.category.slug, filename)

Теперь пример модели с FileField:

class Upload(models.Model):
    user = models.ForeignKey(User)
    file = models.FileField(upload_to=make_upload_path)
    category = models.ForeignKey(Category)
    uploaded_date = models.DateTimeField(auto_now_add=True)

Все просто. Можно использовать множество параметров вашей модели для создания директорий и упорядочивания файлов в них. И самое главное upload_to — самый простой способ закачивания файлов с русскими (и другими юникодными) именами. Т.к. по-умолчанию Django заменяет их на символ подчеркивания, что приводит к появлению файлов типа __________.jpg. Если вы сделаете самую простую функцию с вовращением вида return u"uploads/mypath/%s" % (filename), то получите русские имена файлов после закачки.

Официальная документация Django по FileField.

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

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

Чаще всего ищутся разработчики со знанием Python, Ruby и JavaScript. Если вы пишите на PHP, CSS/HTML, хороший управленец, пиарщик или занимаетесь веб-дизайном, также добавьте ваше резюме.

Мои партнеры чаще всего предлагают контрактную работу в западных стартапах или рунет-проектах. Если вы тоже работодатель или вы просто ищите специалиста, пишите мне на личную почту dobrych [at] gmail.com

На сегодня есть две позиции, на которые требуются специалисты с опытом:

• Ruby программисты для разработки и поддержки сайтов, построенных на Rails.
• JavaScript программист с знанием ExtJS.

Последняя свежая информация и анкета для соискателя всегда на странице «Работа и вакансии».

Для работодателей есть возможность размещения баннеров и выделенных объявлений (виджетов).

На пути к 1.0 релизу Django претерпевал немало радикальных изменений. Одно из них рефакторинг системы сигналов.

Если вы первый раз читаете и не в курсе «что это такое и с чем его едят», то скажу в двух словах. Это система реагирования на события приложения. Любой JavaScript или прикладной UI программист хорошо знаком с системой событий (event) — клик мышкой, нажатие горячей клавиши и т.п. Для программистов серверной части веба все выглядит немного по другому. Есть HTTP-запрос и есть его обработчик, анализируется как правило URL на предмет «кому отправлять запрос». Но на самом деле это та же система сигналов-событий, только узкопрофилированная под обработку HTTP-запросов.

Оказывается серверная часть веб-приложения тоже может, и я уверен, просто должна генерировать намного больший спектр сигналов, чем просто обработку URL и данных запроса. С чем успешно и справляется Django. Теперь немного прозы. Какие же события может ловить Django «из-коробки».

• pre_init — перед запуском метода-конструктора __init__() модели;
• post_init — после выполнения метода __init__() модели;
• pre_save — перед сохранением экземпляра модели в базу;
• post_save — после успешного сохранения экземпляра модели в базу;
• pre_delete, post_delete — перед и после удаления экземпляра модели из базы;
• post_syncdb — генерируется админкой Django после установки нового приложения (INSTALLED_APPS);
• request_started, request_finished, got_request_exception — генерируются при обработке HTTP-запросов;
• template_rendered — генерируется только в режиме тестирования приложения.

Итак сигналы *_init, _*save, *_delete и post_syncdb генерируются системой моделей Django и их можно импортировать из django.db.models.signals. Сигналы обработки HTTP-запросов из django.core.signals. И тестовый template_rendered из django.test.signals.

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

Код модели:

class MimeType(models.Model):
    """
    Mime Types table
    """
    name = models.CharField(max_length=200)
    slug = models.SlugField()

    def __unicode__(self):
        return self.name

class Item(models.Model):
    """
    Main file
    """
    name = models.CharField(max_length=200)
    slug = models.SlugField()
    file = models.FileField(upload_to='files', blank=True)
    mime = models.ForeignKey(MimeType, blank=True, null=True)
    upload_date = models.DateTimeField(auto_now_add=True)

    def __unicode__(self):
        return self.name

    def set_mime(self, mime):
        obj, created = MimeType.objects.get_or_create(name=mime, slug=slugify(mime))
        self.mime = obj

Посмотрите на метод set_mime модели Item. Он создает новый объект MimeType или использует если он уже создан. При этом не сохраняя модель Item. Теперь я пишу функцию-callback, которая будет вызываться по событию сохранения модели Item.

import mimetypes
import os.path

# init mime types dict
mimetypes.init()

def add_mime_type(instance, **kwargs):
    """
    Adding mime-type to uploaded file (for future use).
    Would be called on post-save.
    """
    if not hasattr(instance, 'mime') or not hasattr(instance, 'file'):
        raise Exception("Object %s does not have 'mime' attribute! Can't set mime-type!" % instance)
    if instance.file:
        extension = os.path.splitext(instance.file.path)[1].lower()
        instance.set_mime(mimetypes.types_map[extension])

Итак, функция-callback add_mime_type принимает параметр instance, который является экземпляром модели, сгенерировавшим сигнал (в нашем случае модели Item). Вторым параметром принимает словарь (dictionary). Кстати, это и есть один из моментов обратной несовместимости. После рефакторинга каждая функция-callback должна принимать параметр **kwargs.

Теперь третий самый простой шаг — связывание модели с сигналом. В самом конце файла моделей добавилась строчка:

models.signals.pre_save.connect(add_mime_type, sender=Item)

Теперь перед каждым сохранением объектов Item, будет выполняться проверка и установка Mime-типа.

Кстати, я советую если у вас больше одного сигнала, выносите их в отдельный файл signals.py или можно по-старинке писать в файле моделей (что ИМХО иногда мешает чтению кода).

Почитать про сигналы можно еще в официальной доке: Django Signals и Django Built-in signal reference. Почитать про рефаторинг можно на странице Backwards Incompatible Changes и в соответствующем коммите 8223.

Александр Кошелев тоже немного раньше написал по теме, статья «А вы поймали новые сигналы?» с хорошим примером создания абстрактного сигнала.

«На сегодня все. Вопросы в студию» :-)