Лучшее лекарство от всех болезней в коде - это нагрузочное тестирование. А реализацию любого алгоритма можно у чат джпт спросить. Отстали от жизни интервьюеры, которые требуют знания, которые в элементарном доступе и пригождаются только тогда, когда начинается пресловутая оптимизация после нагрузки. Я за свою жизнь ещё не разу не видел, чтобы написанные опен сорс решения не болели болячками. Хоть многие и считают что все эти вещи делаются супер умными людьми, но прикол в том что именно людьми.
Вывод какой - берёшь готовую деталь - оттестируй её нагрузкой по своим кейсам, точно также как свой продукт. Просвятишься однозначно.
И как знания алгоритмов помогут тебе в оптимизации СУБД например, которая тормозит на твоих кейсах. Да никак. Ишью повесишь разрабам и будешь ждать фикса.
Не существует человека который с первого раза написал супер оптимальный чудо код. Да и с 10 го раза редко получается. И то что код оптимален может сказать именно интеграционный нагрузочный тест, который долбит по апишке или gRPC. А то иногда ведь пишут бенчмарки просто на функции ну и типо гляньте - она быстрая.
Во, тоже так подумал. Сам часто работал раньше с датчиками и микроконтроллерами. Они реально иногда чушь несут, просто из-за того что могут быть дикие электромагнитные помехи и зашумленный радиочастотный фон. Вот и появляются всякие костыли в логике обработки, которые не костыли а целая методика.
Не так давно я прикручивал датчик открытия двери в homeassistant. Так вот эта дурнина шлёт несколько событий подряд открыто, закрыто, открыто на одно физическое открытие. Там для этого придумали замечательные вещи "Ваше устройство открыто сколько по времени?". То есть фактически игнорировать события в последовательности на временной шкале. Так как они могут быть ложными.
Итого любой физический датчик рано или поздно начинает врать, причём всегда с определенной частотой. Именно поэтому стоит посмотреть в сторону камер и компьютерного зрения. Настроить её на подозрительные вещи и она будет делать их фото самостоятельно.
Ну а если жить на датчиках - просто надо принять что они иногда чушь несут просто потому что это микрухи и где то рядом с ними в момент чуши электромагнитная волна пролетела, которая может даже возникать из за неочевидных вещей - трение ножниц о металл. Ну а если датчики дешёвые - и производители no-name. Не исключено что там просто баги в коде самих датчиков.
Лично для меня уход на homeassistant вызван не столько тем, что там всё без интернета работает и вайфай и зигби и что угодно и как угодно. А тем, что там здраво продумана система ценариев. И они все локально работают. Главная Килер фича - это отслеживать в рилтайме состояния устройств и на этом строить сценарии, так ещё и с опцией запомнить как было до того, как сценарий начал работать.
А то что без интернета сможет Алиса ну это второстепенно. Особенно для людей которые на удалёнке работают, у них интернет есть всегда. А когда его нет, эти 10 минут ненастья спокойно проходят за чашкой чая. Первостепенно на мой взгляд - любые сценарии в локальной памяти хранить, а в облако дублировать. Особенно те, где голос не нужен вообще. И возможность хранить атрибуты - это просто пушка была бы.
А из супер фишек - надо Гугл корел забрать и управлять жестами через камеру. Всё руки не дойдут сделать. Вот в Алису встройте камеру и пусть жестами можно будет локально что угодно делать.
Доброго дня. Спасибо за статью. Суть ясна - копируем всё что есть из СУБД к себе в RAM, вместо Redis-а, а с помощью watch - у нас происходит обновление/инвалидация нашего внутреннего кэша.
Но обмануть закон сохранения энергии ещё никому не удавалось. Когда данных много, ну например 100 Гб. Они явно уже в сервис не влезут. Появляется необходимость шардинга, но уже Ваших сервисов, например - по месяцам. Но один в поле не воин, одна шарда - это не отказоустойчиво. Надо 3 хотябы. Ну и вот Вы создали кластер редиса. Который работает быстрее редиса, потому что у редиса видимо нет API - чтобы данные напрямую из него тащить и watch интегрировать в него. Появился чудо-сложный балансировщик трафика, которому надо ещё правильно клиентские запросы балансировать по Вашим шардам-репликам. А ещё Вы сталкиваетесь с людскими хотелками - хотим отчёт за год, а у Вас данные по разным шардам...
То есть, возникнет тот момент, когда Вы ощутите, что закон сохранения энергии начинает Вас догонять. Что все те проблемы, от которых Вы попытались убежать - настигли Вас, но в других местах. Отсюда возникает потребность сформировать общие положения и рекомендации на каких объёмах данных Вас ещё не догнало то, от чего Вы убежали. А когда начнёт догонять - Вы получите ценобразовательный Redis, подключенный через Watch к MongoDB. Со всеми проблемами редиса, будьте готовы к такому.
А ещё было бы не плохо понять сложность самих запросов на чтение. Ну это простые выборки какие-то, или множественные соединения с кучей агрегаций и вычислительных слоёв. Есть ли там Иерархические группировки данных, например. То есть что Вы имели ввиду под чтением, какова его сложность.
Итого, в рекомендации к применению может войти: объём данных, сложность исполняемых запросов на чтение (сортировки, иерархия, агрегация, много-джоинов), сложность структуры хранимых данных в самом кэше, сложность пост-обработки данных перед помещением в свой кэш, что-то ещё.
Подскажите, а на какой СУБД можно прям вместо create table - create cube сделать? Прям заинтересовало.
И кажется я знаю почему кубы перестали быть популярными - потому что в обычных СУБД - где есть JOIN и нет CREATE cube - надо было делать запросы на 1000+ строк SQL чтобы такую модель данных покрутить. А народ обленился.
Сам я не так давно сделал инструмент для создания и поддержки таких запросов, которые как раз и основаны на OLAP методологии.
К сожалению мне не дают в open source его выложить, но видео-обзором никто делиться на запрещал.
Нужно исходить из более реальных примеров. А то в этом - покупка товар данные можно из бэкапов восстановить. А иначе как ты в таком простом кейсе умудрился их потерять, и где тут тебе транзакции помогли.
Зайдём с другого угла. Ну был у тебя монолит, разделил его на сервисы. Один сервис - одна бд. Вроде всё сделал правильно, НО именно путь один сервис - одна бд и привёл тебя к необходимости распределения транзакций. Ты в итоге не туда свернул и решил проблему У. Вместо решения проблемы Х. То есть тебя что-то не устраивало в монолите и ты его поменял, словил проблему ХУ.
Ты просто вспомни свой монолит. Наверное там не нужны были всякие саги... Но почему не нужны были? Вот и ключ. А сделай ты одну бд и пусть все сервисы пишут туда и смотрят туда. И сделай кое что весьма полезное одна сущность - один запрос на запись в бд. Если запрос не удался, то и ладно ты ничего не потерял. А если удался - то всё круто, все данные за один запрос зашли куда надо.
В статьях почему и как вы пошли в распределение транзакций не хватает контекста а накой оно вообще Вам надо. Я вот представил что ты монолит пилил по рекламной брошуре, которую называют бест перктис... Но почему это бест и когда они там обычно тоже не пишут. Ну сделайте один сервис - одна бд, сагу там добавьте и вот... А нафига - не говорят, а мы и не спрашиваем.
Коротко о транзакциях и их распределении - берёшь и выкидываешь их нафиг. На секунду помешаешь в голову мысль, что человечество их ещё не изобрело. Стало страшно? Поборол страх, поместил эту мысль ещё раз, теперь на минуту. Подумал хм, а может быть собрать всё как-то иначе. И придумал какую-нибудь квантовую асинхронную мульти-супер позицию состояния данных. Родил что-то новое в общем.
Ну а если без фантастики. Ну неужели нет способа без транзакций в реляционках системы строить. На каких нибудь хитрых кэшах или crdt. И как нибудь там шмяк бух и вау чего случилось.
Ну... Да. Но... сам знаешь что тут сложнее. Благо на нас монтаж видео инструкций для пользователей не вешают, как между прочим, типо ну не сложно же, тыж программист...
Нужно просто поделить новичков по их уровню интеллекта и способу самопознания.
Объективно тем, кто не любит копать глубоко, а любит быстро достигать финиша - не надо начинать с java. Им наверное вообще не надо идти в разработчики. Пока они не поймут, что это не та сфера, где можно не напрягаться и достигать высот. Им лучше в блогеры податься. Их единственный путь в разработку через тестировщика, а там python подойдёт.
Джава могут выбрать те, кто любит решать головоломки. И например, играя в компьютерные игры не просто бежит убивать босса, а сначала делает прокачку героя, готовит снарягу, выбирает место для атаки, тщательно продумывая каждое нажатие на геймпад. Да и вообще его цель не босса убить, а исследовать игровой мир и открывать сундуки. Вообще джава, она для тех кто любит и умеет заморачиваться и кайфует от долгого достижения результата.
Для математиков - Rust какой-нибудь выбрать сразу. И книжки по алгоритмам. А чё мелочиться то. Человек башковитый. И лучше снизу вверх компьютер познавать. А там и java и python и go ждут тебя и c#.
Гумманитарий - изучи как с чат gpt на python + js лепить чего-нибудь. Если не смог даже это - иди в блогеры. Сними Ютуб канал, как ты пытался войти в айти.
Для тех кто пошёл в программисты через ВУЗ - там и так напичкают всем подряд. Главные знания они будут не про код и языки. А про информационное пространство. Что есть компьютер, сети, безопасность. С помощью любого языка изучайте алгоритмы. Учитесь учиться - вот что важно. И тогда после ВУЗ-а вы не услышите "Забудь всё что знаешь". Если голова варит - возьмитесь за Go или Rust. Не очень варит - python, js, c#. Не нравиться термин варит голова - java, и создайте свой термин.
И самое главное - учение свет, а не учение - неучение. Дожимать задачу до конца надо всегда. Если не обладаете таким навыком - не надо выбирать язык какой учить. Надо научить себя учиться и добиваться результатов. Качаем супер сложную компьютерную игру и проходим на супер сложности пару уровней. Делаем забег на 5 км просто так. Понравилась девушка/парень - добиваемся до тех пор пока на ракете не пошлют на Марс. Когда все барьеры разрушены в голове - вы готовы начать выбирать язык.
Опять low code. И через 10 лет программисты вымерли не потому что их chat gpt заменил, а потому что какой-нибудь бизнес аналитик познал крутой Лоу код. И лоулиндзянями повыкидывал всех разрабов.
Вот зачем бизнесу давать инструменты такие, где надо мало кодить. Ну а потом появиться же лоукод платформа, где лоукодом её же можно и переделывать) Ну и всё. Извини чат джпт, не сегодня... Мы ещё раньше заберём работу у будущих айтишников.
Рассадники зла эти лоукод платформы.
Год 2025 мы сделали супер релиз. Но мы больше не нужны. Так как доли акций у нас были мизерные, продукт просто отобрали и мы теперь пошли в общепит обратно.
Ну уберут из питона GIL, дадут всем дженерики, через пару лет за счёт этого создадут первый официальный компилятор питона в бинарник. И что получиться, голанг какой-нибудь...
Китайские мультитулы это конечно весело. Но когда нужно копьё, как запихать в карман копьё? Какого зверя идём бить - такой и инструмент берём.
Интересно кто-то думал, когда шёл в it, что вот сейчас курс по питону от Яндекса пройду вот и буду горы денег зашибать.
Упёрлись в gil - значит доросли до копья. И пора осваивать копьё.
С языками ещё и инфастуктурщина всякая липнет. Докеры, куберы, гитлабы, дженкинс. Чат жпт вот появился. Улучшайзеры, генераторы, идеешки, плагины, базы данных, ресурсы, мощности, хостинг...
Но почему то вот язык у большинства людей в голове он как то оторван вот от остального... Мол на одном языке продукт создам на 1000 000 пользователей... Ща вот освою питон и как жахну тикток+.
Изучил питон, освоил Джил. Иди го ковыряй. Упёрся в GC - иди rust ковыряй. Там упёрся в сложно понять куда - иди в ассемблер.
Чем раньше это будет понято, тем больше миру пользы. И обсуждений зачем создали Джил и для кого - станет меньше. Особенно советов питонистам, как его обходить. На первой строке такого совета должно быть "Открываем книжку по голангу".
Интересно кто-то занимается иммитационным моделированием бизнес процессов, ну или дискретным. Чтобы были схемы процесса, где кнопку тык, и софт сказал что процесс в принципе рабочий. Ну или запустилась схема и сразу видно что блоке А всё в очередях пухнет при количестве обращений Н.
Как будто чего-то всё время не хватает при проектировании больших систем. Единого инструмента что-ли, где бы и контракты были, и границы сервисов, и bpmn модели и UML схемы, и форматы данных, и смоделированные процессы.
Миру больше не нужны новые языки программирования которые, работают на битах и байтах. Мир уже прозревает потихоньку и создаёт кубиты. Но видимо не в этой статье
А в завершение статьи я предложу альтернативный и менее рискованный подход
Ну и где подход то? Начать с монолита? Америка открыта снова...
А можно начать сразу с архитектуры и определения бизнес модели, всё как следует описать и смоделировать большинство основных бизнес-процессов. Не писать код вообще, месяц другой. И ничто уже не помешает сделать микросервисы сразу.
А если команда маленькая - есть квантовые сервисы + чистая архитектура с инверсией зависимостей и разделение кодовой базы на слои, где слой технологий выпилить в библиотеки.
Основная идея квантового сервиса - одна кодовая база(один проект) - одна команда. Чистый монолит разлагать на докеры путём декомпозиции апи, то есть слоя интерфейса. При этом ядро бизнес модели лежит как кусок независимого от апи кода (и от СУБД если использовать чистую архитектуру, хотя на слоевую оверхеда меньше). На выходе получается целая пачка докеров с одного проекта. Каждый докер масштабируется горизонтально через балансировщик всё как в микросервисах. Но при этом внутри везде одинаковый код ядра. Код он много не весит его не жалко везде засунуть. А что это даёт ? Все плюсы микросервисов раз. Всё удобство монолита два. А ещё убирает оверхед на организацию общения между микросервисах. Потому что они все на борту уже содержат бизнес-модель всю. Вот - решение.
В статье - одна вода. О страданиях Василия. Весь здравый смысл в ней "Надо уметь общаться и договариваться. Слушать и слышать". Ещё бы написали, что люди воздухом должны дышать, а то помрут. И кучу книжек предложили бы почитать, как дышать воздухом.
Будущее за 1С. А не вот это вот всё...
Добрый день. Интересная статья. На сколько Вам был бы полезен такой инструмент?
https://www.youtube.com/playlist?list=PLCxvGZsc-aLnk79wFLUzdaO6_4eitiMym
Лучшее лекарство от всех болезней в коде - это нагрузочное тестирование. А реализацию любого алгоритма можно у чат джпт спросить. Отстали от жизни интервьюеры, которые требуют знания, которые в элементарном доступе и пригождаются только тогда, когда начинается пресловутая оптимизация после нагрузки. Я за свою жизнь ещё не разу не видел, чтобы написанные опен сорс решения не болели болячками. Хоть многие и считают что все эти вещи делаются супер умными людьми, но прикол в том что именно людьми.
Вывод какой - берёшь готовую деталь - оттестируй её нагрузкой по своим кейсам, точно также как свой продукт. Просвятишься однозначно.
И как знания алгоритмов помогут тебе в оптимизации СУБД например, которая тормозит на твоих кейсах. Да никак. Ишью повесишь разрабам и будешь ждать фикса.
Не существует человека который с первого раза написал супер оптимальный чудо код. Да и с 10 го раза редко получается. И то что код оптимален может сказать именно интеграционный нагрузочный тест, который долбит по апишке или gRPC. А то иногда ведь пишут бенчмарки просто на функции ну и типо гляньте - она быстрая.
Во, тоже так подумал. Сам часто работал раньше с датчиками и микроконтроллерами. Они реально иногда чушь несут, просто из-за того что могут быть дикие электромагнитные помехи и зашумленный радиочастотный фон. Вот и появляются всякие костыли в логике обработки, которые не костыли а целая методика.
Не так давно я прикручивал датчик открытия двери в homeassistant. Так вот эта дурнина шлёт несколько событий подряд открыто, закрыто, открыто на одно физическое открытие. Там для этого придумали замечательные вещи "Ваше устройство открыто сколько по времени?". То есть фактически игнорировать события в последовательности на временной шкале. Так как они могут быть ложными.
Итого любой физический датчик рано или поздно начинает врать, причём всегда с определенной частотой. Именно поэтому стоит посмотреть в сторону камер и компьютерного зрения. Настроить её на подозрительные вещи и она будет делать их фото самостоятельно.
Ну а если жить на датчиках - просто надо принять что они иногда чушь несут просто потому что это микрухи и где то рядом с ними в момент чуши электромагнитная волна пролетела, которая может даже возникать из за неочевидных вещей - трение ножниц о металл. Ну а если датчики дешёвые - и производители no-name. Не исключено что там просто баги в коде самих датчиков.
Лично для меня уход на homeassistant вызван не столько тем, что там всё без интернета работает и вайфай и зигби и что угодно и как угодно. А тем, что там здраво продумана система ценариев. И они все локально работают. Главная Килер фича - это отслеживать в рилтайме состояния устройств и на этом строить сценарии, так ещё и с опцией запомнить как было до того, как сценарий начал работать.
А то что без интернета сможет Алиса ну это второстепенно. Особенно для людей которые на удалёнке работают, у них интернет есть всегда. А когда его нет, эти 10 минут ненастья спокойно проходят за чашкой чая. Первостепенно на мой взгляд - любые сценарии в локальной памяти хранить, а в облако дублировать. Особенно те, где голос не нужен вообще. И возможность хранить атрибуты - это просто пушка была бы.
А из супер фишек - надо Гугл корел забрать и управлять жестами через камеру. Всё руки не дойдут сделать. Вот в Алису встройте камеру и пусть жестами можно будет локально что угодно делать.
Доброго дня. Спасибо за статью. Суть ясна - копируем всё что есть из СУБД к себе в RAM, вместо Redis-а, а с помощью watch - у нас происходит обновление/инвалидация нашего внутреннего кэша.
Но обмануть закон сохранения энергии ещё никому не удавалось. Когда данных много, ну например 100 Гб. Они явно уже в сервис не влезут. Появляется необходимость шардинга, но уже Ваших сервисов, например - по месяцам. Но один в поле не воин, одна шарда - это не отказоустойчиво. Надо 3 хотябы. Ну и вот Вы создали кластер редиса. Который работает быстрее редиса, потому что у редиса видимо нет API - чтобы данные напрямую из него тащить и watch интегрировать в него. Появился чудо-сложный балансировщик трафика, которому надо ещё правильно клиентские запросы балансировать по Вашим шардам-репликам. А ещё Вы сталкиваетесь с людскими хотелками - хотим отчёт за год, а у Вас данные по разным шардам...
То есть, возникнет тот момент, когда Вы ощутите, что закон сохранения энергии начинает Вас догонять. Что все те проблемы, от которых Вы попытались убежать - настигли Вас, но в других местах. Отсюда возникает потребность сформировать общие положения и рекомендации на каких объёмах данных Вас ещё не догнало то, от чего Вы убежали. А когда начнёт догонять - Вы получите ценобразовательный Redis, подключенный через Watch к MongoDB. Со всеми проблемами редиса, будьте готовы к такому.
А ещё было бы не плохо понять сложность самих запросов на чтение. Ну это простые выборки какие-то, или множественные соединения с кучей агрегаций и вычислительных слоёв. Есть ли там Иерархические группировки данных, например. То есть что Вы имели ввиду под чтением, какова его сложность.
Итого, в рекомендации к применению может войти: объём данных, сложность исполняемых запросов на чтение (сортировки, иерархия, агрегация, много-джоинов), сложность структуры хранимых данных в самом кэше, сложность пост-обработки данных перед помещением в свой кэш, что-то ещё.
Подскажите, а на какой СУБД можно прям вместо create table - create cube сделать? Прям заинтересовало.
И кажется я знаю почему кубы перестали быть популярными - потому что в обычных СУБД - где есть JOIN и нет CREATE cube - надо было делать запросы на 1000+ строк SQL чтобы такую модель данных покрутить. А народ обленился.
Сам я не так давно сделал инструмент для создания и поддержки таких запросов, которые как раз и основаны на OLAP методологии.
К сожалению мне не дают в open source его выложить, но видео-обзором никто делиться на запрещал.
https://www.youtube.com/playlist?list=PLCxvGZsc-aLnk79wFLUzdaO6_4eitiMym
Области применения таких подходов - порталы на 10 000 000 + пользователей.
Ломать не строить. Черные ящики... Опять придумали как квантовым компьютером RSA поломать бесплатно без регистрации и смс за o(1)
Нужно исходить из более реальных примеров. А то в этом - покупка товар данные можно из бэкапов восстановить. А иначе как ты в таком простом кейсе умудрился их потерять, и где тут тебе транзакции помогли.
Зайдём с другого угла. Ну был у тебя монолит, разделил его на сервисы. Один сервис - одна бд. Вроде всё сделал правильно, НО именно путь один сервис - одна бд и привёл тебя к необходимости распределения транзакций. Ты в итоге не туда свернул и решил проблему У. Вместо решения проблемы Х. То есть тебя что-то не устраивало в монолите и ты его поменял, словил проблему ХУ.
Ты просто вспомни свой монолит. Наверное там не нужны были всякие саги... Но почему не нужны были? Вот и ключ. А сделай ты одну бд и пусть все сервисы пишут туда и смотрят туда. И сделай кое что весьма полезное одна сущность - один запрос на запись в бд. Если запрос не удался, то и ладно ты ничего не потерял. А если удался - то всё круто, все данные за один запрос зашли куда надо.
В статьях почему и как вы пошли в распределение транзакций не хватает контекста а накой оно вообще Вам надо. Я вот представил что ты монолит пилил по рекламной брошуре, которую называют бест перктис... Но почему это бест и когда они там обычно тоже не пишут. Ну сделайте один сервис - одна бд, сагу там добавьте и вот... А нафига - не говорят, а мы и не спрашиваем.
Коротко о транзакциях и их распределении - берёшь и выкидываешь их нафиг. На секунду помешаешь в голову мысль, что человечество их ещё не изобрело. Стало страшно? Поборол страх, поместил эту мысль ещё раз, теперь на минуту. Подумал хм, а может быть собрать всё как-то иначе. И придумал какую-нибудь квантовую асинхронную мульти-супер позицию состояния данных. Родил что-то новое в общем.
Ну а если без фантастики. Ну неужели нет способа без транзакций в реляционках системы строить. На каких нибудь хитрых кэшах или crdt. И как нибудь там шмяк бух и вау чего случилось.
Ну... Да. Но... сам знаешь что тут сложнее. Благо на нас монтаж видео инструкций для пользователей не вешают, как между прочим, типо ну не сложно же, тыж программист...
Нужно просто поделить новичков по их уровню интеллекта и способу самопознания.
Объективно тем, кто не любит копать глубоко, а любит быстро достигать финиша - не надо начинать с java. Им наверное вообще не надо идти в разработчики. Пока они не поймут, что это не та сфера, где можно не напрягаться и достигать высот. Им лучше в блогеры податься. Их единственный путь в разработку через тестировщика, а там python подойдёт.
Джава могут выбрать те, кто любит решать головоломки. И например, играя в компьютерные игры не просто бежит убивать босса, а сначала делает прокачку героя, готовит снарягу, выбирает место для атаки, тщательно продумывая каждое нажатие на геймпад. Да и вообще его цель не босса убить, а исследовать игровой мир и открывать сундуки. Вообще джава, она для тех кто любит и умеет заморачиваться и кайфует от долгого достижения результата.
Для математиков - Rust какой-нибудь выбрать сразу. И книжки по алгоритмам. А чё мелочиться то. Человек башковитый. И лучше снизу вверх компьютер познавать. А там и java и python и go ждут тебя и c#.
Гумманитарий - изучи как с чат gpt на python + js лепить чего-нибудь. Если не смог даже это - иди в блогеры. Сними Ютуб канал, как ты пытался войти в айти.
Для тех кто пошёл в программисты через ВУЗ - там и так напичкают всем подряд. Главные знания они будут не про код и языки. А про информационное пространство. Что есть компьютер, сети, безопасность. С помощью любого языка изучайте алгоритмы. Учитесь учиться - вот что важно. И тогда после ВУЗ-а вы не услышите "Забудь всё что знаешь". Если голова варит - возьмитесь за Go или Rust. Не очень варит - python, js, c#. Не нравиться термин варит голова - java, и создайте свой термин.
И самое главное - учение свет, а не учение - неучение. Дожимать задачу до конца надо всегда. Если не обладаете таким навыком - не надо выбирать язык какой учить. Надо научить себя учиться и добиваться результатов. Качаем супер сложную компьютерную игру и проходим на супер сложности пару уровней. Делаем забег на 5 км просто так. Понравилась девушка/парень - добиваемся до тех пор пока на ракете не пошлют на Марс. Когда все барьеры разрушены в голове - вы готовы начать выбирать язык.
Опять low code. И через 10 лет программисты вымерли не потому что их chat gpt заменил, а потому что какой-нибудь бизнес аналитик познал крутой Лоу код. И лоулиндзянями повыкидывал всех разрабов.
Вот зачем бизнесу давать инструменты такие, где надо мало кодить. Ну а потом появиться же лоукод платформа, где лоукодом её же можно и переделывать) Ну и всё. Извини чат джпт, не сегодня... Мы ещё раньше заберём работу у будущих айтишников.
Рассадники зла эти лоукод платформы.
Год 2025 мы сделали супер релиз. Но мы больше не нужны. Так как доли акций у нас были мизерные, продукт просто отобрали и мы теперь пошли в общепит обратно.
Ну уберут из питона GIL, дадут всем дженерики, через пару лет за счёт этого создадут первый официальный компилятор питона в бинарник. И что получиться, голанг какой-нибудь...
Китайские мультитулы это конечно весело. Но когда нужно копьё, как запихать в карман копьё? Какого зверя идём бить - такой и инструмент берём.
Интересно кто-то думал, когда шёл в it, что вот сейчас курс по питону от Яндекса пройду вот и буду горы денег зашибать.
Упёрлись в gil - значит доросли до копья. И пора осваивать копьё.
С языками ещё и инфастуктурщина всякая липнет. Докеры, куберы, гитлабы, дженкинс. Чат жпт вот появился. Улучшайзеры, генераторы, идеешки, плагины, базы данных, ресурсы, мощности, хостинг...
Но почему то вот язык у большинства людей в голове он как то оторван вот от остального... Мол на одном языке продукт создам на 1000 000 пользователей... Ща вот освою питон и как жахну тикток+.
Изучил питон, освоил Джил. Иди го ковыряй. Упёрся в GC - иди rust ковыряй. Там упёрся в сложно понять куда - иди в ассемблер.
Чем раньше это будет понято, тем больше миру пользы. И обсуждений зачем создали Джил и для кого - станет меньше. Особенно советов питонистам, как его обходить. На первой строке такого совета должно быть "Открываем книжку по голангу".
Интересно кто-то занимается иммитационным моделированием бизнес процессов, ну или дискретным. Чтобы были схемы процесса, где кнопку тык, и софт сказал что процесс в принципе рабочий. Ну или запустилась схема и сразу видно что блоке А всё в очередях пухнет при количестве обращений Н.
Как будто чего-то всё время не хватает при проектировании больших систем. Единого инструмента что-ли, где бы и контракты были, и границы сервисов, и bpmn модели и UML схемы, и форматы данных, и смоделированные процессы.
https://hi-tech.mail.ru/news/63098-v-rossii-nachali-prodavat-kvantovye-kompyutery-spinq/
Миру больше не нужны новые языки программирования которые, работают на битах и байтах. Мир уже прозревает потихоньку и создаёт кубиты. Но видимо не в этой статье
Ну и где подход то? Начать с монолита? Америка открыта снова...
А можно начать сразу с архитектуры и определения бизнес модели, всё как следует описать и смоделировать большинство основных бизнес-процессов. Не писать код вообще, месяц другой. И ничто уже не помешает сделать микросервисы сразу.
А если команда маленькая - есть квантовые сервисы + чистая архитектура с инверсией зависимостей и разделение кодовой базы на слои, где слой технологий выпилить в библиотеки.
Основная идея квантового сервиса - одна кодовая база(один проект) - одна команда. Чистый монолит разлагать на докеры путём декомпозиции апи, то есть слоя интерфейса. При этом ядро бизнес модели лежит как кусок независимого от апи кода (и от СУБД если использовать чистую архитектуру, хотя на слоевую оверхеда меньше). На выходе получается целая пачка докеров с одного проекта. Каждый докер масштабируется горизонтально через балансировщик всё как в микросервисах. Но при этом внутри везде одинаковый код ядра. Код он много не весит его не жалко везде засунуть. А что это даёт ? Все плюсы микросервисов раз. Всё удобство монолита два. А ещё убирает оверхед на организацию общения между микросервисах. Потому что они все на борту уже содержат бизнес-модель всю. Вот - решение.
В статье - одна вода. О страданиях Василия. Весь здравый смысл в ней "Надо уметь общаться и договариваться. Слушать и слышать". Ещё бы написали, что люди воздухом должны дышать, а то помрут. И кучу книжек предложили бы почитать, как дышать воздухом.