Pivot не нуждается в представлении. Если вбить это слово в поиск хабра, результатом будут 37 статей, среди которых есть как обзоры, так и туториалы. Поэтому я решил сосредоточить свои усилия лишь на одном аспекте работы с Pivot — на картинках.

Доброго времени суток.
В этой статье я хочу сделать обзор одного из главных нововведений в Visual Studio 2010, а именно — функционального языка программирования F#.

Рассматривать синтаксис и потенциал F# мы будем на примере создания своего собственного интерпретатора для придуманного нами языка программирования (Ведь рассказвать о чем-то всегда интереснее на примерах).

Hg Init: Учебное пособие по Mercurial.

Mercurial — это современная распределенная система контроля версий с открытым кодом. Эта система — заманчивая замена для более ранних систем вроде Subversion. В этом простом учебном пособии в шести частях Джоэль Спольски (Joel Spolsky) рассказывает о ключевых принципах Mercurial.

Если вы использовали Subversion, то Mercurial будет непонятным. Эта часть рассказывает о главных отличиях при работе с Mercurial. Если вы никогда не использовали Subversion, то можете просто пропустить эту часть.

Часть 1. Переобучение для пользователей Subversion

В каком же я был смятении, когда программисты в моей компании решили сменить Subversion на Mercurial!

Для начала, я начал приводить всевозможные тупые причины, по которым нам не надо ничего менять. «Мы должны хранить репозиторий на центральном сервере, так безопаснее», — сказал я. Знаете что? Я был неправ. При работе с Mercurial у каждого разработчика на жестком диске хранится полная копия репозитория. Это, на самом деле, безопаснее. В любом случае, почти в каждой команде, использующей Mercurial, центральный репозиторий тоже существует. И вы можете делать резервное копирование этого репозитория со всей необходимой одержимостью. А еще можете устроить трехступенчатую защиту с Сайлонами, Штурмовиками и прелестными лабрадудлами или что там требует ваш IT-отдел.

Чтобы было понятно, на чём следует концентрироваться при оптимизации, слайд из доклада «Создание программных систем в Google и его уроки»:

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

Node.js — вещь, вокруг которой сейчас много шума, восторженных отзывов и гневливых выкриков. При этом, по моим наблюдениям, в умах людей закрепилось следующее представление о том что же такое Node.js: «это штука, позволяющая писать на JavaScript на серверной стороне и использующая JavaScript-движок от Google Chrome». Поклонники языка восторженно вздохнули: «Ах! Сбылось!», противники же процедили сквозь зубы: «Ну вот только еще этой ерунды с прототипами и динамической типизацией нам на серверах не хватало!». И дружно побежали ломать копья в блоги и форумы.

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

Первый раз достаточно близко я познакомился с тестированием лет 5-6 назад, как раз начало моей карьеры. Тогда, я помню, мне рассказывали про покрытие кода тестами. Причем никаких Unit тестов меня не просили писать, просто говорили: “вот видишь if с тремя условиями, который ты написал, ты должен проверить все эти три условия”. Подразумевалось, что я, после того как напишу код, должен его проанализировать, и полностью протестировать обычным проходом по интерфейсу приложения. Как вам? Со временем знания в тестировании у меня немного выросли, я немного научился писать тесты. Я до сих пор не видел и не участвовал ни в одном живом проекте, написанным при помощи Test Driven Development (TDD) подхода. Основа моих знаний была в подглядывании того, как делают это коллеги в предыдущей моей конторе, чтении статей (например, у Алесандра Бындю была отличная статья “TDD для начинающих. Ответы на популярные вопросы”), просмотра пару сринкастов. Я решил покончить с безграмотностью и проникнуться темой, для этого я сел за прочтение книги The art of Unit Testing with Examples in .NET. Притом, что в текущей конторе? можно сказать, что тесты пишу только я для своего кода. Нужно быть образцом.

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

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

Истощение

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

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

Сказка про то, как мы биллинг проектировали

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

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

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

Для django есть хорошая утилитка, которая анализирует описание модели данных и рисует её графическое представление в dot-формате graphviz.
Сегодня переписал эту утилитку под appengine.



Утилита распознаёт Expando (добавляет многоточие в список атрибутов),
наследование от PolyModel (рисует стрелки наследования),
а также ссылочные свойства (в том числе самодельные, типа ManyToManyProperty).

Как пользоваться:

1. засунуть скрипт в каталог с sdk
2. запустить её из корневого каталога приложения, указав аргументами список модулей для анализа (в формате имён дя import):
   python path/to/modelviz.py models.foo models.bar > models.dot
3. сконвертить полученный dot-файл во что-нибудь более удобное, например, в png:
   dot models.dot -Tpng > models.png
4. наслаждаться неземной красотой

Дело началось с того, что одна небольшая английская компания решила рассылать рекламные листовки своим существующим и потенциальным клиентам.
Обнаружилась проблема: есть отдельная внутренняя база клиентов, делавших заказы по телефону; отдельная база веб-клиентов, делавших заказы на сайте; и несколько баз «потенциальных клиентов» от разных информаторов.
Тысячи клиентов попали сразу в несколько баз, или даже несколько раз в одну базу.
Если клиент, «засветившийся» пять раз, получит пять одинаковых рекламных листовок с немного отличающимся написанием имени или адреса, то эффект от такой кампании получится противоположный — не говоря уже о бессмысленных расходах на лишние листовки.
Как же отсеять повторы в списке рассылки?

Среди всех данных о клиенте самое однозначное, что его определяет — это почтовый индекс (postcode). Этого мало, но это хорошая отправная точка.

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

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

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



Итак, хочется исправить эти проблемы. А именно, написать корректор коротких фраз или запросов, который:

• умел бы выявлять три (и более) ошибки в запросе;
• умел бы проверять «разорванные» или «слипшиеся» фразы, например expertsexchange — experts_exchange, ma na ger — manager
• не требовал много кода для реализации
• мог бы достраиваться до исправления ошибок на других языках и других типов" ошибок

Остальное — под катом.

Почти год назад, 27 октября, мы объявили об открытии сервиса Яндекс.Почта для домена.

Всё это время мы внимательно прислушивались к отзывам владельцев доменов и активно работали над сервисом. Обо всех заметных нововведениях в Почте для домена мы писали (и, конечно, продолжим писать) в блоге Яндекс.Почты.

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

Сегодня мы объявляем о запуске собственного DNS-хостинга. Это значит, что для подключения сервиса Яндекс.Почта для домена (а также дополнительных сервисов, — таких, как Jabber на вашем домене) достаточно делегировать домен на Яндекс.

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

Отдельно хотим обратить ваше внимание на то, что редактирование DNS-записей — процедура, требующая определённых знаний и навыков. Пожалуйста, будьте внимательны.

Сейчас к Яндекс.Почте для домена подключено уже более 20 тысяч доменных имён. Присоединяйтесь!

Еще давно очень многих интересовал один вопрос: «Эта программа занимает всего 100 кб, что за музыку она воспроизводит? Как это работает?»

Так вот, называется это чудо – Трекерная музыка. И что самое главное – она занимает очень мало места, в отличие от .mp3 или .wav. В современных популярных ОС трекерные файлы (MOD, XM, S3M, IT и пр.) проигрываются большинством медиаплееров, например, Winamp, VLC, Amarok, Audacious и другими.

Скачать такую музыку можно, например отсюда — keygenmusic.net, или отсюда www.modarchive.org. Это отнюдь не единственные ресурсы, стоит только обратиться к поиску.

Для того, чтобы воспроизвести такую музыку в своей программе, нам потребуется минимальное знание C++, а также minifmod, доступный в исходниках. Как заявляют разработчики, minifmod добавит всего 50 кб к вашему exe-файлу (без учета сжатия).

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

Есть один замечательный сайт, посвящённый алгоритмам — наверняка многие из Вас о нём слышали и выкачивали его содержимое Teleport’ом или чем-нибудь подобным. Но совсем недавно Максим (автор сайта) создал очень удобную pdf-книжку из всех статей, что присутствовали на сайте. Я знаю, что ему будет приятно узнать, что его труды пригодились IT-сообществу, поэтому я и решил написать тут о электронной книге с алгоритмами.

Хотел бы рассказать вам о том, как PayPal и его замечательная система Buyer Protection защищает ваши покупки в сети. Или скорее не защищает.

В середине июля я заказал себе iPad. Оплатил покупку карточкой и ждал заветной посылочки. Через полторы недели пришел акт о вскрытии в котором говорилось, что коробочка пришла с недовесом в почти 700 грамм. Кто-то спер планшет, но почему-то оставил коробку, зарядку и все остальное. В добросовестности продавца я не сомневался, по трекингу было видно, что посылка отправлялась весом в полтора килограмма.

Первое что я сделал, как рекомендует eBay, связался с продавцом. Он отмахнулся, мол я товар отправил, ничего не знаю. Делать нечего, создал спор на PayPal.