Показаны сообщения с ярлыком сложности. Показать все сообщения
Показаны сообщения с ярлыком сложности. Показать все сообщения

21 февр. 2010 г.

Простые сложности

Изучаю язык Пайтон на интуит.ру. С ужасом читаю описания некоторых конструкций языка. Такое ощущение, что автор сам не понял материал и поэтому нагоняет кучу тумана, чтобы другие не поняли, что он не понял.
Дабы не быть голословным, вот пример - описание функций генераторов:

Простые генераторы

Разработчики языка не остановились на итераторах. Как оказалось, в интерпретаторе Python достаточно просто реализовать простые генераторы. Под этим термином фактически понимается специальный объект, вычисления в котором продолжаются до выработки очередного значения, а затем приостанавливаются до возникновения необходимости в выдаче следующего значения. Простой генератор формируется функцией-генератором, которая синтаксически похожа на обычную функцию, но использует специальный оператор yield для выдачи следующего значения. При вызове такая функция ничего не вычисляет, а создает объект с интерфейсом итератора для получения значений. Другими словами, если функция должна возвращать последовательность, из нее довольно просто сделать генератор, который будет функционально эквивалентной "ленивой" реализацией. Ленивыми называются вычисления, которые откладываются до самого последнего момента, когда получаемое в результате значение сразу используется в другом вычислении.

Для примера с последовательностью Фибоначчи можно построить такой вот генератор:

def Fib(N):
a, b = 0, 1
for i in xrange(N):
yield a
a, b = b, a + b

Использовать его не сложнее, чем любой другой итератор:

for i in Fib(100):
print i,

Более извращенного описания простой концепции, я не видел. Кому интересно, про генераторы намного понятнее написано здесь (англ.).

25 окт. 2008 г.

Это правда так сложно?

Что вы делаете, когда имеется проблема и ее надо решить? Например, что-то не работает, хотя должно работать? С чего вы начинаете идентификацию проблемы?
Логичным выглядит вариант, попробовать сделать все "по инструкции". Ведь, очень часто, бывает, что мы делаем что-то, пренебрегая некими деталями стандартного процесса. Либо считаем, что некие условия, необходимые для нашей работы, уже удовлетворяют требованиям. После этого, мы начинаем искать проблему в другом месте, порою доходя до совершенно невероятных предположений.
А проблема-то, в большинстве, случаев лежит на поверхности. Поэтому сначала необходимо проверить самые простые варианты. Даже если вы уверены, что здесь не может быть проблемы, проверьте еще раз. Это удивительно, сколько проблем можно решить сразу, если начать все делать по инструкции.
Именно так и поступают (причем чисто автоматически, не сознательно, просто зная эту истину по опыту) работники службы поддержки. Те, глупые вопросы, которые они задают (например, включено ли питание монитора, на который жалуются, что он не работает) являются их попыткой не тратить время на глупые проблемы. Во многих компаниях, "на входе" сидят простые девочки, задача которых отсекать от специалистов службы поддержки глупые проблемы. И только, если проблема действительно серьезная, то они передают ее дальше, специалистам, которые могут помочь в сложных ситуациях.
Почему я это пишу. На днях меня позвали помочь с некой проблемой в одной из Лабораторий Нортеля. Так получалось, что не работала загрузка неких файлов с удаленного SFTP сервера. Файлы просто не перемещались по непонятной причине. Надо сказать, что перемещением файлов заведует код, который я писал и должен поддерживать. То есть, если он не работает, то я обязан выяснить почему и исправить ошибку. Я потратил больше часа, пытаясь разобраться, в чем же дело. А все потому, что я поверил, людям проводившим тестирование, когда они мне сказали, что логин и пароль удаленного сервера правильные. На самом деле, оказалось, что пароль был указан не тот. Именно поэтому файлы не перемещались. Никаких ошибок в нашем коде не было. Если бы я сразу проверил, а можно ли залогиниться на удаленную машину с этим паролем, то не потерял бы напрасно целый час.
А еще, есть люди, которые всегда начинают с самых невероятны предположений. Одна девушка, работающая со мной, довольно часто при обнаружении какого-либо нелогичного поведения нашего продукта сперва начинала искать проблему в ядре Линукс. Она анализировала исходные коды ядра, пытаясь обнаружить проблему там. Порою, она даже находила ошибки в ядре, но ни разу, причиной проблемы нашего продукта не было ядро Линукс (что вобщем-то вполне логично).
Поэтому, проверяйте сначала простые и очевидные вероятные причины и лишь убедившись, что дело не в них, можете предполагать что-либо сложное.