Из недавнего прошлого. Средней величины компания, хочет новый лендинг. Пытаюсь набросать бриф. В каждой итерации постоянно появляются всё новые и новые крупные фичи. При этом всё время звучит один и тот же вопрос «а сколько всё это будет стоить». На что я постоянно отвечаю «давайте сперва определимся, что вы хотите в виде ТЗ».
На 3-4 итерации меня спросили «а у вас есть рыба ТЗ или может откуда-то это можно скачать?», на что я сидел с выражением «рука-лицо» и ответил сухо «такого не может быть в принципе» и, понимая неизбежность нечеловеческих затрат времени на детализацию ТЗ, посоветовал им нанять аналитика, если у них нет квалифицированного человека, готового ответственно отнестись к проектированию.
Тем не менее, через месяц мне прислали содранное откуда-то замшелое ТЗ со своими правками, в которых всё равно ничего не было написано про те фичи, о которых мне рассказывали ранее. Зато было пожелание поддерживать IE 5.0, Firefox 1.0, Chrome 5.0 и какой-то набор диких разрешений мобильных устройств и адаптивную верстку, при этом имея только один макет дизайна под 1280px.
На это мне ничего не оставалось сделать, как назвать с потолка сумму денег, окупившую бы весь гемор по этому ТЗ и серию вопросов «я правильно понял, что вы хотите то-то и то-то?». Там ошалели от стоимости. И конечно же оказалось, что мало чего нужно было, но дополнительной инфы так и не предоставили.
Как итог, я написал от всего сердца, что далее есть только одна возможность общения со мной на тему ТЗ — платить деньги за его составление. Либо не общаться со мной, а заплатить их аналитику, как делают все нормальные люди. В противном случае не смогу считать себя профессионалом, за результат и претензии не отвечаю, но деньги возьму вперед. Больше ответов пока не последовало.
Ах да. Вся это котовасия длилась полгода.
Ничего нового не узнал.
Главный вопрос так и остался открытым: как не ошибиться в предварительной оценке стоимости.
Я решил, что в первую очередь надо согласовать ТЗ. Только после этого можно говорить о коммерческом предложении.
Конечно всегда найдутся еще грабли)
Но я хочу сказать, что если кто-то решает задачу из статьи прямо как написано, то это архитектурно не правильно. Задача веб сервера в том, чтобы как можно быстрее отработать request-response, а не мудрить сложную логику по вытягиванию данных и разруливанию race condition. Зачем множить это на кучи потоков, когда достаточно выделить лишь один, который будет заниматься конкретной задачей по актуализации данных в кеше.
Пример мне кажется немного надуманным, действительно правильнее использовать под такую задачу крон. Но с академической точки зрения очень хорошая иллюстрация грабель.
Более уместным был бы пример, как мне кажется, тяжелых запросов в базу данных, которые зависят от данных профиля пользователя (например выдача новостей по интересам)
Как показал мой личный опыт, смена порта sshd на нестандартный на порядки уменьшило в логах auth.log кол-во записей. Это помогает отсеивать не целенаправленные атаки.
Пробовал на Cubietruck. Тяжеловато ему было, но работало кое-как. Главное в веб-клиент не лазить к фоткам, миниатюры делать очень ресурсоёмко.
Когда я понял, что Owncloud не игрушка, а вполне нормальное приложение, то продал кубик и купил «кубик» побольше — HP Microserver Gen8
Где-то полгода назад тоже перешел на Owncloud. Очень доволен.
По своему опыту могу заметить, что php очень желательно ставить версии >= 7.0, прирост скорости в веб-клиенте в раза 2 точно по отношению к 5.6.
В статье немного не хватает пункта про организацию бекапа, впрочем об этом расписано и в официальной документации.
Почитал бегло комменты. Зачем IDS и какие-то нагромождения? Надо просто понять, что есть юзер, под которым выполняется php, допустим www-data. А есть владелец файлов и директорий проекта на сервере. Это не одно и то же.
Что нужно сделать:
1) добавить владельца в группу www-data;
2) выставить права на файлы и каталоги такие, чтобы владелец мог читать и писать, а группа была www-data и могла только читать;
3) определиться с каталогами, где требуются права записи для php и добавить туда права записи группе www-data.
Всё. Даже если будет дырка в пхп коде, то записать что-либо злоумышленник не сможет, не зная файловой структуры проекта. Даже если он узнает, куда можно положить свой скрипт и положит, то прав на изменение основных файлов проекта у него не будет, как и доступа к уязвимым файлам системы.
До сих пор помню хохму, когда кто-то прислал шаблонное письмо со словами, что «вы нам интересны, но прежде чем встретиться пройдите простой тест пхп на мамбе». Мало того, что данный тест проходить сениору в западло, о чём я прямо и написал, так еще и облажались, указав всех кандидатов в СС. Получилась мини-дискуссия :)
А мне идея понравилась с логгированием с помощью AOP.
Когда дофига серверной логики наворочено, то логгировать приходится много и код разрастается прилично от строк, вызывающих один лишь логгер.
Из недавнего прошлого. Средней величины компания, хочет новый лендинг. Пытаюсь набросать бриф. В каждой итерации постоянно появляются всё новые и новые крупные фичи. При этом всё время звучит один и тот же вопрос «а сколько всё это будет стоить». На что я постоянно отвечаю «давайте сперва определимся, что вы хотите в виде ТЗ».
На 3-4 итерации меня спросили «а у вас есть рыба ТЗ или может откуда-то это можно скачать?», на что я сидел с выражением «рука-лицо» и ответил сухо «такого не может быть в принципе» и, понимая неизбежность нечеловеческих затрат времени на детализацию ТЗ, посоветовал им нанять аналитика, если у них нет квалифицированного человека, готового ответственно отнестись к проектированию.
Тем не менее, через месяц мне прислали содранное откуда-то замшелое ТЗ со своими правками, в которых всё равно ничего не было написано про те фичи, о которых мне рассказывали ранее. Зато было пожелание поддерживать IE 5.0, Firefox 1.0, Chrome 5.0 и какой-то набор диких разрешений мобильных устройств и адаптивную верстку, при этом имея только один макет дизайна под 1280px.
На это мне ничего не оставалось сделать, как назвать с потолка сумму денег, окупившую бы весь гемор по этому ТЗ и серию вопросов «я правильно понял, что вы хотите то-то и то-то?». Там ошалели от стоимости. И конечно же оказалось, что мало чего нужно было, но дополнительной инфы так и не предоставили.
Как итог, я написал от всего сердца, что далее есть только одна возможность общения со мной на тему ТЗ — платить деньги за его составление. Либо не общаться со мной, а заплатить их аналитику, как делают все нормальные люди. В противном случае не смогу считать себя профессионалом, за результат и претензии не отвечаю, но деньги возьму вперед. Больше ответов пока не последовало.
Ах да. Вся это котовасия длилась полгода.
Главный вопрос так и остался открытым: как не ошибиться в предварительной оценке стоимости.
Я решил, что в первую очередь надо согласовать ТЗ. Только после этого можно говорить о коммерческом предложении.
Но я хочу сказать, что если кто-то решает задачу из статьи прямо как написано, то это архитектурно не правильно. Задача веб сервера в том, чтобы как можно быстрее отработать request-response, а не мудрить сложную логику по вытягиванию данных и разруливанию race condition. Зачем множить это на кучи потоков, когда достаточно выделить лишь один, который будет заниматься конкретной задачей по актуализации данных в кеше.
Более уместным был бы пример, как мне кажется, тяжелых запросов в базу данных, которые зависят от данных профиля пользователя (например выдача новостей по интересам)
Я воткнул старенький хард на 500гб в сервачок и ежедневно rsync-аю /data + дампаю БД.
Когда я понял, что Owncloud не игрушка, а вполне нормальное приложение, то продал кубик и купил «кубик» побольше — HP Microserver Gen8
По своему опыту могу заметить, что php очень желательно ставить версии >= 7.0, прирост скорости в веб-клиенте в раза 2 точно по отношению к 5.6.
В статье немного не хватает пункта про организацию бекапа, впрочем об этом расписано и в официальной документации.
Что нужно сделать:
1) добавить владельца в группу www-data;
2) выставить права на файлы и каталоги такие, чтобы владелец мог читать и писать, а группа была www-data и могла только читать;
3) определиться с каталогами, где требуются права записи для php и добавить туда права записи группе www-data.
Всё. Даже если будет дырка в пхп коде, то записать что-либо злоумышленник не сможет, не зная файловой структуры проекта. Даже если он узнает, куда можно положить свой скрипт и положит, то прав на изменение основных файлов проекта у него не будет, как и доступа к уязвимым файлам системы.
3. Я бы с удовольствием перенес в приложение, но это уже сделать практически нереально, тем более тестов нет.
А мне идея понравилась с логгированием с помощью AOP.
Когда дофига серверной логики наворочено, то логгировать приходится много и код разрастается прилично от строк, вызывающих один лишь логгер.