ну если взять какие-то базовые кривовато работающие модули с кривым переводом и просто собрать в кучу, то конечно. в реальной жизни придется это все серьезно обрабатывать напильником, что явно не вписывается в $300 и 7 дней :))
P.S. если не ошибаюсь, тот же vote up/down спокойно двет голосовать за себя и не подозревает что есть какие-то сроки голосования. а попробуйте настроить userpoints, что-бы он давал роли после набора определенного количества поинтов, а потом добавьте пару новых ролей и посмотрите что произойдет.
не знаю как сейчас, но в свое время venividi.ru хостился на каком-то довольно хилом сервере, так-что я бы не стал сравнивать вот так, в лоб. тут недавно активно обсуждался widea.mobi. не знаю какая была на него нагрузка, но от "хабраэффекта" он помоему не загнулся.
кроме того, друпал имеет кеш и его можно научить в тяжелые минуты жизни не лазить в базу, а отображать некоторые не критичные блоки из кеша.
по поводу сборки сайта без умения программировать. с друпалом получается так, что за 20 процентов времени строится 80 процентов функционала. остальные 80 процентов времени идет на борьбу с тривиальными проблемами, которые, благодаря этой универсальности не так просто решить.
модули неплохо работают в накатаной колее, но стоит отойти на шаг в сторону и сделать что-то нестандартное, начинают лезть такие хитрые глюки, которые отловить в этой универсальной среде и в чужом коде, ой как непросто.
вывод: начиная какой-то более-мение не типовый проект, обзаведитесь, как минимум, дебагером. без него там делать нечего.
большое количество модулей действительно порождает бешенное количество запросов к базе. например: один модуль выгребает список пользователей, а другой идет по этому списку и для каждого пользователя обращается к базе и достает какую-то дополнительную информацию. тоесть делает то, что в своем коде можно было сделать одним запросом.
тут, как по мне, только один выход. собрать на базе модулей скелет, а потом просто переписывать и оптимизировать такие места, забыв о какой либо совместимости с новыми версиями. в любом случае для нетипового проекта вам не хватит стандартной функциональность и прийдется дописывать что-то свое.
голосовал за "не нужен", так-как не очень корректно вопрос поставлен. возможно в плашшетниках не помешал бы, но обычному ноуту, как по мне, вообще сенсорный экран не нужен.
и так вечно кто-то пальцем в экран ткнет вытирать потом, а так они на вполне законных основаних будут это делать :))
а еще можно придумть машину времени, накупить китайских электронных часов по 50 центов и полететь в прошлое. там продать часы и купить долларов по 63 копейки. 2-3 ходки и вуаля..
да никто не спорит. я просто не совсем разделяю восторг от ответа про kde. ну, потешил гиков. продемонстрировал, что отвечает на любые вопросы, при этом забыв ответить на те вопросы, ответы на которые ждал народ. прикольно. давайте еще на один срок выберем. возможно нас потешат предвыборной компанией под лозунгом "я креведко".
http://widea.mobi/node/119 см. третий комент
P.S. если не ошибаюсь, тот же vote up/down спокойно двет голосовать за себя и не подозревает что есть какие-то сроки голосования. а попробуйте настроить userpoints, что-бы он давал роли после набора определенного количества поинтов, а потом добавьте пару новых ролей и посмотрите что произойдет.
впервые картинка появилась наверное тут: http://www.makepizdato.ru/showthread.php…
кроме того, друпал имеет кеш и его можно научить в тяжелые минуты жизни не лазить в базу, а отображать некоторые не критичные блоки из кеша.
по поводу сборки сайта без умения программировать. с друпалом получается так, что за 20 процентов времени строится 80 процентов функционала. остальные 80 процентов времени идет на борьбу с тривиальными проблемами, которые, благодаря этой универсальности не так просто решить.
модули неплохо работают в накатаной колее, но стоит отойти на шаг в сторону и сделать что-то нестандартное, начинают лезть такие хитрые глюки, которые отловить в этой универсальной среде и в чужом коде, ой как непросто.
вывод: начиная какой-то более-мение не типовый проект, обзаведитесь, как минимум, дебагером. без него там делать нечего.
большое количество модулей действительно порождает бешенное количество запросов к базе. например: один модуль выгребает список пользователей, а другой идет по этому списку и для каждого пользователя обращается к базе и достает какую-то дополнительную информацию. тоесть делает то, что в своем коде можно было сделать одним запросом.
тут, как по мне, только один выход. собрать на базе модулей скелет, а потом просто переписывать и оптимизировать такие места, забыв о какой либо совместимости с новыми версиями. в любом случае для нетипового проекта вам не хватит стандартной функциональность и прийдется дописывать что-то свое.
P.S. картинка рисовалась давно и, по идее, никакого отношения к опере изначально не имела :)
http://search.freelancer.com.ua/go-30899…
ему и так тяжело, а сейчас все туда попрут :)
http://www.onliner.ua/events/companies/k…
год прожил в 15-ти минутах от этого музея. так и не собрался сходить.. можно включить в программу следующей хабрасходки :)
http://whateverlife.com/profile/?layout=…
http://whateverlife.com/profile/?layout=…
даже и не знаю что тут сказать...
и так вечно кто-то пальцем в экран ткнет вытирать потом, а так они на вполне законных основаних будут это делать :))