User
Статья написана по мотивам моего доклада на митапе. В нем я рассказываю историю того, как мы взяли и не распилили монолит на микросервисы, и что сделали вместо этого.
На тот момент наша команда работала над приложением, начало которому было положено еще в 2009 году не искушенными в архитектуре студентами. К 2018 это уже был типичный big ball of mud (большой ком грязи), или, этакий «монолит-копролит», как выразился один наш коллега. Думаю, многим знакомо.
Вы вряд ли найдете в интернете что-то про разработку ботов, кроме документаций к библиотекам, историй "как я создал такого-то бота" и туториалов вроде "как создать бота, который будет говорить hello world". При этом многие неочевидные моменты просто нигде не описаны.
Как вообще устроены боты? Как они взаимодействуют с пользователями? Что с их помощью можно реализовать, а что нельзя?
Подробный гайд о том, как работать с ботами — под катом.
Сегодня я хочу рассказать вам о нескольких CSS-свойствах и значениях, которые редко упоминаются в специальной литературе, но, на мой вгляд, представляют определенный интерес с точки зрения скорости и качества разработки веб-интерфейсов.
Многие свойства, о которых пойдет речь, являются экспериментальными. Большинство из них поддерживаются всеми современными браузерами, однако, если вы решите использовать какое-либо из названных свойств в продакшне, не поленитесь зайти на Can I use и уточнить поддержку (недавно сильно расстроился, обнаружив, что Safari не поддерживает атрибут loading="lazy").
Там, где можно обойтись сниппетом, я ограничусь кодом. Там, где потребуется визуализация, будет приведена ссылка на песочницу.
Я не стал делать примеры слишком красивыми, чтобы не затенять рассматриваемые свойства другими стилями.
Итак, вы готовы к нашему небольшому путешествию в удивительный и почти безграничный мир CSS? Тогда вперед.
Здесь вы найдете полное визуальное руководство по Grid и Flexbox.
Данная техника позволяет выравнивать элементы по горизонтали и вертикали при помощи всего лишь двух строк кода.
Липкие сессии (Sticky-session) — это особый вид балансировки нагрузки, при которой трафик поступает на один определенный сервер группы. Как правило, перед группой серверов находится балансировщик нагрузки (Nginx, HAProxy), который и устанавливает правила распределения трафика на доступные сервера.
В первой части цикла мы уже разобрали как создавать липкие сессии с помощью Nginx. Во второй части разберем создание подобной балансировки средствами Kubernetes.
Так как статьи в основном направлены на начинающих - придется коснуться основ kubernetes. Да-да, я знаю в интернете полно материала для изучения куба. Но здесь будет минимум душной теории и максимум практики. Лучше один раз развернуть тестовое приложение в кластере и понять основные принципы, чем читать тонну скучных мануалов.
Это - отдельное руководство, описывающее ещё один способ получить личный прокси-сервер shadowsocks бесплатно и служащее продолжением к моей предыдущей статье. В этот раз мы воспользуемся сервисом platform.sh.
От читателя требуется только обладание адресом электронной почты и умение залить файлы в git.
<!DOCTYPE html>
<html lang="en" class="no-js">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width">
<title>Unique page title - My Site</title>
<script type="module">
document.documentElement.classList.remove('no-js');
document.documentElement.classList.add('js');
</script>
<link rel="stylesheet" href="/assets/css/styles.css">
<link rel="stylesheet" href="/assets/css/print.css" media="print">
<meta name="description" content="Page description">
<meta property="og:title" content="Unique page title - My Site">
<meta property="og:description" content="Page description">
<meta property="og:image" content="https://www.mywebsite.com/image.jpg">
<meta property="og:image:alt" content="Image description">
<meta property="og:locale" content="en_GB">
<meta property="og:type" content="website">
<meta name="twitter:card" content="summary_large_image">
<meta property="og:url" content="https://www.mywebsite.com/page">
<link rel="canonical" href="https://www.mywebsite.com/page">
<link rel="icon" href="/favicon.ico">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/my.webmanifest">
<meta name="theme-color" content="#FF00FF">
</head>
<body>
<!-- Content -->
<script src="/assets/js/xy-polyfill.js" nomodule></script>
<script src="/assets/js/script.js" type="module"></script>
</body>
</html>
Осторожно: 1) Гифки тяжелые! 2) Много ярких мигающих картинок!
В своё время я сам здорово намучился с английскими временами. Совершенно не получалось понять, как они формируются. Когда наконец удалось вызубрить все правила, самые простые существующие между временами закономерности всё равно оставались для меня неочевидными.
Как это часто бывает, по-настоящему понимаешь какую-то тему, только когда начинаешь рассказывать о ней другим («метод Фейнмана»). Несколько друзей, позавидовав моим «успехам», попросили помочь разобраться с английским. Тут и обнаружилось, что хотя я уже успешно использую английский в повседневной работе, обучать ему кого-то ещё — это совершенно отдельный навык.
Первоначальная идея. Сначала разъяснить все английские времена за один присест удавалось, надёргав различных идей из интернета: обрывки чьих-то схем, начинали склеиваться в свою схему и обрастать собственными легендами, а применение времён почти всегда было проще пояснить, используя хрестоматийную «систему английских времен с точки зрения употребления глагола “to vodka”». С каждой новой импровизированной лекцией, схема и нарратив продолжали меняться. «Ученики» попадались с различным базовым уровнем, что позволило понять, откуда нужно начинать плясать, чтобы урок был понятен всем, кто хоть раз слышал что-то про глаголы have и be. Когда счёт обученных уже пошёл на десятки, я решил оформить идею в более стройную лекцию. От первых попыток преподавания английских времён, до этого момента прошло пять лет. За это время было обучено ещё пару сотен человек. Обучено — по приколу. Денег за эти уроки я не брал.
Всем привет!
Я работаю бэкенд-разработчиком в компании Tinkoff, где участвую в разработке платформы CRM-системы для обслуживания физических и юридических лиц.
Использование edge proxy и балансировщика в частности — это почти мастхэв при построении современных систем. Сегодня на рынке представлено большое количество разнообразных решений, у каждого из которых есть преимущества и недостатки. Мы остановимся на одном из самых свежих — Envoy.
Envoy — это высокопроизводительный балансировщик, реализованный на C++. Его разработала компания Lyft — сервис заказа такси в Штатах, прямой конкурент Uber — для использования как с отдельными сервисами, так и в качестве связующего звена в сложных микросервисных системах. В том числе для реализации относительно свежего архитектурного явления — service mesh.
Формируя основной фундамент нашей платформы, он реализует cors, access-control, rate limiting, outlier detection, проверку jwt и многое другое.
На Хабре есть отличная статья, которая разбирает его основные отличия от ближайших соседей и проливает свет на внутреннее устройство. Мы же сфокусируемся больше на прикладных моментах, разберемся с запуском и настройкой, попробуем сразу несколько видов балансировки трафика. Поехали!
Привет, Хабра!
Сегодня одолела ностальгия и хочу рассказать, как делал устройства для музыкантов — педальки-контроллеры, наделяющие музыкальный процессор Digitech Whammy новыми возможностями. Устройства мало кому нужны, но кому нужны — то позарез)
Этот проект мне очень дорог, потому что с него началась настоящая страсть к созданию чего-то нового. И хоть я давно уже не брался за паяльник, а основное время посвящаю развитию в управлении продуктом, всё ещё не оставляю фантазии о фееричном возвращении в music hardware, которое сделает немного шума в чахнущем царстве рока.
Да и перед именитыми ребятами (на фото, например, CJ Pierce из Drowning Pool, James "Munky" Shaffer из Korn и Wesley Borland из Limp Bizkit, ну и я с девайсами), признаться, стыдно, что пропал на целых несколько лет — ни слуха от меня, ни духа о новых устройствах.
Удачно сложилось, что сегодня же есть 3,5 часа в самолёте, так что настало время офигительных историй — расскажу, как появились эти железки реально из мусора. Курьёзы и неудачи, какие устройства хотел и что получилось, как они оказались у топ-музыкантов мира и почему я отложил такие крутые штуки в долгий ящик.
Возможно это смотивирует кого-то вернуться и доделать свои идеи, а кому-то просто поднимет настроение. Итак, вперёд! Точнее назад, в 2010 год...
Липкие сессии (Sticky-session) — это особый вид балансировки нагрузки, при которой трафик поступает на один определенный сервер группы. Как правило, перед группой серверов находится балансировщик нагрузки (Nginx, HAProxy), который и устанавливает правила распределения трафика на доступные сервера.
В первой части цикла мы посмотрим как создавать липкие сессии с помощью Nginx. Во второй же части разберем создание подобной балансировки средствами Kubernetes.
