🎁 А вы знали, что на прошлой неделе День Рождения был не только у Школы 21, но у вашего любимого канала - Чашки Кода! ✨

Уже больше года я пишу для вас посты, а вы поддерживаете реакциями и комментариями. Изначально я создавал этот канал, чтобы провести ретроспективу моего пути в IT, но стал писать скорее про то, что было бы полезно мне год-два (или даже больше) назад.

😌 Мне безумно приятно, когда кто-то говорит, что ему помог мой пост, так что не стесняйтесь и пишите комментарии!

Напишите, что самого полезного узнали от меня за этот год или поделитесь впечатлениями от моего выступления в прошлую пятницу👇

P.S: вы можете поддержать канал бустом и поставив tg_stars постам ❤️

🍰 #it #мысли #мой_путь

🔠🔠🔠🔠🔠🔠🔠

Уже и лето прошло... И "Чашке кода" уже год! 💥

Расскажите в комментарии как отдохнули этим летом (если успели), а я собрал все посты за месяц:

〰️Dozer — приложение для меню бара вашего mac
〰️Моё рабочее место, а скоро будет продолжение
〰️Изучаем регулярные выражения Regex
〰️Читаем отчёт stackoverflow 2024
〰️Я стал выпускником Школы 21
〰️Узнали про bash-терминал Линукс? Вам сюда!
〰️Что делать во время созвона? Изучать «слепую» печать!
〰️День рождение Чашки кода

Ставьте реакты, пишите в комменты, какие посты хотели бы почитать в сентябре 👇

🍰 #it #коджест

😁 Самое главное при постановке задачи - грамотно обозначать дедлайны

🍰 #it #капимем

😱 Новичкам платят больше!?

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

👉 Оценим причины, указанные в этой этой статье. Автор отмечает следующие пункты:

🟡Компании хотят, чтобы вы уволились (есть норма, сколько людей должны быть уволены)
🟡Повышение зп ограничено, а бюджеты на найм выше
🟡HR-ы могут не оценивать долгосрочные расходы на найм, считая их постоянными расходами бизнеса
🟡Опыт вне компании ценится больше
🟡Мало кто хочет заниматься решением таких проблем

Некоторые пункты разберу подробнее со своим мнением. А с какими вы согласны или не согласны? 🔽

🍰 #it #мои_мысли #it_инсайт

💻 Язык С падает в рейтинге?

📉Свежее обновление рейтинга TIOBE показывает, что язык С теряет популярность. Я уже писал почему стоит учить язык Си, но для коммерческой разработки он не подходит.

📈 Язык RUST, к слову, в этом рейтинге поднялся с 17 до 14 позиции. Ждём его в топ 10. Python всё ещё занимает лидирующую позицию, и это не удивительно.

Если вы тоже учите Python или другой популярный язык, то скорее читайте мой пост про то, как накрутить получить опыт 👀

🍰 #it #находки #it_отчёт

⭐️ Недавно писал пост про игры с использованием терминала. Как насчёт чего-то более стандартного?

А что нашёптывают карты вам в первый рабочий день недели? 〰️

🍰 #it #капимем

♦️Любите играть в покер? Играйте в покер на работе!

Да-да, я не шучу. Ведь лучшим инструментом для оценки задач является покер-планирование.

Как вы наверное знаете, мне очень нравится тема Agile. Я уже писал про концепцию Agile в целом, выступал в Школе 21 про Agile и писал о книге про Agile.

Но не рассказывал о том, как оцениваются задачи при работе по гибким методологиям (agile-разработка).

В чём суть метода покер-планирования?
🟡Все участники команды разработки должны оценить задачу в условных единицах.
🟡Если до этого вы ничего не оценивали, то возьмите уже готовую задачу (или первую задачу в спринте) и оцените её в 5 стори-поинтов.
🟡Новую задачу оцените относительно той оценённой.
🟡🔘Она сложнее? 🔜 поставьте оценку выше.
🟡🔘Она проще? 🔜 поставьте оценку ниже.
🟡Кто то проголосовал за задачу больше или меньше чем другие? Пусть расскажет почему он так решил и переголосуйте!

Отмечу особенности оценки задач:
🟢 В работу необходимо взять как можно больше задач, но нам нужно понимать, сколько реально мы успеем сделать. Для этого мы смотрим на velocity и capacity (скорость и объем).
🟢 Среднее количество стори поинтов решённых задач в прошлых спринтах это наша скорость (velocity). А объём (capacity) состоит из количества разработчиков и дней в спринте. Если вы решили задач на 100 стори-поинтов, но половина разработчиков ушла в отпуск, то ваш capacity теперь 50.
🟢 Оценивать задачу нужно в абстрактных величинах в сравнении с другими задачами. Используйте оценку в 1, 3, 5, 8, 13 и 20 стори поинтов.

🌟 А вы используете покер-планирование в работе?

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

🔠🔠🔠🔠🔠🔠🔠

Чувствуете это...? Октябрь, за окном холодает, но в Чашке кода всегда тепло и уютно ☕️

Согрейтесь горячими постами за сентябрь:

〰️Почему новичкам платят больше? Узнать
〰️Язык С падает в рейтинге! Что будет дальше?
〰️Чем капибара занимается у себя на работе? Улыбнуться
〰️Рассказываю, что такое покер-планирование. Читать

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

🍰 #it #коджест

Стартап без роста 🔤🔤 крупная компания с возможностью роста?

Ответ прост: идите работать туда, где вы бы хотели работать!

🚀 Рост в компании - обычно лишь уловка HR и корпоративной культуры. На самом деле, гарантировать его вам никто не может. Всегда лучше считать, что роста не будет. Скорее всего повышение по должности и хорошую премию получит ваш начальник, а не вы.

🤑 Так же стоит относиться и к премиям, и к бесплатному фитнесу и другим "плюшкам". Меня скорее они будут настораживать: если они есть в компании, то возможно это означает, что там никто не хочет работать, и компании приходиться как-то удерживать, мотивировать старых сотрудников и привлекать новых.

Если вам было бы интересно работать в этой команде / компании и без всех бонусов, то однозначно вам стоит там работать! Если вам нужны бонусы, то и работать вы, вероятно, будете ради них, а это прямой путь к выгоранию 🫠

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

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

А на какой стороне вы: стартап или корпорация? ⬇️

🍰 #it #мысли

🧑‍🍳 Рецепт резюме, с котором вы сразу получите приглашения на собеседования

Сделать идеальное резюме легко! Даже если у вас нет опыта.

1️⃣ Ответьте на эти вопросы в своём резюме:

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

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

3️⃣ Такое тестовое собеседование вы можете пройти со мной, для этого пишите в личку. Хотите пройти бесплатно - кидайте резюме в комментарии, и если мне будет интересно пообщаться с вами, напишу сам!

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

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

🍰 #it #it_советы

📌 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 #мои_мысли