Перемены — это хорошо, но на мой взгляд текущий дизайн несколько хаотичен. Небольшое ИМХО, всё относится к Chrome 16/Win7:
1) Проработать шрифты.
1.1) Использовать одновременно Georgia, Arial и Tahoma на одной странице — это, мне кажется, чересчур. Причем Georgia и Tahoma есть одновременно и в заголовках, и в обычном тексте.
1.2) Местами перебор с тенью шрифтов. Я, конечно, понимаю, что text-shadow — это круто, но лишь когда он к месту.
1.3) Нет согласия по используемым заголовкам для блоков. Где-то h2 (причем совпадает с заголовком раздела, и из-за тени кажется тяжелее заголовка раздела), где-то h3, где-то вообще th. Причем на support.selectel.ru/cloud/ «Информация по суммарному потреблению» выровнена по центру и верхнему краю (из-за иконки ячейка растягивается), а «Сводная статистика» — по левому краю и середине.
1.4) Зачем так много курсива?)
2) Аккуратнее относиться к сетке, и соблюдать единообразие
2.1) на support.selectel.ru/ платежи вразнобой. Если сделать нормальную таблицу, возможно будет лучше.
2.2) на support.selectel.ru/cloud/ не очень понятно, почему выбор среза статистики так далеко удален от самой таблицы, что ослабляет их связь. С другой стороны, это всё находит в одном блоке…
2.3) в разных разделах между блоками разные отступы
2.4) если в таб-панели нет содержимого, то линии вместо плавного перехода в белый, становятся обрубленными.
2.5) почему в support.selectel.ru/domains/ «Добавить тикет» справа, а в support.selectel.ru/pay/ «Пополнить баланс» слева? Кстати, на support.selectel.ru/pay/ метка «Оплачено» скачет от строчки к строчке.
Git/Hg уменьшают количество шагов, которые нужно сделать. Понятно, что в SVN можно сделать всё, что умеют Git/Hg: настроить локальное зеркало удаленного репозитория, делать и мерджить бранчи, но в Git/Hg это просто удобнее. Можно работать над какой-то фичей, а если срочно что-то нужно поправить в текущей версии, но фича ещё не готова, просто делаешь update к соответствующему changeset, исправляешь, комитишь, делаешь update к своей работе, продолжаешь работать, и это всё делается очень быстро и просто.
Дело не в элитарности и закрытости, а в уже сформировавшейся аудитории. Впрочем, это скорее всего временное явление, и когда там начнут регистрироваться мои друзья и знакомые, не имеющие отношения к IT, то смак этой сети окончательно пропадёт. Особенно если Google не реализует нормальную работу с кругами.
Google+ мне нравится тем, что из-за закрытости регистрации и непривлекательности этой системы для массового пользователя, там собралось множество моих знакомых разработчиков. Ни во вконтакте, ни в фейсбуке я бы не стал делиться впечатлениями от Emacs или жаловаться на то, что на работе используется SVN)
LSP, кстати в оригинале звучал как «functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it», а не про as-is, как это описано у автора поста.
«Area», конечно, не «Square». Кстати, у самого Роберта Мартина в его «Design Principles and
Design Patterns» 2000 года не было SRP. С другой стороны, DIP он описывал ещё в 96ом)
Немного разные вещи. ISP заключается в предоставлении конкретным клиентам минимального интерфейса. Т.е. предположим, что есть класс Rectangle, который умеет возвращать свой периметр и свою площадь. Пусть эти два метода находятся в интерфейсе IShape. Принцип SRP здесь соблюдается, так как зона ответственности этого класса — некие математические операции с данными этого класса. С точки зрения ISP, если у нас есть класс B, который выполняет операции с площадью некоторого объекта, при этом ему не требуется периметр этого объекта, то неплохо было бы разделить интерфейс IShape на какой-нибудь IShapePerimeterProvider и IShapeSquareProvider.
Пример, конечно, надуманный и названия интерфейсов не самые удачные) Суть в том, что SRP — это не одна операция на класс, это скорее операции одного контекста. Т.е. когда Rectangle не только умеет считать свою площадь, но и ещё умеет себя отрисовывать, и при этом используется в двух подсистемах — в одной только для получения площади, а в другой — для отрисовки — это уже нарушение SRP.
SOLID — это как-раз таки попытка сформулировать базис для правильного дизайна. Это не столько паттерны, сколько принципы, на которых строится гибкая архитектура системы. Кроме того, на паттернах от GoF мир клином не сошелся) Помимо них, есть и другие, не менее известные. Те же паттерны enterprise приложений от Фаулера — ActiveRecord, Repository, QueryObject и т.п.
Google нашел «фатальный недостаток» в JavaScript?) У меня такое ощущение, что Google встал на ту же тропу, на которую встал Microsoft во время браузерных войн с Netscape. Впрочем, Microsoft тогда победили…
height:expression((this.parentNode.scrollHeight - 40) + "px");1) Проработать шрифты.
1.1) Использовать одновременно Georgia, Arial и Tahoma на одной странице — это, мне кажется, чересчур. Причем Georgia и Tahoma есть одновременно и в заголовках, и в обычном тексте.
1.2) Местами перебор с тенью шрифтов. Я, конечно, понимаю, что text-shadow — это круто, но лишь когда он к месту.
1.3) Нет согласия по используемым заголовкам для блоков. Где-то h2 (причем совпадает с заголовком раздела, и из-за тени кажется тяжелее заголовка раздела), где-то h3, где-то вообще th. Причем на support.selectel.ru/cloud/ «Информация по суммарному потреблению» выровнена по центру и верхнему краю (из-за иконки ячейка растягивается), а «Сводная статистика» — по левому краю и середине.
1.4) Зачем так много курсива?)
2) Аккуратнее относиться к сетке, и соблюдать единообразие
2.1) на support.selectel.ru/ платежи вразнобой. Если сделать нормальную таблицу, возможно будет лучше.
2.2) на support.selectel.ru/cloud/ не очень понятно, почему выбор среза статистики так далеко удален от самой таблицы, что ослабляет их связь. С другой стороны, это всё находит в одном блоке…
2.3) в разных разделах между блоками разные отступы
2.4) если в таб-панели нет содержимого, то линии вместо плавного перехода в белый, становятся обрубленными.
2.5) почему в support.selectel.ru/domains/ «Добавить тикет» справа, а в support.selectel.ru/pay/ «Пополнить баланс» слева? Кстати, на support.selectel.ru/pay/ метка «Оплачено» скачет от строчки к строчке.
Design Patterns» 2000 года не было SRP. С другой стороны, DIP он описывал ещё в 96ом)
Пример, конечно, надуманный и названия интерфейсов не самые удачные) Суть в том, что SRP — это не одна операция на класс, это скорее операции одного контекста. Т.е. когда Rectangle не только умеет считать свою площадь, но и ещё умеет себя отрисовывать, и при этом используется в двух подсистемах — в одной только для получения площади, а в другой — для отрисовки — это уже нарушение SRP.