Многие программисты оптимизируют JavaScript и CSS-код, чтобы страница грузилась быстрее.
Но не все они делают прелоадеры, которые дают пользователю эффект субъективно более быстрой загрузки.

В предвестии новой 10-й версии браузера Opera, в одноимённом сообществе опять встал вопрос «курицы или яйца» в отношении основы современного интерфейса браузера — панели адресной строки и панели ввода адреса.
Итак, основные действующие лица: панель адресной строки, панель ввода адреса, и, собственно, сама страница. Что к чему крепится логически и технологически, что удобнее, что привычнее в использовании?
Мне, как пользователю браузера Opera с многолетним стажем, естественно, кажется привычней адресная строка с кнопками навигации внутри вкладки. Так же мне это кажется логичным со всех сторон, и, к тому же, я встречал эту модель не только в Опере, но и в таких программах как Adobe Dreamweaver:

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

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

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

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

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

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

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

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

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

Часть I — Часть II — Часть III — Часть IV — Часть V — Часть VI

Часть I

Как-то ко мне обратился знакомый дизайнер с просьбой разобраться в странной по его мнению ситуации. Клиент просил «сделать так же, как у Apple», но с использованием собственных способов расположения блоков, изображений, цветовой гаммы и текста. В общем, дизайн в итоге получался совершенно непохожий на apple.com, но этого, собственно, и добивался клиент. И вроде бы у дизайнера получилось, но… Клиенту по-прежнему не нравилось, он всё равно требовал переделать макет. По его ощущения «что-то было ну совсем не так». А что именно — тот объяснить был не в силах. Вот и возник вопрос у моего коллеги по поводу того, как угодить капризам клиента и понять его чаяния. Оказалось всё не так просто, но вполне объяснимо. Я и раньше сталкивался с данной проблемой. Поэтому решил попробовать изложить свои мысли по этому поводу.

Итак, какова ситуация в области современной веб-типографики и какими способами следует решать возникающие проблемы?

Выкладываю фреймворк, написанный для себя.
Причина создания: надоело каждый раз при верстке нового сайта заниматься одним и тем же — переделывать мой любимый Tripoli (исправляя его баги, добавлять свойства разметки); добавлять JS-фреймворк jQuery, создавать типичную HTML-структуру. Решил объединить часто используемые мной элементы в единое универсальное целое.
Делал для себя, то есть — аккуратно и хорошо.

jQuery — это замечательный JavaScript Framework, который подкупает своей простотой в понимании и удобством в использовании. Но изучение надо с чего-то начинать, и лично моё мнение — лучше всего начинать с наглядных примеров, и они далее…

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

1. Использование дефисов вместо тире em-dash.



Если вам нужно прервать мысль, то делайте это с помощью символа (alt+0151), а не парой знаков «минус». Это, пожалуй, главный источник раздражения для всех редакторов.

На финишную прямую вышел Zend Framework 1.6.0 — уже доступен Release Candidate под номером «Один».

Несколько дней назад скачал ZF 1.5.0 RC3 и собирался его использовать в живом проекте, несмотря на RC3.
Естесвенно вчерашняя новость о релизе ZF очень порадовала. И перед тем как заменить файлы я решил посмотреть, чем собсвтенно релиз отличается от релиз кандидат (я думал, что особо ничем), который я уже закинул в проект.
В общем сделал диф, и так как на Хабре уже стал вопрос о отличиях релиза от кандидата, то решил запостить этот диф. Изменилась регулярка и версия.
Команда
diff -r ZendFramework-1.5.0/library/Zend/ ZendFramework-1.5.0RC3/library/Zend/ > zend_diff
Результат ниже.