Как шустрые кандидаты набирают "очки" на собеседованиях

Вчера слышал, как у нас в конторе человек, проводящий собеседования, рассказывал о том, какой классный специалист ему на последнем собеседовании попался. Мол, говорит, до всего сам докапывается, всё оптимизирует, лезет в "кишки" java и т.д. Например, рассказал, как он исследовал, что быстрее работает: synchronized или ReentrantLock, провёл тесты и выяснил-таки. Вот такие люди нам нужны!

Короче, пел он дифирамбы, а я про себя посмеивался, т.к. недавно читал статью как раз на эту тему. И понял, что чувак, которого он нахваливает, судя по всему, читал ту же самую статью. Ну, или похожую. И вывод тут можно сделать такой, что:
1) тот, кто собеседовал, статью не читал (не был отов к собеседованию);
2) тот, кого собеседовали, либо прочитал статью и выдал за своё исследование (максимум, повторил исследование по мотивам статьи), либо не читал статьи и таки сам провёл исследование, что может характеризовать его как "велосипедостроителя". Такой вместо работы над проектом может начать изобретать собственные коллекции, сборщики мусора и т.п.
И неронятно, что хуже у кандидата: открытое враньё или незнание общих тенденций в сфере его деятельности и велосипедостроение.
В народе говорят, что простота хуже воровства.

Но это всё лирика. Вывод такой: хотите заработать на собесе побольше баллов - вот вам "грязный" приёмчик. Прочитайте чью-нибудь статью и расскажите о том, как "вы" что-то там исследовали или оптимизировали. А, если скажут, что есть такая статья на хабре - скажите, что да, есть, но, ведь, надо было самому проверить и удостовериться. ))

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

Apache Ignite cache: Выбор датасета

 В идеале, хотелось бы найти датасет, который обновлялся хотя бы один раз в неделю. В этом случае, можно было бы протестировать наше приложение на реальных обновляемых данных. Но найти такой я не смог (на самом деле, не очень-то и искал). Поэтому буду использовать датасет от Амазона: Electronics 5-core, состоящий из 1689188 записей отзывов покупателей о товаре, относящемся к группе "электроника".

Датасет небольшой, но, надеюсь, его хватит для демонстрации возможностей приложения.

Состоит датасет примерно из таких вот полей:

{
  "reviewerID": "A2SUAM1J3GNN3B",
  "asin": "0000013714",
  "reviewerName": "J. McDonald",
  "helpful": [2, 3],
  "reviewText": "I bought this for my husband who plays the piano. He is having a wonderful time playing these old hymns. The music is at times hard to read because we think the book was published for singing from more than playing from. Great purchase though!",
  "overall": 5.0,
  "summary": "Heavenly Highway Hymns",
  "unixReviewTime": 1252800000,
  "reviewTime": "09 13, 2009"
}

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

В следующей статье опишу создание компонента, отвечающего за загрузку датасета.

Apache Ignite cache: Архитектура будущего приложения

В прошлой своей статье я составил приблизительный план того, как собираюсь писать приложение, реализующее распределённый кеш на Apache Ignite. И в ней уже обозначил основные компоненты приложения, разделив их по признаку ответственности (как сказал бы Боб Мартин) или другими словами по тому, какую функцию они будут выполнять. Такими компонентами будут:

1. Загрузчик датасета.
Он будет скачивать датасет на локальный диск и разархивировать его (если будет принято решение использовать заархивированный датасет). 

2. Парсер датасета.
Он будет парсить загруженный датасет, мапить распарсенные данные в модели и отправлять данные в кеш.

3. Менеджер загруженных файлов.
Он будет различные операции с файлами. Например, архивирование или удаление.

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

5. И, конечно, нам понадобится главный компонент, который будет объединять все остальные компоненты в одно приложение и управлять ими (запускать, останавливать и т.д.).

Теперь надо всё это красиво зарисовать в виде диаграммы, которую мы громко назовём архитектурной схемой. Мне нравится рисовать такие штуки на draw.io. 

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

 

Что на ней изображено:
Data server  - место, откуда мы будем скачивать датасет.
Apache Ignite Service Grid - платформа, которая будет запускать на исполнение наш сервис.
Apache Ignite Data Grid - собственно, сам кеш на базе Apache Ignite.
Logging - подключим фреймворк, который будет отвечать за логирование событий в нашем приложении.
Application - главный компонент приложения, который будет управлять всеми остальными компонентами.
Downloader - загрузчик датасета.
FileManager - управление загруженными файлами.
FileParser - парсинг загруженных файлов.
ActivityRepository - будет хранить в кеше данные об активности приложения.
DataRepository - будет хранить в кеше распарсенные данные.
PropertyUtility - утилитные методы для работы с настройками приложения. Какие это будут настройки - придумаем по ходу пьессы. Но они будут конфигурируемы извне приложения. Зачем так сложно? Сейчас всем, что связано с CI/CD, занимаются, как правило, инженеры DevOps. Для них может оказаться совсем неочевидным, где внутри нашего приложения нужно искать захардкоженные настройки, как их правильно поменять, чтобы приложение после этого скомпилировалось и собралось в исполняемый файл. Поэтому выносим все настройки наружу, в файл, который будет находиться отдельно от нашего скомпилированного приложения.
DateTimeUtility - работа с датами и временем. Если он нам не пригодится, мы от него откажемся позже. А пока - пусть будет.

Т.к. мы будем писать "самое настоящее интерпрайз-приложение", то для него мы заведём репозиторий на гитхаб.

Apache Ignite: составляем план создания проекта

 Приблизительный план того, как собираюсь писать пет-проект с Apache Ignite:

1. Продумываем архитектуру приложения. Хотя бы в общих чертах.

2. Приложение будет скачивать датасет, парсить его и складывать в кэш Ignite.
Значит, нам нужно будет найти датасет в общем доступе, с которым мы и будем работать.

3. Пишем часть, отвечающую за загрузку датасета.

4. Пишем модельки и часть, отвечающую за парсинг датасета.

5. Скачиваем и устанавливаем Apache Ignite. Настраиваем средство мониторинга за состоянием кластера.

6. Пишем часть, отвечающую за взаимодействие с кэшом Ignite: положить данные в кеш, прочитать данные из кеша.

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

8. Интегрируем наш сервис в Apache Ignite Service Grid.

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

10. Попробуем написать нагрузочный тест.

Apache Ignite: Что это

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

Apache Ignite - это зрелая production-ready система, о чём свидетельствуют доклады с последних конференций, посвящённых разработке на Java (и не только) High-Load систем. Технология имеет довольно подробную документацию и дружелюбное сообщество, участники которого стараются помочь при возникновении проблем с настройкой или использованием Apache Ignite, открыто обсуждают планы по развитию продукта и периодически организуют вебинары, на которых разработчики платформы рассказывают обо всех полезных штуках, которые можно сделать с кластером Ignite.

То, что я хочу рассказать про Ignite в своих последующих статьях - это как можно использовать его в качестве распределённого кэша и среды для запуска своих сервисов. Будет много кода и несколько "граблей", на которые умудрился наступить, работая с Apache Ignite.

Для начала, вот несколько полезных ссылок для предварительного знакомства с Apache Ignite:
- документация
- полезные статьи на Хабре
- вебинары на русском языке:

• Основы In-Memory Computing для архитекторов и разработчиков
• Выводим Apache Ignite в продакшен: чеклист
• Распределенные вычисления с Apache Ignite
• Как понять, что вам подходит Apache Ignite SQL, и начать его использовать

- видео на русском языке:

• Apache Ignite Community - как работает Open Source
• Использование Apache Ignite для проведения рекламных кампаний в реальном времени
• Low Latency при работе с данными (Highload++ 2019)
• Катастрофы больше не страшны (Saint Highload 2019)

- youtube-канал.

Про работу

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

 

К чему стремиться на работе? 

 

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

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

Есть ли "серебряная пуля"?

 

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

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

Сегодня на одном проекте решат, что надо использовать Rabbit, завтра на том же проекте - что Kafka лучше. Послезавтра - <queue-name>. Вчера были уверены, что многопоточность - зло и отовсюду её выпилили. Сегодня поняли, что без неё приложение работает слишком медленно.

 

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

Поэтому не нужно переживать о том, что тебе не известно "самое правильное решение" или, что "ты не знаешь всё и заранее". Ни в одной области нельзя заранее знать всё. К тому же, в IT всё очень быстро меняется. Нужно просто научиться быстро получать и применять новые знания.

 

Что насчёт тестов?

 

Прочитал в одной статье такое мнение:  "У множества компаний и стартапов практически нет тестов. Сражаясь за рынок или за выживание, многие компании пренебрегают тестированием на ранних стадиях. Но не потому, что люди не умеют их писать. Они либо никогда не испытывали проблем от отсутствия тестов, либо испытывали проблемы от наличия старых тестов..."

 У меня с тестами часто бывает так:
Пишешь себе код почти по TDD и тут тебе прилетают изменения задания. Там изменений-то на пару-тройку строк кода. Но по причине этих изменений упали 40 тестов, которые теперь надо переписать...
Когда в течение недели приходит 10 таких изменений и ты в 10-й раз исправляешь 40 тестов, на 11-й раз ты их просто удаляешь или закомментируешь с мыслью поправить после того, как задание "устаканится". )

Лично мне без тестов - совсем никак. Я настолько ленив, что мне проще написать тест, чем дебажить с целью проверки код в ИДЕ или в уме. Не понимаю, зачем насиловать себе глаза и мозг, если можно поручить эту работу юнит- или интеграционному тесту

Какие есть советы по карьере?

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

Психолог и писатель Адам Грант попросил своих подписчиков в Twitter рассказать, какие ВРЕДНЫЕ для карьеры СОВЕТЫ им давали старшие родственники, преподаватели и более опытные коллеги:
• не тратить время на помощь другим;
• закрыть 90% проектов, потому что сосредоточиться можно лишь на одном;
• если вы не остаетесь в офисе после 17 часов, то вы не командный игрок;
• на новой работе нужно продержаться как минимум год;
• в 26 лет менять профессию слишком поздно;
• если вы не близки к обмороку, то недостаточно усердно работаете;
• не будьте слишком амбициозным;
• если вы дважды неудачно пытались поступить на нейрохирурга, возможно, эта специальность не для вас;
• ваши коллеги — это не ваши друзья;
• наука трудна, а вы недостаточно умны, чтобы быть морским биологом;
• если хотите стать CFO, то придется сделать короткую стрижку;
• не идите учиться на историка, потому что потом не найдете работу;
• необходимо выбрать между карьерой и семьей;
• оставайтесь в одной компании как минимум десять лет, чтобы подняться по карьерной лестнице.

 

Егор Бугаенко в своём выступлении перед студентами ВШЭ дал такие карьерные советы:

1) развивать хард-скиллы в одной достаточно специфичной нише;

2) развивать софт-скиллы;

3) работать на достижения (совершенствовать то, в чём ты хочешь быть лучше других и не забывать отражать это в резюме).

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