Started from the bottom.

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

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

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

Так делать не надо.

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

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

Как сказал Сократ: "Не стыдно не знать, стыдно не учиться."

Успехов!

Linux Academy.

При обучении программированию иногда забывают про навыки близкие к системному администрированию - Linux, виртуализация, сети, Docker, облака, т.д.

Linux Academy - это Coursera для таких навыков. Эта платформа очень дорогая, но раз в месяц 5 курсов становятся полностью бесплатными. Очень часто попадаются курсы, которые обучают актуальным технологиям.

Успехов!

@it_intern

#нереклама

Стажировки.

10 прекрасных стажировок с разным стеком технологий в Dell Technologies. К сожалению, только в Петербурге.

https://spb.hh.ru/vacancy/40951409
https://spb.hh.ru/vacancy/41962143
https://spb.hh.ru/vacancy/41713046
https://spb.hh.ru/vacancy/41712910
https://spb.hh.ru/vacancy/40765582
https://spb.hh.ru/vacancy/41706213
https://spb.hh.ru/vacancy/41698567
https://spb.hh.ru/vacancy/41706064
https://spb.hh.ru/vacancy/41698540
https://spb.hh.ru/vacancy/41712910

Успехов!

@it_intern

Новости.

Наш канал называется "//АйТи интерн" и в его описании есть фраза: "Веселые и полезные истории из жизни интерна одной из крупнейших IT-компаний".

Я уже давно не интерн и давно не в той компании. Тема начала карьеры стала для меня неактуальной. Поэтому я решил предложить своему молодому другу начать тоже писать сюда.

Ему 23 года, достаточно senior'ен, занимается студенческими проектами в своей компании и даже делает свой онлайн-курс.

Позже мы вас с ним обязательно познакомим ;)

Скоро будет много технических, процессных и карьерных постов.

Stay tuned!

Zettelkasten.

В этом посте я писал, что начал использовать Zettelkasten для построения базы знаний. Это логичная имплементация принципа "Create more - consume less".

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

Он подходит для изучения чего-то нового, создания базы знаний, подготовка текстов и написания книг, исследований новых областей и технологий.
Не подходит для дневников, ведения проектов, to-do листов и списков. Для этого лучше использовать что-то типо Asana, Trello или Jira :)

В основе Зеттелькастен (надеюсь, что написал правильно) лежит два шага.

Первый шаг: обработать информацию. Сформулировать содержание цитаты, статьи, отрывка из книги своими словами. Такие заметки нужно хранить в разделе "Literature notes". Это может быть моментальная обработка информации, а может быть и отложенная. Для такого можно завести отдельный раздел. Я использую именно отложенную обработку информации и храню это в разделе "Reference notes".

Второй шаг: связать информацию с уже существующей. Проставить ссылки на уже переработанные заметки.

После того как это сделано, то нужно создавать "Permanent notes". Эта та заметка, которая содержит теги и ссылки на Literature notes. Но самое важное в этой заметки, что здесь вы используете переработанную информацию для создания чего-то нового и своего, т.е. воплощаете принцип "Create more - consume less".

Есть много программ, которые можно настроить под Зеттелькастен или они были сделаны специально для него: Obsidian, Roam Research, Notion, Zettlr, NValt, The Archive, Vim-Zettel.

Я использую Roam Research, но он платный. Он мне помогает для ведения Зеттелькастена и научной деятельности.

В такой маленькой заметке тяжело рассказать все про Зеттелькастен, но если появятся вопросы, то задавайте их в комментариях. Мы попытаемся ответить.
Ссылки, которые могут помочь в изучении:
- Статья на VC про Зеттелькастен и Obsidian
- Сайт про Зеттелькастен
- Видео, по которому я разбирался с Roam Research

IT - наш потерянный табель о рангах.

Не люблю канал "Русские норм", но иногда там достойные гости.
Их новый выпуск про IT - https://www.youtube.com/watch?v=qlZmGV4QMhs

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

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

Почему мы займем первое место? Потому что мы всегда умеем и умели самообучаться и соревноваться друг с другом, а также делать "не благодаря, а вопреки" (Ломоносов пешком шел учиться в Москву).

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

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

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

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

И мы с Вами выживем и будем на коне.

Успехов русскому IT!

@it_intern

Магистратура.

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

А еще круче когда сами компании рассказывают с кем они сотрудничают. Яндекс и JetBrains сделали обзоры магистерских программ, в которых принимают активное участие.

Яндекс - https://habr.com/ru/company/yandex/blog/553702/

JetBrains - https://habr.com/ru/company/JetBrains-education/blog/564436/

Успехов!

Выбор каждого.

У молодых людей есть 2 стула - работать много с овертаймами или соблюдать work-life balance. У кого “растяжка” получше получается совмещать или чередовать подходы.

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

Но для меня это все неважно. С возрастом и профессиональным ростом заезженный афоризм Конфуция про работу по душе уже не кажется таким заезженным и глупым 🙂

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

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

Желаю вам найти свою работу по душе и быть счастливыми!

P.S. Канал оживает.

The Missing Semester of Your CS Education.

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

3 PhD студента из MIT пошли дальше. Они организовали материалы и лекции, которых, по их мнению, не хватает в классическом CS курсе. Раскрываются следующие темы:
- Command shell
- Version control
- Text editing
- Remote machines
- Finding files
- Data wrangling
- Virtual machines
- Security

Сайт - https://missing.csail.mit.edu/
Есть русский перевод.

В московском ВШЭ ФКН уже был такой курс - https://t.iss.one/experimentalchill/80

Успехов!

Что я хотел бы знать об IT в 20 лет. Максим Дорофеев.

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

https://www.youtube.com/watch?v=fY8hhOv7lmE

Максим Дорофеев проработал более 15 лет в различных IT компаниях до того как начать писать книги про продуктивность.

Игра в найм.

Недавно перечитал пост про субъективность собеседования - https://t.iss.one/it_intern/57

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

Год назад я решил менять работу. Я не готовился и был очень уверен в себе. После первого собеседования моя корона слетела. Да, вопросы были странные и очень теоретические, но это моя вина, что к тому я был не готов. В другие компании я проходил собеседования лучше и получил 6 офферов (не считая внутренних офферов на удержание).

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

Это и есть та самая субъективность процесса найма и вероятность попасть или не попасть в вопросы. Есть два способа снизить субъективность.

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

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

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

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

Успехов!

#собеседования #поиск_работы

Стажировки.

Весенний семестр - это лучшее время для старта своей карьеры в IT. Он маленький, а впереди лето, во время которого можно сфокусироваться на работе.

Сформировал для вас поисковый запрос для поиска стажировок на HH - https://spb.hh.ru/search/vacancy?area=2&area=1&area=2019&employment=probation&employment=full&search_field=name&search_field=company_name&search_field=description&industry=7&text=%D1%81%D1%82%D0%B0%D0%B6%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B0

Есть очень интересные стажировки во многих областях - фронт, бек, ML, DevOps. Есть даже R&D позиции. Есть фулл-тайм и есть парт-тайм вакансии.

Если вы хотите опубликовать вашу вакансию, то пишете нам на @it_intern_creator

#вакансии

@it_intern

Распределенный вперед.

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

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

Я потратил несколько дней на эту проблему, а потом подошел к своему тимлиду и он сказал: “так у тебя 2 мастера, это split brain, нет консенсуса, пофикси.” Понятнее тогда мне не стало, но я узнал о совершенно новом для себя пласте проблем после часа общения с гуглом.

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

Известный и признанный исследователь Мартин Клеппман определяет распределенную систему как систему, в которой множество узлов (компьютеры, телефоны, сервера, роботы, и т.д.) выполняют какую-то вычислительную задачу вместе, взаимодействуя друг с другом по коммуникационной сети.

Он также написал всемирно известную книгу “Designing Data-Intensive Applications” про создание больших, производительных и поддерживаемых систем. По-русски книжка называется “кабанчик”.

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

Этим постом мы открываем серию небольших заметок про распределенные системы и большую тематику постов про архитектуру в целом. В следующий раз мы расскажем про основные проблемы распределенных систем - Split-brain. И методы их решения - Quorum и Fencing.

@it_intern

#архитектура #распределенные_системы

Split-brain, Quorum и Fencing.

Говоря о распределенных системах многие по умолчанию подразумевают, что они должны быть высокодоступны (high availability - HA ) и по возможности еще и отказоустойчивы ( fault tolerance).

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

Допустим у нас есть 3 сервера “A”, “B”, “C” на которых запущены копии одного приложения. Они умеют общаться друг с другом по сети. У этих копий есть основной экземпляр (главноый, main, master) и есть запасные. Другими словами у нас есть кластер какого-то приложения.

Тут сразу же возникают вопросы: сколько копий (по-умному это называется “реплика”) нам нужно запускать, как отличить падение мастера от реплики? Например, у сервера “C” (картиночка ниже отдельным постом) пропал доступ к сети, и он не может коммуницировать с “А” и “B”. При этом запросы в систему приходят на “B” и на одинокий “C” (почему такое возможно обсудим позже).

Это и есть фундаментальная проблема распределенных систем - Split-brain.

Split-brain возникает при расщеплении распределенной системы на несколько частей, которые не могут взаимодействовать друг с другом. Эту проблему должен уметь решать любой софт, который пытается обеспечить HA. Основными методами решения этой проблемы - Quorum и Fencing. Многие инструменты, которые используют разработчики в своей работе, умеют с этим справляться из коробки, но если вы пишите свое кластерное решение, то вам придется это сделать самим.

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

@it_intern

#архитектура #распределенные_системы

Кабанчик.

Меня спросили про "кабанчика". Кабанчик - это на программистком сленге название книги “Designing Data-Intensive Applications” от Мартина Клеппмана.

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

Ее автор - Мартин Клеппман, ученый-информатик. Работает и читает лекции в Кембриджском университете, исследует распределенные системы. Также он у него есть аккаунт на Патреоне с большим количеством спонсоров. Что очень необычно для такого человека, но это вселяет веру в человечество.

Несколько лет назад я мог посетить конференцию с его участием и лично. У меня был доступ к спикерской зоне, но я поленился ехать, а потом началась корона ;(

Не упускайте возможности!

@it_intern

#архитектура #распределенные_системы #книги

​​Quorum.

В прошлый раз мы говорили о проблеме Split-brain’а. Она происходит, когда распределенная система разделяется на несколько частей. Ее можно решить с помощью Quorum и Fencing.

”Quorum praesentia sufficit - установленное законом, уставом организации или регламентом число участников собрания (заседания), достаточное для признания данного собрания правомочным принимать решения по вопросам его повестки дня.”

Это определение не из информатики, но верно передающее суть происходящего в распределенных системах (удивительно!). Кворум - это минимальное количество голосов от узлов системы для фиксации выполнения какого-нибудь действия в распределенной системе, требующего согласования. Обычно это запись данных внутрь системы или обновление состояние самой системы.

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

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

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

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

Но и это может не гарантировать наличие кворума и консенсуса 🙂 Вот такие они распределенные системы.

Успехов!

@it_intern

#архитектура #распределенные_системы