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

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

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



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

Всем привет!

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


Забегая немного вперед – так выглядит кусочек уже готовой локации в действии.

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

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

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

Трем программистам предложили пересечь поле, и дойти до дома на другой стороне. Программист-новичок посмотрел на короткую дистанцию и сказал, «Это не далеко! Это займет у меня десять минут». Опытный программист посмотрел на поле, немного подумал, и сказал: «Я мог бы добраться туда за день». Новичок посмотрел на него с удивлением. Гуру-программист посмотрел на поле и сказал. «Кажется минут десять, но я думаю пятнадцати будет достаточно». Опытный программист рассмеялся.

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

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

Гуру программист пустился в путь, и пошел прямо через поле. Целеустремленно и прямо. Он достиг цели всего за десять минут.
«Как тебе это удалось?» — спросили двое других — «Как ты умудрился не зацепить ни одной мины?»
«Легко» — ответил он. «Я не закладывал мины на своем пути».

Как ни прискорбно, придется признать – мы сами закладываем себе мины. В первой части я подробно разобрал основные риски в разработке ПО и описал технологические и методологические способы ослабления этих рисков. За прошедший год я получил множество комментариев, основной смысл которых сводился к следующему: «все круто, но с чего начать и как все это будет выглядеть в реальном мире». Действительно, первый текст носит скорее теоретический характер и представляет собой каталог ссылок. В этой статье я постараюсь привести как можно больше примеров.

Привет! Я Максим Андреев, программист бэкенда Облака Mail.Ru. На последнем Security Meetup’е я поделился результатами своего исследования протокола автоматической настройки прокси WPAD. Для тех, кто пропустил, — сегодняшний пост. Я расскажу о том, что такое WPAD, какие возможности для эксплуатации он предоставляет с точки зрения злоумышленника, а также покажу примеры того, как можно частично перехватывать HTTPS-трафик с помощью этой технологии.

Добрый день! Не так давно прошла серия семинаров CLRium по новейшим технологиям и редко-раскрываемым темам CLRium #2. Мы собрали у себя в залах около 740 человек, что для нас является — фантастическим результатом. Сегодня хотелось представить вам свежие видеозаписи семинара и ссылки на репозитории спикеров:

День 1:

Ссылки с привязкой ко времени:

• Андрей Акиньшин — с самого начала
• Станислав Сидристый — .NET objects in Shared Memory

В последнее время мы часто слышим о реактивном программировании и видим различные баззворды: message-driven архитектура, event-sourcing, CQRS. К сожалению, на Хабре об этом пишут довольно мало, поэтому я решил исправить ситуацию и поделиться своими знаниями со всеми желающими.

В этой статье мы узнаем об основных особенностях реактивных приложений, рассмотрим, как паттерны CQRS и EventSourcing помогут нам в их создании, а чтобы не было скучно, мы с вами шаг за шагом сделаем свой мессенджер с вебсокетом и акторами, соответствующий всем канонам реактивного программирования. Для реализации всего этого добра, мы будем использовать замечательный язык Scala вместе с не менее превосходной библиотекой Akkа, реализующей модель акторов. Еще, мы будем использовать Play Framework для написания веб-составляющей нашего приложения. Итак, приступим.

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

В прошлый раз я описал в общих чертах использование Akka для игрового сервера.
Сейчас разберем простой, но тем не менее рабочий пример сервера.

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

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

Для уточнения спутниковых данных используются дифференциальные системы и RTK (real-time kinematics) технологии, но до последнего времени подобного рода устройства были дорогими и громоздкими. Последние достижения цифровой техники в лице микрокомпьютера Intel Edison помогли решить эту проблему. Итак, встречайте: Reach – первый компактный высокоточный приемник GPS, очень доступный по цене, и, к тому же, разработанный в России.

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

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

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

Наш CEO — легендарный Сергей Белоусов решил поменять многое в компании, в том числе логотип. Задание было сформулировано довольно просто:



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

Аналитики Gartner говорят, что доля Mac платформы в корпоративном секторе растет год от года. Поэтому вопрос централизованного управления Mac пакетами в корпоративных средах становится все более актуальным. Каковы преимущества использования централизованного управления ПО? Среди них:

1. возможность устанавливать приложения на большое количество клиентов с едиными настройками;
2. минимизация количества проблем и инцидентов с ПО за счет применения единых стандартов подготовки установочных пакетов;
3. установка инсталляционных пакетов не требует действий от пользователя и каких-либо дополнительных привилегий.

Тема управления ПО достаточна обширна. Выше приведены лишь наиболее яркие и бытовые примеры. Поэтому в нашей компании подготовка инсталляционных пакетов Mac OS предоставляется в качестве отдельного сервиса.

План первой части статьи:

1. Форматы, типы пакетов. В данном разделе рассмотрим разновидности пакетов и их структуру.
2. Краткий обзор наиболее популярных инструментов для подготовки инсталляционных пакетов.

(под катом много фото)

Первая часть статьи здесь.

В качестве примера продемонстрируем создание установочного пакета Mozilla Firefox 31.5.3 esr в среде Pakage Maker. Firefox достаточно популярен среди наших заказчиков и при этом является достаточно показательным.

Для начала скачаем последнюю версию пакета с официального сайта (на момент написания статьи была доступна Mozilla Firefox 31.5.3 esr). Запускаем DMG файл на MAC-машине. Firefox.app переносим в Applications:


(под катом много фото)

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



Сегодня, на мой взгляд, одна из проблем навигационных устройств – это то, что они не ведут пользователя по полосам. Эта проблема увеличивает время в пути, пробки и аварийность. Недавно google maps начали отображать разметку дороги перед поворотом, что уже хороший результат, но и тут можно многое улучшить. Карты не знают на какой полосе сейчас находится машина, средствами gps узнать это проблематично, у gps слишком большая погрешность для этого. Если бы мы знали текущую полосу, то знали бы скорость движения по полосами и могли бы задолго подсказывать пользователю в явном виде, на какую полосу и когда ему лучше перестроиться. Например, навигатор говорил бы “Продолжайте держаться этой полосы до перекрестка” или “Перестройтесь на крайнюю левую полосу”.

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

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

От переводчика: англоязычные it-блоггеры обычно начинают такие статьи со слов I'm so excited. Про Wix# я узнал совершенно случайно и спешу поделиться этим открытием с хабрасообществом, т.к. каждый, кто имел дело с «голым» WiX, знает, насколько неприятным может быть этот процесс. И вот теперь можно сделать msi-дистрибутив, написав всего лишь несколько строчек на C#! По-моему, это круто! А относительно недавно (4 дек 2014) автор Wix# Олег Шило дал интервью изданию InfoQ. Перевод этого интервью я и представляю вашему вниманию. И прошу не судить строго за кальку некоторых слов — тот же «деплоймент» мне как-то ближе, чем «развертывание».

Наконец, перевод очередной статьи от Давида Ревуа — прекрасного художника, использующего свободное программное обеспечение, а также постоянного члена сообществ Krita Foundation и Blender Institute. Мастер делится с начинающими художниками инструкцией по сборке самой свежей версии графического редактора Krita из исходных кодов. Он считает, что этот процесс на самом деле не так сложен и заковырист, как кажется на первый взгляд. Все этапы прекрасно проиллюстрированы. Приобщайтесь!

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

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

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