Дорогие коллеги, хочется поздравить вас с наступающим Новым Годом.
Загадывать не будем, но пусть следующий год у каждого будет успешнее и интереснее, чем предыдущий 🚀
А в планах Alex Code делиться новостям, лучшими практиками и просто полезной информации чаще, больше и круче! Не будем ограничиваться текстом - запустим видео формат 🎞
До новых встреч в 2024 году 🐲
Загадывать не будем, но пусть следующий год у каждого будет успешнее и интереснее, чем предыдущий 🚀
А в планах Alex Code делиться новостям, лучшими практиками и просто полезной информации чаще, больше и круче! Не будем ограничиваться текстом - запустим видео формат 🎞
До новых встреч в 2024 году 🐲
Какие бывают ID?
А давайте сегодня познакомимся с различными видами числовых идентификаторов, их особенностями, интересными свойствами и ограничениями. Поехали!
Integer и Big Integer с автоинкрементом
Один из самых простых и распространенных способов. В качестве ID выступает простое число (обычно начиная с 1) и каждое следующее число больше предыдущего на единицу:
В разных реляционных базах данных такие идентификаторы могут создаваться через немного разный синтаксис: AUTO_INCREMENT, SERIAL, SEQUENCE - но смысл общий.
✅ К плюсам относят малое место на диске (4 для int и 8 байт bigint), быструю скорость генерации.
⛔️ Но для для распределенных систем подходит плохо. Такие айди предназначались для случая с одним мастером в БД. Кроме этого такие айди могут нести проблемы безопасности, потому что добавляют системе излишней прозрачности для стороннего наблюдателя - по сгенеренному ID очевидны предыдущий, следующий и общее количество конкретных сущностей в системе.
UUID
Расшифровывается, как универсальный уникальный идентификатор (еще называют GUID - глобальный уникальный идентификатор). Представляет собой 128-битное число, которое обычно записывают с использованием цифр и латинских букв
✅ В силу своего размера вероятность сгенерировать дублирующие UUID ничтожно мала, поэтому такие идентификаторы можно использовать в распределенных системах.
❗️В качестве недостатка отмечаем больший размер по сравнению с Integer и Big Integer, а так же условно долго время генерации случайных или псевдослучайных числе.
ObjectId и Snowflake ID
✅ Пытаются объединить в себе лучшее, что могут предложить варианты выше: и сравнительно компактный размер (8 и 12 байт соответственно), и генерацию на базе timestamp, и высокую скорость, и возможность использовать в распределенных системах.
🦾 Данные идентификаторы состоят из 3 частей: timestamp (с точностью до секунд или миллисекунд), идентификатор ноды/инстанса/процесса, автоинкрементальная часть. Такая структура обеспечивает и уникальность на разных машинах, и высокую скорость генерации, а также предсказуемую сортировку (чем позже сгенерирован ID, тем он ниже при сортировке по возрастанию).
Пожалуй, это самые распространенные айдишники на базе чисел, которыми пользуются в реальных системах. Надеюсь, теперь есть над чем подумать и что выбрать в следующий раз.
До связи 🤘
А давайте сегодня познакомимся с различными видами числовых идентификаторов, их особенностями, интересными свойствами и ограничениями. Поехали!
Integer и Big Integer с автоинкрементом
Один из самых простых и распространенных способов. В качестве ID выступает простое число (обычно начиная с 1) и каждое следующее число больше предыдущего на единицу:
1, 2, 3, 4, 5...В разных реляционных базах данных такие идентификаторы могут создаваться через немного разный синтаксис: AUTO_INCREMENT, SERIAL, SEQUENCE - но смысл общий.
✅ К плюсам относят малое место на диске (4 для int и 8 байт bigint), быструю скорость генерации.
⛔️ Но для для распределенных систем подходит плохо. Такие айди предназначались для случая с одним мастером в БД. Кроме этого такие айди могут нести проблемы безопасности, потому что добавляют системе излишней прозрачности для стороннего наблюдателя - по сгенеренному ID очевидны предыдущий, следующий и общее количество конкретных сущностей в системе.
UUID
Расшифровывается, как универсальный уникальный идентификатор (еще называют GUID - глобальный уникальный идентификатор). Представляет собой 128-битное число, которое обычно записывают с использованием цифр и латинских букв
c505044c-85bd-496e-b711-bdcaae31a803 В rfc4122 описано целых 5 разных схем генерации с использованием timestamp, MAC-адреса, хешей md5 и sha1, а так же полностью рандомный способ - uuid v4.✅ В силу своего размера вероятность сгенерировать дублирующие UUID ничтожно мала, поэтому такие идентификаторы можно использовать в распределенных системах.
❗️В качестве недостатка отмечаем больший размер по сравнению с Integer и Big Integer, а так же условно долго время генерации случайных или псевдослучайных числе.
ObjectId и Snowflake ID
✅ Пытаются объединить в себе лучшее, что могут предложить варианты выше: и сравнительно компактный размер (8 и 12 байт соответственно), и генерацию на базе timestamp, и высокую скорость, и возможность использовать в распределенных системах.
🦾 Данные идентификаторы состоят из 3 частей: timestamp (с точностью до секунд или миллисекунд), идентификатор ноды/инстанса/процесса, автоинкрементальная часть. Такая структура обеспечивает и уникальность на разных машинах, и высокую скорость генерации, а также предсказуемую сортировку (чем позже сгенерирован ID, тем он ниже при сортировке по возрастанию).
Пожалуй, это самые распространенные айдишники на базе чисел, которыми пользуются в реальных системах. Надеюсь, теперь есть над чем подумать и что выбрать в следующий раз.
До связи 🤘
Новый Shell для JavaScript - Bun Shell
Всем (или почти всем) приходится иногда писать что-то на shell/bash, но взаимодействие с основным языком каждый раз вызывает смешанные чувства - скорее негативные 😒
Именно поэтому создатели Bun (нового быстрого runtime для JavaScript) пытаются решить это путем создания нового встроенного Shell.
Решение имеет сразу много плюсов: и быстро работает, и кроссплатформенное, и выразительный синтаксис, и удобное взаимодействие с остальным кодом.
Подроности опубликовал сегодня на habr - https://habr.com/ru/articles/795949/.
Всем (или почти всем) приходится иногда писать что-то на shell/bash, но взаимодействие с основным языком каждый раз вызывает смешанные чувства - скорее негативные 😒
Именно поэтому создатели Bun (нового быстрого runtime для JavaScript) пытаются решить это путем создания нового встроенного Shell.
Решение имеет сразу много плюсов: и быстро работает, и кроссплатформенное, и выразительный синтаксис, и удобное взаимодействие с остальным кодом.
Подроности опубликовал сегодня на habr - https://habr.com/ru/articles/795949/.
Хабр
Релиз Bun Shell (новый shell для JavaScript)
JavaScript — самый популярный скриптовый язык в мире. Так почему же так сложно запускать shell-скрипты на JavaScript? import { spawnSync } from "child_process"; // this is a lot more work than it...
Docker - давай до свидания 🤪
Вчера российский сегмент интернета наполнился новостями о том, что компания Docker отключила доступ к своему публичному registry с российских ip-адресов.
Шок, паника, какие-такие законы, претензии, почему только сейчас - вот этот поток эмоций наполнял жаркие обсуждения. Честно говоря, у меня почти не случилось никакого эмоционального отклика😐 И вот почему.
"Уже проходили, ничего нового".
Для меня был яркий момент весной 2018 года, когда Роскомнадзор пытался блокировать телеграм и начал блокировать целые подсети апишников. В эти массовые блокировки стали попадать и облачные гиганты, такие как Google Cloud, где тогда жил наш проект с чатиками для отелей. Вот тогда был шок😱 такого на практике ещё не было.
Достаточно быстро мы поняли, что ждать у моря погоды бесполезно, пытаться в Гугле вытащить новый айпишник, который не попал в блокировки, тоже как-то слишком на удачу. И мы просто подняли свой прокси в Германии, переключили DNS, подвязали нужные сертификаты и вперёд. Все заработало и мы вернулись к своим делам.
Теперь про докер.
Проблема с docker pull наиболее легко решается через зеркала, поддержка которых заботливо встроена в сам докер. В файле конфига (в Linux обычно /etc/docker/daemon.json) нужно добавить ключик registry-mirrors со списком адресов. Я пользуюсь:
- https://mirror.gcr.io (это гугл)
- https://dockerhub.timeweb.cloud (это далеко не маленький российский хостер, который раньше всех подсуетился😄)
Если вы собираете свои контейнеры, то хранить их (и соответственно делать `docker push`) лучше на registry от Яндекс Облако, Selectel, VK Cloud и тд, или поднимайте свой регистр, или используйте встроенный в какой-нибудь Gitlab/Gitea/аналог.
Это далеко не полная инструкция, чуть подробнее нашел сегодня на хабре статью - https://habr.com/ru/articles/818565/.
Работаем дальше, до связи 🤘
Вчера российский сегмент интернета наполнился новостями о том, что компания Docker отключила доступ к своему публичному registry с российских ip-адресов.
Шок, паника, какие-такие законы, претензии, почему только сейчас - вот этот поток эмоций наполнял жаркие обсуждения. Честно говоря, у меня почти не случилось никакого эмоционального отклика😐 И вот почему.
"Уже проходили, ничего нового".
Для меня был яркий момент весной 2018 года, когда Роскомнадзор пытался блокировать телеграм и начал блокировать целые подсети апишников. В эти массовые блокировки стали попадать и облачные гиганты, такие как Google Cloud, где тогда жил наш проект с чатиками для отелей. Вот тогда был шок😱 такого на практике ещё не было.
Достаточно быстро мы поняли, что ждать у моря погоды бесполезно, пытаться в Гугле вытащить новый айпишник, который не попал в блокировки, тоже как-то слишком на удачу. И мы просто подняли свой прокси в Германии, переключили DNS, подвязали нужные сертификаты и вперёд. Все заработало и мы вернулись к своим делам.
Теперь про докер.
Проблема с docker pull наиболее легко решается через зеркала, поддержка которых заботливо встроена в сам докер. В файле конфига (в Linux обычно /etc/docker/daemon.json) нужно добавить ключик registry-mirrors со списком адресов. Я пользуюсь:
- https://mirror.gcr.io (это гугл)
- https://dockerhub.timeweb.cloud (это далеко не маленький российский хостер, который раньше всех подсуетился😄)
Если вы собираете свои контейнеры, то хранить их (и соответственно делать `docker push`) лучше на registry от Яндекс Облако, Selectel, VK Cloud и тд, или поднимайте свой регистр, или используйте встроенный в какой-нибудь Gitlab/Gitea/аналог.
Это далеко не полная инструкция, чуть подробнее нашел сегодня на хабре статью - https://habr.com/ru/articles/818565/.
Работаем дальше, до связи 🤘
Начинаем использовать ИИ 🤖
Уже только ленивый не слышал о ChatGPT, нейронных сетях и том, как ИИ может помочь человечеству. А может и заменить собой то ли 50%, то ли 80% профессий, если не прямо сейчас, то в скором будущем.
Все истории и примеры использования генеративных нейронных сетей прекрасны и вдохновляют, но что же мы можем получить на сегодняшний день? Вроде как нужно попытаться максимально облегчить выполнение рутинных и скучных задач. Но, оказывается, использовать ChatGPT на постоянной основе - это тоже навык, ему тоже нужно научиться 🧠
И вот я начал. Идет, честно говоря, с трудом. Нет привычки “не думать”. Только задача встает передо мной, как я неосознанно начинаю перебирать различные способы решения и аналогии с тем, что мне приходилось делать ранее. Перекладывать умственные задачи на ChatGPT - это испытание, это нужно заставлять себя, учиться этому процессу в конце концов.
Что легко начать делать с помощью нейронки в разработке:
🔍 Использовать как поисковик по нетривиальным темам. Если ваш запрос звучит “как использовать вместе A, B, C”, то это то самое. Вам должно повезти, чтобы кто-то сталкивался с проблемой раньше и гугл бы смог найти статью или обсуждение этой проблемы. Но скорее всего вам придется собирать пазл самостоятельно из отдельных порций информации. ChatGPT же сразу начинает описывать готовое решение в соответствии с запросом.
🛠️ Использовать новую библиотеку. Если сроки горят и погружаться с головой в документацию не вариант, то ИИ тут отлично помогает. Можно и валидацию написать, и SQL запрос через неизвестную ORM тоже сделать, и какие-нибудь нужные компоненты в клиентском роутинге заюзать.
🥱 Переписывать код, когда простого find-and-replace уже не хватает. Если нужно заменить одну библиотеку на другую или изменить что-то в подходе именования, то тут ИИ справляется на ура.
🖨️ Генерация шаблонного кода. Оставим за скобками тот факт, что избыток шаблонного кода на проекте - это грустно. Но тесты, например, писать никто не отменял. ChatGPT отлично сгенерирует структуру из describe / it и добавит дефолтное наполнение, которое остается только подкорректировать с учетом специфики проекта.
Отдельно бы хотелось сказать, что у ChatGPT бывают опечатки или фактически неверные ответы, поэтому всё это требует тщательной проверки! Не стоит ответы от ИИ сразу запускать на проде 😁
Если используете нейронки в работе другими классными способами, то пишите в комментариях. Будет очень интересно обменяться опытом.
Всем нейронного повышения продуктивности!
До связи 🤘
Уже только ленивый не слышал о ChatGPT, нейронных сетях и том, как ИИ может помочь человечеству. А может и заменить собой то ли 50%, то ли 80% профессий, если не прямо сейчас, то в скором будущем.
Все истории и примеры использования генеративных нейронных сетей прекрасны и вдохновляют, но что же мы можем получить на сегодняшний день? Вроде как нужно попытаться максимально облегчить выполнение рутинных и скучных задач. Но, оказывается, использовать ChatGPT на постоянной основе - это тоже навык, ему тоже нужно научиться 🧠
И вот я начал. Идет, честно говоря, с трудом. Нет привычки “не думать”. Только задача встает передо мной, как я неосознанно начинаю перебирать различные способы решения и аналогии с тем, что мне приходилось делать ранее. Перекладывать умственные задачи на ChatGPT - это испытание, это нужно заставлять себя, учиться этому процессу в конце концов.
Что легко начать делать с помощью нейронки в разработке:
🔍 Использовать как поисковик по нетривиальным темам. Если ваш запрос звучит “как использовать вместе A, B, C”, то это то самое. Вам должно повезти, чтобы кто-то сталкивался с проблемой раньше и гугл бы смог найти статью или обсуждение этой проблемы. Но скорее всего вам придется собирать пазл самостоятельно из отдельных порций информации. ChatGPT же сразу начинает описывать готовое решение в соответствии с запросом.
🛠️ Использовать новую библиотеку. Если сроки горят и погружаться с головой в документацию не вариант, то ИИ тут отлично помогает. Можно и валидацию написать, и SQL запрос через неизвестную ORM тоже сделать, и какие-нибудь нужные компоненты в клиентском роутинге заюзать.
🥱 Переписывать код, когда простого find-and-replace уже не хватает. Если нужно заменить одну библиотеку на другую или изменить что-то в подходе именования, то тут ИИ справляется на ура.
🖨️ Генерация шаблонного кода. Оставим за скобками тот факт, что избыток шаблонного кода на проекте - это грустно. Но тесты, например, писать никто не отменял. ChatGPT отлично сгенерирует структуру из describe / it и добавит дефолтное наполнение, которое остается только подкорректировать с учетом специфики проекта.
Отдельно бы хотелось сказать, что у ChatGPT бывают опечатки или фактически неверные ответы, поэтому всё это требует тщательной проверки! Не стоит ответы от ИИ сразу запускать на проде 😁
Если используете нейронки в работе другими классными способами, то пишите в комментариях. Будет очень интересно обменяться опытом.
Всем нейронного повышения продуктивности!
До связи 🤘
Поиск “сломанного” коммита с git bisect
Обычно для исправления бага очень бы хотелось знать, в каком конкретно коммите он впервые появился… Но коммитов с последней работающей версии может быть запушено очень много! Как же найти коммит, который всё сломал??? 🤯
На первый взгляд кажется вполне логичным проверить все коммиты, начиная с конца - и нужный коммит мы не пропустим! Но и время можно убить за этой процедурой предостаточно⏳
В терминах алгоритмов, такой поиск называется линейным, и он действительно не отличается скоростью 🐢🐢🐢 А вот бинарный поиск справится намного быстрее! В общем случае он применяется для поиска по отсорированному массиву и обладает логарифмической сложностью. В нашем же случае можно считать, что коммиты отсортированы по признаку сломанности - сначала все несломанные коммиты, потом сломанные. С помощью такого подхода среди 100 коммитов можно найти первый поломанный за 7 шагов.
А в гит это сделать еще проще, потому что есть готовая команда
1️⃣ Стартуем через
2️⃣ Указываем границы поиска - хороший и плохой коммиты:
3️⃣ Затем
4️⃣ В конце поиска мы увидем следующее сообщение:
Если нужно выйти из процесса поиска заранее, то используем
Приятно, когда такой повседневный рабочий инструмент, как
Скорейшего поиска “сломанных” коммитов 🚀
До связи 🤘
Обычно для исправления бага очень бы хотелось знать, в каком конкретно коммите он впервые появился… Но коммитов с последней работающей версии может быть запушено очень много! Как же найти коммит, который всё сломал??? 🤯
На первый взгляд кажется вполне логичным проверить все коммиты, начиная с конца - и нужный коммит мы не пропустим! Но и время можно убить за этой процедурой предостаточно⏳
В терминах алгоритмов, такой поиск называется линейным, и он действительно не отличается скоростью 🐢🐢🐢 А вот бинарный поиск справится намного быстрее! В общем случае он применяется для поиска по отсорированному массиву и обладает логарифмической сложностью. В нашем же случае можно считать, что коммиты отсортированы по признаку сломанности - сначала все несломанные коммиты, потом сломанные. С помощью такого подхода среди 100 коммитов можно найти первый поломанный за 7 шагов.
А в гит это сделать еще проще, потому что есть готовая команда
git bisect . Давайте разберемся с ней по шагам.1️⃣ Стартуем через
git bisect start2️⃣ Указываем границы поиска - хороший и плохой коммиты:
git bisect good <commit_hash>
git bisect bad <commit_hash>
3️⃣ Затем
git bisect переключит репозиторий на коммит, который находится посередине. Вам остается проверить повторяется ли баг или нет и указать это через git bisect good или git bisect bad. Под капотом гит поменяет границы поиска и опять запустит шаг №34️⃣ В конце поиска мы увидем следующее сообщение:
<commit_hash> is the first bad commit
Если нужно выйти из процесса поиска заранее, то используем
git bisect reset .Приятно, когда такой повседневный рабочий инструмент, как
git, способен удивить какой-то дополнительной полезной функцией!Скорейшего поиска “сломанных” коммитов 🚀
До связи 🤘
Эволюция сделала полный круг или htmlX
Не так давно натолкнулся на проект, который пытается подойти к снаряду веб-разработки и HTML еще раз. Создатели обещает то ли сделать HTML "Great Again", то ли наконец-то подарить разработчикам "настоящий" hypertext или как минимум html eXtended.
Но давайте посмотрим на многострадальный язык разметки HTML с исторической перспективы. Крупными мазками я выделяю следующие этапы:
- сначала был просто HTML
- потом HTML генерировали с помощью PHP на сервере (html внутри php на сервере)
- затем случился web 2.0, single page applications и html собирался силами первых клиентских MVC-фреймворков, jQuery и шаблонизаторов (сервер стал отдавать на клиент JSON вместо HTML)
- потом многие стали писать почти-html с помощью React (html внутри js на клиенте)
- затем js начал добираться до серверов в виде Node.js и уже появился Server Side Rendering. HTML стал генерироваться на сервере опять, но уже с помощью большой клиентской тройки Angular, React & Vue (html внутри js на сервере)
И вот тут на сцену выходит проект https://htmx.org/ (более 34 тысяч звезд на Github). Создателям хочется, чтобы web-страницы оставались живыми и интерактивными, но с меньшим количеством js-кода и без всяких модных фреймворков. И это не пустые слова. HTMLX позволяет на уровне разметки пользоваться такими штуками, как AJAX, CSS Transitions и даже WebSocket. И что же получается?
Читаем: "По клику на
Выглядит ли это, как предложение для ребят из 2000-ых сдуть пыль с клавиатуры, запустить сервачек на каком-нибудь не-js языке, смахнуть ностальгическую слезу по jQuery и пуститься во все тяжкие “настоящего” hypertext? Очень возможно! 😁
Прикольно ли это трогать, запускать на этом прототипы? Определенно 😊
А вот выгоднее ли это в долгосрочной перспективе, чем использовать тот же Next.js и все прелести клиентской разработки на React плюс серверный рендеринг? Уже далеко не так очевидно 🤔
Будущее не предопределено и возможно именно такие инструменты займут нишу, например, быстрого создания лендингов. А ведь там до сих пор можно встретить jQuery!
Не бойтесь пробовать что-то новое и до связи 🤘
Не так давно натолкнулся на проект, который пытается подойти к снаряду веб-разработки и HTML еще раз. Создатели обещает то ли сделать HTML "Great Again", то ли наконец-то подарить разработчикам "настоящий" hypertext или как минимум html eXtended.
Но давайте посмотрим на многострадальный язык разметки HTML с исторической перспективы. Крупными мазками я выделяю следующие этапы:
- сначала был просто HTML
- потом HTML генерировали с помощью PHP на сервере (html внутри php на сервере)
- затем случился web 2.0, single page applications и html собирался силами первых клиентских MVC-фреймворков, jQuery и шаблонизаторов (сервер стал отдавать на клиент JSON вместо HTML)
- потом многие стали писать почти-html с помощью React (html внутри js на клиенте)
- затем js начал добираться до серверов в виде Node.js и уже появился Server Side Rendering. HTML стал генерироваться на сервере опять, но уже с помощью большой клиентской тройки Angular, React & Vue (html внутри js на сервере)
И вот тут на сцену выходит проект https://htmx.org/ (более 34 тысяч звезд на Github). Создателям хочется, чтобы web-страницы оставались живыми и интерактивными, но с меньшим количеством js-кода и без всяких модных фреймворков. И это не пустые слова. HTMLX позволяет на уровне разметки пользоваться такими штуками, как AJAX, CSS Transitions и даже WebSocket. И что же получается?
<button
hx-trigger="click"
hx-get="/api/data"
hx-target="#result"
>Загрузить данные</button>
<div id="result"></div>
Читаем: "По клику на
button сделать GET-запрос на /api/data и ответ отрендерить в элемент c идентификатором result". Все логично.Выглядит ли это, как предложение для ребят из 2000-ых сдуть пыль с клавиатуры, запустить сервачек на каком-нибудь не-js языке, смахнуть ностальгическую слезу по jQuery и пуститься во все тяжкие “настоящего” hypertext? Очень возможно! 😁
Прикольно ли это трогать, запускать на этом прототипы? Определенно 😊
А вот выгоднее ли это в долгосрочной перспективе, чем использовать тот же Next.js и все прелести клиентской разработки на React плюс серверный рендеринг? Уже далеко не так очевидно 🤔
Будущее не предопределено и возможно именно такие инструменты займут нишу, например, быстрого создания лендингов. А ведь там до сих пор можно встретить jQuery!
Не бойтесь пробовать что-то новое и до связи 🤘
Нейронки на расстоянии вытянутой руки 🦾
Продолжаю изучать, чем же современные ИИшки могут помогать в разработке на ежедневной основе. И как раз мне подкинули ссылочку на интересный проект - https://www.machinet.net/
Я попробовал их продукт под названием Mate. Как это все устроено? Устанавливается отдельная апка (не веб), затем ему можно выдать доступ на папку проекта (или несколько проектов), нейронка производит анализ содержимого, выводит отчёт о проекте, а дальше готова выполнять задания 😱
Уже анализ и отчет заслуживает внимания. Для Node.js проекта Mate не просто банально перечисляет зависимости пакетного менеджера, но и рассказывает с какими внешними сервисами происходит интеграция, какие у вашего сервиса http ендпоинты и для чего нужны, какие базы данных используются. Если попросить дополнительно, то эта штука вполне справляется с ER-диаграммами для таблиц из бд.
Был реально в шоке, когда Mate расписал основные флоу работы приложения, то есть запрос A приводит к созданию бекграунд джоб B, которые ходят во внешний сервис C и результаты пишутся в табличку D. Здесь закралась мысль, что если не писать код, так писать документацию эта штука точно может помочь ✍
На этом пока все. Об опыте написания кода с Mate напишу чуть позже.
До связи 🤟
Продолжаю изучать, чем же современные ИИшки могут помогать в разработке на ежедневной основе. И как раз мне подкинули ссылочку на интересный проект - https://www.machinet.net/
Я попробовал их продукт под названием Mate. Как это все устроено? Устанавливается отдельная апка (не веб), затем ему можно выдать доступ на папку проекта (или несколько проектов), нейронка производит анализ содержимого, выводит отчёт о проекте, а дальше готова выполнять задания 😱
Уже анализ и отчет заслуживает внимания. Для Node.js проекта Mate не просто банально перечисляет зависимости пакетного менеджера, но и рассказывает с какими внешними сервисами происходит интеграция, какие у вашего сервиса http ендпоинты и для чего нужны, какие базы данных используются. Если попросить дополнительно, то эта штука вполне справляется с ER-диаграммами для таблиц из бд.
Был реально в шоке, когда Mate расписал основные флоу работы приложения, то есть запрос A приводит к созданию бекграунд джоб B, которые ходят во внешний сервис C и результаты пишутся в табличку D. Здесь закралась мысль, что если не писать код, так писать документацию эта штука точно может помочь ✍
На этом пока все. Об опыте написания кода с Mate напишу чуть позже.
До связи 🤟
www.machinet.net
Machinet - AI Agent for Full-Stack Software Developers
Stay in flow using one AI assistant across all your tools. Use an AI SWE agent to solve your tasks and get an additional pair of eyes on your repo. Mate works with any programming language and tools. Install now.
Хандра 😑
Болею вторую неделю какой-то неведомой фигней с глубоким кашлем, температурой и прочими радостями жизни. За окном льет как из ведра. Если бы еще на продакшене что-то развалилось, то было бы совсем грустно.
В любом случае вышеописанная картинка не очень похожа на лучезарное и беззаботное лето, к которому мы привыкли со времен нашего детства ☀️
Зато такое овощное состояние помогает ненадолго выйти из айтишного круговорота и немного вдохнуть новых красок:
📖 Начал читать книжечку "Атомные привычки" (пока не вау, но занятно)
📺 4 сезон сериала The Boys (с нетерпением уже жду 5ый)
🍲 Доставка готовых рационов питания - удобно, вкусно (для неприхотливых, как я) и калории все учтены
Но лучше не болеть, так что не загоняйте себя, давайте организму передышку.
Всем продуктивной рабочей недели!
До связи 🤟
Болею вторую неделю какой-то неведомой фигней с глубоким кашлем, температурой и прочими радостями жизни. За окном льет как из ведра. Если бы еще на продакшене что-то развалилось, то было бы совсем грустно.
В любом случае вышеописанная картинка не очень похожа на лучезарное и беззаботное лето, к которому мы привыкли со времен нашего детства ☀️
Зато такое овощное состояние помогает ненадолго выйти из айтишного круговорота и немного вдохнуть новых красок:
📖 Начал читать книжечку "Атомные привычки" (пока не вау, но занятно)
📺 4 сезон сериала The Boys (с нетерпением уже жду 5ый)
🍲 Доставка готовых рационов питания - удобно, вкусно (для неприхотливых, как я) и калории все учтены
Но лучше не болеть, так что не загоняйте себя, давайте организму передышку.
Всем продуктивной рабочей недели!
До связи 🤟
Python с JIT и настоящим параллелизмом
Этой осенью выйдет финальный релиз Python 3.13.
И он несёт в себе сразу две гигантские истории, о которых спорили многие годы, которые ждали десятилетия 🧙♂
В питон (здесь мы имеем ввиду реализацию именно CPython) наконец-то завезли встроенный JIT - just-in-time компилятор. Теперь наиболее востребованные участки кода могут компилироваться в машинный код под конкретную платформу и исполняться быстрее. Пока JIT не включен по умолчанию и требует специальной сборки питон и запуска с флагом
Параллелизм - как много в этом слове 🚀 В питоне истинному параллельному исполнению кода (не путать с асинхронностью) в рамках разных потоков одного процесса всегда мешал GIL. Этот global interpreter lock даёт исполнять код только одному потоку, сколько бы у вас их не было. В версии 3.13 появляется возможность отключить GIL и больше никто не будет блокировать ваши многопоточные приложения. Опять таки изменение уж больно глобальное и включается не по умолчанию, а через отдельный бинарник -
Первый релиз кандидат Python 3.13 вышел уже 1 августа, так что можно пробовать и экспериментировать.
О других немаловажных изменениях можно почитать в Python 3.13 changelog.
До связи 🤟
Этой осенью выйдет финальный релиз Python 3.13.
И он несёт в себе сразу две гигантские истории, о которых спорили многие годы, которые ждали десятилетия 🧙♂
В питон (здесь мы имеем ввиду реализацию именно CPython) наконец-то завезли встроенный JIT - just-in-time компилятор. Теперь наиболее востребованные участки кода могут компилироваться в машинный код под конкретную платформу и исполняться быстрее. Пока JIT не включен по умолчанию и требует специальной сборки питон и запуска с флагом
--enable-experimental-jit. Разработчики говорят, что ещё есть какие-то минорные баги и прирост скорости не вау, но это первый шаг - в следующих версиях станет лучше.Параллелизм - как много в этом слове 🚀 В питоне истинному параллельному исполнению кода (не путать с асинхронностью) в рамках разных потоков одного процесса всегда мешал GIL. Этот global interpreter lock даёт исполнять код только одному потоку, сколько бы у вас их не было. В версии 3.13 появляется возможность отключить GIL и больше никто не будет блокировать ваши многопоточные приложения. Опять таки изменение уж больно глобальное и включается не по умолчанию, а через отдельный бинарник -
python3.13t.Первый релиз кандидат Python 3.13 вышел уже 1 августа, так что можно пробовать и экспериментировать.
О других немаловажных изменениях можно почитать в Python 3.13 changelog.
До связи 🤟
Библиотека компонентов Mantine
Давно ничего из мира Frontend не обсуждали, а давайте сегодня ✊
Обычно, интерфейс хочется собирать уже на базе готовой библиотеки компонентов. И лучше бы она была с тысячами или десятками тысяч звезд на Github, проверена временем и отлажене на множестве проектов.
У всех в голове всплывает свой набор таких либ. У меня для React в голове возникают гиганты типа Material UI и Ant Design. Но не так давно я случайно наткнулся на Mantine.
Мне сразу приглянулся визуальный стиль - смотрю дальше 👀
Под капотом TypeScript 🦾, css-modules, активно используются CSS variables. Проект разбит на core и дополнительные пакеты - устанавливать можно только то, что действительно юзается в проекте.
Что еще есть - да почти все:
- темная / светлая тема и тотальная кастомизация цветов и темы в целом
- более обычных 100 компонент (кнопки, инпуты, селекты, слайдеры, табы, модалки и т.д.)
- Mantine UI - более 100 высокоуровневых компонент для быстрой сборки сайтов (карточки, карусели, готовые секции страниц, баннеры, комментарии и т.д.)
- Mantine Hooks - собственная библиотека различных хуков для реакт (use-media-query, use-clipboard и т.д.)
- Mantine Form - библиотека форм на хуках (c валидациями и прочими прелестями)
- Mantine Dates - все для работы с датами и временем на базе dayjs
- Mantine Charts - графики и диаграммы на базе recharts v2
- поддержка SSR с шаблонами для Next.js или Remix
- и даже встроенная поддержка право-левого интерфейса (RTL) есть!
Боевого опыта у меня лично или на моих проектах пока нет, но думаю, что скоро будет.
Всем быстрой верстки!
До связи 🤟
Давно ничего из мира Frontend не обсуждали, а давайте сегодня ✊
Обычно, интерфейс хочется собирать уже на базе готовой библиотеки компонентов. И лучше бы она была с тысячами или десятками тысяч звезд на Github, проверена временем и отлажене на множестве проектов.
У всех в голове всплывает свой набор таких либ. У меня для React в голове возникают гиганты типа Material UI и Ant Design. Но не так давно я случайно наткнулся на Mantine.
Мне сразу приглянулся визуальный стиль - смотрю дальше 👀
Под капотом TypeScript 🦾, css-modules, активно используются CSS variables. Проект разбит на core и дополнительные пакеты - устанавливать можно только то, что действительно юзается в проекте.
Что еще есть - да почти все:
- темная / светлая тема и тотальная кастомизация цветов и темы в целом
- более обычных 100 компонент (кнопки, инпуты, селекты, слайдеры, табы, модалки и т.д.)
- Mantine UI - более 100 высокоуровневых компонент для быстрой сборки сайтов (карточки, карусели, готовые секции страниц, баннеры, комментарии и т.д.)
- Mantine Hooks - собственная библиотека различных хуков для реакт (use-media-query, use-clipboard и т.д.)
- Mantine Form - библиотека форм на хуках (c валидациями и прочими прелестями)
- Mantine Dates - все для работы с датами и временем на базе dayjs
- Mantine Charts - графики и диаграммы на базе recharts v2
- поддержка SSR с шаблонами для Next.js или Remix
- и даже встроенная поддержка право-левого интерфейса (RTL) есть!
Боевого опыта у меня лично или на моих проектах пока нет, но думаю, что скоро будет.
Всем быстрой верстки!
До связи 🤟
Вот и прошел очередной 256-ой день в году, день программиста. Всех с праздником!
Такая молодая наша профессия уже успела внести неоценимый вклад в жизнь каждого:
🛜 Мы соединиили людей по всему миру благодаря интернету, email, соц. сетям и мессенджерам
🦾 На наших плечах зародились и выросли гигантские технологические компании, которые очень во многом определяют вектор развития всего человечества
🎮 На компьютерных играх, а так же коротких и длинных видосах выросли уже целые поколения
🧠 Наш неуёмный разум создает все более и более мощные системы ИИ, которые возможно очень скоро сыграют со всеми нами злую шутку...
Будем и дальше изменять мир к лучшем или просто творить just for fun!
До связи 🤟
Такая молодая наша профессия уже успела внести неоценимый вклад в жизнь каждого:
🛜 Мы соединиили людей по всему миру благодаря интернету, email, соц. сетям и мессенджерам
🦾 На наших плечах зародились и выросли гигантские технологические компании, которые очень во многом определяют вектор развития всего человечества
🎮 На компьютерных играх, а так же коротких и длинных видосах выросли уже целые поколения
🧠 Наш неуёмный разум создает все более и более мощные системы ИИ, которые возможно очень скоро сыграют со всеми нами злую шутку...
Будем и дальше изменять мир к лучшем или просто творить just for fun!
До связи 🤟
Продолжаем активно искать к нам в команду толковых ребят с глубокими знаниями TypeScript и Node.js. Все основное под капотом собрано на картинке 👀
Вооружившись этим арсеналом, а так же слабоумием и отвагой разрабатываем суперапп для рынка Кафе & Ресторанов!
Подробнее на HH:
https://hh.ru/vacancy/106348216
Если интересно, то можно написать мне в личку - @a_s_rusakov.
До связи 🤟
Вооружившись этим арсеналом, а так же слабоумием и отвагой разрабатываем суперапп для рынка Кафе & Ресторанов!
Подробнее на HH:
https://hh.ru/vacancy/106348216
Если интересно, то можно написать мне в личку - @a_s_rusakov.
До связи 🤟
Пагинация - основные способы и подводные камни
Пагинация — это метод разделения большого набора данных на порции. С точки зрения Frontend это всего лишь способ постранично вывести информацию. С точки зрения Backend пагинация скорее обязательна к использованию. Вместо передачи всего набора данных, сервер отправляет только малую часть, снижая нагрузку на БД и сеть, а так же улучшая общую пропускную способность и время отклика.
Если говорить о реализации, то выделяются 2 базовых способа:
1️⃣ Limit + Offset. Это самый распространенный метод пагинации, где используются параметры LIMIT и OFFSET из SQL-запросов (или аналоги из NoSQL БД). Например,
2️⃣ Курсорная пагинация, в которой обычно используется уникальный идентификатор последней полученной записи (курсор). Например, если сообщения в чате имеют строго возрастающие id, то запрос следующей порции сообщений получается через фильтрацию по id больше последнего загруженного (или меньше). Такой способ не начинает тормозить про отдаче 100500-ой страницы, а также стабильнее работает при частом создании/удалении данных.
Но дьявол кроется в деталях:
❗️При любом типе пагинации нельзя забывать про ограничения и дефолтное значение для параметра LIMIT. Без указания LIMIT многие БД будут отдавать все доступные данные... Чего вы явно не планируете для реально больших табличек 🤯
❗️Нельзя забывать про индексы в БД. Без индексов какую пагинацию не делай, а фильтрация и/или сортировка убьет любую скорость.
Используйте проверенные практики при реализации пагинации 🙏
До связи 🤟
Пагинация — это метод разделения большого набора данных на порции. С точки зрения Frontend это всего лишь способ постранично вывести информацию. С точки зрения Backend пагинация скорее обязательна к использованию. Вместо передачи всего набора данных, сервер отправляет только малую часть, снижая нагрузку на БД и сеть, а так же улучшая общую пропускную способность и время отклика.
Если говорить о реализации, то выделяются 2 базовых способа:
1️⃣ Limit + Offset. Это самый распространенный метод пагинации, где используются параметры LIMIT и OFFSET из SQL-запросов (или аналоги из NoSQL БД). Например,
SELECT * FROM users LIMIT 10 OFFSET 20 вернет 10 записей, начиная с 21-й. Этот подход очень прост в реализации. Основными недостатками являются: стремительное увеличение времени ответа с возрастание OFFSET и дублирование/пропуск части данных при их частом добавлении/удалении.2️⃣ Курсорная пагинация, в которой обычно используется уникальный идентификатор последней полученной записи (курсор). Например, если сообщения в чате имеют строго возрастающие id, то запрос следующей порции сообщений получается через фильтрацию по id больше последнего загруженного (или меньше). Такой способ не начинает тормозить про отдаче 100500-ой страницы, а также стабильнее работает при частом создании/удалении данных.
Но дьявол кроется в деталях:
❗️При любом типе пагинации нельзя забывать про ограничения и дефолтное значение для параметра LIMIT. Без указания LIMIT многие БД будут отдавать все доступные данные... Чего вы явно не планируете для реально больших табличек 🤯
❗️Нельзя забывать про индексы в БД. Без индексов какую пагинацию не делай, а фильтрация и/или сортировка убьет любую скорость.
Используйте проверенные практики при реализации пагинации 🙏
До связи 🤟
Создатель Redis возвращется в проект!
Выложил на хабре перевод поста из блога Сальваторе Санфилиппо (оригинального автора in-memory db Redis). После 4.5 лет отсутствия Сальваторе решил вернуться к своему детищу и рассуждает о проблемах лицензирования, расколе в сообществе редис, нейронных сетят и LLM, RAG и векторном поиске и, конечно, о том, чем бы он мог быть полезен комьюнити и проекту в целом.
https://habr.com/ru/articles/878184/
Приятного чтения 😊
Выложил на хабре перевод поста из блога Сальваторе Санфилиппо (оригинального автора in-memory db Redis). После 4.5 лет отсутствия Сальваторе решил вернуться к своему детищу и рассуждает о проблемах лицензирования, расколе в сообществе редис, нейронных сетят и LLM, RAG и векторном поиске и, конечно, о том, чем бы он мог быть полезен комьюнити и проекту в целом.
https://habr.com/ru/articles/878184/
Приятного чтения 😊
Хабр
Сальваторе Санфилиппо возвращается в Redis
С того места, где я остановился… Я не из тех, кто сильно привязывается к своим собственным проектам. Когда я решил уйти из Redis, это было примерно 1620 дней назад (около 4,44 года), я напрочь...
Переходим на Redis v8.0
Кажется, это первый за многие годы значимый релиз редиски! И вот почему:
История с лицензированием завершилась возвращением к "нормальной" Open Source лицензии - AGPLv3.
Команда проделала большую работу по оптимизации. Подробнее читайте у них в блоге, но ускорены как конкретные операции, так и общий latency снижен, общая пропускная способность увеличена. В общем чудо, бесплатное ускорение всем и каждому.
Наконец-то самые популярные доп. модули - такие как Search, Json, Bloom Filter - поставляются вместе с редисом из коробки. Это явный сдвиг парадигмы, в сторону более удобного и зрелого решения в духе "batteries included".
До связи 🤟
Кажется, это первый за многие годы значимый релиз редиски! И вот почему:
История с лицензированием завершилась возвращением к "нормальной" Open Source лицензии - AGPLv3.
Команда проделала большую работу по оптимизации. Подробнее читайте у них в блоге, но ускорены как конкретные операции, так и общий latency снижен, общая пропускная способность увеличена. В общем чудо, бесплатное ускорение всем и каждому.
Наконец-то самые популярные доп. модули - такие как Search, Json, Bloom Filter - поставляются вместе с редисом из коробки. Это явный сдвиг парадигмы, в сторону более удобного и зрелого решения в духе "batteries included".
До связи 🤟