Все мы знаем знаменитое выражение «Content is king». Но, если говорить более конкретно, нужно уточнить, что в Интернете важнее всего изображения (как копирайтеру, мне сложно говорить эти слова, но это действительно так).

Как пользователи интернета, мы жаждем изображений — чем больше, тем лучше. Но, как разработчики, создатели контента и владельцы сайтов, мы впадаем в тоску из-за проблем с изображениями. По последним данным HTTP Archive, средняя страница весит 1795 КБ, из которых 56% (1000 KB) занимают изображения. Это делает изображения, наверное, наиболее благодатной почвой для улучшения скорости загрузки страниц. И это — то, почему мы в Radware так много времени вкладываем в оптимизацию изображений.

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


Изображение взято с сайта litmus.com

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

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

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

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

Я бы такие игрушки на собеседованиях ставил кандидатам и смотрел, как человек решает.



Анонс на reddit: www.reddit.com/r/golang/comments/2veiht/operation_go_a_routine_mission
Автор — Andy Brewer

Спешу предположить, что вы наслышаны о ES6 и, возможно, успели попробовать её. Тогда вам наверняка покажется интересной заметка о некоторых фичах спецификации, опубликованная Блейком Уильямсом в блоге Thoughtbots. Я же, с позволения автора, публикую перевод.

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

ES6 сегодня

Вы можете начать писать на ES6 прямо сейчас, используя транслятор в ES5 6to5. 6to5 поддерживает достаточно много инструментов сборки, в их числе: Broccoli, Grunt, Gulp и Sprockets. У меня всё прекрасно работало со sprockets-es6, а 4.x Sprockets будут поддерживать 6to5 из коробки. Также вы можете попробовать ES6 прямо в браузере в 6to5 REPL.

В предыдущей статье мы начали изучение Ansible, популярного инструмента для автоматизации настройки и развертывания ИТ-инфраструктуры. Ansible был успешно установлен в InfoboxCloud, описаны принципы работы, базовая настройка. В завершении статьи мы показали как быстро установить nginx на несколько серверов.

В этой статье мы продолжим изучение Ansible: разберем вывод playbook, научимся отлаживать их и разделять для удобства повторного использования.

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

КДПВ (эта картинка актуальности не потеряет, наверно, никогда):



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

Краткий обзор

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

Введение

Статья начинается с краткого обзора фреймворка AngularJS. Обзор объясняет основные компоненты AngularJS: directives, filters, controllers, services, scope. Во втором разделе перечислены и описаны различные конструкции и архитектурные шаблоны, которые реализованы внутри фреймворка. Шаблоны сгруппированы по компонентам AngularJS, в которых они используются. Если некоторые шаблоны используются в нескольких компонентах, это будет указано.
Последний раздел включает несколько архитектурных шаблонов, которые обычно используются в SPA построенных на AngularJS.

В эпоху Big Data графическое представление многомерных данных является весьма актуальной задачей. Однако результат визуализации не всегда соответствует ожиданиям. Вот пример не самого наглядного графика для изображения многомерных данных «Ирисы Фишера»:

Персональные рекомендации позволяют познакомить пользователя с объектами, о которых он, возможно, никогда не знал (и не узнал бы), но которые могут ему понравиться с учетом его интересов, предпочтений и поведенческих свойств. Однако, часто пользователь ищет не новый объект, а, к примеру, объект A похожий на объект B («Форсаж 2» похож на «Форсаж»), или объект A, который приобретается/потребляется с объектом B (сыр с вином, пиво с детским питанием, гречка с тушенкой и т.д.). Построить такие рекомендации позволяют неперсонализированные рекомендательные системы (НРС).


Рекомендовать похожие/сопутствующие объекты можно, ориентируясь на знания об объектах (свойства, теги, параметры) или на знания о действиях, связанных с объектами (покупки, просмотры, клики). Преимуществом первого способа является то, что он позволяет достаточно точно определить похожие по свойствам объекты («Форсаж 2» и «Форсаж» — похожие актеры, похожий жанр, похожие теги, ...). Однако данный способ не сможет порекомендовать сопутствующие объекты: сыр и вино. Еще одним недостатком этого способа является тот факт, что для разметки всех объектов, доступных на сервисе, требуется не мало усилий.

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

Под катом описан метод ассоциаций, позволяющий построить неперсонализированные рекомендации, основываясь лишь на данных о действиях над объектами. Там же код на Python, позволяющий применить метод для большого объема данных.

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

1 Один столбец вместо нескольких

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

Начало: habrahabr.ru/post/249625

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

Первая статья цикла неожиданно даже для меня вылилась в общие рекомендации о поведении Администратора сервера. Но уже сейчас очевидно, что это — бег впереди паровоза. Перед тем, как некто решает установить браузерку и заделаться админом, он должен ответить себе на главный Вопрос. И звучит этот вопрос так: «ЗАЧЕМ?!»

Мы продолжаем [ 1, 2 ] сравнивать подходы к работе в стартапе в России и США. Сегодня высказывания Сэма Альтмана, Дейва МакКлюра, Дастина Московитца, Фила Либина о важных и неоднозначных аспектах жизни стартапа прокомментирует Илья Красинский – инструктор акселераторов ФРИИ, Яндекс.Старт, Happy Farm по экономике продукта и метрикам.

С 2011 года по лето 2013 Илья руководил разработкой и product-менеджментом мобильных и десктоп-продуктов LinguaLeo (5М установок). C 2010 года руководил разработкой iOS-приложения LinguaLeo, которое в момент выхода заняло 1 место среди всех бесплатных приложений в России. Помог рассчитать экономику продукта и определить ключевые метрики более 500 компаниям (от международных компаний с 30M+ пользователей до небольших стартапов).

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

Содержание основного курса

• Статья 1: алгоритм Брезенхэма
• Статья 2: растеризация треугольника + отсечение задних граней
• Статья 3: Удаление невидимых поверхностей: z-буфер
• Статья 4: Необходимая геометрия: фестиваль матриц
  
  • 4а: Построение перспективного искажения
  • 4б: двигаем камеру и что из этого следует
  • 4в: новый растеризатор и коррекция перспективных искажений
• Статья 5: Пишем шейдеры под нашу библиотеку
• Статья 6: Чуть больше, чем просто шейдер: просчёт теней

Улучшение кода

• Статья 3.1: Настала пора рефакторинга
• Статья 3.14: Красивый класс матриц

---

Official translation (with a bit of polishing) is available here.

---

Новый растеризатор и коррекция перспективных искажений

Тема сегодняшего разговора — это коррекция искажений интерполяции, посмотрите на разницу текстурирования на полу:



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

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

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

В Go кросс-платформенность вышла на тот уровень, когда впервые можно смело отказаться от compile farms, специально настроенных dev-сред, виртуальных машин для сборки или chroot/docker-dev решений. И это ещё один серьезный game-changer, подробнее о котором я и хочу рассказать и показать на примерах
Поехали.

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

Итак, у вас в почте письмо от заказчика. В письме пол-страницы требований и просьба дать оценку.

Давайте сразу определимся, что собирательного заказчика не существует. Говоря: “Нам прилетел проект от Microsoft”, на самом деле мы имеем в виду: “Геннадий, который сейчас работает в Microsoft, прислал прислал нам письмо, про проект, который, возможно, нужен кому-то в Microsoft.” Итак, у нас в почте письмо от Геннадия.

В этот момент, пожалуйста, не предпринимайте ничего, что предполагает участие Геннадия. Не нужно организовывать встречу. Не нужно писать письмо с вопросами. Наша задача сократить количество действий с его стороны. Почему – ниже.

Привет, Мегамозг! Раньше подобные материалы мы писали на Хабр, но после отселения «управленческих и маркетинговых» историй, решили попробовать здесь.

Недавно мы запустили совместно с UMI большой образовательный спецпроект про продажи и маркетинг для студий и агентств (мы уже опубликовали все 5 сезонов в 17 эпизодов). В его рамках я подготовил текст про ключевые KPI в управлении и планировании развития бизнеса агентства — и хотел поделиться им с аудиторией Хабра/Мегамозга.

1. Вводная, зачем этот материал

Наверное, любой руководитель агентства с минимальным управленческим бэкграундом будет знаком с 80% описанных в нашем материале KPI. Цель нашего материала — показать многообразие возможных показателей оценки результативности и эффективности бизнеса с учетом агентской специфики. Если вы найдете в нашем списке из более чем 50 индикаторов хотя бы пару показателей, об учете которых вы ранее не задумывались, а они важны — то мы добьемся своей цели.

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

Ansible – популярный инструмент для автоматизации настройки и развертывания ИТ-инфраструктуры.

Основные задачи, которые решает Ansible:

• Управление конфигурациями. Максимально быстрая и правильная настройка серверов до описанной конфигурации.
• Провижнинг. Управление процессом развертывания новых облачных серверов (например через API, с помощью Docker или LXC).
• Развертывание. Инсталляция и обновление ваших приложений без простоя наилучшим образом.
• Оркестрация. Координация компонентов вашей инфраструктуры для выполнения развертываний. Например проверка, что веб-сервер отключен от балансировщика нагрузки, до апгрейда ПО на сервере.
• Мониторинг и уведомления.
• Логгирование. Централизованный сбор логов.

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

Привет, Мегамозг! После изменений на Хабре, получается так, что подборки ссылок на материалы о создании контента, маркетинге и Growth Hacks переезжают на вновь созданный ресурс.



Статьи на английском и видеоматериалы помечаются специальными иконками.

Содержание курса

• Статья 1: алгоритм Брезенхэма
• Статья 2: растеризация треугольника + отсечение задних граней
• Статья 3: Удаление невидимых поверхностей: z-буфер
• Статья 4: Необходимая геометрия: фестиваль матриц
  
  • 4а: Построение перспективного искажения
  • 4б: двигаем камеру и что из этого следует
  • 4в: новый растеризатор и коррекция перспективных искажений
• Статья 5: Пишем шейдеры под нашу библиотеку
• Статья 6: Чуть больше, чем просто шейдер: просчёт теней

Улучшение кода

• Статья 3.1: Настала пора рефакторинга
• Статья 3.14: Красивый класс матриц

---

Official translation (with a bit of polishing) is available here.

---

Сегодня мы заканчиваем с ликбезом по геометрии, в следующий раз будет веселье с шейдерами!
Чтобы не было совсем скучно, вот вам тонировка Гуро:



Я убрал текстуры, чтобы было виднее. Тонировка Гуро очень проста: добрый дяденька-моделёр дал нам нормальные вектора к каждой вершине объекта, они хранятся в строчках vn x y z файла .obj. Мы считаем интенсивность освещения для каждой вершины треугольника и просто интерполируем интенсивность внутри. Ровно как мы делали для глубины z или для текстурных координат uv!

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

Текущий код, который сгенерировал эту картинку, находится здесь.

В Акселераторе ФРИИ работу со стартапами начинают с того, что пытаются определить, на какой стадии развития находится компания. Почему именно с этого? В целом, большая часть проблем у стартапов появляются от отсутствия фокуса: предприниматели совершают много ненужных действий, не концентрируясь на том, что приведет их бизнес к точке безубыточности. Чтобы понять, какие действия компании необходимо совершить в настоящий момент, нужно определить, на каком этапе развития она находится. Для этого во ФРИИ используется такой инструмент, как дорожная карта или road map. Мы выделяем в развитии ИТ-стартапов три больших этапа – поиск и изучение клиентов, тестирование каналов продаж и масштабирование. В данном материале мы пошагово рассмотрим первую большую стадию развития стартапа – Customer Discovery, поиск и изучение клиентов. Обычно оборот компаний на этой стадии не превышает 100 тысяч рублей. Какие шаги должен совершить ИТ-стартап, чтобы уверенно перейти к следующей стадии — тестированию каналов продаж?