Давным-давно (лет пятнадцать назад) почти все делали сайты и не переживали о том, что под капотом. Верстали таблицами, использовали всё, что попадётся под руку (а попадались в основном <div> и <span>) и не особо заморачивались о доступности. А потом случился HTML5 и понеслось.

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

Дисклеймер: статья может обидеть тех, кто прикипел к вёрстке дивами. Но <div> — не приговор, и мы не призываем от него целиком отказываться. Ну и всегда можно договориться.

Этот текст задуман и написан как дополнение к «Чему я научился за 10 лет на Stack Overflow».

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

Я решился написать эту заметку потому, что за семь лет, проведенные на SO, я достаточно хорошо изучил сообщество изнутри. Я ответил на 3516 вопросов, задал 58, вошел в hall of fame (top 20 во всем мире) в обоих языках, на которых пишу постоянно, подружился со многими умными людьми, и активно пользуюсь, пожалуй, всеми возможностями, предоставляемыми сайтом.

Каждое утро, за утренним кофе, я открываю ленту новостей, twitter, и — SO. И я считаю, что этот сайт может дать разработчику гораздо больше, чем сниппет для копипаста, заботливо предложенный DuckDuckGo.

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

За пятнадцать лет работы в тестировании я наблюдаю, как отрасль из простой и незрелой, ориентированной на начинающих айтишников, становится профессиональным направлением. Раньше тест-менеджер должен был распределять задачи между тестировщиками и следить, чтобы они тестировали разные области, не повторяя одно и то же - такая вот “высокоинтеллектуальная управленческая задача”. Со временем в тестировании появилась узкая специализация, и теперь тестировщики решают разные задачи. Кто-то занимается тест-анализами и тест-дизайном, кто-то автоматизирует тесты, кто-то проводит ручное тестирование как по готовым скриптам, так и в свободном поиске, используя множество инструментов исследовательского тестирования. Соответственно, роль тест-менеджера также поменялась. Теперь он не просто распределяет задачи, а организует процесс, выделяет необходимые задачи для решения, объединяет людей с абсолютно разной квалификацией и целями, чтобы на выходе получить прекрасный результат. И тут, внимание, вопрос: а что же такое прекрасный результат в тестировании? 

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

Несмотря на то что многие разработчики ежедневно используют HTML, они не пытаются оттачивать свой навык и поэтому не применяют некоторые из редко обсуждаемых фичей HTML. Специально к старту нового потока курса по веб-разработке, делимся материалом в котором приведены 5 тегов и атрибутов HTML, которые вам следует знать.

Привет, Хабр. Меня зовут Ольга, я работаю в тестировании с 2013 года, специализируюсь на тест-анализе и тест-дизайне. Сегодня хочу рассказать, как при планировании тестирования сохранить фокус на пользователях и их потребностях.

Часто тестировщики начинают планирование тестирования с составления карты приложения. Т.е. формируют список страниц и перечисляют все контролы на странице. Это приводит к тому, что каждая страница сама по себе работает, но это не значит, что пользователь может выполнить свою задачу целиком. 

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

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

Как правильно вставлять SVG?