📌 Spark или Pandas?

Представим, что нам нужно найти количество раз, сколько слово встречается в тексте. Стандартный подход на Python будет такой:
💋 Открываем файл
💋 Читаем строки
💋 Если в строке нашли слово, то увеличиваем счётчик

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

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

При использовании Spark, мы:
1️⃣ Создаём драйвер — приложение для координации работы и взаимодействия с кластерами.
2️⃣ Пишем инструкцию на получение данных. Поскольку Spark рассчитан на большие объёмы данных, которые не будут храниться локально, он может работать с HDFS, S3 и многими другими системами хранения данных.
3️⃣ После инструкции на получение данных мы описываем действия, что с этими нужно с данными сделать.
4️⃣ Мы можем запросить результаты, и в этот момент начнётся обработка действий. Spark разделит данные на партиции и распределит вычисления на разных кластерах.

Мы получим результат вычислений значительно быстрее обычного скрипта на Python.

🖌 Действия в Spark описываются SQL-подобным синтаксисом, прям как в Pandas. Pandas используется также, как и Spark, но не предоставляет распределения вычислений по кластерам.

Если вам интересно поработать с большими данными и изучить Spark, то стоит начать с Pandas. Вот введение в Pandas на литкоде и 30 дневный план изучения. Второй я сам прошёл без подготовки, так что могу порекомендовать даже новичкам 🤓

🍰 #it #просто_о_сложном

〰️ 3️⃣ лучшие практики коммитов в GIT

Линус Торвальдс на днях сделал заявление:

Anyway, on a completely different note: I try to make my merge commit messages be somewhat "cohesive", and so I often edit the pull request language to match a more standard layout and language. It's not a big deal, and often it's literally just about whitespace so that we don't have fifteen different indentation models and bullet syntaxes. I generally do it as I read through the text anyway, so it's not like it makes extra work for me.

But what *does* make extra work is when some maintainers use passive voice, and then I try to actively rewrite the explanation (or, admittedly, sometimes I just decide I don't care quite enough about trying to make the messages sound the same).

So I would ask maintainers to please use active voice, and preferably just imperative.

Put another way: I'd love it if people would avoid writing their descriptions as "In this pull request, the Xyzzy driver error handling was fixed to avoid a NULL pointer dereference".

Instead write it as "This fixes a NULL pointer dereference in .." or particularly if you just list bullet points, make the bullet point just be "Fix NULL pointer dereference in ..".

This is not a big deal, I realize. But I happened to try to rewrite a few of these cases the last week, and I think simple and to-the-point language is better. The imperative version of just "Fix X" is about as clear as it gets.

А если по-русски и кратко, то он обращается к разработчикам ядра Линукс и просит писать текст к изменениям более понятным языком. Показалось полезным, поэтому вот советы для хороших коммитов:

1. Пишите описание кратко, в формате продолжения фразы "Это изменение исправит ...", например "fix image description".

2. Делайте коммит только полноценных изменений. Не нужно коммитить половину работу или непротестированные изменения.

3. Следуйте одному формату во всех коммитах.

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

🍰 #it #просто_о_сложном

🔠🔠🔠: какую выбрать?

Если вы только изучаете SQL (супер-полезный пост тут), то вы точно задаётесь вопросом, какую систему для управления Базами Данных использовать. Скорее всего, вы выбираете из MySQL, PostrgeSQL и SQLite. Возможно вы смотрите на Oracle, ЯндексДБ или даже на Firebird.

〰️ А что-же стоит выбрать на самом деле? Ответ прост.

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

👁‍🗨 Как и в случае с другими инструментами, используйте популярные решения. Для этого читайте опросы и исследования рынка, как это делаю я (1, 2, 3, 4, 5). И самым популярным решением сейчас является PostgreSQL.

🍰 #it #мои_мысли

☠️ Проклятие знания

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

Но посетив ГЭС-2 в третий или четвёртый раз вы будете легко ориентироваться и разметка будет выглядеть понятной и логичной. Почему так происходит?🤔

Есть такое конгитивное искажение — «проклятие знания».

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

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

☕️ Изучая новую тему - помните об этом. Зачастую новые знания не сложные, но из за того, что лектор столкнулся с этим искажением, вам будет ничего не понятно. Более того, коллеги лектора могут так же, как и сам лектор, воспринимать материал как очень понятный.

А вы сталкивались с таким «проклятием?» 🔽

🍰 #it #просто_о_сложном

💬 Почему решили сменить место работы?

Такой вопрос часто ставит соискателей в ступор. Разберёмся, как отвечать на него.

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

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

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

Примеры:

1. "При оформлении у нас были одни условия работы. В связи с реорганизацией компании они изменились и меня это не устраивает".

Объясните, что речь идёт, например, о обязательном посещении офиса. У нового работодателя, соответственно, это не должно быть обязательным условием работы. 🖥

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

Помните, что проблема скорее всего в вашем отношении и покажите, что вы над этим работаете. ⌛

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

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

🍰 #it #it_собесы

🥇 А вы получили медальки на литкоде в этом году? Делитесь в комментариях!

Хочу записать миникурс про решение алгоритмов, но не понятно, будет ли вам интересно. Напомню, что у меня есть сайт с самыми полезными заданиями из литкода, пост про решение алгоритмов и концепции алгоритмов: 1 и 2. 📌

🍰 #it #алгоритмы

👻 Страшные тайны ООП

Всем привет! Завтра, в московском кампусе Школы 21, я проведу лекцию "Страшные тайны ООП". Приглашаю всех!

Выступление будет состоять из двух частей:
➡️ Первая для тех, кто мало знаком с ООП: разберёмся что это такое и как его использовать. Будут даже примеры на языке C!
➡️ Во второй части мы посмотрим на проблемы, с которыми можно столкнуться, используя ООП. Или как говорит Бьёрн Страуструп, "как отстрелить себе ногу".

🎃В заметках к лекции у меня 5000 слов (!), так что это будет очень комплексное выступление с большим количеством информации. Рекомендую взять с собой блокнот и ручку.

🎁 Во время лекции разыграем мини-бокс сладостей к Хеллоуину, а первый, кто задаст вопрос после выступления, получит от меня менторский созвон.

Трансляция выступления будет тут

P.S: Кидайте свои любимые Хэллоуинские стикеры в комменты (я уже скинул)👇

🍰 #it #анонсы

При работе с Python мы часто используем переменные, с таким же названием, как и параметры. Вроде такого:

User(name=name, email=email)

✏️ Мы можем упростить код и написать так:

User(name, email)

👀 А как насчёт такого варианта?

User(email, name)

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

⚡️ В языке Rust используются лучшие возможности всех языков и придумываются всё новые упрощения. И в нём есть такое решение, которое позволяет не сохранять порядок, если название атрибута соответствует названию переменной. Компилятор сам сопоставит нужные параметры и вы можете быть уверены, что три этих варианта будут работать одинаково:

User(name: name, email: email);
User(name, email);
User(email, name);

Я спросил у знакомых, которые пишут на других языках и выяснил, что больше нигде нет такого решения. Интересно, разработчики Rust сами придумали его, или это из какого-то другого языка? Видели ли вы где-то ещё такой подход?🔽

🍰 #it #просто_о_сложном

📥 Пишите TODO в коде!

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

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

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

👨‍💻 Зачастую бизнесу нужно быстрое решение задачи, поэтому у вас может не быть времени для исправления проблемы. Но вы можете помочь себе и продукту тем, что отметите возможность улучшения. Если в будущем у вас будет время на рефакторинг, то вы сможете вернуться к этому коду и исправить то, что отметили.

Не написав TODO-шку ,вы забудете о проблеме уже через пару минут. Лучше иметь проблему и знать о ней, чем вообще не знать о её существовании.

А вы пишите TODO?⬇️

🍰 #it #it_мнение

🏨 АРХИ-СОБЕС

🚀 Есть новость! Я готовлюсь к архитектурным собеседованиям. Есть план из 7 занятий с обязательными домашками. Нужны 1-2 человека, которые тоже хотят подготовиться.

Кто хочет со мной? Пишите в личку - и я скину первую домашку. Кто первый успеет сделать домашку к 18 ноября, с теми будем проходить подготовку.🙂

🍰 #it #архитектура_it

💵Почему IT-курсы такие дорогие? Или как я записал 2 курса.

Спойлер: это долго, дорого и сложно!

На производство одного часа видео нужно более 40 часов работы. А чтобы записать ±10 часов учебного видео-материала мне потребовался целый год! 🥸

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

⌛ После подготовки сценария его проверяют методист и куратор курса. 9 из 10 сценариев возвращаются на доработку. После того, как методист одобряет сценарий, идёт подготовка материалов: текст вычитывается редакторами, дизайнеры подготавливают презентацию, а куратор курса оформляет заметки/лонгрид/транскрипцию к уроку.

🎙Когда все материалы готовы, можно приступать к записи. Казалось бы - самое сложное позади! Но не тут-то было... Любая запись требует в три раза больше исходного материала. То есть для получения финального 5-минутного видео, вам нужно будет потратить порядка 15 минут для его записи. В процессе съёмки спикер всегда запинается, перезаписывает какие-то фразы или может даже молчать целую минуту.

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

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

💸За запись курсов спикеру (в данном случае мне) платят в три раза меньше, чем платят на обычной работе. В среднем, оплата одного видео составляет порядка 4000 рублей. Когда мы говорим, что эта цена за 20 минут, кажется, что это много. Но добавив информацию из прошлого абзаца мы получаем, что за полноценную работу по записи курсов зарплата была бы 85 000 рублей. Учитывая, что это не основная работа - это очень мало.

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

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

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

А я планирую записать мини-курс про алгоритмы. Сделать его платным или бесплатным? 🔈

🍰 #it #it_мнение #it_курсы

⏩ SLA / SLI / SLO

Проектируя сервисы, мы сталкиваемся с тремя понятиями:
🔢Service Level Agreement,
🔢Service Level Indicators,
🔢Service Level Objectives.

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

Пример: Мы арендуем облако, поставщик гарантирует 99,9% доступности сервиса в месяц. При нарушении мы получаем депозит за каждый 0,1% недоступности.

🟥 SLI — это метрики, которые мы будем использовать для оценки выполнения SLA. В примере выше, SLI - это доступность сервиса. Мы можем измерять также скорость ответа от сервера в мс, если нам важна эффективность сервиса и пользовательский опыт.

🟩 SLO — это цели команды по выполнению SLI, зафиксированные в SLA. В нашем примере, метрикой SLI мы выбрали доступность сервиса. Это популярная метрика, для измерения которой используют "девятки".

У нас в примере целевой уровень для SLI равен 99,9% в месяц, значит что 0.1% времени сервис может быть недоступен. Т.к. в месяце у нас около 43 тысяч минут, недоступен сервис может быть 43 минуты. Этот уровень и есть SLO — то есть цель команды по конкретной метрике.

В итоге, SLA - это соглашение, в котором зафиксированы SLI, целевой уровень которых определён SLO.

Сла, сли, сло... Нам и без этого нормально работается...

🍰 #it #просто_о_сложном

👉 Пока мы готовим полезные материалы с трёх выступлений напомню:

🧑‍💻 Ко мне в команду требуется два стажёра. Если вы, или кто-то из ваших знакомых хочет заниматься тестированием или разработкой веба на Python, то кидайте резюме мне в личку -> @PySage

✍️ Даже если кажется, что не готовы выйти на работу, всё равно кидайте!

P.S: Если уже кидали, скиньте ещё раз и напишите куда хотите, в разработку или в тестирование.

🍰 #it #вакансии #It_материалы

🐰 Ну что коллеги, работаем?

В пятницу настроение только такое.

🍰 #it #капимем

🔠🔠🔠🔠🔠🔠🔠

Когда коллега просит посмотреть код, а там коджест 😊

За октябрь и ноябрь я написал полезные посты на разные темы:

⭐️ HR
〰️Что выбрать стартап или крупную компанию?
〰️Секрет поиска ✨ идеальной ✨ работы
〰️Отвечаем на вопрос "Почему решили уволиться?"

😳 Архитектура
〰️Виды Архитектуры ИС
〰️Разбираем понятия SLA/SLI/SLO
〰️Что такое Spark и Pandas
〰️Как выбрать SQL Базу Данных

🪄Полезности
〰️Изучаете новую тему и ничего не понятно? Это проклятие! Проклятие знания.
〰️Полезные практики работы с GIT
〰️Писать ли TODO в коде?
〰️Почему курсы такие дорогие

Про что написать ещё?

🍰 #it #коджест