Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (5)

Наибольший вклад в теги

Все теги (22)

Лучшие ответы пользователя

Все ответы (27)
  • Какой способ подсчета строк быстрее и тратит меньше ресурсов SQL или PHP?

    @FernandoErrNando
    В таких случаях всегда такие вычисления перекладывают на БД, за 1 запрос ты получаешь ответ и возвращаешь его в качестве результата.
    В случае, если ты попытаешься получить записи для подсчета в PHP, то на больших выборках велика вероятность получить слишком большой массив данных, который не поместится в память, отведенную под PHP, не говоря уже о времени перебора данных.
    Ответ написан
    Комментировать
  • Если ли онлайн эмуляторы, как будет отображаться сайт во всех браузерах всех ОС?

    @FernandoErrNando
    Есть ещё browsershots.org, разные браузеры под Винду, Линукс и Мак
    Ответ написан
    Комментировать
  • Как самостоятельно оценивать объем работы и стоимость разработки?

    @FernandoErrNando
    обычно есть 2 пути:
    1. Оценка по фикс-прайсу
    2. Или Time&material.

    Первый путь начинается с анализа ТЗ, конечно же. Иногда, у заказчика есть какое-то описание в виде текстового файлика, мокапа, дизайна или ещё чего-нибудь. Если же нет, то тебе придется как-то формализовать его хотелки, перевести в понятный вид и написать тз самому, не для него, а для себя прежде всего. В нем ты описываешь весь функционал, который требуется, поведение пользователей, примерные нагрузки и т.д.
    Чем детальней написано тз - тем лучше.
    Например:
    Плохое ТЗ: В приложении можно авторизоваться через email/соцсети.
    Хорошее ТЗ: В приложении можно авторизоваться через email и соцсети facebook, vk, instagram. Пользователь может проходить авторизацию через любую соцсеть, при этом при авторизации через ещё непривязанную соцсеть мы должны обновлять данные пользователя.

    Дальше ты разбиваешь ТЗ на отдельные части, которые ты можешь оценить.
    Например:
    Авторизация по email: 2-3ч + 3-5 на каждую соцсеть.
    На те вещи, которую ты знаешь и много раз делал закладываешь разброс поменьше, то что не делал - побольше. НА интеграции с третьесторонними сервисами типа соц.сетей, платежных систем, закрытых API, невнятно описанных вещей в ТЗ и т.д. делаешь большой рейндж, т.к. велик риск проблем с доступами, сложностей получения, неактульных документаций и прочим. Если что-то непонятно, лучше спросить у заказчика заранее и описать возможные проблемы, возможно, вы найдете другое решение.

    В конце концов у тебя получится 2 оценки - оптимистичная и пессимистичная. Можно ещё добавить какой-нибудь коэффициент, на который надо умножить, если твои оценки обычно слишком оптимистичны ("да тут работы на 2 дня", а сидишь неделю) или наоборот, излишне пессимистичны ("мне надо месяц, а делаю за неделю").

    Далее ты понимаешь работа займет, к примеру 250-300 чч, умножай её на свою часовую ставку. вот ты и получил примерную стоимость работ. Не забудь прибавить стоимость всех материальных затрат, специфичных для (хостинги, доменное имя, спец. оборудование, доступ к платному АПИ).

    Также не забудь учесть, сколько ты сможешь работать, а то он может подумать, что это 250чч - это 1 месяц работы, а в реальности у тебя основная работа/семья/кошка и ты можешь дать только 100чч/месяц.

    2 путь сложнее:
    Заказчик любит менять концепцию, тз нет и не будет ему важно быстро тестировать свои идеи и что в итоге выйдет он плохо себе представляет - тогда ты просто ему озвучиваешь стоимость часа и сколько времени ты можешь ему уделить. Основные сложности - это то, что можно нагородить говнокода из-за постоянных изменений, и каждая дальнейшая правка будет занимать все больше времени, а рефакторинг в таком случае очень трудно продавить.
    Ответ написан
    Комментировать
  • Почему нельзя/можно писать бизнес-логику в sql?

    @FernandoErrNando
    Вам указывали недостатки, но, почему-то для вас "Всё минусы какие-то мутные (кроме зависимости от конкретной БД)".
    Давайте попробуем посмотреть повнимательнее:
    1. Сложность отладки и тестирования - в то время, когда я работал с такими приложениями была проблема с тем, что средства отладки были слишком неразвиты, зачастую приходилось пользоваться dbms_output и все, чтобы отладить процедуру. думаю, нормыльные даббагеры потом появились, но я уже к тому времени ушел. Как сейчас обстоит с этим в РСУБД?
    2. Затрудненная версионность - а разве не так? На больших проектах со множеством разработчиков это ещё как будет стрелять. Просто посмотрите как мучаются люди с данной проблемой https://habr.com/ru/articles/330662/, тогда как те, кто использует БЛ вне базы просто пользуются гитом
    3. Зависимость от конкретной СУБД. Вы уверены, что БД у вас всегда будет подходить под требования бизнеса на 10 лет? Что, если за 10 лет появятся задачи, которые лучше решать другими инструментами? А если появятся задачи которые можно решить только сторонними инструментами?
    4. "Ограниченные возможности языка" - можно ли решить все проблемы с помощь SQL/PL-SQL?
    5. Сложности с масштабированием/оптимизацией - здесь тоже намного сложнее все. Кэширование вы тоже на СУБД будете возлагать? Что будет, когда у вас серверов БД будет больше 1?
    6. Что насчет интеграций? Что будет, если вам надо будет ходить по АПИ в третьесторонний сервис? вы это тоже заложите в логику в БД?
    Ответ написан
  • Почему в апаче срабатывает только первый виртуалхост?

    @FernandoErrNando
    Директива NameVirtualHost в основном конфиге задана?
    Ответ написан
    1 комментарий

Лучшие вопросы пользователя

Все вопросы (11)