- увидел на фейсбуке рекламу хедж-фонда, который лично курируют Павел Дуров и Илон Маск. как думаешь, стоит попробовать?
- нет. это скам
- откуда ты все знаешь?
- книги читал
- про инвестиции?
- про Буратино
- нет. это скам
- откуда ты все знаешь?
- книги читал
- про инвестиции?
- про Буратино
😁49
Китайской ядерной батарейкой, которая может работать 50 лет я заинтересовался и полез посмотреть оригинальные источники, чтобы точно получить ТТХ. Что мы имеем:
- батарея имеет размер 15x15x5мм
- выдает 3 вольта
- выдает 100 микроватт фиксированно
Интересно, но очень мало. Практического применения - ноль. Производитель обещает 1-ваттные батарейки к 2025 году, что при той же технологии будет являть собой куб примерно 22х22х22 сантиметра. 10 таких батареек могут запитать самый маленький Cortex-A, с гарантией что он не вырубится под нагрузкой.
Лучше ситуация с Cortex-M, там есть модели по 100 милливатт. Питать такой процессор можно ядерным кубом 10х10х10см, примерно как 4 кубика-рубика. Правда зачем питать - непонятно. Периферией не обвешать - не хватит батарейки. А для компактных камер слежения или микрофонов - как-то не слишком компактно.
А вообще дело было так - лаборатория выкатила презентацию, что ядерная батарейка - это в принципе возможно, хоть пока и жутко коряво. А журналисты уже дописали всё остальное. Особенно доставляет, что такие батарейки будут помогать ИИ. Ага, и тогда компьютеры станут опять размером со стадион.
- батарея имеет размер 15x15x5мм
- выдает 3 вольта
- выдает 100 микроватт фиксированно
Интересно, но очень мало. Практического применения - ноль. Производитель обещает 1-ваттные батарейки к 2025 году, что при той же технологии будет являть собой куб примерно 22х22х22 сантиметра. 10 таких батареек могут запитать самый маленький Cortex-A, с гарантией что он не вырубится под нагрузкой.
Лучше ситуация с Cortex-M, там есть модели по 100 милливатт. Питать такой процессор можно ядерным кубом 10х10х10см, примерно как 4 кубика-рубика. Правда зачем питать - непонятно. Периферией не обвешать - не хватит батарейки. А для компактных камер слежения или микрофонов - как-то не слишком компактно.
А вообще дело было так - лаборатория выкатила презентацию, что ядерная батарейка - это в принципе возможно, хоть пока и жутко коряво. А журналисты уже дописали всё остальное. Особенно доставляет, что такие батарейки будут помогать ИИ. Ага, и тогда компьютеры станут опять размером со стадион.
😁26👍10
Читаем работы студентов. "Пользовательская база: пожилые люди возраста 45 лет и выше".
М-да.
М-да.
😁65
- спасибо за предложение, но у нас уже есть облако для наших клиентов
- а чего оно так медленно работает?
- эээ, да там сервер говно сейчас. поменяем
- а чего оно так медленно работает?
- эээ, да там сервер говно сейчас. поменяем
😁26👍6
Я стал меньше хейтить растовский sqlx, после того как сложились некоторые привычки работы с ним. Предметная область: я поддерживаю две СУБД, вернее одну - Postgres и ещё Sqlite. Код должен работать с обеими, ORM не применять.
- забудьте про sqlx::Any. во-первых оно кривое и ущербное, во-вторых сложный/производительный db-agnostic sql - это все равно миф.
- sqlx::Pool нельзя просто кинуть в бокс как dyn, в sqlx слишком много инструментов, привязанных к конкретной СУБД женериком. поэтому есть два подхода - либо строим high-level функционал своей базы через трейты, имплементируем их для Pool и боксируем, либо делаем dynamic dispatch ручками через енум с парой вариантов пула. Второй подход чуть менее удобный зато даёт чуть более читаемый код, потому что операции для разных баз не разнесены по имплам, а находятся в одной функции.
- перестать мучаться с функциями для общих задач и использовать макросы. иначе есть риск потеряться в 10 этажных настройках женериков и лайфтаймов.
- обязательно сделать Encode/Decode для своих типов. у sqlx в целом убогое API для этих вещей, много чего строится приватными методами, но выжить можно. зато потом имеете нормальный bind, а обратно из базы данные через FromRow тянутся почти как в serde (serde курильщика).
- использовать sqlx::QueryBuilder, особенно там где запросы меняются динамически (напр. селекты с фильтрами).
- забудьте про sqlx::Any. во-первых оно кривое и ущербное, во-вторых сложный/производительный db-agnostic sql - это все равно миф.
- sqlx::Pool нельзя просто кинуть в бокс как dyn, в sqlx слишком много инструментов, привязанных к конкретной СУБД женериком. поэтому есть два подхода - либо строим high-level функционал своей базы через трейты, имплементируем их для Pool и боксируем, либо делаем dynamic dispatch ручками через енум с парой вариантов пула. Второй подход чуть менее удобный зато даёт чуть более читаемый код, потому что операции для разных баз не разнесены по имплам, а находятся в одной функции.
- перестать мучаться с функциями для общих задач и использовать макросы. иначе есть риск потеряться в 10 этажных настройках женериков и лайфтаймов.
- обязательно сделать Encode/Decode для своих типов. у sqlx в целом убогое API для этих вещей, много чего строится приватными методами, но выжить можно. зато потом имеете нормальный bind, а обратно из базы данные через FromRow тянутся почти как в serde (serde курильщика).
- использовать sqlx::QueryBuilder, особенно там где запросы меняются динамически (напр. селекты с фильтрами).
👍16
Главная проблема любых оптимизаций работы с СУБД - вовремя остановиться и случайно не написать свой ORM.
👍24😁20
Интересно что Postgres под капотом работает с TIMESTAMP и TIMESTAMPTZ, как с 64-bit integers (в микросекундах). Но разработчики выбрали в качестве Epoch "J2000.0" - 1 января 2000 года 00:00:00. Эта точка отсчёта используется в основном в астрономии.
Понабирали астрономов по объявлениям.
Понабирали астрономов по объявлениям.
😁18👍11🔥3
Обнаружил что ChatGPT отлично пишет сериализацию-десериализацию через serde. Она штука простая, но тоже слегка упоротая по API и главное - скучная. Поэтому машине отдавать - самое то. Сказал во что паковать и из чего можно распаковывать - и готово решение.
Кстати, я вчера загрузил Rust-структуру в GPT4, описал как какое поле хочу хранить и он мне написал готовый модуль под Elastic, с созданием индекса и балк-сабмитом. Написал по-умолчанию под 7ю версию клиента, одним запросом переписал под 8ю. И не ныл, что ТЗ плохо поставили.
Растет падаван.
Кстати, я вчера загрузил Rust-структуру в GPT4, описал как какое поле хочу хранить и он мне написал готовый модуль под Elastic, с созданием индекса и балк-сабмитом. Написал по-умолчанию под 7ю версию клиента, одним запросом переписал под 8ю. И не ныл, что ТЗ плохо поставили.
Растет падаван.
👍27🔥17
Кроме Error, у меня на Rust-проектах свой Time.
TLDR: периодически устраивайте субботники и приводите рабочие инструменты в порядок.
Зачем:
- умеет делать From/Into в SystemTime и еще 100500 других
- я очень много работаю с таймстемпами. во-первых у меня сразу есть Time::now(), во-вторых я могу просто сделать Time + 100500, мне лень писать Duration. В-третьих у меня есть даже Time::yesterday(), в основном для serde default - у нас очень много API, где старт таймфрейма по-умолчанию за сутки до now.
- умеет десериализироваться из float, integer, тапла/массива [sec, nsec] и даже из строки (через dateparser)
- умеет сериализироваться в float (тяжелое наследие нашей легасни)
- теперь еще умеет записываться-читаться через sqlx в PostgreSQL (как TIMESTAMP/TIMESTAMPTZ) и Sqlite (как BIGINT в наносекундах)
В результате я просто объявляю переменную как Time, дальше начинается магия раста. Прикинул, что без постоянной конверсии данных руками туда-сюда (включая остальные собственные типы) скорость разработки увеличивается раза в два-три, а желание еще больше - нет рутины.
Почему не подходят другие крейты/почему не выпущу как крейт: по причине см. From/To, де/сериализацию и базы. В каждом проекте/конторе своя политика и всё равно придется городить newtype вокруг готового.
TLDR: периодически устраивайте субботники и приводите рабочие инструменты в порядок.
Зачем:
- умеет делать From/Into в SystemTime и еще 100500 других
- я очень много работаю с таймстемпами. во-первых у меня сразу есть Time::now(), во-вторых я могу просто сделать Time + 100500, мне лень писать Duration. В-третьих у меня есть даже Time::yesterday(), в основном для serde default - у нас очень много API, где старт таймфрейма по-умолчанию за сутки до now.
- умеет десериализироваться из float, integer, тапла/массива [sec, nsec] и даже из строки (через dateparser)
- умеет сериализироваться в float (тяжелое наследие нашей легасни)
- теперь еще умеет записываться-читаться через sqlx в PostgreSQL (как TIMESTAMP/TIMESTAMPTZ) и Sqlite (как BIGINT в наносекундах)
В результате я просто объявляю переменную как Time, дальше начинается магия раста. Прикинул, что без постоянной конверсии данных руками туда-сюда (включая остальные собственные типы) скорость разработки увеличивается раза в два-три, а желание еще больше - нет рутины.
Почему не подходят другие крейты/почему не выпущу как крейт: по причине см. From/To, де/сериализацию и базы. В каждом проекте/конторе своя политика и всё равно придется городить newtype вокруг готового.
👍13🔥4💩1
Вообще забавно с временем сделано в Эластике. Там у них date может хранить только миллисекунды. Поэтому они выпустили date_nanos, который может хранить наносекунды.
Но в date_nanos нельзя писать timestamp в наносекундах. Нужно писать его всё равно в миллисекундах. А если вы не сдались и всё же хотите наносекунды - конвертить numeric в ISO-строку.
Всё для людей, как в любом приличном ентерпрайзе.
Но в date_nanos нельзя писать timestamp в наносекундах. Нужно писать его всё равно в миллисекундах. А если вы не сдались и всё же хотите наносекунды - конвертить numeric в ISO-строку.
Всё для людей, как в любом приличном ентерпрайзе.
😁28👍3
Немного беллетристики от меня сегодня.
https://medium.com/@disserman/working-with-data-storages-in-rust-a1428fd9ba2c
https://medium.com/@disserman/working-with-data-storages-in-rust-a1428fd9ba2c
Medium
Working with data storages in Rust
The article explains how to create an agnostic trait-based storage in Rust. Covers topics: async, new-type, dynamic dispatching, sqlx etc.
👍6🔥5👎2💩1