Но мне кажется в нетопах нету таких потребностей о которых пишете вы? К тому же по вашей же ссылке нрарод жалуется на аналогичные проблемы но с nVidia, так что похоже на глюки винды в перемешку с софтом.
Сижу уже несколько лет на открытых драйверах от AMD и радуюсь. А в следующем ядре так вообще VDPAU будет. :-) И OpenCL кое какой работает в отличии от Intel.
На открытых дровах AMD я спокойно прошёл SC2 почти на максимальных настройках.
Часто начинаешь понимать что в JS и объекты не нужны. :)
Прототипное наследование может даже в чём то хорошо но все разработчики интерпретаторов и JIT оптимизаторов орут, что именно из-за этого происходит проседание по скорости. Гугл вон даже из-за этого Dart начал делать.
Классическое ООП на классах не сильно сковывает руки (хотя есть такое) но зато даёт возможность написать в разы более производительных интерпретаторов/компиляторов.
К JS ещё есть к слову притензия… это постоянное создание объектов (буквально на каждый чих да и ещё с замыканием), что приводит к фрагментированию памяти, увеличивает вероятность утечек и прочее.
Всё чаще начинают писать тяжёлое ПО на JS (игры и т.д.) и все эти проблемы вылезают. В итоге мы видим всякие Float32Array и прочие радости.
Тем не менне, 4 июля заработала начальная заставка игры. Хотя она из себя представляет набор роликов в формате Smacker, однако даже для этого было необходимо реализовать систему сообщений, обновление экрана, обработку клавиатуры, затемнение палитры, переход между сценами, в общем, написать почти 3 тысячи строк кода.
Как это мне напомнило когда мы портировали Ванргеров… хотя там у нас исходники были но то же не айс (безумная лапша на асемблере, DX5 и прочим)
А я недавно помучил AngularJS и понял что не моё. Если у вас много форм, всяких инпутов и в целом пофигу на скорость работы то наверное вещь хорошая. В моём случае оказалась слишком громоздкой (формочки маленькие, лаконичные тянуть ради них столько JS… ). Пользуюсь я в основном Dojo/Dijit.
Да, в PostgreSQL встроен очень гибкий полнотекстный поиск. По нашим тестам оно гораздо лучше работает того же сфинкса. К тому же очень просто настраивается и используется внутри СУБД. www.postgresql.org/docs/9.2/static/textsearch.html
PS по данным из солр вам нужно будет ещё вытащить данные из СУБД, а тут всё и сразу. :)
Нету у потока истории упругости… она больше похоже на разорванную во многих местах ткань. Где то и впрямь некоторые действия не изменят исхода но в некоторых даже маленький чих может перевернуть всё с ног на голову. Эта «упругость» неравномерна в пространстве и времени.
А так идея с котом Шрёдингера мне нравится больше… ветки создаются постоянно и мержить их нельзя.
Тому кому и Pylons,Ruby on Rails, Django требуется… «специально обученный по выбранной CMS админ » это если ваш публичный сайт полностью укладывается в концепцию CMS.
У вас идёт упор на СУБД, а вот есть проекты где основные разработки идут в области шаблонов и фронтенда и тут гораздо удобнее такого рода фреймворки.
А есть для PHP ORM уровня SQLAlchemy? Что бы в таких случаях не надо было опускаться до SQL? (а то СУБД бывают разные и хотелось бы иметь гарантированную прослойку)
И да я не люблю Ruby за его уродский синтаксис аля Perl. К счастью статистика говорит, что не я один такой. Так же я не люблю модные тренды когда за ними гораздо больше маркетинга чем действительно светлой мысли.
Нет. Просто этот проект всегда был чем то в роде хобби. Сейчас небольшой доход приносит и я рад. Но конечно надо капитально развивать, что бы сделать его реально массовым.
В целом для меня PHP и Ruby где то на одном уровне. Почему? Опытом общения. Может быть у меня не репрезентативная выборка… но всё же такое ощущение сложилось (человек 10 было). Люди были не адекватными в обще программистком плане (кажется люди со стороны пошли за модным трендом, что то аналогичное я видел и среди любителей Django в Python).
Мдя… на самом деле вам просто попадались отстойные прогеры. Нормальный программист и не наговнокодит и сделает быстро.
Вы случаем не искали исключительно Ruby программистов? Сейчас это хуже PHP… :( адекватных людей легче найти в Python стане.
На открытых дровах AMD я спокойно прошёл SC2 почти на максимальных настройках.
Прототипное наследование может даже в чём то хорошо но все разработчики интерпретаторов и JIT оптимизаторов орут, что именно из-за этого происходит проседание по скорости. Гугл вон даже из-за этого Dart начал делать.
Классическое ООП на классах не сильно сковывает руки (хотя есть такое) но зато даёт возможность написать в разы более производительных интерпретаторов/компиляторов.
К JS ещё есть к слову притензия… это постоянное создание объектов (буквально на каждый чих да и ещё с замыканием), что приводит к фрагментированию памяти, увеличивает вероятность утечек и прочее.
Всё чаще начинают писать тяжёлое ПО на JS (игры и т.д.) и все эти проблемы вылезают. В итоге мы видим всякие Float32Array и прочие радости.
Как это мне напомнило когда мы портировали Ванргеров… хотя там у нас исходники были но то же не айс (безумная лапша на асемблере, DX5 и прочим)
www.postgresql.org/docs/9.2/static/textsearch.html
PS по данным из солр вам нужно будет ещё вытащить данные из СУБД, а тут всё и сразу. :)
А так идея с котом Шрёдингера мне нравится больше… ветки создаются постоянно и мержить их нельзя.
У вас идёт упор на СУБД, а вот есть проекты где основные разработки идут в области шаблонов и фронтенда и тут гораздо удобнее такого рода фреймворки.
Вы случаем не искали исключительно Ruby программистов? Сейчас это хуже PHP… :( адекватных людей легче найти в Python стане.