Второй семестр is OVER!

Привет. Второй семестр в Карнеги Меллон закончен. Я очень давно не писал, и тому была причина – высокая нагрузка.
В этом посте я расскажу, какие курсы я брал и какие самые важные откровения я для себя вынес.

Чтобы было интересно читать, вот моя фотография с финальной презентации. На этой фотографии я очень злой =) Слава Ковтуненко в моей команде – на фоне с сосредоточенным видом.

20140508-_DSC0252

Но по порядку, что там с нагрузкой

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

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

2semester-analysis

  • простите за вырвиглаз цвета, но зато все курсы различимы по легенде
  • разрыв в центре – это недельные каникулы, называются Spring Break
  • по идее, в течение Spring Break я должен был отдыхать, но курс по Архитектуре взял свое.
  • 08722 и 17603 – два мини-курса для первой и второй половины семестра, каждый считается за 6 юнитов и идет половину семестра
  • 17657 – трёх-юнитовый курс о всякой фигне, типа как проводить презентации. Курс маленький и на первый взгляд ненужный, но зато на нем мы обкатали наши финальные (End of Semester) презентации
  • можно видеть, что в среднем нагрузка держится около 50 часов при том, что у меня в этом семестре было курсов на 63 юнита
  • но и понятие 12-юнитовый курс очень размазано – все курсы, кроме вышеназванных, формально являются 12-ти юнитовыми, а занимают от 4 до 20 часов в неделю.

Как я записываю время: решаю, чем сейчас буду заниматься, включаю счетчик времени, сажусь делать, стоит только отвлечься более, чем на пять минут – счетчик надо выключить. В результате получается, что 10 часов реальной работы в день это ОЧЕНЬ много. Это примерно 15-20 часов реального времени, например, с 10 утра до 5 утра следующего дня. При всем желании быть в фокусе более, чем на один-два часа почти невозможно, исключение составляют всякие программистские задачи – на них получается зависать на 3-5 часов без особых прерываний.

Восьмичасовой день включает в себя от 4 до 5 часов реальной работы.

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

Поговорим о вырвиглазно-лиловом

Да, именно таким цветом у меня на диаграмме отмечен курс 15640 Distributed Systems. Вот [здесь] я анонсировал этот курс ранее.

gopherbw

Это 12-ти юнитовый электив, который мне очень понравился. [Вот здесь] можно ознакомиться с описанием курса и темами. В целом – все, что связано с распределенными системами: распределенные базы данных, DHT, репликация , Paxos, HDFS, и другие слова начиющиеся с Distributed.

Изюминкой этого курса для меня были его кодерские домашние задания на go programming language. Go – это язык программирования, выросший в Goggle, уже как 5 лет назад. По субъективным ощущениям это “python flavored C” т.е. си со вкусом питона.  Кстати, картинка выше – официальное лого языка программирования. =)

Среди проектов по этому курсу (подробнее [тут]):

  • Простой много клиентный эхо-сервер на Go
  • Распределенный биткойн майнер. (ну, на самом деле не совсем биткойн)
  • Пародия на распределенную систему серверов для хранения твитов – Tribbler
  • И проект с открытой темой и обязательным использованием распределеного коммита.

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

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

  • Облачные технологии? 30 лет назад терминалы существовали
  • NoSQL базы данных? до того, как придумали SQL базы данных – все базы данных были NoSQL
  • Виртуализация? 20-30 лет назад уже так делали, разве что были технические ограничения

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

 Архитектура

17655 – Architecture for Software Systems

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

Курс включает в себя 4 групповых проекта, которые имеют вид технических кейсов: дается описание бизнес-контекста и какие-то примеры кода, которые можно использовать. Требуется в заданном контексте, имея на руках данный legacy код, решить данные в задаче проблемы. В результате, в команде пишется немного кода (от 4 до 12 часов времязатрат на человека) и индивидуальный репорт (обычно около 20 страниц получается).

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

Откровение курса: Не существует “правильного решения”

Почти на любой вопрос можно ответить “it depends”, т.е. “это зависит от контекста”. Иными словами, каждое решение будет хорошо только в заданном контексте, и перед тем, как говорить о решении, необходимо очень точно и понятно определить этот контекст. Как результат, у разных людей получаются разные решения в зависимости от того, как они формализовали контекст.

Анализы

Analysis of Software Artifacts. За этим загадочным именем скрывается курс, по сути посвященный проблемам quality assurance. Например:

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

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

Откровение курса: Юнит тесты  – не панацея.

Кроме юнит-тестов еще есть куча способов протестировать код. И, более того,  100% test coverage вам вообще ничего не гарантирует, до тех пор, пока вы не докажете обратное. Я могу привести пример кода из 5 строчек и двух тестов, которые дают 100% test coverage и при этом пропускают простейшую ошибку. Но при этом это не означает, что тестировать бессмысленно.

Практикум

17677 MSIT Project

Про этот курс я уже писал тут [Зимние каникулы и планы на семестр]. Он реально требует отдельной статьи…

slide

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

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

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

А еще хотел отметить, что командная работа выматывает: Совещания – реальная альтернатива работе!