Нет, это не хамство. Я потом уже сообразил, что людям, не знакомым со мной лично это может показаться хамством. Я просто многое говорю в глаза.
По поводу уровня — я знаю много мужчин с высоким уровнем скиллов разработчика. И пока, к сожалению, ни одной женщины. Статистика.
При всём уважении. Если Вы хотите своими заявлениями поставить себя на один уровень с мужчинами в разработке приложений, то до этого момента можно было бы довести свои умения до ума. Ибо вёрстка с <br /> никуда не годится. И попробуйте походить на шейпинг. А пока — морская свинка.
Эх, вы меня просто с головой окунули в мир Полудня. А меня ведь только затянули рынок и потребление. Буду много думать теперь снова. Спасибо. Я уже было считал, что всё потеряно.
Тут получается такая же ситуация, как и недавно мы спорили с ребятами о приемлимости совместного использования UML и подхода Getting Real и agile практив в целом. Правда, там я был за uml, а они против :)
>B и если Котырев здесь habrahabr.ru/blogs/about_cms/22018/ не сочиняет, положение через несколько лет должно изменться.
Да мне кажется, всё равно в этом смысла немного. Технологию нужно использовать там, где она действительно необходима. А XSLT на данный моммент слишком тяжела, чтобы использовать её. Лучшим вариантом было бы формирование отображения на стороне пользователя, но неизвестно, когда браузеры в едином порыве это реализуют.
> Вроде никто особо не предлагает вынести XSLT на клиента.
Тут дело в том, что отличаться структура будет сильно, вплоть до выборки из БД, так что в любом случае структуры xml будут разными.
>Сейчас у каждой долбанной CMS свой долбанный шаблонизатор. Свобода на грани анархии.
XML, тем более с XSLT, достаточно сложен для понимания, а долбаные CMS стараются быть доступными для секретуток. Поэтому соревнуются в простоте.
>Каких интерфейсов? Программных или юзерских?
Я имел ввиду именно пользовательских, а конкретнее способы отображения информации для разных нужд или устройств.
По сути, css к этому стремится, но не структурно, а визуально, ту же принт-версию или pda версию можно получить, манипулируя css стилями, а что касается той же pda версии — то здесь необходимы уже серверные инструменты, исходя, даже, из необходимости оптимизации. И нужна ли эта свобода действий, если есть устоявшиеся рамки и правила в построении интерфейсов?
А я тут, кстати, подумал, а чем HTML или XHTML, по сути не данные? А чем CSS не стили? Получается та же свистопляска. И в принципе, используя XML-XSLT, мы окунаемся в море ограничений и частностей, которые ломают всю идеальную картину и мы приходим всё к тому же сумбуру, от которого пытались отрешиться.
Эх, давно я так не смеялся :) Только в рассказиках автора сходу чувствуется косноязычность какая-то. Поэтому с первых же строк рассказа японца стало ясно, что он просто прикалывается. Но очень смешно :)
Вот, кстати, да, я был не прав, конечно. Под Memcachedb я имел ввиду любую реляционную базу данных, способную хранить данные в памяти. Тот же MEMORY для mysql или TimesTen от oracle. Непосредственно Memcachedb сейчас сыроват, насколько я знаю. А статью я написать, к сожалению, не могу.
Нет, чаще всего в Memcachedb хранятся денормализованные поля и декартовы произведения таблиц. Нет смысла копировать базу в память. Но и не отдельные значения. Я говорю о том, что мемкэш нужен для хранения текущих значений некоторых параметров. Но хранить записи из базы там — черевато трудностями.
Спасибо, интересный подход. Только мне кажется, что использовать мемкеш для хранения структур данных — плохая практика. Если хотите кешировать данные из бд — лучше использовать специализированные базы, типа memcachedb. А мемкеш лучше использовать для хранения состояния системы в данный момент и быстрого доступа к данным, тяжело просчитываемым или труднодоступным, но в то же время требующим высокой скорости доступа.
А слив данных на постоянное хранение как осуществляется? То есть, я понимаю как, но этих возможностей не всегда достаточно. Например, какая-либо постобработка данных осуществляться будет в любом случае неким быстрым демоном.
Нет, я говорил о том же самом. Сходу всю поступающую информацию писать в базу не получится — база загнётся. Приходится её писать в память или на винчестер. А кто принимает её и пишет или кто её потом сбрасывает в бд — уже не так важно и зависит от необходимой пропускной способности всей системы. Я решил, что это демон на сях, а Вы — что скрипт пхп.
Не совсем понял, к чему этот комментарий. Чем сбрасывали? База в памяти — это хороший вариант, но я ту же картину и описал. В моём случае этим занимался демон.
Например, есть системы с таким потоком информации, когда невозможно всю поступающую информацию писать в базу данных. Пишется демон на си, который принимает всю эту информацию и выстраивает очередь, а затем уже медленно, но верно пишет из очереди в базу.
Эх, зря всё это. Подобная тяга к оптимизации не способствует производительности разработчика. Вместо того, чтобы нагружать сервер и клиент аяксом, лучше использовать server-push технологии, а для хранения и быстрого доступа к данным — memcached. Есть множество ситуаций, когда приходится писать на си/си++. Но то, что вы описали — не совсем те задачи.
По поводу уровня — я знаю много мужчин с высоким уровнем скиллов разработчика. И пока, к сожалению, ни одной женщины. Статистика.
>B и если Котырев здесь habrahabr.ru/blogs/about_cms/22018/ не сочиняет, положение через несколько лет должно изменться.
Да мне кажется, всё равно в этом смысла немного. Технологию нужно использовать там, где она действительно необходима. А XSLT на данный моммент слишком тяжела, чтобы использовать её. Лучшим вариантом было бы формирование отображения на стороне пользователя, но неизвестно, когда браузеры в едином порыве это реализуют.
Тут дело в том, что отличаться структура будет сильно, вплоть до выборки из БД, так что в любом случае структуры xml будут разными.
>Сейчас у каждой долбанной CMS свой долбанный шаблонизатор. Свобода на грани анархии.
XML, тем более с XSLT, достаточно сложен для понимания, а долбаные CMS стараются быть доступными для секретуток. Поэтому соревнуются в простоте.
>Каких интерфейсов? Программных или юзерских?
Я имел ввиду именно пользовательских, а конкретнее способы отображения информации для разных нужд или устройств.