Ну приведи же цитату из моих коментариев (можно даже не только из первого) где я такое говорю.
Я уже устал по кругу одно и то же писать разными формулировками. Это ты вцепился в идею что все тебе насаждают богомерзкий ООП, а говнокодинг это небходимость и доказываешь это каждому (не только мне и не только в этой ветке)
Самое страшное в том, что тебя плюсуют не боты накрутки, а реальные люди которые считают так же. Вот к этой ситуации как раз и относится моя цитата про "царства"
Это применимо только когда ты пишешь сам и для себя. Если продукт как минимум смотреть кто то еще будет то коментарии необходимы. А если это классический комерческий продукт, с командой разработки и поддержкой годами - лучше коментариями даже вообще очевидные веши покрыть, а "вещи требующие причины" и вовсе заанотировать развернуто.
Много раз встречал такой лютый пиздец, что диву даешся как так можно на этом языке то - а разработчку все понятно.
С количеством "шума" при вычислениях все современные "вычислители" можно минимум на 100 делить от заявленой мощности.
Мне кажется, даже обьединяя эти тазики в целые кластеры все равно не получится "как думается" так как каждая нода считает независимо. Дешевле и проще на те же деньги огромный кластер FPGA под те же задачи.
И вот как раз таки кластеру FPGA размером с хороший ангар и заточеному только и только под одну задачу вполне реально сотворить такие подвиги.
Из опыта работы с телеграмом - два раза сталкивался с тем что телега ввела новый функционал, а библиотека даже спустя месяц его не имеет (зато пофиксили старые косяки и наделали новых)
И это я подразумеваю период когда у телеги сторисы даже не планировались.
На сейчас "своя реализация" удобна тем, что оно 100% работает как ожидается (и покрыто нормальными тестами). А так же при необходимости добавление нового функционала просходит за пару часов (например мультиязычная подсказка к командам бота) без небходимости лепить костыли так как в либе этого нет, а потом через время править на "тру вей" через либу когда там появится такой функционал.
К примеру наше решение работало с емодзи в первые дни релиза как они появились, тогда еще документации не было нормальной к ним (и потом еше правили наживую). Либы стали поддерживать емодзи если мне память не изменчет только тогда когда их в документацию внесли на чистовую, и то не все и не сразу.
Там можно или собрать "панель" по их стандартам (заморочки вагон)
Или просто выбрать в слоях фрезеровку (не помню как точно называется, есть в доках) и этот слой для краев делает "карточный" срез под 45° а "в плате" просто пропилы но сама плата жесткая
Но это в pro.
Уже 3 год заказываю такое и проблем нет. Единое что я заказываю панелями со сборкой. То есть мои платы с пропилами как одна сущность собираются в большую панель на 20 сущностей (так как мелкая плата слишком для автосборки)
Сходу рекомендую хранить как мин в SQLite с разметкой. Просто в файл дописывать быстро но адово потом обрабатывать. Ни в коем случае логи для контроля не хранить в той же базе если они в единственном екземпляре
В идеале вообще что то готовое заюзать с репликацией. Например ваш скрипт может не писать а отсылать результат в брокер где уже несколько слушателей независимо положат в базу.
Из практики - в случае аварии доступ к данным может отсутсвовать
Задача хороших програмистов решать задачу так, что бы решение не порождало собой новые проблемы
А вы сейчас по классике пытаетесь оправдать говнокодинг. Не знаешь ООП - используй то что знаешь, в чем проблема то. Я нигде не говорил что ООП это золотая пуля и тд.
Каждому инструменту свое применение. Но инструментами нужно уметь пользоватся. К сожалению на сейчас очень большой процент некомпетентности, который только усугубляется тем что прохождение собеседования абсолютно никак не корелирует с реальными знаниями и навыками.
.
По последнему абзацу - все чаще встречаю ситуацию, когда уже не джуны, а "новые мидлы" не знают базовых основ по своему стеку. Про классику со структурами и тд вообще молчу. Зато как попугаи готовы повторять вызубренные термины без малейшего понимания и прямо говоря что это вообще бесполезно так как никогда им в практике не попадалось.
С таким отношением я не спорю что "большинство" совершенно не понимает базовые вещи, считая их "сложными".
Единсвенное что спасает и ужасает - chatGPT позволил таким "погромистам" еще лучше мимикрировать.
А потом охреневаешь от "решения задачи" которая выжирает в 20 раз больше оперативной памяти чем должно, потому что програмист вообще не понимает разницы между передачей среза и ссылки на срез, а тот метод что ему написал chatGPT не работает с ссылкой правильно.
Самая большая проблема с ООП в том, что каждый пытается его понимать в меру своего разумения и получается то что вот сейчас. Терминология, прибитая к старым языкам и ожидающая что програмист владеет определенными базовыми знаниями не упрощает ситуацию.
.
Самое печальное в этом всем, что неумение в ООП не означает умение в функциональное програмирование( Сейчас большая часть продуктов адская вермишель легаси, которую спасает только тотальное покрытие тестами
Сколько дел было против них на монополию, сколько штрафов заплатили, но что то я вообще не наблюдаю улучшения. Только хуже становится.
Зато опять таки эти большие гиганты готовы судится со всеми кто попытается выпустить похожий продукт. Или покупают перспективные стартапы за любые деньги, лишь бы они стали их. Собсвенно практически все купленые перспективные стартапы были "убиты". Какое удивительное совпадение.
Из личного опыта - обмазывать все в crm такое себе решение.
Во первых не на всех уровнях компании нужен crm. Точнее его можно внедрить, но та часть функционала что нужна решается через таблицы, а готовой crm нет с такими требованиями. И приходим к "долго и дорого"
Во вторых я часто видел как компании "тонули" в crm. Одна для финансов, другая для работы с клиентами, третья для логистического контроля. Такого что бы "одна на все задачи" зачастую нет. Готовые решения на рынке - под них нужно подстраиватся и то зачастую они не все 100% потребностей покрывают. И готовые решения зачастую очень не демократично стоят по подписке и с расчетом на количество работников. Создавать свое "долго и дорого"
В третьих crm не является золотой пулей. Если сам по себе процесс поставлен через жопу, то обмазывание crm проблему только усугубит.
.
Резюмируя - каждому инструменту свое место и каждым инструментом нужно уметь пользоватся. Можно бобрам подарить пилу, но это бесполезно если они будут ею "пилить" используя тупую сторону - в таком случае зубами дейсвительно быстрее и удобнее. Для ситуаций когда решение треьует что то сложнее "пилы" тем более нет смысла "набирать" разных инструментов, что бы потом ими жонглировать.
CRM должен оптимизировать работу, а не усложнять. Если хотите внедрить у себя - начните с малого, один тестовый отдел. Нужно четко понимать как и какие проблемы решает crm. И на практике проверить решает ли. Разом 'внедрять' без исследования контродуктивно. Как и создавать с нуля из ТЗ имея только "делайте хорошо, плохо не лелайте".
Если внедрение CRM никак не упростило работу (а может и усложнило) то скорее всего вам слишком рано. Нужно менять процессы, выбрать (или создать) более узкую crm под вашу задачу и возможно обучить сотрудников ею пользоватся, без надежды "там просто, сами разберутся"
Мне больше https://github.com/PaulSonOfLars/gotgbot зашел. Странно что его не упомянули.
Точнее потом от его идеи с автогенерированием всех структур и методов из документации оттолкнулись и сделали свое решение.
Сторонние либы хороши для ситуаций "накидал и забыл". Когда бота нужно поддерживать и обновлять, особенно когда несколько разных платформ сходится в один функционал, удобнее свою реализацию сделать, что бы не заниматся потом исправлением чужих косяков.
Плюс свою реализацию можно потом в отдельный модуль обернуть и притягивать к своим другим проектам как модуль
Мда. У войск давно есть системы аккустической пеленгации артилерии.
Услышать дрон или рой дронов нереально. Люди и транспорт создают такой же звук постоянно. Даже направление чисто в небо не поможет так как звук может отразится от слоев атмосферы при соблюдении условий (тучи, влажный воздушный поток).
Такое можно думать делать только в местах где люди очень редкий гость
Ну приведи же цитату из моих коментариев (можно даже не только из первого) где я такое говорю.
Я уже устал по кругу одно и то же писать разными формулировками. Это ты вцепился в идею что все тебе насаждают богомерзкий ООП, а говнокодинг это небходимость и доказываешь это каждому (не только мне и не только в этой ветке)
Самое страшное в том, что тебя плюсуют не боты накрутки, а реальные люди которые считают так же. Вот к этой ситуации как раз и относится моя цитата про "царства"
Абсолютно не согласен.
Это применимо только когда ты пишешь сам и для себя. Если продукт как минимум смотреть кто то еще будет то коментарии необходимы. А если это классический комерческий продукт, с командой разработки и поддержкой годами - лучше коментариями даже вообще очевидные веши покрыть, а "вещи требующие причины" и вовсе заанотировать развернуто.
Много раз встречал такой лютый пиздец, что диву даешся как так можно на этом языке то - а разработчку все понятно.
Скоро в резюме еше и тикток про себя снять нужно будет?)
Веруны в квантовые вычисления)
С количеством "шума" при вычислениях все современные "вычислители" можно минимум на 100 делить от заявленой мощности.
Мне кажется, даже обьединяя эти тазики в целые кластеры все равно не получится "как думается" так как каждая нода считает независимо. Дешевле и проще на те же деньги огромный кластер FPGA под те же задачи.
И вот как раз таки кластеру FPGA размером с хороший ангар и заточеному только и только под одну задачу вполне реально сотворить такие подвиги.
Физику не наебать, увы и ах.
Из опыта работы с телеграмом - два раза сталкивался с тем что телега ввела новый функционал, а библиотека даже спустя месяц его не имеет (зато пофиксили старые косяки и наделали новых)
И это я подразумеваю период когда у телеги сторисы даже не планировались.
На сейчас "своя реализация" удобна тем, что оно 100% работает как ожидается (и покрыто нормальными тестами). А так же при необходимости добавление нового функционала просходит за пару часов (например мультиязычная подсказка к командам бота) без небходимости лепить костыли так как в либе этого нет, а потом через время править на "тру вей" через либу когда там появится такой функционал.
К примеру наше решение работало с емодзи в первые дни релиза как они появились, тогда еще документации не было нормальной к ним (и потом еше правили наживую). Либы стали поддерживать емодзи если мне память не изменчет только тогда когда их в документацию внесли на чистовую, и то не все и не сразу.
Там можно или собрать "панель" по их стандартам (заморочки вагон)
Или просто выбрать в слоях фрезеровку (не помню как точно называется, есть в доках) и этот слой для краев делает "карточный" срез под 45° а "в плате" просто пропилы но сама плата жесткая
Но это в pro.
Уже 3 год заказываю такое и проблем нет. Единое что я заказываю панелями со сборкой. То есть мои платы с пропилами как одна сущность собираются в большую панель на 20 сущностей (так как мелкая плата слишком для автосборки)
Немного не в тему - а почему используете easyEDA, а не pro версию?
Она тоже бесплатная но более проффесиональная я бы сказал. И линию фрезеровки для последующего разлома плат смогли бы указать.
Сходу рекомендую хранить как мин в SQLite с разметкой. Просто в файл дописывать быстро но адово потом обрабатывать. Ни в коем случае логи для контроля не хранить в той же базе если они в единственном екземпляре
В идеале вообще что то готовое заюзать с репликацией. Например ваш скрипт может не писать а отсылать результат в брокер где уже несколько слушателей независимо положат в базу.
Из практики - в случае аварии доступ к данным может отсутсвовать
Воистину в царстве горбатых прямая спина будет считатся уродством.
И вы опять вцепились в принципы програмирования, когда я с самого начала говорю о том что важно не средство или принцип, а умение и понимание.
Задача програмистов решать задачу.
Задача хороших програмистов решать задачу так, что бы решение не порождало собой новые проблемы
А вы сейчас по классике пытаетесь оправдать говнокодинг. Не знаешь ООП - используй то что знаешь, в чем проблема то. Я нигде не говорил что ООП это золотая пуля и тд.
Каждому инструменту свое применение. Но инструментами нужно уметь пользоватся. К сожалению на сейчас очень большой процент некомпетентности, который только усугубляется тем что прохождение собеседования абсолютно никак не корелирует с реальными знаниями и навыками.
.
По последнему абзацу - все чаще встречаю ситуацию, когда уже не джуны, а "новые мидлы" не знают базовых основ по своему стеку. Про классику со структурами и тд вообще молчу. Зато как попугаи готовы повторять вызубренные термины без малейшего понимания и прямо говоря что это вообще бесполезно так как никогда им в практике не попадалось.
С таким отношением я не спорю что "большинство" совершенно не понимает базовые вещи, считая их "сложными".
Единсвенное что спасает и ужасает - chatGPT позволил таким "погромистам" еще лучше мимикрировать.
А потом охреневаешь от "решения задачи" которая выжирает в 20 раз больше оперативной памяти чем должно, потому что програмист вообще не понимает разницы между передачей среза и ссылки на срез, а тот метод что ему написал chatGPT не работает с ссылкой правильно.
И все как всегда.
Актуально ли ООП? Да
Умеют ли програмисты с ним работать? Зачастую нет
.
Самая большая проблема с ООП в том, что каждый пытается его понимать в меру своего разумения и получается то что вот сейчас. Терминология, прибитая к старым языкам и ожидающая что програмист владеет определенными базовыми знаниями не упрощает ситуацию.
.
Самое печальное в этом всем, что неумение в ООП не означает умение в функциональное програмирование( Сейчас большая часть продуктов адская вермишель легаси, которую спасает только тотальное покрытие тестами
Сразу вспоминаю удаленное видео с ютуба, где видеокамера с улицы смогла снять как "вносились голоса" в избирательную урну)
Это я про текущие выборы если что.
Сколько дел было против них на монополию, сколько штрафов заплатили, но что то я вообще не наблюдаю улучшения. Только хуже становится.
Зато опять таки эти большие гиганты готовы судится со всеми кто попытается выпустить похожий продукт. Или покупают перспективные стартапы за любые деньги, лишь бы они стали их. Собсвенно практически все купленые перспективные стартапы были "убиты". Какое удивительное совпадение.
В чудное время живем.
Из личного опыта - обмазывать все в crm такое себе решение.
Во первых не на всех уровнях компании нужен crm. Точнее его можно внедрить, но та часть функционала что нужна решается через таблицы, а готовой crm нет с такими требованиями. И приходим к "долго и дорого"
Во вторых я часто видел как компании "тонули" в crm. Одна для финансов, другая для работы с клиентами, третья для логистического контроля. Такого что бы "одна на все задачи" зачастую нет. Готовые решения на рынке - под них нужно подстраиватся и то зачастую они не все 100% потребностей покрывают. И готовые решения зачастую очень не демократично стоят по подписке и с расчетом на количество работников. Создавать свое "долго и дорого"
В третьих crm не является золотой пулей. Если сам по себе процесс поставлен через жопу, то обмазывание crm проблему только усугубит.
.
Резюмируя - каждому инструменту свое место и каждым инструментом нужно уметь пользоватся. Можно бобрам подарить пилу, но это бесполезно если они будут ею "пилить" используя тупую сторону - в таком случае зубами дейсвительно быстрее и удобнее. Для ситуаций когда решение треьует что то сложнее "пилы" тем более нет смысла "набирать" разных инструментов, что бы потом ими жонглировать.
CRM должен оптимизировать работу, а не усложнять. Если хотите внедрить у себя - начните с малого, один тестовый отдел. Нужно четко понимать как и какие проблемы решает crm. И на практике проверить решает ли. Разом 'внедрять' без исследования контродуктивно. Как и создавать с нуля из ТЗ имея только "делайте хорошо, плохо не лелайте".
Если внедрение CRM никак не упростило работу (а может и усложнило) то скорее всего вам слишком рано. Нужно менять процессы, выбрать (или создать) более узкую crm под вашу задачу и возможно обучить сотрудников ею пользоватся, без надежды "там просто, сами разберутся"
Мне больше https://github.com/PaulSonOfLars/gotgbot зашел. Странно что его не упомянули.
Точнее потом от его идеи с автогенерированием всех структур и методов из документации оттолкнулись и сделали свое решение.
Сторонние либы хороши для ситуаций "накидал и забыл". Когда бота нужно поддерживать и обновлять, особенно когда несколько разных платформ сходится в один функционал, удобнее свою реализацию сделать, что бы не заниматся потом исправлением чужих косяков.
Плюс свою реализацию можно потом в отдельный модуль обернуть и притягивать к своим другим проектам как модуль
Как показывает практика - апи ботов всегда довольно простое.
Так же зачастую не нужны все 100% функционала бота. Особенно это актуально для обработчика нескольких ботов
В итоге самое сложное это парсинг и сборка json))
.
Тыкал разные модули для ботов, все они зачаствю или тянут дохрелион зависимостей и раздувают проект или имеют узкий функционал
И концепции запланированого удорожания
Воистину гугл в очередной раз доказывает что дна нет.
Как я скучаю за их поиском из 2007, когда правильно сформировав запрос можно было найти практически все
Мда. У войск давно есть системы аккустической пеленгации артилерии.
Услышать дрон или рой дронов нереально. Люди и транспорт создают такой же звук постоянно. Даже направление чисто в небо не поможет так как звук может отразится от слоев атмосферы при соблюдении условий (тучи, влажный воздушный поток).
Такое можно думать делать только в местах где люди очень редкий гость
Ех, вот это я понимаю жить и работать в стране с легализироваными наркотиками.
Что бы придумать такое нужно "читать" не день и не два