Ситуации разные бывают.
Например, недавно одному из клиентов потребовалось переехать с managed хостинга одного хостера на их же dedicated (менять хостера они не хотели, бухгалтерия и все дела). Так вот выбор ОС у этого хостера был довольно интересный: ubuntu 13.x, CentOS 6.4, FreeBSD 8.3. 13 убунта по понятным причинам отпала. Так как у задач есть строки, а я с FreeBSD не знаком, то она тоже отпала. Методом исключения остался староватый CentOS, у которого в репах php 5.3.3.
P.S.: мне кажется, что довольно большая часть этих метрик была снята с шаред хостингов, многие из которых не могут похвастаться последней версией php.
P.P.S: промахнулся кнопкой. Это ответ на комментарий выше.
После django-sphinx захотелось чего-нибудь с бОльшим community.
Чем наш вариант отличается от Real-time indexes? В haystack это реализовано ровно так, как у нас, только мы еще в асинхрон это вынесли.
Это был не выбор стека, а выбор одного компонента. Когда у вас ограниченное количество времени на проект, то кроме монетки ничего не остается.
1. Замеров нет, но я не понимаю как они связаны с темой статьи. Не понял о какой вы батарейке. Генератор конфигов sphinx'а в django-sphinx или backend для xapian?
2. Согласен, что плохо. Есть масса вариантов лучше. Но в данном контексте они нам не нужны. Чтобы собирать всякие deb пакеты надо потратить больше времени, чем на этот простой скрипт, который целиком и полностью выполняет задачу. Плюсы «нормальной установки» в данной ситуации не ясны.
Если честно, то я RTD не пользовался никогда, поэтому сложно сказать.
Судя по виду индекса и сообщению в ошибке проблемы возникают из-за того, что в индексе прописано поле slug related объекта version, а самого привязанного объекта не существует:
version = CharField(model_attr='version__slug', faceted=True)
Проверьте, что у всех объектов ImportedFile есть связанные объекты version. Через shell может выглядеть так:
Нет, у нас таких проблем пока не возникало. Тут все зависит от структуры самих индексов и переиндексации. Можно при обновлении объекта обновлять все индексы, где он участвует. Но это уже все специфика каждого конкретного проекта.
Пр логике «налога с болванок» должен быть «налог с траффика».
Ведь неизвестно что вы там качаете. Вдруг пиратский контент? Извольте с каждого мегабайта копеечку за недополученную прибыль…
Вы так говорите, как будто у всех заводов «все включено».
Конечно это замедляет производственный процесс, но фотошаблоны не единственный ключевой элемент этой цепочки, поэтому зря вы так драматизируете. Даже если бы шаблоны производились на Микроне или где-то недалеко, все равно при браке или косяках «по-быстрому напильником» ничего не исправить, а большая часть времени уходит скорее на производство шаблонов, нежели на доставку.
P.S.: около года назад слышал, что где-то у нас делают производство фотошаблонов. Не факт, что там будут хотя бы 65-90 делать, но думаю, что на 180-350 рассчитывать можно
Мне кажется, что одним Стивом Джобсом тут не обойтись. Производственно-техническая база есть, но не вся. Есть оборудование, есть налаженное производство, но как мне показалось, есть еще существенная проблема с новыми кадрами.
В отделах разработки я такой проблемы не увидел — там много молодых специалистов, которые хорошо работают, которым нравится работа, которые, по их словам, видят себя и свой рост в этой компании и в отрасли в целом.
Но в производственных отделах/цехах ситуация сильно отличается. Мой друг работает там технологом на производстве и по его словам довольно большая часть новых молодых сотрудников, грубо говоря «алкоголики и тунеядцы». А самым частым «планом» на работу у тех, кто остается, является «поработаю тут года 2-3, наберу стаж и свалю туда, где много платят». В результате очень высокая текучка молодых специалистов именно на производстве.
Если учесть перспективу «развития» вузов, которые должны готовить таких специалистов, то новым кадрам вообще браться будет неоткуда.
P.S.: надеюсь, что я не прав, но у меня сложилось именно такое впечатление
На Микроне до сих пор на 90нм серийное производство запилить не могут, хотя тестовые схемы были года 1.5-2 назад. Так что до серийного производства на 65нм еще очень далеко.
Но в целом ребята молодцы: для крупного отечественного производства скорость развития довольно высокая, да и интересные проекты иногда появляются. Так держать!
У «закинул в папку www» имхо минусов больше, и они существенно серьезнее, чем у pip.
«Закинул в папку» вообще сложно назвать пекедж менеджментом. Да и простор для создания хаоса просто огромный из-за того, что проект вот таким вот образом ведется.
Вообще у php, а в особенности у apache, иное отношение к папкам и файлам, нежели у питона. Питоновский подход, как мне кажется, более правильный: хоть 100500 файлов и папок в проект закинь — ничего не изменится; можно даже вносить изменения в сам проект, без перезапуска сервера ничего не изменится.
У всего есть свои минусы. Да и речь в основном про разработку.
Зато, с точки зрения администрирования, мне кажется, что у питона гораздо более приятная система package management'а, чем у php. На всяких линуксах, во всяком случае.
pypi, pip и virtualenv вообще «жара» по сравнению с «пересобери php» (я утрирую конечно, но надеюсь, что посыл ясен)
Из этой области могу порекомендовать: Blender — отличный вариант. Можно создать какую-нибудь простенькую фигуру парой движений, а потом сразу в blender'овской консоли пощупать. Panda3d — игровой движок под питон. Правда, придется потратить какое-то время на ознакомление и до «потрогать» может дойти не так скоро, как хотелось бы, зато какой простор для творчества
P.S.: после ознакомления с блендером можно показать детям какие штуки можно делать прямо в этой программе (примеры)
P.P.S.: а если соединить blender и panda3d, то можно отдельный курс по геймдеву запилить
Профиты от интеграции с django можно перечислять бесконечно, но по-моему основным является работа с БД. Такой подход может быть неправильным в ряде клиентских тестов, но иногда гораздо быстрее бывает поменять значение поля у какого-нибудь объекта с помощью django, чем прогонять дополнительный десяток действий.
По поводу зависимостей: готовых решений я не видел. Но есть замечательный объект world, который lettuce везде за собой таскает, в который можно складывать всю нужную информацию.
Период авто-обновления настраивается.
> Он не умеет сохранять дашбоарды на сервер
Все дашборды графита, которые я видел, сохраняют настройки на сервере. Удивлюсь, если здесь иначе. Вероятно это ограничение демки.
Например, недавно одному из клиентов потребовалось переехать с managed хостинга одного хостера на их же dedicated (менять хостера они не хотели, бухгалтерия и все дела). Так вот выбор ОС у этого хостера был довольно интересный: ubuntu 13.x, CentOS 6.4, FreeBSD 8.3. 13 убунта по понятным причинам отпала. Так как у задач есть строки, а я с FreeBSD не знаком, то она тоже отпала. Методом исключения остался староватый CentOS, у которого в репах php 5.3.3.
P.S.: мне кажется, что довольно большая часть этих метрик была снята с шаред хостингов, многие из которых не могут похвастаться последней версией php.
P.P.S: промахнулся кнопкой. Это ответ на комментарий выше.
Чем наш вариант отличается от Real-time indexes? В haystack это реализовано ровно так, как у нас, только мы еще в асинхрон это вынесли.
Это был не выбор стека, а выбор одного компонента. Когда у вас ограниченное количество времени на проект, то кроме монетки ничего не остается.
1. Замеров нет, но я не понимаю как они связаны с темой статьи. Не понял о какой вы батарейке. Генератор конфигов sphinx'а в django-sphinx или backend для xapian?
2. Согласен, что плохо. Есть масса вариантов лучше. Но в данном контексте они нам не нужны. Чтобы собирать всякие deb пакеты надо потратить больше времени, чем на этот простой скрипт, который целиком и полностью выполняет задачу. Плюсы «нормальной установки» в данной ситуации не ясны.
Спасибо за исправление, сейчас добавлю в пост.
P.S.: предварительно импортировать эту модель надо, конечно же
Судя по виду индекса и сообщению в ошибке проблемы возникают из-за того, что в индексе прописано поле slug related объекта version, а самого привязанного объекта не существует:
Проверьте, что у всех объектов ImportedFile есть связанные объекты version. Через shell может выглядеть так:
Ведь неизвестно что вы там качаете. Вдруг пиратский контент? Извольте с каждого мегабайта копеечку за недополученную прибыль…
Конечно это замедляет производственный процесс, но фотошаблоны не единственный ключевой элемент этой цепочки, поэтому зря вы так драматизируете. Даже если бы шаблоны производились на Микроне или где-то недалеко, все равно при браке или косяках «по-быстрому напильником» ничего не исправить, а большая часть времени уходит скорее на производство шаблонов, нежели на доставку.
P.S.: около года назад слышал, что где-то у нас делают производство фотошаблонов. Не факт, что там будут хотя бы 65-90 делать, но думаю, что на 180-350 рассчитывать можно
В отделах разработки я такой проблемы не увидел — там много молодых специалистов, которые хорошо работают, которым нравится работа, которые, по их словам, видят себя и свой рост в этой компании и в отрасли в целом.
Но в производственных отделах/цехах ситуация сильно отличается. Мой друг работает там технологом на производстве и по его словам довольно большая часть новых молодых сотрудников, грубо говоря «алкоголики и тунеядцы». А самым частым «планом» на работу у тех, кто остается, является «поработаю тут года 2-3, наберу стаж и свалю туда, где много платят». В результате очень высокая текучка молодых специалистов именно на производстве.
Если учесть перспективу «развития» вузов, которые должны готовить таких специалистов, то новым кадрам вообще браться будет неоткуда.
P.S.: надеюсь, что я не прав, но у меня сложилось именно такое впечатление
Но в целом ребята молодцы: для крупного отечественного производства скорость развития довольно высокая, да и интересные проекты иногда появляются. Так держать!
«Закинул в папку» вообще сложно назвать пекедж менеджментом. Да и простор для создания хаоса просто огромный из-за того, что проект вот таким вот образом ведется.
Вообще у php, а в особенности у apache, иное отношение к папкам и файлам, нежели у питона. Питоновский подход, как мне кажется, более правильный: хоть 100500 файлов и папок в проект закинь — ничего не изменится; можно даже вносить изменения в сам проект, без перезапуска сервера ничего не изменится.
Зато, с точки зрения администрирования, мне кажется, что у питона гораздо более приятная система package management'а, чем у php. На всяких линуксах, во всяком случае.
pypi, pip и virtualenv вообще «жара» по сравнению с «пересобери php» (я утрирую конечно, но надеюсь, что посыл ясен)
А редакторы можно настроить.
Blender — отличный вариант. Можно создать какую-нибудь простенькую фигуру парой движений, а потом сразу в blender'овской консоли пощупать.
Panda3d — игровой движок под питон. Правда, придется потратить какое-то время на ознакомление и до «потрогать» может дойти не так скоро, как хотелось бы, зато какой простор для творчества
P.S.: после ознакомления с блендером можно показать детям какие штуки можно делать прямо в этой программе (примеры)
P.P.S.: а если соединить blender и panda3d, то можно отдельный курс по геймдеву запилить
По поводу зависимостей: готовых решений я не видел. Но есть замечательный объект world, который lettuce везде за собой таскает, в который можно складывать всю нужную информацию.