Must have технологии: react-admin
При разработке проектов обычно возникает момент, когда необходимо создать административную панель управления данными. Она должна обеспечивать базовые операции CRUD (Create, Read, Update, Delete) и не требуют сложных дизайнерских решений, но при этом время на разработку съедает неадекватно (даже если собирать из говна и палок). Стоит ли писать кастомные админки? 🤔
Я думаю нет, ведь есть замечательный react-admin (https://marmelab.com/react-admin/) - фреймворк для написания унифицированных административных панелей. С одной стороны структуру приложения диктует фреймворк (она скорее всего подойдет и вам - она всем подходит 😆). С другой стороны - предоставляет широкий набор готовых компонентов для декларативного описания интерфейса (от
Какие моменты еще стоит отметить:
- Более 22 тысяч звезд на Github, более 55 тысяч скачиваний с npm за неделю
- Имеет провайдеры к различным популярным бекендам (REST, JSON API, GraphQL и другие). Есть достаточно простой гайд по написанию провайдера именно к собственному бекенду.
- Смотреть на такие админки приятно - это Material Design
- Предоставляет готовые решения в области авторизации и разграничении доступа, роутинга, интернализации, различным темам оформления
- Есть Enterprise Edition, в рамках которого можно получить еще больше сложных компонент, ролевую систему доступа (RBAC), упрощение работы с древовидными структурами данных, поддержку RealTime и много других плюшек
Жизнь слишком коротка, чтобы писать еще одну типовую админку. Воспользуйтесь react-admin.
До связи 🤘
При разработке проектов обычно возникает момент, когда необходимо создать административную панель управления данными. Она должна обеспечивать базовые операции CRUD (Create, Read, Update, Delete) и не требуют сложных дизайнерских решений, но при этом время на разработку съедает неадекватно (даже если собирать из говна и палок). Стоит ли писать кастомные админки? 🤔
Я думаю нет, ведь есть замечательный react-admin (https://marmelab.com/react-admin/) - фреймворк для написания унифицированных административных панелей. С одной стороны структуру приложения диктует фреймворк (она скорее всего подойдет и вам - она всем подходит 😆). С другой стороны - предоставляет широкий набор готовых компонентов для декларативного описания интерфейса (от
<TextInput> до `<DataGrid>`), но можно использовать и кастомные.Какие моменты еще стоит отметить:
- Более 22 тысяч звезд на Github, более 55 тысяч скачиваний с npm за неделю
- Имеет провайдеры к различным популярным бекендам (REST, JSON API, GraphQL и другие). Есть достаточно простой гайд по написанию провайдера именно к собственному бекенду.
- Смотреть на такие админки приятно - это Material Design
- Предоставляет готовые решения в области авторизации и разграничении доступа, роутинга, интернализации, различным темам оформления
- Есть Enterprise Edition, в рамках которого можно получить еще больше сложных компонент, ролевую систему доступа (RBAC), упрощение работы с древовидными структурами данных, поддержку RealTime и много других плюшек
Жизнь слишком коротка, чтобы писать еще одну типовую админку. Воспользуйтесь react-admin.
До связи 🤘
Marmelab
React Admin
A frontend Framework for building B2B applications running in the browser on top of REST/GraphQL APIs, using ES6, React and Material Design
👍8
Инструменты разработчика: RegExp
Регулярные выражения — это мощный инструмент для обработки текстовых данных. В программирование они пришли из математических теорий, таких как формальные языки 🤯, в середине XX века. Но настоящее признание этот инструмент получил ближе к 1970-ым годам, когда регулярные выражения были массово встроены в различные утилиты UNIX, например, awk или grep.
Основные сценарии использования в повседневной разработке следующие:
- Поиск подстрок или паттернов в тексте. Например, можно найти все цифры
- Замена подстрок или паттернов другими данными. Можно найти и убрать знаки препинания
- Разделение текста на части на основе определенных правил. Делим строчку на слова по всевозможным пробельным сиволам
- Валидация данных. Регулярные выражения могут быть использованы для проверки, соответствует ли введенная пользователем информация определенному формату. Например,
Первоначальное погружение в специальный язык регулярных выражений может отпугнуть: кривая обучения скорее крутая, чем пологая. Но с другой стороны освоив RegExp один раз его можно применять в любом современном языке программирования на протяжении всей карьеры.
✅ Так же помогает писать и понимать регулярные выражения возможность визуализации и быстрой проверки. Я использую https://regex101.com/, но возможно есть что-то и получше.
До связи 🤘
Регулярные выражения — это мощный инструмент для обработки текстовых данных. В программирование они пришли из математических теорий, таких как формальные языки 🤯, в середине XX века. Но настоящее признание этот инструмент получил ближе к 1970-ым годам, когда регулярные выражения были массово встроены в различные утилиты UNIX, например, awk или grep.
Основные сценарии использования в повседневной разработке следующие:
- Поиск подстрок или паттернов в тексте. Например, можно найти все цифры
\d+ или символы английского алфавита [a-z]+ в исходной строке- Замена подстрок или паттернов другими данными. Можно найти и убрать знаки препинания
[\.,-;:!?]+ из оригинального текста- Разделение текста на части на основе определенных правил. Делим строчку на слова по всевозможным пробельным сиволам
\s+- Валидация данных. Регулярные выражения могут быть использованы для проверки, соответствует ли введенная пользователем информация определенному формату. Например,
^\d{4}-\d{2}-\d{2}$ проверит, соответствует ли строка формату ГГГГ-ММ-ДДПервоначальное погружение в специальный язык регулярных выражений может отпугнуть: кривая обучения скорее крутая, чем пологая. Но с другой стороны освоив RegExp один раз его можно применять в любом современном языке программирования на протяжении всей карьеры.
✅ Так же помогает писать и понимать регулярные выражения возможность визуализации и быстрой проверки. Я использую https://regex101.com/, но возможно есть что-то и получше.
До связи 🤘
regex101
regex101: build, test, and debug regex
Regular expression tester with syntax highlighting, explanation, cheat sheet for PHP/PCRE, Python, GO, JavaScript, Java, C#/.NET, Rust.
👍7
JavaScript внутри Redis
Годами для написания скриптов внутри Redis в основном использовали Lua (не самый популярный язык). Но с релизом 7.2 ситуация начинает меняться, наконец-то для написания скриптов можно использовать JavaScript. Пока доступно в режиме превью, не стабильно, но уже можно пробовать.
Что стоит отметить:
- под капотом используется свежая версия V8 (современный JS доступен!) 🚀
- js-модуль сохраняется в Redis и в режиме standalone, и в кластере на всех нодах (Redis сам следит за этим) 🧐
- обьявленные js-функции можно вызывать через
- js-функцию можно зарегистрировать в качестве триггера, который будут реагировать на все события происходящие с ключами с определенным префиксом
Предлагаю ознакомиться с более подробным анонсом на Хабре https://habr.com/ru/articles/761514/
До связи 🤘
Годами для написания скриптов внутри Redis в основном использовали Lua (не самый популярный язык). Но с релизом 7.2 ситуация начинает меняться, наконец-то для написания скриптов можно использовать JavaScript. Пока доступно в режиме превью, не стабильно, но уже можно пробовать.
Что стоит отметить:
- под капотом используется свежая версия V8 (современный JS доступен!) 🚀
- js-модуль сохраняется в Redis и в режиме standalone, и в кластере на всех нодах (Redis сам следит за этим) 🧐
- обьявленные js-функции можно вызывать через
TFCALL lib_name.func_name numkeys kyes args - js-функцию можно зарегистрировать в качестве триггера, который будут реагировать на все события происходящие с ключами с определенным префиксом
Предлагаю ознакомиться с более подробным анонсом на Хабре https://habr.com/ru/articles/761514/
До связи 🤘
Хабр
JavaScript триггеры и функции появились в Redis 7.2
Как правило, приложения обрабатывают операции бизнес-логики, отправляя код для выполнения в базу данных. Это медленный процесс, поскольку код передается от клиента на сервер каждый раз, когда...
👍7
Факапы и что делать дальше?
В жизни каждого из нас бывают моменты, когда не всё идет по плану 🤯. Это могут быть плохие релизы, несоблюдение сроков, ошибки в принятии решений и так далее. Факапы - неотъемлемая часть любой деятельности. И, что важно понимать, это нормально. Мы не роботы, и совершать ошибки - часть процесса саморазвития и профессионального роста.
После того как мы пережили самый напряженный период необходимо уделить время на восстановление. Неважно, насколько серьезным был факап, всегда наступает момент, когда мы должны быть готовы к новым вызовам. Но чтобы эффективно двигаться дальше, нужно позаботиться о себе.
Важно дать своему организму возможность восстановиться после стресса. Иногда этим может быть день отдыха 🧘♂️, когда вы просто расслабляетесь и забываете о проблемах. Для других это может быть спортивный зал 🏋️, где физическая активность помогает очистить ум от негативных мыслей. Иногда это просто несколько часов в уединении с хорошей книгой или фильмом 📺.
Самое главное - найти способ, какой бы он ни был, чтобы перезагрузиться и отпустить негативные эмоции. Нет универсального совета, важно найти то, что работает именно для вас.
P.S. В четверг был очень тяжелый релиз. Была потрачена куча времени на подготовку, но все равно очень многое пошло не так 😩
В пятницу не работал, посмотрел тупейший "Отряд самоубийц 2", лег рано спать. Суббота уже прошла нормально.
Падаем, но поднимаемся! До связи 🤘
В жизни каждого из нас бывают моменты, когда не всё идет по плану 🤯. Это могут быть плохие релизы, несоблюдение сроков, ошибки в принятии решений и так далее. Факапы - неотъемлемая часть любой деятельности. И, что важно понимать, это нормально. Мы не роботы, и совершать ошибки - часть процесса саморазвития и профессионального роста.
После того как мы пережили самый напряженный период необходимо уделить время на восстановление. Неважно, насколько серьезным был факап, всегда наступает момент, когда мы должны быть готовы к новым вызовам. Но чтобы эффективно двигаться дальше, нужно позаботиться о себе.
Важно дать своему организму возможность восстановиться после стресса. Иногда этим может быть день отдыха 🧘♂️, когда вы просто расслабляетесь и забываете о проблемах. Для других это может быть спортивный зал 🏋️, где физическая активность помогает очистить ум от негативных мыслей. Иногда это просто несколько часов в уединении с хорошей книгой или фильмом 📺.
Самое главное - найти способ, какой бы он ни был, чтобы перезагрузиться и отпустить негативные эмоции. Нет универсального совета, важно найти то, что работает именно для вас.
P.S. В четверг был очень тяжелый релиз. Была потрачена куча времени на подготовку, но все равно очень многое пошло не так 😩
В пятницу не работал, посмотрел тупейший "Отряд самоубийц 2", лег рано спать. Суббота уже прошла нормально.
Падаем, но поднимаемся! До связи 🤘
👍7
Алгоритмы сжатия и gzip
Быстрая современная передача информации по проводным или беспроводным сетям была бы невозможна без алгоритмов сжатия. Ведь универсальный способ увеличить скорость доставки - это уменьшение объема. Неотъемлемой частью современной веб-разработки и обработки данных стал
Первый публичный релиз Gzip состоялся в 1992 году, а в 1993 была выпущена версию 1.0. Gzip не является алгоритмом как таковым, а в первую очередь является форматом данных и программным обеспечением для хранения (обычно `.gz`) и сжатия. Под капотом gzip использует алгоритм сжатия без потерь Deflate, который является универсальным алгоритмом и, например, применяется для сжатия изображений в формате PNG.
Deflate в свою очередь является комбинацией из двух наиболее успешных и достаточно древних алгоритмов сжатия без потерь, которые используют разные подходы: LZ77 (1977 г.) и кодирование Хаффмана (1952 г.). LZ77 находит повторяющиеся последовательности байт и заменяет их на указатели на первое вхождение. Кодирование Хаффмана осуществляется путем частотного анализа - чем чаще последовательность кодов встречается, тем в более короткий код на выходе она преобразуется.
В мире Unix для работы с gzip можно использовать следующие утилиты:
Используйте gzip и не забывайте сжимать данные на створе веб-сервера перед отправкой вашим клиентам.
До связи 🤘
Быстрая современная передача информации по проводным или беспроводным сетям была бы невозможна без алгоритмов сжатия. Ведь универсальный способ увеличить скорость доставки - это уменьшение объема. Неотъемлемой частью современной веб-разработки и обработки данных стал
gzip. Скорее всего каждый сайт открытый в вашем браузере так или иначе использует Content-Encoding: gzip. Давате немного разберемся.Первый публичный релиз Gzip состоялся в 1992 году, а в 1993 была выпущена версию 1.0. Gzip не является алгоритмом как таковым, а в первую очередь является форматом данных и программным обеспечением для хранения (обычно `.gz`) и сжатия. Под капотом gzip использует алгоритм сжатия без потерь Deflate, который является универсальным алгоритмом и, например, применяется для сжатия изображений в формате PNG.
Deflate в свою очередь является комбинацией из двух наиболее успешных и достаточно древних алгоритмов сжатия без потерь, которые используют разные подходы: LZ77 (1977 г.) и кодирование Хаффмана (1952 г.). LZ77 находит повторяющиеся последовательности байт и заменяет их на указатели на первое вхождение. Кодирование Хаффмана осуществляется путем частотного анализа - чем чаще последовательность кодов встречается, тем в более короткий код на выходе она преобразуется.
В мире Unix для работы с gzip можно использовать следующие утилиты:
gzip - собственно сжимает файл или поток данных (для сжатия нескольких файлов используется в паре с утилитой tar)gunzip - распаковка .gz файловzcat - для чтения сжатых файлов без их распаковки (например, можно просматривать сжатые логи веб-сервера)Используйте gzip и не забывайте сжимать данные на створе веб-сервера перед отправкой вашим клиентам.
До связи 🤘
👍5🔥1
Бинарный поиск или Binary search
Представьте себе задачу: вам нужно найти позицию определенного значения в массиве. 🤔
Наивное решение задачи сводится к вызову функции типа
Алгоритм бинарного поиска поможет вам справиться с этой задачей за логарифмическое время! Принцип работы очень прост:
1. Находим средний элемент в отсортированном массиве
2. Сравниваем его с искомым значением. Если они совпали, значит задача выполнена
3. Если значение в среднем элементе больше искомого, то искомое значение находится слева от среднего элемента, и мы продолжаем поиск в левой половине массива.
4. Если значение меньше искомого, то продолжаем поиск в правой половине массива.
5. Возвращается к пункту 1 и так, пока не найдем элемент.
✅ Деление исходных данных пополам на каждом шаге и приводить нас в логарифмической оценке временной сложности алгоритма.
Бинарный поиск пользуется популярностью и входит в стандартные библиотеки С/C++, Java, Python, Go, .NET.
Эффективного поиска и до связи 🤘
Представьте себе задачу: вам нужно найти позицию определенного значения в массиве. 🤔
Наивное решение задачи сводится к вызову функции типа
indexOf(...), и в таком случае поиск занимает линейное время. Но что если данные отсортированы и нам хочется осуществить поиск как можно быстрее?Алгоритм бинарного поиска поможет вам справиться с этой задачей за логарифмическое время! Принцип работы очень прост:
1. Находим средний элемент в отсортированном массиве
2. Сравниваем его с искомым значением. Если они совпали, значит задача выполнена
3. Если значение в среднем элементе больше искомого, то искомое значение находится слева от среднего элемента, и мы продолжаем поиск в левой половине массива.
4. Если значение меньше искомого, то продолжаем поиск в правой половине массива.
5. Возвращается к пункту 1 и так, пока не найдем элемент.
✅ Деление исходных данных пополам на каждом шаге и приводить нас в логарифмической оценке временной сложности алгоритма.
Бинарный поиск пользуется популярностью и входит в стандартные библиотеки С/C++, Java, Python, Go, .NET.
Эффективного поиска и до связи 🤘
👍8
B-tree и базы данных
B-tree, несмотря на первое впечатление, это не бинарное дерево 🌲. Это сбалансированное (self-balancing) дерево поиска, где каждый узел может хранить более 1 ключа, а количество потомков может быть более 2. В такой трактовке B-tree - это обобщение бинарного дерева. Давайте теперь разберемся, что нам дают две основных части определения - дерево поиска и сбалансированное дерево.
✅ В деревьях поиска данные упорядочиваются на основе выбранной операции (обычно это операция < или “меньше”). В случае с B-tree это означает, что все ключи узла упорядочены по возрастанию, а значения в ключах левого потомка меньше, чем значения в ключах потомков правее. Зная такую структуру хранения можно, итерационно применяя операцию “меньше”, найти необходимый элемент в дереве.
✅ Сбалансированные деревья устроены таким образом, что расстояние от корня до листьев дерева (узлов без потомков) примерно равно для всех веток дерева. Обычно в реализациях B-tree оно строго одинаково для всех листьев.
Устройство ключей в B-tree и комбинация свойств выше делают такие деревья не очень глубокими. Именно поэтому в таких популярных реляционных базах данных, как PostgreSQL и MySQL, а также в различных NoSQL решениях, типа MongoDB, индексы хранятся именно в виде B-деревьев. Это обеспечивает высокую производительность 🚀 при выполнении запросов и с точным совпадением, и при поиске по диапазону, а так же для сортировки данных.
Всегда приятно знать чуть больше, когда выполняете операцию
До связи 🤘
B-tree, несмотря на первое впечатление, это не бинарное дерево 🌲. Это сбалансированное (self-balancing) дерево поиска, где каждый узел может хранить более 1 ключа, а количество потомков может быть более 2. В такой трактовке B-tree - это обобщение бинарного дерева. Давайте теперь разберемся, что нам дают две основных части определения - дерево поиска и сбалансированное дерево.
✅ В деревьях поиска данные упорядочиваются на основе выбранной операции (обычно это операция < или “меньше”). В случае с B-tree это означает, что все ключи узла упорядочены по возрастанию, а значения в ключах левого потомка меньше, чем значения в ключах потомков правее. Зная такую структуру хранения можно, итерационно применяя операцию “меньше”, найти необходимый элемент в дереве.
✅ Сбалансированные деревья устроены таким образом, что расстояние от корня до листьев дерева (узлов без потомков) примерно равно для всех веток дерева. Обычно в реализациях B-tree оно строго одинаково для всех листьев.
Устройство ключей в B-tree и комбинация свойств выше делают такие деревья не очень глубокими. Именно поэтому в таких популярных реляционных базах данных, как PostgreSQL и MySQL, а также в различных NoSQL решениях, типа MongoDB, индексы хранятся именно в виде B-деревьев. Это обеспечивает высокую производительность 🚀 при выполнении запросов и с точным совпадением, и при поиске по диапазону, а так же для сортировки данных.
Всегда приятно знать чуть больше, когда выполняете операцию
CREATE INDEX. До связи 🤘
👍8
Чем отличается HTTP/2 от HTTP/1.1
Спецификация HTTP/2 была опубликована в мае 2015, и это стало одним из важнейших шагов по улучшению производительности всего интернета за последние 10 лет. Какие же существенные отличия в сравнении с HTTP/1.1 нужно иметь ввиду:
1️⃣ Бинарный протокол. HTTP/2 использует бинарный протокол для передачи данных, в то время как HTTP/1.1 использует текстовый формат. Бинарные данные меньше по объему - скорость передачи и обработки увеличивается.
2️⃣ Мультиплексирование. В HTTP/1.1 для экономии времени на установление нового TCP-соединения (а так же SSL/TLS в случае https) использовалась техника keep-alive, чтобы слать запросы через одно соединения, но в блокирующем режиме: сначала должен прийти ответ на первый запрос, чтобы можно было отправить второй. В HTTP/2 через одно TCP-соединение можно отправлять множество запросов параллельно.
3️⃣ Приоритизация. HTTP/2 вводит приоритизацию для потоков данных. Это дает возможность клиентам (например, браузеру) более рационально использовать единое TCP-соединения. Теперь запросить все данные у сервера можно одновременно, но поступать на клиенты они будут в заранее выбранном порядке.
4️⃣ Сжатие заголовков. Кроме перехода на бинарный формат HTTP/2 может сжимать заголовки запросов и ответов с помощью специального алгоритма HPACK. Объем передаваемых данных еще меньше, скорость выше.
5️⃣ Server Push. В HTTP/2 серверу предоставляется возможность самостоятельно направить данные клиенту, как бы предугадывая его будущие потребности. Это может существенно уменьшить задержки, например, при переходе между разными страницами одного сайта.
Так же стоит отметить, что современные браузеры поддерживают HTTP/2 только поверх защищенного SSL/TLS соединения. Интернет становится еще безопаснее 🔐
Если в голых цифрах, то почти 95% пользователей интернета используют браузеры с поддержкой HTTP/2. Nginx получил поддержку в версии 1.9.5 (2015 год!). Так что если вы еще не включили для своих клиентов HTTP/2, то сделайте это прямо сейчас - нет причин откладывать!
До связи 🤘
Спецификация HTTP/2 была опубликована в мае 2015, и это стало одним из важнейших шагов по улучшению производительности всего интернета за последние 10 лет. Какие же существенные отличия в сравнении с HTTP/1.1 нужно иметь ввиду:
1️⃣ Бинарный протокол. HTTP/2 использует бинарный протокол для передачи данных, в то время как HTTP/1.1 использует текстовый формат. Бинарные данные меньше по объему - скорость передачи и обработки увеличивается.
2️⃣ Мультиплексирование. В HTTP/1.1 для экономии времени на установление нового TCP-соединения (а так же SSL/TLS в случае https) использовалась техника keep-alive, чтобы слать запросы через одно соединения, но в блокирующем режиме: сначала должен прийти ответ на первый запрос, чтобы можно было отправить второй. В HTTP/2 через одно TCP-соединение можно отправлять множество запросов параллельно.
3️⃣ Приоритизация. HTTP/2 вводит приоритизацию для потоков данных. Это дает возможность клиентам (например, браузеру) более рационально использовать единое TCP-соединения. Теперь запросить все данные у сервера можно одновременно, но поступать на клиенты они будут в заранее выбранном порядке.
4️⃣ Сжатие заголовков. Кроме перехода на бинарный формат HTTP/2 может сжимать заголовки запросов и ответов с помощью специального алгоритма HPACK. Объем передаваемых данных еще меньше, скорость выше.
5️⃣ Server Push. В HTTP/2 серверу предоставляется возможность самостоятельно направить данные клиенту, как бы предугадывая его будущие потребности. Это может существенно уменьшить задержки, например, при переходе между разными страницами одного сайта.
Так же стоит отметить, что современные браузеры поддерживают HTTP/2 только поверх защищенного SSL/TLS соединения. Интернет становится еще безопаснее 🔐
Если в голых цифрах, то почти 95% пользователей интернета используют браузеры с поддержкой HTTP/2. Nginx получил поддержку в версии 1.9.5 (2015 год!). Так что если вы еще не включили для своих клиентов HTTP/2, то сделайте это прямо сейчас - нет причин откладывать!
До связи 🤘
👍9
Принципы разработки: KISS
В мире разработки программного обеспечения существует целый ряд принципов, рекомендаций и практик, которые помогают создавать эффективные и поддерживаемые решения. Принцип KISS - “Keep It Simple, Stupid” - был сформирован еще в середине XX века и применим почти в любой сфере интеллектуальной человеческой деятельности.
Почему KISS так важен в программировании?
Простота и читаемость кода 🤓 Принцип KISS настаивает на том, что код должен быть максимально понятным для разработчиков. Простой и ясный код легче поддерживать, тестировать и масштабировать.
Нет избыточности 🎡 KISS призывает избегать не только излишней сложности в самом коде, но и в реализованной функциональности. Не стоит добавлять что-то, что не имеет прямого отношения к решению задачи. Лишние элементы только усложняют систему, могут запутать или стать причиной неочевидных багов.
Легкость в обучении и внедрении 📚 Простой код и ясная архитектура упрощают процесс передачи знаний и обучения для новых членов команды.
Соблюдение сроков 🗓️ Как правило, простой код требует меньше времени на разработку и тестирование. Простота помогает соблюсти сроки проекта.
Как говорится, простое лучше сложного! 😁
До связи 🤘
В мире разработки программного обеспечения существует целый ряд принципов, рекомендаций и практик, которые помогают создавать эффективные и поддерживаемые решения. Принцип KISS - “Keep It Simple, Stupid” - был сформирован еще в середине XX века и применим почти в любой сфере интеллектуальной человеческой деятельности.
Почему KISS так важен в программировании?
Простота и читаемость кода 🤓 Принцип KISS настаивает на том, что код должен быть максимально понятным для разработчиков. Простой и ясный код легче поддерживать, тестировать и масштабировать.
Нет избыточности 🎡 KISS призывает избегать не только излишней сложности в самом коде, но и в реализованной функциональности. Не стоит добавлять что-то, что не имеет прямого отношения к решению задачи. Лишние элементы только усложняют систему, могут запутать или стать причиной неочевидных багов.
Легкость в обучении и внедрении 📚 Простой код и ясная архитектура упрощают процесс передачи знаний и обучения для новых членов команды.
Соблюдение сроков 🗓️ Как правило, простой код требует меньше времени на разработку и тестирование. Простота помогает соблюсти сроки проекта.
Как говорится, простое лучше сложного! 😁
До связи 🤘
👍7
Что такое ORM?
ORM, или Object-Relational Mapping, представляет собой программный подход, который связывает объекты в приложении напрямую с записями в реляционной базе данных. Вместо того чтобы писать SQL-запросы вручную, разработчики могут использовать объекты и методы для выполнения типовых операций, типа SELECT, INSERT и так далее.
Давайте рассмотрим, какие преимущества и недостатки сопутствуют использованию ORM.
✅ Ускорение разработки. Использование ORM не только уменьшает количество написанного кода, если сравнивать с голым SQL, но и заметно упрощает написание однотипных выражений, типа фильтраций на больше/меньше/равно. Кроме этого все операции маппинга из БД в объекты вашего языка программирования происходят внутри ORM и для этого не нужно писать дополнительный код.
✅ Защищает от ошибок и опечаток. Если при написании SQL можно допустить ошибку в синтаксисе или вообще обратиться к несуществующей таблице, то как правило при использовании ORM это сделать значительно сложнее. В этом помогают и автоматические подсказки в IDE при вызове методов ORM, и проверки на этапе компиляции и/или статического анализа. Всё это позволяет больше сосредоточиться на бизнес-логике во время непосредственного программирования.
✅ Автоматические миграции. Многие ORM-фреймворки предоставляют механизм автоматических миграций, который позволяет управлять схемой базы данных с помощью кода. Это делает процесс обновления схемы базы данных более предсказуемым и менее подверженным ошибкам.
⛔️ Непрозрачность. При использовании ORM сложно быть до конца уверенным, как именно будет обработана конкретная конструкция под капотом и в какой SQL-запрос она будет преобразована. Это может усложнить отладку и понимание того, что происходит в базе данных.
⛔️ Потери в производительности. Часто использование ORM приводит к потере производительности из-за генерации неэффективных SQL-запросов, выборки избыточного количества полей, а также излишних преобразований, выполняемых внутри ORM.
⛔️ Невозможность написать сложный SQL-запрос. Возможности ORM по генерации SQL почти всегда ограничены и не весь доступный функционал вашей СУБД может быть отражен в синтаксисе ORM. Очень часто сложные запросы приходится писать на голом SQL, что лишает вас преимуществ работы с ORM.
Так же большинство ORM пытается обобщить работу с разными СУБД через единый интерфейс. Это с одной стороны может быть удобным, позволяет работать с разными СУБД через одну и туже известную вам ORM. С другой стороны не дает воспользоваться максимум преимуществ каждой отдельно взятой базы данных.
ORM - это мощный инструмент, который действительно упрощает и ускоряет разработку нового функционала, но не бесплатно: необходимо идти на компромисс как минимум с производительностью. В таком контексте основной задачей проектирования становится выбор частей проекта, где ORM принесет максимальную пользу.
До связи 🤘
ORM, или Object-Relational Mapping, представляет собой программный подход, который связывает объекты в приложении напрямую с записями в реляционной базе данных. Вместо того чтобы писать SQL-запросы вручную, разработчики могут использовать объекты и методы для выполнения типовых операций, типа SELECT, INSERT и так далее.
Давайте рассмотрим, какие преимущества и недостатки сопутствуют использованию ORM.
✅ Ускорение разработки. Использование ORM не только уменьшает количество написанного кода, если сравнивать с голым SQL, но и заметно упрощает написание однотипных выражений, типа фильтраций на больше/меньше/равно. Кроме этого все операции маппинга из БД в объекты вашего языка программирования происходят внутри ORM и для этого не нужно писать дополнительный код.
✅ Защищает от ошибок и опечаток. Если при написании SQL можно допустить ошибку в синтаксисе или вообще обратиться к несуществующей таблице, то как правило при использовании ORM это сделать значительно сложнее. В этом помогают и автоматические подсказки в IDE при вызове методов ORM, и проверки на этапе компиляции и/или статического анализа. Всё это позволяет больше сосредоточиться на бизнес-логике во время непосредственного программирования.
✅ Автоматические миграции. Многие ORM-фреймворки предоставляют механизм автоматических миграций, который позволяет управлять схемой базы данных с помощью кода. Это делает процесс обновления схемы базы данных более предсказуемым и менее подверженным ошибкам.
⛔️ Непрозрачность. При использовании ORM сложно быть до конца уверенным, как именно будет обработана конкретная конструкция под капотом и в какой SQL-запрос она будет преобразована. Это может усложнить отладку и понимание того, что происходит в базе данных.
⛔️ Потери в производительности. Часто использование ORM приводит к потере производительности из-за генерации неэффективных SQL-запросов, выборки избыточного количества полей, а также излишних преобразований, выполняемых внутри ORM.
⛔️ Невозможность написать сложный SQL-запрос. Возможности ORM по генерации SQL почти всегда ограничены и не весь доступный функционал вашей СУБД может быть отражен в синтаксисе ORM. Очень часто сложные запросы приходится писать на голом SQL, что лишает вас преимуществ работы с ORM.
Так же большинство ORM пытается обобщить работу с разными СУБД через единый интерфейс. Это с одной стороны может быть удобным, позволяет работать с разными СУБД через одну и туже известную вам ORM. С другой стороны не дает воспользоваться максимум преимуществ каждой отдельно взятой базы данных.
ORM - это мощный инструмент, который действительно упрощает и ускоряет разработку нового функционала, но не бесплатно: необходимо идти на компромисс как минимум с производительностью. В таком контексте основной задачей проектирования становится выбор частей проекта, где ORM принесет максимальную пользу.
До связи 🤘
👍6👎1
Null-ссылки и Null Safety
Null - это концепция, которая представляет собой ссылку на "ничто" или отсутствие значения, поэтому активно используется различными языками программирования в качестве значения по-умолчанию.
🤓 Появление null-ссылок в программировании обычно приписывают языкам из семейства ALGOL в 1960ых годах. В последствии Тони Хоар - лауреат премии Тьюринга, один из автором ALGOL и создатель “быстрой сортировки” - называл Null своей “ошибкой на миллиард долларов”. Почему же так?
🤔 Несмотря на всю простоту и вроде бы логичность концепции, Null порождает бесконечное количество ошибок при обращении к переменным, которые могут содержать в себе null в качестве значения. И действительно, какой-то полноценной защиты от таких ошибок до последнего времени не было - только вездесущие проверки
А проблема остается актуальной для широко используемых в наше время языков, таких как Java, Python, Go, C#, JavaScript.
🔒 Но не так давно на сцену вышел принцип Null Safety или Void Safety. Данный принцип строится на поддержке в языке программирования продвинутой системы типов с возможностью Union и Intersection типов. Благодаря этому типы с null и без null можно отделить друг от друга, и становится возможным провести все необходимые проверки на этапе статического анализа или компиляции и не допускать обращения к null в рантайме. Наиболее популярными языками, которые поддерживаю данную возможность, являются Rust, Kotlin, TypeScript, Swift, Dart.
Будьте внимательны при работе с null или переходите на Null Safety!
До связи 🤘
Null - это концепция, которая представляет собой ссылку на "ничто" или отсутствие значения, поэтому активно используется различными языками программирования в качестве значения по-умолчанию.
🤓 Появление null-ссылок в программировании обычно приписывают языкам из семейства ALGOL в 1960ых годах. В последствии Тони Хоар - лауреат премии Тьюринга, один из автором ALGOL и создатель “быстрой сортировки” - называл Null своей “ошибкой на миллиард долларов”. Почему же так?
🤔 Несмотря на всю простоту и вроде бы логичность концепции, Null порождает бесконечное количество ошибок при обращении к переменным, которые могут содержать в себе null в качестве значения. И действительно, какой-то полноценной защиты от таких ошибок до последнего времени не было - только вездесущие проверки
if (arg != null) и различные виды тестирования для выявления ошибок на ранних стадиях.А проблема остается актуальной для широко используемых в наше время языков, таких как Java, Python, Go, C#, JavaScript.
🔒 Но не так давно на сцену вышел принцип Null Safety или Void Safety. Данный принцип строится на поддержке в языке программирования продвинутой системы типов с возможностью Union и Intersection типов. Благодаря этому типы с null и без null можно отделить друг от друга, и становится возможным провести все необходимые проверки на этапе статического анализа или компиляции и не допускать обращения к null в рантайме. Наиболее популярными языками, которые поддерживаю данную возможность, являются Rust, Kotlin, TypeScript, Swift, Dart.
Будьте внимательны при работе с null или переходите на Null Safety!
До связи 🤘
👍6
Что такое Webhook?
Webhook — это мощный и универсальный инструмент в области веб-разработки и API. Этот механизм позволяет одному веб-приложению уведомлять другое приложение о возникновении определенного события. Уведомление обычно имеет форму HTTP-запроса, отправляемого на конкретный URL-адрес, предоставленный принимающим приложением.
Использование вебхуков в API переводит взаимодействие между сервисами на новый уровень, предоставляя возможность получать обновления в реальном времени в противовес такому методом, как переодический полинг данных на предмет наличия изменений.
С технической точки зрения при работе с вебхуками всегда встает два важных вопроса - безопасность и надежность.
🔐 URL адрес принимающей стороны должен быть доступен в интернете, поэтому необходимо дополнительно позаботиться о безопасности. Для этого можно использовать разные подходы или их комбинации: принимать запросы только с разрешенных ip-адресов, использовать длинные рандомные токены, зашитые в URL или переданные в специальном заголовке, а так же подпись запросов с помощью, например, HMAC
🦾 При разработке систем вебхуков особое внимание нужно уделить обработке ошибок и переотправке запросов для того, чтобы обеспечить надежную коммуникацию между сервисами. Если по какой-то причине запрос не доходит до принимающей стороны или его обработка завершается ошибкой, запрос должен быть отправлен повторно. Политика переотправки запросов (временные задержки, количество попыток) должна быть понятной и четко регламентированной
А вот несколько примеров it-решений на базе webhook:
- Платежные шлюзы уведомляют сайты магазинов об успешной оплате или, наоборот, отклонении платежа
- Telegram использует вебхуки для отправки обновлений ботам
- Платформы CI/CD используют webhook для отправки информации о сломанных билдах или наоборот об успешно завершенных пайплайнах
Если вы разрабатываете публичное API, то ваши пользователи будут действительно рады появлению вебхуков 😍
До связи 🤘
Webhook — это мощный и универсальный инструмент в области веб-разработки и API. Этот механизм позволяет одному веб-приложению уведомлять другое приложение о возникновении определенного события. Уведомление обычно имеет форму HTTP-запроса, отправляемого на конкретный URL-адрес, предоставленный принимающим приложением.
Использование вебхуков в API переводит взаимодействие между сервисами на новый уровень, предоставляя возможность получать обновления в реальном времени в противовес такому методом, как переодический полинг данных на предмет наличия изменений.
С технической точки зрения при работе с вебхуками всегда встает два важных вопроса - безопасность и надежность.
🔐 URL адрес принимающей стороны должен быть доступен в интернете, поэтому необходимо дополнительно позаботиться о безопасности. Для этого можно использовать разные подходы или их комбинации: принимать запросы только с разрешенных ip-адресов, использовать длинные рандомные токены, зашитые в URL или переданные в специальном заголовке, а так же подпись запросов с помощью, например, HMAC
🦾 При разработке систем вебхуков особое внимание нужно уделить обработке ошибок и переотправке запросов для того, чтобы обеспечить надежную коммуникацию между сервисами. Если по какой-то причине запрос не доходит до принимающей стороны или его обработка завершается ошибкой, запрос должен быть отправлен повторно. Политика переотправки запросов (временные задержки, количество попыток) должна быть понятной и четко регламентированной
А вот несколько примеров it-решений на базе webhook:
- Платежные шлюзы уведомляют сайты магазинов об успешной оплате или, наоборот, отклонении платежа
- Telegram использует вебхуки для отправки обновлений ботам
- Платформы CI/CD используют webhook для отправки информации о сломанных билдах или наоборот об успешно завершенных пайплайнах
Если вы разрабатываете публичное API, то ваши пользователи будут действительно рады появлению вебхуков 😍
До связи 🤘
👍7
Принципы разработки: DRY
Принцип DRY (Don't Repeat Yourself) - это один из основных принципов разработки программного обеспечения, который важен как для начинающих, так и для опытных разработчиков. Если переводить дословно, то это звучит как “Не повторяйтесь”, то есть призывает не дублировать код.
Давайте разберемся, что может дать следование принципу DRY:
✅ Переиспользование кода. Сознательное избавление от дублирования заставляет разработчика проводить более строгую декомпозицию кода на классы и/или функции для дальнейшего переиспользования.
✅ Меньше ошибок и проще поддерживать. Отсутствие дублирования так же упрощает процесс внесения исправлений, потому что не требует дополнительной работы от программиста по поддержке согласованности однотипных частей кодовой базы.
✅ Читаемость кода. Знакомство с кодом без дублирования обычно вызывает меньше вопросов при погружении для нового участника команды. Да и у старожил освежит в памяти все тонкости быстрее.
✅ Увеличение производительности. Отсутствие дублирования обычно приводит к уменьшению кодовой базы. Меньший объем кода означает более быструю загрузку и скорость выполнения приложения.
‼️ Но, к сожалению, все эти прелести мы получаем не бесплатно, а за счет больших временных затрат на проектирование и постоянный процесс декомпозиции тех участков, которые мы хотим в каком-то объеме переиспользовать, а не дублировать. Здесь важно найти золотую середину именно для вашего проекта.
До связи 🤘
Принцип DRY (Don't Repeat Yourself) - это один из основных принципов разработки программного обеспечения, который важен как для начинающих, так и для опытных разработчиков. Если переводить дословно, то это звучит как “Не повторяйтесь”, то есть призывает не дублировать код.
Давайте разберемся, что может дать следование принципу DRY:
✅ Переиспользование кода. Сознательное избавление от дублирования заставляет разработчика проводить более строгую декомпозицию кода на классы и/или функции для дальнейшего переиспользования.
✅ Меньше ошибок и проще поддерживать. Отсутствие дублирования так же упрощает процесс внесения исправлений, потому что не требует дополнительной работы от программиста по поддержке согласованности однотипных частей кодовой базы.
✅ Читаемость кода. Знакомство с кодом без дублирования обычно вызывает меньше вопросов при погружении для нового участника команды. Да и у старожил освежит в памяти все тонкости быстрее.
✅ Увеличение производительности. Отсутствие дублирования обычно приводит к уменьшению кодовой базы. Меньший объем кода означает более быструю загрузку и скорость выполнения приложения.
‼️ Но, к сожалению, все эти прелести мы получаем не бесплатно, а за счет больших временных затрат на проектирование и постоянный процесс декомпозиции тех участков, которые мы хотим в каком-то объеме переиспользовать, а не дублировать. Здесь важно найти золотую середину именно для вашего проекта.
До связи 🤘
👍9❤1
Сетевые протоколы. DNS
Первые спецификации DNS (Domain Name System) появились в 1983 году, а в 1984 г. в Беркли была написана первая реализация DNS-сервера - BIND (остается одним из самых широко используемых DNS-серверов). На базе ДНС работает весь современный интернет, так как именно эта система служит для преобразования доменных имен в IP-адреса.
Для того, чтобы домен example.com ссылался на ваш IP-адрес необходимо создать A-запись. Так же часто используется CNAME - эта запись служит для создания переадресации или псевдонима. Например, очень часто www-домены указываются именно через CNAME на оригинальный домен (без www префикса).
При работе с DNS необходимо иметь ввиду следующие моменты:
✉️ DNS неразрывно связан с электронной почтой. Именно MX запись указывает, по какому адресу расположен почтовой сервер вашего домена.
TXT записи активно используются для хранения мета-информации, например, для подтверждения владения доменом или подписи для email.
DNS-сервера используют очень агрессивное кэширование. Время жизни записей начинается как правило от 5 минут и доходит до суток и более. Это приводит к тому, что изменения распространяются по сети очень долго 🐢.
🔐 Безопасность DNS - тема, важность который с годами только растет. Здесь стоит обратить внимание на DNS-over-HTTPS надстройку, которая не только обеспечивает подлинность, но и конфиденциальность.
Если говорить про сегодняшний день, то нельзя не упомянуть разработку под названием CoreDNS (написан на Go, более 11 тысяч звезд на Github). Отличительной особенностью этого DNS-сервера является расширяемость: даже базовая функциональность реализована с помощью плагинов и вы легко можете добавить свой.
Быстрого и бесперебойного разрешения имен 🚀
До связи 🤘
Первые спецификации DNS (Domain Name System) появились в 1983 году, а в 1984 г. в Беркли была написана первая реализация DNS-сервера - BIND (остается одним из самых широко используемых DNS-серверов). На базе ДНС работает весь современный интернет, так как именно эта система служит для преобразования доменных имен в IP-адреса.
Для того, чтобы домен example.com ссылался на ваш IP-адрес необходимо создать A-запись. Так же часто используется CNAME - эта запись служит для создания переадресации или псевдонима. Например, очень часто www-домены указываются именно через CNAME на оригинальный домен (без www префикса).
При работе с DNS необходимо иметь ввиду следующие моменты:
✉️ DNS неразрывно связан с электронной почтой. Именно MX запись указывает, по какому адресу расположен почтовой сервер вашего домена.
TXT записи активно используются для хранения мета-информации, например, для подтверждения владения доменом или подписи для email.
DNS-сервера используют очень агрессивное кэширование. Время жизни записей начинается как правило от 5 минут и доходит до суток и более. Это приводит к тому, что изменения распространяются по сети очень долго 🐢.
🔐 Безопасность DNS - тема, важность который с годами только растет. Здесь стоит обратить внимание на DNS-over-HTTPS надстройку, которая не только обеспечивает подлинность, но и конфиденциальность.
Если говорить про сегодняшний день, то нельзя не упомянуть разработку под названием CoreDNS (написан на Go, более 11 тысяч звезд на Github). Отличительной особенностью этого DNS-сервера является расширяемость: даже базовая функциональность реализована с помощью плагинов и вы легко можете добавить свой.
Быстрого и бесперебойного разрешения имен 🚀
До связи 🤘
👍9
Дорогие коллеги, хочется поздравить вас с наступающим Новым Годом.
Загадывать не будем, но пусть следующий год у каждого будет успешнее и интереснее, чем предыдущий 🚀
А в планах Alex Code делиться новостям, лучшими практиками и просто полезной информации чаще, больше и круче! Не будем ограничиваться текстом - запустим видео формат 🎞
До новых встреч в 2024 году 🐲
Загадывать не будем, но пусть следующий год у каждого будет успешнее и интереснее, чем предыдущий 🚀
А в планах Alex Code делиться новостям, лучшими практиками и просто полезной информации чаще, больше и круче! Не будем ограничиваться текстом - запустим видео формат 🎞
До новых встреч в 2024 году 🐲
🔥10❤1
Какие бывают 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, тем он ниже при сортировке по возрастанию).
Пожалуй, это самые распространенные айдишники на базе чисел, которыми пользуются в реальных системах. Надеюсь, теперь есть над чем подумать и что выбрать в следующий раз.
До связи 🤘
👍7
Новый 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...
🔥7👍2👏1
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/.
Работаем дальше, до связи 🤘
👍9🔥2👏1