DEV: Рубиновые тона – Telegram
DEV: Рубиновые тона
3.22K subscribers
143 photos
2 videos
8 files
978 links
Анонсы новых видео о программировании (Ruby/Rails, Solidity/Ethereum, Python, JS и не только), практические советы, обзор полезных инструментов и новости из мира IT
Download Telegram
В этом уроке по Ruby 3 мы продолжим говорить об автотестах и применим свои знания на практике. Мы узнаем, как тестировать сторонние API с помощью webmock, как измерять покрытие кода тестами и как работать со вспомогательными файлами. https://youtu.be/f9yVwBYyNqU
👍19🔥101
Помните такие? 😁
🔥30👍14😁4😢3🍓3🤔1
Можно ли в тестах для контрактов легко получить нужное событие? Вполне. К примеру, есть транзакция:

const tx = contract.doSomething();
const receipt = await tx.wait();


Тогда мы можем сделать функцию для поиска события

import type { ContractReceipt } from 'ethers';

async function eventFor(receipt: ContractReceipt, name: string) {
return receipt?.events?.find(function (e) {
return e.event === name;
});
}


Ищем событие

const myEvent = await eventFor(receipt, "MyEvent");


И достаём из него нужное поле

myEvent?.args?.value


Вопросительные знаки тут потому, что наличие этих полей не гарантированно, то есть формально события может и не быть (другими словами, это атрибуты optional). Но так как мы делаем это в тестах и как раз ожидаем, что оно *должно быть* (если, конечно, все предварительные условия выполнены), то всё должно сработать корректно. А вот если события как раз нет, то вылетит ошибка, тест сломается и мы поймём, что где-то у нас проблема.
🔥11👍3
Немного backstage (начал готовить новый урок) 😄
👍30🔥7❤‍🔥2😁1
В этом уроке по Solidity мы с помощью дебаггера Remix будем разбирать байткод, который генерирует компилятор и который используется для деплоя контракта. Мы обсудим каждую отдельную инструкцию, каждый операционный код (opcode) и узнаем смысл и назначение этих инструкций. Таким образом мы поймём, как именно работает стек и память,что именно происходит в момент развёртывания нашего контракта и как передаются в конструктор аргументы и как они обрабатываются.

Это довольно длинный урок, на запись которого ушло весьма приличное время, так что надеюсь, он вам понравится. https://www.youtube.com/watch?v=pz8NeV6bo3E
👍25🔥16
Планируется саммит по Rails в начале следующего года. Правда интересных докладов там пока как-то не очень много, и, похоже, послушать их можно только за деньги (пусть и не очень большие) https://events.geekle.us/ruby
👍6❤‍🔥1
Ну, что ж, первый месяц, когда я в кои-то веки за что-то плачу на Heroku (раньше если там и были платные проекты, то платил заказчик). Пока так

Charges

Amount
Application dynos $ 6.34
Add-on services $ 8.16
Subtotal: $ 14.50
Total:

$ 14.50

Простой dyno и БД. Ну, кое-какие дополнение для почты, логгинга, кэша остались бесплатными, что приятно.
🤔3
В этом уроке по Ruby мы узнаем, как правильно тестировать ошибки, которые может вернуть сторонний сервис. Также мы добавим и настроим Rubocop для исправления стиля нашего кода и наконец-таки опубликуем финальную версию библиотеки на сайт rubygems, чтобы её могли использовать другие разработчики. https://www.youtube.com/watch?v=WLgSqsQCKHQ
14❤‍🔥6👍2👌1
У меня вот тоже уникальный вкус, только, наверное, в другом смысле. А у вас как? 😂
😁3👍1
Ну, и последняя запись на сегодня. Нашёл забавное рекламное видео бородатых годов, где представлен всем известный "микроавтобус" RAF-977, что означает всего лишь Rīgas Autobusu Fabrika. Удивительно, снято ещё в шестидесятые, а места все знакомые - совсем не изменились. https://twitter.com/sovietvisuals/status/1588642492009824259
👍6🔥1
В этом месяце состоялась годовщина нашего фотопроекта "Легенды Оссиании", которому исполнилось пять лет. В рамках проекта мы выпустили некоторое количество фотокомиксов - как серьёзных, так и смешных (сюжет всего этого безобразия писал ваш покорный слуга). К сожалению, политическая ситуация не позволяет нам продолжать работу (участники проекта живут в разных странах), но хотя бы есть, что вспомнить. Эта страница фотокомикса, пожалуй, наиболее любимая и в целом наиболее личная (как и вся эта и последующая части). На создание всей этой истории ушло какое-то легендарное количество времени, но результат получился вполне приличным. Ссылка здесь https://vk.com/ossiania_legends (постоянные читатели и так её уже видели). Ну, а мы с вами скоро увидимся, ибо в этом месяце планируется аж три стрима по разным темам. Берегите себя.
👍8🍾3
Культурные типажи (модель Льюиса)
🤔4❤‍🔥3👍21🔥1
Друзья, предварительно: завтра вечером в районе 21-22 UTC+3 будет стрим по Solidity и байткоду. Посмотрим, как вызываются функции, какие там опкоды и особенности. Думаю, будет интересно 😄
🔥18👍3
В общем, ради развлечения немного пошутковал с нейросетью (тред). Началось с того, что я спросил, что делает конкретный байткод, на что получил ответ "да фиг его знает"
🤣8
Отвечая на вопрос по следам двух прошлых уроков про байткод: что именно происходит при попытке использования delegatecall? Иными словами, что там в байткоде?

Ответ очень простой: ничего особенного 😄 По факту, это можно проверить самостоятельно с подобными контрактами

contract Target {
uint a;

function callMe(uint _a) external {
a = _a;
}
}

contract Demo {
uint a;
address to;

constructor(address _to) {
to = _to;
}

function doCall() external {
(bool success,) = to.delegatecall(
abi.encodeWithSignature("callMe(uint256)", 42)
);
require(success);
}
}


В дебаггере там будет куча не сильно интересных инструкций, которые делают всякие проверки, кодируют сигнатуру и подготавливают стек, но главные инструкции имеют номера 240 и 241 (это с оптимизацией 2000):

GAS(0x5a)
DELEGATECALL (0xf4)


GAS - смотрит, что там по газу осталось, а DELEGATECALL использует значения из стека и определяет с их помощью байткод какого контракта надо выполнить, какой там селектор функции найти и какой аргумент в эту функцию передать. А дальше на DELEGATECALL можно просто нажать кнопку step into и guess what: вы прыгнете к байткоду другого контракта, где все инструкции начинаются опять с нуля, причём в начале будет уже знакомый набор

000 PUSH1 80 - LINE 5
002 PUSH1 40 - LINE 5
004 MSTORE - LINE 5


То есть пока крутится delegatecall, у него там своя атмосфера и своя память. В calldata же будет содержаться что-то такое

0xe73620c3000000000000000000000000000000000000000000000000000000000000002a


Это селектор функции callMe и 0x2a, что равно значению 42 в десятичном формате. То есть я просто в a хочу положить 42. Этот код выполнится в контексте нашего же контракта, но вот память на момент вызова окажется как бы новой.

Почему это можно делать? Потому что *читать* байткод чужого контракта нам никто не мешает, ведь в блокчейне всё публично. Значит мы в принципе можем взять код и его исполнить у себя. Что делать нельзя, так это напрямую что-то менять в чужом состоянии, забирать у кого-то деньги или вносить в байткод изменения, ясное дело.

Ну, а дальше опкоды будут очень похожи на то, что мы видели. Например, мы увидим

026 CALLDATALOAD - LINE 5
027 PUSH1 e0 - LINE 5
029 SHR - LINE 5


Опять как в уроке - он читает calldata и вычленяет оттуда селектор.

А потом

031 PUSH4 e73620c3 - LINE 5
036 EQ - LINE 5


Ну то есть сравниваем селектор. А дальше там всё просто - он берёт из calldata аргумент и говорит

057 PUSH1 00 -
059 SSTORE -


0 - это номер слота переменной a в контракте Target, тк она там на самой первой позиции (потому что в момент компиляции контракта Target он знает, какой слот был у a). Но тк это выполняется в нашем контексте, то по факту *мы имеем ввиду нулевой слот в Demo*. Именно поэтому переменные должны быть перечислены в правильном порядке.

Последняя инструкция в рамках delegatecall:

062 STOP - LINE 9


Дальше он возвращается к исходному байткоду, там меряет returndatasize (чтобы понять вернула ли что-нибудь функция), проверяет require и просто говорит STOP, то есть транзакция завершается.

Иными словами, никакой магии особо нет: он прямо берёт чужой байткод и начинает его прогонять с самого начала, но только для своего контекста.
👍141🔥1