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

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

Надеюсь вы подчеркнете для себя что-то полезное, здесь вы можете ознакомиться с ним.
custom-reset.css

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

Все это побудило создать введение в те аспекты работы с шейдерами, которые наиболее вероятно пригодятся в работе именно верстальщику для создания различных 2d-эффектов с картинками на сайте. Конечно с поправкой на то, что сами по себе в дизайне интерфейсов они у нас применяются относительно редко. Мы сделаем стартовый шаблон на чистом JS без сторонних библиотек и рассмотрим идеи создания некоторых популярных эффектов, основанных на сдвиге пикселей, которые сложно сделать на SVG, но при этом они легко реализуются с помощью шейдеров.

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

• С точки зрения User Experience (UX) фронтенд должен обеспечивать быструю загрузку и работу веб-страниц.
• А с точки зрения Developer Experience (DX) нам хочется, чтобы и сам фронтенд тоже работал быстро, был прост в использовании и вообще являлся примером для подражания.

Всё это делает пользователей и разработчиков счастливее, а заодно существенно улучшает ранжирование сайтов поисковиками. Например, Google уделяет особое внимание оптимизированности фронтенда. Если вы достаточно долго бились над тем, чтобы ваш сайт заработал побольше баллов в Google Pagespeed Insights, то, надеемся, эта статья поможет вам лучше понять, для чего всё это нужно и каково разнообразие стратегий оптимизации фронтенда.

Если вдруг вся эта история прошла мимо вас, Let's Encrypt — центр сертификации от некоммерческой организации ISRG, существующий при поддержке EFF и многих компаний, взявшей на себя миссию дать людям бесплатные SSL/TLS сертификаты для сайтов и серверов. Сертификаты от Let's Encrypt уже используются на более чем 10 миллионах доменов.

Кроме очевидной бесплатности у сертификатов от Let's Encrypt есть особое, отсутствующее у любых других коммерческих сертификационных центров, достоинство: если вы однажды получили сертификат от Let's Encrypt, то, при прочих равных, это навсегда. Не нужно раз в год-два вручную обновлять сертификаты. Не нужно вообще вспоминать что сертификаты где-то есть. Получил, настроил и забыл!

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

Организации автоматического обновления сертификатов в статье уделено пристальное внимание, с тем чтобы вы могли в полной мере оценить это принципиальное преимущество Let's Encrypt.

У меня есть три сервера, но я не профессиональный сисадмин. Это означает, что несмотря на четыре базы данных и стопяцот приложений, бэкапы нигде не ведутся, к любой проблеме на сервере я подхожу, шумно вздохнув и бросив тарелку в стену, а операционные системы там достигли EOL два года назад. Я бы рад обновить, но на это нужно выделить, наверное, неделю, чтобы всё забэкапить и переставить. Проще забыть про yum update и apt-get upgrade.

Конечно, это неправильно. Я давно присматривался к chef и Puppet, которые, как я думал, решат все мои проблемы. Но я смотрел на конфиги знакомых проектов и откладывал. Это же нужно изучать, разбираться с ruby, бороться с многочисленными, по отзывам, косяками и ограничениями. Две недели назад статья Георгия amarao стала животворящим пинком. Даже не сама статья, а перечисление систем управления конфигурацией. После чтения комментариев и лёгкого гугления решил: возьму Ansible. Потому что питон, и на проблемы никто не жалуется.



Что ж, тогда я первым буду.

Настройка резервного копирования в Ubuntu за 20 минут.

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

Итак, мы имеем удаленный хост под управлением ubuntu, с некоторым массивом довольно критичных данных. Довольно логичным было бы настроить бэкап прямо на удаленном хосте, с помощью tar по крону, rsyns и т.д. Но, т.к. место на виртуальном выделенном хостинге довольно дорого и использовать его лучше по делу, идеально было бы, чтобы данные автоматически копировались на какую нибудь локальную машину, место на которой хоть отбавляй. В моем случае это файловый сервис в офисе, под управлением все той же Ubuntu.

Недавно по работе собирал своего рода лекцию по веб-безопасности, ознакомился с известным рейтингом уявзимостей OWASP 2013 года, но с удивлением обнаружил, что корректной инфы на русском языке крайне мало, или её практически нет.

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

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

• SQL Injection
• Некорректная аутентификация и управление сессией
• Межсайтовый скриптинг (XSS)
• Небезопасные прямые ссылки на объекты
• Небезопасная конфигурация
• Утечка чувствительных данных
• Отсутствие контроля доступа к функциональному уровню
• Подделка межсайтовых запросов (CSRF)
• Использование компонентов с известными уязвимостями
• Невалидированные редиректы
• Кликджекинг
• Фишинг
• Include

Текстовые редакторы, как тип программного обеспечения, появились чуть позже чем динозавры, и вероятнее всего это был вообще первый софт, с которым вы столкнулись в своей жизни, возможно кто-то даже застал MS-DOS Editor.

Однако с переходом большой части ПО в браузеры актуальны и соответствующие визуальные редакторы Rich Text Editors, и проблемных мест в их разработке масса. Если вы по какой-то причине решили сделать свой собственный редактор, то подумайте еще раз — есть мнение, что делать этого не нужно.



Чтобы вы могли принять более взвешенное решение, Егор Яковишен обобщил весь свой опыт, полученный в процессе создания Setka Editor, и рассказал про проблемы, с которыми придется столкнуться, и что можно предпринять для их решения.

Disclaimer: статья написана на основании доклада Егора на конференции Frontend Conf 2017 в июне 2017 года. Ситуация с поддержкой браузерами определенных API с тех пор уже могла измениться.

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

Всем привет! Три года назад, когда у меня был свой небольшой интернет-магазин необычных подарков, не существовало таких маркетплейсов и продвижения, как сейчас, и все свои «велосипеды» приходилось изобретать самому. Но, с другой стороны, не было никаких онлайн-касс и жёсткого контроля со стороны государства. Можно было торговать чем угодно через паблик в ВК в любом формате: с чеком, без чека, за нал и безнал — всё, что душеньке угодно. Потом кольцо «государственного контроля» начало сжиматься. Сначала взялись за крупный бизнес, потом за банки. Потом всех торговцев алкоголем, включая палатки у дома, «посадили» на ЕГАИС. Потом «посчитали» дальнобойщиков, дважды или трижды раздев их системой учёта «Платон».
Год назад руки государства добрались и до такой мелюзги, как малый и микробизнес. Многие думали, что до этого не дойдёт, но — дошло. Началась «жесть» — я имею в виду смену правил торговли по закону 54-ФЗ. Одни кричали, что эти онлайн-кассы дорогие и убьют торговлю. Другие, наоборот, уверяли, что управлять процессом станет проще и прозрачней. Третьи (особенно — гики, фанаты Джека Ма, основателя Alibaba и апологеты технологий) предрекали, что неизбежно появятся новые сервисы, которые изменят бизнес-процессы, и это хорошо.

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

Здравствуйте, дорогие читатели!

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

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

Сегодня началась конференция Facebook F8. Мероприятие интересно именно тем, как Facebook видит будущее. Такого количества футуристических фантазий в голове не рождается ни после WWDC, ни после Google IO. Как и ожидалось большой акцент был сделан на дополнительной и виртуальной реальностях, но главная задача для Facebook со слов Марка Цукерберга — это построение сообществ. Если раньше целью было просто соединить друзей и знакомых, то сейчас речь идёт о формирование групп по интересам.

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

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

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

Благодаря стараниям разработчиков, эта проблема была успешно пофикшена в течение нескольких дней, но на этом наша сага не закончена. Напомню, что согласно официальному прайс-листу Хабра стоимость 1000 показов банера для пользователей ресурса колеблется от 400 до 550 рублей. За гео-таргетинг по Москве и Питеру придется доплатить 20 и 15 процентов соответственно.

Но всё еще существует способ рекламироваться на эту же аудиторию платя 30-150 рублей за тысячу показов. Давайте думать, как исправить и эту фичу:

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

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

Я думаю, вы уже знаете что такое push-уведомления, но я всё же напишу коротко о главном.

Пользователь, заходя на сайт, вытягивает (pull) с него данные. Это удобно и безопасно, но с развитием интернет ресурсов, появилась необходимость оперативно доставлять информацию пользователям не дожидаясь пока те сами сделают запрос. Так и появилась технология принудительной доставки (push) данных с сервера клиенту.

Вы уже используете прогрессивную загрузку? А как насчёт технологий Tree Shaking и разбиения кода в React и Angular? Вы настроили сжатие Brotli или Zopfli, OCSP stapling и HPACK-сжатие? А как у вас обстоят дела с оптимизацией ресурсов и клиентской части, со вложенностью CSS? Не говоря уже о IPv6, HTTP/2 и сервис-воркерах.

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

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

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

Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик. Последние полгода занимался разработкой многопользовательской космической браузерной стратегии. На текущий момент мы уже находимся на стадии закрытого бета тестирования (доступного для вложившихся) и запустили компанию на бумстартере.



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

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

Вводная часть

Я разработчик, пару лет работаю удаленно на европейских и американских клиентов. До этого 10 лет проработала разработчиком и техническим менеджером в Москве.

Какое-то время назад озаботилась вопросом легализации доходов от удалённой работы и одновременного переезда.

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

Но мне уже не очень хотелось наниматься к кому-то (почему, читайте ниже) и прельстила идея “собственного бизнеса”.

Уточню, что на получение документов у меня ушел примерно год.

Что такое CSRF атака?

Ознакомиться с самой идеей атаки CSRF можно на классических ресурсах:

• OWASP
• Acunetix
• Отличный ответ на SO

Выдержка из ответа на SO:

Причина CSRF кроется в том, что браузеры не понимают, как различить, было ли действие явно совершено пользователем (как, скажем, нажатие кнопки на форме или переход по ссылке) или пользователь неумышленно выполнил это действие (например, при посещении bad.com, ресурсом был отправлен запрос на good.com/some_action, в то время как пользователь уже был залогинен на good.com).

Как от нее защититься?

Эффективным и общепринятым на сегодня способом защиты от CSRF-Атаки является токен. Под токеном имеется в виду случайный набор байт, который сервер передает клиенту, а клиент возвращает серверу.

Защита сводится к проверке токена, который сгенерировал сервер, и токена, который прислал пользователь.