Хотел бы поделиться простым, но полезным инструментом. Когда много работаешь с данными, часто возникают примитивные, но долгие операции, например: «скачать 10 000 урлов», «прочитать файл на 2Гб, и что-то сделать с каждой строчкой», «распарсить 10 000 html-файлов и достать заголовки». Долго смотреть в зависший терминал тревожно, поэтому долгое время я использовал следующий гениальный код:

def log_progress(sequence, every=10):
    for index, item in enumerate(sequence):
        if index % every == 0:
            print >>sys.stderr, index,
        yield item

Эта функция прекрасна, больше года она кочевала у меня из задачи в задачу. Но недавно я заметил в стандартной поставке Jupyter виджет IntProgress и понял, что пора что-то менять:

Для чего используются базы данных, ведь есть старые добрые файлы? Чем они хуже базы данных или чем база данных лучше файлов? БД — более структурированное хранилище. Она позволяет делать транзакции, запросы и так далее. Самый простой случай: есть сервер с базой данных и несколько приложений, которые делают запросы к серверу. База данных отвечает, меняет что-то внутри себя, и всё хорошо ровно до того момента, пока нагрузка на неё не вырастает настолько, что база данных перестаёт справляться.

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

Если база не держит нагрузку на запись, то шарды можно добавлять до бесконечности. Шард устроен сложнее, чем реплика, потому что нужно как-то распределить данные по таблицам или внутри таблицы, по хэшу, по range — есть множество разных вариантов. Таким образом, добавляя реплики и шарды, вы можете делить любую нагрузку на базу данных. Казалось бы, больше желать нечего, о чём дальше говорить?

Этот пост — небольшая шпаргалка по mongodb и немного длинных запросов с парой рецептов. Иногда бывает удобно когда какие-то мелочи собраны в одном месте, надеюсь, каждый, кто интересуется mongodb, найдет для себя что-то полезное.

Не хотелось бы, чтобы пост воспринимался в ключе холиваров на тему SQL vs. NOSQL И так понятно что везде есть свои плюсы и минусы, в данном случае это просто где-то немного справки, где-то немного примеров из того, с чем приходилось сталкиваться. Примеры на mongo shell и на python.

1. Миграция в на новые версии в mongodb
   
   • До версии 2.6
   • С 2.6 до 3.0 версии
   • Новое в PyMongo
2. Запросы сравнения и логические
3. Полнотекстовый поиск в Mongodb, regexp, индексы и пр.
4. Атомарные операторы (модифицирующие данные )
5. Немного о транзакциях в Mongodb
   
   • Уникальный индекс
   • Двухфазный коммит
6. Агрегационный фреймворк и JOIN-ы в Mongodb
7. Примеры
   
   • Деревья, комментарии в Mongodb
   • Теги, блоги
   • Е-commerce, и сложные фильтры в Mongodb
8. Небольшая песочница на Python

"Это стоит $50 миллиардов"
Такую фразу должен произносить Марк Цукерберг на встречах с потенциальными инвесторами. Наверняка в этом году их будет много.

Оценка стоимости Facebook в $50 млрд. говорит об одном — Цукерберг сам стоит в 5 раз больше всей AOL, а его творение — больше Boeing. И вот уже Goldman Sachs, платиновые воротнички Wall Street, готовят «транспорт бабла специального назначения» для того чтобы урвать еще бОльший кусок.

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

А значит Марк нашел себе банкира.

Введение

Полтора года назад я пришел работать в техническую поддержку филиала одной крупной общероссийской компании. До этого технической поддержкой я не занимался, мог, конечно, переустановить, настроить ОС или настроить простейшую сеть, но сильно не вникал. По мере накопления знаний, возникла необходимость их систематизировать и сохранить. Сначала у меня была специальная папочка, куда я складывал обычные документы Word и Excel. Со временем в папке накопилось много документов, поиск нужной информации стал занимать довольно значительное время. Работал я не один, поэтому некоторые файлы необходимо было держать в открытом доступе, например, список пользователей, периодически приходилось искать информацию, нужную другим сотрудникам. При заведении нового пользователя администраторами, я заносил его в таблицу, где также содержались реквизиты для удаленного доступа на его компьютер (не все же время ходить на рабочие места, когда пользователей больше 300 человек). Актуальный файл всегда был только в одном экземпляре, у других сотрудников технической поддержки были копии, которые могли не совпадать, если один из сотрудников подключал человека или менял сетевые реквизиты, а потом забывал об этом сообщить.
Со временем появилась мысль о том, что надо все это объединить и сохранить в одно место, чтобы у всех сотрудников технической поддержки был доступ к информации, возможности ее редактирования и добавления.

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

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



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

Здравствуй хаброчеловек!

Так уж случилось, что с этого семестра в своем вузе я записался на спецкурс по паттернам проектирования. Курс проходит в виде семинаров, на которых ты (студент) должен рассказать чему научился за неделю (имеется ввиду, какие паттерны изучил и применил на практике).

Недавно решил отделиться от «Wi-Fi соседей» и перебраться в 5 Ghz, для чего был приобретен роутер Cisco Linksys EA4500. К роутеру можно подсоединить USB Storage, который раздается через SMB и FTP. Захотелось заставить Time Machine делать бэкапы на это чудо устройство. В результате гугления долго не получалось заставить Time Machine от Mac OS X Mountain Lion порадовать меня, пока не наткнулся на одну статью, адаптивный перевод которой и представляю вам для ознакомления ниже.

C Новым Годом всех, кто не может в праздники без мозговой деятельности и без хабра.
Продолжаю полюбившуюся серию постов (раз, два) про теорию и практику ведения семейного бюджета в Google Docs.

Я честно вел свой бюджет, написанный в Google docs год назад, и родил новую версию и новую философию (для себя) ведения бюджета. Чем и спешу поделиться.

Вступление

Я знаю, что есть много специализированных систем для семейного бюджета вроде 4 Конверта или ИзиФинанс, но я люблю все делать сам, ибо это позволяет сделать то, что сам хочешь и своим детищем пользоваться приятнее.

Основные преимущества ведения бюджета на Google Docs:

1. Можно заполнять откуда угодно (ноутбуки, телефоны, айпады) — с помощью Google forms
2. Можно самому разрабатывать логику и визуализацию
3. Надежность и почти 100% отказоустойчивость обеспечена корпорацией зла :)

Немного философии.

Зачем мы начинаем вести бюджет? У каждого есть свои причины: понять, почему за 10 дней до ЗП кончаются деньги; понять, почему долги по кредиткам только растут; понять какие расходы лучше сократить или как накопить денег на новую машину.
Многие финансовые системы предлагают нам завести целую уйму статей бюджета и записываться свои расходы в них, не задумываясь, а зачем нам все это. Я в самом начале пошел тем же путем и столкнулся с тем, что расходы почти невозможно анализировать, т.к. часть из них были явно не постоянными (покупка ноутбука или костюма — явно расходы «по необходимости/желанию») и планировать и анализировать их невозможно.
Сферический бюджет в вакууме — это две статьи: «приход» и «расход». Каждый день вписываете расходы и доходы и смотрите, что получается. Потом у вас появляются мысли, а что мы хотим анализировать? Кто-то хочет посмотреть, а сколько в итоге уходит денег на авто (бензин, страховка, налоги, ремонт, мойка), кому-то интересно понять, сколько он тратит на развлечения (походы в рестораны, кино, бары).
Я советую делить статьи расходов не более чем на 10-15 позиций исходя из того, что вы хотите анализировать в этом году/квартале.

Мои статьи расходов выглядят примерно так:


А самое интересное — как это сделать в Гуглодоксах с подробными инструкциями и формулами и примеров — под катом.

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

• Обучающие материалы (4 статьи)
• Материалы про платформу (36 статей)
• Программирование элементов управления (39 статей)
• Программирование с использованием шаблонов (21 статья)

Полный список под катом

Добрый день, хабраюзер.

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

Идея использовать git для хранения всех своих фотографий.

Чего хотелось добиться?

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

Как оказалось, GIT с большим трудом справляется с этой задачей.

Записи с последней конференции HPC — High Performance Conference, состоявшейся 6 декабря 2012, никак не анонсировались, хотя заслуживают внимания.

Под катом видеозаписи следующих докладов:

1. Практические вопросы использования NOSQL в высоконагруженном проекте
   Дмитрий Ананьев, Руководитель группы разработки новых сервисов, Мамба
2. Как работает «умная живая миграция» в Jelastic
3. Дмитрий Лазаренко, Директор R&D, Jelastic Russia
4. Parallels Cloud Server как платформа для высокопроизводительных систем
   Дмитрий Мишин, Team-lead отдела серверной виртуализации, Parallels
5. Облачная платформа Windows Azure для высоконагруженных проектов
   Владимир Юнев, Technical evangelist, DPE, Microsoft Russia

и одно видео с фестиваля профессионального развития BitByte:

1. Badoo Desktop: оптимизация приложения на миллион юзеров
   Руководитель проекта десктопных приложений компании Badoo.

Мне постоянно приходится слышать от студентов и начинающих гейм-дизайнеров – да, честно говоря, и от бывалых программистов тоже – один и тот же вопрос, который звучит примерно так: “Какую архитектуру AI мне выбрать для своего проекта?”. Этим вопросом пестрят форумы, его можно услышать на конференции разработчиков игр GDC, и, конечно же, его не один раз вспоминают во время пре-продакшна создатели любой игры – от AAA-класса до инди. Я работаю консультантом по игровому AI, поэтому я постоянно слышу ее от своих клиентов.

Обычно, самый лучший ответ на этот вопрос – «Когда как». Вот только подобный ответ мало кого устраивает, поэтому после него мне приходится устраивать самый настоящий допрос.

Эрик Липперт — ветеран Microsoft, проработавший в компании 16 лет и стоящий за разработкой VBScript, JScript и C#.

На прошлой неделе в комментариях к одной из статей разгорелся спор о роли низкоуровневой оптимизации в программировании, и я вспомнил относящуюся к этому статью Эрика. Она была написана в конце 2003, и хотя реалии с тех пор несколько изменились — принципы остались теми же самыми. Можете мысленно заменить ASP и VBScript на PHP, JavaScript, или на другой скриптовый язык по вашему вкусу.

Эту статью я уже пытался перевести в 2005, но русский текст тогда получился неуклюжий, так что этот перевод — новый и ранее не публиковался, в соответствии с требованиями НЛО. В Переводе блога Эрика Липперта этого текста тоже нет — наверное, для них он слишком стар.

---

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

Например, за семь лет в Microsoft я получил десятки вопросов, аналогичных по своей сути этому, заданному в конце 1990-х:

У нас есть код на VBScript, и в одной часто вызываемой функции мы определяем оператором Dim несколько переменных, которые нигде в функции не используются. Не замедляется ли каждый вызов функции из-за объявления этих переменных?

Какой интересный вопрос! В компилируемом языке, таком как Си, объявление локальных переменных общим размером n байт всего лишь вычитает n из указателя стека при входе в функцию. Если n будет чуть больше или чуть меньше, затраты времени на вычитание никак не изменятся. Наверное, в VBScript точно так же? Оказалось, что нет! Вот что я написал автору вопроса:

Проблема z-index в том, что многие просто не понимают, как он работает.
Всё, описанное ниже, есть в спецификации W3C. К сожалению, не все её читают.

Описание проблемы:

Итак, пусть у нас есть HTML код, состоящий из 3 элементов.
Каждый из них внутри себя содержит по одному . А каждый , в свою очередь, имеет свой фон: красный, зеленый и синий, соответственно. Плюс ко всему, каждый позиционирован абсолютно левого верхнего края документа таким образом, что он немного перекрывает собой следующий за ним . Первый имеет z-index, равный 1, у остальных двух z-index не задан.

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

На хабре уже неоднократно упоминалось насколько китайский рынок смартфонов шагнул вперёд. Сегодня я расскажу ещё об одном аппарате из поднебесной – Jiayu G2. Это единственный смартфон с диагональю экрана в 4 дюйма, 1 Гб оперативной памяти и стоимостью до $200.

• Процессор MT6577, работающий на частоте 1ГГц
• 1 Гб RAM + 4 Гб встроенной памяти
• 2 активные сим-карты(в режиме ожидания, конечно), одна из которых может работать в 3G сетях.
• Экран IPS, 4", 480x800 точек, 16,7 млн. цветов, сенсорный, емкостный, поддержка multi-touch
• 2 камеры: задняя 8 Мп, авто-фокус и фронтальная 0.3 Мп
• Аккумулятор емкостью 2050 мАч
• Операционная система Android ICS 4.0.3
• Датчики: освещения, приближения, гироскоп, акселерометр и компас
• Коммуникации: GPS, Wi-Fi(n), BT, FM
• Габариты: 124 × 63 × 10,6 (мм)
• Масса: 140 г (со стандартной батареей)

Устройство продается в различных версиях, в минимальной комплектации его стоимость стартует с отметки в 160 долларов. Отличный ценник за такие характеристики для смартфона с диагональю экрана в 4 дюйма – это именно тот размер, который я считаю идеальным.

Думаю что большинство python программистов уже в какой-то степени знакомы с возможностями Celery. В 1-ой части я расскажу, как можно использовать RabbitMQ без celery, а во второй части — краткий обзор новых возможностей celery 3.0.
Об установке связки Django-Celery-RabbitMQ можно почитать тут.
Про использование RabbitMQ хорошо написано тут, и тут, ну и на сайте RabbitMQ.

Большинство приложений провальны. Эта жестокая реальность приводит многих разочарованных разработчиков к заключению, часто подсознательному, что преуспевание в App Store — всё равно, что разбогатеть на «золотой лихорадке»: нужно быть чертовски удачливым.



Идея «удачи» — опасное успокоительное средство, облегчающее боль неудачи. А боль — это хорошая вещь. Она показывает, что что-то идёт не так. Если моё приложение потерпело крах, я хочу знать почему. Вместо того, чтобы обвинять мироздание, почему бы не посмотреть, что ребята из tap tap tap и Tapbots делают для того, чтобы снова и снова достигать успеха.

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