Конспект 5 главы книги по postgresql Моргунова
В этой главе автор книги рассказывает про DDL в postgres:
- как создавать схему таблицы
- как создавать констреинты и рассказывает про их виды
- рассказывает про ссылочную целостность
- как работать с вьюхами и материализованными вьюхами и зачем они нужны

В этой главе я набил руку на DDL запросах и в целом стал чувствовать себя в них очень уверено.
Еще начинают чувствоваться упражнения и их огромный минус.
Автор ссылается в упражнениях на какие-то строчки из текста главы, но главы большие и теряется контекст, особенно,что он хочет,чтобы я привел схему бд в тот вид,какая она была на момент чтения определенного участка главы. Без этого упражнение не сделать.

Конспект 6 главы книги по postgresql Моргунова

В этой главе автор очень обширно проходится по разным фишкам команды SELECT
- работа с атрибутами(DISTINCT и ТД)
- агрегация
- окошки (очень очень кратко)
- CTE
- подзапросы
- джоины (очень подробно)

В данной главе я как обычно набил руку уже на SELECT, особенно, на джоинах. Автор так много про них рассказывает,что к ним привыкаешь и начинаешь их чувствовать и потом уже их очень легко писать на лету.
Про окошки очень мало и скомкано, пришлось много гуглить и изучать дополнительно.
Упражнения норм до середины, дальше уже душно и возникает чувство,что упражнения ради упражнений.
про NOT EXISTS и FILTER раньше не знал, так что полезно.
#postgresql #book #morgunov

Конспект 7 главы книги по postgresql Моргунова

В этом главе автор подробно рассказывает про команды INSERT, UPDATE, DELETE

В основном автор прошелся по разным фишкам использования команд выше

- создание временных таблиц и копирование констрейнтов
- Ведение логов запросов без триггеров - одним запросов
- рассказал про UPSERT и его вариации
- использование ключевого слово USING как альтернативы JOIN
- использование джоинов в команде DELETE, когда надо удалить что-то на основе условия связанного с полем ссылочной таблицы

https://telegra.ph/Izmenenie-dannyh-05-16

#postgresql #book #morgunov

Как начать перформить?

https://habr.com/ru/companies/alconost/articles/321932/

Прикольная статья мне оч помогла ускорить написание кода и перф соответственно

Суть простая🤲

Чтобы быстрее закрывать тикеты - нужно внимательно следить сколько времени тратится на программирование. Если ты перестаешь кодить и начинаешь думать, то значит неопределенность задачи все еще высокая.

Как выйти из этой ситуации?🤔

- Убедиться, что понимаешь задачу
- Спроектировать задачу по шагам
- Задать вопросы коллегам с бОльшим контекстом
- Убедиться, что есть понимание методов, функций, объектов и других программных сущностей, которые используются для решения задачи
- Написать прототип
- Написать сначала тесты, чтобы проверить, что задача спроектирована последовательно и корректно
- Не надо писать сразу идеально

И главный поинт статьи ❗️
Всегда нужно спрашивать себя, почему я остановился писать код и что мне сейчас не хватает?

#разработка #лайфхаки

Почти полтора месяца ничего писал в канал
За это время дочитал моргунова, скоро скину просто единый конспект по всем главам и подведу итоги
- Готовлю 2 статьи в канал по алгоритму локализации багов и поиску утечек памяти в python приложениях

Как проходить онбординг part 1

Не так давно, я успешно прошел испытательный срок в своей компании, поэтому пока не забыл хочу поделиться своим списком советов и лайфхаков как облегчить себе жизнь при прохождении онбординга.😎

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

- Завести отдельный документ, где будет записана важная информация по онбордингу:
ссылки на документацию/системы/репозитории, важные замечания по проекту, ответы на вопросы, замечания по политикам разработки/картинки с архитектурой.

Как проходить онбординг part 2

Все встречи касающиеся онбординга нужно записывать, так как информации действительно много, поэтому ее надо агрегировать и структурировать.

- В первые дни онбординга нужно убедиться, что у тебя есть детерминированные ответы на следующие вопросы:
1. Какой план онбординга
2. Какие задачи будут на испыталке
3. Критерии прохождения испыталки
4. Ссылка на документацию
5. Какие есть важные ссылки, которыми пользуется команда
6. Ссылка на репозитории
7. Ссылка на систему мониторинга (графана, кибана, джагер, sentry)
8. какие доступы необходимы для работы
9. Нужно ли согласовывать новые библиотеки/использование нового docker-образа
10. Есть ли документация по политикам разработки (как работать с пулл реквестами/как принято писать код)
11. Есть ли документация по архитектуре проекта?
12. Как у вас принято работать с задачей?

- Не торопиться предлагать улучшения, так как вначале кредит доверия к новенькому низкий

- не выносить замеченные проблемы в процессах/коде/архитектуре в общий чат. В таком случае лучше выписать эти замечания и обсудить на личной встрече с руководителем.

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

- Не пытаться оверперформить.

- Не перерабатывать.

- Заранее предупреждайте, если оценка задачи поехала.

- Не бросаться делать недекомпозированые задачи с неправильной оценкой. Лучше назначить встречу и объяснить лиду, почему оценка неправильная.

- Нужно уделять больше времени проектированию задач.

- Стоит заранее разобраться к каким конкретно людям бежать в случае организационных вопросов.

- Настройте ноутбук заранее. Если вам выдали новый ноут, то стоит выделить отдельно 3-4 часа и полностью настроить его под удобное использование. Это делается один раз.

- Настройте фильтры на рабочей почте по папкам, это поможет избавиться от замусоривания.

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

Кстати недавно прочитал один совет по онбордингу, что при знакомстве с проектом нужно делать так:
- выписать все существующие модели и их поля с описанием, что они значат
- выписать все ручки и описать зачем они нужны
- выписать описание бизнес логики для каждого хендлера

автор писал, что таким образом получится в разы сократить время вкатывания в проект

Я один раз так попробовал сделать, но в итоге сначала читал логику работы функции обработки сообщения из кафки около часа, потом у меня появилось миллион вопросов по этому коду, а еще через 30 минут, я забыл, что я читал вообще) По итогу получилось , что совершенно некогда этим заниматься и кажется это не особо эффективно на практике.

Есть еще вариант изучить тесты, но мысль о том,что надо будет читать код ВСЕХ тестов вызывает у меня боль😂

По итогу я разбираюсь только с тем,что мне необходимо для решения задач и годами могу не знать про определенный функционал в системе.

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

А как вы разбираетесь в новом проекте?

Если кто-то на маке тоже стал ловить эту ошибку, то вот фикс,который работает:
https://forums.docker.com/t/malware-blocked-com-docker-vmnetd-was-not-opened-because-it-contains-malware/145930/39

Наконец реализовал сервис для управления финансами (fin-manager) 🎉

Мотивация:
Хочется грамотно вести собственный бюджет и эффективно управлять своими финансами, как будто бы для этого уже есть множество решений. Те же excel таблицы. Я попробовал - для меня показалось не очень удобно.

И вот почему:
- Ручное управление таблицей, управление ссылками и формулами создает свои неудобства. В случае изменения/удаления какой-то строки в общей сводной таблице, приходится менять ссылки во всех формулах, графиках и в целом не очень удобно обновлять сводную таблицу трат, так как нужно обновлять суммы, что-то считать и обновлять ячейки в ручную. Как итог - я обленился и перестал вести эту таблицу🥱

- Построение аналитических графиков занимает время так как нужно писать формулы агрегации и ссылки на ячейки. В интерфейсе Excel это делать максимально противно, особенно с телефона🤮

- В других приложениях: либо неудобный интерфейс либо много рекламы и свои ограничения

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

И я реализовал сервис fin-manager состоящий из следующих компонент:
- сервер API на Go, который описывает обычные круды для управления категориями и транзакциями. Его цель - аккумулировать в себе всю ту логику для управления финансами, форматом и хранением данных. То есть предоставлять внешними сервисам удобно работать с интерфейсом управления финансами.
https://github.com/AnatolyPoluyaktov/fin-manager

- бот (тоже на Go) как простой клиент для взаимодействия с этим API. То есть он дает возможность вносить категории и траты по кнопке, что очень упрощает мониторинг и управление финансами,ни одна трата не будет пропущена:)
https://github.com/AnatolyPoluyaktov/fin-manager-bot

- apache superset для построения аналитики на основе данных, которых хранит сервис. гистограммы,сводные таблицы, бар чарты - все что угодно за sql-запросы, а sql мне удобнее чем формулы в excel. Вообщем любая аналитика welcome, но и мне много не надо:) А также ничего писать не пришлось (кроме одного sql) так как superset - opensource решение. Просто нужно было написать деплойменты😩

- библиотечка на python, которая на основе выгруженных выписок по операциям на дебетовых картах в формате pdf из сбера и тинька :
- парсит все операции из pdf
- делает разметку по категориям, которые я указал и которые существуют в моей системе
- преобразовывает в json формат, который принимает мое API
ну это выкладывать не стал так как делает она разметку только для моих категорий:)Было сложно, надо было упороться в регулярки🐻

Также настроил CI для обновления этих компонентов и написал деплойменты для автоматизированного развертывания этих компонентов с помощью ansible

Временные затраты:

- 3 вечера на апишку

- 1 вечер на бота

- около 5 вечеров на библиотеку для разметки данных

- 1 вечер на CI и дейплойменты

Как результат можно легко оптимизировать и облегчить свою жизнь каким-то не сложным программированием
P.S
про использование ресурсов расскажу потом отдельно -_-

Верхнеуровневая архитектура fin-manager

Как видите архитектура максимально простая, много придумывать не надо, зато все по кнопке и можно забыть про эксель таблицы
P.S
на рисунке не указал категории, но суть та же:)

Есть еще такой репозиторий
https://github.com/codecrafters-io/build-your-own-x

вообщем если хочется попробовать написать что-то приближенное к реальности или потрогать руками какой-то язык, то можно найти много интересных тем, которые уже спроектированы и остается только ознакомиться и написать код:)
например из интересного:
- можно написать свой load balancer на расте, свой http сервер, свой впн или свой блокчейн,что звучит прикольно😂
например если хочется разобраться в DNS протоколе, вместо того,чтобы читать сухой RFC, можно читать сухой RFC и реализовывать что там написано😂И точно будешь знать все хедеры и байты работы с DNS📚Зачем правда не знаю, но интересы бывают разные:)

Мой опыт перехода на Neovim

Недавно я полностью перешёл с GoLand на Neovim, так как решил обменять привычный комфорт IDE на возможность полностью управлять своей средой разработки, кастомизировать её и быть защищённым от ситуации, когда разработчик IDE может закрыть мне доступ.

Пришлось всё-таки с нуля писать свой конфиг для Neovim, несмотря на большое количество готовых дистрибутивов. Я перепробовал несколько, и у каждого нашлись свои минусы, которые не соответствовали моим критериям удобства:



Скорость — хотелось, чтобы IDE работала моментально и без лагов.


Простота — не хотелось учить новый «фреймворк» конфигураций на Lua, а использовать стандартный и понятный каркас.


Минималистичность — нужны только те плагины, которые действительно полезны. Например, я пользуюсь Git исключительно в консоли, поэтому мне не нужен UI для Git.


Модульность и единая ответственность — каждый плагин или модуль конфигурации отвечает только за свою логику.


После того как я настроил Neovim, возник вопрос:
как удобно переключаться между проектами, как в GoLand, где достаточно выбрать другую вкладку — и ты уже работаешь в новом проекте?

Решением оказался Tmux. Более того, он оказался даже эффективнее, чем GoLand:

- работает очень быстро;

- позволяет легко создавать окна, переключаться между ними и давать имена;

Позже появилась необходимость синхронизировать свои конфиги между устройствами. Для этого я создал dotfiles-репозиторий с помощью stow, где храню большинство своих конфигураций:
👉 github.com/AnatolyPoluyaktov/dotfiles

Сейчас моя конфигурация включает:

- Neovim
- Alacritty
- Tmux
- Zsh


Достаточно просто склонировать репозиторий и выполнить команду:

stow -vt ~ */

После этого создаются симлинки по иерархии, начиная с домашней директории.

просто цитатки из моего сердца….

Ну это прям добивочная, читается прям как библия для разработчика)

🚧 Проблемы с соблюдением API-контрактов

Бывало ли у вас, что:
• один микросервис внезапно начал отправлять запросы в другой в неправильном формате
• или фронтенд и бэкенд начали обмениваться несовместимыми данными

🤦‍♂️ Это довольно типичная история.
Часто причина — отсутствие единого источника правды.

⸻

📝 Решение: Spec-First

Один из работающих подходов — Spec-First.

📌 Суть:
• Сначала согласовываем контракт между командами
• Описываем его в формате, например OpenAPI
• Публикуем спецификацию на сервере,продюсере, а клиенты ее копируют

• Разработчики на основе этой спецификации генерируют сервер, клиент и модели

🛠 Пример инструмента:
OpenAPI Generator CLI
(подобных утилит есть много для разных языков)

⸻

✅ Преимущества
• Спецификация — источник правды 🗂
Контракты не изменятся без изменения спеки, значит ей можно доверять.
• Нет нужды тестировать контракты 🧪
Команды могут сосредоточиться на тестировании юзкейсов и мапперов.

⸻

⚠️ Недостатки
• Нужно копировать спецификацию между сервисами
• Клиенты не должны менять спеку самостоятельно — иначе будет десинхронизация
• Разработчики сервиса должны уведомлять об изменениях (например, звать разработчиков клиентов в PR со сменой спеки)