Бегло посмотрела, мне кажется нет напрямую. Если нужно такого вида логирование, то это всегда обёртки разного рода вокруг jdbc. А чем вас этот подход смущает? Вполне рабочий вариант. Ну и ещё если у вас spring boot аспектами можно, но опять это обёртка.
Ужасная статья. Неужели есть люди в самом деле руководствующиеся этими принципами? Отношение, как будто не с людьми работаете, а с роботами, которых при любом удобном вам случае можно просто выкинуть.
Спасибо большое, хорошая подборка. Сейчас дочитываю System Design (Алекс Сюй). Хочу отметить, что книга именно обзорная и достаточно поверхностная. По ней нельзя научиться проектировать и даже проходить архитектурные интервью( что не одно и тоже) . Скорее можно получить представление о задачах и ожиданиях на таких интервью.
С одной стороны базовая джава и concurrency вместе, и нужно их отличное знание. Если базовая джава - да, то отличное знание многопоточности - это про сеньора. С другой стороны, почему-то коллекции выделены в отдельный пункт. Конечно знать их надо, но они уже для джунов являются базовыми, а не специфичными для мидлов. В статье мало упора на реально необходимые базовые навыки мидла, только общие слова.
Согласна, обычно и не всякий сеньор отлично разбирается, в силу специфики. Тут реально нужен большой практический опыт, но чтобы мидл. Если у вас мидл отлично понимает concurrency, то что-то не додали вы ему, он сеньор уже.
Мне кажется, если делалось такое исследование, то паралельно нужно было бы предоставить цифры о проценте компаний, заставляющих своих работников перерабатывать самым различным образом без оплаты. И гит дает такую возможность. И там будет далеко не 10%. Мой опыт говорит, что практически все. Конечно можно сказать, что это субъективные данные одного человека. Но так было бы честнее. Интересно, что заставило автора выбрать именно эту тему?
Я работаю тим. лидом давно. Много проектов, несколько контор. Всё так и есть, как описано в статье. Подпишусь под каждым словом. Чтобы остаться на нужном техническом уровне неизбежно придётся перерабатывать, много. То, что модно зовут 'играющим тренером'. Меня почему-то эта формулировка раздражает неимоверно. Нет такого, ты или тренер или игрок :) А так ты реально шестирукий Шива, обязанностей огромное количество, реальных инструментов влияния даже на состав команды не всегда много. Поймала себя на том, что ситуаций, когда ты сел в 10 часов на минуточку и очнулся часов в 5, забыв про завтрак и обед много. Почему стоит работать на этой позиции? Наверное у каждого свой ответ. У меня случались проекты, когда всё нужно было сделать с нуля и тогда это очень интересно. Тим. лид - это стержень, без которого всё рассыплется. Ну или получится лебедь, рак и щука. А так, вот не было ничего, а вот уже что-то закрутилось, живое, и это стоит того :)
Информация
В рейтинге
Не участвует
Зарегистрирован
Активность
Специализация
Фулстек разработчик, Архитектор программного обеспечения
Спасибо! Отличная статья, все описанные проблемы и способы решения видела на практике.
Бегло посмотрела, мне кажется нет напрямую. Если нужно такого вида логирование, то это всегда обёртки разного рода вокруг jdbc. А чем вас этот подход смущает? Вполне рабочий вариант. Ну и ещё если у вас spring boot аспектами можно, но опять это обёртка.
Ужасная статья. Неужели есть люди в самом деле руководствующиеся этими принципами? Отношение, как будто не с людьми работаете, а с роботами, которых при любом удобном вам случае можно просто выкинуть.
Спасибо большое, хорошая подборка. Сейчас дочитываю System Design (Алекс Сюй). Хочу отметить, что книга именно обзорная и достаточно поверхностная. По ней нельзя научиться проектировать и даже проходить архитектурные интервью( что не одно и тоже) . Скорее можно получить представление о задачах и ожиданиях на таких интервью.
С одной стороны базовая джава и concurrency вместе, и нужно их отличное знание. Если базовая джава - да, то отличное знание многопоточности - это про сеньора. С другой стороны, почему-то коллекции выделены в отдельный пункт. Конечно знать их надо, но они уже для джунов являются базовыми, а не специфичными для мидлов. В статье мало упора на реально необходимые базовые навыки мидла, только общие слова.
Согласна, обычно и не всякий сеньор отлично разбирается, в силу специфики. Тут реально нужен большой практический опыт, но чтобы мидл. Если у вас мидл отлично понимает concurrency, то что-то не додали вы ему, он сеньор уже.
Мне кажется, если делалось такое исследование, то паралельно нужно было бы предоставить цифры о проценте компаний, заставляющих своих работников перерабатывать самым различным образом без оплаты. И гит дает такую возможность. И там будет далеко не 10%. Мой опыт говорит, что практически все. Конечно можно сказать, что это субъективные данные одного человека. Но так было бы честнее. Интересно, что заставило автора выбрать именно эту тему?
Я работаю тим. лидом давно. Много проектов, несколько контор. Всё так и есть, как описано в статье. Подпишусь под каждым словом. Чтобы остаться на нужном техническом уровне неизбежно придётся перерабатывать, много. То, что модно зовут 'играющим тренером'. Меня почему-то эта формулировка раздражает неимоверно. Нет такого, ты или тренер или игрок :) А так ты реально шестирукий Шива, обязанностей огромное количество, реальных инструментов влияния даже на состав команды не всегда много. Поймала себя на том, что ситуаций, когда ты сел в 10 часов на минуточку и очнулся часов в 5, забыв про завтрак и обед много. Почему стоит работать на этой позиции? Наверное у каждого свой ответ. У меня случались проекты, когда всё нужно было сделать с нуля и тогда это очень интересно. Тим. лид - это стержень, без которого всё рассыплется. Ну или получится лебедь, рак и щука. А так, вот не было ничего, а вот уже что-то закрутилось, живое, и это стоит того :)