Задать вопрос
  • Как сконфигурировать статический ip?

    @idd451289 Автор вопроса
    Ну у меня ip перепривязался, только куда делся мой старый статический? И не совсем понял по поводу проброса портов
    Написано
  • Как сконфигурировать статический ip?

    @idd451289 Автор вопроса
    Дмитрий, Ну суть в том что у меня есть инфа для IPOE соединения в лк, и теперь добавлся статический ip. Раньше у меня был 1 ip(он судя по всему тоже был статическим), и теперь он сменился на тот, который мне добавили
    Написано
  • Как лучше учить node.js?

    @idd451289
    historydev, Опять же нет


    Теперь ты говоришь об абстракции на уровне кода)

    Я о них изначально и говорил
    Я упоминал что сначала мы строим модели, cвязи и доменные области. Но очевидно мы их строим уже когда понимаем что такое какие нибудь классы и как они работают, как в нашем случае


    Все эти инструменты влекут за собой горы публичных апи и вместо изучения базы, тебя дрессируют на их понимание.

    Перед тем как обучать умножению, в школе подают сложение и вычитание.

    Не совсем так. Точнее это не наш случай. Тут человек знаком с фронтом и соответственно с js-ом, и учить его циклам нет смысла. А вот что имеет смысл это переходить к практике и писать уже какое нибудь api параллельно глядя в доку или на ютубе а как сделать то и это

    Но собственно так же и с простым обучением. Даже ничего не зная лучше взять идею, и делать ее, попутно изучая все(ну понятно что с вещами типа переменных и вывода в консоль лучше всего ознакомится, потому что без них просто ничего не сделаешь)

    А так вообще я пытался мысль донести что без практики теория бесполезна(а единственный способ ее получить это писать код)


    - доростёшь, поймёшь как тяжело не знать на чём всё построено.

    А вот эта фраза очень плохая, выкиньте ее. С чего бы вам быть уверенным что я вас уже не перерос?))
    Написано
  • Как лучше учить node.js?

    @idd451289
    historydev, Нет)

    Архитектура процессора ничего не делает, кроме того, как устанавливает спецификацию для регистров и инструкций.

    В принципе наверное могу согласиться. Архитектура действительно здесь не особо уместна. Но суть моего вопроса вы поняла. Если вы не понимаете всего процесса работы условного процессора и прочих элементов, то вот не правильно вы все изучаете, без абстракций правильно


    Вся эта белиберда, это куча абстрактных понятий через запятую.

    Опять же мысль должна быть ясна. Размер приложения. Хеллоу ворлд обычно подразумевает собой что то очень простое, а огромное апи подразумевает собой какое-то приложение близкое к большому продакш решению(апи я взял банально потому что мы говорим про бэк и как раз таки зачастую при разработке мы получаем какое-нить rest api)


    То, о чём ты говоришь противоречит самому себе, то ты за обучение на практике, то за обучение через абстракции, определись уже.

    Одно другому не противоречит
    Мы пишем на условном nest-е. При этом мы имеем абстракцию над express-ом(убирая всякие res.send), получаем готовые декораторы для более простого управления express-ом. Так же вместо чистых мидлвар мы имеем готовые пресеты для расширений(guards, exception filters, interceptor). В ту же корзину DI. И собственно туда же можно отнести всякие абстракции типа редиски для кэша, каких то СУБД, и прочего

    И собственно вместо того чтобы думать о том как работают эти несколько слоев абстракций мы учимся строить предметную область, разбивать приложение на домены(не те которые для маппинга ip используются)

    А вот после того как мы научились это делать можно опуститься на уровень ниже, и смотреть как работает нест, экспресс, и еще куча слоев которые в теории можно убрать
    При этом понимать требования бизнеса и знать решения к ним(согласен что это тоже абстракция своего рода) тоже требуется, но это задача вторична, потому что пока человек не может реализовать ту самую форму толкну от него ноль(если мы говорим про разработку)


    Я могу рассказать намного больше, чем ты сможешь понять. - для тебя этот вопрос просто шутка, пусть ей и останется.

    Если это правда то уважаю. Я поковырял немного уровень ассемблера и прочего и что-то как то не мое, пошел дальше крудошлепить(шутка)
    Написано
  • Как лучше учить node.js?

    @idd451289
    historydev, Ну давайте начнем с простого
    Способ это действительно единственный. Потому что прочитай ты документацию 100 раз, вызубри все паттерны и книги по проектированию, пока ты не напишешь хоть что-то - будешь не знать как учить. А как только начнешь что то писать вылезут естественные вопросы - а где хранить данные, в какой базе, а оптимален ли мой запрос, а надо ли мне вот тут что то изменить, а можно ли упростить какой то бойлерплейт. И вот тогда начинается гуглеж и разбор кучи вопросов. А так, ну знаешь ты как работает какая нить условная редиска, пока не поюзаешь и не столкнешься с проблемами знания гроша не стоят(ну с хелло ворлдом я конечно переборщил, все таки стоит взять что то побольше, но суть думаю ясна)

    Дальше. На счет абстракций. Как по мне как раз именно их и надо сначала показывать. Потому что сначала мы учимся решать задачу(хоть как то), потом учимся формировать какие то предметные области(модели, разделять слои и все такое), и уже потом или параллельно можно изучить как работает nest или express под капотом
    И еще немного в тему абстракции, Можете мне послойно рассказать что происходит от архитектуры процессора и голого железа до исполнения кода?))) Причем не словами уровня: ну вот процессор получает инструкции и исполняет их?) Ну собственно тогда вам не то что js, си нельзя доверить. Так и работают абстракции)) Возможно когда то оно вам понадобится, и вы это изучите, но сейчас как видите и так хорошо идет
    Написано
  • Как лучше учить node.js?

    @idd451289
    Вообще самый простой способ
    Берешь любой фреймворк(хоть легковесный express, хоть архитектурно мощный nest) и пишешь
    Вот что угодно, любое приложение, хоть хеллоу ворлд, хоть огромное апи
    Это по сути единственный способ что то изучить
    Написано
  • Стоит ли использовать ООП для бота на Telebot?

    @idd451289
    И да и нет
    Все зависит от архитектуры вашего приложение и уровня его сложности

    Есть процедурный подход, т.е. тупо функции. Он простой, но приложение быстро растет, и его как по мне нужно контролировать хорошо

    Так же, например в nestjs есть уровень сервисов, которые работают с данными, и уровень контроллеров - классов которые тем или иным способом осуществляют общение с внешним миром(например путем тг бота). Кола больше, но у вас есть di, более удобная и четкая организация проекта, и возможность добавить впоследствии ещё один вариант отдачи данных(например чистый рест)

    А можно сделать как вы предложили с классом на команду. Это решение дает большую свободу нежели нест, но меньшую нежели процедурка. По объему кода это решение будет больше, так как надо будет написать основной пласт кода с взаимодействием классов и бота

    В общем определитесь чего хотите, и вперёд)
    П.с. нест замените на какой нить питоновский фреймворк, я прост на жсе пишу
    Написано