Bash, он же возрождённый shell, является по-прежнему одним из самых популярных командных процессоров и интерпретаторов сценариев. Как бы его ненавидели и не пытались заменить, всё равно он присутствует вокруг нас и никуда не собирается исчезать. Если вам приходится писать bash скрипты или вы только планируете этим заняться, данная статья написана для вас.

Самый плохой разработчик — тот, который всё делает по ТЗ. А самый лучший код — не написанный.

«Моя задача — писать код, я разработчик!» — да, это очень удобная позиция. Но людям, которые не только программируют, но ещё и общаются с коллегами, организуют собственную работу и понимают предметную область, платят больше. Потому что они приносят бизнесу больше пользы. Разработчики, которых надо микроменеджерить, чтобы они делали свою работу, никому не нужны.

Основная обязанность разработчика — это решить проблему. Не написать код, не отдать задачу на тестирование, а решить проблему. Писать код по спецификациям может любой дурак (на самом деле тоже нет). А вот решать проблемы — нет. Для этого надо думать и брать на себя ответственность.

Это история не про любовь, мир, жвачку и миссию компании, а про простую способность сделать свою работу так, чтобы она была сделана хорошо. И да, для этого разработчик должен не только уметь программировать, но и уметь общаться с другими людьми, уметь доносить свои мысли, уточнять и понимать, что вообще происходит. То есть уметь договариваться. Да, разработчик должен уметь организовывать свою работу: раскладывать проблему на задачи. Ещё он должен интересоваться продуктом (проектом). Не потому что разработчик так его любит, и не потому, что этого требует Agile, а потому, что живой интерес к продукту и понимание его ценности увеличивает качество решений и стоимость разработчика на рынке. Знание предметной области и её ограничений — первейшее требование для того, чтобы принять правильное техническое и архитектурное решение. И очевидно, что чем меньше руководитель тратит сил на управление сотрудником и чем больше получает результат, — то есть чем выше автономность сотрудника, его самостоятельность и беспроблемность, — тем он ценнее при прочих равных.

Впервые принципы SOLID были представлены в 2000 году в статье Design Principles and Design Patterns Роберта Мартина, также известного как Дядюшка Боб. 

С тех пор прошло два десятилетия. Возникает вопрос - релевантны ли эти принципы до сих пор?

Перед вами перевод статьи Дядюшки Боба, опубликованной в октябре 2020 года, в которой он рассуждает об актуальности принципов SOLID для современной разработки.   

Недавно я получил письмо с примерно следующими соображениями:

Годами знание принципов SOLID было стандартом при найме. От кандидатов ожидалось уверенное владение этими принципами. Однако позже один из наших менеджеров, который уже почти не пишет код, усомнился, разумно ли это. Он утверждал, что принцип открытости-закрытости стал менее важен, так как по большей части мы уже не пишем код для крупных монолитов. А вносить изменения в компактные микросервисы - безопасно и просто.

Принцип подстановки Лисков давно устарел, потому что мы уже не уделяем столько внимания наследованию, сколько уделяли 20 лет назад. Думаю, нам стоит рассмотреть позицию Дена Норса о SOLID - “Пишите простой код”

В данной статье я предлагаю рассмотреть проблемы, с которыми за 2020-й удаленно-пандемийный год столкнулись множество разных команд и компаний, понять, что пошло не так при переходе из офиса на удаленку.

Да, я понимаю, что уже 2021-й год, и многие уже сами во всём разобрались. Но практика показывает, что это успешно удалось не стольким, скольким хотелось бы.

Всё это я проговаривал в подкасте Кода Кода.

Однако я уверен, что есть такие люди, которым не хочется полчаса слушать подкаст, а хочется за 5-10 минут прочитать структурированный текст. Поэтому я размещу его тут, в надежде на то, что он найдет своего заинтересованного читателя

Небольшой дисклеймер: Я веду телеграм-канал с названием Тимлид Очевидность. Поэтому все мои советы и рекомендации, вроде бы, довольно очевидные и плавают на поверхности. Однако при общении с разными командами оказывается, что не всегда всё настолько ясно и понятно. А еще важно, что ценность очевидных советов ощутимо возрастает, если применять их более-менее комплексно.

Nginx — это веб-сервер, на котором работает треть всех сайтов в мире. Но если забыть или проигнорировать некоторые ошибки в настройках, можно стать отличной мишенью для злоумышленников. Detectify Crowdsource подготовил список наиболее часто встречающихся ошибок, делающих сайт уязвимым для атак.

Nginx — один из наиболее часто используемых веб-серверов в Интернете, поскольку он модульный, отзывчивый под нагрузкой и может масштабироваться на минимальном железе. Компания Detectify регулярно сканирует Nginx на предмет неправильных настроек и уязвимостей, из-за которых могут пострадать пользователи. Найденные уязвимости потом внедряются в качестве теста безопасности в сканер веб-приложений.

Мы проанализировали почти 50 000 уникальных файлов конфигурации Nginx, загруженных с GitHub с помощью Google BigQuery. С помощью собранных данных нам удалось выяснить,  какие ошибки в конфигурациях встречаются чаще всего.

По мотивам своих собеседований, а также собеседований коллег и mentee, составил список вопросов от тимлида к компании, что стоит прояснить на собеседовании — что спросить собеседующего.

Вопросы подойдут, возможно, не только тимлиду, но были придуманы для него.

Каковы финансовые показатели компании?

Является ли компания прибыльной или тратит деньги инвесторов? Или даже до инвесторов ещё не дошло, и основатели пока платят из своего кармана? Как выглядит бизнесовый план развития?

Если компания имеет представительство в РФ, официальное ли (по ТК РФ) трудоустройство и полностью ли "белая" зарплата?

Даже сейчас некоторые компании порой используют "серые" схемы выплат зарплат. Также иногда бывают сотрудники, сознательно просящие "серую" схему.

Расскажите про ваше понимание «хорошего тимлида»

У собеседника должно быть четкое и непротиворечивое понимание, что он вкладывает в понятие «тимлид» и какие критерии используются для оценки работы тимлида.

Возможно, это понимание даже прописано в должностных инструкциях.

Где-то тимлид должен быть разработчиком (то есть, писать код) с минимальной общественной нагрузкой, где-то руководителем, где-то пытаться совместить.

Эта статья не о том, как проходить собеседования, чтобы вас взяли. Она о том, как смотреть на работодателей, чтобы сделать выбор в условиях, когда тексты вакансий, рекрутеры, да и весь процесс найма копируют друг друга. Все работают итерациями, используют Jira, технический стек тоже часто идентичен. С первого взгляда кажется, что это одна и та же кухня. Стоит ли сменить поднадоевшее, но привычное место работы на новое и неизведанное? Как выбрать между двумя офферами с похожими условиями? Как понять, где работать будет комфортно, а где придется терять нервы и интерес к делу?

В этой статье я расскажу, что делаю, чтобы узнать больше о потенциальном работодателе, его процессах, внутренней атмосфере и людях, с которыми предстоит работать. А вот как выбить себе условия покруче, обсуждать не будем. Про плюшки, бонусы и торги по зарплате - это не сюда.

Привет.

Я впервые пишу в поток об управлении и найме персонала. Речь пойдет об одном из способов классифицировать ваших будущих или действующих программистов. Мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Попытка направить неправильный типаж на решение неподходящих для него задач ведет к провалу (неэффективная работа, или сотрудник покидает команду). Хотите знать почему так — добро пожаловать под кат. Приготовьтесь, текста много.