Подкаст хорошего программиста

R.01 Ruby on Rails: Введение, установка Друзья, ловите урок по Ruby on Rails. Рассказываем, как работают рельсы (вкратце), что лежит в папке проекта. Устанавливаем ruby + rvm + rails в убунту, создаем новый проект и деплоим его на Heroku. Если хотите научиться Ruby on Rails с нами и стать разработчиком — мы как раз учим таком, записывайтесь на наш интенсив: ➡️ https://bit.ly/3A84yv1 Старт нового потока — 13 февраля 💳 При полной оплате — промокод RUBYRUSH Или можно оплатить сразу или в рассрочку на 4, 6 или 12 месяцев. Пишите в личку, расскажу.

R.02 Ruby on Rails: Модели, миграции На нашем интенсиве мы стопятсот раз рассказали про магию моделей в рельсах, как работает ActiveRecord и откуда у руби-объектов берутся геттеры и сеттеры с названием полей в таблице БД, зачем нужны миграции и как они работают. Теперь я постарался сделать такое видео, чтобы больше не рассказывать. Надеюсь, получилось. Зацените! Если хотите научиться Ruby on Rails и стать разработчиком — мы как раз учим такому, записывайтесь на наш интенсив: ➡️ https://bit.ly/3r27DK4 Старт нового потока — 13 февраля 💳 При полной оплате — промокод RUBYRUSH Или можно оплатить сразу или в рассрочку на 4, 6 или 12 месяцев. Пишите в личку, все расскажу.

R.03 Ruby on Rails: Контроллеры, пути Ещё одна концепция, которую сложно понять новичкам, изучающим рельсы: как после нажания «ОК» в форме на сайте, данные оказываются в базе данных. Чтобы разоблачить эту магию, я убрал из этого уравнения HTML-форму и шлю на сервер запросы (эмулирующие отправку этой формы) руками, прописывая все параметры, как если бы этот запрос был отправлен из формы. А потом в дебагере показываю, где мы оказались в коде rails приложения (спойлер, в методе контроллера). Все это (и многое другое) мы с удовольствием расскажем вам на нашем интенсиве по Ruby on Rails: ➡️ https://bit.ly/33c1oKx Стартуем уже в конце недели, 13 февраля 💳 При полной оплате — промокод RUBYRUSH Или можно оплатить сразу или в рассрочку на 4, 6 или 12 месяцев. Пишите в личку, все расскажу.

R.04 Ruby on Rails: Шаблоны (views), ERB В MVC осталась одна неразобранная буква — V, views (виды, шаблоны, «вьюхи»), в этом уроке поговорим про неё. Расскажу, как рельсы выбирают, где брать вьюху для отрисовки в конце конкретного действия, как она формируется из кусочков HTML-кода и вставок ruby-кода. Расскажу про удобные методы-помощники, доступные из коробки, view helpers. Все это (и многое другое) мы с удовольствием расскажем вам на нашем интенсиве по Ruby on Rails: ➡️ https://bit.ly/3v6WABE Группа уже стартовала 13 февраля, но можно ещё заскочить: 💳 При полной оплате — промокод RUBYRUSH Или можно оплатить сразу или в рассрочку на 4, 6 или 12 месяцев. Пишите в личку, все расскажу.

R.05 Ruby on Rails: Формы, лэйауты (layouts), assets pipeline 5-й урок нашего курса по основам Ruby on Rails. Если за неделю ролик наберет 200 лайков, в следующий четверг закину 6-й урок. Сегодня продолжим про вьюхи (views) — специальные помощники для создания форм (form helpers), сделаем форму для создания вопроса, расскажу , как управляют HTML-лэйаутом (layout), в который заворачиваются шаблоны каждой отдельной вьюхи + добавим стили (stylesheets) в rails-приложение с помощью assets pipeline. Кстати, можно ещё заскочить на наш интенсив. ➡️ https://bit.ly/3wAeZb3 При полной оплате скидка 5000 по промокоду RUBYRUSH, или в рассрочку на 4, 6 или 12 месяцев. Все вопросы — в личку @installero.

R.06 Ruby on Rails: Паршлы (partials), хелперы (helpers), flash Правила те же. Давайте соберем 200 лайков и я опубликую 7-й урок (через пару дней). В этом уроке поговорим о том, куда можно вынести сложную логику из шаблонов: паршлы (partials) и хелперы (helpers). Также расскажу про объект flash для передачи сообщений при редиректе из контроллера на другую страницу. Ну и поговорим про многоуровневую архитектуру (layered architecture) и обсудим, какой код куда лучше запихивать в rails-проектах. Ну и традиционно ссылка на наш интенсив. ➡️ https://bit.ly/3Me1hPt Если хотите попасть на следующий поток — записывайтесь.

Что меня как организатора курсов по веб-разработке спрашивают чаще прочего? 9 из 10 студентов приходит к нам с целью устроиться на работу Ruby on Rails разработчиком. И примерно половина перед тем, как записаться на курс, спрашивает: «Если пройду ваш курс, я смогу устроиться?», «Знаний после вашего курса хватит для прохождения собеседований?», «Тяжело ли найти работу после курса сейчас?». Такой вопрос задают не только нам, но и поди всем школам по программированию. Поэтому на лендингах обычно столько всего пишут про трудоустройство: вот эти все «так будет выглядеть ваше резюме», центры карьеры и даже гарантии, мол: «не устроитесь — вернем деньги». Всё это пишут с целью «снять» это «возражение», конечно (и правильно делают). Кстати, сделать, чтобы после курса было легко найти работу — проще простого. Соберите все мыслимые и немыслимые требования из вакансий и запихните всё это в программу. Готово. Формально, возьмут ли вас после прохождения такого курса на работу. Конечно! Но будет ли у этого курса хоть один выпускник? Понимаете, куда я клоню? Речь сейчас даже не о других онлайн-школах. Я хочу немного поговорить о самих студентах. Если очень сильно упростить последовательность шагов для старта карьеры разработчика (если вы решили пройти курс, конечно), получится как-то так: Записаться на курс — Пройти курс — Найти работу В голове будущего студента самое сложное звено в этой цепочке, конечно, последнее. А теперь угадайте, какое звено в этой цепи объективно самое сложное на самом деле? Спойлер: второе. Взять хотя бы длительность. Наш интенсивна длится 4.5 месяца и за всю его историю в это время уложился только 1 (прописью: один) студент. В среднем студент проходит существенную часть нашего курса (90%) за 6 месяцев. При этом, чтобы после окончания курса искать работу полгода — это прям надо очень сильно не хотеть ее найти. Если курс действительно серьезный и включает в себя объем знаний и навыков, достаточный для устройства на работу, то самое сложное на вашем

R.07 Ruby on Rails: Аутентификация, вход на сайт, сессии (session), куки (cookies) Пора к нашему askme прикрутить регистрацию и вход на сайт. Для этого надо узнать про то, как сервер «узнает» браузер (понимает, что HTTP-запрос пришел от того же клиента), познакомиться с понятием сессии (глянем, что внутри рельсовой сессии зашифровано), узнать про хэширование паролей, bcrypt и хранение паролей в базе данных. После этого урока точно почувствуете себя настоящими программистами. Ну и, традиционно, ссылка на наш интенсив по Ruby on Rails. ➡️ https://bit.ly/3OaxpnH Если хотите в следующий поток — вам сюда — Когда следующий видос? — Ну вы же в курсе. Когда этот наберет 200 лайков

Привет, друзья! Завтра, 25 декабря, в 17:00 МСК мы с Женей ждем вас на стриме по ChatGPT: новой нейросети, способной, в том числе, писать программы, исправлять ошибки в коде, подсказывать решения тестовых задач. 🤖 Присоединяйтесь! 👋 (да, запись будет) https://youtu.be/1QxGcLELOrs

R.08 Ruby on Rails: Валидация данных, колбэки в моделях, CRUD юзеров Ловите долгожданный 8-й урок. Спасибо всем за лайки! Ещё раз прошу прощения за задержку. В этом видео поговорим про проверку данных перед сохранением в БД (валидации, rails validations) и про преобразование этих данных перед сохранением/обновлением/удалением (колбэки, rails callbacks). Удобством использования ActiveRecord так и подталкивает нас к тому, чтобы всё проверять в моделях и, заодно, при сохранении в базу навернуть кучу действий по колбэкам. Так делать не стоит, об этом тоже поговорим. Ещё сделаем валидацию почты, подтверждение пароля и добьем CRUD юзеров. До следующего видео 250 лайков под этим. 22-го января у нас стартует новый поток интенсива по Ruby on Rails: ➡️ https://bit.ly/3Wn56HN 💳 По промокоду RUBYRUSH скидка 7500. Все вопросы пишите мне в личку: @installero.

Друзья, поздравляю вас с Новым годом! Не у всех сейчас есть настроение отмечать этот праздник. И этих людей можно понять: когда год — такой, каким был 2022-й, то «поскорее бы прошел и славу Богу». Однако, предлагаю в эту новогоднюю ночь найти в себе тепло и добрые слова для ваших друзей и близких. Желаю вам в 2023-м не счастья, радости и здоровья, а дисциплины, самоконтроля, смекалки и умения быстро принимать взвешенные решения. Уходящий год показал, насколько эти качества на самом деле важны. А ещё уходящий год наглядно показал, что никакие инвестиции не уберечь: рубли, доллары, акции, облигации, металлы и даже квартиры могут внезапно падать в цене, замораживаться, становиться недоступными и т.д. С одним исключение — инвестиции в самих себя, в ваши способности, навыки и качества. В очередной раз напомню, что 22 января вы можете начать обучение на нашем интенсиве по Ruby on Rails, который, возможно, станет для вас стартом новой карьеры. Как говорится, хороший Ruby on Rails разработчик — и в Казахстане/Армении/Польше/Германии хороший Ruby on Rails разработчик. Ловите промокод RL23NY на 12 023 рубля (при полной оплате) и записывайтесь! Ещё раз с наступающим вас! 🎄

🎶 Немного музыки для работы Дебютный альбом моего брата в жанре Lounge Несмотря на название - мне заходит и во время кодинга 🙂 Хочется услышать в комментах отзывы опытных меломанов — что хорошо, что плохо? Сссылки на альбом ⬇️ https://music.yandex.ru/album/26340373 https://open.spotify.com/album/1CMDH6BXJtXEYEZv7esex7 https://music.apple.com/us/album/aftercoding/1693373990

Про Вадика на память https://youtu.be/FHW0bXcQ4Is

1. Подарок 🎁 к рождеству 2. Про канал и интенисв https://youtu.be/2Mg0oz3DDr4?si=FjSf7jaJY_XNlh5r

Первый урок нашего легендарного интенсива. Интересно, что в самых первых потоках его не было. Но мы с Вадиком заметили, что некоторые ученики не имеют нормальной ментальной модели работы современного интернета. А без нее очень плохо ложатся фреймворки, рельсы и все остальное. Пришлось как обычно за 18 минут вспомнить всё 🤓️️️️️️ https://youtu.be/PslExWYTD8U?si=cPDeyAcF2bLAJHV7tuj

Коротышечка 1 Наблюдаю как все сходят с ума по AI. По принципу обезьяна увидела осмысленный текст — обезьяна наделила "автора" текста осмысленностью. К сожалению сходят с ума действительно все, то есть и многие состоятельные топ менеджеры и владельцы больших и малых хайтек компаний, и инвесторы и венчурные фонды. Глупые компании "делают ставку на ИИ" и сокращают штат. Умные знают где их бизнесу ИИ помогает, а где нет и пользуясь случаем отбирают с рынка по дешевке лучших программистов. Еще они понимают, что скорость написания говнокода никогда не была важной метрикой. Более того, они знают, что чем меньше кода, тем лучше (строчки кода это не актив, а пассив для бизнеса). Когда пузырь лопнет, глупые компании останутся с простреленными ногами. Незавидна судьба многих из них. А умные останутся с лучшими командами и уменьшенной конкуренцией.

Разминка для ума 🧠 Пример вопроса на собес уровня senior/staff+ по мотивам реальной рабочей проблемы. Вы тех лид сервиса типа google analytics. Внезапно обнаружился баг в вашем алгоритме расчета пользовательских сессий (какой юзер сколько времени провел на каком сайте, сколько визитов на сессию, сколько сессий в день и т.п.), вы диагностировали баг, оказалось он возник еще 5 лет назад. Ошибочные результаты огорчают некоторых самых важных ваших клиетов и они хотят все исправить. К счастью у вас есть архив событий (с информацией о юзере - user agent, cookie, ip и о визите - timestamp, url, и т.д.) в виде zip файлов на S3. Каждый файл несколько десятков гигабайт событий за ровно 1 час какого-то дня (час и день в пути файла видны). Внутри этого файла события не отсортированы. Для простоты положим у вас есть либа для последовательного чтения строк из этого файла без загрузки всего файла в память или копирования целиком из S3. Предложите схему решения проблемы и ее trade-offs. 1. Без шпаргалки в общих чертах - основные движущиеся части, алгоритмы и что куда идет. Не надо разбираться в фреймворках, можно на пальцах пояснить суть того что требуется от каждой части системы. 2. Полезно потом погуглить и составить более детальную картину (или полностью поменять свой изначальный проект). 💬 Доп вопросы и свои идеи пишите в комментах

🧐 Коротышечка 2 В реальных проектах и реальных компаниях (от нескольких десятков разработчиков) время и ресурсы потраченные на написание и исправление непосредственно кода это от силы 20-30% времени разработчика (в крупных компаниях даже 10% можно считать удачей). Все остальное (думание, анализ, коммуникация, принятие решений, проектирование и т.д.) гораздо более важные процессы. И их LLM-ки не умеют by design. В лучшем случае они эти процессы только имитируют. Значит в самом идеальном раскладе прирост общей скорости серьезного проекта не значительный, а компромиссы в качестве — это новый риск, плохо предсказуемый. Речь идет о серьезных проектах, когда разрабатывается что-то в какой-то степени новое, не типовое. Там где нельзя просто скопипастить. Там где нужны живые разработчики. Как правило это растет из уникального набора требований даже в рамках вроде бы типовой задачи. Например интернет магазин на Shopify и Amazon, и то и то магазин. Но есть нюансы :) Личное наблюдение с LLM агентами моя продуктивность написания кода на Java с учетом всех переделок, тяни-толкаев и прочего в среднем почти сравнялась с моей же скоростью работы на Typescript (которая в свою очередь немного отстает от скорости работы на Ruby) Мораль Морали нет, в работе все средства хороши, которые помогают. А еще Java - говно мамонта 🦣, без которого в 2026м в 99% случаев можно было бы прекрасно обойтись. Только заядлым джавистам не говорите 🤫 им тоже надо семью кормить.

🧐 Коротышечка 3 ЛЛМки изменяют работу программистов но не совсем так как шароголовые эффективные мэнеджеры думают. ЛЛМка не думает как программист, не принимает решения как программист, она не способна заменить программиста, ни опытного ни начинающего. Также она не способна сама по себе волшебно ускорить или облегчить работу программиста (про это предыдущая коротышечка ☝️). И волшебным образом превратить рядового менеджера в инженера она тоже не способна. ЛЛМка как любой новый инструмент это мультипликатор. Если вы достаточно долго общались с ними не только на тему кода вы не могли не заметить, что ЛЛМкам свойственно отражать и усиливать ваши собственные bias, докадки, мысли, предположения. Так устроен сам дизайн этого алгоритма - он подхватывает затравку и развивает ее, он не обладает собственной агентностью, а ее имитация с помощью рандома слишком примитивна, чтобы всерьез конкурировать с человеческой. Из этого следует, что та же самая команда инженеров может справляться с более масштабными задачами. Обратный процесс сокращения команды при сохранении текущий масштабов задачи работать так просто не будет. Во-первых из-за нелинейности этой работы (см. "мифический человеко-месяц" и пр.), во-вторых из-за того, что растущая конкуренция будет скорее навязывать расширение масштабов задач, а не урезание костов. Может не значит будет. Инструмент-усилитель усиливает и плохие и хорошие решения. Цена ошибки будет возрастать, а растущие масштабы проектов будут создавать отрицательную обратную связь (чем больше выработка программистов - тем сложнее и крупнее проект - чем крупнее и сложнее проект - тем сложнее его двигать с ЛЛМ или без). И общедоступность инструмента постепенно нивелирует различия между компаниями и командами. И несмотря на может быть новый способ и формат работы приведет всех к общему знаменателю. Не только вы такой умный и научились готовить ваших агентов вам кодить, но и все ваши конкуренты. А значит все быстро вернется на круги своя — ключевым фа

😎 Коротышечка 4 Знания можно условно разделить на декларативные и процедурные. ЛЛМки by design заточены на декларативные и коммуникацию. Процедурные они лишь имитируют. Работа современного инженера это в первую очередь процедурные знания. И чем сложнее проект, тем в большей степени. А значит страхи программистов о потере работы вызваны проф деформацией (Ходжа Насреддин тоже искал деньги там где светло, а не там где потерял), нежели объективным анализом. В первую очередь жопа должна гореть у современные юристов, врачей (тех из них, работа которых сводится к следованию протоколов и выписыванию бумажек), психологов, консультантов и прочих профессий где доминирует коммуникация и декларативные знания. Кстати, it менеджмент сюда тоже не относится. Управлять людьми и принимать решения это тоже процедурные знания, а иногда вообще магия.

😎 Коротышечка 5 Повод для поста - новый тренд ждать когда ИИ заменит менеджеров. Повальной замены инженеров чета как-то не случилось, поэтому чтоб второй раз не собираться журналисты переключились на новую тему. Несколько суровых истин из моего наблюдения за реальностью: 1. В хайтек компаниях всегда менеджмент самая важная и одновременно почти всегда самая плохо организованная функция. В каждой компании я встречаю по несколько сильных программистов и 1-2 вау. А менеджеров, которых хочется приводить в пример и у кого хочется учиться я за всю карьеру встретил примерно 5. 2. Инженеры и их крутые навыки играют критичную роль только в 0.01% по-настоящему инновационных проектов (R&D), для всех остальных - с большим запасом достаточно тех, кого можно нанять на рынке (если не факапить функцию хайринга). 3. Ключевая роль менеджеров в 99.9% компаний (включая почти все текущие проекты фаанга, например) - правильно собрать машину бизнеса из ролей и людей (инженеров, маркетологов, продажников и тп) и поддерживать ее в здоровом состоянии. Так же как программист в тех же 99.9% компаний собирает систему из известных решений, фреймворков, библиотек, алгоритмов, сервисов. 4. В реальности большинство менеджеров это бывшие программисты, сейлзы и пр (часто фиговые), которые по разным причинам пошли в менеджмент как более изи уровень игры. На самом деле наоборот, но… 5. …но текущая система в хайтеке сложившаяся еще 20 лет назад (когда создавались те 0.01% технологий) и по инерции исповедуемая ее авторами (фаанг) помогает менеджерам замести сложность под ковер, раскидать свои ключевые функции на других людей (чего стоит только стандартная практика performance review, где ты сам себе придумываешь цели а потом сам себя по ним оцениваешь + мнения о тебе коллег) и достаточно долго выживать в роли примитивного передатчика информации, съезжая на базаре и получая звездочки на погоны по принципу ходжи насреддина: или шах сдохнет (команда виновата, все провалила, несмотря на мои

Для порядка и удобства опубликован плейлист Интенсив 2nd edition. Там будут собраны все уроки в том порядке, как они есть в самой последней версии интенсива Хорошего Программиста. Уже опубликована часть курса НПДВ1, включая блок уроков про методы и классы, нигде ранее не публиковавшийся.