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

В октябре прошлого года я летал в Сибирь на TEDx Novosibirsk и в самолёте внезапно оказался рядом с другим спикером – Павлом Буковым. Он психотерапевт и собирался сделать доклад про профессиональное выгорание: как бы выгорать пореже и не дотла. Я, естественно, вспомнил, как год назад выгорел сам. Заодно вспомнил, сколько людей набивается в зал, когда на технологических конференция докладчик рассказывает про выгорание. В общем, пока мы летели в Сибирь, я записал с Павлом эпизод подкаста про стресс и выгорание и решил собрать из него статью.

(часть 1)

Каким должно быть эссе? Многие сказали бы — убедительным. Так нас учили… Но я думаю, что мы можем стремиться к чему-то более амбициозному: эссе должно быть полезным.

Прежде всего эссе должно быть корректным. Но недостаточно просто быть корректным. Легко сделать утверждение корректным, сделав его расплывчатым. Это распространенный недостаток академического письма. Если вы ничего не знаете о предмете, вы не можете ошибиться, сказав, что проблема является сложной, что есть много факторов, которые следует учитывать, что слишком простой взгляд на неё был бы ошибкой, и так далее.

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

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

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

Изображение: Unsplash

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

Сегодня мы поговорим о нескольких подходах к оценке результативности инвестиционного портфеля.

Не за горами очередной старт курса для руководителей разработки «Team Lead 2.0». В связи с этим мы провели открытый урок под названием «Почему мои коллеги/сотрудники ведут себя как @%§?». На вебинаре поговорили о том, что заставляет людей вести себя некорректно, почему люди идут на конфликт, какие есть способы влияния на поведение.

---

Преподаватель — Станислав Михальский, технический директор «Развитие.Ру».

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

В новом проекте в нашей команде мы выбрали frontend framework VUE для нового продукта, бэкенд написан на PHP, и уже как 17 лет успешно работает.

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

Представим команду, где не проводится Code review. Разработчики пишут код, и без проверок вносят все изменения в основную ветку. Спустя время расширяется функционал или находятся баги, они возвращаются к исходному коду, а там все переменные названы одной буквой, нет следования архитектуре, да и качество не самое лучшее. Этот некачественный код будет копиться и однажды наступит момент, когда, при любом мало-мальском нововведении, проект начнёт разваливаться: в лучшем случае – увеличится время разработки, в худшем – поддержка проекта станет невозможной. И это при том, что когда-то давно задача была выполнена и все хорошо работало.

Как этого можно избежать?

Тимлиды часто оценивают проекты, и не все делают это хорошо. Тут многое зависит от личности самого тимлида, а также от его понимания команды. Есть много техник оценки проектов от метода “по аналогии” до PERT. Но сегодня я расскажу о том, как я применяю planning poker и другие приемы, чтобы оценивать точнее и с большей пользой.

HR-специалист одной компании недавно сказал такую фразу: “разработчики не хотят к нам идти, как только узнают, что мы работаем по Agile”. И хотя я сам нередко слышу недовольство, высказываемое разработчиками в отношении Agile, такая категоричность меня удивила.

Ведь одна из целей Agile – создание комфортных условий для работы тех самых разработчиков. Agile-практики стремятся освободить разработчиков от рутины, поощряют творческий подход. Самоорганизация, минимизация бюрократии – всё это призвано упростить жизнь разработчиков. Happiness (счастье) разработчиков – одна из Agile-метрик, которую нужно повышать.

Почему же не стыкуются отзывы реальных разработчиков с декларируемыми целями Agile?

Содержание

• Вопросы и ответы
  
• Введение
  
  • Пре-реквизиты
    
  • Настройка компьютера
    
  
  
• 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 Фидбек автору
    

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

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

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

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

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

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

С 2008 года количество жалоб на дискриминацию по возрасту выросло до 25 000 в год. Можно возразить, что мы везде вынуждены «крутиться» сейчас и всегда найдётся кто-то, кто пожалуется на какую-то несправедливость. Конечно, ОК! Давайте не будем принимать во внимание жалобы. Просто посмотрим на средний возраст сотрудников известных IT-компаний. Фейсбук: 28. LinkedIn: 29. Гугл: 30. Чтобы увидеть объективно — средний возраст работника в США составляет 42 года. Это намного выше среднего возраста в названных выше компаниях. Даже сам Марк Цукерберг однажды публично высказался на каком-то мероприятии в Стэнфорде: «Я хочу подчеркнуть важность быть молодым и технически подготовленным. Молодые люди просто умнее.»

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

Я отошел от своего выгорания только недавно — несмотря на то, что случилось оно несколько лет назад. Да, мне было непросто… очень непросто. Когда я думаю о произошедшем, на ум приходит немало причин тому, что случилось со мной — но самое интересное заключается в том, что каждой из них я никогда раньше не придавал значения. Хотите повторить мой путь и выгореть? Пожалуйста, у меня готов целый список, как следует поступать в таком случае:

1. Думать о проекте и только о нем

Признайтесь себе: бизнес хочет, чтобы вы создавали наилучший продукт «для наших клиентов». Вы откладываете в долгий ящик какой-либо функционал из-за того, что не успеваете к дедлайну. Вы планируете проект и анализируете его со всех сторон для того, чтобы разбить на несколько «перевариваемых» частей, которые затем должны быть воплощены одним из кодеров (в роли обезьянки, или code monkey, кстати говоря, можете быть и вы один). Вы создаете рабочий прототип, затем получаете обратную связь и делаете еще одну итерацию. И все это — без единой мысли о себе любимом.

У Git есть строгие обязательства по обратной совместимости: многие продвинутые возможности скрыты за разнообразными опциями, а не применяются как поведение по умолчанию. К счастью, Git также поддерживает и алиасы, так что вы можете создавать свои собственные команды, которые делают всю характерную для Git магию. Под катом — подборка полезных (или как минимум забавных) алиасов, определённых в моём .gitconfig.

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

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

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

20-го февраля 2020-го года исполняется 34 года с момента запуска и ввода в эксплуатацию космической станции «Мир». Станции, которая была обитаема с 13 марта 1986 года по 16 июня 2000 года. И могла быть обитаема ещё, если бы…

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



23 февраля 1997 года на станции «Мир» должен был погибнуть весь международный экипаж – 4 российских космонавта, один немецкий и один американский астронавт. И тогда станцию «Мир» пришлось бы затопить не планово – весной 2001 года, а вынужденно, на 4 года раньше, с мертвым экипажем на борту. Об этой экспедиции до 2006 года принято было молчать, и до сих пор о ней мало что известно, кроме самих космонавтов и руководителей полета, никто не знал подробностей случившегося. В 2006-м, космонавты 23 международной экспедиции согласились рассказать, что же на самом деле происходило на космической станции, заложниками которой они оказались и Первый канал снял отличный документальный фильм об этом — «Некуда бежать. Пожар на космической станции», который сегодня доступен на Youtube, сайт студии Роскосмоса, почему-то выдаёт ошибку. Возможно потому, что там сказали не всю правду или потому, что правда не совсем та.

Пожар потушили, но он имел страшные последствия. Несколько месяцев космонавтам пришлось жить при температуре более +40 С, дышать ядовитыми парами этиленгликоля, а затем спасать станцию от разгерметизации, вызванной столкновением с 10-тонным грузовым кораблем «Прогресс».

И совсем недавно мой друг нашёл версию произошедшего столкновения от американцев (смотреть с 1:18:00), где астронавт Майкл Фоул, непосредственный участник событий, утверждает, что столкновение было результатом эксперимента по ручной стыковке со станцией, а что самого эксперимента не должно было быть.

И снова здравствуйте. В преддверии старта курса «DevOps практики и инструменты» делимся с вами переводом еще одного интересного материала.

---

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

От А0 до B2 за год

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

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

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

Не могу сказать, что полностью свободно говорю, но чтобы вы лучше понимали, каких результатов удалось достичь, приведу список того, что больше не вызывает у меня проблем:

• Беседа на французском в течение нескольких часов;
• Понимание различных видов французских СМИ (например, новости и видео на YouTube);
• Чтение статей, написанных для носителей французского языка;
• Построение мыслей на французском;

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

Осторожно, этот текст написан настоящим прокрастинатором. Желание написать статью на тему борьбы с прокрастинацией появилось у меня летом 2019 года, приступила к работе в ноябре и думала, что выпущу статью к концу декабря — как раз когда все подводят итоги и планируют начать новую жизнь. Сегодня 17 февраля 2020, и у меня еще не готов последний абзац. Тем не менее в этой статье я расскажу, что все-таки помогло мне выкарабкаться из пучины «я сделаю это завтра/в выходные/в понедельник…» и закончить работу.

В последнее время задача распознавания символов в прикладных программах не представляет особой сложности — можно использовать множество готовых OCR-библиотек, многие из которых доведены почти до совершенства. Но все же иногда может возникнуть задача разработать свой алгоритм распознавания без использования сторонних «навороченных» OCR-библиотек.

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

Боксёрские перчатки. Перчатки для MMA. Вообще, полный набор для тренировок – лапы, шлем, защита на колени. Спортивный костюм, даже два – для лета и осени. Гитара. Синтезатор. Гантели. Кроссовки, купленные специально для пробежек. Беспроводные наушники, разумеется.

Всё это лежит в моей квартире. Формально всё это – моё. Но я этим не пользуюсь, т.к. купил не для себя. Не, я, конечно, пару раз тягал гантели, попиликал на синтезаторе, освоил аккорд A на гитаре, месяц ходил на тренировки по MMA, столько же занимался пробежками. Но нельзя же злоупотреблять чужой добротой? Вдруг вернётся хозяин всех этих замечательных вещей, и ему не понравится моё самоуправство?

Как думаете, кто он? Для кого я всё это купил? Потерпите, скоро узнаете.

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



В конце этого материала, вы найдете ссылки на целый курс по Vue.js.