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

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

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

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

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

Мы уже писали о «консольных помощниках» для Kubernetes год назад, а ещё раньше делали обзор других полезных утилит. Однако с развитием K8s и его сообщества претерпевает изменения и сопутствующая экосистема. Поэтому нам снова есть о чём рассказать любителям консоли. Поехали!

Технический директор Croteam Ален Ладавач, участвовавший в разработке Serious Sam и Talos Principle, рассказывает, как ему удалось найти причину торможения графики даже на самых мощных машинах.

Наконец-то появилось объяснение того, почему некоторые игры тормозят на вашем PC (и луч надежды на то, что в ближайшем будущем они тормозить перестанут).

Т-т-тормоза

Вы с нетерпением ждали следующей части вашей любимой серии видеоигр для PC и она наконец вышла. На этот раз вы хотите насладиться ею во всей полноте, поэтому потратили деньги и время на тщательную подготовку. Вы заменили процессор, поставили сверхсовременную видеокарту, добавили ещё ОЗУ — чёрт возьми, даже купили RAID на SSD. Игра должна быть плавной с самой заставки.

Предзаказ наконец разблокирован и вы только что завершили установку. В нервном предвкушении вы впервые запускаете игру. Пока всё хорошо — она работает с частотой 60 кадров в секунду. Или, по крайней мере, так сообщает счётчик кадров тюнера GPU. Но что-то не так. Вы делаете мышью резкие, хаотичные движения. Стрейфитесь влево-вправо, и тут игра… начинает тормозить! Блин, да как такое возможно? Как она может тормозить при 60 кадрах в секунду?

Если такое с вами никогда не случалось, то это может показаться смешным. Но если вы их испытали, то, скорее всего, ненавидите тормоза всей душой. Тормоза в играх. Это не старый добрый «лаг». Не низкая частота кадров. Это просто «тормоза», происходящие при высоких частотах кадров на идеальных, супербыстрых машинах. Что это, откуда они взялись и как от них избавиться? Позвольте мне рассказать вам историю…

Я выступаю против усилий Google по дискредитации протокола HTTP. Здесь — обобщение причин, по которым я придерживаюсь такой точки зрения.

Праздники все прошли, прибыль и убытки подсчитаны. Настало время повествования. Эта история о том, как из-за технической ошибки интернет-магазин по доставке цветов потерял несколько сотен заказов и выручки в 1 миллион рублей на День Святого Валентина.

Прим. перев.: Этот материал, озаглавленный в оригинале как «What happens when… Kubernetes edition!» и написанный Jamie Hannaford из компании Rackspace, является отличной иллюстрацией работы многих механизмов Kubernetes, которые зачастую скрыты от нашего глаза, но весьма полезны для лучшего понимания устройства этой Open Source-системы, алгоритма работы и взаимосвязей её компонентов. Поскольку вся статья весьма объёмна, её перевод разбит на две части. В первой речь идёт про работу kubectl, kube-apiserver, etcd и initializers.

P.S. Некоторые оригинальные ссылки на код в master-ветках были заменены на последние к моменту перевода коммиты, чтобы актуальность номеров строк, к которым отсылает автор, сохранялась долгое время.



Представим, что я хочу задеплоить nginx в кластере Kubernetes. Я введу в терминале нечто такое:

kubectl run --image=nginx --replicas=3

… и нажму на Enter. Через несколько секунд увижу 3 пода с nginx, распределённые по всем рабочим узлам. Работает — словно по волшебству, и это здорово! Но что на самом деле происходит под капотом?

Я как-то немного пропустил статью и весь всплеск обсуждений и критики Xored. Поэтому буду нагонять.

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

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

Спустя еще три месяца появился «Мегамозг», сконцентрировавший вокруг себя все, что так или иначе касается менеджмента, управления и маркетинга в ИТ, равно, как и «стартапов».

Таким образом, мы разделили «Хабрахабр» на три узкоспециализированных ресурса, каждый из которых охватывал определенную сферу интересов наших пользователей: Хабр — программирование и разработка, ГТ — космос, наука, гаджеты, развлечения и другие тематики, ММ — бизнес и менеджмент.

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

С радостью, волнением, но в то же время некоторым облегчением мы объявляем о релизе новой итерации Хабра!

Чем мы занимаемся большую часть времени? Пишем код — прикладываем математику к реальности, крутим алгебру конструкциями языка и создаем новое и интересное.

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

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

А иногда люди придумывают вещи, сильно оторванные от реальности — типа недетерминированной машины Тьюринга и вопрос — зачем? :-)

Разработчики из американской компании Gaslight написали интересный материал о том, почему организация, известная своей любовью к Ruby и Ruby on Rails, решила инвестировать в освоение новых технологий — например, Clojure. Мы в «Латере» развиваем биллинг для операторов связи «Гидра» и тоже работаем с этим языком программирования, поэтому решили выделить главные тезисы команды Gaslight в отдельный материал.

Итак, почему стоит изучать Clojure и использовать его в реальных проектах?

Странно, что нет этой новости, хотя про обращение в ФАС bobuk довольно оперативно написал.

Федеральная антимонопольная служба (ФАС) признала американскую корпорацию Google виновной в нарушении закона «О защите конкуренции».

Теперь Google грозит штраф в размере от 1 до 15 процентов от выручки компании на рынке.

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

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

Хочу поделиться с сообществом опытом разработки JS-виджета межпроектной навигации. Он представляет собой модуль, который подключается на большинство сайтов вселенной Wargaming (Порталы, Wiki, WarGag и пр.).

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

Введение

Решение задачи поиска минимальных остовных деревьев ( MST — minimum spanning tree) является распространенной задачей в различных областях исследований: распознавание различных объектов, компьютерное зрение, анализ и построение сетей (например, телефонных, электрических, компьютерных, дорожных и т.д.), химия и биология и многие другие. Существует по крайней мере три известных алгоритма, решающих данную задачу: Борувки, Крускала и Прима. Обработка больших графов (занимающих несколько ГБ) является достаточно трудоемкой задачей для центрального процессора (CPU) и является востребованной в данное время. Все более широкое распространение получают графические ускорители (GPU), способные показывать намного большую производительность, чем CPU. Но задача MST, как и многие задачи по обработке графов, плохо ложатся на архитектуру GPU. В данной статье будет рассмотрена реализация данного алгоритма на GPU. Также будет показано, как можно использовать CPU для построения гибридной реализации данного алгоритма на общей памяти одного узла (состоящего из GPU и нескольких CPU).

Предлагаю читателям «Хабрахабра» перевод статьи «A Quick Comparison of Nim vs. Rust». Мои замечания будут выделены курсивом.

Rust и Nim — два новых языка программирования за развитием которых я слежу. Вскоре, после моего первого поста о Rust, вышел в свет Nim 0.10.2. Это побудило меня поближе познакомиться с Nim и, естественно, сравнить его с Rust.

В этом посте я собираюсь показать вам две простых программы написанных на Nim и Rust с грубым сравнением их времени выполнения и выскажу мои субъективные впечатления от программирования на этих языках.

В этой статье я попробую ответить на такие вопросы:

• может ли один доклад умного человека сделать другого человека одержимым?
• как окунуться в машинное обучение (почти) с нуля?
• почему не стоит недооценивать многоруких бандитов?
• существует ли серебряная пуля для a/b тестов?

Ответ на первый вопрос будет самым лаконичным — «да». Услышав это выступление bobuk на YaC/M, я восхитился элегантностью подхода и задумался о том, как бы внедрить похожее решение. Я тогда работал продуктовым менеджером в компании Wargaming и как раз занимался т.н. user acquisition services – технологическими решениями для привлечения пользователей, в число которых входила и система для A/B тестирования лендингов. Так что зерна легли на благодатную почву.

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

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

Этой обзорной статьёй я открываю серию статей, посвящённых языку Активный Оберон и операционной системе A2, написанной на этом языке.

Итак, встречайте — Активный Оберон

Первая публикация по Активному Оберону появилась в 1997 году, но понятно, что язык и его реализация появились несколько раньше. За эти годы произошло много изменений в языке, переработана среда времени выполнения, написана операционная система A2…

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

Понять осторожных британцев поможет грибной фольклор и тест на выживаемость в английских лесах. Поехали!

Допустим, вы крупная Компания. Занимаетесь разработкой Браузера, Почтовика и даже ОС для смартфонов. Неожиданно вы понимаете, что вам не нравится современный и мощный язык С++. Ну или нравится, но работать с ним невозможно. Бывает. И вот вы, взрослая стабильная компания решаете разработать новый язык программирования. Рецепт простой. Берете бочку денег, книжки по истории ИТ, роту программистов и грузовик МакБуков. Долго думаете, быстро кодите, разводите хайп в соцсетях (реддит, фейсбук, гитхаб). И вот, в 2015-м году вы даете сообществу The Язык. Назовем его Яист.