Хабр уже насыщен статьями на тему «нового» формата изображений WebP (описание, сравнение с JPEG2000, сравнение с BPG, использование, подключение на сайте). К сожалению, открытыми остаются вопросы: как правильно подключить WebP на сайте, чтобы «все работало», и насколько он лучше (меньше) PNG/JPEG. В этой заметке я буду отвечать на оба вопроса.

Предполагаю, что вы уже в курсе оптимизации изображений, умеете конвертировать изображения в WebP, понимаете разницу между использованием JPEG и PNG на сайте, знаете инструменты ExifTool, jpegtran, mozjpeg, JPEGrescan, optipng, pngcrush, pngwolf, zopflipng и TruePNG, а также различаете пастеризацию молока и постеризацию изображений.

Если все так — то переходим к сути.

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

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

Соглашусь, трудно взять и начать писать BEM без разбега: и нотация глаз колет, и старые трюки не проходят, и думать приходится системно. И вообще, писали как-то годами без BEM'а и писать будем! А ведь для легкого и непринужденного преодоления порога вхождения нужно сделать всего два движения. Во-первых, понизить сам порог, смягчив BEM. И во-вторых, немного подтянуться самим. Тогда переход будет ровненьким и мы мягко вкатимся в эру читабельного и поддерживаемого CSS.

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

Ключевые моменты:
* Реализация скрипта для проверки PTR посетителей;
* Конфигурирование nginx в IfIsEvil-style с ветвлениями map;
* Имена location в переменных map;
* Управление ветвлением через try_files /nonexist $map_var.

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

В прошлом месяце Microsoft стал навязывать пользователям обновление до Windows 10, вместо апдейта по желанию. Это, как ожидается, вызовет новую волну активаций, так как пользователи, которые не настроили блокировку обновлений, обнаружат на своей машине полностью готовый к установке пакет Windows 10.

Компания Microsoft заявила, что пользователи смогут отказаться от обновления до новой ОС после начала установки, но не сообщила, будет ли опять предлагаться переход на Win 10 после того, как клиент откажется от апдейта.

Предполагалось, что подобная политика приведет к значительному росту установок, но по подсчетам Net Applications, StatCounter и DAP (см. выше график) этого не произошло, сообщает extremetech.

Предлагаю вашему вниманию перевод статьи How To Pick a Frontend Web Framework c сайта top.fse.guru.

Привет, приятель!

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

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

Методология изменения версий продукта программного обеспечения

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

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

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

Несколько дней назад David Demaree, главный по Typekit в Adobe, издал крутую книжку "git для людей". Чтобы привлечь к ней внимание, он опубликовал выжимку самой, на мой взгляд, интересной главы — как оформлять коммиты чтобы и волки были целы, и овцы сыты, и песец не пришел. А я за эти выходные подготовил выжимку из выжимки — сокращенный и адаптированный перевод, чтобы можно было быстро прочитать и добавить в копилку своего опыта самое ценное.

На Хабре уже много писали о методологии БЭМ, выросшей в Яндексе. И мы решили, что пора системно рассказать о том, откуда она появилась и что сделало БЭМ таким, каким мы его знаем. Думаем, это будет интересно не только тем, кто уже использует БЭМ, но и тем, кто считает, что эта методология не подходит для их проектов. Возможно, они увидят, что мы решали проблемы, похожие на их собственные, и найдут что-то полезное для себя.



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

Суть в следующем: с помощью написанной программы автоматически по английским субтитрам разбиваю фильм/сериал на отдельные фрагменты. Также автоматически создается tsv файл для импорта в Anki (http://ankisrs.net), содержащий английский транскрипт и русский перевод (если были добавлены русские субтитры) каждого фрагмента.

Затем импортирую в Anki и просматриваю весь фильм следующим образом:

1. Просматривается видеофрагмент.
2. Прослушивается аудио с одновременным чтением английского транксрипта.
3. Прослушивается аудио еще раз с чтением русского перевода или просто смотрится перевод незнакомых фраз.
4. Заново просматривается видеофрагмент.

Пример просмотра таким образом (все 4 шага) одной карточки:

Пишущую машинку я расчехляю нечасто, но сегодня есть повод.

Тесты для JavaScript пишут многие, некоторые пишут много тестов. Есть несколько популярных тестовых фреймворков, таких как Jasmine, Mocha, QUnit, а также инструменты для автоматического запуска тестов. Некоторые из них даже интегрированы в некоторые редакторы кода. Например, Karma runner и Mocha прекрасно интегрированы моими коллегами в WebStorm. Словом, существуют разные способы запускать тесты автоматически и получать результаты в течении одной или нескольких секунд. Впрочем, время зависит от количества и характера тестов.

Как мы используем наши JavaScript тесты

Все CSS-селекторы живут в глобальной области видимости.

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

Абсолютно каждый селектор потенциально может вступить в борьбу с другим селектором или стилизовать «посторонний» элемент. В этой «глобальной» борьбе селектор может даже полностью проиграть, в итоге не применив к странице ни одного из своих правил.

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

Так не должно быть. Пора оставить позади эру глобальных стилей. Наступило время закрытого CSS.

Хорошо бы иногда придвинуть стол к дивану и сделать его ниже, оставив на нем компьютер. Тогда можно немного поработать лежа, или отправить статью на Хабр, или посмотреть видео… А еще, под стать времени, стол должен быть визуально легким. Он не предполагает большого количества книг или бумаг, да и стандартный компьютер ATX тоже будет заменен чем-то более легким. Так что никаких полок и тумбочек — все в облако! Такие мысли привели к настоящей работе по железу, с 60 болтами, сверлением более чем 120 отверстий в профиле и решениями из чистой и простой механики позапрошлого века.

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

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

Такое положение вещей заставляло многих переходить на хром, а кто не хотел — искал пути решения в виде разного рода оптимизаций, которые по большому счёту из-за нелогичного подхода распределения потоков или банального желания настрочить что-то в блог просто усугубляли ситуацию. Теперь один процесс должен был не просто работать, а очень быстро работать! В конечном итоге и разработчики сами прекрасно понимали, что одно дело — мало памяти, другое — низкая скорость работы, которая в основном оправдана старыми связками с XUL. На деле: открываем в Firefox несколько вкладок сразу, скролим их и в момент загрузки видим, что все тормозит — ни о каком плавном серфинге речи быть не могло.

BPG (Better Portable Graphics) — новый графический формат, цель которого заменить JPEG там, где качество или размер файла имеют значение. Именно так описывает BPG создатель этого формата — гениальный программист Фабрис Беллар, автор таких программ как LZEXE, FFmpeg, QEMU и др.

Основные преимущества BPG

• Высокая степень сжатия. Файлы гораздо меньше, чем JPEG при таком же качестве.
• Поддержка большинством веб-браузеров через маленький Javascript-декодер (56 КБ в gzip).
• Основан на подмножестве открытого стандарта видеосжатия HEVC.
• Поддержка тех же форматов цветности, что и в JPEG (grayscale, YCbCr 4:2:0, 4:2:2, 4:4:4) для снижения потерь во время конвертации. Альфа-канал поддерживается. Цветовые пространства RGB, YCgCo и CMYK тоже поддерживаются.
• Нативная поддержка от 8 до 14 бит на канал для расширения динамического диапазона.
• Возможно сжатие без потерь.
• Различные метаданные (такие как EXIF, профили ICC, XMP) можно внедрить в файл.
• Поддержка анимации.

Именно последний пункт даёт возможность предположить, что BPG заменит в интернете анимированный GIF. В самом деле, он лучше по всем параметрам.

Это перевод статьи ребят из Aristotle Interactive.
Говорят, фотография стоит тысячи слов. Но в сети, фотография может занимать тысячу килобайт и больше! По данным HTTP Archive, изображения в среднем занимают до 64% веб-страницы. Учитывая это, оптимизация изображений — крайне важный аспект, особенно принимая во внимание то, что многие пользователи просто уйдут с сайта, если он не загрузится за несколько секунд.

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

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

Уже очень давно самыми популярными форматами остаются: JPEG — для lossy сжатия, PNG — для сжатия без потерь и GIF для анимации. Эти форматы поддерживаются всеми браузерами и веб-приложениями.

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

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

Сейчас уже созданы несколько форматов, имеющих все шансы заменить и JPEG и GIF и PNG. Очень хорошие результаты показывают гугловский WebP и «свободный» BPG.

В последнее время наблюдается рост платформ, построенных на асинхронной архитектуре. На асинхронной модели построен самый быстрый в мире веб-сервер nginx. Активно развивается шустрый серверный javascript в лице Node.js. Чем же хороша эта архитектура? Чем она отличается от классической многопоточной системы? На эту тему было написано огромное множество статей, но полного понимания предмета они дали далеко не всем. Часто приходится наблюдать споры вокруг Node.js vs PHP+apache. Многие не понимают, почему некоторые вещи можно сделать на Node.js, но нельзя на PHP или наоборот — почему вполне правильный рабочий код на PHP сильно замедлится в Node.js, а то и повесит ее. В данной статье я бы хотел еще раз подробно объяснить разницу в их архитектуре. В качестве примеров двух систем, возьмем вебсервер с PHP и Node.js.