Evo Dev Club

2021-06-11 16:02:02 Продолжаем рассказывать про opensource-проекты, которые делают наши лучшие специалисты. В этот раз о ttag

ttag - это библиотека и набор утилит для локализации javascript-приложений. Работает на тегировагных шаблонных строках. Это фича языка, когда строка заворачивается в обратные кавычки, как gql у Apollo. В нашем случае выглядит вот так:

import { t } from "ttag";
t`Введите имя пользователя`

История:
4 года назад возникла задача локализации фронтенда prom.ua. Хотелось иметь простой инструмент для организации перевода интерфейса. Нам было важно, чтобы переводы в проект мог вносить переводчик (не тех.специалист, без доступа к репозиторию). Для перевода бекенда уже использовался gettext. Это надежный и проверенный стандарт для организации инфраструктуры переводов. Однако тогда мы не нашли готового удобного gettext инструмента для js. В итоге, решили писать свой, о чем ни разу не пожалели. Проекту уже около 4-х лет, успешно внедрен на продуктах EVO и не только. Также пришелся по душе ребятам из ProtonMail, Metabase.

Особенности:
- CLI для извлечения строк в формат gettext (*.pot, *.po файлы), для которых есть специальные редакторы
- babel-плагин для удобной сборки в разные локали
- поддержка JSX-тегов внутри строк для перевода. Удобно для перевода фраз, внутри которых зашита верстка. Например в случаях, когда в тексте встречается ссылка

Автор и основной мейнтейнер наш лучший специалист в области архитектуры фронтенда Саша Мостовенко. Задавайте ему свои вопросы в комментариях

#evo Открыть/Комментировать

2021-06-09 18:21:44 Держите 16й выпуск WatEvoCast!
Тема выпуска: Flutter
Гость: наш лучший специалист Теодор Мыцик

- сравнили со всеми альтернативами и поругали React Native
- обсудили интерфейсы мобильных приложений
- вспомнили какой tooling есть у флаттера и как это помогает разрабатывать
- узнали, как это взять и пересесть на совсем новую и свежую технологию: плюсы, минусы и подводный камень
- спросили при чем тут Fuchsia и что с ней делать
- разобрались почему native experience не так и нужен

Послушать можно на сайте или в вашем любимом подкаст-выигрывателе: /

#watevocast Открыть/Комментировать

2021-05-14 12:05:29 Решили немного рассказать о нашем опенсорсе. Начнем с lets (https://github.com/lets-cli/lets)

Предыстория

До перехода на docker мы пользовались своим (opensource, rust) решением для контейнеризации и оркестрации - vagga/lithos. В vagga процесс построения образа проверял чексумы файлов с зависимостями, сам умел скачать готовый образ из репозитория, а если его нет, то сбилдить. Для больших монолитов, где зависимости меняются часто и пересборка регулярная и долгая - это важно. Кроме того vagga давала удобный способ строить CLI для запуска разных команд внутри ваших образов. Словом, docker-compose и рядом не стоял, не говоря о Makefile и bash.

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

Что такое lets?

lets это таск-раннер. Создал файл lets.yaml, добавил пару команд, готово.

Главные особенности:
- вычисление чексум файлов
- переменные окружения
- указание зависимостей одних команд от других
- простой и понятный способ описать и парсить аргументы (docopts)

В prom.ua мы используем lets
- для запуска приложения
- для запуска тестов (локально и в gitlab ci)
- для запуска Selenium тестов

Одно из интересных применений, это подсчет чексумы файлов от которого зависит нужно ли пересобирать докер контейнер (Dockerfile, requirements.txt, package.json). При изменении одного из файлов мы считаем чексуму и используем ее как tag для докер образа. Таким образом, при запуске проекта, если файлы поменялись, то мы посчитаем чексуму, и если образ докера с таким тегом есть в registry, то мы его просто спулим, ведь образы постоянно билдятся на CI. Что это дает?
В большинстве случаев разработчик пулит себе уже готовый образ за несколько секунд, а не билдит его локально около 20-30 минут.
По соглашению, чтобы запустить только что склонированый репозиторий достаточно запустить выполнить lets run. Для нового разработчика в проекте это супер-удобно.

Для проекта основное преимущество в использовании lets это то что lets является абстракцией над тем как проект запускается.
Сегодня это docker + docker-compose. Завтра что-то другое (podman, etc). Можно заменить все что угодно под капотом, для людей ничего не изменится, команды те же.

Автор и основной контрибутор - наш лучший специалист Макс Киндрицкий Можете спросить его о чем-нибудь в комментариях

#evo Открыть/Комментировать

2021-04-21 14:05:45 Мітап розробників на Clojure

Завтра, 22.04, о 19.00 відбудеться онлайн-мітап Київської юзер-групи Clojure. Заплановано дві доповіді:

1. @mishabohdan про фреймворк Duct
2. Сергей Нечипорчук про те, як запускали платформу для онлайн-конференцій в Attendify

Мітап транслюватиметься на YouTube (посилання буде опубліковано пізніше)
Докладніше у https://t.me/kyivprogusergroup Открыть/Комментировать

2021-04-01 10:21:06 Python functions naming: an algorithm

Здравый гайд по именованию функций. Особенно полезно почитать тем у кого методы, которые что-то возвращают называются только get_* и никак иначе.

#python #codestyle #medium #pydaily #nothabr Открыть/Комментировать

2021-03-29 11:52:49 В соседнем канале серия постов про ошибки в работе с реляционными БД, и это прямо ценно

https://t.me/nosingularity/737
https://t.me/nosingularity/738
https://t.me/nosingularity/739 Открыть/Комментировать

2021-03-29 11:52:49 Но если вы фанат реляционных БД, то вот тут еще есть что интересного почитать Открыть/Комментировать

2021-03-29 11:51:11 Очень хороший текст о том, почему традиционные реляционные БД плохо скейлятся и как DynamoDB (+ его последователи Apache Cassandra, ScyllaDB) решают эту проблему.

Автор разбирает основные 3 проблемы реляционных БД:

1. Перфоманс JOIN-ов. На малых объемах это практически незаметно, но при росте записей в таблицах время на джойн растет также
2. Сложности горизонтального масштабирования. Либо мы соглашаемся с тем, что все данные живут на одной машине и можем делать запросы с джойнами, юнионами и подзапросами в любых комбинациях; либо мы шардируем данные но тогда денормализируем и теряем плюсы реляционок.
3. Размер и количество данных, которые возвращает запрос никак не ограничены. Поэтому сложный запрос или лок на таблицу может сильно затормозить параллельно идущие запросы.

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

Я сильно упростил, конечно. Рекомендую почитать статью

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

https://www.alexdebrie.com/posts/dynamodb-no-bad-queries/

#databases Открыть/Комментировать

2021-03-22 12:46:01 Отличный набор книг по разработке, архитектуре и сопровождению ПО. К каждой есть небольшой обзор.

Я как раз сейчас Designing Data-Intensive Applications неспешно читаю. Действительно фундаментальный труд.

https://apolomodov.medium.com/software-design-books-743be52e4c71

#books Открыть/Комментировать

2021-03-15 14:35:05 Наш лучший специалист в области построения инфраструктуры Тарас Филипов пишет заметки о приручении OpenStack и других администраторских буднях.

Свежий пост о поиске поиске причины out of memory на OpenStack и при чем тут CPU

https://www.linkedin.com/pulse/%25D0%25BF%25D0%25B0%25D0%25BC%25D1%258F%25D1%2582%25D1%258C-numa-%25D0%25B4%25D0%25B2%25D0%25B0-%25D0%25BF%25D1%2580%25D0%25BE%25D1%2586%25D0%25B0-taras-filipov/?trackingId=FZH9wkPsQSCIGlQmTH3ZKw%3D%3D

#openstack Открыть/Комментировать