Привет, друзья!
Завтра, 25 декабря, в 17:00 МСК мы с Женей ждем вас на стриме по ChatGPT: новой нейросети, способной, в том числе, писать программы, исправлять ошибки в коде, подсказывать решения тестовых задач. 🤖
Присоединяйтесь! 👋
(да, запись будет)
https://youtu.be/1QxGcLELOrs
Завтра, 25 декабря, в 17:00 МСК мы с Женей ждем вас на стриме по ChatGPT: новой нейросети, способной, в том числе, писать программы, исправлять ошибки в коде, подсказывать решения тестовых задач. 🤖
Присоединяйтесь! 👋
(да, запись будет)
https://youtu.be/1QxGcLELOrs
YouTube
ChatGPT для разработчиков с примерами 🤖
🤖 ChatGPT: https://chat.openai.com
🎒 Курс Ruby on Rails с нуля: https://bit.ly/3Ghfvin
📍 Уютный чат рубистов: https://bit.ly/3GhfIlF
Показываем, как пользоваться Chat GPT на примере простых задач по Ruby (которые можно встретить, например, при устройстве…
🎒 Курс Ruby on Rails с нуля: https://bit.ly/3Ghfvin
📍 Уютный чат рубистов: https://bit.ly/3GhfIlF
Показываем, как пользоваться Chat GPT на примере простых задач по Ruby (которые можно встретить, например, при устройстве…
👍16🔥11❤6
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.
Ловите долгожданный 8-й урок. Спасибо всем за лайки! Ещё раз прошу прощения за задержку.
В этом видео поговорим про проверку данных перед сохранением в БД (валидации, rails validations) и про преобразование этих данных перед сохранением/обновлением/удалением (колбэки, rails callbacks).
Удобством использования ActiveRecord так и подталкивает нас к тому, чтобы всё проверять в моделях и, заодно, при сохранении в базу навернуть кучу действий по колбэкам. Так делать не стоит, об этом тоже поговорим. Ещё сделаем валидацию почты, подтверждение пароля и добьем CRUD юзеров.
До следующего видео 250 лайков под этим.
22-го января у нас стартует новый поток интенсива по Ruby on Rails:
➡️ https://bit.ly/3Wn56HN
💳 По промокоду RUBYRUSH скидка 7500.
Все вопросы пишите мне в личку: @installero.
YouTube
Уроки Ruby on Rails - 8. Валидации, колбэки, CRUD юзеров 🛤️
Основы Ruby on Rails - Урок 8. Валидация данных, колбэки в моделях, CRUD юзеров
📍 Курс Ruby on Rails с нуля: https://bit.ly/3hRSKbv
💎 Уютный чат рубистов: https://bit.ly/3WqrUpN
В этом коротком уроке расскажу, как в rails принято проверять данные, которые…
📍 Курс Ruby on Rails с нуля: https://bit.ly/3hRSKbv
💎 Уютный чат рубистов: https://bit.ly/3WqrUpN
В этом коротком уроке расскажу, как в rails принято проверять данные, которые…
❤12👍4
Друзья, поздравляю вас с Новым годом!
Не у всех сейчас есть настроение отмечать этот праздник. И этих людей можно понять: когда год — такой, каким был 2022-й, то «поскорее бы прошел и славу Богу». Однако, предлагаю в эту новогоднюю ночь найти в себе тепло и добрые слова для ваших друзей и близких.
Желаю вам в 2023-м не счастья, радости и здоровья, а дисциплины, самоконтроля, смекалки и умения быстро принимать взвешенные решения. Уходящий год показал, насколько эти качества на самом деле важны.
А ещё уходящий год наглядно показал, что никакие инвестиции не уберечь: рубли, доллары, акции, облигации, металлы и даже квартиры могут внезапно падать в цене, замораживаться, становиться недоступными и т.д.
С одним исключение — инвестиции в самих себя, в ваши способности, навыки и качества. В очередной раз напомню, что 22 января вы можете начать обучение на нашем интенсиве по Ruby on Rails, который, возможно, станет для вас стартом новой карьеры. Как говорится, хороший Ruby on Rails разработчик — и в Казахстане/Армении/Польше/Германии хороший Ruby on Rails разработчик.
Ловите промокод
Ещё раз с наступающим вас!🎄
Не у всех сейчас есть настроение отмечать этот праздник. И этих людей можно понять: когда год — такой, каким был 2022-й, то «поскорее бы прошел и славу Богу». Однако, предлагаю в эту новогоднюю ночь найти в себе тепло и добрые слова для ваших друзей и близких.
Желаю вам в 2023-м не счастья, радости и здоровья, а дисциплины, самоконтроля, смекалки и умения быстро принимать взвешенные решения. Уходящий год показал, насколько эти качества на самом деле важны.
А ещё уходящий год наглядно показал, что никакие инвестиции не уберечь: рубли, доллары, акции, облигации, металлы и даже квартиры могут внезапно падать в цене, замораживаться, становиться недоступными и т.д.
С одним исключение — инвестиции в самих себя, в ваши способности, навыки и качества. В очередной раз напомню, что 22 января вы можете начать обучение на нашем интенсиве по Ruby on Rails, который, возможно, станет для вас стартом новой карьеры. Как говорится, хороший Ruby on Rails разработчик — и в Казахстане/Армении/Польше/Германии хороший Ruby on Rails разработчик.
Ловите промокод
RL23NY на 12 023 рубля (при полной оплате) и записывайтесь!Ещё раз с наступающим вас!
Please open Telegram to view this post
VIEW IN TELEGRAM
goodprogrammer.ru
Онлайн интенсив по Ruby on Rails
От новичка до профессионального Ruby разработчика за полгода. Уроки, задачи, ежедневный кодревью, еженедельные вебинары. Помощь в трудоустройстве.
❤18👍15
Страх перед будущим AI (ChatGPT и все такое)
Anonymous Poll
22%
Я боюсь что потеряю (или так и не найду) работу программиста 😱
32%
Я рад, ведь теперь работать программистом станет проще 😎
46%
Это все хайп! Нехватка программистов будет только расти
🎶 Немного музыки для работы
Дебютный альбом моего брата в жанре Lounge
Несмотря на название - мне заходит и во время кодинга 🙂
Хочется услышать в комментах отзывы опытных меломанов — что хорошо, что плохо?
Сссылки на альбом ⬇️
https://music.yandex.ru/album/26340373
https://open.spotify.com/album/1CMDH6BXJtXEYEZv7esex7
https://music.apple.com/us/album/aftercoding/1693373990
Дебютный альбом моего брата в жанре Lounge
Несмотря на название - мне заходит и во время кодинга 🙂
Хочется услышать в комментах отзывы опытных меломанов — что хорошо, что плохо?
Сссылки на альбом ⬇️
https://music.yandex.ru/album/26340373
https://open.spotify.com/album/1CMDH6BXJtXEYEZv7esex7
https://music.apple.com/us/album/aftercoding/1693373990
music.yandex.ru
Яндекс Музыка — собираем музыку для вас
Персональные рекомендации, подборки на любой случай, подкасты обо всём на свете и музыкальные новинки — с Яндекс Музыкой всегда есть что послушать!
🔥6👍4❤1
Первый урок нашего легендарного интенсива.
Интересно, что в самых первых потоках его не было.
Но мы с Вадиком заметили, что некоторые ученики не имеют нормальной ментальной модели работы современного интернета. А без нее очень плохо ложатся фреймворки, рельсы и все остальное.
Пришлось как обычно за 18 минут вспомнить всё 🤓️️️️️️
https://youtu.be/PslExWYTD8U?si=cPDeyAcF2bLAJHV7tuj
Интересно, что в самых первых потоках его не было.
Но мы с Вадиком заметили, что некоторые ученики не имеют нормальной ментальной модели работы современного интернета. А без нее очень плохо ложатся фреймворки, рельсы и все остальное.
Пришлось как обычно за 18 минут вспомнить всё 🤓️️️️️️
https://youtu.be/PslExWYTD8U?si=cPDeyAcF2bLAJHV7tuj
YouTube
[Уроки Ruby on Rails] Интернет глазами веб-разработчика 👀
🎧 Подкаст: https://news.1rj.ru/str/horoshy_programmist
♦️ Чат: https://news.1rj.ru/str/rubyrush
© Хороший программист
♦️ Чат: https://news.1rj.ru/str/rubyrush
© Хороший программист
🔥32👍12❤7
Коротышечка 1
Наблюдаю как все сходят с ума по AI.
По принципу обезьяна увидела осмысленный текст — обезьяна наделила "автора" текста осмысленностью.
К сожалению сходят с ума действительно все, то есть и многие состоятельные топ менеджеры и владельцы больших и малых хайтек компаний, и инвесторы и венчурные фонды.
Глупые компании "делают ставку на ИИ" и сокращают штат. Умные знают где их бизнесу ИИ помогает, а где нет и пользуясь случаем отбирают с рынка по дешевке лучших программистов.
Еще они понимают, что скорость написанияговнокода никогда не была важной метрикой. Более того, они знают, что чем меньше кода, тем лучше (строчки кода это не актив, а пассив для бизнеса).
Когда пузырь лопнет, глупые компании останутся с простреленными ногами. Незавидна судьба многих из них.
А умные останутся с лучшими командами и уменьшенной конкуренцией.
Наблюдаю как все сходят с ума по AI.
По принципу обезьяна увидела осмысленный текст — обезьяна наделила "автора" текста осмысленностью.
К сожалению сходят с ума действительно все, то есть и многие состоятельные топ менеджеры и владельцы больших и малых хайтек компаний, и инвесторы и венчурные фонды.
Глупые компании "делают ставку на ИИ" и сокращают штат. Умные знают где их бизнесу ИИ помогает, а где нет и пользуясь случаем отбирают с рынка по дешевке лучших программистов.
Еще они понимают, что скорость написания
Когда пузырь лопнет, глупые компании останутся с простреленными ногами. Незавидна судьба многих из них.
А умные останутся с лучшими командами и уменьшенной конкуренцией.
👍40❤4🔥3😱2
Разминка для ума 🧠
Пример вопроса на собес уровня senior/staff+ по мотивам реальной рабочей проблемы.
Вы тех лид сервиса типа google analytics.
Внезапно обнаружился баг в вашем алгоритме расчета пользовательских сессий (какой юзер сколько времени провел на каком сайте, сколько визитов на сессию, сколько сессий в день и т.п.), вы диагностировали баг, оказалось он возник еще 5 лет назад.
Ошибочные результаты огорчают некоторых самых важных ваших клиетов и они хотят все исправить.
К счастью у вас есть архив событий (с информацией о юзере - user agent, cookie, ip и о визите - timestamp, url, и т.д.) в виде zip файлов на S3.
Каждый файл несколько десятков гигабайт событий за ровно 1 час какого-то дня (час и день в пути файла видны).
Внутри этого файла события не отсортированы. Для простоты положим у вас есть либа для последовательного чтения строк из этого файла без загрузки всего файла в память или копирования целиком из S3.
Предложите схему решения проблемы и ее trade-offs.
1. Без шпаргалки в общих чертах - основные движущиеся части, алгоритмы и что куда идет. Не надо разбираться в фреймворках, можно на пальцах пояснить суть того что требуется от каждой части системы.
2. Полезно потом погуглить и составить более детальную картину (или полностью поменять свой изначальный проект).
💬 Доп вопросы и свои идеи пишите в комментах
Пример вопроса на собес уровня senior/staff+ по мотивам реальной рабочей проблемы.
Вы тех лид сервиса типа google analytics.
Внезапно обнаружился баг в вашем алгоритме расчета пользовательских сессий (какой юзер сколько времени провел на каком сайте, сколько визитов на сессию, сколько сессий в день и т.п.), вы диагностировали баг, оказалось он возник еще 5 лет назад.
Ошибочные результаты огорчают некоторых самых важных ваших клиетов и они хотят все исправить.
К счастью у вас есть архив событий (с информацией о юзере - user agent, cookie, ip и о визите - timestamp, url, и т.д.) в виде zip файлов на S3.
Каждый файл несколько десятков гигабайт событий за ровно 1 час какого-то дня (час и день в пути файла видны).
Внутри этого файла события не отсортированы. Для простоты положим у вас есть либа для последовательного чтения строк из этого файла без загрузки всего файла в память или копирования целиком из S3.
Предложите схему решения проблемы и ее trade-offs.
1. Без шпаргалки в общих чертах - основные движущиеся части, алгоритмы и что куда идет. Не надо разбираться в фреймворках, можно на пальцах пояснить суть того что требуется от каждой части системы.
2. Полезно потом погуглить и составить более детальную картину (или полностью поменять свой изначальный проект).
💬 Доп вопросы и свои идеи пишите в комментах
🔥7😱1
🧐 Коротышечка 2
В реальных проектах и реальных компаниях (от нескольких десятков разработчиков) время и ресурсы потраченные на написание и исправление непосредственно кода это от силы 20-30% времени разработчика (в крупных компаниях даже 10% можно считать удачей).
Все остальное (думание, анализ, коммуникация, принятие решений, проектирование и т.д.) гораздо более важные процессы. И их LLM-ки не умеют by design. В лучшем случае они эти процессы только имитируют.
Значит в самом идеальном раскладе прирост общей скорости серьезного проекта не значительный, а компромиссы в качестве — это новый риск, плохо предсказуемый.
Речь идет о серьезных проектах, когда разрабатывается что-то в какой-то степени новое, не типовое.
Там где нельзя просто скопипастить. Там где нужны живые разработчики. Как правило это растет из уникального набора требований даже в рамках вроде бы типовой задачи. Например интернет магазин на Shopify и Amazon, и то и то магазин. Но есть нюансы :)
Личное наблюдение
с LLM агентами моя продуктивность написания кода на Java с учетом всех переделок, тяни-толкаев и прочего в среднем почти сравнялась с моей же скоростью работы на Typenoscript (которая в свою очередь немного отстает от скорости работы на Ruby)
Мораль
Морали нет, в работе все средства хороши, которые помогают.
А еще Java - говно мамонта 🦣, без которого в 2026м в 99% случаев можно было бы прекрасно обойтись.
Только заядлым джавистам не говорите 🤫 им тоже надо семью кормить.
В реальных проектах и реальных компаниях (от нескольких десятков разработчиков) время и ресурсы потраченные на написание и исправление непосредственно кода это от силы 20-30% времени разработчика (в крупных компаниях даже 10% можно считать удачей).
Все остальное (думание, анализ, коммуникация, принятие решений, проектирование и т.д.) гораздо более важные процессы. И их LLM-ки не умеют by design. В лучшем случае они эти процессы только имитируют.
Значит в самом идеальном раскладе прирост общей скорости серьезного проекта не значительный, а компромиссы в качестве — это новый риск, плохо предсказуемый.
Речь идет о серьезных проектах, когда разрабатывается что-то в какой-то степени новое, не типовое.
Там где нельзя просто скопипастить. Там где нужны живые разработчики. Как правило это растет из уникального набора требований даже в рамках вроде бы типовой задачи. Например интернет магазин на Shopify и Amazon, и то и то магазин. Но есть нюансы :)
Личное наблюдение
с LLM агентами моя продуктивность написания кода на Java с учетом всех переделок, тяни-толкаев и прочего в среднем почти сравнялась с моей же скоростью работы на Typenoscript (которая в свою очередь немного отстает от скорости работы на Ruby)
Мораль
Морали нет, в работе все средства хороши, которые помогают.
А еще Java - говно мамонта 🦣, без которого в 2026м в 99% случаев можно было бы прекрасно обойтись.
Только заядлым джавистам не говорите 🤫 им тоже надо семью кормить.
👍7
🧐 Коротышечка 3
ЛЛМки изменяют работу программистов но не совсем так как шароголовые эффективные мэнеджеры думают.
ЛЛМка не думает как программист, не принимает решения как программист, она не способна заменить программиста, ни опытного ни начинающего.
Также она не способна сама по себе волшебно ускорить или облегчить работу программиста (про это предыдущая коротышечка ☝️).
И волшебным образом превратить рядового менеджера в инженера она тоже не способна.
ЛЛМка как любой новый инструмент это мультипликатор. Если вы достаточно долго общались с ними не только на тему кода вы не могли не заметить, что ЛЛМкам свойственно отражать и усиливать ваши собственные bias, докадки, мысли, предположения.
Так устроен сам дизайн этого алгоритма - он подхватывает затравку и развивает ее, он не обладает собственной агентностью, а ее имитация с помощью рандома слишком примитивна, чтобы всерьез конкурировать с человеческой.
Из этого следует, что та же самая команда инженеров может справляться с более масштабными задачами. Обратный процесс сокращения команды при сохранении текущий масштабов задачи работать так просто не будет.
Во-первых из-за нелинейности этой работы (см. "мифический человеко-месяц" и пр.), во-вторых из-за того, что растущая конкуренция будет скорее навязывать расширение масштабов задач, а не урезание костов.
Может не значит будет. Инструмент-усилитель усиливает и плохие и хорошие решения. Цена ошибки будет возрастать, а растущие масштабы проектов будут создавать отрицательную обратную связь (чем больше выработка программистов - тем сложнее и крупнее проект - чем крупнее и сложнее проект - тем сложнее его двигать с ЛЛМ или без).
И общедоступность инструмента постепенно нивелирует различия между компаниями и командами. И несмотря на может быть новый способ и формат работы приведет всех к общему знаменателю. Не только вы такой умный и научились готовить ваших агентов вам кодить, но и все ваши конкуренты.
А значит все быстро вернется на круги своя — ключевым фактором как и всегда останется качество людей, команды, инженерных решений и т.п. Какими они пользуются инструментами дело второе. Если у всех есть новый молоток, то молоток или умение им пользоваться перестает быть конкурентным преимуществом.
ЛЛМки изменяют работу программистов но не совсем так как шароголовые эффективные мэнеджеры думают.
ЛЛМка не думает как программист, не принимает решения как программист, она не способна заменить программиста, ни опытного ни начинающего.
Также она не способна сама по себе волшебно ускорить или облегчить работу программиста (про это предыдущая коротышечка ☝️).
И волшебным образом превратить рядового менеджера в инженера она тоже не способна.
ЛЛМка как любой новый инструмент это мультипликатор. Если вы достаточно долго общались с ними не только на тему кода вы не могли не заметить, что ЛЛМкам свойственно отражать и усиливать ваши собственные bias, докадки, мысли, предположения.
Так устроен сам дизайн этого алгоритма - он подхватывает затравку и развивает ее, он не обладает собственной агентностью, а ее имитация с помощью рандома слишком примитивна, чтобы всерьез конкурировать с человеческой.
Из этого следует, что та же самая команда инженеров может справляться с более масштабными задачами. Обратный процесс сокращения команды при сохранении текущий масштабов задачи работать так просто не будет.
Во-первых из-за нелинейности этой работы (см. "мифический человеко-месяц" и пр.), во-вторых из-за того, что растущая конкуренция будет скорее навязывать расширение масштабов задач, а не урезание костов.
Может не значит будет. Инструмент-усилитель усиливает и плохие и хорошие решения. Цена ошибки будет возрастать, а растущие масштабы проектов будут создавать отрицательную обратную связь (чем больше выработка программистов - тем сложнее и крупнее проект - чем крупнее и сложнее проект - тем сложнее его двигать с ЛЛМ или без).
И общедоступность инструмента постепенно нивелирует различия между компаниями и командами. И несмотря на может быть новый способ и формат работы приведет всех к общему знаменателю. Не только вы такой умный и научились готовить ваших агентов вам кодить, но и все ваши конкуренты.
А значит все быстро вернется на круги своя — ключевым фактором как и всегда останется качество людей, команды, инженерных решений и т.п. Какими они пользуются инструментами дело второе. Если у всех есть новый молоток, то молоток или умение им пользоваться перестает быть конкурентным преимуществом.
👍15🔥6❤1
😎 Коротышечка 4
Знания можно условно разделить на декларативные и процедурные.
ЛЛМки by design заточены на декларативные и коммуникацию. Процедурные они лишь имитируют.
Работа современного инженера это в первую очередь процедурные знания. И чем сложнее проект, тем в большей степени.
А значит страхи программистов о потере работы вызваны проф деформацией (Ходжа Насреддин тоже искал деньги там где светло, а не там где потерял), нежели объективным анализом.
В первую очередь жопа должна гореть у современные юристов, врачей (тех из них, работа которых сводится к следованию протоколов и выписыванию бумажек), психологов, консультантов и прочих профессий где доминирует коммуникация и декларативные знания.
Кстати, it менеджмент сюда тоже не относится. Управлять людьми и принимать решения это тоже процедурные знания, а иногда вообще магия.
Знания можно условно разделить на декларативные и процедурные.
ЛЛМки by design заточены на декларативные и коммуникацию. Процедурные они лишь имитируют.
Работа современного инженера это в первую очередь процедурные знания. И чем сложнее проект, тем в большей степени.
А значит страхи программистов о потере работы вызваны проф деформацией (Ходжа Насреддин тоже искал деньги там где светло, а не там где потерял), нежели объективным анализом.
В первую очередь жопа должна гореть у современные юристов, врачей (тех из них, работа которых сводится к следованию протоколов и выписыванию бумажек), психологов, консультантов и прочих профессий где доминирует коммуникация и декларативные знания.
Кстати, it менеджмент сюда тоже не относится. Управлять людьми и принимать решения это тоже процедурные знания, а иногда вообще магия.
❤6🔥1