параноик хуесос

Тотальное господство в Cambria'ии или как я получил бан за твинк

2025-04-28T15:30:00.375Z

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

Начало

Время шло, сомнения постепенно сменялись надеждой. Я собрал восемь юнитов для отыгровки, и мы начали играть. За каждого пришлось отдать не меньше 300 $ в эквиваленте ETH — в итоге вышло около 1,2 ETH плюс небольшой резерв на непредвиденные расходы.

Сомнения

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

фармеры — добывают мобов / руду / рыбу;
ПК-шники (Player Killer) — боты, убивающие игроков.

Из-за них нормальный геймплей страдал, прогресс тормозился.

Орешники

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

Так родился проект с кодовым названием O.R.E.S.H.N.I.K — сеть ботов, которые быстро пополняли бы наши ряды и служили боевой мощью гильдии.

Я углубился в исходники и понял, насколько всё это криво: игра, по сути, собрана на Phaser.js и Svelte. 😋
Тогда-то я ещё не подозревал, какой пиздец меня ждёт дальше.

Провал

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

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

Выводы

Тестить бота с одного IP-адреса — ебучая глупость. Больше таких банальных ошибок допускать не планирую.
И вообще, писать ботов стоило ещё во время F2P-стейджа, до начала самого сезона.

история о том, как солану чуть не централизовали

2024-03-17T22:03:45.408Z

Эх, солана-солана, что же ты творишь...

Солана и мемпул

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

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

Gulf Stream - одна из оптимизаций, которая позволяет соланочке быть такой быстрой. Ее главная особенность - каждый раз, как только в валидатор попадает транзакция, валидатор заранее напрявляет транзакцию в лидера, который уже в свою очередь будет исполнять транзакцию. (данные из доки соланы)

Proof Of History - очень сложная штука, которую в двух словах не объяснить. Если говорить ОЧЕНЬ поверхностно, то это последовательность вычислений, которая позволяет определять временной диапазон между транзакциями.

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

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

JITO и их "мемпул"

Житовцы, как истинные гои, хотели зарабатывать мильйоны денег. Насмотрелись на MEV на эфирах всяких и решили, а чо бы и на соланочке такое не сделать????

Сели и думают: ТАКК, КАК БЫ НАМ ТАКОЕ РЕАЛИЗОВАТЬ??

Жито переписывают валидатор соланы, его главные функции становятся:

Перенаправлять транзакции во временное хранилище
Исполнять и симулировать бандлы

БАНДЛ - ПОСЛЕДОВАТЕЛЬНОСТЬ ТРАНЗАКЦИЙ, КОТОРЫЕ ВАЛИДАТОР ИСПОЛНЯЕТ ПОСЛЕДОВАТЕЛЬНО, ТРАНЗАКЦИЮ ЗА ТРАНЗАКЦИЕЙ

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

Jito Block Engine - хуйнюшка, которая принимает от релеера все транзакции и направляет их в ботов. Боты получают эти транзакции, обрабатывают и на выходе возвращают тот самый БАНДЛ, в котором хранится эта самая транзакция и нужные для мева другие транзакции. Блок енжин отправляет в релеер этот бандл, а он уже перенаправляет их в валидатор(если не было превышено 200 миллисекунд).

Такая сложная связка нескольких инструментов позволила JITO добиться создания "мемпула", но это было бы невозможно, если бы в их связке не было бы большого количества валидаторов с большим стейкингом. для этого они проводили всякие активности и тыр пыр мыр мыр уже есть валидаторы с большими объемами стейкинга. ВОТ ЗА ЧТО ВЫ ПОЛУЧИЛИ ДРОПЫ, ДОВОЛЬНЫ???

Что же будет дальше?

Я думаю в ближайшее время люди начнут повторять успех жито, ведь для их успеха им всего лишь нужно:

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

казалось бы, ТАКАЯ СЕТЬ, КАК ТАКОЕ МОЖЕТ БЫТЬ, КАК ЕЕ МОГУТ ТАК ЛЕГКО ПРИВЕСТИ К ЦЕНТРАЛИЗАЦИИ? а вот... вот такое вот случается...

ДЛЯ ВАС СТАРАЛСЯ - https://t.me/dolbaebskicode

Блокчейн эфириум, контракт нфтишек и ебучий питон... или как написать свой BUYER для эфира. АКТ ПЕРВЫЙ

2022-11-02T13:35:31.694Z

Что же такое эфириум минты? - Этим вопросом не задаются грамотные люди, ибо знают, что минтеры - пидорасы.

Набрав в поисковике лучшей социальной сети ВКОНТАКТИ - "что такое эфириум", получил довольно вразумляющий ответ:

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

Изучите Ethereum

Посмотреть другие варианты на DeepL.com

Как же он работает эта тварь?

Блоки и транзакции

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

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

В блоках хранятся транзакции, в транзакциях информация о всех действиях участников блокчейна.

Транзакции подробно

Для следующих тем нужно знать несколько понятий:

Ethereum - нативная монета, которую мы отдаём уёбкам(ныне называются валидаторами) чтобы они наши транзы подтвердили.
Gas limit и gas price - дань для ахуевших хуесосов(в простонародии - комиссия), которую мы должны заплатить, чтобы нашу транзу включили в сеть. Gas limit зависит от сложности транзакции(перевод стоит меньше, чем вызов функций контрактов, потому что количество переносимых байтов в транзе меньше, чем вес твоей мамаши), gas price зависит от количество поступаемых пенисов в жопу сети(Чекать тут).
Data - данные, которые передаются в контракт.

бля, а что нахуй такое эти ваши контракты?

Смарт-контрактики

Смарт-контракт это аппка в блокчейне, у которой есть какой-то пул функций и стор. токены, nft, дексы - всё это работает через них.

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

У нас есть 3 аргумента:от кого, кому и сколько - аргументы.

Конечный результат вызова функции, так называемая INPUT DATA, штука, которая хранит в себе: нейм вызываемой функции и аргументы:

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

Input data - поле транзакции, в котором передаётся информация о том, какую функцию мы хотим вызвать и какие аргументы в неё передать. В переводе USDT мы используем функцию transferFrom и передаём аргументы from, to, value(от кого, кому и сколько). Но в целом, туда можно написать что угодно при желании, например что-то о матери битка???

Вывод

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

Авторы:

Левиафан / Параноик

Эфириум в Расте? Часть вторая

2022-08-12T18:33:38.938Z

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

Окружение

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

Зависимости

Теперь мы создадим проект Rust и добавим необходимые зависимости.

Создайте папку нашего проекта и инициализируйте его с помощью cargo:

mkdir rust-ethereum-tutorial-part2
cd rust-ethereum-tutorial-part2
cargo init

Для удобства добавления зависимостей Rust в наш проект мы будем использовать cargo-edit:

cargo install cargo-edit

Добавим необходимые модули:

cargo add tokio eyre ethers +legacy

Подключение к WebSocket Ноде эфира.

В отличие от прошлого туториала, конструкция подключения будет немного иная:

use ethers::prelude::*;

#[tokio::main]
async fn main() -> eyre::Result<()> {
    // Подключаемся ноде, создаем новый экземпляр провайдера.
    let client = Provider::new(
        Ws::connect("wss://eth-mainnet.g.alchemy.com/v2/rhHsBRIaD9TsoHdKpnymrJimBxPwv5Xp").await?,
    );
    
    Ok(()) // Пустое возвращаемое значение
}

Создание кошелька

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

    let wallet = LocalWallet::new(&mut rand::thread_rng()); // Генерация рандомного кошелька
    let address = wallet.address(); // Получение адреса кошелька

    println!("ебать привет {:?}", address);

Подпись сообщения

Так как мы не долбаебы, то лучше всего изучить какие-то доп. возможности объекта кошелька.

Одна из возможностей подпись сообщения:

    let signature = wallet.sign_message("Я пидор").await?; // Создание сигнатуры

    println!("{}", signature);

Сигнатура подписанного сообщения есть, но как теперь ее верефать?

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

Попробуем наебать систему и вписать какую-то хуйню:

    match signature.verify("Я не пидор", address) {
        Err(_) => println!("ХХИХХИХИ, ТЫ ЧО ПИДОР?))"),
        Ok(_) => println!("ЧОО ТЫ НЕ ПИДОР?"),
    };

Запустив наше детище в ебло прилетит сообщение ХХИХХИХИ, ТЫ ЧО ПИДОР?))

Так, а теперь попробуем ввести правильное значение, которое соответствует подписанному сообщению:

    match signature.verify("Я пидор", address) {
        Ok(_) => println!("ЧЧООО ПИДОР??"),
        Err(_) => println!("НЕЕЕЕЕЕЕ ПИДОР???"),
    };

Что же получится при запуске? - Выведется ЧЧООО ПИДОР??

Чтение мемпула

Чтобы полностью овладеть БЛОКЧЕЙНОМ ЭФИРОМ и стать настоящим Терном, нужно научиться читать мемпул.

Mempool — очень важная часть сети Bitcoin (сеть компьютеров и устройств, подключенных к Интернет и работающих с программным обеспечением Bitcoin Core). Данные, хранящиеся в мемпуле — это неподтвержденные транзакции, которые в настоящее время застряли в сети. Каждая часть мемпула хранится на специальном электронном устройстве и за его содержимым можно наблюдать в режиме реального времени. Чтобы объяснить, как это работает, сначала нужно разобраться, что происходит во время транзакции?

(я спиздил определение хз нахуя но мне похуй)

ТАААК, чтение мемпула дело простое, но требует некоторых действий.

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

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

    let filter = Filter::new();

Теперь, чтобы начать читать мемпул, нам нужно передать этот своеобразный фильтр в метод subscribe_logs, который создает новый ручей подписок

    let mut stream = client.subscribe_logs(&filter).await?;

Ручей получили, а как в нем купаться? Для этого нам потребуется особенная конструкция:

    while let Some(log) = stream.next().await {}

Такая хуета позволяет постоянно получать данные из мемпула.

Чтобы понять, что находится внутри лога, достаточно ебануть под двум клавишам ctrl+space.

По аналогии я сделал что-то примерно такое:

    while let Some(log) = stream.next().await {
        println!(
            "транзакция {:?}, блок {:?}",
            log.transaction_hash, log.block_number
        );
    }

Код готов, пришло время запускать:

[meqy@meqy-hplaptop15seq2xxx eth_rust]$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.38s
     Running `target/debug/eth_rust`
ебать привет 0xda85e6532cce4869c18025aac2b34386d5c5f8ce
18350d269ad85efee75ee83ed22c84c891dd6209c27868582c9e81a65cc6ad9965002af2fd1c0174ad44bfcacd314ff6af153f1cba02e6e368f25e2d9fc6172c1b
ХХИХХИХИ, ТЫ ЧО ПИДОР?))
ЧЧООО ПИДОР??
^C

Дальше мне думать чото лень, так что ждите следующей статьи.

#rust

#ethereum

#mempool

Эфириум в Расте? Часть первая: Отправка простых транзакций.

2022-08-10T16:21:33.923Z

В этом руководстве показано, как запустить локальную виртуальную машину Ethereum (EVM) в Rust, запросить баланс и совершить простые транзакции.

Настройка зависимостей

Прежде чем писать код, мы должны убедиться, что у нас установлены некоторые необходимые инструменты, а именно Rust и Ganache.

Rust

Установите Rust, следуя инструкциям. Или, если вы используете Arch Linux, вы можете следовать инструкциям здесь, чтобы установить Rust.

ganache-cli

Ganache поможет вам быстро создать среду Ethereum для тестирования. Если вам не нужен весь пакет, вы можете просто установить ganache-cli с помощью npm,

npm install -g ganache

Запустите ganache-cli, чтобы проверить, правильно ли вы его установили.

Настройка проекта Rust

Теперь мы создадим проект Rust и добавим необходимые зависимости.

Создайте папку нашего проекта и инициализируйте его с помощью cargo:

mkdir rust-ethereum-tutorial
cd rust-ethereum-tutorial
cargo init

Для удобства добавления зависимостей Rust в наш проект мы будем использовать cargo-edit:

cargo install cargo-edit

Это добавит последнюю версию ethers в качестве зависимости в Cargo.toml:

cargo add --no-default-features ethers +legacy

и еще несколько библиотек:

cargo add tokio +full clap hex eyre

Краткое описание этих библиотек:

tokio - позволяет нам использовать асинхронные функции в Rust
clap - для работы с аргументами командной строки
hex - для работы с шестнадцатеричными строками
eyre - это библиотека, которая помогает сократить количество кодового кода при обработке ошибок

Подключение к RPC Ethereum Web3

Узел Ethereum обычно предоставляет конечную точку HTTP, WebSocket или IPC для доступа к сети Ethereum. Для разработки в локальной среде мы можем подключиться к нашей конечной точке, предоставляемой локально запущенным ganache. Чтобы запустить ganache в Rust, мы можем просто использовать Ganache::new().spawn():

use ethers::utils::Ganache;
use eyre::Result;#[tokio::main]
async fn main() -> Result<()> {
    // Спавн Ganache экземпляра
    let ganache = Ganache::new().spawn();
    println!("HTTP Endpoint: {}", ganache.endpoint());
    Ok(())
}

Если мы выполним команду cargo run, мы увидим URL конечной точки, выведенный в консоли:

...
HTTP Endpoint: http://localhost:46795

Доступ к тестовым кошелькам ganache

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

Чтобы сделать наш пример более детерминированным, мы можем настроить его на использование определенную мнемонику:

let mnemonic = "gas monster ski craft below illegal discover limit dog bundle bus artefact";
let ganache = Ganache::new().mnemonic(mnemonic).spawn();

Чтобы получить доступ к кошельку, созданному ganache, мы сначала получим закрытые ключи, а затем преобразуем их в экземпляр LocalWallet:

// Получите первый кошелек, управляемый ganache
let wallet: LocalWallet = ganache.keys()[0].clone().into();
let wallet_address: String = wallet.address().encode_hex();
println!("Default wallet address: {}", wallet_address);

Подключение через JSON RPC

Для взаимодействия с узлом или сетью Ethereum нам потребуется создать клиент, который подключается к конечной точке ganache:

// Провайдер - это клиент Ethereum JsonRPC.
let provider = Provider::try_from(ganache.endpoint())?.interval(Duration::from_millis(10));

Запрос баланса по адресу

Теперь, когда наш клиент подключен к сети Ethereum, мы можем запросить баланс любого адреса в нашем кошельке:

// Запросить баланс нашего счета
let first_balance = provider.get_balance(first_address, None).await?;
println!("Баланс первого адреса кошелька: {}", first_balance);

Если мы снова запустим программу cargo run, то узнаем, что по этому адресу у нас есть 1000ETH. Это добавляется программой Ganache автоматически.

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

// Запросить баланс случайного счета
let other_address_hex = "0xaf206dCE72A0ef76643dfeDa34DB764E2126E646";
let other_address = "0xaf206dCE72A0ef76643dfeDa34DB764E2126E646".parse::<Address>()?;
let other_balance = provider.get_balance(other_address, None).await?;
println!(
    "Баланс адреса {}: {}",
    other_address_hex, other_balance
);

Попробуйте cargo run, и вы увидите, что баланс этого адреса равен нулю:

Баланс адреса 0xaf206dCE72A0ef76643dfeDa34DB764E2126E646: 0

Создать простую транзакцию

Далее мы создадим простую транзакцию для перевода нескольких токенов Ethereum на другой адрес.

// Создайте транзакцию для перевода 1000 wei на `other_address`.
let tx = TransactionRequest::pay(other_address, U256::from(1000u64)).from(first_address);
// Отправляем транзакцию и ждем получения
let receipt = provider
    .send_transaction(tx, None)
    .await?
    .log_msg("Ожидание трансфера")
    .await?
    .context("Нет получателя")?;
    
println!(
    "Транзакция замайнена на блоке {}",
    receipt.block_number.context("Не получилось получить блок транзакции")?
);
println!(
    "Баланс у {} {}",
    other_address_hex,
    provider.get_balance(other_address, None).await?
);

Выполните cargo run, вы получите следующие результаты:

Ожидание трансфера: 
0xff6153310304732bb28856ca3a90ab9c94c5c9e20cf51e8a2803f3483670cd6f
Транзакция замайнена на блоке 1
Баланс у 0xaf206dCE72A0ef76643dfeDa34DB764E2126E646 1000

#rust

#ethereum

#transaction

#block

Реализация своего АПИ на Rust с помощью Tokio и Wrap

2022-08-10T12:30:19.199Z

Сейчас вам поведаю о создании своего API сервиса на основе Warp и Tokio.
Это является перевод данной статьи.

Структура

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

Роуты

Для своего апи я определил два роута

/customers
     - GET -> получить список пользователей
     - POST -> создать нового пользователя и добавить инфомацию в хранилище
/customers/{guid}
     - GET -> получить информацию о пользователе
     - POST -> обновить информацию о пользователе
     - DELETE -> удалить пользователя из хранилища

Обработчики

На основе маршрутов мне потребовалось определить несколько обработчиков

list_customers -> вернуть список пользователей
create_customer -> создать нового пользователя и добавить его в базу данных
get_customer -> вернуть информацию о конкретном пользователе
update_customer -> обновить информацию о пользователе 
delete_customer -> удалить пользователя из базы данных

База данныхчто

Для примера я буду использовать in-memory хранилище.

Чтобы сгенерировать необходимый набор данных я воспользовался mockaroo.

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

Зависимости

Warp — Фреймворк для создания веб-сервера на Расте.
Tokio — Асинхронная среда выполнения для Раста.
Serde — Библиотека для де/сериализации данных в типизированные данные Раста.

Реализация

Модели

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

В main.rs определите новый модуль с именем models следующим образом:

mod models;
fn main() { /* Логика */ }

Затем создать новый файл с именем models.rs и добавьте следующее:

pub struct Customer {
    pub guid: String,    
    pub first_name: String,
    pub last_name: String,    
    pub email: String,    
    pub address: String,
}

Так как я разрабатываю API, эта структура данных должна иметь возможность сериализации и десериализации JSON. Я также хочу иметь возможность копировать структуру в хранилище данных и из него, не беспокоясь о проверке заимствования.

Для этого я добавлю оператор drive для структуры пользователя, чтобы использовать пару макросов из библиотеки Serde и пару из Rust. Сейчас models.rs выглядит так:

База данных

База данных для этого API будет являться in-memory(то есть находиться в оперативной памяти и после отключения сервера очистится), которая будет являться вектором структуры Customer. Но хранилище должно быть общим для всех маршрутов, поэтому я буду использовать смарт поинтеры[0 ] Раста вместе с Mutex[1], чтобы обеспечить безопасность потоков.

Во-первых, добавим в main.rs новый модуль db:

mod db;
mod models;
fn main() { /* Логика */ }

Теперь создадим новый файл db.rs.

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

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

Добавим примерно такое в db.rs:

use std::sync::Arc;
use tokio::sync::Mutex;

use crate::models::Customer;

pub type Db = Arc<Mutex<Vec<Customer>>>;

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

Инициализация пустого хранилища довольно проста:

pub fn init_db() -> Db {
    Arc::new(Mutex::new(Vec::new()))
}

Но чтобы получить данные из файла, нам придется добавить еще одну зависимость:

serde_json — Для чтения необработанного JSON

Добавим его в Cargo.toml:

serde_json = "1.0"

Теперь мы можем изменить db.rs следующим образом:

use std::fs::File;
use serde_json::from_reader;

pub fn init_db() -> Db {
    let file = File::open("./data/customers.json");
    match file => {
        Ok(json) => {
            let customers = from_reader(json).unwrap();
            Arc::new(Mutex::new(customers))
        },
        Err(_) => {
            Arc::new(Mutex::new(Vec::new()))
        }
    }
}

Эта функция пытается прочитать файл ./data/customers.json. В случае успеха функция возвращает хранилище данных, загруженное данными клиента, в противном случае она возвращает пустой вектор.

db.rs должен выглядеть примерно так:

Обработчики

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

Создадим файл handlers.rs и определим его, как модуль в файле main.rs:

mod handlers;

Добавим в handlers.rs несколько импортов:

use std::convert::Infallible;
use warp;

use crate::models::Customer;
use crate::db::Db;

Этот кусок позволяет обращаться к примитивам Customer и Db, которые мы определили ранее, из модуля обработчиков. Также тут мы импортируем модуль warp и перечисление Infallible, которое является типом ошибок, что никогда не могут произойти.

Список пользователей

Обработчик list_customersвобработчик принимает на вход ссылку на хранилище и возвращает Result, который оборачивает JSON-ответ.

pub async fn list_customers(db: Db) -> Result<impl warp::Reply, Infallible> { 
   // ...  
}

В теле функции нужно реализовать получение данных из хранилища и сериализация их в JSON объект. Для удобства wrap предоставляет функцию, которая преобразовывает вектор в JSON объект.

Строчка let customers = db.lock().await; дожидается блокировки выполнения задачи, чтобы можно было безопасно обратиться к хранилищу.

Строка let customers: Vec<Customer> = customers.clone() клонирует вектор из MutexGuard.

Последняя строка Ok(warp::reply::json(&customers)) оборачивает вектор в JSON объект и возвращает его.

Создание пользователя

Обработчик create_customer принимает на вход объект Customer и ссылку на хранилище. В случае успешного создания возвращает статус код CREATED, в ином случае BAD_REQUEST.

Но прежде нужно обновить импорты wrap'a в файле handlers.rs.

Заменяем строчку use wrap; на;

use warp::{self, http::StatusCode};

Данное изменение позволит использовать перечисление StatusCode, как респонс.

По аналогии с list_customers определяем обработчик create_customer с подобным содержанием:

Получение пользователя

Обработчик get_customer на вход берет guid определенного пользователя и ссылку на базу данных и возвращает JSON-объект, если пользователь найден, иначе вернет заглушку в виде дефолтного объекта пользователя.

Перед этим добавим еще один макрос в структуру пользователя:

По аналогии с другими обработчиками добавляет что-то подобное в код:

pub async fn get_customer(guid: String, db: Db) -> Result<Box<dyn warp::Reply>, Infallible> {
}

Возвращаемый примитив немного отличный от других, потому что на выходе мы получаем либо StatusCode, либо JSON-объект. Так как оба этих примитива реализуют warp::Reply, то мы можем использовать динамическое приведение через dyn.

Обновить пользователя

Обработчик update_customer на вход принимает guid пользователя, измененный объект Customer и ссылку на бд. Возвращает OK, если получилось изменить пользователя, NOT_FOUND в случае, если нет пользователя в хранилище.

Удаление пользователя

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

Если удалось удалить пользователя из базы данных, то функция вернет NO_CONTENT, иначе NOT_FOUND.

Роутинг

Теперь у нас все обработчики собраны, теперь присвоим их соответствующим роутам.

В main.rs определим еще один модуль:

mod routes;

Теперь создадим файл routes.rs:

use std::convert::Infallible;
use warp::{self, Filter};

use crate::db::Db;
use crate::handlers;
use crate::models::Customer;

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

fn with_db(db: Db) -> impl Filter<Extract = (Db,), Error = Infallible> {
    warp::any().map(move || db.clone())
}

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

GET /customers

Функция возвращает тип, реализующий трейт Filter. Extract используется, когда происходит совпадение, и возвращается значение Extract.

По сути, функция определяет маршрут, который соответствует запрошенному пути «/customers» и является GET запросом.

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

pub fn customer_routes(db: Db) -> impl Filter<Extract = impl warp::Reply, Error = warp::Rejection> + Clone {
    customers_list(db.clone())
}

POST /customers

Этот маршрут добавит нового клиента в хранилище данных, если он еще не существует.

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

fn json_body() -> impl Filter<Extract = (Customer,), Error = warp::Rejection> + Clone {
    warp::body::content_length_limit(1024 * 16)
        .and(warp::body::json())
}

Функция будет очень похожа на customers_list, за исключением обработчика. Добавьте в route.rs следующее:

Эта функция определяет маршрут, который соответствует пути «/customers» и является POST запросом. Затем JSON из POST запроса и ссылка на хранилище извлекаются и передаются обработчику.

GET /customers/{guid}

Этот маршрут попытается получить одного клиента из хранилища данных.

В этой функции мы используем макрос path! из wrap, который позволяет передавать путь с переменной.

Это определяет маршрут, который будет соответствовать «customers/{какое-то значение}» и GET запросу. Затем он извлекает хранилище и передает его обработчику.

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

Например, если вспомогательная функция для маршрутов обновлена таким образом:

pub fn customer_routes(
    db: Db,
) -> impl Filter<Extract = impl warp::Reply, Error = warp::Rejection> + Clone {
    customers_list(db.clone())
        .or(create_customer(db.clone()))
        .or(get_customer(db.clone()))
}

Маршрут get_customer никогда не будет совпадать, потому что они имеют общий корневой путь — «/customers», что означает, что маршрут списка клиентов будет соответствовать «/customers» и «/customers/{guid}».

Чтобы устранить проблему, упорядочите маршрут так, чтобы наиболее точное совпадение было первым. Как это:

pub fn customer_routes(
    db: Db,
) -> impl Filter<Extract = impl warp::Reply, Error = warp::Rejection> + Clone {
    get_customer(db.clone())
        .or(customers_list(db.clone()))
        .or(create_customer(db.clone()))
}

PUT /customers/{guid}

Этот маршрут попытается обновить клиента, если он существует, и вернуть код состояния OK, в противном случае возвращается код состояния NOT_FOUND.

По аналогии с созданием определяем обработчик:

Затем обновим обертку над маршрутом пользователя:

pub fn customer_routes(
    db: Db,
) -> impl Filter<Extract = impl warp::Reply, Error = warp::Rejection> + Clone {
    get_customer(db.clone())
        .or(update_customer(db.clone()))
        .or(create_customer(db.clone()))
        .or(customers_list(db))
}

DELETE /customers/{guid}

Последний маршрут просто удаляет клиента из хранилища данных, если он соответствует заданному guid, а затем возвращает код состояния NO_CONTENT, в противном случае возвращается код состояния NOT_FOUND.

Затем обновим оболочку маршрута клиента. После добавления всех маршрутов обертка должна выглядеть так:

На этом все маршруты заканчиваются. Теперь мы можем перейти к связыванию всего вместе.

Функция main

Файл main.rs собирает все части кода воедино. Он инициализирует хранилище данных, получает все маршруты и запускает сервер. Это также довольно короткий файл, поэтому я просто покажу его целиком:

Мы уже видели первые несколько строк, так что давайте пройдемся по основной функции.

Атрибут функции #[tokio::main] устанавливает точку входа для среды выполнения tokio. Это позволяет нам объявить основную функцию как асинхронную.

Первые две строки main — это просто вызовы функций из наших модулей. Первый инициализирует хранилище данных, а второй получает оболочку маршрутов наших клиентов.

В последней строке используется warp::server для создания сервера, а затем run для запуска сервера на указанном хосте и порте. Мы используем ключевое слово await, чтобы выполнить код до тех пор, пока функция запуска не завершится.

#rust

#wrap

#mutex

#arc

#dyn

#server

Подборка библиотек для персонализации терминальных приложений на Python

2022-08-09T12:14:11.408Z

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

1. asciimatics

Asciimatics — это пакет, помогающий людям создавать полноэкранные текстовые пользовательские интерфейсы (от интерактивных форм до анимации ASCII) на любой платформе. Он распространяется под лицензией Apache Software Foundation License 2.0.

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

2. textual

Textual — это полноценный фреймворк TUI (текстовый пользовательский интерфейс) для Python, вдохновленный современной веб-разработкой.

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

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

3. rich

Rich это Python библиотека, позволяющая отображать красивый текст и форматировать терминал.

Rich API упрощает добавление цветов и стилей к выводу терминала. Rich также позволяет отображать красивые таблицы, прогресс бары, markdown, код с отображением синтаксиса, ошибки, и т.д. — прямо после установки.

4. questionary

Questionary — это библиотека Python для простого создания красивых интерфейсов командной строки.

Позволяет создавать красивые промпты, которые украсят дефолтный питоновский инпут.

Поддерживаемые промпты:

5. python-prompt-toolkit

python-prompt-toolkit - библиотека, позволяющая создавать интерактивные программы командной строки прямо на Python.

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

#python

#питон

#пайтон

#программирование

#textual

#prompt

#toolkit

#teminal

#tui

#terminaluserinterface

#anchor_exampletextuserinterfac

параноик хуесос

Тотальное господство в Cambria'ии или как я получил бан за твинк

Начало

Сомнения

Орешники

Провал

Выводы

история о том, как солану чуть не централизовали

Солана и мемпул

JITO и их "мемпул"

Что же будет дальше?

Блокчейн эфириум, контракт нфтишек и ебучий питон... или как написать свой BUYER для эфира. АКТ ПЕРВЫЙ

Блоки и транзакции

Транзакции подробно

Смарт-контрактики

Вывод

Эфириум в Расте? Часть вторая

Окружение

Зависимости

Подключение к WebSocket Ноде эфира.

Создание кошелька

Подпись сообщения

Чтение мемпула

Эфириум в Расте? Часть первая: Отправка простых транзакций.

Настройка зависимостей

Rust

ganache-cli

Настройка проекта Rust

Подключение к RPC Ethereum Web3

Доступ к тестовым кошелькам ganache

Подключение через JSON RPC

Запрос баланса по адресу

Создать простую транзакцию

Реализация своего АПИ на Rust с помощью Tokio и Wrap

Структура

Роуты

Обработчики

База данныхчто

Зависимости

Реализация

Модели

База данных

Обработчики

Список пользователей

Создание пользователя

Получение пользователя

Обновить пользователя

Удаление пользователя

Роутинг

GET /customers

POST /customers

GET /customers/{guid}

PUT /customers/{guid}

DELETE /customers/{guid}

Функция main

Подборка библиотек для персонализации терминальных приложений на Python

Навигация:

1. asciimatics

2. textual

3. rich

4. questionary

5. python-prompt-toolkit