Не так давно, я заинтересовался трудами идеологов программирования, таких как Кент Бэк, Роберт Мартин, Мартин Фаулер, Пол Дюваль.

Их книги произвели на меня впечатление и воодушивили попробовать некоторые описанные практики. Refactoring, TDD, XP, и, наконец, Continuous Integration, это то, что в последнее время интересует меня в процессе разработки программного обеспечения.

Хочу поделиться с хабросообществом тем, что я вынес из книг и с чем приходится сталкиваться в реальности.

Теория

Continuous Integration (далее CI) — это практика разработки программного обеспечения, в которой члены команды проводят интеграцию не реже чем раз в день. Результаты интеграции проверяются автоматически, используя автотесты и статический анализ кода.

Использование CI позволяет вовремя отслеживать ошибки интеграции, сделать систему и процесс разработки более «прозрачными» для всех участников команды, также, CI избавляет от рутинных операция по сборке продукта, повышает качество продукта, включает в себя профит от написания тестов, который, я думаю, для всех хаброюзеров очевиден.

Фактически, CI позволяет избавиться от предположений, при процессе разработки ПО. Менеджер предполагает, что продукт готов и стабилен, программист — что в коде нет ошибок и т. д. Избавиться от вопросов, таких как: «стабильна ли последняя сборка, какие фичи готовы, соответствует ли код стандартам компании» и т.д.

Всех, кому интересна тема CI прошу под кат.

Эпиграф:
Муж, глядя на чумазых детей, говорит жене: ну, что, этих отмоем или новых нарожаем?

Под катом рассуждения нашего тимлида, а также директора по развитию продукта RAS — Игоря Марната об особенностях мотивации программистов.


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

Вычисление ряда Фибоначчи — это классическая алгоритмическая задача, потому её нередко дают на собеседованиях, когда хотят проверить, что кандидат в принципе хоть как-то умеет в алгоритмы. Предположим, вы тот самый кандидат. Вам дали задание: на языке JavaScript написать функцию fib(n), возвращающую энное число Фибоначчи. Считаем, что нулевое число Фибоначчи — это нуль. Проверка корректности аргумента не требуется. Какие у вас есть варианты?

Вступление

Наверняка первый вопрос, который возник у вас при взгляде на заголовок, был "Шта?". На самом деле я просто перевел фразу "Инверсия управления, внедрение зависимости" в Google Translate на китайский, а затем обратно. Зачем? Затем, что на мой взгляд, это хорошая иллюстрация того, что происходит на самом деле. Люди вокруг путают, коверкают и извращают эти понятия. По долгу службы я провожу много интервью, и 90% того, что я слышу, когда задаю вопрос про DI — честно говоря, откровенный бред. Я сделал поиск по Хабру и нашел несколько статей, которые пытаются раскрыть эту тему, но не могу сказать, что они мне сильно понравились (ладно, ладно, я проглядел только три первых страницы, каюсь). Здесь же на Хабре я встречал в комментариях такую расшифровку IoC, как Injection of Container. Кто-то всерьез предполагает, что есть некий механизм инъекции контейнеров, который сосуществует где-то рядом с DI, и, видимо, даже делает нечто похожее. Только с контейнерами. Мда. На самом деле понять внедрение зависимости очень просто, надо всего лишь…

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

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

• Какой технологической экспертизой я должен обладать?
• Какие навыки/качества являются ключевыми, чтобы быть успешным в этой роли?

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

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

Итак, начнем. Нашего первого гостя зовут Антон Данилов. Антон — Group Product Manager в Wrike, руководит направлением Enterprise. В прошлом Антон отвечал за инфраструктуру онлайн-продаж в Лаборатории Касперского, а до этого работал в Microsoft и Sun Microsystems. Общий стаж в продакт менеджменте – больше 10 лет.

Итак, вы решили сделать новый проект. И проект этот — веб-приложение. Сколько времени уйдёт на создание базового прототипа? Насколько это сложно? Что должен уже со старта уметь современный веб-сайт?

В этой статье мы попробуем набросать boilerplate простейшего веб-приложения со следующей архитектурой:

Что мы покроем:

• настройка dev-окружения в docker-compose.
• создание бэкенда на Flask.
• создание фронтенда на Express.
• сборка JS с помощью Webpack.
• React, Redux и server side rendering.
• очереди задач с RQ.

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

У этих классических отношений есть вариации — опционы, проценты, бонусы, которые немного напоминают, что владельцы и сотрудники в одной лодке. Но бывают и менее типичные ситуации.

Компания Флант состоит из нескольких команд девопосов, которые обслуживают чужие продакшены под ключ. Они выросли из банды студентов-энтузиастов и фанатов Linux, а сейчас построили структуру «бизнесов внутри бизнеса», просто потому что так комфортнее и честнее. Дима Столяров и Саша Баталов рассказали нам, как это устроено.

Флант попал в рейтинг лучших ИТ-работодателей 2018 со средней оценкой 4.68. Судя по оценкам компании на «Моём круге», сотрудники верят, что компания делает мир лучше, а ещё ценят Флант за интересные задачи, хорошие отношения в коллективе, современные технологии и связь с топ-менеджментом.

Привет, Хабр!

Мы занимаемся HR в ИТ, с небольшим уклоном в экономику и организацию труда. Придумываем подходы, инструментарий и первые эксперименты ставим на себе.

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

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

История про график работы. Управление им и контроль.
Место действия: Москва и Киев. Распределенный коллектив.
Интеллектуальный труд. Самоокупаемая коммерческая компания.
Продолжительность эксперимента: примерно 6 лет.

Подробности под катом.

При создании технического задания клиенты часто отправляют много ссылок на сайты для понимании бизнес задач. Например: хочу регистрация и авторизацию как у twitter, список с новостными блоками как в Яндекс Дзен и т.д. Очень сложно такие части проекта задокументировать, хочется их оформить визуально с помощью вайрфреймов.

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

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

Добрый день.

Предлагаю вашему вниманию перевод юмористического поста, посвященного облачным технологиям: It's The Future. Всяческие поправки и советы привествуются.

Содержание

• Вопросы и ответы
  
• Введение
  
  • Пре-реквизиты
    
  • Настройка компьютера
    
  
  
• 1.0 Играем с Busybox
  
  • 1.1 Docker Run
    
  • 1.2 Терминология
    
  
  
• 2.0 Веб-приложения и Докер
  
  • 2.1 Статические сайты
    
  • 2.2 Образы
    
  • 2.3 Наш первый образ
    
  • 2.4 Dockerfile
    
  • 2.5 Docker на AWS
    
  
  
• 3.0 Многоконтейнерные окружения
  
  • 3.1 SF Food Trucks
    
  • 3.2 Сети Docker
    
  • 3.3 Docker Compose
    
  • 3.4 AWS Elastic Container Service
    
  
  
• 4.0 Заключение
  
  • 4.1 Следующие шаги
    
  • 4.2 Фидбек автору
    

Вопросы и ответы

Что такое Докер?

Определение Докера в Википедии звучит так:

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

Ого! Как много информации.

Примерно такие же эмоции я и мои коллеги испытывали, когда начинали работать с Docker. В подавляющем большинстве случаев это происходило от недостатка понимания основных механизмов, поэтому его поведение казалось нам непредсказуемым. Сейчас страсти поутихли и вспышки ненависти происходят все реже и все слабее. Более того, постепенно мы на практике оцениваем его достоинства и он начинает нам нравиться… Чтобы снизить степень первичного отторжения и добиться максимального эффекта от использования, нужно обязательно заглянуть на кухню Docker'a и хорошенько там осмотреться.

Технологии контейнеризации приложений нашли широкое применение в сферах разработки ПО и анализа данных. Эти технологии помогают сделать приложения более безопасными, облегчают их развёртывание и улучшают возможности по их масштабированию. Рост и развитие технологий контейнеризации можно считать одним из важнейших трендов современности.

Docker — это платформа, которая предназначена для разработки, развёртывания и запуска приложений в контейнерах. Слово «Docker» в последнее время стало чем-то вроде синонима слова «контейнеризация». И если вы ещё не пользуетесь Docker, но при этом работаете или собираетесь работать в сферах разработки приложений или анализа данных, то Docker — это то, с чем вы непременно встретитесь в будущем.

→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными



Если вы пока не знаете о том, что такое Docker, сейчас у вас есть шанс сделать первый шаг к пониманию этой платформы. А именно, освоив этот материал, вы разберётесь с основами Docker и попутно приготовите пиццу.

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

Я не понял ни слова из предложения и стал разбираться, как это может помочь мне как разработчику.

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

Привет, Хабр! Несколько месяцев назад у меня остро встал вопрос смены профиля деятельности и я обнаружил, что для претендента на вакансию web-разработчика сейчас недостаточно навыков десятилетней давности (какая неожиданность!). Пришлось срочно актуализировать свои знания. Заодно я решил составить шпаргалку с описанием большинства современных технологий, чтобы в случае чего кидать жаждущим новых знаний линк на эту статью, да и самому не забывать.

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

Наши привычки постоянно развиваются и меняются. Изменяется стиль кодирования, подход к написанию кода в целом. Обычно это хорошо, но иногда этот процесс минует некоторые плохие привычки и они надолго остаются с нами. Я хотел бы поделиться размышлениями о некоторых «не очень хороших» привычках, которые я наблюдал в себе и в других людях на протяжении многих лет. Некоторые даже могут быть не похожи на плохие…

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

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

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

Девушки-программистки носят свитер и толстые очки. С чем, кроме алгоритмов, борются айтишницы?

От переводчика: больше всего мне хотелось бы этот текст (написанный, кстати, девочкой) поместить в юмор. Но как человек, который регулярно видит вокруг себя зашкаливающее количество умных и красивых программисток, я волевым усилием вынудил себя этого не делать. Эта статья — взгляд на известный стереотип с женской стороны. Хотя автор плохо различает понятия «программист» и «IT-специалист», почитать имеет смысл и довольно забавно.

Информационные технологии нельзя оставить мужчинам. Они слишком важны. Для этого не надо менять мысли женщин, достаточно изменить отношение к программисткам тех, кто с IT не имеет вообще ничего общего. Баб к компам!

Судя по комментариям к посту о небесной воде, среди читателей есть некое недопонимание вопросов ядерной энергетики. Я хочу внести некую ясность в этот вопрос. Многим то, что я напишу, покажется элементарщиной, но, к сожалению, не всем.