Изначально я планировал выпустить этот опус как дополнение к книге “Learn You Some Erlang”, однако его содержание больше соответствует редакционному материалу, нежели хорошему справочному документу, поэтому я решил просто написать об этом в блоге.

Многие новички в мире Erlang успешно изучают его и начинают играться, не вступая с ним в тесное знакомство. Я прочитал много жалоб именно на синтаксис и эти “козьи шарики” (ant turds — ориг.) — «веселый» способ называть символы ,, ;, .. Например, «Как же они бесят», а также многое другое.

Я упоминал в книге, что Erlang берет свое начало из Prolog. Это дает нам понять, откуда берутся все эти знаки препинания, но это, увы, не заставляет людей проникнуться любовью к подобной пунктуации. И правда, почему-то никто не говорит мне: «А-а! Prolog! Что ж ты раньше не сказал!» Ввиду этого я предлагаю три возможных способа человеческого чтения кода на Erlang, дабы сделать мир добрее.

В серии статей мы рассказываем о новых подходах в Искусственном Интеллекте, моделировании личности и обработке BIG Data, которые недоступны для большинства специалистов по ИИ и общественности. Ценность этой информации в том, что она вся проверена на практике и большинство теоретических наработок реализованы в прикладных проектах.



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

Крупные поисковые компании обладают почти неограниченными ресурсами – у них есть деньги, на них работают самые профессиональные сотрудники, тысячи и даже миллионы серверов обслуживают поисковые запросы.
Так почему же до сих пор вы получаете в качестве ответа ссылки, а не ответ на свой вопрос?

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

или «Прекратите характеризовать хранилища данных как CP или AP»

Джеф Ходжес в своем прекрасном посте «Заметки о распределенных системах для новичков» рекомендует использовать САР теорему для критики найденных решений. Многие, похоже, восприняли этот совет слишком близко к сердцу, описывая свои системы как «СР» (согласованность данных, но без постоянной доступности при сетевой распределенности), «АР» (доступность без согласованного состояния при сетевой распределенности), или иногда «СА» (означает «Я всё ещё не читал статью Коды (Coda Hale) почти 5-летней давности»).

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

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

САР использует слишком узкое определение

Если вы хотите ссылаться на САР как на теорему (а не на расплывчатый концепт в маркетинговых материалах к вашей базе данных), вы должны быть точны. Математика требует точности. Доказательство сохраняется только если вы вкладывается в слова, то же самое значение, что было использовано при доказательстве. И оно опирается на очень точные определения:

Введение

Несмотря на обилие социальных сетей, за последние несколько лет появился целый ряд новых, оригинальных и необычных социальных приложений, таких как just yo, snapchat, secret, и пр. Успех приложения just yo, ограниченного единственной функцией – отправкой сообщения фиксированного содержания, меня заинтересовал и мы с друзьями тоже решили попробовать написать очередную социальную сеть на Android. Нашей целью было очертить круг задач общий для большинства подобных приложений, предложить их решения и подготовить скелет, из которого каждый сможет сделать что-то своё и оригинальное, не тратя время на решение рутинных вопросов. С результатами работы можно сразу ознакомиться на github – android клиент и сервер на ruby on rails.

Мы уже рассказывали о том, как устройства Lenovo помогают охотникам за ураганами и графическим дизайнерам. А сегодня хотим поделиться опытом интеграции наших решений в серьёзную Российскую государственную информационную систему. В конце 2013 года, за очень короткий срок – менее месяца, мы поставили 120 серверов в медицинские организации Краснодарского края. Все они благополучно работают в поликлиниках и стационарах до сих пор, но интереснее всего процесс прохождения всех классических формальностей. Так что это история не только про хорошую технику, но и про то, как победить систему: выиграть тендер, за месяц привезти в крупный регион большую партию серверов, настроить их и полностью удовлетворить заказчика и проверяющие органы. Подробности под катом.

Шифруем всё подряд

Эра незашифрованного веба проходит, и это хорошо. В этой инструкции мы предполагаем, что на вашем сервере работает веб-сервер Nginx. И теперь мы сделаем так, чтобы все посетители сайта пользовались исключительно протоколом HTTPS. Кроме этого мы включим HSTS – это «HTTP Strict Transport Security», когда сайт не только поддерживает HTTPS, но и настаивает на его использовании.

Для этого есть множество способов, но я опишу метод под названием «HTTPS termination». Иначе говоря, мы поставим перед веб-сервером обратный прокси, который и будет обеспечивать HTTPS. Это получается проще и гибче, чем настраивать HTTPS только при помощи возможностей веб-сервера. Возможно, вам покажется контринтуитивным, что добавление ещё одного приложения в стек упростит вашу жизнь – но это действительно так.

Уточним, что данный рецепт подходит для серверов на базе Linux, на которых установлен Nginx.

То, что будет работать прежде всех остальных приложений в стопке – это HAProxy. Это в первую очередь приложение для балансировки – он умеет распределять приходящие запросы между разными физическими серверами. Много высоконагруженных сайтов используют его в этом качестве (тот же reddit), но в последней версии у него появилась возможность выполнять SSL termination. Он умеет устанавливать HTTPS-соединения от имени сервера.

Поэтому мы поставим HAProxy, скормим ему наши сертификаты SSL/TLS, поручим перенапрявлять все HTTP запросы на HTTPS, и покажем ему уже сам веб-сервер в качестве бэкенда.

Тим Петерс разработал гибридный алгоритм сортировки Timsort в 2002 году. Алгоритм представляет собой искусную комбинацию идей сортировки слиянием и сортировки вставками и заточен на эффективную работу с реальными данными. Впервые Timsort был разработан для Python, но затем Джошуа Блох (создатель коллекций Java, именно он, кстати, отметил, что большинство алгоритмов двоичного поиска содержит ошибку) портировал его на Java (методы java.util.Collections.sort и java.util.Arrays.sort). Сегодня Timsort является стандартным алгоритмом сортировки в Android SDK, Oracle JDK и OpenJDK. Учитывая популярность этих платформ, можно сделать вывод, что счёт компьютеров, облачных сервисов и мобильных устройств, использующих Timsort для сортировки, идёт на миллиарды.

Но вернёмся в 2015-й год. После того как мы успешно верифицировали Java-реализации сортировки подсчётом и поразрядной сортировки (J. Autom. Reasoning 53(2), 129-139) нашим инструментом формальной верификации под названием KeY, мы искали новый объект для изучения. Timsort казался подходящей кандидатурой, потому что он довольно сложный и широко используется. К сожалению, мы не смогли доказать его корректность. Причина этого при детальном рассмотрении оказалась проста: в реализации Timsort есть баг. Наши теоретические исследования указали нам, где искать ошибку (любопытно, что ошибка была уже в питоновской реализации). В данной статье рассказывается, как мы этого добились.

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

Разработчик популярного браузера Firefox, компания Mozilla будет постепенно отказываться от поддержки протокола HTTP в пользу зашифрованного протокола HTTPS. Это решение было принято после всестороннего и бурного обсуждения в списке почтовой рассылки.

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

План не отвергает полностью использование старых ссылок в формате http – вместо этого они будут преобразовываться в HTTPS через HSTS и атрибут upgrade-insecure-requests (средства, которыми пользуется сервер для переадресации всех запросов по безопасным каналам). Mozilla призывает разработчиков активнее включаться в движение по усилению безопасности работы в интернете, и планирует представить свои рекомендации консорциуму W3C.

Оказывается, ещё в 19 веке существовали вычислительные машины, способные осуществлять сложнейшие математические расчёты. Один из уникальных экземпляров — гармонический анализатор Альберта Майкельсона. Прибор выполнял преобразование Фурье. Эта функция сегодня широко используется в информатике, обработке сигналов, физике, теории чисел, комбинаторике, теории вероятностей, криптографии и других областях.

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

Скачать пост в виде документа Mathematica, который содержит весь код использованный в статье, вместе с дополнительными файлами, можно здесь.

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

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

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

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

Сегодня я хочу показать, как используя React, Flummox и Express, создать полноценное изоморфное приложение.

Идея изоморфности давно витала в воздухе, но никто не знал этого слова, поэтому ничего особо не менялось, пока не пришел airbnb.

За полгода до этого появился React, позже появился Flux и множество его реализаций, одна не хуже другой. Но все эти реализации ориентировались только на работу на клиентской стороне, они работали через синглтоны и, зачастую, их нельзя было нормально использовать на сервере. Я успел попробовать несколько, но ни одна мне не понравилась. Пока два месяца назад я не наткнулся на Flummox. Как заявляет разработчик, Flummox создан как раз для изоморфных приложений, он не использует синглтоны, присущие другим реализациям, и максимально прост в использовании.

Ожидается, что вы имеете опыт работы с React и слышали про Flux. Итак, поехали…
Забрать готовый код можно тут.

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

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

Краудфандинговая кампания только началась, но финансирование уже выполнено на 3000 %

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

И это неудивительно: извлечение мёда из ульев — это самая трудоёмкая и времязатратная работа в пчеловодстве. Традиционно эта операция состоит из множества шагов, основными являются открытие улья, удаление пчёл, распечатывание сот с мёдом и работа центрифуги аппарата медогонки. Также возможны стекание мёда без всякой помощи и после этого тепловое воздействие. А австралийский проект Flow предлагает решение, при котором для извлечения мёда не нужно открывать улей и тревожить пчёл — нужна лишь ёмкость, в которую будет стекать готовый продукт.

Вторая встреча сообщества DataTalks была посвящена визуализации данных – одному из самых важных и сильных инструментов в руках аналитиков. Ведь именно от того, как представлены результаты исследовательской работы, зависят решения и выводы заказчика. Помимо этого, визуализация помогает проводить предварительный анализ данных и быстро находить новые взаимосвязи.
Под катом вы найдете записи выступлений представителей компаний Wargaming, Ambitious Suits Consulting, Targetprocess, А2 Консалтинг и интернет-портала TUT.BY. Докладчики поделились опытом наглядного и информативного представления данных.
Сама встреча традиционно прошла «под танком», в главном офисе компании СООО «Гейм Стрим», минского офиса разработки Wargaming.

Довольно часто встречается задача классификации текстов — например, определение тональности (выражает ли текст позитивное мнение или отрицательное о чем-либо), или разнесения текста по тематикам. На Хабре уже есть хорошие статьи с введением в данный вопрос.

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

Чертежи позабытых процессоров, исходные коды легендарных игр, неизвестные произведения искусства, — чего только не находят в архивах любители старины. Их задача — восстановить, надёжно сохранить и каталогизировать.

Может показаться, что мы живём в век, когда информация практически не способна потеряться: что однажды было оцифровано или создано на компьютере, будет, имей оно хоть какую-то ценность, тиражироваться и вечно кочевать с одного цифрового носителя на другой. Это, к сожалению, не совсем так: стандарты и форматы меняются с поразительной скоростью, а носители информации (в особенности — магнитные диски) имеют крайне ограниченный срок службы. «Цифровая археология» — то есть извлечение данных со старых носителей и перекодирование в современные форматы становится всё более актуальной дисциплиной. В этой области существуют специалисты, и раз за разом появляются истории о том, как они героически извлекли из цифровых руин нечто, имеющее неоспоримую ценность.

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

В настоящее время департамент мобильной разработки Rambler&Co активно расширяется, в том числе и в плане iOS-разработчиков и UX дизайнеров. Большое количество людей и проектов, ведущихся ими, усложняет и без того непростой процесс передачи дизайна разработчикам. Всем, так или иначе связанным с мобильной разработкой, знакомы проблемы и разногласия, возникающие на стыке интересов программиста и дизайнера — начиная тем, в каких единицах измерять расстояния, и заканчивая тем, кто должен нарезать элементы экранов в различных разрешениях. Чтобы окончательно решить проблему в рамках нашей компании, мы решили подготовить подробные гайдлайны по этому взаимодействию.

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

А что же в играх?

Допустим, появилась необходимость использовать Color Dodge смешивание для системы частиц или UI-художник сделал красивую графику для игрового интерфейса, но некоторые его элементы используют какой-нибудь Soft Light. А может, вам понадобилось подвергнуть трёхмерный объект Divide-смешиванию, чтобы получить эффект прямиком из кинокартин Линча?



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

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

А что, если бы все клиент-серверное приложение целиком писалось на Java, но его клиентская часть была бы «нативной» для браузера и соответствовала бы самым современным представлениям о юзабилити?