Чтение 1 МБ последовательно из основной памяти: 250,000 нс
Произвольный доступ к жесткому диску: 10,000,000 нс
Чтение 1 МБ последовательно с жесткого диска: 20,000,000 нс[3]
Эти цифры показывают, насколько критична оптимизация работы с памятью и дисками для производительности программ.
Сетевые задержки
Пересылка 2 КБ по сети со скоростью 1 Гбит/с: 20,000 нс
Передача сообщения туда/обратно в одном дата-центре: 500,000 нс
Передача пакета из Калифорнии в Нидерланды и обратно: 150,000,000 нс[3]
Понимание сетевых задержек важно при разработке распределенных систем.
Другие важные числа
Ошибка при предсказании условного перехода: 5 нс
Открытие/закрытие мьютекса: 25 нс
Сжатие 1 КБ быстрым алгоритмом: 3,000 нс[3]
Эти цифры помогают оценивать эффективность различных операций в коде.
Степени двойки
Разработчикам также полезно помнить степени двойки: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024[31]. Они часто встречаются при работе с памятью, файловыми системами и другими аспектами разработки.
Задержка обработки данных (Data processing latency)
Безопасность (Security)
Потенциальные атаки? Как их следует смягчать?
Конфиденциальность (Privacy)
PII (Personally Identifiable Information — Персональные данные, позволяющие идентифицировать личность), PCI (Payment Card Industry — Индустрия платежных карт) или другие пользовательские данные
Целостность данных (Data Integrity)
Как восстановиться после повреждения или потери данных?
Соотношение чтения:записи (Read:Write Ratio)
API (Application Programming Interface — Интерфейс программирования приложений)
Публичные и/или внутренние API?
Просты ли API для понимания?
Как идентифицируются сущности?
Схемы хранения (Storage Schemas)
SQL (Structured Query Language — Язык структурированных запросов) vs NoSQL (Not Only SQL — Не только SQL, обозначает нереляционные базы данных)
Очереди сообщений (Message Queues)
Проектирование системы (System Design)
Масштабируемость (Scalability)
Как масштабируется система? Учитывайте увеличение как объема данных, так и трафика.
Каковы узкие места? Как их следует устранять?
Каковы граничные случаи? Что может пойти не так? Предполагая, что они произойдут, как их следует решать?
Как мы будем проводить стресс-тестирование этой системы?
Сегодня меня пригласил на вебинар по трудоустройству в качестве соведущего Алексей Голобурдин, автор канала Диджитализируй. Я согласился сразу — ведь во многом благодаря его каналу я ответил на многие вопросы на технических собеседованиях. С его разрешения публикую на своем блоге:
Для максимально стройного изложения своих мыслей я решил написать эту статью. У меня несколько необычный опыт в IT, но велика вероятность, что он поможет таким же специалистам, которые решили сменить сферу работы после 30.
Мой опыт в IT
Я пришел в технологии 12 лет назад предпринимателем. Я не делал проекты на заказ, я делал их для себя, сам ставил задачи, сам их выполнял. Так как я не был разработчиком в прямом смысле этого слова — решения я находил такие, которые можно установить на сервер своими силами через скрипты-установщики, связать через плагины или встраиваемые скрипты. Сейчас подобная парадигма называется No Code, так вот именно этим я и занимался всю свою карьеру. И, конечно, много опыта в бизнесе — ведь это были мои магазины, а значит маркетинг и продажи тоже должны быть настроены. До 2019 года я делал это все в команде с моими соучредителями, затем — уже самостоятельно, полный цикл решений.
Почему я решил идти в программирование?
В определенный момент времени ты понимаешь, что нужного тебе плагина не существует, или две системы не общаются между собой, но у каждой есть описание API. И чем дальше ты ищешь нужное тебе решение, тем больше убеждаешься, что его либо нет, либо оно сырое.
Так как я давно уже автоматизировал все в своем бизнесе — у меня было время на стороннее консультирование. Несколько лет я настраивал IT-системы в фитнес-клубе, делал их взаимосвязь, применял свой бизнес-опыт и профильное банковское образование для бизнес-консультирования. В общем, был занят. А в какой-то момент на мир спустился черный лебедь — пандемия. Естественно, фитнес-клуб закрыли одним из первых, и у меня появилось свободное время. И я решился — сейчас, пора. Python, я иду!
У меня есть отдельная статья про Яндекс.Практикум, там есть плюсы и минусы. Рекомендую ознакомиться, здесь повторяться не буду. Здесь я сосредоточусь на тех шагах, которые я предпринял после обучения.
Подготовка к устройству на работу
Мне нужно было разобраться в моих знаниях. Я решил сделать это через книги. Понятное дело, что что-то могло пройти мимо. Я взялся за «Изучаем питон», «Чистый питон», «Грокаем алгоритмы», «Программист-прагматик» и другую литературу, которая гуглится по запросу «Лучшие книги по питону» и которые можно заказать на бумаге — с технической литературой я умею только так.
Также я начал участвовать в Open Source проектах. Нашел интересного ментора, Леона Сендоя, и помогал ему писать систему резервного копирования различных баз данных Blackbox. Читал код, разбирался в фабричном методе проектирования, и что самое главное — решал поставленные задачи. Причем почти все они были для меня абсолютно новыми, я разбирался в проблеме с нуля. Серьезный буст для саморазвития и в качестве бонуса ревью от очень хорошего норвежского специалиста и владельца сообщества Python-Discord на 200 000 человек.
Размещение резюме
Также я разместил резюме на HH и Хабр.Карьере. Я неплохо говорю по-английски, поэтому, проконсультировавшись с сестрой, которая уже много лет живет в Англии и работает HR, разместил резюме еще на следующих сайтах:
Также заручился рекомендациями от моих менторов — Леона Сендоя и Андрея Ли — на LinkedIn (рекомендации приложены в конце статьи для примера).
Первое собеседование
Довольно быстро пришло приглашение на первое собеседование на английском. Сказать что было страшно — ничего не сказать. Это был грандиозный выход из зоны комфорта. Но у меня есть один трюк, как бороться со страхом принятия решения — я его сразу принимаю. Не раздумывая, не переживая, да и еще раз да.
Теперь у меня был уже совсем другой повод беспокоиться — надо было готовиться к собеседованию на английском. Я составил речь, позвонил сестре, рассказал ей, она похвалила. Что ж, кажется я готов, подумал я.
Пройти собеседование с HR было несложно, но нервно. У меня красивая история, я подготовился — и вот у меня уже назначено техническое собеседование. Как мог я готовился, читал все, что попадалось под руки. Вот список того, что вам поможет в этом:
Техническое интервью тоже прошло на ура, я отвечал на вопросы, я знал как устроены некоторые сложные фичи питона и уверенно об этом говорил. Настало время технического задания, и вот тут я первый раз сделал все неправильно. Я прочитал задание, и сразу побежал выполнять. Я был слишком уверен в себе, ведь я понравился на всех этапах собеседования! И я решил задачу, получил данные по API, распечатал их в консоль, ничего сложного. Но техдиректору компании все это не понравилось от слова совсем. Потому что я не использовать паттерны проектирования, писал без классов, код нельзя было переиспользовать. Не то, что я не умел это делать — умел, но торопился, переживал, сделал тяп-ляп. Первый отказ. Я был чрезвычайно расстроен.
Следующие 30 собеседований
Дальше моя стратегия поменялась. Я должен был набрать опыт собеседований. Не важно, нравится ли мне компания или нет — я всегда откликался на все предложения разговоров от HR. Я внимательно изучал компанию, стек — по каждому непонятному слову сразу смотрел подробное руководство на Youtube (выбирал длинные ролики и скорость 1.75х). И с каждым разом отвечал все лучше. Попадались хитрые вопросы, попадались скучные, но почти всегда я проходил стадию HR на ура, а вот технические собеседования были успешны в 50% случаев.
Что стоит знать:
напиши свой декоратор
напиши свой декоратор с параметрами
паттерны проектирования и где ты их применял
SOLID, ACID, принципы ООП
Нормализация БД и вообще вопросов на построение запроса к БД много, в основном на Postgres
Базовые алгоритмы и их сложность
Структуры данных
Индексы и устройство хешей в общем виде
Контекстный менеджер with
REST/OpenAPI/принципы проектирования, SOAP
Очереди Kafka и RabbitMQ
AWS будет плюсом
Redis
Celery
Асинхронное программирование и принцип работы GIL
Микросервисы
Рекурсия
MongoDB
Два типа собеседований
Все можно поделить на два типа, вот и собеседования тоже. Первый тип — самый распространенный — собеседования, которые очень плохо подготовлены. Вопросы точечные, твой уровень никак не показывают, пытаются проверить не твои знания, а твой зубреж. Наверное, хороши для людей с идеальной памятью, я не из них. Я не могу вписать в поле название класса джанго, который я буду наследовать при создании своего фильтра — без подглядывания в документацию или проект, где я это уже делал.
Второй тип — это собеседования, где интервьюер выясняет область твоих знаний и четко начинает ходить по ее грани, пытаясь понять, как ты размышляешь, когда сталкиваешься с неизвестным. Вот из таких собеседований я выносил максимальное количество новой информации и именно они меня готовили к самому важному собеседованию — в компанию мечты.
Собеседование в EPAM
Так как компания ЕПАМ большая и ей уже 25 лет — то и процессы там гораздо лучше отлажены, в том числе собеседования. Это без преувеличения мой лучший опыт за весь период поиска работы. Ребята задавали интересные вопросы, где я что-то упускал — рассказывали, давали возможность раскрыться. Суммарно 5 часов технических собеседований, я был уставший, но довольный. Я рассказал свой опыт, я позиционировал себя как специалиста, который делает горизонтальный переход, и претендовал на должность Мидл-разработчика. Как я понял — позиционирование и вера в себя — это самые важные вещи после знаний.
И вот я получил оффер от ЕПАМ, и сразу на достойную сумму. Не принимая его сразу, я сказал, что мне нужно две недели на принятие решения и продолжил изучать рынок. Теперь была задана планка, и я хотел перепроверить — точно ли я правильно выбрал ЕПАМ.
Еще 10 собеседований, в том числе 3 технических, и я принял решение — я иду в ЕПАМ. Я пытался следовать советам из статей про то, как принимаются офферы и сколько надо выждать, но в итоге все равно договорился с HR о звонке и сообщил о своих намерениях. Всего процесс трудоустройства занял около трех месяцев, и это были самые насыщенные на учебу месяцы.
Пример резюме
Примеры моих резюме, если вам интересно как я себя позиционировал:
В своих проектах я всегда придерживался философии «как можно меньше правок в фреймворк». Основная задача была сделать проект автообновляемым и не теряющим своей актуальности на протяжении долгого времени. Как я пришел к этой философии?
Почему No или Less Code?
Свои самые первые интернет-магазины я запускал в 2009-2010 годах, тогда не было еще того разнообразия готовых фреймворков и плагинов к ним. Был вордпресс, были скрипты интернет-магазинов с самоустановкой — укажи данные базы и проект начинает свое MVP-путешествие. Что происходило дальше? Если нужен новый заголовок, я лез в код и менял заголовок. Когда нужно было поставить какое-то условие в шаблоне — лез в Smarty и делал условие. Когда менялась логика бизнеса — я копал еще глубже и менял уже PHP-файлы. И вылилось это все в невозможность обновления продукта. А когда у вас успешный сайт, вам нужны новые функции для сохранения бизнеса в игре, и получить вы их можете только сделав еще больше правок в коде, или, как мы их называли всегда, костылей.
В итоге шли годы, а сайт устаревал, а сменить все и при этом сохранить трафик из поисковых систем — задача около нереальная. И когда все-таки этот момент наступал — наступали последствия в виде просадки позиций и падения продаж.
Концепция самообновляемости сайта
В итоге самым правильным решением для бизнеса стал переход на фреймворки с поддержкой плагинов. Таким образом, новые функции прилетали с обновлениями, плагины были изолированы от основного кода и всегда можно было заказать доработку под себя. Тут оставался простор для небольшого фронтенд кодинга, но все в очень жестких рамках.
No code сервисы
Не я один полюбил эту концепцию. В интернете появилось множество сервисов, которые стали помогать делать вам сайт совершенно без кода. Вы собираете интерфейс или даже целое мобильное приложение в визуальном редакторе. Если мои проекты все еще лежат на моих же серверах, то современные тенденции предлагают хранить их у провайдеров услуги за небольшие деньги и при этом всегда иметь возможность принять больше посетителей в моменте, чем позволил бы один свой сервер.
Рассмотрим некоторые из no code сервисов:
Скриншот из видео сверху (оригинал недоступен, сайт не работает):
webflow.com
Удивительный сервис, где даже базы данных нужно проектировать в визуальном интерфейсе. Получается, что это какой-то новый уровень разработки, и теперь можно делать не только сайты-визитки или посадочные страницы, но и полноценные системы управления контентом и онлайн-магазины!
editorx.com
Еще один сервис с возможностью полного проектирования как дизайна, так и базы данных. Проекты, построенные с помощью этой платформы — впечатляют.
bravostudio.app
Неожиданный поворот — это сервис Браво, позволяющий делать мобильные приложения без кода. В какой-то момент начинаешь понимать, что за этим всем будущее. Только сложные проекты с запутанной логикой будут писаться с нуля, все остальное можно будет сделать за пару вечеров без каких либо знаний программирования.
supernova.io
Сверхновую позиционируют уже не как no code, а как удобный код рядом с дизайном. Для тех, кто все еще хочет держать руку на пульсе, но уже хочет упростить себе жизнь.
Какие еще сервисы?
Обратите внимание на Notion (рич-блокнот с коллаборацией), Anima (ожившие прототипы), Play (дизайн мобильных приложений прямо на мобильных приложениях) и Airtable (прекрасная смесь экселя и баз данных).
Миграция на чип М1 от Apple прошла для меня практически бесшовно. Встретилась лишь одна проблема — с установкой psycopg2-binary, что является утилитой, с помощью которой Django Framework подключается к PostgreSQL.
Проблема неприятная и свежая, по ней много вопросов в англоязычной части интернета и очень мало хорошо расписанных инструкций. А на вариант с докером инструкции нет вовсе, это решение мне пришлось придумать самому.
Проблема 1: Не устанавливается psycopg2-binary в Docker-контейнере через Dockerfile или docker-compose (MacOS Big Sur M1)
Здесь самым простым способом будет отказаться от урезанных образов наподобие alpine или slim. Просто используйте самый обычный Python 3.9:
FROM python:3.9
После этого контейнеры поднимутся именно так, как вы их задумывали. Здесь, видимо, проблема в том, что архитектура чипа M1 пока неизвестна и не так популярна. В скором времени эту проблему наверняка исправят.
Проблема 2: Не устанавливается psycopg2-binary в MacOS Big Sur M1
Возможные выводы ошибки:
$ pip install psycopg2-binary
Collecting psycopg2-binary
Using cached psycopg2-binary-2.8.6.tar.gz (384 kB)
ERROR: Command errored out with exit status 1:
И дальше длинный трейс ошибки. Как победить? Если вы только купили свой мак, скорее всего у вас не установлен пакет brew и вам нужно сделать следующие шаги:
Чтобы он запускался без указания полного пути вам нужно добавить этот путь (к многим другим путям) в переменную PATH. Не пугайтесь, это страшно лишь по началу. В unix-подобных системах терминал умеет запускать приложения только если он знает где их искать. А brew установилась в хитрую папку и наш терминал просто не знает этого пути. Пока не знает. Давайте его научим, и рекомендую запомнить этот трюк, он часто нужен (и не только на маках, но и на виндус). На вашем маке в качестве терминала по умолчанию стоит ZSH. Вам нужно создать файл в домашней директории (если там его еще нет, проверить можно командой ls -la) с названием .zshrc (именно с точкой в начале) и положить туда одну строчку:
export PATH=/opt/homebrew/bin:$PATH
Перезапустите терминал, теперь у вас есть brew.
3. Дальше проще, установите сам пакет с Постгресом
brew install postgresql
4. Теперь установите SSL, без него не заработает
brew link openssl
5. Пропишите в наш созданный в пункте 2 файл еще один путь:
Получил список рекомендаций от знакомого разработчика — что нужно знать, программа-минимум. Решил оставить в блоге этот перечень, чтобы не затерялся. Итак:
Как минимум поверхностное понимание работы JavaScript
Если учить React, то сфокусироваться на практическом применении, а также разобраться с фреймворками на его основе, например next.js, который позволяет обойтись без бэкенда вовсе
Ознакомиться с технологиями публикации сайтов прямо из репозитория, например Netfly
Понять JAMstack, так как он очень популярен и удобен
Взять на вооружение технологию htmx, которая позволяет сделать отзывчивый интерактивный сайт без JS, только на питоне
Узнать больше про безсерверную архитектуру на основе AWS и Lambdas (причем докер образы будут прямо в Лямбде). В питоне это позволяет сделать утилита Zappa
Также общий набор рекомендаций для софт-скиллов:
Писать хорошие коммиты
Уметь делать CI/CD
Писать тесты для своих проектов на гитхабе
Проявлять активность на гитхабе в целом
Писать красивый PEP8 код
Писать статьи в блог
Может, даже вести подкаст
Помогать с опен-сорс проектами
И это ведь только начало. Впереди столько интересных технологий!
