Трудоголики – влажная мечта любого руководителя. Бьющая фонтаном продуктивность, горящие глаза, желание совершенствоваться в профессии и сворачивать горы 24/7… Но зачастую постоянная гонка, жизнь «в колесе» и повышенные требования к самому себе приводят к профессиональному выгоранию.

И здесь, и в других местах в Сети есть масса статей, пропагандирующих автоматическое тестирование вообще и unit-тесты в частности. В статьях расписываются преимущества тестирования, использование его для устранения хрупкого кода, увеличения качества, миграции со старых систем на новые, рефакторинга. И, одновременно, нигде почти не упоминается об их недостатках, а ведь в инженерии нет "серебряных пуль"!

На самом деле "серебряные пули" есть, но их изобрели ещё первые инженеры, и они воспринимаются нами как скучные банальности: "мойте руки перед едой", "вытирайте ноги", "структурируйте код", "не пишите без отступов", "локализируйте состояние" и т.д. Тем не менее, тесты — это не "серебряная пуля", а один из эффективных и широко используемых инструментов, а значит, у него есть недостатки.

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

Почему функциональное программирование? Так тестируем же мы почти исключительно функции.

В феврале мы выяснили, что во втором полугодии 2020 года зарплаты в Москве и Петербурге обогнали региональные на 62%. А затем узнали, что в регионах высокий спрос на айтишников всех специализаций. Но оба этих исследования больше про доходы ИТ-спецов, а что с их расходами? Чтобы картина была полной, мы взяли зарплаты разработчиков в российских городах, наложили на них стоимость жизни в этих городах, и узнали, где России живется выгоднее.

Зарплаты мы традиционно взяли из нашего калькулятора зарплат — там пользователи Хабр Карьеры указывают, сколько они получают на руки после вычета налога. А для расчёта стоимости жизни мы воспользовались данными сервиса Numbeo — глобальной краудсорсинговой базы потребительских цен.

​Почему у многих возникают проблемы с этим принципом? Если ли более простое объяснение?

​️В данной статье мы НЕ будем рассматривать общие примеры данного принципа, о которых уже есть много материалов (пример с квадратом и прямоугольником или управления термостатами). Здесь мы немного подробнее остановимся на таких понятиях как «Предусловия», «Постусловия», рассмотрим что такое ковариантность, контравариантность и инвариантность, а также что такое «исторические ограничения» или «правило истории».

Привет, Хабр! Меня зовут Ваня Антипин, я Deputy CTO в компании AGIMA. Сегодня я постараюсь вам рассказать про роль техлида в компании. Напомню, что в октябре 2020 года мы говорили о роли тимлида в компании и команде. Если кратко, пришли к тому, что от него зависит многое, включая эффективность команды, достижение поставленных целей, оперативное решение рабочих тасков. 

Привет, Хабр! Как и многие другие, в прошлом году мне пришлось внезапно мигрировать из тесного привычного офиса к себе домой. Я и раньше работал из дома, когда была такая нужда. Но чтобы несколько месяцев подряд — такое со мной случилось впервые. Появилось свободное время, которое я сначала не знал, куда девать. Но потом приспособился, начав изучать вещи, до которых раньше не доходили руки.

Я поковырялся в инвестиционных играх на бирже, познакомился с облачным геймингом, а ещё успел почитать о том, что за зверь такой появился, про который из каждого умного утюга говорят — Kubernetes. Начав с блога Фланта, я убедился, что конкретно мне и конкретно сейчас эта штука не нужна, но выглядит она интересно.

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

От подработок на 500 долларов – до контрактов на миллионы. Подробная история бизнеса «с нуля» со взлетами и падениями

На днях я зафиксировал круглую дату – 15 лет с момента регистрации моей первой IT-компании (было это 25 апреля 2006 года) – так что захотелось немного поделиться опытом, да и, чего греха таить, слегка предаться ностальгии. Опыт этот, думаю, будет многим интересен – как создать бизнеса с нуля, как его развить, как пережить кризис (а мировой финансовый кризис 2009 года можно поставить ближе всего к удару пандемии по экономике в наши дни), вновь возродить компанию и найти новые ниши для развития, создавая свой уникальный продукт.

Бессерверные вычисления (или serverless-технологии, как их иногда называют) — это перспективная технологическая модель облачных вычислений, появившаяся на горизонте прикладной разработки и архитектуры в последние годы. Именно благодаря стремлению воспользоваться огромным потенциалом бессерверных фреймворков многие крупные рыночные игроки оказались увлечены общим бумом облачных сервисов. Такие гиганты программной отрасли, как Google, Microsoft, IBM и Amazon, уже предлагают своим клиентам перенести локальные бизнес-процессы и обеспечить операционную эффективность на флагманских бессерверных платформах, таких как AWS Lambda и Azure Functions.

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

Более того, выбор бессерверных сервисов позволяет оптимизировать процессы разработки приложений и таким образом повысить результативность других практик по оптимизации бизнес-процессов, включая DevOps и Agile.

Вам нужно сделать аудит рекламной кампании для нового клиента или разобрать накопившиеся материалы для обучения, но никак не получается даже приступить. Что же мешает – лень или прокрастинация? Казалось бы, вся разница между этими понятиями заключается в эмоциональной окраске. У лени она ярко негативная, у прокрастинации – нейтральная. На самом деле это два отдельных состояния. Они в чем-то схожи, но различны по психологической природе, причинам и особенностям.

Но что еще важнее, бороться с этими состояниями тоже нужно по-разному. И то, и другое доставляет неприятности и мешает достигать целей. Чтобы справиться с ними и наконец начать действовать, сначала нужно понять: вы прокрастинируете или просто ленитесь. В статье разберемся, чем отличается прокрастинация от лени и как бороться и с тем, и с другим.

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

Всё это я проговаривал на вебинаре в Хекслете тут https://www.youtube.com/watch?v=y_HkXvFovAc

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

Общий стаж моей работы в ИТ - около 14 лет. Я начинал с системного администрирования, потом перешел в разработку, поработав как в аутсорсе, так и в продукте. Не один раз проходил путь от рядового разработчика до тимлида.

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

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

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

Привет. Меня зовут Вадим Бараненко. С украинским офисом EPAM я сотрудничаю в роли архитектора решений. И в этом материале я хотел бы поделиться своими взглядами и опытом в такой интересной теме, как парное программирование (далее — ПП).

С ПП я впервые познакомился около 9 лет назад и практиковал этот подход на разных проектах — часть в харьковском офисе EPAM, часть на территории заказчика в Англии. И этот опыт показался мне интересным и полезным.

Вчера я заглянул на страницу Википедии, посвященную кольцевому буферу (circular buffer), и был заинтригован предполагаемой техникой оптимизации, с которой до этого не был знаком: 

Реализация кольцевого буфера может быть оптимизирована путем отображения нижележащего буфера в двух смежных областях виртуальной памяти. (Естественно, длина нижележащего буфера должна в таком случае равняться некоторому размеру кратному страницы страницы системы.) Чтение и запись в кольцевой буфер могут выполняться в этой реализации с большей эффективностью посредством прямого доступа к памяти; те обращения, которые выходят за пределы первой области виртуальной памяти, автоматически переходят в начало нижележащего буфера. Когда смещение чтения продвигается во вторую область виртуальной памяти, оба смещения - чтения и записи - уменьшаются на длину нижележащего буфера.

В рамках реализации кольцевого буфера нам необходимо обработать случай, когда сообщение попадает на «разрыв» в очереди и должно быть перенесено (wrap around). Очевидная реализация записи в кольцевой буфер может полагаться на побайтовую запись и выглядеть примерно так:

На написание этой статьи меня подтолкнуло обсуждение докладов с Heisenbug 2021 в нашем корпоративном чате. Причиной является тот факт, что достаточно много внимания уделяется «правильному» написанию тестов. В кавычках — потому что на бумаге все действительно логично и аргументированно, однако на практике такие тесты получаются достаточно медленными.

Эта статья ориентирована скорее на новичков в программировании, но возможно кто-то сможет вдохновиться одним из описанных далее подходов.