Честная и хорошая статья. Жаль, только то, что сайт имеет аудиторию в основном Linux-пользователей, которые уже почуяли эти плюсы и выбрали Linux для себя. Надо распространить ее на других ресурсах, с близкой тематикой, но с большей концентрацией Windows-пользователей. =)
В любом случае, за статью спасибо. Ссылки распространю, где смогу =)
Есть национальная не только РСУБД уже, но и NoSQL СУБД. Sedna. Это документо-ориентированная СУБД, хранящая документы в XML, использует XPath и Scheme-подобный язык для запросов. =)
Там безобразная политика всех. Однако шумиху поднимали не политики, и во главе шумихи Михалков, правда если не изменяет память — не он один. Но думаю, эта ветку можно закрывать, ибо уже флуд пошел )
Идеи идеями… Да только его идеи далеко зашли.
По моему мнению, платить налог за потенциальную, а не фактическую информацию — глупо. Страхи сбываются — налог на воздух. А с учетом того, что дело пошло дальше болванок — то это уже похоже на маразм. Платить налог за любую технику, которая имеет возможность воспроизводить мультимедиа — та же плата за воздух. Хотя по этому поводу и в частности про маразм Михалкова сказано много, так что не буду повторять, ибо всем этим пестрил интернет некоторое время назад. )
Я говорил конкретно про Cloud Foundry. По сути, вы можете использовать Cloud Foundry для создания своего облака, и так же как они продавать вычислительные мощности. Я имел ввиду это. А остальные продукты — ну тут никто не спорит, что они гребут на этом деньги. В конце концов — это основа их бизнеса.
Хм. Ну по масштабу может и такое. Но я как понял, у Red Hat будет Java-ориентированный сервис? Просто как я вник в идею VMWare Cloud Foundry — это мало того, что открытая платформа, она еще и нацелена на постоянное расширение спектра платформ для деплоинга. Ну я имею ввиду языков, фреймворков и прочего прочего.
А вот как у Red Hat с этим — не знаю. Могу и ошибаться.
Кстати, спасибо за ссылку )
И по большому счету, VMWare не стремится создать поприетарную систему, или завязанное на них облако. Оно будет развиваться по открытой модели, любой желающий сможет развернуть такое облако где ему надо, вплоть до предоставления образа, для разворачивания на локальном компьютере (для разработчиков). Плюс, облако представляет собой платформу, а не инфраструктуру, что дает большие преимущества в развитии CloudFoundry.
Ну а так, по поводу их сбоя. Они пока в бете, и говорить о сбоях как о чем-то серьезном, пока рано.
Ну как переводится framework, это чуть другое. Суть в том, что несмотря на то, что ты предоставляешь удобные средства для использования твоей идеи, ты не предоставляешь удобных средств для разработки приложения в целом. То есть, одному потянуть хорошую альтернативу к примеру уровня Django/Symfony или Rails — грубо говоря трудно, и на это очень много времени надо.
То есть, это грубо говоря, все равно приведет к написанию большого количества кода для реализации другой части функционала. )
Тогда не лучше ли свои наработки реализовать на базе существующего фреймворка? В виде форка или плагина, а многие популярные фреймворки это позволяют делать легко )
В общем я не против идеи, и поддерживаю. Просто думаю насчет целесообразности появления еще одного фреймворка, против целесообразности расширения существующих )
Я высказал свое мнение, и как оно более привлекательно выглядит. Если ему нравится, он может делать как хочет. Я же не принуждаю его делать по другому. Или высказывание своего мнения — это не кафильфо?
Ну и кроме того. Блоки в зависимости от страницы могут меняться. Гораздо лучше их контролировать на стороне сервера, и использовать кэширование.
Я бы был рад, если бы был удобный плагин, в виде к примеру автоматического dispatcher'а.
Объясню более конкретно. Мы храним «активные» DOM-элементы (то есть те, которые должны выполнять какие-то события). Пусть, это будут даже объекты того же jQuery. Мы просто где-то пишем функции для событий. А в одном месте, объявляем кортежи (элемент, событие, callback). И dispatcher автоматически инициализирует callbacks. То есть некая реализация синтаксического сахара, если можно так сказать. Но это явно не тянет на фреймворк с серверной стороной )
Не обижайся. Ни в коем случае не хочу отбить у тебя охоту что-то делать, или разрабатывать, но мне кажется ты изначально выбрал не совсем удачный путь реализации идеи. Дело в том, что:
1) Фреймворк реализовать трудно, а хороший — еще труднее. Прежде всего это куча взаимосвязанных компонентов, которые решают самые разнообразные задачи, и которые управляют пользовательским кодом. В твоем случае, на фреймворк это не тянет, по крайней мере на серверной стороне.
2) Задачи бывают разные. Идея хороша. Но HTML5 уже делит страницу на области. Во-вторых, реализация страницы может быть самой разнообразной.
То есть, если ты хочешь воплотить идею — то более удачный вариант — это плагин к библиотеке (подчеркиваю к библиотеке JS). То есть, сделать не код, который будет управлять пользовательским кодом, а код, который можно использовать в своих целях.
Реализовать блоки или подобное — для разных приложений требования могут быть совершенно разные. Ведь никто не мешает взять к примеру Flask, который будет выдавать данные в JSON. А на клиенте написать js-приложение, которое будет обновлять содержимое посредством AJAX и запрашивать нужные данные у сервера. Что это нам дает? Это дает полную, подчеркиваю, полную свободу в выборе фреймворка: будь то Symphony, Sinatra, Flask или Pylons, RoR или Django, или вообще самописное приложение с нуля. Мы свободны. Мы так же свободны в реализации клиентской стороны, свободны, и можем делать так, как надо нам. А твоя библиотека могла бы предоставить быстрый интерфейс для дергания обновлений, или вызова callbacks для тех, или иных действий с DOM элементами.
Надеюсь, я смог донести свою мысль )))
Кстати. Если менять управление для одного игрока, то клавиши для второго не меняются. К примеру, если в дефолте поменять у первого игрока «Огонь» на пробел, то в режиме двух игроков при нажатии пробела стреляют оба игрока сразу )
Прикольная вещица. Только советую сделать передвижения исключительно по квадратам, как в танчиках. Просто на скоростном танке уж очень бывает сложно попасть в проемы между стенами )))
В любом случае, за статью спасибо. Ссылки распространю, где смогу =)
По моему мнению, платить налог за потенциальную, а не фактическую информацию — глупо. Страхи сбываются — налог на воздух. А с учетом того, что дело пошло дальше болванок — то это уже похоже на маразм. Платить налог за любую технику, которая имеет возможность воспроизводить мультимедиа — та же плата за воздух. Хотя по этому поводу и в частности про маразм Михалкова сказано много, так что не буду повторять, ибо всем этим пестрил интернет некоторое время назад. )
А вот как у Red Hat с этим — не знаю. Могу и ошибаться.
Кстати, спасибо за ссылку )
Ну а так, по поводу их сбоя. Они пока в бете, и говорить о сбоях как о чем-то серьезном, пока рано.
То есть, это грубо говоря, все равно приведет к написанию большого количества кода для реализации другой части функционала. )
Тогда не лучше ли свои наработки реализовать на базе существующего фреймворка? В виде форка или плагина, а многие популярные фреймворки это позволяют делать легко )
В общем я не против идеи, и поддерживаю. Просто думаю насчет целесообразности появления еще одного фреймворка, против целесообразности расширения существующих )
Я бы был рад, если бы был удобный плагин, в виде к примеру автоматического dispatcher'а.
Объясню более конкретно. Мы храним «активные» DOM-элементы (то есть те, которые должны выполнять какие-то события). Пусть, это будут даже объекты того же jQuery. Мы просто где-то пишем функции для событий. А в одном месте, объявляем кортежи (элемент, событие, callback). И dispatcher автоматически инициализирует callbacks. То есть некая реализация синтаксического сахара, если можно так сказать. Но это явно не тянет на фреймворк с серверной стороной )
1) Фреймворк реализовать трудно, а хороший — еще труднее. Прежде всего это куча взаимосвязанных компонентов, которые решают самые разнообразные задачи, и которые управляют пользовательским кодом. В твоем случае, на фреймворк это не тянет, по крайней мере на серверной стороне.
2) Задачи бывают разные. Идея хороша. Но HTML5 уже делит страницу на области. Во-вторых, реализация страницы может быть самой разнообразной.
То есть, если ты хочешь воплотить идею — то более удачный вариант — это плагин к библиотеке (подчеркиваю к библиотеке JS). То есть, сделать не код, который будет управлять пользовательским кодом, а код, который можно использовать в своих целях.
Реализовать блоки или подобное — для разных приложений требования могут быть совершенно разные. Ведь никто не мешает взять к примеру Flask, который будет выдавать данные в JSON. А на клиенте написать js-приложение, которое будет обновлять содержимое посредством AJAX и запрашивать нужные данные у сервера. Что это нам дает? Это дает полную, подчеркиваю, полную свободу в выборе фреймворка: будь то Symphony, Sinatra, Flask или Pylons, RoR или Django, или вообще самописное приложение с нуля. Мы свободны. Мы так же свободны в реализации клиентской стороны, свободны, и можем делать так, как надо нам. А твоя библиотека могла бы предоставить быстрый интерфейс для дергания обновлений, или вызова callbacks для тех, или иных действий с DOM элементами.
Надеюсь, я смог донести свою мысль )))