Ссылки о веб-разработке за август 2010

Sergey Trofimov: $4800 за 3 баг-репорта.

Sergey Trofimov
$4800 за 3 баг-репорта. - http://googlechromereleases.blogspot.com/2010...
Некто Sergey Glazunov заработал $4800 за 3 найденных бага в chromium. - Sergey Trofimov
а за 625 найденных багов можно стать миллионером! ;) - β-Котэ Шредингера

Четверть внешних ссылок Википедии — битые

Увидев сегодня топик Д'Артаньян и интернет, или работа над проблемой битых ссылок, решил поделиться с вами кое-какой статистикой, собранной при написании моей магистерской диссертации.

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

Оказалось, что 20% ссылок являются нерабочими!

Подробности внутри

Making Sites Look Their Best in Standards Mode

IE has traditionally drawn a 2-pixel border around the content area of a site. This border, drawn as part of the page rather than IE’s frame, affects calculations of distance from the top and left of the page. It also creates a not-so-modern beveled look.

In the fourth Platform Preview, you’ll notice pages running in IE9’s Standards Mode no longer have the border. Here’s a before and after:

Before
webpage with 2px border
After
webpage with no border

Pages that run in legacy document modes will still have a 2-pixel border so that any site calculations dependent on the 2 pixels remain the same as in IE8.

To make sure your site runs in IE9 Standards Mode and gets this and all the other latest features in IE9, use a strict doctype. We recommend the HTML5 doctype (<!DOCTYPE html>) since it’s simple and will put your site in Standards Mode in all current browsers.

John Hrvatin
Program Manager

ГОСТ-овский стиль управления

Многим, кто работал по ГОСТ-19 или 34, или по другим ГОСТ вариациям ЕСКД, этот стиль хорошо знаком. Он значительно отличается от западной "классики", хоть и сам является не меньшей классикой.

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

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

И вот тогда, когда вы не только выставляете "внешний интерфейс" в виде ГОСТ-19, но и сами выдаете задания по его правилам - становится понятна вся его сила и весь смысл.

Это очень простой, чрезвычайно эффективный, и, вероятно, наиболее недооцениваемый стиль из существующих. И этот стиль по настоящему крут. Сейчас разберем его отличительные особенности по практике его применения. Без шелухи и формализма - только суть и дух. То, про что я расскажу - базовые принципы, общие для всех ГОСТ, посвященных организации работ. Однако, если вам хочется определенности - думайте, что я говорю про ГОСТ-19.

Значит, первое, и главное. Единицей планирования в ГОСТ является ТЗ. Техническое задание. Вокруг предназначения и сути этого документа много непонимания. Многие путают его с Requirements Specification.

Так вот, это НЕ Requirement Specification. Начать можно с того, что правильно составленное ТЗ обычно гораздо короче, и в секции "технические требования" содержит в основном ключевые требования, определяющие успех всей рабоы. Почему? Потому, что эта секция - только одна из секций документа, который суть "Задание", а не требования.

Вторая главная секция - поэтапный план работ. Это простая таблица - последовательность этапов выполнения работы. В ГОСТ есть список стадий и этапов, но этот список носит рекомендательный характер. На практике - у вас есть полная свобода в определении количества этапов, их названий, и состава работ.

Итак, что такое "этап"? Этап имеет срок окончания, название, описание результатов этапа, и (наименее важная, информационная составляющая) - перечень видов работ-активностей, которые выполняются в рамках этапа. Если оплата работ сдельная - в этой же таблице стоят суммы за каждый этап, и ТЗ - является приложением к договору подряда.

Почему активности - наименее важная составляющая? Потому, что ГОСТ не содержит никаких инструментов контроля, выполняются на самом деле эти активности, или нет. Этап проверяется по результатам. Точка. А активности - указываются для того, чтобы заказчику было понятно, чем люди заниматься будут, и почему у этапа такие сумма и сроки.

Итак, что такое ТЗ? ТЗ, это комбинация ключевых требований, определяющих успех работ, и поэтапного плана данных работ. ТЗ - это единица планирования. Это не "требования". Это - задание.

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

Ближайшим аналогом ТЗ является Project Charter, если угодно.

А еще в ТЗ есть очень короткая секция, в самом начале, с которой у большинства есть огромные проблемы. Но - в которой состоит весь дзен ТЗ. Называется "Цели и задачи работы". :)

В чем состоят проблемы? В неумении людей отличать цели от задач. Типичное содержимое - "целью работы является разработка системы Х. Задачами работы, э-э-э... Чорт! Что здесь писать? являются проектирование, кодирование, и отладка системы Х".

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

"Задача - достать денег в партийную кассу, предотвратив тем самым закрытие типографии" - таковы цели и задачи Грина в одном из эпизодов "Статского Советника" Акунина.

"Задача - достать денег, с целью нихреново отдохнуть в Европе" - казалось бы, другая цель, но какая разница, если выполнять надо одну задачу - достать денег? А разница очень большая.

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

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

И в конце концов - раз у вас затруднение с формулировкой цели работ, и она дублирует задачи - может быть, работу вообще не стоит выдавать? Ну, раз выдающий задание не в состоянии внятно объяснить, зачем нужен результат работ? То, может, и работа не нужна?

Ок, переходим на конкретику. Задача работы - получить работоспособную реализацию аудиокодека Dolby Digital. А вот с какой целью? Проще выражаясь - зачем он нам нужен, ради чего вообще эта работа затеяна, для решения какой проблемы? Плевать, что вам это очевидно - это необходимо довести до исполнителей.

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

Если же с целью использования в конечном продукте - тут уже совершенно другое дело. Абсолютно другие требования к качеству, и GPL лицензия не подойдет.

Цель работ, т.е. решаемая работой проблема, rationale, стоящее за задачей - обязательно должны быть обозначены явно. Для этого, в принципе, допустимо ввести отдельную "главу" в ТЗ - она называется как-то вроде "характеристика предметной области" (забыл, как она точно называется, см. ГОСТы в сети), где простым человеческим образом описать проблему. Можно это сделать в той же самой секции "цели и задачи".

Здесь многие знатоки ЕСПД-ЕСКД со мной не согласятся. Ибо - общая практика такова, что к данной секции относятся наплевательски - лень мозги включать. Не без греха и автор этих строк - бывало, что писал в эту часть полную хрень. Но я скажу - вне всякого сомнения, "цели и задачи работы", вкупе с описанием решаемой проблемы - самая важная секция ТЗ. И умение отделять цели от задач - ключевое в составлении ТЗ и менеджменте вообще.

Теперь два фокуса.
1) Вас могут не устраивать фиксированные даты окончания этапов. Пишете в соответствующей графе: "в соответствии с ведомостью исполнения". И все ок.
2) Вас может волновать отсутствие детально расписанных требований в документе ТЗ. Волноваться не надо - у вас есть "программа и методика испытаний".

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

Далее - вы сможете отслеживать прогресс работ по количеству проходящих пунктов этого "документа". Вот и весь фокус.

Вкратце - все. Но к самому интересному моменту мы только подошли. Вы видите - ТЗ это очень укрупненный план. Вот у вас есть ТЗ на весь проект. Что же делать дальше? Составлять WBS? Рисовать задачи?

Черта с два. Единственная "задача" - это ТЗ. Правильный ответ - выделять частные, более мелкие ТЗ, на более мелкие работы. И так - до самого мелкого уровня. Две главных секции - я показал. Это технические требования плюс поэтапный план.

Вот в этом и состоит второе важное отличие схемы ГОСТ от классической. План работ - это совокупность заданий, на каждое из которых выписано ТЗ. Результат каждого задания - конкретный и проверяемый. Проходит обязательную приемку. Задание может иметь промежуточные этапы - каждый из которых также проходит приемку.

То есть, в отличии от классики, ГОСТ:
1) Объединяет планирование и управление требованиями в единую технику.
2) Явно фокусируется на результате работ, а не на процессах и активностях.
3) Опирается на одну и ту же технику при управлении программой и проектом. Он предполагает, что вы вместо выдачи "заданий", будете дробить крупные "проекты" на "подпроекты", концентрируясь на результатах каждой задачи и этапа.
4) Не предполагает отдельной роли "менеджера". Все, кто завязан в процесс - в той или иной степени инженеры. Задание-то "техническое", как ни крути.
5) Совместим со стилем управления Auftragstaktik, про который я много писал.

Когда вы понимаете принцип, стоящий за ГОСТ (а ГОСТ были изначально разработаны для управления большими программами, вроде разработки комплексов ПВО), все становится очень просто и симпатично.

Настолько - что вы можете даже не писать документов-ТЗ. Честно. Смотрите: Берете Redmine.
1) Иерархия ТЗ - это иерархия проектов и подпроектов.
2) Этапы - это "версии" для каждого проекта.
3) Технические требования - можете в вики писать, а можете задавать тикетами. Это уж как душе угодно.

Вот вам и все управление. Просто, симпатично, и, самое главное - отлично работает.

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

Социальные сети / Как авторизуются люди в Рунете

image
По следам этого поста, публикую данные о ситуации в Рунете. В качестве оператора «общей» аутентификации в данном случае вышла система Loginza. Данные собраны за три полных месяца и за половину августа.

Первое место занимает великое рунетовское зло (пока что незаменимое лично для меня, ввиду его повсеместности – где бы еще я за два часа смог найти внедорожник для съемок или фотографа на бекстейдж?) vkontakte.ru. Количество заходов под этим аккаунтом составило почти 14 тыс. за исследуемый период, что в процентном отношении дает около 45%.
Читать дальше →

Социальные сети / Как авторизуются люди в Вебе

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

Равно как и в последнем, апрельском, отчете Гугл и Фейсбук доминируют среди сайтов, предоставляющих возможности входа под их аккаунтами на сторонние сайты. Среди посетителей 250 тыс. сайтов, использующих систему Janrain Engage, 38% входит под аккаунтами Гугл.
Читать дальше →

Drag and drop attachments to save them to your desktop

Posted by Adam de Boor, Software Engineer

Dragging and dropping files is an easy way to save time in Gmail. We’ve previously blogged about dragging files to upload as attachments and dragging images into new messages. Now, if you're using Google Chrome, you can also drag attachments out of messages you receive to save them to your computer.

Let’s say you have an email open containing an attachment. Hover your mouse over the attachment’s “Download” link or its file icon and a tooltip appears that says: “Click to view OR drag to your desktop to save."


Simply click and hold, then drag your cursor to anywhere in your file system that you want to save the file. Release the mouse button, and voilà! Your attachment is saved (for large files, you may see a progress dialog).

← предыдущий месяц