Первый промежуточный релиз Spring Framework 4.0 M1 предоставил поддержку SockJS на стороне сервера — лучшая и наиболее полная альтернативная реализация WebSocket. Вам потребуется этот резервный вариант в браузерах, не поддерживающих WebSocket и в ситуациях когда прокси препятствует их использованию. Проще говоря, SockJS позволяет строить WebSocket-приложения уже сегодня, которые, ко всему прочему, умеют прозрачно переходить на резервные возможности.

Но даже с резервными вариантами проблемы остаются. Сокет — довольно низкоуровневая абстракция и подавляющее большинство веб-приложений сегодня не адаптированы для сокетов. Вот почему протокол WebSocket определяет механизм под-протоколов, который, по существу, позволяет (и поощряет) использование протоколов более высокого уровня над WebSocket, аналогично тому как мы используем HTTP поверх TCP.

Второй промежуточный релиз Spring Framework 4.0 M2 позволяет использовать высокоуровневые протоколы обмена сообщениями поверх WebSocket. Для демонстрации этого, мы разберем пример приложения.

Эта тема не относится к IT напрямую, но все знают, что без нее никуда. К сожалению, далеко не у всех есть возможность изучать английский с преподавателями. Ну что ж, попробуем заняться этим дома и с максимальной отдачей!

Картинка для привлечения внимания, clckwrks — веб-фреймворк, тесно связанный с Happstack.

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

Некоторое время назад зам.главы московского офиса разработки Badoo Алексей Рыбак и ведущие IT-Компот записали выпуск подкаста «Архитектура высоконагруженных приложений. Масштабирование распределенных систем".

Сейчас мы сделали расшифровку подкаста, привели ее в удобный для чтения вид и разбили на 2 части.

О чем говорили в первой части:

• Общая информация о проекте Badoo: стек технологий, характер и объем нагрузки, посещаемость.
• Горизонтальное масштабирование проекта:

— веб-сервера, кеширование, мониторинг etc;
— подводные камни при масштабировании проекта;
— масштабирование баз данных, как правильно делать шардинг.

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

Пары и списки

В предыдущих частях мы научились задавать новые типы данных, определять функции над ними и доказывать их корректность с помощью распространенных тактик. Настало время определить некоторые структуры данных и функции высших порядков (далее ФВП) над ними.

2 месяца назад e-Legion и JetBrains провели очередную конференцию для Scala-разработчиков в Санкт-Петербурге — Scaladev.

На мероприятии выступили представители из e-Legion, Jetbrains, Huawei Research, Grid Dynamics и GridGain. Выступление Павла Фатина (JetBrains) «Поддержка компиляции в Scala Plugin с использованием Zinc» уже выкладывали в блоге Jetbrains, кто пропустил — вот ссылка.

В этом же посте будет доклад и презентация Рафаэля bugzmanov Багманова из компании Grid Dynamics. В своем докладе он рассказал о своем опыте реализации типичного веб-приложения для enterprise-проекта на Scala.


Презентация

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

Теперь я пишу на Питоне и с ООП знаком. И паттерны мне теперь намного понятней. Но меня по-прежнему воротит от развесистых схем классов. Многие паттерны прекрасно работают в функциональной парадигме. Опишу несколько примеров.

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

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

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

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

Компанией, с которой предстояло работать конкурсантам, была Godzilla Nursery Laboratory — интернациональная корпорация, занимающаяся разведением и продажей домашних годзилл. Годзиллы были выбраны не случайно – именно они «охраняли» железную дорогу из конкурса «Choo-choo PWN».



Google подсказывал участникам сразу, что рабочий сайт этой компании с симпатичным логотипом — www.godzillanurserylab.com, а многие из ее сотрудников представлены в социальной сети LinkedIn. Ну, поехали!

Краткое содержание:

Возьмем немного функций высшего порядка, добавим частичное применение функций, приправим fold с map-ом и получим Javascript DSL для работы с DOM.

Человеческим языком:
Простое и понятное введение в функциональное программирование на чистом и понятном Javascript.

В отличие от «Через тернии к Haskell» все разжевано (возможно даже слишком) и разложено по полочкам.

Прочтение статьи развоплотит миф о неприменимости ФП в реальной жизни. Вы сможете смотреть на решение одной и той же задачи с разных точек зрения. Прямо как на картинке.

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


Элементарно. Так что теперь усложним задание — пусть наше значение имеет контекст. Пока что вы можете думать о контексте просто как о ящике, куда можно положить значение:


Теперь, когда вы примените функцию к этому значению, результаты вы будете получать разные — в зависимости от контекста. Это основная идея, на которой базируются функторы, аппликативные функторы, монады, стрелки и т.п. Тип данных Maybe определяет два связанных контекста:

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!

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

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

Существует мнение, что C++ имеет заметные накладные расходы по сравнению с C и поэтому он медленнее. Помимо этого, даже, существуют статьи показывающие преимущества в скорости языков с компиляцией налету (JIT — Just-in-time compilation), таких как Java и C#. Сравнить последние мы оставим тем, кто считает их быстрыми, но мы объясним почему это не так. А C и C++ мы сравним на примере задачи поиска данных.
Задача поиска данных часто встречается в: веб-сервисах, системах управления баз данных (СУБД), гео-поиске и аналитике.
Сначала для простоты объяснения поставим задачу поиска элементов полным проходом по массиву из 10 000 000 элементов (структур), содержащих 5 полей с диапазонами значений: amount_of_money(0-1000000), gender(0-1), age(0-100), code(0-1000000), height(0-300). А в следующих статьях добавим в решение индексный поиск.
Мы будем писать кроссплатформенно под MSVC11(MSVS2012) и GCC 4.7.2, и использовать в них частично реализованный стандарт C++11.

В продолжении статьи о кроссплатформенной и кросс-аппаратной оптимизации, на примере задачи поиска полным проходом по таблице из 5 полей и 10 000 000 строк, и неизбежности этой задачи даже при индексном поиске, я покажу как ускорить такой поиск в 3.5-5.3 раза с использованием C++ независимо от аппаратной платформы.
В предыдущей статье нам удалось ускорить поиск в 1.3 раза: GitHub.com
Мы не будем банально описывать конструкции языка, а покажем преимущества C++ при решении одного из этапов реальной задачи.
Мы по-прежнему пишем кроссплатформенно под MSVC11(MSVS2012) и GCC 4.7.2, и используем в них C и частично реализованный стандарт C++11.
Для упрощения понимания мы все ещё пишем без индексного поиска, но это решение в дальнейшем будет использоваться при индексном поиске.