Недавно я снова исследовал вопрос загрузки шрифтов, так как я хотел использовать локальную копию шрифта и сделать ее загрузку максимально быстрой и эффективной. Данный подход существенно отличается от того, когда вы используете TypeKit или шрифты Google и простые сниппеты «копировать/вставить».

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

1, 2, 3

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

Цели:

1. Асинхронно загружать веб-шрифты
2. Избежать сильного пересчета положения в макете
3. Как можно быстрее загружать веб-шрифты
4. Избежать загрузки шрифтов для возвращающихся посетителей

А теперь давайте попробуем добиться наших целей поэтапно:

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

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

Важные замечания:

• Пункты с неуказанным источником написаны мной самостоятельно. Поправьте меня, если вы заметите какие-то неточности. Предложите лучшую аналогию, если это возможно.
• Заголовки ссылаются на соответствующие им статьи в Wikipedia. Пожалуйста, читайте эти статьи для более серьезных и детальных объяснений.
• Аналогии — отличный способ объяснить материал, но они не идеальны. Если вы хотите по-настоящему понять перечисленные концепции, вам следует начать с фундаментальных азов и рассуждать, исходя из них.

Также зацените эту инфографику (вариант на русском), если вы просто начинающий программист.

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

Внутри схемы, гифки, таблицы и много интересного текста.

Вы готовы?

Специалист, приступающий к изучению функционального программирования, сталкивается как с неоднозначностью и запутанностью терминологии, так и с постоянными ссылками на «серьезную математику».

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

• ко-вариантный функтор
• контра-вариантный функтор

которые являются стартовой точкой для понимания всего множества категориальных конструкций, куда можно включить

• Exponential (Invariant) Functor, BiFunctor, ProFunctor
• Applicative Functor, Arrow, Monad / Co-Monad
• Monad Transformers, Kleisli, Natural Transformations

Объяснено происхождение категориальной терминологии, указана роль языковых механизмов в реализации категориальных абстракций и рассмотрено несколько ковариантных (Option, Try, Future, List, Parser) и контравариантных (Ordering, Equiv) функторов из стандартной библиотеки Scala.

Первая статья в «категориальной серии»:

1. FP на Scala: что такое функтор?
2. FP на Scala: Invariant Functor

Если Вы желаете сильнее погрузиться в мир Scala, математики и функционального программирования — попробуйте онлайн-курс «Scala for Java Developers» (видео + тесты, всего за 25% цены!).

• Про языковые механизмы абстракции
• Про теорию категорий и Haskell
• Что такое ковариантный функтор
• Примеры ковариантных функторов
• Ковариантный функтор: Identity Law
• Ковариантный функтор: Composition Law
• Ковариантный функтор: используем для оптимизации
• Что такое контравариантный функтор
• Примеры контравариантных функторов
• Контравариантный функтор: Identity Law
• Контравариантный функтор: Composition Law
• Что дальше?

В статье рассматривается

• Как такая абстракция теории категорий как инвариантный функтор (Invariant Functor), который иногда называют экпоненциальным функтором (Exponential Functor), выражается на Scala.
• Два правила (Identity Law, Composition Law), которым доложен следовать каждый инвариантный функтор.
• Приведен пример инвариантного функтора с состоянием (Value Holder)
• Приведен пример инвариантного функтора-отношения между элементами множества (полугруппа)

Публикация является продолжением FP на Scala: Что такое функтор? в которой были рассмотрены следующие вопросы

• Какая имеется связь между теорией категорий, Haskell и Scala.
• Что такое ковариантный функтор.
• Что такое контравариантный функтор.

Содержание

• Введение
• Что такое Invariant Functor
• Invariant Functor — Identity Law
• Invariant Functor — Composition Law
• Пример #1: Value Holder
• Пример #2: Полугруппа
• Инвариантный функтор в библиотеках

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

В общем случае решение задачи слежения содержит три основных этапа:
– выделение сегментов;
– установление соответствия между выделенными сегментами и отслеживаемыми объектами;
– уточнение или прогнозирование положения объектов интереса.

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

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

Предлагаю вашему вниманию перевод статьи «Responsive Upscaling: Large-Screen E-Commerce Design» автора Christian Holst.

Революция в адаптивном дизайне не за горами (если уже не случилась!), и даже не смотря на то, что интернет-магазины не взялись на адаптивный дизайн столь же агрессивно, как другие индустрии, все же это становится популярным.

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

1. Только 18% из 50 ведущих американских интернет-магазинов, которые мы тестировали ранее, в этом году адаптировали свой дизайн под большие экраны (в то время как у 94% этих сайтов дизайн адаптирован под мобильные устройства).
2. Почти три четверти электронных продаж все ещё совершаются на ПК, а не на мобильных устройствах (смотрите здесь, здесь и здесь).
3. Около трети этих пользователей приходят с экранов шире 1350 пикселей (смотрите здесь, здесь и здесь). (Примечание: Разумеется, есть разница между шириной экрана и шириной браузерного окна — реальное число пользователей с браузером указанной ширины будет ниже. Мы рекомендуем вам отслеживать размеры браузерного окна в вашей веб-статистике для более полной картины того, насколько значителен этот сегмент для вашего сайта.

Здравствуйте, уважаемые читатели.

Сегодня мы хотели поговорить с вами на тему «все новое — это хорошо забытое старое» и вспомнить об акторах, описанных Карлом Хьюиттом еще в начале 70-х. А все дело в том, что недавно вышла вот такая книга:



Она довольно объемная — в переводе должна получиться более 500 страниц.

Несмотря на подчеркнутую элитарность книги (Akka и Scala), ее автор Вон Вернон (крупнейший специалист по DDD) уверен, что архитектурные паттерны, описанные в этой работе, вполне реализуемы на .NET и C#, о чем рассказывает в приложении. Мы же размещаем под катом перевод статьи, автор которой допускает перенос акторной парадигмы на язык Java. Поскольку рейтинг книги на Amazon стабильно высок, а тема универсальна, просим поделиться вашими мнениями как о ней, так и об акторной архитектуре в принципе.

Обратили внимание, что доля поискового трафика Яндекса на Кабанчике значительно меньше, нежели доля Google. Т.е. значительно меньше, чем среднее соотношение трафика Yandex/Google по рынку.

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

Общие отличия Google от Yandex

• Возраст сайта больше важен для Yandex.
• Продвигаться по НЧ намного легче в Яндексе. Для этого достаточно писать качественный уникальный контент. В Google без ссылок на страницу продвигать НЧ тяжко. Для СЧ и НЧ Яндексу нужны трастовые доноры.
• Скорость индексации сайта в Яндекса в разы медленнее, нежели у Google: 8-10 дней против 1-2.
• Частое обновления контента влияет на траст в Google. Яндекс любит старые уникальные тексты.
• По ВЧ запросам в ТОПе Яндекса можно видеть в основном главные страницы сайтов. В Google — чаще внутренние страницы.
• На одной странице поиска Google может находится 5 ссылок с одного сайта. в Яндексе — только одна страница.
• На Яндекс легче влиять с помощью поведенческих факторов, нежели на Google.
• Google далеко не всегда обращает внимание на запрет к индексации в robots.txt.
• Скорость загрузки страниц более важна для Google. Он не пускает в ТОП медленные сайты. Для Яндекса скорость загрузки сайта не так важна.
• Яндекс больше любит поддомены для региональных запросов. Т.е. для продвижения в другом городе лучше использовать домен gorod.site.com/…
• Для Яндекса имеет большое значение нахождение сайта в Яндекс.Каталоге.

Внутренняя оптимизация

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

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

Эта статья поможет ответить на вопросы владельцев, разработчиков и системных администраторов PHP-сайтов:

• Как оптимизировать сайт и ускорить его работу?
• С какой скоростью будет и может работать сайт, в соответствии с теми технологиями на которых он будет запущен?
• Какие технологии следует использовать настраивая сервер или VPS?

Типичная проблема:
В какой-то момент сайт начинает открываться и работать слишком медленно. Бывает, что хостинговая компания блокирует сайт за превышение нагрузки или перерасход ресурсов. Что же делать в такой ситуации?

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

И если говорить о серверах для PHP, то такой проблемой является способ исполнения php кода, ровно как и другие значимые настройки окружения на сервере.
Не зависимо от того, есть ли проблема в вашем коде или её нет, высокая у вас посещаемость или нет, от настроек сервера зависит очень многое. Что бы все сказанное не звучало пустыми словами и была написана эта статья.

В этом обзоре я протестирую только что установленный сайт на одном из самых распространённых движков управления контентом Drupal 7.33.

Для теста выбрана лишь одна составляющая php-хостинга. Мы будем тестировать web-серверы Nginx и Apache2, модули mod_php и php-fpm, версии php php53 и php56, посмотрим, как влияют оптимизаторы apc и opcache на скорость работы сайта.

Как построить график по n точкам? Самое простое — отметить их маркерами на координатной сетке. Однако для наглядности их хочется соединить, чтобы получить легко читаемую линию. Соединять точки проще всего отрезками прямых. Но график-ломаная читается довольно тяжело: взгляд цепляется за углы, а не скользит вдоль линии. Да и выглядят изломы не очень красиво. Получается, что кроме ломаных нужно уметь строить и кривые. Однако тут нужно быть осторожным, чтобы не получилось вот такого:

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

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

Последний предлагаемый метод спорный, но судите сами!

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

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

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

Что же нужно иметь ввиду и что можно сделать для создания относительно безопасного сайта?

Началось все с того что Adsense в очередной раз понизил оценку эффективности страниц:

А все мы знаем, что скорость сайта – один из факторов ранжирования в выдаче Гугла.

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

Изначально имеется сайтик со статьями, коих в интернете миллионы: CMS Wordpress 4.2, два десятка плагинов, тема, сверстанная фрилансером и shared хостинг.

Всем привет!

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

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

Можно прочитать много книг по базам данных, написать кучу приложений на аутсорс или для себя. Но при этом невозможно не наступить на грабли, при работе с действительно большими базами/таблицами особенно, когда downtime на большом проекте хочется свести к минимуму, а еще лучше совсем избежать. Вот здесь самые простые операции, как например изменение структуры таблицы может стать более сложной задачей. Наиболее интересные случаи, проблемы, грабли и их решения из личного опыта с которыми нам на проекте Pushwoosh пришлось столкнуться описаны под катом. В статье нет красивых картинок, зато есть много сухого текста.

Привет Хабр! Анализируя пользовательские данные для нужд маркетинга и рекламы, мы решили исследовать влияние типа личности пользователя на то, как он реагирует на рекламное объявление. За основу решили взять, пожалуй, самую популярную типологию линостей MBTI (Myers-Briggs Type Indicator), известную еще с середины 20-го века. Многие крупные западные компании используют тесты MBTI при найме или при формировании команды для работы над проектами.

Но нас интересует, конечно, не готовность пользователя к командной работе, а влияние его типа личности на желание кликнуть по баннеру. Поэтому вопрос, который мы исследовали звучит так: «Могут ли типы личности влиять на CTR в рекламных кампаниях?»

В этой статье я расскажу о том как мы это делали.