Очень неплохо, только немного непонятно почему не использовать обычный WebRequest для получения контента, а затем уже вашу библиотеку для парсинга? Это немного отпугивает.
P.S. Заметил у всех рьяных защитников свободного софта один и тот же алгоритм поведения.
+ к теме, — в 3 предыдущих моих поста (видать не читая), — в карму. Спасибо! =)
Я согласен с тем, что должен быть выбор. Но рынок работает по принципу — спрос порождает предложение, если бы был большой спрос на ноутбуки с OEM линуксом, производители бы их активно предлагали, несмотря на все уловки microsoft. Улавливаете очевидный ответ?
Спроса видимо нет, а тот что есть у нас, формируется в основном не желанием использовать Linux,
а банальным нежеланием платить за Windows.
Выбор есть всегда, не нравиться проприетарный софт — используйте бесплатный.
Нехотите платить за OEM софт — подищите похожую модель.
Верите установка Windows может быть сложна для некоторых пользователей. Если вы молоды попросите ваших родителей установить ради интереса.
Про магазин точнее так — 1 хлеб платный, 2 хлеб можно своровать, 3 хлеб бесплатен вообще. Выбирайте, что вам угодно.
Вот вам к примеру про бесплатный хлеб, поставил последний убунту, хочу в интернет, интернет у меня через VPN, открываю «мастер подключения», а он мне говорит, что пакеты для VPN доступа должны быть скачены с интернета.
Парадокс, для выхода в интернет, мне нужен интернет.
Всё это конечно хорошо, но кроме 10 млн гиков есть 6.4 млрд человек которых вполне устроит Windows или Mac OS. Им не хочеться устанавливать \ выбирать \ разбираться \ перекомпилировать, всё что им надо — включить и работать. Пока будут такие пользователи будет и Windows OEM.
У нас была задача добавить 3D-Pie для конкретного заказчика и по его желанию, рассуждения на тему подходит \ не подходит оставлю Лебедеву. Жираф большой — ему видней =)
Ну в реальном проекте он оформлен естественно как компонент. Здесь я разместил первоначальную версию прототипа, NDA понимаешь =). Желающие могут прилепить поверх декоративную маску к примеру.
Так как уж Вы процитировали меня в своём топике, выскажусь.
«Мёртвый код»? Сударь, ваши PHP скрипты уже хостятся в огромной матрёшке «мёртвого кода» ( ОС -> Вебсервер -> PHP интерпритатор -> СУБД ) из «возможностей» которых используеться 2-3%. Может тогда резонно свою ОС написать, под сайт?
Я не могу сейчас точно сказать как решена проблема ускорения парсинга PHP, просто потому, что им не занимаюсь, но на 99% уверен, что продукты Zend'а решают эту проблему, прогоните код через оптимизатор и сравните результаты. Что касается .NET и Java описанная вами «проблема» для них вообще не актуальна.
Увеличение быстродействия — очень спорный момент, без тестов ничего не говорит.
Все ваши плюсы можно без мазохизма имплементировать классическим ООП.
Скину ка я сюда полную версию минусов с прошлого поста:
— IDE работают с файлами
— исходники это файлы, в итоге с ними можно делать любые файловые операции
— поддержка, наверняка человек пришедший после вас на такой проект сочтёт вас идиотом
— производительность, в большинстве случаев скрипты \ рантаймы могут применять какие-либо оптимизации, включая кеш, а ваши BLOB'ы уж никак сюда не впишуться
— Распостранение, ох некрасиво таскать SQL дампы туда — сюда
— Безопасность, прямой код инжекшн в случае проблем
— Бекап, представляете, бывает так, что их не делают, и тогда любые ваши «кастомизации» on site коту под хвост если сломаеться база
— Отладка отвратительна
— Нормальная поддержка ОПП, — не возможна
— Очень вероятны скрытые дефекты при работе с shared statеом
— Eval ВСЕГДА дефакто будет медленее обычного выполнения
— Версии \ бранчи \ мерджи \ итерации не возможны
— Runtime migration, при переходе на новый рантайм ошибки совместимости не будут выловлены вовремя
К своему сожалению, я не знаком с DSL Boo, в СУБД вполне нормально хранить к примеру конфигурацию, даже в ХМL формате. Но категорически противопоказано хранить непосредственно исполняемый ход или его производные.
То есть к примеру, если Вам как-то удастся разместить workflow оперирующий бизнес объектами в СУБД, — это нормально, так как это всего лишь метаданные. А мета-информация, — это не код.
Я против хранения любого кода в СУБД, кроме возможностей предоставляемых самими СУБД.
SQL CLR — сколько угодно. БД — база данных, а не база кода =) Каким боком сдесь Lua я не понял.
— Отладка отвратительна
— Нормальная поддержка ОПП, — не возможна
— Очень вероятны скрытые дефекты при работе с shared statеом
— Eval ВСЕГДА дефакто будет медленее обычного выполнения
— Версии \ бранчи \ мерджи \ итерации не возможны
— Runtime migration, при переходе на новый рантайм ошибки совместимости не будут выловлены вовремя
Если хорошо подумать, можно найти ещё минимум 10 причин, по которым этого не стоит делать.
Идея хранить код в СУБД плоха хотя бы тем, что СУБД изначально расчитана на хранение данных. Это так сказать отделение зерён от плевел.
Из очевидных минусов:
— IDE работают с файлами
— исходники это файлы, в итоге с ними можно делать любые файловые операции
— поддержка, наверняка человек пришедший после вас на такой проект сочтёт вас идиотом
— производительность, в большинстве случаев скрипты \ рантаймы могут применять какие-либо оптимизации, включая кеш, а ваши BLOB'ы уж никак сюда не впишуться
— Распостранение, ох некрасиво таскать SQL дампы туда — сюда
— Безопасность, прямой код инжекшн в случае проблем
— Бекап, представляете, бывает так, что их не делают, и тогда любые ваши «кастомизации» on site коту под хвост если сломаеться база
+ к теме, — в 3 предыдущих моих поста (видать не читая), — в карму. Спасибо! =)
Спроса видимо нет, а тот что есть у нас, формируется в основном не желанием использовать Linux,
а банальным нежеланием платить за Windows.
Нехотите платить за OEM софт — подищите похожую модель.
Верите установка Windows может быть сложна для некоторых пользователей. Если вы молоды попросите ваших родителей установить ради интереса.
Про магазин точнее так — 1 хлеб платный, 2 хлеб можно своровать, 3 хлеб бесплатен вообще. Выбирайте, что вам угодно.
Вот вам к примеру про бесплатный хлеб, поставил последний убунту, хочу в интернет, интернет у меня через VPN, открываю «мастер подключения», а он мне говорит, что пакеты для VPN доступа должны быть скачены с интернета.
Парадокс, для выхода в интернет, мне нужен интернет.
//LinearGradientBrush brush = new LinearGradientBrush(
// new Point( x, y + height + sideHeight + 100),
// new Point( x, y — (height/2)),
// Color.Black,
// Color.Transparent
// );
//e.Graphics.FillPath(brush, shadowSides1);
Попробуйте так если хотите, я и вправду не заметил лишние строки.
«Мёртвый код»? Сударь, ваши PHP скрипты уже хостятся в огромной матрёшке «мёртвого кода» ( ОС -> Вебсервер -> PHP интерпритатор -> СУБД ) из «возможностей» которых используеться 2-3%. Может тогда резонно свою ОС написать, под сайт?
Я не могу сейчас точно сказать как решена проблема ускорения парсинга PHP, просто потому, что им не занимаюсь, но на 99% уверен, что продукты Zend'а решают эту проблему, прогоните код через оптимизатор и сравните результаты. Что касается .NET и Java описанная вами «проблема» для них вообще не актуальна.
Увеличение быстродействия — очень спорный момент, без тестов ничего не говорит.
Все ваши плюсы можно без мазохизма имплементировать классическим ООП.
Скину ка я сюда полную версию минусов с прошлого поста:
— IDE работают с файлами
— исходники это файлы, в итоге с ними можно делать любые файловые операции
— поддержка, наверняка человек пришедший после вас на такой проект сочтёт вас идиотом
— производительность, в большинстве случаев скрипты \ рантаймы могут применять какие-либо оптимизации, включая кеш, а ваши BLOB'ы уж никак сюда не впишуться
— Распостранение, ох некрасиво таскать SQL дампы туда — сюда
— Безопасность, прямой код инжекшн в случае проблем
— Бекап, представляете, бывает так, что их не делают, и тогда любые ваши «кастомизации» on site коту под хвост если сломаеться база
— Отладка отвратительна
— Нормальная поддержка ОПП, — не возможна
— Очень вероятны скрытые дефекты при работе с shared statеом
— Eval ВСЕГДА дефакто будет медленее обычного выполнения
— Версии \ бранчи \ мерджи \ итерации не возможны
— Runtime migration, при переходе на новый рантайм ошибки совместимости не будут выловлены вовремя
То есть к примеру, если Вам как-то удастся разместить workflow оперирующий бизнес объектами в СУБД, — это нормально, так как это всего лишь метаданные. А мета-информация, — это не код.
Я против хранения любого кода в СУБД, кроме возможностей предоставляемых самими СУБД.
SQL CLR — сколько угодно. БД — база данных, а не база кода =) Каким боком сдесь Lua я не понял.
— Отладка отвратительна
— Нормальная поддержка ОПП, — не возможна
— Очень вероятны скрытые дефекты при работе с shared statеом
— Eval ВСЕГДА дефакто будет медленее обычного выполнения
— Версии \ бранчи \ мерджи \ итерации не возможны
— Runtime migration, при переходе на новый рантайм ошибки совместимости не будут выловлены вовремя
Если хорошо подумать, можно найти ещё минимум 10 причин, по которым этого не стоит делать.
Из очевидных минусов:
— IDE работают с файлами
— исходники это файлы, в итоге с ними можно делать любые файловые операции
— поддержка, наверняка человек пришедший после вас на такой проект сочтёт вас идиотом
— производительность, в большинстве случаев скрипты \ рантаймы могут применять какие-либо оптимизации, включая кеш, а ваши BLOB'ы уж никак сюда не впишуться
— Распостранение, ох некрасиво таскать SQL дампы туда — сюда
— Безопасность, прямой код инжекшн в случае проблем
— Бекап, представляете, бывает так, что их не делают, и тогда любые ваши «кастомизации» on site коту под хвост если сломаеться база
Зачем это вообще необходимо? Данные != Код
faiz.kera.la/2009/08/02/does-partitioning-improve-performance-for-sql-tables/