Cобеседования

Довольно часто бывает страшно идти на собеседование потому, что нет понимания о том, что там вообще ждёт: какие знания будут проверять на Junior, а какие на Middle? И прочие подобные вещи.

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

Один из роликов: https://www.youtube.com/watch?v=3D0IVhYzXJM

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

Один из роликов: https://www.youtube.com/watch?v=b4fx8Zu4IU4

Так же есть несколько роликов, рассчитанных на новичков (и не только) в профессии от Сергея Немчинского, которые я тоже нахожу полезными. Вот список:

- про резюме: https://www.youtube.com/watch?v=b4fx8Zu4IU4
- как понять, что компания вам не подходит: https://www.youtube.com/watch?v=3vPNReMUzBE
- как пройти испытательный срок и не вылететь: https://www.youtube.com/watch?v=i3Z5LvDaFR8
- как устроиться на первую работу: https://www.youtube.com/watch?v=ozgiX6pto1o

***

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

Хочу собрать небольшую статистику, поэтому голосуйте!

Немного спекуляций для подогревания интереса к подкасту, который выйдет уже совсем скоро (через 1.5 часа примерно)

​Выгорание / Полгода до тимлида / Пытаюсь всё успеть / Фриланс — НА ВСЮ ГОЛОВУ JS #11

Привет! Это одиннадцатый выпуск моего подкаста "На всю голову JS". Сегодня мы поговорим про выгорание, мой опыт управления командой и как я пытаюсь всё успевать.

UPD: простите за качество картинки, не понял в какой момент webm стал так сжимать всё :(

System-design для самых маленьких

Довольно подробная статья про то, как правильно строить веб-приложение (и не только, мобильные приложения — тоже можно сюда отнести), с какими трудностями можно столкнуться и насколько важно изначально понимать как построить систему таким образом, чтобы она была готова к высоким нагрузкам. Не могу сказать, что я узнал для себя много нового, но — как минимум — освежил в памяти довольно много моментов и задумался о более глубоком подходе к настройке внутренностей тех систем, которые мне ещё предстоит написать.

Почитать можно тут: https://vitkarpov.me/posts/what-is-system-design/

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

Архитектура веб-приложения на лего: https://youtu.be/9mZmc6a0tmM

И раз уж речь зашла о роликах на YouTube, есть ещё видео про масштабируемую архитектуру от канала "Диджитализируй!" (крайне рекомендую всем, кто пишет на Django, кстати).

Ссылочка: https://youtu.be/kclYmb47LTg

​Странные оптимизации

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

Пример «полезного однострочного выражения»:

const isArray = (arr) => Array.isArray(arr)

Как вам? Мне очень нравится, если честно. Всегда мечтал превратить JS в python, поэтому придумал ещё вот это:

const len = (iterableVar) => iterableVar.length

Ура, теперь можно мерить длину как в python! Только нужно ли?..

Безусловно, в этой статье есть и нормальные примеры (точнее, заявки на нормальные примеры), но и те содержат в себе «магические числа», пришедшие не пойми откуда.

Пример, который меня так же смутил:

const getPositiveNumber = (number) => Math.max(number, 0)

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

Тестирование приложений на мобильных устройствах

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

Из всего списка я знал только про BrowserStack, на котором я тестировал то, как будет работать и выглядеть моё приложение на разных iOS-устройствах (dev-tools для этих целей недостаточно, потому что они не могут на все 100% гарантировать те же условия: браузер, плотность пикселей и так далее). Из реальных устройств у меня есть старенький iPhone 5c с iOS 10 и относительно новый смартфон от Huawei (P40 Lite). На iPhone я тестирую вёрстку под viewport 320px и проверяю насколько хорошо всё работает в старом Safari (периодически расстраиваюсь и грущу, конечно). На Huawei у меня стоит 3 браузера: стандартный, Firefox и Chrome. В них результаты всегда плюс-минус одинаковые, но я всё равно всегда проверяю, чтобы быть спокойным при деплое (и не так важно идёт ли речь о SPA или о лендингах). Ещё было бы неплохо иметь пару планшетов, но до этого я пока не дошёл :)

Ссылка: https://www.smashingmagazine.com/2021/03/mobile-app-web-testing/

Ключевое слово «this»

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

Ссылка: https://dmitripavlutin.com/javascript-this-interview-questions/

Если вы не смогли ответить ни на один вопрос, то это не беда, прочтите раздел про this на learn.javascript.ru:

https://learn.javascript.ru/object-methods

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

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

Ссылка: https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Operators/this

​Тестирование и документирование в Postman

В университете на одной из пар по тестированию преподаватель поделился своим подходом к документированию API, рассказав и показав как он делает документацию средствами Postman. После у нас была целая отдельная лабораторная посвящённая тестированию и документированию API. С того момента я стараюсь делать документацию к API таким и только таким образом, потому что это намного удобнее любого Swagger'а, плюс процесс документированию идёт параллельно процессу тестирования, что позволяет повысить скорость выведения API в продакшн. Конечно, иногда при тестировании я использую старый добрый Curl, потому что он более универсален, но он не позволяет задокументировать всё происходящее. Зато тесты через Curl можно запустить даже с телефона (подразумеваю андроид-смартфон), если есть такая необходимость.


Что почитать?

Вводная статья от geekbrains, для тех, кто совсем ничего не слышал о Postman раньше: https://geekbrains.ru/posts/kak-testirovat-api-ili-postman-dlya-chajnikov

Чуть более сложная для понимания статья с хабра (здесь затрагивается и автоматизация тестирования в том числе): https://habr.com/ru/company/kolesa/blog/351250/

Довольно простая статья об автоматизации: https://quality-lab.ru/blog/test-automation-rest-api-using-postman-and-javascript/

Гайд на сайте постман по документированию: https://learning.postman.com/docs/publishing-your-api/documenting-your-api/

​500 подписчиков на YouTube

Это наконец-то случилось! Нас уже целых 500! Пускай, эта цифра и кажется маленькой, но как по мне — это довольно неплохое достижение. Не забывайте, что это всё только начало. И спасибо, что остаётесь со мной :)

​Docker: контейнеризация и оркестрация приложений

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

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

Кроме прочего, докер идеален для CI/CD, потому что позволяет запустить приложение в ограниченном режиме на тестовом сервере, прогнать все тесты (небольшая тавтология), после чего можно запускать сборку на продакшн-сервере без каких-либо дополнительных усилий со стороны разработчика: всё настраивается один раз, после чего можно забыть о неудовлетворённых зависимостях и дополнительных настройках для тех же баз данных/nginx и прочем. По сути, вся настройка сводится к написанию Dockerfile, в которых будет описано каким образом и в какой среде будет собираться приложение, а в docker-compose используется YAML-файл, необходимый для описания того каким образом контейнеры будут взаимодействовать между собой.



Полезные ссылочки по теме:

Официальная документация докер: https://docs.docker.com/
Неплохая статейка с Хабра: https://habr.com/ru/post/309556/
Официальная документация по docker-compose: https://docs.docker.com/compose/
Статья по связке Nginx + Gunicorn + Django + PostgreSQL в докере: https://testdriven.io/blog/dockerizing-django-with-postgres-gunicorn-and-nginx/
Большое видео от Артёма Матяшова про Docker: https://www.youtube.com/watch?v=QF4ZF857m44

Удалённая работа

Я довольно давно работаю по разным кафе/кофейням и так далее, недавно попробовал работать и в коворкинге, впечатление — неизгладимое. Но дома меня всегда ждёт мой замечательный Apple Magic Trackpad 2 и механическая клавиатура, работать за которыми — удовольствие. Поэтому, я стараюсь чередовать рабочие места. А вы где больше всего любите работать? Голосуйте постом ниже!

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

Если повезёт — видео будет сегодня!

P. S. видео по курсу, видимо, откладываются, как минимум, до четверга-пятницы, а то и субботы. Сейчас последняя учебная неделя чтобы всё закрыть. Постараюсь не пропасть из ТГ. Во втором канале — возобновлю посты уже сегодня вечером.

​Собеседования в IT/К чему готовиться?/Что спрашивать? — На всю голову JS #12 (п. у. Дима Венгеров)

Привет, это 12й выпуск моего подкаста на всю голову JS. Сегодня мы с моим товарищем и коллегой Димой Венгеровым обсудим собеседования в IT, к чему стоит готовиться и что стоит спрашивать. А ещё немного расскажем про свой путь и поговорим про менеджмент.

***

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

***

Смотреть: https://youtu.be/nc4BXVvQ0PQ

***

Полезные ссылки:

Тот самый пост про Event Loop: https://www.tg-me.com/davidobryakov/1038
Телеграм-канал Димы: https://www.tg-me.com/vengerovs_talk
Мой гитхаб (сюда ставить звёздочки): https://github.com/kantegory
Мой блог: https://blog.kantegory.me

Указали на некоторую неточность в этом посте, исправил, дополнил источниками. Действительно, немного запутался и написал не совсем верно. Конечно, Promise выполнится раньше, чем setTimeout.

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

Что значит задача сделана?

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

Суть проблемы
На переднем краю проблемы выступает разработчик. Он написал код, отправил в тестирование и доложил «задача готова». Хотя, как она готова, если она даже не протестирована?

Ну такой подход из серии «с моей стороны пули вылетели».

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

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

Другой подход
Лично мне нравится идея, которую высказывали на одном из докладов (если я ничего не перепутал) в Badoo.

Когда разработчик занимается задачей «на полную катушку». Пишет код, участвует в тестировании, контролирует деплой и последующую жизнь этой своей фичи некоторое время. Мониторит, метрики собирает. И когда всё тоооочно нормально, тогда считается, что его задача сделана.

Критика такого подхода
Я уверен, что найдется много людей, которые искренне полагают, что их задача – ТОЛЬКО НАПИСАТЬ КОД, а для других стадий жизненного цикла фичи есть другие люди, и это их работа дальше вылетевшие пули контролировать, чтобы прилетели, куда надо.

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

Однако, стоит отметить, что если в цепочке, например, из 4х человек всё не совсем гладко и надежность каждого из них по отдельности – 0.95, то надежность всей цепочки (если я правильно считаю) будет уже 0.95*0.95*0.95*0.95 = 0.81.

Так что там про «задача сделана»?
К сожалению, я отвлекся от основной темы и начал рассуждать про то, как именно лучше сделать задачу. А что это значит – не сказал.

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

По крайней мере с точки зрения бизнеса – вот теперь она сделана. И менеджера, как представителя бизнес стороны, должно волновать всё это в комплексе.

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

Итог
Позаботьтесь о том, чтобы задача была по-настоящему "сделана".

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

Бонусный контент
Мы с Никитой Хромушкиным договорились написать пост на эту тему, каждый у себя в канале. Его вариант здесь https://www.tg-me.com/product_developer/27

Организация совместной работы

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

https://blog.kantegory.me/organization-of-joint-work