Есть еще одна распространенная ошибочка: установив SDK Android не в домашнюю папку пользователя, запустить эмулятор будет невозможно, будет писать об отсутствующем образе системы. Т.е. в AVD все создается нормально, а при запуске — облом.
Лечится путем создания линка на папку с установленным SDK из директории домашней папки пользователя (mklink /d).
Проблема использование Mongo или CouchDB заключена в том что для их нет у хостеров виртуального хостинга. Покупать VPS и заниматься администрированием на ламерском уровне не хочется.
По поводу хлебных крошек в любом из вариантов построения дерева не обойтись одним запросом, собственно здесь есть parent_id по которому можно подняться до нужного уровня.
В общем о рекламе речь не идет. Речь идет о идее. Просто разработчику иногда необходимо понять то что он делает имеет здравый смысл или нет. Кроме как таким образом сделать это трудно. По поводу отсутствующих комментариев — согласен. Однако для подробного описания необходимо много больше, чем я написал. А для оценки идее — вполне. Если идея интересна, то буду дальше расписывать реализованные механизмы.
Если принять во внимание «достаточно статические структурированные массивы данных», т.е. не требующие постоянного таскания их из базы, то файловое кэширование позволяет получиь достаточно неплохие результаты по скорости доступа — как на статичном html. Тормозить будут только frontend скрипты.
Весь необходимый интерактив в виде комментариев и иже с ним — то они лежат в отдельных таблицах и на отображение самих данных не влияют.
А это не попытка пихать пхп везде, это попытка расширить возможное применение знаний за пределы устоявшегося. Согласитесь все прикладные задачи можно разделить на ту или иную работу с БД, работу с вычислениями, работу с железом и игры. Вычисления и железо вряд ли для программистов php будут интересны по ряду причин. А вот всевозможные БД — почему бы и нет. Кроме того блязящаяся облачность и Google OC точно сдвинет приоритеты.
К примеру локальный DocuWiki, или реплика web проекта с чем-нибудь полезным для локального использования. В общем, в принципе есть зачем. Но может у кого есть идея, но не было решения.
Самый больной вопрос: гигобайтные tiff чем лучше в JPG конвертировать?
С логикой приложения не так страшнно, опыт есть, а вот такая конвертация, да еще на уровне процесса или сервиса пугает.
Недавно сталкивался с необходимостью обработки нажатий. В проекте используется jQuery. Искал плагины. Но в итоге решил воспользоваться стандартными средствами jQuery (http://docs.jquery.com/Events/keypress). Ибо подгрузка дополнительных библиотек дело все же сомнительное, т.к. их и так уже много используется. Конечно есть оптимизаторы и слияние в единый зазипованый файлик, но в живом проекте всегда приходится что-то править и дописывать. Каждый раз сливать JS-ы не всегда удобно. Понятно, что есть функции, которых в стандартном keypress не хватит, но для стандартных задач, мне кажется вполне достаточно.
Да, API у них есть, по использованию сервиса GoogleMaps на своем сайте, однако изобразительный контент не карты. Грубо говоря, нужен движок Google для своего контента. Хотя читая комменты, пока, склоняюсь к Silverlight Deep Zoom.
Согласен, все можно запланировать. Однако, я несколько о другом: когда начинаешь творить (программирование тоже к этому относится я считаю), когда «поперло», что называется, очень трудно остановится, и встать из-за компа часов через 6-8 — обычное дело. Вдохновение в план не всунешь, ибо материя уж больно эфемерная.
Согласен, название не удачное, да, в общем-то, и не отражает сути того, ради чего все и замышлялось. Всегда приходится учитывать желание заказчика, согласен. Больше интересовал, пожалуй, вопрос, а надо ли пытаться реализовать функционал для использования его самим заказчиком или лучше самим в случае чего пару скриптов на PHP набросать.
Лечится путем создания линка на папку с установленным SDK из директории домашней папки пользователя (mklink /d).
По поводу хлебных крошек в любом из вариантов построения дерева не обойтись одним запросом, собственно здесь есть parent_id по которому можно подняться до нужного уровня.
Весь необходимый интерактив в виде комментариев и иже с ним — то они лежат в отдельных таблицах и на отображение самих данных не влияют.
С логикой приложения не так страшнно, опыт есть, а вот такая конвертация, да еще на уровне процесса или сервиса пугает.