Как монитор — один фиг, что thunderbolt display, что cinema display. Как док-станция для новых маков — хуже: нет firewire, ethernet и ..thunderbolt. Смысла брать вместо Cinema Display вместо Dell уже почти не вижу, разве что из-за дизайна. Мне кажется, за дизайн вполне разумно переплачивать, чтоб продуктом приятно пользоваться было — но только если основные функции не страдают. А тут получаем глянец вместо матового монитора (и без полезностей, которые есть у Thunderbolt Display).
Mox, +1. Ну и не факт, что у фрилансеров дешевле выйдет, а уж быстрее и качественнее-то точно автор напишет. Если не сработает, можно еще кого-нибудь из активных контрибьюторов попросить, если они там есть. Плюс трудозатраты тут неясно какие. Вы пишете, что сделать нужно мало, но от устройства библиотеки многое зависит, для оценки трудозатрат тоже квалификация требуется.
+1, Dell U2311H — отличная штука, матовый экран, хорошая подставка, клевая картинка, взял его пару недель назад вместо того Samsung'а на PVA, что был раньше, разница большая в пользу делла — никаких претензий. Разве что кабеля DisplayPort в поставке не было.
Только не понял, почему за модель на 24" вдвое больше просят, ну да, получше по мелочам, но 23" — imho гораздо более удачная покупка, лучше уж 2 на 23" взять вместо 1 на 24" тогда :)
> Для полноценной каждодневной работы 13 дюймовый (да еще и глянцевый) экран, конечно, не подходит.
Года 2 с половиной на 13" макбуке работаю, единственная машина, веб-разработка. Купил монитор, думал, понадобится, но нет, включаю максимум раз в неделю фильм посмотреть. Мышка тоже лежит в коробке, трекпад удобнее показался. Из плюсов — стимулирует код понятнее писать и на одной задаче концентрироваться. Из минусов — верстать на 13" неудобно, но я особо и не верстаю.
Не совсем так. Я о том, что неправильно считать, что поддержка работы без js делается для 0.1% людей с браузерами без js, она не для них делается. Она делается, чтобы увеличить надежность сайта и ускорить его загрузку (особенно для новых пользователей). От этого выигрывают потенциально все, а не 0.1% людей с явно отключенным js.
К tornado клиентская часть от socket.io прикручивается через tornadio (см. habrahabr.ru/blogs/python/112711/ ). Имеет смысл использовать вместо socket.io-node, если все остальное на питоне тоже написано (мой use case был — к джанге все это прикрутить с общей авторизацией).
Глянул сейчас на список пакетов в pear — то, что там есть, в питоне покрывается большей частью стандартной библиотекой. Т.е. PEAR — это скорее недоаналог питоньей стандартной библиотеки, который не ставится по умолчанию и которым никто не пользуется. В питоне же знание стандартной библиотеки — вещь обязательная для каждого программиста. А аналога pypi, выходит, и нет совсем?
В руби/питоне все проще. Ставится все одной командой, код не нужно искать где-то по интернету (все собрано более-менее в одном месте), более-менее решена проблема обновления кода, не нужно думать, куда его поместить и т.д. На том же pypi библиотек раз в 20-30 больше, чем в pear, сами гляньте. Вот вам и популярность php. К тому же библиотеки обычно меньше по размеру (можно прочитать код перед использованием) и узконаправленней (понятно, что делают), а разработка ведется открыто на bitbucket/github/googlecode — ясно, куда отправлять патчи, если что-то не так; можно сделать свой форк и ставить пакет из него, пока изменения не вольют в основную ветку. То, что пакеты не нужно скачивать вручную, а они ставятся отдельно (вне проекта обычно), стимулирует людей делиться своими наработками (меньше соблазн похачить прямо в проекте) => развитие идет быстрее. То, что на pypi нет модерации, стимулирует альтернативные версии пакетов, которые могут отличаться только интерфейсами, есть конкуренция, в которой побеждают (становятся более известными/популярными/о которых пишут и на которые ссылаются/у которых больше фолловеров на bitbucket/github) более удобные пакеты. Разработчики больше читают код друг друга, берут друг у друга хорошие идеи, больше делятся наработками, а не варятся каждый в своем болотце. За годы, которые существует pypi и bitbucket/github/launchpad, это дало все суммарно очень большой эффект, и экосистема в python/ruby теперь приятная, там есть культура совместной разработки. Дополнительный плюс от использования стороннего кода в проекте — снижается объем кода, который требуется поддерживать, и упрощается понимание проекта новыми разработчиками (т.к. часть кода может быть им уже знакома). В текущем проекте у меня, например, в зависимостях более полусотни библиотек, в пару десятков из них я отправлял патчи, десяток-другой — написанных мной, которые я выдрал из проектов (этого и предыдущих) и которые теперь используют и другие программисты (где-то 20тыс скачиваний только с pypi суммарно). И так в ruby/python делают многие, т.к. особых усилий для этого не требуется. А в php так не принято, максимум — какой-нибудь фреймворк изобретет сайт со списком своих плагинов, или кто-то в блоге выложит кусок написанного с ошибками неюзабельного велосипеда. Осталось помножить это на годы разработки, и причина разница в инфраструктуре php и python/ruby становится понятной.
Про RoR сказать точно не могу, но на vps за 20$ от linode.com десяток-другой проектов на джанге будут уживаться вполне хорошо. Думаю, с рельсам так же, хотя опыта не имел. Сейчас не 2005 год.
Ну и numpy и scipy в узких местах на C переписаны, так что работают быстро. Они активно используются математиками, биолагами, инженерами и т.д. как более гибкая, бесплатная/открытая и, возможно, удобная замена матлабу. «Голые» расчеты можно на Cython делать, это совсем не сложно. Но вот насчет pypy — не уверен, что он работает нормально под windows, и не уверен, что он PyQT сможет запустить. Насчет написания GUI на PyQT — думаю, на том же дельфи или вижуал студии это делать проще.
Еще раз: лучшая практика — выставлять для статики expires на год-другой вперед и потом менять названия файлов. При такой схеме запросы к серверу генерируются только 1 раз, в отличие от ETag, с которыми переспрашивать нужно постоянно (чтобы получить этот Not Modified).