CSS-препроцессоры в своё время значительно облегчали работу по написанию CSS кода. Однако в некотором роде все они были несовершенны и имели значительные изъяны в работе. А потому на смену препроцессорам пришёл постпрепроцессор PostCSS.

Это довольно таки мощный инструмент, облегчающий работу с CSS. Постпрепроцессор уже сегодня используется в таких крупных компаниях как Twitter и Google. Кроме того, по сообщениям разработчиков Bootstap, пятая версия CSS-фреймворка вероятнее всего также будет написана на PostCSS.

Три недели назад директор по маркетингу одного из стартапов в Сан-Франциско, в который вложили средства известные инвесторы, написала мне по поводу своей презентации.

«Презентации не хватает некой изюминки», – сказала она. – «Информации достаточно, слайды выглядят великолепно, но все это не складывается в захватывающую историю. Не мог бы ты помочь?»

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

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

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

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

Большие картинки == большие проблемы

Средняя веб-страница весит 2 Мб, из них 2/3 – картинки. Миллионы людей ходят в интернет через 3G, или ещё хуже. 2Мб-сайты в этих случаях работают ужасно. Даже на быстром соединении такие сайты могут израсходовать лимиты трафика. Работа веб-дизайнеров и разработчиков – упростить и улучшить жизнь пользователя.



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

ImageMagick

Утилита командной строки с 25-летним стажем в то же время является редактором картинок с полным набором функций. В ней огромная куча функций, и среди них – быстрое и автоматическое изменение размера картинок. Но с настройками по умолчанию файлы часто получаются излишне большими – иногда по объёму больше оригинала, хотя в них и меньше пикселей. Сейчас я объясню, в чём проблема, и покажу, какие настройки необходимы для её решения.

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

На хостинге эти проблемы решает сам хостер, а вот на собственном сервере это уже задача администратора. И даже если у Вас хостинг с предустановкой, то вероятность того, что на нем ограничены права для каждого пользователя и сайта маловероятна. Скорее всего Ваш провайдер ограничился установкой стандартных приложений vsftpd, Apache, nginx, php, mysql и тд и тп.

Будем считать, что необходимый комплект на сайте установлен и пришло время позаботиться о безопасности. Если же нет, то находим подходящую инструкцию по «настройке nginx в качестве front-end к apache» и возвращаемся к вопросу безопасности.

Безопасность будем строить из следующих принципов:

Первое это создание пользователей с оболочкой /bin/false на примере vsftpd и proftpd. Это ограничит выполнение скриптов в пределах собственной директории.

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

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

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

Не так давно в рабочей рассылке обсуждалась тема использования буквы «ё» в документации и постах.
Обсуждение затянулось на несколько месяцев…

Осознав важность проблемы, написал ёфикатор на Node.js.

Оптимизация веб-сайтов, известная под именем А/Б тестирование набрала популярность в качестве рабочей техники для многих команд, создающих сайты. Но до сих пор по ней слишком мало всеобъемлющих книг, статей или обучающих материалов, направленных на одиночных разработчиков, стремящихся ввести эту технику у себя в организации.

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

Основы: что такое оптимизация веб-сайтов?

Это метод экспериментов, проверяющих, какой дизайн лучше подходит для вашего сайта. Идея проста:

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

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

От переводчика.
Это перевод статьи Филипа Бернарда с сайта css-tricks.com. Часть статьи, содержащую описание работы с созданным им сервисом, я позволил себе опустить. Если вы найдете ошибки, просьба сообщить о них в личном сообщении.

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

Фавикон был представлен в 1999 году, в Internet Explorer 5 (источник) и стандартизирован W3C несколько месяцев спустя. Это была маленькая иконка, представляющая сайт.



С тех пор большинство настольных браузеров следуют тенденции и используют фавикон тем или иным способом. Это очень просто, не так ли? Создать маленькую картинку и добавить в любой интернет-проект, чтобы сделать его «завершённым». Ничего сложного.

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

Основные проблемы, которые встречаются в библиотеках валидации данных

Проблема №1. Многие валидаторы проверяют только те данные, для которых описаны правила проверки. Для меня важно, чтобы любой пользовательский ввод, который явно не разрешен, был проигнорирован. То есть, валидатор должен вырезать все данные для которых не описаны правила валидации. Это просто фундаментально требование.

Проблема №2. Процедурное описание правил валидации. Я не хочу каждый раз думать про алгоритм валидации, я просто хочу описать декларативно, как должны выглядеть правильные данные. По сути, я хочу задать схему данных (почему не «JSON Schema» — в конце поста).

Проблема №3. Описание правил валидации в виде кода. Казалось бы, это не так страшно, но это сразу сводит на нет все попытки сериализации правил валидации и использования одних и тех же правил валидации на бекенде и фронтенде.

Проблема №4. Валидация останавливается на первом же поле с ошибкой. Такой подход не дает возможности подсветить сразу все ошибочные/обязательные поля в форме.

Проблема №5. Нестандартизированные сообщения об ошибках. Например, «Field name is required». Такую ошибку я не могу показать пользователю по ряду причин:

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

То есть, нужно возвращать не сообщение об ошибках, а стандартизированные коды ошибок.

Проблема №6. Числовые коды ошибок. Это просто неудобно в использовании. Я хочу, чтобы коды ошибок были интуитивно понятны. Согласитесь, что код ошибки «REQUIRED» понятней, чем код «27». Логика аналогична работе с классами исключений.

Проблема №7. Нет возможности проверять иерархические структуры данных. Сегодня, во времена разных JSON API, без этого просто не обойтись. Кроме самой валидации иерархических данных, нужно предусмотреть и возврат кодов ошибок для каждого поля.

Проблема №8. Ограниченный набор правил. Стандартных правил всегда не хватает. Валидатор должен быть расширяемый и позволять добавлять в него правила любой сложности.

Проблема №9. Слишком широкая сфера ответственности. Валидатор не должен генерировать формы, не должен генерировать код, не должен делать ничего, кроме валидации.

Проблема №10. Невозможность провести дополнительную обработку данных. Практически всегда, где есть валидация, есть необходимость в какой-то дополнительной (часто предварительной) обработке данных: вырезать запрещенные символы, привести в нижний регистр, удалить лишние пробелы. Особенно актуально — это удаление пробелов в начале и в конце строки. В 99% случаев они там не нужны. Я знаю, что я до этого говорил, что валидатор не должен делать ничего кроме валидации.

3 года назад, было решено написать валидатор, который не будет иметь всех вышеописанных проблем. Так появился LIVR (Language Independent Validation Rules). Есть реализации на Perl, PHP, JavaScript, Python (мы на python не пишем — фидбек по ней дать не могу). Валидатор используется в продакшене уже несколько лет практически в каждом проекте компании. Валидатор работает, как на сервере, так и на клиенте.

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

Так вышло, что всю свою недолгую карьеру я занимаюсь разработкой API для мобильных приложений и сайтов на Symfony2. Каждый раз открываю для себя все новые знания, которые кому-то покажутся очевидными, а кому-то помогут сэкономить не мало времени. Об этих знаниях и пойдет речь.

Привет, Хабр!

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

Предыстория. О трендах

В последнее время все сильнее набирает обороты тренд «отзывчивого дизайна». Идея, заложенная в эту методологию, в режиме реального времени модифицируется, дополняется и обрастает новыми функциями. Я — не фанат трендов и моды как таковой, не сложилась у меня с ними взаимная любовь. Но в профессиональной сфере все иначе: здесь тренды правят бал, и выбросить их просто так не получается.

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

1) UIkit

getuikit.com

99% проблем юзабилити возникают из-за медленного ответа веб-интерфейсов. Очень важно создавать быстрые интерфейсы. UIKit полезен именно для этого. Он лёгкий, модульный, и идеальный для разработки фронтенда. Предоставляет богатый набор HTML, JavaScript и CSS компонентов.

Заинтересовавшись публикацией «Пишем свой Xcode plugin» решил написать простой тайм-трекер для Xcode. Процесс, через который я прошел — суть данной статьи. В ней мы с вами разберём несколько плагинов, которые помогут писать другие плагины быстрее и эффективнее.

Основная идея любого плагина с интерфейсом состоит в том, что он интегрируется в UI Xcode'a и выглядит максимально родным для него. Но как только мы смотрим на окно Xcode, сразу же встает вопрос: «Как понять где какой объект и как нам интегрироваться в нужный нам?» Так на нашем пути появляется первый плагин. Мы напишем простой плагин, который будет загружаться в Xcode и говорить, где какой объект расположен.

Frontend с каждым днём становится сложнее. Задачи — объёмнее, пользовательский интерфейс — насыщеннее, HTML, CSS и Javascript — огромнее, а сон фронтендера — короче и беспокойнее. Необходимо грамотно структурировать код, выполнять множество рутинных задач (компиляция css- и js-препроцессоров, сборка спрайтов, подготовка и оптимизация изображений, минификация файлов и др). Если вы работаете в команде — это автоматически увеличивает сложность разработки. Чтобы решить эти проблемы, я создал TARS — сборщик html-вёрстки, основанный на gulpjs.

Предлагаю такую подборку вопросов, которую можно задать кандидату. Ответы выводятся во всплывающем окне.
Испытуемому предлагается предугадать, что появится в окне alert.
Главное здесь — нужно объяснить, почему был получен такой ответ.
Не страшно, если ответ отличается от действительного, потому что в вопросах есть подковырки. Тогда нужно будет объяснить, как получился такой результат.
Скопируйте код в консоль браузера или вставьте его на html страницу. После каждого alert'а спрашивайте у собеседуемого, что будет на следующем, и почему.

Приветствую. Представляю сообществу проект Konva.js.

Konva.js — это фреймворк, который позволяет работать c canvas 2d в объектном стиле с поддержкой событий.

Кратко список особенностей выглядит так:

1. Объектное API
2. Вложенные объекты и «всплытие» событий
3. Поддержка нескольких слоёв (нескольких canvas элементов)
4. Кэширование объектов
5. Поддержка анимаций
6. Настраиваемый drag&drop
7. Фильтры
8. Готовые к использованию объекты, включая прямоугольник, круг, изображение, текст, линия, SVG путь, ..
9. Простое создание собственных фигур
10. Событийная архитектура, которая позволяет разработчикам подписываться на события изменений аттрибутов, отрисовки, и так далее
11. Сериализация и десериализация
12. Продвинутый поиск с помощью селекторов stage.get('#foo') и layer.get('.bar')
13. Десктоп и мобильные события
14. Встроенная подержка HDPI устройств
15. и еще много разного

Далее подробней рассмотрим возможности фреймворка с примерами кода.

Автор оригинальной статьи Ali Mese добавил ещё 100 новых бесплатных сервисов. Все 400 потрясающих сервисов доступны здесь. И еще подборку +500 инструментов от 10 марта 2017 г. смотрите здесь.

A. Бесплатные Веб-Сайты + Логотипы + Хостинг + Выставление Счета

• HTML5 UP: Адаптивные шаблоны HTML5 и CSS3.
• Bootswatch: Бесплатные темы для Bootstrap.
• Templated: Коллекция 845 бесплатных шаблонов CSS и HTML5.
• Wordpress.org | Wordpress.com: Бесплатное создание веб-сайта.
• Strikingly.com Domain: Конструктор веб-сайтов.
• Logaster: Онлайн генератор логотипов и элементов фирменного стиля (new).
• Withoomph: Мгновенное создание логотипов (англ.).
• Hipster Logo Generator: Генератор хипстерских логотипов.
• Squarespace Free Logo: Можно скачать бесплатную версию в маленьком разрешении.
• Invoice to me: Бесплатный генератор счета.
• Free Invoice Generator: Альтернативный бесплатный генератор счета.
• Slimvoice: Невероятно простой счет.

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

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

UPD (13 марта 2015): Заменил несколько плагинов на более актуальные + решил проблему с импортом CSS файлов внутрь SCSS

Как мы избавились от JavaScript-библиотек социальных сетей, ускорили скорость загрузки страниц и использовали RESTful API для “шаринга” и “лайков”.

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

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