пятница, 25 марта 2011 г.

Dive in python

Последний год мониторинг происходящего в нашей эко-системе меня сильно озадачивает. На рынке труда появилась бешенная любовь к python. Работодатели предлагают 80, 90, 100, 200 тысяч рублей в месяц за работу с django.

Более того косвенными способами узнаю кого нанимают на работу серъезные компании, имея в наличии рекомендации этих говноедов от бывших коллег или работодателей - охуеваю.

Переодически борюсь с позывами завести трактор. В экосистему прорвались долбоебы с ФГМ выше 9000, которые по баз-квизу судят способность человека алогритмировать, при это абсолютно не слушая аргументацию оппонента.

Демонстрацией все этой истерией является следующее изображение:


Это и код который мы теперь пишем, подгоняемыми сроками от инфантильных менеджеров, это и работодатели, это и проекты, это и программисты. 

понедельник, 14 марта 2011 г.

CV одного человека

Просто оставлю это здесь, как бы в напоминание о том, что нужно эту тему раскрыть:



Как бы современность Российского рынка нам говорит. Если у тебя нет фольксваген-фургона и нечего продать. То лучше продать почку, чем попытаться искать работу :D

С другой стороны аллегория такова, что и ни один хантер на найдет "работягу". 

пятница, 11 марта 2011 г.

Старый манускрипт

На одном из сайтов о программировании нашел няшную цитату из IRC, от товарища по подпольной борьбе - cadmi:

1. Perl сделал _одмин_, который заипался логи парсить на awk
2. PHP написало уебище (nothing personal, возможно он очень мил и приятен в общении и водки выпить),
которое делало "движёк для своей домашней страницы" вот Personal Home Page оно и осталось как его не переименовывай
3. Python написал Математик, в Университете
дальше третий пункт разворачивать не стану, и так уже достаточно
написал для того, чтобы в том числе людей программированию обучать
поэтому Python - это язык для людей
Perl - для админов, которые по образованию к тому же лингвисты, если я правильно помню тему диплома Ларри
а PHP - для голодранцев, которые сами себе гостевую книгу пишут
пока похапесты "завоёвывали рынок web приложений"
на Python шпарили математики и физеги :) не обламываясь :) а это плять Школа. ее так просто не пропьешь,
системный подход, системный подход, и "люди привыкли писать статьи так, чтобы другим понятно было"
Как бе 2007 год.

И да. Мы действительно считаем что все вокруг именно такое :) 

Google Accounts -> Google Accounts

Внезапно обнаружилось, что теперь можно свою "организацию" подключить ко всему спектру гугловских серверов.

Поэтому взял и перетащил блог с одного аккаунта на другой. Импорт/Экспорт чуть более чем няшен.

Параллельно умудрился завершить интсталяцию нового сервера под MongoDB. В нашу хреново связанной архитектуре появится наконец распределенный реплика сет. В нагрузку придумал четыре варианта его использования :)

Вообще генерация тракторов вошла уже в привычку :)


пятница, 25 февраля 2011 г.

Creatio ex Nihilo. Архитектура сложного веб-проекта. Введение

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

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

Архитектуры можно разделить на распределенную и монолитную. А внутреняя структура имеет определенную степень связанности - сильную или слабую. Собственно архитектура влияет на структуру кода и проекта в целом, а структура влияет на методику разработки и способы развития проекта.

Перед разговором о собственно архитектуре нужно понимать масштабы задач которые ставятся при ее реализации. Есть веб-ресурсы с огромной упорядоченной инфраструктурой - например Гугл или Яндекс. Есть веб-ресурсы с небольшой инфраструктурой, но большим числом сервисом - фейсбук. Есть небольшие сайты - веб-ресурсы компаний, банков, контентные. Архитектура, структура и реализация у них различна. И различна в первую очередь из-за различия амбиций и способностей созидающих их людей.

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

1. Python/Django - язык программирования и фреймворк посредством которых программист может описать доступ к базе данных, миддлвейры, обработчики контекста и программировать внутреннюю структуру т.н. бекенда;
2. Django-templates/HTML/CSS - система шаблонизации и разметка отображений. То что описывает задачу фронтенда, и позволяет создавать непосредственно внешний вид веб-ресурса;
3. JavaScript/jQuery/AJAX/JSON - язык программирования, фреймворк для создания всего и вся, технология передачи данных и средство сериализации. Все это в сумме позволяет создать динамические, легкие и удобные интерфейсы для пользователя.
4. SQL/JOIN/RELAITIONS/MySQL/Postgresql - средство для хранения данных превращенное временем в кумира и идола для миллионов веб-разработчиков. Благодаря консистентности, строгости в языке запросов и сложности во внутреннем устройстве создает этакую магическую простоту в разработке и шаманскую сложность в обслуживании. Позволяя полным профанам от программирования иметь хранилище с данными, которое очень трудно разрушить. Посредством чего решается множество проблем.

Заменить участки можно чем угодно. Но модель MVC/MVT нынче является архитектурой которой поклоняются мирриады бездушных тварей миллионы веб-разработчиков.

Сколько не грызите ногти, конфетами они не станут.
Идея заложенная в паттерне проектирования MVC - весьма прозрачна. Мы создаем код, который умеет работать с данными (Models/Controllers), мы создаем код который умеет управлять контекстом исполнения (Controller), и пишем код который ответственен за отображение данных (Views/Templates).

При этом мы стремимся к отделению мух от котлет. Работа с данными у нас в одном месте, их обработка в другом. Что и в какой-последовательности в третьем, а создание ненавистных виджетов или генерация HTML в четвертом.

В веб-программировании это все было не с проста. В целом люди обладающие способности к программированию не любят рутинную работу. По их мнению рутина - это работа с HTML. В действительности разработка представлений тоже креативная и интересная работа. Но отсутсвие знаний в этой области превращает работу в скучную и ненавистную рутину.

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

Da Red Goez Fasta!
Космические Орки знают в то, что красная машина едет быстрее. Основываясь на этом знании, они покрасили гретчинов в красный цвет, думая, что таким образом увеличат их производительность и эффективность. Реальность их удурчала.

В нашем случае веб-программисты постепенно объеденили в себе множество профессий: верстальщиков, JS-программистов и флеш-аниматоров, программистов бизнес-логики, DB-администраторов, системных администраторов и местами даже проектировщиков-архитекторов и менеджеров.

Это все в целом позволяет компаниям минимизировать затраты на штат сотрудников, позволяет более эффективно создавать новые продукты или ресурсы. Увеличить прибыль и получать качественные цельные разработки.


И чтец и жнец и на дуде игрец!
Реальность часто отличается от бизнес-планов. По факту большинство веб-программистов импотенты в аспекте DBA, SQL, администрирования, проектирования архитектуры, менеджемента и нередко даже программирования. Один человек может получить экспертизу во всем вышеперечисленным. Но внезапно он захочет занимать иную должность, например технического директора, а не обычного разработчика. А это явно не совпадает с планами работодателя.

Чтобы убить вампира, вам нужна серебрянная пуля
Дабы упростить задачи веб-девелоперов решения вроде Django предлагают множество допущений - отказ от использования и знания SQL - Django-ORM. Отказ от непосредственной реализации многих сервисных вещей - кеширования, аутенфикаци, валидации форм etc.

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


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

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


Распределенная архитектура - делает в целом тоже самое, что написание программы разделенное на функции. Мы выделяем определенную задачу и решаем ее необходимым способом.

Слабая связанность - достигается должной степенью абстракций. Отказом от конкретных способов реализации. Т.е. новостную ленту мы можем сделать на Django+MySQL. А вот счетчик посещений реализуем комплексом из C+libevent+NoSQL DB+python+Postgresql.

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

Collector & Templates
Наиважнейшей частью веб-проекта является его внешний вид. Если у вас порядка 10 источников с данными, и количество их будет лишь расти с геометрической прогрессией, то вам нужен общий центр синхронизации.

В нашем случае это приложение прототипированое посредством python+twisted+lxml(libxml2). Оно занимается следуюшими вешами:

1. URL Dispatching - анализируем URL и определяем к каким источникам данных нам нужно обратиться. Для упрощения реализации, обращаемся к источником только через протокол HTTP, хотя в целом ничего не мешает использовать и другие средства.
2. Authentication - частично выполняет проверку аутенфикации. Для уменьшения числа запросов к бекендам (источникам данных) которые требуются только для определенных ситуации на данном рынке :)
3. Context Processing - для каждого контекста нужен свой общий набор запросов к данным. Группируя их мы формируем общий контекст для вывода;
4. Data Transformation - в общем и целом мы генерируем на выход HTML. Впрочем нам ничего не мешает генерировать CSS/JS/JSON/AMF или что-то еще. Для текстовой информации мы используем XSLT. Это формирует и требования к ответу бекендов - XML. Причина использования XSLT будет обоснована позднее. Пока коротко о XML. XML не оптимален как транспортный протокол, в случае если он станет узким местом, мы всегда сможем сделать JSON способ сериализации, или вообще использовать бинарные протоколы. Коллектору останется лишь привести их к XML.

Backend Developing
Источник данных может быть любым. В простейшем случае это pylons/pyramid сервис который обращается к хранилищу и препарирует данные для сериализации. Главное это специфицировать метод обращения к бекенду.

В сложном случае им может быть и сложное асинхронное приложение (или даже комплекс) которые выполняют множество задач.

Например мы хотим знать кто из друзей пользователя онлайн. У пользователя 100 тысяч друзей. Вычисление постраничного вывода на лету, для пары тысяч таких ребя, может стать травматичным и опасным мероприятием. Поэтому у нас есть некий сервис который активируется при авторизации пользователя и запускает процесс кеширования данных. Они вынимаются из базы и складываются например в Redis. Дальше когда кто-то переходит в состояние оффлайн, мы его удаляем из писка онлайн у его друзей (точно так-же в бекграунде). Снижая таким образом накладные расходы на множество вычислений и перекладывая их с одного средства (СУБД) - на другое (Redis).

Т.к. нам в данном случае результат работы не важен, наш бекенд ответит коротким респонсом и передаст дальше задачу либо своим внутренним ресурсам, либо вообще через MQ стороннему приложению.

Хранилища
Основное хранилище данных у нас MongoDB. Однако помимо оного используется так же MySQL и Postgresql. А в ближайщем будущем добавиться еще и Cassandra и парочка прочих веселых вещей.

Частично это получилось исторически. И оказалось достаточно удачным для создания в целом гибкой инфраструктуры.

Что мы получаем?
Благодаря разделению задач на каждом пласте комплекса программ и средств мы получаем распределение обязанностей между людьми. Тот кому нравится работать с веб-интерфейсом - трудится с коллектором и XSLT. Используя свои знания и способности в области HTML/CSS/JS/jQuery.

Тот кому нравится писать бизнеслогику работает с бекендами. Программисты интересующиеся сетевым стеком и интеграционными задачами пишут программы вроде коллектора или сервера приложений работающие с данными поступающими из MQ.

Каждая программа и каждый программист таким образом живет независимо от других. И в то же время является частью общего целого. Общая интеграция становится весьма простой задачей. Добавлением пары строчек в конфигурационный файл коллектора и на данном конкретном сайте появится новый виджет.

В продолжении

В продолжении рассмотрим каждую деталь механизма подробнее. А вдруг я ошибаюсь. Лишь графоманство и размышления позволяет понять не допущены ли ошибки в спецификации :)

понедельник, 14 февраля 2011 г.

mongodump/mongorestore

Если вы еще не переносили данные с продакшен-сервера, на девелоперскую версию, обязательно сделайте это.

mongodump/mongorestore в этом плане сексуальны чуть более, чем полностью. Первая без параметров делает дамп всех данных с сервера, в структуру типа dump/database_name/collection_name.bson.

Вторая с 2 ключами принимается за восстановление данных.

Никогда еще этот процесс не был, столь прост и увлекателен.

ИСПДН: Пора заводить трактор!

Через 130+ дней в нашей стране вступает в действие ИСПДН. В связи с этим любопытен комментарий:

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

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


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

среда, 26 января 2011 г.

Через 20 минут, война с Англией!

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

Как с Англией? Где эта Англия? А где мы? ЭТО ЖЕ РЯДОМ!
Одна сцена из ностальгической сатиры "Тот самый Мюнхгаузен" способна расскрыть происходящее в современном IT бизнесе. Отмеряя рулеткой портного расстояние от Англии до Ганновера герцог как бы удивляется тому, насколько близок дедлайн и насколько слабо мы к этому готовы.

Планируя разработку герцоги, отчего-то никогда не готовы к тому, что разработка сложный технический процесс. Принимая решения которые кардинально изменяют весь производственный цикл или отказываясь от понимания того, что задержки неизбежны (например множественными согласованиями дизайна или интерфейса) из-за их действий, они из глубины времен удивляются тому, ЧТО ПИЗДЕЦ РЯДОМ. И в следующий раз все равно не услышат разработчика который будет твердить о тестировании, багах и возможных задержках. Это не важно, ведь война с Англией не избежна.

Отозвать всех уволенных в запас, отменить отпуска!
На фоне феерии дедлайнового бреда отменяются например запланированные отпуска разработчиков. В одной такой сказочной компании мой 2 недельный отпуск превратился в 4 дневный. Все остальное время пришлось сидеть и работать. Такое ощущение, что планируя что-нибудь на ближайщие 2 недели, нельзя было принять во внимание, что через неделю человек уходит в отпуск, о котором предупредил за 2 месяца (срок в 4 раза больший).

Еще более интересны предложения поработать в выходные или праздничные дни (дедлайны же). Почему не запланировать задержки в 30% срока, чтобы иметь запас времени на экстренные ситуации. По факту эти 30% это время когда люди работают сверх оговоренной нормы и в выходные дни. Причем бесплатно.

Качество и мотивация сотрудников ниже планки. Товар ниже планки. Доходы снижены.

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

Но т.к. в старом костюме никто не воюет, необходимо обязательно применить самые модные технологии. Разработчик всегда ратует за это (явно предупреждая, что возможны задержки по срокам), но менеджер всегда примет неадекватное решении - обновить парк технологий, обновить стиль приложения, и сделать это в тот срок в который невозможно это сделать. Все последующие решения будут усугублять ситуацию и приведут к краху. Только лишь потому, что недалеким людям, куда ближе максимум возможностей. При этом они всегда считают, что проблем будет минимум.

Ваше высочество, вы же умный человек и в душе, я уверен, тоже не любите Англию.
Сроки дедлайнов, не будут пересмотренны никогда. Уволили у вас половину штата, сломался у вас сервер. Не было в офисе интернета. Было пересмотрено техническое задание. Ни при каких условиях герцог не согласиться с тем, что он тоже не любит Англию. Потому что:

Да не люблю. Но я сижу и помалкиваю.
А как иначе. Начальство шкуру снимет. Неустойки клиент будет требовать, или воовсе откажется от ваших услуг, если вы будете за каждое изменение требовать оплаты. Дешевле для себя никогда не пересматривать сроки.

О. Без четверти 5. Успели все таки.
Английский парламент признал независимость США. Феноменальный финишный спурт множества людей привел к тому, что труп ожил и двигается. Успели. И все опять повторится сначала.


Древняя русская мудрость:
Заставь дурака Боги молиться,он себе и лоб расшибет

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

Это пиздец.

понедельник, 17 января 2011 г.

Притча о несчастном клоуне.

Жил да был на свете клоун. И вот решил он однажды найти себе работу в новом цирке.
Пошел он в интернет и нашел элитный сайт для клоунов. Стал заполнять форму - и увидел, что может выбрать профессию - клоун. "Надо же" - подумал клоун - "я могу указать свою профессию! Этот сайт явно сделан для нас!"

Указав профессию. Он восторженно нажал на кнопку подтвердить. Дальше ему показывали все новые и новые формы, в которых он указал фотографию, возраст, места где служил ранее. И в конце сообщили, "дождитесь активации вашего аккаунта".

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

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

И в целом верно. Проще надо быть. А то видишь ли - профессию он указывает. Мудак.

Притча о Святом Луке.

Жила была интернет компания.

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

Нарисовали три варианта дизайна Святого Луки. и вот начали делать будущего покорителя интернетов.

Но вышло так, что у него левое ухо было КВАДРАТНОЕ. Оказалось так описано в техническом задании. В срочном порядке хирургу вели ухо отрезать. Он и отрезал, но под корень. А это уже не по плану, ведь по плану у Святого должно быть два уха. Иначе как же он будет пользователям в доверие то входить. И ногу лишнюю отпилили. И руку нужную пришили.

И так пилили луку пилами и пилили. Два месяца и две недели.
И вот косоглазый и хромой Святой Лука вышел на суд людской. А его никто и не заметил. Ибо Лука, да еще и святой, ну нахуй никому не уперся.

четверг, 13 января 2011 г.

2011 year summary

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

В конечном итоге, при всей моей любви погружаться в прошлое, все равно остаюсь мечтателем погруженным в настоящее и будущее. Поэтому решено написать этакий постскриптум только начинающемуся году. А потом в конце посмотреть, насколько дальновидным оказалось планирование.

Трудность работы с програмистом заключается в том, что вы не можете понять что он делает до тех пор пока не стало слишком поздно.
— Seymour Cray


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

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

Чуть ранее была создана библиотека, которую хотелось использовать для примеров в вышеописанных статьях, а сейчас использую для создания непосредственно инструмента.

Назвал эту библиотеку - "Эффект Доплера" в честь одного из эпизодов "Теории Большого Взрыва" и его героя доктора Шелдона Купера. Библиотека разделена на несколько частей - core с прототипами, полезными классами и удобными в работе обобщениями и непосредственно на Collector. Сейчас это находится в стадии pre init developing, но уже в феврале-марте решение должно быть закончено и приведено к версии 0.1

Для реализации непосредственно Коллектора используется twisted, lxml (XML/XSLT), py-Routes.

Коллектор является этаким комбайном - отслеживает авторизацию, разделяет запрос пользователя на набор логических кусков, активно использует кеширование (в планах для начала memcached и redis).

Общая схема веб-сайта с использованием Коллектора "ЭД" выглядит как-то так:

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

Ах да. "ЭД" лицензирован будет под GNU LGPL-3.

От Советского Информ Бюро. Говорят все радиостанции Советского Союза.
Была такая компания когда-то СУ-29. И я там работал. Написал несколько любопытных программ. Хотя некоторые были не так и хорошо написаны. Одна из них являлась транспортом между сетевыми сервисами (DHCP, web-ERP, IP-Telephony Hardwares).

С тех времен прошло 4 года. Оказывается эта транспортная схема проработала все это время практически без сбоев. В процессе однако отмерли некоторые части, но схема транспор для телефонии оказался столь приятным, что мне предложили переписать. Это либо будет довесок к "ЭД", либо частично расширит его функционал.

У нас казино будет свое и лучше. С блекжеком. И шлюхами!
Есть один любопытный проект который хочется закончить к лету. Кавайный проект, для няшных людей. :) И да. Офкос с блекджеком и шлюхами. И конечно лучше чем у других. С учетом всех новомодных трендов гг.


Аппетит приходит во время еды.
Покупкой прошлого года стал замечательный фотообъектив Canon EF 135 f/2L USM. С его помощью удается делать весьма примечательные фотографии. Такое ощущение, что он прямо пришелся в руку. Каждая прогулка с "моей прелестью" заканчивалась парой хороших, красивых фотографий. Не стали исключением и новогодние праздники.

Поэтому в новом году хочется скопить левых деньжат на покупку другой няшки -
Canon EF 50 f/1.2L, который куда веселее моего 24-70 :) И заодно продать последний кому-нибудь ^^