Местоположение
Россия, Свердловская обл., Екатеринбург

Достижения

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

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

Все теги (28)

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

Все ответы (24)
  • Могли бы вы поделиться хорошим техническим заданием на разработку сайта/веб-приложения?

    Хорошее техническое задание -- очень обтекаемый термин. "Хорошим" можно было бы назвать техническое задание, отвечающее некоторым требованиям. А вот уже эти требования в зависимости от масштаба разрабатываемого продукта, методологии разработки, заказчика/исполнителя и других факторов могут сильно отличаться.

    Так, например, если вы работаете с государственным или окологогосударственным заказчиком/исполнителем, весьма вероятно, вам придётся подготовить ТЗ в соответствии с требованиями ГОСТ-19 и 34 (в особенности ГОСТ 34.602-89 и ГОСТ 19.201-78), которые предполагают создание очень формальных и подробных документов.

    Если же вы работаете не по водопаду или подобным методологиям, а используете подходы Agile, весьма вероятно, что детальное и проработанное от общих вещей до самых мелочей ТЗ вам не подойдёт, так как оно не будет обеспечивать требуемую гибкость подхода.

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

    Резюмируя: определитесь с требованиями к ТЗ, а, отталкиваясь от них, уже можно искать какие-то варианты.
    Ответ написан
  • Принцип работы DNS сервера в локальной сети?

    Действительно, все DNS, как публичные, провайдерские, так и локальные выполняют одну функцию.

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

    Рабочие станции, обращаясь к вашему DNS, пытаются разрешить имя для ресурса. Здесь два варианта: либо это ресурс внутри домена и он отвечает клиенту, либо это внешний ресурс и нужно обращаться к вышестоящему серверу (рекурсивным запросом или напрямую).
    Вышестоящим сервером могут быть либо настроенные сервера пересылки (обычно DNS провайдера), либо корневые.

    Почему имеет смысл настроить DNS провайдера как сервер пересылки? По той же причине: они могут выполнять некоторые дополнительные функции как кэширование, которое сократит время запроса, так и географические привязки (местные узлы CDN крупных сервисов, например).

    В общем-то, структура DNS является древовидной и принципы работы сохраняются для более высоких уровней.
    Ответ написан
  • Как перезапускать службу в хр каждые 5 минут?

    cmd > services.msc > Диспетчер печати -- настраивайте тут: 5d963c122747d449132844.png

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

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

    Лаг (задержка, иногда пинг) -- время ожидания ответа, особенно сильно влияет при большом количестве последовательных соединений, каждое из которых будет ждать своего ответа. Например, при открытии сайта: ДНС-запрос, установка защищённого соединения, запрос контента, загрузка тела страницы, загрузка какого-нибудь скрипта, загрузка графики, загрузка данных на страницу каким-нибудь AJAX-запросом. Если лаг соединения будет 500 мс, то только на ожиданиях каждого из этапов мы в таком сценарии потеряем 3,5 секунды. А ведь количество нераспараллеливаемых запросов может быть на порядки больше. Часто так и бывает. Например, главная страница Тостера у меня грузится в 45 запросов, не все они последовательные, но всё же.

    Качество соединения тоже немаловажно. Если происходит потеря пакета, то в протоколах с обеспечением доставки, например, TCP, по которому и осуществляются HTTP-соединения, данные придётся запрашивать заново. А все остальные подождут, пока потерянный пакет всё-таки не придёт. А в худшем случае может произойти и обрыв соединения, который может привести вообще к необходимости полного рестарта всего процесса загрузки данных.

    Джиттер для просмотра сайтов не так важен, он сильнее будет влиять, например, на онлайновые игры.

    Проверяйте эти показатели.
    Ответ написан
  • Можно ли рассчитать стоимость системы без ТЗ?

    В похожей известной мне ситуации заказчик, заказав оценку стоимости у десятка различных исполнителей, получил разброс стоимости проекта от 400 тысяч до 32 млн рублей. (Заказчик в итоге отказался от проекта вообще).

    Не знаю, есть ли в такой ситуации вообще какое-то единственно правильное решение, но помочь вам могут методы оценки стоимости проекта, тот же самый PERT. В двух словах:
    Декомпозируйте задачи настолько, насколько это необходимо для того, чтобы их оценить хотя бы предварительно.
    Выполните, исходя из имеющегося опыта, оценку сроков получившихся задач по трём точкам: оптимистическую, наиболее вероятную, пессимистическую. В этих оценках постарайтесь учесть возможные риски.
    Вычислите ожидаемое время проекта на основании получившихся оценок, накиньте пару стандартных отклонений в плюс и минус: получите достаточно широкую вилку суммарного времени работы над проектом, но с высокой вероятностью включающей в себя то время, которое может получиться по факту.
    Умножьте получившиеся оценки на стоимость работы вашей команды (в час/день -- какую единицу при оценке сроков использовали), таким образом получите оценку стоимости проекта сверху и снизу. Презентуйте получившуюся вилку и скоуп проекта, который лёг в её основу, заказчику. Сужайте вилку на свой страх и риск.

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

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