SSH/HTTPS/OpenVPN/Telegram и всё на одном порту?! Что?!
— Да!

• Хотите скрыть наличее у вас некоторых сервисов?
• В публичной wi-fi сети блокируется всё кроме 443 (https) порта?
• Настроили Telegram Proxy/OpenVPN и не хотите его «светить» ?
• SSH подключение к своему серверу из стран с цензурой?

На все эти вопросы ответ один — Мультиплексирование SSL/TLS соединений, или SSLH.

В посте мы рассмотрим как в 1 команду спрятать кучу сервисов за 1 портом.

Я 10 лет разрабатываю ПО, участвовал в нескольких open source-проектах и в многочисленных не-open source-проектах, работал в больших и малых командах, и везде мы использовали Github в качестве репозитория версионирования.

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

1. Части I, II (синглплеер с авторитарным сервером)
2. Часть III (Появление врага)
3. Часть IV (Хэдшот!)

Предлагаю вашему вниманию перевод статьи Fast-Paced Multiplayer (Part I): Introduction.

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

Об авторе: Хэм Фокке — разработчик и консультант ThoughtWorks в Германии. Устав от деплоя в три ночи, он добавил в свой инструментарий средства непрерывной доставки и тщательной автоматизации. Сейчас налаживает такие системы другим командам для обеспечения надёжной и эффективной поставки программного обеспечения. Так он экономит компаниям время, которое эти надоедливые людишки тратили на свои выходки.

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

Привет, Хабр! Представляю вашему вниманию перевод статьи «The Java Language Specification (Chapter 17. Threads and Locks)» Оригинал.

Глава 17. Треды и блокировки (Chapter 17. Threads and Locks)

В то время как большая часть дискуссий в предыдущих главах касалась только поведения кода, исполняемого одновременно и как единое утверждение или выражение одновременно, т.е. в одном треде, JVM (Java virtual machine) может поддерживать одновременно несколько тредов исполнения. Эти треды независимо друг от друга используют код, который действует на значения и объекты, находящиеся в общей памяти (shared main memory). Треды могут поддерживаться за счет использования множества аппаратных процессоров, временным разделением одного аппаратного процессора или временным разделением нескольких аппаратных процессоров.

Треды представлены классом Thread. Единственный способ, каким пользователь может создать тред — это создать объект этого класса; каждый тред ассоциируется с каким-то объектом. Тред начнет свое исполнение, когда будет вызван метод start() на соответствующем Thread-объекте.
Поведение тредов, особенно когда синхронизация выполнена некорректно, может быть непонятно и не соответствовать ожиданиям. Эта глава описывает семантику многопоточного программирования; она содержит правила, согласно которым значения можно увидеть для чтения в общей памяти, которая обновляется множеством тредов. Так как спецификация аналогична Memory Models для различных архитектур, эта семантика известна как Memory Model языка программирования Java. Когда не будет возникать путаницы, мы просто будем называть эти правила "Memory Model".

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

17.1 Синхронизация (17.1. Synchronization)

Java — очень распространённая платформа, на ней пишут очень разные вещи, начиная от Big Data, заканчивая микросервисами, монолитами, enterprise и прочим. И, как правило, всё это развёртывают на Linux серверах. При этом, соответственно, те люди, которые пишут на Java, зачастую делают это совсем на других операционных системах. Там они:

• пишут код;
  
• отлаживают, тестируют;
  
• после этого упаковывают в jar;
  
• отправляют на Linux, и оно работает.
  

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



С другой стороны, есть те, кто занимается администрированием серверов, на их сервера устанавливают JVM, отправляют jar и war-файлы, а с точки зрения мира Linux все это:

• чужеродное;
  
• проприетарное;
  
• собирается не из исходников;
  
• поставляется какими-то jar-архивами;
  
• «отъедает» всю память на сервере;
  
• вообще, ведёт себя не по-человечески.
  

Цель доклада Алексея Рагозина на Highload++, расшифровка которого идет далее, была в том, чтобы рассказать особенности Java для «линуксоидов» и, соответственно, Linux — Java-разработчикам.

Эта статья написана в продолжение к первой части и посвящена новому Date Time API, который был введен в Java 8. Я изначально хотел оформить эту тему отдельно, поскольку она достаточно большая и серьезная. Я еще сам не в полной мере начал использовать этот API в проектах, поэтому разбираться будем вместе по ходу. В принципе в переходе на новый API нет никакой срочной необходимости, более того многие еще и не начинали проекты на Java 8, а это означает, что время на освоение еще есть.

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

Не так давно вышла новая версия самого популярного фреймворка на Java: Spring Framework 5. Новая версия принесла много нового. Одно из самых больших нововведений — модель реактивного программирования. Совсем скоро выйдет Spring Boot 2, который существенно упростит создание микросервисов c данным подходом.

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

Ранее я представил пару небольших постов о потенциальной роли Spring Boot 2 в реактивном программировании. После этого я получил ряд вопросов о том, как работают асинхронные операции в программировании в целом. Сегодня я хочу разобрать, что такое Non-blocking I/O и как применить это знание для создания небольшого tcp–сервера на python, который сможет обрабатывать множество открытых и тяжелых (долгих) соединений в один поток. Знание python не требуется: все будет предельно просто со множеством комментариев. Приглашаю всех желающих!

Способность data scientist-а извлекать ценность из данных тесно связана с тем, насколько развита инфраструктура хранения и обработки данных в компании. Это значит, что аналитик должен не только уметь строить модели, но и обладать достаточными навыками в области data engineering, чтобы соответствовать потребностям компании и браться за все более амбициозные проекты.

При этом, несмотря на всю важность, образование в сфере data engineering продолжает оставаться весьма ограниченным. Мне повезло, поскольку я успел поработать со многими инженерами, которые терпеливо объясняли мне каждый аспект работы с данными, но не все обладают такой возможностью. Именно поэтому я решил написать эту статью — введение в data engineering, в которой я расскажу о том, что такое ETL, разнице между SQL- и JVM-ориентированными ETL, нормализации и партиционировании данных и, наконец, рассмотрим пример запроса в Airflow.

1. Первые шаги
2. Сочетаем функции
3. Частичное применение (каррирование)
4. Декларативное программирование
5. Бесточечная нотация
6. Неизменяемость и объекты
7. Неизменяемость и массивы
8. Линзы
9. Заключение

Данный пост — это пятая часть серии статей о функциональном программировании под названием "Мышление в стиле Ramda".

В четвёртой части мы говорили о написании кода в декларативном стиле (объясняем компьютеру что нужно сделать) вместо императивного (говорим ему, как это сделать).

Вы могли заметить, что некоторые из функций, которые мы написали (forever21, drivingAge и water, к примеру) все принимают параметр, создают новую функцию и применяют эту функцию к параметру.

Это очень распространённый паттерн в функциональном программировании, и Ramda здесь в очередной раз предоставляет нам утилиты для того чтобы ещё немного очистить наш код.

Введение

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

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

Терминология

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


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

• «Забытый слой пирамиды автоматических тестов» (Майк Кон, 2009)
• «Пирамида тестов» (Мартин Фаулер, 2012)
• «Блог отдела тестирования Google» (Google, 2015)
• «Пирамида тестов на практике» (Хэм Фокке, 2018)

В последнее время чаще стал встречать команды, которые используют Guice в качестве DI фреймворка. Стал его бояться (слезать с любимого Spring!?), и, как это обычно в жизни и бывает, страхи мои материализовались — я попал на проект, на котором активно используется Guice…

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

В статье я в очередной раз покажу практическое использование Guice и некоторых его extensions: assistedinject, mutibindings , а также работу с generics. Сначала я опишу суть задачи, а затем итеративно приду к ее решению.

Кого можно назвать «пиксельных шейдеров начальник и пикселов командир»? Дениса Радина, работающего в Evolution Gaming над фотореалистичными веб-играми с использованием React и WebGL: он известен многим как раз под именем Pixels Commander.

В декабре на нашей конференции HolyJS он выступил с докладом о том, как использование GLSL может улучшить работу с UI-компонентами по сравнению с «обычным джаваскриптом». А теперь для Хабра мы подготовили текстовую версию этого доклада — добро пожаловать под кат! Заодно прикладываем видеозапись выступления:

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

Оптимизация ради игроков и собственного психического здоровья

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

Основы оптимизации кода

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

Многие уже научились строить чистые интерфейсы и писать «undo-redo» в несколько строчек. Но как быть с анимациями? Часто их обходят стороной, и они не всегда вписываются в подход (state) ↦ DOM. Есть отличные решения вроде React Motion, но что если вам нужно делать сложные анимации или работать с Canvas, используя физический движок?

В нашем тексте рассказывается, как работать с анимациям в React-приложениях, и сравнивается несколько подходов (D3, React-Motion, «грязные компоненты»). А также о том, как «запускать» анимации в Redux-приложениях. Материал основан на расшифровке доклада Алексея Тактарова с нашей декабрьской конференции HolyJS 2017 Moscow. Прилагаем заодно видеозапись этого доклада:


Осторожно, трафик: под катом много картинок и гифок (сами понимаете, материал про анимации).

Окей, Гугл, раз-раз, как меня слышно, прием? 12 апреля видеоблоггер Mitchollow устраивает в прямом эфире Ютьюба эксперимент, чтобы ответить на простой вопрос: если у вас на компьютере установлено какое-то ПО от Google (например, браузер Chrome), означает ли это, что Гугл, как родина, всегда слушает вас через микрофон? Автор видео сначала показывает табличку с названием товара (игрушки для собак), о котором позже он говорит вслух в течение пары минут. После этого, открыв пару популярных сайтов, моментально натыкается на рекламу зоомагазинов в больших количествах.

Из этого прекрасного эксперимента можно сделать массу далеко идущих выводов. Например, что мы сейчас, с точки зрения разнузданности слежки за пользователями в сети, живем в некотором мире дикого Запада, где нас профилируют по всем параметрам — от высказываний до селфи и паттернов встроенного в телефон датчика ускорения. Возможно, так и есть, но 24 апреля тот же видеоблоггер выкладывает не то чтобы опровержение, а скорее попытку показать, что не все так однозначно. Как обычно бывает в интернетах, первое видео с набросом на вентилятор смотрят больше двух миллионов раз, второе видео набирает всего 160 тысяч просмотров.

Как в блогах, так и в журналах есть множество статей о том, как собрать NAS своими руками.
И с первого взгляда кажется, что при наличии прямых рук, свой NAS по всем пунктам бьёт покупное решение.
"Фигак, фигак и в продакшн", — и вот уже быстро, дёшево и качественно реализованное хранилище радует вас высокой производительностью и надёжностью.