В новой компании в слаке есть канал #insights куда падают feature-реквесты от пользователей и куда кидают результаты опроса-фидбека по поводу причин почему пользователь начал или прекратил пользоваться услугами компании.
Очень нравится быть намного ближе к пользователям и возможность тут же обсудить их идеи с коллегами, а может и забрать что-то в беклок. Сразу начинаешь и по своим небольшим задачам понимать необходимсть / пользу / критичность.
Очень нравится быть намного ближе к пользователям и возможность тут же обсудить их идеи с коллегами, а может и забрать что-то в беклок. Сразу начинаешь и по своим небольшим задачам понимать необходимсть / пользу / критичность.
Value
И наконец, третье отличие рекрутингового процесса на западе и СНГ-рынка - это ориентация на ценности (или value). По сути эта ориентация в процессе интервью позволит не просто пройти интервью, но и получить позитивную, а зачастую и восторженную, обратную связь от менеджеров. В самом примитивном варианте value - количество заработанных для компании денег, т.е. в процессе интервью показывайте сколько денег сэкономлено или заработано в прошлых компаниях и сколько заработаете для этой. Более продвинутый вариант - это почитать на сайте о ценностях компании и излагать опыт и умения с точки зрения ценностей для конкретной компании. Но последним мерилом ценности и полезности все равно являются деньги, поэтому деньги - универсальная метрика, которая помогает компании оценивать профессионалов. Если доказать, что будете приносить компании $30к, то можно легко просить обоснованную зарплату в $10к.
И наконец, третье отличие рекрутингового процесса на западе и СНГ-рынка - это ориентация на ценности (или value). По сути эта ориентация в процессе интервью позволит не просто пройти интервью, но и получить позитивную, а зачастую и восторженную, обратную связь от менеджеров. В самом примитивном варианте value - количество заработанных для компании денег, т.е. в процессе интервью показывайте сколько денег сэкономлено или заработано в прошлых компаниях и сколько заработаете для этой. Более продвинутый вариант - это почитать на сайте о ценностях компании и излагать опыт и умения с точки зрения ценностей для конкретной компании. Но последним мерилом ценности и полезности все равно являются деньги, поэтому деньги - универсальная метрика, которая помогает компании оценивать профессионалов. Если доказать, что будете приносить компании $30к, то можно легко просить обоснованную зарплату в $10к.
Запостил новую статью про то как делать какие-то прикидки насколько быстро или долго может выполняться тот или иной запрос:
https://hackernoon.com/how-to-make-rough-estimates-of-sql-queries
Но конечно все равно такие вещи сводятся к мониманию архитектуры баз данных, а еще глубже - к знанию как работает железо.
https://hackernoon.com/how-to-make-rough-estimates-of-sql-queries
Но конечно все равно такие вещи сводятся к мониманию архитектуры баз данных, а еще глубже - к знанию как работает железо.
Hackernoon
How to Make Rough Estimates of SQL Queries | HackerNoon
To do estimates of SQL queries we need to understand how DB works with queries. Let's find out what exactly the db do with queries.
Недавно дошло, почему у меня в целом редко бывают рутиные задачи в обычной деятельности, хотя почти на каждом рекрутинговом интервью спрашивают "А как ты относишься к рутиным задачам?".
Дело в том, что суть любого программиста - это автоматизировать рутину. И вот буквально каждый мой рабочий момент, где я сталкиваюсь с рутиной или местом, где мне нужно скопипастить сотни, а то и тысячи строк, чтоб добавить функциональность/фичи, я начинаю искать как же это можно автоматизировать или унифицировать и как-то само собой рутиная задача превращается в интересный челлендж "как же сделать правильно то, что не сделали до тебя другие". И почти всегда можно найти ошибки в дизайне / проектировании / идее, которые привели к появлению рутины в том месте, где этого можно было избежать или создать инструмент чтоб твои заказчики/пользователи сами с помощью инструмента решали свои рутиные хотелки.
Помните об этой возможности каждый раз когда получаете рутиную задачу. Рутина - это не для тех, кто не умеет в программирование и архитектуру.
Дело в том, что суть любого программиста - это автоматизировать рутину. И вот буквально каждый мой рабочий момент, где я сталкиваюсь с рутиной или местом, где мне нужно скопипастить сотни, а то и тысячи строк, чтоб добавить функциональность/фичи, я начинаю искать как же это можно автоматизировать или унифицировать и как-то само собой рутиная задача превращается в интересный челлендж "как же сделать правильно то, что не сделали до тебя другие". И почти всегда можно найти ошибки в дизайне / проектировании / идее, которые привели к появлению рутины в том месте, где этого можно было избежать или создать инструмент чтоб твои заказчики/пользователи сами с помощью инструмента решали свои рутиные хотелки.
Помните об этой возможности каждый раз когда получаете рутиную задачу. Рутина - это не для тех, кто не умеет в программирование и архитектуру.
Dependency Inversion для процессов разработки
Представьте, что у вас есть команда, отвечающая за бекофис банка. У вас есть несколько сотен тысяч клиентов, с которыми периодически что-то происходит - у кого-то баг, кому-то что-то не привезли, кто-то решил закрыть аккаунт. Выделена команда, которая реализует бекофисную "очередь запросов" требующую от менеджеров вовлечения - аппрув чего-либо, расширение лимитов, ревью из-за подозрения в мошенничестве или отмывании денег, запрос документов и т.д.
Команда может быть загружена на 100% реализацией каждого вида запроса - нужно делать серверную интеграцию, фронтенд часть, отображение информации и т.д. Но что если посмотреть на эту задачу с другой точки зрения? Можно создать инструмент для создания таких фич для других команд и сервисов, чтоб они сами регистрировали новые типы кейсов, требующих ревью менеджеров, и сообщали в наш сервис коллбек поинт с вариантами возможных действия для решения кейса.
Таким образом, мы можем развернуть зависимость и создать инструмент для других инженерных команд. Другие команды знают детали своих серверов сильно лучше и могут эффективнее и быстрее интегрировать свои бизнес процессы самостоятельно. Нужно лишь дать им несколько эндпоинтов. А бекофисная команда может сфокусироваться на создании и апгрейде самого инструмента и применении своих сил для других, не рутинных, дел.
Короче, такой "продуктовый DI" в конце концов изменяет процессы разработки и повышает эффективность работы и этой команды и других. Не стоит зацикливаться на реализации каждой отдельной фичи, лучше создать инструменты, которые позволят другим командам интегрировать свои сервисы самостоятельно.
Представьте, что у вас есть команда, отвечающая за бекофис банка. У вас есть несколько сотен тысяч клиентов, с которыми периодически что-то происходит - у кого-то баг, кому-то что-то не привезли, кто-то решил закрыть аккаунт. Выделена команда, которая реализует бекофисную "очередь запросов" требующую от менеджеров вовлечения - аппрув чего-либо, расширение лимитов, ревью из-за подозрения в мошенничестве или отмывании денег, запрос документов и т.д.
Команда может быть загружена на 100% реализацией каждого вида запроса - нужно делать серверную интеграцию, фронтенд часть, отображение информации и т.д. Но что если посмотреть на эту задачу с другой точки зрения? Можно создать инструмент для создания таких фич для других команд и сервисов, чтоб они сами регистрировали новые типы кейсов, требующих ревью менеджеров, и сообщали в наш сервис коллбек поинт с вариантами возможных действия для решения кейса.
Таким образом, мы можем развернуть зависимость и создать инструмент для других инженерных команд. Другие команды знают детали своих серверов сильно лучше и могут эффективнее и быстрее интегрировать свои бизнес процессы самостоятельно. Нужно лишь дать им несколько эндпоинтов. А бекофисная команда может сфокусироваться на создании и апгрейде самого инструмента и применении своих сил для других, не рутинных, дел.
Короче, такой "продуктовый DI" в конце концов изменяет процессы разработки и повышает эффективность работы и этой команды и других. Не стоит зацикливаться на реализации каждой отдельной фичи, лучше создать инструменты, которые позволят другим командам интегрировать свои сервисы самостоятельно.
Через пару недель вместе с замечательной @xuyanet планируем провести стрим с обсуждением IT рыночка и в качестве бонуса разберём и покритикуем несколько резюмешек. Если хотите чтоб ваша резюмешка попала в разбор - кидайте мне в личку, самые типовые ошибки обсудим, а самые интересные CVшки разберём на стриме.
На прошлой неделе схлестнулись мы с коллегами по одной теме о том, как же правильно писать компоненты на React, я из-за некоторых болячек пересмотрел подходы к базовому паттерну в проекте и имплементировал кое-что попроще (с моей точки зрения), но коллегам не нравилось это, хотя альтернативы были хуже и экстремальнее (с моей точки зрения). А их только одна небольшая деталь в общем-то не устраивала, но как ее сделать правильно ни я, с 6 месяцами опыта на реакте, ни кто-нибудь из них не втыкали. Вот так и просидели 4 мидло-сениора три часа на коле ничего не решив и только проспорив про подходы.
А на следующий день я вместе с ChatGPT обсудил проблему, рассказал ему чего там у меня в компонентах и он показал на примере как можно упростить мою штуку. Коллеги сказали "Да, это подходит".
А выводов пока что не будет. Вот посоветую только интересную статью как тот самый Т9 доэволюционировал до ChatGPT: https://thebell.io/evolyutsiya-neyrosetey-ot-t9-do-chatgpt-obyasnyaem-na-prostom-russkom-kak-rabotayut-yazykovye-modeli
А на следующий день я вместе с ChatGPT обсудил проблему, рассказал ему чего там у меня в компонентах и он показал на примере как можно упростить мою штуку. Коллеги сказали "Да, это подходит".
А выводов пока что не будет. Вот посоветую только интересную статью как тот самый Т9 доэволюционировал до ChatGPT: https://thebell.io/evolyutsiya-neyrosetey-ot-t9-do-chatgpt-obyasnyaem-na-prostom-russkom-kak-rabotayut-yazykovye-modeli
The Bell
Эволюция нейросетей от Т9 до ChatGPT. Объясняем на простом русском, как работают языковые модели
НАСТОЯЩИЙ МАТЕРИАЛ (ИНФОРМАЦИЯ) ПРОИЗВЕДЕН И РАСПР
Начал все больше использовать ChatGPT. Всякие рутиные задачи он конечно классно снимает, например тут для генерации таблицы для статьи.
Интересно ли вам читать для кейсы использования ChatGPT?
Anonymous Poll
77%
да
23%
нет, надоело уже из каждого утюга
Fill Factor для РСУБД
Fill Factor — это параметр, определяющий, какой процент каждого блока данных базы данных будет использоваться для операций вставки (INSERT). Оставшееся пространство будет использоваться для операций обновления (UPDATE). Это означает, что если в том же блоке имеется свободное пространство, строка будет перезаписана в тот же блок, что в свою очередь не потребует пересчета индекса.
Для некоторых паттернов нагрузки на таблицу, например, если ваша таблица часто получает запросы по определенному индексу (не первичному) и возвращает более одной строки, а также имеет много запросов на обновление отдельных записей, установка Fill Factor ниже 100% позволит хранить часто запрашиваемые данные вместе, избегая фрагментации. В результате, это приведет к уменьшению случайных чтений (Random Reads) с диска и увеличению процента последовательного чтения.
Применяя Fill Factor и команду CLUSTER в одном из моих недавних экспериментов на продакшен-базе на сервере Google Cloud SQL, мне удалось ускорить выполнение критических запросов в ~1000 раз для наиболее сложных сценариев. Конечно, все зависит от характера нагрузки на таблицы, но у меня сложилось ощущение что это может вылечить многие сложные случаи.
Fill Factor — это параметр, определяющий, какой процент каждого блока данных базы данных будет использоваться для операций вставки (INSERT). Оставшееся пространство будет использоваться для операций обновления (UPDATE). Это означает, что если в том же блоке имеется свободное пространство, строка будет перезаписана в тот же блок, что в свою очередь не потребует пересчета индекса.
Для некоторых паттернов нагрузки на таблицу, например, если ваша таблица часто получает запросы по определенному индексу (не первичному) и возвращает более одной строки, а также имеет много запросов на обновление отдельных записей, установка Fill Factor ниже 100% позволит хранить часто запрашиваемые данные вместе, избегая фрагментации. В результате, это приведет к уменьшению случайных чтений (Random Reads) с диска и увеличению процента последовательного чтения.
Применяя Fill Factor и команду CLUSTER в одном из моих недавних экспериментов на продакшен-базе на сервере Google Cloud SQL, мне удалось ускорить выполнение критических запросов в ~1000 раз для наиболее сложных сценариев. Конечно, все зависит от характера нагрузки на таблицы, но у меня сложилось ощущение что это может вылечить многие сложные случаи.
Снова про ChatGPT
В последнее время так получилось что я работаю с фронтендом и много пишу на React/TypeScript. До начачала использования ChatGPT я просто полагался на свой большой опыт в бекенде, некоторые интуитивные штуки и гуглеж. Но сейчас ИИ стал прям постоянным бадди который четко отвечает на вопросы, помогает писать некоторые куски кода, скидывает мне примеры, описывает плюсы и минусы разных подходов. По моим ощущениям продуктивность изучения технологии, эффективность реально ощутимо выросли. Изначально было и про выросшее качество кода но тут видел в тви ссылку на исследование что ИИ приводит к понижению качества кода, так что тут еще посмотрим :) субъективно - растет, объективно - не знаю.
Это вот то самое пресловутое "рост производительности труда". Как писали умные люди - к безработице это не приведет, но приведет к необходимости переучиваться, еще большему количеству новых рабочих мест, и росту среднего благосостояния.
Наскринил рандомных мест из диалога для примера (появятся в комментариях к посту). Это по сути я в новой для себя технологии занимаюсь архитектурными делами + одновременно изучаю эту самую технологию и докапываюсь до всяких непонятных мне деталей. А этих непонятных деталей в каждой новой технологии всегда полно.
Так что если вам не хватает ментора - за 20 долларов в месяц его легко сейчас найти :)
Скоро еще сделаю пост с различными хаками которые помогают работать с ИИ эффективнее.
В последнее время так получилось что я работаю с фронтендом и много пишу на React/TypeScript. До начачала использования ChatGPT я просто полагался на свой большой опыт в бекенде, некоторые интуитивные штуки и гуглеж. Но сейчас ИИ стал прям постоянным бадди который четко отвечает на вопросы, помогает писать некоторые куски кода, скидывает мне примеры, описывает плюсы и минусы разных подходов. По моим ощущениям продуктивность изучения технологии, эффективность реально ощутимо выросли. Изначально было и про выросшее качество кода но тут видел в тви ссылку на исследование что ИИ приводит к понижению качества кода, так что тут еще посмотрим :) субъективно - растет, объективно - не знаю.
Это вот то самое пресловутое "рост производительности труда". Как писали умные люди - к безработице это не приведет, но приведет к необходимости переучиваться, еще большему количеству новых рабочих мест, и росту среднего благосостояния.
Наскринил рандомных мест из диалога для примера (появятся в комментариях к посту). Это по сути я в новой для себя технологии занимаюсь архитектурными делами + одновременно изучаю эту самую технологию и докапываюсь до всяких непонятных мне деталей. А этих непонятных деталей в каждой новой технологии всегда полно.
Так что если вам не хватает ментора - за 20 долларов в месяц его легко сейчас найти :)
Скоро еще сделаю пост с различными хаками которые помогают работать с ИИ эффективнее.
Сидел сейчас рефакторил очередной сложный кусок и интересная мысль пришла в голову:
Написание чистого кода требует чистой головы. А чтоб ваш разум был чист в процессе работы - он не должен быть забит знаниями о том, как будут работать те или иные вызовы на 4 уровнях абстракции ниже или выше. Чем большим количеством текущего контекста забита голова, тем меньше места остается на непосредственную текущую задачу.
Я люблю писать красивый и чистый код, и наверное поэтому я постоянно пытаюсь все упростить до максимального состояния :) и именно доведение каждого слоя приложения до самостоятельного независимого состояния в итоге и приводит к тому что очень легко становится с ним разбираться и не нужно "знание" о том как работает другой уровень, чтоб внести изменения на текущем.
Написание чистого кода требует чистой головы. А чтоб ваш разум был чист в процессе работы - он не должен быть забит знаниями о том, как будут работать те или иные вызовы на 4 уровнях абстракции ниже или выше. Чем большим количеством текущего контекста забита голова, тем меньше места остается на непосредственную текущую задачу.
Я люблю писать красивый и чистый код, и наверное поэтому я постоянно пытаюсь все упростить до максимального состояния :) и именно доведение каждого слоя приложения до самостоятельного независимого состояния в итоге и приводит к тому что очень легко становится с ним разбираться и не нужно "знание" о том как работает другой уровень, чтоб внести изменения на текущем.
Завтра залейтайте к нам на стрим! :) мы немного изменили планируемую тему с рекрутинговой на ИИшную но надеюсь это будет более интересно :)
Forwarded from ROSLOVETS: Product, Startup, IT
Как использовать GPT-4
😐 Создание контента: 📝 От создания блогов до составления привлекательных подписей в социальных сетях, GPT-4 кардинально меняет подход к созданию контента.
😐 Персонализированное образование: 🎓 ИИ-репетиторы на базе GPT-4 могут предоставлять индивидуализированные пути обучения, определяя сильные и слабые стороны каждого ученика. Это позволяет предлагать настроенные уроки, упражнения и обратную связь, чтобы помочь студентам справиться с их уникальными трудностями и преуспеть в учебе.
😂 Перевод языков. Ну тут все понятно.
🎮Игровая индустрия: GPT-4 может помочь создать погружающиеся и динамичные сюжеты, генерируя диалоги и взаимодействия персонажей, которые кажутся более реалистичными и интересными.
🔥🔥🔥🔥Ну а мы тем временем готовим эфир совместно с Андреем Сундуковым, адептом чистого кода, Senior-разработчиком американской компании Step Mobile про то, как мы используем GPT-4. Андрей использует его как программист каждый день, я как не программист))
Поговорим про:
- как использовать GPT-4 эффективно
- какие ежедневные задачи может закрыть ИИ
- мои кейсы и кейсы Андрея, как мы их использовали и что из этого вышло
🚀🤖 Раскрываем сценарии использования в прямом эфире завтра 1 апреля в 11.00 по Москве по ссылке! 🤖🚀
PS: вступление и вот этот реплаенный пост сгенерированы GPT)))
🎮Игровая индустрия: GPT-4 может помочь создать погружающиеся и динамичные сюжеты, генерируя диалоги и взаимодействия персонажей, которые кажутся более реалистичными и интересными.
🔥🔥🔥🔥Ну а мы тем временем готовим эфир совместно с Андреем Сундуковым, адептом чистого кода, Senior-разработчиком американской компании Step Mobile про то, как мы используем GPT-4. Андрей использует его как программист каждый день, я как не программист))
Поговорим про:
- как использовать GPT-4 эффективно
- какие ежедневные задачи может закрыть ИИ
- мои кейсы и кейсы Андрея, как мы их использовали и что из этого вышло
🚀🤖 Раскрываем сценарии использования в прямом эфире завтра 1 апреля в 11.00 по Москве по ссылке! 🤖🚀
PS: вступление и вот этот реплаенный пост сгенерированы GPT)))
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Заменит ли ChatGPT программистов? Обсуждение использования нейросети с Senior разработчиком
🔥 Запишись на курсы для инженеров, подними свою квалификацию на новый уровень: https://inzhenerka.tech/?utm_source=youtube_marybrenly
Канал Андрея в телеграмме https://t.me/developers_mind
Кто не слышал про ChatGPT? Какие возможности есть у нейросети,…
Канал Андрея в телеграмме https://t.me/developers_mind
Кто не слышал про ChatGPT? Какие возможности есть у нейросети,…
по мотивам использования ChatGPT написал в итоге статью с кучей рабочих скриншотов, читать тут:
https://ru.hexlet.io/blog/posts/chatgpt-kak-instrument-programmista
https://ru.hexlet.io/blog/posts/chatgpt-kak-instrument-programmista
Хекслет
8 полезных функций ChatGPT для программиста
Рассказываем, как разработчик с помощью ChatGPT может упростить себе работу и стоит ли вообще доверять нейросети писать код.
нашу прожарку заходов от рекрутеров полугодовой давности выложили на хабр:
https://habr.com/ru/articles/749992/
а вас что бесит в письмах от рекрутеров (кроме их отсутствия если вы только вкатываетесь 🥲) ?
https://habr.com/ru/articles/749992/
а вас что бесит в письмах от рекрутеров (кроме их отсутствия если вы только вкатываетесь 🥲) ?
Хабр
Зачем они пишут, что я крутой: разработчики комментируют письма рекрутеров
Мы попросили разработчиков прокомментировать реальные письма, которые прислали нам рекрутеры. Фил Ранжин и Андрей Сундуков в прямом эфире читали и оценивали сообщения, а мы сделали из этого статью —...
Заметил, что в добротном микросервисном проекте уже не такую большую роль играют правильные слои controller/service/db, потому что когда в принципе в сервисе 2-3 сущности (а в некоторых сервисах - одна), то и "толстый контроллер" в этом случае сложно получить, ну потому что размеры не позволят. Конечно, не привызваю всю логику писать в один слой, хотя бы даже потому что тогда тестирование будет затруднено, но удивляюсь насколько же высокоуровневая архитектура влияет на низкоуровневую организацию. И избавляет от старых болячек.
Еще одно следствие правильной микросервисной архитектуры - отсутствие высоких нагрузок в пересчете на сервис. В проекте, в котором работаю, зарегистрированны миллионы пользователей, сотни тысяч из которых совершают транзакции ежедневно. До такого уровня развития доживают считанные доли процентов проектов. И даже в такой ситуации в проекте нет никакого хайлоада или бигдаты. А из используемых технологий - Java, Postgres да Google Cloud. Да, даже кэш системы реализованы на основе СУБД. Очереди и асинхронная обработка - тоже базируются на базе данных и запускаются внутри сервисов, как Java классы из подключаемых зависимостей со своими конфигами.
И запаса по производительности еще кажется два порядка.
В итоге - не нужны дополнительные технологии, ни редисы и мемкеши, ни кафки и альтернативы с кучей обвязок типа дебезиума. А значит не нужны и отдельные инженеры или девопсы, которые умеют обслуживать и знают особенности дополнительных технологий. А все что нужно - люди, которые умеют работать с джавой и с постгресом. Более того, так как все технологии "in-house" - можно имплементировать самим дополнительные фичи если понадобится. По стабильности - меньше единых точек отказа, так как обычно всю инфрастуктуру обслуживает один кластер кафки и один кластер мемкеша. И по стоимости инфраструктуры - тоже выигрыш. На самом деле впервые столкнулся с таким подходом, но чем больше об этом думаю, тем больше вижу насколько много здесь очевидных плюсов.
И запаса по производительности еще кажется два порядка.
В итоге - не нужны дополнительные технологии, ни редисы и мемкеши, ни кафки и альтернативы с кучей обвязок типа дебезиума. А значит не нужны и отдельные инженеры или девопсы, которые умеют обслуживать и знают особенности дополнительных технологий. А все что нужно - люди, которые умеют работать с джавой и с постгресом. Более того, так как все технологии "in-house" - можно имплементировать самим дополнительные фичи если понадобится. По стабильности - меньше единых точек отказа, так как обычно всю инфрастуктуру обслуживает один кластер кафки и один кластер мемкеша. И по стоимости инфраструктуры - тоже выигрыш. На самом деле впервые столкнулся с таким подходом, но чем больше об этом думаю, тем больше вижу насколько много здесь очевидных плюсов.