Недовольных так мало только потому, что ведущие интернет ресурсы так вяло на это все реагируют. А у нашего правительства есть зомбоТВ… Тем не менее, аудитория интернета так же не маленькая. И планомерное «анти промывание мозгов» — разъяснение вредности принимаемых законов — помогло бы 10-12% превратить в 25-30% и более…
Я не могу понять только одного — после стольких неадекватных законопроектов эта дума все еще не распущена? Все интернет ресурсы кипят гневными обсуждениями, но в реале — все довольны? Почему ключевые интернет ресурсы не ведут активную борьбу с такими законопроектами вплоть до сбора подписей о вотуме недоверия? Ведь большинство законов непосредственно касается деятельности как раз этих ресурсов.
Я бы оставался на раздаче, если бы мне вернули 10% процентов от изначальной стоимости за 3-5 копий. Не обязательно выходить в ноль. И даже не обязательно оставаться после этого на раздаче, ведь всегда будут те, кто захочет так же получить эту скидку, а значит на раздаче всегда кто то будет. Так же, меня привлекла бы система бонусных баллов, за которые я бы мог получить скидку на другой контент этого правообладателя.
Я говорю про себя, но уверен, такой (или похожей) системой бы пользовались многие. ИМХО, правообладателям просто не хочется прорабатывать такие схемы. Проще по старинке. И наказывать «преступников»…
А вы думаете, что человек, который ничего не делал, но написал «отличное» эссе — написал его не общими фразами? И если бы мне сунули такое, как референс «как надо делать», я бы чисто из принципа в следующий раз выслал бы его слово в слово. Хотя нет, вру, я бы раньше уволился. Т.к. если меня не оценивают по моей работе, если мне в качестве «правильного» варианта бессмысленной траты времени подсовывают набор красивых фраз (догадаться чье это авторство не сложно) — я считаю, что работать в такой компании как минимум не комфортно.
Ок, в следующий раз Петя тоже напишет массу общих фраз, какой он хороший. И все это превратиться в «накосили, надоили». Реального же положения дел в команде, на проекте под этими фразами не будет. Зато мы красиво отпишемся начальству. Офигенный тимлид. Дайте два!
А Петя и так спустя некоторое время поймет, что за место под солнцем надо бороться и молчать — это не лучший вариант. Особенно если его непосредственный начальник не ведет себя как начальник, а стремится сломать барьер начальник-подчиненный, если старается разговорить коллегу, если пытается найти к нему индивидуальный подход (а не «на смотри как надо»).
А учить «как надо» надо Васю. Учить, как надо работать, как надо код писать.
Может быть Вы не правильно разговоры ведете? Беседы с подчиненными подразумевают диалог. И чем ваши устные вопросы и необходимость ответить на них отличаются от вопросов в эссе? Просто помимо беседы (или того же эссе) важны и другие моменты. После performance review человек должен четко представлять:
1. Свой текущий уровень. Причем его понимание должно минимально отличаться от представления о нем коллег и тимлида. ИМХО, помочь составить о себе такое мнение можно только в результате «душевной», доверительной беседы.
2. Свои сильные стороны. Важно что бы человек понимал, в чем он крут, за что его ценят. Это позволит ему чувствовать себя увереннее.
3. Свои слабые стороны. Важно дать понять, что есть и проблемы. Но мало потыкать, как котенка, мордочкой в лужу. Необходимо вместе с человеком обсудить эти проблемы и их влияние на развитие, добиться понимания важности/неважности этих пробелов.
4. Перспективу своего развития. Это может быть что угодно от плана развития до устной договоренности. Но лучше записать. Важно, что бы эта перспектива была реальна, выполнима, ее можно было проверить (измерима) и что бы вы, как начальник, не забыли про это все.
5. Пути достижения нового уровня.
6. Какие плюшки он от этого получит.
7. Какое наказание он понесет, если ничего не изменится/станет хуже.
Да, эссе, тесты, анкеты могут Вам помочь. Но они являются лишь вспомогательным средством, полезность которого не всегда высока. Основой же должны быть результаты работы человека и активное участие непосредственного начальника в трудовой жизни работника.
+Отвлечение людей от работы различными нерабочими заданиями (анкетами, эссе) вызывают раздражение и волну негатива. Статистики у меня конечно нет, но подавляющее большинство моих коллег крайне резко относятся к подобным вещам. А мы ведь за позитив на работе?
Делегирование обязанностей (и ответственности) — это конечно хорошо. Только в полезность такого делегирования верится с трудом. Предположим, есть команда и есть тимлид. Они вместе трудятся над проектом. Тимлид прекрасно осведомлен, как справляются с заданиями его субординаты. Если, конечно, тимлид не работает спустя рукава. Он обязан знать, что Петя, для своего уровня, работает за двоих, а Вася, напротив, заваливает любое задание, какое бы ему не дали. И вот этот тимлид говорит: напишите, кто что сделал для проекта. И Петя, поскольку он скромный человек и вообще интроверт, пишет: работал мол, выполнял все задачи. А Вася, имея неплохо подвешенный язык, расписывает какой он офигенный и как он полезен для проекта. Что имеем в остатке? Если тимлид не следил за проектом, он прочтет замечательное сочинение Васи и продвинет его. А Петя, будь он хоть трижды хорошим разработчиком, будет и дальше тянуть проект (а скорее всего, просто уволится). Если же тимлид в курсе дел на проекте, то он просто выкинет эти сочинялки и напишет свой отчет. И КПД от такого подхода стремится к нулю. А вот побеседовать с глазу-на-глаз с Петей и Васей, объяснить им ситуацию, помочь разобраться в ситуации и в себе, возможно, зафиксировать какие то тезисы и положения в индивидуальном плане — это будет куда эффективней. Но это, конечно, требует большей отдачи от тимлида, большей квалификации, причем не в технической области, а в области психологии. И конечно, тимлиду должны быть не безразличны его подчиненные. А это уже вообще большая редкость.
Да, про планы развития я перегнул. План развития должен быть, особенно на начальном этапе. Когда же человек уже состоялся как специалист, он сам знает, как правило, в каком направлении и как он хочет и будет развиваться. Вначале же карьеры, представление об этом очень смутное. И первоочередная задача тим лида — это помочь начинающим выбрать правильный путь. Замечу только, что написание эссе на тему «кем я хочу стать, когда вырасту» тут не особо поможет. А вот душевный разговор со старшими коллегами — это правильный путь.
Не знаю, как в остальных сферах, но в IT все эти эссе, отчеты о проделанной работе за пол года-год, планы развития и прочее — полный бред. Вы работаете не один, вы работаете в команде. Где каждый знает, что делают остальные (если это не так — это проблема управления проектом). И каждый видит результаты работы остальных. И всегда есть общий результат — сдача проекта в сроки/провал проекта по срокам. В такой ситуации даже PR360 выглядит куда более привлекательным и объективным. Но на мой взгляд, лучшую оценку и результат может дать только общение со своим непосредственным начальником (тим лидом, менеджером), человеком, который по долгу службы знает о вас все и с высоты своего опыта может дать более-менее объективную оценку вашим действиям и вашему развитию. И, конечно, помочь в развитии вас, как специалиста. Если же по каким то причинам ваш непосредственный начальник не в состоянии выполнить эту функцию — это повод задуматься.
А доказывать, что ты не верблюд — это, на мой взгляд, порочная практика. Если начальник (компания) считает, что я не приношу пользу — пусть увольняют. Я найду место работы, где меня по достоинству оценят и где мне не придется каждый раз пустыми словами доказывать, что я полезен. За меня будут говорить результаты моей работы.
Если давать осмысленные имена переменным и правильно расставлять отступы, то 80 символов порой не хватает. У меня как то исторически сложилась граница в 100 символов. Более длинная — уже не всегда охватишь взглядом. Ну и конечно, граница не жесткая. Если что то не помещается на пару символов — я прощаю. Форматирование по ширине автоматическое.
SLF4J — это не конкретная реализация системы логирования, это фасад логирования. Под который можно легко подложить любую другую, конечную систему логирования, без каких либо конфигов со стороны slf4j. Чем этот подход отличается от Apache Commons Logging? Практически ничем. При этом, Apache Common Logging имеет ряд проблем, из-за которых многие отказываются от него в пользу slf4j.
Что касается описанной проблемы с Jetty, Wicket и вашим приложением… На вскидку могу предположить, что имели место конфигурационные проблемы, возможно не было необходимых slf4j бриджей. В моей практике slfj4 не доставлял проблем. Хотелось бы взглянуть на проблемный пример в живую.
Библиотека уж тем более должна использовать slf4j, что бы не зависеть от конкретной системы логирования. Да и в любом проекте лучше через нее работать.
А в чем проблема то? Проект не должен зависеть от системы логирования. Сами по себе логгеры похожи. Не думаю, что в Log4j2 будет что то революционное. Возможно он будет незначительно быстрее… Возможно будет иметь несколько удобных, но не везде необходимых фич. Проблема перехода с одной системы логирования на другую — проблема конфигурирования. Затруднения могут вызвать только кастомные аппендеры — не частая встречающаяся задача.
То, что есть конкуренция — это хорошо. Технология не застаивается, есть альтернатива, можно выбрать именно то, что подойдет для твоего конкретного проекта.
Функциональность у Log4j и Logback практически идентичная. Logback в свое время «учился» на ошибках Log4j, исправлял их. Теперь, судя по заявлениям разработчиков Log4j2, они занимаются исправлением «ошибок» архитектуры Logback'а.
Но он пока сыроват и только в beta версии… Выйдет полноценная версия — можно будет потрогать. В большинстве случаев, лучше использовать slf4j и не зависеть от конечной системы логирования.
А почему бы не использовать для этих целей готовое решение slf4j + logback + стандартные логбэковские аппендеры (SocketAppender, DBAppender)?
Log4j, как мне кажется, уже устарел. И его используют только по инерции.
Вопрос о подходах unit-тестирования, а так же о том как и где их применять — это тема отдельной статьи и отдельного обуждения… В этой статье был обзор возможностей PowerMock для создания детализированных тестов.
И позвольте Вам возразить. Конечно, Вы частично правы. При таком подходе тесты будут завязаны на коде. И в случае изменений кода потребуется время на изменение тестов. Но это не всегда плохо. Упавший тест — повод задуматься: «А все ли я сделал правильно? Может кто то неспроста до меня сделал именно так?» Плюс ко всему, есть ряд ситуаций, когда тестирование по «внешним проявлениям» не подойдет. Простой пример: есть некий метод, предположим, public void open(), который как мы видим не принимает и не возвращает параметров. Внутри него происходит последовательный вызов нескольких функций из внутренних объектов (возможно так же и статические). Скорее всего, состояние тестируемого объекта изменится. Но, во-первых, это состояние может быть чисто внутренним и не торчать наружу. А следовательно, что бы его проверить необходимо производить танцы с бубном (или использовать PowerMock для удобного доступа к private полям). Во-вторых, в тестируемом методе наверняка важен порядок выполнения внутренних вызовов. Как Вы будете это проверять?
Думать о том, что свалится, если в этом методе что то будет не вызвано — это совсем другая задача, другого теста. Этот же метод вы оставите не протестированным.
Повторюсь, я утверждаю, что все тесты должны быть только такими. Все всегда зависит от ситуации. Просто всегда понимайте что вы делаете и что это может повлечь. Вы тестируете систему детально — будьте готовы к переделке тестов при рефакторинге архитектуры. Вы тестируете систему интеграционно в виде BlackBox — готовьтесь к тому, что внутри система может вести себя не корректно, а ваши тест кейсы просто не способны отловить эту особенность. И никогда не стоит говорить: «я крут и со мной такого не случится». Практика показывает, что случится. Причем в самый не подходящий момент.
Есть два подхода к тестированию — BlackBox & WhiteBox. Если проверять только результат выполнения метода — это BlackBox тестирование. Если тестировать с проверкой всех «потрохов» — это WhiteBox подход. Мне позарез надо знать, что был вызван метод flip(), а не ручками выставлены значения. А то ведь всякое бывает.
А реальный кейс… Может Вы и сами скоро с подходящим столкнетесь. А если нет — тем лучше. Значит Вам конкретно эта функциональность PowerMock'а не пригодится. Но ведь важно просто знать, что возможность есть, что бы быть готовым.
Опять же, всегда можно придраться, почему ByteBuffer не приходит извне функции. Но еще раз напоминаю, что это лишь пример, такой же сферический, как те, которые приведены в статье. Однако, похожие ситуации в жизни не раз бывали и в них не к чему было придраться. Просто на вскидку сложно вспомнить что то конкретное.
Да, в этом примере очень бы хотелось проверить, выполняется ли flip() для буфера. Предположим, что если его кто то удалит, все будет плохо.
Я говорю про себя, но уверен, такой (или похожей) системой бы пользовались многие. ИМХО, правообладателям просто не хочется прорабатывать такие схемы. Проще по старинке. И наказывать «преступников»…
А Петя и так спустя некоторое время поймет, что за место под солнцем надо бороться и молчать — это не лучший вариант. Особенно если его непосредственный начальник не ведет себя как начальник, а стремится сломать барьер начальник-подчиненный, если старается разговорить коллегу, если пытается найти к нему индивидуальный подход (а не «на смотри как надо»).
А учить «как надо» надо Васю. Учить, как надо работать, как надо код писать.
1. Свой текущий уровень. Причем его понимание должно минимально отличаться от представления о нем коллег и тимлида. ИМХО, помочь составить о себе такое мнение можно только в результате «душевной», доверительной беседы.
2. Свои сильные стороны. Важно что бы человек понимал, в чем он крут, за что его ценят. Это позволит ему чувствовать себя увереннее.
3. Свои слабые стороны. Важно дать понять, что есть и проблемы. Но мало потыкать, как котенка, мордочкой в лужу. Необходимо вместе с человеком обсудить эти проблемы и их влияние на развитие, добиться понимания важности/неважности этих пробелов.
4. Перспективу своего развития. Это может быть что угодно от плана развития до устной договоренности. Но лучше записать. Важно, что бы эта перспектива была реальна, выполнима, ее можно было проверить (измерима) и что бы вы, как начальник, не забыли про это все.
5. Пути достижения нового уровня.
6. Какие плюшки он от этого получит.
7. Какое наказание он понесет, если ничего не изменится/станет хуже.
Да, эссе, тесты, анкеты могут Вам помочь. Но они являются лишь вспомогательным средством, полезность которого не всегда высока. Основой же должны быть результаты работы человека и активное участие непосредственного начальника в трудовой жизни работника.
+Отвлечение людей от работы различными нерабочими заданиями (анкетами, эссе) вызывают раздражение и волну негатива. Статистики у меня конечно нет, но подавляющее большинство моих коллег крайне резко относятся к подобным вещам. А мы ведь за позитив на работе?
А доказывать, что ты не верблюд — это, на мой взгляд, порочная практика. Если начальник (компания) считает, что я не приношу пользу — пусть увольняют. Я найду место работы, где меня по достоинству оценят и где мне не придется каждый раз пустыми словами доказывать, что я полезен. За меня будут говорить результаты моей работы.
Что касается описанной проблемы с Jetty, Wicket и вашим приложением… На вскидку могу предположить, что имели место конфигурационные проблемы, возможно не было необходимых slf4j бриджей. В моей практике slfj4 не доставлял проблем. Хотелось бы взглянуть на проблемный пример в живую.
То, что есть конкуренция — это хорошо. Технология не застаивается, есть альтернатива, можно выбрать именно то, что подойдет для твоего конкретного проекта.
Log4j, как мне кажется, уже устарел. И его используют только по инерции.
И позвольте Вам возразить. Конечно, Вы частично правы. При таком подходе тесты будут завязаны на коде. И в случае изменений кода потребуется время на изменение тестов. Но это не всегда плохо. Упавший тест — повод задуматься: «А все ли я сделал правильно? Может кто то неспроста до меня сделал именно так?» Плюс ко всему, есть ряд ситуаций, когда тестирование по «внешним проявлениям» не подойдет. Простой пример: есть некий метод, предположим, public void open(), который как мы видим не принимает и не возвращает параметров. Внутри него происходит последовательный вызов нескольких функций из внутренних объектов (возможно так же и статические). Скорее всего, состояние тестируемого объекта изменится. Но, во-первых, это состояние может быть чисто внутренним и не торчать наружу. А следовательно, что бы его проверить необходимо производить танцы с бубном (или использовать PowerMock для удобного доступа к private полям). Во-вторых, в тестируемом методе наверняка важен порядок выполнения внутренних вызовов. Как Вы будете это проверять?
Думать о том, что свалится, если в этом методе что то будет не вызвано — это совсем другая задача, другого теста. Этот же метод вы оставите не протестированным.
Повторюсь, я утверждаю, что все тесты должны быть только такими. Все всегда зависит от ситуации. Просто всегда понимайте что вы делаете и что это может повлечь. Вы тестируете систему детально — будьте готовы к переделке тестов при рефакторинге архитектуры. Вы тестируете систему интеграционно в виде BlackBox — готовьтесь к тому, что внутри система может вести себя не корректно, а ваши тест кейсы просто не способны отловить эту особенность. И никогда не стоит говорить: «я крут и со мной такого не случится». Практика показывает, что случится. Причем в самый не подходящий момент.
А реальный кейс… Может Вы и сами скоро с подходящим столкнетесь. А если нет — тем лучше. Значит Вам конкретно эта функциональность PowerMock'а не пригодится. Но ведь важно просто знать, что возможность есть, что бы быть готовым.
Опять же, всегда можно придраться, почему ByteBuffer не приходит извне функции. Но еще раз напоминаю, что это лишь пример, такой же сферический, как те, которые приведены в статье. Однако, похожие ситуации в жизни не раз бывали и в них не к чему было придраться. Просто на вскидку сложно вспомнить что то конкретное.
Да, в этом примере очень бы хотелось проверить, выполняется ли flip() для буфера. Предположим, что если его кто то удалит, все будет плохо.