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

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

Казалось бы просто, но.
Когда через несколько недель после начала сборки проекта до проекта добираются тестировщики, они хватаются за голову. В верстке обнаруживается десятки несоответствий дизайну. Баги сыплются на головы программистов и верстальщика. Следя за сборкой, дизайнер погружается в грусть все глубже и глубже, его состояние на границе отчаяния, а дизайн в забвении (как можно положить “это” в портфолио?!). Верстальщик не прекращает попыток фиксить баги, но они появляются быстрее, чем он успевает их читать.

Всегда сталкиваюсь с проблемой сбора требований перед началом нового проекта. Делаю это в разных программах в зависимости от сложности проекта, когда в Word, когда в Mindjet MindManager. Пытался найти специальное ПО или информацию, в том числе и на хабре — не нашел, хотя смотрю тут тему «Сбор требований» затрагивают часто. Так, что думаю данный вопрос будет актуален на Хабре.

На данный момент мне известно несколько профессиональных продуктов созданных для структурирования, сбора и анализа требований:

— Rational RequisitePro
— AllFusion Process Modeler (ранее: BPwin)
— AllFusion ERwin Data Modeler (ранее: ERwin)
— Doors
— Borland Caliber RM

А как вы собираете/структурируете/анализируете требования к проекту?

Калифорнийский университет в Беркли стал первым в мире образовательным учреждением, который опубликовал видеозаписи полных курсов лекций на YouTube. Для этого там открыт специальный раздел youtube.com/ucberkeley.

Уже сейчас на YouTube опубликовано более 300 часов видеозанятий по химии, физике, биологии (всего девять полных курсов по 40 лекций по 45-55 минут каждая) и даже одна лекция по поисковым системам, которую прочитал в 2005 году лично Сергей Брин (видео под хабракатом).

Кстати, на сайте университета UC Berkeley раздел с видеозаписями появился еще в 2001 году, а в 2006 году они начали публиковать подкасты.

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

В первую очередь следует знать, что кроссбраузерная верстка сродни магии. Объясняется это все банальной вещью, которую я озвучу так: ”Все мы ненавидим Internet Explorer!” Таким образом, 90% всей магии сводится к тому, чтобы заставить правильно сверстанный макет корректно отображаться в браузере Internet Explorer всех актуальных версий.

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

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

Перевод статьи «55 Reasons to Design in XHTML-CSS».
В случайном порядке здесь представлены мои 55 причин создавать только бестабличные сайты, используя валидный XHTML для разметки, CSS для форматирования и Flash только в качестве уместной вставки. Под бестабличностью я понимаю избегание форматирования контента таблицами (или «супом» из заменяющих таблицы div-ов) и нацеленность на как можно более семантичную разметку. Некоторыe из перечисленных причин объясняют, «почему не использовать простой HTML», некоторые — «почему не сделать все на Flash», некоторые относятся как к первому, так и ко второму.
Я знаю, что эта тема обсуждалась множество раз, но все равно выскажусь

Специалисты сообщают о необычном поведении операционных систем Windows XP и Vista в последние дни. Некоторые из них по команде посреди ночи начали обновлять системные файлы в обход традиционной процедуры автоапдейта. Причём файлы обновлялись даже в том случае, если в системе отключена функция автоматического обновления. Программа Windows Update (WU) взяла на себя все полномочия и без всяких диалогов с пользователем самостоятельно заменила девять файлов.

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

Андрей Иванов из компании «Ашманов и партнёры» объявил о запуске нового аналитического проекта под названием Analyze This. Система автоматически анализирует самые важные параметры российских поисковых систем: частоту и силу апдейтов, качество навигационного поиска, качество тематического поиска, уровень SEO-прессинга, количество спама в поисковой выдаче. Доступен для просмотра весь архив измерений, поддерживаются комментарии.

Анализу подвергаются девять крупнейших поисковых систем: Yandex, Google, Rambler, Gogo, Live.com, Aport, Webalta, Liveinternet, Yahoo (по непонятным причинам отсутствуют Nigma.ru, Quintura.ru и прочие).

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

Примечание: ниже расположен перевод статьи «jQuery for JavaScript programmers», в которой автор высказывает свое мнение об этой библиотеке, ориентируясь, в первую очередь, на продвинутых программистов, и приводит несколько десятков примеров ее использования.

Когда jQuery увидела свет в январе 2006, я подумал: «очередная красивая игрушка». Выбор CSS-селекторов в качестве базиса было, конечно, изящной идеей (подробнее о ней в моей заметке getElementsBySelector), но использование цепочек преобразований выглядело немного замысловато, и сама библиотека, по-видимому, не покрывала всех возможных случаев. Я расценивал тогда jQuery только как временное и проходящее решение.

Только несколько месяцев спустя понял я, насколько же ошибался по отношению к ней. jQuery является просто произведением инженерного искусства. Она умело покрывает достаточно широкой диапазон повседневных функций и предоставляет при этом удобный API для расширений, с помощью которых можно добавить любую другую функциональность. Абстрактность в ней заложена на уровне ядра — речь идет о выборе DOM-элементов — и она извлекает из него максимум пользы. И что важнее всего, использование этой библиотеки подразумевает следование хорошему стилю в программировании и хорошо сочетается с другими частями JavaScript-кода.

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

На конференции ICANN в Лиссабоне выступил с докладом Роб Холл, известный эксперт и крупный инвестор на рынке доменных регистраций. Этот человек явно ничем себя не стеснял и начал рубить правду-матку о том, как на самом деле ведут бизнес доменные регистраторы, сколько стоят их активы и т.д.

На конференции eTarget-2007 директор интернет-агентства PRIOR.ru Сергей Спивак представил собственный метод анализа эффективности страниц сайта под названием «Диаграмма Спивака». Метод, который вскоре будет запатентован, позволяет понять, отрабатывает ли отдельно взятая страница свою функцию в пределах задач проекта. «Диаграмма» адресована, в первую очередь, крупным сайтам (более 100 страниц), имеющим целью что-то продать.

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

Давайте сразу же договоримся — эти советы подходят в основном программерам, ну и, скажем так, сильно технишн людям. Зададимся вопросом — что такое «продуктивность»? Не знаю как вы, а я вкладываю в это слово очень простое значение. Человек продуктивен, когда выполняет необходимые ему действия с минимальным напрягом для себя и максимальной отдачей для других. В случае программера идеально продуктивным является человек, который легко и непринужденно пишет хороший код за минимальное время. Хватит слов — вот вам советы:

1. Никогда не ищите глазами, пользуйтесь функциями поиска. Всегда, всегда используйте поиск, если вы печатаете быстро. Хороший пример — открытие файла в редакторе. Используйте поиск или комплишн (в зависимости от редактора) и вы увидите насколько это быстрее. То же относится к выбору таба/буфера, если редактор не позволяет перейти в нужный буфер — выкиньте его, иначе смотрите в пункт 4. Идеальный редактор работает так — нажимаем кнопочку (в моем случае Ctrl-X + b) и в строке ввода вписываем первые несколько букв открытого в другом табе файла. Завершаем всё нажатием tab и enter. Таким методом я переключаю открытый буфер за 0.2 секунды. Мышью и глазами я переключаю его за 1.4 секунды. Что приводит нас к следующему пункту.

2. Не повторяйте что-либо более 10 раз. Это критическое число для всех разное, для меня оно именно десять. Автоматизируйте. Больше. Чаще, но не увлекаясь глобализмом. Причем не только в коде, в редакторе, в среде, но и в жизни. Нужно разбить 20 куриных яиц? Сделайте коробочку с дырочками и отсекайте острую часть яйца. 11 раз написать триграмматон на заборе? Сделайте шаблон и купите балон с краской. Не забывайте, что клавиатурные шорткаты есть почти во всем софте. Каждый раз когда вы снимате руки с клавиатуры — теряете время.

3. Учитесь скриптовым языкам. Python, Ruby, Perl, Bash, Javascript, CMD, VBasic. Просто хватайте тот, который ближе к вам и пишите-пишите-пишите. Понятно, что выбрать просто, если вы работаете в windows — для вас только CMD и VBasic. Юниксоидам доступно чуть больше, думаю это одна из причин почему гики так активно пересаживаются на Linux. Я знаю, что учиться не легко — но надо. Есть один странный рецепт — попробуйте в течение 2-3 недель работать из консоли. Нет, не надо отказываться от окон и тп — просто откройте окно терминала или cmd и работайте из него, запустив нужный вам скриптовый интерпретатор. И ради бога, никаких far/mc/nc и тп. — ваша цель научиться писать скрипты. После этих 2х недель вы вернетесь к привычной среде с довольно большим знанием о том, как же устроен скриптовый язык. Напомню, для python и ruby есть ipython и iruby. Для perl есть mshell, остальные интерпретируемы сами по себе.

4. Изучите свой IDE настолько, насколько это возможно. В идеале — откажитесь от IDE в пользу хорошего текстового редактора. Я имею ввиду редактора. Например ViM или Emacs. Пользователи MacOS могут использовать и TextMate, однако мне он кажется жалким подобием левой руки (слабой пародией на MicroEmacs). Да, и уверяю вас — оба редактора, и ViM, и Emacs имеют столько возможностей, сколько не снилось любому другому. В то же время оба они прекрасно работают без донастройки, хотя я предпочитаю Emacs. Конечно многие еще помнят что Emacs раcшифровывается как Eight Megs And Constantly Swaping, но 8 метров памяти уже давно перестали быть чем-то из ряда вон выходящим. Окей, вернемся. Выберите редактор. И теперь используйте его везде, где только можно. Вбейте себе в голову — вы используете ТОЛЬКО этот редактор. Потому что достаточно хорошо знать два редактора невозможно. Знатоки утверждают что работая со своим редактором на полную катушку вы получаете буст к производительности в 200-500%. И глядя на Бацека, например, я в это верю. И единственный минус от этого знания только в одном — вы не сможете от этого отвыкнуть.

5. Изучайте технологии и пишите маленькие программки. Выделяйте себе 20-30 процентов времени на ковыряние в новых движках или базах данных. Да, двадцать-тридцать процентов времени. Я знаю что обычно на это выделятся куда меньше — но меня-то не надо обманывать, я ж сам такой был, и хорошо знаю сколько процентов времени программист пишет код. Подвиньте чуть-чуть время, выделяемое вами на чтение LiveJournal и закопайтесь по локоть в Django. Или сядьте и напишите скрипт для накручивания голосов на Хабре. В общем проводите время весело и с пользой. Это сильно помогает отдохнуть на работе не теряя темпа. А главное — это очень неплохо сказывается на структуре вашего кода — теперь вы знаете как и что делают другие.

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