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

Для решения этой задачи мы решили внедрить инструмент для форматирования кода, который умел бы следующее:

1. выводить сообщения о несоответствии стандарту форматирования в виде списка, не трогая сам файл;
2. автоматически исправлять все найденные проблемы с форматированием;
3. уметь форматировать только часть файла (нам не нужно переформатировать репозиторий сразу целиком, чтобы не потерять историю).

Мы рассматривали два проекта, которые можно было бы взять за основу для написания такого инструмента — PHP Beautifier и PHP Code Sniffer. Первый умел форматировать код, но не умел печатать диагностику, а второй — наоборот, умел печатать диагностику, но не умел форматировать файлы. К сожалению, оба этих проекта, по нашей оценке, были не слишком пригодны для того, чтобы добавить в них недостающую нам функциональность, поэтому была написана новая утилита — phpcf (PHP Code Formatter). Уже в течение двух лет она работает как git pre-receive hook, настроенный на отклонение (!) изменений, которые не оформлены по нашему стандарту кодирования.

Наконец настало время открыть исходные тексты нашей утилиты для широкой публики: github.com/badoo/phpcf

Здравствуйте!

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

Сайт написан на ASP.NET MVC 5 и Web API 4, для логирования используется библиотека NLog, сайт хостится в облаке Амазона. Записи лога пишутся в три места (target по терминологии NLog): в файловую систему (подпапку Logs папки App_Data, в которую разрешается доступ на запись при стандартных настройках деплоя Amazon Elastic Beanstalk), на сервис logentries и в БД. Записи лога за день ведутся в отдельный файл, в названии которого указывается текущая дата.

Доброго времени суток, уважаемые хабравчане!

Возникла передо мной сегодня задача генерации GET-параметров и всего URL в целом, на стороне клиента, прям вот щас, без возможности «поговорить» с сервером. Сразу оговорюсь, про этот пост я узнал вот прям перед написанием данной статьи ибо сначала закончил писать, а потом уже прибег к поиску, да и пост тот — не со всем про то же самое, что у меня.

Итак, к делу.

Задача и проблемы

Проблемы — те же что и в посте, который я привел выше:

• Невозможность использовать window.location для «приготовления» URL;
• Нельзя работать сразу с несколькими window.location в силу политики безопасности браузеров;
• Отсутствие известных готовых решений ( да и сейчас, уже апосля, я не нашел подобного кода )

Задачи которые я поставил перед собой:

• Удобный синтаксис
• Возможность как читать части URL так и изменять их
• Работа с GET-параметрами
• Кроссбраузерность и универсальность

Писал я на чистейшем JavaScript, причем без использования prototype.__defineGetter__ или prototype.__defineSetter__ в угоду кроссбраузерности ибо IE < 9 такого не умеет. Более подробно про getters/setters написано в этом посте.

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

Приступим! Раньше сядем — раньше выйдем.

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

Привет, Хабр!
Лето, все в отпуске. У всех расходы. Где взять денег? У банка!
Только за этот июль крупнейший банк России выдал кредитов физическим лицам на 73 545 493 тыс. руб. Ипотечные займы Северо-Западного отделения составляет 53% от общего портфеля, потребительские кредиты — 32%, согласно пресс-релизу . Средний размер ипотечного займа за март 2014 составил порядка 1.5 млн рублей. Средний размер автокредита составляет
не менее 0.5 млн рублей. Спасибо lany за предоставленные ссылки.
Исходя из вышеприведенных цифр, можно предположить, что банк умудрился за месяц выдать кредит около двумстам тысячам человек.
Конечно, в этом банке используют скоринговые системы.
Я узнал про скоринговые системы пару лет назад и был потрясен. Сама идея, что бездушная машина может принимать решение о выдаче кредита на основе статистических данных, не выходила из головы. Я захотел поиграть в банк и проверить, выдаст ли компьютер кредиты моим друзьям, just for fun. Настоящие скоринговые системы я никогда не видел, но решил, что это и неважно, напишу сам.
Сказано — сделано.

Исходники на репе в гитхабе.

Осторожно, много изображений!

Эта статья — продолжение доклада «Как просить деньги через телевизор», сделанного нашим проектировщиком Екатериной Юлиной (Katarios) на конференции ProfsoUX 2014. Основной темой доклада были интерфейсы коммерческих интернет-поставщиков: типичные ошибки пользовательских интерфейсов, хорошие примеры, аппаратные действия, осложняющие взаимодействие пользователя с телевизором. Отчет о конференции можно почитать на habrahabr.ru.

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

Вы знаете, что такое Selenium и/или PhantomJS? И с чем их едят? Тогда, возможно, вам будет интересен проект Dalek.js — кроссбраузерная утилита для тестирования веб-приложений.

Dalek.js позволяет писать тесты, которые ходят по веб-страничкам, щелкают ссылки, заполняют формы, отправляют данные и делают скриншоты. То же самое и даже больше делают тесты, написанные с использованием Selenium'а или Phantom.js, в чем подвох?

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

Кейс 2 — как Yoast.Com создали такой шаблон оформления заказа, которым они могли бы гордиться?

В то время как микрокопия в одиночку не сможет увеличить конверсию на 11, 3%, в этом кейсе она определенно играет ключевую роль.

Мы вернулись из отпусков и с новыми силами предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости

Вездесущий… это определённо то слово, которым можно описать язык PHP по отношению к вебу. Он действительно вездесущ. В настоящее время, среди всех серверных языков программирования, PHP используется наиболее широко. На нём написаны более 80% сайтов, при этом следующий по популярности ASP.NET со своими 17% остаётся далеко позади.



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

Именно в этом и заключается основная проблема поиска высококвалифицированных PHP-разработчиков. Относительно низкий порог вхождения и 20 лет развития языка привели к тому, что PHP-программисты стали такими же вездесущими, как и сам PHP. Многие из них могут на законных основания утверждать, что «знают» язык. Однако разработчики, которые действительно являются экспертами по PHP, способны создавать куда более функциональное, надёжное, масштабируемое и простое в сопровождении программное обеспечение.

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

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

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

Следующий момент который надо уяснить – для кого делаются такие выступления. Конечно, если говорить о стартап-соревнованиях, то они делаются для инвесторов, но кроме того они могут подготавливаться для банкиров, потенциальных спонсоров, руководства, сотрудников, клиентов, партнёров. В общем, для всех, кому необходимо что-то продать.

Третье, следует понимать, что существует несколько видов питч-выступлений:

1) Elevator pitch, длительность которого 1 минута. Основная цель – заинтересовать инвестора, чтоб получить приглашение на вторую встречу. За данную минуту необходимо успеть кратко сказать о существующей проблеме; о решении, которое вы предлагаете; и рассказать какие существуют перспективы по монетаризации данного проекта.

2) Idea pitch, длительность которого до 3 минут. Данный вид питчинга наиболее часто практикуется в стартап конкурсах. Он состоит из следующих элементов:

Прошлой осенью, вернувшись из отпуска, я обнаружил, что Дехана, наш Product Manager в UserVoice, заменила мой любимый «Roadmap» в Google Docs на доску Trello.

Моя первоначальная реакция на такие перемены была отнюдь не положительной. Проблема заключалась не в самом Trello, а в том, как мы им пользовались. Trello – это ОЧЕНЬ открытый проект. Не существует единственного “правильного” способа работы в Trello, поэтому, чтобы чувствовать себя в нем как дома, вам потребуется время для настройки «под себя».

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

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

В этой статье я не буду говорить о том зачем в javascript нужны промисы и в частности JQuery.Deferred. Также не буду приводить справочную информацию, ее достаточно в интернете. Например тут или тут или вот тут.
Эта статья для тек кто уже немного знаком с объектом Deferred из библиотеки JQuery, но не имеет опыта написания сложных цепочек (очередей).

Подготовка

Все примеры кода, рассмотренные здесь, используют асинхронный метод $.ajax(), который возвращает так называемый jqXHR в котором реализованы промис-методы (done, fail, always, then). Нам нужны будут только они, поэтому будем считать что $.ajax возвращает промис (promise).
В некоторых примерах используются методы $.map() и $.each(), которые входят в состав библиотеки JQuery.

Последовательное выполнение

Простейшее использование промисов — это последовательное выполнение асинхронных операций. То есть следующая операция не начинается пока текущая не закончится.

$.ajax('http://echo.jsontest.com/id/1')
.then(function(result){
    console.log(JSON.stringify(result));
    return $.ajax('http://echo.jsontest.com/id/2')
}).then(function(result){
    console.log(JSON.stringify(result));
    return $.ajax('http://echo.jsontest.com/id/3')
}).then(function(result){
    console.log(JSON.stringify(result));
});

Живой пример тут.

Предлагаем вашему вниманию очередную подборку со ссылками на новости и материалы.

Приятного чтения!

Содержание:

1. Поиск и анализ цветового пространства оптимального для построения выделяющихся объектов на заданном классе изображений
2. Определение доминирующих признаков классификации и разработка математической модели изображений мимики"
3. Синтез оптимального алгоритма распознавания мимики
4. Реализация и апробация алгоритма распознавания мимики
5. Создание тестовой базы данных изображений губ пользователей в различных состояниях для увеличения точности работы системы
6. Поиск оптимальной аудио-системы распознавания речи на базе открытого исходного кода
7. Поиск оптимальной системы аудио распознавания речи с закрытым исходным кодом, но имеющими открытые API, для возможности интеграции
8. Эксперимент интеграции видео расширения в систему аудио-распознавания речи с протоколом испытаний

Вместо введения

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

Цели:

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

Задачи:

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

Введение

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

Типы лицензий

Большинство современных продуктов имеют два самых распространенных типа лицензий:
• Проприетарный (собственнический) тип, когда продукт является частной собственностью авторов и правообладателей и не удовлетворяющий критериям свободного ПО (наличия открытого программного кода недостаточно). Правообладатель проприетарного ПО сохраняет за собой монополию на его использование, копирование и модификацию, полностью или в существенных моментах. Обычно полуприетарным называют любое несвободное ПО, включая полусвободное.
• Свободные лицензии (open-source software) — программное обеспечение с открытым исходным кодом. Исходный код таких программ доступен для просмотра, изучения и изменения, что позволяет пользователю принять участие в доработке самой открытой программы, использовать код для создания новых программ и исправления в них ошибок — через заимствование исходного кода, если это позволяет совместимость лицензий, или через изучение использованных алгоритмов, структур данных, технологий, методик и интерфейсов (поскольку исходный код может существенно дополнять документацию, а при отсутствии таковой сам служит документацией).

Среди рассматриваемых систем распознавания речи с открытым исходным кодом нам встретились 2 вида сублицензий BSD и GPL. Рассмотрим их более подробно

Инверсия управления (Inversion of Control) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах (“Википедия”).

Простой как Pimple, мощный как Symfony DI

Syringe — простой IoC Container написанный на PHP с большим количеством возможностей и декларативной конфигурацией.

В нем реализованы: внедрение параметров, фабричные методы, основные виды инъекций, в том числе и через интерфейс, области видимости, внедрение тега и триггеры.

Далее возможности расписаны более подробно.

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

Написать эту статью меня сподвигло отсутствие в интернете готового пошагового руководства «как реализовать фильтр товаров на ElasticSearch», а задача сделать это у меня стояла чётко и непоколебимо. Удавалось находить отрывочную справочную информацию, но никак не cookbook по решению самых тривиальных задач.

Акцентирую ваше внимание именно на symfony2, поскольку буду использовать FOSElasticaBundle, который позволяет описывать mapping индексов elasticsearch в удобных yaml конфигах и привязывать к ним сущности Doctrine ORM или документы Doctrine ODM. Промаппленные индексы заполняются из связанных доктриновских сущностей с помощью одной единственной консольной команды. Кроме того, он включает в себя вендорную библиотеку для конструирования поисковых и фильтрационных запросов. Результаты поиска возвращаются в виде массива объектов сущности или документа Doctrine ORM/ODM, привязанной к поисковому индексу. Подробнее о FOSElasticaBundle, традиционно, на гитхабе: github.com/FriendsOfSymfony/FOSElasticaBundle

Использование бандла позволяет полностью абстрагироваться от манипуляций с чистым JSON, что-то кодировать и декодировать функциями json_encode и json_decode, лезть куда-то с помощью сurl. Здесь только ООП подход!

Немного о схеме данных в SQL

Поскольку мои товары хранятся в реляционной СУБД, мне понадобилось реализовать EAV модель для их свойств и значений (подробнее: en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model )

В результате, у меня вышла вот такая схема данных:

Все закончилось Pivot-ом. Но первоначальную идею мы зафейлили.

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

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