За 5 лет работы в компании сменилось огромное количество менеджеров проектов.
ПМ-ы мрут как мухи. Как пехота штрафбата, брошенная в бессмысленную лобовую атаку.

Мрут сами (уходят), их убивают (увольняют), устраивают ксеноцид (их увольняют вместе с командой). Бегущие без винтовок, сзади вас товарищи, заменят вас. И проживут свои 2 минуты.

Поводом для написания этой статьи стало желание разобраться с тем, как работает Y-комбинатор.

Чтобы мозги не ржавели и работали как часы, я стараюсь пробовать новые и необычные вещи.
Интереса ради, я скомпилировал Lua 5.x под DOS, с этим никаких проблем не было, но при проверке Lua на её стандартных тестах, я обнаружил код вычисления факториала, работу которого я не понял.
Но ясно осознал, что это нечто относится к функциональному программированию.

В последнее время на Хабре появились несколько статей, посвящённых грамматическому разбору выражений.
И это замечательно! По моему скромному мнению, каждый программист должен хоть раз в жизни написать разбор выражения. Постараюсь и я внести свою лепту в общее дело.

Методов разбора существует множество (рекомендую следующий обзор Dick Grune, Ceriel J. H. Jacobs — Parsing Techniques: A Practical Guide, ISBN 0-13-651431-6). Причём реализации методов варьируются от полностью ручных до использования автоматизированных генераторов, таких как bison, antlr, lemon и других.
В то время, как ручное написание лексических и синтаксических (далее я буду называть из лексер и парсер) разборов позволяет достичь максимальной скорости и контроля (особенно над ошибками и способами их преодоления), использование генераторов позволяет сосредоточиться непосредственно на задаче, облегчает модификацию грамматики и бережёт время. Умение владеть такими инструментами позволяет чаще прибегать к DSL (Domain Specific Language) и вообще видеть возможность их применения.

Я хочу привести пример использования bison (парсер) и flex (лексер) в реальной жизни: от возникновения задачи, до её решения.

Memoization – свойство функций сохранять (кешировать) результаты вычислений, дабы не вычислять в последствии повторно.

Эта технология оптимизации позволят достичь прироста скорости работы за счет потерь в свободной памяти.

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

Для python декоратор для функции будет выглядеть следующим образом:

import cPickle
def memoized(func):
    memory = {}
    def memo(*args,**kwargs):
       hash = cPickle.dumps((args, sorted(kwargs.iteritems())))
       if hash not in memory:
           memory[hash] = func(*args,**kwargs)
       return memory[hash]
    return memo

Далее, нам достаточно объявить bigfunc как

@memoized
def bigfunc(…):
…

Или переопределить, если она уже объявлена:

bigfunc = memoized(bigfunc)

Декоратор, объявленный в начале статьи, работает только с пиклезуемыми объектами. Если ваша функция работает с непиклезуемыми объектами – вы можете заменить

hash = cPickle.dumps((args, sorted(kwargs.iteritems())))

на

hash = (tuple(args), frozenset(kwargs.items())

но вы потеряете возможность работы с mutable объектами.

Декоратор можно легко модифицировать, для ограничения количества закешированных элементов.

Криптография

Три кита криптографии — хеш, шифрование симметричное, шифрование асимметричное (с открытым ключом). Основываются криптографические алгоритмы на сложности вычисления больших чисел, но подробнее об этом, если вас конкретно интересует «начинка», стоит читать не в общих обзорах, именуемых ликбезом. Здесь же содержится простое изложение, без лишних заморочек, то есть поверхностное.

Двое моих знакомых, задавших в течение недели вопросы примерно одинаковые по сути (примерно в духе: «А я слышал, что MD5/SHA-1 уже взломан, почему мы до сих пор их используем ?»), подтолкнули меня к написанию этой заметки, хотя основные события, описываемые ниже, произошли уже более 3 лет назад.

Work on Stuff that Matters: First Principles

опубликовано 11 января 2009 года

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

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

Продолжение, начало см. тут.

В этом разделе мы поговорим более подробно про определение функций, и раскроем некоторые Python-специфичные особенности данного процесса. Так как информации много, то постараюсь излагать все достаточно кратко.

Параметры по-умолчанию

Для всех параметров функций можно указывать значения по-умолчанию, это дает возможность вызвать функцию с меньшим числом параметров. Например, у нас есть функция для авторизации пользователя на сайте:

def login(username="anonymous", password=None):
    """Тут какие-то действия"""
    pass

# вызвать эу функцию мы можем одним 
# из нижеприведенных способов
login("root", "ujdyzysqgfhjkm")
login("guest")
login()
# мы можем указать какой из параметров мы передаем, 
# указав его имя в явном виде
login(password="nobody@mail.com") 

Все мы, здесь присутствующие, горячо любим IE6, чуть менее горячо — IE7 и искренне верим (правда, не все и не всегда признаёмся в этом) в IE8. Здесь писали про множество способов борьбы с особенностью шестого издания мелкомягкого браузера не понимать формат png. Но все эти обсуждения касались просто загрузки png-картинок. А передо мной возникла гораздо более интересная (и более сложная) задача — анимация этих картинок. И всё бы ничего, если бы нужна была анимация, в которой бы нужно было менять только положение и размеры картинок. Мне требовалось сделать анимацию, в которой бы плавно менялась их прозрачность. Тут-то и обнаружились новые фокусы.

В тему компиляций и вычислений выражений.

В далёком 1973 году Воган Прэтт (Vaughan Pratt) предложил простой и эффективный метод разбора выражений, не использующий ни автоматы, ни грамматику как таковую.

Идея заключается в том, что каждый символ (token) наделяется свойствами:
lbp = приоритет связывания символа слева,
nud = функция, определяющая результат применения оператора в начале выражения,
led = функция, определяющая результат применения в середине выражения.

Основной разбор осуществляется по схеме:

разбор(приоритет продолжения):
    вытолкнуть символ из входного потока
    результат = вызов nud этого символа
    пока приоритет lbp следующего в потоке символа > приоритета продолжения:
        вытолкнуть символ из входного потока
        результат = применени led этого символа к текущему результату

Константы и переменные имеют приоритет связывания 0, а функция nud возвращает их значение (или ссылку). Поэтому применение разбора к константам сразу возратит их значение.
Для бинарных операторов функция led рекурсивно вызывает продолжение разбора (справа) вплоть до более низкого приоритета, и делает что-нибудь с уже накопленым (слева) результатом, и полученным рекурсивно.
Результат применения оператора аггрегируется для внешнего вызова.
Много-арные операторы — получают аргументы дополнительным вызовом функции разбора.
Префиксные операторы делаются с помощью определения для них функции nud.
Для правостороннего связывания меняется приоритет продолжения рекурсивного разбора.

На сайте effbot.org приводится подробная реализация на питоне.
Там же есть ссылки для жаваскрипта и схемы.

Достоинства удаленной работы очевидны — меньше ограничений в поиске специалистов с нужной квалификацией, возможность нанимать людей за пределами МКАД, меньше расходов на ведение бизнеса. С другой стороны, есть и проблемы: наиболее значительные — со стороны организации работы. Последние 4 года я работаю тим лидом распределенной группы программистов (3-15 человек в разное время) для зарубежного заказчика, и хочу поделиться с хабрадевелоперами опытом такой работы :-)

Здесь и далее имеется ввиду следующая организация труда:

1. Заказчик (+on-site команда опционально) в офисе где-нибуть в Европе/США.
2. Тим лид распределенной команды — где-то на бескрайних просторах exUSSR.
3. Члены распределенной команды — также где-то на бескрайних просторах exUSSR.

Подразумевается, что при желании заказчик может общаться со всеми членами команды. Оплата работы — почасовая.

Часто возникает желание посмотреть отуда приходят люди на ваш сайт, дабы пойти туда почитать что про нас любимых пишут, и рьяно вступить в полемику не отходя от кассы. Казалось бы, такая популярная штука как Google Analitycs должна делать это, но есть одна проблема — в отчете отрезаются GET-параметры, и если вы видите что ссылка с огромного форума, то вам еще предстоит найти нужную тему, что отнимает время (стоит упомянуть, что Google Analitycs требует дополнительного JS кода на страницах, что также отнимает время и трафик).

Достаточно часто нам приходится хранить данные в memcached или MemcacheDB. Это могут быть относительно простые данные, например, закэшированные выборки из базы данных, а иногда необходимо хранить и обрабатывать более сложные структуры данных, которые обновляются одновременно из нескольких процессов, обеспечивать быстрое чтение данных и т.п. Реализация таких структур данных уже не укладывается в комбинацию команд memcached get/set. В данной статье будут описаны способы хранения некоторых структур данных в memcached с примерами кода и описанием основных идей.

Memcached и MemcacheDB в данной статье рассматриваются вместе, потому что имеют общий интерфейс доступа и логика работы большей части структур данных будет одинаковой, далее будем называть их просто «memcached». Зачем нам нужно хранить структуры данных в memcached? Чаще всего для распределенного доступа к данным из разных процессов, с разных серверов и т.п. А иногда для решения задачи хранения данных достаточно интерфейса, предоставляемого MemcacheDB, и необходимость в использовании СУБД отпадает.

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

KDE4

Все уже успели пройтись по сырости технологии, внешнему виду, концепциям интерфейса, но настоящие апологеты знают — когда KDE4 войдёт в стабильную фазу, все станет хорошо, и слабые духом отступники, которые видите ли не могли потерпеть годик постоянных глюков, вернутся.

Теперь серьезно — ключевая технология нового KDE — Plasma. Таким образом, чтобы в KDE было жить хорошо, надо создавать плазмоиды. Спасибо C и C++ за работу ядра, X сервера и KDE, а мы, поколение web-разработчиков, да и вообще людей привыкших к простоте, вполне можем обжить систему используя более знакомые нам языки, к примеру Python, который, как известно, поставляется с батарейками.

В продолжение поста Компилятор выражений. По просьбам читающих. Специально для michurin

Есть много способов вычислить значение выражения мне больше всего нравится метод с двумя стеками.
Нравится за его элегантность и простоту реализации.

Суть метода 2х стеков (наверняка у него есть красивое научное название.) заключается в том, что любое сложно выражение, в конечном счете, сводится к последовательности простых операций. В нашем случае это будет бинарная операция над операндами A и В.

Мы будем идти слева на право, добавляя операнды в один стек, а операции в другой. При каждом добавлении новой операции мы будем пытаться вытолкнуть из стека старые, руководствуясь приоритетами операций.

Идея совсем не нова. Идея древна.
Однако большинство наблюдаемых вокруг веб-фреймворков упорно игнорируют эту идею.

Она заключается в том, чтобы использовать континуации (continuations) для магического превращения RESTful (stateless) веб-приложений в более удобный и привычный stateful формат.

Новичкам в Django будет полезно узнать об очень полезном инструменте отладки — debug-toolbar. Он настолько крут, что его называют Firebug for Django. На больших проектах без него (или другого отладчика) не обойтись.

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

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

Второй пример, который стал причиной моего углубления в этот вопрос, — это проект, мы его еще не запустили, но как всегда сделали заглушку с формой для сбора адресов. Так вот, чтобы она не выглядела уныло и люди могли следить за тем, что происходит с проектом, я создал аккаунт на твиттере и транслирую сообщения на этот сайт в удобном мне виде. Человек может заходить на сайт и смотреть «что нового», а может и воспользоваться тви, а мне нужно будет вводить текст всего единожды. Тем более люди легко смогут задать вопрос, а я быстро о нем узнаю.

В техническом исполнении все оказалось не сложно.

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

Один из стандартных вопросов, который задает (или по идее должна задавать) веб-студия на первой встрече с клиентом – зачем вам нужен сайт? Зачастую клиент с готовностью отвечает «нам нужен сайт как инструмент». Но, как показывает опыт, иногда это примерно то же самое, что прийти в магазин и купить дрель, чтобы была. Чтобы в доме был инструмент.

Вспомним классический пример, что покупая дрель, по сути человек покупает дырки, которые можно сделать с помощью этой дрели. Для того чтобы эти дырки появились, инструментом надо пользоваться, надо уметь с ним обращаться и работать. Сама по себе дрель (как и сам по себе сайт) особого смысла не имеют.

С учетом того, что создание сайта – удовольствие чаще всего не дешевое, что же нужно сделать, чтобы инструмент не лежал на полке, а использовался по своему прямому назначению? Декларируя, что мы заказываем сайт-инструмент, надо понимать, какие именно «дырки» мы хотим получить в результате.

Давайте рассмотрим постановку задачи на примере.