(2009 год, второе письмо старшего менеджера веб-студии — младшему)
Итак, первоначальные переговоры c клиентом проведены. Смотрим первую часть методички здесь http://habrahabr.ru/blogs/studiobusiness/45543/.
Теперь надо сориентировать клиента по цене. Если он с ней принципиально согласен — переходим к обсуждению Технического задания (ТЗ).
Делаем смету

Ничто не предвещало (преамбула)

Приходит посредник (или представитель заказчика), приносит концепцию (почти всегда гордо именуемую ТЗ) и просит оценить фронт работ в человеко-часах или баксо-рублях. После просмотра предоставленного документа я прикидываю, что работа займет около x (икс) недель и будет стоить примерно y (игрек) денег. Оценочная прикидка, ничего более. При оценке учитывается, что ТЗ (концепция) штука достаточно расплывчатая, чтобы при его уточнении можно было бы упихать функциональности раз в 5 больше, чем нарисовано изначально и сам проект выше среднего по сложности, причем не социальщина какая-нибудь, а программно-аппаратный комплекс взаимодействующий ещё и со сторонними приложениями. Оценки высылаются запросившему. В ответ приходит письмо с просьбой расписать чуть подробнее. Опускаюсь на уровень ниже выделяю какие-то наиболее существенные подпроекты, высылаю. Получаю замечательный ответ: «Вы просите так много, что я даже не буду показывать это заказчику.» Где-то рядом крутится смайл с ВОТ ТАКИМИ глазами.

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

jReject — jQuery Browser Rejection

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

При обновлении очередного проекта решил полностью забить на IE6. Его доля сильно падает, а времени на оптимизацию под этот браузер уходит достаточно много. Сначала всё же хотел оптимизировать сидеть, но потом решил что моё время дороже. Не смотря на то, что верстаю уже давно, IE всегда преподносит что-то новое =) Да и профиль не мой немного.
Однако совесть не позволяла выгрузить простой текст типа «обновите браузер», хотелось сделать доступно и понятно. Сделал, получилось приятно, настолько приятно, что захотелось поделиться =) Владельцы IE6 принудительно видят такую картину, при попытке обратиться к любой станице сайта

Добрый день, коллеги!

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

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

Чего ви пагите?

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

Данное мнение, на мой взгляд, ошибочно.

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

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

Перевод статьи Oliver Reichenstein «The 100% Easy-2-Read Standard».

Большинство сайтов доверху наполнены мелким текстом, который больно читать. Но зачем? Нет причины вжимать так много информации в экран. Это глупая коллективная ошибка, которая относится к временам когда экраны были действительно маленькими. Так что…

Экран и журнал: 100%-размер шрифта — это не много. Фотограф: Wilson Miner.

Не заставляйте нас изменять размер шрифта

Мы не хотим изменять настройки браузера каждый раз когда посещаем новый сайт!

Свойство clear со значениями left, right, both действительно очищает поток в отличие от overflow со значеним hidden, которое создаёт отдельный контекст форматирования для выбранного элемента, тем самым локализуя действие свойства float внутри элемента к которому применён.

Я занимаюсь разработкой форм ввода персональных данных. Для удобства работы пользователей и увеличения скорости ввода данных (а та же сокражения расходов на перепроверку введенных данных) был разработан метод обработки блока ФИО.



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

Логика функционирования блока «Личные данные»
После ввода фамилии, определяется пол по окончанию фамилии:
Мужской: 'ОВ', 'ЕВ' ,'ИН' ,'ЫН', 'ОЙ', 'ЦКИЙ', 'СКИЙ', 'ЦКОЙ', 'СКОЙ', 'ЦКИЙ'.
Женский: 'ОВА', 'ЕВА', 'ИНА', 'АЯ', 'ЯЯ', 'ЕКАЯ', 'ЦКАЯ'.

ФИО должны вводится в именительном падеже!
1. Если удалось определить пол по фамилии то в следующее поле «Имя» подгружаются исключительно мужские имена-справочник мужских имен(если пол мужской определился), женские имена(аналогично)-женская фамилия. В случае если фамилия оказалсь бесполой (Кравчук), то подгружаются оба справочника мужской и женский.
2. В поле «Имя», в зависимости от подгруженного справочника по первым буквам происходит подстановка полного имени, при нажатии на «Enter» происходит переход к следующему полю «отчество». Имеются также справочники отчеств, значения в поле подставляются аналогично предыдушему пункту. В случае когда введено не справочное имя(либо имя которое не содержится в справочнике), т.е. не возможно определить пол, происходит проверка опять же фамилии, и по ней происходит подгрузка значений в поле «отчество», и в случае когда не по имени не по фамилии невозможно определить пол, происходит подгрузка обоих справочников. Если имя является не справочным, то оно подсвечивается красным цветом, и отмечается в базе метка о несправочном значени, свидетельствующая о том что запись нужно повторно проверить на корректность.
3. Отчество. После ввода проверяется также на справочное значение и помечается так же как имя.
4. Форма проставляет пол автоматически при вводе информации, если есть уверенность в этом. Т.е.:
4.1. Фамилия мужская или женская, при этом имя и отчество из справочника мужские или женские – форма проставляет пол. Вам требуется обратить внимание, что пол проставлен верно.
4.2. Фамилия бесполая, имя и отчество справочные, если имя и отчество соответствуют одному полу, форма проставляет пол.
4.3. Фамилия + имя если отчество пустое или по нему невозможно определить пол.
4.4. Фамилия + отчество, если имя пустое или по нему невозможно определить пол.
5. Форма НЕ проставляет пол автоматически при наличии одной только фамилии (имя и отчество – инициалы):
5.1. Иванова И.И. – форма НЕ проставит пол, т.к. тут может быть ошибка – родительный падеж, в этом случае форма оставляет пол пустым, и Вы должны проставить его вручную с анкеты.

После заолнения остальных полей, происходит выход из блока и заключительная проверка:

6.Форма спрашивает о соответствии ФИО и пола один раз, при выходе из блока, при повторном обращении к блоку сообщения выводиться не будут для данной анкеты. При этом анализируются сочетания:
6.1. Окончание фамилии и пол (Иванова – мужской, форма спросит «уверены ли?»).
6.2. Неверные совпадения Фамилия + Имя / Фамилия + Имя + Отчество (Иванова Алексей, или Иванов Алексей Ивановна и т.д. – форма спросит).
6.3. Неверные совпадения ФИО – пол (при наличии полного ФИО), аналогично п. (6.1) – Иванова Алексей женский – форма спросит.
7. В случае, если пол не проставлен – форма при выходе из блока спросит, можете ли вы проставить пол?

Хотел разместить в разделе «Эти пользовательские интерфейсы», но у меня недостаточно кармы.

Речь в статье пойдет о такой, казалось бы изжеваной и изъезженой теме, как валидация веб-документа по одной из DTD-схем, которые в свою очередь определяются с помощью DOCTYPE.

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

В последнее время, многие редакторы и CMS'ки автоматически проставляют DOCTYPE для документа, что само по себе является прорывом, но к сожалению этого недостаточно, так как зачастую это именно Transitional схема. Начинающие разработчики не уделяют этому должного внимания, а зачастую вобще не подозревают что у них есть выбор.

(2008 год, письмо старшего менеджера веб-студии — младшему)
( профи вряд ли найдут что-то новое, молодым будет интересно)
Привет. Вот краткая инструкция, основанная на личном опыте. Так сказать, курс молодого бойца.
наша задача — заработать как можно больше денег, при минимальных телодвижениях.

Итак, получили письмо от клиента

обычно есть следующие варианты

1. клиент явно перспективный и обратился «выборочно» именно к нам — есть большая вероятность, что переговоры будут удачными — тогда лучше сразу набивать стрелку и устанавливать личный контакт и все выяснять на месте. Хотя, границы бюджета лучше выяснить в любом случае.
2. клиент интересный, но многое неясно из его письма ( нет ТЗ, нет бюджета, он написал в несколько студий, сайт потенциально сложный, сайт неинтересный и тд. ). Тут важно прислать ему БРИФ на заполнение, выяснить сроки и бюджет. Согласовать бюджет сроки — уже потом встречаться в случае, если все устраивает.
3. Письмо подозрительно короткое и не «пахнет интересом». Например, «нужен обувной интернет-магазин, сколько стоит? Как быстро сделаете? Виталий» — тут вряд-ли чтото выгорит + вероятно это пробивон по ценам от конкурентов.
   В этом случае — цену говорим в полтора раза дето дороже, интересуемся «укладываемся ли мы в их бюджет» в положительном случае — можно встречаться. Иначе — скорее всего трата времени.

Итак, свершилось то, чего так долго ждали некоторые посвященные блоггеры. Я открыл для всех желающих Parasite Eliminator – сервис и плагин для Wordpress, благодаря которым в моих блогах нет ручного спама.

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

Как оно работает

Большинство дизайнов ориентировано на использование фиксированных значений при верстке: ширина и высота блоков, размер шрифта. Это позволяет сверстанному шаблону «не разваливаться» при изменении масштабов просмотра и сохранять свойство кроссбраузерности. Однако в этом есть один большой минус – при большом разрешении экрана маленькие фиксированные блоки теряются на большой площади и остаются незамеченными. Тут даже не спасет «резиновая» верстка, т.к. сайт будет выглядеть еще более нечитабельным, например на 19'' мониторах при разрешении большем 1280 по ширине. Для меня это актуально, т.к. на ноутбуке 17'' с разрешением 1400х800 просматривать «резиновый» сайт очень неудобно. И желание оставаться на таком сайте отпадает быстро. Существует ли способ, позволяющий управлять масштабами не только текста, но и всего сайта?

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

Предисловие
В этом примере я не буду использовать ни JavaScript, ни любые другие языки. Все, что мне нужно это хорошая разметка и код CSS.
Таким образом, наша цель состоит в том, чтобы представить данные таблицы в виде диаграммы. Можно отметить, что данные диаграммы – это объект из 2х элементов, непосредственно зависимых друг от друга. Поэтому, лучшим решением в отношении структуры и семантики будет использование списков определений.
Почему? Ну, для начала, это список элементов. Несмотря на то, что список является линейным, мы можем обозначить заголовки определений (элементы dt) как пункты по оси X и описание определений (элементы dd) как значения по оси Y.

В W3Cast #3 Денис ( CurlyBrace) затронул тему использования styleguides, а у меня как раз уже была статья по этой теме. Поэтому я решил поделиться ей, чтобы показать наглядные примеры, демонстрирующих возможности «стилевых гидов».
«Стилевые гиды» — это свод правил и соглашений, предоставляющих разработчикам информацию о структуре кода и принятых правилах оформления. Чаще всего используется группой разработчиков, при совместном участии в проекте или же для самодисциплины при разработке кода.
Если проект большой, то он обрастает многочисленными файлами CSS с различными цветовыми схемами, типографикой и другими стилевыми установками. Чтобы избежать путаницы в структуре кода и не забыть что да как, нужно разрабатывать структурированный код, который впоследствии будет проще использовать, править и частично использовать в других проектах.

UPD: Заголовок изменен, что бы более соответствовать теме статьи

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

Cтатья будет интересна не только веб-программистам, но и всем кто так или иначе занимается программной обработкой изображений, поскольку функции для работы с матрицей скручивания имеются во многих языках (точно известно о php и flash). Так же, статья будет интересна дизайнерам, использующим Adobe Photoshop, поскольку в нем имеется соответствующий фильтр (Filter-Other-Custom).

Примеры будут на языке PHP с использованием библиотеки GD. Теория, практика, примеры (осторожно, много картинок!)

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

А вот надписей вроде еще не было. Значит будут. :-)

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

Одна из мелких неприятностей, которую студии чаще всего получают от клиентов — это несвоевременная оплата счета. Иногда у клиентов «нет денег на счету», иногда «бухгалтер забыл оплатить», иногда «бумага потерялась». Иногда бывает так, что «мы хотели уточнить кое-что у вашего бухгалтера, но не знали, как с ним связаться». Некоторые особо одаренные бухгалтеры отправляют деньги «с НДС» юрлицу, работающему по «упрощенке».

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

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