Добрый день.

Предыдущие уроки вы можете найти по следующим ссылкам:
Уроки B01-B03
Уроки B04-B08

Сегодня на платформе Android доступно более 600 000 приложений, в которых очень легко потеряться. Один из самых надежных способ стимулирования скачиваний – это получение приложением в Google Play титула «Выбор редакции», но до сих пор компания не объяснила, какими принципами она руководствуется, чтобы определить, пригодно ли приложение для того, чтобы получить такую рекомендацию.

На конференции Google I/O, прошедшей на прошлой неделе, заступники всех разработчиков Дэн Галпин и Йан Льюис предложили разработчикам для Android несколько шагов, следуя которым они могут увеличить шансы своего приложения попасть в список рекомендуемых на Google Play.

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

Многое, о чем я буду говорить, будет похоже на откровения капитана, а какие-то высказывания, возможно, могут кому-то показаться окрашенными в назидательный тон (хотя я никоим образом этого не хотел). Заранее прошу у читателей отнестись к тексту снисходительно, т.к. всё, что вы прочтете ниже, лишь изложение мыслей автора вслух по теме, и ничего больше.

Xpath — это язык запросов к элементам xml или xhtml документа. Также как SQL, xpath является декларативным языком запросов. Чтобы получить интересующие данные, необходимо всего лишь создать запрос, описывающий эти данные. Всю «черную» работу за вас выполнит интерпретатор языка xpath.
Очень удобно, не правда ли? Давайте посмотри какие возможности предлагает xpath для доступа к узлам веб-страниц.

Никак не могу дописать документацию по Grab:Spider — это часть библиотеки Grab — для написания асинхронных пауков. Подумал выкладывать куски документации на хабрахабр. Думаю, с некоторым фидбэком дело быстрей пойдёт. На данный момент в документации есть лишь введение, описывающие в общих чертах, что за это за зверь такой Grab:Spider. Его и выкладываю.

На хабе появилось несколько топиков об «однострочниках» на разных языках, которые решали простые задачи. Я решил опубликовать несколько алгоритмов на языке C/С++.
Итак, поехали!

Часть 1.

Введение.

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

Все переводы можно разделить на две части:
a) Те что непосредственно в файлах с расширением .py — с ними все просто.
b) И те что в шаблонах — к ним придется написать небольшой велосипед :).
Ну и далее нужно автоматизировать процесс управления переводами.
Итак добро пожаловать под кат.

Открылся веб-сервис TinyPNG, на котором можно быстро конвертировать полноцветные PNG24 в индексные PNG8 с сохранением альфа-прозрачности. Сайт работает на известных open source утилитах, так что квантование палитры можно сделать и без него, но здесь это просто удобнее.

Как вы не знаю, но я себя на этой картинке узнал. Ведь, согласитесь, когда проектируется архитектура приложения, все красиво, логично и соответствует лучшим мировым практикам. Но в процессе работы, сталкиваясь с ограничениями предъявляемыми архитектурой, мы зачастую думаем: «Вот здесь немножко нарушу, это ведь сэкономит мне час времени разработки. Ну а потом, как будет время, поправлю». Но, почему-то, это время так никогда и не наступает. На мой взгляд, единственным способом заставить себя, как программиста, следовать разработанной архитектуре, это научить среду разработки все отклонения и костыли показывать как ошибки компиляции. В этом случае, если код плох, он сразу будет исправлен, ну а если архитектура устарела, то будет исправлена она. Т.е. в хранилище кода всегда будет код соответствующей запланированной архитектуре.
Пара слов, о том, что будет подкатом:
1. Небольшая преамбула.
2. Восстановление архитектуры по имеющемуся проекту.
3. Настройка Visual Studio и TFS для автоматического контроля архитектуры.
Под катом много картинок и желание все описанное попробовать.

Хочу поделиться полезным скриптом для поиска проектов на odesk.com Честно говоря, я не понял, как на odesk.com задать вопрос с OR оператором, чтобы за один присест найти все интерсующие меня проекты, поэтому я искал в несколько подходов, что не очень удобно. Этот скрипт решает проблему. Я поставил его на крон, добавил закладку на локальный файл в браузер и просто смотрю её периодически.

Код скрипта под катом:

Статья описывает разработку скрипта на языке Python. Скрипт выполняет парсинг HTML-кода, составление списка материалов сайта, скачивания статей и предварительную очистку текста статьи от «посторонних» элементов. Используется библиотеки urllib (получение HTML-страниц), lxml (парсинг HTML-кода, удаление элементов и сохранение «очищенной» статьи), re (работа с регулярными выражениями), configobj (чтение файлов конфигурации).

Для написания скрипта достаточно базовых знаний языка Python, навыков программирования и отладки кода.

В статье даются пояснения по применению библиотек на примере составления списка публикаций С.М. Голубицкого, приведена ссылка на работающий скрипт.

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

• создать паука, выполняющего GET запросы,
• извлекать данные из HTML документа,
• обрабатывать и экспортировать данные.

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

Недавно (буквально два года назад) тут пробегала статья Только 10% программистов способны написать двоичный поиск. Двоичный поиск — это классический алгоритм поиска. Мало того, это еще чрезвычайно простой алгоритм, который можно очень легко описать: берем отсортированный массив, смотрим в середину, если не нашли там число, в зависимости от того, что в середине — ищем это число этим же методом либо в левой части, либо в правой, откидывая средний элемент. Для функций также, просто берем не массив, а функцию. Все очень и очень просто, алгоритм описан почти везде, все баги словлены и описаны.

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

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

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

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

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

Я думаю стоит сразу упомянуть, что на всех этапах мы использовали:

• Модульные тесты с покрытием около 50%
• Continuous Integration с запуском модульных тестов (в последствии и интеграционных), автоматической сборкой и выпуском релиза
• Пересечение из гибких методологий под общим названием ScrumbanXP

Везде, где я буду говорить про автоматизацию тестирования, речь будет идти про тестирование интерфейса с подключением к внешним ресурсам (БД, файловая система, сервисы и т.п.).

Правило №1. Делайте все авторизационные куки HttpOnly

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

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

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

Прошло почти 3 недели с момента публикации моего первого поста о коллекциях объектов в PHP. За это время было сделано много работы и получено много опыта, которым я хочу поделиться. Наибольшее количество изменений претерпели карты, большая часть внимания будет уделена именно им.

В этом посте вы увидите:

• Проект и реализацию коллекций объектов в PHP.
• Тесты производительности.
• Впечатления о написании первых Unit тестов.
• Интересную информацию о работе с множествами объектов PHP.

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

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