Эту статью я хочу посвятить временами нелегкой, но увлекательной профессии ИТ-аналитика. На Хабре не так много материалов по данной дисциплине. К примеру, по управлению проектами – на порядок больше. Но выложенные недавно две статьи (раз и два), похоже, вызвали интерес, посему я тоже хотел бы внести свой скромный вклад. Сам работаю более 8 лет в роли аналитика, так что постараюсь не потратить Ваше время зря.
Не стану пересказывать теорию (ее можно почерпнуть в замечательной книге Вигерса или в BABOK). Мне бы хотелось сосредоточиться на практической стороне вопроса – описать выжимку из «боевого» опыта, как своего, так и некоторых других людей, с которыми мне посчастливилось работать.

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

Мы захотели узнать, почему уходят игроки и можно ли предсказать их уход. Предмет исследования – ММОРПГ Аион, однако наши результаты оказались применимы к широкому кругу игр и онлайн сервисов.

Переписывал в островке кусок одного сервиса с Python на Erlang. Сам сервис занимается тем, что скачивает по HTTP значительное количество однотипных HTML страниц и извлекает из них некоторую информацию. Основная CPU нагрузка сервиса приходится на парсинг HTML в DOM дерево.

Сперва захотелось сравнить производительность Erlang парсера mochiweb_html с используемым из Python lxml.etree.HTML(). Провел простейший бенчмарк, нужные выводы сделал, а потом подумал что неплохо было бы добавить в бенчмарк ещё парочку-другую парсеров и платформ, оформить покрасивее, опубликовать код и написать статью.
На данный момент успел написать бенчмарки на Erlang, Python, PyPy, NodeJS и С в следующих комбинациях:

• Erlang — mochiweb_html
• CPython — lxml.etree.HTML
• CPython — BeautifulSoup 3
• CPython — BeautifulSoup 4
• CPython — html5lib
• PyPy — BeautifulSoup 3
• PyPy — BeautifulSoup 4
• PyPy — html5lib
• Node.JS — cheerio
• Node.JS — htmlparser
• Node.JS — jsdom
• C — libxml2 (скорее для справки)

В тесте сравниваются скорость обработки N итераций парсера и пиковое потребление памяти.

Интрига: кто быстрее — Python или PyPy? Как сказывается иммутабельность Erlang на скорости парсинга и потреблении памяти? Насколько быстра V8 NodeJS? И как на всё это смотрит код на чистом C.

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

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

Давайте рассмотрим, что стоит сразу же учесть при обсуждении проекта интернет-магазина.

Толстые модели.

Некоторое время назад пришлось мне производить мероприятия по переименованию моих танков. Связано это было с претензией некоторой компании, которой не понравилось использование слова «Frontline» в сочетании с военной тематикой (удивительно, с чем же еще может ассоциироваться «линия фронта»?) с военной тематикой игры. Но этот пост не об этом. Проверяя как-то результаты переименования, я искал приложения на Google Play и увидел странную картину.

Программисты очень по разному относятся к тестированию, и многие не любят писать тесты. Процесс TDD же для новичков не особенно понятен — ведь приходится вместо функционала программы писать вначале тест, который его проверяет, то есть количество работы увеличивается. Однако со временем приходит осознание того, что автоматическое тестирование необходимо. К примеру, возьмем процесс разработки даже несложного проекта на django, пока в проекте пара вьюх и моделек все просто. Когда приложение обрастает функциями, внезапно обнаруживается, что совершать такое тестирование все сложнее — кликов больше, надо вносить какие-то данные и т.д., вот тут-то и на помощь приходит behavior-driven development (BDD).



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

В данном посте представлен обзор новшеств и особенностей популярного среди Python разработчиков фреймворка Django 1.7. Релиз позиционируется как сообществом, так и основными разработчиками — как наиболее значимый релиз, с момента выхода в свет Django 1.0.

Лет пять-шесть назад, когда я ещё программировал преимущественно на PHP, я начал использовать библиотеку curl для парсинга сайтов. Мне нужен был инструмент, который позволял эмулировать сессию пользователя на сайте, отсылать заголовки обычного браузера, давать удобный способ отсылки POST-запросов. Сначала я пытался использовать напрямую curl-расширение, но его интерфейс оказался очень неудобным и я написал обёртку с более простым интерфейсом. Время шло, я пересел на python и столкнулся с таким же дубовым API curl-расширения. Пришлось переписать обёртку на python.

В последнее время все чаще на телевизионных экранах, страницах газет, в Интернете можно увидеть или услышать слова “Тендер”, “Госзакупки”, “Госзаказ” … Как правило эти термины в СМИ употребляются в контексте коррупции, откатов и наглости чиновников. Но в нашей стране есть уже десятки тысяч компаний, которые активно участвуют как в государственных так и корпоративных закупках и весьма неплохо на этом зарабатывают.

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

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

Удачная возможность для веб-разработчиков выучить язык программирования Си — HTML5-парсер Gumbo, реализованный в виде небольшой библиотеки C99 без внешних зависимостей. Парсер создан как строительный блок для создания других инструментов и библиотек, таких как валидаторы, языки шаблонов, инструменты рефакторинга и анализа кода.

Особенности:

• Полная совместимость со спецификациями HTML5.
• Устойчивость к некачественным входным данным.
• Простые API, которые могут быть легко обработаны программами на других ЯП.
• Поддержка исходных позиций и указателей в оригинальном коде, при навигации по дереву зависимостей.
• Проходит все тесты html5lib-0.95.
• Проверен на более чем 2,5 млрд страниц в индексе Google.

Введение

Приветствую читателей.
В ходе разработки проекта, мне понадобилось сделать небольшой парсер для смежного сайта.
Незадолго до этого командой было принято решение использовать фреймворк Dojo
В результате размышлений родилась идея сделать красивый парсер Хабра, заодно осовоив Dojo и решив проблему экономии трафика для мобильного (часто читаю в пути).
Данное руководство несёт чисто практический характер и не претендует на идеальность исполнения.

В прошлом топике я рассказывал о том, как мы с другом решили ради развлечения написать свой встраиваемый язык программирования для платформы .NET. У первой версии был серьезный недостаток — парсер был реализован на F# с помощью сторонней библиотеки. Из-за этого требовалась куча зависимостей, парсер работал медленно, а поддержка его была крайне муторным занятием.

Очевидно, что парсер нужно было переписать на C#, но при мысли о написании парсера с нуля вдруг находилась дюжина других срочных дел. Таким образом таск перекидывался и откладывался практически полгода и казался непосильным, а в итоге был сделан за 4 дня. Под катом я расскажу об удобном способе, позволившим реализовать парсер достаточно сложной грамматики без использования сторонних библиотек и не тронуться умом, а также о том, как это позволило улучшить язык LENS.

Но обо всем по порядку.

… а именно как писать LL парсеры для не очень сложных структур при помощи конструирования сложного парсера из более простых. Изредка возникает необходимость распарсить что то несложное, скажем некую XML-подобную структуру или какой нибудь data URL, и тогда обычно возникает либо простыня хитрого трудно читаемого кода либо зависимость от какой то ещё более сложной и хитрой библиотеки для парсинга. Здесь я собираюсь совместить несколько известных идей (какие то из них попадались на Хабре) и показать как можно просто и лаконично написать довольно сложные парсеры уложившись при этом в совсем немного строчек кода. Для примера я буду писать парсер XML-подобной структуры. И да, я не буду вставлять сюда картинку для привлечения внимания. В статье вообще картинок нет, поэтому читать будет трудно.

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

Когда фирмы обращаются за консультацией по поводу автоматизации бизнеса в целом и внедрения CRM в частности, нередко наблюдается один и тот же симптом: нужна не инфраструктура с нуля, нужна замена другому софту. Это зачастую сложная ситуация, особенно, когда видишь, что софт стоит адекватный, хоть и старой версии, а пользоваться им не умеют или не хотят. Приходится собирать представителей клиента и с сожалением объяснять, что кнопка «Сделать всё» так и не создана, а любое ПО требует ответственной работы со стороны человека.

Пост является значительной переработкой статьи The Complete Guide to China’s Major Social Media Networks с моими правками, комментариями и некоторыми иллюстрациями. А ещё добавил правильное русское чтение китайских сервисов.

17 апреля 2014 г. китайский аналог Twitter'а — Sina Weibo – вышел на американскую биржу. Благодаря IPO компания привлекла меньше ожидаемого, однако это, безусловно, большой успех китайских социальных медиа-ресурсов. Поэтому стоит сделать небольшой обзор существующих на сегодняшний день китайских социальных интернет-ресурсов. Разумеется, он не претендует на абсолютною полноту и объективность, поэтому смело пишите свои дополнения и замечания.

Платформы и сервисы, о которых пойдёт речь, имеют как настольный, так и мобильный клиент, если прямо не указано другое.
Так же следует помнить, что многие иностранные ресурсы – такие, как Facebook, Twitter, YouTube, частично Википедия – заблокироавны в КНР, поэтому местные жители пользуются китайскими аналогами, зачастую не зная о существовании оригиналов. Кроме того, везде существуют списки «плохих слов» (в основном плохих политически), ввод которых блокируется, либо активность таких пользователей тщательно отслеживается. Под Китаем, разумеется, будем иметь в виду его материковую часть, не считая Гонконга, Макао и Тайваня, где цензура компартии не работает.

Категории социальных медиа

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

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

Уровни управления проектом

ITIL[1] — библиотека книг в которых подробно и всесторонне описываются различные «хорошие» практики управления ИТ-услугами (IT Service Management). У книг ITIL разные авторы, описанные в них процессы и рекомендации никто между собой не согласовывал, так что любимый тезис специалистов по ITIL — ITIL нельзя внедрить, только адаптировать. Логическим выводом из этого будет то, что ITSM-решение нельзя получить из коробки.

Прежде, чем запустить Service Desk и завести первые тикеты, вам придется сначала получить сертификат по ITIL, пройти обучение по выбранному ITSM-продукту, пригласить консультантов, потратить несколько месяцев и несколько миллионов рублей на проект. Есть, конечно, бесплатные решения, которые можно настроить самому, но голову в процессе настройки придется поломать изрядно. Не лучший подход, особенно для небольшой ИТ-службы с ограниченным бюджетом и ресурсами.

Исходный тезис про необходимость адаптации сам по себе правильный. Конечно, потребуется несколько лет, чтобы обнаружить и автоматизировать несколько десятков процессов, описанных в ITIL. Однако если компания вообще не сталкивалась с ITIL и ITSM, то ни большей части этих процессов, ни какой-либо потребности в них у нее просто еще нет.

В реальности с чего все начинают внедрение Service Desk? С управления инцидентами или если проще с заведения тикетов. Откровенно говоря, не самый сложный процесс — пришла заявка открыли тикет. Выполнили заявку — закрыли тикет. На этом этапе автоматизации вникать в теоретические сложности и особенности системы не требуется.