Я иногда сталкивался с тем, когда web-программист не знал CSS или, скорее, не хотел заниматься облагораживанием своего HTML, который являлся результатом работы разрабатываемого им скрипта. Это натолкнуло меня на мысль, что ему (программисту) не помешало бы иметь при себе некоторое средство для создания «красивых» страниц. Средство должно было бы включать в себя некоторый CSS, возможно, картинки, и подключаться к любому HTML (очевидно, созданному по некоторым определённым правилам). При этом смена CSS (и картинок) на альтернативные не должна была бы приводить к семантически некорректному отображению.
     Вышеобозначенные требования очень похожи на требования к составлению скина для какой-либо системы (в частности, CMS). Но, в отличие от скина, который заточен под конкретный HTML, в нашем случае хотелось бы максимально упростить правила написания HTML, чтобы разработчикам не нужно было держать в голове много сложных правил.
     Таким образом, оговаривая некоторые (небольшие) ограничения на HTML, мы с одной стороны гарантируем программисту, что его код, генерируемый с учётом этих правил, будет корректно оформлен любым сделанным для этих целей CSS, а с другой стороны, оговариваем шаблон изготовления самих этих CSS.

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

Плюсы

• Есть прижимающийся к полу футер
• Колонки меню растягиваются по 100% высоте
• Колонок может быть сколько душе угодно
• Колонки могут быть как лево- так и правосторонними, а также совмещенными, например 2 справа и 1 слева
• Ширина как резиновая, так и фиксированная
• Критический минимум хаков
• Не используется Javascript
• Не используются бекграундовые изображения для создания эффекта колонки
• Никаких таблиц
• Одинаковый результат в ie5.5, ie6, ie7, ie8, ff3.5, o10, chrome4 (Если у вас не работает в каком-то браузере — отпишитесь, пожалуйста, в комментах. Исправим и приведем к универсальному виду)

Минусы

• Есть несколько «лишних» блоков. (Я бы и сам рад от них избавиться)
• Есть несколько абсолютно-позиционируемых блоков

Из институтского курса по технологиям программирования я вынес следующую классификацию видов тестирования (критерий — степень изолированности кода). Тестирование бывает:

• Блочное (Unit testing) — тестирование одного модуля в изоляции.
• Интеграционное (Integration Testing) — тестирование группы взаимодействующих модулей.
• Системное (System Testing) — тестирование системы в целом.

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

Я хочу дать исчерпывающее описание замечательному фреймворку для построения модульных сеток 960gs. Недавно где-то в комментариях сказали, что 960gs сложнее в понимании, чем blueprint, что меня удивило. Я не хочу заниматься сравнением этих фреймворком, хотя бы потому, что они выступают в разных весовых категориях, однако, для построения модульной сетки ничего легче и проще в понимании, чем 960gs я не видела.

Без малого год назад, я уже писал (http://habrahabr.ru/blogs/javascript/50544/) о самом коротком способе определение браузера Internet Explorer, но вот некто Aleko нашел еще более короткий вариант:

-[1,]

Всего 5 байт. Пример использования:
if(-[1,]){
alert("Not IE!");
}

Вступление

Сегодня я расскажу вам как установить и настроить гипервизор от Microsoft, а так же как управлять им.
Итак, сначала небольшое лирическое отступление.
По мере оптимизации существующей инфраструктуры встал вопрос о виртуализации. Я тут же вспомнил про замечательное решение от VMware — ESXi, с которым раньше неоднократно работал и был более чем доволен и собрался уже было на него мигрировать, но судьба распорядилась иначе. В процессе планирования и выбора платформы виртуализации неожиданно победил Hyper-V.
Две вещи склонили чашу весов в его сторону: отличная поддержка железа, а так же тот фактор, что у меня в организации используются только продукты Microsoft, вследствие чего имеем более тесную интеграцию и лучшую управляемость. К сожалению, поддержка AD была анонсирована в ESXi 4.1 позже начала миграции, а то наверное я бы еще подумал.
Как многие знают, Hyper-V Server 2008 R2 — бесплатный продукт и представляет собой ОС Windows Server 2008 R2 Standard, работающую в режиме Server Core (то есть без GUI) и с включенной ролью Hyper-V. В связи с этим возникают некоторые сложности в настройке системы для «виндовых» админов, так как нет волшебных кнопочек «далее» и «готово», а уж для линуксоидов и подавно — синтаксис комманд в винде и рядом не лежал с никсами по удобству и понятности.

Установка

Начнем с установки.
Установка с компакт-диска не представляет собой ничего сложного — загрузились с диска, выбрали язык, согласились с лицензионным соглашением, выбрали раздел и «ушли курить» минут на 10.

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


Я понимаю, откуда это пришло. Большинство программистов любят программировать. Они готовы учиться новым особенностям языков программирования, пробуют новые компоненты и библиотеки, улучшают свои алгоритмы и архитектуру кода или скажем оптимизируют структуру используемых данных. Это кажется очень важным, потому что, программа хороша настолько, насколько хороши её коды и алгоритмы и насколько все это оптимизировано. И это так. Но только если программы пишутся для программистов.

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

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

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

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

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

Часть I

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

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

Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.

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

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

Со временем возможно появятся похожие таблички с правилами расстановки пробелов, знаков препинания и по оформлению текста в целом.

Grid 960 — это CSS Фреймворк, который позволяет разработчикам быстро конструировать прототипы дизайна. Они являются замечательным инструментом для создания макетов. Почему? Потому что они делают за вас всю тяжелую работу, позволяя получить быстрые результаты.

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