• Как написать бота отслеживающего скидки на маркетплейсах?

    ipatiev
    @ipatiev
    Потомок старинного рода Ипатьевых-Колотитьевых
    Ну что вы как дети?
    Каждый раз этот вечнозелёный вопрос обрастает гроздьями любопытных.
    Спарсить весь интернет мы хочем, а научиться пользоваться одним поисковым сервисом - не можем.
    Ответ написан
    Комментировать
  • Как хранить сайт на гитхабе?

    sergiks
    @sergiks Куратор тега Веб-разработка
    ♬♬
    github pages

    1. создать репо с названием username.github.io, где username – точное имя вашего аккаунта или организации, в которой это репо
    2. в нём создать index.html
    3. запушить в основную ветку main
    4. открыть https://username.github.io


    Потом можно настроить и свой домен на этот сайт.

    Единственная неприятность, если сайт требует билда скриптов и прочего, в итоге придётся коммитить и скомпилированные файлы.
    Ответ написан
    Комментировать
  • Что нужно знать про ООП?

    @Evident
    От ООП в php одно название, потому что даже перегрузки методов нет.
    Чтобы проще постичь ООП, переходите на Java или C#.
    Ответ написан
    8 комментариев
  • Правда ли что рынок веб разработки "перегрет"?

    OTCloud
    @OTCloud
    Программирование и Архитектура ПО
    100% перегрет, но не программистами или веб-мастерами, а индивидами, которые решили что веб это просто и легко и не стоит сильно париться над своими скиллами и знаниями.
    Ответ написан
    8 комментариев
  • Может ли быть API не как API?

    @karminski
    Senior React.JS Developer
    Так вот, для меня, - все AJAX запросы это API

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

    Апи можно дергать как Аяксом, так и curl и другими методами.
    Ответ написан
    Комментировать
  • Есть ли сайт, где собраны общепринятые практики программирования?

    Moskus
    @Moskus
    Естественно, нет, потому что всё, что вы описали - это не какое-то тайное знание, которое можно только запомнить, а логичные приёмы, которые следуют из знания фундаментальных принципов и анализа требований к продукту. Если попытаться заменить фундаментальные знания таким сборником прецедентов, он получится гигантским и совершенно непригодным для освоения - столько всего просто нельзя запомнить. Объем фундаментальных знаний - на порядки меньше объёма частностей, которые из них выводятся, но сложность этих знаний, при этом, выше. Кто фундаментальные знания не осилил, остаётся говнокодером, пока не осилит.
    Ответ написан
    Комментировать
  • Чем опытнее разработчик, тем меньше соблюдается принцип KISS?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Принцип KISS не означает что надо использовать самые примитивные инструменты.
    Он означает, что не надо переусложнять систему без нужды.
    Если так рассуждать, так и высшее образование не нужно: "Дед отличные бани строил, хотя вовсе был неграмотный. Я и без сопромата небоскреб построю!"
    Если вы пока ещё не понимаете назначение всех этих "лееров, провайдеров и репозиториев", это не значит, что они вообще никому не нужны.

    Для того, чтобы упростить управление системой, её надо усложнить.
    Этот принцип относится к любой области человеческой деятельности, от постройки ракет до управления государствами.
    Чем сложнее система, тем больше накладные расходы на ее управление. Хоумпейдж с котиками можно и нужно делать примитивными средствами. В большом проекте надо сразу закладываться на будущую расширяемость. То есть, заранее делить ответственность между "леерами".

    И кстати. Код, в котором "всё друг на друге завязано" - это очень плохой код. Собственно, предназначение всех этих "лееров, провайдеров и репозиториев" как раз в том, чтобы компоненты были как можно более независимы друг от друга.
    Ответ написан
    1 комментарий
  • Кто знает простые альтернативы JQuery?

    VanillaJS, очень хороший фреймворк. Перешел на него с jQuery и всем советую.
    Ответ написан
    3 комментария
  • Какой язык/фреймворк выбрать?

    neatsoft
    @neatsoft
    Life is too short for bad software
    Фреймворки нужны для упрощения и ускорения разработки - избавления от бойлерплейта и защиты от типичных ошибок. Можно ли всё тоже самое сделать вручную? Можно, но не нужно - большая часть времени уйдет на изобретение велосипедов, некоторые из которых будут медленными или небезопасными.

    По моему опыту, Django позволяет реализовывать типичные задачи вдвое быстрее, чем Laravel (использовал оба). Во многом это заслуга Python и сложившейся вокруг него экосистемы. Здесь выбор очевиден.

    VueJS скорее с ReactJS нужно сравнивать, а не с Angular, т.к. Angular это фреймворк, а VueJS и ReactJS - библиотеки. Все три помогают быстро и эффективно создавать фронтенд современных веб приложений, но делают это по разному. В качестве первого мягко (ненастойчиво) рекомендую изучить VueJS.

    p.s. Вне зависимости от выбора, не стоит заниматься веб-разработкой под windows. Стандартные среды - Ubuntu 18.04 (либо любой другой, но не слишком маргинальный дистрибутив) и MacOS.
    Ответ написан
    5 комментариев
  • Актуально ли изучать nodejs для бекенда или лучше оставаться на php?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Изучать надо программирование.
    Все эти вопросы, "Какую машину лучше учиться водить - Рено или Фольксваген?" - это детский сад, честное слово.
    Если для вас потолок - это несколько десятков встроенных функций одного языка, то всё равно что учить - ковыряться помаленьку можно на любом.
    Программист же мыслит не инструкциями, а алгоритмами, паттернами, потоками данных, структурами объектов, шинами сообщений. На каком языке это все реализуется - не принципиально.
    Ответ написан
    2 комментария
  • Как правильно писать на ООП?

    Xuxicheta
    @Xuxicheta
    инженер
    У вас линейная обработка данных, это одна процедура, а вы сделали класс ради класса.

    Вообще в js я начал стараться предпочитать функциональный стиль там, где это возможно.
    Даже методы пишу максимально похожими на чистые функции. Так проще переиспользовать их в других местах и, вообще, понятнее что происходит.
    А то уже замучался разбираться с этим хардкорным ООП, которое встречается сплошь и рядом.

    Качественный класс написать сложно, плюс наследование в js не особо рекомендуется. А для композиции лучше подходят простые функции.
    Ответ написан
  • Подготовка к собеседованию Junior Ruby on Rails?

    c3gdlk
    @c3gdlk
    Ментор в http://rubyboost.ru/
    Я уже выучил Ruby, RoR


    до сих пор не могу сказать, что выучил рельсы и руби =)

    По сабжу

    REST, MVC, структура проекта, в каких папках что лежит, включая папку config.
    что такое представление, паршиалы, по моделям полностью - скоупы, ассоциасии. валидации, коллбеки
    контроллеры - before_action, что уже лежит в ApplicationController
    Unix - что такое приложение, процесс и порт. Что делать если при старте сервера пишет, что порт 3000 уже используется.
    По руби - идиома @a ||= b, блоки, циклы, что делаeт attr_accessor, что такое символ, константы в руби.
    По базам - прошу привести примеры какие запросы генерирует та или иная цепочка DSL ActiveRecord, например
    User.where(id: 1), User.where(id: [1]), User.where(id: []) И таких вариантов куча, нет смысла пытаться заучить, нужно разбираться.

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

    Кроме того, предлагаю банальщину - пройтись по основам railsguides и убедиться, что верно понимаете соглашения фреймворка. Rails построен на соглашениях и тот кто в них хорошо разобрался имеет высокий шанс получить работу.

    Например, большинство кандидатов на вопрос, что в имени представления index.html.erb означает html отвечают, что это язык разметки в котором вернется ответ. Т.е. они просто строят логичное предположение и не пытаются его проверить. И таких, казалось бы простых вопросов, у меня целая пачка. В большинстве случаев кандидат уходит с пониманием, что ничего на самом деле и не знает.

    P.S. лучше знать что-то одно хорошо, чем много всего по немногу.

    Но, в каждой компании по разному.
    Ответ написан
    Комментировать
  • Как организовать структуру для spa приложения (backend, frontend)?

    dmitriylanets
    @dmitriylanets
    веб-разработчик
    на самом деле вы должны проектировать ваш rest отталкиваясь от предметной области, от сущностей, а там нет разделения публичка, админка
    Ответ написан
    Комментировать
  • В чём причина постоянного переделывания кода?

    Заказчик хочет чтобы разработчик сделал сложное приложение.

    Причина 1: обычно заказчик хочет, но не знает чего конкретно. Фишка в том, что разработка приложения, у которого ещё нет аналога - это... не только разработка приложения. Это ещё и выяснение того, что действительно нужно, начиная с пожеланий по UX, и заканчивая оптимизацией бизнес-процессов во всей компании (это когда заказчик внезапно говорит "слушайте, и правда, на кой чёрт мы печатаем эту накладную каждый раз").

    КПД получается крайне низок.

    Причина 2: вы не учитываете причину 1 при расчёте КПД и думаете, что проделали мало работы. Да, приложение ещё не готово или делается очень долго, но это не потому что вы мало работаете, а потому что работы намного больше, чем казалось.

    но идёт на удаление или переделку из-за того, что что-то не так.

    Причина/особенность 3: иногда это неизбежно: бизнес меняется, потребности - тоже.
    Иногда этого можно избежать, не заводя требования слишком "далеко" - очевидно, нет смысла реализовывать то, что УЖЕ СЕЙЧАС кажется неподходящим под требования, НО это далеко не всегда вовремя замечают. Над проектом работает много людей, у всех немного разные представления о задаче, или ещё хуже: не все и далеко не всегда говорят о проблемах с системой, которые уже виднеются "на горизонте", говоря что "в ТЗ всё написано, а мы делаем по ТЗ". Можете погуглить статьи о стоимости ошибок на разных этапах разработки.

    Причина 4: заказчик, разработчики или и те и другие не умеют останавливаться и выбирать необходимый и достаточный функционал для первого или очередного релиза. Я в последнее время убеждаюсь, что это целая наука - вовремя остановиться и не расширять список "супернужных" фич, из которых треть окажется почти невостребованными. Особенно часто это бывает, когда бизнес уже работает как-нибудь (например, на экселевских табличках или Access-овских базах), а теперь пришла пора автоматизации, но релиз постоянно откладывается, потому что "и это хочется, и то бы сразу сделать". Иными словами, иногда нужно решиться на гарантированные переделки в будущем ради релиза сейчас. Оценка возможности и стоимости таких "переделок" - т.е. подождать и переделать сейчас или зарелизиться и переделать потом (соответственно, с удорожанием "переделок") - и есть та самая наука. Разработчик обычно видит только архитектуру, и раньше понимает её недостатки/ограничения, ему сложно решиться на релиз того, что не будет идеально решать поставленную задачу.
    Ответ написан
    Комментировать
  • В чём причина постоянного переделывания кода?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    В неумении разработчика проектировать гибкую архитектуру приложения и писать расширяемый код.
    Ответ написан
    2 комментария
  • В чём причина постоянного переделывания кода?

    titov_andrei
    @titov_andrei
    All my life I learn - and die a fool!
    Ремонт ЗАКОНЧИТЬ нельзя — его можно только ПРЕКРАТИТЬ.
    https://www.inpearls.ru/
    - © Михаил Жванецкий
    Ответ написан
    Комментировать
  • В чём причина постоянного переделывания кода?

    Maksclub
    @Maksclub
    maksfedorov.ru
    Причин много:
    1. Бизнесу всегда нужно срочно. Из-за этого менеджер/заказчик бьет по рукам и говорит "не до архитектуры и главное быстрее", по итогу — пилятся костыли, которые блинным комом накатываются и в определенный момент нужно переписывать куски структуры, чтобы просто иметь техвозможность работать дальше
    2. Если было жирно по ресурсами и времени изначально и такая проблема — не правильная архитектура, экономия на тестах и прочее
    3. Плохая договоренность и плохое понимание задачи с каждой стороны, у кого-то завышенные/заниженные ожидания (один сказал сделай мне приложение, второй сказал, что сделает — вина обоих в таком случае)
    4. Не всегда это плохо. Сначала быстро запустили (проверили гипотезу, получили первые деньги, инвестиции и прочее), потом переделывают планово (просто этот план может не проговорен, отсюда плохие ожидания и чувство низкого КПД, а он может высокий как раз).

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

    UPD: Urukhayy речь не об этом проекте?
    Может ли проект быть собран с низким качеством кода, и пользоваться большим спросом?
    Ответ написан
    Комментировать
  • В чём причина постоянного переделывания кода?

    search
    @search
    мама говорит что я особенный
    На самом деле, рефакторинг - это неотъемлемый элемент процесса разработки. Без него никак. На поздних этапах обязательно всплывают неучтенные подробности. К тому же сам разработчик развивается и стремится улучшить то, что было написано несколькими месяцами ранее.

    Но если в рамках рефакторинга программист коммитет больше 20 файлов за раз, то есть вариант что он не видит всей картины, поэтому пилит "супергибкую архитектуру". В этом случае, можно сесть вместе с разработчиком и составить майндмеп всех элементов будущей системы и связей между ними. Это будет полезно как для разработчика, так и для менеджера проекта.
    Ответ написан
    5 комментариев
  • В чем концептуальный смысл ухода с jQuery на более современные front end инструменты?

    Выгода от использования Vue в сравнении с jquery заметна уже после того, как на атрибут disabled кнопки в форме влияет 2 и более условий, не говоря о состоянии других элементов. Если отображение ваших элементов на странице не зависит от состояния других объектов, то значит вам и правда не нужны фреймворки. Они требуются, если вы пилите нечто более-менее динамичное.
    Ответ написан
    Комментировать