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

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

Перевод поста Виталия Каурова "Automating xkcd Diagrams: Transforming Serious to Funny".
Скачать файл, содержащий текст статьи, интерактивные модели и весь код, приведенный в статье, можно здесь.
Выражаю огромную благодарность Кириллу Гузенко за помощь в переводе.

---

Утром в понедельник я наткнулся на интересный вопрос, опубликованный в Mathematica Stack Exchange, с нехитрым заголовком — "создание графиков в xkcd-стиле". Из-за популярности веб-комиксов xkcd Рэндалла Манро (Randall Munroe), я ожидал, что люди добавят себе несколько закладок этой страницы и с десяток up-vote. Тогда я ещё не знал, как всё обернётся. Сложно предсказать вирусность какого-то мема, однако если удалось создать такой, то весьма здорово наблюдать, как растёт его популярность и как он распространяется в интернете. Через два дня этот пост имел уже более 100 тысяч просмотров, двести up-vote и 150 закладок; стали возникать ответы и схожие посты в других разделах Stack Exchange, в Twitter разразился небольшой ураган по этому поводу, появлялись обсуждения в Hacker News и reddit. Тут я приведу оригинал поста Amatya с примером изображения в xkcd-стиле:

«Я получил электронное письмо, на которое я захотел ответить с графиком в xkcd-стиле, но я не мог справиться с этим. Всё, что я рисовал, выглядело как надо, однако я не мог придумать такой команды для Plot Legends, чтобы сделать фрагменты текста плавающими. Может, есть какие-то идеи, как можно было бы создать графики в xkcd-стиле? Когда всё выглядит рисованным от руки и неточным. Думаю, рисование таких странных кривых в Mathematica должно быть трудным в реализации.»

Немного истории

Благодаря классному дядьке Кенту Беку (Kent Beck) родилась замечательная методология test-driven development. Не смотря на необычность подхода, переворачивающего привычный процесс написания кода с ног на голову (тест на функционал создается до реализации), сейчас уже можно сказать, что разработка через тестирование стала стандартом де-факто. Практически в любых вакансиях фигурирует требование к знанию и опыту использования методики TDD и соответствующих инструментов. Почему, казалось бы, ломающая привычную парадигму мышления методология прижилась и стандартизировалась? Потому что “Жизнь слишком коротка для ручного тестирования”, а писать авто-тесты на существующий код иногда просто не возможно, ведь код, написанный в обычной парадигме, как правило совершенно тесто-не-пригодный.

Стоит отметить, что за время своего существования методология успела обзавестись ответвлением (fork) в виде BDD. Дэн Норт (Dan North) в своей статье (Introducing BDD) указал на сложности внедрения TDD среди разработчиков и для решения обозначенных проблем предложил практику, которая называется behaviour-driven development. Основной фишкой BDD можно назвать микс из TDD и DDD, которая в начале выражалась в правильном именовании тестовых методов (названия тестовых методов должны быть предложениями). Апогеем BDD, на текущий момент, можно считать рождение языка Gherkin и инструментария, который его использует (Cucumber, RSpec и т.п.).

— Для начала, ты должен понять главное…
— Что главное?
— Нет никакой ложки!

"Матрица"
 

Как я уже неоднократно говорил ранее, некоторые вещи реализовать в Zillions of Games попросту невозможно. Впрочем, если нельзя, но очень хочется, то иногда бывает всё таки можно. Как далеко можно зайти по этому пути?

Это моё «оружие-призрак» (ghost gun) — термин, придуманный поборниками контроля за распространением оружия, и подхваченный любителями оружия. Это полуавтоматическая винтовка без серийного номера, о которой не знают органы охраны правопорядка. А привязанность, которую я к ней испытываю, проистекает из того факта, что я сделал её сам, в мастерской офиса WIRED.

Я справился практически в одиночку. У меня не было никаких знаний, касающихся оружия, а навыки по работе с инструментами были не лучше, чем у кроманьонца. При этом я сделал металлическую, работающую винтовку AR-15. Точнее, я сам сделал «ствольную коробку» (lower receiver) — основу конструкции, ту часть, которую законы США определяют, как «огнестрельное оружие». Всё, что мне нужно было для проекта — 6 часов, понимание компьютерных программ на уровне пятиклассника, кусок алюминия стоимостью $80 и безликий автоматический фрезерный аппарат Ghost Gunner.

Ghost Gunner — фрезерный станок стоимостью $1500, управляемый компьютером. Его продаёт компания Defense Distributed, выступающая за доступность оружия. Она стала известна в 2012 — 2013 годах, когда начала печатать первый пистолет на 3D-принтере, известный, как Liberator. И пока все вокруг спорили насчёт политических и законодательных вопросов, касающихся этой идеи, DD перешла с пластика к металлу.

Ghost Gunner вырезает объекты из алюминия на основе компьютерной модели. Первые поставки этого агрегата начаты этой весной. Группа DD хочет облегчить людям задачу изготовления частей оружия из материала, сравнимого по прочности с промышленными образцами.

Доброго времени суток, хабр!

Здесь мы не будем рассуждать о плюсах и минусах языков.



Мы будем использовать их вместе!

JavaScript библиотека jQuery была выпущена 9 лет назад и с тех пор этот open source проект внес ощутимый вклад в мир веб-разработки. Безусловно интересно оглянуться назад и посмотреть на истоки jQuery.

В апреле 2015 года создатель jQuery Джон Резиг (John Resig) опубликовал самую первую версию jQuery от января 2006 года. В этой публикации Джон дополнил код воспоминаниями о том, как создавался jQuery.

Вот несколько фактов, которые можно узнать изучая комментарии Джона:

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

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

Итак, что же такое дождь или снег в реальном мире?

В наше время для разработки фронтенда существует много фреймворков и библиотек. Есть хорошие, есть не очень. Часто нам нравится только какая-то концепция, модуль или синтакс. Универсальных инструментов не существует. В статье я описываю фреймворк будущего – такой, которого ещё нет. Я собрал достоинства и недостатки известных фреймворков и мечтаю об идеальном решении.

Абстракция опасна

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

var page = Framework.createPage({
	'type': 'home',
	'visible': true
});

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

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

Если мы поменяем пример на следующий:

Очень удивительно (я бы даже сказал — внезапно!), но кортеж-пара в GHC является функтором. Это сложно понять, ведь функтор должен иметь только один параметр, а у пары их два. Можно восхищаться тем, как разработчики стандартной библиотеки GHC умудрились предоставить такую абстракцию, но мне кажется, полученное решение все же следует признать неудачным.

Начнем с того, что оно интуитивно непонятно. Скажем, попробуйте вычислить вручную, не используя инструментов GHC, выражение (1+) `fmap` (2, 3). А после этого проверьте полученный результат, например, в ghci. У многих ли результат ручного вычисления совпал с тем, который выдала система? И если у вас результаты все же совпали, мне очень хотелось бы услышать хорошее объяснение того, как именно вам это удалось.

На прошлой неделе я обновил свои мониторы. Выбросил Apple Cinema Display и на их место взял 4К-мониторы от Dell. Как печатнику, мне понравился предыдущий апгрейд с чёрно-белых до grayscale-мониторов в 90-х годах. Но 4К – ещё лучше. Дисплеи высокого разрешения уже пришли на смартфоны и планшеты. Приятно, что они появляются и у ноутбуков и декстопов. Шрифты выглядят чудесно.

Хотя – хорошие шрифты выглядят чудесно. Плохие выглядят хуже – они уже не спрячутся за плохо различимыми гранями грубых пикселей. Если вы работаете с текстом – читаете, пишете, программируете, рисуете (а это охватывает чуть ли не все профессии), то апгрейд на 4К стоит того.



Но что есть «4К»? С лёгкой руки маркетологов, это экран размера 3840 на 2160 пикселей (3840 – это ну почти 4000). По каждой из сторон разрешение в два раза больше, чем у HDTV, то есть 1920х1080.

Спервоначалу люди говорили, что у 4К-экранов «в два раза больше пикселей». На самом деле, если вы удвоите количество пикселей линейно, это всё равно, что вы разрежете каждый пиксель как по вертикали и по горизонтали. То есть, на экране 4К в 4 раза больше пикселей, чем у HDTV.

И, что характерно, на этом останавливаться никто не собирается, на горизонте уже дисплеи 7680 х 4320, известные как 8К. С другой стороны, разрешение, воспринимаемое человеческим глазом, имеет границы. Переход на 4К заметен. На 8К – менее заметен. В какой-то момент нужно будет перестать делить пиксели.

Но что, если они не перестанут? Что, если они будут делить пиксели бесконечно? Сколько тогда пикселей будет на экране?

а) по количеству положительных целых чисел
б) меньше
в) больше

Если вам не интересна математика, тогда итог статьи такой: купите 4К-монитор. Не стоит благодарности.

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

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

Вот и мне в очередной раз «спустили» такую идею в немаленьком-таком legacy проекте. Не совсем переписать, не совсем все (ну в перспективе). В общем перейти с питона (а у нас там еще и тикль модульно присутствует) на scala. Речь пока шла о разработке новых модулей и сервисов, т.е. начинать с наименее привязанных к middle-level и front-nearby API's. Как я понял в перспективе возможно совсем.

Человек — не разработчик, типа нач-проекта и немного продажник (для конкретного клиента) в одном лице.

Я не то, чтобы против. И скалу уважаю и по-своему люблю. Обычно я вообще открыт ко всему новому. Так, например, местами кроме тикля и питона у нас появляются сервисы или модули на других языках. Так, например, мы переехали с cvs на svn, а затем на git (а раньше, давно-давно, вообще MS-VSS был). Примеров на самом деле масса, объединяет их один момент — так решили или как минимум одобрили сами разработчики (коллективно ли, или была группа инициаторов — не суть важно). Да и дело в общем в аргументах за и против.

Проблема в том, что иногда для аргументированной дискуссии «Developer vs. Anybody-Else» у последнего не дотягивает уровень знаний «материи» или просто невероятно сложно донести мысль — т.е. как-бы разговор на разных языках. И хорошо если это кто-нибудь типа software architect. Хуже, если имеем «беседу» например с чистым «продажником», огласившим например внезапные «требования» заказчика.

Ну почему никто не предписывает, например, плиточнику — каким шпателем ему работать (типа с зубцами 10мм клея же больше уйдет, давайте может все же 5мм. А то что там полы-стены кривущие никого не волнует). И шуруп теоретически тоже можно «закручивать» молотком, но для этого же есть отвертка, а позже был придуман шуруповёрт. Утрирую конечно, но иногда действительно напоминает такой вот абсурд.

Это я к тому, что инструмент в идеале должен выбирать сам разработчик или иметь в этом как минимум последнее слово — ему с этим инструментом работать или мучиться.

Но что-то я отвлекся. В моей конкретной истории аргументов — за scala, у человека как всегда почти никаких.
Хотя я мог бы долго говорить про вещи, типа наличие разрабов, готовые наработки, отточенную и отлаженную систему и т.д. и т.п. Но зацепился за его «Питон очень медленный». В качестве примера он в меня кинул ссылкой на Interpreting a benchmark in C, Clojure, Python, Ruby, Scala and others — Stack Overflow, которую он даже до конца не прочитал (ибо там почти прямым текстом есть — не так плохо все с питоном).

Имелось ввиду именно вот это (время указано в секундах):

  Sexy primes up to:        10k      20k      30k      100k
  ---------------------------------------------------------
  Python2.7                1.49     5.20    11.00       119     
  Scala2.9.2               0.93     1.41     2.73     20.84
  Scala2.9.2 (optimized)   0.32     0.79     1.46     12.01

Думаю, многие из вас знают, что сейчас существует обилие различных языков (или инструментов), которые позволяют писать код компилируемый в JavaScript. Это CoffeeScript, Dart, GorillaScript и другие (довольно большой список можно найти здесь). Недавно я решил познакомиться с одним из представителей этого списка — языком программирования под названием TypeScript.

Я расскажу о личном опыте — почему решил попробовать именно его, как начать работать с ним, и какие выводы сделал, поработав с ним несколько дней.

Если вам это интересно — пожалуйста, заходите под кат.

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

Привет, Хабр!
Историй о разработке игр было немало, сегодня я попробую вкратце рассказать нашу.

Мир есть текст — Жак Деррида
Игра есть словарь — a11aud

Типичный любитель λ-исчисления.

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

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

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

Если вас не пугает Lisp, много лямбд и y-combinator (не тот, который с новостями),

В 2000 году я был большим фанатом PHP. Я начал пользоваться им сразу после официального выхода версии 4.0 в апреле. В то время кроме него было всего 4 альтернативы для создания веб-сайтов.

1) C – слишком сложный для часто меняющегося проекта. Компиляция занимала много времени, было мало свободных инструментов, а платные не влезали в мой бюджет. Слишком многословный. Управление зависимостями было сложным делом.

2) Java – лучше, чем С, но всё ещё многословный и долго компилирующийся. Управление зависимостями было сложным делом.

3) Perl – почти так же хорош, как PHP, только без системы управления пакетами. На CPAN был набор модулей на все случаи жизни, но их надо было скачивать и устанавливать. Управление зависимостями было сложным делом.

4) ASP – почти так же хорош, как PHP, только это был инструмент от Microsoft, и его использование засосало бы меня в их дорогой мир.

Для трёх позиций я написал: " Управление зависимостями было сложным делом". Для меня это был ключевой момент PHP. Его философия была «всё в одном». Таких, как сейчас, систем управления пакетами тогда не было. Сейчас есть удобные штуки типа Bundler для Ruby и Leiningen для Clojure. Но не в 2000-м. Даже системы управления пакетами в Linux стали лучше с 2000 года. А система «всё в одном» решала проблемы управления пакетами в PHP. Но теперь это преимущество не имеет значения.

/ фото Brian Cantoni CC

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