un1t

Подскажите, что за устройство такое «отвертка для поиска скрытой проводки»?

Видел пару решений этой задачи, но все они не очень удобные. Нужно добавлять дополнительные поля в документы или стоить дополнительную коллекцию.
Одно из таких решений:
cookbook.mongodb.org/patterns/random-attribute/

Т.к. используете Сфинкс, есть смысл посмотреть может ли он решать вашу задачу. Там есть функционал упорядочивания случайным образом, хотя конечно не во всех случаях подойдет.

Метрика шлет пинги каждые 15 секунд, так что посчитает и для одностраничника без проблем.

myArray.append(myClass)

Вы тут не создаете объекты. А добавляете в список ссылку на класс.
Нужно так:
myArray.append(myClass())

Есть куча разнных баг-трекеров и систем ведения проектов, но мне лично не одна не нравиться. Хочется относительно простенький трекер для небольших команд 3-5 человек.

К момему прошлому сообщению слишком много комментов, поэтому отвечу здесь.

>Вы никогда не отвечали за поддержку критической инфраструктуры, оттого и настолько неправильное понимание вопроса.

Такой опыт у меня был. Обслуживал систему маниторинга ИТ инфраструктуры связанной с выборами в 2008 году. К томже по образованию я энергетик и знаю как организована работа на электрических подстанциях — это куда более важные объекты чем интернет или телефон.

Дежурства должны оплачиваться.

> Вот произошла авария в той области, которую сопровождают два человека. Оба человека в отпуске, забухали, сидят с
>разряженными мобильниками и т.д. Инфраструктура лежит. Поднять ее некому. Каждая минута простоя — приличные
> деньги. И тут речь может идти не о минутах, а о днях, что представляет угрозу самому существованию конторы.
> Надеюсь, я понятно объяснил, почему «хотя бы один человек из отдела всегда должен быть на связи»?

Дак вы же сами говорите, что такой простой стоит для конторы огромных денег, но почему-то вы считаете, что сотрудники должны делать эту работу бесплатно.

> Автор топика, будучи человеком профессионально незрелым, раз возмущается тому, что начальник не разрешает им всем
> отделом куда-то свинтить. Но что если они действительно разлетятся по отпускам, и произойдет авария?

Речь не об этом. Дежурства должны быть организованы, чтобы инфраструктура работала стабильно. С этим согласны все. Однако автор говорит, и я с ним согласен, что дежурства должны оплачиваться и должны быть прописаны в трудовом договоре. Дежурства должны быть оплачены. От человека это требует определенных усилий, быть на отдыхе и быть на дежурстве это не одно и тоже.

Я часто вижу ситуацию в организациях, когда «эффективные менеджеры» пытаются всех заставить работать в дополнительное время и по выходным. Мое мнение, что руководители плохо выполняют свою работу. Если компания не успевает выполнять всю работу во время, то нужно либо нанимать больше людей, либо не брать на себя столько работы. На предложение поработать в выходные, я обычно отвечаю категорическим отказом.

Странно что никто не упомянул Бизли Д. «Python. Подробный справочник.» Хотя это конечно больше как справочник, но книга довольно толковая, я ей переодически пользуюсь.

Без конкретных примеров, не понятно о чем идет речь, соотвественно ответы могут быть противоположными.

У меня на одном из проектов нужно парсить разные xml файлы, причем файлы достаточно большие 200-600 Мб. Сначала я выбрал стандартное решение для питона — lxml.etree. Одно отлично работало, но оказалось, что не все файлы сформированы правильным образом. Там могут встречатся всякие ошибким типа незакрытих тегов и внутри могу быть какие-угодно кодировки, а не только та которая указана в xml-заголовке. Т.е. в одном файле может быть куча разных ошибок. Вобщем никаие стандартные решения не умеют обрабатывать все эти проблемы. Просле поиска готовых решений, я написал парсер на регулярках. Этому парсеру вообще пофиг на любые ошибки, он также может спокойно парсить любые битые файлы. К томуже оказалось, что такой парсер работает в 1.5 раза быстрее, чем парсер на lxml. В моем случае решение адекватно задаче.

Я написал свой визивиг. Скриншот и описание можно посмотреть тут Обладает мнималистичным интерфейсом. Поддерживает AJAX загрузку картинок.
Он опубликован на гитхабе github.com/un1t/pencil и также есть праложение для джанги github.com/un1t/django-pencil. Я нормально использую его в админках. Из недостатков отмечу, что за неимением времени я не допилил его для IE(для админки это как правило не критично), в других браузерах работает нормально.

Попробуй Sphinx, прикручивается легко. Пример тут

Я не верю что может быть затык в этом месте. Затыки бывают — БД, сеть и дисковые операции. На генерацию объектов тратиться относительно мало времени. Я знаю, некоторые крупные и действительно высоконагруженные прокеты используют внутри аццки тормозные технологии типа расширенных xslt преобразований. При этом у пользователя все летает. Это достигается кешированием и горизонтальным масштабированием.

Я рекомендую изучать 2.7 в настоящее время все испльзуют именно ее. Активных телодвижений в сторону третьей ветки не видно. Отдельные билиотеки и фреймворки переносят на 3, но большинство пока работает на 2.5-2.7. Не думаю что в ближайшие пару лет ситуация измениться. Тот же Flask переносить на 3 не собираются. Мне не известны крупные проекты рабтающие на третьем питоне, хотя не исключаю что они существуют.

Ох уж этот академический подход…

Вся эта теоретическая хрень не нужна на данном этапе. Нужно учить на простых практических примерах. Например мы хотим сделать упрощенную версию арканойда. Для начала упростимм ее до такой степени что шарик летает по экрану и отталкивается от стенок. Садимся пишем. Здесь не нужны ни системы счисления ни архитектура компьютера. Здесь нужны лишь понятия переменных, циклов и какое-то API для отрисовки простой фигуры. Нужно подбирать пример который будет интересен ученику, это может быть что-то другое.

Интересно что же за вопросы такие, которые на stackoverflow закрывают?

Для таких задач особенно актуальны автоматические тесты
docs.djangoproject.com/en/dev/topics/testing/?from=olddocs

Консольный отладчик pdb также может быть в этом деле полезен.

Рекомендую Python+Django. У джанги большое сообщество хорошая документация, множество готовых компонентов. На питоне есть и другие хорошие фреймворки, но у джанги самое большое сообщество, поэтому это идеальный вариант для вникания в веб-разработку.

> Были посты про то, что железо улучшается, а программы продолжают тормозить — не из-за этого ли?
> Десятки слоев, абстракций, отъедающие свои ресурсы.

Посмотрите доклады архитектуры highoad проектов. Тормозить могут три вещи — дисковые операции, база данных и сеть. ООП конечно проигрывает по скорости выполнения процедурному подходу, но этот проигрышь 0.00001% запроса к БД. Если программа тормозит, то не из за слоев абстракции, а вышеуказанных причин.

>MVC — круто, наворочено, универсально — но проигрывает по сравнению с тем же PHP по многим пунктам.

Тут либо неточность формулировки либо непонимание разницы. Нельзя сравнивать MVC и PHP, первое это шаблон проектирования, а второе это язык программирования. На PHP есть куча фреймворков придерживающихся MVC.

>Простой проект MVC — это около десятка папок, пять конфигов, куча контроллеров. Опять же — куда такие сложности?
> Для чего?

Это очень сильно упрощает жизнь даже в небольших проектах, в больших польза от этого растет экспотенциально.

>когда вы в этом успеваете разобраться? Сколько лет ковыряния нужно, чтобы досконально знать, что вызов вот
> этого приведет к этому, вызов того делает то, причем на пять слоев абстракций в глубину, и особенность
> вон того дает преимущество в этом.

Это зависит от опыта и сложности платформы, опытному программисту (5 лет коммерческой разработки на полную ставку) хватит от пары дней до пары недель чтобы начать выполнять новый проект на незнакомом фреймворке, месяца 3 чтобы уверенно себя чуствовать и 1-2 года, чтобы досканально разобраться во всех внутренностях.

Судя по году рождения, ты еще только начинаешь свой путь в программировании. Так что если пока в чем-то не удается разобраться это нормально. С опытом придет понимание.

>И как можно вникнуть в технологию, чтобы применять её на практике, если через пару лет появляется
> более новая технология или в корне меняется старая и надо снова рыться, снова изучать и т.п.

Новые технологии принципиално оличающиеся от всех предыдущих появляются редко, если вообще появляются. Все новые технологии основанны на предыдущем опыте. Например новомодная MongoDB которой лишь предстоит стать мэйнстримом основана на JavaScript и JSON, а эти технологии знакомы любому веб-разработчику. Другой пример новомодных NoSQL технологий — это key-storage хранилища например memcached и redis, любой кто работал с реляционными БД разберется в них за 5 минут. Конечно чтобы внкнуть в тонкости API и конфигурации нужно больше времени, но ничего сложного там нет.

Я написал свой WYSIWYG правда, он пока еще в IE не полностью работает, но для моих целей хватает.
github.com/un1t/pencil

Кода мало, легко разобраться. Самому писать, визивиг дело тяжкое, но допиливать чужое еще более тяжкое. Если поправить пару неработающих моменов в IE то можно будет вполне нормально пользоваться.

Если есть желание, можешь помочь мне допилить его.

Том Демарко и Тимоти Листер «Человеческий фактор. Успешные проекты и команды»

Том Демарко «Deadline. Роман об управлении проектами»

Том ДеМарко, Тимоти Листер «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения»

Джоэл Спольски «Руководство Джоэла Спольски по подбору программистов и управлению ими»

Джоэл Спольски «Джоэл о программировании»

Роберт Гласс «Факты и заблуждения профессионального программирования»