Пишу про полезные материалы про IT, и собираю свой ламповый нетворкинг тут - https://t.me/+434aQiGpZtAyNTU6. Присоединяйтесь!

Оглавление.

Привет, на CKA курсе туторы нарочито вдалбливают последовательность действи: set the cluster, set the namespace, set the pod... И все это происходит в консоли, используя kubectl - консольная утилита для управления k8s кластерами. Мне настолько это вдолбилось что я решил это автоматизировать. У меня уже был интересный проект автоматизации ssh подключений (sshto), не долго думая, я взял его за основу и написал kui. Это bash скрипт, dialog обёртка для kubectl. У диалога есть приятная фича присваивать горячку каждому пункту меню по первому символу. Это очень удобно, в результате весь k8s кластер оказывается у вас на кончиках пальцев.

Обычно мы рассказываем, как помогаем нашим клиентам. Но сегодня разговор особенный — заказчиком биллинговой системы для ИТ-компании выступила сама ИНТЕРВОЛГА!

Когда мы увидели, что наши клиенты готовы работать по Agile-методологии и модели Time & Material (почасовая оплата), мы столкнулись с новым вызовом: управление проектами стало сложнее, а объем отчетности существенно вырос.

Один из наших ключевых принципов в работе с заказчиками — всегда говорить правду. В формате Time & Material это особенно важно: прозрачность должна быть полной — как в части “Time” (затраченное время), так и “Material” (стоимость работ).

В вопросах учета рабочего времени мы уже давно доверяем системе JetBrains YouTrack, поэтому точный подсчет часов по задачам для нас не был проблемой. Настоящая сложность скрывалась в другом — в расчете стоимости.

На первый взгляд задача казалась простой:

ОБЩЕЕ ВРЕМЯ × СТАВКА ЧАСА = ОБЩАЯ СТОИМОСТЬ

Но на практике все оказалось куда сложнее. В разных проектах и отделах применялись разные ставки. Были “бесплатные” задачи — ведь мы всегда бесплатно исправляем собственные ошибки — и задачи, требующие уникальной экспертизы. Простого умножения было явно недостаточно.

Проектные менеджеры буквально становились магами Excel, применяя сложные формулы и сводные таблицы. Создание одного отчета занимало от 30 до 50 минут, а у каждого менеджера было несколько клиентов.

Так перед нами и встала новая задача: выстроить полноценный процесс биллинга внутри компании.

Наверняка каждый php-разработчик, хоть раз сталкивавшийся с чтением или записью Excel-файлов, знает про библиотеку PhpSpreadsheet (в прошлом - PHPExcel). Это мощная библиотека на чистом php, которая позволяет читать, а, главное, создавать Excel-таблицы. И все с ней хорошо, пока работаешь с небольшим набором данных. Но при работе с большими файлами PhpSpreadsheet начинает чудовищно отжирать память, да и производительность резко падает, и php-скрипт, использующий библиотеку, часто просто отваливается по таймауту. И проблема - в архитектуре библиотеки.

Библиотека PhpSpreadsheet, казалось бы, спроектирована очень правильно: листы таблицы, строки, ячейки, прочие сущности - это все классы, стили, форматы и всевозможные свойства тоже состоят из классов. И когда создается таблица, то в памяти создается огромное количество связанных между собой объектов, им задаются свойства, выполняются всевозможные манипуляции, ячейки заполняются данными, всё-всё это держится в памяти, и пишется в файл только в момент сохранения.

И вот однажды, когда ресурсы на генерацию большого Excel-файла превысили все разумные значения, я начал искать альтернативу известной библиотеке. Альтернатива нашлась. В отличие от PhpSpreadsheet, тут все было упаковано в один класс, возможности по форматированию и стилям - скромнее некуда, но зато XLSX-файл создавался в разы быстрее, а потребление памяти было вообще копеечное. А все потому, что тут был реализован совсем иной принцип - данные не накапливались в памяти, а построчно сразу выводились в файл. Вдохновившись этой идеей, я и создал свою библиотеку FastExcelWriter.

Мы — команда студентов из ИТМО, которая прошла путь от хакатонов до продуктовой разработки. На собственном опыте расскажем, как выстроили инфраструктуру, способную масштабироваться, переживать сбои и не стоить, как полкоманды в найме.

Когда вы только начинаете делать стартап, инфраструктура кажется чем-то второстепенным. Важнее MVP, фичи, дизайн, пичдек. Но в какой-то момент всё внезапно перестаёт помещаться на одном сервере, руками деплоить становится больно, SSL не обновляется, а продакшн падает из-за перегрузки или забытого docker-compose up.

Kubernetes? Слишком сложно, долго и дорого. Монолит? Неудобно масштабировать. Мы искали третий путь — и нашли его.

Все прекрасно понимают, что традиционное, классическое, «синхронное» программирование подразумевает пошаговое выполнение программного кода. Соответственно, каждый следующий шаг скрыт за пределами «видимости» до момента его выполнения. 

Из этого вытекает вполне логичная проблема — что делать, когда необходимо получить некие данные в процессе выполнения определенного блока кода или до? Тут на помощь нам и приходит асинхронная обработка запросов и асинхронное программирование в целом.

В статье описывается процесс установки и настройки утилиты Beszel для мониторинга домашних серверов. Автор делится опытом работы с этой платформой, её преимуществами и недостатками, а также рассказывает о том, как интегрировать систему уведомлений в Telegram для быстрого реагирования на проблемы.

Всем привет! Меня зовут Никита Рыженков, и я хочу поделиться опытом разработки библиотеки FastOpenAPI. Это инструмент, который приносит удобный стиль маршрутизации FastAPI и автоматическую документацию OpenAPI в целый ряд Python-фреймворков. Идея родилась из личной боли: в одном проекте приходилось поддерживать OpenAPI-документацию сразу в нескольких фреймворках, и я устал дублировать решения под каждый из них. Вдохновившись лаконичностью FastAPI, я решил создать унифицированный подход для Flask, AioHttp, Sanic, Falcon, Starlette, Quart, Tornado – назвал его FastOpenAPI​. В этой статье расскажу, какие проблемы решает FastOpenAPI, как он устроен внутри и как им пользоваться с примерами кода под каждый поддерживаемый фреймворк.

👋 Привет, Habr!

Вы когда-нибудь пытались найти качественный open-source клон Pinterest — с real-time функционалом, полноценной архитектурой, удобным UI и современной технологической основой? Я — да. И не нашёл. Поэтому решил создать свой.

Представляю вам Pinterest Clone — мой pet-проект, над которым я работал в одиночку 4 месяца, чтобы воссоздать не просто копию, а полнофункциональную платформу с реальным пользовательским опытом, максимально приближённым к оригиналу.

Меня зовут Андрей Никольский, я Head of Platform в Банки.ру. Сегодня хочу обсудить не самую приятную, но важную тему — технический долг и как с ним работать.

Любой разработчик или руководитель неизбежно сталкивается с техдолгом: либо устраняет его, либо создает. Чаще всего — и то, и другое одновременно. Год назад я решил глубже разобраться в этом вопросе и начал изучать, что происходит в индустрии: как компании работают с техдолгом в теории и на практике, какие подходы применяют и с какими проблемами сталкиваются.

Потом я структурировал, что есть по этой теме у нас в Банки.ру и решил написать статью. Будет много ссылок на англо- и русскоязычные статьи и доклады, рекомендую изучить каждую ссылку для полноты понимания.

Мы начинали с обычного ELK-стека, логи приходили на logstash, записывались в Elasticsearch, а пользователи смотрели их в Kibana. Потом в эту схему добавилась Kafka, так как мы понимали, что на пиках нагрузок не успеваем записать все логи в Elasticsearch. Всё это располагалось в одном ЦОДе, а в Kafka была единая очередь. В результате горизонтального масштабирования Elasticsearch разросся до 30+ нод. Данная схема справлялась с нагрузкой в 100 тысяч документов в секунду.

Как вы понимаете, эта схема нас устраивала только до определённого периода. В какой-то момент нагрузка начала расти как на дрожжах.

Привет, Хабр! На связи Филипп Бочаров, руководитель платформы наблюдаемости и мониторинга для более 400 продуктов экосистемы МТС, и Юлия Тальцкова, ведущий инженер сервиса логирования и кластеров Open Search с более 400 терабайтами логов клиентов. Этот материал написан на основе нашего доклада для конференции Highload++

Расскажем, как нам удалось переписать критичный и высоконагруженный сервис логирования, перестать просыпаться от ночных звонков и даже иногда уходить в отпуск.

И это решит 95% проблем типичного стартапа. Как-то так повелось, что по всему СНГ и его окрестностям на работу набирают зумеров с колоссальным опытом в три года, и они начинают создавать идеальные архитектуры. Да, каждый из вас, как только получает возможность взять на себя хоть малейшую ответственность, сразу вспоминает все прочитанные и не прочитанные книги и пилит свою уникальную архитектуру, непохожую ни на что.

Какие автомобильные компании Китая самые сильные и крупные? Какие марки самые популярные? Кто кого производит? Кто кем владеет? Кто с кем конкурирует? Раскладываем по полочкам, как устроена автомобильная индустрия Китая. После этой статьи у вас сложится цельная и понятная картинка.

Я уже писал на Хабре статью, что такое СДВГ и как он влияет на жизнь. Жизнь с СДВГ создаёт свои трудности и я (как имеющий этот синдром) ненавижу и максимально стараюсь избегать любую рутину.

Иногда это доходит до крайности — мне необходимо заполнить какие-то заметки, но они все одинаковые. Ты их копируешь, вставляешь, опять поднимаешь руку к мышке, пытаешься попасть в нужную строку иии... глючит при прокрутке ролик, ты промазываешь и эмоции такие, что хочется выкинуть всю технику в окно.

Поэтому я сделал для себя кучу шаблонов заметок, которые очень быстро заполняются по правилу игры «Тронул мышку — проиграл». Эти шаблоны сильно облегчили мою жизнь и одним таким шаблоном я и хочу поделиться.

Привет, Хабр!

Сегодня поговорим про одну из тех тем, что вроде бы тривиальна, но до последней капли грязи тащит за собой внушительный пласт вопросов. Речь пойдёт про COUNT(*) и COUNT(col) в PostgreSQL.

В своих заметках часто хочется сослаться на определённого контакта. Более того, именно в заметках хочется отметить кого-то определённого и описать, в чём его особенность.
Например, контакт строителя, который делал ремонт в спальне и запомнился отличными навыками по электрике.
Писать подобные заметки в самой телефонной книжке не очень удобно, и сложно впоследствии находить нужные контакты.
Дублировать контакт в Obsidian — это и время занимает, и неизбежно приведёт к конфликтам в данных.
Ведение части контактов в телефонной книжке, а части — в Obsidian — вообще приведёт к хаосу, в котором непонятно будет, как и где искать нужный контакт.

В очередные выходные пришла идея: почему бы не сделать синхронизацию телефонной книжки с Obsidian?

«Людей не будет — справляйтесь сами».

Кто-то слышит это в первый рабочий день, кто-то — после пятой переработки за неделю. Новички выгорают, не успев войти в ритм, а опытные специалисты понимают: разговоры с руководством — как об стену.

Почему компании не нанимают, даже когда всё трещит по швам? Что делать в такой ситуации сотрудникам и руководителям? Разбираемся — а в финале делимся историями, от которых стынет кофе в кружке. Возможно, после них вы посмотрите на свою работу иначе.

Если вы считаете, что принципы SOLID — это что-то из учебника по ООП и к вашему проекту они не имеют отношения, у меня для вас плохие новости. Так думали и мы, пока один «божественный» класс не положил прод на сутки. А всё потому, что его писали с мыслью «зачем разбивать, всё и так работает».

В этой статье — без академической воды: как SOLID спасает архитектуру, ускоряет команду и помогает не утонуть в легаси. С примерами, с типичными фейлами и с тем, что действительно работает в продакшене.