Всем привет!
Вот что я вам сегодня скажу (то что вы и так знаете) — нужно ставить свои сервисы на мониторинг как можно раньше, это очень важно! 🤓
Предыстория (любимый начальник, прошу не читай 😅)
Я на той неделе выкатила свою доработку в прод и только вчера узнала, что у определенной части пользователей при определённых кривых данных перестала работать одна фича.
Давайте опустим вопросы про тестирование, речь не об этом)
Как бы я могла узнать об этом раньше? Если бы мониторила эту фичу)
Очевидно, что мониторинг, это не новость, но почему-то часто на него забивают. Например, когда я пришла на текущий проект, тут было очень мало чего на мониторинге, хотя проект делали не джуны.
Даже на собеседованиях иногда разработчики не знают про графану, либо «у нас маленькая нагрузка», «просто посмотрим логи», «у нас MVP», «руки не дошли» 😒
Блин, это как с тестами, может лучше сначала мониторинг сделать, а потом уже писать функционал 🤣
В общем - настраивайте мониторинг с алертами в тележку и спите спокойно 😌
Вот что я вам сегодня скажу (то что вы и так знаете) — нужно ставить свои сервисы на мониторинг как можно раньше, это очень важно! 🤓
Предыстория (любимый начальник, прошу не читай 😅)
Я на той неделе выкатила свою доработку в прод и только вчера узнала, что у определенной части пользователей при определённых кривых данных перестала работать одна фича.
Давайте опустим вопросы про тестирование, речь не об этом)
Как бы я могла узнать об этом раньше? Если бы мониторила эту фичу)
Очевидно, что мониторинг, это не новость, но почему-то часто на него забивают. Например, когда я пришла на текущий проект, тут было очень мало чего на мониторинге, хотя проект делали не джуны.
Даже на собеседованиях иногда разработчики не знают про графану, либо «у нас маленькая нагрузка», «просто посмотрим логи», «у нас MVP», «руки не дошли» 😒
Блин, это как с тестами, может лучше сначала мониторинг сделать, а потом уже писать функционал 🤣
В общем - настраивайте мониторинг с алертами в тележку и спите спокойно 😌
👍22💯7🔥6❤2
Forwarded from Nomad
А еще надо приделывать к логам ошибок какие то мотивационные цитатки, или гороскоп, или анегдот...о, предсказание как из печенек
"Расслабся и пусть весь мир подождет"
"Это не самая лучшая работа в мире"
....
"Расслабся и пусть весь мир подождет"
"Это не самая лучшая работа в мире"
....
🤣14👍8🐳5😁3💯2
Builder: паттерн или антипаттерн?
На днях поспорила с коллегой за паттерн Builder 🤓 Он его часто использует, а я стараюсь избегать, дальше расскажу почему)
Когда его используют?
• нужен иммутабельный объект, который содержит множество необязательных параметров ( = множество конструкторов)
• объект содержит поля с одинаковым типом и есть вероятность перепутать эти параметры при инициализации
• иногда его пихают везде))))
Почему я стараюсь его избегать:
• даже если мы ожидаем, что все параметры объекта обязательные, ничего не мешает вызвать build() раньше чем надо и объект получается недоинициализированным
• мы смещаем проверку валидности объекта на рантайм, вместо compile time (как например в случае со статическим методом создания объекта)
• необходимы дополнительные тесты, что объект правильно создаётся в рантайме и тот ли объект вообще создаётся
• куча бойлерплейта, если не хочется использовать lombok (котлин-ребята поймут)
А ваще я люблю писать на котлине, я использую дата классы и конструкторы с именованными аргументами, и никакие билдеры мне не нужны)))
В джаве использую статический метод создания объекта и делаю конструктор приватным
Пользуетесь этим паттерном? Если да, то как проверяете, что объект валиден после создания?
На днях поспорила с коллегой за паттерн Builder 🤓 Он его часто использует, а я стараюсь избегать, дальше расскажу почему)
Когда его используют?
• нужен иммутабельный объект, который содержит множество необязательных параметров ( = множество конструкторов)
• объект содержит поля с одинаковым типом и есть вероятность перепутать эти параметры при инициализации
• иногда его пихают везде))))
Почему я стараюсь его избегать:
• даже если мы ожидаем, что все параметры объекта обязательные, ничего не мешает вызвать build() раньше чем надо и объект получается недоинициализированным
• мы смещаем проверку валидности объекта на рантайм, вместо compile time (как например в случае со статическим методом создания объекта)
• необходимы дополнительные тесты, что объект правильно создаётся в рантайме и тот ли объект вообще создаётся
• куча бойлерплейта, если не хочется использовать lombok (котлин-ребята поймут)
А ваще я люблю писать на котлине, я использую дата классы и конструкторы с именованными аргументами, и никакие билдеры мне не нужны)))
В джаве использую статический метод создания объекта и делаю конструктор приватным
Пользуетесь этим паттерном? Если да, то как проверяете, что объект валиден после создания?
👍13🔥3👏3🤔3👎2
Девчонка из IT
Сегодня весь день ковырялась с Hibernate 😅 На прошлом месте работы у меня его не было, пользовалась Jdbc, а потом и R2dbc и бед не знала)) А сейчас у нас везде Hibernate, приходится изучать, а он мне не нравится) Я всегда думала хиба, да и JPA в целом, это…
Я уже писала, что ступила на скользкую дорожку Hibernate и недавно столкнулась с прикольной ошибкой, которую не ожидала вообще) (по незнанию)
У меня bidirectional one-to-many relationship между двумя объектами и они ссылаются друг на друга с соответствующими анноташками.
Пример в основной сущности (код не настоящий если что):
В дочерней
И тут мне понадобилось сложить эту сущность в json и записать в БД)))
Закономерно я получила циклическую зависимость и StackOwerflowException при сериализации в JSON.
Подробнее про ошибку и способы устранения можно почитать тут
Я у себя добавила
У меня bidirectional one-to-many relationship между двумя объектами и они ссылаются друг на друга с соответствующими анноташками.
Пример в основной сущности (код не настоящий если что):
@OneToMany(mappedBy = "user", cascade = [CascadeType.ALL], fetch = FetchType.EAGER)
lateinit var emails: Set<Email>В дочерней
@ManyToOne
lateinit var user: UserИ тут мне понадобилось сложить эту сущность в json и записать в БД)))
Закономерно я получила циклическую зависимость и StackOwerflowException при сериализации в JSON.
Подробнее про ошибку и способы устранения можно почитать тут
Я у себя добавила
@JsonIgnore в дочерней сущности и теперь довольная))@ManyToOne
@JsonIgnore
lateinit var user: UserBaeldung on Kotlin
Jackson - Bidirectional Relationships | Baeldung
How to use Jackson to break the infinite recursion problem on bidirectional relationships.
👍9🔥3🤣2❤1👏1
Всем привет!
Сегодня с утра с кофейком посмотрела доклад Ивана Углянского про проект Loom и его место в мире параллельных вычислений. Выделила для себя несколько интересных моментов, щас опишу)))
Во-первых, котлиновские корутины это отличная реализация колбеков на уровне компилятора, и для их использования нужно достаточно мало менять исходный код, но есть и минусы:
- издержки по производительности и по памяти по сравнению с блокирующим кодом (создаём на каждую функцию Continuation объект и даём доп. нагрузку на GC)
- накладывается обязательство от компилятора раскрашивать код (явно маркировать suspend-функции)
Во-вторых, сам проект Loom реализован достаточно интересно, виртуальные потоки имеют свои стеки в heap’е и эти стеки копируются на платформенные треды и обратно.
Тоже есть свои минусы))
- не работает нативка 😨 (а даже в моих крудо-микросервисах кое-где есть JNI)
- пока не работает synchronized (мне не страшно 🤣)
- не предназначено для CPU-intensive задач 😵
- планировщик - ForkJoinPool - недостаточно эффективен для виртуальных потоков и нет возможности подключить свой планировщик
В котле кстати написали свой кастомный планировщик, хотя изачально тоже сидели на FJP
Оказывается в Go самые эффективные виртуальные потоки, в которых уже решены все боли Loom’а, ну дела)))
P.S: почему-то тащусь от докладов про JVM и всего этого низкуровневого😍
Сегодня с утра с кофейком посмотрела доклад Ивана Углянского про проект Loom и его место в мире параллельных вычислений. Выделила для себя несколько интересных моментов, щас опишу)))
Во-первых, котлиновские корутины это отличная реализация колбеков на уровне компилятора, и для их использования нужно достаточно мало менять исходный код, но есть и минусы:
- издержки по производительности и по памяти по сравнению с блокирующим кодом (создаём на каждую функцию Continuation объект и даём доп. нагрузку на GC)
- накладывается обязательство от компилятора раскрашивать код (явно маркировать suspend-функции)
Во-вторых, сам проект Loom реализован достаточно интересно, виртуальные потоки имеют свои стеки в heap’е и эти стеки копируются на платформенные треды и обратно.
Тоже есть свои минусы))
- не работает нативка 😨 (а даже в моих крудо-микросервисах кое-где есть JNI)
- пока не работает synchronized (мне не страшно 🤣)
- не предназначено для CPU-intensive задач 😵
- планировщик - ForkJoinPool - недостаточно эффективен для виртуальных потоков и нет возможности подключить свой планировщик
В котле кстати написали свой кастомный планировщик, хотя изачально тоже сидели на FJP
Оказывается в Go самые эффективные виртуальные потоки, в которых уже решены все боли Loom’а, ну дела)))
P.S: почему-то тащусь от докладов про JVM и всего этого низкуровневого
Please open Telegram to view this post
VIEW IN TELEGRAM
👍18🔥7❤3👏2
Тэкс, я уже посетила практически все доклады для будущих СТО ☺️
Сейчас попробую сформулировать свои мысли🤩
Сейчас попробую сформулировать свои мысли
Please open Telegram to view this post
VIEW IN TELEGRAM
Евгений из Иви рассказал о том, с какими трудностями сталкивается СТО в своей работе.
Что я для себя поняла:
🫧 СТО занимается людьми и бюджетом, и чуть-чуть архитектурой
🫧 важно уделять время наставничеству или преподаванию, конференциям, публикациям
🫧 важно окружить себя людьми, которым не всё равно и которые хотят учиться
🫧 если скучаешь по программированию, нужно больше уделять времени архитектуре
Остальное на слайдах)))
Что я для себя поняла:
🫧 СТО занимается людьми и бюджетом, и чуть-чуть архитектурой
🫧 важно уделять время наставничеству или преподаванию, конференциям, публикациям
🫧 важно окружить себя людьми, которым не всё равно и которые хотят учиться
🫧 если скучаешь по программированию, нужно больше уделять времени архитектуре
Остальное на слайдах)))
🔥9👍8🤔2👏1
Доклад Михаила Тюрганова из Альфы тоже был классный, он рассказывал своё видение работы СТО
⚡️ важно уметь продать свою идею бизнесу, но сначала нужно продать им проблему, возможно они вообще о ней не думали
⚡️ необходимо налаживать самоподдерживающиеся процессы, чтобы не утонуть в рутине екселей))
⚡️ команда критически важна, но формировать её нужно от потребностей, а не от симпатии
⚡️ важно уметь продать свою идею бизнесу, но сначала нужно продать им проблему, возможно они вообще о ней не думали
⚡️ необходимо налаживать самоподдерживающиеся процессы, чтобы не утонуть в рутине екселей))
⚡️ команда критически важна, но формировать её нужно от потребностей, а не от симпатии
👍11🔥4🤔2👏1
ОЧЕНЬ понравился доклад от СТО Lamoda Tech Эмиля Абдулнасырова. Он честно рассказал с какими задачами столкнулся практически с самого начала работы в роли СТО. Получилось мудро и жизненно
Инсайты:
🔥 СЕО ищет себе не IT человека, а бизнес-партнёра, с которым он будет дальше растить бизнес
🔥 нужно уметь спорить с бизнесом, не стоит со всем соглашаться
🔥 не смотреть близоруко, держать в голове технологическую стратегию на 3-5 лет вперёд
🔥 принять то, что СТО берёт на себя роль визионера, принятые им решения могут дать эффект только через несколько лет
Инсайты:
🔥 СЕО ищет себе не IT человека, а бизнес-партнёра, с которым он будет дальше растить бизнес
🔥 нужно уметь спорить с бизнесом, не стоит со всем соглашаться
🔥 не смотреть близоруко, держать в голове технологическую стратегию на 3-5 лет вперёд
🔥 принять то, что СТО берёт на себя роль визионера, принятые им решения могут дать эффект только через несколько лет
👍15🔥6👏2🤔2
И немножко моих личных инсайтов от общения с разными людьми за эти два дня:
✨ мне почему-то казалось, что СТО это какая-то общая совокупность мыслей и навыков, и у всех СТО она примерно одинаковая, оказалось вообще не так, очень разный майнд-сет, разные взгляды, разные состояния
✨ СТО отличается от руководителя разработки тем, что он меняет старые процессы, налаживает новые, придумывает новые правила и является визионером
✨ для СТО не может быть такого, что ему нравится или не нравится какой-то инструмент или подход. нужно понимать чем хорош каждый инструмент и для каких задач он подходит
✨ т.к. я хочу стать спикером, мне нужно организовать внутренние митапы в своей компании и постепенно привыкать выступать 😅
Такие дела))))
✨ мне почему-то казалось, что СТО это какая-то общая совокупность мыслей и навыков, и у всех СТО она примерно одинаковая, оказалось вообще не так, очень разный майнд-сет, разные взгляды, разные состояния
✨ СТО отличается от руководителя разработки тем, что он меняет старые процессы, налаживает новые, придумывает новые правила и является визионером
✨ для СТО не может быть такого, что ему нравится или не нравится какой-то инструмент или подход. нужно понимать чем хорош каждый инструмент и для каких задач он подходит
✨ т.к. я хочу стать спикером, мне нужно организовать внутренние митапы в своей компании и постепенно привыкать выступать 😅
Такие дела))))
🔥17👍5👏5🌭3❤1🤡1
🔥14👍7👏4