Всем привет, с вами @Arhelmus, адепт Scala секты и любитель поговорить на тему того что ООП не нужно.

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

Пожалуй одной из главных мотиваций для меня оставаться со Scala является то что я могу лаконично писать функциональный код

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

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

Есть те кто юзают активно ФП в своем коде? На чем пишете? Мне вот одно время очень нравился Эрланг.

Но только чет Эрланг не может в маркетинг, поэтому интерес слегка угас, не так много проектов.

Тут в комментах появилась мысль что все эти модные языки от лукавого, и бизнесу лучше то где побольше девелоперов подешевле, что думаете?

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

Раз был разговор об Эрланге, то давайте поговорим о модели акторов, есть кто пишет распределенные системы на них?

@backendsecret как-то было желание соскочить на них из-за того что были проблемы с реализацией валидации в евентсорсном проекте

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

Кажется все те кто пишут распределенные системы на акторах сейчас работают, а не в твиттере сидят :)

Недавно мой знакомый начал писать и пропагандировать Rust. Одним из пунктов было то что программы запускаются моментально, нет загрузки VM.

В мире Scala есть такая эксперементальная штука как scala-native.org которая соберет ваш код через тот-же LLVM в бинарник.

Но несмотря на это, большим удивлением было то что на том-же Rust есть свои sinatra-like фреймворки. Веб на низкоуровневом языке?

@backendsecret писать веб часть не на языке с динамической типизацией – знатный мазохизм

Раз затронули тему веба, в последнее время много от кого слышу идеи о том чтобы использовать NodeJS как фронтенд сервер.

В Wix мы переходим к этому так как есть разделение между back и front. Благодаря этому фронты смогут сами делать себе такое апи как захотят

Альтернативным решением есть генерация JS либ из сервер кода, aka ScalaJS scala-js.org.

@backendsecret тут и котлин аннонсировали что собираются бинарники генерить

Тут кстати наброс был про то что C лучше этих ваших JVM ибо в нем нет GC. У меня есть знакомые которые пишут трейдерских ботов на джаве.

Особенность их в том, что они работают с выключенным GC :)

Когда они пишут код, то жестко профайлят, чтобы не дай бог не нагенерить много мусора.

Это я к чему, для всего есть свой инструмент. Но к слову о Rust, у них gc делается через коомпиляцию, что как по мне просто мега фича.

@theaspect @backendsecret Никто и не спорит. Но может быть резон отказаться от jre и использовать что-то более тонкое, или предсказуемое.

@backendsecret @theaspect у SUN когда-то был такой неофиц.лозунг: если тормозит sun.java - просто купи ещё один сервер Sun :)

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

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

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

Единственная проблема это то что в моем случае GC отжирает больше процессорного времени на очистку мусора.

Но для этого @den_sh запилил github.com/densh/scala-of… , так что если сильно запарится по этому поводу, то проблема решаема

@backendsecret тут важен баланс, если новый инструмент позволяет эффективней решать задачи, то надо использовать. Разработчики подтянуться

Пойду поработаю немного, после обеда продолжим ;)

Я вернулся, мне тут из моей старой компании посоветовали делать меньше инсайдов о том что мы используем, пришлось немножно потереть твиты)

Одной из вещей которую мне привили в Wix это TDD. Как вы относитесь к написанию тестов до реализации?

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

Еще как по мне tdd вполне себе заменяет статическую типизацию, просто вместо коомпилятора, тесты покроют код.

@backendsecret
Tests cover code
And time trieth truth

Но все-же вещью которая как по мне не имеет смысла, это тесты сквозь всю систему, когда подымается весь бекенд и селениумом дергается фронт

Мало того что для прогона тестов нужно поднять абсолютно все, так еще имеется множество мест где что-то может упасть по таймауту

В итоге получается тест шредингера, он вроде как упал, но вообще проходит.

@backendsecret не, проверка и вывод типов на этапе компиляции дорогого стоит, я уж молчу про фичи IDE оттуда вытекающие

Давайте сегодня поговорим немного о девопс и сразу же опрос, чем вы менеджите свое приложение в продакшене?

У меня все начиналось с банального git clone в /www папку, но все закончилось когда мне рассказали что я не закрыл .git для доступа из вне)

После был шеф, который настраивал не я, и в принципе меня все устраивало, пока не пришлось руками ранить скрипт на каждой машине

Сеичас в своем проекте я использую docker и swarm. То чего я добился этим, это оперированием кластером серверов разом.

В docker compose конфиге можно описать все зависимости между контейнерами и после просто скормить этот конфиг master ноде.

Расскажите что интересного у вас было для того чтобы построить деплой?

Сеичас на самом деле очень много хайпа вокруг докера, есть те кто сьели пуд соли на этом?

Кастую @fxposter сюда, думаю тебе есть о чем рассказать

У меня была проблема связанная с тем что я не мог найти какой из докер контейнеров выжирал все IO.

Я хостил некоторые девелоперские штуки типо репозиториев приватных на сервере за 3 бакса, и иногда он просто намертво вис

Самое веселое было в том, что процессор и память были свободны, а load average пробивал очередную высоту

В итоге после поочередного отключения контейнеров проблемой оказался docker-registry, который что-то очень активно делал с диском

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

Кстати ни docker stats, ни iotop не показывали адекватные данные в момент таких зависаний

@backendsecret вот примерно так, только вместо Surf ansible стал использовать dimaip.github.io/2015/03/03/hyb…

Кстати клевая статья о том как написать свой менеджер контейнеров:
infoq.com/articles/build…
Увы, все на golang

Кстати небольшой вброс, вот если с стейтлесс приложениями и их контейнеризацией все понятно, то что делать с бд?

У себя я все-же держу бд в докере, но делаю маунт на жесткий диск, держите ли вы бд в докере?

В новой компании все будет хоститься на aws, что в принципе уже стандарт для веба, кто сравнивал стоимость aws с своими серверами в дц?

И кстати я слышал что не все что предлогает амазон такое-уж отказоустойчивое, допустим их elastic search, @pvoznenko расскажешь?

@backendsecret из личного опыта, я гоняю докер 2 года для хостинга простых веб-проектов в in-house среде, очень даволен

@backendsecret свое дешевле, но когда нужна гибкость но денег на собственное облако нет, AWS неплохой вариант.

О чем мы еще не говорили, так это про базы данных, признавайтесь в каких базах храните данные и почему?

В Wix мы все храним в MySQL и некоторые команды пробуют Cassandra. И да, не спешите кидать помидоры "а почему не постгрес/монга/etc".

Данные хранятся в денормализированном виде и как итог, в принципе все равно где хранить key-value.

На эту тему есть отличная статья на хабре от нашей компании, habrahabr.ru/company/wix/bl….

Благодаря этому, для нас найболее важным критерием является стабильность бд и наличие навыков у DBA для того чтобы поддерживать нас.

Много кто поддался хайпу монги? Есть те кто у в итоге остались довольными тем что протащили в проект?

У нас одно время был кластер монги, но это время было недолгим, ибо мастер нода отваливалась стабильно раз в неделю.

Главной фишкой было то, что новый мастер не выбирался, по какой-то магической причине и в итоге мы отвечали дольше чем обычно.

Решение было более фееричным чем баг, крон скрипт который детектил падение мастера и перезапускал ее.

Не менее важной темой считаю хайп по postgres, первым камнем в их огород была Uber, если вы не читали, советую ознакомится в их блоге.

Та самая, крутая статья: eng.uber.com/mysql-migratio…
TLDR: потому-что репликация

Многие вещи из этой статьи в итоге оспорили, но основное отличие и причина по которой они перешли на mysql это мутабельность.

Postgres иммутабелен внутри, и вместо изменения записи, он создает новую, с таким-же id (спойлер, primary key в postgres это не primary key)

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

MySQL же мутабельный, и вроде как решает проблемы с которыми они столкнулись в Postgres.

@backendsecret да-да, та самая в которой уберовские инженеры расписались в том, что использовали старую версию и не знают про HOT.

А есть среди нас люди которые хранят данные (именно хранят, а не кешируют что-то) в redis, elasticsearch итд? Расскажите как спится по ночам

@backendsecret кастую в тред @ptico, я помню был у тебя на докладе где ты очень хвалил redis, поделись опытом

Держу базы исходных слов для твитов @zapretbot @eto_kogda_ebut @HarryTwibotter в redis, читаю ленту этого аккаунта… twitter.com/i/web/status/8…

@backendsecret есть ли те, кто хотя бы пробовал tarantool?)

@backendsecret через "да еб твою мать" слышал, что у нас так делают. А так я не в теме, я на клиенте.

В Java комьюнити есть огромное нежелание писать асинхронный код, и это как по мне большая проблема, ибо это влияние переходит и на скалу

Мне когда-то попадал в руки проект, где был прокси сервер на Java, который выделял по треду на реквест.

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

В общем тема сегодняшнего опроса, пишите ли вы асинхронный серверный код?

Одной из вещей которая мешает писать приложение полностью асинхронными является jdbc драйвер

По определенным причинам, мне не понятным, единственный способ сделать jdbc драйвер асинхронным, это добавить костыль с очередью

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

Есть кто может рассказать в чем проблема сделать тру асинхронный jdbc драйвер? Ведь всего-то нужно делать запросы по сети не синхронно, не?

@backendsecret вся работа со statement'ами и транзакционным контекстом должна быть привязана к одному соединению (~потоку)

Вопрос ближе к системному уровню, когда вы запускаете асинхронную операцию IO, по сути вы говорите ОС вычитать/записать данные и сообщить

@backendsecret как ос выделяет ресурсы на эту операцию? тред на задачу?

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

Надеюсь воскресенье не скажется на активности опроса, как вы защищаете трафик при передаче по сети?

Для начала хотелось бы развеять миф о том что перехватив handshake клиента и сервера возможно расшифровать весь последующий трафик

Данное заблуждение идет от того что люди не понимают что значит асимметричные ключи шифрования.

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

Однако расшифровать можно только одним - секретным. Это как банальный замок, каждый может его закрыть, но открыть только тот у кого ключ.

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

Однако у ассиметричных ключей есть проблемы:
1) Возможность украсть ключ для расшифровки через уязвимости сервера
2) Подбор секретного ключа

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

Примерами того как можно украсть ваши ключи, является когда-то нашумевший heartbleed.com

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

Еще одним интересным примером не из серверной разработки является Pegasus.
bgr.in/news/pegasus-s…

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

Для решения проблемы того что кто-то когда-то украдет ваши ключи и расшифрует трафик, были найдены Эфемерные ключи

SSL DHE: Diffie–Hellman ephemeral. Эфемерные значит временные.

Суть в том, что если вы боитесь что кто-то украдет секретный ключ, шифруйте уже зашифрованный трафик сгенерированными ключами.

Тогда злой дядя, расшифровав ваш трафик, увидит обмен открытыми ключами и еще зашифрованный трафик

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

Не поможет если ваше приложение взломано в течении времени, но в таком случае можно не парится насчет того как расшифровать трафик из сети.

С проблемой украденных ключей разобрались, а что делать с подбором ключа? И возможно ли это?

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

Большей проблемой является то что процессоры становятся мощнее, а вычисления дешевле.

Проблемой на сегодня есть GPU вычисления которые позволяют добиться большего перфоманса в числодроблении благодаря паралеллизму

Однако этого всеравно мало чтобы допустим быстро взломать RSA 4096. Как было сказано в комментариях. Но...

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

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

Ну а теперь давайте поговорим о том что делать дабы ваш RSA в течении времени не подобрали.

Ответ - не использовать RSA ;)

Есть такая вещь как эллиптическая криптография, SSL ECC - elliptic curves cryptography.

Это асимметричное шифрование построенное на основе эллиптической кривой, в четырехмерном пространстве

@backendsecret И если честно, я не могу представить такую кривую в своей голове, ну да ладно :)

Для шифрования с помощью этих кривых используются проекции на плоскости.

На основе этих проекций можно понять, о той ли части кривой идет речь, а дальше идет матан в который я так и не докопал

Главное здесь то, что повышается сложность подбора ключа, что позволяет использовать более короткие ключи чем в RSA.

Таким образом, венцом безопасности будет использование ECDHE шифрования (ефемерные эллиптические ключи), но нужно ли оно вам?)

Есть те кто работали над приложениями для которых действительно было важно сохранить данные скрытыми даже через десятки лет?

@backendsecret было бы круто послушать

@backendsecret @phillennium а что насчет помех, ведь 0 и 1 не просто так выбраны в качестве основы, это уровни напряжения

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

@backendsecret строилась на примере о передаче посылки сквозь заведомо небезопасные точки

@backendsecret алгоритм решения был, А вешает замок и отправляет посылку к Б, Б вешает свой замок и отправляет к А, А открывает замок

@backendsecret в результате Б получал посылку закрытую своим же ключем, но невозможно снять шифр с сообщения в произвольном порядке

@backendsecret что в принципе и послужило основой идеи, что невозможно безопасно передавать данные заранее не договорившись о ключах)

Спасибо всем за внимание, на этой неделе с вами был @Arhelmus, надеюсь вам понравилось (а если нет, ну и черт с ним). Удачи ;)