сказки стареньких дряхленьких айтишников, которым не платят теперь огромные денежки. AI будущее и за несколько часов создаст MVP которое уже можно обкатать в бою
Как бесят эти "эффективные менеджеры", идите на завод, а не людей изучайте, вы кто? Хозяева чтоли? возомнили себя пастухами, таким бы ручонки пооткручивать
Пусть население убывает, в чём проблема то? ну спад рождаемости, значит жизнь продолжительнее. Или нужно по 10 детей и смертность в 35-40 лет? Уже по горло эта демагогия с рождаемостью.
??? непонятный комментарий? не ясно претензия или нет, вы молодец, хороший работник и исполнитель, работать на компанию, быть специалистом отлично
Я развиваю свои проекты и идеи которые копились за всю жизнь, пока я трудился на дядю, теперь пришло моё время + AI в помощь, отличные руки для разработки и проверки прототипов и MVP
Понимаю вас, возрастным программистам сейчас скорее всего трудно, молодежь на пятки наступает, а тут еще и AI
Забавно, что 20 лет издатели оптимизировали всё под Google, а теперь выясняется, что зависимость от одного источника трафика — плохая бизнес-модель. Проблема, кажется, не только в AI, а в том, что слишком много компаний построили бизнес вокруг чужой платформы.
Всегда интересно смотреть такие статьи через пару лет использования. Но почти у всех замечаю одну закономерность: чем больше появляется собственных правил, шаблонов и соглашений, тем выше порог входа для самого себя через год. Иногда проще написать обычную markdown-заметку, чем решить, это note, zettel или уже index.
Всегда немного настораживает hot reload в Python-проектах. Пока проект маленький — магия. Потом начинаются singleton'ы, фоновые задачи, импорт побочными эффектами и выясняется, что полный рестарт был не таким уж плохим решением.
Понравилось, что библиотека не пытается заменить aiogram, а именно дополняет его. Часто подобные проекты начинают постепенно "затягивать" всё в себя и через год превращаются в отдельный фреймворк с несовместимым API. Если получится удержать именно формат DX-плагина — это, на мой взгляд, самый удачный путь.
Самая большая опасность таких библиотек — желание собрать вообще всё. Сегодня hot reload и пагинация, завтра ORM, DI, планировщик задач и свой конфиг. Интересно, где автор сам для себя проводит границу, чтобы Raito не превратился в очередной "framework over framework".
Да, я с ai создаю проекты на Rust, Python, Swift, Kotlin, Goddot, оболочки и билды linux (готовлю сборку пакетов Platinum OS над armbian загрузчик бортов), языки которые я знаю хорошо php, go, c/c++ Arduino esp32 сбокри из ESP-IDF) проекты и языки пишу для себя,
Идей у меня ещё миллион, а также скоро будут новые интересные стать и по роботов и другие проекты
Хорошая статья. Я бы только добавил ещё одно правило:
Чем меньше UI используется для подготовки состояния теста, тем стабильнее становится весь набор.
Если можно создать сущность через API за 100 мс вместо 20 кликов по интерфейсу — почти всегда стоит так и сделать. UI должен проверять UI, а не использоваться как средство подготовки данных.
На мой взгляд, ключевая мысль статьи даже не про Natural vs Surrogate Key, а про то, что Primary Key — это контракт системы, а не просто способ обеспечить уникальность строки.
Пока приложение живёт внутри одной БД, кажется, что изменить PK — не такая уж проблема. Но как только появляются внешние сервисы, кэш, Kafka, CDC, S3, аналитика или просто ссылки в других БД — PK становится частью публичного API.
Именно поэтому стоимость ошибки здесь растёт не линейно, а практически экспоненциально.
Эти опарыши из гугл плэй заблочили мою учетку и не вернули 25$ толком не объяснив причину, поэтому думаю буду публиковать через китайские сторе и русторе
Позже попробую еще зарегать аккаунт в гугле, но 25$ жалко
Справедливое замечание — без TURN действительно не обойтись, но ситуация не такая мрачная, как кажется. TURN включается только когда P2P-соединение не пробивается (симметричный NAT, CGNAT, корпоративные сети), и в среднем задействуется у 10–30 % звонков.
сказки стареньких дряхленьких айтишников, которым не платят теперь огромные денежки. AI будущее и за несколько часов создаст MVP которое уже можно обкатать в бою
Все эти грейды, чушь собачья, выдуманные отсталыми менеджерами и hr, которые сейчас становятся наиболее невостребованными
Как бесят эти "эффективные менеджеры", идите на завод, а не людей изучайте, вы кто? Хозяева чтоли? возомнили себя пастухами, таким бы ручонки пооткручивать
Пусть население убывает, в чём проблема то? ну спад рождаемости, значит жизнь продолжительнее. Или нужно по 10 детей и смертность в 35-40 лет? Уже по горло эта демагогия с рождаемостью.
??? непонятный комментарий? не ясно претензия или нет, вы молодец, хороший работник и исполнитель, работать на компанию, быть специалистом отлично
Я развиваю свои проекты и идеи которые копились за всю жизнь, пока я трудился на дядю, теперь пришло моё время + AI в помощь, отличные руки для разработки и проверки прототипов и MVP
Понимаю вас, возрастным программистам сейчас скорее всего трудно, молодежь на пятки наступает, а тут еще и AI
Забавно, что 20 лет издатели оптимизировали всё под Google, а теперь выясняется, что зависимость от одного источника трафика — плохая бизнес-модель. Проблема, кажется, не только в AI, а в том, что слишком много компаний построили бизнес вокруг чужой платформы.
Всегда интересно смотреть такие статьи через пару лет использования. Но почти у всех замечаю одну закономерность: чем больше появляется собственных правил, шаблонов и соглашений, тем выше порог входа для самого себя через год. Иногда проще написать обычную markdown-заметку, чем решить, это note, zettel или уже index.
Всегда немного настораживает hot reload в Python-проектах. Пока проект маленький — магия. Потом начинаются singleton'ы, фоновые задачи, импорт побочными эффектами и выясняется, что полный рестарт был не таким уж плохим решением.
Понравилось, что библиотека не пытается заменить aiogram, а именно дополняет его. Часто подобные проекты начинают постепенно "затягивать" всё в себя и через год превращаются в отдельный фреймворк с несовместимым API. Если получится удержать именно формат DX-плагина — это, на мой взгляд, самый удачный путь.
Самая большая опасность таких библиотек — желание собрать вообще всё. Сегодня hot reload и пагинация, завтра ORM, DI, планировщик задач и свой конфиг. Интересно, где автор сам для себя проводит границу, чтобы Raito не превратился в очередной "framework over framework".
Да, я с ai создаю проекты на Rust, Python, Swift, Kotlin, Goddot, оболочки и билды linux (готовлю сборку пакетов Platinum OS над armbian загрузчик бортов), языки которые я знаю хорошо php, go, c/c++ Arduino esp32 сбокри из ESP-IDF) проекты и языки пишу для себя,
Идей у меня ещё миллион, а также скоро будут новые интересные стать и по роботов и другие проекты
https://github.com/digkill
Да, так и есть. Особенно по моим внешним дискам)
Молодец, тестируй ios на докере запускай на эмуляторе
Спасибо за тёплые слова!
Хорошая статья. Я бы только добавил ещё одно правило:
Чем меньше UI используется для подготовки состояния теста, тем стабильнее становится весь набор.
Если можно создать сущность через API за 100 мс вместо 20 кликов по интерфейсу — почти всегда стоит так и сделать. UI должен проверять UI, а не использоваться как средство подготовки данных.
На мой взгляд, ключевая мысль статьи даже не про Natural vs Surrogate Key, а про то, что Primary Key — это контракт системы, а не просто способ обеспечить уникальность строки.
Пока приложение живёт внутри одной БД, кажется, что изменить PK — не такая уж проблема. Но как только появляются внешние сервисы, кэш, Kafka, CDC, S3, аналитика или просто ссылки в других БД — PK становится частью публичного API.
Именно поэтому стоимость ошибки здесь растёт не линейно, а практически экспоненциально.
Эти опарыши из гугл плэй заблочили мою учетку и не вернули 25$
толком не объяснив причину, поэтому думаю буду публиковать через китайские сторе и русторе
Позже попробую еще зарегать аккаунт в гугле, но 25$ жалко
Спасибо, в develop ветке буду дорабатывать
Спасибо, в develop ветке буду дорабатывать
Справедливое замечание — без TURN действительно не обойтись, но ситуация не такая мрачная, как кажется. TURN включается только когда P2P-соединение не пробивается (симметричный NAT, CGNAT, корпоративные сети), и в среднем задействуется у 10–30 % звонков.
https://habr.com/ru/articles/907934/
Вот я писал пост о секьюрном мессенджере на Rust