В наших с вами интернетах недавно поднялся нешуточный шум по поводу того, жив ли TDD сейчас, нужен ли он, и в каком виде. Все началось со статьи Дэвида Хансона «TDD is dead. Long living testing», после которой последовали статьи многих авторов и живые обсуждения этой проблемы включая hangout вместе с Дэвидом, Кентом Беком и Мартином Фаулером (кстати, очередной hangout будет завтра, 16 мая).

Но немногие знают, что за несколько дней до этого все тот же Мартин Фаулер постарался дать определение модульного теста (bliki:UnitTest), перевод которого представлен ниже. А после перевода идут кое-какие мои мысли по этому поводу.

Добрый день.
В рамках детальной проработки курса удаленного образования «Java Core» я пишу серию публикаций и делаю несколько переводов наиболее популярных статей.

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

Сейчас я предлагаю Вам на рассмотрение мой перевод «Programming With Assertions» с некоторыми комментариями.

Оригинальная публикация не только детально объясняет варианты использования ключевого слова assert в Java и то, как реализована поддержка данного механизма на уровне загрузки классов, но также является достаточно неформальным введением в Разработку-по-Контракту (Design-by-Contract).




P.S. Автор признает, что для него лично русский язык намного сложнее языка Java, с благодарностью выслушает в личку о всех замеченных ошибках и постарается их в кратчайшие сроки исправить.

---

Программирование с утверждениями (oracle.com: Programming With Assertions)

Утверждение (assert) — это оператор (statement) языка программирования Java, который позволяет вам проверить свои предположения о программе. Например, если вы пишете метод, вычисляющий скорость частицы, можно «утверждать», что расчетная скорость меньше скорости света.

Каждое утверждение содержит логическое выражение, которое, по вашему мнению, будет верным в момент выполнения. В противном случае, система выбросит исключение. Проверяя, что логическое выражение на самом деле верно, утверждение (assert) подтверждает ваши предположения (ожидания) о поведении программы, увеличивая уверенность в том, что программа не содержит ошибок.

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

Причина побудившая автора к публикации

Первая версия описания алгоритма было послана мною в институт математики им. С. Л. Соболева Сибирского отделения РАН, откуда был прислан ответ что указанный алгоритм известен давно. Цитирую:

Одно из его первых упоминаний в книге Кереллера Nemhauser, Ullman, Discrete dynamic programming and capital allocation, Management Science, 15 p. 494-505, 1969.

Тем не менее я решил ознакомить сообщество с алгоритмом, т.к. в известных мне учебниках по дискретной математике я его не обнаружил (возможно плохо искал). В первой версии алгоритма была ошибка, указанная мне пользователем wataru. За это ему большое спасибо. Я постарался эту ошибку устранить. До алгоритма я дошел самостоятельно, так что надеюсь ничьих прав не нарушаю. Возможно кому нибудь описание будет интересно и пригодится.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

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

Есть некоторое множество объектов, и некоторое множество тегов. Каждый объект может содержать несколько тегов. Какие-то теги очень редкие, а какие-то встречаются часто. Одному объекту один тег может быть сопоставлен несколько раз.
Новые объекты, теги и связи между ними непрерывно добавляются.
Задача — очень быстро отвечать на вопросы вида: «сколько есть объектов, у которых есть тег А или B, но нету тега С» и похожие. На такие запросы хотелось бы отвечать за десятые доли секунды, при этом не останавливая загрузку данных.

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

SELECT 
    COUNT(*) 
FROM (
    SELECT 
        object_id, 
        (MAX(tag == A) OR MAX(tag == B)) AND MIN(tag != C) AS good
    FROM tags
    WHERE tag IN (A, B, C)
    GROUP BY object_id
) WHERE good == 1;

Чтобы такой запрос выполнялся быстро, мы разбили данные между серверами кластера по object_id, а внутри каждого сервера отсортировали их по тегам. Таким образом сервер, выполняющий запрос, может отправить запрос без изменений на все сервера с данными, а затем просто сложить их результаты. На каждом сервере с данными для выполнения запроса достаточно найти строки для тегов A, B и C (а так как данные по тегу отсортированы, это быстрая операция), после чего выполнить запрос за один проход по этим строкам. Худший тег имеет несколько десятков миллионов объектов, несколько десятков миллионов строк обработать за десятые доли секунды видится возможным.
Стоит отметить, что подзапрос содержит GROUP BY object_id. GROUP BY в данной ситуации можно выполнить несколькими способами, например, если данные после тега отсортированы по object_id, то можно выполнить что-то похожее на merge sort. В данной ситуации, однако, мы данные по object_id не отсортировали, и оптимизатор разумно решил, что для выполнения GROUP BY надо построить хеш-таблицу.

Мы загрузили все данные в кластер, и запустили запрос. Запрос занял 25 секунд.

При построении многослойных («enterprise») систем часто оказывается, что создаются ValueObject'ы (или case class'ы), в которых хранится информация о каком-либо экземпляре сущности, обрабатываемом системой. Например, класс

case class Person(name: String, address: Address)

Такой способ представления данных в системе обладает как положительными свойствами:

• строго типизированный доступ к данным,
• возможность привязки метаинформации к свойствам с помощью аннотаций,

так и некоторыми недостатками:

• если сущностей много, то таких классов также становится довольно много, а их обработка требует много однотипного кода (copy-paste);
• потребности отдельных слоёв системы в метаинформации могут быть представлены аннотациями к свойствам этого объекта, но возможности аннотаций ограничены и требуют использования reflection'а;
• если требуется представить данные не обо всех свойствах объекта сразу, то созданные классы использовать затруднительно;
• затруднительно также представить изменение значения свойства (delta).

Мы хотим реализовать фреймворк, позволяющий создавать новые «классы» (типы, конструкторы этих типов, объекты новых типов) инкрементно, используя наши собственные «кирпичики». Попутно, пользуясь тем, что мы сами изготавливаем «кирпичики», мы можем достичь таких полезных свойств:

• возможность описывать отдельные свойства сущностей (с указанием типа данных в этом свойстве и любой метаинформации, необходимой приложению, в форме, подходящей именно для этого приложения);
• возможность оперировать со свойствами экземпляров строго типизированным образом (с проверкой типов на этапе компиляции);
• представлять частичную/неполную информацию о значениях свойств экземпляра сущности, пользуясь объявленными свойствами;
• создавать тип объекта, содержащего частичную информацию о свойствах экземпляра сущности. И использовать этот тип наравне с другими типами (классами, примитивными типами и др.).

Шла холодная зима 2063 года… Вы, сидя в избушке в сибирских степях, попивая горячий чай, из ностальгических побуждений достали свой любимый раритетный смартфон образца 2014 года с поддержкой ГЛОНАСС — однако он почему-то не нашел ни одного спутника. Вдруг тишину разрезал пронзительный звонок красного правительственного телефона — голос на той стороне затараторил: оказалось все спутники ГЛОНАСС вышли из строя из-за неизвестного сбоя… (ТЗЧ? Закладки? Кто теперь разберет....)

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

Не знаете чем заняться в майские праздники? Решение есть!

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

Что-ж, посмотрим, что из этого выйдет!

Сроки проведения соревнования: с 9 мая 0:00 по 11 мая 23:59 по московскому времени.
Условия будут опубликованы 9 мая в 0:00 — в этих же хабах на хабре, прием решений соответственно не позднее 11 мая 23:59.

12 апреля в Одессе впервые прошла конференция «Al&BigData Lab», посвященная искусственному интеллекту и большим данным. Если проблема искусственного интеллекта исследуется давно, то понятие «большие данные» появилось относительно недавно и до сегодняшнего дня остается довольно расплывчатым. Основной целью мероприятия виделось прежде всего обмен опытом среди разработчиков, объединение сообщества для более эффективного развития проектов по этой проблематике, а также создание и продвижение решений big data и искусственного интеллекта в Украине. Мы планировали заложить основы создания в одесском регионе AI-клаба (как это сделано в Киеве и Харькове) для поддержки и развития данного направления в регионе. Можно с уверенностью утверждать, что нам это удалось.

Да, это целая статья по самому обычному switch в JDK 7. Бывает так, что накопленный материал кажется интересным и малоизвестным, а потом оказывается, что любая бабка у подъезда уже 50 лет знает об особенностях реализации switch. Но я попробую. Для затравки, предлагаю 3 вопроса:

1. (Простой) Каков результат работы этого кода?
   

   switch(5){
   default: System.out.print(0);
   case 1: System.out.print(1); break;
   case 4: System.out.print(4);
   case 2: System.out.print(2);
   }

   
   
2. Следующие 2 варианта практически одинаковы. Немного отличаются литералами.
   

   //Вариант 1 switch("BBBBBB"){ case "AaAaAa": break; case "AaAaBB": break; case "AaBBAa": break; case "AaBBBB": break; case "BBAaAa": break; case "BBAaBB": break; case "BBBBAa": break; case "BBBBBB": break; }

   //Вариант 2 switch("BBBBBB_8"){ case "AaAaAa_1": break; case "AaAaBB_2": break; case "AaBBAa_3": break; case "AaBBBB_4": break; case "BBAaAa_5": break; case "BBAaBB_6": break; case "BBBBAa_7": break; case "BBBBBB_8": break; }

   Почему первый switch выполняется в несколько раз медленнее, по крайней мере, с отключенным JIT (-Djava.compiler=NONE)? Сами проверьте в цикле! JIT таким кодом не проведешь, но если немного пошаманить, то небольшая разница будет заметна.
3. Какова вычислительная сложность алгоритма нахождения совпадающего значения среди n case-ов (по крайней мере, в JDK 7)?
   

Перевод доклада Стивена Вольфрама, прочитанного им на фестивале SXSW 2014.
Оригинальный текст вы можете найти здесь.



Две недели назад я выступал с речью на конференции SXSW в Остине, Техас. Эта статья является немного доработанными тезисами доклада (это конспект текста, включающий демонстрации, от которых пришлось отказаться в процессе выступления):

Итак, на этот час запланировано довольно много.

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

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

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

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

Но, для начала, немного истории. 40 лет назад я был 14-летним юнцом, который впервые прикоснулся к компьютеру (он тогда еще был размером со стол). Я не часто использовал его как нечто фундаментальное, но пытался с его помощью понять некоторые вещи из физики, которая меня по-настоящему интересовала. В тот момент я открыл для себя некоторые важные вещи, которыми пользуюсь до сих пор. Но сейчас я понимаю что самая важная вещь, которую я понял тогда относилась вовсе не к физике: чем лучше инструменты, которые мы используем, тем глубже мы сможем копнуть. Мне не очень хорошо давалась “математика на бумаге”, а в то время это было серьезной проблемой для тех, кто хотел заниматься физикой. Однако, я осознавал, что расчеты можно делать на компьютере и начал создавать инструменты для этого. Очень скоро я с моими программами был лучше всех в математических расчетах для физики.

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

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

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

Преамбула

Здравствуйте. Я являюсь главным разработчиком крупнейшего в СНГ сервера Minecraft (не буду рекламировать, кому надо, те знают). Уже почти год мы пишем свою реализацию сервера, рассчитанную на больше чем 40 человек (мы хотим видеть цифру в 500 хотя бы). Пока всё было удачно, но последнее время система начала упираться в то, что из-за не самой удачной реализации сети (1 поток на ввод, 1 на вывод + 1 на обработку), при 300 игроках онлайн работает более 980 потоков (+ системные), что в сочетании с производительностью дефолтного io Явы даёт огромное падение производительности, и уже при 100 игроках сервер в основном занимается тем, что пишет/читает в/из сети.

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

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

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

Уточнение

Так как Sun'a больше нет, то и экзамена SCJP тоже нет. Теперь он значится так:
1Z0-851 Java Standard Edition 6 Programmer Certified Professional Exam.

Abstract: Изоляция приложения на уровне сети использованием network namespaces Линукса. Организация SSH-туннелей.

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

Вместо вступления. Я просто покажу эту картинку:

147%… Что-то мне это напоминает. Впрочем, хабр не для политики.

Цена на игры в Стиме зависит от региона. Регион — от IP'шника. Есть желание иметь цены в рублях, а не в евро.

Для этого мы используем VPN через SSH с использованием tun-устройств, плюс network namespaces для изоляции приложения от всех остальных сетевых устройств.

Network namespaces

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

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

Если у нас есть несколько интерфейсов (один из которых относится к VPN), то нет штатных методов сказать стиму, что надо использовать его, а не eth0/wlan0. Точнее, мы можем «завернуть» весь трафик в VPN, но это не всегда желательно. Как минимум — рост latency и снижение скорости (даже если VPN ведёт на супербыстрый сервер, увеличение latency, оверхед от туннеля и фиксированная ширина локального канала ставят TCP в положение, когда приходится резать скорость). Как максимум — одно дело «покупать через русский VPN», другое дело — пускать туда весь трафик. Меня совсем не прельщает использование VPN для получения защиты роскомнадзором от оппозиции и вольнодумства.

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

Для решения этой задачи в Linux, уже довольно давно (аж с 2007 года) существует технология, называемая network namespaces, то есть пространства имён для сетей. Суть технологии: над сетевыми интерфейсами создаётся подобие «каталогов», в каждом каталоге может быть несколько сетевых интерфейсов и приложений. Приложение, оказавшееся в заданном сетевом пространстве имён, может использовать (и видит) только те сетевые интерфейсы, которые отнесены к этому пространству.

Картинка ниже поясняет происходящее:

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

Скажу сразу, что стандартная реализация такого взаимодействия — существует.

Однако, поскольку эта статья — продолжение темы «Простой вызов удалённых сервисных методов в одностраничных приложениях», здесь будет приведена альтернативная схема взаимодействия, необходимая для замены ajax на вебсокеты, в контексте подхода (jrspc), описанного в вышеупомянутой теме.

В первой статье — был описан механизм вызова сервисных методов, с использованием ajax.

В этой статье — описано, как можно реализовать данный механизм, с заменой ajax на вебсокеты, не меняя код бизнес-логики приложения.

Такая замена даёт более быстрое соединение(тесты в конце), экономию серверной памяти, и добавляет возможность вызывать методы клиента с сервера.

Для демонстрации, написано небольшое чат-приложение, с исходным кодом на гитхабе.
на примере разбора которого, я попытаюсь объяснить, как реализованы клиентская и серверная части такого взаимодействия.
Приложение работает на сервере tomcat 7.042.
Поддерживает https и wss (сертификат неподтверждённый), и не ведёт логов на сервере.

Яндекс.Карты – это высоконагруженный картографический портал, который работает с огромными объемами данных. В своей лекции Владимир Зайцев рассказывает старшеклассникам – студентам Малого ШАДа – о том, как создавать и поддерживать такие ресурсы, и о технологиях, которые для этого используются. А также на примерах объясняет, какие можно разрабатывать инструменты и проводить исследования на базе полученных данных.



Попробуем разобраться в том, что такое Яндекс.Карты так, как если бы мы ничего о них не знали, и слышим о них впервые. Если смотреть на них в общем, то это большой сайт, на котором собрано несколько сервисов:

• Спутниковые снимки и карта
• Народная карта
• Поиск
• Пробки
• Маршрутизатор и навигация
• Панорамы
• API

Добрый день.
Меня зовут Головач Иван, я руковожу небольшой образовательной компанией и преподаю сам:

1. Java Core
2. Junior Java Developer: Servlet API, JDBC, Maven, JUnit, Mockito, Log4J, основы Spring/SpringMVC, основы JPA/Hibernate, шаблоны/архитектуры MVC/IoC/DAO.
3. Multicore programming in Java.

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

В следствии этого у меня скопилось значительно количество ссылок на видео на русском языке по Java как моего авторства, так и моих коллег.

(GolovachCourses.com)

Здесь собраны несколько вариантов записи моего курса Java Core.
Модуль #1 (Procedural Java):
Набор июль 2013: #1, #2, #3, #4
Набор апрель 2013: #1, #2, #3, #4
Набор февраль 2013: #1, #2, #3, #4
Набор январь 2013: #1, #2, #3, #4
Набор октябрь 2012: #1, #2, #3, #4.

В прошлом году в Санкт-Петербурге прошла конференция бизнес и системных аналитиков в разработке ПО. Был там довольно интересный доклад минчан Марии и Сергея Бондаренко, под названием «Полезные навыки аналитиков. Как стать профессионалом». Ниже публикуем статью, сделанную на основе доклада.