Давно я не писал реально полезных статей. Эта будет посвящена очень важной теме: работе мечты и построению своей карьеры. Я буду писать исключительно о себе, о том, какой я вижу свою идеальную работу и к чему буду стремиться в ближайшее время. Как это может помочь вам и зачем вам вообще читать этот поток сознания? Я надеюсь, что мой пример вдохновит кого-то задуматься о своих карьерных целях и как именно они видят свою работу в идеальном будущем. Без целей и этого видения очень сложно чего-то добиться и реализовать свои мечты. Мне в формулировке своих целей очень сильно помог недавний перерыв в работе, во время которого я больше сил сосредоточил на консалтинг и смог наконец нормально структурировать свои мысли и пожелания.
Итак, первым шагом нужно определиться с движущими факторами. Чего вы хотите добиться? Деньги, важная должность, интересная повседневная работа, постоянное развитие, стабильность, переезд в другую страну? Я для себя давно решил, что моим выбором руководят факторы наличия интересных вызовов и постоянное развитие. Они тесно связаны между собой, потому что я верю в толчок к развитию в виде вызова, который заставляет тебя выйти из зоны комфорта и шевелиться в нужном направлении. Вызовы я для себя классифицировал следующим образом в порядке убывания важности:
Команда докладчиков на предстоящую конференцию XP Days Ukraine уже начала формироваться. Мы ожидаем много интересных докладов в этом году от зарубежных и отечественных экспертов. А пока продолжаем публиковать ТОП-10 докладов с прошлого года. В этот раз 7-е место и доклад Николая Алименкова “How TDD helps to produce better design, or not?”.
Описание доклада:
TDD is well known approach to develop more clear and less buggy solutions, completely covered with tests as a bonus. But what about design? Some people think that TDD also helps design to emerge as implementation grows, so there will be just enough design in place when all cases are covered. Others think that without general design skills and experience output from TDD will be a garbage from design perspective. In this talk we will try to cover this topic in all details, focusing on TDD usage at different levels and with different styles.
Видео:
Не забывайте делиться с нами идеями потенциальных докладчиков для приглашения на XP Days Ukraine 2017, программный комитет будет рад услышать ваши мнения и пожелания.
Недавно снова вспомнил свою статью про качества хорошего ScrumMaster, без которых пользы от него команде мало. И в обсуждениях сторонники “классических” подходов начали утверждать, что для успешной работы с командой нужна власть. Это очень забавное мнение на мой взгляд, поэтому я решил посвятить ему отдельную небольшую статью.
Мы живем в очень технологическом мире, когда новые технологии появляются чуть ли не ежедневно, и при этом кто-то все равно продолжает верить, что в разработке ПО власть реально помогает достигать результата. Давайте обратимся для начала к определению:
Мне никогда не нравилась метрика цикломатической сложности (cyclomatic complexity), которую большинство инструментов использует для анализа сложности кода. Просто она задумана скорее для того, чтобы показать вариативность сценариев в коде, что, естественно, влияет на его сложность, но не всегда прямолинейно. Посыл идет скорее к сложности тестирования, чтобы убедиться что код работает правильно. В случае автоматизации тестирования, цикломатическая сложность говорит нам сколько тестов нужно написать на этот код. В случае ручного тестирования – сколько должно быть разных сценариев для этого кода (тут на деле еще сложнее, потому что не до каждого такого сценария может добраться легко ручное тестирование).
Доклад “The portrait of professional developer 3.0”
Николай Алименков
Сегодня пятница, поэтому можно написать не такой серьёзный пост как обычно. Речь пойдёт о моей нелюбви к машинам и водителям на польских и литовских бляхах. Эта тема не раз обсуждалась в фейсбуке и люди разделились на два лагеря: поддерживающие эту тенденцию с лозунгом “не будем платить пошлины государству” и ненавистники под флагом “остановим жесть на дорогах страны”.
Я больше отношусь ко второму лагерю и на то есть вполне конкретные причины. Чтобы лучше их понять, я продемонстрирую распространённые аналогии из мира IT. Сначала для тех кто не в курсе краткое описание ситуации: в Литве и Польше открываются компании, которые на себя регистрируют служебные автомобили и заодно наших граждан в качестве липовых сотрудников, что даёт им право ездить по территории Украины вроде как практически легально. И все это сопровождается пиар компанией вида: “за сумму $XXX вы можете купить отличный BMW в Литве или Ланос в Украине, все из-за грабительских пошлин государства”.
За последние несколько лет термин DevOps стал настолько привычным, что без него не обходится ни один проект. К большому сожалению, в подавляющем большинстве случаев люди упускают из внимания первопричину появления DevOps движения и те проблемы, которое оно призвано было решить. Еще печальнее осознавать, что неправильное понимание до такой степени укоренилось и распространилось, что воспринимается большинством как стандарт де-факто. Даже на встрече DevOps сообщества в докладах говорят только про обязанности конкретных людей и инструменты для конкретной роли в проекте.
Самым распространенным заблуждением является то, что DevOps – это конкретный человек, который обладает по сравнению с традиционным системным администратором дополнительными навыками и знаниями определенных инструментов: компоненты CI/CD (CI сервер, репозиторий артефактов, динамические языки для написания конфигураций, инструменты сборки приложений и т.д.), централизованное логирование (ELK стек, Splunk и прочие), управление облачной инфраструктурой (AWS, Azure, Heroku и т.д.), инструменты для деплоя приложений и конфигурации окружения (Ansible, Chef, Puppet и другие), контейнеризация (Docker, Kubernetes, Swarm и т.д.). Эдакий эксперт, который будет помогать несмышленым разработчикам собрать и задеплоить свой код на разные окружения.
