ИТМО СТУДЕНТЫ

Как стать частью ITMO. STUDENTS?

Состав Совета обучающихся

Хочешь установить стол для настольного тенниса в игровой? Готов организовать раздельный сбор мусора в своём общежитии? Есть проблемы в общежитии, которые не знаешь как можно решить? Пиши по контактам ниже.

Арушанян Артём, председатель общежития №4

Членам стипендиальной комиссии можно написать с предложениями по модернизации системы ПГАС, обновлением критериев, правками по материальной помощи и не только. Также мы принимаем обращения о спорных ситуациях, в которых вам как студентам может понадобиться помощь.

Матвеев Тимур, член стипендиальной комиссии от совета обучающихся

Шатохина Екатерина, член стипендиальной комиссии от совета обучающихся

Представители спорта могут сориентировать по созданию своего спортивного клуба или секции, а также по всем инфраструктурным и ресурсным вопросам внутри ССК “Кронверкские Барсы”. Также мы принимаем предложения или запросы, связанные с нашим спортивным клубом. В случае спорной ситуации, готовы помочь в её решении по мере возможности.

Матвеев Тимур, руководитель клуба горнолыжного спорта

Полухин Александр, руководитель шахматного клуба

Рассказать о клубной деятельности, проведении мероприятий, использовании ресурсов университета для клуба и не только смогут представители Совета обучающихся из руководителей клубов. Также к ним можно обращаться с вопросами или предложениями, связанными с клубной системой Университета ИТМО.

Аршинов Олег, руководитель клуба «Живой звук»

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

Родионова Алиса, руководитель конструкторского бюро «Олимп»

Дополнительная информация

Материалы и документы Совета обучающихся

Варианты логотипа ITMO. Students и правила его использования

Положение о Совете обучающихся

(pdf, 833.56 Кб)

Как выглядит стажировка в ИТМО

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

В этой статье мы покажем, как стажировка проходит на практике и что она приносит самим IT-компаниям. В фокусе истории двух магистрантов института прикладных компьютерных наук ИТМО
― Федора Золотухина
и Андрея Стояна
.

В ИТМО стараются познакомить студентов с реалиями IT-бизнеса как можно раньше. Свои стажировки есть на уровне бакалавриата, но сегодня речь пойдет о том, как применяют практические навыки студенты магистратуры.

Взаимодействие с компаниями на рынке начинается с самого начала обучения. Для закрытия сессий все пишут НИРы, защищают результаты пройденной стажировки, а потом могут писать диплом на базе реальной промышленной задачи.

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

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

• Диплом также можно писать в рамках исследовательской задачи реальной IT-компании. 

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

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

Первый опыт в DevOps

Незадолго до начала стажировки, во втором семестре пятого курса (первого курса магистратуры), Федор Золотухин выполнял НИР в Azul Systems. Поскольку компания оказалась довольно открытой, и процессы в ней выстроены хорошо, когда встал вопрос стажировки, первым делом он обратился сюда.

Хотя в резюме у Федора не было опыта в DevOps, компания предложила прокачать компетенции в этом направлении. Дело в том, что команда DevOps в Azul Systems не справлялась с существующим объемом задач ― она была слишком маленькой, поскольку основные усилия перед запланированным выпуском продукта шли на разработку бэкенда. Так что Федор включился в работу на позиции джуна.

Во время стажировки он занимался рефакторингом существующей кодовой базы Azul Systems и выстраиванием процессов версионирования и выхода в релиз. Среди прочего подключил автоматический линтинг и переложил пайплайны, написанные в bash для Jenkins, под используемую в компании систему контроля версий. Кроме того, убрал из системы связи с использовавшимся ранее в компании Mercurial SCM. Незадолго до этого команда Azul Systems переехала на Git, однако все ссылки на старый инструмент убрать еще не успели. Так что перед Федором была поставлена задача вычистить их из системы.

Как правило, стажировка ―мероприятие на лето. А осенью Федор продолжил работать над процессами ежедневной доставки новых версий продукта другим командам. Здесь также потребовался перевод некоторых пайплайнов под систему контроля версий.

Продукт, в разработке которого принял участие Федор, в конце осени был выпущен на рынок. Это Azul Vulnerability Detection
― Saas-инструмент, который помогает бизнесу обнаруживать известные уязвимости в Java-приложениях. Он подключается к рантайму Java и на лету детектит уязвимости, даже не имея доступа к исходному коду.

Сам Федор о своей стажировке отзывается очень позитивно:

«Взаимодействие с Azul Systems дало мне понимание, как вообще идет работа в больших компаниях. До этого я сталкивался только со стартапами. Плюс до этой стажировки у меня в резюме не было навыков DevOps. Но теперь я понимаю, как это устроено, знаю, как в компаниях организуют CI/CD не только до конечного пользователя, но и до других команд, представляю, как идет работа в DevOps команде. Да и интересных практических задач было немало. Я, например,  плотнее столкнулся с bash ― пришлось переписывать скрипты на Groovy. В целом работа с Azul Systems продолжается, сейчас я в той же команде пишу диплом, устроившись к ним по срочному трудовому договору».

Разработка образовательной платформы на Haskell

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

Как Андрей поясняет свой выбор:

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

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

Как раз летом в Сириус. Курсах начинался внутренний проект по переносу разных форм настроек методических материалов на другую технологию. Ранее вид формы полностью описывался на фронте, и она отображала данные с бэкенда. Это размывало зоны ответственности фронтенда и бэка, требовалось прикладывать дополнительные усилия на поддержание согласованности между разными командами по каждой форме. Вместо этого было решено сообщать фронту внешний вид формы с бэка и уже на фронте рендерить UI формы некоторым обобщенным образом. Для этого с бэка нужно отдавать одновременно json-схему, которая задаёт компоненты формы, данные для отображения в ней и дополнительную информацию для рендеринга компонент по их json-путям. Фокус в том, что всю эту информацию необходимо было как-то описывать на бэкенде, чтобы используемый для этого доменный язык контролировал происходящее ― следил за тем, чтобы компоненты формы, их опции и данные для отображения были согласованы.

Фактически Андрей реализовал библиотеку с DSL на уровне типов, предназначенную для описания форм в коде бекенда. Тут здорово помог именно Haskell, предоставляющий богатые средства программирования на уровне типов, за счет которых удалось добиться многих нетривиальных статических гарантий внутренней согласованности отдаваемой на фронт информации.

DSL на Haskell

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

Описать нужно было три вещи:

• json-схему ― по описанной в ней иерархии компонент на фронте рендерится UI. Для этого используется стандартная json-schema
  
  и генераторы форм для неё;

• данные в формате json для заполнения формы, которые должны удовлетворять схеме;

• опции. Они представляют собой отображение json-путей к компонентам на дополнительную информацию, необходимую для их рендеринга. Например, какой именно визуальный элемент использовать для отображения конкретного текстового поля.

  У тривиального решения были бы очевидные проблемы:

  • сложно контролировать валидность json-путей;

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

  Поэтому решено было дополнить описание композитного типа данных (record’a) метаданными UI компонент прямо в типах полей, а также использовать систему вывода инстансов классов типов языка Haskell для автоматической генерации json-путей к нужным компонентам по соответствующей метке доступа к полю record’a.

  Чтобы хранить информацию на уровне типов Андрей использовал идиому phantom types. В Haskell она представлена типом Tagged
  . Для него Андрей завел синоним и, используя пары уровня типов, обозначил, что именно требуется сохранить в дополнение к данным (ключ имени компоненты для отображения ее названия пользователю в UI и её вид):

В результате композитную компоненту общих настроек модуля можно описывать следующим образом:

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

Решение задачи требует, чтобы у каждой метки доступа рекорда компоненты был инстанс этого класса типов. Haskell такие инстансы сможет вывести автоматически (при этом json-путь до вложенной компоненты дополняется корректно):

Чтобы json-пути выводились для компонент произвольной вложенности, а не только уровня один и два, Андрей создал класс типов вложенной компоненты (у одной компоненты может быть только один родитель, что обозначается с помощью механизма functional dependencies

):

Этот класс типов реализован для каждой вложенной композитной компоненты вручную через указание её имени.

А чтобы для каждой вложенной компоненты выводился инстанс класса типов Component с валидным json-путём к ней, необходимо:

Так в любом месте кода можно получить всю информацию о компоненте по метке доступа к ней, например, componentPath generalSettingsModuleType.

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

Сейчас реализованная Андреем библиотека используется в разных местах платформы:

“Кажется, мне удалось добиться разумного баланса между статическими гарантиями, которые дает библиотека, и сложностью ее использования. Читать новым её пользователям спецкурс о том, как создать простейшую форму, не придется”.

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

“А еще мне понравилось работать с тимлидом Сашей. Он очень внимательный, всегда помогает разобраться с постановкой задачи и всегда готов прийти на помощь в процессе решения. Его всегда можно о чем-то спросить. В команде Сириус. Курсов ценят сотрудников, собирают фидбэк о работе, всегда открыты к новым предложениям и решениям. Это очень приятно и создаёт отличную рабочую атмосферу взаимопомощи и поддержки”.

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

ИТМО. Первый классический?

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

Вместо вступления

Чтобы мои слова не были голословными, хочется уточнить некоторые детали. Я закончил ИТМО совсем недавно по направлению “программная инженерия”. Сейчас я являюсь Middle разработчиком и совмещаю эту деятельность с преподаванием в университете в должности  младшего преподавателя.

Как проходило мое обучение

Первый год

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

Второй год

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

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

По воспоминаниям, этот год был самым тяжелым, но наиболее полезным для обретения работы.

Третий год

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

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

Четвертый год

Что изменилось 

В данном разделе хочется описать, что изменилось с моего времени, и что встретит будущего первокурсника. Из приятных мелочей: в университете сделали ремонт, кабинеты выглядят приятно и современно, везде появились розетки, отдельно выделили коворкинг, где студенты могут пользоваться своей или университетской техникой 24\7. Больше нет проблемы “где бы посидеть в универе, чтобы что-то сделать”.

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

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

Что я вынес из университета

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

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

Заметки, которые никуда не влезли

ЕГЭ не решает. Если для поступления важен каждый балл, то после разница уже стирается. Забавно сложилось, что в моей группе, все, кто обладал баллом более 290, покинули стены ИТМО без диплома.

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

Вместо заключения

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

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

P. S.

В комментариях к данному посту готов ответить на возникшие вопросы и внести дополнительные уточнения.