В одном из проектов необходимо регулярно выкладывать код из ветки stage на staging сервер. Начали делать это вручную — входишь через ssh, делаешь git push origin stage, если нужно — обновляешь базу и затем перезапускаешь apache. К концу этой недели решили, что хорошо бы все эти действия выполнять одной командой. Я прошерстил блоги — сейчас очень активно пишут про использования для этих целей библиотеки Fabric (это аналог Capistrano из Ruby on Rails).

Некоторое время назад у меня дошли руки до темы, которая давно уже меня нервирует интересует. Эта тема — наследование в JavaScript.

В сети есть много статей по данному вопросу, но мне не удалось найти обобщающего анализа, который бы удовлетворил меня своей полнотой и логикой. Почему хотелось найти именно обобщающий анализ? Дело в том, что особая, я бы сказал, уникальная сложность объектно ориентированного программирования в JS состоит в шокирующем (во всяком случае, меня) разнообразии его возможных реализаций. После довольно продолжительных неудачных поисков я решил попробовать разобраться в этом вопросе самостоятельно.

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

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

Список книг будет разбит на группы по темам, и каждая из них — на группы «обязательно прочесть и иметь» и «можно прочесть и иметь» (это выделение безусловно субъективно, так что спорить насчёт него не буду точно). В принципе, большинство книг есть в широкой продаже, в том числе и в крупнейших российских интернет-магазинах. Некоторые есть в отсканированном виде и их можно найти в Интернете.

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

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

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

Хочу заметить, что это не улучшение какого-то из существующих методов, а совершенно новый (по крайней мере, я нигде не смог найти — наверное, плохо искал ;) метод. В статье 38 статей о создании закругленных углов на сайтах данный метод также не был упомянут.

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

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

Часть V

Очевидно, что в сфере высоких технологий развитие зачастую происходит быстро и бурно. Так произошло и со средствами отображения информации. В течении каких-то двух-трёх лет обычные ЭЛТ-мониторы почти целиком и полностью были вытеснены стремительно дешевеющими ЖК-собратьями. Что позволило существенно улучшить как геометрию отображения, так и цветопередачу, а также снизить утомляемость глаз за счёт отсутствия вредного мерцания. И если несколько лет назад подобное утверждение в пользу TFT-панелей можно было бы оспорить, то теперь этот факт не вызывает ни у кого сомнений: ЖК-дисплеи намного лучше для повседневной работы рядового пользователя. В связи с этим фактором возникла необходимость поиска качественно новых алгоритмов отображения шрифтов. Одно из таких решений пусть не сразу, но всё же получило определённое признание в среде пользователей, и на сегодняшний день является чуть ли не самым популярным на современных платформах. Речь, конечно же, о технологии рендеринга ClearType, которая послужила причиной разработки новых веб-ориентированных шрифтов…

Когда мы делали Рисоваську, то сайту отвели не очень много внимания. «Простой, быстрый, „продающий“ нашего скачиваемого клиента» — такие требования получил dmalinovsky. В итоге сайт был написан на PHP с использованием авторского мини-фреймворка. Когда же Денис переключился на другие задачи, то стало понятно, что сайт никто не хочет расширять — не прикольно. На Эрланге писать — прикольно, на C++ — тоже прикольно (но после Эрланга конечно же все ворчали), на PHP — «не-не-не, я лучше на Эрланге попишу».

Меня это всё не устраивало, поэтому как только у меня выдалось время, я начал портирование сайта на технологии, поработать с которыми захочет каждый из нашей команды. Кандидатами были — Ruby on Rails и Django. Оба фреймворка — прекрасны! И самое главное — подходят по уровню инноваций, фана, красивого кода. Django я выбрал из-за языка — Python мне как-то сразу запал в душу.

Я получил это электронное письмо сегодня от Марка…

Привет Джо,
Во-первых я хотел бы поблагодарить вас за всю информацию, которую вы опубликовали на asp.net. Я почерпнул оттуда очень многое. Так же я слежу за вашими твиттами и меня заинтересовало, с чего вы начинали, как накапливали опыт для того, что бы стать Senior Program Manager в Microsoft. Если у вас будет возможность ответьте мне, я бы был очень благодарен.
Заранее спасибо,
Марк

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

Задался недавно вопросом, какие шрифты можно без зазрения совести и страха развалить дизайн сайта использовать на последнем.

Нашел несколько полезных ссылок, спешу поделиться с теми, кто еще не успел найти подобное.

1 Введение

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

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

1 Вступление

В топике освещаются не столько подробности работы с git, сколько его отличия от схемы разработки других систем контроля версий, и общий подход (выработанный по большей части личным опытом и Git Community Book) к работе.

Продолжая статьи о Git, распределенной системе контроля версий, с помощью которой ведется разработка таких проектов как Linux и Ruby on Rails, хотелось бы сказать и несколько слов о работе с ним под Windows.

Официального порта Git под Windows нет, есть mingw+msys порт по адресу code.google.com/p/msysgit/downloads/list

Как-то понадобилось написать проект на ruby под Windows — возникла проблема с виндовым переносом строки, который вставлялся во все файлы автоматически, вследствие чего проект не работал вообще. Оказалось, что для исправления нужно подправить gitconfig, в котором разработчики msysgit предусмотрительно вставили автопостановку CRLF.

Отключается она элементарной правкой gitconfig (можно найти в папке C:\Program Files\Git\etc), меняем содержимое секции core на следующее:

[core]
autocrlf = false
symlinks = false

Надеюсь, совет окажется многим полезным :)

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

К делу

Внешне задумка выглядит так:

Преамбула

Из нескольких способов развертывания Django я сразу отмёл mod_python, потому что мне не хотелось поднимать тяжеловесный Apache. Решил развернуть на легком веб-сервере. На данный момент основных легковесных альтернатив Апачу две — lighttpd и nginx. Первоначально я выбрал первый, но столкнулся с проблемами, связанными с URL. Я подумал, что, может, nginx будет работать получше, и развернул приложение на нём. В этом деле мне очень сильно помог один скринкаст, уже не помню точно чьего авторства.
Всё было отлично, но когда я захотел использовать админку Django(удобная вещь, кстати), меня постигло разочарование — форма логина показывалась, но при попытке войти меня выбрасывало на admin. После получаса гугления, я нашёл топик на небезызвестном форуме Ивана Салагаева, в котором описывалось решение проблемы. После того, как я последовал описанным советам, все заработало на-ура. Представляю вашему вниманию необходимую конфигурацию сервера и Django.

Наверное многие из вас знают, что Adobe Photoshop и Adobe Fireworks сжимают изображения не оптимально и после нарезки макета в Photoshop'e (Fireworks'e) изображения в большинстве случаев можно ужать. В среднем на дополнительном сжатии без потери качества небольшого сайта можно сэкономить килобайт 10, уж не говоря о разного рода фотогаллереях или сайтов с большим количеством графики. Немало, особенно на высоконагруженных проектах! Существует довольно много консольных программ для сжатия картинок без потери качества, а через консоль работать достаточно неудобно, и это отнимает время разработчика. Около месяца назад наткнулся на программу под названием ImageOptim.



Она прогоняет картинки через консольные оптимизаторы изображении (AdvPNG from AdvanceCOMP, OptiPNG, PngCrush, JpegOptim, Jpegtran from libjpeg и опционально PNGOUT) и выбирает лучший алгоритм для сжатия, и самое главное она имеет очень удобный визуальный интерфейс. Достаточно просто перетащить изображение или папку с изображениями в окно ImageOptim и все. К сожалению программа рассчитана на работу только с png и jpg форматами и не поддерживает gif.

Спешу расстроить пользователей Windows, есть только версия программы под Mac. Те кто использует Windows, могут обратить внимание на сервис smush.it — это онлайновый оптимизатор графики, также есть расширение для Firefox. Одним из преимуществ сервиса над ImageOptim является возможность оптимизации анимированных gif.

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

upd. Перенес в Web-разработку

upd2. В комментах подсказали, что есть программа с аналогичным функционалом под windows, называется PictureBeaver. Сам сию утилиту не тестировал, так что кто пользуется отпишитесь плз. Автор кстати москвич Артём Сапегин.

Статья написана по материалам моего доклада на CodeCamp 2009.

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

У любого проекта всегда есть что оптимизировать: можно почитать советы по оптимизации на webo.in, установить eaccelerator, memcache, проиндексировать поисковые поля в базе данных. Я предполагаю, что все это уже проделано, а сайт по прежнему тормозит.

Пришло время оптимизировать nginx...

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

• данная статья написана про MySQL, хотя общие вещи скорее всего справедливы для любой СУБД.
• все написанное в статье является моей личной точкой зрения, и не является истиной в последней инстанции.
• советы не претендуют на новизну и являются результатом обобщения прочтенной литературы и личного опыта.
  
• в рамках данной статьи я не буду касаться вопросов конфигурирования MySQL.

Проблемы при использовании MySQL можно разделить на следующие три группы(в порядке значимости):

1. Неиспользование или неправильное использование индексов.
2. Неправильная структура БД.
3. Неправильные \ неоптимальные SQL запросы.

Остановимся на каждой из этих групп подробнее.

Внимание!
Перед изменением файла .htaccess не забудьте сделать его резервную копию.

1 — Перенаправляем WordPress RSS поток на feedburner с использованием .htaccess
Почему некоторые вебмастера не используют feedburner? Ведь это такой замечательный инструмент для контроля за подписками на RSS. Проблема в том, что приходится руками исправлять файлы шаблонов. Этот прием поможет сохранить Ваше время.
И не забудьте исправить в строке 6 на Ваш код

<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteCond %{HTTP_USER_AGENT} !FeedBurner    [NC]
 RewriteCond %{HTTP_USER_AGENT} !FeedValidator [NC]
 RewriteRule ^feed/?([_0-9a-z-]+)?/?$ httр://feeds2.feedburner.com/wordpress[R=302,NC,L]
</IfModule>

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

Сложность элементов интерфейса увеличивается с каждым новым макетом, что доставляет немало хлопот верстальщикам. Развивающиеся технологии позволяют создавать в WEBе сложные приложения (Google не даст мне соврать), поэтому дизайнеры себя не сдерживают и рисуют всё более навороченные вещи. Как правило, это приводит к большому количеству графики на страницах.

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

Данная статья — первая из цикла на тему укрощения CSS. Сегодня мы рассмотрим технологию CSS Reset.

Зачем это нужно?

Каждый браузер устанавливает свои значения стилей по умолчанию для различных HTML-элементов. С помощью CSS Reset мы можем нивелировать эту разницу для обеспечения кроссбраузерности стилей.

Например, вы используете элемент a в вашем документе. Большинство браузеров, как Internet Explorer и Firefox, добавляют ссылке синий цвет и подчёркивание. Однако представьте, что через пять лет кто-то решил создать новый браузер (назовём его UltraBrowser). Разработчикам браузера не нравился синий цвет и раздражало подчёркивание, поэтому они решили выделять ссылки красным цветом и полужирным шрифтом. Именно исходя из этого, если вы установите базовое значение стилей для элемента a, то он гарантированно будет таким, каким вы хотите его видеть, а не как предпочитают его отображать разработчики UltraBrowser.