У меня, как и у многих других программистов, есть слабость: я очень люблю различные планерки, на которых обсуждаются новые проекты и идеи. Все презентации в моем представлении делятся на 3 вида: муторное чтение цифр успеваемости начальника транспортного цеха, демонстрации системы из рук и презентация идей и решений при помощи построителя презентаций. Если с демонстрацией системы из рук программисты знакомы по сдаче лабораторных в университетах, а монотонно читающие тексты «коты баюны», постепенно вымирают как класс, то с презентациями у нашего брата явный напряг. Менеджеры еще прошли либо просмотрели курсы «молодого построителя презентаций», то молодежь ограничилась книгами типа «Уроки ПоверПоинта за 24 часа» или хуже того, один раз увидели и самотыком изучили сей продукт буржуазной экономики. Поэтому, просмотр их презентаций вызывает приступ тошноты, не говоря уже о том, что их часто перебивают, вызывая на «живое» общение. Ориентироваться в их презентациях невозможно и зачастую бессмысленно. А ведь для того чтобы создавать красивые презентации нужно немного. Попробую составить список «наставлений для программистов», что делать нельзя и что нужно.

В предыдущей части были освещены общедоступные вопросы, касающиеся SAT и P-NP: история проблемы, интуитивные определения классов и задач, указаны основные приложения SAT и основные последствия, в случаи решения P ?= NP (там же можно найти достаточное число ссылок на различный материал для самостоятельного изучения тематики).

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



картинка из статьи Boolean Satisfiability: From Theoretical Hardness to Practical Success (Communications of ACM)

Добрый день, уважаемое хабрасообщество!

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

Выкладываю на суд общественности наше творчество и краткое описание «эксперимента».

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

Восстановление формулы ранжирования

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

Рис. 1. Выбор направляющего вектора

Для решения данного вопроса был рассмотрен подход, лежащий в основе метода опорных точек, а именно – выбор такого направления, которое будет обеспечивать максимальное удаление объектов друг от друга.
Следующая задача, которая была решена — выбор стратегии обучения. Рассматривалось два варианта – сокращенная стратегия обучения, при которой учитывается порядок двух соответствующих элементов, и полная стратегия, которая учитывает весь порядок объектов. В результате экспериментов была выбрана сокращенная стратегия, которая заключается в решении следующего уравнения:(1)
, где — решение стандартной задачи квадратичного программирования при линейных ограничениях: , где
— симметричная матрица
— вектор коэффициента
— разница векторов характеристик

Данный подход на различных выборках (100 признаков и 500 признаков на 20 различных множествах поисковых запросов) показал хорошие результаты (см. табл. 1).

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

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

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

Под катом набор инструментов для аналитики и рекомендации по их настройке принятые в Touch Instinct и ценные комментарии от LinguaLeo и агентства мобильной рекламы Mobio.

На сегодняшний день существует немалое количество обзорных статей о PhoneGap, но к сожалению, написаны они или front-end разработчиками, которые решили заняться мобильными платформами, или нативными программистами, которые решили попробовать себя в кроссплатформенной разработке. И именно с этих позиций рассматриваются достоинства и недостатки PhoneGap'а, возникают статьи о том, «насколько крута кроссплатформа», или об «ущербности кроссплатформенных решений».

В качестве затравки — видео демо-приложения, написанного за 6 часов; готовым был взят UI-бутстрап, наверстанный за 3,5 часа; использовались библиотеки iScroll, backbone, underscore, Jquery, и небольшая обертка на backbone (RAD.js — rapid application development, архитектурный фреймворк, берущий на себя часть оптимизации, связанной с мобильной средой выполнения).


Еще 2 часа было потрачено на фикс движка. Но сегодня речь не о том, что что-то тормозит, дергается, или самописный свайп не всегда вовремя отрабатывает на 14000 объектах данных; речь о том, что на PhoneGap можно и нужно писать.

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

Спустя 3 года и более тысячи патчей, состоялся релиз одного из самых популярных текстовых редакторов Vim.

Ситуации взаимной блокировки

В Википедии дается следующее определение взаимной блокировки: «Взаимная блокировка (англ. deadlock) — ситуация в многозадачной среде или СУБД, при которой несколько процессов находятся в состоянии бесконечного ожидания ресурсов, занятых самими этими процессами».

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

Классический пример взаимной блокировки: первый поток (A) захватывает мьютекс M1 и следом мьютекс M2. Второй поток (B) захватывает мьютекс M2, а уже после этого – мьютекс M1. Взаимная блокировка этих двух потоков может произойти следующим образом: поток A захватывает M1, поток B захватывает M2, после этого оба потока «обречены»: ни поток A не может захватить M2, ни поток B не может захватить M1; попытки захвата мьютексов заблокируют оба потока.

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

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

Дональд Кнут (известный тем, что его книги никто не читает) пишет, что хотя первый двоичный поиск был опубликован в 1946 году, первый двоичный поиск без багов был опубликован только в 1962.

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

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

Введение

Табличная Модель Данных как основа для решений в бизнес-аналитике была предложена корпорацией Майкрософт в компоненте по имени PowerPivot, скромном дополнении к Microsoft Office Excel. С тех пор дискуссии о значении этой модели не стихают и по сей день. Апологеты новой технологии убеждены в ее революционности, скептики считают, что это не более чем эволюционная подвижка. В SQL Server 2012 Analysis Services (SSAS 2012) Майкрософт представил теперь уже серверный вариант аналитической базы данных, основанной на принципах Табличной Модели. Естественно, это не может не добавить в диспуты свежую струю.

Всем привет!
Хочу поделиться опытом организации резервного копирования файлов и MySQL/XtraDB в Amazon Web Services. Надеюсь, информация пригодится, особенно если вас «принудили» развернуть проекты в облаке, а время — ограничено :-)
Но прежде всего кратко пробежим технологии хранения данных, предлагаемые нам амазоном.

В оригинале название звучит как «How Not To Sort By Average Rating». Я подумал, что дословный перевод «Как не сортировать по усреднённому рейтингу» будет малопонятен и хуже отражает содержание статьи.

Постановка проблемы

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

Неправильное решение №1

Рейтинг= (Число положительных оценок) - (Число отрицательных оценок)

По умолчанию в Google Analytics отслеживать взаимодействие посетителей с контентом сайта довольно просто. Используя стандартный код отслеживания, вы сможете получать различную информацию такую как: время проведённое посетителем на странице (time on site), показатель отказов (bounce rate) и количество просмотров (pageviews).

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

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

Эта статья о том, как измерить степень взаимодействия с контентом при помощи кастомизированного кода отслеживания Google Analytics (далее GA).

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

Итак, представляю публике проект под девизом «Поменьше писанины! Побыстрей, дебаг!» Набор для скоростной разработки на Джанго.

Это 2 шаблона:

• шаблон конфига buildout, который подтягивает и собирает все необходимые проекту пакеты
• шаблон проекта, а именно настройки, включающие все нужные инструменты, и набор статики (готовые файлы на Haml и Sass)

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

Звук можно представить ввиде бесконечного количества волн различной частоты
и амплитуды. Волны, в свою очередь, могут иметь практически любую форму.
Из самых распространенных и чаще всего используемых можно назвать: синусоидальная (sine), квадратная (square), пилообразная(saw), треугольная (triangle), и шум (noise). Сначала попробуем разобраться с основными параметрами волны: период и амплитуда.

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

1) Кэширование результатов выполнения запросов

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

2) NoSQL решения

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

Сегодня я хочу познакомить вас с таким типом хранилища данных, который объединяет достоинства обоих подходов и при этом имеет ряд преимуществ перед упомянутыми выше решениями: In-memory-data-grid (IMDG).

Почтовые рассылки нужны не только тем, кто уверен, что пользователь не проживёт без информации о новой суперскидке или акции с летающими лопатами. Рассылка — это любое взаимодействие сервиса с пользователем через его электронную почту, например — подтверждение о регистрации или служебные уведомления. В нашем прошлом обзоре мы рассматривали преимущества и недостатки двух способов организации email-рассылок — через saas-сервисы или с помощью специализированного софта. Если говорить о сервисах, то на на рынке представлен достаточный выбор услуг почтовой рассыли. В сегодняшнем обзоре мы сравним несколько из них: наиболее популярные в России сервисы SmartResponder. UniSender и Subscribe, а также одного из лидеров западного рынка ConstantContact.



Конечно, интересных сервисов гораздо больше, например MadMimi, Mailchimp, StreamContact и другие. Читайте обсуждение не попавших в обзор сервисов в комментариях.

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

При обращению к гуглу выдаёт много статей по загрузке файлов через iframe. Алгоритм в общем сводится к:
1) Создаём скрытый фрейм (обычно просто обнуляется ширина и высота через HTML и CSS свойства)
2) Устанавливаем action формы в имя фрейма.
3) Отправляем файл. Радуемся.

Для удобства использования отдельная кнопка «Начать загрузку» не создавалась, а был повешен обработчик onChange для файлового input'a.

Представляю вашему вниманию перевод статьи под названием "Innovative Techniques To Simplify Sign-Ups and Log-Ins" от Anthony T. Перевели в компании UXDepot специально для пользователей Хабрахабра с одобрением издания Smashing Magazine.

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



Форма авторизации на сайте Basecamp

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