Переписывайте новости своими словами, так безопаснее и для поисковиков лучше - уникальный контент, как-никак. В народе для такой работы популярны "добросовестные студентки филфака" :)
Ну, как только цены упадут, понятное дело, что сдавать придется...но до этого будут держать до упора.
Есть один нюанс в таком превращении: чтобы сдавать, нужен хотя бы минимальный ремонт, а инвестиционные бетонометры закупались в виде голых стен. В квартире, купленной для последующей продажи, делать ремонт - выброшенные деньги: покупатель не будет переплачивать за тот ремонт, который ему все равно захочется переделать. В том числе поэтому пока есть шанс выгодно продать, хотя бы призрачный, немногие согласятся на сдачу в аренду. Зато если цены упадут, многие уйдут в аренду: зачем фиксировать убытки, если можно не спеша сдавать, надеясь на повторное надувание пузыря через N лет. :)
хочу всех предупредить. не делайте не скажу что не скажу с кем. иначе будет не знаю что.
100k анонимных пользователей - это не highload..это ерунда!
Вот если это 100k зарегистрированных пользователей, общающихся, комментирующих и отправляющих материалы, тогда да
Первое друпал потянет даже на shared хостинге (с соотв. оптимизацией) а для второго может потребоваться целая ферма серверов. Проблемы будут в основном в базе: для друпала нет готовых решений сегментирования базы, поэтому масштабирование SQL возможно только по стандартной схеме master-slaves (что может упереться в производительность мастер сервера).
Вообще для проекта такого масштаба лучше нанять профессиональных разработчиков которые сделают custom решение на хорошем фреймворке типа Django.
В контексте существования ТЗ, и рабочей группы состоящей из >1 человек
Как известно, лучшее - враг хорошего, и я считаю перфекционизм абсолютно неуместен, если у проекта есть реальные сроки. Set your priorities straight.
Заказчик - вы сами ? Тогда и обсуждать нечего. Я думал речь идет о серьезных проектах. ;)
Что будет, если готовой функции нет ? Какой процент функциональности JQuery у вас реализован ?
malls, бизнес есть бизнес. Критерии простые: скорость разработки, стоимость разработки, поддержка, надежность. По всем этим параметрам велосипеды проигрывают. Конкурс красоты кода каждый программист имеет возможность организовать на своих проектах, а в коммерческих решениях это последний фактор.
Вопрос не том, чтобы мочь! Вопрос в том, чтобы хотеть! Человек, ценящий свое время и усилия, выберет фреймворк, чтобы не изобретать велосипед. Вы кажется, пытаетесь автоматически приписать всем пользователям фреймворков незнание языка и неумение программировать, а это очень смелая заява! 🚬 Давайте сравнивать программистов одного уровня квалификации.
Pandabeer добавил 07.12.2009 в 17:21
Ну да. А еще они юзают Django. Вот ламеры, нет чтобы на чистом питоне писать.
Весьма смелое заявление...
А теперь, вместо вашего примера, сравним 2 программистов: первый в течение 2-3 лет пишет свои костыли, а второй за это время изучает один из популярных фреймворков и использует его в своих проектах. Я думаю, второй будет и продуктивнее и востребованнее как специалист по нескольким причинам: код фрейморка оттачивается сообществом, содержит меньше багов (за счет тестирования сообщества), более поддерживаемый (специалисты по фреймворкам взаимозаменяемы). И я как заказчик выберу программиста, использующего существующие фреймворки а не собственные велосипеды (квадратность колес которых не всегда известна :D ).
Заказал EQ4 вместе с отказом от DS3000, плотно пообщавшись с саппортом на тему, как организовать плавный переезд, и платить за 2 сервера минимальное время. Вот результат:
1) Предложили как опцию заказ на EQ4 Flexipack и разовую плату 99 EUR. За эти деньги данные переносишь все равно сам, но переносят закрепленную подсеть со старого сервиса (основной адрес, закрепленный за сервером, не переносится). "Хорошо живете", подумал я, и отказался 😂
2) Информация, что отказываться нужно не раньше, чем за 30 дней, размещенная у них на сайте, не совсем корректна: скорее всего, она касается только случая отказа без переноса на новый сервис.
3) Заказ нужно делать заранее, учитывая свой pay period (можно узнать в pdf который присылают каждый месяц) и время подготовки сервера (нужно узнавать у саппорта). Если новый сервер вам успевают подготовить до окончания pay period старого сервера, делаем заказ, с коментарием, что сервер на замену старому. Тут самый тонкий момент - как согласовать отказ от старого сервера со своей процедурой переноса данных и обновления DNS ? Оказывается, очень просто. При переходе на новый серв, вам открывают возможность выбора даты отключения старого сервиса в любой день, и биллинг вам насчитает плату за ровно столько дней, сколько сервер проработал сверх pay period. Т.е. если новый сервер вам поставили 18 числа, pay period до 19 числа, от старого сервера можно отказаться 25го и заплатить сверх только за (25 - 19) дней. Это очень удобно, особенно после российских реалий, когда везде тебя пытаются кинуть 😎 Вообще суппорт терпиливо объяснял мне все нюансы, и было заметно, что мне хотят помочь, а не тупо отписываются. 🍻
