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
Ну что ребята, расскажу как прошёл для меня кэмп South Hub @sthhb ✨
Это был БАЛДЁЖ 😍😍😍🔥🔥🔥
Атмосфера нереальная,
нетворкинг пушка, вечеринки жаркие и лекции классные 🤩🤩🤩
А теперь поподробнее)
Это был БАЛДЁЖ 😍😍😍🔥🔥🔥
Атмосфера нереальная,
нетворкинг пушка, вечеринки жаркие и лекции классные 🤩🤩🤩
А теперь поподробнее)
🔥5❤3👍3🥰1